Re: [Lightning-dev] An Argument For Single-Asset Lightning Network

2019-01-05 Thread Lloyd Fournier
Hi David and ZmnSCPxj, ZmnSCPxj, Thanks for your response. I messed something up with my response so my original post didn't get into the archive. I put it in a gist: https://gist.github.com/LLFourn/d0afa6b37207aed7cd73f6b9203c0def for reference. > I agree. > When I was developing American Call

Re: [Lightning-dev] An Argument For Single-Asset Lightning Network

2019-01-07 Thread Lloyd Fournier
Happy new year lightning-dev! This topic is my main area of research at moment so I'm really happy to see a thread about it. In general I agree with ZmnSCPxj's analysis and conclusions. I'd like to add a couple of ideas to this discussion and would greatly appreciate some early peer review on

Re: [Lightning-dev] An Argument For Single-Asset Lightning Network

2019-05-19 Thread Lloyd Fournier
of-of-payment secrets (such as > the offline vending machine discussed before) from working correctly. > > Regards, > ZmnSCPxj > > > Sent with ProtonMail Secure Email. > > ‐‐‐ Original Message ‐‐‐ > On Saturday, May 4, 2019 4:28 AM, Lloyd Fournier > wrote: >

Re: [Lightning-dev] An Argument For Single-Asset Lightning Network

2019-05-03 Thread Lloyd Fournier
Hi ZmnSCPxj, I'm glad you pointed this out. I think this protocol is practical. That talk was actually given by my colleague :). My post in the December thread was trying to explain the same idea but as a [A -> Exchange -> A] on-chain trade (rather than a [A -> Exchange -> B] cross chain L2

Re: [Lightning-dev] Selling Signatures: Another Reason to Move to Payment Points

2019-07-17 Thread Lloyd Fournier
Hi Nadav, This is cool idea. I always imagined oracles would either give their DLC signatures away for free or work via a subscription model. The downside to this proposal is that the seller of the signature knows which signature they're selling and therefore learns what kind of contract the

Re: [Lightning-dev] Paper: A Composable Security Treatment of the Lightning Network

2019-07-17 Thread Lloyd Fournier
Hi Orfeas, Thanks for formally modelling lightning and posting your paper here. I've taken a brief look at the paper so far. I am a UC novice and have no academic background so please take that into account when interpreting my comments. In general, I am glad that you are taking the approach to

Re: [Lightning-dev] Selling Signatures: Another Reason to Move to Payment Points

2019-07-17 Thread Lloyd Fournier
Ts be 3-of-3 multisig > outputs. In this way the oracle is still not learning about the contract, > just like normal DLCs. > > Best, > Nadav > > On Wed, Jul 17, 2019 at 11:23 AM Lloyd Fournier > wrote: > >> Hi Nadav, >> >> This is cool idea. I always imagin

Re: [Lightning-dev] Selling timestamps (via payment points and scalars + Pedersen commitments ) [try2]

2019-09-25 Thread Lloyd Fournier
This is a nice scheme. Pedersen commitments + pay to point seems to be the most practical way to do it but you can generalise this paying for a decommitment idea to any commitment scheme. For example, you could do this in a payment channel with hashes if we had something like OP_CAT. e.g HTLC

Re: [Lightning-dev] A Payment Point Feature Family (MultiSig, DLC, Escrow, ...)

2019-10-10 Thread Lloyd Fournier
Hi Nadav, I've thought about similar problems before. Essentially you are trying to create an "access structure" on discrete logarithm (the completion of the adaptor signature in "pay-to-point"). I think the term for arbitrary combinations of AND and ORs and even N-of-M is called a *monotone

Re: [Lightning-dev] A Payment Point Feature Family (MultiSig, DLC, Escrow, ...)

