Lightning: Empty close transaction on very low value channels

[cdecker]

Reported by a user on IRC: if a channel is funded with a value lower than the estimatefee result, we'll create a close transaction with no outputs:

0200000000010180a3cdf98dd561c0d697304b20ab48ec7c6f22da0e3ee1b7cedafd9ec4deff130000000000000c7680000400483045022100dc56ae5900ba0613d30efd101fbf017e3910a9bbfc8cc16a3f41f2a102e5a4760220582c440e3dad02e5c70d16fd56190f89276b8b7a8da93fdc667b8a6125bc48ea014830450221009bced74abafb345f5a3b42c11666370686ae22cc76414bdc074d12d4d7f363ec022059577f167eac0c187a4d5d732dd5b04a3c4d1c9a600cf2ce22e4e2272f206ff90147522102db02aabecf3b3b808a283c21a4b9f58942f5fdda63d36662315f5b631935fc88210332b70bf0791e9c945a7281903075c17f661a3a49c30081915e6820cde9c9445852ae8165a120

I guess we could suggest using --override-fee-rates however that may get funds stuck. Not sure what to do with this one.

[DanielWeigl]

if the channel closing can not produce economically spendable outputs, the best would be to provide an option to forget the channel and leave it as it is - or?

additionally, would it make sense to add a check in fundchannel to ensure the channel capacity is greater than the current fee for an average tx size with the selected feerate?

(irc user was me)

[cdecker]

A check when funding is definitely a good idea, not so sure about forgetting. The channel can still be useful for others to route through or you to make small payments, so it's not all bad :-)

[ZmnSCPxj]

Perhaps @DanielWeigl means, if the controller requested an RPC close anyway, the controller presumably foresees no use for the channel in the future and if the channel close would not produce economically-spendable outputs, we might as well forget the channel.

BOLT 3 specifically allows a closing transaction with 0 outputs: https://github.com/lightningnetwork/lightning-rfc/blob/master/03-transactions.md#closing-transaction

* txout count: 0, 1 or 2

[cdecker]

Hm, I would prefer having a tiny output, and the rest of the funds go to on-chain fees, otherwise we're slowly eroding the money supply, since those outputs become unusable.

[jb55]

A check when funding is definitely a good idea, not so sure about
forgetting. The channel can still be useful for others to route
through or you to make small payments, so it's not all bad :-)

Is this true when the channel is stuck in the CLOSINGD_SIGEXCHANGE state? That's my situation right now:

lightning_closingd(19665): STATUS_FAIL_PEER_BAD: Funder cannot afford fee 78669 (38000 and 0)

I'm sure we could have predicted this scenario given the funding amounts? Is this not implemented yet? I noticed a

FIXME: dustlimit

in the code, not sure if this is related.

[alvenca]

I belive to have the same issue with a channel stuck in ONCHAIND_OUR_UNILATERAL and the closing tx failing:

lightningd(16256): Broadcasting tx 02000000000101d61bfb0462c46d37fe364fa41fa67b844b9786af9798220b7950055e04fc8a45000000000090000000000347304402206e65e2c1729f4fa3453bcf3ec0f532ce93935e26c64c83a0d548166750c8d78402207c7a3e04d61d57231420a29ad4d88fb383819c49ce381d5115f0bd96747248c901004d632103969c7b3edde0b442e27b84f1f1f8fb04ef97db00820a2f18d9376f7f676bd56967029000b2752103d3105aed43e3b3440a052ae8cde7a2102493d33de8fa199c2f542c3fc82639fb68ac00000000: 26 error code: -26
error message:
16: bad-txns-vout-empty

Tell me if further logs would help.

[windsok]

After talking with Rusty on IRC, I think I also have an example of this.

Someone opened a channel with me, no lightning transactions were ever sent, and it looks like somehow a close was triggered, and the channel is stuck in CLOSINGD_SIGEXCHANGE state.

Trying a force dev-fail produces the bad-txns-vout-empty error.

Transaction from dev-fail is here: https://gist.github.com/windsok/5c10286e2589b41d83284d8146023b38

[windsok]

related discussion on lightning-rfc https://github.com/lightningnetwork/lightning-rfc/issues/360

[laanwj]

@alvenca I'm seeing the same - it is trying to broadcast a transaction without vouts, after

lightningd(23449): peer <id>: Peer permanent failure in CHANNELD_NORMAL: lightning_channeld: update_fee 10000 outside range 23424-224975

[alvenca]

@laanwj mine was accepted after a restart, maybe after fees dropped enough, my own output was tiny

[andronoob]

Came across this issue, too.
Refund tx(cannot be broadcasted, because output count is zero):

02000000000101f5e1a772dad66218cb089681d0890d0fa5ecb6b8e5c352e407665bcff369ea40000000000090000000000347304402202ca40d748594095deff85e5dad0b47f6a495e795a894a8ed4335e37b53e570b702201d4f6a886afcc9ffaeafc58cde9d63e0488167f232041358e79fe86feae4ce7d01004d6321037126f12b38d0074483f880434ebbf8b9b665e855671ee93dbf2eff5a15106b8567029000b2752102c1649db2cb5827a831ed8fbffca0bfc132ab38f0085a2beb9d3893081a700eb068ac00000000

My getinfo output:

{ "id" : "029c84efc179604981e24234b12025adfb4cec56de68f19ea32323170e03c3af28", "port" : 9735, "address" : 
    [ 
        { "type" : "ipv4", "address" : "108.61.162.115", "port" : 9735 } ], "version" : "v0.5.2-2016-11-21-1932-gfe670b9", "blockheight" : 508994, "network" : "bitcoin" }

BTW, if I recalled correctly, this channel was automatically force-closed, which might be triggered by a "crazy operation" set off by me: executing while true; do ./lightning-cli pay [BOLT11]; done in bash shell...
listpeers output:

{ "peers" : 
    [ 
        { "id" : "03cbf298b068300be33f06c947b9d3f00a0f0e8089da3233f5db37e81d3a596fe1", "connected" : false, "channels" : 
            [ 
                { "state" : "ONCHAIND_OUR_UNILATERAL", "owner" : "lightning_onchaind", "short_channel_id" : "508600:1116:0", "funding_txid" : "31ac34caee03fc8dac78be04adab7eced62db06b15e01c6147827b6adf2d26d6", "msatoshi_to_us" : 2019997, "msatoshi_total" : 2498000, "dust_limit_satoshis" : 546, "max_htlc_value_in_flight_msat" : 18446744073709551615, "channel_reserve_satoshis" : 0, "htlc_minimum_msat" : 0, "to_self_delay" : 144, "max_accepted_htlcs" : 483 } ] } ] }

[rustyrussell]

OK, there are three places where we can produce empty txs:

1. Trying to put tiny outputs back in our wallet. Fixed in 45e145df5efab5ffe6ced26cb94bd9b57013ec7c where we create a valid tx, but just donate the trivial amounts to miners.
2. Stupidly tiny channels where we end up with all dust outputs, then try to unilaterally close. I'm fixing that now to disallow them.
3. Mutual close. Fixing 2 above fixes this, since fees for mutual close have to be <= commitment txs.