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 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
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
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 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
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
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
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:
>
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
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
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
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.
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
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
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 [
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.
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
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
>
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)?
> >>
> >>
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
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
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]
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
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
> &
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
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`.
>
> 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
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
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
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
> 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
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
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
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
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
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
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
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
> 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
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
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
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
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
(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
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
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 <
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
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 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
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
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
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
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
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:
>
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
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
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
57 matches
Mail list logo