2019-10-10 Thread Lloyd Fournier
Hi ZmnSCPxj, > I think, it is possible to make, a miniscript-like language for such things. > Indeed, the only material difference, between SCRIPT-based `OP_CHECKSIG`s and Lightning, would be the requirement to reveal scalars rather than prove your knowledge of them. I've thought about this too.

Re: [Lightning-dev] Lightning in a Taproot future

2019-12-17 Thread Lloyd Fournier
Hi ZmnSCPxj and Aj, Thanks for starting this discussion ZmnSCPxj. Although transactions with relative lock times are easily distinguishable today, couldn't this situation be improved? Even just a few wallets changing their behaviour to set relative time locks on normal payments would weaken the

Re: [Lightning-dev] Locking of funds by both parties in HTLC to enforce penalty

2020-03-05 Thread Lloyd Fournier
ocal HTLC, won't B put the same clause on C > as well so that in case C misbehaves it is able to spool out the penalty > for the rest of the path from C itself ? > > On Fri, Mar 6, 2020 at 12:00 PM Lloyd Fournier > wrote: > >> Hi Subhra, >> >> Afaik, the only pro

Re: [Lightning-dev] Locking of funds by both parties in HTLC to enforce penalty

2020-03-05 Thread Lloyd Fournier
Hi Subhra, Afaik, the only problem is the one you identified, it doesn't work across multiple hops but only for the final hop. This penalty idea is the basis for doing atomc swaps fairly: https://coblox.tech/docs/financial_crypto19.pdf LL On Fri, Mar 6, 2020 at 4:58 PM Subhra Mazumdar <

Re: [Lightning-dev] Locking of funds by both parties in HTLC to enforce penalty

2020-03-05 Thread Lloyd Fournier
(on channel AB): both A and B lock say 0.1 BTC each i.e. 0.2 > BTC > 2. HTLC A (on channel AB) : A locks 0.1 BTC, HTLC B (on channel BA): B > locks 0.1 BTC > > Pardon me if I am wrong but I am still confused why situation 1 will not > be possible ? > > On Fri, Mar 6, 2020 at

Re: [Lightning-dev] An update on PTLCs

2020-04-28 Thread Lloyd Fournier
Hi Laolu, >From my PoV, new technologies aren't what has held back DLC deployment to > this date since the paper was originally released. Tadge has had working > code than can be deployed today for some time now, and other parties like > DG-Lab have created full-fledge demos with the system

Re: [Lightning-dev] DLC channels and integration in the Lightning Network

2020-04-29 Thread Lloyd Fournier
Hi Thibaut, Thanks for carrying out this research. I have not finished reading the paper but have a question about what you call the "straw man" proposal early on: "At the end of this protocol, both Alice and Bob have the set of signed transactions for the second DLC, and the transactions for

Re: [Lightning-dev] [bitcoin-dev] On the scalability issues of onboarding millions of LN mobile clients

2020-05-05 Thread Lloyd Fournier
On Tue, May 5, 2020 at 9:01 PM Luke Dashjr via bitcoin-dev < bitcoin-...@lists.linuxfoundation.org> wrote: > On Tuesday 05 May 2020 10:17:37 Antoine Riard via bitcoin-dev wrote: > > Trust-minimization of Bitcoin security model has always relied first and > > above on running a full-node. This

Re: [Lightning-dev] Witness asymmetric payment channels

2020-08-31 Thread Lloyd Fournier
Hi Z, Thanks as usual for your thoughtful comments I agree with you that there is no improvement in complexity in the formal sense. I do believe it is an improvement in conceptual complexity. At least, I am able to keep all the moving parts in my head at the same time whereas I struggle

Re: [Lightning-dev] Witness asymmetric payment channels

2020-09-09 Thread Lloyd Fournier
> > > Fortunately, I am wrong. At least in the case of non-aggregated 2-of-2 you > can deterministically produce the encrypted signature by yourself for any > commitment transaction as long as you use a deterministic nonce. > But I think if using MuSig you would need to store each two party >

