Rusty Russell [ARCHIVE] on Nostr: 📅 Original date posted:2018-10-31 📝 Original message: Gert-Jaap Glasbergen ...

📅 Original date posted:2018-10-31
📝 Original message:
Gert-Jaap Glasbergen <gertjaap at 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.