pull down to refresh

0 sats \ 8 replies \ @SwapMarket 1 May \ parent \ on: JPEGS or no JPEGS... Bitcoin dies without Fee Pressure. THAT is the Truth bitcoin
He explains this well. I am not wasting my time.
write
preview
21 sats \ 7 replies \ @Murch 1 May
There can be up to 4 MB of witness data in a block, but only 1 MB of other transaction data. Output scripts are "other transaction data". So, if you put data in an OP_RETURN, it results in a smaller block than when you put it in witness data.
So, yeah, the point doesn’t make sense to me.
reply
0 sats \ 6 replies \ @sudonaka 3 May
please explain how allowing these fiat snake oil salesmen to store more data cheaply in op_return stops them from also bloating with witness data?
reply
51 sats \ 0 replies \ @Murch 3 May
Their usecase requires the data to become available immediately and not be malleable. Witness data is malleable and therefore doesn't work for them.
Their current solution is to write data to the UTXO set by putting the data into hash-based output scripts. That outputs are unspendable and will live in every nodes UTXO set forever. It is probably that they write to OP_RETURN outputs which do not get added to the UTXO set.
reply
63 sats \ 4 replies \ @TheCharlatan 3 May
They don't care if they store it in an OP_RETURN, or an unprunable output for which also no amount extra policy can stop them. They will post it either way. Giving them and others the option of doing so in an OP_RETURN, we at least give them the option to post their data in a way that is prunable.
reply
0 sats \ 3 replies \ @sudonaka 3 May
You are also setting a cultural policy of encouraging this behavior.
Even if technically beneficial I continue to oppose it on cultural and political grounds. At this time, going forward with this MERGE means bitcoin-core endorsement of the forthcoming "built on bitcoin" shitcoins
reply
1084 sats \ 1 reply \ @TheCharlatan 3 May
I really like the following gmaxwell quote from 2015: "Since Bitcoin is an electronic cash, it isn’t a generic database; the demand for cheap highly-replicated perpetual storage is unbounded, and Bitcoin cannot and will not satisfy that demand for non-ecash (non-Bitcoin) usage, and there is no shame in that." https://gnusha.org/pi/bitcoindev/CAAS2fgQyVs1fAEj+vqp8E2=FRnqsgs7VUKqALNBHNxRMDsHdVg@mail.gmail.com/
Clearly this is a political issue, it's in the name "policy" itself. I don't think attempting to minimize harm is caving to shitcoins. I think they should be held accountable socially, but we also have to face the fact that them anchoring data in the chain is inevitable.
reply
0 sats \ 0 replies \ @sudonaka 3 May
Funny that "PR" also refers to "public relations". Since it appears the technical team incompetently solicited feedback from people at my level, the only healthy response to be expected is NACK and the solution should be rewritten at a later date.
reply on another page
42 sats \ 0 replies \ @028559d218 OP 3 May
i am as monetary-maximalist as it gets, i am a 'maxi' through and through. "bitcoin is money" is something i totally support.
however... treating another's usage of bitcoin in a way i don't like with hate and animosity is not good for Bitcoin and it's not the solution.
the 'fee pressure' i mentioned in the post is the egalitarian, honest, sustainable way to decide what gets into blocks and the best expression of the free market.
but that also requires aligning consensus and what is 'actually' being mined... with default mempool policy, no?
reply