pull down to refresh

well...

First of allFirst of all

it's your node... so do what you want.

personally, I'm still running a version lower than 24. I respect your right to do whatever you want with your hardware (to the extent that your hardware will support it).

some years ago, I ran Core™️'s software on a raspberry pi 3... you might have noticed that's no longer an option, because that device can no longer process the UTXO set through IBD.

I like to take it slow with my savings and I hadn't formed an opinion about BIP110 until Feb 6th, just moments before sending a friend who's a bitcoin dev a message:

Secondly (of all)Secondly (of all)

I'll be honest that when I read this, it felt like you hadn't yet read the BIP:

get used to the idea of "bad" valid transactions

Back in the days of the Captain Crunch whistle, it was possible to make the phone company's computer think a valid phone call was being made on the payphone network. That wasn't a valid phone call, it was an exploit. The p2p cash network is being exploited for data storage.

And then, your follow-up statement:

"I have zero confidence that we stop with spam" is specifically addressed in the BIP:

This is specifically addressed in the BIP.

No. It is impossible to solve spam completely, and typically spam is best fought with policy/filters, not consensus. What this softfork does is require users wanting to store large unencrypted files in the blockchain to disguise the data as financial data and/or break it up into multiple data pushes.

Lastly (for now)Lastly (for now)

Specifically, this proposal invalidates all methods of embedding contiguous arbitrary data larger than 256 bytes; it also invalidates large scriptPubKey and Tapleaf formats that are abused almost exclusively for data embedding; and finally, it restores, in consensus, the long-established 83-byte policy limit on OP_RETURN outputs.

Until v30 you (and your ancestors, who I presume will also be node-operators) were getting hosed by some of the largest, financially aligned network participants leverage fiat financial engineering to make more fiat, in a high-time preference way. So, we pay them for it... but they're not our friends.

Now the developers who forced this mempool policy change through (despite considerable pushback from the community (before retiring from the project, evidently?!?)) have opened up every future user of the software to helping those least-aligned participants get paid to store somebody's backups on every raspberry pi 4 struggling to stand up under an overweight UTXO set, in every poor corner of the earth.

It's a good time to point out that... WE DON'T PAY CORE DEVELOPERS. They're getting paid by somebody tho :) And that's probably something the community should find a better way of addressing. Same is true for politicians in the US... low salary incentivizes influence peddling.

... the fee for a data storage transaction still goes only to the miner who includes the data in a block, but the burden of storing the data falls on all node operators, who never received even a part of the fee, yet are forced to continue downloading, storing, and serving the data forever.
In this case, the miner accepts a one-time fee, and in exchange, the priceless service of highly-available, uncensorable data storage is provided in perpetuity for free by node operators.

One last thingOne last thing

If you don't like the idea of BIP110 after 1 year, then you just don't adopt any further implementation of it. If the spammers continue to operate afterwards, then we know that style of change is ineffective.

And to this point, at the risk of damaging my own argument in favor of signaling BIP110 (especially since F2Pool refuses to), I think it's important to point out that the better arguments against BIP110 are:

a) Fork riska) Fork risk

Here, I'll add my friend's final remark about BIP110... I imagine I could get more details if I poke around for it, but I don't want to push the issue with somebody who's probably had plenty of talking about it already and might be over it for now.

b) Todd demonstrated BIP110 doesn't stop spamb) Todd demonstrated BIP110 doesn't stop spam

Todd actually demonstrated that BIP110 considerably reduces the impact of this kind of data-backup exploit.

I think this is particularly significant since it's got 2 possible fork points... but, also... the fork wars were also an airdrop, if you were running a node. I do think it's necessary for the community of node-runners to re-engage with the decisive nature of bitcoin. This is a continuous process of taking responsibility for custodianship of our currency from the moneylenders and fraudsters who have done us the honor of no less than a century of total war, destruction of whole societies in the name of laundering money, and doing so in way so as to leave us (the ones who work for our money) arguing amongst ourselves.

Closing this down for real nowClosing this down for real now

Anyway, thanks for the opportunity to put my thoughts together a bit better.

21 sats \ 1 reply \ @Scoresby OP 2h

I appreciate your response here, and I agree with many of your points.

I, too, am running an old version of Core. Nor do I have any particular attachment to that project.

I've read the BIP, although I'll certainly admit that I am capable of misunderstanding things. The BIP's statements that "spam is best fought with policy/filters, not consensus" are given the lie by the very fact that RDTS is temporary. Additionally, if one listens to Luke or Dathon or Mechanic, it seems that continual forking is very much in line with the BIP 110 vision.

I think Bitcoin is quite a bit different than a telephone network. And we should be very careful about calling previously valid transaction types "exploits." It may even be the case that with Bitcoin once a transaction type is valid and widely-used, we're stuck with it.

I use bitcoin because it is the best chance I have to resist state control of my money. It achieves this by making it very hard for the state to prevent me from getting my utxos in a confirmed block.

BIP 110 claims to improve this censorship resistance of bitcoin by maintaining low burdens on node runners. But in doing so, it seems to me to sacrifice the confidence a utxo-holder has that they will be able to use Bitcoin the way they thought they could when they first bought in.

As far as I can tell, a user of bitcoin who bought bitcoin in 2011 can still use bitcoin in the same ways they did when they first started using it (plus in a bunch of new ways). And so on and so on until BIP 110. Now, there is a proposal to say all these people who used Bitcoin in a way that we don't like lose their guarantees. This seems like a very dangerous path to me.

Like I said at the top, I agree with many of your points, especially that we should be thinking about how we pay for bitcoin development. But I am entirely unconvinced by BIP 110.