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 forwarding.

I wanted to add a theoretical note that you might be aware of. The final
message "Bob -> Alice: revoke_and_ack" is not strictly necessary. Alice
does not care about Bob revoking a commit tx that gives her strictly more
coins. Bob's new commit tx can use the same revocation key as the previous
one i.e. only the offerer of the PTLC/HTLC does a revocation and increments
their revocation key. Not sending messages you don't need to is usually
both more performant and simpler but given that it introduces some
asymmetry so I'm not sure if it's worth it. It's also worth noting that
with fast forwards + symmetric commit tx you will need to do the full four
rounds always I think.

Cheers,

LL

On Thu, 9 Dec 2021 at 02:03, Bastien TEINTURIER  wrote:

> Hi again AJ and list,
>
> I have slightly re-worked your proposal, and came up with the following
> (I also added the musig2 nonces for completeness):
>
> Alice -> Bob: commitment_proposed
> channel id
> adaptor sigs for PTLCs to Bob in Alice's next commitment
> musig nonces for Alice to spend funding tx
> musig nonces for Bob to spend funding tx
>
> Bob -> Alice: commitment_proposed
> channel id
> adaptor sigs for PTLCs to Alice in Bob's next commitment
> musig nonces for Alice to spend funding tx
> musig nonces for Bob to spend funding tx
>
> Bob -> Alice: commitment_signed
> channel id
> signature for Alice to spend funding tx
> sigs for Alice to spend HTLCs and PTLCs from her next commitment
>
> Alice -> Bob: revoke_and_ack
> channel id
> reveal previous commitment secret
> next commitment point
>
> Alice -> Bob: commitment_signed
> channel id
> signature for Bob to spend funding tx
> sigs for Bob to spend HTLCs and PTLCs from his next commitment
>
> Bob -> Alice: revoke_and_ack
> channel id
> reveal previous commitment secret
> next commitment point
>
> I believe it's exactly the same flow of data between peers as your
> proposal, but I simply split the data into several messages. Let me
> know if that's incorrect or if I missed a subtlety in your proposal.
>
> This has some small advantages:
>
> * commitment_signed and revoke_and_ack are mostly unchanged, we just
> add a new message before the commit / revoke dance. The only change
> happens in commitment_signed, where the signatures for PTLC-success
> transactions will actually become adaptor signatures.
> * the new adaptor signatures are in commitment_proposed instead of being
> in commitment_signed, which ensures that we can still have 2*483
> pending (H|P)TLCs: since the message size is limited to 65kB, we would
> otherwise decrease our maximum to ~2*335 with your proposal (very rough
> calculation)
> * the messages are now symmetrical, which may be easier to reason about
>
> One thing to note is that we reversed the order in which participants
> sign new commitments. We previously had Alice sign first, whereas now
> if Alice initiates, Bob will sign the updated commitment first. This is
> why we add only 0.5 RTT instead of 1 RTT compared to the current protocol.
> I don't think this is an issue, but if someone sees a way to maliciously
> exploit this, please share it!
>
> I updated my article [0], people jumping on the thread now may find it
> helpful to better understand this discussion.
>
> Thanks,
> Bastien
>
> [0] https://github.com/t-bast/lightning-docs/pull/16
>
> Le mer. 8 déc. 2021 à 11:00, Bastien TEINTURIER  a
> écrit :
>
>> Hi AJ,
>>
>> I think the problem t-bast describes comes up here as well when you
>>> collapse the fast-forwards (or, anytime you update the commitment
>>> transaction even if you don't collapse them).
>>
>>
>> Yes, exactly.
>>
>> I think doing a synchronous update of commitments to the channel state,
>>> something like:
>>
>>
>>
>> Alice -> Bob: propose_new_commitment
>>> channel id
>>> adaptor sigs for PTLCs to Bob
>>
>>
>>> Bob -> Alice: agree_new_commitment
>>> channel id
>>> adaptor sigs for PTLCs to Alice
>>> sigs for Alice to spend HTLCs and PTLCs to Bob from her own
>>> commitment tx
>>> signature for Alice to spend funding tx
>>>
>>> Alice -> Bob: finish_new_commitment_1
>>> channel id
>>> sigs for Bob to spend HTLCs and PTLCs to Alice from his own
>>> commitment tx
>>> signature for Bob to spend funding tx
>>> reveal old prior commitment secret
>>> new commitment nonce
>>>
>>> Bob -> Alice: finish_new_commitment_2
>>> reveal old prior commitment secret
>>> new commitment nonce
>>>
>>> would work pretty well.
>>
>>
>> I agree, this is better than my naive addition of a `remote_ptlcs_signed`
>> message in both directions, and even though it changes the protocol
>> messages
>> it stays 

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 understanding are accurate, in the above, it
> is the *PTLC-offerrer* which provides an adaptor signature.
> That adaptor signature would be included in the `update_add_ptlc` message.
>

Isn't it the case that all previous PTLC adaptor signatures need to be
re-sent for each update_add_ptlc message because the signatures would no
longer be valid once the commit tx changes. I think it's better to put it
in `commitment_signed` if possible. This is what is done with pre-signed
HTLC signatures at the moment anyway.

LL
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev


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 there
were various objections to it becoming specified as it forces
implementations to handle keys in a certain way. You can still do it
informally though by fixing your funding pubkey to be derived from the
Diffie-Hellman key of the two node ids. This makes the funding public keys
a (secret) deterministic function of the two node ids without making a
privacy leak.

FWIW I still think this is a good idea but in hindsight I think the
objections to it being mandatory are valid.

Cheers,

LL

On Sat, 18 Sept 2021 at 02:14, SomberNight via Lightning-dev <
lightning-dev@lists.linuxfoundation.org> wrote:

> Hi all,
>
> TL;DR: an approach is described how to derive channel keys
> deterministically that allows certain forms of recovery from just
> a seed, that works today. This approach however will no longer work
> with e.g. MuSig key aggregation in the future. An idea for a proposal
> is given how the channel-open flow (e.g. as part of channel v2) could be
> changed to make a similar approach work independent of key aggregation.
>
> -
>
> While implementing anchor output support in Electrum, we have realised
> one difficulty is to do with the remote-force-close case where the
> to_remote output is no longer a simple p2wpkh.
>
> Currently, pre-anchor-support, Electrum sets option_static_remotekey
> to required (feature bit 12), and we restrict lightning usage to wallets
> that derive p2wpkh addresses, and payment_basepoint is set
> to a bip32-derived pubkey that corresponds to a wallet address.
> Hence, if a user were to restore from seed words, and their channel
> counterparty force closed their channel, the to_remote output of the
> broadcast commitment tx would directly pay to the user's wallet.
> That is, in many typical scenarios, funds are not lost when restoring
> from seed.
>
> (Also, if we are the channel-funder/opener, it is easy to find the
> funding transaction, just by testing txs in the wallet history.
> Further, for the cases we are the channel-funder/opener,
> there is a setting to put an OP_RETURN in the funding tx, which stores
> the nodeid of the counterparty, allowing us to identify who to contact
> to get the channel closed.
> Also, we are (ab)using dataloss_protect to ask the remote
> to force-close when restoring from seed, so the user does not even have
> to wait for an arbitrarily long time.)
>
> With anchors, the to_remote is now a p2wsh that involves a CSV,
> and we cannot easily make this script correspond to a wallet address,
> i.e. we lose the property that the remote-force-close pays directly
> to a wallet address.
>
> So, the problem we would like to solve, is:
> - having seed words
> - having access to blockchain data
> - somehow having identified our channel counterparties (node IDs),
>   and our channels with them (funding outpoints)
> - and assuming we can get the remote to do a force-close
> --> we would like to be able to spend the to_remote output
>
> Solutions:
>
> 1) Naively, we could just derive a static key to be used as
> payment_basepoint, reused between all our channels, and watch the
> single resulting p2wsh script on-chain.
> Clearly this has terrible privacy implications.
>
> 2) Or, we could derive a new bip32 chain/sequence of pubkeys
> used as payment_basepoint for channels, and watch these p2wsh scripts,
> with a gap limit.
> Particularly the gap limit part makes this undesirable though
> (just consider having more than "gap limit" channels open and restoring
> from seed).
>
> Instead, it seems desirable to see whether we can extract some entropy
> from the blockchain, and use that as a nonce to be combined with a
> static private secret derived from our seed.
> We could extract data either from the funding tx, or from the
> remote-commitment-transaction that spent the funding output.
>
> 3) We exploit the fact that the funding output uses a
> 2of2 OP_CHECKMULTISIG script composed of the funding pubkeys of
> each party. The funding pubkey itself can be used as a nonce, and
> it can be recovered from the witness of the commitment tx.
> The privkey for payment_basepoint can then be derived as e.g.
> hash(bip32_derive(seed, HARDCODED_PATH) + funding_pubkey).
>
> In fact (3) is not novel at all: eclair has been deriving
> all their channel keys like this [0] for some time, from
> a static seed-based secret combined with the funding_pubkey as nonce,
> and generating the funding_privkey from ~os.urandom.
>
> Electrum will likely use (3) at least for the payment_basepoint,
> as part of adapting to anchors.
>
> -
>
> Note that the idea (3) relies on recovering the funding_pubkey from
> the witness of the spending transaction, which will break in the future
> if the funding 

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:
>  Alice's balance
>  (others)
>
> low-latency inflight tx:
>   input:
> Alice's balance
>   output:
> (1) or (2)
> Alice's remaining balance
>
> Bob claim:
>   input:
> (1) [ CSV bob CHECKSIG]
>   output:
> [ checksigverify  checksig
>  ifdup notif  csv endif]
>
> Too-slow:
>   input:
> (2) [ CLTV alice CHECKSIG]
>   output:
> Alice
>
> The idea being:
>
>  * Alice sends the low-latency inflight tx which Bob then forwards
>immediately.
>
>  * Bob then tries to update the base channel state with Alice, so both
>sides have a commitment to the new payment, and the low-latency
>inflight tx is voided (since it's based on a revoked channel state)
>If this succeeds, everything is fine as usual.
>
>  * If Alice is unavailable to confirm that update, Bob closes the
>channel prior to (payment-timeout - payment-recover-delay), and posts
>"Bob claim". After an additional pyment recovery delay (and prior
>to payment-timeout) Bob posts Bob claim, ensuring that the only way
>Alice can claim the funds is if he had posted a revoked state.
>
>  * In this case, Alice has at least one payment-recovery-delay period
>prior to the payment-timeout to notice the transaction onchain and
>recover the preimage.
>
>  * If Bob posted the low-latency inflight tx later than
>(payment-timeout - payment-recovery-delay) then Alice will have
>payment-recovery-delay time to notice and post the "too-slow" tx and
>claim the funds via the timeout path.
>
>  * If Bob posted a revoked state, Alice can also claim the funds via
>Bob claim, provided she notices within the channel-recovery-delay
>

In my mind your "update the base channel state" idea seems to fix
everything by itself. So at T - to_self_delay (or a bit before) you say to
your counterparty "can we lift this HTLC out of your in-flight tx into the
'balance tx' (which will go back to naming a 'commitment tx' since it
doesn't just have balance outputs anymore) so I can use it too? --
otherwise I'll have to close the channel on chain now to force you to
reveal it to me on time?". If they agree, after the revocation and new
commit tx everything is back to (tx symmetric) Poon-Dryja so no need for
extra CSVs. Am I missing something?

I realise this kills some of the elegance of your original protocol and
adds quite a bit of complexity but I think it retains the important
properties.


> That only allows one low-latency payment to be inflight though, which I'm
> not sure is that interesting... It's also kinda complicated, and doesn't
> cover both the low-latency and offline cases, which is disappointing...
>
>
It seems to me lazily lifting the HTLCs into the commitment tx would allow
as many low-latency payments as you want to be in-flight. You would
probably just lift them all up to the commitment tx if you lift one. I
think in the case of nodes that want to keep channel keys offline, having
to go on-chain at T - to_self_delay is not a disaster since it will likely
only be the payment receiver who has their keys offline i.e. the merchant
or end user. So only the last hop would go on chain if the user fails to
claim payment as per usual (just to_self_delay earlier than usual).

Cheers,

LL
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev


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 HTLC on chain
> and don’t have to close the channel early.
>
> So against a malicious node you have to go on chain to_self_delay earlier
> than usual but if both are honest you don’t have to. The problem with eltoo
> is that we don’t know how to achieve this even if both parties are honest
> iirc.
>

Err never mind that won’t work. Sending in-flights to both parties makes no
sense because they can be stale of course.

LL

>
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev


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 at time T-to_self_delay.
>
> Any time later than that, say T-to_self_delay+x+1, would allow Bob to
> post the inflight tx at T+x (prior to Alice being able to claim her
> balance directly due to the to_self_delay) and then immediately post the
> layered transaction (4, above) revealing the preimage, and preventing
> Alice from claiming the refund.
>

This problem may not be as bad as it seems. Recall that the issue in eltoo
is worse because you are delayed both when you are offering and receiving
the HTLC. In this one you are only delayed on offered HTLC.

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 chain
and don’t have to close the channel early.

So against a malicious node you have to go on chain to_self_delay earlier
than usual but if both are honest you don’t have to. The problem with eltoo
is that we don’t know how to achieve this even if both parties are honest
iirc.

LL
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev


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 what to
do with them. Looks like you've done that!

I also didn't make the connection to how revocable signatures actually
solves the constant size storage problem. I knew it could make the protocol
in "generalized payment channels" [1] only require constant size which was
the target of the idea but I hadn't considered that lightning already
suffers from this problem so it can be applied more generally.

The other big breakthrough you made is showing how you can do concurrent
non-interactive payment forwarding by using a refined version of Z's fast
forward idea. In my mind the most practical way to make FF work on
Poon-Dryja channels was to do it asymmetrically [3] but this meant that if
a payment was sent the other way you'd have to do a 3 phase commit first.
With your idea as long as you have balance to spare in your balance output
you can always forward a payment in one message. A nice speed boost for
busy routing nodes.

### Scorched earth punishment

Another thing that I'd like to mention is that using revocable signatures
enables scorched earth punishments [2]. The key you reveal when you post a
revoked state does not have to be limited to your channel -- it could be
used in multiple channels allowing the wronged party to take coins from all
their channels with the perpetrator. Furthermore, a lightning service
provider that offers channels with the same channel key to all their
customers is putting up all their coins in all their existing channels as
their good behaviour bond rather than just the coins they have in the
channels they have with you.

For many users this will be sufficient to go without a "watchtower" to do
punishments for them. They know if the LSP takes their coins with a revoked
state whenever they come back online they can punish the LSP by revealing
their static channel key to everyone. They can even do this weeks or months
after the theft assuming the LSP is still operating with the same key.

Some people feel this idea is too spicy but I prefer it to introducing a
trusted third party for people that cannot be online all the time.

[1] https://eprint.iacr.org/2020/476.pdf
[2]
https://github.com/LLFourn/witness-asymmetric-channel#scorched-earth-punishments
[3]
https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-June/003045.html

Some queries below:

On Sat, 9 Oct 2021 at 12:12, Anthony Towns  wrote:

>
> We will use "i" to represent the number of times a given inflight
> transaction has been updated for the nth update to the balance
> transaction.
>
> At any time Alice can update the inflight transaction spending her balance
> to transfer funds towards Bob, either by updating the balances directly,
> or adding a htlc/ptlc entry to conditionally transfer funds to Bob. (And
> conversely for Bob)
>
> We will define RP=musig(A/2/n/i, RB2(n,i)).
>
> The inflight transaction spending Alice's balance can have multiple
> types of outputs:
>
>  * Alice's remaining balance: pays directly to A/2/n/i
>
>  * Bob's remaining balances: pays to RP/2 with script path
>" CHECKSIGVERIFY  CSV"
>
>  * An htlc paying to Bob: pays to RP/2/k with script paths:
>+ "LENGTH 32 EQUALVERIFY HASH160  EQUALVERIFY 
> CHECKSIGVERIFY  CHECKSIG"
>+ " CHECKSIGVERIFY  CLTV"
>
>  * A ptlc paying to Bob: pays to RP/2/k with script paths:
>+ " CHECKSIG NOTIF  CLTV DROP ENDIF  CHECKSIG"
>
> Any outputs that would be zero or dust are not included.
>
> Note that we number each currently inflight transaction by "k",
> starting at 0. The same htlc/ptlc may have a different value for k
> between different inflight transactions.
>

Can you expand on why "k" is needed in addition to "n" and "i". k sounds
like the same thing as i to me.

Also what does RP/2/k notation imply given the definition of RP you gave
above?


>  * if the inflight transaction contains a ptlc output, then if Alice
>has not retained the old ptlc details (the point and the timeout)
>she will not trivially be able to reconstruct the script path,
>which includes the timeout. However, presuming the timeout was
>within 5000 blocks, then the only possible timeouts are the inflight
>tx's nlocktime+i with 05000*k cases and match the corresponding scriptPubKeys to exhaustively
>enumerate every possible ptlc output, which should take under a minute,
>and be easily achievable. In addition, if Bob attempts to claim the
>funds, he will reveal the script path, and Alice will be either able
>to claim the inflight output directly or the layered output.
>

What about just doing a scriptless PTLC to avoid this (just CSV input of
presigned tx)? The cost is pre-sharing more nonces per PTLC message.

This does not 

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 Alice --- we model
> the signature-deletion attack as impossible, by assumption.
> (This is a strengthening of security assumptions, thus a weakening of the
> security of the scheme --- if Bob does not take the above mitigations, Bob
> ***is*** vulnerable to a signature-deletion attack and might have ***all***
> funds in hostage).
>

Only where ***all*** refers to the funds in the fast forward -- funds
consolidated into the channel balance are not at risk (modulo enforcing
correct state on chain).
I think it should be easy to get a stream of signatures so they can't be
deleted. The user "Bob" is creating and sending the invoices so they can
always demand and save the signatures from "Carol the Cashier" that
correspond to each payment so the "deletion attack" will be thwarted.

LL
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev


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.
With the non-custodial LN phone apps there is this annoying UX where you
have to keep the app open to receive a payment (because the pre-image is on
my phone).
I wouldn't mind letting the provider handle receiving payments on my behalf.
Of course this means they would be able to steal the money in the FF state
but this is a big reduction in risk from a full custodial solution.
In other words, you should be able to get the seamless experience of a
fully custodial wallet while only giving them custody of small amounts of
coins for a short time.

On Wed, 2 Jun 2021 at 13:30, ZmnSCPxj  wrote:

>
> Another advantage here is that unlike the Poon-Dryja Fast Forwards, we do
> *not* build up a long chain of HTLC txes.
> At the worst case, we have an old update tx that is superseded by a later
> update tx instead, thus the overhead is expected to be at most 1 extra
> update tx no matter how many HTLCs are offered while Bob has its privkey
> offline.
>

I don't think you need to build up a long chain of HTLC txs for the
Poon-Dryja fast forward in the "desync" approach. Each one just replaces
the other.

Cheers,

LL
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev


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 asymmetric.

This is what I think happens when offering a FF HTLC:
1. The offerer creates and signs a new commitment tx as normal with the
HTLC except it has the same revocation key as the last one.
2. The offerer patches their balance output by sending a tx spending from
it to a new tx which has the HTLC output and their balance output
(unencumbered).

The HTLC is now irrevocably committed from the perspective of the receiver.
Now the receiver presents the pre-image and the offerer then:

1. The offerer creates and signs a new commitment tx as normal
consolidating the funds into the receiver's balance output except once
again it has the same revocation key as the last one.
2. The offerer patches their commitment tx balance output again by sending
a tx spending from it to a new tx which splits into the receiver's balance
(the value of the claimed HTLC) and the offerer's remaining balance.

You can repeat the above process without having the receiver's revocation
keys online or their commitment tx keys for many HTLCs while the offerer
still has balance towards the receiver.
The on-chain cost is about the same as before for an uncooperative close.

Once the receiver brings their keys on line they can consolidate the FF
state into a new commitment txs on both sides and with a proper revocation
operate the channel normally. What has been the receiver up until now can
finally send funds.

Am I missing something?

Cheers,

LL

On Mon, 31 May 2021 at 19:47, ZmnSCPxj via Lightning-dev <
lightning-dev@lists.linuxfoundation.org> wrote:

> Good morning list,
>
> > It may be difficult to understand this, so maybe I will make a
> convenient presentation of some sort.
>
> As promised: https://zmnscpxj.github.io/offchain/2021-06-fast-forwards.odp
>
> The presentation is intended to be seen by semi-technical and technical
> people, particular those that have not read (or managed to fully read and
> understand) the original writeup in 2019.
> Simply "run" the presentation (F5 in LibreOffice), as the presentation
> uses callouts extensively for explication.
>
> Regards,
> ZmnSCPxj
>
>
> ___
> Lightning-dev mailing list
> Lightning-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev


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 which can be swept
into the commit tx at the merchants discretion.
If a fast forward state needs to be asserted on-chain it can then be done
automatically without the hardware device.
Of course, the funds in the FF state are more vulnerable than the main
channel balance during that time because their keys are not in a secure
device but this seems ok.
The obvious analogy is to having cash in the till (less secure) that you
send to your bank (more secure™) at the end of the day or week.

> We ***need*** privkeys to be periodically online more often than
`to_self_delay` anyway, ***in case of theft attempts***.
>  So this is not an ***additional*** requirement at least.

This is a really important point. I guess you have to actually do this
periodically, only when there is an actual attempt at theft. Quite annoying
to UX to require this.

Cheers,

LL
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev


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 [1] [...]
> > (3) is also a problem with just doing encrypted backups -- going around
> > looking for backups means you tell everyone that you are in recovery
> mode.
>
> Eh, I assume nodes using the backup commons would, each time they're
> restarted, go through the steps of downloading some number of backups
> even if they haven't lost any data.  This tests that the backups are
> being stored faithfully (essential to any backup process) and provides
> cover for cases where a node does lose data.
>

Ok this is a fun idea and hadn't thought of it like that before. Here are
the thoughts that come to mind:

1. Each time you start up your node you backup you go around to different
nodes -- but the obvious question is *which* nodes do you go to? You could
try and do something like rendezvous hashing [1] to reduce the set (with
some secret data as input so it is not predictable to anyone but yourself) .
2. What do you backup? Full-channel state or just a channel list? Even if
you have mostly honest backup nodes you need to make sure you delete old
states from your remote backups before revoking them if you do full
backups. This slows down sending payments but it might be worth it for
users like myself. So perhaps it's still better to avoid full backups here.

[1] https://en.wikipedia.org/wiki/Rendezvous_hashing

LL
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev


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. It creates a new gossip message that can be spammed.
2. It is not easy to figure out whether it worked or not (maybe the person
I had my channel with is offline?).
3. This is incompatible with covert recovery schemes like in [1] whereas
what I propose here builds towards making such schemes possible in the
future.

(3) is also a problem with just doing encrypted backups -- going around
looking for backups means you tell everyone that you are in recovery mode.

[1]:
https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-December/002912.html

LL
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev


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 your
> funds into the same funding).
>

Nevermind I've thought of a few -- ignore this point!

LL
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev


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
>gossip and to DH to set up a new peer connection.  c-lightning does
>not use this for now (we keep the per-channel keys in the HSM too),
>but it would be a perfectly acceptable tradeoff not to do this.
>

Don't you also need the node secret key for onion routing? i.e. every time
you update your channel to forward a payment.
I am not familiar with lightning HSM designs and security goals but to me
it doesn't sound like much of a cost to keep the key on the HSM and to
include doing channel updates as well seeing as it's already doing so much
work. If it is desirable to have different keys for DH and channel updates
then a simple solution is to have two static public keys -- one for each
task.

>From my perspective it is worth making the necessary sacrifices to include
this feature. For me and many people, lost data without backups is the
biggest risk to my funds in lightning. Certainly much more threatening than
whether certain keys are on a HSM or not. Anecdotally I've heard stories
like "I put my lnd on autopilot and then lost my disk died -- all my funds
are gone!?" more than once.

2. It doesn't get rid of temporary_channel_id, since we don't know
>the generation_number until both sides have sent it.  We have a
>workaround for this already in dual-funding anyway.
>

Why did you decide to send this rather than just look up in your own
database what "generation" should be? I think that it's easy to make sure
that you and the other node are on the same page about this number without
communicating it. If someone is opening a channel with data that appears to
be invlaid because they are using the wrong generation then sending an
error back indicating what you are up to should be sufficient to recover?


> 3. Because we need a generation counter, it's not quite as easily
>scannable as you'd hope (the "gap" problem).
>

This doesn't seem to be a big issue. You are trying to recover your funds
after all so you can afford to scan over very large gaps i.e. leave the
node on for days. I mean my Bitcoin wallet manages to handle this so why
wouldn't it work here? 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 funds into the same funding).


> I think the "encrypted blob served by peers", even in a very naive way,
> offers another way to do this, though it requires the assumption that at
> least one peer is honest.
>

I see encrypted backups as complementary. With this scheme you can at least
find a peer that you've had a channel with. From the encrypted backup you
left with them you can then find others and check against them.

LL
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev


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)?
> >>
> >> 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 change!
> >>
> >
> > Yes that's certainly a fine way to do it.
> > I was also thinking you could eliminate all "basepoints" (not just
> funding
> > pubkey) using something like this. i.e. just use the node pubkey as the
> > "basepoint" for everything and randomize it using the shared secret for
> > each purpose.
>
> OK, I tried to spec this out, to implement it.  One issue is that you
> now can't sign the commitment_tx (or htlc_tx) without knowing the node's
> secret key (or, equivalently, knowing the tweaked key and being able to
> use the derivation scheme to untweak it).
>

