📅 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
Luke Dashjr [ARCHIVE] /
npub1tf…rfq0n
2023-06-07 17:44:07
in reply to nevent1q…0v8p
Author Public Key
npub1tfk373zg9dnmtvxnpnq7s2dkdgj37rwfj3yrwld7830qltmv8qps8rfq0nPublished at
2023-06-07 17:44:07Event JSON
{
"id": "6cdb135b095b4d47194fbb88328fe159b6ff499b74507651049ff5b99d193439",
"pubkey": "5a6d1f44482b67b5b0d30cc1e829b66a251f0dc99448377dbe3c5e0faf6c3803",
"created_at": 1686159847,
"kind": 1,
"tags": [
[
"e",
"59e25977e31b6de547dc99825f6bc9fc8d0d57f8dc5978611471ad70444e93b2",
"",
"root"
],
[
"e",
"20b36e0ea60affd446db326acb60a4c587fd2a476c220c62555135b7ae3d4242",
"",
"reply"
],
[
"p",
"498a711971f8a0194289aee037a4c481a99e731b5151724064973cc0e0b27c84"
]
],
"content": "📅 Original date posted:2015-11-05\n📝 Original message:On Thursday, November 05, 2015 3:27:37 PM Jorge Timón wrote:\n\u003e On Tue, Nov 3, 2015 at 11:01 PM, Luke Dashjr via bitcoin-dev\n\u003e \n\u003e \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e \u003e On Tuesday, November 03, 2015 9:44:02 PM Christian Decker wrote:\n\u003e \u003e\u003e So this is indeed a form of desired malleability we will likely not be\n\u003e \u003e\u003e able to fix. I'd argue that this goes more into the direction of\n\u003e \u003e\u003e double-spending than a form of malleability, and is mostly out of scope\n\u003e \u003e\u003e for this BIP. As the abstract mentions this BIP attempts to eliminate\n\u003e \u003e\u003e damage incurred by malleability in the third party modification\n\u003e \u003e\u003e scenario and in the multisig scenario, with the added benefit of\n\u003e \u003e\u003e enabling transaction templating. If we can get the segregated witnesses\n\u003e \u003e\u003e approach working all the better, we don't even have the penalty of\n\u003e \u003e\u003e increased UTXO size. The problem of singlesig users doublespending\n\u003e \u003e\u003e their outputs to update transactions remains a problem even then.\n\u003e \u003e \n\u003e \u003e I don't know what you're trying to say here. Double spending to the same\n\u003e \u003e destination(s) and malleability are literally the same thing. Things\n\u003e \u003e affected by malleability are still just as broken even with this BIP -\n\u003e \u003e whether it is triggered by a third-party or not is not very relevant.\n\u003e \n\u003e I think this is just a terminology confusion.\n\u003e There's conflicting spends of the same outputs (aka unconfirmed\n\u003e double-spends), and there's signature malleability which Segregated\n\u003e Witnesses solves.\n\u003e If we want to define malleability as signature malleability +\n\u003e conflicting spends, then that's fine.\n\u003e But it seems Christian is mostly interested in signature malleability,\n\u003e which is what SW can solve.\n\u003e In fact, creating conflicting spends is sometimes useful for some\n\u003e contracts (ie to cancel the contract when that's supposed to be\n\u003e allowed).\n\u003e Maybe it is \"incorrect\" that people use \"malleability\" when they're\n\u003e specifically talking about \"signature malleability\", but I think that\n\u003e in this case it's clear that we're talking about transactions having\n\u003e an id that cannot be changed just by signing with a different nonce\n\u003e (what SW provides).\n\nOk, then my point is that \"signature malleability\" is not particularly \nproblematic or interesting alone, and the only way to get a practically-useful \nsolution, is to address all kinds of malleability.\n\nLuke",
"sig": "f16931c999acc9142fd2b5cbcf948e9c4586daa8a9bcee495e853657957ac80a79b0be25ed35a7cfc92a1ff3621dbf245a3ffdac501ebb584201dee97a45f5af"
}