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 742AA8DD for ; Thu, 5 Nov 2015 09:38:15 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 5DF74112 for ; Thu, 5 Nov 2015 09:38:14 +0000 (UTC) Received: by wicll6 with SMTP id ll6so5716483wic.1 for ; Thu, 05 Nov 2015 01:38:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=84vB4QvPjMOVNxjT3gFILXGHS2FR8iHK1stWVMi6J0s=; b=1C5VbqBrnAxLP1Wft9KoQ5bqVuKcpgUhxcOU2sAw0zKmwTK7u2rXjGB/K2fysf0Umt 1zHmEyxzn7kS7M/u8o8ZviakX8J0JRdtEd97claNMDauMUkZmFCIag5fk7ImBH38yGQ7 lXoWNe6phdhoYlvdV0MOstiPGJDG2ih3KT+9sIDERcdKtdoEp2HeSa6oboJPEpk2YVt2 8GQUu6Bc7Rl1iNnYySzY+n80XTh24AlWpb2HaRICA6OPTVHhoLY1jrvZoKIqMW20btFE enEVw7kCtBNjS6Yfo1ahWyq09uKGjXmVY3nYOs8szhH0lPMjNqcywVO6RTj5XutnLo9g 4Fug== X-Received: by 10.194.243.227 with SMTP id xb3mr7994607wjc.96.1446716292698; Thu, 05 Nov 2015 01:38:12 -0800 (PST) MIME-Version: 1.0 References: <201510220905.27124.luke@dashjr.org> <201511032048.18680.luke@dashjr.org> <20151104040033.GA26961@muck> In-Reply-To: <20151104040033.GA26961@muck> From: Christian Decker Date: Thu, 05 Nov 2015 09:38:03 +0000 Message-ID: To: Peter Todd Content-Type: multipart/alternative; boundary=089e0141a162b7a12f0523c7e2a1 X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,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] [BIP] Normalized transaction IDs 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: Thu, 05 Nov 2015 09:38:15 -0000 --089e0141a162b7a12f0523c7e2a1 Content-Type: text/plain; charset=UTF-8 This does indeed sound reasonable. The chances of having a cut in the network consisting of non-upgraded nodes partitioning the network and not forwarding the segregated witnesses should be minimal, given a long rollout phase before the activation. If everybody agrees that this is a better way to approach the normalization issue we should probably start writing it up and see if we can get critical mass behind it :-) On Wed, Nov 4, 2015 at 5:00 AM Peter Todd wrote: > On Tue, Nov 03, 2015 at 09:44:02PM +0000, Christian Decker via bitcoin-dev > wrote: > > Ok, so assuming we can get a connected component of upgraded nodes that > > relay both the transaction and the associated external scripts then we > > could just piggyback the external scripts on top of the normal messages. > > Non-upgraded nodes will read the entire two-part message but only parse > the > > classical transaction, dropping the external script. Validation rules for > > upgraded nodes are the same as before: if the attached signatures are > > invalid the entire TX is dropped. We have to commit to the external > scripts > > used during the creation of a block. I think the easiest way to add this > > commitment is the coinbase input I guess, and following the transaction > > list a new list of signature lists is shipped with the rest of the block. > > Non-upgraded will ignore it as before. > > > > Would that work? It all hinges on having upgraded miners in a connected > > component otherwise non-upgraded nodes will drop the external scripts on > > the way (since they parse and then reconstruct the messages along the > > path). But if it works this could be a much nicer solution. > > FWIW my replace-by-fee fork does preferential peering with other RBF > nodes to ensure that you'll always be connected to at least some > full-RBF peers. In practice this works very well, and I'm sure a similar > scheme could be used in this situation as well. > > Basically, conceptually unless you're connected to peers that advertise > that they relay the new data, you treat the situation as though you're > not connected to any peers at all. No different than if for some reason > none of your peers were advertising NODE_NETWORK. > > -- > 'peter'[:-1]@petertodd.org > 00000000000000000247b0e7436a5169ac6f9087be0295d10b07bf0bcbd4c0cc > --089e0141a162b7a12f0523c7e2a1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This does indeed sound reasonable. The chances of having a= cut in the network consisting of non-upgraded nodes partitioning the netwo= rk and not forwarding the segregated witnesses should be minimal, given a l= ong rollout phase before the activation.

If everybody ag= rees that this is a better way to approach the normalization issue we shoul= d probably start writing it up and see if we can get critical mass behind i= t :-)

On Wed, No= v 4, 2015 at 5:00 AM Peter Todd <p= ete@petertodd.org> wrote:
On= Tue, Nov 03, 2015 at 09:44:02PM +0000, Christian Decker via bitcoin-dev wr= ote:
> Ok, so assuming we can get a connected component of upgraded nodes tha= t
> relay both the transaction and the associated external scripts then we=
> could just piggyback the external scripts on top of the normal message= s.
> Non-upgraded nodes will read the entire two-part message but only pars= e the
> classical transaction, dropping the external script. Validation rules = for
> upgraded nodes are the same as before: if the attached signatures are<= br> > invalid the entire TX is dropped. We have to commit to the external sc= ripts
> used during the creation of a block. I think the easiest way to add th= is
> commitment is the coinbase input I guess, and following the transactio= n
> list a new list of signature lists is shipped with the rest of the blo= ck.
> Non-upgraded will ignore it as before.
>
> Would that work? It all hinges on having upgraded miners in a connecte= d
> component otherwise non-upgraded nodes will drop the external scripts = on
> the way (since they parse and then reconstruct the messages along the<= br> > path). But if it works this could be a much nicer solution.

FWIW my replace-by-fee fork does preferential peering with other RBF
nodes to ensure that you'll always be connected to at least some
full-RBF peers. In practice this works very well, and I'm sure a simila= r
scheme could be used in this situation as well.

Basically, conceptually unless you're connected to peers that advertise=
that they relay the new data, you treat the situation as though you're<= br> not connected to any peers at all. No different than if for some reason
none of your peers were advertising NODE_NETWORK.

--
'peter'[:-1]@petertodd.org
00000000000000000247b0e7436a5169ac6f9087be0295d10b07bf0bcbd4c0cc
--089e0141a162b7a12f0523c7e2a1--