Feature: Liquidity ads (lightning native dual funded channels)

[zerofeerouting]

Background

As per the proposed BOLT specification by @niftynei (lightning/bolts#878), there is a way to allow for dual funded channels natively without having to run additional and implementation specific software on top.

The feature is already implemented and rolled out in CLN. ACINQ is currently implementing it for eclair if I understand correctly.

It would be great if the most common lightning implementation would support this feature as well.

There is a feature bounty for this, which I will match up to 10,000,000 sats:
https://btcpay.zerofeerouting.com/apps/6RNpv94dQvWV3n65Fze2xrubbAm/crowdfund

I really hope this feature will be implemented, should make lightning more robust and less dependend on centralized points of failure.

[Roasbeef]

A would-be implementor should first become intimately familiar with the existing dual funding flow in the internal wallet, which was implemented in 2015 or so:

lnd/lnwallet/test/test_interface.go

Lines 444 to 655 in 7106ea5

	func testDualFundingReservationWorkflow(miner *rpctest.Harness,
	alice, bob *lnwallet.LightningWallet, t *testing.T) {
	fundingAmount, err := btcutil.NewAmount(5)
	if err != nil {
	t.Fatalf("unable to create amt: %v", err)
	}
	// In this scenario, we'll test a dual funder reservation, with each
	// side putting in 10 BTC.
	// Alice initiates a channel funded with 5 BTC for each side, so 10 BTC
	// total. She also generates 2 BTC in change.
	feePerKw, err := alice.Cfg.FeeEstimator.EstimateFeePerKW(1)
	if err != nil {
	t.Fatalf("unable to query fee estimator: %v", err)
	}
	aliceReq := &lnwallet.InitFundingReserveMsg{
	ChainHash: chainHash,
	NodeID: bobPub,
	NodeAddr: bobAddr,
	LocalFundingAmt: fundingAmount,
	RemoteFundingAmt: fundingAmount,
	CommitFeePerKw: feePerKw,
	FundingFeePerKw: feePerKw,
	PushMSat: 0,
	Flags: lnwire.FFAnnounceChannel,
	}
	aliceChanReservation, err := alice.InitChannelReservation(aliceReq)
	if err != nil {
	t.Fatalf("unable to initialize funding reservation: %v", err)
	}
	aliceChanReservation.SetNumConfsRequired(numReqConfs)
	channelConstraints := &channeldb.ChannelConstraints{
	DustLimit: alice.Cfg.DefaultConstraints.DustLimit,
	ChanReserve: fundingAmount / 100,
	MaxPendingAmount: lnwire.NewMSatFromSatoshis(fundingAmount),
	MinHTLC: 1,
	MaxAcceptedHtlcs: input.MaxHTLCNumber / 2,
	CsvDelay: csvDelay,
	}
	err = aliceChanReservation.CommitConstraints(
	channelConstraints, defaultMaxLocalCsvDelay, false,
	)
	if err != nil {
	t.Fatalf("unable to verify constraints: %v", err)
	}
	// The channel reservation should now be populated with a multi-sig key
	// from our HD chain, a change output with 3 BTC, and 2 outputs
	// selected of 4 BTC each. Additionally, the rest of the items needed
	// to fulfill a funding contribution should also have been filled in.
	aliceContribution := aliceChanReservation.OurContribution()
	if len(aliceContribution.Inputs) != 2 {
	t.Fatalf("outputs for funding tx not properly selected, have %v "+
	"outputs should have 2", len(aliceContribution.Inputs))
	}
	assertContributionInitPopulated(t, aliceContribution)
	// Bob does the same, generating his own contribution. He then also
	// receives' Alice's contribution, and consumes that so we can continue
	// the funding process.
	bobReq := &lnwallet.InitFundingReserveMsg{
	ChainHash: chainHash,
	NodeID: alicePub,
	NodeAddr: aliceAddr,
	LocalFundingAmt: fundingAmount,
	RemoteFundingAmt: fundingAmount,
	CommitFeePerKw: feePerKw,
	FundingFeePerKw: feePerKw,
	PushMSat: 0,
	Flags: lnwire.FFAnnounceChannel,
	}
	bobChanReservation, err := bob.InitChannelReservation(bobReq)
	if err != nil {
	t.Fatalf("bob unable to init channel reservation: %v", err)
	}
	err = bobChanReservation.CommitConstraints(
	channelConstraints, defaultMaxLocalCsvDelay, true,
	)
	if err != nil {
	t.Fatalf("unable to verify constraints: %v", err)
	}
	bobChanReservation.SetNumConfsRequired(numReqConfs)
	assertContributionInitPopulated(t, bobChanReservation.OurContribution())
	err = bobChanReservation.ProcessContribution(aliceContribution)
	if err != nil {
	t.Fatalf("bob unable to process alice's contribution: %v", err)
	}
	assertContributionInitPopulated(t, bobChanReservation.TheirContribution())
	bobContribution := bobChanReservation.OurContribution()
	// Bob then sends over his contribution, which will be consumed by
	// Alice. After this phase, Alice should have all the necessary
	// material required to craft the funding transaction and commitment
	// transactions.
	err = aliceChanReservation.ProcessContribution(bobContribution)
	if err != nil {
	t.Fatalf("alice unable to process bob's contribution: %v", err)
	}
	assertContributionInitPopulated(t, aliceChanReservation.TheirContribution())
	// At this point, all Alice's signatures should be fully populated.
	aliceFundingSigs, aliceCommitSig := aliceChanReservation.OurSignatures()
	if aliceFundingSigs == nil {
	t.Fatalf("alice's funding signatures not populated")
	}
	if aliceCommitSig == nil {
	t.Fatalf("alice's commit signatures not populated")
	}
	// Additionally, Bob's signatures should also be fully populated.
	bobFundingSigs, bobCommitSig := bobChanReservation.OurSignatures()
	if bobFundingSigs == nil {
	t.Fatalf("bob's funding signatures not populated")
	}
	if bobCommitSig == nil {
	t.Fatalf("bob's commit signatures not populated")
	}
	// To conclude, we'll consume first Alice's signatures with Bob, and
	// then the other way around.
	_, err = aliceChanReservation.CompleteReservation(
	bobFundingSigs, bobCommitSig,
	)
	if err != nil {
	for _, in := range aliceChanReservation.FinalFundingTx().TxIn {
	fmt.Println(in.PreviousOutPoint.String())
	}
	t.Fatalf("unable to consume alice's sigs: %v", err)
	}
	_, err = bobChanReservation.CompleteReservation(
	aliceFundingSigs, aliceCommitSig,
	)
	if err != nil {
	t.Fatalf("unable to consume bob's sigs: %v", err)
	}
	// At this point, the funding tx should have been populated.
	fundingTx := aliceChanReservation.FinalFundingTx()
	if fundingTx == nil {
	t.Fatalf("funding transaction never created!")
	}
	// The resulting active channel state should have been persisted to the
	// DB.
	fundingSha := fundingTx.TxHash()
	aliceChannels, err := alice.Cfg.Database.FetchOpenChannels(bobPub)
	if err != nil {
	t.Fatalf("unable to retrieve channel from DB: %v", err)
	}
	if !bytes.Equal(aliceChannels[0].FundingOutpoint.Hash[:], fundingSha[:]) {
	t.Fatalf("channel state not properly saved")
	}
	if !aliceChannels[0].ChanType.IsDualFunder() {
	t.Fatalf("channel not detected as dual funder")
	}
	bobChannels, err := bob.Cfg.Database.FetchOpenChannels(alicePub)
	if err != nil {
	t.Fatalf("unable to retrieve channel from DB: %v", err)
	}
	if !bytes.Equal(bobChannels[0].FundingOutpoint.Hash[:], fundingSha[:]) {
	t.Fatalf("channel state not properly saved")
	}
	if !bobChannels[0].ChanType.IsDualFunder() {
	t.Fatalf("channel not detected as dual funder")
	}
	// Let Alice publish the funding transaction.
	err = alice.PublishTransaction(fundingTx, "")
	if err != nil {
	t.Fatalf("unable to publish funding tx: %v", err)
	}
	// Mine a single block, the funding transaction should be included
	// within this block.
	err = waitForMempoolTx(miner, &fundingSha)
	if err != nil {
	t.Fatalf("tx not relayed to miner: %v", err)
	}
	blockHashes, err := miner.Client.Generate(1)
	if err != nil {
	t.Fatalf("unable to generate block: %v", err)
	}
	block, err := miner.Client.GetBlock(blockHashes[0])
	if err != nil {
	t.Fatalf("unable to find block: %v", err)
	}
	if len(block.Transactions) != 2 {
	t.Fatalf("funding transaction wasn't mined: %v", err)
	}
	blockTx := block.Transactions[1]
	if blockTx.TxHash() != fundingSha {
	t.Fatalf("incorrect transaction was mined")
	}
	assertReservationDeleted(aliceChanReservation, t)
	assertReservationDeleted(bobChanReservation, t)
	// Wait for wallets to catch up to prevent issues in subsequent tests.
	err = waitForWalletSync(miner, alice)
	if err != nil {
	t.Fatalf("unable to sync alice: %v", err)
	}
	err = waitForWalletSync(miner, bob)
	if err != nil {
	t.Fatalf("unable to sync bob: %v", err)
	}
	}

. One will also likely want to look at the history of the reservation system, and how the single funder flow was added after the initial dual funding reservations (see the single prefix/suffix on some of the new methods).

[zerofeerouting]

Cool! Thank you for the feedback and the pointers!

[Darth-Coin]

I would like to add something in regards to this proposal.

Add also a feature that will lock that channel for a specific CLTV time (agreed by parties) and could not be force closed until at least that block height agreed.

It is useless and painful to have a channel contract to open a dual funded channel that after 1-2 days got forced closed, for various reasons, that users cannot control.

All these force closing channels that happen lately in mass are totally wrong and make unusable LN.
In the last 10 days I got 20 channels forced closed. Why? Because somehow on the path the HTLCs got stuck and I am the one penalized for no reason. I am not the one that had the node offline or not forwarding the payment.

Some channels I paid for them and now I got them forced closed. This have to be addressed somehow.

[C-Otto]

Because somehow on the path the HTLCs got stuck and I am the one penalized for no reason. I am not the one that had the node offline or not forwarding the payment.

In this case your node force-closed the channels. If you don't want this to happen, you could tweak your own code - with the risk that the "offline" counter party steals the funds in said HTLCs. There's a reason why unilateral closes happen automatically, and I'm pretty sure you're not the only node operator who hates it when it happens.

That being said, delaying/disallowing unilateral channel closes is a very bad idea. They are required in certain situations, and aside from bugs there are plenty of situations where the one who issues the close needs to mitigate some kind of risk.

[Darth-Coin]

Opening a channel is a contract. A contract must have a grace period.
Right now users can't set a specific time, agreed between them, until when the channel is open.
The CLTV is used only as a punishment or dispute time, but is NOT the time of the contract.
So is useless to have a contract that I don't know when will be void or canceled.

So if you have a renting contract for a house, but the owner will not put any term until you could stay in that house. Then once you paid the rent for the first 3 months, the owner come and kick you out, because the contract doesn't have any term.
How is that a bad idea disallowing the owner to kick you out now ?

[C-Otto]

Contracts usually require trust, either in the other party, or some higher entity. In situations where one node issues a unilateral close automatically, there's some kind of dispute (most likely because one party is offline). The blockchain is the higher entity that settles the dispute. I don't see how this can be fixed, as it's at the core of how the LN works.

Your example lacks the reason for the owner kicking you out. If it's the equivalent of a manual "lncli closechannel --force": sure, that's bad. But what if you (the renter) didn't pay rent, or your check bounced, or you're about to destroy the house?

I'd say we shouldn't have this discussion in here, as it's an underlying problem (property?) of the LN.

[zerofeerouting]

@Darth-Coin - that can't work. There always is a reason for automated force-closes, usually to safe one (or both) peer's funds. Prohibiting this will put the peer that can't force-close at a disadvantage.

A channel where both peers want the channel to be force-closed, that can't be force-closed due to some agreement is just dead weight, since both parties would just disable it.

[Darth-Coin]

Then create a special signature that both parties have to sign after agree to close that channel before the time.

[zerofeerouting]

You're derailing this issue with something unrelated.

[dni]

is anyone seriously working on this issue?

[morehouse]

Hi folks. I've quit my day job and am interested in working on this.

@niftynei's spec for liquidity ads seems to be shelved until the dual funding spec is finalized and merged. I've left feedback on both specs. In particular, I think there's some major changes we should make to liquidity ads around how leases are enforced (CLTV seems simpler and cleaner than the current update_blockheight hack, and we can easily put timelocks on more branches in HTLCs).

Regardless, dual funding is what we need to implement first in LND, and the spec for that seems more mature. We should be able to implement experimental support for the current spec draft, and update as the spec is finalized. Later we can revisit how to best implement liquidity ads.

I'm currently working on an implementation plan for dual funding. I'll post some ideas here for feedback later this week.

[zerofeerouting]

@morehouse - very cool, that you're interested in doing this. Feel free to create a feature branch and / or ask questions here in the ticket. I am unaware of anyone else working on this at the moment.

The bounty raised by me is currently 0.104 BTC plus the 0.1 BTC I will personally give. (so 0.204 BTC as of now). I think we might be able to raise additional awareness if there is some progress. Would love to see liquidity ads happening!