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?

  • Is there any particular reason why you are typing // everywhere? It doesn't do anything as far as I know. Mar 27, 2017 at 21:08
  • @NateEldredge: I was just editing the same post for the same reason.— Nathan Basanese: please stop doing this. While it may give your posts some additional attention for a moment due to the visual clutter, you're creating unnecessary work for other users.
    – Murch
    Mar 27, 2017 at 21:17
  • // , :) I guess not everyone on here can be expected to have a sense of humor about such things Mar 28, 2017 at 18:23
  • // , Do you have any comments about the question itself, or just style guides? I think some stackexchange fora have style guides. Would you link me to the one for bitcoin.stackexchange.com? Mar 28, 2017 at 18:28
  • @NathanBasanese Honestly, I can't tell what you're asking. e.g. [..] came up with an idea for a way to pay an oracle [..] using lightning & bcoin What information are we paying for? Why do we trust this oracle to provide it? My brother wrote an implementation of NAND gates here That's cool, but what relationship does this have to the rest of the question? You're asking for something that is explicitly not multisig, but it sounds like multisig makes the most sense for your use case.
    – Nick ODell
    Mar 28, 2017 at 18:51

3 Answers 3


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.


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.


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

  • You should mention that you're affiliated with the link you added. Otherwise, this just looks like spam.
    – Hannah Vernon
    Sep 14, 2021 at 20:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.