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

[Luke Dashjr <luke@dashjr.org>]

On Thursday, November 05, 2015 3:27:37 PM Jorge Timón wrote:
> On Tue, Nov 3, 2015 at 11:01 PM, Luke Dashjr via bitcoin-dev
> 
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> > On Tuesday, November 03, 2015 9:44:02 PM Christian Decker wrote:
> >> So this is indeed a form of desired malleability we will likely not be
> >> able to fix. I'd argue that this goes more into the direction of
> >> double-spending than a form of malleability, and is mostly out of scope
> >> for this BIP. As the abstract mentions this BIP attempts to eliminate
> >> damage incurred by malleability in the third party modification
> >> scenario and in the multisig scenario, with the added benefit of
> >> enabling transaction templating. If we can get the segregated witnesses
> >> approach working all the better, we don't even have the penalty of
> >> increased UTXO size. The problem of singlesig users doublespending
> >> their outputs to update transactions remains a problem even then.
> > 
> > I don't know what you're trying to say here. Double spending to the same
> > destination(s) and malleability are literally the same thing. Things
> > affected by malleability are still just as broken even with this BIP -
> > whether it is triggered by a third-party or not is not very relevant.
> 
> 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).

Ok, then my point is that "signature malleability" is not particularly 
problematic or interesting alone, and the only way to get a practically-useful 
solution, is to address all kinds of malleability.

Luke