📅 Original date posted:2018-11-13
📝 Original message:
Quick correction:
> Thus, the cost to perform the attack would be many orders of
> magnitude greater than the cost to back up one channel.
This was written assuming the attacker was trying to upload multiple encrypted
blobs for the same txid, which seems like an unlikely attack vector if the tower
inherently defends against it. If instead they are just trying to fill
up the tower, the cost
is linear in the amount of blobs they send.
--Conner
On Tue, Nov 13, 2018 at 4:12 PM Conner Fromknecht
<conner at lightning.engineering> wrote:
>
> Hi ZmnSCPxj,
>
> I haven't yet gotten around to writing up everything documenting in the working
> watchtower design. However, I think we are nearing that phase where things seem
> mostly solidified and would welcome feedback before attempting to formalize it.
> Expect some follow up posts on the ML :)
>
> > From my bare knowledge of go, it seems data structures and messages so far,
> > without actual logic, but please inform me if I am incorrect.
>
> Much of the server side has been implemented, which accepts encrypted blobs from
> watchtower clients and stores them. The functionality related to scanning blocks
> and publishing justice txns has also been implemented, but has not been merged
> yet. The big remaining task is to integrate the client such that it properly
> backs up states after receiving revocations from the remote peer.
>
> > Note however that watchtowers would require to keep all encrypted blobs that
> > are keyed to the same partial txid. I.e. watchtowers need to store the pair
> > in a set with the set looking at the entire txid+blob as the identity of the
> > object. Otherwise it would be possible, if your watchtower is identified by
> > your counterparty, for the counterparty to give the commitment transaction's
> > txid with a randomly-generated blob to your watchtower before it gives the
> > revocation key to you.
> >
> > I have described the above problem before here:
> > https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-April/001203.html
> > with an unsatisfactory solution.
>
> Indeed, this was great observation! The tower can't be sure which client is
> uploading the "real" blob either. In light of that, the chosen design uses a
> two level bucketing structure that maps:
>
> <txid[:16]> -> client_pubkey1 : encrypted_blob1
> -> client_pubkey2 : encrypted_blob2
>
> ensuring that different client's can't overwrite each other. Further, the tower
> will only store one blob for a given txid per client. Upon decryption, the tower
> would learn that only one of this a valid update (and possibly delete state for
> the offender).
>
> > However, this remains your counterparty best avenue of attack, is to simply
> > spam your watchtower until it runs out of resources and crashes.
>
> The client pubkeys described above are tied to what we've been referring to as a
> session. In order for a client to facilitate the attack described above, they
> would have to pay the tower for multiple sessions tied to different ephemeral
> session keys.
>
> A session grants the client the ability to store up to N blobs, where N would be
> several thousand. Thus, the cost to perform the attack would be many orders of
> magnitude greater than the cost to back up one channel. In the private tower
> case, there isn't necessarily payment, though it's more or less assumed that one
> wouldn't DOS their own tower.
>
> In practice, the tower should only ever accept sessions if it can be certain it
> has the appropriate disk-space to facilitate them, so I don't think
> there is much
> risk in the node crashing due to this. Someone could still pay to fill
> up my tower,
> but the tower would be compensated appropriately. The tower could also raise
> it's price point if it detects such behavior.
>
> > And if the watchtower identifies the user, then this leaks the privacy of the
> > user to the watchtower, and what would then be the point of encrypted blob?
>
> I believe the same session-based, encrypted-blob approach would work eltoo
> towers as well, if the concern is primarily about the channel partner presuming
> the valid blob. The general design should be readily able to serve
> eltoo clients,
> with some slight modifications to breach detection and justice txn construction.
>
> My greater concern with the update-and-replace model is that it leaks timing
> information about a particular channel to the tower, since the tower must know
> which prior state needs replacing. So even though it is possible to make eltoo
> towers constant-space per channel, IMO we're better off storing all prior
> encrypted blobs to maintain adequate privacy. On private towers, perhaps this
> privacy/space tradeoff may acceptable, but not sure if the tradeoff makes sense
> on public towers.
>
> Cheers,
> Conner
>
> On Mon, Nov 12, 2018 at 1:18 AM ZmnSCPxj via Lightning-dev
> <lightning-dev at lists.linuxfoundation.org> wrote:
> >
> > Good morning list,
> >
> > We were not able to discuss this topic much at recent summit, but I noticed that lnd has some code related to watchtowers already. From my bare knowledge of go, it seems data structures and messages so far, without actual logic, but please inform me if I am incorrect.
> >
> > I assume much of the watchtowers code and design in lnd is by Conner, simply because, he discussed this on this list earlier this year.
> >
> > I have seen recently, some paper about paying watchtowers by actually simulating breaches. You would give a watchtower some txid+blob pair, then send that txid and see if the watchtower claims it. If it does, then you have evidence of liveness and correct behavior, and have also paid for and incentivized the watchtower to operate correctly.
> >
> > Note however that watchtowers would require to keep all encrypted blobs that are keyed to the same partial txid. I.e. watchtowers need to store the pair in a set with the set looking at the entire txid+blob as the identity of the object. Otherwise it would be possible, if your watchtower is identified by your counterparty, for the counterparty to give the commitment transaction's txid with a randomly-generated blob to your watchtower before it gives the revocation key to you. However, this remains your counterparty best avenue of attack, is to simply spam your watchtower until it runs out of resources and crashes.
> >
> > I have described the above problem before here: https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-April/001203.html with an unsatisfactory solution.
> >
> > --
> >
> > I have also been thinking about watchtowers compatible with Decker-Russell-Osuntokun channels.
> >
> > As I understand, in a separate thread, laolu is promoting that Decker-Russell-Osuntokun channels can simply "update" the blob side of a txid-blob entry, with the txid being the kickoff/trigger transaction. As I point out, unless the watchtower identifies the user somehow, this is unsafe; if I can identify your watchtower, then after you update it but before I attack, I can "update" the blob side with a randomly-generated, invalid blob. And if the watchtower identifies the user, then this leaks the privacy of the user to the watchtower, and what would then be the point of encrypted blob? https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-May/001264.html
> >
> > I am curious what Conner and the other lnd developers are planning for these issues? You seem to be the first movers into this, and I cannot read go well enough to decipher what plans you have.
> >
> > Regards,
> > ZmnSCPxj
> >
> >
> >
> > _______________________________________________
> > Lightning-dev mailing list
> > Lightning-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Conner Fromknecht [ARCHIVE] /
npub1za…uua2a
2023-06-09 12:52:32
in reply to nevent1q…nxa0
Author Public Key
npub1za0a9afyj7um5feva0d5xmhfsah3zxm252hna2duq0numa952frqvuua2aPublished at
2023-06-09 12:52:32Event JSON
{
"id": "da694f00d54e7f1607fc878751816ad7c3755ab5595925a1be638b88be03e3ac",
"pubkey": "175fd2f52497b9ba272cebdb436ee9876f111b6aa2af3ea9bc03e7cdf4b45246",
"created_at": 1686315152,
"kind": 1,
"tags": [
[
"e",
"846617d090eb97eb8cd109187c6c8202aa915ade69abe415ac73d62722a28f4a",
"",
"root"
],
[
"e",
"c87f28dfe107ed559a71e4feb466a27bfe4d2dd8c4ee372da4e5f011ce2895dd",
"",
"reply"
],
[
"p",
"175fd2f52497b9ba272cebdb436ee9876f111b6aa2af3ea9bc03e7cdf4b45246"
]
],
"content": "📅 Original date posted:2018-11-13\n📝 Original message:\nQuick correction:\n\n\u003e Thus, the cost to perform the attack would be many orders of\n\u003e magnitude greater than the cost to back up one channel.\n\nThis was written assuming the attacker was trying to upload multiple encrypted\nblobs for the same txid, which seems like an unlikely attack vector if the tower\ninherently defends against it. If instead they are just trying to fill\nup the tower, the cost\nis linear in the amount of blobs they send.\n\n--Conner\nOn Tue, Nov 13, 2018 at 4:12 PM Conner Fromknecht\n\u003cconner at lightning.engineering\u003e wrote:\n\u003e\n\u003e Hi ZmnSCPxj,\n\u003e\n\u003e I haven't yet gotten around to writing up everything documenting in the working\n\u003e watchtower design. However, I think we are nearing that phase where things seem\n\u003e mostly solidified and would welcome feedback before attempting to formalize it.\n\u003e Expect some follow up posts on the ML :)\n\u003e\n\u003e \u003e From my bare knowledge of go, it seems data structures and messages so far,\n\u003e \u003e without actual logic, but please inform me if I am incorrect.\n\u003e\n\u003e Much of the server side has been implemented, which accepts encrypted blobs from\n\u003e watchtower clients and stores them. The functionality related to scanning blocks\n\u003e and publishing justice txns has also been implemented, but has not been merged\n\u003e yet. The big remaining task is to integrate the client such that it properly\n\u003e backs up states after receiving revocations from the remote peer.\n\u003e\n\u003e \u003e Note however that watchtowers would require to keep all encrypted blobs that\n\u003e \u003e are keyed to the same partial txid. I.e. watchtowers need to store the pair\n\u003e \u003e in a set with the set looking at the entire txid+blob as the identity of the\n\u003e \u003e object. Otherwise it would be possible, if your watchtower is identified by\n\u003e \u003e your counterparty, for the counterparty to give the commitment transaction's\n\u003e \u003e txid with a randomly-generated blob to your watchtower before it gives the\n\u003e \u003e revocation key to you.\n\u003e \u003e\n\u003e \u003e I have described the above problem before here:\n\u003e \u003e https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-April/001203.html\n\u003e \u003e with an unsatisfactory solution.\n\u003e\n\u003e Indeed, this was great observation! The tower can't be sure which client is\n\u003e uploading the \"real\" blob either. In light of that, the chosen design uses a\n\u003e two level bucketing structure that maps:\n\u003e\n\u003e \u003ctxid[:16]\u003e -\u003e client_pubkey1 : encrypted_blob1\n\u003e -\u003e client_pubkey2 : encrypted_blob2\n\u003e\n\u003e ensuring that different client's can't overwrite each other. Further, the tower\n\u003e will only store one blob for a given txid per client. Upon decryption, the tower\n\u003e would learn that only one of this a valid update (and possibly delete state for\n\u003e the offender).\n\u003e\n\u003e \u003e However, this remains your counterparty best avenue of attack, is to simply\n\u003e \u003e spam your watchtower until it runs out of resources and crashes.\n\u003e\n\u003e The client pubkeys described above are tied to what we've been referring to as a\n\u003e session. In order for a client to facilitate the attack described above, they\n\u003e would have to pay the tower for multiple sessions tied to different ephemeral\n\u003e session keys.\n\u003e\n\u003e A session grants the client the ability to store up to N blobs, where N would be\n\u003e several thousand. Thus, the cost to perform the attack would be many orders of\n\u003e magnitude greater than the cost to back up one channel. In the private tower\n\u003e case, there isn't necessarily payment, though it's more or less assumed that one\n\u003e wouldn't DOS their own tower.\n\u003e\n\u003e In practice, the tower should only ever accept sessions if it can be certain it\n\u003e has the appropriate disk-space to facilitate them, so I don't think\n\u003e there is much\n\u003e risk in the node crashing due to this. Someone could still pay to fill\n\u003e up my tower,\n\u003e but the tower would be compensated appropriately. The tower could also raise\n\u003e it's price point if it detects such behavior.\n\u003e\n\u003e \u003e And if the watchtower identifies the user, then this leaks the privacy of the\n\u003e \u003e user to the watchtower, and what would then be the point of encrypted blob?\n\u003e\n\u003e I believe the same session-based, encrypted-blob approach would work eltoo\n\u003e towers as well, if the concern is primarily about the channel partner presuming\n\u003e the valid blob. The general design should be readily able to serve\n\u003e eltoo clients,\n\u003e with some slight modifications to breach detection and justice txn construction.\n\u003e\n\u003e My greater concern with the update-and-replace model is that it leaks timing\n\u003e information about a particular channel to the tower, since the tower must know\n\u003e which prior state needs replacing. So even though it is possible to make eltoo\n\u003e towers constant-space per channel, IMO we're better off storing all prior\n\u003e encrypted blobs to maintain adequate privacy. On private towers, perhaps this\n\u003e privacy/space tradeoff may acceptable, but not sure if the tradeoff makes sense\n\u003e on public towers.\n\u003e\n\u003e Cheers,\n\u003e Conner\n\u003e\n\u003e On Mon, Nov 12, 2018 at 1:18 AM ZmnSCPxj via Lightning-dev\n\u003e \u003clightning-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e \u003e\n\u003e \u003e Good morning list,\n\u003e \u003e\n\u003e \u003e We were not able to discuss this topic much at recent summit, but I noticed that lnd has some code related to watchtowers already. From my bare knowledge of go, it seems data structures and messages so far, without actual logic, but please inform me if I am incorrect.\n\u003e \u003e\n\u003e \u003e I assume much of the watchtowers code and design in lnd is by Conner, simply because, he discussed this on this list earlier this year.\n\u003e \u003e\n\u003e \u003e I have seen recently, some paper about paying watchtowers by actually simulating breaches. You would give a watchtower some txid+blob pair, then send that txid and see if the watchtower claims it. If it does, then you have evidence of liveness and correct behavior, and have also paid for and incentivized the watchtower to operate correctly.\n\u003e \u003e\n\u003e \u003e Note however that watchtowers would require to keep all encrypted blobs that are keyed to the same partial txid. I.e. watchtowers need to store the pair in a set with the set looking at the entire txid+blob as the identity of the object. Otherwise it would be possible, if your watchtower is identified by your counterparty, for the counterparty to give the commitment transaction's txid with a randomly-generated blob to your watchtower before it gives the revocation key to you. However, this remains your counterparty best avenue of attack, is to simply spam your watchtower until it runs out of resources and crashes.\n\u003e \u003e\n\u003e \u003e I have described the above problem before here: https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-April/001203.html with an unsatisfactory solution.\n\u003e \u003e\n\u003e \u003e --\n\u003e \u003e\n\u003e \u003e I have also been thinking about watchtowers compatible with Decker-Russell-Osuntokun channels.\n\u003e \u003e\n\u003e \u003e As I understand, in a separate thread, laolu is promoting that Decker-Russell-Osuntokun channels can simply \"update\" the blob side of a txid-blob entry, with the txid being the kickoff/trigger transaction. As I point out, unless the watchtower identifies the user somehow, this is unsafe; if I can identify your watchtower, then after you update it but before I attack, I can \"update\" the blob side with a randomly-generated, invalid blob. And if the watchtower identifies the user, then this leaks the privacy of the user to the watchtower, and what would then be the point of encrypted blob? https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-May/001264.html\n\u003e \u003e\n\u003e \u003e I am curious what Conner and the other lnd developers are planning for these issues? You seem to be the first movers into this, and I cannot read go well enough to decipher what plans you have.\n\u003e \u003e\n\u003e \u003e Regards,\n\u003e \u003e ZmnSCPxj\n\u003e \u003e\n\u003e \u003e\n\u003e \u003e\n\u003e \u003e _______________________________________________\n\u003e \u003e Lightning-dev mailing list\n\u003e \u003e Lightning-dev at lists.linuxfoundation.org\n\u003e \u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev",
"sig": "b461560d90362d5023d3d42c2a60e7ba1564e0fd1c00af274f00c31c262e79190fa9a1e76a2e06dc7b9f68540f572ed0f091fb5f9712fa1b242406c4c17480d6"
}