Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 3FDF7E0F for ; Sun, 20 Dec 2015 15:50:58 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-io0-f180.google.com (mail-io0-f180.google.com [209.85.223.180]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C6BB914D for ; Sun, 20 Dec 2015 15:50:57 +0000 (UTC) Received: by mail-io0-f180.google.com with SMTP id 186so135645812iow.0 for ; Sun, 20 Dec 2015 07:50:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:cc :content-type; bh=JzBgbTQQm1DLt+fEdiGtnKhXbm4Sqq+tKkHVZOWdpjs=; b=IesuahCdPaKYhZezBZNb1Z5UHBfNqT8mEbW/2MfTL8eosDwujlQQ3exesaG4dwJdDN Vn3eMqQFgayMLZJry26rEMW66BA4sPLeegePUl3LYUmrAL8n0YRtu1xupRwFEcSXTt2G MiEOrRuaJnqPJTLyfh/S6VqDaMm4FBS6+cxTU7NwIXilHfg5XKFJPDqeAyZJy91PPOdU 7dE1bPxx4PoBMqsoikZQqFKTspCw4MlF7u0IXU/Z1lFnqn8PlDQQNvBS1FE38f0yfD4b hpbf08MntNlJWUKLFYbAn8Ra6/uIfsKFAIiUmDewwZ/+brietixLmeg8v7KsUJTLOqtr 9mug== MIME-Version: 1.0 X-Received: by 10.107.131.207 with SMTP id n76mr14085152ioi.135.1450626657250; Sun, 20 Dec 2015 07:50:57 -0800 (PST) Received: by 10.79.77.75 with HTTP; Sun, 20 Dec 2015 07:50:57 -0800 (PST) In-Reply-To: <1bf64a5b514d57ca37744ae5f5238149@openmailbox.org> References: <1bf64a5b514d57ca37744ae5f5238149@openmailbox.org> Date: Sun, 20 Dec 2015 15:50:57 +0000 Message-ID: From: Tier Nolan Cc: Bitcoin Dev Content-Type: multipart/alternative; boundary=001a113ebda69b72ac052756560e X-Spam-Status: No, score=-1.7 required=5.0 tests=AC_DIV_BONANZA,BAYES_00, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE, MISSING_HEADERS,RCVD_IN_DNSWL_LOW autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: Re: [bitcoin-dev] Increasing the blocksize as a (generalized) softfork. X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Dec 2015 15:50:58 -0000 --001a113ebda69b72ac052756560e Content-Type: text/plain; charset=UTF-8 This is essentially the "nuclear option". You are destroying the current chain (converting it to a chain of coinbases) and using the same POW to start the new chain. You are also giving everyone credit in the new chain equal to their credit in the old chain. It would be better if the current chain wasn't destroyed. This could be achieved by adding the hash of an extended block into the coinbase but not requiring the coinbase to be the only transaction. The new block is the legacy block plus the associated extended block. Users would be allowed to move money to the extended block by spending it to a specific output template. OP_1 OP_TO_EXTENDED OP_TRUE OP_1 is the extended block index and initially, only one level is available. This would work like P2SH. Users could spend the money on the extended block chain exactly as they could on the main chain. Money can be brought back the same way. ... OP_0 OP_UNLOCK OP_TRUE The txids are for transactions that have been locked in root chain. The transaction is only valid if they are all fully funded. The fee for the transaction would be fee - (cost to fund unlocked txids). A negative fee tx would be invalid. This has the advantage that it keeps the main chain operating. People can still send money with their un-upgraded clients. There is also an incentive to move funds to the extended block(s). The new extended blocks are more complex, but potentially have lower fees. Nobody is forced to change. If the large blocks aren't needed, nobody will both to use them. The rule could be Now: 0) 1 MB After change over 0) 1 MB 1) 2 MB After 2 years 0) 1 MB 1) 2 MB 2) 4MB After 4 years 0) 1 MB 1) 2 MB 2) 4MB 3) 8MB --001a113ebda69b72ac052756560e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This is = essentially the "nuclear option".=C2=A0 You are destroying the cu= rrent chain (converting it to a chain of coinbases) and using the same POW = to start the new chain.=C2=A0 You are also giving everyone credit in the ne= w chain equal to their credit in the old chain.

It would be be= tter if the current chain wasn't destroyed.

This could be = achieved by adding the hash of an extended block into the coinbase but not = requiring the coinbase to be the only transaction.=C2=A0

The new bl= ock is the legacy block plus the associated extended block.

Us= ers would be allowed to move money to the extended block by spending it to = a specific output template.=C2=A0

<public key hash> OP_= 1 OP_TO_EXTENDED OP_TRUE

OP_1 is the extended block index= and initially, only one level is available.

This w= ould work like P2SH.=C2=A0 Users could spend the money on the extended bloc= k chain exactly as they could on the main chain.

Money can be = brought back the same way.=C2=A0=C2=A0

<public key hash>= ; <txid1> <txid2> ... <txid-n> <N> OP_0 OP_UNLOCK O= P_TRUE

The txids are for transactions that have been locked in= root chain.=C2=A0 The transaction is only valid if they are all fully fund= ed.=C2=A0 The fee for the transaction would be fee - (cost to fund unlocked= txids).=C2=A0 A negative fee tx would be invalid.

This h= as the advantage that it keeps the main chain operating.=C2=A0 People can s= till send money with their un-upgraded clients.=C2=A0 There is also an ince= ntive to move funds to the extended block(s).=C2=A0 The new extended blocks= are more complex, but potentially have lower fees.=C2=A0 Nobody is forced = to change.=C2=A0 If the large blocks aren't needed, nobody will both to= use them.

The rule could be

Now:
<= /div>
0) 1 MB

After change over
0) 1 MB=
1) 2 MB

After 2 years
0) 1 M= B
1) 2 MB
2) 4MB

After 4 year= s
0) 1 MB
1) 2 MB
2) 4MB
3) 8M= B


--001a113ebda69b72ac052756560e--