Good morning Joost and Z,
So in your proposal, an htlc that is received by a routing node has the
> following properties:
> * htlc amount
> * forward up-front payment (anti-spam)
> * backward up-front payment (anti-hold)
> * grace period
> The routing node forwards this to the next hop with
> * lo
Hey Joost and Z,
I brought up the question about the amounts because it could be that
> amounts high enough to thwart attacks are too high for honest users or
> certain uses.
I don't think this is a concern for this proposal, unless there's an attack
vector I missed.
The reason I claim that is t
Thanks for your answers,
My first instinct is that additional complications are worse in general.
> However, it looks like simpler solutions are truly not enough, so adding
> the complication may very well be necessary.
I agree with both these statements ;). I'd love to find a simpler solution,
Good morning list,
Sorry in advance for the lengthy email, but I think it's worth detailing my
hybrid proposal
(bidirectional upfront payments), it feels to me like a workable solution
that builds on
previous proposals. You can safely ignore the details at the end of the
email and focus only on
th
Good morning list,
I've started summarizing proposals, attacks and threat models on github [1].
I'm hoping it will help readers get up-to-speed and avoid falling in the
same pitfalls we already
fell into with previous proposals.
I've kept it very high-level for now; we can add nitty-gritty techni
To be honest the current protocol can be hard to grasp at first (mostly
because it's hard to reason
about two commit txs being constantly out of sync), but from an
implementation's point of view I'm
not sure your proposals are simpler.
One of the benefits of the current HTLC state machine is that
Hey laolu,
I think this fits in nicely with the "parameter re-negotiation" portion of
> my
> loose Dynamic commitments proposal.
Yes, maybe it's better to not offer two mechanisms and wait for dynamic
commitments to offer that
flexibility.
Instead, you may
> want to only allow them to utilize s
ase
> cost of needing to go to chain with a "fully loaded" commitment
> transaction.
> Even with HTLCs, they could only be signed at 1 sat/byte from the funder's
> perspective, once again putting the burden on the broadcaster/confirmer to
> make up the difference.
>
Good morning,
For instance, Tor is basically two-layer: there is a lower-level TCP/IP
> layer where packets are sent out to specific nodes on the network and this
> layer is completely open about where the packet should go, but there is a
> higher layer where onion routing between nodes is used.
>
Hey Zman,
raising the minimum payment size is another headache
>
It's true that it may (depending on the algorithm) lower the success rate
of MPP-split.
But it's already a parameter that node operators can configure at will (at
channel creation time),
so IMO it's a complexity we have to deal with
TLC block-buffer-before-onchain is higher
> than the cost of going onchain. It should cost higher for the counterparty
> to withhold a HTLC than paying onchain-fees to close the channel.
>
> Or can you think about another mitigation for the issue raised above ?
>
> Antoine
&g
Good morning Antoine and Zman,
Thanks for your answers!
I was thinking dynamic policy adjustment would be covered by the dynamic
> commitment mechanism proposed by Laolu
I didn't mention this as I think we still have a long-ish way to go before
dynamic commitments
are spec-ed, implemented and d
If I remember correctly, it looks very similar to how I2P establishes
tunnels, it may be worth
diving in their documentation to fish for ideas.
However in their case the goal is to establish a long-lived tunnel, which
is why it's ok to have
a slow and costly protocol. It feels to me that for payme
Hi darosior,
This is true, but we haven't solved yet how to estimate a good enough
`min_relay_fee` that works
for end-to-end tx propagation over the network.
We've discussed this during the last two spec meetings, but it's still
unclear whether we'll be able to solve
this before package-relay lan
Good morning list,
It seems to me that the "funder pays all the commit tx fees" rule exists
solely for simplicity
(which was totally reasonable). I haven't been able to find much discussion
about this decision
on the mailing list nor in the spec commits.
At first glance, it's true that at the beg
Good evening list,
Recent discussions around channel jamming [1] have highlighted again the
need to think twice when
configuring your channels parameters. There are currently parameters that
are set once at channel
creation that would benefit a lot from being configurable throughout the
lifetime o
Thanks for sharing this, I think it's the right time to start experimenting
with
that kind of feature (especially in the light of Taproot and the package
relay
work / pinning transactions issue).
we can start to experiment with flow-control like
> ideas such as limiting a new channel peer to only
Hey ZmnSCPxj,
I agree that in theory this looks possible, but doing it in practice with
accurate control
of what parts of the network get what tx feels impractical to me (but maybe
I'm wrong!).
It feels to me that an attacker who would be able to do this would break
*any* off-chain
construction t
Thanks for the detailed write-up on how it affects incentives and
centralization,
these are good points. I need to spend more time thinking about them.
This is one reason I suggested using independent pay-to-preimage
> transactions[1]
>
While this works as a technical solution, I think it has som
Hello Dave and list,
Thanks for your quick answers!
The attacker would be broadcasting the latest
> state, so the honest counterparty would only need to send one blind
> child.
>
Exactly, if the attacker submits an outdated transaction he would be
shooting himself in the foot,
as we could claim
Good morning list,
Sorry for being (very) late to the party on that subject, but better late
than never.
A lot of ideas have been thrown at the problem and are scattered across
emails, IRC discussions,
and github issues. I've spent some time putting it all together in one
gist, hoping that it wil
Hi Antoine and list,
Thanks for raising this. There's one step I'd like to understand further:
* Mallory can broadcast its Pinning Preimage Tx on offered HTLC #2 output
> on Alice's transaction,
> feerate is maliciously chosen to get in network mempools but never to
> confirm. Absolute fee must
>
Good morning list,
In Bolt 11 we decided to use bech32 to encode lightning invoices.
While bech32 has some nice properties, it isn't well suited for invoices.
The main drawback of Bolt 11 invoices is their size: when you start adding
routing hints or rendezvous onions, invoices become huge and har
Good morning ZmnSCPxj,
Ok I see what you mean. In that case it would be slightly different from
the current path blinding proposal.
The recipient would need to give the sender all the blinding points for
each hop in the blinded path.
Currently the recipient only gives one blinding point and then e
Good morning list,
Thanks Rusty for following up on this, I'm glad it may be useful for offers!
I certainly want this as well for wallet users' privacy.
I have gathered my proposal in a better format than my previous gist here:
https://github.com/lightningnetwork/lightning-rfc/blob/route-blinding
revisit it a couple of
> times before opening a PR, but feel free to shout at me if I have
> forgotten to consider something :-)
>
> Cheers,
> Christian
>
> [1]
> https://github.com/lightningnetwork/lightning-rfc/blob/rendez-vous/proposals/0001-rendez-vous.md
> [2] https
Good morning list,
After exploring decoys [1], which is a cheap way of doing route blinding,
I'm turning back to exploring rendezvous.
The previous mails on the mailing list mentioned that there was a
technicality
to make the HMACs check out, but didn't provide a lot of details.
The issue is that
27 matches
Mail list logo
