rich1.0npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2https://nostr.ae/npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2njumphttps://nostr.ae📅 Original date posted:2015-02-14 📝 Original message:I haven't bothered reading the thread, but I'll put this out there: The consensus critical Satoshi-derived sourcecode is a protocol *specification* that happens to also be machine readable and executable. Rewriting it is just as silly as as taking RFC 791 and rewriting it because you wanted to "decentralize control over the internet" My replace-by-fee fork of Bitcoin Core is a perfect case in point: it implements different non-consensus-critical policy than Bitcoin Core does, while adhering to the same Bitcoin protocol by virtue of being the same sourcecode - the same protocol specification. When I went to miners asking them to implement it, the biggest concern for them is "Will it stay in consensus with other miners?" If I had rewritten the whole thing from scratch the fact is the honest answer to them would be no way in hell - reimplementing Bitcoin and getting it right is software engineering's Apollo Project and none of us have the resources to pull that off. But I didn't, which means we might soon have a significant chunk of hashing power implementing a completely different mining policy than what is promoted by the Bitcoin Core maintainers. By reimplementing consensus code - rewriting the protocol spec - you drop out of the political process that is Bitcoin development. You're not decentralizing Bitcoin at all - you're contributing to its centralization by not participating, leaving behind a smaller and more centralized development process. Fact is, what you've implemented in libbitcoin just isn't the Bitcoin protocol and isn't going to get adopted by miners nor used by serious merchants and exchanges - the sources of real political power. Right now we could live in a world where a dozen different groups maintain Bitcoin implementations that are actually used by miners. We could have genuine innovation on the p2p networking layer, encryption, better privacy for SPV clients, better resistance to DoS attacks. We could have diverse tx acceptance policies rather than wasting hundreds of man hours bitching about how many bytes OP_RETURN should allow. We could have voices from multiple groups at the table when the community discusses how to scale Bitcoin up. Instead we have a world with a half dozen teams wasting hundreds if not thousands of of man hours dicking around trying to rewrite consensus critical *specifications* because they happen to be perfectly good executable code, and the first thing a programmer thinks when they see perfectly good battle-hardened code is "Hey! Let's rewrite that from scratch!" You know you does have significant political power over the development of the Bitcoin protocol *other* than the Bitcoin Foundation? Luke Dashjr. Because he maintains the Eligius fork of Bitcoin Core that something like %30 of the hashing power run. It Actually Works because it uses the Actual Protocol Specification, and miners know if they run it they aren't going to lose tens of thousands of dollars. It's why it's easy to get transactiosn mined that don't meet the Bitcoin Core's IsStandard() rules: they aren't part of the protocol spec, and Luke-Jr has different views on what transactions should and should not be allowed into the blockchain. And when Gavin Andresen starts negotiating with alt-implementations to get his bloat coin proposals implemented, you know who's going to be at the table? Luke-Jr again! Oh sure, the likes of btcd, libbitcoin, toshi, etc. will get invited, but no-one's going to really care what they say. Because at best only a tiny - and foolish - sliver of hashing power will be using their implementations of Something Almost But Not Quite Bitcoin™, and any sane merchant or exchange will be running at least one or two Bitcoin Foundation Genuine Bitcoin Core™ nodes in front of any from-scratch alt-implementation. So stop wasting your time. Help get the consensus critical code out of Bitcoin Core and into a stand-alone libconsensus library, wrap it in the mempool policy, p2p networking code, and whatever else you feel like, and convince some hashing power to adopt it. Then enjoy the fruits of your efforts when the next time we decide to soft-fork Bitcoin the process isn't some secretive IRC discussion by a half-dozen "core developers" - and one guy who finds the term hilarious - but a full on DIRECT DEMOCRACY OCCUPY WALL STREEET MODIFIED CONSENSUS POW-WOW, complete with twinkle fingers. A pow-wow that you'll be an equal part of, and your opinions will matter. Or you can be stereotypical programmers and dick around on github for the next ten years chasing stupid consensus bugs in code no-one uses. The choice is yours. On Sat, Feb 14, 2015 at 03:16:16AM -0800, Eric Voskuil wrote: > On 02/14/2015 01:51 AM, Jorge Timón wrote: > > I agree that this conversation is not being productive anymore. I'm > > doing my best to understand you but I just happen to disagree with > > many of your arguments. > > I doubt it makes you feel better but it's being tedious and > > frustrating for me as well. > > I don't know about other people's intentions, but I know that my only > > intention when recommending libbitcoin to depend on libconsensus is to > > prevent its direct and indirect users from accidentally being forked > > off the network due to a consensus failure. > > If you want to achieve that goal, I would again recommend that a > standard suite of test vectors be published that other implementations > can easily consume. Everyone runs the tests and compares results - just > like deterministic build verification. -- 'peter'[:-1]@petertodd.org 00000000000000000e95dcd2476d820f6fd26eb1a9411e961347260342458e9c -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 650 bytes Desc: Digital signature URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150214/92986503/attachment.sig>