Good morning Rusty,
Someone pointed out to me that `intended_payment_amount` is unnecessary.
On reflection, this is correct.
Both intermediate nodes and the payee node need not have
`intended_payment_amount`.
Therefore
> > I propose the below to support Base AMP.
>
> I think the complexity
Quick correction:
> Thus, the cost to perform the attack would be many orders of
> magnitude greater than the cost to back up one channel.
This was written assuming the attacker was trying to upload multiple encrypted
blobs for the same txid, which seems like an unlikely attack vector if the towe
ZmnSCPxj via Lightning-dev writes:
> Good morning list,
>
> I propose the below to support Base AMP.
I think the complexity outweighs the benefits for the moment. The
sender would have to make the onions identical past the merge point (so
any one of them could be used), the merge point has to no
Hi ZmnSCPxj,
I haven't yet gotten around to writing up everything documenting in the working
watchtower design. However, I think we are nearing that phase where things seem
mostly solidified and would welcome feedback before attempting to formalize it.
Expect some follow up posts on the ML :)
> F
Pierre writes:
> Hi Rusty,
>
>>The feature masks are split into local features (which only
>>affect the protocol between these two nodes) and global features
>>(which can affect HTLCs and are thus also advertised to other
>>nodes).
>
> I don't think that definition
ZmnSCPxj via Lightning-dev writes:
> Thus, I propose:
>
> * The local feature bit `option_i_wumbo_you_wumbo`, which indicates that the
> node is willing to wumbo with its counterparty in the connection.
> * The global feature bit `option_anyone_can_wumbo`, which indicates that the
> node is will
Good morning Margherita,
> In case of a breach while node A is offline, can the Watchtowers do anything?
> In my solution, the function of backup is not destinated to substitute the
> first function of the watchtower, that is monitoring the status channel, but
> instead, the backup option can be
Good morning Conner,
> > MUST NOT forward (if an intermediate node) or claim (if the final node)
> > unless
> > it has received a total greater or equal to `intended_total_payment` in all
> > incoming HTLCs for the same `payment_hash`.
>
> I was under the impression that this would not require ch
Good morning Johan,
Merge nodes will prefer to wait until the entire payment is available and
committed to as HTLCs, before doing any claims.
I believe it was mentioned that one of us figured it out (prior to the summit)
that such a thing was what a merge point would rationally want.
We assume
Hello ZmnSCPxj,
thanks for your e-mail and your feedback, I'll answer your questions in the
following points.
In case of a breach while node A is offline, can the Watchtowers do anything?
In my solution, the function of backup is not destinated to substitute the
first function of the watchtower,
Good morning all,
Taking a step back—even if key switching can be done mathematically, it seems
dubious that we would want to introduce re-routing or rendezvous routing in this
manner. If the example provided _could_ be done, it would directly violate the
wrap-resistance property of the ideal onio
Good morning all,
> MUST NOT forward (if an intermediate node) or claim (if the final node) unless
> it has received a total greater or equal to `intended_total_payment` in all
> incoming HTLCs for the same `payment_hash`.
I was under the impression that this would not require changes on behalf o
Good evening Z and list,
I'm wondering, since these payments are no longer atomic, should we name it
accordingly?
Cheers,
Johan
On Tue, Nov 13, 2018 at 1:28 PM ZmnSCPxj via Lightning-dev <
lightning-dev@lists.linuxfoundation.org> wrote:
> Good morning list,
>
> I propose the below to support Ba
Good morning list,
During the summit, it was asked about an actual application problem for vending
machines without any secret keys (so that hackers of vending machines cannot
steal money from the machine).
It was quite very satisfactorily solved by one of us, and I thought it would
best share
Hi Rusty,
>The feature masks are split into local features (which only
>affect the protocol between these two nodes) and global features
>(which can affect HTLCs and are thus also advertised to other
>nodes).
I don't think that definition makes a lot of sense. For
Good morning list,
I propose the below to support Base AMP.
The below would allow arbitrary merges of paths, but not arbitrary splits. I
am uncertain about the safety of arbitrary splits.
### The `multipath_merge_per_hop` type (`option_base_amp`)
This indicates that payment has been split by
Good morning list,
I would like to propose, to make both a wumbo local AND global feature bit.
The interpretation is to be as follows:
* The local wumbo feature specifically means "I am willing to wumbo with you."
* The global wumbo feature means "I am willing to wumbo with anyone".
The primary
17 matches
Mail list logo
