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 6DCBA360 for ; Mon, 27 Mar 2017 21:02:48 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-pg0-f51.google.com (mail-pg0-f51.google.com [74.125.83.51]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D550F128 for ; Mon, 27 Mar 2017 21:02:47 +0000 (UTC) Received: by mail-pg0-f51.google.com with SMTP id 81so36993256pgh.2 for ; Mon, 27 Mar 2017 14:02:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=voskuil-org.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=0HN/snQv6chHUr36dTgjqHLDjWh16uXk2UNKnH9/llw=; b=2Coq0hn1VkEgH+L9jvr3u9Dq9HEA/r+aTYTgWrr027b4vBBBRTvvhX2Oa/g5pS92XN 0UuF+PZO/J777NUZi/b5Mrb3c2oac8vS4SEtUd6Oilt6dT0gT18kwNsFAqxmiI6sC2Ko XYmZb3ZsUS7sb6bQqorqkndCOxSOWhbqllT42kqu3Ej9JITfnW3WTzDPqvCe5qM9MsWm UZTEyQNNftL0TLd6keutslUwSjSFv00gS2FHdvxswvA/dhuFAwC6BFWX8V9g80mmSjy5 456HLodW9N2jlhPYI3I1LTLHd/iZq99qXgTrTCvp4pFPpG6FlAvYge3tx/A2K4H15Gj2 Gfmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=0HN/snQv6chHUr36dTgjqHLDjWh16uXk2UNKnH9/llw=; b=YDuTjvaANI9qsIa8Oy/Adcnk8hjBiJ2pzMIWIMI3w73g+1qpvYxjx5NDpYqkHWjfxp C1iHhScDIdKA27diRuzyyMt77cjvQWCwDXtpZbMJrcJJYiFUvlA/c0TpAFN3kn/fSs5Z ZN96T263ZVQs2tS4bueC8Ix3gHfwLjcVUbdPZ8NSKO+JQaCgtAhcyo4N7hMEHD3Ug3YS A1hwg0XGJSaxuFAVIl1hzcEP3zG8yGRWvELVQj2iIJMglAJDbGMyCY4dpoyPa8VsuonW sU2Ff8GAGBvd5Yljhd9E464peTxgkL4RCBl/WooJeVX+iNdXxU65nAiDngJYVtkqN7Xi +M/Q== X-Gm-Message-State: AFeK/H0bmXI/R2oQ+f+Z4f7p6XDVMrnquwIseAirMrJ7ibOLLHn1ilS3peo0EvFU91tKoQ== X-Received: by 10.99.47.68 with SMTP id v65mr26473534pgv.23.1490648567236; Mon, 27 Mar 2017 14:02:47 -0700 (PDT) Received: from ?IPv6:2601:600:9000:d69e:8c11:8163:4024:ef42? ([2601:600:9000:d69e:8c11:8163:4024:ef42]) by smtp.gmail.com with ESMTPSA id t12sm2932768pfg.14.2017.03.27.14.02.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Mar 2017 14:02:46 -0700 (PDT) To: Suhas Daftuar , Bitcoin Protocol Discussion References: From: Eric Voskuil Message-ID: Date: Mon, 27 Mar 2017 14:03:08 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,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 X-Mailman-Approved-At: Mon, 27 Mar 2017 21:17:48 +0000 Subject: Re: [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 21:02:48 -0000 -----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-----