Re: [Lightning-dev] Code for sub second runtime of piecewise linarization to quickly approximate the minimum convex cost flow problem (makes fast multi part payments with large amounts possible)

[ZmnSCPxj via Lightning-dev]

Good morning Rene, sorry for the lateness,

> Last but not least, please allow me to make a short remark on the (still to 
> me very surprisingly controversial) base fee discussion: For simplicity I did 
> not include any fee considerations to the published code (besides a fee 
> report on how expensive the computed flow is). However in practice we wish to 
> optimize at least for high reliability (via neg log success probabilities) 
> and cheap fees which in particular with the ppm is very easily possible to be 
> included to the piece wise linearized cost function. While for small base 
> fees it seems possible to encode the base fee into the first segment of the 
> piecewise linearized approximation I think the base fee will still be tricky 
> to be handled in practice (even with this approximation). For example if the 
> base fee is too high the "base fee adjusted" unit cost of the first segment 
> of the piecewise linearized problem might be higher than the unit cost of the 
> second segment which effectively would break the convexity. Thus I reiterate 
> my e
 arlier point that from the perspective of the year long pursued goal of 
optimizing for fees (which all Dijkstra based single path implementations do) 
it seems to be best if the non linearity that is introduced by the base fee 
would be removed at all. According to discussions with people who crate 
Lightning Network explorer (and according to my last check of gossip) about 90% 
of channels have a base fee of 1 sat or lower and ~38% of all channels already 
set their base fee away from the default value to 0 [16].

I think the issue against 0-base-fee is that, to a forwarding node operator, 
every HTLC in-flight is a potential cost center (there is always some 
probability that the channel has to be forced onchain with the HTLC in-flight, 
and every HTLC has to be published on the commitment tx), and that cost is 
*not* proportional to the value of the HTLC (because onchain fees do not work 
that way).
Thus, it seems reasonable for a forwarding node to decide to pass on that cost 
to their customers, the payers, in the form of base fees.

The response of customers would be to boycott non-0-base fees, by e.g. using a 
heuristic that overweighs non-0-base-fee and reducing usage of such channels 
(but if every forwarding node *has* a base fee, going through them anyway, 
which is why you just overweigh them, not eliminate them from the graph 
outright).
Then forwarding nodes will economically move towards 0-base fee.

So I think you would find it impossible to remove the base fee field, but you 
can strongly encourage 0-base-fee usage by integrating the base fee but 
overweighted.
(I think my previous formulation --- treat the base fee as a proportional fee 
--- would do some overweighing of the base fee.)

Which reminds me, I have not gotten around to make a 0-base-fee flag for 
`clboss`, haha.
And I might need to figure out a learning algorithm that splits base and 
proportional fees as well, *sigh*.

Regards,
ZmnSCPxj
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] Interesting thing about Offered HTLCs

[darosior via Lightning-dev]

Miniscripts with duplicate keys are considered insane as it makes it too hard 
to reason about malleability (there is no CODESEPARATOR in Miniscript).

A policy compiler would never produce such a Miniscript.

 Original Message 
On Mar 15, 2022, 4:26 PM, Eugene Siegel < elzei...@gmail.com> wrote:

> I'm not familiar with miniscript besides that it's a subset of script - how 
> would it help avoiding an unintended path being taken?
>
> On Fri, Mar 11, 2022 at 8:47 AM darosior  wrote:
>
>> Also, using Miniscript (whether in Segwit v0 or v1) would prevent this kind 
>> of surprises. And many potential others. :-)
>>
>> I'll post something soon about how we could integrate Miniscript in 
>> Lightning.
>>  Original Message 
>> On Mar 10, 2022, 2:55 PM, Eugene Siegel < elzei...@gmail.com> wrote:
>>
>>> Yes I think bip342 should solve it. Maybe splitting up all conditionals 
>>> into leaves is a good idea for taproot lightning
>>>
>>> On Mon, Mar 7, 2022 at 5:46 PM Antoine Riard  
>>> wrote:
>>>
 Hi Eugene,

> Since the remote party gives them a signature, after the timeout, the 
> offering party can
 claim with the remote's signature + preimage, but can only spend with the
 HTLC-timeout transaction because of SIGHASH_ALL.

 I've not exercised the witness against our test framework though the 
 description sounds to me correct.

 The offering counterparty spends the offered HTLC output with a 
 HTLC-timeout transaction where the witness is < 
 >. SIGHASH_ALL is not committing to the spent Script 
 branch intended to be used. As you raised, it doesn't alleviate the 
 offering counterparty to respect the CLTV delay and as such the offered 
 HTLC timespan cannot be shortened. The implication I can think of, in case 
 of competing HTLC race, once the absolute timelock is expired, the 
 offering counterparty is able to compete against the receiving one with a 
 more feerate-efficient witness. However, from a receiving counterparty 
 safety viewpoint, if you're already suffering a contest, it means your 
 HTLC-claim on your own local commitment transaction inbound HTLC output 
 has been inefficient, and your fee-bumping strategy is to blame.

 If we think the issue is relevant, I believe splitting the Script branches 
 in two tapleaves and having bip342 signature digest committing to the 
 tapleaf_hash solves it.

 Antoine

 Le lun. 7 mars 2022 à 15:27, Eugene Siegel  a écrit :

> I'm not sure if this is known, but I'm pretty sure it's benign and so I 
> thought I'd share since I found it interesting and maybe someone else 
> will too. I'm not sure if this is already known either.
>
> https://github.com/lightning/bolts/blob/master/03-transactions.md#offered-htlc-outputs
> Offered HTLCs have three claim paths: the revocation case, the offerer 
> claiming through the HTLC-timeout transaction, and the receiver claiming 
> via their sig + preimage. The offering party can claim via the 
> HTLC-timeout case on their commitment transaction with their signature 
> and the remote's signature (SIGHASH_ALL) after the cltv_expiry timeout. 
> Since the remote party gives them a signature, after the timeout, the 
> offering party can claim with the remote's signature + preimage, but can 
> only spend with the HTLC-timeout transaction because of SIGHASH_ALL. This 
> assumes that the remote party doesn't claim it first. I can't think of 
> any cases where the offering party would know the preimage AND want to 
> force close, so that's why I think it's benign. It does make the witness 
> smaller. The same trick isn't possible with the Received HTLC's due to 
> OP_CHECKLOCKTIMEVERIFY.
>
> Eugene (Crypt-iQ on github)
> ___
> Lightning-dev mailing list
> Lightning-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev