Open BitcoinErrorLog opened 5 days ago
I couldn't find anyone associated with alternative implementations in contributors or authors list.
Well interestingly others had the opposite reaction! https://x.com/midmagic/status/1854768874367193467
Do note that BCAP is referring to alternative clients with consensus changes. Libbitcoin, Knots, btcd aren't being referred to by BCAP. Instead it is referring to BU, XT, the taproot activation alternative client, and any future alternative client that includes activation of a consensus change that isn't merged into Bitcoin Core. Perhaps with this clarification you have a different view? Or, is there a way for us to make it more clear that it is specifically referring to alternative clients with consensus changes?
BCAP's positives on this are that it is an important option for bitcoin to remain healthy. It is a checks & balances against a dominant implementation (Core). BCAP also covers the challenges of gaining adoption of an alternative client and the associated risks. Are there specific edits or improvements you'd suggest?
We did have reardencode review the draft, and he has been an advocate for alternative clients activating consensus changes. Now the project is public, anyone is welcome to engage, as you are now. Thank you.
On Thu, Nov 7, 2024 at 10:34 PM 1440000bytes @.***> wrote:
I couldn't find anyone associated with alternative implementations in contributors or authors list.
— Reply to this email directly, view it on GitHub https://github.com/bitcoin-cap/bcap/issues/27#issuecomment-2463885490, or unsubscribe https://github.com/notifications/unsubscribe-auth/AACPUAZDXYJSLXKP44WTPK3Z7RLQXAVCNFSM6AAAAABRMIGKOGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINRTHA4DKNBZGA . You are receiving this because you are subscribed to this thread.Message ID: @.***>
There is no pattern, or activation method, or recommendation, for breaking Bitcoin rules to achieve a "hard fork" "upgrade" or any sort of deterministic migration; there is only an overzealous interest and complementary tolerance for the addition of new rules to Bitcoin as "soft forks."
Alternative compatible Bitcoin implementations are most relevant here, unless only specifically describing the activity of copying the bitcoin blockchain into a new incompatible network, on purpose, creating a new asset.
There should be no illusion that breaking Bitcoin rules, magic numbers, is a path for progress for Bitcoin.
The text handwaves away that alternatives are important but harps on why they are bad. Well, some of us think they are great and necessary.
Libbitcoin is proving to improve on Bitcoin Core in various ways, and evidence that more competition is needed.
Regarding fragility, why not portray the positive side of this? That it requires changes to have clearer consensus and to be more sensitive to proposing disruptive change.
Or, we can keep pretending that inventing new payment protocols every year is sustainable...