From: Eric Voskuil <eric@voskuil•org>
To: Suhas Daftuar <sdaftuar@gmail•com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Segregated witness p2p layer compatibility
Date: Mon, 27 Mar 2017 14:03:08 -0700 [thread overview]
Message-ID: <cacb32cd-387b-2189-141f-3f5f60c38d49@voskuil.org> (raw)
In-Reply-To: <CAFp6fsHhqdL=MNyAAyfwA7qw5-MhW19Whky+kY3n3=+u61bXBg@mail.gmail.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 03/27/2017 12:22 PM, Suhas Daftuar via bitcoin-dev wrote:
> 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.
I agree, and thanks for the detailed clarification. Clearly it is
possible for segwit blocks to be relayed. It is the implementation of
Bitcoin Core (at least), in the absence of sufficient relay, that
produces this outcome.
> 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.
IOW Bitcoin Core has been implemented so that it will not see valid
blocks announced by certain of its peers. Forcing it to see such
blocks requires the p2p network work around its implementation. I
agree that this is not inherent in the specifications for segwit, but
it reads more like a bug than an "implementation detail" to me.
e
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQEcBAEBCAAGBQJY2X3/AAoJEDzYwH8LXOFOez8H+wcmUkQnzqMlmBTQ/OqMO6q4
enLOX3H4UDa6gZdUxEDpszUvuca2ayukVYwIVo28BcjsTmQgxaxdrFTNTDYTRfe1
S2aX3Ftism0zuEIw8/KM2wcnNaHe9C5Q8TRmW7u6ZoLTJFwCkKWK1VEM9GFDePpT
+HjtdviKt3s6NwiYhG+U+JawF+YDJvxyxcEj28bMFB1EW1kIAPA709oz2scZCPrc
VroEUoFXFgMXBJaosKSVTUN3JE9pU9R1Mn7xVWwMEdU1IjeOeygHjdE/NfP7BJuU
05dWsH0be/xyNO76oFGhmwIyDogloQ9a5klEe7NetTDs1ieMD5j5oyr/qB79spw=
=xkiV
-----END PGP SIGNATURE-----
prev parent reply other threads:[~2017-03-27 21:02 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-27 19:22 Suhas Daftuar
2017-03-27 19:32 ` Matt Corallo
2017-03-27 21:03 ` Eric Voskuil [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=cacb32cd-387b-2189-141f-3f5f60c38d49@voskuil.org \
--to=eric@voskuil$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=sdaftuar@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox