Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id C015B899 for ; Mon, 27 Mar 2017 19:22:46 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-vk0-f66.google.com (mail-vk0-f66.google.com [209.85.213.66]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 9F4A1229 for ; Mon, 27 Mar 2017 19:22:45 +0000 (UTC) Received: by mail-vk0-f66.google.com with SMTP id z204so9686500vkd.2 for ; Mon, 27 Mar 2017 12:22:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=nUcLiKIr4Mzbcp1cozviTP+I2zn2Z5/qytnqjykr74U=; b=aoINjTedc/u8dj3MYDJR4xpqpydeFZZ6K1pJaaFb80IWmwYk8sCWorlZMe/MeJ5JZd vJ5kVRVYZnoJ4HStXUeDjpVL1Xklpc0lgRwTH15tXRT3Bj4yFEIrG4dMbS984r/olIQu PDWZqJg5fbnEyFCk5TyPn1R642wj15kMuvaV0Iz6NoCfCWsAuXUCQst9PstC7opGZY3x u8lE4DHCbYG6h+ZESGMY7OXyOp7eAnAyUXXsQyw2gitTvkMFzJKzOZDqp2vfzP5xYyBx r4wGbY8Bp5GyQgwzCw3YWb7iS5etCDjK2ky2ELpo5LLw4FouceE1x0eT6roYiaC10+mB l52g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=nUcLiKIr4Mzbcp1cozviTP+I2zn2Z5/qytnqjykr74U=; b=KqE+oZGn3sIZg7JSKqMOX+mzl4fmlQux2N1/7AotByOnWaw6xntF6XA4xXBabvNEXz myajTd/nQxNTdjtZerZyh9M4eYL1FI+9cnNfL8aLfwTWsqNhLx2i4OoBOwXBSoBePRew Q2WN6scP9ges6dO9d5LBp4/5+GV9CV/D8OJp2I4BrCZkZSSXEmw3GCgJz/MUGyGdCmJ2 JJUwdtq2qvmvTCJDOk90Oy2vt9Mkm6yD5HvZvIY5Tkg9a+g5ZIvsTM7W8ozSfyTjCVLF AYMohPPW2hj1ar3lIyY274mbH3oUiQm5GHYrV2+/eCyZExtm2W0IZ+gkNNo07pLuDxdy Q5vQ== X-Gm-Message-State: AFeK/H0cYFYK1R+OWHQLaPRdIHdocU4pLx8as7bYXFcWaADqelJSO5vaoYoIGwroDex01K/Gi1XHXVaNN5kfSw== X-Received: by 10.176.85.199 with SMTP id w7mr12249734uaa.83.1490642564361; Mon, 27 Mar 2017 12:22:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.45.147 with HTTP; Mon, 27 Mar 2017 12:22:43 -0700 (PDT) From: Suhas Daftuar Date: Mon, 27 Mar 2017 15:22:43 -0400 Message-ID: To: Bitcoin Dev Content-Type: multipart/alternative; boundary=f403045e34348933ba054bbb443d X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE, RCVD_IN_SORBS_SPAM autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: [bitcoin-dev] Segregated witness p2p layer compatibility 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: Mon, 27 Mar 2017 19:22:46 -0000 --f403045e34348933ba054bbb443d Content-Type: text/plain; charset=UTF-8 Hi, There have been two threads recently that have made references to peer-to-peer implementation details in Bitcoin Core's Segregated Witness code that I would like to clarify. In the thread "Issolated Bitcoin Nodes" ( https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-March/013765.html), there was some discussion about how Bitcoin Core's block download logic behaves after segwit activation. After segwit activation, Bitcoin Core nodes will not (currently) attempt to download any blocks from non-segwit peers (nodes that do not set the NODE WITNESS service bit). This is a bandwidth optimization to prevent a node from downloading a block that may be invalid only because the sender omitted the witness, requiring re-download until the block is received with the required witness data. But to be clear, non-segwit blocks -- that is, blocks without a witness commitment in the coinbase, and whose transactions are serialized without witnesses, and whose transactions are not spending segwit outputs which require a witness -- are evaluated under the same rules as prior, pre-segwit versions of the software. So such non-segwit blocks that are valid to older, pre-segwit nodes are also valid to segwit-nodes. In https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-March/013796.html, Eric Voskuil wrote: Given the protocol requirements of the segwit proposal this is not the > case. A miner running pre-segwit code will produce blocks that no > segwit node will ever receive. The phrase "protocol requirements of segwit" is confusing here, because there are two different layers that need consideration: the consensus protocol layer and the peer-to-peer protocol layer. But in neither layer is the behavior of not downloading blocks from non-NODE WITNESS peers a "requirement". This is an implementation detail in the Bitcoin Core code that alternate implementations compliant with BIP 144 could implement differently. At the consensus layer, non-segwit blocks (described above) that are valid to older nodes are also valid to segwit nodes. That means that if a miner was using an older, pre-segwit version of Bitcoin Core to produce blocks after segwit activates, that blocks they find will be valid to all nodes. At the p2p layer, though, segwit-enabled Bitcoin Core nodes will only try to download those blocks if announced by a segwit-enabled peer. But this is not a protocol requirement; other implementations can remain compatible even they take different approaches here. (As an example, I could imagine an implementation that downloaded a new block from any peer, but if the block has a witness commitment in the coinbase and was received from a non-segwit peer, then the node would attempt re-download from a segwit peer. I'm sure many other reasonable block download strategies could be devised.) Still, if a miner wants to continue mining post-segwit activation, but using pre-segwit software, they would need a way to relay their blocks to a segwit-enabled peer. There are a few ways to do this that I can think of: - Use the RPC call "submitblock" on a segwit-enabled node. Calling "submitblock" on a Bitcoin Core 0.13.1 (0.13.0 in the case of testnet) or later node works fine as long as the block is valid (whether or not it has a witness commitment or witness transactions), and once a segwit-enabled peer has the block it will relay to other segwit peers. - Explicitly deliver the block to a segwit node over the p2p network, even if unrequested. Currently Bitcoin Core at least will process unrequested blocks, and valid blocks that update the tip will then be relayed to other peers. - Run a bridge node, which advertises NODE_WITNESS and can serialize blocks with witness data, which downloads blocks even from non-NODE WITNESS peers. Anyone can do this to bridge the networks for the benefit of the whole network (I have personally been running a few nodes that do this, for several months now), but miners concerned about this issue for their own blocks could explicitly do this themselves to ensure that their own blocks propagate to the segwit-enabled network. - Peer directly with other miners, bypassing the p2p network. Many miners do this already, using protocols which may already serve to bridge the network. So saying that "A miner running pre-segwit code will produce blocks that no segwit node will ever receive" is not really correct, in my view. If the whole network were just running Bitcoin Core software releases, and the miner was not able/willing to deliver their block to a segwit-enabled node (eg by using the RPC call "submitblock", or one of the other suggestions I had above), then I would agree with the statement. But given that there are bridge nodes on the network, and that miners have other options to relay their block, I think this is not an accurate portrayal of what would actually happen on the network -- I would expect that non-segwit miners' blocks would still get relayed post-segwit activation, even if only by the handful of bridge nodes that I expect are currently running. All that said, I do think this is an important detail to highlight and that this behavior should be better documented (I believe it deserves specific mention in a BIP), as this is an important issue for miners to be aware of. --f403045e34348933ba054bbb443d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

There have been two threads recentl= y that have made references to peer-to-peer implementation details in Bitco= in Core's Segregated Witness code that I would like to clarify.

In the thread "Issolated Bitcoin Nodes" (https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-Marc= h/013765.html), there was some discussion about how Bitcoin Core's = block download logic behaves after segwit activation.=C2=A0 After segwit ac= tivation, Bitcoin Core nodes will not (currently) attempt to download any b= locks from non-segwit peers (nodes that do not set the NODE WITNESS service= bit).=C2=A0 This is a bandwidth optimization to prevent a node from downlo= ading a block that may be invalid only because the sender omitted the witne= ss, requiring re-download until the block is received with the required wit= ness data.

But to be clear, non-segwit blocks -- t= hat is, blocks without a witness commitment in the coinbase, and whose tran= sactions are serialized without witnesses, and whose transactions are not s= pending segwit outputs which require a witness -- are evaluated under the s= ame rules as prior, pre-segwit versions of the software.=C2=A0 So such non-= segwit blocks that are valid to older, pre-segwit nodes are also valid to s= egwit-nodes.


Given the protocol requirements of the segwit proposal thi= s is not the
case. A miner running pre-segwit code will produce blocks t= hat no
segwit node will ever receive.

Th= e phrase "protocol requirements of segwit" is confusing here, bec= ause there are two different layers that need consideration: the consensus = protocol layer and the peer-to-peer protocol layer.=C2=A0 But in neither la= yer is the behavior of not downloading blocks from non-NODE WITNESS peers a= "requirement".=C2=A0 This is an implementation detail in the Bit= coin Core code that alternate implementations compliant with BIP 144 could = implement differently.

At the consensus laye= r, non-segwit blocks (described above) that are valid to older nodes are al= so valid to segwit nodes.=C2=A0 That means that if a miner was using an old= er, pre-segwit version of Bitcoin Core to produce blocks after segwit activ= ates, that blocks they find will be valid to all nodes.

<= /div>
At the p2p layer, though, segwit-enabled Bitcoin Core nodes will = only try to download those blocks if announced by a segwit-enabled peer.=C2= =A0 But this is not a protocol requirement; other implementations can remai= n compatible even they take different approaches here. =C2=A0(As an example= , I could imagine an implementation that downloaded a new block from any pe= er, but if the block has a witness commitment in the coinbase and was recei= ved from a non-segwit peer, then the node would attempt re-download from a = segwit peer.=C2=A0 I'm sure many other reasonable block download strate= gies could be devised.)

Still, if a miner wants to= continue mining post-segwit activation, but using pre-segwit software, the= y would need a way to relay their blocks to a segwit-enabled peer.

There are a few ways to do this that I can think of:
=

- Use the RPC call "submitblock" on a segwit-= enabled node.=C2=A0 Calling "submitblock" on a Bitcoin Core 0.13.= 1 (0.13.0 in the case of testnet) or later node works fine as long as the b= lock is valid (whether or not it has a witness commitment or witness transa= ctions), and once a segwit-enabled peer has the block it will relay to othe= r segwit peers.

- Explicitly deliver the block to = a segwit node over the p2p network, even if unrequested.=C2=A0 Currently Bi= tcoin Core at least will process unrequested blocks, and valid blocks that = update the tip will then be relayed to other peers.

- Run a bridge node, which advertises NODE_WITNESS and can serialize bloc= ks with witness data, which downloads blocks even from non-NODE WITNESS pee= rs.=C2=A0 Anyone can do this to bridge the networks for the benefit of the = whole network (I have personally been running a few nodes that do this, for= several months now), but miners concerned about this issue for their own b= locks could explicitly do this themselves to ensure that their own blocks p= ropagate to the segwit-enabled network.

- Peer dir= ectly with other miners, bypassing the p2p network.=C2=A0 Many miners do th= is already, using protocols which may already serve to bridge the network.<= /div>

So saying that "A miner running pre-segwit co= de will produce blocks that no segwit node will ever receive" is not r= eally correct, in my view.=C2=A0 If the whole network were just running Bit= coin Core software releases, and the miner was not able/willing to deliver = their block to a segwit-enabled node (eg by using the RPC call "submit= block", or one of the other suggestions I had above), then I would agr= ee with the statement.=C2=A0 But given that there are bridge nodes on the n= etwork, and that miners have other options to relay their block, I think th= is is not an accurate portrayal of what would actually happen on the networ= k -- I would expect that non-segwit miners' blocks would still get rela= yed post-segwit activation, even if only by the handful of bridge nodes tha= t I expect are currently running.

All that sa= id, I do think this is an important detail to highlight and that this behav= ior should be better documented (I believe it deserves specific mention in = a BIP), as this is an important issue for miners to be aware of.
--f403045e34348933ba054bbb443d--