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 `<Alice key> 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 <Alice key>, 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 our channel limit of 16,777,215 satoshi, of which 1% would be a large fee even during congestion conditions. Still, a node could refuse incoming channel open requests for Decker-Russell-Osuntokun that are larger than 100 times the typical fee for a 1-input 1-output transaction, and still get similar protection to Poon-Dryja using the de facto standard 1% reserve. Regards, ZmnSCPxj _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
