I think he's more talking about like extension-blocks, however they are actually soft-forkable even (and keep the 21m coins obviously)
See See https://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg07937.html and Tier Nolan tech detail https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg07927.html Discussion / claimed properties on https://www.reddit.com/r/Bitcoin/comments/39kqzs/how_about_a_softfork_optin_blocksize_increase/ Adam On 15 June 2015 at 19:53, Raystonn . <rayst...@hotmail.com> wrote: >> The solution is to hard-fork and merge-mine. This way, both can live, and >> mining power is not divided. > > No, this would essentially be blessing an increase to 42M bitcoins, half on > each chain. You could expect a severe market price correction if this were > to happen. > > From: Rebroad (sourceforge) > Sent: Monday, June 15, 2015 4:16 AM > Cc: Bitcoin Dev > Subject: Re: [Bitcoin-development] comments on BIP 100 > > My understanding of this debate is that there are some people who want to > keep Bitcoin at 1MB block limit, and there are some who want to increase it. > > I for one am curious to see how 1MB limited bitcoin evolves, and I believe > we can all have a chance to see this AND hard-fork bitcoin to remove the > block size restriction. > > To remove the 1MB limit required a hard fork. This is not disputed. It's > what we do with the original (1MB limit) bitcoin that concerns me (and > other's I am sure). > > What I would like to see is both being allowed to live. Harry Potter and > Voldermort! (Except neither are evil!) > > The solution is to hard-fork and merge-mine. This way, both can live, and > mining power is not divided. > > Dogecoin recently hardforked and this hardfork also involved switching to > merge-mining, so it's been done successfully. > > So, simply, bitcoin as it is doesn't need to actually fork, but instead, at > a certain block size, a forked bitcoin with the blocksize lmit removed will > start to be merge-mined alongside bitcoin. Miners can be ready for this. > Wallets can be ready for this - in fact, for most wallets and merchants they > will possibly want to default to the bigger blocksize fork since this caters > for more transactions per block. > > We still don't know how removing the block limit will pan out and what other > problems with scalability will arise in the future, so by preserving the > original bitcoin, we keep diversity, and people won't feel their investments > in bitcoin are being unnecessarily put at risk (as their investments will > stay in both the new and the old bitcoin). > > The bitcoin core developers can implement a patch like the one recently used > for dogecoin, to allow the chain to fork at a set point, where at which > point, bitcoins will be split into the new and the old. Branding will be an > important issue here I think, so that there is as little confusion as > possible. I think this is a small price to pay in return for not killing the > original bitcoin (even if it's true that Satoshi did intend to remove the > 1MB limit at some point). > > If I'm missing something obvious please let me know. > > On Mon, Jun 15, 2015 at 1:50 PM, Mike Hearn <m...@plan99.net> wrote: >>> >>> The fact that using a centralized service is easier isn't a good reason >>> IMHO. It disregards the long-term, and introduces systemic risk. >> >> >> Well sure, that's easy for you to say, but you have a salary :) Other >> developers may find the incremental benefits of decentralisation low vs >> adding additional features, for instance, and who is to say they are wrong? >> >>> >>> But in cases where using a decentralized approach doesn't *add* anything, >>> I cannot reasonably promote it, and that's why I was against getutxos in the >>> P2P protocol. >> >> >> It does add something though! It means, amongst other things, I can switch >> of all my servers, walk away for good, discard this Mike Hearn pseudonym I >> invented for Bitcoin and the app will still work :) Surely that is an >> important part of being decentralised? >> >> It also means that as the underlying protocol evolves over time, getutxos >> can evolve along side it. P2P protocol gets encrypted/authenticated? Great, >> one more additional bit of security. If one day miners commit to UTXO sets, >> great, one more additional bit of security. When we start including input >> values in the signature hash, great ... one more step up in security. >> >> Anyway, I didn't really want to reopen this debate. I just point out that >> third party services are quite happy to provide whatever developers need to >> build great apps, even if doing so fails to meet some kind of perfect >> cryptographic ideal. And that's why they're winning devs. >> >> Now back to your regularly scheduled block size debates ... >> >> >> ------------------------------------------------------------------------------ >> >> _______________________________________________ >> Bitcoin-development mailing list >> Bitcoin-development@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development >> > > > ________________________________ > ------------------------------------------------------------------------------ > > ________________________________ > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > > ------------------------------------------------------------------------------ > > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > ------------------------------------------------------------------------------ _______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
