Hello everyone,
While working on some upgrades to our lightning-onion repo [1],
roasbeef pointed
out that all of our implementations use a quadratic algorithm to
iteratively apply the intermediate blinding factors.
I spent some time working on a linear algorithm that reduces the total
number of s
Hi ZmnSCPxj and Laolu,
> Indeed, the existence of per-hop fees (`fee_base_msat`) means, splitting
the
> payment over multiple flows will be, very likely, more expensive,
compared to
> using a single flow.
As Laolu pointed out, we have yet to see how fees evolve on mainnet or what
will
emerge a
Hi everyone,
I've seen some discussions over losing proofs of payment in the AMP setting,
and wanted to address some lingering concerns I have regarding the
soundness of using the current invoicing system to prove payments.
In general, I think we are ascribing too much weight to simply having a
p
Hi ZmnSCPxj,
> Can you describe the "encrypted blob" approach to me? Or point me to
> materials?
There's an awesome watchtower thread on the mailing list from 2016 that
starts
here [1]. It covers a broader range of possibilities than just the encrypted
blob approach, and also considers other revo
Good evening ZmnSCPxj,
> Also, thank you for the link.
Definitely! I had to do some digging myself to recover these hidden gems.
> I understand. It would be good to know what you have, and perhaps consider
> planning a new BOLT document for such.
Yes, that is the ultimate goal. I think it might
Hi ZmnSCPxj,
> I understand. For myself, I will also wait for comment from other
c-lightning
> developers: this seems to require a bit of surgery on our code I think
> (currently construction of justice transactions is done in a separate
process,
> and we always generate a justice transaction tha
The ability for a watchtower to spend them independently seems to resolve
this*
On Tue, Apr 17, 2018 at 01:30 Conner Fromknecht
wrote:
> Hi ZmnSCPxj,
>
>
> > I understand. For myself, I will also wait for comment from other
> c-lightning
> > developers: this seems to req
Good evening all,
Thank you Rusty for starting us down this path :) and to ZmnSCPxj and Lisa
for
your thoughts. I think this narrows down the design space considerably!
In light of this, and if I'm following along, it seems our hand is forced in
splicing via a single on-chain transaction. In my b
Good morning everyone,
> We could also use SIGHASH_ANYONECANPAY|SIGHASH_SINGLE
> for HTLC txs, without adding the "OP_TRUE"
> output to the commitment transaction
Doesn’t this require a non-zero number of HTLCs on the commitment txn? We
would still require the OP_TRUE if there are no HTLCs, right
also has the transaction. Until a splice does confirm, a node has
to store multiple potential splice outpoints. Seeing this, it seems to me
that
backward looking announcements are less susceptible to abuse and DOS in
this regard.
Thoughts?
Cheers,
Conner
On Thu, Oct 18, 2018 at 8:04 PM Conner Fromk
> How do i unsubscribe from this email list? Could someone help me please.
There’s a link in the footer to the linux list, there you can enter your
email to unsubscribe
Cheers,
Conner
-- Sent from my Spaceship
On Fri, Nov 9, 2018 at 17:19 alexis petropoulos
wrote:
> How do i unsubscribe from
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 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
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
if the tower
inherently defends against it. If instead they are just trying to fill
up the tower, the cost
is linear in the amount of blobs they send.
--Conner
On Tue, Nov 13, 2018 at 4:12 PM Conner Fromknecht
wrote:
>
> Hi ZmnSCPxj,
>
> I haven't yet gotten around to writing up ev
Hi ZmnSCPxj,
Thanks for writing this up! I had started an email, but you beat me to it :)
> 1. For a sequence of `type,len,value`, each `type` must be unique. --
> accepted.
To add to this, it seemed that there was some agreement that repeated fields
should be serialized under a single root key
Hi ZmnSCPxj,
Precisely, something like that is what I had in mind.
Since the max message size is 65KB, one option could be to only allow
the varint to
be max 2 bytes where:
- if the 8th bit is not set, the lowest 7 bits of the first bytes
translate to 0 - 127
- if the 8th bit is set, this impli
Hi all,
> But it's unnecessary for the recipient to know the total amount I meant
> to pay; they just need to return the receipt once it exceeds the amount
> they want.
I think it’s true that the recipient doesn’t need to know necessarily, but
sending the intended amount is more robust IMO, since
Hi Paberlance,
As ZmnSCPxj mentioned, it should be possible to so after TLV and related
dependencies are finalized.
However I don’t think embedding an invoice in the onion is the most
efficient way to do this. Once a spontaneous payments protocol is
established, it should be sufficient to embed,
Hi all,
I recently revisited the eltoo paper and noticed some things related
watchtowers that might affect channel construction.
Due to NOINPUT, any update transaction _can_ spend from any other, so
in theory the tower only needs the most recent update txn to resolve
any dispute.
In order to spe
Good evening,
> I didn't think this was the design. The update transaction can spend any
prior, with a fixed script, due to NOINPUT.
>From my reading of the final construction, each update transaction has a
unique script to bind settlement transactions to exactly one update.
> My understanding
/lnd/blob/master/docs/INSTALL.md#installing-lnd.
Regards,
Conner Fromknecht
-BEGIN PGP SIGNATURE-
iQIzBAEBCAAdFiEEnI1hhop8SSADsnRO59c3tn+lkscFAl9/ozwACgkQ59c3tn+l
kscVvBAAk21z6tlHPkOSwfj1lBE0pqc65A6Qa927WEjN5hdUpjjof4Xo2j+GzbnN
Uoj4HGZu+koakzoVpJ4mzN+vg086zAnv+K668hhl7bbPHsQu6FqA1ALiAyy0nH6H
ble
check the plaintext matches
verbatim with what was sent on lightning-dev.
Cheers,
Conner
On Thu, Oct 8, 2020 at 5:19 PM Conner Fromknecht
wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Hi all,
>
> We are writing to let the Lightning community know abou
and for helping to
make lnd more safu. More information can be found in Antoine’s disclosure [5].
Regards,
Conner Fromknecht
-BEGIN PGP SIGNATURE-
iQIzBAEBCAAdFiEEnI1hhop8SSADsnRO59c3tn+lkscFAl+PWzMACgkQ59c3tn+l
kseIJw//UwswUyh6BNgmi4D8NoC6olelW0dRmecqcZF7J
d2cd3ba24fdc18ccc8c5c6eb4
Huge thanks to Antoine Riard for the responsible disclosure and for helping to
make lnd more safu. More information can be found in Antoine’s disclosure [5].
Regards,
Conner Fromknecht
-BEGIN PGP SIGNATURE-
iQIzBAEBCAAdFiEEnI1hhop8SSADsnRO59c3tn+lkscFAl
25 matches
Mail list logo
