search

lightning / bolts

BOLT: Basis of Lightning Technology (Lightning Network Specifications)
2.1k stars 492 forks source link

BOLT3 allows a Closing transaction with no outputs? #360

Closed ZmnSCPxj closed 2 weeks ago

ZmnSCPxj commented 6 years ago

Good morning,

Looking through BOLT 3, it seems to allow Closing Transactions with no outputs?

* txout count: 0, 1 or 2

My understanding is that transactions without any outputs are invalid and cannot be put in a block. Is my understanding correct?

Also this line about closing transactions and dust_limit_satoshis is confusing to me:

There will be at least one output, if `dust_limit_satoshis` is greater
than twice the funding amount.

Should it be "if the funding amount is greater than twice the dust_limit_satoshis"?

jb55 commented 6 years ago

My understanding is that transactions without any outputs are invalid and cannot be put in a block. Is my understanding correct?

Thinking about this, I don't see why it wouldn't be allowed, since you could use it to donate your dust to miners. I haven't checked the code yet...

ZmnSCPxj commented 6 years ago

https://github.com/bitcoin/bitcoin/blob/master/src/consensus/tx_verify.cpp#L164

jb55 commented 6 years ago

Consensus code... so it looks like you are correct.

yuntai commented 6 years ago

Also, I found this line confusing. Note that there are two possible variants for each node. 'Two possible variants' because 0-outputs is not allowed?

instagibbs commented 2 years ago

I just ran into this in the spec. It seems very odd to enumerate 0 outputs when it's patently illegal.

ZmnSCPxj commented 2 years ago

In particular, this is a mutual close transaction, meaning that in order to fix this spec bug, we need agreement from developers of multiple implementations. And probably a feature flag and a way to upgrade existing channels from the old "allow 0" protocol to the new "disallow 0" protocol. Sigh. Because "modern" mainnet Lightning Network channels "should not" hit this spec bug anymore (because nobody wants to spend onchain fees to open up tiny channels that are likely to have both outputs pruned), this becomes a low priority, and thus will never be fixed.

My proposal is that if both outputs end up being pruned, we should instead put an OP_RETURN output with 20 0x00 bytes. The extra 20 bytes is needed since without it we could hit the minimum transaction weight limit instead, LOL. Ideally the capstone should be random, but that just makes things even more complicated with the need to somehow generate the random capstone, sigh.

instagibbs commented 2 years ago

I doubt the spec includes what to do if the resulting transaction is illegal(I have to keep reading :) ), so I am not convinced it needs a coordinated roll-out, only that those who have the fix agree on the updated spec.

ZmnSCPxj commented 2 years ago

Finally --- In C-Lightning we avoid this by simply refusing to create (accept or offer) channels where it is possible for both sides to have less than the dust limit, so we no longer hit this case on the network at all, thus sidestepping this issue. It seems possible that modern versions of implementations also have similar prevention mechanisms.

instagibbs commented 2 years ago

Well, if fees rise, the fee_satoshis in closing_signed may cause additional drops in outputs? Could also be gated in various implementations at this level where they will refuse to send such a message.

ZmnSCPxj commented 2 years ago

BOLT2 already specifies the gates at the open_channel and accept_channel messages. It does not specify any gates at update_fee though.

instagibbs commented 2 years ago

To be clear, I don't believe those gating measures matter when it comes to mutual close.

ZmnSCPxj commented 2 years ago

Not to mention that some implementations may loosen some gates. For example: there is a protocol variation, in an LSP-client context, where clients continue to require a 1% channel_reserve_satoshis from the LSP but the LSP does not impose this and allows clients to have 0 reserve, so as to avoid support questions from clients "why can I not send my entire amount, why is some of my capacity wasted on this 'reserve' crap?" This is safe for the LSP as long as it ensures a high uptime for its node and any watchtowers it has, and this remains safe for clients as they still impose a channel reserve. In such variant cases, at extremes there may be cases where removal of the gates at open may cause this very problem at the mutual close. Such protocol variants are likely to be implemented as taking the source code for a complete specs-compliant implementation and modifying it minimally to remove the gate, so even complete specs-compliant implementations should support such uses by supporting the OP_RETURN mutual close.

t-bast commented 2 weeks ago

This should be fixed by #1096 which explicitly mentions this case.