📅 Original date posted:2015-11-27
📝 Original message:
> 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?
Did not thought about that, yes you are right.
> Yeah, it's 99% of the way there; I just worry about random vandalism,
> personally.
Yes, I was worrying about B pro actively malleating everything.
But since A controls broadcast time, he can choose to delay the broadcast
when a vast malleability attack happens.
On Sat, Nov 28, 2015 at 5:11 AM, Anthony Towns <aj at erisian.com.au> wrote:
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20151128/ea994660/attachment-0001.html>;
Nicolas Dorier [ARCHIVE] /
npub1hu…9q4u3
2023-06-09 14:45:19
in reply to nevent1q…mlru
Author Public Key
npub1huz53hq26gu7nc0qhw3uj6tr9hk5q2ngpywduxep5zy4ay9unftsm9q4u3Published at
2023-06-09 14:45:19Event JSON
{
"id": "b14dbaa0704ec46b6b44fc09b489cb2439fee857a269b68ef00780142f555799",
"pubkey": "bf0548dc0ad239e9e1e0bba3c969632ded402a68091cde1b21a0895e90bc9a57",
"created_at": 1686314719,
"kind": 1,
"tags": [
[
"e",
"976944a7f9d46a909b7be1bf805da7a69458632cf9b988a18d530a47c461d44a",
"",
"root"
],
[
"e",
"f8465c2ceb432e911b951a1dea0a452c022f6975f70fce089c2940f2697cab33",
"",
"reply"
],
[
"p",
"f0feda6ad58ea9f486e469f87b3b9996494363a26982b864667c5d8acb0542ab"
]
],
"content": "📅 Original date posted:2015-11-27\n📝 Original message:\n\u003e But B won't be able to guess what the \u003crevoke\u003e hash is, so won't be\n\u003e able to correlate with potential anchor transactions at all, afaics,\n\u003e even if pubkeys \u003cA\u003e and \u003cB\u003e are both known to B?\n\nDid not thought about that, yes you are right.\n\n\u003e Yeah, it's 99% of the way there; I just worry about random vandalism,\n\u003e personally.\n\nYes, I was worrying about B pro actively malleating everything.\nBut since A controls broadcast time, he can choose to delay the broadcast\nwhen a vast malleability attack happens.\n\n\nOn Sat, Nov 28, 2015 at 5:11 AM, Anthony Towns \u003caj at erisian.com.au\u003e wrote:\n\n\u003e On Sat, Nov 28, 2015 at 01:18:21AM +0900, Nicolas Dorier wrote:\n\u003e \u003e \u003e A also passes the original unsigned commitment to B, who verifies that\n\u003e \u003e \u003e it's in the right format (ie, can be revoked), and hashes to the hash\n\u003e \u003e \u003e that he signed.\n\u003e \u003e No, if A pass the unsigned commitment to B then B can malleate the\n\u003e anchor.\n\u003e\n\u003e Sorry, I meant the above needs to happen after the anchor's confirmed\n\u003e in the blockchain (and A's told B about the anchor).\n\u003e\n\u003e \u003e \u003e B can't reuse pubkeys between different channels with this protocol\n\u003e \u003e \u003e either, but that's good practice anyway.\n\u003e \u003e Right, neither A should. If A reuse a key, then B can guess the redeem\n\u003e \u003e hash, then would identify the transaction to malleate at broadcast time,\n\u003e \u003e before A's announcement.\n\u003e\n\u003e B will be providing a signature for a tx that:\n\u003e\n\u003e - has the anchor as input\n\u003e - has a single refund output payable to\n\u003e (A \u0026\u0026 OP_CSV) | (B \u0026\u0026 OP_HASH \u003crevoke\u003e OP_EQUALVERIFY)\n\u003e\n\u003e But B won't be able to guess what the \u003crevoke\u003e hash is, so won't be\n\u003e able to correlate with potential anchor transactions at all, afaics,\n\u003e even if pubkeys \u003cA\u003e and \u003cB\u003e are both known to B?\n\u003e\n\u003e \u003e I'd prefer seggregated witness to fix the problem cleanly, but I think\n\u003e that\n\u003e \u003e opening the channel as I said is a good enough workaround until it\n\u003e happen.\n\u003e\n\u003e Yeah, it's 99% of the way there; I just worry about random vandalism,\n\u003e personally.\n\u003e\n\u003e Cheers,\n\u003e aj\n\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20151128/ea994660/attachment-0001.html\u003e",
"sig": "2a7a7f1e56dfecd81b510c6a6be2724a40fbed45ce73f784f081e49d553702164a069690bab02652b49ff9b755e2414365cc9eea05877b606e066a7aa27e18dd"
}