Chain Lightning - a magic mint payment channel scheme

General RFCs
1

Multisig allows for complex relationships between keyholders. Multisig minting is a recently implemented capability that allows multisig addresses to participate in the minting process. Concurrently, multisig payment channel concepts are being pursued with great interest by the Bitcoin community, and look to be adopted by the Peercoin community. Concepts of proof of stake pooling in Peercoin have been discussed for nearly a decade (rfcs/0012-cold-minting.md at master · peercoin/rfcs · GitHub) with continuous heed being paid to maintaining decentralization. Layer 2 solutions may finally provide the necessary protocols to unlock a new form of distributed minting.

Lightning Network involves entering a multisig address with a person you want to exchange coin with. You are then able to record transactions off-chain via intermediary signed transactions, only broadcasting upon settling out the channel. Eltoo provides a concept of update and settlement transactions that allows for invalidating previously valid off-chain transactions. Let’s imagine how a ‘magic mint’ multisig might be able to interact here.

In the ‘magic mint’ setup, coins are held in a 2-of-3 multisig where 1 key is an always-online pool operator and 2 keys are held by the original funder and minter. I will skip over the details here to address the payment channel. We would promote the 2-of-3 into a 5-of-7 magic mint payment channel, where 2 keys are magic mint hot keys and 1 magic mint cold key of one participant, 3 are the magic mint keys of another participant (2 hot 1 cold), and 1 is the operator key (vout[0]). From here, the multisig can act simultaneously as a magic mint address requiring all 4 hot keys and 1 operator key to mint, while also acting as a payment channel where either the operator or one of the cold keys is used off-chain.

The reason we use 5-of-7 instead of 3-of-5 is that a single participant colluding with the operator would be able to use their hot and cold and the operator key to reach the 3 keys required, without the other participant being necessary. With 5-of-7, a single participant plus the operator is only 4 keys, insufficient to drain the funds.

I believe the rest of the tech stack flows from here, if a bit more complex due to the quantity of signatures.

2 Likes
2

A mint txn must be broadcast and can be used as a settlement. It can also be sent right back to the same address to keep the channel open. In such a case (which should be considered standard operation), participants would need to essentially reopen the channel, once again exchanging fund txns and resetting the update-chain back to the start.

Rewards sharing is implicit in this, and the distribution of rewards would be able to chain through the entire lightning network if so desired.

3

An issue with this setup is that the particpants, not the operator, must open multiple payment channels with various operators in order to chain the mint channels together between operators. This is necessary, because we want the participants to be in control of their keys, where the operator is just a facilitating entity and a watchtower.