📅 Original date posted:2015-11-27
📝 Original message:
> 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.
(because B would know the txid of the anchor at broadcast time)
B does not have to verify it is in right format, because he does not have
anything to loose by signing a random hash.
B can verify he signed the hash of the first commitment after A announce
his already confirmed anchor.
> Someone other than B (ie a third party) could malleate the anchor between
> broadcast and confirmation just for their own amusement.
Yes, actually the only malleability vector which B can use to his advantage
is HighS, not all BIP62 vectors.
Knowing miners will most likely run at least 0.11.2 (if CLTV is acceepted)
HighS should be more likely rejected.
> 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.
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.
The only attack B can try is malleate all transaction to HighS.
When CLTV will pass, there is not lot of probability of such attack to
succeed, because bitcoind should block HighS.
> 'without timeout' is only possible with OP_CSV - not naturally
with what we have currently. ;)
The anchor does not have to use OP_CSV at all. But yes, for commitment, I'm
assuming OP_CSV passed.
> To be able to build a valid payment channel on top of the anchor,
B has to be sure that A cannot get her money back at any point in the
future. Given just a hash that B should sign, B has no clue what is
the output of the transaction he just signed.
Actually B do not care about it. Remember I am separating "A's anchor
broadcast" from "A's announcement of anchor to B".
When A announce the anchor, then B can check if he really signed the first
commitment or something else, but he can't malleate anything since the
anchor is already confirmed.
B does not have anything to loose by signing unknown hash. (if he use a non
reusable key)
Again, yes, a network-wide HighS attack would be the only way to malleate
the anchor.
If CLTV fork pass, then it is fair to consider that the odd of such attack
succeeding is very low. HighS should be blocked from 0.11.1 if I remember
well.
On Fri, Nov 27, 2015 at 6:09 PM, Anthony Towns <aj at erisian.com.au> wrote:
> On Fri, Nov 27, 2015 at 04:37:04PM +0900, Nicolas Dorier wrote:
> > By adapting an idea from gmaxwell (
> > https://bitcointalk.org/index.php?topic=303088.0) it is possible to
> open a
> > channel without suffering from malleability attack.
> > The process for A to open channel with B is the following:
> > * A asks B pubkey
> > * A create the first commitment transaction
> > * A extract the hash that B needs to sign to be able to broadcast the
> > commitment
> > * A asks B to sign the hash, but do not disclose the commitment
> > * A broadcast the anchor
> > * After confirmation, A announce the anchor to B.
>
> 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.
>
> > B can't identify A's anchor before announcement because he does not know
> > the P2SH of the multisig.
> > Am I missing something ?
>
> Someone other than B (ie a third party) could malleate the anchor between
> broadcast and confirmation just for their own amusement.
>
> B can't reuse pubkeys between different channels with this protocol
> either, but that's good practice anyway.
>
> From the same forum post, using child-pays-for-parent seems plausible.
> Doing:
>
> txA: spend 6 BTC to
> 5 BTC to A&B
> 1 BTC to A
>
> txB: spend 1 BTC from txA:1 to
> 0.999 BTC to A
>
> should be pretty safe: either someone malleates txA and mines it for
> 0 fee; or they mine both txA+txB for 0.001 BTC fee, and txA can't be
> malleated. But CPFP doesn't work yet, and segregated witness seems like
> it'll happen sooner anyway?
>
> Cheers,
> aj
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20151128/454bf694/attachment.html>;
Nicolas Dorier [ARCHIVE] /
npub1hu…9q4u3
2023-06-09 12:45:18
in reply to nevent1q…9npc
Author Public Key
npub1huz53hq26gu7nc0qhw3uj6tr9hk5q2ngpywduxep5zy4ay9unftsm9q4u3Published at
2023-06-09 12:45:18Event JSON
{
"id": "14baa18fc80efb50cb8e1bde0bb1c989b4ebed9439b4dac875c7da7741a12b7e",
"pubkey": "bf0548dc0ad239e9e1e0bba3c969632ded402a68091cde1b21a0895e90bc9a57",
"created_at": 1686314718,
"kind": 1,
"tags": [
[
"e",
"976944a7f9d46a909b7be1bf805da7a69458632cf9b988a18d530a47c461d44a",
"",
"root"
],
[
"e",
"40818a8477f384fe266b6f07c23f18bd56704089130c55d2bcd36db3fbaa486c",
"",
"reply"
],
[
"p",
"f0feda6ad58ea9f486e469f87b3b9996494363a26982b864667c5d8acb0542ab"
]
],
"content": "📅 Original date posted:2015-11-27\n📝 Original message:\n\u003e A also passes the original unsigned commitment to B, who verifies that\n\u003e it's in the right format (ie, can be revoked), and hashes to the hash\n\u003e that he signed.\n\nNo, if A pass the unsigned commitment to B then B can malleate the anchor.\n(because B would know the txid of the anchor at broadcast time)\nB does not have to verify it is in right format, because he does not have\nanything to loose by signing a random hash.\nB can verify he signed the hash of the first commitment after A announce\nhis already confirmed anchor.\n\n\u003e Someone other than B (ie a third party) could malleate the anchor between\n\u003e broadcast and confirmation just for their own amusement.\n\nYes, actually the only malleability vector which B can use to his advantage\nis HighS, not all BIP62 vectors.\nKnowing miners will most likely run at least 0.11.2 (if CLTV is acceepted)\nHighS should be more likely rejected.\n\n\u003e B can't reuse pubkeys between different channels with this protocol\n\u003e either, but that's good practice anyway.\n\nRight, neither A should. If A reuse a key, then B can guess the redeem\nhash, then would identify the transaction to malleate at broadcast time,\nbefore A's announcement.\n\nI'd prefer seggregated witness to fix the problem cleanly, but I think that\nopening the channel as I said is a good enough workaround until it happen.\nThe only attack B can try is malleate all transaction to HighS.\nWhen CLTV will pass, there is not lot of probability of such attack to\nsucceed, because bitcoind should block HighS.\n\n\u003e 'without timeout' is only possible with OP_CSV - not naturally\nwith what we have currently. ;)\n\nThe anchor does not have to use OP_CSV at all. But yes, for commitment, I'm\nassuming OP_CSV passed.\n\n\u003e To be able to build a valid payment channel on top of the anchor,\nB has to be sure that A cannot get her money back at any point in the\nfuture. Given just a hash that B should sign, B has no clue what is\nthe output of the transaction he just signed.\n\nActually B do not care about it. Remember I am separating \"A's anchor\nbroadcast\" from \"A's announcement of anchor to B\".\nWhen A announce the anchor, then B can check if he really signed the first\ncommitment or something else, but he can't malleate anything since the\nanchor is already confirmed.\nB does not have anything to loose by signing unknown hash. (if he use a non\nreusable key)\n\nAgain, yes, a network-wide HighS attack would be the only way to malleate\nthe anchor.\nIf CLTV fork pass, then it is fair to consider that the odd of such attack\nsucceeding is very low. HighS should be blocked from 0.11.1 if I remember\nwell.\n\n\nOn Fri, Nov 27, 2015 at 6:09 PM, Anthony Towns \u003caj at erisian.com.au\u003e wrote:\n\n\u003e On Fri, Nov 27, 2015 at 04:37:04PM +0900, Nicolas Dorier wrote:\n\u003e \u003e By adapting an idea from gmaxwell (\n\u003e \u003e https://bitcointalk.org/index.php?topic=303088.0) it is possible to\n\u003e open a\n\u003e \u003e channel without suffering from malleability attack.\n\u003e \u003e The process for A to open channel with B is the following:\n\u003e \u003e * A asks B pubkey\n\u003e \u003e * A create the first commitment transaction\n\u003e \u003e * A extract the hash that B needs to sign to be able to broadcast the\n\u003e \u003e commitment\n\u003e \u003e * A asks B to sign the hash, but do not disclose the commitment\n\u003e \u003e * A broadcast the anchor\n\u003e \u003e * After confirmation, A announce the anchor to B.\n\u003e\n\u003e A also passes the original unsigned commitment to B, who verifies that\n\u003e it's in the right format (ie, can be revoked), and hashes to the hash\n\u003e that he signed.\n\u003e\n\u003e \u003e B can't identify A's anchor before announcement because he does not know\n\u003e \u003e the P2SH of the multisig.\n\u003e \u003e Am I missing something ?\n\u003e\n\u003e Someone other than B (ie a third party) could malleate the anchor between\n\u003e broadcast and confirmation just for their own amusement.\n\u003e\n\u003e B can't reuse pubkeys between different channels with this protocol\n\u003e either, but that's good practice anyway.\n\u003e\n\u003e From the same forum post, using child-pays-for-parent seems plausible.\n\u003e Doing:\n\u003e\n\u003e txA: spend 6 BTC to\n\u003e 5 BTC to A\u0026B\n\u003e 1 BTC to A\n\u003e\n\u003e txB: spend 1 BTC from txA:1 to\n\u003e 0.999 BTC to A\n\u003e\n\u003e should be pretty safe: either someone malleates txA and mines it for\n\u003e 0 fee; or they mine both txA+txB for 0.001 BTC fee, and txA can't be\n\u003e malleated. But CPFP doesn't work yet, and segregated witness seems like\n\u003e it'll happen sooner anyway?\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/454bf694/attachment.html\u003e",
"sig": "97383175701d1fc01a1e512b1b3d84aea9eb09ebbb6f6b31c35822f3cd32d561eb606ef8af1cfd139c002ba4110dafd4d0ff1034bc894a6f7d52eba68961f3fb"
}