Gert-Jaap Glasbergen <gertj...@gertjaap.nl> writes: > As for htlc_minimum_msat I would not feel good about it being dropped. > It is the only protection measure I saw in the standard against > producing trimmed HTLCs. In my view the safe default is to set it above > the dust limit to avoid it to get trimmed, and effectively end up > routing trusted in-flight payment, that can't be enforced on-chain.
BTW, that problem is more subtle: non-dust outputs can still be uneconomic to collect. Ideally our definition of "dust" should vary with fees, which makes this "I don't want dust" awkward. > There might be reasons to define this differently per client as per > everyone's own views, but I don't think it is a good idea to remove > this behavior negotiation entirely, because it would effectively force > any client to accept HTLCs of any minimum size. Only incoming HTLCs. You can always refuse to create outgoing HTLCs; this parameter only limits what the peer can offer you. I don't *think* there's any danger in accepting a tiny HTLC, which you'll immediately fail. > As for minimum_depth, I think this default should be chain-dependant. > Given the standard describes the possibility to use different chains, > limiting this to a fixed number in the standard seems like a risky > choice. Given that it's optional that would mean anyone that wants to > enforce a higher value would just stop supplying the field. Agreed: I was assuming bitcoin. The spec assumes bitcoin in several places because nobody else has done the work, though we leave it open. We should specify it by chain. > Would it be something to consider? Given the fact that any part below > 1000 msat cannot be enforced on-chain, I would prefer giving users the > ability to opt out of that. There currently is none. > > So, either a transaction_min_msat_multiple (set to 1000 for only > accepting whole satoshis) or accept_subsatoshi (1/0). The latter seems > more useful since you probably wouldn't give the former any other value > than either 1 or 1000. I believe this would render you inoperable in practice; fees are frequently sub-satoshi, so you would fail everything. The entire network would have to drop millisatoshis, and the bitcoin maximalist in me thinks that's unwise :) On-chain enforcement is not a panacea. We could do probabilistic payments but they can still be gamed as you can just retry until you get the desired skew :( In practice, bitcoin charges enough that playing such games cannot win. Thanks, Rusty. _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
