{"type":"rich","version":"1.0","author_name":"npub10z4xjfgftd3fm9dfu7dw6mkemgyhxgumcmhd7yd0ggjq7rsaw4wqa3xfzw","author_url":"https://nostr.ae/npub10z4xjfgftd3fm9dfu7dw6mkemgyhxgumcmhd7yd0ggjq7rsaw4wqa3xfzw","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-08-04\n📝 Original message:On Tue, Aug 4, 2015 at 9:12 AM, Gavin Andresen via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e On Tue, Aug 4, 2015 at 7:27 AM, Pieter Wuille via bitcoin-dev \u003c\n\u003e bitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\n\u003e\u003e I would say that things already demonstrately got terrible. The mining\n\u003e\u003e landscape is very centralized, with apparently a majority depending on\n\u003e\u003e agreements to trust each other's announced blocks without validation.\n\u003e\u003e\n\u003e And that is a problem... why?\n\u003e\n\u003e As far as I can tell, nobody besides miners running old and/or buggy\n\u003e software lost money due to outsourced mining validation (please correct me\n\u003e if I'm wrong-- I'm looking forward to Greg's post-mortem). The operators of\n\u003e bitcoin.org seem to have freaked out and pushed the panic button (with\n\u003e dire warnings of not trusting transactions until 20 confirmations), but\n\u003e theymos was well known for using an old, patched version of Core for\n\u003e blockexplorer.com so maybe that's not surprising.\n\u003e\n\u003e\nI'm also looking forward to Greg's post-mortem, because I had a completely\ndifferent takeaway from the BIP66 mini-forks.  My view is that despite the\nextremely cautious and conservative planning for the completely\nuncontentious fork, the damage could and would have been very significant\nif it had not been for several core devs manually monitoring, intervening\nand problem solving for other network participants.  I don't believe thats\nthe way the system should work.  Participants in the Bitcoin community have\ncome to rely on the devs for just making sure everything works for them.\nThat's not sustainable.  The system needs to be made fundamentally more\nsecure if its going to succeed, not depend on the good will of any\nparticular parties, otherwise it certainly will no longer be permissionless.\n\nThe BIP66 fork was urgently required to fix an undisclosed consensus bug,\nunanimously agreed on and without technical objection, and it was still\nfraught with problems.  That's the most clear cut example of when we should\nhave a fork.  A change to a consensus limit that a significant proportion\nof the community disagrees with for economic or technical reasons or both\nshould be raising a sea of red flags.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150804/b2ddba5d/attachment.html\u003e"}