[bitcoin-dev] [BIP] Normalized transaction IDs

Christian Decker decker.christian at gmail.com
Fri Nov 6 14:52:49 UTC 2015


On Thu, Nov 5, 2015 at 4:27 PM Jorge Timón <jtimon at jtimon.cc> wrote:

> I think this is just a terminology confusion.
> There's conflicting spends of the same outputs (aka unconfirmed
> double-spends), and there's signature malleability which Segregated
> Witnesses solves.
> If we want to define malleability as signature malleability +
> conflicting spends, then that's fine.
> But it seems Christian is mostly interested in signature malleability,
> which is what SW can solve.
> In fact, creating conflicting spends is sometimes useful for some
> contracts (ie to cancel the contract when that's supposed to be
> allowed).
> Maybe it is "incorrect" that people use "malleability" when they're
> specifically talking about "signature malleability", but I think that
> in this case it's clear that we're talking about transactions having
> an id that cannot be changed just by signing with a different nonce
> (what SW provides).
>
> Please, Christian, correct me if you mean something else.
>

Yes, your differentiation is spot on. My main goal is to eliminate the risk
of detaching transactions in  off-blockchain protocols that rely on a
number of transactions being chained, hence solving signature malleability
might be the correct term. Canonical encodings do address part of the
problem, however they do nothing in the case of one of the signers
re-signing a transaction and detaching any followup transaction. Also
having transaction templates is a nice way to reduce the complexity of
protocols by eliminating some of the "who signs what when" gotchas.
Segregated witnesses would be a perfect solution, we just need to find a
good migration plan for Bitcoin :-)

Sorry for the confusion caused by me misusing the term malleability, I'll
use signature malleability in the future :-)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151106/1a49d31c/attachment.html>


More information about the bitcoin-dev mailing list