Hi Olaoluwa Thank you for your reply!
Good point that channel state is transitory, my thinking was that opening balanced channels simplifies things for new routing nodes, rather than having to balance them out through fee adjustments when most channels are lopsided. But I clearly need to learn more about this. -- Ole Henrik Skogstrøm Mobile: (+47) 97 42 74 44 On Thu, Sep 23, 2021 at 1:31 AM Olaoluwa Osuntokun <laol...@gmail.com> wrote: > 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 < > oleskogst...@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@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev >> >
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
