{"type":"rich","version":"1.0","author_name":"npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2","author_url":"https://nostr.ae/npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-02-14\n📝 Original message:I haven't bothered reading the thread, but I'll put this out there:\n\nThe consensus critical Satoshi-derived sourcecode is a protocol\n*specification* that happens to also be machine readable and executable.\nRewriting it is just as silly as as taking RFC 791 and rewriting it\nbecause you wanted to \"decentralize control over the internet\"\n\nMy replace-by-fee fork of Bitcoin Core is a perfect case in point: it\nimplements different non-consensus-critical policy than Bitcoin Core\ndoes, while adhering to the same Bitcoin protocol by virtue of being the\nsame sourcecode - the same protocol specification. When I went to miners\nasking them to implement it, the biggest concern for them is \"Will it\nstay in consensus with other miners?\" If I had rewritten the whole thing\nfrom scratch the fact is the honest answer to them would be no way in\nhell - reimplementing Bitcoin and getting it right is software\nengineering's Apollo Project and none of us have the resources to pull\nthat off. But I didn't, which means we might soon have a significant\nchunk of hashing power implementing a completely different mining policy\nthan what is promoted by the Bitcoin Core maintainers.\n\nBy reimplementing consensus code - rewriting the protocol spec - you\ndrop out of the political process that is Bitcoin development. You're\nnot decentralizing Bitcoin at all - you're contributing to its\ncentralization by not participating, leaving behind a smaller and more\ncentralized development process. Fact is, what you've implemented in\nlibbitcoin just isn't the Bitcoin protocol and isn't going to get\nadopted by miners nor used by serious merchants and exchanges - the\nsources of real political power.\n\n\nRight now we could live in a world where a dozen different groups\nmaintain Bitcoin implementations that are actually used by miners. We\ncould have genuine innovation on the p2p networking layer, encryption,\nbetter privacy for SPV clients, better resistance to DoS attacks. We\ncould have diverse tx acceptance policies rather than wasting hundreds\nof man hours bitching about how many bytes OP_RETURN should allow. We\ncould have voices from multiple groups at the table when the community\ndiscusses how to scale Bitcoin up.\n\nInstead we have a world with a half dozen teams wasting hundreds if not\nthousands of of man hours dicking around trying to rewrite consensus\ncritical *specifications* because they happen to be perfectly good\nexecutable code, and the first thing a programmer thinks when they see\nperfectly good battle-hardened code is \"Hey! Let's rewrite that from\nscratch!\"\n\n\nYou know you does have significant political power over the development\nof the Bitcoin protocol *other* than the Bitcoin Foundation?\n\nLuke Dashjr.\n\nBecause he maintains the Eligius fork of Bitcoin Core that something\nlike %30 of the hashing power run. It Actually Works because it uses the\nActual Protocol Specification, and miners know if they run it they\naren't going to lose tens of thousands of dollars. It's why it's easy to\nget transactiosn mined that don't meet the Bitcoin Core's IsStandard()\nrules: they aren't part of the protocol spec, and Luke-Jr has different\nviews on what transactions should and should not be allowed into the\nblockchain.\n\nAnd when Gavin Andresen starts negotiating with alt-implementations to\nget his bloat coin proposals implemented, you know who's going to be at\nthe table? Luke-Jr again! Oh sure, the likes of btcd, libbitcoin, toshi,\netc. will get invited, but no-one's going to really care what they say.\nBecause at best only a tiny - and foolish - sliver of hashing power will\nbe using their implementations of Something Almost But Not Quite\nBitcoin™, and any sane merchant or exchange will be running at least one\nor two Bitcoin Foundation Genuine Bitcoin Core™ nodes in front of any\nfrom-scratch alt-implementation.\n\n\nSo stop wasting your time. Help get the consensus critical code out of\nBitcoin Core and into a stand-alone libconsensus library, wrap it in the\nmempool policy, p2p networking code, and whatever else you feel like,\nand convince some hashing power to adopt it. Then enjoy the fruits of\nyour efforts when the next time we decide to soft-fork Bitcoin the\nprocess isn't some secretive IRC discussion by a half-dozen \"core\ndevelopers\" - and one guy who finds the term hilarious - but a full on\nDIRECT DEMOCRACY OCCUPY WALL STREEET MODIFIED CONSENSUS POW-WOW,\ncomplete with twinkle fingers. A pow-wow that you'll be an equal part\nof, and your opinions will matter.\n\nOr you can be stereotypical programmers and dick around on github for\nthe next ten years chasing stupid consensus bugs in code no-one uses.\n\nThe choice is yours.\n\n\nOn Sat, Feb 14, 2015 at 03:16:16AM -0800, Eric Voskuil wrote:\n\u003e On 02/14/2015 01:51 AM, Jorge Timón wrote:\n\u003e \u003e I agree that this conversation is not being productive anymore. I'm\n\u003e \u003e doing my best to understand you but I just happen to disagree with\n\u003e \u003e many of your arguments.\n\u003e \u003e I doubt it makes you feel better but it's being tedious and\n\u003e \u003e frustrating for me as well.\n\u003e \u003e I don't know about other people's intentions, but I know that my only\n\u003e \u003e intention when recommending libbitcoin to depend on libconsensus is to\n\u003e \u003e prevent its direct and indirect users from accidentally being forked\n\u003e \u003e off the network due to a consensus failure.\n\u003e \n\u003e If you want to achieve that goal, I would again recommend that a\n\u003e standard suite of test vectors be published that other implementations\n\u003e can easily consume. Everyone runs the tests and compares results - just\n\u003e like deterministic build verification.\n\n-- \n'peter'[:-1]@petertodd.org\n00000000000000000e95dcd2476d820f6fd26eb1a9411e961347260342458e9c\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 650 bytes\nDesc: Digital signature\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150214/92986503/attachment.sig\u003e"}