Is there some way to add a third party authorizer to (or by) a lightning network transaction?

Question

I'm not asking for "multisig on the lightning network", but I'm more curious about how one would set up shared control over lightning network transactions in general.

Imagine we don't have a multisig transaction... would it be possible to set up some sort of 3rd party oracle that would "link" a channel?

Or maybe set up some sort of logic implemented by the opening or closing of payment channels on a boutique lightning network?

In 2.2 of the lightning network paper, it says that opening payment channels doesn't actually control the movement of any funds. https://lightning.network/lightning-network-paper.pdf

Some folks came up with an idea for a way to pay an oracle for provable information (especially information that can best be obtained in from a lot of different decentralized nodes at "anti-affinitied" locations) using lightning & bcoin: https://github.com/michaelfolkson/bcoin-hackathon

My brother wrote an implementation of NAND gates here, https://github.com/rjb25/gate-wiring , and since considering both of these I wondered whether one might hook up some sort of gating system whereby a third party could make a decision about two possibilities for distribution of the funds of another two parties.

And now I'm wondering if it'd be possible to set up some sort of private lightning network that uses the opening and closing of payment channels (or resizing them) to do some kind of third party authorization logic for lightning payments?

Perhaps where one person (party A) receives some amount of bitcoin in one case, and another (party B) in a different case, as determined by a third party oracle or mod?

Answer 1

I think you ask about escrow services in lightning. Generally there is a good opportunity to work with preimages. For example if we would move away from sha256 and would use ecdsa public private key encryption or a homomorphic hash function. Several parties could collaborative create a payment hash Wo sich they could only together generate the preimage. Stuff like this would also be possible with scriptless scripts. Also multiparty channels and channel factories could yield such functionality. So yes generally it is possible with lightning to go down this road but currently nothing of that is implemented to the protocol.

Answer 2

I asked @roasbeef last night, and he mentioned that Lightning may soon support multicontrol payments.

I'll add more details once I do some reading on the mailing list.

Answer 3

An oracle can be created on lightning if users set up their HTLCs in such a way that a third party can settle or cancel a bitcoin payment from one party to the other and thus resolve a contract without the oracle ever taking custody of either party’s funds.

How it would work is this: one or both counterparties deposit funds to an HTLC where the oracle can withdraw the funds if it learns the hashlock key and where the hashlock key is only known to that HTLC’s depositor’s counterparty. The result is one or two funded HTLCs.

Next, the oracle prepares an additional HTLC with the counterparty who did not deposit funds. (If both deposited funds, he creates a second HTLC with both.) This second HTLC uses a hashlock identical to the one known by the party with whom it is created. However, no one deposits funds to this HTLC yet. Instead, the oracle assesses the outcome of a real world event.

After the real world event happens, the oracle picks a “winner” and deposits funds into the unfunded HTLC which will be withdrawable by the winner if and only if he or she provides the hashlock key to that contract. If he or she does so, the oracle now has the hashlock key it needs to withdraw the funds that come from the other party -- the “loser” -- thus reimbursing the oracle with the loser’s money.

The timelock on the HTLC that the winner originally deposited funds into will eventually expire, and at that point the winner can recover the funds he or she deposited into that HTLC. The loser gets nothing and cannot recover any funds because that money went into the oracle’s pocket when the oracle reimbursed itself.

An implementation of this for the lightning network is here: https://github.com/supertestnet/hodlcontracts