pull down to refresh
31 sats \ 0 replies \ @LibreHans 1 Oct \ on: MERGED: Undeprecate datacarrier - bitschmidty Pull Request #33453 bitcoin
They are in full damage control mode. Anyway, it's too late for me, the more I looked into how the decision for op_return was made, the less I could trust core devs, I'll never go back.
the purpose of the mempool is to “model what will get mined”
In 2017 we saw that nodes were sovereign, but suddenly we're told that whatever miners will mine is what we have to have in our mempool and relay. Can you find the difference in these two pictures?
Unspendable outputs are actually a good example of a working relay policy, as massive data storage only started when the taproot bug was discovered, which lowered cost and slipped by policy.
Fee estimation again... fee estimation is a terrible feature and only leads to users not learning how to manage fees properly, and about RBF.
And the main network "damage" is that spam miners risk that their blocks propagate slower, that's a feature, and bitcoin core devs always said this for the last decade until they became spam lovers.
And "inscriptions have stopped"... If inscriptions have stopped opening op_return is pointless, is it not, as there is no demand for data storage, and certainly not for one that's 4x as expensive. Btw what was the "economic demand" core devs fantasized about, but gave no evidence for?
Sorry, but it's absurd to pretend that people would resist a bugfix. The only people who would want to keep the inscription bug are the people who exploit it, and some fools who believe that we need to shovel additional funds to mining operations.
People also keep repeating that a minority relaying transactions would guarantee they are mined, but it's something that core devs have contradicted for the last decade, they used to say that the risk of slow propagation incentivizes miners to produce blocks that a majority of nodes relay.
Op_return being 4x as expensive means there are zero incentives to use it.
This post is complete nonsense. Core refused to fix the inscription bug, and then tell use filters don't work. Lol. Create problem, refuse to fix it, use problem as justification to remove all protection and create more problems.
"We" is whoever cares about bitcoins future as money. And real world experience is obviously related to programming, somebody who has been paid to write code by the market
For starters, we shouldn't fund developers who have little real world experience, or developers who are not heavily invested in bitcoin.
I have lost all faith in bitcoin core development and won't be using their product any more, so I'm not really thinking about improvements for their development process. The process to change the bitcoin I'm running is to get changes merged into knots. I don't like it like that, but it is what it is.
Your understanding seems somewhat accurate.
- Developers come up with random ideas that don't have to be about bitcoin being electronic cash
- There is no consideration for what users want
- In-groups of developers talk to each other, and when they reach consensus it's "rough consensus"
If you care about process, Sjors gave you an important part of their reasoning in the optech podcast 352 around minute 15:
okay, if we're going to increase it to 150, do we really want to have this debate every time?
It's all about governance shortcuts and doing whatever they want.
Ah yes, doing <random thing> in 2014 is the same as hard forking bitcoin, are you really that retarded? Can't wait for your talk in Berlin.
The guy who figured out how to do segwit as a soft fork wants to do a random hard fork.. sure buddy. The press is playing coretards for clicks, beautiful.
So bitcoin didn't relay transactions before 2015 when fee estimation was added? https://github.com/bitcoin/bitcoin/blob/v0.10.0/doc/release-notes.md#transaction-fee-changes
And only computer scientists without any experience in the real economy think it's a problem they can solve (they can't)