Using node secret key to sign the commitment_tx seems like something you
will have to accept to introduce this feature. For the idea to work it has
to be some public key that is known by others and gossiped through the
network. Of course you could extend the information that is gossiped about
a node to include a "commit_tx_point" but the nodeid seems the more natural
choice.


> c-lightning currently does a round-trip to the signing daemon for this
> already, but it'd be nice to avoid requiring it.
>
> So I somewhat reluctantly added `commit_basepoint` from which the others
> are derived: an implementation can use some hardened derivation from its
> privkey (e.g. SHA256(node_privkey || ss || counter)) to create
> this in a deterministic but still private manner.
>
> Or we could just leave all the other points in and just replace
> funding_pubkey.
>

Another approach is to do things in "soft-fork" like manner.
Each node that wants to offer this feature sets their funding_pubkey to a
specified DH tweak of the nodeid. Nodes that want backup-free channel
recovery can just refuse to carry on the funding protocol if the
funding_pubkey is not set the way it wanted.

>From my pruisit crypto point of view having only one public key is nice but
I'm not sure how it impacts things architecturally and other protocols like
watchtowers.

Cheers,

LL
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev


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 the answer to both these questions hinges on whether you
exclusively use private channels. If you fund private and public channels
with the same wallet then it may be possible to identify your private
channels and the owner of the channel and channel close outputs[1].
I've recently tried to describe what I think needs to happen to turn
lightning into an effective layer-1 privacy tool in the "Removing
cross-layer links" problem on bitcoin-problems.github.io[2].

Cheers

LL

[1] https://arxiv.org/pdf/2003.12470.pdf (section 3.2).[2]
https://bitcoin-problems.github.io/problems/removing-cross-layer-links.html
[2]
https://bitcoin-problems.github.io/problems/removing-cross-layer-links.html

On Sat, 17 Apr 2021 at 12:22, Mr. Lee Chiffre 
wrote:

>
> > Two, if the balances of each side of a
> > channel are different when closing vs. opening, can someone determine
> > which output from the 2 of 2 multisig belongs to who?
>
>
> A thought to add to my last email. In theory it could be determined if the
> output belonging to a certain node later uses that as an input for a non
> private chan opening right? But that would also look the same if it was
> also the same user opening a new chan to that node?
>
> This brings to another question. Not just chan closure but on chan opening
> is it possible to determine which input came from who?
>
> ___
> Lightning-dev mailing list
> Lightning-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev


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 credential server is
able to identify you somehow at the point of payment then they might want
to selectively steal your money while being honest with everyone else.
In your scheme, if you pay you get the credential and then since it is
anonymous it can't be distinguished from others when you go to claim
whatever it entails.
Is this the idea?

Cheers,

LL

On Thu, Feb 4, 2021 at 1:04 PM 宮本丈 via Lightning-dev <
lightning-dev@lists.linuxfoundation.org> wrote:

>
> Hi all.
>
> I want to point out another application of Discrete-Log selling on PTLC
> lightning since I could not find anyone else mentioning it (in particular,
> I could not find in the Nadav Kohen's list here. [1] )
>
> The protocol may be obvious to most of the members here, but I believe its
> application has some impact on the way people make anonymity-focused
> applications with LN, so I want to have some feedback.
>
> In short, by using ElGamal encryption, we can sell not only a discrete-log
> but also an elliptic curve point which satisfies some requirements. This
> includes KVAC [2] which is used for WabiSabi [3] and Signal app [4].
>
> > disclaimer: I'm not a cryptography or math major, the following
> reasoning might be wrong at the fundamental level. Please correct me if I'm
> wrong.
>
> ## Notations
>
> * G ... Elliptic curve base point.
> * H ... some additional NUMS
> * x, X = x * G ... secret and public key
>
> For ZKPoK, I will use Camenisch-Stadler like notation
> PK{ (secret values) : statements about secret values to prove. }
> e.g. For DLEQ proof. assume the verifier already have some points P_1, P_2
> PK{ (x, y) : P_1 =  x * G and P_2 = y * H and x = y }
>
> # Protocols
>
> ## pay-for ElGamal decryption key
>
> Quick recap, ElGamal encryption for message M (= m * G) is
> (r * G, M + r * P)
> where r is some blinding factor and P is a shared secret (P = p * G)
>
> Imagine the Buyer knows some point (X_h = x * H), and he wants another
> point (X_g  = x * G).
> The Seller knows x and he wants to sell the point X_g but he does NOT want
> to reveal its discrete log x to the buyer.
> (There is not much of a situation like this, but I will explain it later.)
>
> In this case, the Seller can send its elgamal encryption and sell its
> decryption key.
> Seller:
> * Generate ephemeral encryption key S = s * G
> * Encrypt X_g  with random blinding r ... (c1, c2) := (r * G, X_g + r * S)
> * Send (c1, c2) and S to the Buyer.
> * Also, send PK{(x, r, s) :  c1 = r * G and c2 = x * G + r * S and X_h = x
> * H }
>
> Buyer
> * Verifies the ZKPoK, he can be sure that the plaintext will be X_g that
> he wants.
> * Make a payment offer to the Seller with S.
>
> Seller
> * Receive the payment by revealing s
>
> Buyer
> * Decrypt the ciphertext by s to get the X_g ... (X_g := c2 - c1 * s)
>
> ## Pay for Keyed Verification Anonymous Credential. (KVAC)
>
> We assume MAC_{GGM} scheme for the KVAC. [2]
>
> * attributes encoded in the credential is m_1, ... m_n
> * secret keys for the issuer=verifier is r, x_0, x_1, ... x_n
> * Public params for the issuer is (C_x0 = x_0 * G + r * H), (X_1 = x_1 *
> G, ... X_n = x_n * G)
>
> The credential is of the form (U, U') where U' = U * (x_0 + x_1 * m_1 +
> ... + x_n * m_n)
>
> Issuer:
> * get random point `U`
> * compute U' = U * (x_0 + x_1 * m_1 + ... + x_n + m_n)
> * sends U and ElGamal encryption of U' to the Buyer with blinding factor k
> and ephemeral encryption key S.
>   * (c1, c2) = (k * G, U' + k * S)
> * Also send ZKPoK to tell the ciphertext is for correct U'
>   * PK{(x_0, ... x_n, x_0, r, k, s) :  U' = U * (x_0 + x_1 * m_1 + ... +
> x_n * m_n)  and  C_x0 = G * x_0 + H * r and X_1 = x_1 * G and ... and X_n =
> x_n * G and  c1 = k * G and c2 = U' + k * S }
>
> Then Buyer can buy s as the same as above.
>
> # Why this matters
>
> I believe that KVAC has great potential as a building block of anonymous
> web apps.
> Its MAC-based construction is more performant and easy to prove the
> security compared to the similar system for the PKI based anonymous
> credentials (e.g. U-Prove [5] and ACL [6]).
> And it's a great fit for commercial purpose applications which do not have
> to cooperate with other entities when defining the protocol. (Which is not
> the case for an Attribute based credential system in general.)
>
> The reason so far it has not been used widely is, IMHO, it's because there
> is no way to charge its users anonymously. [7]
> Another problem is Sybil attack. In general, the DoS protection is a great
> concern for anonymous applications.
> So we need users to commit something "scarce" to prevent it.
> It is why Signal requires its users to register their telephone number
> (Maybe I'm wrong about this, 

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] https://arxiv.org/pdf/2003.12470.pdf
> > [3] https://graphsense.info/
> >
> > I am told there is a new revision of [1] coming out any day now that will
> > present a few more tricks and have contributions directly from a
> scientist
> > at Chainalsysis (the company).
>
> I'll add to my reading list (or wait for one of my colleagues to provide
> the TL;DR!).
>
>
Let me TL;DR quickly the core idea quickly as it's not too difficult to
grasp.

1. You are node n_1
2. You fund a public channel to node n_2 called c1
3. You use the change to fund a public channel to node n_3 called c2
4. The network sees that n_1 is involved in both c_1 and c_2. They're both
public channels so the channel_id gives away the on-chain funding utxo.
Everyone can conclude that the owner of n_1 was also the funder of both and
therefore owns the change output of the funding of c_2.

Consider a variant of this heuristic where instead of using funding change
they use the output of a cooperative close of c_1 to to fund c_2. By the
same reasoning you can identify the owner of n_1 funded the channel but you
can also now know  that n_2 is the owner of the other utxo of the close of
c_1.

The point of this is if you are a node that is churning UTXOs from the
funding change or the closing UTXO into other public channels you
necessarily associate those UTXOs with your node id and any descendent
utxos. This is the point of UTXO probing too but with this you get the info
for free by just passively observing the new channel gossip. I think this
makes UTXO probing useless as long we can assume that public nodes that
accept dual funding requests from random people on the internet (and
therefore vulnerable to probing) are also likely to use their wallet funds
to fund channels in the future.

LL
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev


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 with doing that:
>
> 1. Everyone knows what you're doing, as they see the signalling tx (and
>it needs to commit to a challenge, such as using OP_RETURN, so you
>can't simply reuse the same tx).
> 2. Bitcoind doesn't tell you if it encounters a conflicting tx from a
>peer, so we'd probably need to gossip this via lightning instead.
> 3. If tx fees are low, the signalling tx might get mined.
>

I think immediate broadcast of signaling TX is a bad idea even if it's done
over lightning since it leaks that the UTXO associated with the signaling
TX is creating a channel (even if the channel was meant to be private).
You could argue that the signaling TX need not be associated with a UTXO
but I find this awkward.
Lazily broadcast, signaling txs are a good way to protect against
sequential attacks but are weak against parallel attacks. Unfortunately I
think protection of the former means very little without the latter.


>
> > There are several (perhaps addressable) downsides to this scheme but it
> at
> > least has better protection against parallel attacks than the others.
> > Since it is effective it would also break the "middleman" idea unless
> Alice
> > funds with two utxos (a different h2 for each party) or there is some way
> > for all parties involved in the funding to distinguish gossiped h2s from
> > their funding session from others.
>
> Yes, every initiator needs to provide an h2, and it has to be their own.
> But you don't care (and can't know) that there's an h2 for another
> input, too.  If Alice wants to initialte an open with Carol while Bob is
> initiating an opening with her, she's got to provide her own UTXO &
> PoDLE.
>
> Another point: the idea was that the accepting node would sign the
> gossip msg, and only known nodes (i.e. ones with a public channel) would
> be allowed to do so.  This gives easy anti-spam: if Alice starts
> spamming a giant pile of h2s, we start randomly dropping them.  That
> doesn't degrade the protection much: a single UTXO reuse might slip
> through, but a larger number would still be detected with P approaching
> 1.
>
>
Ok since it appears eagerly broadcasted PoDLEs are the only proposal that
can protect against parallel attacks let's try and put the best version of
it forward.
Here's my shot.

Let H0 and H1 be 32-byte output hash functions.

1. In any of the `tx_add_input` messages the initiator may attach a PoDLE
which contains the public key for an input as well as a P2 (the public key
projected onto a different generator).
2. Upon receiving the PoDLE, the peer checks its validity and creates a
"claim" message claiming the UTXO which contains.
i) H0(P2)
ii) A MAC (e.g. Poly1305) produced with the H1(P2) as the key and
claimer_node_id as the message -- required so conflicting claim messages
can only be produced by someone who actually knows P2.
iii) The claimer_node_id and a BIP340 signature under it over the rest
of the message data -- required to stop spam: only accept and re-broadcast
these messages from nodes who have real channels.
   The peer broadcasts this claim message if they haven't before received a
