pull down to refresh

This will be a post on bitcoincore.org soon by the looks of it.
We'd like to share our view on the relation between Bitcoin Core development and transaction relay policy on the network.
Bitcoin is a network that is defined by its users, who have ultimate freedom in choosing what software they use (fully-validating or not) and implementing whatever policies they desire. Bitcoin Core contributors are not in a position to mandate what those are. One way this is reflected is by our long-running practice of avoiding auto-updating in the software. This means that no entity can unilaterally push out changes to Bitcoin Core users: changes must be made by users choosing to adopt new software releases themselves, or if they so desire, different software. Being free to run any software is the network's primary safeguard against coercion.
As Bitcoin Core developers we also consider it our responsibility to make our software work as efficiently and reliably as possible for its purpose, namely validating and relaying blocks and transactions in the Bitcoin peer-to-peer network, so that it succeeds as a decentralized digital currency. Within transaction relay, this may include adding policies for denial of service (DoS) protection and fee assessment, but not blocking relay of transactions that have sustained economic demand and reliably make it into blocks. The goals of transaction relay include:
  • predicting what transactions will be mined (for example for fee estimation or fee bumping, but it is also the basis for many DoS protection strategies inside of node software);
  • speeding up block propagation for the transactions we expect to be mined. Reduced latency helps prevent large miners from gaining unfair advantages;
  • helping miners learn about fee-paying transactions (so they do not need to rely on out-of-band transaction submission schemes that undermine mining decentralization).
Knowingly refusing to relay transactions that miners will include anyway forces users into alternate communication channels, undermining the above goals.
It is the case that transaction acceptance rules have been used effectively in the past to discourage the development of use cases that used block space inefficiently while doing so was very cheap. However this can only be effective while both users and miners are satisfied with whatever alternatives exist. When that is no longer the case, and an economically viable use case develops that would conflict with policy rules, users and miners can directly collaborate to avoid any external attempt to impose restrictions on their activities. In fact, the ability to do precisely that is an important aspect of Bitcoin's censorship resistance, and other node software with preferential peering has also shown that circumventing filters of the vast majority of the nodes is relatively easy. Given that, we believe it is better for Bitcoin node software to aim to have a realistic idea of what will end up in the next block, rather than attempting to intervene between consenting users and miners in order to discourage non-monetary activity that is largely harmless at a technical level. This is not endorsing or condoning non-financial data usage, but accepting that as a censorship-resistant system, Bitcoin can and will be used for use cases not everyone agrees on.
While we recognize that this view isn't held universally by all users and developers, it is our sincere belief that it is in the best interest of Bitcoin and its users, and hope our users agree. We will continue to apply our best judgment as developers in aligning transaction acceptance rules with Bitcoin's long-term health and miners' rational self-interest, including for specific technical reasons such as upgrade safety, efficient block building, and node DoS attacks.
Signed,
(List of contributors who support this letter)
  • Ava Chow
  • Antoine Poinsot
  • Gregory Sanders
  • Pieter Wuille
  • Gloria Zhao
ACK
A very straightforward and reasonable letter.
If people don't agree they can run something else like Knots. Running Knots won't actually accomplish anything. But no-one is stopping you.
reply
This is pretty reasonable and makes sense to me. I run Core and think they've made logical arguments throughout this most recent round of relay discussion.
That being said, I'm still in favor multiple implementations. Maybe we will get there one day...
reply
50 sats \ 0 replies \ @jgbtc 4 Jun
If out-of-band payments are so lucrative, miners will come up with creative new reasons for them. The end result of this will be a spam free-for-all and probably increased payments via "alternate communication channels". Unintended consequences are the biggest threat.
reply
1121 sats \ 6 replies \ @LibreHans 3 Jun
It sounds like they are saying that whatever consensus touching bugs and hacks they introduce, they will never fix them, but turn them into official features instead. Ossification sounds better to me, and that's something I thought I'd never say a month ago.
reply
200 sats \ 5 replies \ @k00b OP 3 Jun
Do you have a fix that you like for those bugs mentioned? There’s been lots of discussion about this elsewhere, and afaik no one has proposed a way to detect data stuffing except for specific historical methods, which when fixed would be worked around with new data stuffing methods.
reply
Core devs are clearly saying they don't want a fix.
reply
117 sats \ 3 replies \ @k00b OP 4 Jun
Core devs don’t think there’s a fix. That’s why I asked you for yours. Maybe we just need to show them The Fix and they’ll see their mistake.
reply
Indeed, there is no fix, when core devs fuck up at the consensus level, there are only consensus level fixes, which they refuse to touch. If they refuse to take responsibility for their errors, they should never touch the consensus layer again. Like I said in my first comment.
reply
What’s the consensus fix you’d like to see?
105 sats \ 2 replies \ @k00b OP 3 Jun
I know it’s not intended as such, but I’d avoid the phase “our users” because it sounds possessive.
reply
+1.
But, the strong start could and perhaps should make up for any misgivings anyone may have after, imho:
Bitcoin is a network that is defined by its users, who have ultimate freedom in choosing what software they use (fully-validating or not) and implementing whatever policies they desire. Bitcoin Core contributors are not in a position to mandate what those are.
... and I'm rather skeptical towards re-teamification of the bitcoin/bitcoin repo (because it inevitably leads to polarisation and segregation, again...), so it's a big concession for me to appreciate it, but I do think that it's really good that this is reinforced.
reply
BITCOIN™ COREporation:
reply
reply
21 sats \ 0 replies \ @anon 4 Jun
load of cope signed by the people at the helm of the fuckup.
reply
Bitcoin Core is by far one of the most amazing projects I've ever been in contact with. A truly decentralized chain of people that main goals is to keep Bitcoin true to it's original roots yet secure and flexible. I don't trust people that are against Core, but still I am totally in favor of them having an option to opt out.
reply
So, created the official blueprint for crime??
reply
Whether they are technically correct or not is no longer relevant. They lost the trust permanently because of the handling of the discussion around that pull request. Trust is lost FOREVER!
reply