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