valid claim message with H0(P2) and a valid MAC.
3. Any node receiving the claim message checks whether it has seen it
already (same H0(P2) and MAC). If not, checks the signature against
claimer_node_id and checks whether that node is valid (or perhaps
blacklisted because it has spammed too many claim messages recently),
stores (H0(P2), MAC, claimer_node_id) it and re-broadcasts the message to
its peers.
4. The claiming node waits ~60 seconds to see if it receives a conflicting
claim message where the H0(P2) is the same and the MAC is different and
valid. If they don't receive that then they carry on to add their own utxos.

I believe this does guarantee what we wanted: an attacker will only be able
to do the attack once per UTXO. This is better than I expected to find at
the beginning of entering into this subject!
This certainly seems to be the strongest in the class of solutions.

Now I'd like to make the strongest possible argument against it in favor of
just doing nothing (for now) at the protocol level about this problem.

Consider the following propositions:
1. The public nodes that will offer dual funding and are susceptible to
this attack will be the kind that have a lot of churn i.e. they dual fund a
channel, when that closes they use the remaining funds to fund another
channel.
2. Chainalysis already works very well at identifying the UTXOs these kinds
of nodes. If the change output of a funding or the closing output are
reused in another public channel it is easy to identify which node was
funding what with the techniques in 

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
> > inputs.
>
> But that's by design.  You can contact two peers and middleman between
> them to produce a single tx.
>

Ah. I missed this motivation. So you actually want to have sessions where
you use the same signaling transaction in all of them. That's a cool idea.

>
> The practical problem with a signalling tx is that it's hard to tell if
> it's conflicting.  Mallory uses a single UTXO to probe for everyone's
> UTXO at once.  Poor Bob wants to both wait 60 seconds to see if a
> conflicting tx ends up in his mempool, *and* broadcast it ASAP to signal
> to others.  He wants to do both of these *before* revealing his own
> UTXOs.
>
>
I think this is a problem with all three schemes I mentioned. You will
always have to wait for things to be gossiped in some way to catch attempts
at parallel sessions.
Of course there could be faster mediums than the mempool but it does seem a
convenient one to use.
Note that you should not wait a predictable amount of time but rather a
randomly sampled amount from e.g. 0-60 seconds (or longer). If everyone is
waiting the same predictable amount of time it does nothing to protect you.

But the "middleman" idea you mentioned above makes this all the more
complicated: If you are meant to have parallel sessions then this is a
problem for an honest Alice who initiates a funding with Bob and Carol.
Bob decides to wait 24s and Carol decides to wait 55s to check the mempool
for the signaling before revealing their utxos. After Bob wakes up from his
24s he will add his own utxos and demand that Alice complete the
transaction by signing it. But since Alice is trying to also add Carol's
UTXOs to the transaction she will have to wait until Carol becomes
responsive again. To Bob this will look like Alice has become unresponsive
through no fault of her own and Bob will broadcast the signaling tx.

In other words, if parallel sessions are legal then you shouldn't try and
catch parallel sessions. But if parallel sessions are legal there will
always be an effective dual funding UTXO discovery attack by using one UTXO
to hit many targets. I think this is true for all three schemes I mentioned.

It seems the really difficult question is: is it even worth trying to stop
sequential attacks if parallel attacks are unstoppable?

Not sure how to square this, but I do prefer this approach over PoDLE.
>

I think PoDLE might actually have an advantage in parallel attacks if the
scheme was changed a bit. A weakness of the lightning proposal as compared
to the joinmarket idea is that the `h2` point is not broadcast immediately
-- rather you wait for failure and then broadcast it.  Instead, a peer
should broadcast h2 as soon as they have agreed to create a transaction
with the initiator. Then if at any time during the tx creation protocol
they receive the same h2 from someone else, they cancel and don't reveal
their UTXOs (let's say they wait ~10s after broadcasting before revealing
any utxos). Note that here you don't have to randomly select the time you
wait.

There are several (perhaps addressable) downsides to this scheme but it at
least has better protection against parallel attacks than the others.
Since it is effective it would also break the "middleman" idea unless Alice
funds with two utxos (a different h2 for each party) or there is some way
for all parties involved in the funding to distinguish gossiped h2s from
their funding session from others.

Cheers,

LL
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev


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 would allow you to add whale output from the chain to trick the
peer's algorithm for deciding how much they want to add to the funding.
Perhaps regulators of the future might check whether the LN node is
following their directive to ban certain inputs on a blacklist -- If you
carry on after the  funding_add_input from a blacklisted input you must not
be running our gov approved node!
If that is not a concern, then I agree a single 1-input-1-output signaling
transaction should be fine, otherwise requiring 1-input-1-output signaling
tx for each input the opener adds may be prudent (as Z suggested).

> [2] Which Lisa promises she'll publish RSN, so we can add your derived
points proposal to it.

Looking forward to seeing this :)

Cheers,

LL
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev


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`.
> >
> > Actually no -- the fact that you were able to create a secure
> conditional payment for the proof would always prove the proof existed.
> > You wouldn't need to pay for the proof then!
>
> That depends on the proof.
>
> For example, one pay-for-proof scheme would be somebody to provide you an
> `(R, S)` for a public key `P = p * G`,  where `S = s * G` (i.e. a
> signature, or a proof that you know `p` where `P = p * G`), and it would
> not prove anything until you pay for the scalar `s` and the prover can
> provide `s`, since `S` is computable from public information that anyone
> can have.
> So it really depends on what you want to prove; a mere ZKCP is not always
> enough.
>
> Regards,
> ZmnSCPxj
>
> PS I am dabbling in BTRFS now though, so ---
>

You're right. I stand corrected. It is possible to construct ZKCP payments
where the messages sent by the prover up until the point the prover claims
the payment (and reveals the witness) could have been simulated by someone
who doesn't know the witness. You give a good example of this. After
thinking about your post I recalled that I used a similar argument about
the security of my protocol for buying an opening of a Pedersen commitment
with Bitcoin [1].

[1]
https://github.com/LLFourn/buying-pedersen-commitment/blob/master/main.pdf

LL
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev


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 for the proof would always prove the proof existed.
You wouldn't need to pay for the proof then!

LL
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev


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 user does not use state-of-the-art
checksumming filesystems like ZFS and does not monitor disk health by
S.M.A.R.T.
> * A high-onchain-fee condition exists.
> * The casual user attempts to send out a payment consisting of almost all
funds in their LN channels via several HTLCs on MPP or other multipath.
> * Because of the activity generated, the filesystem assigns the LN
database to the failing part.
> * Storage fails with most funds in outgoing HTLCs.

Note that this is fine if the payment goes through. Their counterparty will
have to go on-chain to claim the payment (since your node is down due to
data-loss) and then you claim whatever is left from your seed.
The main risk here is for routing nodes which are hopefully only using this
technique as a very poor last resort.
If you actually manage to get online and try to restore before the on-chain
settlement then just attaching outgoing HTLCs to the mutual close would be
fine -- that way the peer can still claim the money from you if the payment
goes through and you can get the refund if not.

The same could apply to incoming HTLCs as long as you can reproduce your
HTLC pre-image deterministically.

PS good to hear you are a ZFS user too

>
> Thus, merely activating the wallet and using HTLCs may result in a
*detectable* failure of the hardware (which was already failing before,
just not noticed by the casual user).
>
> On the other hand, we can consider this situation as having a complexity
penalty.
>
> As someone who has seen a lot of storage devices slowly fail in unique
and interesting (and data-losing) ways, I am always going to assume that
storage devices are going to fail at any time, including a few hours after
installation.
>
> It would be preferable if HTLCs and PTLCs are not gifted.

Yes I am convinced.

> >
> > > Using static-key channels (i.e. channel keys are our node keys)
allows us to recover even the outgoing channel with outgoing HTLC that has
been forgotten by the outgoing peer.
> >
> > Right. I think this doesn't work with PTLCs though.
>
> Yes, loss of the adaptor signature means we cannot recover in this case.

Let's think about this again. There is no reason why the oblivious mutual
close has to be the only thing the peer sends you upon connection. They can
also send you the necessary signatures for each PTLC output on the mutual
close because you can't do anything with this unless you choose to receive
the mutual close signature. You verify these each time you connect without
data loss so optimistically you should be able to recover both incoming and
outgoing PTLCs

> Right, that would work.
>
> How about just using a multiplicative tweak of your own privkey and the
pubkey of the other node (i.e. just use the "raw" ECDH point), that would
work as 2-of-2 in 2p-ECDSA, and I believe (but do not know) should also be
signable using MuSig/MuSig2 under taproot?

I think multiplicative combination of keys does *not* work for Schnorr
multisignatures.

>
> "Peer selling private information" is always going to be an issue with
unpublished channels, and this seems to be an inherent issue with that
model.
>
> Note that due to the existence of proof-of-discrete-log-equivalence, a
node operator can *prove* to someone buying private information that a
particular outpoint onchain is actually an unpublished channel.
> If I have privkey `z` and you have pubkey `L`, I can show `z * G` (my
node pubkey), `L` (your "unpublished" (ha, ha) node pubkey), and `z * L`
(our ECDH secret), plus a proof-of-discrete-log-equivalence that the `z` in
`z * G` is the same `z` in `z * L`, in order to convice them of the ECDH
secret.
> 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`.
>
> As the ECDH secret is what tweaks the channel keys, that is enough to
convince any surveilling buyer.
> Further, `z` is not revealed, and channel funds cannot be stolen by just
knowledge of the ECDH secret, thus protecting the interests of the selling
forwarding node.
>
> Now of course, I could just be making up `L` (i.e. LL could be a
sockpuppet of mine).
> However, between these two choices:
>
> * I lock up a set number of millisatoshi in a Z + L channel where L is a
sockpuppet, and sell this fake information to surveillors.
> * I lock up a set number of millisatoshi in a Z + L channel where L is a
genuine user node that thinks unpublished channels are private, and sell
this genuine information to surveillors.
>
> Which is more lucrative for me?
> The latter case would be more lucrative for me, as I not only earn from
selling your 

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 you could just 
> > gift the money to the party offering the recovery settlement.
>
> Gifting the money is not a good option --- we allow HTLCs to be almost as 
> high as the total channel value minus fees and reserve.
> Thus all the claimable value could potentially be in an outgoing HTLC.
> Worse, if our node is a forwarding node, it would be easy for a third party 
> to arrange to have our funds in various HTLCs.

Hopefully this recovery system is used by people whose channels are in
a HTLC free state 99.% of the time (and hopefully hardware
failures do not somehow coincide with HTLCs!).
As a user, it would be cool to be able to just lock up all my Bitcoin
into channels with well-established lightning nodes. That way if fees
go ballistic I can still move money around cheaply.
One of the main concerns for this pattern of user behaviour is the
recovery story I think. The first line of defence for routing nodes
(people who are taking their role in LN seriously) has to be redundant
data storage.
This would be a poor last-resort solution for routing nodes.

> Using static-key channels (i.e. channel keys are our node keys) allows us to 
> recover even the outgoing channel with outgoing HTLC that has been forgotten 
> by the outgoing peer.

Right. I think this doesn't work with PTLCs though.

> Using static-key channels does have slightly weaker privacy:
>
> * Published nodes reveal all their channels with other published nodes on the 
> blockchain.
>   * While it is true that published nodes already reveal their channels with 
> published nodes, they are currently only revealed on the LN gossip network, 
> which is not archived; historical channels that are now closed are not 
> informed to current surveillors.
> * On the other hand, all it takes is one "LN wayback machine" to record 
> all LN gossip, which are self-attesting and include a signature from the node.
> * Unpublished nodes risk revealing their channels with published nodes via 
> the blockchain.
>   * Invoices created by unpublished nodes currently reveal their public key.
> Payers can then uncover all the channels of that node.

I don't think so? You need to know the private key of the node to
discover its channels! The points actually used in the channels would
be randomized with shared secret from Diffie-Hellman so are unlinkable
to the public keys of the two nodes under decisional Diffie-Hellman
assumption.

There is more minor but still real concern of "deniability" of
unpublished closed channels if a large node operator later becomes
corrupted or coerced by a malicious actor. Since the node operator
still knows their secret key (obviously) they can still do a scan
(same as you would do in recovery) on the whole chain and find any
past channels they had with any nodes. A mitigation of this problem
would be for users who want unpublished channels to turn the
use-node-key-as-channel-key feature off for their keys in the channel
so they would still be able to do a backup-free channel scan but the
well-established node would lose the ability to do so. This means that
after the channel is closed there would be no way for the large node
to find the channel again assuming they honestly delete the data.

Cheers,

LL
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev


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 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 unlike current system) and (ii) it's  "what you 
> > see is what you get" -- you are guaranteed to recover the funds that you 
> > are presented with once you finally trigger the recovery
>
> Off list Dave correctly pointed out to me that this wasn't a very clear 
> picture of the situation.
> After some thought, I came up with these claims that I think I can make 
> strongly:
>
> 1. Before you reveal that you are doing recovery you are guaranteed to have a 
> tx in hand that:
>  i. You can broadcast first
>  ii. You can choose the fee to be as high as you like
>  iii. Is not replaceable.
> 2. If the malicious party is *not* willing to risk broadcasting a revoked tx 
> then you are guaranteed to recover the face value of the transaction(s) you 
> have in hand.
> 3. An honest party is never at risk of broadcasting a revoked commitment tx.
> 4. You never have to reveal that you were doing a recovery i.e. the channel 
> can continue (strictly preferable to 1)
>
> Current system has: 3
> Oblivious mutual close has: 1,2,3
> YOLO commitments has: 1,5
>
> So I think the question of YOLO commitments vs oblivious mutual close is 
> whether paying the price of losing (2,3) is worth the upgrade from (1) to (5).
> The concern with (1) is that once you broadcast to the network the 
> obliviously transferred "mutual close" transaction, the malicious party then 
> has a hint that you have lost data and they can try and broadcast a 
> favourable revoked transaction.
> This should be very hard since in (1) you broadcast first, can choose as 
> large a fee as you like and the tx does not signal replaceability whereas the 
> revoked tx *will* signal replaceability.
> I'm also personally trying to avoid losing (3) because to keep [1] applicable.
>
> As a side note: in YOLO commitment transactions you have to recover some 
> additional metadata from the other party -- in particular the compressed 
> revocation keys that you *should* know otherwise the channel cannot continue 
> to operate. So a signature on the compressed revocation keys must be given to 
> the other party before you lose data and returned to you when you are given 
> the commitment transaction upon reconnection.
> This should be easy enough to do though.
>
> [1] 
> https://github.com/LLFourn/witness-asymmetric-channel#scorched-earth-punishments
>
> On Tue, Dec 15, 2020 at 12:13 AM David A. Harding  wrote:
>>
>> > The idea I'm working with in revocable signature based channels [1] is
>> > to make the node lose its static secret key if it posts a revoked
>> > commitment tx. This means they could lose ALL funds from ALL their
>> > channels with ALL their peers if they ever broadcast a single revoked
>> > commitment transaction. This would be a very bad thing to happen while
>> > you're trying to recover funds.
>>
>> Yikes!  A very bad thing indeed.  I'll have to re-read about witness
>> asymmetric channels; I don't think I realized that was a consequence of
>> using them.
>
>
> It's an optional feature -- see link[1] above where I just added an 
> explanation of it.
> I actually see no reason why you couldn't apply revocable signatures to 
> transaction asymmetric channels (LN as it is today) you just have to overhaul 
> the revocation mechanism.
>
> In general I agree with your points that side-channels may be effective tools 
> to reveal whether a node has had data loss or not.
> I think in both YOLO commitments and oblivious mutual close it is easy enough 
> to simulate data-loss up to a point to try and catch malicious peers using 
> side channels.
> At least you don't have to ask the peer to broadcast a tx to find out!
>
> Cheers,
>
> LL
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev


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 unlike current system) and (ii) it's  "what you
see is what you get" -- you are guaranteed to recover the funds that you
are presented with once you finally trigger the recovery

Off list Dave correctly pointed out to me that this wasn't a very clear
picture of the situation.
After some thought, I came up with these claims that I think I can make
strongly:

1. Before you reveal that you are doing recovery you are guaranteed to have
a tx in hand that:
 i. You can broadcast first
 ii. You can choose the fee to be as high as you like
 iii. Is not replaceable.
2. If the malicious party is *not* willing to risk broadcasting a revoked
tx then you are guaranteed to recover the face value of the transaction(s)
you have in hand.
3. An honest party is never at risk of broadcasting a revoked commitment tx.
4. You never have to reveal that you were doing a recovery i.e. the channel
can continue (strictly preferable to 1)

Current system has: 3
Oblivious mutual close has: 1,2,3
YOLO commitments has: 1,5

So I think the question of YOLO commitments vs oblivious mutual close is
whether paying the price of losing (2,3) is worth the upgrade from (1) to
(5).
The concern with (1) is that once you broadcast to the network the
obliviously transferred "mutual close" transaction, the malicious party
then has a hint that you have lost data and they can try and broadcast a
favourable revoked transaction.
This should be very hard since in (1) you broadcast first, can choose as
large a fee as you like and the tx does not signal replaceability whereas
the revoked tx *will* signal replaceability.
I'm also personally trying to avoid losing (3) because to keep [1]
applicable.

As a side note: in YOLO commitment transactions you have to recover some
additional metadata from the other party -- in particular the compressed
revocation keys that you *should* know otherwise the channel cannot
continue to operate. So a signature on the compressed revocation keys must
be given to the other party before you lose data and returned to you when
you are given the commitment transaction upon reconnection.
This should be easy enough to do though.

[1]
https://github.com/LLFourn/witness-asymmetric-channel#scorched-earth-punishments

On Tue, Dec 15, 2020 at 12:13 AM David A. Harding  wrote:

> > The idea I'm working with in revocable signature based channels [1] is
> > to make the node lose its static secret key if it posts a revoked
> > commitment tx. This means they could lose ALL funds from ALL their
> > channels with ALL their peers if they ever broadcast a single revoked
> > commitment transaction. This would be a very bad thing to happen while
> > you're trying to recover funds.
>
> Yikes!  A very bad thing indeed.  I'll have to re-read about witness
> asymmetric channels; I don't think I realized that was a consequence of
> using them.
>

