Luke Dashjr [ARCHIVE] on Nostr: 📅 Original date posted:2015-11-05 📝 Original message:On Thursday, November 05, ...
📅 Original date posted:2015-11-05
📝 Original message: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 at 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
📝 Original message: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 at 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