On 04/15/2017 03:04 AM, Gregory Maxwell via bitcoin-dev wrote: > Considering that you did not spare a single word about the specific > property that I am concerned about-- that the proposal will reject > the blocks of passive participants, due to avoidable design > limitations-- I can't help but feel that you don't even care to > understand the concern I was bringing up. :(
Not sure if you missed my previous reply to you, but I'm curious about your thoughts on this particular point. I contend that for any UASF, orphaning non-signalling blocks on the flag date is safer than just considering the fork active on the flag date. Unless we have majority miner support for the fork, we have to assume that a chain split will occur at some point. With the orphaning approach, we know exactly when that will be, and can plan around it. Miners know that they need to upgrade by the flag date in order to get paid. We even have an opportunity to back out if it looks like we don't have enough economic support. With the non-orphaning approach, the split won't occur until someone chooses to craft a malicious block (short bitcoin; rent hash power; profit). We don't know when that will be, so we can't plan around it. Some nodes and miners will assume it won't happen at all. When it happens, our responses to it will be clumsy, uncoordinated, and likely panicked. While the orphaning approach is potentially disruptive to miners, it is necessarily so in order to minimize disruption to users. In general, users should be prioritized over miners. The point of Bitcoin is to have secure, digital money that we can *use*, not to enable people to earn money from running busy-work computations. > How many people barely reviewed the specifics of the proposal simply > because they want something fast and this proposal does something > fast? I have scrutinized the strategy of BIP148 a fair bit. I was initially opposed to it, but after Bitfury showed their support, and especially after the Asicboost revelation, I think it has solid potential to succeed. It would be a waste not to at least attempt to organize around it. If it turns out that we can't get the necessary support in time, we can abandon the effort and reassess our options. _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
