Non-Standard OP_RETURN transaction Data \ stacker news ~bitcoin

pull down to refresh

1696 sats \ 4 comments \ @jimmysong 12h bitcoin

This is a continuation of my investigations into the OP_RETURNs begun here: https://primal.net/e/nevent1qvzqqqqqqypzq7el0qph2p6x7325zw3zr7qfvhhvk600xz8jatga4zwv9jy396tgqythwumn8ghj7cnfw33k76twv4ezuum0vd5kzmp0qy88wumn8ghj7mn0wvhxcmmv9uq3uamnwvaz7tmwdaehgu3dwp6kytnhv4kxcmmjv3jhytnwv46z7qpqhx60jwrs5pfyjhw834esuw7s0d4xha96e5vutr3sh7kfx0n0fhxqhy7fut

There have been 11700 transactions since block 894289 that have had OP_RETURN size > 83. This is way more than the 30 from the first 4 months and it's probably because of @oomahq 's challenge to make the non-standard OP_RETURNs more than 50% of the total OP_RETURNs.

Running the numbers on these, here are the fee rates that they paid compared to the median fee rate.

On average the 11700 transactions paid 191% more than the median fee rates of the blocks in which they were included. Or put another way, these transactions paid a bit less than triple the median fee rate.

1336 paid less than the median fee rate 2197 paid between the median and 50% more than the median fee rate 3516 paid between 1.5x-2.5x the median fee rate 1554 paid between 2.5x-3.5x the median fee rate 3094 paid more than the 3.5x the median fee rate

1064 were mined by F2Pool 10636 were mined by MARA Pool

You can look at all the transactions in the spreadsheet I put together: https://docs.google.com/spreadsheets/d/19c7xOw-8UasQQkyU0EjJo_CuJRLjyu3Z84IrZPpePxI/edit?usp=sharing

view all related items

105 sats \ 3 replies \ @k00b 7h

The filters certainly make OP_RETURN data more expensive. I don't think that's up for debate in the face of data like this.

Is this incentivizing people to put data in unspendable outputs, which is more expensive to the network? That probably can't be measured as easily, but it's safe to assume it is sometimes.

This is a lot like the war on drugs to me. It makes drugs more expensive, but is it worth the Nth order consequences that are not as easy to see/measure?

100 sats \ 2 replies \ @jimmysong OP 6h

That probably can't be measured as easily, but it's safe to assume it is sometimes.

I'm not sure it can be measured at all and at the very least, there are lots of of outputs that are functionally the same in the form of lost private keys. And if they can't be measured, it's futile to make concessions to them, no? Imagine if a mafia don came to your place of business and started extorting you. You have to pay some amount that he says each month. If he suddenly says, if you do X for me, I'll knock of $50 from what you owe next month, you have no idea if he'll actually knock off $50 because he determines the amount each month anyway. That's what this seems like to me.

As far as I can tell, this is the argument that if you give them OP_RETURN, perhaps the bad guys will put stuff there instead of where it hurts. I don't trust the bad guys and have no interest in conceding anything to them, especially when there's nothing stopping them from doing what you're trying to prevent them from doing anyway.

What we know from the data is that non-standard OP_RETURN is cumbersome and costly compared to normal transactions. You have to wait longer and pay more. If you make the wait shorter and the cost less, it'll naturally mean more people will use it, not just the bad guys, but lots of people that weren't even thinking about using it.

100 sats \ 1 reply \ @k00b 6h

That's a helpful metaphor. I only have questions (which is why I think some folks prefer the technical arguments).

How many of them are good (or ambiguous, e.g. OpenTimestamps) guys/txs doing harm because there's no easier/cheaper way, and how many of them are bad guys/txs doing harm because that's what they do? The quantity of each seems relevant because, at least from a utilitarian POV, we're concerned about net harm. There's no clear answer though.

Hypothetically, if we knew it meant less net harm to the network, is it worth conceding to the bad guys? If we don't know, is it worth it? What's the best way one can prove there might be less or more net harm?

I'm beginning to think McElrath has a point: it's a dilemma. That is, ignoring the technical arguments, it's bad either way.

110 sats \ 0 replies \ @jimmysong OP 5h

The answer to almost all of these if we're answering honestly is that we don't know. We have no idea because Bitcoin is not a centralized system and that's a good thing. We want people to make decisions based on their own values and profit calculations, and not on centralized dictates.

We have incentive guidelines based on economics. We know lowering the price means more people buy. We know that friction and bad user experience prevent people from adoption. But ultimately, playing with incentives to try to get a particular result is technocratic hubris. Particularly for the reason you point out. We really don't know what the second and third order effects will be. This is the main failure of central planning.

That said, I think the way to solve this is more decentralization. We should be encouraging nodes to be more self-sovereign and decide for themselves what they relay and encourage hashers to decide for themselves what they mine. Power to the people, I say.