Reimplementing Bitcoin Core is generally a bad idea.
I disagree strongly. Implementation follows specification, not the other way round. Bitcoiners forgetting their principles about decentralization when it comes to Bitcoin-core is just cognitive dissonance.
These are just child-illnesses. With a few more years of lifetime the Bitcoin ecosystem will be rocksolid.
Implementation follows specification, not the other way round.
In an ideal world where "specification first, then implementation" (assuming software spec can be perfect which is rarely the case), then yes. But that has never been Bitcoin.
Bitcoin Core can have bugs too or have internally inconsistent code, but when it does, you want to follow whatever it does.
It's not ideal but the ship has sailed long ago on that one. There's no going back to the "specification first, then implementation" model. Not on a live, decentralized production network worth hundreds of billions of dollars.
This is true even if certain parts of btcd / libbitcoin / [INSERT YOUR ALT. CLIENT HERE] are somehow "better written" / "more sensible" than in Core.
In a distributed consensus sense, being correct is not the ultimate goal. Being correct relative to everyone else is.
Another reason to stick to Core for consensus is that consensus is so hard (and 10x more critical for a base monetary protocol), even Core must honor its past selves. The backward-compatibility requirements for Bitcoin is the most stringent among all software we humans have ever built to-date, if it is here to stay and to have an impact that we hope for.
In summary, IMHO people are applying old mental models and existing software practices to Bitcoin, but that's a huge mistake.
Bitcoin (as a software project) is an extremely special beast, and is the first and only of its kind. The old rules / practices might not apply.
The Bitcoin Core source code that does consensus is the specification.
Making that spec be written in English rather than C++ won't make Bitcoin more decentralized, as the centralized debate would just be on two levels. You can't fight reality: computer science is yet capable of getting two different code bases to agree 100%
You can't fight reality: computer science is yet capable of getting two different code bases to agree 100%
Have you looked into "TCP" or "HTTPS" or "JSON"? Or how every plattform in the world has a compatible Android and IOS app?
This is nonsense. Just pure cognitive dissonance.
And I'm glad that it doesn't matter anyway because we will have multiple big implementations in 10 years anyway. History goes its way like water downhill.
I'm going to be honest with you. 3 years ago, in 2022, I would have expected 2025 to have a more interesting discussions about implementations than "core vs knots"
The reason many people insist that Bitcoin should have a single implementation is that Core has been captured (clear to anyone who witnessed the block size wars), and multiple competing node implementations would challenge their current total control over the network. As it stands the only time the network has seen a change of primary developers was when the current core cabal essentially performed a hostile takeover of the core repo, kicking out the original developers through the use of incredibly impressive social engineering and PR. Unfortunately the tactic was successful and now many apparently free-thinking humans believe that only core can lead the project and the possibility of the free market choosing which software to use is blasphemy.
I saw the Lightning reference in the footnote, but can’t figure out how you feel about the 4 major Lightning implementations. Do you believe we’d be better off with all Lightning development activity going into a single reference implementation?
Absolutely. It just helps if you don't accidentally re-implement base layer consensus code in your Lightning node, when you're already using a separate base layer module (bitcoind) doing the same thing (but, correctly).
I asked a CLN dev, and apparently CLN just trusts your block provider to validate and does minimal further parsing. That's exactly how to do it right.
Defense in depth is ok in some circumstances where downtime is acceptable. But Lightning isn't one of those circumstances because if you're down too long your counterparty can defraud you.
My understanding is that the bugs (both times) were in block deserialization code. People want to write bitcoin-processing applications in a variety of languages, which means we’re going to have parsers in different languages. Having only one implementation of the full node wont change that.
I disagree. I believe multiple implementations will strengthen the LONG TERM stability of the consensus system. As bitcoiners, we like low time preference.
I agree that in the short term, re-implementing bitcoin core could be a bad idea. In the long term, however, it is obvious that it is optimal to have multiple implementations.
Imagine that a three letter agency finds a bug in the bitcoin core consensus system and convinces a minority of miners to operate their honeypot mining software. This allows them to crash the network at any time and adversarially erode trust in the consensus process.
Developing multiple implementation is crucial for the anti-fragility of the bitcoin consensus mechanisms. It is much better to find the consensus bugs EARLIER (at $20k) rather than LATER (at $2M). It is difficult to imagine that only bitcoin core c++ will continue to run for 100 years. Think about all the outdated FORTRAN and COBOL software that runs our society.. that is merely 60 years old. Lets be realistic...
According to Roasbeef (and confirmed by Sipa), the transaction was non-standard and required an adversarial mining pool to make it into a block.
The question is whether the mining pool was cooperating to broadcast this transaction or was running a "custom-made" client that won't do the expected checks before including it into a block (which is, in a way, questioning the point of blaming btcd).
Speaking of which, what's the point of having tx relay checks then? If not proactively adversarial, the mining pool operator might have been running a non-standard node. Would you be happy to provide them with your hashpower?
Plus, wasn't everyone blasting Faketoshi/Wright on Twitter for not understanding the relay consensus rules?
"however, I didn't imagine someone would work w/ miners to mine it"
Its a shame that lightning developers don't care to operate under adversarial mindsets and continue to dismiss real concerns that can lose funds. Oh well, LL will just raise hundreds of millions anyways so not their problem.
Conformal maintained it for a long time before forking the code to create Decred. Why Lightning Labs opted to maintain/use the code is almost as crazy as the creation of the code itself.
It is only channel opening / closing that is affected. Nodes are still running and routing transactions. So it's not exactly "down" but rather, temporarily closed to new business.
Same for me. I'm currently seeing all channels down on my node as well. The balances of those channels are now showing as on-chain instead..... very strange.
Is it LND or btcd? I guess most common LND setup uses btcd instead of bitcoin core, and thats why everyone just says LND down... Reminder that bitcoin core is Bitcoin, everything else isn't. Use bitcoin core, it's the best, safest and the only tool for running bitcoin.
Technical bike-shedding aside, how is the average end-user going to feel about his LN daemon crashing abruptly, because of a normal flow of transactions? Things like this erode trust in LN implementations and hence LN itself.
Relevant reading: https://petertodd.org/2016/multiple-implementations-consensus-systems
Reimplementing Bitcoin Core is generally a bad idea.
I disagree strongly. Implementation follows specification, not the other way round. Bitcoiners forgetting their principles about decentralization when it comes to Bitcoin-core is just cognitive dissonance.
These are just child-illnesses. With a few more years of lifetime the Bitcoin ecosystem will be rocksolid.
In an ideal world where "specification first, then implementation" (assuming software spec can be perfect which is rarely the case), then yes. But that has never been Bitcoin.
Bitcoin Core can have bugs too or have internally inconsistent code, but when it does, you want to follow whatever it does.
It's not ideal but the ship has sailed long ago on that one. There's no going back to the "specification first, then implementation" model. Not on a live, decentralized production network worth hundreds of billions of dollars.
This is true even if certain parts of btcd / libbitcoin / [INSERT YOUR ALT. CLIENT HERE] are somehow "better written" / "more sensible" than in Core.
In a distributed consensus sense, being correct is not the ultimate goal. Being correct relative to everyone else is.
Another reason to stick to Core for consensus is that consensus is so hard (and 10x more critical for a base monetary protocol), even Core must honor its past selves. The backward-compatibility requirements for Bitcoin is the most stringent among all software we humans have ever built to-date, if it is here to stay and to have an impact that we hope for.
In summary, IMHO people are applying old mental models and existing software practices to Bitcoin, but that's a huge mistake.
Bitcoin (as a software project) is an extremely special beast, and is the first and only of its kind. The old rules / practices might not apply.
The Bitcoin Core source code that does consensus is the specification.
Making that spec be written in English rather than C++ won't make Bitcoin more decentralized, as the centralized debate would just be on two levels. You can't fight reality: computer science is yet capable of getting two different code bases to agree 100%
Have you looked into "TCP" or "HTTPS" or "JSON"? Or how every plattform in the world has a compatible Android and IOS app?
This is nonsense. Just pure cognitive dissonance.
And I'm glad that it doesn't matter anyway because we will have multiple big implementations in 10 years anyway. History goes its way like water downhill.
HTTPS isn't a consensus system. The requirements for HTTPS to work are much less stringent than Bitcoin as you don't need “bug-for-bug” compatibility.
Ignorant missinterpretation of what I said.
Https is a protocol that has many many implementations. They follow the specification and are compatible with each other.
@remindme in 7 years
I'm going to be honest with you. 3 years ago, in 2022, I would have expected 2025 to have a more interesting discussions about implementations than "core vs knots"
The reason many people insist that Bitcoin should have a single implementation is that Core has been captured (clear to anyone who witnessed the block size wars), and multiple competing node implementations would challenge their current total control over the network. As it stands the only time the network has seen a change of primary developers was when the current core cabal essentially performed a hostile takeover of the core repo, kicking out the original developers through the use of incredibly impressive social engineering and PR. Unfortunately the tactic was successful and now many apparently free-thinking humans believe that only core can lead the project and the possibility of the free market choosing which software to use is blasphemy.
Thinking about the future, that's more worrying than reasssuring
Well written article, Peter!
I saw the Lightning reference in the footnote, but can’t figure out how you feel about the 4 major Lightning implementations. Do you believe we’d be better off with all Lightning development activity going into a single reference implementation?
Lightning isn't a consensus system, so multiple implementations probably do improve overall reliability.
Basically, my LN node can disagree with your LN node on most things without all hell breaking loose. That is not true of mining in a consensus system.
Absolutely. It just helps if you don't accidentally re-implement base layer consensus code in your Lightning node, when you're already using a separate base layer module (bitcoind) doing the same thing (but, correctly).
Exactly!
I asked a CLN dev, and apparently CLN just trusts your block provider to validate and does minimal further parsing. That's exactly how to do it right.
Defense in depth is ok in some circumstances where downtime is acceptable. But Lightning isn't one of those circumstances because if you're down too long your counterparty can defraud you.
My understanding is that the bugs (both times) were in block deserialization code. People want to write bitcoin-processing applications in a variety of languages, which means we’re going to have parsers in different languages. Having only one implementation of the full node wont change that.
Nope. The bugs are in validation code added on top of deserialization; actual deserialization wouldn't have those issues.
Ah! I didn't realize that. Thank you.
I disagree. I believe multiple implementations will strengthen the LONG TERM stability of the consensus system. As bitcoiners, we like low time preference. I agree that in the short term, re-implementing bitcoin core could be a bad idea. In the long term, however, it is obvious that it is optimal to have multiple implementations.
Imagine that a three letter agency finds a bug in the bitcoin core consensus system and convinces a minority of miners to operate their honeypot mining software. This allows them to crash the network at any time and adversarially erode trust in the consensus process.
Developing multiple implementation is crucial for the anti-fragility of the bitcoin consensus mechanisms. It is much better to find the consensus bugs EARLIER (at $20k) rather than LATER (at $2M). It is difficult to imagine that only bitcoin core c++ will continue to run for 100 years. Think about all the outdated FORTRAN and COBOL software that runs our society.. that is merely 60 years old. Lets be realistic...
According to Roasbeef (and confirmed by Sipa), the transaction was non-standard and required an adversarial mining pool to make it into a block.
The question is whether the mining pool was cooperating to broadcast this transaction or was running a "custom-made" client that won't do the expected checks before including it into a block (which is, in a way, questioning the point of blaming btcd).
view on twitter.com(Nevertheless, I agree with Peter Todd position)
It's a stretch to call the mining pool adversarial. They were simply paid to mine a valid but non-std tx that wouldn't ordinarily be relayed.
Speaking of which, what's the point of having tx relay checks then? If not proactively adversarial, the mining pool operator might have been running a non-standard node. Would you be happy to provide them with your hashpower?
Plus, wasn't everyone blasting Faketoshi/Wright on Twitter for not understanding the relay consensus rules?
It increases the cost of attacks and helps prevent honest mistakes. Motivated attackers will still find a way around. It makes sense to have them.
I believe it's just weaker consensus, ie it prevents unmotivated bad behavior, but not motivated bad behavior.
What's the point of having curbs if you can just drive onto them?
"however, I didn't imagine someone would work w/ miners to mine it"
Its a shame that lightning developers don't care to operate under adversarial mindsets and continue to dismiss real concerns that can lose funds. Oh well, LL will just raise hundreds of millions anyways so not their problem.
We need more "attacks" like this.
The history of Conformal Systems, btcd, and Core go way back. For a trip down memory lane: https://bitcointalk.org/index.php?topic=192880.0
May 1st 2013
Kinda sad that they've nearly spent 10 years chasing the impossible goal of perfect compatibility with Bitcoin Core.
Conformal maintained it for a long time before forking the code to create Decred. Why Lightning Labs opted to maintain/use the code is almost as crazy as the creation of the code itself.
Don't forget to upgrade your BTCD node too!
Seems like the bug was reported weeks ago but not fixed: https://twitter.com/ajtowns/status/1587414992961216512
Is there a name for exploiting a bug for the sole purpose of increasing it's assigned priority in the ticket que?
Jumping the queue!
electrs also impacted https://github.com/romanz/electrs/issues/783
One reason why multiple implementations don't improve reliability in consensus systems: people tend to make the same mistakes!
Of course it doesn't improve reliability. Reliability is not the objective of an alternate implementation.
FUD
It is only channel opening / closing that is affected. Nodes are still running and routing transactions. So it's not exactly "down" but rather, temporarily closed to new business.
https://nitter.it/lopp/status/1587436033976795137#m
It's not fud.
First of all, you need to process blocks or the counterparty in an LN channel can eventually defraud you.
Second, even if they're honest, LN channels will eventually fail due to timeouts if your LN node can't process blocks.
There's a time window when LND can still function. But it can't go on indefinitely without a patch.
100%, and nicely explained.
It's definitely a critical issue, but it's not really "down" when plebs can still make payments, at least in the short term.
I believe the fix is already released.
All my channels are listed as inactive, and a test payment I attempted a while ago failed.
Same for me. I'm currently seeing all channels down on my node as well. The balances of those channels are now showing as on-chain instead..... very strange.
I see. Ok - I stand corrected! More details have also since come to light (that this was clearly a deliberate attack on LND).
tl;drama
Dev was sponsored by blockstream. LL calling it a sponsored attack. Since removed.
It appears the nonstandard tx would be rejected by standard mempool policy, so a miner was paid directly to include it in a block.
This needs more eyes on it! Their response was horrific, I lost a lot of respect for Stark from this.
I will send 5000 sats to whoever has the tweet screenshotted
my LND seems to sync just fine.
My synced_to_chain was showing false.
https://github.com/lightningnetwork/lnd/releases/tag/v0.15.4-beta hotfix released
is electrum rust server also affected?
Yes, but has been patched since 0.9.8: https://github.com/romanz/electrs/issues/783
btcd related
Is it LND or btcd? I guess most common LND setup uses btcd instead of bitcoin core, and thats why everyone just says LND down... Reminder that bitcoin core is Bitcoin, everything else isn't. Use bitcoin core, it's the best, safest and the only tool for running bitcoin.
lnd uses library code from btcd. even if you're using the bitcoin-core backend for lnd, this affected you
Technical bike-shedding aside, how is the average end-user going to feel about his LN daemon crashing abruptly, because of a normal flow of transactions? Things like this erode trust in LN implementations and hence LN itself.
8-(