Re: [Lightning-dev] Witness asymmetric payment channels

2020-09-01 Thread Lloyd Fournier
> Unfortunately, while thinking about the above statement I realised > there is worse storage complexity. > In order to punish a revoked commitment transaction efficiently you > need to extract the publication secret. > But in order to do that you need to keep around the encrypted > signature

[Lightning-dev] two-round MuSig less dangerous than it seems

2020-10-08 Thread Lloyd Fournier
Hi list, tl;dr: I think can use two round MuSig safely in the context of lightning. As a recap, Zeeman did a good evaluation of "purely scriptless" lightning channels after taproot/schnorr.[1] Z concluded that even in the most optimized case the 3 round MuSig protocol leads to an extra round of

Re: [Lightning-dev] two-round MuSig less dangerous than it seems

2020-10-10 Thread Lloyd Fournier
tless" lightning with the same number of rounds as today before forwarding the payment is correct. Cheers, LL On Fri, Oct 9, 2020 at 3:31 PM Lloyd Fournier wrote: > Hi list, > > tl;dr: I think can use two round MuSig safely in the context of lightning. > > As a recap, Zee

Re: [Lightning-dev] Witness asymmetric payment channels

2020-10-07 Thread Lloyd Fournier
primitive. This allows for O(1) storage complexity in both key aggregated and "multisig" constructions. LL On Thu, Sep 10, 2020 at 1:56 PM Lloyd Fournier wrote: > > >> >> >> Fortunately, I am wrong. At least in the case of non-aggregated 2-of-2 you >> can

[Lightning-dev] Witness asymmetric payment channels

2020-08-25 Thread Lloyd Fournier
# Abstract This is a proposal for a new channel symmetric channel construction that uses the key idea from a recent paper called "Generalized Bitcoin-Compatible Channels"[1] and tries to practically apply it to lightning. If you prefer, you can read the rendered markdown version here:

Re: [Lightning-dev] Mitigating Channel Jamming with Stake Certificates

2020-11-29 Thread Lloyd Fournier
Hi Gleb et al, I really appreciate the out-of-the-box thinking of this proposal. I will put to the side the very difficult task of creating a cryptosystem that efficiently achieves what's necessary for this to work because that seems not to be the main concern. I agree with Z that this proposal

Re: [Lightning-dev] Mitigating Channel Jamming with Stake Certificates

2020-12-01 Thread Lloyd Fournier
> Loop attacks are not about loops, it only requires that the start and end of a payment are controlled by the same entity Thanks for clearing that up. I was referring to cycles in the payment paths where you get honest parties to forward your HTLC between themselves over and over again as part

Re: [Lightning-dev] Recovery of Lightning channels without backups

2020-12-08 Thread Lloyd Fournier
> Create a static channel backup after the fact. I have dubbed this a > synthetic static channel backup. I only use it to trigger the data loss > protection protocol. > By restoring this synthetic SCB a `channel_reestablish` is being sent to > the remote peer. This `channel_reestablish`contains

Re: [Lightning-dev] Recovery of Lightning channels without backups

2020-12-09 Thread Lloyd Fournier
On Wed, Dec 9, 2020 at 4:26 PM Rusty Russell wrote: > > Say r1=SHA256(ss || counter || 0), r2 = SHA256(ss || counter || 1)? > > Nice work. This would be a definite recovery win. We should add this > to the DF spec, because Lisa was almost finished implmenting it, so it's > clearly due for a

Re: [Lightning-dev] Mitigating Channel Jamming with Stake Certificates

2020-11-30 Thread Lloyd Fournier
produce stake certificates galore and lock up channels anyway. I don't see much of a way around this other than reputation systems. LL > > – gleb > On Nov 30, 2020, 6:39 AM +0200, Lloyd Fournier , > wrote: > > Hi Gleb et al, > > I really appreciate the out-of-the-box

