📅 Original date posted:2018-04-17
📝 Original message:
Good morning Conner,
> Hi ZmnSCPxj,
>
>> Can you describe the "encrypted blob" approach to me? Or point me to
>> materials?
>
> There's an awesome watchtower thread on the mailing list from 2016 that starts
> here [1]. It covers a broader range of possibilities than just the encrypted
> blob approach, and also considers other revocation schemes, e.g. elkrem.
>
> Similar to what you described, one encrypted blob approached discussed in
> that thread is:1. hint = tixd[:16]2. blob = Enc(data, txid[16:])3. Send (hint, blob) to watchtower.
>
> Whenever a new block is mined, the watchtower checks if it has an entry for each
> txid[:16]. If so, it decrypts using txid[16:], assembles the justice txn, andbroadcasts (assuming the reward output matches what was negotiated).
Thank you, that is indeed similar to what I was thinking given the name "encrypted blob".
Also, thank you for the link. I have not had much time to back-read anything older than 2017 in the archives. I observe that neither Poon nor Dryja seem to strongly participate in this list from 2017 onwards.
>> Do you have a description of the WatchTower protocol used in lnd? It may be> useful to be intercompatible.
> We don't have anything written up formally, though what we have currently
> operates on the design above.
I understand. It would be good to know what you have, and perhaps consider planning a new BOLT document for such.
Nicolas Dorier mentioned plans for BTCPay to somehow host "merchant support networks" where merchants may expose WatchTower endpoints, which other merchants may post revocation information for their channels to.
> I'll also take this time to brain dump some recent investigations I've been doing on
>
> watchtowers. TL;DR @ fin.
>
> FWIW, I've been thinking about this in the context of the simple encrypted
> blob approach, though the observations can generalize to other schemes.
>
> As Laolu mentioned, the storage requirement for the watchtower is dominated bythe number of HTLC signatures included in the encrypted blob. Due toindependence of the second stage transactions, there is a combinatoric blowup inthe number of signatures that would need to be pre-signed under the revocationprivate key _if sweeping of HTLC outputs is batched_.
>
> If we want to batch sweep without more liberal sighash flags, I think we'd need to
> pre-sign n*2^n signatures. There are 2^n possible ways that n HTLCs can straddle
> the first and second stages, and each permutation would require n distinct signatures
> since the set of inputs is unique to each permutation. Needless to say, this isn't feasible
> with the maximum number of HTLCs allowed in the protocol.
Yes, I thought this too.
> However, I have some observations that might inform an efficient set of
> signatures we can choose to include in the encrypted blobs.
>
> The first is that the HTLC timeout or HTLC success transaction _must_ bebroadcast before the attacker can move funds back into their wallet. If
> these transactions are never mined, it is actually fine to do nothing and leave
> those outputs in the breached state.
>
> If/when the victim comes back online, they themselves can sign and broadcast
> a justice transaction that executes the revocation clause of either the offered or
> received HTLC scripts, based on the observed spentness of the various commitmentHLTC outputs at that time. So, we can save on signature data by only requiring thewatchtower to act if second stage transactions are confirmed.
This is a good observation! I initially thought that we would have to provide both the first-stage and second-stage revocation signatures.
> One reallyyy nice thing about not having the watchtower sweep the HTLC outputson the commitment txn directly is that it doesn't need to know how toreconstruct the more complex HTLC redeem scripts. It only needs to reconstructcommitment to-local and second-stage to-local scripts and witnesses. This means
> the blob primarily contains:
> - 1 revocation pubkey
> - 1 local delay pubkey
> - 1 CSV delay
> - 2 commitment signatures - n HTLC signatures
> and we don't have to bother sending CLTVs, local/remote htlc pubkeys, or payment hashes at all.
>
> The storage for this ends up being something like ~100 + 64*(2+nhtlcs) when you
> include other things like the sweep address.
Thank you, that seems like a start at something that can be implemented.
> The second observation is that the second stage transactions could be broadcast
> sequentially such that the CSV delays don't overlap at all. In this event, thewatchtower needs to sweep the HTLCs iteratively to prevent the attacker from
> sweeping any of the outputs as the relative timelocks expire.
Sorry, I seem confused this idea. Can you give example for commitment with 2x HTLC?
> One minimal solution could be to send signatures for independent sweep
> transactions, allowing the watchtower to sweep each HTLC output individually.
> This is nice because it permits the watchtower to sweep exactly the subset ofHTLCs that ever transition into the second stage, and under any permutationwrt. ordering of confirmed second stage transactions.
Yes, this seems like a good general idea.
> With the single transaction per HTLC approach, the total number of signatures thatare sent to the watchtower remains linear in the number HTLCs on the commitmenttransaction. This approach does have the downside of consuming slightly more
> fees, since each output is swept with a distinct transaction.
>
> However, this approach is fairly efficient in preventing the attacker entirely from
> moving funds from the channel into their wallet wrt. to the amount of data stored.
> Considering that the majority of the channel balance is expected to be in
> the commitment outputs and that hypothetically on-chains fees are offset by the
> remote balance, this could be an acceptable tradeoff.
>
> I suspect that in practice, most second stage transactions will be valid by the time an attacker would drop to chain. Because of this, it's possible that they
> could be mined in the same block as the breach transaction.
>
> If everything is mined in the same block or in quick succession, it might be
> worthwhile to also pre-sign a justice txn that batch sweeps all HTLCs directlyfrom the second layer, requiring one additional signature/HTLC.
> This could be a plausible scenario if the offender breached unintentionally, and their implementation tries to proceed normally. However it does require all of the
> CSV delays to conincide. If that doesn't happen, the watchtower can alwaysresort to sweeping the outputs individually.
>
> All in all, I think the ability to sweep each HTLC independently is more-or-lessa requirement just given the complexity of how the on-chain state-space can manifest, especially if CLTVs have already expired. Other scenarios may
> be worth including on a case by case basis or if we feel they are justified. This
> could be handled dynamically by including some bitvector or some compact
> representation of how to reconstruct the transactions for any additional, included
> signatures.
Okay. So it seems, the blob contains:
1. Revocation pubkey (from our revocation basepoint and per-commitment basepoint)
2. Their delayed payment pubkey (needed in scripts)
3. Our imposed to_self_delay (the setting we indicate, that we impose on the remote side)
4. Our payment pubkey
5. 0 or 1 or 2 signatures for the main outputs. These sign a single transaction that claims only the main outputs.
6. 0 or more second-stage HTLC revocation signatures. These sign individual transactions (one per HTLC) that claims only the second-stage HTLC output.
7. scriptpubkey to put all the funds in.
When the commitment txid is found onchain, the WatchTower creates a single main output claim transaction using the 1 or 2 signatures for the main outputs. And for each HTLC outpoint on the commitment transaction, if it gets spent, the WatchTower creates one HTLC justice transaction from the second-stage HTLC transaction.
Is that approximately what is needed? Have I missed anything?
Regards,
ZmnSCPxj
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180417/441f5a17/attachment-0001.html>;
ZmnSCPxj [ARCHIVE] /
npub1g5…3ms3l
2023-06-09 12:50:09
in reply to nevent1q…ueu5
Author Public Key
npub1g5zswf6y48f7fy90jf3tlcuwdmjn8znhzaa4vkmtxaeskca8hpss23ms3lPublished at
2023-06-09 12:50:09Event JSON
{
"id": "56fbd1bff85e2851e5b3ba623835e37a5f07138cd2e4137d585d9d2efcdd00c0",
"pubkey": "4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861",
"created_at": 1686315009,
"kind": 1,
"tags": [
[
"e",
"6dd96ef1f5459831b29122e2c31121736b8e8107366862ff1c3ad1cf0ba80839",
"",
"root"
],
[
"e",
"322287a7d5fd26a8fc7acb71c800a548b4bfd569411602b0292deae9d3ab4ffa",
"",
"reply"
],
[
"p",
"175fd2f52497b9ba272cebdb436ee9876f111b6aa2af3ea9bc03e7cdf4b45246"
]
],
"content": "📅 Original date posted:2018-04-17\n📝 Original message:\nGood morning Conner,\n\n\u003e Hi ZmnSCPxj,\n\u003e\n\u003e\u003e Can you describe the \"encrypted blob\" approach to me? Or point me to\n\u003e\u003e materials?\n\u003e\n\u003e There's an awesome watchtower thread on the mailing list from 2016 that starts\n\u003e here [1]. It covers a broader range of possibilities than just the encrypted\n\u003e blob approach, and also considers other revocation schemes, e.g. elkrem.\n\u003e\n\u003e Similar to what you described, one encrypted blob approached discussed in\n\u003e that thread is:1. hint = tixd[:16]2. blob = Enc(data, txid[16:])3. Send (hint, blob) to watchtower.\n\u003e\n\u003e Whenever a new block is mined, the watchtower checks if it has an entry for each\n\u003e txid[:16]. If so, it decrypts using txid[16:], assembles the justice txn, andbroadcasts (assuming the reward output matches what was negotiated).\n\nThank you, that is indeed similar to what I was thinking given the name \"encrypted blob\".\n\nAlso, thank you for the link. I have not had much time to back-read anything older than 2017 in the archives. I observe that neither Poon nor Dryja seem to strongly participate in this list from 2017 onwards.\n\n\u003e\u003e Do you have a description of the WatchTower protocol used in lnd? It may be\u003e useful to be intercompatible.\n\u003e We don't have anything written up formally, though what we have currently\n\u003e operates on the design above.\n\nI understand. It would be good to know what you have, and perhaps consider planning a new BOLT document for such.\n\nNicolas Dorier mentioned plans for BTCPay to somehow host \"merchant support networks\" where merchants may expose WatchTower endpoints, which other merchants may post revocation information for their channels to.\n\n\u003e I'll also take this time to brain dump some recent investigations I've been doing on\n\u003e\n\u003e watchtowers. TL;DR @ fin.\n\u003e\n\u003e FWIW, I've been thinking about this in the context of the simple encrypted\n\u003e blob approach, though the observations can generalize to other schemes.\n\u003e\n\u003e As Laolu mentioned, the storage requirement for the watchtower is dominated bythe number of HTLC signatures included in the encrypted blob. Due toindependence of the second stage transactions, there is a combinatoric blowup inthe number of signatures that would need to be pre-signed under the revocationprivate key _if sweeping of HTLC outputs is batched_.\n\u003e\n\u003e If we want to batch sweep without more liberal sighash flags, I think we'd need to\n\u003e pre-sign n*2^n signatures. There are 2^n possible ways that n HTLCs can straddle\n\u003e the first and second stages, and each permutation would require n distinct signatures\n\u003e since the set of inputs is unique to each permutation. Needless to say, this isn't feasible\n\u003e with the maximum number of HTLCs allowed in the protocol.\n\nYes, I thought this too.\n\n\u003e However, I have some observations that might inform an efficient set of\n\u003e signatures we can choose to include in the encrypted blobs.\n\u003e\n\u003e The first is that the HTLC timeout or HTLC success transaction _must_ bebroadcast before the attacker can move funds back into their wallet. If\n\u003e these transactions are never mined, it is actually fine to do nothing and leave\n\u003e those outputs in the breached state.\n\u003e\n\u003e If/when the victim comes back online, they themselves can sign and broadcast\n\u003e a justice transaction that executes the revocation clause of either the offered or\n\u003e received HTLC scripts, based on the observed spentness of the various commitmentHLTC outputs at that time. So, we can save on signature data by only requiring thewatchtower to act if second stage transactions are confirmed.\n\nThis is a good observation! I initially thought that we would have to provide both the first-stage and second-stage revocation signatures.\n\n\u003e One reallyyy nice thing about not having the watchtower sweep the HTLC outputson the commitment txn directly is that it doesn't need to know how toreconstruct the more complex HTLC redeem scripts. It only needs to reconstructcommitment to-local and second-stage to-local scripts and witnesses. This means\n\u003e the blob primarily contains:\n\u003e - 1 revocation pubkey\n\u003e - 1 local delay pubkey\n\u003e - 1 CSV delay\n\u003e - 2 commitment signatures - n HTLC signatures\n\u003e and we don't have to bother sending CLTVs, local/remote htlc pubkeys, or payment hashes at all.\n\u003e\n\u003e The storage for this ends up being something like ~100 + 64*(2+nhtlcs) when you\n\u003e include other things like the sweep address.\n\nThank you, that seems like a start at something that can be implemented.\n\n\u003e The second observation is that the second stage transactions could be broadcast\n\u003e sequentially such that the CSV delays don't overlap at all. In this event, thewatchtower needs to sweep the HTLCs iteratively to prevent the attacker from\n\u003e sweeping any of the outputs as the relative timelocks expire.\n\nSorry, I seem confused this idea. Can you give example for commitment with 2x HTLC?\n\n\u003e One minimal solution could be to send signatures for independent sweep\n\u003e transactions, allowing the watchtower to sweep each HTLC output individually.\n\u003e This is nice because it permits the watchtower to sweep exactly the subset ofHTLCs that ever transition into the second stage, and under any permutationwrt. ordering of confirmed second stage transactions.\n\nYes, this seems like a good general idea.\n\n\u003e With the single transaction per HTLC approach, the total number of signatures thatare sent to the watchtower remains linear in the number HTLCs on the commitmenttransaction. This approach does have the downside of consuming slightly more\n\u003e fees, since each output is swept with a distinct transaction.\n\u003e\n\u003e However, this approach is fairly efficient in preventing the attacker entirely from\n\u003e moving funds from the channel into their wallet wrt. to the amount of data stored.\n\u003e Considering that the majority of the channel balance is expected to be in\n\u003e the commitment outputs and that hypothetically on-chains fees are offset by the\n\u003e remote balance, this could be an acceptable tradeoff.\n\u003e\n\u003e I suspect that in practice, most second stage transactions will be valid by the time an attacker would drop to chain. Because of this, it's possible that they\n\u003e could be mined in the same block as the breach transaction.\n\u003e\n\u003e If everything is mined in the same block or in quick succession, it might be\n\u003e worthwhile to also pre-sign a justice txn that batch sweeps all HTLCs directlyfrom the second layer, requiring one additional signature/HTLC.\n\u003e This could be a plausible scenario if the offender breached unintentionally, and their implementation tries to proceed normally. However it does require all of the\n\u003e CSV delays to conincide. If that doesn't happen, the watchtower can alwaysresort to sweeping the outputs individually.\n\u003e\n\u003e All in all, I think the ability to sweep each HTLC independently is more-or-lessa requirement just given the complexity of how the on-chain state-space can manifest, especially if CLTVs have already expired. Other scenarios may\n\u003e be worth including on a case by case basis or if we feel they are justified. This\n\u003e could be handled dynamically by including some bitvector or some compact\n\u003e representation of how to reconstruct the transactions for any additional, included\n\u003e signatures.\n\nOkay. So it seems, the blob contains:\n\n1. Revocation pubkey (from our revocation basepoint and per-commitment basepoint)\n2. Their delayed payment pubkey (needed in scripts)\n3. Our imposed to_self_delay (the setting we indicate, that we impose on the remote side)\n4. Our payment pubkey\n5. 0 or 1 or 2 signatures for the main outputs. These sign a single transaction that claims only the main outputs.\n6. 0 or more second-stage HTLC revocation signatures. These sign individual transactions (one per HTLC) that claims only the second-stage HTLC output.\n7. scriptpubkey to put all the funds in.\n\nWhen the commitment txid is found onchain, the WatchTower creates a single main output claim transaction using the 1 or 2 signatures for the main outputs. And for each HTLC outpoint on the commitment transaction, if it gets spent, the WatchTower creates one HTLC justice transaction from the second-stage HTLC transaction.\n\nIs that approximately what is needed? Have I missed anything?\n\nRegards,\nZmnSCPxj\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180417/441f5a17/attachment-0001.html\u003e",
"sig": "feca91ca5fd00e3c9ebded7cc0805fbf0e9df8554bdf185ac6a47a87f8867bdd098f3f21ad6cf2e3c2fc34e07dbf56539355ba98aecf5a78e9c880c693aeba5e"
}