📅 Original date posted:2018-04-17
📝 Original message:
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,
and
broadcasts (assuming the reward output matches what was negotiated).
> 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.
There are more complex proposals discussed allowing an encrypted blob to
reference data stored in a prior encrypted blob. Primary advantage would be
reducing the storage costs of HTLCs present on multiple successive
commitment transactions; primary disadvantage is that it's significantly
more
complex, in addition to the other points brought up by Laolu.
I'm not positive as to the extent this approach was implemented/fleshed
out, or
if any other pros/cons may have been realized in the process. I haven't done
nearly as much research as Tadge on that front, he's probably got some
extensive thoughts on the tradeoffs.
=======
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
by
the number of HTLC signatures included in the encrypted blob. Due to
independence of the second stage transactions, there is a combinatoric
blowup in
the number of signatures that would need to be pre-signed under the
revocation
private 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.
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_ be
broadcast 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
commitment
HLTC outputs at that time. So, we can save on signature data by only
requiring the
watchtower to act if second stage transactions are confirmed.
One reallyyy nice thing about not having the watchtower sweep the HTLC
outputs
on the commitment txn directly is that it doesn't need to know how to
reconstruct the more complex HTLC redeem scripts. It only needs to
reconstruct
commitment 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.
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,
the
watchtower needs to sweep the HTLCs iteratively to prevent the attacker from
sweeping any of the outputs as the relative timelocks expire.
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
of
HTLCs that ever transition into the second stage, and under any permutation
wrt. ordering of confirmed second stage transactions.
With the single transaction per HTLC approach, the total number of
signatures that
are sent to the watchtower remains linear in the number HTLCs on the
commitment
transaction. 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
directly
from 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 always
resort to sweeping the outputs individually.
All in all, I think the ability to sweep each HTLC independently is
more-or-less
a 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.
TL;DR: We can get away with just sweeping the second stage outputs. Sweeping
each in a distinct txn avoids combinatoric blowup of trying to batch the
sweeps. The
storage is linear in the number of HTLC outputs, and also reduces the data
required
to reconstruct the individual redeem scripts.
Any feedback or additional insights would be greatly appreciated! Let me
know if
I've overlooked anything critical :)
Cheers,
Conner
[1] https://lists.linuxfoundation.org/pipermail/lightning-dev
/2016-August/000565.html
On Mon, Apr 16, 2018 at 11:30 PM ZmnSCPxj via Lightning-dev <
lightning-dev at lists.linuxfoundation.org> wrote:
> Good morning Laolu,
>
>
> Hi ZmnSCPxj,
>
> > It seems to me, that the only safe way to implement a trustless
> WatchTower,
> > is for the node to generate a fully-signed justice transaction,
> IMMEDIATELY
> > after every commitment transaction is revoked, and transmit it to the
> > WatchTower.
>
> No, one doesn't need to transmit the entire justice transaction. Instead,
> the client simply sends out the latest items in the script template, and a
> series of _signatures_ for the various breach outputs. The pre-generated
> signature means that the server is *forced* to reproduce the justice
> transaction that satisfies the latest template and signature. Upfront, free
> parameters such as breach bonus (or w/e else) can be negotiated.
>
>
> Thank you, I understand.
>
> As a result of these downside, our current implementation goes back to the
> ol' "encrypted blob" approach. One immediate benefit with this approach is
> that the outsourcing protocol isn't so coupled with the current _commitment
> protocol_. Instead, the internal payload can be typed, allowing the server
> to dispatch the proper breach protocol based on the commitment type. The
> blob approach can also support a "swap" protocol which is required for
> commitment designs that allow for O(1) outsourcer state per-client, like
> the
> scheme I presented at the last Scaling Bitcoin.
>
>
> Can you describe the "encrypted blob" approach to me? Or point me to
> materials?
>
> I imagine that in this case, the protected node hands a (txid, blob) pair
> to the WatchTower. If the WatchTower sees a transaction that matches the
> given txid, it gets some information from the actual transaction to decrypt
> the blob (e.g. use the encrypted commitment index in `nLockTime` and
> `nSequence` as a decryption key); the blob is the justice transaction (or
> just a template type and its signatures as you describe above).
>
> Do you have a description of the WatchTower protocol used in lnd? It may
> be useful to be intercompatible.
>
> Regards,
> ZmnSCPxj
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180417/0da51a71/attachment-0001.html>;
Conner Fromknecht [ARCHIVE] /
npub1za…uua2a
2023-06-09 12:50:08
in reply to nevent1q…tj7p
Author Public Key
npub1za0a9afyj7um5feva0d5xmhfsah3zxm252hna2duq0numa952frqvuua2aPublished at
2023-06-09 12:50:08Event JSON
{
"id": "322287a7d5fd26a8fc7acb71c800a548b4bfd569411602b0292deae9d3ab4ffa",
"pubkey": "175fd2f52497b9ba272cebdb436ee9876f111b6aa2af3ea9bc03e7cdf4b45246",
"created_at": 1686315008,
"kind": 1,
"tags": [
[
"e",
"6dd96ef1f5459831b29122e2c31121736b8e8107366862ff1c3ad1cf0ba80839",
"",
"root"
],
[
"e",
"bd16c4488a4cce2413345385911e572d1d5750d8f697f52dd71257213a1317ab",
"",
"reply"
],
[
"p",
"4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861"
]
],
"content": "📅 Original date posted:2018-04-17\n📝 Original message:\nHi ZmnSCPxj,\n\n\u003e Can you describe the \"encrypted blob\" approach to me? Or point me to\n\u003e materials?\n\nThere's an awesome watchtower thread on the mailing list from 2016 that\nstarts\nhere [1]. It covers a broader range of possibilities than just the encrypted\nblob approach, and also considers other revocation schemes, e.g. elkrem.\n\nSimilar to what you described, one encrypted blob approached discussed in\nthat thread is:\n1. hint = tixd[:16]\n2. blob = Enc(data, txid[16:])\n3. Send (hint, blob) to watchtower.\n\nWhenever a new block is mined, the watchtower checks if it has an entry for\neach\ntxid[:16]. If so, it decrypts using txid[16:], assembles the justice txn,\nand\nbroadcasts (assuming the reward output matches what was negotiated).\n\n\u003e Do you have a description of the WatchTower protocol used in lnd? It may\nbe\n\u003e useful to be intercompatible.\n\nWe don't have anything written up formally, though what we have currently\noperates on the design above.\n\nThere are more complex proposals discussed allowing an encrypted blob to\nreference data stored in a prior encrypted blob. Primary advantage would be\nreducing the storage costs of HTLCs present on multiple successive\ncommitment transactions; primary disadvantage is that it's significantly\nmore\ncomplex, in addition to the other points brought up by Laolu.\n\nI'm not positive as to the extent this approach was implemented/fleshed\nout, or\nif any other pros/cons may have been realized in the process. I haven't done\nnearly as much research as Tadge on that front, he's probably got some\nextensive thoughts on the tradeoffs.\n\n=======\n\nI'll also take this time to brain dump some recent investigations I've been\ndoing on\nwatchtowers. TL;DR @ fin.\n\nFWIW, I've been thinking about this in the context of the simple encrypted\nblob approach, though the observations can generalize to other schemes.\n\nAs Laolu mentioned, the storage requirement for the watchtower is dominated\nby\nthe number of HTLC signatures included in the encrypted blob. Due to\nindependence of the second stage transactions, there is a combinatoric\nblowup in\nthe number of signatures that would need to be pre-signed under the\nrevocation\nprivate key _if sweeping of HTLC outputs is batched_.\n\nIf we want to batch sweep without more liberal sighash flags, I think we'd\nneed to\npre-sign n*2^n signatures. There are 2^n possible ways that n HTLCs can\nstraddle\nthe first and second stages, and each permutation would require n distinct\nsignatures\nsince the set of inputs is unique to each permutation. Needless to say,\nthis isn't feasible\nwith the maximum number of HTLCs allowed in the protocol.\n\nHowever, I have some observations that might inform an efficient set of\nsignatures we can choose to include in the encrypted blobs.\n\nThe first is that the HTLC timeout or HTLC success transaction _must_ be\nbroadcast before the attacker can move funds back into their wallet. If\nthese transactions are never mined, it is actually fine to do nothing and\nleave\nthose outputs in the breached state.\n\nIf/when the victim comes back online, they themselves can sign and broadcast\na justice transaction that executes the revocation clause of either the\noffered or\nreceived HTLC scripts, based on the observed spentness of the various\ncommitment\nHLTC outputs at that time. So, we can save on signature data by only\nrequiring the\nwatchtower to act if second stage transactions are confirmed.\n\nOne reallyyy nice thing about not having the watchtower sweep the HTLC\n outputs\non the commitment txn directly is that it doesn't need to know how to\nreconstruct the more complex HTLC redeem scripts. It only needs to\nreconstruct\ncommitment to-local and second-stage to-local scripts and witnesses. This\nmeans\nthe blob primarily contains:\n - 1 revocation pubkey\n - 1 local delay pubkey\n - 1 CSV delay\n - 2 commitment signatures\n - n HTLC signatures\nand we don't have to bother sending CLTVs, local/remote htlc pubkeys, or\npayment hashes at all.\n\nThe storage for this ends up being something like ~100 + 64*(2+nhtlcs) when\nyou\ninclude other things like the sweep address.\n\nThe second observation is that the second stage transactions could be\nbroadcast\nsequentially such that the CSV delays don't overlap at all. In this event,\nthe\nwatchtower needs to sweep the HTLCs iteratively to prevent the attacker from\nsweeping any of the outputs as the relative timelocks expire.\n\nOne minimal solution could be to send signatures for independent sweep\ntransactions, allowing the watchtower to sweep each HTLC output\nindividually.\nThis is nice because it permits the watchtower to sweep exactly the subset\nof\nHTLCs that ever transition into the second stage, and under any permutation\nwrt. ordering of confirmed second stage transactions.\n\nWith the single transaction per HTLC approach, the total number of\nsignatures that\nare sent to the watchtower remains linear in the number HTLCs on the\ncommitment\ntransaction. This approach does have the downside of consuming slightly more\nfees, since each output is swept with a distinct transaction.\n\nHowever, this approach is fairly efficient in preventing the attacker\nentirely from\nmoving funds from the channel into their wallet wrt. to the amount of data\nstored.\nConsidering that the majority of the channel balance is expected to be in\nthe commitment outputs and that hypothetically on-chains fees are offset by\nthe\nremote balance, this could be an acceptable tradeoff.\n\nI suspect that in practice, most second stage transactions will be valid by\nthe\ntime an attacker would drop to chain. Because of this, it's possible that\nthey\ncould be mined in the same block as the breach transaction.\n\nIf everything is mined in the same block or in quick succession, it might be\nworthwhile to also pre-sign a justice txn that batch sweeps all HTLCs\ndirectly\nfrom the second layer, requiring one additional signature/HTLC.\n\nThis could be a plausible scenario if the offender breached\nunintentionally, and\ntheir implementation tries to proceed normally. However it does require all\nof the\nCSV delays to conincide. If that doesn't happen, the watchtower can always\nresort to sweeping the outputs individually.\n\nAll in all, I think the ability to sweep each HTLC independently is\nmore-or-less\na requirement just given the complexity of how the on-chain state-space can\nmanifest, especially if CLTVs have already expired. Other scenarios may\nbe worth including on a case by case basis or if we feel they are\njustified. This\ncould be handled dynamically by including some bitvector or some compact\nrepresentation of how to reconstruct the transactions for any additional,\nincluded\nsignatures.\n\nTL;DR: We can get away with just sweeping the second stage outputs. Sweeping\neach in a distinct txn avoids combinatoric blowup of trying to batch the\nsweeps. The\nstorage is linear in the number of HTLC outputs, and also reduces the data\nrequired\nto reconstruct the individual redeem scripts.\n\nAny feedback or additional insights would be greatly appreciated! Let me\nknow if\nI've overlooked anything critical :)\n\nCheers,\nConner\n\n[1] https://lists.linuxfoundation.org/pipermail/lightning-dev\n/2016-August/000565.html\n\n\nOn Mon, Apr 16, 2018 at 11:30 PM ZmnSCPxj via Lightning-dev \u003c\nlightning-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e Good morning Laolu,\n\u003e\n\u003e\n\u003e Hi ZmnSCPxj,\n\u003e\n\u003e \u003e It seems to me, that the only safe way to implement a trustless\n\u003e WatchTower,\n\u003e \u003e is for the node to generate a fully-signed justice transaction,\n\u003e IMMEDIATELY\n\u003e \u003e after every commitment transaction is revoked, and transmit it to the\n\u003e \u003e WatchTower.\n\u003e\n\u003e No, one doesn't need to transmit the entire justice transaction. Instead,\n\u003e the client simply sends out the latest items in the script template, and a\n\u003e series of _signatures_ for the various breach outputs. The pre-generated\n\u003e signature means that the server is *forced* to reproduce the justice\n\u003e transaction that satisfies the latest template and signature. Upfront, free\n\u003e parameters such as breach bonus (or w/e else) can be negotiated.\n\u003e\n\u003e\n\u003e Thank you, I understand.\n\u003e\n\u003e As a result of these downside, our current implementation goes back to the\n\u003e ol' \"encrypted blob\" approach. One immediate benefit with this approach is\n\u003e that the outsourcing protocol isn't so coupled with the current _commitment\n\u003e protocol_. Instead, the internal payload can be typed, allowing the server\n\u003e to dispatch the proper breach protocol based on the commitment type. The\n\u003e blob approach can also support a \"swap\" protocol which is required for\n\u003e commitment designs that allow for O(1) outsourcer state per-client, like\n\u003e the\n\u003e scheme I presented at the last Scaling Bitcoin.\n\u003e\n\u003e\n\u003e Can you describe the \"encrypted blob\" approach to me? Or point me to\n\u003e materials?\n\u003e\n\u003e I imagine that in this case, the protected node hands a (txid, blob) pair\n\u003e to the WatchTower. If the WatchTower sees a transaction that matches the\n\u003e given txid, it gets some information from the actual transaction to decrypt\n\u003e the blob (e.g. use the encrypted commitment index in `nLockTime` and\n\u003e `nSequence` as a decryption key); the blob is the justice transaction (or\n\u003e just a template type and its signatures as you describe above).\n\u003e\n\u003e Do you have a description of the WatchTower protocol used in lnd? It may\n\u003e be useful to be intercompatible.\n\u003e\n\u003e Regards,\n\u003e ZmnSCPxj\n\u003e _______________________________________________\n\u003e Lightning-dev mailing list\n\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180417/0da51a71/attachment-0001.html\u003e",
"sig": "6034f40112724d15a9f016c5cab3a07ef2e640d20179d3e8210b34ae64961fcaaba69213007d8bbf2d94ee3ced0bb0e1997e3762b10e333a4adca51048855372"
}