Christian Decker [ARCHIVE] on Nostr: 📅 Original date posted:2019-07-14 📝 Original message: ZmnSCPxj via ...
📅 Original date posted:2019-07-14
📝 Original message:
ZmnSCPxj via Lightning-dev <lightning-dev at lists.linuxfoundation.org>
writes:
> Good morning Atoine,
>
> Thank you for your proposal.
>
>> Eltoo has been criticized to lower the cost for a malicious party to
>> test your monitoring of the chain. If we're able to reintroduce some
>> form of punishment without breaking transaction symmetry that would be great.
>
> The primary advantage of Decker-Russell-Osuntokun is that it
> eliminates "toxic waste".
>
> By this we mean, older version of your channel database are "toxic" in
> that you, ***or someone who wants to attack you***, can use it
> (accidentally in your case, deliberately in the attacker case), and
> then you will lose all funds in the channel.
I'm pretty sure at this point that the toxic-waste problem is inherent
to punishment schemes, and anything we build on top of it would
reintroduce asymmetry, undoing a lot of the benefits that we gained with
eltoo. Then again, I personally don't think that punishments are such a
great idea in the first place (having been inadvertently punished myself
due to botched backups and similar things).
> Note that access to your channel database, without necessarily
> accessing your node private keys, is often easier. For example,
> C-Lightning stores channel data into an SQLITE database and exposes
> every transaction it makes to a `db_hook` that plugins can use to
> replicate the database elsewhere. If you were to use an
> insufficiently secured plugin to replicate your database, an attacker
> might be able to access your channel data, replicate your database,
> and use an older version to frame you for theft and make you lose all
> your channel funds.
Just a minor correction here: your own commitment transactions are not
being signed until we want to release them. Therefore having access to
your DB doesn't give an attacker the ability to frame the user with an
old version, since that'd still require access to the keys to add our
own signature. Even a simple signing component that keeps a high-water
mark for the latest state and refuses to sign an older one would be
sufficient to guard against involuntary cheating.
Nevertheless, there are quite a few damaging things an attacker can do
if he get hold of your DB, just not this one :-)
> Thus, Decker-Russell-Osuntokun removes the punitive consideration so
> that you being framed for theft does not lose all your funds, it
> merely closes your channels.
Which is also not free: you are still paying on-chain fees for your
failed attempt to enforce an older state, and you still don't get the
desired effect, since the counterparty just overrides your attempt,
without returning your fees.
Cheers,
Christian
📝 Original message:
ZmnSCPxj via Lightning-dev <lightning-dev at lists.linuxfoundation.org>
writes:
> Good morning Atoine,
>
> Thank you for your proposal.
>
>> Eltoo has been criticized to lower the cost for a malicious party to
>> test your monitoring of the chain. If we're able to reintroduce some
>> form of punishment without breaking transaction symmetry that would be great.
>
> The primary advantage of Decker-Russell-Osuntokun is that it
> eliminates "toxic waste".
>
> By this we mean, older version of your channel database are "toxic" in
> that you, ***or someone who wants to attack you***, can use it
> (accidentally in your case, deliberately in the attacker case), and
> then you will lose all funds in the channel.
I'm pretty sure at this point that the toxic-waste problem is inherent
to punishment schemes, and anything we build on top of it would
reintroduce asymmetry, undoing a lot of the benefits that we gained with
eltoo. Then again, I personally don't think that punishments are such a
great idea in the first place (having been inadvertently punished myself
due to botched backups and similar things).
> Note that access to your channel database, without necessarily
> accessing your node private keys, is often easier. For example,
> C-Lightning stores channel data into an SQLITE database and exposes
> every transaction it makes to a `db_hook` that plugins can use to
> replicate the database elsewhere. If you were to use an
> insufficiently secured plugin to replicate your database, an attacker
> might be able to access your channel data, replicate your database,
> and use an older version to frame you for theft and make you lose all
> your channel funds.
Just a minor correction here: your own commitment transactions are not
being signed until we want to release them. Therefore having access to
your DB doesn't give an attacker the ability to frame the user with an
old version, since that'd still require access to the keys to add our
own signature. Even a simple signing component that keeps a high-water
mark for the latest state and refuses to sign an older one would be
sufficient to guard against involuntary cheating.
Nevertheless, there are quite a few damaging things an attacker can do
if he get hold of your DB, just not this one :-)
> Thus, Decker-Russell-Osuntokun removes the punitive consideration so
> that you being framed for theft does not lose all your funds, it
> merely closes your channels.
Which is also not free: you are still paying on-chain fees for your
failed attempt to enforce an older state, and you still don't get the
desired effect, since the counterparty just overrides your attempt,
without returning your fees.
Cheers,
Christian