From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 915C8EDF for ; Mon, 1 Feb 2016 16:55:05 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-lf0-f44.google.com (mail-lf0-f44.google.com [209.85.215.44]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D0AD610C for ; Mon, 1 Feb 2016 16:55:04 +0000 (UTC) Received: by mail-lf0-f44.google.com with SMTP id m1so25624244lfg.0 for ; Mon, 01 Feb 2016 08:55:04 -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:to :cc:content-type; bh=BGwpHQAEabSnlk+/oFOOIzbJO+3BwsDB0B1mmaLZkqw=; b=oqptTRdtUEf8e94gS3zOxYdDFqiDdACPmX3wCuUJQmj9efI7N+ApBGRrYWwRkyfEoy KlRFxR1GltJdKoGCQovjb/rNbAISi5sSxDquHFM+jtoI3Jw9YTOc/vIsjg+3XGnGK1nH U7hwLJFjnFxYDoyMXsp3KqsXLD/X9KkN7/5DZEI62BS+aegkLoPJUTlPUjC/6AmSOdl0 /7McH7NQT8TIO7sMvjF4GnHzvQUTw10zZP46P7gu+dXcT+qUxREKvA//1z7Xj2jmlSJt GUibx/mMnZ4s//OFfZVwA0xb06J4XR1YhERKNTat1qhShMT7mR2qv8zcy5d6G1V8+F78 Gv4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=BGwpHQAEabSnlk+/oFOOIzbJO+3BwsDB0B1mmaLZkqw=; b=U4hsN7v8lGT2s9PF7V2ooWUIHyHnoRmgMD/Qrl5pzaeBM/byYvqXjuXdd5cCCWXaJI O5NO/bczETQ35mFCaWaE8Aie8hM20A7lSmpDftnnu9krz51lD0XoC/Qzwc478HvEpHnq CO7jjqql7wt6O5hfPGSfHd+DzEcdnMdxo+vqsVdewxxmlld+JG18qx6f9dDvNBmTyL+u YYgElKdoIIenf8jc7vPgb6HR23s4PRPbv8bdL6vsyfThVJTbOOenEWjTpFxnRPcZGfeP 4mWh3QG5YgDG2flkyMO7UyskreRNaKL2eUje13iqCIy87AJs1hr4/Fi7kc6P2vTXDkAL gU4w== X-Gm-Message-State: AG10YOTGcS9O5wevikVDt7dFlZbKr81da74QD/e0CAEwPjW3jZfXCXBF7T7gRjQDsT3t7Ay1HsSlh7lznMTTdg== MIME-Version: 1.0 X-Received: by 10.25.40.139 with SMTP id o133mr7256872lfo.10.1454345703178; Mon, 01 Feb 2016 08:55:03 -0800 (PST) Received: by 10.115.4.134 with HTTP; Mon, 1 Feb 2016 08:55:03 -0800 (PST) In-Reply-To: <20160128185124.GA5140@savin.petertodd.org> References: <20160128185124.GA5140@savin.petertodd.org> Date: Mon, 1 Feb 2016 17:55:03 +0100 Message-ID: From: Pieter Wuille To: Peter Todd Content-Type: text/plain; charset=UTF-8 X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: Bitcoin Dev Subject: Re: [bitcoin-dev] Segwit Upgrade Procedures & Block Extension Data 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: Mon, 01 Feb 2016 16:55:05 -0000 On Thu, Jan 28, 2016 at 7:51 PM, Peter Todd via bitcoin-dev wrote: > A few notes on upgrade procedures associated with segregated witnesses: > While Pieter Wuille's segwit branch(1) doesn't yet implement a fix for > the above problem, the obvious thing to do is to add a new service bit > such as NODE_SEGWIT, and/or bump the protocol version, and for outgoing > peers only connect to peers with segwit support. Agree, I've merged the changes to switch to a service bit instead. We'll need further changes to prefer connecting to segwit nodes. > Segwit isn't going to be the last thing that adds new block data. For > example, my own prev-block-proof proposal(3) requires that blocks commit > to another tree, which itself is calculated using a nonce that must be > passed along with the block data. (U)TXO commitments are another > possible future example. > Unfortunately, this means that the next soft-fork upgrade to add > additional data will have the above relaying problem all over again! > Even a minimal upgrade adding a new commitment - like my > prev-block-proof proposal - needs to at least add another nonce for > future upgrades. In addition to having to upgrade full nodes, this also > requires systems like the relay network to upgrade, even though they may > not themselves otherwise need to care about the contents of blocks. Those are good arguments for making the witness data more extensible. > > A more subtle implication of this problem is how do you handle parallel > upgrades, as proposed by BIP9? Splitting the P2P network into > non-upgraded nodes, and a much smaller group of upgraded nodes, is bad > enough when done every once in a awhile. How does this look with more > frequent upgrades, not necessarily done by teams that are working > closely with each other? I don't expect that changes that add more data to be relayed with blocks will be frequent, though I certainly agree there may be some. > Proposal: Unvalidated Block Extension Data > ========================================== (snip) This will need a backward-incompatible change to the current segwit change anyway, so at the risk of more bikeshedding, let me propose going a bit further: * The coinbase scriptSig gets a second number push (similar to the current BIP34 height push), which pushes a number O. O is a byte offset inside the coinbase transaction (excluding its witness data) that points to a 32-byte hash H. This is more flexible and more compact than what we have now (a suggestion by jl2012). * H is the root of a Merkle tree, whose leaves are the hashes of the coinbase witness's stack items. * Item 0 of the coinbase witness stack must be 32 bytes, and must be equal to the witness tree root. * No further restrictions on the rest of the stack items; these can be used for future commitments. > A significant design consideration is that if arbitrary data can be > added, it is very likely that miners will make use of that ability for > non-Bitcoin purposes; we've already run into problems deploying segwit > itself because of pools using the coinbase space for advertising and > merge-mining. Avoiding this problem is easiest with a merkelized > key:value mapping, with the ability to use collision-resistant ID's as > keys (e.g. UUID). I agree with the concern, but I don't really understand how this idea solves it. -- Pieter