Re: [bitcoin-dev] [BIP] Normalized transaction IDs

[Peter Todd <pete@petertodd.org>]

[-- Attachment #1: Type: text/plain, Size: 1810 bytes --]

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]