Re: [Lightning-dev] Covert channel recovery with Oblivious Signatures

2020-12-17 Thread Lloyd Fournier
> I suspect part of the proof-of-discrete-log-equivalance can be gated as well by a ZKCP on payment point+scalar the proof is provided only on payment. > The selling node operator does not even need to reveal `z`. Actually no -- the fact that you were able to create a secure conditional payment

Re: [Lightning-dev] Covert channel recovery with Oblivious Signatures

2020-12-17 Thread Lloyd Fournier
On Thu, Dec 17, 2020 at 1:56 AM ZmnSCPxj wrote: > A common occurrence is that hardware failure is not detected until when the hardware is used, especially when used by casual users. > > Consider the sequence of events: > > * Part of the storage device fails. > * Due to being a casual user, the

[Lightning-dev] Covert channel recovery with Oblivious Signatures

2020-12-10 Thread Lloyd Fournier
Hi list, Currently, if your lightning node has data loss there are two ways of recovering your funds once you have established which channels you had with which peers: 1. Wait until your peer closes the channel. The downside is that you have no control over when this happens. 2. Connect to your

Re: [Lightning-dev] Covert channel recovery with Oblivious Signatures

2020-12-19 Thread Lloyd Fournier
On Sat, Dec 19, 2020 at 6:48 PM ZmnSCPxj wrote: > Good morning LL, > > > > I suspect part of the proof-of-discrete-log-equivalance can be gated > as well by a ZKCP on payment point+scalar the proof is provided only on > payment. > > > The selling node operator does not even need to reveal `z`. >

Re: [Lightning-dev] Covert channel recovery with Oblivious Signatures

2020-12-15 Thread Lloyd Fournier
Hey Z, On Tue, Dec 15, 2020 at 9:21 PM ZmnSCPxj wrote: > > Good morning LL, > > > > - What do you do if the channel state has HTLCs in flight? I don't know -- > > I guess you can just put them onto the settlement tx? That way it's > > possible the payment could still go through. Alternatively

Re: [Lightning-dev] Covert channel recovery with Oblivious Signatures

2020-12-14 Thread Lloyd Fournier
> It seems difficult to recommend YOLO commitment transactions becoming the standard way to recover funds. It could be preferable to the current system but even that is up for debate I guess. > I feel like I can recommend oblivious settlements because (i) it's covert (like YOLO commitments txs

Re: [Lightning-dev] Covert channel recovery with Oblivious Signatures

2020-12-14 Thread Lloyd Fournier
Errr please replace 5 with 4 in the previous post. Thanks to devrandom. LL On Tue, Dec 15, 2020 at 2:43 PM Lloyd Fournier wrote: > > > It seems difficult to recommend YOLO commitment transactions becoming the > > standard way to recover funds. It could be preferable to the

Re: [Lightning-dev] PoDLEs revisited

2021-01-08 Thread Lloyd Fournier
Rusty, Zman, A concern I have with only doing one signaling transaction out of the whole group of inputs is that it means you don't prove ownership of the other inputs. I am not exactly sure what you could do by adding inputs from the chain you don't own but it does feel a bit risky. Perhaps it

Re: [Lightning-dev] PoDLEs revisited

2021-01-14 Thread Lloyd Fournier
On Wed, Jan 13, 2021 at 11:54 AM Rusty Russell wrote: > Lloyd Fournier writes: > > Rusty, Zman, > > > > A concern I have with only doing one signaling transaction out of the > whole > > group of inputs is that it means you don't prove ownership of the other > &

Re: [Lightning-dev] Covert channel recovery with Oblivious Signatures

2020-12-13 Thread Lloyd Fournier
Hi Dave, Thanks for taking a read. You brought up really good points that need addressing. This is really cool! However, I don't understand why it's needed. Your > goal seems to be for the sender to provide the commitment transaction > and signatures before he learns whether the receiver

Re: [Lightning-dev] PoDLEs revisited

