Re: [Lightning-dev] Using Per-Update Credential to enable Eltoo-Penalty
Good morning list, I had another realization about the use of punishment in a multiparticipant (n > 2) setting. And it has to do with contracts that have a sort of "shared ownership". Consider HTLC outputs. Such outputs have shared ownership, as the offerer of the HTLC will be able to reclaim the money after the timelock, and the accepter of the HTLC will be able to reclaim the money before the timelock. Suppose we know that Alice cheated. Suppose also that Bob offered an HTLC to Alice with a hash whose preimage Alice secretly knows, and that Alice offered an HTLC to Charlie with a long future lock time with a hash that Alice secretly knows has a high probability that nobody knows the preimage. How should Bob and Charlie split the HTLCs? If we do not punish the HTLCs, then Alice can arrange such that most of her money is in HTLCs that she can recover, and thereby avoid punishment. If we *do* punish the HTLCs, we would have to make the Bob->Alice revocable only in favor of Bob, and make the Alice->Carol revocable only in favor of Charlie. This ties to constructions such as Channel Factories. I would argue that channel factories are better used than multiparticipant channels, as channel factories allow *some* limited transport of funds even if one participant is offline, whereas multiparticipant channels prevent *all* transport of funds as soon as any one participant is offline. At the same time, channel factories allow arbitrary transport of funds between any participants inside the factory if all participants are online: if a channel is exhausted, but the paying participant has funds elsewhere, the paying participant can initiate a channel reorganization and move funds to the exhausted channel. Channel factories host channels. Channels are shared-ownership UTXOs, in much the same way that HTLCs are shared-ownership UTXOs. Thus, if we will use this construction to implement channel factories, channels inside the factory should be punished by transferring the funds to the other participant of the channel. However, things can get more complicated as the states inside the construction change over time. Let us return to the HTLC example. Suppose there exists an Alice->Bob HTLC in the old state that Alice the thief publishes, and that the entire value of the construction is in that HTLC. Let us consider what happens if Alice the thief performs the theft attempt during various states: * Suppose the current state is that Charlie owns the entire funds of the channel right now. Alice steals by publishing old state, but the old-state Alice->Bob HTLC is revocable only by Bob. Thus the money (that rightfully belongs to Charlie) goes to Bob instead. * Alice and Bob could be in cahoots, with Bob as the mastermind and Alice as the fall guy. * Suppose we decide that the Alice->Bob HTLC is revocable split by Bob and Charlie. Suppose the current state is that Bob owns the entire funds of the channel right now. Alice steals by publishing old state, but the old-state Alice->Bob HTLC is revocable split by Bob and Charlie. Thus the money (that rightfully belongs only to Bob) goes partly to Charlie instead. * Alice and Charlie could be in cahoots, with Charlie as the mastermind and Alice as the fall guy. It seems to me, that punishment systems can only work if one of the following are true: * 2 participants, which prevents channel factory scaling. * OR, no smart contracts (HTLCs or subchannels), which prevents channel factory scaling, **and** network/routing scaling. So I think that, in terms of multiparticipant constructions, non-punitive constructions are the only possible constructions. Regards, ZmnSCPxj ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Using Per-Update Credential to enable Eltoo-Penalty
Good morning list, > witness: > "sig(A, hash_type=SINGLE|ANYPREVOUTANYSCRIPT|NONE) sig(P, hash_type=SINGLE)" > (Alice commitment signature) I realized that this would not work. Alice can simply sign `sig(A, hash_type=ALL)` instead at this stage, as she is the only signatory to the ` OP_CHECKSIGVERIFY` and nobody else can impose that she use the above `hash_type`. And this signature is intended to be used to identify Alice as the culprit, by also being used to sign for , but `SIGHASH_ALL` would strongly bind the signature to this particular transaction. You could use `MuSig(A, B, C)` instead and perform the MuSig signing ritual such that Alice is the last one to generate the final signature, but this massively complicates things as you need to perform `n` such rituals where `n` is the number of participants. I think a hash/preimage challenge would work better here. Each participant would reveal an identifying hash on channel opening, with a preimage only each participant knows. This is used to restrict which Taproot script they can use to perform a unilateral close, thus identifying which participant initiated the unilateral close (and if the unilateral close is to an old state, can be used to identify who should be punished). > > > 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). I largely agree. > > 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 :-) Ah, I understand. > > 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. Current Poon-Dryja requires a "reserve", a minimum amount that each participant must maintain in the channel. Though not fixed in the spec (each participant supposedly indicates the reserve they want from the other) all implementations I know of hardcode 1% of the channel total value as the reserve. This is the amount that can be used to punish a thief. Now, an economically-maximizing thief would prefer to steal as much as possible, thus such a thief would initiate a channel, then send out funds until only 1% is left to the thief, then "freeze" the channel (fail all incoming HTLCs from this channel without bothering to check if they would succeed) until the participant is offline, then perform the theft attempt by using their initial commitment (the one where they own all the funds in the channel). Thus, if the fee that is needed in Decker-Russell-Osuntokun is at or above 1% of the channel value, the fee lost would be larger than what a thief would risk under Poon-Dryja. Of course, an economically-maximizing thief would make channels of up to
Re: [Lightning-dev] Using Per-Update Credential to enable Eltoo-Penalty
ZmnSCPxj via Lightning-dev 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 ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
