From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YyUCa-0004le-Mc for bitcoin-development@lists.sourceforge.net; Sat, 30 May 2015 00:00:36 +0000 X-ACL-Warn: Received: from mout.perfora.net ([74.208.4.194]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1YyUCY-0001Vo-S9 for bitcoin-development@lists.sourceforge.net; Sat, 30 May 2015 00:00:36 +0000 Received: from mail-qg0-f46.google.com ([209.85.192.46]) by mrelay.perfora.net (mreueus001) with ESMTPSA (Nemesis) id 0MCaCy-1YqCkA3kxu-009TRT for ; Sat, 30 May 2015 02:00:29 +0200 Received: by qgf2 with SMTP id 2so35324974qgf.3 for ; Fri, 29 May 2015 17:00:28 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.140.97.136 with SMTP id m8mr12618056qge.32.1432944028216; Fri, 29 May 2015 17:00:28 -0700 (PDT) Received: by 10.96.112.164 with HTTP; Fri, 29 May 2015 17:00:28 -0700 (PDT) Date: Sat, 30 May 2015 01:00:28 +0100 Message-ID: From: Adam Back To: "Raystonn ." Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K0:UjuBxgeXZzpJI3RJApDmlryEjdh4I2agb/CkPueZyZ25nzaPjER FEmDuzWS4sIwvnNKtw+wBpSOfVQ8wRHlPZs8YuXrh8h2pbs+qO0a8XbmygPB2ZE23K/a+k1 3sZh1Dm3pOB8iWyxmh6/EmqWX3hvMNwZaxJsQXnMP8Lb5DbIFkJeb0LL2a10/uHk6O4OGB5 aYpFdS27FPZls57pP64CQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:GHz1nSiGexM=:VxUlJ3q2//+1nfQgJPBBZC sJ+WvNYXwg8s6i4ECTY53Ao7GRWhPczra0GkcebOioeBgePtmvDarbsc3/E8RRRib2JnuXHq/ TRKsQQ2QAHFz29Hjmcg7yi+IGVHJkLX15zQ8kR+mxtCEu26mtsZMuvulY7IajTTsaN8ZfUdsB 1/MMrdG7U+Mu3o/x3ca/hr+eRMr4yZZrlDLQDAS2Y5Hk7exY3633xZ1UXux1NO2TqsZhiJz0y nucgRh7i0cxk+POifQ34dFSRfAArnIc09pv6y5W7bSPL8rLCeO+Vi2blTKLFHe+Ea6gRaa9bO FOrN3BVroydOeqFi6JOeWN02clXpS06Pqz4RoVg0r/WMxHa2HaNZaRDlZGtJaYaOF5PO+yZtp IOYJW5vPmuyBTt/kBWY4OOk7/K/gzBGX0hOtfpkPCnMGOI0Kah8QlAPCmOFU4gd1rdFnuGcDk 1D2DeT031XBcOVBAVgIfcswni4VS6mqlwRLXpqly3oM32TF3GPANhuMZsOaR+FonIeP3R5vBW g+GbvBTnCdMJm923S8QSkfVLPE5gddFA3VuHfjlo/am1X78L4+jxojxyR7lhv8ut23M2CljFJ yu2IvqG7VCi/tZcOJerupG6OtlZdnbMi+QPQK9ygPW2fZF7yDHfZcuYImPdZtJX2s3efUK2h8 7Cfx8pWI6p9ee2TZ4bXwX2BrEK4SYAEe1WFar7H45SxEKtg== 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.194 listed in list.dnswl.org] -0.0 SPF_HELO_PASS SPF: HELO matches SPF record X-Headers-End: 1YyUCY-0001Vo-S9 Cc: Bitcoin Dev Subject: [Bitcoin-development] soft-fork block size increase (extension blocks) Re: Proposed alternatives to the 20MB stepfunction 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: Sat, 30 May 2015 00:00:36 -0000 I discussed the extension block idea on wizards a while back and it is a way to soft-fork an opt-in block-size increase. Like everything here there are pros and cons. The security is better than Raylstonn inferred from Tier's explanation I think.. It works as Tier described - there is an extension block (say 10MB) and the existing 1MB block. The extension block is committed to in the 1MB chain. Users can transfer bitcoin into the extension block, and they can transfer them out. The interesting thing is this makes block sizes changes opt-in and gives users choice. Choice is good. Bitcoin has a one-size-fits-all blocksize at present hence the block size debate. If a bigger block-size were an opt-in choice, and some people wanted 10MB or even 100MB blocks for low value transactions I expect it would be far easier a discussion - people who think 100MB blocks are dangerously centralising, would not opt to use them (or would put only small values they can afford to lose in them). There are some security implications though, so this also is nuanced, and more on that in a bit. Fee pressure still exists for blocks of difference size as the security assurances are not the same. It is plausible that some people would pay more for transactions in the 1MB block. Now there are three choices of validation level, rather than the normal 2-levels of SPV or full-node, with extension blocks we get a choice: A) a user could run a full node for both 1MB and 10MB blocks, and get full security for both 1MB and 10MB block transactions (but at higher bandwidth cost), or B) a user could run a full node on the 1MB block, but operate as an SPV node for the 10MB block, or C) run in SPV mode for both 1MB and 10MB blocks. Similarly for mining - miners could validate 1MB and 10MB transactions (solo mine or GBT-style), or they could self-validate 1MB transactions and pool mine 10MB transactions (have a pool validate those). 1MB full node users who do not upgrade to software that understands extension blocks, could run in SPV mode with respect to 10MB blocks. Here lies the risk - this imposes a security downgrade on the 1MB non-upgraded users, and also on users who upgrade but dont have the bandwidth to validate 10MB blocks. We could defend non-upgrade users by making receiving funds that came via the extension block opt-in also, eg an optional to use new address version and construct the extension block so that payments out of it can only go to new version addresses. We could harden 1MB block SPV security (when receiving weaker extension block transactions) in a number of ways: UTXO commitments, fraud proofs (and fraud bounties) for moving from the extension block to the 1MB block. We could optionally require coins moving via the extension block to the 1MB block to be matured (eg 100 blocks delay) Anyway something else to evaluate. Not as simple to code as a hard-fork, but way safer transition than a hard-fork, and opt-in - if you prefer the higher decentralisation of 1MB blocks, keep using them; if you prefer 10MB blocks you can opt-in to them. Adam On 29 May 2015 at 17:39, Raystonn . wrote: > Regarding Tier=E2=80=99s proposal: The lower security you mention for ext= ended > blocks would delay, possibly forever, the larger blocks maximum block siz= e > that we want for the entire network. That doesn=E2=80=99t sound like an = optimal > solution. > > Regarding consensus for larger maximum block size, what we are seeing on > this list is typical of what we see in the U.S. Congress. Support for > changes by the stakeholders (support for bills by the citizens as a whole= ) > has become irrelevant to the probability of these changes being adopted. > Lobbyists have all the sway in getting their policies enacted. In our ca= se, > I would bet on some lobbying of core developers by wealthy miners. > > Someone recently proposed that secret ballots could help eliminate the po= wer > of lobbyists in Congress. Nobody invests in that which cannot be confirm= ed. > Secret ballots mean the vote you are buying cannot be confirmed. Perhaps > this will work for Bitcoin Core as well. > > > From: Tier Nolan > Sent: Friday, May 29, 2015 7:22 AM > Cc: Bitcoin Dev > Subject: Re: [Bitcoin-development] Proposed alternatives to the 20MB > stepfunction > > On Fri, May 29, 2015 at 3:09 PM, Tier Nolan wrote: >> >> >> >> On Fri, May 29, 2015 at 1:39 PM, Gavin Andresen >> wrote: >>> >>> But if there is still no consensus among developers but the "bigger >>> blocks now" movement is successful, I'll ask for help getting big miner= s to >>> do the same, and use the soft-fork block version voting mechanism to >>> (hopefully) get a majority and then a super-majority willing to produce >>> bigger blocks. The purpose of that process is to prove to any doubters = that >>> they'd better start supporting bigger blocks or they'll be left behind,= and >>> to give them a chance to upgrade before that happens. >> >> >> How do you define that the movement is successful? > > > Sorry again, I keep auto-sending from gmail when trying to delete. > > In theory, using the "nuclear option", the block size can be increased vi= a > soft fork. > > Version 4 blocks would contain the hash of the a valid extended block in = the > coinbase. > > <32 byte extended hash> > > To send coins to the auxiliary block, you send them to some template. > > OP_P2SH_EXTENDED OP_TRUE > > This transaction can be spent by anyone (under the current rules). The s= oft > fork would lock the transaction output unless it transferred money from t= he > extended block. > > To unlock the transaction output, you need to include the txid of > transaction(s) in the extended block and signature(s) in the scriptSig. > > The transaction output can be spent in the extended block using P2SH agai= nst > the scriptPubKey hash. > > This means that people can choose to move their money to the extended blo= ck. > It might have lower security than leaving it in the root chain. > > The extended chain could use the updated script language too. > > This is obviously more complex than just increasing the size though, but = it > could be a fallback option if no consensus is reached. It has the advant= age > of giving people a choice. They can move their money to the extended cha= in > or not, as they wish.