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