> I concede the point. Perhaps a flag date based on previous observation of network upgrade rates with a conservative additional margin in addition to supermajority of mining power. It occurs to me that this would allow for a relatively small percentage of miners to stop the upgrade if the flag date turns out to be poorly chosen and a large number of non-mining nodes haven't upgraded yet. Would be a nice safety fallback. Aaron Voisine co-founder and CEO breadwallet.com On Wed, May 13, 2015 at 6:31 PM, Aaron Voisine wrote: > > by people and businesses deciding to not use on-chain settlement. > > I completely agree. Increasing fees will cause people voluntary economize > on blockspace by finding alternatives, i.e. not bitcoin. A fee however is a > known, upfront cost... unpredictable transaction failure in most cases will > be a far higher, unacceptable cost to the user than the actual fee. The > higher the costs of using the system, the lower the adoption as a > store-of-value. The lower the adoption as store-of-value, the lower the > price, and the lower the value of bitcoin to the world. > > > That only measures miner adoption, which is the least relevant. > > I concede the point. Perhaps a flag date based on previous observation of > network upgrade rates with a conservative additional margin in addition to > supermajority of mining power. > > > Aaron Voisine > co-founder and CEO > breadwallet.com > > On Wed, May 13, 2015 at 6:19 PM, Pieter Wuille > wrote: > >> On Wed, May 13, 2015 at 6:13 PM, Aaron Voisine wrote: >> >>> Conservative is a relative term. Dropping transactions in a way that is >>> unpredictable to the sender sounds incredibly drastic to me. I'm suggesting >>> increasing the blocksize, drastic as it is, is the more conservative choice. >>> >> >> Transactions are already being dropped, in a more indirect way: by people >> and businesses deciding to not use on-chain settlement. That is very sad, >> but it's completely inevitable that there is space for some use cases and >> not for others (at whatever block size). It's only a "things don't fit >> anymore" when you see on-chain transactions as the only means for doing >> payments, and that is already not the case. Increasing the block size >> allows for more utility on-chain, but it does not fundamentally add more >> use cases - only more growth space for people already invested in being >> able to do things on-chain while externalizing the costs to others. >> >> >>> I would recommend that the fork take effect when some specific large >>> supermajority of the pervious 1000 blocks indicate they have upgraded, as a >>> safer alternative to a simple flag date, but I'm sure I wouldn't have to >>> point out that option to people here. >>> >> >> That only measures miner adoption, which is the least relevant. The >> question is whether people using full nodes will upgrade. If they do, then >> miners are forced to upgrade too, or become irrelevant. If they don't, the >> upgrade is risky with or without miner adoption. >> >> -- >> Pieter >> >> >