Joost Jager writes:
>>
>> But Joost pointed out that you need to know the node_id of the next node
>> though: this isn't quite true, since if the node_id is wrong the spec
>> says you should send an `update_fail_malformed_htlc` with failure code
>> invalid_onion_hmac, which node N turns into its
Matt Corallo writes:
> Somehow I missed this thread, but I did note in a previous meeting - these
> issues are great fodder for fuzzing. We’ve had a fuzzer which aggressively
> tests for precisely these types of message-non-delivery-and-resending
> production desync bugs for several years.
>
> But Joost pointed out that you need to know the node_id of the next node
> though: this isn't quite true, since if the node_id is wrong the spec
> says you should send an `update_fail_malformed_htlc` with failure code
> invalid_onion_hmac, which node N turns into its own failure message.
>
> On Apr 20, 2021, at 17:19, Rusty Russell wrote:
>
> After consideration, I prefer alternation. It fits better with the
> existing implementations, and it is more optimal than reflection for
> optimized implementations.
>
> In particular, you have a rule that says you can send updates and
>
Hi all,
You can currently probe for a channel id attached to node N by
sending an HTLC, and seeing whether the error reply comes from the N or
the next hop. The real answer is to get back to blinded paths, BTW.
But Joost pointed out that you need to know the node_id of the next node
The update_fee message does not, as far as I recall, change the dust limit for
outputs in a channel (though I’ve suggested making such a change).
> On Apr 23, 2021, at 12:24, Bastien TEINTURIER wrote:
>
>
> Hi Eugene,
>
> The reason dust HTLCs count for the 483 HTLC limit is because of
Thanks for replying.
I was under the impression that long-term update_fee was going to be
removed since second-level HTLC txn's can bring their own fees?
On Fri, Apr 23, 2021 at 12:24 PM Bastien TEINTURIER
wrote:
> Hi Eugene,
>
> The reason dust HTLCs count for the 483 HTLC limit is because of
Hi Eugene,
The reason dust HTLCs count for the 483 HTLC limit is because of
`update_fee`.
If you don't count them and exceed the 483 HTLC limit, you can't lower the
fee anymore
because some HTLCs that were previously dust won't be dust anymore and you
may end
up with more than 483 HTLC outputs in
Great idea, I'll join as well.
Thanks for setting this in motion.
Le ven. 23 avr. 2021 à 17:39, Antoine Riard a
écrit :
> Hi Jeremy,
>
> Yes dates are floating for now. After Bitcoin 2021, sounds a good idea.
>
> Awesome, I'll be really interested to review again an improved version of
>
I propose a simple mitigation to increase the capital requirement of
channel-jamming attacks. This would prevent an unsophisticated attacker
with low capital from jamming a target channel. It seems to me that this
is a *free* mitigation without any downsides (besides code-writing), so I'd
like to
Hi Jeremy,
Yes dates are floating for now. After Bitcoin 2021, sounds a good idea.
Awesome, I'll be really interested to review again an improved version of
sponsorship. And I'll try to sketch out the sighash_no-input fee-bumping
idea which was floating around last year during pinnings
I'd be excited to join. Recommend bumping the date to mid June, if that's
ok, as many Americans will be at Bitcoin 2021.
I was thinking about reviving the sponsors proposal with a 100 block lock
on spending a sponsoring tx which would hopefully make less controversial,
this would be a great
Hi,
During the lastest years, tx-relay and mempool acceptances rules of the
base layer have been sources of major security and operational concerns for
Lightning and other Bitcoin second-layers [0]. I think those areas require
significant improvements to ease design and deployment of higher
13 matches
Mail list logo
