[Lightning-dev] CVE-2020-26895: LND Low-S Tx-Relay Standardness

2020-10-20 Thread Conner Fromknecht
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+PWykACgkQ59c3tn+l ksf7Yg

[Lightning-dev] CVE-2020-26896: LND Invoice Preimage Extraction

2020-10-20 Thread Conner Fromknecht
ping 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//UwswUyh6BNgmi4D8NoC6olelW0dRmecqcZF7JBQa619kVFm/D7ri

Re: [Lightning-dev] Partial LND Vulnerability Disclosure, Upgrade to 0.11.x

2020-10-09 Thread Conner Fromknecht
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

[Lightning-dev] Partial LND Vulnerability Disclosure, Upgrade to 0.11.x

2020-10-08 Thread Conner Fromknecht
/lnd/blob/master/docs/INSTALL.md#installing-lnd. Regards, Conner Fromknecht -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEnI1hhop8SSADsnRO59c3tn+lkscFAl9/ozwACgkQ59c3tn+l kscVvBAAk21z6tlHPkOSwfj1lBE0pqc65A6Qa927WEjN5hdUpjjof4Xo2j+GzbnN Uoj4HGZu+koakzoVpJ4mzN+vg086zAnv+K668hhl7bbPHsQu6FqA1ALiAyy0nH6H

Re: [Lightning-dev] eltoo towers and implications for settlement key derivation

2019-12-02 Thread Conner Fromknecht
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

[Lightning-dev] eltoo towers and implications for settlement key derivation

2019-11-26 Thread Conner Fromknecht
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

Re: [Lightning-dev] type,len,value standard

2018-11-15 Thread Conner Fromknecht
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

Re: [Lightning-dev] type,len,value standard

2018-11-14 Thread Conner Fromknecht
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

Re: [Lightning-dev] Trustless Watchtowers

2018-11-13 Thread Conner Fromknecht
vector 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 ever

Re: [Lightning-dev] Trustless Watchtowers

2018-11-13 Thread Conner Fromknecht
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 :) >

Re: [Lightning-dev] Link-level payment splitting via intermediary rendezvous nodes

2018-11-13 Thread Conner Fromknecht
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

Re: [Lightning-dev] Base AMP

2018-11-13 Thread Conner Fromknecht
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

Re: [Lightning-dev] RFC: simplifications and suggestions on open/accept limits.

2018-11-09 Thread Conner Fromknecht
> 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

Re: [Lightning-dev] Splicing Proposal: Feedback please!

2018-10-22 Thread Conner Fromknecht
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 Fromknecht wrote:

Re: [Lightning-dev] Commitment Transaction Format Update Proposals?

2018-10-20 Thread Conner Fromknecht
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,

Re: [Lightning-dev] Trustless WatchTowers?

2018-04-17 Thread Conner Fromknecht
The ability for a watchtower to spend them independently seems to resolve this* On Tue, Apr 17, 2018 at 01:30 Conner Fromknecht <conner@lightning.engineering> wrote: > Hi ZmnSCPxj, > > > > I understand. For myself, I will also wait for comment from other > c-lightning &g

Re: [Lightning-dev] Trustless WatchTowers?

2018-04-17 Thread Conner Fromknecht
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

Re: [Lightning-dev] Trustless WatchTowers?

2018-04-17 Thread Conner Fromknecht
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

Re: [Lightning-dev] Trustless WatchTowers?

2018-04-16 Thread Conner Fromknecht
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

Re: [Lightning-dev] AMP: Atomic Multi-Path Payments over Lightning

2018-02-12 Thread Conner Fromknecht
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