2021-01-27 Thread Lloyd Fournier
On Wed, Jan 20, 2021 at 12:34 PM Rusty Russell wrote: > > > Yes, sorry. I assumed immediate broadcast + 60 second wait for > conflicts. It's this scheme I was trying to shoehorn into the mempool > (broadcast signalling tx, wait, try to RBF it with a real open). But > there are three problems

Re: [Lightning-dev] PoDLEs revisited

2021-02-02 Thread Lloyd Fournier
On Fri, Jan 29, 2021 at 10:51 AM Rusty Russell wrote: > Less true after taproot though? > The heuristic from [1] is not affected by Taproot. Taproot will be helpful for keeping private channels private against the method in [2] though. > [1] https://arxiv.org/abs/2007.00764 > > [2]

Re: [Lightning-dev] Improving Payment Latency by Fast Forwards

2021-06-12 Thread Lloyd Fournier
Hi Z, Thanks again for getting to the bottom of this. I think we are on the same page except for one clarification: On Tue, 8 Jun 2021 at 12:37, ZmnSCPxj wrote: > Thus, in our model, we have the property that Bob can always recover all > signatures sent by Alice, even if Carol is corrupted by

Re: [Lightning-dev] Improving Payment Latency by Fast Forwards

2021-06-01 Thread Lloyd Fournier
Hi Z, I just went through the presentation which made your thinking very clear. Thanks. I will not be able to match this effort so please bear with me as I try and explain my own thinking. I don't see why fast forwards (FF) need "symmetrically encumbered outputs"? To me the protocol should be

Re: [Lightning-dev] Improving Payment Latency by Fast Forwards

2021-05-23 Thread Lloyd Fournier
Hey Z, Thanks for your analysis. I agree with your conclusion. I think the most practical approach is the "ask first" 3 round protocol. Another option is to have `remote_penaltyclaimpubkey` owned by the node instead of the hardware device. This allows funds to accrue in the fast forward state

Re: [Lightning-dev] Improving Payment Latency by Fast Forwards

2021-06-06 Thread Lloyd Fournier
Hi Z, I agree with your analysis. This is how I pictured eltoo fast forwards working as well. Another interesting thing about this idea is that it could allow a new type of custodial LN provider where the custodian is only in charge of receiving payments to the channel but cannot spend them.

Re: [Lightning-dev] Recovery of Lightning channels without backups

2021-05-02 Thread Lloyd Fournier
On Thu, 29 Apr 2021 at 06:15, David A. Harding wrote: > why can't she sign a message that gets gossiped across the network that > says, "if you have a channel with node_id 0xa11ce, please close it now"? > Hi David, As a user this would be an improvement. There are a few downsides though: 1.

Re: [Lightning-dev] Recovery of Lightning channels without backups

2021-04-27 Thread Lloyd Fournier
Hey Rusty, Thoughts on each point below. On Fri, 23 Apr 2021 at 14:29, Rusty Russell wrote: > OK, I'm now leaning *against* this method. > > 1. It removes the ability to update a channel without access to the node's >secret key. At the moment the node secret key is only needed for >

Re: [Lightning-dev] Recovery of Lightning channels without backups

2021-04-27 Thread Lloyd Fournier
On Wed, 28 Apr 2021 at 09:36, Lloyd Fournier wrote: > I wonder if it is even necessary to bump the generation until a funding > tx is confirmed -- I can't think of a good reason why you would want to > open two channels to the same node at the same time (why not put all you

Re: [Lightning-dev] Recovery of Lightning channels without backups

