[bitcoin-dev] [BIP] Normalized transaction IDs

Luke Dashjr luke at dashjr.org
Tue Nov 3 20:48:17 UTC 2015


On Tuesday, November 03, 2015 8:37:44 PM Christian Decker wrote:
> I am still very much intrigued by Luke's idea of having empty scriptsigs
> and ship the signatures in external scripts, however the proposal uses the
> on-the-fly normalization because we have no good way of relaying the
> external scripts. Since we are still in the drafting phase I am open to
> suggestions and if there is a good/working solution I can amend/withdraw
> the proposal.

Changing the network protocol is trivial in comparison to making a permanent 
increase in UTXO set costs.

> As for open venues for malleability, I'm not sure we can fix them at all,
> after all the ability of a single signer to doublespend by
> appending/replacing inputs/outputs in an arbitrary fashion is not fixable
> IMHO and will cause any future transaction building on its outputs to be
> orphaned. What would the perfect properties for such a fix be?

The problem isn't changing inputs/outputs, but that such changes invalidate 
later spends. In particular, note that wallets *should ideally* be actively 
trying to make transfers using multiple malleated versions of the same 
payment.

So the way to make an anti-malleable wallet, would be to strictly enforce the 
no-address-reuse rule on payments received (note this has no effect on 
other/current wallets) and rely only on the hash of that scriptPubKey+value 
for the input in subsequent transactions. This way, no matter what inputs or 
other outputs the transaction paying the address/invoice uses, the subsequent 
transaction ignores them and remains valid. (I am not suggesting this as a 
mandatory change that all wallets must adopt to receive the current semi-
malleability protection you propose - only that it be *possible* for wallets 
to upgrade to or offer in the future.)

Luke


More information about the bitcoin-dev mailing list