📅 Original date posted:2015-11-27
📝 Original message:
On Sat, Nov 28, 2015 at 01:18:21AM +0900, Nicolas Dorier wrote:
> > A also passes the original unsigned commitment to B, who verifies that
> > it's in the right format (ie, can be revoked), and hashes to the hash
> > that he signed.
> No, if A pass the unsigned commitment to B then B can malleate the anchor.
Sorry, I meant the above needs to happen after the anchor's confirmed
in the blockchain (and A's told B about the anchor).
> > B can't reuse pubkeys between different channels with this protocol
> > either, but that's good practice anyway.
> Right, neither A should. If A reuse a key, then B can guess the redeem
> hash, then would identify the transaction to malleate at broadcast time,
> before A's announcement.
B will be providing a signature for a tx that:
- has the anchor as input
- has a single refund output payable to
(A && OP_CSV) | (B && OP_HASH <revoke> OP_EQUALVERIFY)
But B won't be able to guess what the <revoke> hash is, so won't be
able to correlate with potential anchor transactions at all, afaics,
even if pubkeys <A> and <B> are both known to B?
> I'd prefer seggregated witness to fix the problem cleanly, but I think that
> opening the channel as I said is a good enough workaround until it happen.
Yeah, it's 99% of the way there; I just worry about random vandalism,
personally.
Cheers,
aj
Anthony Towns [ARCHIVE] /
npub17r…x9l2h
2023-06-09 12:45:18
in reply to nevent1q…sngp
Author Public Key
npub17rld56k4365lfphyd8u8kwuejey5xcazdxptserx03wc4jc9g24stx9l2hPublished at
2023-06-09 12:45:18Event JSON
{
"id": "f8465c2ceb432e911b951a1dea0a452c022f6975f70fce089c2940f2697cab33",
"pubkey": "f0feda6ad58ea9f486e469f87b3b9996494363a26982b864667c5d8acb0542ab",
"created_at": 1686314718,
"kind": 1,
"tags": [
[
"e",
"976944a7f9d46a909b7be1bf805da7a69458632cf9b988a18d530a47c461d44a",
"",
"root"
],
[
"e",
"14baa18fc80efb50cb8e1bde0bb1c989b4ebed9439b4dac875c7da7741a12b7e",
"",
"reply"
],
[
"p",
"bf0548dc0ad239e9e1e0bba3c969632ded402a68091cde1b21a0895e90bc9a57"
]
],
"content": "📅 Original date posted:2015-11-27\n📝 Original message:\nOn Sat, Nov 28, 2015 at 01:18:21AM +0900, Nicolas Dorier wrote:\n\u003e \u003e A also passes the original unsigned commitment to B, who verifies that\n\u003e \u003e it's in the right format (ie, can be revoked), and hashes to the hash\n\u003e \u003e that he signed.\n\u003e No, if A pass the unsigned commitment to B then B can malleate the anchor.\n\nSorry, I meant the above needs to happen after the anchor's confirmed\nin the blockchain (and A's told B about the anchor).\n\n\u003e \u003e B can't reuse pubkeys between different channels with this protocol\n\u003e \u003e either, but that's good practice anyway.\n\u003e Right, neither A should. If A reuse a key, then B can guess the redeem\n\u003e hash, then would identify the transaction to malleate at broadcast time,\n\u003e before A's announcement.\n\nB will be providing a signature for a tx that:\n\n - has the anchor as input\n - has a single refund output payable to\n (A \u0026\u0026 OP_CSV) | (B \u0026\u0026 OP_HASH \u003crevoke\u003e OP_EQUALVERIFY)\n\nBut B won't be able to guess what the \u003crevoke\u003e hash is, so won't be\nable to correlate with potential anchor transactions at all, afaics,\neven if pubkeys \u003cA\u003e and \u003cB\u003e are both known to B?\n\n\u003e I'd prefer seggregated witness to fix the problem cleanly, but I think that\n\u003e opening the channel as I said is a good enough workaround until it happen.\n\nYeah, it's 99% of the way there; I just worry about random vandalism,\npersonally.\n\nCheers,\naj",
"sig": "0d7317044547c426dec71f0085179d48fc019a0b490edae271199cb6633a609d4ff03400970667d72274613ba53bfe3069839bca8a4363d43d56d840c4ee74b3"
}