pull down to refresh
spam is spam. there's nothing wrong with coordinating among peers to disincentivize it.
The BIP 110 approach is to go down a road of perpetual 51% attacks to root out spam. What make me nervous is that they want Bitcoiners to get used to the idea of "bad" valid transactions. If we go down this road, I have zero confidence that we stop with spam.
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:
https://m.stacker.news/129741
Secondly (of all)Secondly (of all)
I'll be honest that when I read this, it felt like you hadn't yet read the https://github.com/bitcoin/bips/blob/master/bip-0110.mediawiki#user-content-Motivation:
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 https://www.todayonchain.com/news/article/01K8NA96KBQ0SDSTPK0NCG64SK/ 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.
https://m.stacker.news/129749
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.
https://m.stacker.news/129747
Closing this down for real nowClosing this down for real now
Anyway, thanks for the opportunity to put my thoughts together a bit better.
appeal to emotion.
spam is spam. there's nothing wrong with coordinating among peers to disincentivize it.
this sort of shit is the result of the stupid block size wars where somebody wanted to make money quickly, and needed centralizing changes. compromises were made, after the "industry" pushed for 4mb blocks, and we wound up with 2mb blocks.