It's an optional feature -- see link[1] above where I just added an
explanation of it.
I actually see no reason why you couldn't apply revocable signatures to
transaction asymmetric channels (LN as it is today) you just have to
overhaul the revocation mechanism.

In general I agree with your points that side-channels may be effective
tools to reveal whether a node has had data loss or not.
I think in both YOLO commitments and oblivious mutual close it is easy
enough to simulate data-loss up to a point to try and catch malicious peers
using side channels.
At least you don't have to ask the peer to broadcast a tx to find out!

Cheers,

LL
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev


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 actually needs
> them.  That's just as easily accomplished by sending the data upfront in
> plain text.
>

To be clear: The goal is to offer a cooperative settlement transaction up
front to the (possibly) recovering party -- *not a commitment transaction*.
Note we cannot send a cooperative settlement tx up front for each
connection since they are not revocable -- the channel is over once it has
been received.

I admit I didn't properly consider just sending commitment transactions
over. This is probably because it exposes the recovering party to the
punishment mechanism and in my most recent line of research you *really*
don't want to do this. The idea I'm working with in revocable signature
based channels [1] is to make the node lose its static secret key if it
posts a revoked commitment tx. This means they could lose ALL funds from
ALL their channels with ALL their peers if they ever broadcast a single
revoked commitment transaction. This would be a very bad thing to happen
while you're trying to recover funds.

I agree with your core point that in LN as it exists today the security
assumption of both methods is that the adversary will be unable to
distinguish a connection attempt after data loss from an ordinary one. If
they can reliably do this then both methods can lead to loss of funds so
why bother with the wonky crypto?

I think there is a subtle reason why oblivious settlement signatures are
still preferable: it is difficult to provide a coherent UX for recovery
when just sending YOLO commitment transactions. It would be best if the
recovery UX was "hey user I've found 0.367 Bitcoin across these three
channels would you like to recover them?". The user can then accept this or
cancel the recovery process and go through some extra trouble to recover
their data (in practice, data is often not completely lost but recoverable
with some effort). This is how it could work using the oblivious settlement
txs I proposed.

Using YOLO commitment transactions this becomes "hey user I've found 0.523
Bitcoin across three channels" which may actually be more than you are owed
to entice you to shoot yourself in the foot. Even if it's exactly what you
are owed, when you confirm the recovery your next message might be "nd
it's gone" because one of the commit txs was revoked.

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
unlike current system) and (ii) it's  "what you see is what you get" -- you
are guaranteed to recover the funds that you are presented with once you
finally trigger the recovery.

