Alex Morcos [ARCHIVE] on Nostr: 📅 Original date posted:2015-08-04 📝 Original message:On Tue, Aug 4, 2015 at ...

📅 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>;