2021-05-03 Thread Lloyd Fournier
On Mon, 3 May 2021 at 22:58, David A. Harding wrote: > On Mon, May 03, 2021 at 11:01:48AM +1000, Lloyd Fournier wrote: > > 2. It is not easy to figure out whether it worked or not > > Good point. > > > 3. This is incompatible with covert recovery schemes like in [

Re: [Lightning-dev] Pay-for-Elgamal-decryption-key and its application to Anonymous Credentials

2021-02-04 Thread Lloyd Fournier
Hi Miyamoto, Very interesting idea :) Usually when dealing with anonymous credentials you are necessarily dealing with a trusted third party so it's fine to just make a normal payment and then receive the credential after successfully paying. But I see the advantage of your idea. If a malicious

Re: [Lightning-dev] Recovery of Lightning channels without backups

2021-04-19 Thread Lloyd Fournier
Hi Rusty, On Tue, 20 Apr 2021 at 10:55, Rusty Russell wrote: > Lloyd Fournier writes: > > On Wed, Dec 9, 2020 at 4:26 PM Rusty Russell > wrote: > > > >> > >> Say r1=SHA256(ss || counter || 0), r2 = SHA256(ss || counter || 1)? > >> > >>

Re: [Lightning-dev] Questions on lightning chan closure privacy

2021-04-17 Thread Lloyd Fournier
Hi Lee, You are touching on some very relevant privacy challenges for lightning. To your questions: 1. Is it possible to identify which node funded a lightning channel? (this tells you who owns the change output) 2. Is it possible to identify who owns which channel close output? I think that

Re: [Lightning-dev] Lightning over taproot with PTLCs

2021-10-12 Thread Lloyd Fournier
On Tue, 12 Oct 2021 at 14:08, Anthony Towns wrote: > > If you're willing to accept that "worst case" happening more often, I > think you could then retain the low latency forwarding, by having the > transaction structure be: > > commitment tx > input: > funding tx > outputs: >

Re: [Lightning-dev] Deriving channel keys deterministically from seed, musig, and channel establishment v2

2021-10-13 Thread Lloyd Fournier
Hi SomberNight, I started a similar discussion less than a year ago on the list. The idea I put forward works fine with MuSig and taproot. https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-December/002907.html The idea was considered for channel establishment v2 but in the end

Re: [Lightning-dev] Lightning over taproot with PTLCs

2021-10-11 Thread Lloyd Fournier
On Mon, 11 Oct 2021 at 9:23 pm, Lloyd Fournier wrote: > > Adjust the protocol so that you reciprocate the in-flight txs. So when I > offer you a HTLC you first forward it and then lazily send me the signature > for the inflight tx. Therefore I dont have to wait to get the H

Re: [Lightning-dev] Lightning over taproot with PTLCs

2021-10-11 Thread Lloyd Fournier
Hey aj, This is awesome work. My line of research on "witness asymmetric channels" essentially ended up in a dead end because I couldn't see how they were much better than naive PTLC lightning. The idea I really liked from it was "revocable signatures". I hoped someone would eventually figure out

Re: [Lightning-dev] Lightning over taproot with PTLCs

2021-10-11 Thread Lloyd Fournier
On Mon, 11 Oct 2021 at 17:30, Anthony Towns wrote: > > I don't think the layering here quite works: if Alice forwarded a payment > to Bob, with timeout T, then the only way she can be sure that she can > either reclaim the funds or know the preimage by time T is to close the > channel on-chain

Re: [Lightning-dev] PTLCs early draft specification

2021-12-06 Thread Lloyd Fournier
I was thinking along the same lines as Z. With MuSig2 and pre-sharing of signature nonces it should stay three rounds and share a similar structure. On Tue, 7 Dec 2021 at 11:08, ZmnSCPxj via Lightning-dev < lightning-dev@lists.linuxfoundation.org> wrote: > > Basically, if my memory and

Re: [Lightning-dev] PTLCs early draft specification

2021-12-08 Thread Lloyd Fournier
Hi thread, I was indeed mistaken. It does require four rounds for both parties to fully transition to the next comimit tx and I don't think there is any easy way around this. As you've pointed out there it's still only three rounds before the message is forwarded so no performance decrease for