Although I do think oblivious settlement txs is a good idea I am working on
yet *another* recovery idea for doing peer provided encrypted backup and
full channel restoration in a way that provides another guarantee: If the
peer sends you an outdated encrypted backup (perhaps in the hope that it
has a revoked commitment tx in it) -- you can punish them immediately upon
receiving the backup (if you haven't actually had data loss).
Unfortunately, It looks like this will use more heavy cryptographic
primitives.

I think the challenge in either protocol above is deciding which peer
> goes first, because whoever sends the commitment transaction reveals
> what they think the current state is.  Any node that refuses to go first
> can then be suspected of having lost data.  BOLT2
> option_static_remotekey has this same problem, which is reasonably
> mitigated IMO by LN's penalty mechanism forcing any would-be thief to
> risk their own funds; this doesn't work for basic eltoo, though.
>

What is the story with option_static_remotekey? I am interested to know how
the negotiation of that option has a security issue but I don't see how it
could.

[1]: https://github.com/LLFourn/witness-asymmetric-channel

Cheers,

LL
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev


[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 peer and ask them to close it. The downside is that to a
malicious actor this request reads like "now is a good time to steal my
money or extort me".

What if instead we could somehow covertly get a signed cooperative
settlement transaction for the most recent state without your peer knowing
that you've received it?
Luckily this mystical and almost incoherent requirement is provided by one
of the oldest and well developed cryptographic primitives: the so called
"Oblivious Transfer" (OT).

https://en.wikipedia.org/wiki/Oblivious_transfer

The idea might go something like this: every time you connect to your peer
they present you with an unsigned cooperative settlement transaction for
all channels you have with them. You and your peer then do an oblivious
transfer where they send you their signatures on the transaction or nothing
(whichever you choose). If you want to carry on with the channel you reveal
to the sender that you chose nothing. If you are recovering funds you
choose the signatures and broadcast the transaction.

For this to be useful we have an extra requirement over typical OT which is
that we can verify the contents of the message we didn't choose. i.e. even
if we are not doing a recovery we have to be able to verify that the
signatures we were offered were valid (wihout actually ever being able to
use them!). Otherwise a malicious party could just be sending us invalid
signatures in the OT the whole time. The name for this oblivious signatures.

## Constructing

Oblivious signatures can be created using any verifiable encrypted
signature scheme where the encryption key is a group element (this includes
adaptor signatures).
In [1] they actually use adaptor signatures without calling them that to
create a Schnorr oblivious signature scheme that is similar to what you
would do with BIP340 Schnorr in practice.
I used this in [2] to create scriptless lotteries in Bitcoin.

To start assume that you have three functions (which can be instantiated
with adaptor signatures):

- `encrypted_sign(x, m, Y) -> e`
- `encrypted_signature_verify(X, m, Y) -> true/false`
- `decrypt_signature(e, y) -> s`

Where X is the public signing key Y is the encryption key and (x,y) are
their corresponding secret keys.
In our case x can be thought of as a secret key on a funding output.

First, the party receiving the offer decides whether they want to receive
the settlement tx signature by setting c = 0  or otherwise c = 1 and then
creates a pedersen commitment Y to c by choosing a random y:

Y = y *G + c * H

and sends the commitment Y to its peer.

The peer then sends `e = encrypted_sign(x, settlement_tx, Y)` back.

If c = 0 (i.e. it is doing a covert recovery) it does `s =
decrypt_signature(e, y)` and attaches to the settlement transaction and
broadcasts it.  The channel is now successfully closed assuming the
encrypted signature was valid.

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
signature (i.e. prove c = 1). If verification fails then the node is
malicious and it fails the channel. Note that it is not possible to decrypt
the signature if c = 1 since the discrete logarithm of H with respect to G
is unknown.

## Misc Q

- Does this require crazy crypto magic? No with the exception of Pedersen
commitments it only requires what is being planned to be included in
lightning anyway i.e. adaptor signatures.

-  Who is receiver and who is sender? In my imagination this works by the
peer that is opening the connection being the receiver. This seems more
useful since users who are likely to not have redundant storage and
generally mess things up and need to recover are often behind NAT or on
phone networks without a public ip. There are cases where a public node may
want to recover by having people connect to them but I don't know what to
do about that. It looks like you have to choose one or the other.

- Can't they still steal money? Yes but this is still a strictly better
than the current situation. The attacker has to guess precisely which
connection you make is after data loss. This is tricky task especially
because if they ever guess wrongly you close your channel with them and
block them. Right now you are the one who tells them you've lost data!

- Are these oblivious signatures secure? Yes. Sender security (receiver
only gets the signature if c = 0) is based on discrete log assumption.
Hint: if you instantiate the above algorithms with adaptor signatures we
can extract the discrete log of H from a receiver who knows an opening of Y
where c = 1 

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 change!
>

Yes that's certainly a fine way to do it.
I was also thinking you could eliminate all "basepoints" (not just funding
pubkey) using something like this. i.e. just use the node pubkey as the
"basepoint" for everything and randomize it using the shared secret for
each purpose.

Note that in practice you can have nodes reconnecting to you.
>

Hmm, this is a good point.
I was incorrectly assuming the best way to implement "recovery mode" would
be to never accept incoming connections.

We've long thought about peers supplying some storage for each other, so
> you can spray out (encrypted) backups that way.  It's actually a fairly
> trivial addition; your scheme makes for much less data to store.
>

I've also been thinking about the best way to go about this.
If you're able to encrypt some backups to different places then all you
have to do is find one of your honest channel partners using this method
and then get encrypted hints to find them all.

Cheers,

LL
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev


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 the
> `next_commitment_number`and the `next_revocation_number` both set to zero.
> This triggers the remote peer to force close the channel dropping its
> current commitment transaction to the chain. Using the
> `per_commitment_point` received from the remote peer you can now derive the
> private key needed for sweeping your funds, using
> privkey = basepoint_secret + SHA256(per_commitment_point || basepoint)
>

Thanks Gijs for describing how this works I wasn't quite sure.

The thing I dream of is being able to securely restore my layer 1 and 2
funds with just my seed.
There was discussion of this idea in last lightning dev meeting:
https://github.com/lightningnetwork/lightning-rfc/issues/821#issuecomment-740161185
A few of the concerns were:

1. You have to remember the counter

The intention here is to not have to remember any counter. Just as in BIP32
you just scan with some allowance for gaps.
roasbeef correctly points out that this may be more or less difficult
depending on your node setup and whether you can ballpark how long ago your
funding transactions were put down.
However since you are using this when you have lost your channel states
with no static channel backups I think it still provides a very realistic
chance of recovering a significant chunk of your funds.

Another point ariard made is that you only have to find one of the channels
with a peer to find all of them with a peer if there was some kind of "list
channels" message request.

2. It only works for public nodes who can be discovered

Correct. For my use of LN so far I am always connecting to public nodes so
it would likely work well for me.
I think this is true for most unsophisticated users who are most likely to
lose their channels with no backups.

If each peer allowed you to store some encrypted data with them then
finding one honest public peer through the chain could potentially let you
find all other peers (even the private ones).

3. We might not want to encourage doing channel recovery by asking the node
to force close channel

I agree. "PLEASE BLACKMAIL ME" is not a bad characterization of the channel
backup interaction Gijs describes above.
I believe there is a lot of room for improvement here. First you have to
find the channels though!


LL
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev


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 of a single paryment. I have just realized that it's
easy to prevent by just looking for duplicate payment hashes. This will be
a problem for randomized PTLCs though.

> * There are two griefing attacks:
>   * Loop attacks, which are deliberate malicious attacks to lock up funds
of competitors in order to redirect forwarding towards the attacker.
> * Accidental "attacks", which are accidental due to incompetence, where a
forwarding node accidentally goes offline and causes payments to be locked
up for long periods and making everyone on the network cry when HTLCs time
out and things have to be dropped onchain

Another one recently pointed out in [1] is to jam a channels towards a
competing merchant. Users who are trying to buy from the merchant will give
up because of technical failure and instead come to your site where you
will sell successfully for a higher price.
This seems more plausible to me than completing for fees.

Back to the general topic. Perhaps a way of refining the proposal is the
following:

1. Drop idea of "stake certificates" in favor of a chaumian e-cash kind of
design.
2. The owner (owners?) of leach LN UTXO can go to any node in the network
and request a kind of token for their UTXO (i.e. channel id).
3. When making a payment you present a randomized version of the token to
each node (it is not linkable to the UTXO) and prove that the UTXO it
represents is large enough to support the payment (the token and proof
protocol can hopefully be non-interactive so it can fit in the onion).
4. If your HTLC fails your token is deleted (and have to wait some period
before requesting a new one).
5. If your payment succeeds your token is renewed on the spot (and maybe
forwarded back along the path covertly).

Not saying this will be easy (or even totally coherent) but I feel the
direction is a bit more plausible.
The benefit here is that you avoid the complicated ZKPs about UTXOs and are
treading on a more well worn path of anonymous credentials and ecash.

[1]:
https://github.com/t-bast/lightning-docs/issues/7#issuecomment-736713076

LL

On Tue, Dec 1, 2020 at 11:11 PM ZmnSCPxj  wrote:

> Good morning LL, and list,
>
>
> > That's a very interesting point. If we were to be able to prevent loop
> attacks by the sender proving the path is well formed (without revealing
> who they are or any of the other hops) would this be an alternative
> solution?
> > It seems to me that disabling loop attacks might be much easier than
> stake certificates.
>
> Loop attacks are not about loops, it only requires that the start and end
> of a payment are controlled by the same entity.
>
> Multiple nodes on the LN may be owned by the same entity.
> Nodes, individually as nodes, are trivially cheap and just need 32 bytes
> of entropy from a `/dev/random` near you.
> It is the channels themselves, requiring actual funds, high uptime, and
> not being a dick to your counterparty, that are fairly expensive.
>
> Thus, a "loop attack" need not involve a loop per se --- a single entity
> can run any number of nodes with small numbers of channels each, and
> thereby grief the network.
>
> Stake certificates make the node itself expensive, so a single entity
> running a number of nodes cannot perform such loop attacks, since it would
> require entities expensively allocating funds for each node.
>
>
>
>
> On the other hand, if channels are expensive, then a node with channels is
> expensive.
>
> In
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-November/002890.html
> , which contains the "Z consideration" you were alluding to, I note that
> the "point-to-point property" is already proven by the ***existing***
> Lightning network without an additional ZK cryptographic proof.
>
> So let me invert that logic and present an even more extreme position:
>
> * There are two griefing attacks:
>   * Loop attacks, which are deliberate malicious attacks to lock up funds
> of competitors in order to redirect forwarding towards the attacker.
>   * Accidental "attacks", which are accidental due to incompetence, where
> a forwarding node accidentally goes offline and causes payments to be
> locked up for long periods and making everyone on the network cry when
> HTLCs time out and things have to be dropped onchain.
> * The point-to-point property, which is already proven by the
> ***existing*** Lightning network, is already sufficient to prevent loop
> attacks, leaving only accidental incompetence-based "attacks".
>   * Or: the ***existing*** Lightning Network ***already*** proves the
> point-to-point property presented by t-bast, and that property is
> ***already*** sufficient to prevent the loop attacks.
>
> So, maybe we should 

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

2020-11-30 Thread Lloyd Fournier
On Mon, Nov 30, 2020 at 7:34 PM Gleb Naumenko  wrote:

> Hi Lloyd,
>
> > I agree with Z that this proposal is missing a strong argument as to why
> this is a better “proof-of-stake” than channel balances themselves.
>
> I think Z’s consideration is about the alternative Stake Certificates
> proposed by t-bast, where every link in the route proves something to the
> next hop.
> For the context see this post, specifically “point-to-point property”:
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-November/002888.html
>

Thanks for the correction.


>
> I think you managed to apply the same argument to our original proposal as
> well :)
>
> > In order to send a jamming HTLC you have to have to lock up funds to do
> it (they need outgoing balance for the sender and incoming balance for the
> receiver).
>
> I think the issue here is with loop attacks (
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2015-August/000135.html)?
> This restriction with locking funds doesn’t really work…
> After getting past their intermediate hop, an attacker can make arbitrary
> loops and lock 100 BTC channels even by just having 1 BTC locked in the
> initial hop.
>
> Stake Certificates allow for a node in the middle of the route to
> distinguish where the payment is coming from (in a privacy-preserving
> manner of course), to distinguish heavy channel users from normal.
> They also allow to force an attacker to distribute jamming in time and
> across many channels.
>

That's a very interesting point. If we were to be able to prevent loop
attacks by the sender proving the path is well formed (without revealing
who they are or any of the other hops) would this be an alternative
solution?
It seems to me that disabling loop attacks might be much easier than stake
certificates.


> Perhaps, alternative restrictions may take place by restricting based on
> from which immediate channel/node they are coming (one-hop). But that
> sounds like a mess, as a payment sender doesn’t have any control, and
> gossiping that would probably be a privacy leak, also it still allows free
> jamming I think (just a bit different).
> The big deal here is to distinguish the flows, to better control them.
> We can discuss this separately.
>
> It’s true that any token might achieve the same goal here, but how to make
> it Sybil-resistant and prevent generating new tokens? Stake Certificates, I
> don’t know what else we can commit to.
>
> > If we are talking about non-economic adversaries who simply wish to
> destroy LN then that’s another game altogether.
>
> I was thinking about this scenario all the way, but maybe I should think
> about the other one as well.
>
>
But if we are talking about large holders of Bitcoin that just want to
destory LN this seems like a very weak mitigation since they will be able
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-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 is missing a strong argument as to why
> this is a better "proof-of-stake" than channel balances themselves.
> In order to send a jamming HTLC you have to have to lock up funds to do it
> (they need outgoing balance for the sender and incoming balance for the
> receiver).
> Why would stake certificates be more powerful than this? I get that you
> decrement the UTXO's credit even if they fail. This increases the cost of
> sending spam (but it also increases the cost of sending normal payments
> since you now may be honest but have all your UTXOs run out of credit.)
> Does this increased cost (it was not zero before) actually prevent the
> attack without inhibiting normal usage?
>
> In general there seems to be an open question about whether these channel
> jamming attacks are actually economic.
> If I want to get more payments routed through me would it really be
> optimal to do channel jamming?
> Suppose that the nodes react to the jamming by adding extra capacity by
> splicing out from somewhere else. Then I have jammed up my own coins and
> got nothing for it.
> What if instead of attacking I allocated the coins instead to creating
> more valuable channels. Couldn't this be more profitable?
> I just posed this question in [1].
>
> If we are talking about non-economic adversaries who simply wish to
> destroy LN then that's another

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 is missing a strong argument as to why
this is a better "proof-of-stake" than channel balances themselves.
In order to send a jamming HTLC you have to have to lock up funds to do it
(they need outgoing balance for the sender and incoming balance for the
receiver).
Why would stake certificates be more powerful than this? I get that you
decrement the UTXO's credit even if they fail. This increases the cost of
sending spam (but it also increases the cost of sending normal payments
since you now may be honest but have all your UTXOs run out of credit.)
Does this increased cost (it was not zero before) actually prevent the
attack without inhibiting normal usage?

In general there seems to be an open question about whether these channel
jamming attacks are actually economic.
If I want to get more payments routed through me would it really be optimal
to do channel jamming?
Suppose that the nodes react to the jamming by adding extra capacity by
splicing out from somewhere else. Then I have jammed up my own coins and
got nothing for it.
What if instead of attacking I allocated the coins instead to creating more
valuable channels. Couldn't this be more profitable?
I just posed this question in [1].

If we are talking about non-economic adversaries who simply wish to destroy
LN then that's another game altogether.
For example if the CCP with its 1% of all Bitcoin it seized from the
plustoken scam were to try and attack lightning they would likely succeed
even if we had this system in place simply because they have a lot of
"stake".
As David points out I don't think you can make a distinction between real
LN outputs and fake ones.
It seems unavoidable that any coins you own could be used to produce a
certificate to give you spam bandwidth (especially if you actually manage
to guarantee privacy through ZKPs).

[1] https://github.com/t-bast/lightning-docs/issues/7

Cheers,

LL


On Sun, Nov 29, 2020 at 5:25 AM David A. Harding  wrote:

> On Thu, Nov 26, 2020 at 11:40:46PM +0200, Gleb Naumenko wrote:
> >
> > Hello list,
>
> Gleb and Antoine,
>
> This is an interesting idea!  Thank you for working on it.
>
> I had difficulty with one part of the proposal:
>
> >  Should we allow holding *any* Bitcoins (not just LN channels) for
> Stake Certificates?
> >
> > [...] we believe that allowing any UTXO would give an attacker more
> > opportunities to use their cold funds for this attack, or even have a
> > secondary market where holders sell their proofs (they have nothing to
> > loose).
>
> Can't a malicious user get around this restriction by opening channels
> with themself?  (Also, aren't current channel open outputs just P2WSH
> 2-of-2 multisigs, and in the future won't they be generic P2TR outputs?
> How would a stake certificate prove that the UTXO was generated for LN
> rather than just belonging to a user with a 2-of-2 multisig wallet or
> any key-path-spendable taproot wallet?)
>
> According to some random website, the current total channel balance of
> the public LN is about 1,000 BTC.  Although I'm sure this will grow with
> time, it seems to me that an attacker who can rent access to stake
> certificates for a one-week attack at, say, a 5% annual interest rate
> would only need to pay 1 BTC to acquire stake certificates equal to all
> honest users at present.  That cost doesn't seem high enough to me to
> effectively prevent attacks.  Am I missing something?
>
> Thanks,
>
> -Dave
> ___
> Lightning-dev mailing list
> Lightning-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev


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

2020-10-10 Thread Lloyd Fournier
After posting I was tapped on the shoulder and informed that it is very
likely that we will have an enhanced secure parallel composition 2 round
MuSig in the future.
This is really good news.
This makes much of the post moot but I think the conclusion about being
able to do "pure scriptless" 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 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 communication before you can forward a
> payment.
> I think this is correct but perhaps you could just use 2 round MuSig
> (without MuSig-DN magic[4]).
>
> === 2 round MuSig ===
>
> (from memory) The original MuSig paper suggested the following signing
> algorithm once two keys A and B have already been established for Alice and
> Bob
>
> Alice   Bob
> pick ra randomly
> Ra = ra * G
>   - Ra >
> pick rb randomly
> Rb = rb * G
> let c = H(Ra + Rb || A + B
> || m)
> sb = rb + cb
>   <--Rb, sb
> s = sb + ra + ca
> R = Ra + Rb
> X = A + B
> verify(X, (R, s), m)?
> output: (R,s)
>
> This was insecure under *parallel composition* because the proof cannot
> work (from my memory because having open signing sessions makes the
> rewinding argument in the proof incoherent) and led to actual attacks which
> have recently improved in efficiency.[3]
>
> === My insight ===
>
> 2 round MuSig *is secure* under sequential composition and in a lightning
> channel we are essentially arranging sequential state updates so perhaps
> we're ok here?
>
> It should be easy to require that you can't open another signing session
> until we've finished the current session.
> Also if Alice has sent Ra there is no reason that Bob can't send multiple
> (Rb, sb) pairs for different messages for the same Ra while he wants for
> Alice to respond.
> Alice doesn't have to finish the signature yet she can just store the most
> recent one and finish if/when she needs to.
> This preserves the current update communication structure of lightning
> without breaking the security requirements of 2 round MuSig.
>
> === How could PTLCs work ===
>
> Updating states is more than just signing the commitment transaction.
> Let's assume we do PTLCs with both a PTLC-success and PTLC-timeout
> pre-signed transaction (I don't see how else to do it) on *both* sides of
> the channel.
> This means you have to pre-share the following:
>
> - A fresh pair of nonces for every existing PTLC in the state plus one
> extra (must be done every update)
> - A key for every existing PTLC in the state plus one extra (can be fixed
> at the start of the channel or updated as you go along).
>
> After pre-sharing this data Bob starts the communication with:
>
> (the postfix *-alice and *-bob means that they are in the tree of
> transactions on alice or bob's side, not necessarily that alice or bob is
> the one broadcasting it).
>
> Bob sends:
> - new PTLC details
> - (Rb,sb)-success(s)-bob (uses pre-shared nonce)
> - (Rb,sb)-success(s)-alice (uses pre-shared nonce)
> - (Rb)-commit-bob
> - (Rb)-timeout(s)-bob
> - (Rb)-timeout(s)-alice
>
> Alice sends back:
> -  (Ra,sa)-timeout(s)-bob
> -  (Ra,sa)-timeout(s)-alice
> -  (Ra,sa)-commit-bob
> -  (Ra)-commit-alice
> Bob sends:
> - (Rb,sb)-commit-alice
> - revocation key for last commitment
>
> **Note that Alice still hasn't revoked her last state but at this point
> she can safely forward the PTLC since Bob has revoked his last state.**
>
> Other notes:
> - This is and looks convoluted but it is simpler if you use witness
> asymmetry[2] because it removes duplicating the party's transactions across
> both sides.
> - Although you are doing parallel signing on the PTLC output key (you are
> signing both a timeout and success) a different party is receiving the
> signature and the nonces are communicated in reverse so it actually
> sidesteps the flaw of two round MuSig (where the adversary is always
> declaring his nonce second and second).
> - For protocols such as DLCs you will have to do proper three round MuSig
>

[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 communication before you can forward a payment.
I think this is correct but perhaps you could just use 2 round MuSig
(without MuSig-DN magic[4]).

=== 2 round MuSig ===

(from memory) The original MuSig paper suggested the following signing
algorithm once two keys A and B have already been established for Alice and
Bob

Alice   Bob
pick ra randomly
Ra = ra * G
  - Ra >
pick rb randomly
Rb = rb * G
let c = H(Ra + Rb || A + B
|| m)
sb = rb + cb
  <--Rb, sb
s = sb + ra + ca
R = Ra + Rb
X = A + B
verify(X, (R, s), m)?
output: (R,s)

This was insecure under *parallel composition* because the proof cannot
work (from my memory because having open signing sessions makes the
rewinding argument in the proof incoherent) and led to actual attacks which
have recently improved in efficiency.[3]

=== My insight ===

2 round MuSig *is secure* under sequential composition and in a lightning
channel we are essentially arranging sequential state updates so perhaps
we're ok here?

It should be easy to require that you can't open another signing session
until we've finished the current session.
Also if Alice has sent Ra there is no reason that Bob can't send multiple
(Rb, sb) pairs for different messages for the same Ra while he wants for
Alice to respond.
Alice doesn't have to finish the signature yet she can just store the most
recent one and finish if/when she needs to.
This preserves the current update communication structure of lightning
without breaking the security requirements of 2 round MuSig.

=== How could PTLCs work ===

Updating states is more than just signing the commitment transaction. Let's
assume we do PTLCs with both a PTLC-success and PTLC-timeout pre-signed
transaction (I don't see how else to do it) on *both* sides of the channel.
This means you have to pre-share the following:

- A fresh pair of nonces for every existing PTLC in the state plus one
extra (must be done every update)
- A key for every existing PTLC in the state plus one extra (can be fixed
at the start of the channel or updated as you go along).

After pre-sharing this data Bob starts the communication with:

(the postfix *-alice and *-bob means that they are in the tree of
transactions on alice or bob's side, not necessarily that alice or bob is
the one broadcasting it).

Bob sends:
- new PTLC details
- (Rb,sb)-success(s)-bob (uses pre-shared nonce)
- (Rb,sb)-success(s)-alice (uses pre-shared nonce)
- (Rb)-commit-bob
- (Rb)-timeout(s)-bob
- (Rb)-timeout(s)-alice

Alice sends back:
-  (Ra,sa)-timeout(s)-bob
-  (Ra,sa)-timeout(s)-alice
-  (Ra,sa)-commit-bob
-  (Ra)-commit-alice
Bob sends:
- (Rb,sb)-commit-alice
- revocation key for last commitment

**Note that Alice still hasn't revoked her last state but at this point she
can safely forward the PTLC since Bob has revoked his last state.**

Other notes:
- This is and looks convoluted but it is simpler if you use witness
asymmetry[2] because it removes duplicating the party's transactions across
both sides.
- Although you are doing parallel signing on the PTLC output key (you are
signing both a timeout and success) a different party is receiving the
signature and the nonces are communicated in reverse so it actually
sidesteps the flaw of two round MuSig (where the adversary is always
declaring his nonce second and second).
- For protocols such as DLCs you will have to do proper three round MuSig
but you are not forwarding payments so it's not as time sensitive.
- I am completely avoiding revocation mechanisms here but from my own ideas
and what I've seen from others this is compatible.

=== Claim Summary ===

Given the above, I claim there is a protocol using two-round MuSig for
fully scriptless lightning that incurs no extra rounds of communication to
get to the irrevocably committed state.
It does incur extra storage for each PTLC in the present commitment
transaction.
It includes an extra round to "fully" update the state between two parties
(but this does not delay payment forwarding).

I don't claim that this is the optimal path forward but just wanted to make
this observation to see what others thought.

LL

[1]
https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-December/002375.html
[2] https://github.com/LLFourn/witness-asymmetric-channel
[3] https://eprint.iacr.org/2020/945.pdf (thanks @n1cklr)
[4] https://eprint.iacr.org/2020/1057.pdf

Re: [Lightning-dev] Witness asymmetric payment channels

2020-10-07 Thread Lloyd Fournier
For those interested I've recently integrated the above refinements
and tried to coherently package the whole idea together here:
https://github.com/LLFourn/witness-asymmetric-channel

The main difference is that the protocol now uses what I am calling
"revocable signatures" as the 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 
>> 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 generated 
>> encrypted signature.
>> Seeing as the likely way forward would be to use MuSig on an output which 
>> has a taproot which hides a discrete 2-of-2 this may not be a problem.
>
>
> Upon further reflection I was missing something obvious when I came to this 
> conclusion. You can't produce the adaptor signature for a commitment 
> transaction deterministically without the encryption key (the other party's 
> publication point).
> As long as we have to store the other party's per-commitment publication 
> point we still need O(n) storage where n is the number of commitment 
> transactions. Sorry for the confusion.
>
> Fortunately I had a bit of a breakthrough which allows us to eliminate 
> publication points altogether and enables O(1) storage when 2-of-2 
> multi-signatures are instantiated with or without key aggregation (i.e. MuSig 
> or OP_CHECKMULTISIG).
>
> ### Eliminating Publication Points In favor of  "revocable signatures" (for 
> OP_CHECKMULTISIG)
>
> I propose replacing the publication point with a static key that remains the 
> same with each commitment transaction.
> The encryption key for each commitment transaction adaptor signature is (Ra + 
> A)  for Alice and (Rb + B) for Bob.
> Therefore, Alice broadcasting her commitment transaction would reveal the 
> discrete log of Ra + A (and Bob Rb + B).
> Note that if Alice has not revealed her recvocation key (Ra) for this 
> commitment transaction she is not in trouble since her static key A is 
> blinded by Ra. If she has then Bob will learn her static secret key for A.
> The intuition here is that the revocation key acts as a blinding factor for 
> the static key in the same way a nonce blinds your secret key in a schnorr 
> signature (more on that later).
> If you haven't revealed your revocation key then you are free to use that 
> signature. If you have revealed the revocation key then you have in effect 
> "revoked" the signature.
>
> Now we need to make sure that if a party learns the secret key of the other 
> they can efficiently punish them so make the following changes to my original 
> proposal:
>
> Balance output for Alice is  2-of-2(A , Rb + B)
> Balance output for Bob is   2-of-2(Ra + A, B)
>
> The implication of the above structure is that if you broadcast a commitment 
> transaction the other party can take their balance immediately.
> If you broadcasted a revoked commitment transaction then they can take their 
> output and yours immediately.
>
> PTLC outputs and all subsequent transaction outputs then simplify to 
> 2-of-2(A,B) on every output. Yay!
> Consider a PTLC paying to Alice. The PTLC-success output can be 2-of-2(A,B). 
> If Alice broadcasted it and it has been revoked then Bob knows A and B so he 
> can punish her.
> The converse is true for the PTLC-timeout.
> This elegant uniformity extends to other off-chain protocols hosted in these 
> channels e.g. DLCs
>
> Since A and B are static per channel and the secret keys for Ra and Rb can be 
> incrementally derived from subsequent values (as in the present lightning 
> spec) we have O(1) communication.
> In practice each 2-of-2(A,B) should be randomized so they don't all look the 
> same.
>
> ### Revoking key aggregated schnorr signatures (for MuSig)
>
> Even with the above improvement there is still O(n) storage if using key 
> aggregation (MuSig) on the funding transaction output.
> Key aggregation may be desirable here since you may want to not use a taproot 
> spend to broadcast a commitment transaction.
> Since the two party adaptor signature scheme needs randomness from both 
> parties, you would have to store the other party's nonce and retrieve it to 
> deterministically produce the adaptor signature so you can extract Ra + A (if 
> Alice broadcasts) from the witness of the commitment transaction.
>
> Fortunately, there is a natural way to revoke a key aggregated signature you 
> helped p

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
> generated encrypted signature.
> Seeing as the likely way forward would be to use MuSig on an output which
> has a taproot which hides a discrete 2-of-2 this may not be a problem.
>

Upon further reflection I was missing something obvious when I came to this
conclusion. You can't produce the adaptor signature for a commitment
transaction deterministically without the encryption key (the other party's
publication point).
As long as we have to store the other party's per-commitment publication
point we still need O(n) storage where n is the number of commitment
transactions. Sorry for the confusion.

Fortunately I had a bit of a breakthrough which allows us to eliminate
publication points altogether and enables O(1) storage when 2-of-2
multi-signatures are instantiated with or without key aggregation (i.e.
MuSig or OP_CHECKMULTISIG).

### Eliminating Publication Points In favor of  "revocable signatures" (for
OP_CHECKMULTISIG)

I propose replacing the publication point with a static key that remains
the same with each commitment transaction.
The encryption key for each commitment transaction adaptor signature is (Ra
+ A)  for Alice and (Rb + B) for Bob.
Therefore, Alice broadcasting her commitment transaction would reveal the
discrete log of Ra + A (and Bob Rb + B).
Note that if Alice has not revealed her recvocation key (Ra) for this
commitment transaction she is not in trouble since her static key A is
blinded by Ra. If she has then Bob will learn her static secret key for A.
The intuition here is that the revocation key acts as a blinding factor for
the static key in the same way a nonce blinds your secret key in a schnorr
signature (more on that later).
If you haven't revealed your revocation key then you are free to use that
signature. If you have revealed the revocation key then you have in effect
"revoked" the signature.

Now we need to make sure that if a party learns the secret key of the other
they can efficiently punish them so make the following changes to my
original proposal:

Balance output for Alice is  2-of-2(A , Rb + B)
Balance output for Bob is   2-of-2(Ra + A, B)

The implication of the above structure is that if you broadcast a
commitment transaction the other party can take their balance immediately.
If you broadcasted a revoked commitment transaction then they can take
their output and yours immediately.

PTLC outputs and all subsequent transaction outputs then simplify to
2-of-2(A,B) on every output. Yay!
Consider a PTLC paying to Alice. The PTLC-success output can be
2-of-2(A,B). If Alice broadcasted it and it has been revoked then Bob knows
A and B so he can punish her.
The converse is true for the PTLC-timeout.
This elegant uniformity extends to other off-chain protocols hosted in
these channels e.g. DLCs

Since A and B are static per channel and the secret keys for Ra and Rb can
be incrementally derived from subsequent values (as in the present
lightning spec) we have O(1) communication.
In practice each 2-of-2(A,B) should be randomized so they don't all look
the same.

### Revoking key aggregated schnorr signatures (for MuSig)

Even with the above improvement there is still O(n) storage if using key
aggregation (MuSig) on the funding transaction output.
Key aggregation may be desirable here since you may want to not use a
taproot spend to broadcast a commitment transaction.
Since the two party adaptor signature scheme needs randomness from both
parties, you would have to store the other party's nonce and retrieve it to
deterministically produce the adaptor signature so you can extract Ra + A
(if Alice broadcasts) from the witness of the commitment transaction.

Fortunately, there is a natural way to revoke a key aggregated signature
you helped produce without using adaptor signatures at all: just reveal the
nonce you used for it to the other party.
This prevents you from broadcasting it since the other party can now
extract your secret key from it!
Explicitly, two party signature generate two Schnorr signatures for the key
A + B in the form:

sa = ra + rb' + H(Ra + Rb' || A + B || m)(a + b)
sb = ra' + rb + H(Ra' + Rb || A + B || m)(a + b)

- (ra,rb) are the revocation secret keys,
- (ra', rb') are typical deterministically produced[1] nonces with Ra' =
ra' * G etc.
- (a,b) are the static secret keys

Only Alice knows sa and only Bob knows sb but they are both signatures on
the same commitment transaction.
This is the witness asymmetry in the protocol.

When revoking the commitment transaction associated with sa Alice reveals
ra to Bob and vice versa. If Alice uses sa after that, Bob can
deterministically produce rb' and ra (because each revocation key can be
derived from the last) and 

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 (a.k.a adaptor signature) **for that particular commitment
> transaction**.
> This means you have O(n) storage, unlike the present spec which has
> O(1) by deriving the previously revealed revocation secret from the
> present one (this can't be done with adaptor signatures).
> This doesn't seem to be addressed in the original work.
>
> Yikes! This might be a fatal flaw to this proposal unless it can be
addressed.
>

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 generated
encrypted signature.
Seeing as the likely way forward would be to use MuSig on an output which
has a taproot which hides a discrete 2-of-2 this may not be a problem.

LL
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev


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 sometimes with the current BOLT spec.

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.a adaptor signature) **for that particular commitment
transaction**.
This means you have O(n) storage, unlike the present spec which has
O(1) by deriving the previously revealed revocation secret from the
present one (this can't be done with adaptor signatures).
This doesn't seem to be addressed in the original work.

Yikes! This might be a fatal flaw to this proposal unless it can be addressed.

> When we have "the same" transaction on both sides, however, we need to 
> synchronize between the two sides.

Can you elaborate on this? I think you can carry on using the same
BOLT 2 update protocol within this channel system.
The txids being the same for both parties sometimes seems to be incidental.
It may be advantageous to use an alternative protocol that forces a
synchronization of the commitment transactions but I don't *think* it
is a requirement.
I guess you would need to sync  in Decker-Russell-Osuntokun because it
needs an objective ordering of commitment transactions.
That is seemingly not the case here though

LL

On Tue, Aug 25, 2020 at 10:45 PM ZmnSCPxj  wrote:
>
> Good morning Lloyd,
>
> I think this is excellent work overall.
>
> With that said...
>
>
> > -   It is more elegant as there are half the number of possible 
> > transactions. I
> > expect this will follow through to reduced implementation complexity 
> > and maybe
> > make it easier to explain as well.
>
> I am not sure the complexity will be reduced all that much.
>
> Currently:
>
> * We provide a partial signature for the other side for their commitment 
> transaction.
> * We keep our own commitment transaction and the partial signature we receive 
> from the other side.
>
> The node never has to retain the commitment transaction of the other side.
>
> With this setup:
>
> * We provide a partial signature for the other side for their asymmetric 
> signature.
> * We keep a copy of the shared commitment transaction and the partial 
> signature we received for our own asymmetric signature from the other side.
>
> So storage complexity is still the same.
>
> An issue is that with asymmetric transactions, it is fairly easy to use TCP 
> to communicate changes to the commitment txes.
> We send a bunch of HTLC changes we want to apply to the other side commitment 
> tx, then send a signature for those changes.
> Since what we send applies to *their* transaction only, we do not have to 
> consider what they sent to us, we just have to consider what we sent to them.
> Conversely, when keeping track of what our commitment transaction is, we only 
> have to consider what they sent to us, in order, and then when we receive a 
> signature we know it is for the commitment transaction with all the updates 
> the other side sent.
>
> (This arguably just moves the complexity higher, however: we cannot forward 
> an HTLC until both us and the other side have revoked the transactions that 
> do not contain it i.e. the "irrevocably committed" state.)
>
> When we have "the same" transaction on both sides, however, we need to 
> synchronize between the two sides.
> Suppose both participants want to forward HTLCs to one another.
> Without any kind of locking, both participants could send network packets 
> containing the HTLCs they want to add to each other, and it becomes ambiguous 
> whether the signature they *should* send contains one, or both.
>
> Basically, TCP only assures a global order for *one* direction of the 
> communications, once we have two network nodes talking simultaneously, the 
> order in which one writes and then reads is a lot more ambiguous.
>
> This issue also exists for Decker-Russell-Osuntokun, incidentally.
>
> One way to solve this would be to have a "token" that is passed alternately 
> between the participants.
> At initial connection, they run a secure multiparty coinflip that indicates 
> which one gets the token.
> Then, the one that holds the token can add more HTLCs, then tell the other 
> "okay, now we sign" and they exchange signatures for a new version that 
> involves only the HTLCs from the token-holder.
> Then the token-holder passes the token to the other side.
>
> If the current token-holder does not have any HTLCs it wants to send, it can 
> wait for some time (in case it receives a request to forward), then if there 
> are still no HTLCs, it can pass the token to the other side by sending a 
> 

[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: https://github.com/LLFourn/witness-asymmetric-channel

The purpose of this post is to get feedback to see if it's worth doing
a PoC implementation.

# Background

As presently specified the two parties in a lightning channel are assigned
different commitment transactions. This _transaction asymmetry_ is logically
necessary for the protocol to identify which party broadcasted a commitment
transaction and potentially punish them if the other party provides
proof it has been revoked (i.e. knows the revocation key).

Wouldn't it be nice if we could identify the broadcasting party without
assigning them different transactions? Riard first considered this problem in
[8] while trying to add a punishment mechanism to eltoo[9] style channel
updates. They proposed that you could identify the broadcasting party using
_witness asymmetry_ i.e. both parties broadcast the same transaction but have
different witnesses. Unfortunately, the solution proposed is rather convoluted.

More recently in [1], Aumayr et al. introduced a much more elegant witness
asymmetric solution using adaptor signatures. Instead of being assigned
different transactions, the parties are assigned different adaptor signatures as
witnesses for the _same_ transaction. The adaptor signatures force the party
broadcasting a commitment transaction to reveal a "publishing secret" to the
other party. The honest party can then use this publishing secret along with
knowledge of the usual revocation secret to punish the malicious party for
broadcasting an old commitment transaction.

Aumayr et al. combine this idea with a "punish-then-split" mechanism similar to
the original eltoo proposal. Unfortunately, it therefore inherits the same issue
with staggering time-locks. BOLT 3 [4] describes why it avoids this problem as a
design choice:

> The reason for the separate transaction stage for HTLC outputs is so that
> HTLCs can timeout or be fulfilled even though they are within the
> to_self_delay delay. Otherwise, the required minimum timeout on HTLCs is
> lengthened by this delay, causing longer timeouts for HTLCs traversing the
> network.

There is further background discussion to this choice in [2] and Towns proposes
a solution for eltoo in [3].

In short, the problem is that it creates a risk for the party that needs to
fulfill an HTLC with the secret in time. The only known way of accounting for
this risk is to increase the difference between the time-locks on each hop.
There could be situations where this trade off makes sense but it seems
undesirable for a general purpose payment channel network.

# Proposal

I propose a channel protocol which steals the main idea from Aumayr et al. while
retaining the time-lock precedence of BOLT 3 transactions. That is, absolute
time-locks are settled before relative time-locks to avoid having to account for
relative time-locks when calculating absolute time-locks.

The guiding principle is to keep commitment transactions symmetric but to use
the asymmetric knowledge of the parties to simulate the way lightning works
right now. The main benefits of this seem to be:

- It is more elegant as there are half the number of possible transactions. I
  expect this will follow through to reduced implementation complexity and maybe
  make it easier to explain as well.
- Every output can just be a 2-of-2 multi-sig (which could be a single key with
  MuSig or OP_CHECKMULTISIG with ECDSA etc). This makes the transactions a
  little smaller even when using 2-of-2 with ECDSA on balance, The space saving
  comes from avoiding explicit revocation keys in the commitment transaction
  outputs and using PTLCs rather than HTLCs.
- The design works today and easily transitions into a post-taproot world
  although there is still a bit to explore there [5].

## Notation

I describe the protocol with respect to two parties Alice and Bob. 2-of-2(Xa,Xb)
refers to a multi-signature output that supports adaptor signatures and requires
the owners of Xa (Alice) and Xb (Bob) to authorize it (e.g. `OP_CHECKMULTISIG`
with ECDSA [6], or MuSig with Schnorr etc [7]).

## The Fund transaction

The structure of channel funding does not change from the current BOLT spec. The
Fund transaction spends from the funding party's (or funding _parties_) outputs
to an output of 2-of-2(Fa,Fb) where Fa and Fb are public keys owned by Alice and
Bob respectively. These keys are generated and exchanged once per channel.

## Commitment transactions

All commitment transactions spend from the 2-of-2 on the Fund transaction and
each represents a "state" of the channel. A commitment transaction has two
balance outputs and zero or more PTLC outputs.

Before creating a commitment transaction the 

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 current paradigm may be shifted by LN
> > where fast, affordable, confidential, censorship-resistant payment
> services
> > may attract a lot of adoption without users running a full-node.
>
> No, it cannot be shifted. This would compromise Bitcoin itself, which for
> security depends on the assumption that a supermajority of the economy is
> verifying their incoming transactions using their own full node.
>

Hi Luke,

I have heard this claim made several times but have never understood the
argument behind it. The question I always have is: If I get scammed by not
verifying my incoming transactions properly how can this affect anyone
else? It's very unintuative.  I've been scammed several times in my life in
fiat currency transactions but as far as I could tell it never negatively
affected the currency overall!

The links you point and from what I've seen you say before refer to "miner
control" as the culprit. My only thought is that this is because a light
client could follow a dishonest majority of hash power chain. But this just
brings me back to the question. If, instead of BTC, I get a payment in some
miner scamcoin on their dishonest fork (but I think it's BTC because I'm
running a light client) that still seems to only to damage me. Where does
the side effect onto others on the network come from?

Cheers,

LL
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev


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 the previous one
are revoked. However, there is an issue at step 6. After sending her
revocation secret to Bob, Alice cannot anymore enforce the result from the
first contract. However, as Bob has not yet revealed his secret, he still
has the ability to do so, in addition to having the ability to enforce the
second one. If Bob is dishonest, he could thus choose not to reveal his
revocation key, and wait until just before the maturity of the second
contract to execute the one that is most favorable to him (he could also
potentially use the previous refund transaction if the time lock expired)."

Since Alice has the signed transactions for the new state, if Bob refuses
to revoke the old state why can't she just post the new state on chain
immediately? This limits Bob's "option" and I thought is the optimal
solution whenever this problem occurs.

Cheers,

LL

On Tue, Apr 28, 2020 at 5:43 PM LE GUILLY THIBAUT <
thib...@cryptogarage.co.jp> wrote:

> Hi list,
>
>
> First let me introduce myself as this is my first time posting. My name is
> Thibaut and I’ve been working at Crypto Garage for some time, mainly
> focusing on DLC. With my colleagues Ichiro Kuwahara and Takatoshi Nakagawa
> , we have been researching on how to construct DLC channels, and how such
> channels could be integrated in the Lightning network. As there are
> currently quite some discussions around DLC, we thought that it was a
> good time to share the result of this research. You can find the paper on
> github (
> https://github.com/p2pderivatives/offchain-dlc-paper/blob/master/offchaindlc.pdf
> ) , and I’ll try to summarize it here (if you’re not familiar with DLC I
> recommend going for the paper as I’ll assume some knowledge in the
> following, also it has nice figures and everything so nice to skim
> through as a support for the description here). We’d be happy to hear
> feedback from the community on the feasibility of the approach we propose, 
> both
> theoretically and practically.
>
>
> Motivation
>
> ==
>
>
> At the moment, once a DLC expires, both parties need to close and open a
> new one in order to re-enter in a contract. This is wasteful as it requires
> at the minimum two extra on-chain transactions (one for mutual closing, and
> a new funding tx). So one would like to have a way to have actual DLC
> channels, where two parties can keep establishing contracts between
> themselves as long as the balance in the channel allows it. Creating such
> channels is less trivial than it may seem at first glance, as one tricky
> part is to ensure that no party can ever have the possibility of both
> enforcing the outcome of a previous contract or that of the latest contract
> (so they could pick the most favorable to them). I’ll refer to this issue
> as the “free option” problem hereafter, but it shouldn’t be confused with
> the free option problem of atomic swaps.
>
>
> In addition, if we are to implement such DLC channels, we would like to
> avoid having to re-do all the work and instead take advantage of the
> existing Lightning Network infrastructure. Note that the integration
> solution we propose is generic and would work to integrate other types of
> layer 2 protocol in LN. It also permits the existence of multiple
> concurrent channels, so two parties could have multiple DLC at the same
> time using a single fund transaction.
>
>
> Note that one of our motivation was also to come up with something that
> doesn’t require any changes to the Bitcoin transaction structure or
> SIGHASH or any new cryptographic operation, as it is rather trivial to
> implement in an eltoo context for example.
>
>
> Related Work
>
> ==
>
>
> Juraj Bednár and René Pickhardt previously proposed Lightning DLC channels
> [1]. Their construction works by adding an output to a LN commitment
> transaction, from which the regular set of DLC transactions can be
> attached. Our approach differs in two ways:
>
>1. Our DLC channel construction can be made standalone, meaning they
>could be deployed outside (or alongside) of the LN
>2. The integration with LN that we propose allow for more separation
>of concerns between the channels, as they can be updated separately
>without influencing each others (their construction requires
>re-building all transactions for any update, we only require this for
>opening/closing and re-balancing).
>
>
> Bednár and Pickhardt approach is similar to the one briefly described by
> Ben Carman of Suredbit in the first section of [2]. He then proposes
> routed DLC that require PTLC and barrier escrow. While our proposal only
> works for direct channels (so 

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 working end to end.
> Instead, the real impediment has been the bootstrapping of the oracles
> which the scheme critically depends upon.
>

Oracles certainly require a huge bootstrapping effort but I think that some
of the limitations of the original also hurt the progress of DLCs. The
original protocol requires three on-chain transactions, asymmetric state
and punishment transactions (i.e. you have to run a node to watch the
chain). The original DLC is also easy to get wrong:
https://github.com/mit-dci/dlcspec/issues/5.

The PTLC based DLC on the other hand is rather straightforward with only
two transactions, symmetric state and no penalty transactions. Even more
importantly, it has no liveness requirement after the funding transaction
is down (assuming there are no refund transactions) -- you can wait as long
as you want before claims funds. For me, this makes the whole idea far more
attractive both as a user and developer.

Self plugs: I wrote a short paper on how to optimise the DLCs so they could
get more adoption:
https://github.com/LLFourn/two-round-dlc/blob/master/main.pdf. I am also
working on a framework for oracle deployment which will be ready soon™.

LL



>
> On Thu, Apr 23, 2020 at 7:52 AM Nadav Kohen  wrote:
>
>> Hi Laolu,
>>
>> Thanks for the response :)
>>
>> I agree that some more framing probably would have been good to have in
>> my update.
>>
>> First, I want to clarify that my intention is not to implement a
>> PTLC-based lightning network on top of ECDSA adaptor signatures, as I do
>> believe that using Schnorr will be superior, but rather I wish to get some
>> PoC sandbox with which to start implementing and testing out the long list
>> of currently theoretical proposals surrounding PTLCs, most of which are
>> implementation agnostic (to a degree anyway). I think it would be super
>> beneficial to have more fleshed out with respect to what some challenges of
>> a Payment Point LN are going to be than we understand now, before Schnorr
>> is implemented and it is time to commit to some PTLC scheme for real.
>>
>> Second, I agree that I've probably understated somewhat the changes that
>> will be needed in most implementations as I was mostly thinking about what
>> would need to change in the BOLTs, which does actually seem relatively
>> minimal (although as you mention, these minimal changes to the BOLTs do
>> trigger large changes in many implementations). Also, good point on how
>> BOLT 11 (invoicing) will have to be altered as well, must've slipped my
>> mind.
>>
>> Best,
>> Nadav
>>
>> On Wed, Apr 22, 2020 at 8:17 PM Olaoluwa Osuntokun 
>> wrote:
>>
>>> Hi Nadav,
>>>
>>> Thanks for the updates! Super cool to see this concept continue to evolve
>>> and integrate new technologies as they pop up.
>>>
>>> > I believe this would only require a few changes to existing nodes:
>>>
>>> Rather than a "few changes", this would to date be the largest
>>> network-level
>>> update undertaken to the Lightning Network thus far. In the past, we
>>> rolled
>>> out the new onion blob format (which enables changes like this), but
>>> none of
>>> the intermediate nodes actually need to modify their behavior. New
>>> payment
>>> types like MPP+AMP only needed the _end points_ to update making this an
>>> end-to-end update that has been rolled out so far in a de-synchronized
>>> manner.
>>>
>>> Re-phrasing deploying this requires changes to: the core channel state
>>> machine (the protocol we use to make commitment updates), HTLC scripts,
>>> on-chain HTLC handling and resolution, path finding algorithms (to only
>>> see
>>> out the new PTLC-enabled nodes), invoice changes and onion blob
>>> processing.
>>> I'd caution against underestimating how long all of this will take in
>>> practice, and the degree of synchronization required to pull it all off
>>> properly.
>>>
>>> For a few years now the question we've all been pondering is: do we wait
>>> for
>>> scnhorr to roll out multi-hop locks, or just use the latest ECDSA based
>>> technique? As dual deployment is compatible (we can make the onion blobs
>>> for
>>> both types the same), a path has always existed to first roll out with
>>> the
>>> latest ECDSA based technique then follow up later to roll out the schnorr
>>> version as well. However there's also a risk here as depending on how
>>> quickly things can be rolled out, schnorr may become available
>>> mid-development, which would possibly cause us to reconsider the ECDSA
>>> path
>>> and have the network purely use scnhorr to make things nice and uniform.
>>>
>>> Zooming out for a bit, the solution space of "how channels can look post
>>> scriptless-scripts + taproot" is rather large [1], and the addition 

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

2020-03-05 Thread Lloyd Fournier
> Why do we need another HTLC to be established from B to A ?

We don't. This wasn't what I was saying. The atomic swap example was just
to show that your idea does exist in a different context. An atomic swap
can be viewed as a payment A -> B -> A where B switches the currency.

> Pardon me if I am wrong but I am still confused why situation 1 will not
be possible ?

It is possible. In A -> B, A is able to punish B for not revealing secret.
The problem is with A -> B -> C, the HTLCs need to be set up from left to
right, A can't punish B for not revealing secret because he doesn't know
it. B cannot set up the HTLC to C before having the HTLC from A. So it
doesn't work -- or at least that's the conventional conclusion. To
summarise:

A -> B : punishment works
A -> B -> A: punishment works
A -> B -> C: it can't work (we think)

LL

On Fri, Mar 6, 2020 at 6:03 PM Subhra Mazumdar <
subhra.mazumdar1...@gmail.com> wrote:

> Can you send the draft on fair atomic swap? Also the scenario stated in
> the pdf you have shared is based on exchange of asset. But here I am not
> trying to work on different ledger A to B and B to A. Here it deals with
> just simple transfer of funds from A to B. So whatever HTLC A establishes
> with B, is it not the case where just one HTLC from A to B is enough? Why
> do we need another HTLC to be established from B to A ?  To clarify this,
> we have two 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 (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 12:00 PM Lloyd Fournier 
> wrote:
>
>> 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.mazumdar1...@gmail.com> wrote:
>>
>>> Hi,
>>>   I was reading the paper by Poon and Dryja on Bitcoin Lightning
>>> Network and was going through the construction of HTLC. Suppose 2 parties A
>>> and B have a channel with each party locking 0.5 BTC. Suppose A wants to
>>> transfer 0.1 BTC to B contingent to the knowledge of R : H=h(R) produced
>>> within a locktime of say t days. So the script output for A is -
>>> 1. 0.4 BTC to A
>>> 2. 0.5 BTC to B
>>> 3. 0.1 BTC locked in HTLC between A & B.
>>> Why we cannot set the terms as say 0.4 BTC to A, 0.2 BTC to B and 0.4
>>> BTC to HTLC, where HTLC output can follow either of the paths - If B
>>> produces R within t days then it gets back 0.4 BTC else after t days A can
>>> broadcast with 0.4 BTC going to the A? This prevents B from not responding
>>> (and induce possibly griefing attack across a longer path by withholding
>>> the solution) since it will lose out 0.3 BTC. What can be the problem if
>>> the terms of HTLC itself tries to enforce a penalty on the counterparty?
>>>
>>> --
>>> Yours sincerely,
>>> Subhra Mazumdar.
>>>
>>> ___
>>> Lightning-dev mailing list
>>> Lightning-dev@lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>>
>>
>
> --
> Yours sincerely,
> Subhra Mazumdar.
>
>
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev


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

2020-03-05 Thread Lloyd Fournier
If you can atomically set up both those penalties atomically then that
would be a big breakthrough. It looks impossible. The problem is one will
be set up before the other and it is only fair if both are set up at the
same time.

LL

On Fri, Mar 6, 2020 at 5:34 PM Subhra Mazumdar <
subhra.mazumdar1...@gmail.com> wrote:

> But wont the decision of penalty be based on what incoming contract
> expects from a node ? Suppose there is a contract between A and B and then
> B and C, where A wants to transfer money to C. So if it is the case that A
> impose penalty on B using its local 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 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.mazumdar1...@gmail.com> wrote:
>>
>>> Hi,
>>>   I was reading the paper by Poon and Dryja on Bitcoin Lightning
>>> Network and was going through the construction of HTLC. Suppose 2 parties A
>>> and B have a channel with each party locking 0.5 BTC. Suppose A wants to
>>> transfer 0.1 BTC to B contingent to the knowledge of R : H=h(R) produced
>>> within a locktime of say t days. So the script output for A is -
>>> 1. 0.4 BTC to A
>>> 2. 0.5 BTC to B
>>> 3. 0.1 BTC locked in HTLC between A & B.
>>> Why we cannot set the terms as say 0.4 BTC to A, 0.2 BTC to B and 0.4
>>> BTC to HTLC, where HTLC output can follow either of the paths - If B
>>> produces R within t days then it gets back 0.4 BTC else after t days A can
>>> broadcast with 0.4 BTC going to the A? This prevents B from not responding
>>> (and induce possibly griefing attack across a longer path by withholding
>>> the solution) since it will lose out 0.3 BTC. What can be the problem if
>>> the terms of HTLC itself tries to enforce a penalty on the counterparty?
>>>
>>> --
>>> Yours sincerely,
>>> Subhra Mazumdar.
>>>
>>> ___
>>> Lightning-dev mailing list
>>> Lightning-dev@lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>>
>>
>
> --
> Yours sincerely,
> Subhra Mazumdar.
>
>
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev


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 <
subhra.mazumdar1...@gmail.com> wrote:

> Hi,
>   I was reading the paper by Poon and Dryja on Bitcoin Lightning
> Network and was going through the construction of HTLC. Suppose 2 parties A
> and B have a channel with each party locking 0.5 BTC. Suppose A wants to
> transfer 0.1 BTC to B contingent to the knowledge of R : H=h(R) produced
> within a locktime of say t days. So the script output for A is -
> 1. 0.4 BTC to A
> 2. 0.5 BTC to B
> 3. 0.1 BTC locked in HTLC between A & B.
> Why we cannot set the terms as say 0.4 BTC to A, 0.2 BTC to B and 0.4 BTC
> to HTLC, where HTLC output can follow either of the paths - If B produces R
> within t days then it gets back 0.4 BTC else after t days A can broadcast
> with 0.4 BTC going to the A? This prevents B from not responding (and
> induce possibly griefing attack across a longer path by withholding the
> solution) since it will lose out 0.3 BTC. What can be the problem if the
> terms of HTLC itself tries to enforce a penalty on the counterparty?
>
> --
> Yours sincerely,
> Subhra Mazumdar.
>
> ___
> Lightning-dev mailing list
> Lightning-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev


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 heuristic. From
a design perspective it feels like leaving the improvement vector open
would be better.

Aj's model of scriptless lightning is more or less what I had in my mind
(but with much better detail). On the question of "script based payment
points" or "fully scriptless": Why not just do both?

Since the tapscript version is faster to the "irrevocably committed" state,
you first do that so you can forward the payment as fast as possible. Now
that both parties have a commitment tx with a tapscript PTLC, they can (in
no hurry) sign the scriptless spending transactions from the PTLC output. I
think once they have signatures on their scriptless PTLC transactions they
can forget all the tapscript data (to minimize the data they have to store
per commitment tx).

> But with taproot you can have a script path as well, so you could have a
> script:

>A CHECKSIGVERIFY B CHECKSIG

> and supply a partial signature:

>R+X,s,X where s = r + H(R+X,A,m)*a

> to allow them to satisfy "A CHECKSIGVERIFY" if they know the discrete
> log of X, and of course they can sign with B at any time. This is only
> half a round trip, and can be done at the same time as sending the "I
> want to do a PTLC for X" message to setup the (ultimately cheaper) MuSig
> spend. It's an extra signature on the sender's side and an extra
verification
> on the receiver's side, but I think it works out fine.

This is exactly how I thought the "script based payment point" would work
where you just replace the hashing with an CHECKSIG and an adaptor sig.
Like Z, I don't see how you can get away with just that though. I think you
need to do a full tapscript PTLC and revocation (1.5 round trips) before
you can forward a payment.

Cheers,

LL
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev


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. I've been pitching the language name as
"Improv" (since it's scriptless!). I think it would allow you to specify
the rules by which each output on each transaction can be spent and would
compile those rules into a protocol that does the secure key and signature
exchange for all the transactions in the scaffold. In other words, a
protocol compiler. I think this could be really useful for formal
specification of layer-2 protocols.

LL

On Thu, Oct 10, 2019 at 3:31 PM ZmnSCPxj via Lightning-dev <
lightning-dev@lists.linuxfoundation.org> wrote:

> Good morning Nadav,
>
> Thank you very much for this framework!
> It seems very good idea, kudos to making this framework.
>
> 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.
>
>
> > Idea 2: DLCs Routed over Lightning
> > Say that some DLC oracle will either broadcast s_A or s_B whose public
> points are S_A and S_B (which can be computed from public information as
> per the DLC scheme). Then say that Alice and Bob enter into a contract
> under which Alice wins some amount if s_A is broadcasted and Bob if s_B is
> broadcasted. Say Alice has a point A and Bob has a point B. They each send
> the other a payment with the amount that party must receive if they win
> with the payment point A + S_A for Bob's payment to Alice and B + S_B for
> Alice's payment to Bob. And this is it! If s_A is broadcasted then Alice
> gets paid (and Bob gets proof of payment a, which is the scalar to A),
> otherwise s_B is broadcasted and Bob gets paid (with Alice receiving b as
> PoP). An interesting note is that under this scheme neither party is forced
> to pay extra on-chain fees in the case of a counter-party who doesn't
> cooperate whilst in the wrong.
> > One wrinkle with this scheme is that setup isn't trustless. Although it
> is generally true that one party must sign the funding transaction for a
> DLC before the other party for on-chain DLCs, at least there is the
> mitigation that when your counter-party goes silent, you can move your
> input funds invalidating the funding transaction you signed (at a cost
> because fees). So what can we do here to ensure that both payments are
> setup at the same time in the case that Alice and Bob don't trust each
> other?
> > Say that although they don't trust each other, they're both willing to
> trust some escrow entity who generates some point E for their payment.
> Alice's payment point to Bob becomes B + S_B + E and Bob's to Alice becomes
> A + S_A + E. The escrow now waits to hear from Alice and Bob that they have
> incoming payments setup and only once both of them attest to this (using
> signatures, for example) does the escrow release the scalar to E to them
> both. The escrow can also have a timeout at which it will never reveal the
> scalar to E: forcing both parties to commit to the contract well before the
> DLC event. In this way, trust has been moved from counter-party to
> trustworthy (hopefully) escrow in such a way that the Escrow learns nothing
> about the contract itself (other than that there is one of some kind).
>
> I think we can call this a "barrier escrow".
>
> * It is similar to the concept of synchronization barriers for multithread
> coordination: https://en.wikipedia.org/wiki/Barrier_(computer_science)
> * In effect, each sub-transaction of the entire arrangement is a "thread"
> of operation, and the "barrier escrow" ensures that all the threads have
> reached it before letting them continue to claim the payments.
>
>
> I seem, this is applicable to *not only* DLC, but others as well.
> Instead, it seems to me to also provide an alternate solution to the
> Premium-free American Call Option Problem.
>
> Let us introduce our characters:
>
> * B, a supposed buyer, holding some Bitcoin.
> * S, a supposed seller, who wishes to be paid in another asset.
> * X, a cross-currency exchange Lightning node.
> * E, a tr\*sted escrow.
>
> X would like to facilitate exchanges across different assets, but wants to
> be paid a premium in order to prevent the Premium-free American Call Option
> Problem.
> B would like to swap its Bitcoin for another asset to pay S, and would be
> willing to pay the above premium, but only conditional on S actually
> getting the asset it wants to be paid in.
> X and B are non-trusting to each other, but are willing to tr\*st escrow E.
>
> This again is another "two transactions" setup, where we move tr\*st from
> X and B and transfer it to E.
>
> * B forwards the payment to be exchanged through X 

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
access structure*.

> Essentially the idea is to use the point S + ECDH(B, E) where S is the
seller's point, B is the buyer's point and E is the escrow's point

I can't see how you can create an access structure like this with ECDH.
Neither B nor E know the discrete log of ECDH(B,E). I can see that you can
hash it and use it as a scalar but then you have to make a heavy zkp to
prove the validity (or interact with the escrow which violates the premise).

Fortunately, I think it is possible to create any monotone access structure
on a discrete logarithm using *verifiable encryption*.  Applying this to
the Escrow payment problem, the buyer decides on the payment point B and
verifiably encrypts the discrete logarithm of B under the Escrow's public
key E and sends the encryption to the seller. If there's a dispute, the
seller sends the encryption to the Escrow. If the Escrow resolve the
dispute in favour of the seller they just decrypt the ciphertext and send
the discrete log of B to the seller. The seller can now redeem the payment.

If we want to create more complex access structures then we use verifiable
secret sharing where the discrete log of B is split up into shares and
distributed according the the desired structure.

So how do we do this verifiable encryption/secret sharing? Well it's not
really straight forward. In the case of Escrow, Camenisch-Shoup [1]
verifiable encryption might be attractive since the Escrow can be trusted
to produce the Paillier modulus properly. Otherwise there's
Camenisch-Damgaard [2] which is much less efficient but only relies on CDH
assumption. As far as I know there are no usable implementations of either
of these schemes but Camenisch-Damgaard is relatively straightforward and I
think it's practical.

[1] https://www.shoup.net/papers/verenc.pdf
[2] https://eprint.iacr.org/1999/008

LL

On Thu, Oct 10, 2019 at 10:43 AM Nadav Kohen  wrote:

>  Hi list,
>
> I'm back again with another idea about Payment Points and fun things to do
> with them! Hopefully this time I'm not entirely just hashing out old ideas
> in public like an out-of-the-loop person :)
>
> *TLDR: Adding and ECDH-ing points gives us AND and OR functionality which
> we can compose to make cool lightning contracts like Multisig, Escrow, and
> DLCs*
>
> So when looking at the following (likely incomplete) list of things you
> can do with payment points:
>
> 1) Payment De-correlation
> 2) "Stuckless" Payments
> 3) High AMP
> 4) Selling Signatures
> 5) Selling Pedersen De-commitment
> 6) Escrow Contracts
>
> I started of trying to classify what kind of thing these new features are
> in hopes of coming across new ones. The first three I clumped into a group
> I called "Payment point addition allows us to do cool things while
> maintaining the Proof of Payment (PoP) property". The next two (4 and 5) I
> called "Commitment applications where point is public". But ZmnSCPxj's
> proposal for lightning escrow contracts (
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-June/002028.html)
> struck me as something different that might somehow be made more general.
>
> Essentially the idea is to use the point S + ECDH(B, E) where S is the
> seller's point, B is the buyer's point and E is the escrow's point. This
> means that the scalar can be discovered by the seller in collaboration with
> the buyer or the escrow, that is, S AND (B OR E). I propose that under
> certain circumstances (such as the parties involved being able to
> interact), this can be generalized to have payments conditioned on
> arbitrary AND/OR circuits.
>
>  I believe that AND is very straightforward as you simply take two
> conditions A and B and add them together to get a point that requires both
> of their scalars are discoverable (except maybe under certain bad
> circumstances that can be avoided where like B = C - A, this must be
> guarded against).
>
> OR is harder but I think that it can be achieved in the two party case by
> ECDH and in the n-party case by multi-party key exchanges (which I know
> pretty much nothing about other than that they exist). Given some key
> exchange protocol (preferably non-interactive), KE, KE(A_1, ..., A_n)
> should result in a number known only to those who know any scalar a_1, ...,
> a_n and no one else. Assuming this exists and we can manage to trustlessly
> (in some possibly stretched sense of the word) compute shared keys
> (including such things as KE(A+B, C)), then KE(A, B) acts as A OR B in our
> payment condition contract.
>
> To restate the escrow contract idea in this setting, the payment is
> conditioned on S + KE(B, E). Important to note is that not all parties must
> know about the details of the 

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 unlocks based on whether
you can provide an r such that H(r || x) == C.

> Unfortunately that zkp already proves that C was generated based on x, so
you get your timestamp for free. Ooops. :(

I haven't studied zkp for circuits in general but I guess the
non-interactive proofs are fiat-shamir transformations of an interactive
protocol. Maybe you could just use the interactive zero knowledge protocol
which doesn't have the side effect of the verifier with a proof they can
give to others.

LL

On Thu, Sep 26, 2019 at 5:30 AM Anthony Towns  wrote:

> On Wed, Sep 25, 2019 at 01:30:39PM +, ZmnSCPxj wrote:
> > > Since it's off chain, you could also provide R and C and a zero
> knowledge
> > > proof that you know an r such that:
> > > R = SHA256( r )
> > > C = SHA256( x || r )
>
> > > in which case you could do it with lightning as it exists today.
> > I can insist on paying only if the server reveals an `r` that matches
> some known `R` such that `R = SHA256(r)`, as currently in Lightning network.
> > However, how would I prove, knowing only `R` and `x`, and that there
> exists some `r` such that `R = SHA256(r)`, that `C = SHA256(x || r)`?
>
> If you know x and r, you can generate C and R and a zero knowledge proof
> of the relationship between x,C,R that doesn't reveal r (eg, I think
> you could do that with bulletproofs). Unfortunately that zkp already
> proves that C was generated based on x, so you get your timestamp for
> free. Ooops. :(
>
> Cheers,
> aj
>
> ___
> Lightning-dev mailing list
> Lightning-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev


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

2019-07-17 Thread Lloyd Fournier
Hi Nadav,

Interesting. Is there a writeup anywhere of this CET idea that I can add to
my reading list. I feel like I am missing some background.

LL

On Thu, Jul 18, 2019 at 2:56 AM Nadav Kohen  wrote:

> Hi Lloyd,
>
> Glad you like it :) And to address your concern, I think that although
> certainly it is possible for oracles to sell options contracts, it is also
> possible to have a more decentralized setup with normal DLC oracles (that
> can be used for all kinds of things as all they do is schnorr sign messages
> with pre-commited R values), and then have the CETs 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 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 buyer must be involved in.
>>
>> LL
>>
>>
>> On Thu, Jul 18, 2019 at 1:37 AM Nadav Kohen  wrote:
>>
>>> Hi All,
>>>
>>> I recently posted a proposal here for a scheme through which a trusted
>>> data provider can utilize the Lightning Network to privately sell data
>>> where data is received atomically with purchase.
>>>
>>> I've more recently been thinking about situations where a party, that is
>>> *not* trusted, is attempting to sell its signature to a known message. One
>>> example of a situation where this would be useful is if someone is trying
>>> to offer a DLC-like Option contract where they are essentially
>>> collateralizing themselves in a funding transaction and then selling their
>>> signatures to Contract Execution Transactions (CETs). In this example, we
>>> must ensure that the buyer of the signatures pays if and only if they
>>> receive valid signatures for the CETs which are known.
>>>
>>> I believe that this is achievable in a relatively straightforward way if
>>> we were to use ZmnSCPxj's proposed payment points with scalars (as opposed
>>> to payment hashes with pre-images). The (Schnorr) signature seller could
>>> give the buyer their one-time public key, `R = k*G`, through which the
>>> buyer could compute the payment point whose scalar is the seller's
>>> signature: `sig*G = R + h(m, R)*A` where `A` is the seller's public key.
>>> Using this value as the payment point, the buyer could be assured that they
>>> pay if and only if they receive `sig` from the seller, where `sig` is the
>>> desired valid signature of `m`!
>>>
>>> Best,
>>> Nadav
>>> ___
>>> Lightning-dev mailing list
>>> Lightning-dev@lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>>
>>
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev


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 model
the protocol relative to the G_ledger functionality which seems like the
right thing to do (from my amateurish view). The questions/comments I have
are:

1. When modelling things in UC the ideal functionalities should be as
simple and intuitive as possible. I found F_PayNet to be rather difficult
to follow as compared to the Sprites paper [1]. For example,

"F_PayNet checks that for each payment the charged party was one of the
following: (a) the one that initiated the payment, (b) a malicious party or
(c) an honest party that is negligent"

 Why not assume that (b) never happens because a malicious party never
wants to lose the funds from a party they've corrupted and (c) never
happens because honest parties follow the protocol and check each ledger
update for malicious channel closes. Real world protocols always realise
ideal functionalities under some assumptions and these two things seem like
pretty reasonable things to include in your assumptions rather than
cluttering up your ideal functionality.

2. In both your paper and [1] I am not convinced that the ideal and real
worlds aren't easily distinguishable from each other by an Environment that
just looks at the transactions in the blockchain (G_ledger). For example,
the lightning protocol makes heavy use of pay-to-script-hash where as ideal
functionalities have no need for this. F_PayNet can just send normal
transactions. I think it would be a great idea to describe how you ensure
that the transactions that make it onto the blockchain after an execution
in the real world are indistinguishable from the ideal world.

3. On a related note, I don't understand this "receipt" mechanism. In your
protocol description of OpenChannel, Alice uses her private key which owns
UTXO(s) with x coins to create the funding transaction. This means she
received that private key as input to the execution of the protocol so that
she is able to do this (why don't you explicitly include this private key
in the OpenChannel message?). In the ideal world, the ideal functionality
should be the one with the private key signing the funding transaction
directly (in the ideal world the parties are dummy ITMs which just send
their input to the ideal functionality). But instead there is this receipt
thing which I don't understand.

Cheers

LL

[1] https://arxiv.org/pdf/1702.05812.pdf

On Wed, Jul 10, 2019 at 6:44 PM Orfeas Stefanos Thyfronitis Litos <
o.thyfroni...@ed.ac.uk> wrote:

