From antoine.riard at gmail.com Tue Jul 16 18:34:00 2019 From: antoine.riard at gmail.com (Antoine Riard) Date: Tue, 16 Jul 2019 14:34:00 -0400 Subject: [Lightning-dev] Using Per-Update Credential to enable Eltoo-Penalty In-Reply-To: References: <877e8kraux.fsf@gmail.com> Message-ID: Hi ZmnSCPxj, > 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. Okay, do you plan to handover keys to the watchtower to be able to sign and broadcast local commitment transactions or are you thinking about another design like giving him signed commitment ? That's an area we still need to think more for rust-lightning too. > 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. Okay, you maybe also need a special pubkey type to force signatures to use a given SIGHASH. that's a lot of tricks but that could be a use-case for taproot introducing key types. > 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). I think it's quite dubious to base our reasoning on current network situation and from then say on-chain fees in Eltoo model are enough to deter attackers (or even lazy parties). Channels are going to increase in size and people are learning how they are structured. With more knowledge of timeout locks and deltas, attackers may try to game them, specially by exploiting others elements like mempool congestion or eclipse your onchain node. I see penalty as the price the attacker have to pay to test your onchain monitoring setup. If it's cheap and the probabilities to win are high, given he is able to trouble confirmation of your update tx, a rational attacker will try. "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" And maybe people are going to limit of their channels to stay in a multiple of onchain fees, but they may also refuse to open channel with unknown or "untrusted" parties. Relying on economical incentives is better than social ones. > 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. Yes, I think a contract design principle is that we should enforce an order of claims between different channel participants. In a multiparty channel between Alice, Bob, Caroll and Dave, if Alice offered a HTLC to Bob and then cheats, if Bob come with a preimage to unlock the HTLC, his claim shouldn't be canceled by the punitive one raised by Bob, Caroll or Dave. "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" I agree too, with my current proposal I was just thinking in multiparty setup and not a 2-party one because it's far more adversarial. IMO, channel factories are a better design because I would say the "valuespace" is well isolated between participants.I.e if Alice has 1, Bob has 1, Caroll has 3, Alice shouldn't be able offer a HTLC worth 3 to Bob. It's more tricky to enforce on a multiparty channel rather than on a channel factory. > 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. If a HTLC output is claimable by both a preimage + sig from a channel participant or MuSig from all channel participants to a punitive tx, the punitive tx may be encumbered by some delay to let the preimage path being used first. I agree that may be tricky due to overlap between HTLC delay and this nSequence one. Easiest way is you don't punish on HLTC outputs, but that mean you need to keep higher channel reserve. > So I think that, in terms of multiparticipant constructions, non-punitive constructions are the only possible constructions. I think punitive constructions are possible on the channel syntax level but may not make sense on the economic due to higher funds being locked as channel reserve. This being balanced with an increased rate of attack, in which case you may want an higher insurance policy in the form of punitive provisions on your channel dishearten cheat attempts. Hard to guess if and how much the network is going to be adversarial in 2 or 3 years.. Le dim. 14 juil. 2019 ? 20:12, ZmnSCPxj via Lightning-dev < lightning-dev at lists.linuxfoundation.org> a ?crit : > 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 at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: