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`.
> > >
> > > Actually no -- the fact
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`.
>
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`.
>
> Actually no -- the fact that you were able to
> 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
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 you could just
> > > gift the money to the party
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
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 you could just gift the
> money to the party offering the recovery
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 current system
> >
> 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
I don't think it's so clear that any party refusing to go go first can be
assumed to have lost data.
If the rule is that the party receiving the connection is the one that must
send the oblivious signatures then a party that has both lost data and is
receiving a connection can just ignore the
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 Fri, Dec 11, 2020 at 01:02:04PM +1100, Lloyd Fournier wrote:
> If c = 1 (i.e. the node is fine and it wants to continue the channel) then
> it checks `encrypted_signature_verify(X, settlement_tx, Y)`. If it passes
> it sends the commitment blinding y back to prove that it doesn't have the
>
13 matches
Mail list logo
