Date: Tue, 3 Nov 2015 23:00:33 -0500
From: Peter Todd <pete@petertodd.org>
To: Christian Decker <decker.christian@gmail.com>
Message-ID: <20151104040033.GA26961@muck>
References: <CALxbBHU+kdEAh_4+B663vknAAr8OKZpUzVTACORPZi47E=Ehkw@mail.gmail.com>
	<201510220905.27124.luke@dashjr.org>
	<CALxbBHV4JU7TG8QutkX7m9V4n_ANgKAgWO8ZA2KxQk8jP=kF0g@mail.gmail.com>
	<201511032048.18680.luke@dashjr.org>
	<CALxbBHVwv_T4=DTUdmbgG2y7QmjETCKbQ6_oKKNjsCS=HDrJ+A@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="HcAYCG3uE/tztfnV"
Content-Disposition: inline
In-Reply-To: <CALxbBHVwv_T4=DTUdmbgG2y7QmjETCKbQ6_oKKNjsCS=HDrJ+A@mail.gmail.com>
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] [BIP] Normalized transaction IDs
Precedence: list


--HcAYCG3uE/tztfnV
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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 t=
he
> 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 scrip=
ts
> 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.
>=20
> 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.

--=20
'peter'[:-1]@petertodd.org
00000000000000000247b0e7436a5169ac6f9087be0295d10b07bf0bcbd4c0cc

--HcAYCG3uE/tztfnV
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----

iQGrBAEBCACVBQJWOYLcXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw
MDAwMDAwMDAwMDAwMDAwZDhkMTNhMDM5M2JlZTIwNjhkZGUxZjI3MzJiNjc4NmUx
MGQzODM4NDcxMzA4NDUvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0
ZUBwZXRlcnRvZC5vcmcACgkQwIXyHOf0udyzFQf/dAaIRXA2rTnHnUCB4VztI+Yy
mE0oX81wtUsnei/JtxzTr5Z92zxSMLvxgrDAscywDCapHicdbNUj4UDeXJ7CyeL3
/cZOcxlsQYYqfe8pJqFtwZKtfNUqlni4xYH5fjyQBjMjdFAGB/ICbSVSnmKkiV62
nldkUx1jg5jdMNXntuWC9zu7alnfcp4crfyy3hEM6m0WBTAjOPn7uhPTMK2B0uBS
AdAOI07LG++ztys3SiUBluDnkzXhufOlocyeSOqhfJGEZMFVihst/lFM22NveNzl
wWf7j0b4MGPze9udgmtkM8ZsiyI/ZpFUqjN3AWJOQv2KvOON5wHk8Rtou4283g==
=ul4p
-----END PGP SIGNATURE-----

--HcAYCG3uE/tztfnV--