Payment channels with dynamic signatures

Talking about single-funded payment channels, the idea is quite simple: Alice puts 10 btc into a multi-sig signed with Bob, and then they each update the state accordingly to send money to each-other back and forth.

Now, imagine a third person joins the picture, say Carol. And Alice wants to send her some btc. Can the channel state be updated with someone else's public key?

I'd like to understand if something like this is possible. If not, I'd like to know why this isn't possible (I'm for sure missing something about how payment-channels work and I'd like to understand what). Perhaps using Channel Factories something like this is possible?

The main idea here is that someone can set funds aside for a new person, without having to create a new channel, but by using the funds in an already created channel.

Please note that this doesn't have to do anything with routing. It's simply using funds within a channel for another person rather than just the 2 parties of the channel.

EDIT

Perhaps there's the possibility of creating "off-chain channels" (maybe this is channel factories?) that are somewhat connected to the main branch, using other participants. I want to stress that in this example Carol has never participated in a on-chain channel -- she's a new participant involved using "off-chain channels":

Luca Matteis

Posted 2018-01-20T17:25:02.593

Reputation: 4 784

Answers

It's possible for Alice and Bob to agree among themselves to pay Carol and any number of other recipients (subject to limits on transaction size). However, it's not possible for Carol and other additional recipients to receive those payments with the same trustless security available to Alice and Bob through the payment channel construct.

Alice and Bob open a channel by committing funds to a multisig address that requires signatures from both of them in order to spend. For Alice, this guarantees that her consent is required for any transaction spending the funds to be valid. Bob receives the same guarantee that his consent is required.

The innovation of bi-directional payment channels (including, but not exclusively, those used by Lightning Network) is that each payment in the channel can be revoked by the recipients, allowing a subsequent payment to take its place.

The encumbrance (redeem script) that protects a revocable payment is larger than a normal Bitcoin encumbrance, so the most desirable end to a payment channel is a mutual close where the last revocable payment is revoked and converted into a non-revocable payment that looks like a normal Bitcoin 2-of-2 multisig spend.

The only known way for revocable payments to work is for each party to have a complete list of every payment ever made and (if it has been revoked) what data is necessary to revoke it. This is what prevents Carol from having full payment channel security.

Alice and Bob can both mutually consent to paying Carol and they can tell Carol about this payment. If the transaction containing that payment gets broadcast, Carol gets her money. But because the multisig address to which the funds were initially deposited only requires Alice's and Bob's mutually consent to create other payments, they can create other payments in secret from Carol.

If one of the secret payments created between Alice and Bob gets broadcast, Carol doesn't have the data necessary to prove on the block chain that it was made fraudulently. Alice and Bob can thus, by mutual consent, steal Carol's funds.

A more conceptual way of looking at it is to envision the block chain as a trust anchor for payment channels. You need to have some degree of control over that anchor in order for you to be able to trust the resultant channel. Alice and Bob have that because their consent is required to use the anchor; Carol does not have any control over the anchor and so cannot trust it.

David A. Harding

Posted 2018-01-20T17:25:02.593

Reputation: 10 154

Say the Alice:3, Bob:7 state (earlier state) gets published on-chain. As far as I understand, both Alice and Bob have some "data" to essentially overwrite such earlier state, with the newest correct state (Alice:4, Bob:6). Can't this "data" also be shared with Carol, so that if Alice and Bob collude and publish on-chain an earlier state, Carol can overwrite it? – Luca Matteis – 2018-01-21T16:12:37.687

@LucaMatteis when Alice and Bob revoke an early state, they each share revocation data with each other that allows either of them to seize the other's funds if the other publishes an earlier state. There's no way to retroactively add Carol to these earlier states, and later states can be added after Carol becomes a designated recipient to which Carol is also not a recipient and so has no recourse. This means Carol has no security from collusion between Alice and Bob other than immediate closure of the payment channel upon Carol first receiving funds. – David A. Harding – 2018-01-21T16:43:42.513

The main problem I see with this is increased complexity, and possible collusion between 2 of the 3 parties. If Carol is now required to sign updates, what does Alice do if Carol is unresponsive? Broadcast her rescue transaction even though Bob is a responsive participant? Does she have rescue transactions for misbehavior from both Bob and Carol? What if Bob and Carol are colluding? Now she needs rescues for each of them, plus for then combined. What happens if you add Dave to the mix?

All of these scenarios would need to be covered in order to keep the system trustless. As you increase the complexity of a single channel, you scale the potential problems even more. It is probably better to keep the channels, themselves, as simple as possible and attempt to scale via routing.

Jestin

Posted 2018-01-20T17:25:02.593

Reputation: 8 339