Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Z4YuW-0007Qr-R9 for bitcoin-development@lists.sourceforge.net; Mon, 15 Jun 2015 18:15:04 +0000 X-ACL-Warn: Received: from mout.perfora.net ([74.208.4.196]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1Z4YuV-0007Ys-Gt for bitcoin-development@lists.sourceforge.net; Mon, 15 Jun 2015 18:15:04 +0000 Received: from mail-qk0-f173.google.com ([209.85.220.173]) by mrelay.perfora.net (mreueus002) with ESMTPSA (Nemesis) id 0M8gIX-1ZH7op3gwt-00wAGB for ; Mon, 15 Jun 2015 20:14:57 +0200 Received: by qkfe185 with SMTP id e185so17613620qkf.3 for ; Mon, 15 Jun 2015 11:14:56 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.55.40.214 with SMTP id o83mr18329132qko.106.1434392096361; Mon, 15 Jun 2015 11:14:56 -0700 (PDT) Received: by 10.96.20.164 with HTTP; Mon, 15 Jun 2015 11:14:56 -0700 (PDT) In-Reply-To: References: Date: Mon, 15 Jun 2015 20:14:56 +0200 Message-ID: From: Adam Back To: "Raystonn ." Content-Type: text/plain; charset=UTF-8 X-Provags-ID: V03:K0:29VfcbYyXYuSVQ5YeAPRf1qaA+788+YQ0v8vFD0m+lsKykg80cR r9zzJgy1Fi02O1rJyOYaT81+nKQqdZ0fV3xHpT/t7ipuLOE+6t9wFSF74Jdxig1S3jBdLaH NikDRU3cx6Rsk5SgmxblFZ/MeZWy3Cqz8IN/G4RybPlA4vCjdJwtQL7mWWF+IWTNbRz+PCV l9L+nsQoYO6OcX9B/B6DQ== X-UI-Out-Filterresults: notjunk:1; X-Spam-Score: 0.0 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [74.208.4.196 listed in list.dnswl.org] -0.0 SPF_HELO_PASS SPF: HELO matches SPF record 0.0 AWL AWL: Adjusted score from AWL reputation of From: address X-Headers-End: 1Z4YuV-0007Ys-Gt Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] comments on BIP 100 X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2015 18:15:04 -0000 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 . 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 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 >