Reimplementing Bitcoin Core is generally a bad idea.
reply
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.
reply
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.
reply
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%
reply
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.
reply
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.
reply
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.
reply
Thinking about the future, that's more worrying than reasssuring
reply
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.
reply
Nope. The bugs are in validation code added on top of deserialization; actual deserialization wouldn't have those issues.
reply
Ah! I didn't realize that. Thank you.
reply
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?
reply
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.
reply
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).
reply
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.
reply
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...
reply
Don't forget to upgrade your BTCD node too!
reply
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).
(Nevertheless, I agree with Peter Todd position)
reply
"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.
reply
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.
reply
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?
reply
Speaking of which, what's the point of having tx relay checks then?
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.
reply
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?
reply
Seems like the bug was reported weeks ago but not fixed: https://twitter.com/ajtowns/status/1587414992961216512
reply
Is there a name for exploiting a bug for the sole purpose of increasing it's assigned priority in the ticket que?
reply
Jumping the queue!
reply
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
reply
May 1st 2013
Kinda sad that they've nearly spent 10 years chasing the impossible goal of perfect compatibility with Bitcoin Core.
reply
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.
reply
reply
One reason why multiple implementations don't improve reliability in consensus systems: people tend to make the same mistakes!
reply
Of course it doesn't improve reliability. Reliability is not the objective of an alternate implementation.
reply
is electrum rust server also affected?
reply
Yes, but has been patched since 0.9.8: https://github.com/romanz/electrs/issues/783
reply
reply
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
reply
my LND seems to sync just fine.
reply
My synced_to_chain was showing false.
reply
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.
reply
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.
reply
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.
reply
All my channels are listed as inactive, and a test payment I attempted a while ago failed.
reply
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.
reply
I see. Ok - I stand corrected! More details have also since come to light (that this was clearly a deliberate attack on LND).
reply
btcd related
reply
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.
reply
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.
reply
lnd uses library code from btcd. even if you're using the bitcoin-core backend for lnd, this affected you
reply
reply