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 > > <[email protected]> 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 _______________________________________________ bitcoin-dev mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
