Dear Jesse & Z,
I believe this kind of scheme is of crucial importance. I think if we're
serious about bridging layer-1 and layer-2 systems transparently for users,
wallets must be able to give out addresses that are covert channel openings
without the sender's knowledge. e.g. I should be able to
Hi g0b1e,
I wanted to add to this excellent summary that there is a trade off here.
The harder you make payment correlation the easier you make channel
jamming. If payments can not be correlated at all it's possible to make
payment paths that cycle through the same nodes many times over. This
allo
Hi AJ,
On Wed, 20 Sept 2023 at 17:19, Anthony Towns wrote:
>
> I think:
>
> https://github.com/BlockstreamResearch/scriptless-scripts/pull/24
>
> describes (w/ proof sketch) how to do a single-signer adaptor with musig2;
> might need some updates, to match the final musig2 API, but I think it'
u, 21 Sept 2023 at 11:56, Anthony Towns wrote:
> On 21 September 2023 11:44:47 am AEST, Lloyd Fournier <
> lloyd.fo...@gmail.com> wrote:
> >Hi AJ,
> >
> >On Wed, 20 Sept 2023 at 17:19, Anthony Towns wrote:
> >
> >>
> >> I think:
> >>
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
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 them
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 paymen
r protocols requiring proof-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 Fo
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 buye
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 mo
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
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 unlo
Hi Thread,
I made a reply to the OP but didn't "reply all" so it just went directly to
Ethan. Since the comments were interesting I'll attempt to salvage them by
posting them in full:
== Lloyd's post ==
Hi Ethan,
I'd be interested to know what protocols you need OP_CAT for. I'm trying to
figure
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
acces
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.
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 he
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 <
subhra.ma
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 onl
situation -
> 1. HTLC A & B (on channel AB): both A and B lock say 0.1 BTC each i.e. 0.2
> BTC
> 2. HTLC A&B (on channel AB) : A locks 0.1 BTC, HTLC B&A (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 p
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 workin
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 the
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 curr
# 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: https://gith
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 sometimes
> 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 (a.k.
>
>
> 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
> gener
main 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
>>
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 c
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, Zeeman
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 i
le
to 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-t
> 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 o
Hi list,
I've been considering the problem of recovering lightning channels after
losing channel state in a boating accident. The modern way of doing this
seems to be "static channel backups" -- these are essentially lists of
channel ids and the nodes you had the channels with.
The idea is that w
> 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 the
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 cha
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 p
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 actual
> 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 unl
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
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 y
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 u
> 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 fo
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`.
>
Happy New Year Lightning Developers,
I've recently been closely looking at the dual funding proposal [1] because
it uses a DLEQ proof (PoDLE) which we are also working on specifying as
part of DLC ECDSA adaptor signatures [2].
While reading it I had some queries and ideas that I thought were worth
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 wo
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
&
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 w
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] https://arx
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 cr
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 the
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)?
> >>
> >>
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
>gos
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 your
&g
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. It
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 [1]
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 whi
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 asym
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.
With
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
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
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 at
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 HTLC on
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:
> Alice
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 there
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 understand
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 for
66 matches
Mail list logo