📅 Original date posted:2021-09-22
📝 Original message:
Hi Ole,
It's generally known that one can use out of band transaction construction,
and the push_amt feature in the base funding protocol to simulate dual
funded channels.
The popular 'balanceofsatoshis' tool has a command that packages up the
interaction (`open-balanced-channel`) into an easier to use format, IIRC it
uses key send to ask a peer if they'll accept one and negotiate some of the
params.
The one thing you need to take mind of when doing this manually is that by
default lnd will only lock the UTXOs allocated for the funding attempt for a
few minutes. As a result, you need to make sure the process is finalized
during that interval or the UTXOs will be unlocked and you risk accidentally
double spending yourself.
Lightning Pool also uses this little trick to allows users to purchase
channels that are 50/50 balanced, and also purchase channel leases _for_ a
third party (called sidecar channels) to help on board them onto Lightning:
https://lightning.engineering/posts/2021-05-26-sidecar-channels/. Compared
to the above approaches, the process can be automatically batched w/ other
channels created in that epoch, and uses traits of the Pool account system
to make things atomic.
Ultimately, the balanced-ness of a channel is a transitory state (for
routing nodes, it's great for on-boarding end-users) and opening channels
like these only serves to allow the channel to _start_ in the state. If your
fees and channel policies aren't set accordingly, then it's possible that a
normal payment or balance flow shifts the channel away from equilibrium
shortly after the channel is open.
-- Laolu
On Tue, Sep 21, 2021 at 10:30 PM Ole Henrik Skogstrøm <
oleskogstrom at gmail.com> wrote:
> Hi
>
> I have found a way of opening balanced channels using LND's psbt option
> when opening channels. What I'm doing is essentially just joining funded
> PSBTs before signing and submitting them. This makes it possible to open a
> balanced channel between two nodes or open a ring of balanced channels
> between multiple nodes (ROF).
>
> I found this interesting, however I don't know if this is somehow unsafe
> or for some other reason a bad idea. If not, then it could be an
> interesting alternative to only being able to open unbalanced channels.
>
> To do this efficiently, nodes need to collaborate by sending PSBTs back
> and forth to each other and doing this manually is a pain, so if this makes
> sense to do, it would be best to automate it through a client.
>
> ----------------------
> --- Here is an example of the complete flow for a single channel:
> ----------------------
>
> ** Node A: generates a new address and sends address to Node B *(lncli
> newaddress p2wkh)
>
> ** Node A starts an Interactive channel **open** to Node B* *using psbt*
> (lncli openchannel --psbt <node_b_pubkey> 2000000 1000000)
>
> ** Node A funds the channel address *(bitcoin-cli walletcreatefundedpsbt
> [] '[{"<channel_address>":0.02}]')
>
> ** Node B funds the refund transaction to Node A and sends PSBT back to
> Node A (*bitcoin-cli walletcreatefundedpsbt []
> '[{"<node_a_return_address>":0.01}]')
>
> * *Node A joins the two PSBTs and sends it back to Node B (*bitcoin-cli
> joinpsbts '["<channel_open_psbt>", "<node_b_return_to_node_a_psbt>"]')
>
> ** Node B verifies the content and signs the joined PSBT before sending it
> back to Node A *(bitcoin-cli walletprocesspsbt <joined_psbt>)
>
> ** Node A: Verifies the content and signs the joined PSBT *(bitcoin-cli
> walletprocesspsbt <joined_psbt>)
>
> ** Node A: Completes channel open by publishing the fully signed PSBT*
>
>
> ----------------------
> --- Here is an example of the complete flow for a ring of channels between
> multiple nodes:
> ----------------------
>
> ** Node A starts an Interactive open channel to Node B using psbt* (lncli
> openchannel --psbt --no_publish <node_b_pubkey> 2000000 1000000)
> ** Node A funds the channel address* (bitcoin-cli walletcreatefundedpsbt
> [] '[{"<channel_address>":0.02}]')
>
> ** Node B starts an Interactive open channel to Node C using psbt* (lncli
> openchannel --psbt --no_publish <node_b_pubkey> 2000000 1000000)
> ** Node B funds the channel address* (bitcoin-cli walletcreatefundedpsbt
> [] '[{"<channel_address>":0.02}]')
>
> ** Node C starts an Interactive open channel to Node A using psbt* (lncli
> openchannel --psbt <node_b_pubkey> 2000000 1000000)
> ** Node C funds the channel address *(bitcoin-cli walletcreatefundedpsbt
> [] '[{"<channel_address>":0.02}]')
>
> ** Node B and C sends Node A their PSBTs*
>
> ** Node A joins all the PSBTs* (bitcoin-cli joinpsbts
> '["<A_funded_channel_psbt>", "<B_funded_channel_psbt>",
> "<C_funded_channel_psbt>"]')
>
> Using (bitcoin-cli walletprocesspsbt <joined_psbt>):
>
>
>
> ** Node A verifies and signs the PSBT and sends it to Node B (1/3
> signatures)* Node B verifies and signs the PSBT and sends it to Node C (2/3
> signatures)* Node C verifies and signs the PSBT (3/3 signatures) before
> sending it to Node A and B.*
>
>
> ** Node A completes channel open (no_publish)* Node B completes channel
> open (no_publish)* Node C completes channel open and publishes the
> transaction.*
>
> --
> Ole Henrik Skogstrøm
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210922/b4281beb/attachment.html>;
Olaoluwa Osuntokun [ARCHIVE] /
npub19h…zkvn4
2023-06-09 13:03:52
in reply to nevent1q…apwv
Author Public Key
npub19helcfnqgk2jrwzjex2aflq6jwfc8zd9uzzkwlgwhve7lykv23mq5zkvn4Published at
2023-06-09 13:03:52Event JSON
{
"id": "66dad7bae9ef7614b216d1d07807bb3e4d49b07a3c58a8a80fb4e9eff50776f6",
"pubkey": "2df3fc2660459521b852c995d4fc1a93938389a5e085677d0ebb33ef92cc5476",
"created_at": 1686315832,
"kind": 1,
"tags": [
[
"e",
"9e84b62453fcef308636a5dccc45372e401ad899661148040d2e0b8c0396adee",
"",
"root"
],
[
"e",
"70c0d1b65d566649ba456dd412f237a839ae2e56949cd3d0ab8a342a88776933",
"",
"reply"
],
[
"p",
"0ca920dde5c4f4986ee8de6e8e24e9ddf951c8f96c8fbadf244c9caac3a49db3"
]
],
"content": "📅 Original date posted:2021-09-22\n📝 Original message:\nHi Ole,\n\nIt's generally known that one can use out of band transaction construction,\nand the push_amt feature in the base funding protocol to simulate dual\nfunded channels.\n\nThe popular 'balanceofsatoshis' tool has a command that packages up the\ninteraction (`open-balanced-channel`) into an easier to use format, IIRC it\nuses key send to ask a peer if they'll accept one and negotiate some of the\nparams.\n\nThe one thing you need to take mind of when doing this manually is that by\ndefault lnd will only lock the UTXOs allocated for the funding attempt for a\nfew minutes. As a result, you need to make sure the process is finalized\nduring that interval or the UTXOs will be unlocked and you risk accidentally\ndouble spending yourself.\n\nLightning Pool also uses this little trick to allows users to purchase\nchannels that are 50/50 balanced, and also purchase channel leases _for_ a\nthird party (called sidecar channels) to help on board them onto Lightning:\nhttps://lightning.engineering/posts/2021-05-26-sidecar-channels/. Compared\nto the above approaches, the process can be automatically batched w/ other\nchannels created in that epoch, and uses traits of the Pool account system\nto make things atomic.\n\nUltimately, the balanced-ness of a channel is a transitory state (for\nrouting nodes, it's great for on-boarding end-users) and opening channels\nlike these only serves to allow the channel to _start_ in the state. If your\nfees and channel policies aren't set accordingly, then it's possible that a\nnormal payment or balance flow shifts the channel away from equilibrium\nshortly after the channel is open.\n\n-- Laolu\n\nOn Tue, Sep 21, 2021 at 10:30 PM Ole Henrik Skogstrøm \u003c\noleskogstrom at gmail.com\u003e wrote:\n\n\u003e Hi\n\u003e\n\u003e I have found a way of opening balanced channels using LND's psbt option\n\u003e when opening channels. What I'm doing is essentially just joining funded\n\u003e PSBTs before signing and submitting them. This makes it possible to open a\n\u003e balanced channel between two nodes or open a ring of balanced channels\n\u003e between multiple nodes (ROF).\n\u003e\n\u003e I found this interesting, however I don't know if this is somehow unsafe\n\u003e or for some other reason a bad idea. If not, then it could be an\n\u003e interesting alternative to only being able to open unbalanced channels.\n\u003e\n\u003e To do this efficiently, nodes need to collaborate by sending PSBTs back\n\u003e and forth to each other and doing this manually is a pain, so if this makes\n\u003e sense to do, it would be best to automate it through a client.\n\u003e\n\u003e ----------------------\n\u003e --- Here is an example of the complete flow for a single channel:\n\u003e ----------------------\n\u003e\n\u003e ** Node A: generates a new address and sends address to Node B *(lncli\n\u003e newaddress p2wkh)\n\u003e\n\u003e ** Node A starts an Interactive channel **open** to Node B* *using psbt*\n\u003e (lncli openchannel --psbt \u003cnode_b_pubkey\u003e 2000000 1000000)\n\u003e\n\u003e ** Node A funds the channel address *(bitcoin-cli walletcreatefundedpsbt\n\u003e [] '[{\"\u003cchannel_address\u003e\":0.02}]')\n\u003e\n\u003e ** Node B funds the refund transaction to Node A and sends PSBT back to\n\u003e Node A (*bitcoin-cli walletcreatefundedpsbt []\n\u003e '[{\"\u003cnode_a_return_address\u003e\":0.01}]')\n\u003e\n\u003e * *Node A joins the two PSBTs and sends it back to Node B (*bitcoin-cli\n\u003e joinpsbts '[\"\u003cchannel_open_psbt\u003e\", \"\u003cnode_b_return_to_node_a_psbt\u003e\"]')\n\u003e\n\u003e ** Node B verifies the content and signs the joined PSBT before sending it\n\u003e back to Node A *(bitcoin-cli walletprocesspsbt \u003cjoined_psbt\u003e)\n\u003e\n\u003e ** Node A: Verifies the content and signs the joined PSBT *(bitcoin-cli\n\u003e walletprocesspsbt \u003cjoined_psbt\u003e)\n\u003e\n\u003e ** Node A: Completes channel open by publishing the fully signed PSBT*\n\u003e\n\u003e\n\u003e ----------------------\n\u003e --- Here is an example of the complete flow for a ring of channels between\n\u003e multiple nodes:\n\u003e ----------------------\n\u003e\n\u003e ** Node A starts an Interactive open channel to Node B using psbt* (lncli\n\u003e openchannel --psbt --no_publish \u003cnode_b_pubkey\u003e 2000000 1000000)\n\u003e ** Node A funds the channel address* (bitcoin-cli walletcreatefundedpsbt\n\u003e [] '[{\"\u003cchannel_address\u003e\":0.02}]')\n\u003e\n\u003e ** Node B starts an Interactive open channel to Node C using psbt* (lncli\n\u003e openchannel --psbt --no_publish \u003cnode_b_pubkey\u003e 2000000 1000000)\n\u003e ** Node B funds the channel address* (bitcoin-cli walletcreatefundedpsbt\n\u003e [] '[{\"\u003cchannel_address\u003e\":0.02}]')\n\u003e\n\u003e ** Node C starts an Interactive open channel to Node A using psbt* (lncli\n\u003e openchannel --psbt \u003cnode_b_pubkey\u003e 2000000 1000000)\n\u003e ** Node C funds the channel address *(bitcoin-cli walletcreatefundedpsbt\n\u003e [] '[{\"\u003cchannel_address\u003e\":0.02}]')\n\u003e\n\u003e ** Node B and C sends Node A their PSBTs*\n\u003e\n\u003e ** Node A joins all the PSBTs* (bitcoin-cli joinpsbts\n\u003e '[\"\u003cA_funded_channel_psbt\u003e\", \"\u003cB_funded_channel_psbt\u003e\",\n\u003e \"\u003cC_funded_channel_psbt\u003e\"]')\n\u003e\n\u003e Using (bitcoin-cli walletprocesspsbt \u003cjoined_psbt\u003e):\n\u003e\n\u003e\n\u003e\n\u003e ** Node A verifies and signs the PSBT and sends it to Node B (1/3\n\u003e signatures)* Node B verifies and signs the PSBT and sends it to Node C (2/3\n\u003e signatures)* Node C verifies and signs the PSBT (3/3 signatures) before\n\u003e sending it to Node A and B.*\n\u003e\n\u003e\n\u003e ** Node A completes channel open (no_publish)* Node B completes channel\n\u003e open (no_publish)* Node C completes channel open and publishes the\n\u003e transaction.*\n\u003e\n\u003e --\n\u003e Ole Henrik Skogstrøm\n\u003e\n\u003e _______________________________________________\n\u003e Lightning-dev mailing list\n\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210922/b4281beb/attachment.html\u003e",
"sig": "2b888b3ec0e84e63ca3dca4ce60f25a0fb6b7bc9c410976f172c1dfbd8b12eecf712b4726b8a226fb1786c1dcac569107d742367789538bc1aa3bfe14cc36d3c"
}