> Hi all,
>
> The promise for fast, scalable, user-friendly and trustless use of
> bitcoin that the Lightning Network offers motivated us to author a paper
> where we formalize LN in the cryptographic framework of Universal
> Composition and prove its security. It can be found here:
> https://eprint.iacr.org/2019/778
>
> We believe that a formal proof of security was needed to specify the
> exact operating parameters that safeguard the funds and transactions of
> users against arbitrary attackers, to abstract, modularize and validate
> the underlying cryptography that is used in LN, to incorporate LN in the
> body of cryptographic protocols that have been abstracted within the
> Universal Composition framework (and thus can be safely composed and run
> in parallel) and to increase the trust of the wider community to LN. We
> view this work as a small contribution to the amazing effort that the
> Lightning community has expended both on the theoretical and the
> practical front throughout the last years.
>
> The paper is authored by my PhD supervisor Prof. Aggelos Kiayias and me.
> Any feedback will be greatly appreciated.
>
> Best regards,
> Orfeas Stefanos Thyfronitis Litos
>
> --
> The University of Edinburgh is a charitable body, registered in
> Scotland, with registration number SC005336.
>
> ___
> Lightning-dev mailing list
> Lightning-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev


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 buyer must be involved in.

LL


On Thu, Jul 18, 2019 at 1:37 AM Nadav Kohen  wrote:

> Hi All,
>
> I recently posted a proposal here for a scheme through which a trusted
> data provider can utilize the Lightning Network to privately sell data
> where data is received atomically with purchase.
>
> I've more recently been thinking about situations where a party, that is
> *not* trusted, is attempting to sell its signature to a known message. One
> example of a situation where this would be useful is if someone is trying
> to offer a DLC-like Option contract where they are essentially
> collateralizing themselves in a funding transaction and then selling their
> signatures to Contract Execution Transactions (CETs). In this example, we
> must ensure that the buyer of the signatures pays if and only if they
> receive valid signatures for the CETs which are known.
>
> I believe that this is achievable in a relatively straightforward way if
> we were to use ZmnSCPxj's proposed payment points with scalars (as opposed
> to payment hashes with pre-images). The (Schnorr) signature seller could
> give the buyer their one-time public key, `R = k*G`, through which the
> buyer could compute the payment point whose scalar is the seller's
> signature: `sig*G = R + h(m, R)*A` where `A` is the seller's public key.
> Using this value as the payment point, the buyer could be assured that they
> pay if and only if they receive `sig` from the seller, where `sig` is the
> desired valid signature of `m`!
>
> Best,
> Nadav
> ___
> Lightning-dev mailing list
> Lightning-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev


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

2019-05-19 Thread Lloyd Fournier
t; payment!" to all intermediate nodes; also, it still allows a short time
> duration for American Option shenanigans.
>
> The Route Maker solution by CJP is plausible, to me, only if the exchange
> and the Route Maker are the same, which is effectively what is done here,
> but now requires multiple secrets to be revealed.
>
> I was thinking it might be possible, to use point/scalar and require the
> sum of the payment scalar and the exchange scalar, and thereby hide from
> intermediate nodes that multiple secrets are needed, but now the payer
> receives the sum of scalars instead of two separate preimages; this can
> make it difficult for 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 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 payment). For reference:
> https://gist.github.com/LLFourn/d0afa6b37207aed7cd73f6b9203c0def.
> >
> > I mentioned it was possible to do it in a channel. Although looking back
> at it now it seems I was somewhat confused at the time. I said:
> >
> > > As ZmnSCPxj demonstrated, the idea of sending a payment in asset A and
> the other party receiving it as asset B with some exchange node in the
> middle doing a conversion is unsound given what we are able to construct in
> Lightning.
> >
> > As you just showed, this is wrong. [A -> Exchange -> B] with the
> collateral on the last hop works fine. After all, [A -> Exchange -> A] is
> just a special case of [A -> Exchange -> B]. I agree that extending this
> idea across multiple hops after the exchange securely looks impossible.
> >
> > Note, the Exchange should watch carefully for their counter-party
> delaying in signing the channel update on the final hop (to gain value from
> the option this gives them).  If they notice this they should close the
> channel and avoid doing business with this party.
> > Despite this, it's still a far better protocol than the vanilla atomic
> swap because the delaying party has a far less time to realise any gains
> from the option. The exchange can put an end to it by closing the channel
> within 1 on chain tx.
> >
> > On naming. I think it's better to call it *collateral* rather than an
> *option premium* because it is only paid on a failure to execute the trade.
> > I was thinking we can call them collateralized HTLCs.
> >
> > It's possible to modify the protocol slightly so that the party
> receiving the option pays the *premium* regardless of whether they release
> x or not. This makes it a proper cross chain option with guaranteed premium.
> > We made a poster describing this idea here:
> https://coblox.tech/docs/financial_crypto19.pdf.
> >
> > Cheers,
> >
> > Lloyd
> > On Tue, Apr 23, 2019 at 1:52 PM ZmnSCPxj via Lightning-dev <
> lightning-dev@lists.linuxfoundation.org> wrote:
> >
> > > Good morning list,
> > >
> > > Reviving an old thread, but I saw this just recently:
> http://diyhpl.us/wiki/transcripts/scalingbitcoin/tokyo-2018/atomic-swaps/
> > >
> > > Suppose you are a BTC to WJT exchange.
> > > I want to pay 1 BTC to send 10 WJT to YAIjbOJA.
> > > I have a BTC channel to you.
> > > You have a WJT channel to YAIjbOJA.
> > >
> > > In order to create a properly-incentivized American Call Option with a
> premium, you insist that 10% of the WJT value be the premium that is paid
> if the exchange does not pull through.
> > >
> > > We perform this ritual:
> > >
> > > 1.  YAIjbOJA generates a secret x and gives h(x) to me.
> > > 2.  On my channel to you, I get 1 BTC from my side and create an HTLC.
> > > Hash is h(x) payable to you, timelock is 2 days payable to me.
> > > 3.  On your channel to YAIjbOJA, you get 10 WJT from you, and
> 1 WJT (10%, the premium) from YAIjbOJA and create an HTLC.
> > > Hash is h(x) payable to YAIjbOJA, timelock is 1 days payable to
> you.
> > >
> > > The above also forms an American Call Option, but with a premium if
> the payment does not push through.
> > >
> > > However, extending this to beyond on

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 payment). For reference:
https://gist.github.com/LLFourn/d0afa6b37207aed7cd73f6b9203c0def.

I mentioned it was possible to do it in a channel. Although looking back at
it now it seems I was somewhat confused at the time. I said:

> As ZmnSCPxj demonstrated, the idea of sending a payment in asset A and
the other party receiving it as asset B with some exchange node in the
middle doing a conversion is unsound given what we are able to construct in
Lightning.

As you just showed, this is wrong. [A -> Exchange -> B] with the collateral
on the last hop works fine. After all, [A -> Exchange -> A] is just a
special case of [A -> Exchange -> B]. I agree that extending this idea
across multiple hops after the exchange securely looks impossible.

Note, the Exchange should watch carefully for their counter-party delaying
in signing the channel update on the final hop (to gain value from the
option this gives them).  If they notice this they should close the channel
and avoid doing business with this party.
Despite this, it's still a far better protocol than the vanilla atomic swap
because the delaying party has a far less time to realise any gains from
the option. The exchange can put an end to it by closing the channel within
1 on chain tx.

On naming. I think it's better to call it *collateral* rather than an
*option premium* because it is only paid on a failure to execute the trade.
I was thinking we can call them collateralized HTLCs.

It's possible to modify the protocol slightly so that the party receiving
the option pays the *premium* regardless of whether they release x or not.
This makes it a proper cross chain option with guaranteed premium.
We made a poster describing this idea here:
https://coblox.tech/docs/financial_crypto19.pdf.

Cheers,

Lloyd
On Tue, Apr 23, 2019 at 1:52 PM ZmnSCPxj via Lightning-dev <
lightning-dev@lists.linuxfoundation.org> wrote:

> Good morning list,
>
> Reviving an old thread, but I saw this just recently:
> http://diyhpl.us/wiki/transcripts/scalingbitcoin/tokyo-2018/atomic-swaps/
>
> Suppose you are a BTC to WJT exchange.
> I want to pay 1 BTC to send 10 WJT to YAIjbOJA.
> I have a BTC channel to you.
> You have a WJT channel to YAIjbOJA.
>
> In order to create a properly-incentivized American Call Option with a
> premium, you insist that 10% of the WJT value be the premium that is paid
> if the exchange does not pull through.
>
> We perform this ritual:
>
> 1.  YAIjbOJA generates a secret x and gives h(x) to me.
> 2.  On my channel to you, I get 1 BTC from my side and create an HTLC.
> Hash is h(x) payable to you, timelock is 2 days payable to me.
> 3.  On your channel to YAIjbOJA, you get 10 WJT from you, and
> 1 WJT (10%, the premium) from YAIjbOJA and create an HTLC.
> Hash is h(x) payable to YAIjbOJA, timelock is 1 days payable to you.
>
> The above also forms an American Call Option, but with a premium if the
> payment does not push through.
>
> However, extending this to beyond one hop after the exchange node is
> difficult.
> Problems in communicating with the next hop may cause the current hop
> after the exchange node to become liable for the premium without being able
> to forward the liability to the final payee, which is an avenue for attack.
> And if the payee must be the hop after the exchange node, the exchange
> node now knows exactly how much and when that node receives payment, and
> can sell this information and/or selectively disrupt/censor some payments.
>
> Putting the premium before the exchange node is possible with an
> additional transaction spending the HTLC (the timelock branch is payable to
> a 2-of-2 with a pre-signed transaction that sends the premium to the
> exchange and returns the rest of the value to the payer).
> But this is unsafe, since the exchange (and any node between the payer and
> the exchange) can stall the protocol deliberately and refuse to forward,
> extracting the premium via the timelock branch.
> This is effectively forcing fees even in a route failure, which does not
> incentivize intermediate nodes to actually forward when they can do nothing
> and receive fees anyway for not routing.
>
> Regards,
> ZmnSCPxj
> ___
> Lightning-dev mailing list
> Lightning-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev


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 them :)

HTLCs as American call options
=

I think the "option problem" is actually caused by protocols using HTLCs in
a naive way rather than the use of HTLCs themselves. Consider the atomic
swap protocol described in the OP:

>1.  You provide me a hash of some secret preimage that only you know.
>2.  You make an HTLC on the Bitcoin blockchain.
>The value of this HTLC is `P`, the hash is the hash you gave above, and
the timelock is `E` + 1 day.
>3.  I make an HTLC on the WJT blockchain.
>The value of this HTLC is 1, the hash is the hash you gave, and the
timelock is `E`.

If we take this protocol and draw out its abstract functionality we get:

1. *Up for sale* Alice puts Asset `A` up for sale to Bob for some time
period `Eb` + `Ea`
2. *Make expiring offer* Bob makes an offer of asset `B` which expires at
time `Eb`
3. *Take offer* Alice may take the offer up until time `Eb`

As has been pointed out, Alice has an "option" for the duration of `Eb`
(and she didn't pay a premium). This is because Bob made her an offer he
cannot cancel (an offer you can't cancel but has an expiration is basically
the definition of being short an option contract).
In order to remedy this, the party that makes the offer must be able to
cancel their offer at any point after they have made it (before the
counterparty has taken it). This should be intuitive because it's how
centralised exchanges work.

Therefore, the ideal abstract functionality we want is:

1. *Make Offer* Alice makes an offer to Bob to trade `A` for `B`
2. *Take Offer* Bob can take the offer (if Alice hasn't already cancelled
it) and get `A` in exchange for `B`.
3. *Cancel Offer* If Bob hasn't taken the offer, Alice may get back `A` by
cancelling the offer

I developed the protocol below which comes pretty close to realising this.
Let
- α and β and be two bitcoin-like blockchains
- Alice own asset `A` on the α blockchain and `C` on the β blockchain
- Bob own asset `B` on the β blockchain

1. Alice puts the HTLC for `A` on α and waits for it to confirm (as per
usual)
2. Alice creates a partial β blockchain transaction by signing one input
and one output (using SIGHASH_SINGLE for example):
   - The input is the asset `C`
   - The output is a HTLC which gives `B` and `C` to herself with the
secret or gives them both to Bob on timeout
  She sends this partial transaction to Bob. (This gives us the "Make
Offer" functionality)
3. If Bob wants to accept the offer, he adds asset `B` to another input of
the transaction and posts it to β. (This gives us "Take Offer"
functionality)
4. If Alice wishes to cancel the trade before Bob has confirmed this
transaction she double spends the `C` output and then reclaims `A` on α
after the timeout. (This gives us the "Cancel Offer" functionality)
5. If the "Take Offer" transaction is confirmed on β, Alice must unlock the
HTLC before the timeout or Bob will gain `C` AND get back `B`.
6. Once she reveals the secret, she both gets back `C` and gains `B` on β.
7. Bob can now take `A` on α in the usual manner now that he has learned
the secret.

Bob is not guaranteed to get `A` after he "takes" the offer but he is
guaranteed to get `A` (in exchange for `B`) or `C` (for free). Obviously,
`C` is Alice's collateral for the trade. Bob should only take the offer if
he wants `A` more than `B` and if he is sure that the value of gaining `C`
will be greater than any loss he could experience from `B` depreciating
relative to `A` during the execution of the protocol.

I believe this shows that HTLCs do not in cause options but rather
uncancelable offers + uncollateralized HTLCs cause the option problem.

I think this protocol works in payment channels in the case that Alice and
Bob have direct channels to each other. The issue is that if Alice decides
she wants to cancel at the same time Bob decides he wants to take it you
have to go to the blockchain to resolve the issue (which will be rather
arbitrary). CJP's idea of having a 3rd party who is trusted simply to
compute the outcome of a offer (cancelled or taken) in layer 2 networks
seems like a promising direction because this would avoid on-chain
resolution in this case.

Cross Asset Payments Don't Make Sense


As ZmnSCPxj demonstrated, the idea of sending a payment in asset `A` and
the other party receiving it as asset `B` with some exchange node in the
middle doing a conversion is unsound given what we are able to construct in
Lightning.

But this doesn't necessarily mean that Lightning has to be single asset.
Theoretically, a single two-party channel could record multiple asset types
with a state transaction that has distinct outputs for 

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 Options on top of onchain HTLCs, I
came up with a similar construction for ensuring that the premium is paid
before the HTLCs setting up the option appear onchain.

I would be interested to see how your construction worked. You can actually
modify the construction I gave before (in the gist) to create a fair option
too. You just change it so the asset `C` is paid on both branches of the
HTLC. This changes `C` from collateral to a premium. This sounds a bit
different to what you describe as the premium isn't paid before the HTLCs
go onto the chain.

The only other proposal for options I've seen is:
https://www.ics.uci.edu/~jamesal1/Swaptions.pdf. I could be missing
something, but this seems to give Alice a free option on an option in this
one. The premium payment has the option problem: Bob cannot cancel his
offer of an option but Alice can take her time to accept it.

> However, can such a scheme scale on-Lightning?

The scalability issue with the scheme in payment channels is the lack of
objective ordering of events in layer 2. If Alice and Bob disagree on
whether "Take Offer" or "Cancel Offer" happened first, they will have to
close their channel and resolve their dispute on the blockchain. This means
that channels may have to go to the blockchain much more often than if you
were just doing payments. In practice, this problem might not be so severe.
Parties that have frequent disputes will just tend to stop opening channels
with each other. It still guarantees that in the worst case there are no
long options for either party.

---
David,

> Instead of Alice's node just locally constructing this path and trying
> to pay it like normal, she first sends a special probe to Charlie
> requesting a new hash for which only he knows the preimage.  With this
> hash plus the hash Alice received from Eliza, Alice sends a payment that
> requires both hashlocks be unlocked before anyone can claim the payment.

Moving the option from the random anonymous person (Alice) to the exchange
node is a good improvement. If participants become good at identifying
exchange nodes that delay in revealing the secret that might be enough to
make the cross asset payment idea practical.

As you hinted at, I think there is a simpler construction that is more
compatible with today's lightning:
1. Alice given `A` wants to send `B` to Bob with Charlie doing the exchange.
2. Charlie generates a secret `s` and makes a payment of `B` to Bob locked
under H(s)
3. Once Bob has the locked payment of `B` he sends H(s) to Alice
4. Alice then makes the payment of `A` under H(s) to Charlie.
5. Charlie now unlocks Alice's payment with `s` and receives `A`
6. Alice then learns `s` and sends it to Bob
7. Bob unlocks Charlie's payment with `s` and receives `B`

> In ZmnSCPxj's terminology, the option is now no longer
> free because Charlie must decide between potential routing income and
> potential option income

I didn't really get why the exchange would get any routing income from
this? The exchange is the receiver of a payment of BTC on one leg and the
sender of WJT on another. I'd expect the exchange would gain profit from
spreads rather than fees in these protocols.

Lloyd

\n

On Sat, Jan 5, 2019 at 6:01 PM ZmnSCPxj via Lightning-dev <
lightning-dev@lists.linuxfoundation.org> wrote:

> Good morning David,
>
> What happens if the exchange node only sends its preimage towards the
> payer and not towards the payee?
>
> If the payer and payee do not coordinate, then it becomes possible for the
> exchange node to take the funds without the payee gaining the ability to
> claim the payment.
> This might be used by a node to take proofs of payment without paying, by
> simulating the payer and exchange nodes.
> This may be important if the proof of payment is valuable, such as, the
> mentioned offline Lightning vending machines, or if the preimage is the
> decryption key for valuable data (e.g. ransomware; now the ransomware
> author may find it is scammed off their potential earnings).
>
> Regards,
> ZmnSCPxj
>
>
>
> Sent with ProtonMail Secure Email.
>
> ‐‐‐ Original Message ‐‐‐
> On Saturday, January 5, 2019 5:05 AM, David A. Harding 
> wrote:
>
> > On Thu, Dec 27, 2018 at 05:43:51AM +, ZmnSCPxj via Lightning-dev
> wrote:
> >
> > > We can try to mitigate this, but the solutions below all have
> significant drawbacks.
> >
> > An alternative is to give the person making the exchange the ability to
> > cancel the payment if they think the exchange rate has changed
> > unfavorably for them. I think you could do that by adding an extra
> > hashlock to the HTLC that's controlled by the exchanger. For example,
> > here's what we'd expect a cross-asset