Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id EE1C7B2A for ; Thu, 26 Jan 2017 09:39:56 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from sender163-mail.zoho.com (sender163-mail.zoho.com [74.201.84.163]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 5251D12D for ; Thu, 26 Jan 2017 09:39:56 +0000 (UTC) Received: from [10.7.56.158] (ip-123-255-103-183.wlan.cuhk.edu.hk [123.255.103.183]) by mx.zohomail.com with SMTPS id 1485423589315837.0731533661734; Thu, 26 Jan 2017 01:39:49 -0800 (PST) From: Johnson Lau Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Message-Id: <5B69C153-4623-4664-9C4B-4E0396FF021A@xbt.hk> Date: Thu, 26 Jan 2017 17:39:43 +0800 To: bitcoin-dev X-Mailer: Apple Mail (2.3259) X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: [bitcoin-dev] Extension block softfork proposal X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2017 09:39:57 -0000 This is a pre-BIP which allows extra block space through a soft-fork. It = is completely transparent to existing wallets (both send and receive), = but new wallets taking advantage of the extra block space will have a = very different user experience. I=E2=80=99m sure this is controversial but I think it=E2=80=99s an = interesting academic topic. If we=E2=80=99d ever have any fully = consensus enforced 2-way-peg side chain design, that=E2=80=99d be = something like this. Objectives: 1. Provide more block space through a soft forks 2. Completely transparent to existing wallets 3. Not breaking any current security assumptions Specification and Terminology: Main block / block: the current bitcoin block (with witness if BIP141 is = activated) Main transaction / tx: txs in the current bitcoin network (with witness) Main UTXO / UTXO: the normal UTXO Extension transaction / xtx: transactions with a format same as the = witness tx format described in BIP141, without scriptSig field, and the = =E2=80=9Cflag=E2=80=9D as 0x02. Only witness program are allowed for = scriptPubKey of xtx Extension block / xblock: xblock is a collection of xtx. Each block may = have 0 or 1 xblock when this softfork is activated. Extension UTXO / xUTXO: the UTXO set for of the extension block. Bridging witness program: A new type of witness program is defined. The = witness script version is OP_2. The program length could be 4 to 40. The = first byte ("direction flag=E2=80=9D[note 1]) must be 0x00 (indicating = block->xblock) or 0x01 (indicating xblock->block). Like P2WPKH and = P2WSH, the bridging program could be wrapped by P2SH. There are 2 ways = to spend this program type on the main block: 1) Spend it like a usual witness program with a tx. For example, if = the bridging program is OP_2 <0x000014{20 bytes}>, it could be spent = like a version-0 20bytes programme, i.e. P2WPKH. Nothing special would = happen in this case 2) Spend it like a usual witness program with a special xtx, the = genesis xtx. In this case, the miner including this xtx will need to do = more as described below. Integrating UTXO: a special UTXO with a value >=3D the total value of = all existing xUTXO and scriptPubKey is OP_1. (to make the spec easier to = read, here we assume that now we have a zero value UTXO with its = outpoint hardcoded as the initial integrating UTXO. In practice we may = have the first miner making xblock to create the initial integrating = UTXO) Integrating transaction: if a block has an xblock, the second = transaction in the block must be the integrating transaction. The inputs = include the spent UTXO of all the genesis xtx in this xblock. If it is a = bare witness program, the witness must be empty. If it is a P2SH witness = program, the scriptSig must be the bridging witness program and the = witness must be empty. The last input must be the original integrating = UTXO, with empty witness and scriptSig. If no one is trying to send = money back from the xblock to the main block, the only output is the = updated integrating UTXO, which the value must be >=3D the total value = of all xUTXO =E2=80=94=E2=80=94=E2=80=94=E2=80=94 Up to now, I have described how we could send bitcoins from the main = UTXO to the xUTXO. Simply speaking, people send money to a new form of = witness programme. They have the flexibility to spend it in the main = block or xblock. Nothing special would happen if they send to the main = block. If they send to the xblock, the value of such UTXO will be = collected by the integrating UTXO. After people sent money to xblock, they could trade inside the xblock = just like in the main block. Since xblock is invisible to the = pre-softfork users, we could have whatever size limit for the xblock, = which is not a topic of this proposal. The tricky part is sending from xblock to main block. Returning transaction: returning transaction is a special xtx, sending = money to a bridging witness program, with a direction flag of 0x01. = These bridging witness program won=E2=80=99t be recorded in the xUTXO = set. Instead, an output is added to the integrating tx, with the = bridging witness program and corresponding value, called the = =E2=80=9Creturning UTXO=E2=80=9D. The returning UTXOs are not spendable = until confirmed by 100 blocks. The updated integrating UTXO is the last = output, and is not restricted by the 100-block requirement Fees collection in xblock: Same as normal tx, people pay fee in xblock = by making output value < input value. Since the value of the integrating = UTXO is >=3D the total value of all existing xUTXO, if fees are paid in = the xblock, that will reduce the value of the integrating UTXO, and = miners are paid through the usual coinbase tx as fee. xblock commitment: 2 xblock merkle root, with and without witness, are = placed exactly after the witness commitment in the coinbase tx.(maybe we = could use the coinbase reserved witness value, details TBD). If there is = no xblock commitment, xblock must be empty and integrating tx is not = allowed. =E2=80=94=E2=80=94=E2=80=94=E2=80=94 Same as any 2-way-peg proposal, sending money from the side chain to the = main chain is always the most tricky part. Different from other side = chain proposals like Rootstock, extension block is fully consensus = enforced, and has the same security level as existing bitcoin = transactions. To ensure this, an 100-block maturity is needed for the = returning UTXO, as the TXID of the integrating transaction is *very* = likely to change after a reorg, which will break the transaction chains = coming from it. The 100-block maturity requirement bring us back to the = usual assumption that txs become permanent after 100 confirmations. Please note that this drastically changes the user experience, as no = current users (expect miners) would expect such 100-block freezing. = That=E2=80=99s why I don=E2=80=99t allow the returning UTXO to have an = arbitrary scriptPubKey, as users of current wallet would never expect = such freezing. Using a special output scriptPubKey guarantees that the = recipient must understand the implications. Users of the new wallet = should be warned that despite they may enjoy lower fees in the xblock, = it may be difficult for them to send money to legacy wallets. This is a = huge limitation. Maybe we could have some decentralised market (using simple = hash-time-locked txs) allowing people to exchange value between block = and xblock, bypassing the 100 block requirement. This is actually = cheaper, because a full returning is a 2-step process, while p2p = exchange is only 1-step. =E2=80=94=E2=80=94=E2=80=94=E2=80=94 Questions: 1. Is it possible to simplify the design, without compromising security? 2. Is it acceptable to do it without the 100-block maturity requirement, = thus breaking some long-held assumptions? (This would vastly improve the = usability, until a reorg happens) 3. Even with maturity requirement, is 100-block an overkill? We never = had a fork over maybe 20 blocks. Also, breaking of transaction chain due = to reorg is already possible, as people may double spend during a reorg. [note 1] the direction flag is needed to make sure a recipient won=E2=80=99= t be paid with a returning transaction, unless explicitly requested. It = might be combined with the serialised witness version to save one byte.=