Lloyd Fournier [ARCHIVE]

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2019-01-02 to 2023-05-11
💬 Posted a total of 106 messages
📚 Participated in the following categories: bitcoin-dev, Lightning-dev, Annoucement, try2
🔇 Please do not DM this user as it's used for archive purposes only.

Public Key

npub1khlhcuz0jrjwa0ayznq2q9agg4zvxfvx5x7jljrvwnpfzngrcf0q7y05yp

Profile Code

nprofile1qqsttlmuwp8epe8wh7jpfs9qz75y23xrykr2r0f0epk8fs53f5puyhsmyvavu

Author Public Key

npub1khlhcuz0jrjwa0ayznq2q9agg4zvxfvx5x7jljrvwnpfzngrcf0q7y05yp

Show more details

Last Notes

2023-08-16 00:45:53

- reply

📅 Original date posted:2023-08-14
🗒️ Summary of this message: Lloyd asks Tom if parallel signing requests are required in the statechain protocol and questions the use of Schnorr blind signatures.
📝 Original message:
Hi Tom,
Thanks for the explanation. There's one remaining thing that isn't clear:
do you actually require parallel signing requests under the same key. It
seems to me that the protocol is very sequential in that you are passing a
utxo from one point to another in sequence. If so then the Schnorr blind
sigs problem doesn't apply.
LL
On Thu, 10 Aug 2023 at 20:00, Tom Trevethan <tom at commerceblock.com> wrote:
> HI Lloyd,
>
> Yes, the blind signatures are for bitcoin transactions (these are
> timelocked 'backup txs' if the server disappears). This is not standard
> 'Schnorr blind signature' (like
> https://suredbits.com/schnorr-applications-blind-signatures/) but a
> 2-of-2 MuSig where two keys are required to generate the full signature,
> but one of them (the server) does not learn of either the full key, message
> (tx) or final signature.
>
> The server is explicitly trusted to report the total number of partial
> signatures it has generated for a specific key. If you can verify that ALL
> the signatures generated for a specific key were generated correctly, and
> the total number of them matches the number reported by the server, then
> there can be no other malicious valid signatures in existence. In this
> statechain protocol, the receiver of a coin must check all previous backup
> txs are valid, and that the total number of them matches the server
> reported signature count before accepting it.
>
> On Thu, Aug 10, 2023 at 4:30 AM Lloyd Fournier <lloyd.fourn at gmail.com>
> wrote:
>
>> Hi Tom,
>>
>> These questions might be wrongheaded since I'm not familiar enough with
>> the statechain protocol. Here goes:
>>
>> Why do you need to use schnorr blind signatures for this? Are the blind
>> signatures being used to produce on-chain tx signatures or are they just
>> for credentials for transferring ownership (or are they for both). If they
>> are for on-chain txs then you won't be able to enforce that the signature
>> used was not generated maliciously so it doesn't seem to me like your trick
>> above would help you here. I can fully verify that the state chain
>> signatures were all produced non-maliciously but then there may be another
>> hidden forged signature that can take the on-chain funds that were produced
>> by malicious signing sessions I was never aware of (or how can you be sure
>> this isn't the case).
>>
>> Following on from that point, is it not possible to enforce sequential
>> blind signing in the statechain protocol under each key. With that you
>> don't have the problem of wagner's attack.
>>
>> LL
>>
>> On Wed, 9 Aug 2023 at 23:34, Tom Trevethan via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>> @moonsettler
>>>
>>> When anyone receives a coin (either as payment or as part of a swap)
>>> they need to perform a verification of all previous signatures and
>>> corresponding backup txs. If anything is missing, then the verification
>>> will fail. So anyone 'breaking the chain' by signing something
>>> incorrectly simply cannot then send that coin on.
>>>
>>> The second point is important. All the 'transfer data' (i.e. new and all
>>> previous backup txs, signatures and values) is encrypted with the new owner
>>> public key. But the server cannot know this pubkey as this would enable it
>>> to compute the full coin pubkey and identify it on-chain. Currently, the
>>> server identifies individual coins (shared keys) with a statechain_id
>>> identifier (unrelated to the coin outpoint), which is used by the coin
>>> receiver to retrieve the transfer data via the API. But this means the
>>> receiver must be sent this identifier out-of-band by the sender, and also
>>> that if anyone else learns it they can corrupt the server key
>>> share/signature chain via the API. One solution to this is to have a second
>>> non-identifying key used only for authenticating with the server. This
>>> would mean a 'statchain address' would then be composed of 2 separate
>>> pubkeys 1) for the shared taproot address and 2) for server authentication.
>>>
>>> Thanks,
>>>
>>> Tom
>>>
>>> On Tue, Aug 8, 2023 at 6:44 PM moonsettler <moonsettler at protonmail.com>
>>> wrote:
>>>
>>>> Very nice! Is there an authentication mechanism to avoid 'breaking the
>>>> chain' with an unverifiable new state by a previous owner? Can the current
>>>> owner prove the knowledge of a non-identifying secret he learned as
>>>> recipient to the server that is related to the statechain tip?
>>>>
>>>> BR,
>>>> moonsettler
>>>>
>>>> ------- Original Message -------
>>>> On Monday, August 7th, 2023 at 2:55 AM, Tom Trevethan via bitcoin-dev <
>>>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>>
>>>> A follow up to this, I have updated the blinded statechain protocol
>>>> description to include the mitigation to the Wagner attack by requiring the
>>>> server to send R1 values only after commitments made to the server of the
>>>> R2 values used by the user, and that all the previous computed c values are
>>>> verified by each new statecoin owner.
>>>> https://github.com/commerceblock/mercury/blob/master/layer/protocol.md
>>>>
>>>> Essentially, the attack is possible because the server cannot verify
>>>> that the blinded challenge (c) value it has been sent by the user has been
>>>> computed honestly (i.e. c = SHA256(X1 + X2, R1 + R2, m) ), however this CAN
>>>> be verified by each new owner of a statecoin for all the previous
>>>> signatures.
>>>>
>>>> Each time an owner cooperates with the server to generate a signature
>>>> on a backup tx, the server will require that the owner send a commitment to
>>>> their R2 value: e.g. SHA256(R2). The server will store this value before
>>>> responding with it's R1 value. This way, the owner cannot choose the value
>>>> of R2 (and hence c).
>>>>
>>>> When the statecoin is received by a new owner, they will receive ALL
>>>> previous signed backup txs for that coin from the sender, and all the
>>>> corresponding R2 values used for each signature. They will then ask the
>>>> server (for each previous signature), the commitments SHA256(R2) and the
>>>> corresponding server generated R1 value and c value used. The new owner
>>>> will then verify that each backup tx is valid, and that each c value was
>>>> computed c = SHA256(X1 + X2, R1 + R2, m) and each commitment equals
>>>> SHA256(R2). This ensures that a previous owner could not have generated
>>>> more valid signatures than the server has partially signed.
>>>>
>>>> On Thu, Jul 27, 2023 at 2:25 PM Tom Trevethan <tom at commerceblock.com>
>>>> wrote:
>>>>
>>>>>
>>>>> On Thu, Jul 27, 2023 at 9:08 AM Jonas Nick <jonasdnick at gmail.com>
>>>>> wrote:
>>>>>
>>>>>> No, proof of knowledge of the r values used to generate each R does
>>>>>> not prevent
>>>>>> Wagner's attack. I wrote
>>>>>>
>>>>>> > Using Wagner's algorithm, choose R2[0], ..., R2[K-1] such that
>>>>>> > c[0] + ... + c[K-1] = c[K].
>>>>>>
>>>>>> You can think of this as actually choosing scalars r2[0], ...,
>>>>>> r2[K-1] and
>>>>>> define R2[i] = r2[i]*G. The attacker chooses r2[i]. The attack
>>>>>> wouldn't make
>>>>>> sense if he didn't.
>>>>>>
>>>>>
>>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230814/56725037/attachment-0001.html>

2023-08-10 23:09:38

- reply

📅 Original date posted:2023-08-10
🗒️ Summary of this message: The sender is questioning the use of schnorr blind signatures in the statechain protocol and the potential for malicious signatures. They also suggest enforcing sequential blind signing to prevent attacks.
📝 Original message:
Hi Tom,
These questions might be wrongheaded since I'm not familiar enough with the
statechain protocol. Here goes:
Why do you need to use schnorr blind signatures for this? Are the blind
signatures being used to produce on-chain tx signatures or are they just
for credentials for transferring ownership (or are they for both). If they
are for on-chain txs then you won't be able to enforce that the signature
used was not generated maliciously so it doesn't seem to me like your trick
above would help you here. I can fully verify that the state chain
signatures were all produced non-maliciously but then there may be another
hidden forged signature that can take the on-chain funds that were produced
by malicious signing sessions I was never aware of (or how can you be sure
this isn't the case).
Following on from that point, is it not possible to enforce sequential
blind signing in the statechain protocol under each key. With that you
don't have the problem of wagner's attack.
LL
On Wed, 9 Aug 2023 at 23:34, Tom Trevethan via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> @moonsettler
>
> When anyone receives a coin (either as payment or as part of a swap) they
> need to perform a verification of all previous signatures and
> corresponding backup txs. If anything is missing, then the verification
> will fail. So anyone 'breaking the chain' by signing something
> incorrectly simply cannot then send that coin on.
>
> The second point is important. All the 'transfer data' (i.e. new and all
> previous backup txs, signatures and values) is encrypted with the new owner
> public key. But the server cannot know this pubkey as this would enable it
> to compute the full coin pubkey and identify it on-chain. Currently, the
> server identifies individual coins (shared keys) with a statechain_id
> identifier (unrelated to the coin outpoint), which is used by the coin
> receiver to retrieve the transfer data via the API. But this means the
> receiver must be sent this identifier out-of-band by the sender, and also
> that if anyone else learns it they can corrupt the server key
> share/signature chain via the API. One solution to this is to have a second
> non-identifying key used only for authenticating with the server. This
> would mean a 'statchain address' would then be composed of 2 separate
> pubkeys 1) for the shared taproot address and 2) for server authentication.
>
> Thanks,
>
> Tom
>
> On Tue, Aug 8, 2023 at 6:44 PM moonsettler <moonsettler at protonmail.com>
> wrote:
>
>> Very nice! Is there an authentication mechanism to avoid 'breaking the
>> chain' with an unverifiable new state by a previous owner? Can the current
>> owner prove the knowledge of a non-identifying secret he learned as
>> recipient to the server that is related to the statechain tip?
>>
>> BR,
>> moonsettler
>>
>> ------- Original Message -------
>> On Monday, August 7th, 2023 at 2:55 AM, Tom Trevethan via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>> A follow up to this, I have updated the blinded statechain protocol
>> description to include the mitigation to the Wagner attack by requiring the
>> server to send R1 values only after commitments made to the server of the
>> R2 values used by the user, and that all the previous computed c values are
>> verified by each new statecoin owner.
>> https://github.com/commerceblock/mercury/blob/master/layer/protocol.md
>>
>> Essentially, the attack is possible because the server cannot verify that
>> the blinded challenge (c) value it has been sent by the user has been
>> computed honestly (i.e. c = SHA256(X1 + X2, R1 + R2, m) ), however this CAN
>> be verified by each new owner of a statecoin for all the previous
>> signatures.
>>
>> Each time an owner cooperates with the server to generate a signature on
>> a backup tx, the server will require that the owner send a commitment to
>> their R2 value: e.g. SHA256(R2). The server will store this value before
>> responding with it's R1 value. This way, the owner cannot choose the value
>> of R2 (and hence c).
>>
>> When the statecoin is received by a new owner, they will receive ALL
>> previous signed backup txs for that coin from the sender, and all the
>> corresponding R2 values used for each signature. They will then ask the
>> server (for each previous signature), the commitments SHA256(R2) and the
>> corresponding server generated R1 value and c value used. The new owner
>> will then verify that each backup tx is valid, and that each c value was
>> computed c = SHA256(X1 + X2, R1 + R2, m) and each commitment equals
>> SHA256(R2). This ensures that a previous owner could not have generated
>> more valid signatures than the server has partially signed.
>>
>> On Thu, Jul 27, 2023 at 2:25 PM Tom Trevethan <tom at commerceblock.com>
>> wrote:
>>
>>>
>>> On Thu, Jul 27, 2023 at 9:08 AM Jonas Nick <jonasdnick at gmail.com> wrote:
>>>
>>>> No, proof of knowledge of the r values used to generate each R does not
>>>> prevent
>>>> Wagner's attack. I wrote
>>>>
>>>> > Using Wagner's algorithm, choose R2[0], ..., R2[K-1] such that
>>>> > c[0] + ... + c[K-1] = c[K].
>>>>
>>>> You can think of this as actually choosing scalars r2[0], ..., r2[K-1]
>>>> and
>>>> define R2[i] = r2[i]*G. The attacker chooses r2[i]. The attack wouldn't
>>>> make
>>>> sense if he didn't.
>>>>
>>>
>> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230810/ed54cc20/attachment.html>

2023-07-28 15:08:07

- reply

📅 Original date posted:2023-07-26
🗒️ Summary of this message: The text discusses the need for a secure blind schnorr signing service and the potential attacks that can occur without proof of knowledge of the signing key.
📝 Original message:
Hello all,
1. No proof of knowledge of each R does *NOT* prevent wagner's attack.
2. In my mind, A generic blind signing service is sufficient for doing
blinded MuSig, Muig2, FROST or whatever without the blind signing service
knowing. You don't need a specialized MuSig2 blind singing service to
extract MuSig2 compatible shares from it. You can just add the MuSig tweak
(and/or BIP32 etc) to their key when you do the blind signing request (this
seemed to be what the OP was suggesting). Making the server have multiple
nonces like in MuSig2 proper doesn't help the server's security at all. I
think the problem is simply reduced to creating a secure blind schnorr
signing service. Jonas mentioned some papers which show how to do that. The
question is mostly about whether you can practically integrate those tricks
into your protocol which might be tricky.
LL
On Thu, 27 Jul 2023 at 08:20, Erik Aronesty via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> correct. you cannot select R if it is shipped with a POP
>
> On Wed, Jul 26, 2023, 4:35 PM Tom Trevethan <tom at commerceblock.com> wrote:
>
>> Not 'signing' but 'secret' i.e. the r values (ephemeral keys). Proof of
>> knowledge of the r values used to generate each R used prevents the Wagner
>> attack, no?
>>
>> On Wed, Jul 26, 2023 at 8:59 PM Jonas Nick <jonasdnick at gmail.com> wrote:
>>
>>> None of the attacks mentioned in this thread so far (ZmnSCPxj mentioned
>>> an
>>> attack on the nonces, I mentioned an attack on the challenge c) can be
>>> prevented
>>> by proving knowledge of the signing key (usually known as proof of
>>> possession,
>>> PoP).
>>>
>> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230727/4af404bf/attachment-0001.html>

2023-06-09 13:12:55

- reply

📅 Original date posted:2023-03-28
🗒️ Summary of this message: Payment correlation attacks can link the sender and receiver of a payment by observing traffic, making channel jamming easier, and allowing an adversary to lock up more than the committed coins.
📝 Original message:
Hi g0b1e,
I wanted to add to this excellent summary that there is a trade off here.
The harder you make payment correlation the easier you make channel
jamming. If payments can not be correlated at all it's possible to make
payment paths that cycle through the same nodes many times over. This
allows an adversary to lock up e.g. 10x the channel capacity on a target
channel than the coins they commit to the attack.
See: https://bitcoinproblems.org/problems/ptlc-cycle-jamming.html
Cheers,
LL
On Mon, 27 Mar 2023 at 10:26, g0b1el via Lightning-dev <
lightning-dev at lists.linuxfoundation.org> wrote:
>
> Using payment correlation attacks adversary can try to link the sender and
> receiver of payment by observing traffic from the potential sender to the
> potential receiver. Such observations can be made by the adversary nodes if
> they are present on the payment path or if the adversary is able to monitor
> the network traffic of the potential sender and receiver. In some
> circumstances, the adversary can detect not only his presence on the
> payment path, but also if the monitored nodes are the sender and receiver.
>
> ___ ____ ____ ___
> | | | | | | | |
> --| S |->| A1 |--> ......... -->| A2 |->| R |--
> |___| |____| |____| |___|
>
> S - potential sender
> R - potential receiver
> A1, A2 - adversary surveillance node
>
> For big well-distributed networks, these forms of attacks are very costly
> and can be economically applied only on a small set of nodes. However, if a
> network is centralized, with the majority of traffic passing through a
> small number of big nodes, an adversary's job is much easier. An adversary
> can monitor traffic on those nodes, or in the case of a state-funded
> surveillance adversary, an adversary can acquire a court order to get
> complete access to big nodes routing information.
>
> The adversary job can be simplified if:
> - A1 and A2 are the same nodes. The sender and receiver are connected
> through a single node, the adversary node.
> - A2 and R are the same nodes. The receiver is some form of custodial
> wallet, directly controlled or in collusion with the adversary. The
> adversary is going to be aware of all income transactions. The only thing
> left is to find out who the sender is.
> - S and A1 are the same nodes. If the sender is some form of custodial
> wallet, directly controlled or in collusion with the adversary, the sender
> has no privacy, so correlation attacks are unnecessary.
> - S->A1 is an unpublished channel. An adversary can identify S as the
> sender for all payments originating from S and passing through A1.
> - A2->R is an unpublished channel. An adversary can identify R as the
> receiver for all payments destined for R and passing through A2.
>
>
> The most notable LN payment correlations in order of severity are:
>
> * Hash correlation
> * Amount correlation
> * CLTV correlation
> * Timing correlation
>
> Hash correlation
> ================
>
> Hash correlation is the most straightforward to detect for surveillance
> nodes. If adversary nodes A1 and A2 observe a payment with the same hash,
> they can confidently conclude that they are on the payment path. However,
> the adversary cannot yet determine with enough certainty whether S is the
> sender and R the receiver. Yet, when combined with other correlation
> attacks or network topology examination, the adversary can establish such a
> conclusion with enough probability.
> Fortunately, payment hash correlation is soon expected to be fixed with
> point time lock contracts (PTLCs)[1]. Each payment hop will use a unique
> lock contract point, so there will be no information that can correlate
> different payments.
>
>
> Amount correlation
> ==================
>
> Payment amount correlation is only slightly better than hash correlation
> in terms of privacy because the receiver amount on each hop is mixed with
> the fees of all the downstream nodes. Fees on LN are just a tiny fraction
> of the amount, so for the attacker fees are not an issue, especially in
> combination with timing correlation attacks.
>
> Single-path payments are the most vulnerable to amount correlation
> attacks. Besides the fact that nodes A1 and A2 will see a payment with
> roughly the same amount, node A2 depending on the payment amount, can
> conclude that R is a receiver. For instance, if the receiver is a shop that
> sells some product for X satoshis, and if the attacker sees a payment of
> around X satoshis, he can be sure that this payment goes to that shop node.
>
> Multi-path payments have better privacy because the amount is now split
> into multiple parts. The attacker can not easily find out what product the
> sender is buying. But there is still a potential correlation factor,
> depending on how we split the payment amount.
> If we split the payment into equal parts, the attacker still can find out
> if a partial payment is multiple of the price of some of the shop products.
> Also, those sub-payment paths will be easily distinguishable by the amount,
> just like in the case of single-path payment.
>
> So, what can be done to de-correlate sub-path payment amounts?
>
> Rather than splitting the payment amount into equal parts, we split it
> into predefined values. For instance: 10k, 20k, 50k, 100k, 200k, 500k,
> 1000k, ... satoshis. Just like physical cash. By doing so, every individual
> payment is part of a much larger anonymity set consisting of all the
> payments at that moment. Using this approach, we can split a payment into
> as many paths as needed until we get to the exact number of satoshis.
> Splitting the payment amount into enough sub-paths to get an exact amount
> might be an overhead if current satoshi value, fees, and latencies are
> taken into account. Depending on user privacy preference, the wallet can
> create a payment path with exact change or overpay to the closest
> predefined value.
>
> For instance, if there is a payment of 459,645 satoshis.
>
> Users not that interested in privacy can split:
> 200k + 200k + 50k + 9,645.
> While privacy-oriented users would overpay slightly:
> 200k + 200k + 50k + 10k.
>
> Now sub-payments of privacy-oriented users are mixed with all other
> privacy-oriented and non-privacy-oriented users. Thus, the anonymity set is
> increased subsectional, especially if LN is processing a huge amount of
> transactions per second.
>
> The drawback in splitting payment amounts into predefined values is that
> we might create more redundant payment[2] routes to match the reliability
> of sub-payments split into equal parts. When we split into equal parts,
> every redundant payment path can be used to replace any other failed paths.
> But in the case of predefined values, redundant sub-payment can replace
> only the sub-path with the same payment amount.
>
> CLTV correlation
> ================
>
> CLTV correlation is not as serious as hash or amount correlation because
> it doesn't explicitly connect payment routes through adversary nodes. CLTV
> value does give a sense of closeness to either sender or receiver. However,
> if hop CLTV delta values used are exactly as the one nodes gossiped, then
> an attacker can potentially determine the payment path as well. This is
> especially true when CLTV deltas are used in combination with timing
> correlation, allowing the attacker to calculate all cltv path combinations
> between A1 and A2 and deduce if they are on the payment path.
> With payment route reservation [2], CLTV delta gets shuffled thanks to the
> payment route split. If there is no route split node can return a random
> CLTV value around some predefined value. Thus for the attacker's job to
> correlate payment with payment route reservation, using only CLTV gets much
> harder.
>
>
> Timing correlation
> ==================
>
> Every low-latency network is susceptible to timing correlation attacks.
> The adversary observes the network traffic between the potential sender and
> receiver, and the time of the transactions is used to make correlations.
> This type of attack can be carried out even without LN node if the
> adversary can monitor the surveilled node's network traffic. Low-traffic
> networks are more vulnerable to timing attacks than high-traffic networks.
> As the number of LN users and payments continues to grow, the potential
> payment set will increase, making it increasingly difficult to correlate
> payments using only timing analysis.
>
> To mitigate timing correlation attacks, a possible solution is to
> introduce a small random delay for privacy-oriented payments. This approach
> can make the attacker's job somewhat harder.
>
>
> What the attacker would most likely do is use a combination of amount,
> cltv, and timing correlation attacks. Each correlation attack will give
> some probability, and cumulative probability might reveal the payment route
> and, in the worst case, the sender and receiver. Therefore, it is crucial
> to minimize the probability of success for each attack to ensure the
> highest possible payment privacy.
>
>
> [1] https://bitcoinops.org/en/topics/ptlc/
> [2]
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-February/003867.html
>
> Best Regards,
> g0b1el
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230329/5e48a435/attachment-0001.html>

2023-06-09 13:12:25

- reply

📅 Original date posted:2023-01-04
🗒️ Summary of this message: A new scheme for bridging layer-1 and layer-2 systems transparently for users has been proposed, allowing wallets to give out addresses that are covert channel openings without the sender's knowledge. This would enable users to withdraw coins from an exchange straight into a channel by submitting an address without knowing precisely how much money they will receive to that address. The use of a covenant would mean the channel would not have an expiry date and therefore be a first-class citizen among channels.
📝 Original message:
Dear Jesse & Z,
I believe this kind of scheme is of crucial importance. I think if we're
serious about bridging layer-1 and layer-2 systems transparently for users,
wallets must be able to give out addresses that are covert channel openings
without the sender's knowledge. e.g. I should be able to withdraw coins
from an exchange straight into a channel by submitting an address without
knowing precisely how much money I will receive to that address. I hadn't
considered this particular design before -- it's very practical and works
today. My own minor effort on this topic was to suggest that researchers
designing sophisticated covenant proposals should make sure that they
achieve this functionality cleanly [1]. The advantage of using a covenant
is that the channel would not have an expiry date and therefore be a first
class citizen among channels.
[1]
https://github.com/ariard/bitcoin-contracting-primitives-wg/issues/19#issue-1492942389
Cheers,
LL
On Wed, 4 Jan 2023 at 00:58, ZmnSCPxj via Lightning-dev <
lightning-dev at lists.linuxfoundation.org> wrote:
> Subject: Swap-in-Potentiam: Moving Onchain Funds "Instantly" To Lightning
>
> by Jesse Posner, ZmnSCPxj
>
> Introduction
> ============
>
> Moving funds from an onchain-only address to Lightning Network is slow,
> especially if you desire trust-minimization (which removes solutions
> relying on 0-conf).
>
> Basically, to reduce trust requirements in all onchain transactions,
> onchain receivers *MUST* ensure confirmation of the onchain transaction
> that creates their UTXO.
> In practice, the minimum should be at least 3 blocks, since reorgs of
> up to 2 blocks are common occurences, but even 1 confirmation can
> take an inordinately long time in the real world due to the random
> nature of mining.
>
> This is particularly acute for mobile phone use-cases.
> As mobile phones run on a battery, mobile phone OSs often greatly
> restrict CPU and other resource consumption when an app is not
> currently open by the user.
>
> Now consider this user story, for a wallet app that supports both
> Bitcoin blockchain and Lightning Network operations:
>
> * The user wants to be paid over the Bitcoin blockchain.
> * The user gets an address from their wallet and provides it to
> some other party to receive their payment.
> * The user closes their wallet app, which causes the mobile phone
> OS to kill all its threads.
> * The other party sends their payment over blockchain while the
> user is asleep.
> * The blockchain transaction confirms and time passes.
> * The user wakes up and checks their favorite blockchain explorer,
> and sees they received funds on their wallet address.
> * The user opens their wallet app and decides they need a coffee,
> so they buy coffee over Lightning.
>
> For current solutions to move funds from the blockchain layer to
> Lightning, however, the above user story would need to complete
> over a long time, possibly measurable in dozens of minutes or
> even hours in the worst case, due to the need for confirmation:
>
> * Channel open: Requires confirmation, many nodes require 6 or
> more confirmations.
> * Submarine swap/peerswap: Requires confirmation before the swap
> service will send out the HTLC on Lightning.
> * Splice-in: Channel remains operational, but until the splice
> transaction confirms, the channel operates in "dual mode"
> where both pre-splice and post-splice state is valid, and
> that means only the lower amount of the pre-splice and
> post-splice can be used in the mean time.
> For splice-in, the pre-splice amount will be lower, thus
> the amount being spliced in will not be credited until
> the splice transaction is confirmed.
>
> In this writeup, we present a novel protocol, swap-in-potentiam,
> that can be used for immediate transfer from the blockchain
> layer to the Lightning layer, in the above user story.
>
> Advantages And Limitations
> --------------------------
>
> To whet your appetite, here are the advantages:
>
> * Immediate transfer of already-confirmed-received onchain
> funds to Lightning.
> * Onchain funds can also be transferred to another onchain
> address (subject to normal onchain confirmation rules).
> * This can be "immediate" if sending to a receiver that
> accepts the risk of 0-conf onchain transactions.
> * Minimized trust requirement.
>
> The disadvantages, to help convince you that yes, this is
> technology and not magic beans (and to not oversell this
> tech, Bitcoin media reporting often tend to oversell
> new technologies because the disadvantages are often
> hidden away behind technical minutae):
>
> * Requires a cooperating LSP.
> If LSP is down or refuses to cooperate, onchain funds
> are locked for some time.
> This has a timeout (so if the LSP never comes online
> again, you just wait out the timeout) and the timeout
> starts from when the receiving UTXO is confirmed in a
> blocks, so it will not cause loss of funds, only loss
> of opportunity (i.e. "involuntary HODLing").
> * If you have multiple LSPs, when you generate an address
> you *have to* select one of them at that point, you
> *cannot* commit to multiple LSPs and select one of them
> later when your phone wakes up again.
> This exacerbates the above disadvantage, since you have
> to select one of your LSPs and hope that when your
> phone wakes up the LSP you selected is also up and
> cooperative.
> * The onchain-received funds have to be confirmed first,
> otherwise we still need to wait for confirmation of the
> onchain-received funds.
> This is generally true for many blockchain-only wallets
> anyway and is thus not a worsening, but is also not an
> improvement.
> * If the timeout is too near, actions must be performed
> onchain that require confirmation.
>
> Swap-in-Potentiam
> =================
>
> All onchain fund movements, as noted, require confirmation.
> These include onchain fund movements to the Lightning network.
>
> If the onchain address that the wallet provides was controlled
> solely by that wallet, then any action that requires cooperation
> with a Lightning Network participant --- channel open, swap, or
> splice --- would require an onchain transaction that commits to
> that specific Lightning Network participant.
> Only when the new onchain transaction is confirmed, can that
> Lightning participant rely on the transaction output without
> having to trust the initiator.
>
> From there, we can consider: what if the wallet provides an
> address that *already* commits to that specific Lightning Network
> participant?
>
> If so, then the "timer for confirmation" starts as soon as
> the wallet receives on the blockchain, not as soon as the wallet
> decides to move funds from blockchain to Lightning.
>
> This is a significant difference for a mobile wallet: the mobile
> environment does not support the mobile wallet being online for
> long.
> Thus, the mobile wallet may not have any CPU to make the decision
> to move funds from blockchain to Lightning, until the actual user
> explicitly opens the mobile wallet app.
>
> It has already been generally accepted that due to the limitations
> of the mobile phone environment, a mobile phone wallet with
> Lightning support would need some LSP anyway.
> Thus, a mobile wallet that can receive on the blockchain layer
> and then send on the Lightning layer can commit to a specific,
> different, Lightning participant: the LSP it has channels with.
>
> Thus, the mobile wallet can provide an address that commits to
> one particular Lightning Network participant: its LSP.
>
> The mobile wallet can then initiate a single-hop swap with the
> LSP when the mobile wallet app is in the foreground and has CPU
> to think with.
> If it received funds into the address that have already been
> confirmed, then it can do this single-hop swap immediately with
> its LSP.
> The LSP can immediately resolve this swap, crediting funds to
> channel, while atomically ensuring it has sole claim to the
> onchain UTXO.
>
> The Contract
> ------------
>
> The contract has two participants: Alice the funds owner, and
> Bob its potential swap partner.
>
> Once *any* funds have been confirmed received into an address
> committing to this contract, Alice owns the funds and can
> dispose of them as it likes (with cooperation from Bob).
> The source of the funds need not be Alice, it could be a third
> party that has an obligation to pay Alice onchain.
>
> The contract has only 2 branches:
>
> * Onchain/channel branch: Alice and Bob.
> * Timelock branch: Alice plus a relative timelock (`OP_CSV`)
> measurable in weeks.
>
> Astute readers will realize that the above is really a variant
> of [CLTV-style unidirectional time-limited channels][1],
> themselves a variant of Spilman-style channels:
>
> * Uses an explicit opcode to simplify channel setup (no need
> to pre-sign a timeout transaction between Alice and Bob,
> can just send funds directly to the address).
> * Uses a relative locktime instead of an absolute one to
> allow funding of the channel address (= receive onchain
> funds ready to spend over Lightning) at any time.
>
> The use-cases this enables are:
>
> * If Alice wants to pay to another onchain address, and Bob
> is also online and cooperative, Alice can ask Bob to help
> sign the Onchain/channel branch to move the funds in any
> arbitrary onchain manner.
> * If Alice wants to pay to a Lightning invoice / keysend, and
> has insufficient Lightning outgoing capacity (but has
> sufficient *total* capacity), it can swap with Bob, by
> offerring a transaction that spends via the Onchain/channel
> branch and instantiates a fresh onchain HTLC that Bob can
> then forward over Lightning.
> As soon as Alice offers its signature of that transaction,
> Bob can immediately offer an in-Lightning HTLC to Alice on
> their channel, and then Alice can immediately resolve it
> (thus immediately getting its funds into Lightning).
> * If Bob is offline or uncooperative, Alice can unilterally
> recover its funds after the timeout in the Timelock
> branch.
>
> Trust is required only to the extent that Alice trusts Bob to
> be cooperative so that Alice can dispose of its funds immediately.
> In case Bob turns out to be non-trustworthy, Alice can recover
> its funds via the timelock branch after the timeout period.
> There is no scope for Bob to steal funds (indeed, it is easier
> for Bob to steal Lightning funds than to steal swap-in-potentiam
> funds).
>
> The intent here is that the mobile wallet is Alice, while the
> LSP is Bob.
>
> ### Bob Security
>
> Bob *MUST* ensure that, for each UTXO, it is either asked to
> sign an arbitrary onchain transaction (i.e the first use-case
> above) *OR* it gets offered an onchain HTLC from that UTXO.
> Once Alice has asked Bob to cooperate in either case for a
> particular UTXO, Bob *MUST* ensure that it does not sign the other
> case (and Bob *MUST* refuse to cooperate in the other case once
> one case has been requested).
>
> In addition, Bob *MUST* ensure that, if it is used in the
> "channel" case (i.e. the second use-case above), the timeout of
> the Timelock branch is far enough in the future that it is likely
> that spends using the Onchain/channel branch have confirmed by
> then.
>
> With both invariants enforced by Bob, Bob can ensure that, if
> Alice requests a swap using the Onchain/channel branch, only Bob
> can spend the UTXO (at least before the timeout), and thus can
> safely offer a Lightning HTLC to Alice immediately without any
> additional waiting for onchain confirmations.
>
> As Bob needs to know the UTXO in the first use-case above, this
> requirement prevents the use of blind signing techniques when
> implementing the first use-case.
> Basically, when being asked to sign, Bob must generate the entire
> `SIGHASH` from data that Alice provides, so that Bob is able to
> keep track of UTXOs it is signing for.
>
> ### Remote Swap
>
> While Bob is generally considered "the" LSP of the mobile wallet
> Alice, nothing in the Lightning protocol actually requires that
> Bob be a direct peer of Alice.
> The only real requirement is that Bob is able to send funds to
> Alice over Lightning in exchange for possession of the equivalent
> onchain funds.
>
> Against this, we should note that the mobile wallet is already
> dependent on one or more LSPs anyway, so it may as well just use
> its direct peer LSPs instead of a remote node.
>
> ### Address Derivation
>
> Swap-in-potentiam addresses can be derived from a root public or
> private key.
>
> We only need one keypair each from Alice and Bob.
> Alice can use standard derivation paths for its keypair.
>
> As Bob is intended to be an LSP, we can just use its Lightning
> node ID as the public key.
> Bob needs to be in possession of the corresponding private key
> anyway in order to set up BOLT 8 encrypted transports.
>
> As LSPs are part of the public network, Alice can simply try to
> scan for all published nodes that advertise support for
> swap-in-potentiam.
> Alternately if the wallet has a short list of fixed LSPs it
> will use, it can simply refer to that list.
>
> Thus:
>
> * Alice uses a derived keypair.
> * Bob uses a fixed keypair (its Lightning node ID).
>
> The above is sufficient to derive swap-in-potentiam addresses
> from an `xprv` or `xpub` root key.
>
> Swap-in-potentiam For LSPs
> ==========================
>
> While the original design of swap-in-potentiam has the mobile
> wallet in the "Alice" role and its LSP in the "Bob" role, it
> turns out that LSPs can provide special service to improve
> receiving mobile wallets.
>
> Suppose that the LSP keeps track of statistics, and thus has
> an idea of which of its mobile wallet clients are likely to
> be net receivers.
>
> Net receivers will often have low inbound capacity (since the
> inbound capacity has been used up during previous LN receives).
>
> During times of low onchain fees, an LSP can check which of its
> offline mobile wallet clients have low inbound capacity, and are
> likely to come online in the future to receive.
> In those cases, the LSP can commit funds to a swap-in-potentiam
> with the mobile client, with the LSP as "Alice" and the mobile
> client as "Bob".
> This at least lets the LSP set up half of a swap during a time of
> low fees.
>
> If the transfer to swap-in-potentiam addresses is confirmed by
> the time the mobile wallet client comes online, the LSP can
> immediately initiate a swap, giving inbound capacity towards the
> mobile client.
> This swap can be immediately resolved, and allows the mobile
> wallet client to immediately receive funds over Lightning.
>
> In particular, if "offline receive" as designed by TheBlueMatt
> is implemented, then the LSP already has indication of a pending
> payment towards an offline mobile wallet client.
> The LSP can check if the offline mobile wallet client has
> insufficient incoming capacity to receive the funds, and if so,
> arrange to fund a swap-in-potentiam with that client.
> Then, when the mobile wallet client comes online, the LSP can
> initiate the swap with them, and once the swap completes (and
> thus the mobile wallet client has sufficient incoming capacity)
> the LSP can contact the sender LSP to complete the payment.
>
> In particular, this use-case allows for *immediate* receives as
> soon as the mobile wallet client gets foregrounded and has CPU
> time, **without** requiring 0-conf trusted transactions and
> thus without requiring any kind of semi-custodial trust, even
> if the mobile wallet client had insufficient incoming capacity.
> A channel still has to be set up beforehand (without 0-conf, if
> trusting funds to the LSP is undesirable).
>
> Implementation Sketch
> =====================
>
> The intent is to use Taproot with Schnorr signatures, but
> **without** using the keyspend path (at least initially).
>
> The plan currently is to use a `MuSig(A, B)` as the internal
> pubkey, but with the branches still explicitly laid out as
> tapleaves.
> That is, there are two tapleaf SCRIPTs corresponding to the
> two branches described above:
>
> * `<A> OP_CHECKSIGVERIFY <B> OP_CHECKSIG`
> * `<timelock> OP_CHECKSEQUENCEVERIFY OP_DROP <A> OP_CHECKSIG`
>
> Using an explicit 2-of-2 branch rather than a MuSig allows
> for a simple protocol at least for initial deployment:
> we can have Alice send the signature using `A` in a single
> half-round without having to engage in a 2-round MuSig2 signing
> ritual.
>
> We intend to use Taproot since the mobile wallet client
> may need to use a 2-of-3 or 2-of-2 signing scheme, similar
> to Blockstream Green.
> This allows either Alice or Bob in the contract to secretly
> be a FROST 2-of-3 or MuSig 2-of-2 (or any FROST k-of-n or
> MuSig n-of-n).
> This is also another reason for avoiding a 2-of-2 MuSig
> keyspend path between Alice and Bob, as there is (to our
> knowledge) no publicly-reviewed security proof that
> FROST-in-MuSig and MuSig-in-MuSig are safe (or the
> corresponding variants using MuSig2 for the signing
> ritual).
>
> Later, when we are more confident of the use of MuSig2 and
> FROST inside a MuSig2, and with using MuSig2 with possibly
> untrusted outsiders (who might exploit any mis-implementation
> of the MuSig2 signing protocol if we are not careful with
> designing it), we can seamlessly upgrade the protocol
> to use the keyspend path later, to save witness bytes.
>
> For the Onchain use-case (i.e. Alice wants to spend the UTXO
> to an onchain address), the protocol betweeen Alice and Bob
> would be:
>
> * `request_arbitrary_signature` Alice->Bob: Requests Bob
> to sign a PSBT spending a swap-in-potentiam address
> using the Onchain branch.
> * `response_arbitrary_signature` Bob->Alice: Response to
> the above, returning the requested signature.
> * `reject_arbitrary_signature` Bob->Alice: Sent in
> response to `request_arbitary_signature` if Bob refuses
> to cooperate (e.g. the UTXO being spent has already
> been accepted by Bob in a Channel use-case below).
>
> For the Channel use-case (i.e. Alice wants to spend the UTXO
> to a Lightning receiver), we operate the swap-in-potentiam
> UTXO(s) as a Spilman-like channel over two states:
>
> * HTLC-offering: Offering an amount `N` HTLC from Alice to
> Bob, with any remaining amount to a change address to
> Alice.
> * Resolved: Giving the amount `N` outright to Bob, with any
> remaining amount to a change address to Alice.
>
> The intention is that the channel is initially put into
> the HTLC-offerring state.
> Then Bob offers a corresponding in-Lightning HTLC to Alice
> over their channel.
> When Alice resolves the in-Lightning HTLC, it can then
> send a new signature for the Resolved state.
> Once the channel is in a Resolved state, Bob *SHOULD* sign
> the last state and broadcast it on the blockchain, thereby
> closing the Spilman-like channel.
>
> The protocol messages for the Channel use-case are:
>
> * `request_swap_in` Alice->Bob: Tell Bob the UTXOs with
> the same swap-in-potentiam address to spend, how
> much to put into the Alice->Bob channel direction,
> what channel to move into, and (optionally) a change
> address for Alice.
> * `reject_swap_in` Bob->Alice: Sent in response to
> `request_swap_in` if Bob refuses to cooperate (e.g.
> one of the UTXOs on offer was already signed with
> `response_arbitrary_signature`, or Bob cannot legally
> accept control of funds from one or more of the UTXOs
> offerred).
> * `accept_swap_in` Bob->Alice: Sent in response to
> `request_swap_in`, containing the Bob-side address to
> send funds to later once the state is Resolved.
> * `swap_in_signed` Alice->Bob: Response to
> `accept_swap_in`, containing the Alice-side signature
> for the HTLC-offering state transaction.
> Once Bob receives this, Bob can safely construct a
> new on-Lightning HTLC using BOLT1
> `update_offer_htlc`.
> * `swap_in_resolved` Alice->Bob: Sent after Alice has
> acquired the funds via `update_fulfill_htlc` of the
> corresponding on-Lightning HTLC, containing the
> Alice-side signature for the Resolved state
> transaction.
> The Resolved state transaction spends to the Bob-side
> address given in `accept_swap_in`, and any change to
> the Alice-side change address in `request_swap_in`.
>
> The plan is to reserve only one odd BOLT1 message ID,
> and to embed the actual swap-in-potentiam message ID
> as the first 2 bytes of the BOLT1 message, to reduce
> pollution of the limited BOLT1 message ID space and to
> allow more flexibility for swap-in-potentiam to expand
> to new messages inside its own message ID space.
>
> For a richer future protocol, we will want to consider
> how a swap-in can be combined with a splice-in.
> This is useful if the current total capacity of the
> channel is lower than the available onchain funds.
> The swap-in can be credited immediately (and is limited
> to the current total capacity) while additional funds
> can be added to the channel via splice-in (which is
> credited only once the splice-in is confirmed).
>
> As-is, a similar result can be obtained using openv1,
> wherein a swap-in is combined with a channel open,
> with the swap-in immediately credited while the channel
> open is awaiting confirmation:
>
> * Alice and Bob currently have one or more existing
> channels, and Alice has a UTXO in a swap-in-potentiam
> address whose value exceeds the incoming capacity of
> the existing channel(s).
> * Alice->Bob `open_channel`.
> * Bob->Alice `accept_channel`.
> * Alice->Bob `request_swap_in` with the "change address"
> being the funding address of the channel.
> * Bob->Alice `accept_swap_in` provides the TXID of the
> funding transaction (Alice now knows the "change
> address" and the Bob final Resolved address, letting it
> know the final Resolved state transaction TXID).
> * Alice->Bob `funding_created` with the TXID.
> * Bob->Alice `funding_signed`.
> * Alice->Bob `swap_in_signed` to provide the signature
> spending the swap-in-potentiam address to Bob.
> * Bob then constructs an HTLC over the existing channel,
> which Alice claims, revealing the preimage.
> * Alice->Bob `swap_in_resolved`.
> * Bob then broadcasts the Resolved state transaction,
> which is also the funding transaction of the new channel.
> * Both Alice and Bob await confirmation of the transaction
> in order to use the new channel.
> Alice can still use the existing channel, which has been
> topped-up with fresh outgoing capacity by the swap-in.
>
> (The above is not safe, as Bob can complete the protocol
> by using the HTLC-offerring state transaction; this can
> be fixed by having Alice open *2* channels with the same
> amount, one with the HTLC-offering state transaction as
> the funding tx, the other with the Resolved state
> transaction as the funding tx, and later `error`ing the
> channel corresponding to the transaction that is not
> confirmed; this is left as an exercise to the reader,
> though note that it requires two different change addresses
> for Alice for both HTLC-offerring and Resolved states,
> which can be arranged for the protocol)
>
> --
>
> [1]:
> https://en.bitcoin.it/wiki/Payment_channels#CLTV-style_payment_channels
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230104/22436848/attachment-0001.html>

2023-06-09 13:08:23

- reply

📅 Original date posted:2023-03-28
📝 Original message:
Hi g0b1e,
I wanted to add to this excellent summary that there is a trade off here.
The harder you make payment correlation the easier you make channel
jamming. If payments can not be correlated at all it's possible to make
payment paths that cycle through the same nodes many times over. This
allows an adversary to lock up e.g. 10x the channel capacity on a target
channel than the coins they commit to the attack.
See: https://bitcoinproblems.org/problems/ptlc-cycle-jamming.html
Cheers,
LL
On Mon, 27 Mar 2023 at 10:26, g0b1el via Lightning-dev <
lightning-dev at lists.linuxfoundation.org> wrote:
>
> Using payment correlation attacks adversary can try to link the sender and
> receiver of payment by observing traffic from the potential sender to the
> potential receiver. Such observations can be made by the adversary nodes if
> they are present on the payment path or if the adversary is able to monitor
> the network traffic of the potential sender and receiver. In some
> circumstances, the adversary can detect not only his presence on the
> payment path, but also if the monitored nodes are the sender and receiver.
>
> ___ ____ ____ ___
> | | | | | | | |
> --| S |->| A1 |--> ......... -->| A2 |->| R |--
> |___| |____| |____| |___|
>
> S - potential sender
> R - potential receiver
> A1, A2 - adversary surveillance node
>
> For big well-distributed networks, these forms of attacks are very costly
> and can be economically applied only on a small set of nodes. However, if a
> network is centralized, with the majority of traffic passing through a
> small number of big nodes, an adversary's job is much easier. An adversary
> can monitor traffic on those nodes, or in the case of a state-funded
> surveillance adversary, an adversary can acquire a court order to get
> complete access to big nodes routing information.
>
> The adversary job can be simplified if:
> - A1 and A2 are the same nodes. The sender and receiver are connected
> through a single node, the adversary node.
> - A2 and R are the same nodes. The receiver is some form of custodial
> wallet, directly controlled or in collusion with the adversary. The
> adversary is going to be aware of all income transactions. The only thing
> left is to find out who the sender is.
> - S and A1 are the same nodes. If the sender is some form of custodial
> wallet, directly controlled or in collusion with the adversary, the sender
> has no privacy, so correlation attacks are unnecessary.
> - S->A1 is an unpublished channel. An adversary can identify S as the
> sender for all payments originating from S and passing through A1.
> - A2->R is an unpublished channel. An adversary can identify R as the
> receiver for all payments destined for R and passing through A2.
>
>
> The most notable LN payment correlations in order of severity are:
>
> * Hash correlation
> * Amount correlation
> * CLTV correlation
> * Timing correlation
>
> Hash correlation
> ================
>
> Hash correlation is the most straightforward to detect for surveillance
> nodes. If adversary nodes A1 and A2 observe a payment with the same hash,
> they can confidently conclude that they are on the payment path. However,
> the adversary cannot yet determine with enough certainty whether S is the
> sender and R the receiver. Yet, when combined with other correlation
> attacks or network topology examination, the adversary can establish such a
> conclusion with enough probability.
> Fortunately, payment hash correlation is soon expected to be fixed with
> point time lock contracts (PTLCs)[1]. Each payment hop will use a unique
> lock contract point, so there will be no information that can correlate
> different payments.
>
>
> Amount correlation
> ==================
>
> Payment amount correlation is only slightly better than hash correlation
> in terms of privacy because the receiver amount on each hop is mixed with
> the fees of all the downstream nodes. Fees on LN are just a tiny fraction
> of the amount, so for the attacker fees are not an issue, especially in
> combination with timing correlation attacks.
>
> Single-path payments are the most vulnerable to amount correlation
> attacks. Besides the fact that nodes A1 and A2 will see a payment with
> roughly the same amount, node A2 depending on the payment amount, can
> conclude that R is a receiver. For instance, if the receiver is a shop that
> sells some product for X satoshis, and if the attacker sees a payment of
> around X satoshis, he can be sure that this payment goes to that shop node.
>
> Multi-path payments have better privacy because the amount is now split
> into multiple parts. The attacker can not easily find out what product the
> sender is buying. But there is still a potential correlation factor,
> depending on how we split the payment amount.
> If we split the payment into equal parts, the attacker still can find out
> if a partial payment is multiple of the price of some of the shop products.
> Also, those sub-payment paths will be easily distinguishable by the amount,
> just like in the case of single-path payment.
>
> So, what can be done to de-correlate sub-path payment amounts?
>
> Rather than splitting the payment amount into equal parts, we split it
> into predefined values. For instance: 10k, 20k, 50k, 100k, 200k, 500k,
> 1000k, ... satoshis. Just like physical cash. By doing so, every individual
> payment is part of a much larger anonymity set consisting of all the
> payments at that moment. Using this approach, we can split a payment into
> as many paths as needed until we get to the exact number of satoshis.
> Splitting the payment amount into enough sub-paths to get an exact amount
> might be an overhead if current satoshi value, fees, and latencies are
> taken into account. Depending on user privacy preference, the wallet can
> create a payment path with exact change or overpay to the closest
> predefined value.
>
> For instance, if there is a payment of 459,645 satoshis.
>
> Users not that interested in privacy can split:
> 200k + 200k + 50k + 9,645.
> While privacy-oriented users would overpay slightly:
> 200k + 200k + 50k + 10k.
>
> Now sub-payments of privacy-oriented users are mixed with all other
> privacy-oriented and non-privacy-oriented users. Thus, the anonymity set is
> increased subsectional, especially if LN is processing a huge amount of
> transactions per second.
>
> The drawback in splitting payment amounts into predefined values is that
> we might create more redundant payment[2] routes to match the reliability
> of sub-payments split into equal parts. When we split into equal parts,
> every redundant payment path can be used to replace any other failed paths.
> But in the case of predefined values, redundant sub-payment can replace
> only the sub-path with the same payment amount.
>
> CLTV correlation
> ================
>
> CLTV correlation is not as serious as hash or amount correlation because
> it doesn't explicitly connect payment routes through adversary nodes. CLTV
> value does give a sense of closeness to either sender or receiver. However,
> if hop CLTV delta values used are exactly as the one nodes gossiped, then
> an attacker can potentially determine the payment path as well. This is
> especially true when CLTV deltas are used in combination with timing
> correlation, allowing the attacker to calculate all cltv path combinations
> between A1 and A2 and deduce if they are on the payment path.
> With payment route reservation [2], CLTV delta gets shuffled thanks to the
> payment route split. If there is no route split node can return a random
> CLTV value around some predefined value. Thus for the attacker's job to
> correlate payment with payment route reservation, using only CLTV gets much
> harder.
>
>
> Timing correlation
> ==================
>
> Every low-latency network is susceptible to timing correlation attacks.
> The adversary observes the network traffic between the potential sender and
> receiver, and the time of the transactions is used to make correlations.
> This type of attack can be carried out even without LN node if the
> adversary can monitor the surveilled node's network traffic. Low-traffic
> networks are more vulnerable to timing attacks than high-traffic networks.
> As the number of LN users and payments continues to grow, the potential
> payment set will increase, making it increasingly difficult to correlate
> payments using only timing analysis.
>
> To mitigate timing correlation attacks, a possible solution is to
> introduce a small random delay for privacy-oriented payments. This approach
> can make the attacker's job somewhat harder.
>
>
> What the attacker would most likely do is use a combination of amount,
> cltv, and timing correlation attacks. Each correlation attack will give
> some probability, and cumulative probability might reveal the payment route
> and, in the worst case, the sender and receiver. Therefore, it is crucial
> to minimize the probability of success for each attack to ensure the
> highest possible payment privacy.
>
>
> [1] https://bitcoinops.org/en/topics/ptlc/
> [2]
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-February/003867.html
>
> Best Regards,
> g0b1el
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230329/5e48a435/attachment-0001.html>

2023-06-09 13:07:48

- reply

📅 Original date posted:2023-01-04
📝 Original message:
Dear Jesse & Z,
I believe this kind of scheme is of crucial importance. I think if we're
serious about bridging layer-1 and layer-2 systems transparently for users,
wallets must be able to give out addresses that are covert channel openings
without the sender's knowledge. e.g. I should be able to withdraw coins
from an exchange straight into a channel by submitting an address without
knowing precisely how much money I will receive to that address. I hadn't
considered this particular design before -- it's very practical and works
today. My own minor effort on this topic was to suggest that researchers
designing sophisticated covenant proposals should make sure that they
achieve this functionality cleanly [1]. The advantage of using a covenant
is that the channel would not have an expiry date and therefore be a first
class citizen among channels.
[1]
https://github.com/ariard/bitcoin-contracting-primitives-wg/issues/19#issue-1492942389
Cheers,
LL
On Wed, 4 Jan 2023 at 00:58, ZmnSCPxj via Lightning-dev <
lightning-dev at lists.linuxfoundation.org> wrote:
> Subject: Swap-in-Potentiam: Moving Onchain Funds "Instantly" To Lightning
>
> by Jesse Posner, ZmnSCPxj
>
> Introduction
> ============
>
> Moving funds from an onchain-only address to Lightning Network is slow,
> especially if you desire trust-minimization (which removes solutions
> relying on 0-conf).
>
> Basically, to reduce trust requirements in all onchain transactions,
> onchain receivers *MUST* ensure confirmation of the onchain transaction
> that creates their UTXO.
> In practice, the minimum should be at least 3 blocks, since reorgs of
> up to 2 blocks are common occurences, but even 1 confirmation can
> take an inordinately long time in the real world due to the random
> nature of mining.
>
> This is particularly acute for mobile phone use-cases.
> As mobile phones run on a battery, mobile phone OSs often greatly
> restrict CPU and other resource consumption when an app is not
> currently open by the user.
>
> Now consider this user story, for a wallet app that supports both
> Bitcoin blockchain and Lightning Network operations:
>
> * The user wants to be paid over the Bitcoin blockchain.
> * The user gets an address from their wallet and provides it to
> some other party to receive their payment.
> * The user closes their wallet app, which causes the mobile phone
> OS to kill all its threads.
> * The other party sends their payment over blockchain while the
> user is asleep.
> * The blockchain transaction confirms and time passes.
> * The user wakes up and checks their favorite blockchain explorer,
> and sees they received funds on their wallet address.
> * The user opens their wallet app and decides they need a coffee,
> so they buy coffee over Lightning.
>
> For current solutions to move funds from the blockchain layer to
> Lightning, however, the above user story would need to complete
> over a long time, possibly measurable in dozens of minutes or
> even hours in the worst case, due to the need for confirmation:
>
> * Channel open: Requires confirmation, many nodes require 6 or
> more confirmations.
> * Submarine swap/peerswap: Requires confirmation before the swap
> service will send out the HTLC on Lightning.
> * Splice-in: Channel remains operational, but until the splice
> transaction confirms, the channel operates in "dual mode"
> where both pre-splice and post-splice state is valid, and
> that means only the lower amount of the pre-splice and
> post-splice can be used in the mean time.
> For splice-in, the pre-splice amount will be lower, thus
> the amount being spliced in will not be credited until
> the splice transaction is confirmed.
>
> In this writeup, we present a novel protocol, swap-in-potentiam,
> that can be used for immediate transfer from the blockchain
> layer to the Lightning layer, in the above user story.
>
> Advantages And Limitations
> --------------------------
>
> To whet your appetite, here are the advantages:
>
> * Immediate transfer of already-confirmed-received onchain
> funds to Lightning.
> * Onchain funds can also be transferred to another onchain
> address (subject to normal onchain confirmation rules).
> * This can be "immediate" if sending to a receiver that
> accepts the risk of 0-conf onchain transactions.
> * Minimized trust requirement.
>
> The disadvantages, to help convince you that yes, this is
> technology and not magic beans (and to not oversell this
> tech, Bitcoin media reporting often tend to oversell
> new technologies because the disadvantages are often
> hidden away behind technical minutae):
>
> * Requires a cooperating LSP.
> If LSP is down or refuses to cooperate, onchain funds
> are locked for some time.
> This has a timeout (so if the LSP never comes online
> again, you just wait out the timeout) and the timeout
> starts from when the receiving UTXO is confirmed in a
> blocks, so it will not cause loss of funds, only loss
> of opportunity (i.e. "involuntary HODLing").
> * If you have multiple LSPs, when you generate an address
> you *have to* select one of them at that point, you
> *cannot* commit to multiple LSPs and select one of them
> later when your phone wakes up again.
> This exacerbates the above disadvantage, since you have
> to select one of your LSPs and hope that when your
> phone wakes up the LSP you selected is also up and
> cooperative.
> * The onchain-received funds have to be confirmed first,
> otherwise we still need to wait for confirmation of the
> onchain-received funds.
> This is generally true for many blockchain-only wallets
> anyway and is thus not a worsening, but is also not an
> improvement.
> * If the timeout is too near, actions must be performed
> onchain that require confirmation.
>
> Swap-in-Potentiam
> =================
>
> All onchain fund movements, as noted, require confirmation.
> These include onchain fund movements to the Lightning network.
>
> If the onchain address that the wallet provides was controlled
> solely by that wallet, then any action that requires cooperation
> with a Lightning Network participant --- channel open, swap, or
> splice --- would require an onchain transaction that commits to
> that specific Lightning Network participant.
> Only when the new onchain transaction is confirmed, can that
> Lightning participant rely on the transaction output without
> having to trust the initiator.
>
> From there, we can consider: what if the wallet provides an
> address that *already* commits to that specific Lightning Network
> participant?
>
> If so, then the "timer for confirmation" starts as soon as
> the wallet receives on the blockchain, not as soon as the wallet
> decides to move funds from blockchain to Lightning.
>
> This is a significant difference for a mobile wallet: the mobile
> environment does not support the mobile wallet being online for
> long.
> Thus, the mobile wallet may not have any CPU to make the decision
> to move funds from blockchain to Lightning, until the actual user
> explicitly opens the mobile wallet app.
>
> It has already been generally accepted that due to the limitations
> of the mobile phone environment, a mobile phone wallet with
> Lightning support would need some LSP anyway.
> Thus, a mobile wallet that can receive on the blockchain layer
> and then send on the Lightning layer can commit to a specific,
> different, Lightning participant: the LSP it has channels with.
>
> Thus, the mobile wallet can provide an address that commits to
> one particular Lightning Network participant: its LSP.
>
> The mobile wallet can then initiate a single-hop swap with the
> LSP when the mobile wallet app is in the foreground and has CPU
> to think with.
> If it received funds into the address that have already been
> confirmed, then it can do this single-hop swap immediately with
> its LSP.
> The LSP can immediately resolve this swap, crediting funds to
> channel, while atomically ensuring it has sole claim to the
> onchain UTXO.
>
> The Contract
> ------------
>
> The contract has two participants: Alice the funds owner, and
> Bob its potential swap partner.
>
> Once *any* funds have been confirmed received into an address
> committing to this contract, Alice owns the funds and can
> dispose of them as it likes (with cooperation from Bob).
> The source of the funds need not be Alice, it could be a third
> party that has an obligation to pay Alice onchain.
>
> The contract has only 2 branches:
>
> * Onchain/channel branch: Alice and Bob.
> * Timelock branch: Alice plus a relative timelock (`OP_CSV`)
> measurable in weeks.
>
> Astute readers will realize that the above is really a variant
> of [CLTV-style unidirectional time-limited channels][1],
> themselves a variant of Spilman-style channels:
>
> * Uses an explicit opcode to simplify channel setup (no need
> to pre-sign a timeout transaction between Alice and Bob,
> can just send funds directly to the address).
> * Uses a relative locktime instead of an absolute one to
> allow funding of the channel address (= receive onchain
> funds ready to spend over Lightning) at any time.
>
> The use-cases this enables are:
>
> * If Alice wants to pay to another onchain address, and Bob
> is also online and cooperative, Alice can ask Bob to help
> sign the Onchain/channel branch to move the funds in any
> arbitrary onchain manner.
> * If Alice wants to pay to a Lightning invoice / keysend, and
> has insufficient Lightning outgoing capacity (but has
> sufficient *total* capacity), it can swap with Bob, by
> offerring a transaction that spends via the Onchain/channel
> branch and instantiates a fresh onchain HTLC that Bob can
> then forward over Lightning.
> As soon as Alice offers its signature of that transaction,
> Bob can immediately offer an in-Lightning HTLC to Alice on
> their channel, and then Alice can immediately resolve it
> (thus immediately getting its funds into Lightning).
> * If Bob is offline or uncooperative, Alice can unilterally
> recover its funds after the timeout in the Timelock
> branch.
>
> Trust is required only to the extent that Alice trusts Bob to
> be cooperative so that Alice can dispose of its funds immediately.
> In case Bob turns out to be non-trustworthy, Alice can recover
> its funds via the timelock branch after the timeout period.
> There is no scope for Bob to steal funds (indeed, it is easier
> for Bob to steal Lightning funds than to steal swap-in-potentiam
> funds).
>
> The intent here is that the mobile wallet is Alice, while the
> LSP is Bob.
>
> ### Bob Security
>
> Bob *MUST* ensure that, for each UTXO, it is either asked to
> sign an arbitrary onchain transaction (i.e the first use-case
> above) *OR* it gets offered an onchain HTLC from that UTXO.
> Once Alice has asked Bob to cooperate in either case for a
> particular UTXO, Bob *MUST* ensure that it does not sign the other
> case (and Bob *MUST* refuse to cooperate in the other case once
> one case has been requested).
>
> In addition, Bob *MUST* ensure that, if it is used in the
> "channel" case (i.e. the second use-case above), the timeout of
> the Timelock branch is far enough in the future that it is likely
> that spends using the Onchain/channel branch have confirmed by
> then.
>
> With both invariants enforced by Bob, Bob can ensure that, if
> Alice requests a swap using the Onchain/channel branch, only Bob
> can spend the UTXO (at least before the timeout), and thus can
> safely offer a Lightning HTLC to Alice immediately without any
> additional waiting for onchain confirmations.
>
> As Bob needs to know the UTXO in the first use-case above, this
> requirement prevents the use of blind signing techniques when
> implementing the first use-case.
> Basically, when being asked to sign, Bob must generate the entire
> `SIGHASH` from data that Alice provides, so that Bob is able to
> keep track of UTXOs it is signing for.
>
> ### Remote Swap
>
> While Bob is generally considered "the" LSP of the mobile wallet
> Alice, nothing in the Lightning protocol actually requires that
> Bob be a direct peer of Alice.
> The only real requirement is that Bob is able to send funds to
> Alice over Lightning in exchange for possession of the equivalent
> onchain funds.
>
> Against this, we should note that the mobile wallet is already
> dependent on one or more LSPs anyway, so it may as well just use
> its direct peer LSPs instead of a remote node.
>
> ### Address Derivation
>
> Swap-in-potentiam addresses can be derived from a root public or
> private key.
>
> We only need one keypair each from Alice and Bob.
> Alice can use standard derivation paths for its keypair.
>
> As Bob is intended to be an LSP, we can just use its Lightning
> node ID as the public key.
> Bob needs to be in possession of the corresponding private key
> anyway in order to set up BOLT 8 encrypted transports.
>
> As LSPs are part of the public network, Alice can simply try to
> scan for all published nodes that advertise support for
> swap-in-potentiam.
> Alternately if the wallet has a short list of fixed LSPs it
> will use, it can simply refer to that list.
>
> Thus:
>
> * Alice uses a derived keypair.
> * Bob uses a fixed keypair (its Lightning node ID).
>
> The above is sufficient to derive swap-in-potentiam addresses
> from an `xprv` or `xpub` root key.
>
> Swap-in-potentiam For LSPs
> ==========================
>
> While the original design of swap-in-potentiam has the mobile
> wallet in the "Alice" role and its LSP in the "Bob" role, it
> turns out that LSPs can provide special service to improve
> receiving mobile wallets.
>
> Suppose that the LSP keeps track of statistics, and thus has
> an idea of which of its mobile wallet clients are likely to
> be net receivers.
>
> Net receivers will often have low inbound capacity (since the
> inbound capacity has been used up during previous LN receives).
>
> During times of low onchain fees, an LSP can check which of its
> offline mobile wallet clients have low inbound capacity, and are
> likely to come online in the future to receive.
> In those cases, the LSP can commit funds to a swap-in-potentiam
> with the mobile client, with the LSP as "Alice" and the mobile
> client as "Bob".
> This at least lets the LSP set up half of a swap during a time of
> low fees.
>
> If the transfer to swap-in-potentiam addresses is confirmed by
> the time the mobile wallet client comes online, the LSP can
> immediately initiate a swap, giving inbound capacity towards the
> mobile client.
> This swap can be immediately resolved, and allows the mobile
> wallet client to immediately receive funds over Lightning.
>
> In particular, if "offline receive" as designed by TheBlueMatt
> is implemented, then the LSP already has indication of a pending
> payment towards an offline mobile wallet client.
> The LSP can check if the offline mobile wallet client has
> insufficient incoming capacity to receive the funds, and if so,
> arrange to fund a swap-in-potentiam with that client.
> Then, when the mobile wallet client comes online, the LSP can
> initiate the swap with them, and once the swap completes (and
> thus the mobile wallet client has sufficient incoming capacity)
> the LSP can contact the sender LSP to complete the payment.
>
> In particular, this use-case allows for *immediate* receives as
> soon as the mobile wallet client gets foregrounded and has CPU
> time, **without** requiring 0-conf trusted transactions and
> thus without requiring any kind of semi-custodial trust, even
> if the mobile wallet client had insufficient incoming capacity.
> A channel still has to be set up beforehand (without 0-conf, if
> trusting funds to the LSP is undesirable).
>
> Implementation Sketch
> =====================
>
> The intent is to use Taproot with Schnorr signatures, but
> **without** using the keyspend path (at least initially).
>
> The plan currently is to use a `MuSig(A, B)` as the internal
> pubkey, but with the branches still explicitly laid out as
> tapleaves.
> That is, there are two tapleaf SCRIPTs corresponding to the
> two branches described above:
>
> * `<A> OP_CHECKSIGVERIFY <B> OP_CHECKSIG`
> * `<timelock> OP_CHECKSEQUENCEVERIFY OP_DROP <A> OP_CHECKSIG`
>
> Using an explicit 2-of-2 branch rather than a MuSig allows
> for a simple protocol at least for initial deployment:
> we can have Alice send the signature using `A` in a single
> half-round without having to engage in a 2-round MuSig2 signing
> ritual.
>
> We intend to use Taproot since the mobile wallet client
> may need to use a 2-of-3 or 2-of-2 signing scheme, similar
> to Blockstream Green.
> This allows either Alice or Bob in the contract to secretly
> be a FROST 2-of-3 or MuSig 2-of-2 (or any FROST k-of-n or
> MuSig n-of-n).
> This is also another reason for avoiding a 2-of-2 MuSig
> keyspend path between Alice and Bob, as there is (to our
> knowledge) no publicly-reviewed security proof that
> FROST-in-MuSig and MuSig-in-MuSig are safe (or the
> corresponding variants using MuSig2 for the signing
> ritual).
>
> Later, when we are more confident of the use of MuSig2 and
> FROST inside a MuSig2, and with using MuSig2 with possibly
> untrusted outsiders (who might exploit any mis-implementation
> of the MuSig2 signing protocol if we are not careful with
> designing it), we can seamlessly upgrade the protocol
> to use the keyspend path later, to save witness bytes.
>
> For the Onchain use-case (i.e. Alice wants to spend the UTXO
> to an onchain address), the protocol betweeen Alice and Bob
> would be:
>
> * `request_arbitrary_signature` Alice->Bob: Requests Bob
> to sign a PSBT spending a swap-in-potentiam address
> using the Onchain branch.
> * `response_arbitrary_signature` Bob->Alice: Response to
> the above, returning the requested signature.
> * `reject_arbitrary_signature` Bob->Alice: Sent in
> response to `request_arbitary_signature` if Bob refuses
> to cooperate (e.g. the UTXO being spent has already
> been accepted by Bob in a Channel use-case below).
>
> For the Channel use-case (i.e. Alice wants to spend the UTXO
> to a Lightning receiver), we operate the swap-in-potentiam
> UTXO(s) as a Spilman-like channel over two states:
>
> * HTLC-offering: Offering an amount `N` HTLC from Alice to
> Bob, with any remaining amount to a change address to
> Alice.
> * Resolved: Giving the amount `N` outright to Bob, with any
> remaining amount to a change address to Alice.
>
> The intention is that the channel is initially put into
> the HTLC-offerring state.
> Then Bob offers a corresponding in-Lightning HTLC to Alice
> over their channel.
> When Alice resolves the in-Lightning HTLC, it can then
> send a new signature for the Resolved state.
> Once the channel is in a Resolved state, Bob *SHOULD* sign
> the last state and broadcast it on the blockchain, thereby
> closing the Spilman-like channel.
>
> The protocol messages for the Channel use-case are:
>
> * `request_swap_in` Alice->Bob: Tell Bob the UTXOs with
> the same swap-in-potentiam address to spend, how
> much to put into the Alice->Bob channel direction,
> what channel to move into, and (optionally) a change
> address for Alice.
> * `reject_swap_in` Bob->Alice: Sent in response to
> `request_swap_in` if Bob refuses to cooperate (e.g.
> one of the UTXOs on offer was already signed with
> `response_arbitrary_signature`, or Bob cannot legally
> accept control of funds from one or more of the UTXOs
> offerred).
> * `accept_swap_in` Bob->Alice: Sent in response to
> `request_swap_in`, containing the Bob-side address to
> send funds to later once the state is Resolved.
> * `swap_in_signed` Alice->Bob: Response to
> `accept_swap_in`, containing the Alice-side signature
> for the HTLC-offering state transaction.
> Once Bob receives this, Bob can safely construct a
> new on-Lightning HTLC using BOLT1
> `update_offer_htlc`.
> * `swap_in_resolved` Alice->Bob: Sent after Alice has
> acquired the funds via `update_fulfill_htlc` of the
> corresponding on-Lightning HTLC, containing the
> Alice-side signature for the Resolved state
> transaction.
> The Resolved state transaction spends to the Bob-side
> address given in `accept_swap_in`, and any change to
> the Alice-side change address in `request_swap_in`.
>
> The plan is to reserve only one odd BOLT1 message ID,
> and to embed the actual swap-in-potentiam message ID
> as the first 2 bytes of the BOLT1 message, to reduce
> pollution of the limited BOLT1 message ID space and to
> allow more flexibility for swap-in-potentiam to expand
> to new messages inside its own message ID space.
>
> For a richer future protocol, we will want to consider
> how a swap-in can be combined with a splice-in.
> This is useful if the current total capacity of the
> channel is lower than the available onchain funds.
> The swap-in can be credited immediately (and is limited
> to the current total capacity) while additional funds
> can be added to the channel via splice-in (which is
> credited only once the splice-in is confirmed).
>
> As-is, a similar result can be obtained using openv1,
> wherein a swap-in is combined with a channel open,
> with the swap-in immediately credited while the channel
> open is awaiting confirmation:
>
> * Alice and Bob currently have one or more existing
> channels, and Alice has a UTXO in a swap-in-potentiam
> address whose value exceeds the incoming capacity of
> the existing channel(s).
> * Alice->Bob `open_channel`.
> * Bob->Alice `accept_channel`.
> * Alice->Bob `request_swap_in` with the "change address"
> being the funding address of the channel.
> * Bob->Alice `accept_swap_in` provides the TXID of the
> funding transaction (Alice now knows the "change
> address" and the Bob final Resolved address, letting it
> know the final Resolved state transaction TXID).
> * Alice->Bob `funding_created` with the TXID.
> * Bob->Alice `funding_signed`.
> * Alice->Bob `swap_in_signed` to provide the signature
> spending the swap-in-potentiam address to Bob.
> * Bob then constructs an HTLC over the existing channel,
> which Alice claims, revealing the preimage.
> * Alice->Bob `swap_in_resolved`.
> * Bob then broadcasts the Resolved state transaction,
> which is also the funding transaction of the new channel.
> * Both Alice and Bob await confirmation of the transaction
> in order to use the new channel.
> Alice can still use the existing channel, which has been
> topped-up with fresh outgoing capacity by the swap-in.
>
> (The above is not safe, as Bob can complete the protocol
> by using the HTLC-offerring state transaction; this can
> be fixed by having Alice open *2* channels with the same
> amount, one with the HTLC-offering state transaction as
> the funding tx, the other with the Resolved state
> transaction as the funding tx, and later `error`ing the
> channel corresponding to the transaction that is not
> confirmed; this is left as an exercise to the reader,
> though note that it requires two different change addresses
> for Alice for both HTLC-offerring and Resolved states,
> which can be arranged for the protocol)
>
> --
>
> [1]:
> https://en.bitcoin.it/wiki/Payment_channels#CLTV-style_payment_channels
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230104/22436848/attachment-0001.html>

2023-06-09 13:04:40

- reply

📅 Original date posted:2021-12-08
📝 Original message:
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 <bastien at acinq.fr> 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 <bastien at acinq.fr> 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 very close to the mechanisms we currently have.
>>
>> I'll spend some time specifying this in more details, to verify that we're
>> not missing anything. What I really like about this proposal is that we
>> can probably bundle that protocol change with `option_simplified_update`
>> [0]
>> without the adaptor sigs, and simply add the adaptor sigs as tlvs when we
>> do PTLCs. That lets us deploy this new update protocol separately from
>> PTLCs
>> and ensure it also simplifies the state machine and makes other features
>> such as splicing [1] and dynamic channel upgrades [2] easier.
>>
>> Thanks,
>> Bastien
>>
>> [0] https://github.com/lightning/bolts/pull/867
>> [1] https://github.com/lightning/bolts/pull/863
>> [2] https://github.com/lightning/bolts/pull/868
>>
>> Le mer. 8 déc. 2021 à 10:29, Anthony Towns <aj at erisian.com.au> a écrit :
>>
>>> On Tue, Dec 07, 2021 at 11:52:04PM +0000, ZmnSCPxj via Lightning-dev
>>> wrote:
>>> > Alternately, fast-forwards, which avoid this because it does not
>>> change commitment transactions on the payment-forwarding path.
>>> > You only change commitment transactions once you have enough changes
>>> to justify collapsing them.
>>>
>>> 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).
>>>
>>> That is, if you have two PTLCs, one from A->B conditional on X, one
>>> from B->A conditional on Y. Then if A wants to update the commitment tx,
>>> she needs to
>>>
>>> 1) produce a signature to give to B to spend the funding tx
>>> 2) produce an adaptor signature to authorise B to spend via X from his
>>> commitment tx
>>> 3) produce a signature to allow B to recover Y after timeout from his
>>> commitment tx spending to an output she can claim if he cheats
>>> 4) *receive* an adaptor signature from B to be able to spend the Y
>>> output
>>> if B posts his commitment tx using A's signature in (1)
>>>
>>> The problem is, she can't give B the result of (1) until she's received
>>> (4) from B.
>>>
>>> It doesn't matter if the B->A PTLC conditional on Y is in the commitment
>>> tx itself or within a fast-forward child-transaction -- any previous
>>> adaptor sig will be invalidated because there's a new commitment
>>> transaction, and if you allowed any way of spending without an adaptor
>>> sig, B wouldn't be able to recover the secret and would lose funds.
>>>
>>> It also doesn't matter if the commitment transaction that A and B will
>>> publish is the same or different, only that it's different from the
>>> commitment tx that previous adaptor sigs committed to. (So ANYPREVOUT
>>> would fix this if it were available)
>>>
>>> So I think this is still a relevant question, even if fast-forwards
>>> make it a rare problem, that perhaps is only applicable to very heavily
>>> used channels.
>>>
>>> (I said the following in email to t-bast already)
>>>
>>> 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.
>>>
>>> This adds half a round-trip compared to now:
>>>
>>> Alice -> Bob: commitment_signed
>>> Bob -> Alice: revoke_and_ack, commitment_signed
>>> Alice -> Bob: revoke_and_ack
>>>
>>> The timings change like so:
>>>
>>> Bob can use the new commitment after 1.5 round-trips (previously 0.5)
>>>
>>> Alice can be sure Bob won't use the old commitment after 2 round-trips
>>> (previously 1)
>>>
>>> Alice can use the new commitment after 1 round-trip (unchanged)
>>>
>>> Bob can be sure Alice won't use the old commitment after 1.5
>>> round-trips
>>> (unchanged -- note: this is what's relevant for forwarding)
>>>
>>> Making the funding tx a musig setup would mean also supplying 64B
>>> of musig2 nonces along with the "adaptor sigs" in one direction,
>>> and providing the other side's 64B of musig2 nonces back along with the
>>> (now partial) signature for spending the funding tx (a total of 256B of
>>> nonce data, not 128B).
>>>
>>> Because it keeps both peers' commitments synchronised to a single channel
>>> state, I think the same protocol should work fine with the revocable
>>> signatures on a single tx approach too, though I haven't tried working
>>> through the details.
>>>
>>> Fast forwards would then be reducing the 2 round-trip protocol to
>>> update the state commitment to a 0.5 round-trip update, to reduce
>>> latency when forwarding by the same amount as before (1.5 round-trips
>>> to 0.5 round-trips).
>>>
>>> Cheers,
>>> aj
>>>
>>> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20211209/dcadd171/attachment-0001.html>

2023-06-09 13:04:37

- reply

📅 Original date posted:2021-12-07
📝 Original message:
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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20211207/894e2b77/attachment.html>

2023-06-09 13:04:16

- reply

📅 Original date posted:2021-10-13
📝 Original message:
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 at 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 script is changed to e.g. a p2tr that uses musig.
>
> Crucially, note that all the approach needs is some blockchain-visible
> nonce that is already known at the time we need to construct the
> open_channel message (as we want to be able to derive some of the keys
> that are sent as part of the open_channel message
> (e.g. payment_basepoint) from it).
> As long as the funding output uses a 2of2 OP_CHECKMULTISIG,
> the local funding_pubkey fits the bill.
>
> Note that irrespective of any restrictions on the script used in
> the funding output, we could use the funding scriptPubKey/address as
> the nonce, if the open_channel/accept_channel messages were
> split into two.
> For example, instead of the single round of open_channel/accept_channel,
> there could be two rounds:
> - an open_channel_part1, where the peers exchange only
> the funding_pubkey (and the other non-pubkey fields), and
> - an open_channel_part2, where the rest of the pubkeys are sent
> This way the peers would learn what the funding address would be after
> the first round finishes, and could potentially use that to derive
> their other channel keys (needed for round 2).
>
> So, to arrive at my point, I would like to ask whether people think
> such a change - or something similar - might be useful, and if so,
> whether it could/should be incorporated to the current
> channel establishment v2 proposal [1].
> If there is agreement that this would be useful, a spec change
> would be most useful before changing the 2of2 multisig script.
>
> Regards,
> ghost43 (SomberNight)
>
>
> [0]: https://github.com/ACINQ/eclair/pull/1097
> [1]: https://github.com/lightningnetwork/lightning-rfc/pull/851
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20211013/390ec20d/attachment-0001.html>

2023-06-09 13:04:10

- reply

📅 Original date posted:2021-10-13
📝 Original message:
On Tue, 12 Oct 2021 at 14:08, Anthony Towns <aj at erisian.com.au> 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) [<payment-recovery-delay> CSV bob CHECKSIG]
> output:
> [<bob-revoke> checksigverify <alice> checksig
> ifdup notif <channel-recovery-delay> csv endif]
>
> Too-slow:
> input:
> (2) [<payment-timeout> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20211013/f94a9551/attachment.html>

2023-06-09 13:04:09

- reply

📅 Original date posted:2021-10-11
📝 Original message:
On Mon, 11 Oct 2021 at 9:23 pm, Lloyd Fournier <lloyd.fourn at gmail.com>
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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20211012/603c793a/attachment.html>

2023-06-09 13:04:09

- reply

📅 Original date posted:2021-10-11
📝 Original message:
On Mon, 11 Oct 2021 at 17:30, Anthony Towns <aj at erisian.com.au> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20211011/270d3661/attachment.html>

2023-06-09 13:04:08

- reply

📅 Original date posted:2021-10-11
📝 Original message:
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 <aj at erisian.com.au> 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
> "<B/2/n/i> CHECKSIGVERIFY <D> CSV"
>
> * An htlc paying to Bob: pays to RP/2/k with script paths:
> + "LENGTH 32 EQUALVERIFY HASH160 <X> EQUALVERIFY <B/2/n/i/k>
> CHECKSIGVERIFY <A/2/n/i/k> CHECKSIG"
> + "<A/2/n/i/k/1> CHECKSIGVERIFY <T> CLTV"
>
> * A ptlc paying to Bob: pays to RP/2/k with script paths:
> + "<B/2/n/i/k> CHECKSIG NOTIF <T> CLTV DROP ENDIF <A/2/n/i/k> 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 0<i<=5000, and she will only need to calculate
> 5000*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 support option_static_remotekey, but compensates for that
> by allowing balances to be recovered with only the channel setup data
> even if all revocation data is lost.
>
This is rather big drawback but is this really the case? Can't "in-flight"
transactions send the balance of the remote party to their unencumbered
static remote key? Since there is no "in-flight" transaction just after you
create a new balance tx you can just sign a "good will" in-flight tx
whenever you create a new balance tx that sends all the coins to your
static key. Of course, your counterparty has no incentive to broadcast this
when they close the channel but we can just specify that as part of the
protocol you broadcast this anyway (even if it gives you nothing). It's no
skin off their back.
Ok so what about the fee for the "good will" tx? Well let's say it is a
special case and just pays for itself with a reasonable fee. The "good
will" tx is low time preference and can be CPFP easily if you haven't lost
your state. If you have lost your state then this is much better than
nothing.
Cheers,
LL
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20211011/a619e4b8/attachment-0001.html>

2023-06-09 13:02:32

- reply

📅 Original date posted:2021-06-13
📝 Original message:
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 <ZmnSCPxj at protonmail.com> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210613/fdeacd68/attachment.html>

2023-06-09 13:02:31

- reply

📅 Original date posted:2021-06-01
📝 Original message:
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 at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210602/d72b5993/attachment.html>

2023-06-09 13:02:31

- reply

📅 Original date posted:2021-06-07
📝 Original message:
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 <ZmnSCPxj at protonmail.com> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210607/510d656b/attachment.html>

2023-06-09 13:02:29

- reply

📅 Original date posted:2021-05-24
📝 Original message:
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210524/98ec9903/attachment.html>

2023-06-09 13:02:25

- reply

📅 Original date posted:2021-05-02
📝 Original message:
On Thu, 29 Apr 2021 at 06:15, David A. Harding <dave at dtrt.org> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210503/2e8afd2a/attachment.html>

2023-06-09 13:02:25

- reply

📅 Original date posted:2021-05-03
📝 Original message:
On Mon, 3 May 2021 at 22:58, David A. Harding <dave at dtrt.org> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210504/dec95c85/attachment.html>

2023-06-09 13:02:17

- reply

📅 Original date posted:2021-04-27
📝 Original message:
On Wed, 28 Apr 2021 at 09:36, Lloyd Fournier <lloyd.fourn at gmail.com> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210428/d8436baa/attachment.html>

2023-06-09 13:02:16

- reply

📅 Original date posted:2021-04-27
📝 Original message:
Hey Rusty,
Thoughts on each point below.
On Fri, 23 Apr 2021 at 14:29, Rusty Russell <rusty at rustcorp.com.au> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210428/9090ecc5/attachment.html>

2023-06-09 13:02:15

- reply

📅 Original date posted:2021-04-20
📝 Original message:
Hi Rusty,
On Tue, 20 Apr 2021 at 10:55, Rusty Russell <rusty at rustcorp.com.au> wrote:
> Lloyd Fournier <lloyd.fourn at gmail.com> writes:
> > On Wed, Dec 9, 2020 at 4:26 PM Rusty Russell <rusty at rustcorp.com.au>
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210420/65f16c10/attachment.html>

2023-06-09 13:02:14

- reply

📅 Original date posted:2021-04-18
📝 Original message:
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 <lee.chiffre at secmail.pro>
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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210418/eaf2a040/attachment.html>

2023-06-09 13:01:55

- reply

📅 Original date posted:2021-02-04
📝 Original message:
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 at 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, not sure).
> (WabiSabi cleverly uses the user's UTXO as the scarce resource to mitigate
> this problem.)
>
> And of course, these problems get fixed by LN, if users have to pay to get
> their service, the service does not have to ban the users by DoS-ing
> anymore. So I think the LN-based payment and KVAC-based app fits very well.
>
> Thus, if the service wants to grant some right to do something with their
> server resource to users in an unlinkable fashion, then I believe
> exchanging the credential in this way has a benefit.
>
>
> Regards,
>
> Miyamoto.
>
>
> [1]:
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-April/002647.html
> [2]: https://eprint.iacr.org/2013/516.pdf
> [3]: https://github.com/zkSNACKs/WabiSabi
> [4]: https://signal.org/blog/pdfs/signal_private_group_system.pdf
> [5]: https://www.microsoft.com/en-us/research/project/u-prove/
> [6]: https://core.ac.uk/download/pdf/193377167.pdf
> [7]: DuckDuckGo has an interesting solution for this. But it is not a
> general solution for all kinds of apps and I doubt how good it works.
> https://spreadprivacy.com/duckduckgo-revenue-model/
>
>
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210205/8001a145/attachment.html>

2023-06-09 13:01:54

- reply

📅 Original date posted:2021-02-03
📝 Original message:
On Fri, Jan 29, 2021 at 10:51 AM Rusty Russell <rusty at rustcorp.com.au>
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210203/253a4ccb/attachment.html>

2023-06-09 13:01:51

- reply

📅 Original date posted:2021-01-28
📝 Original message:
On Wed, Jan 20, 2021 at 12:34 PM Rusty Russell <rusty at rustcorp.com.au>
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 [1,2].
3. It is therefore rather redundant to do this type of active UTXO probing
since all you need to do is wait and be patient. Churning public nodes will
eventually use their UTXO to do a dual or single funding. Then by
cross-layer de-anonymization techniques you will be able to determine that
they owned that UTXO without ever interacting with the node.
4. These techniques can even be applied to private channels at least while
they are identifiable on the blockchain (in [2] using chainalysis they can
identify one node involved in a private channel 79% of the time).
5. There is of course some extra advantage in doing this attack but looking
at the effectiveness of techniques in [1,2] and my intuition about how
churning nodes are most susceptible to these techniques I *guess* it
wouldn't be much. If this is the case then chainalysis companies may not be
able to justify doing active attacks when passive attacks work almost as
well.
6. It may be more effective to deal with UTXO probing outside of the
protocol. For example, a group of dual-funders could maintain a shared UTXO
blacklist and use chainalysis on it to not only ban single UTXOs but entire
clusters of outputs. i.e. do chainalysis on the chainalyzers! There are
some efforts to create open tools to do Chainalysis [3] that could be
leveraged against this attack. This might be much more effective than
PoDLEs as just spending the output somewhere else would not be enough to
use it again in the attack.
7. The above PoDLE proposal actually creates a new extra bit of data that
can be used for chainalysis -- when you broadcast the claim message you are
saying you're going to make a dual funded channel sometime soon. So
Chainalysis can look in the next block for something that looks like a dual
funding and know you participated. This could be quite valuable for them
and I would hesitate to give it to them in the anticipation of them doing
an attack they may never actually do.
8. If all of the above points are not enough to prevent this attack from
being widespread and the above PoDLE proposal is still the best idea I
guess it wouldn't be too hard to shoehorn it into the protocol later.
At the moment my bias is towards doing nothing and keeping things simple.
It seems chainalysis techniques are effective at associating funding UTXOs
to nodes for the most common usage patterns. Taproot will change the game
for private channels but won't do much for public channels.
Having said that -- it was a thing in JoinMarket so I might be wrong. I can
offer some conjecture as to why JoinMarket had this issue: if you can find
all the maker UTXOs before and after a join then you have removed a lot of
the anonymity set. Since CoinJoin is a UTXO privacy technology this makes
sense.
[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).
Cheers,
LL
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210128/1f7d828d/attachment.html>

2023-06-09 13:01:50

- reply

📅 Original date posted:2021-01-09
📝 Original message:
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210109/f94f442f/attachment.html>

2023-06-09 13:01:50

- reply

📅 Original date posted:2021-01-14
📝 Original message:
On Wed, Jan 13, 2021 at 11:54 AM Rusty Russell <rusty at rustcorp.com.au>
wrote:
> Lloyd Fournier <lloyd.fourn at gmail.com> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210115/db7150a5/attachment.html>

2023-06-09 13:01:49

- reply

📅 Original date posted:2021-01-04
📝 Original message:
Happy New Year Lightning Developers,
I've recently been closely looking at the dual funding proposal [1] because
it uses a DLEQ proof (PoDLE) which we are also working on specifying as
part of DLC ECDSA adaptor signatures [2].
While reading it I had some queries and ideas that I thought were worth
sharing (even though they are very very late).
# Background
Lisa posted a draft proposal [1] which includes the PoDLE and explained it
in [3] along with a good list of its weaknesses.
The original discussion thread where the idea was conceived is [4] and
there is an excellent summary in the following optech [5] which I post
below:
> Another proposal was to use PoDLE, which was originally developed for
JoinMarket based on a suggestion by Gregory Maxwell. This protocol allows
an initiating user such as Mallory to commit to a UTXO in a way that
prevents anyone from identifying that UTXO. The participating user, such as
Bob, publishes the commitment across the network (e.g. the JoinMarket
network) so that nobody else will start a session with Mallory while she’s
using that particular UTXO. Then Bob asks Mallory to identify her UTXO and,
if it’s a valid UTXO that matches her commitment, Bob discloses his UTXO to
Mallory so that they can proceed with the protocol (e.g. a coinjoin). If
Mallory aborts the protocol before completion, the commitment previously
published across the network prevents her from being able to start a new
session with any other user and so learn their UTXO. Mallory’s only option
is to spend her coins from herself to herself in order to generate a new
UTXO—a process that costs her money and so limits her ability to spy on
users. (Note, though, that PoDLE as implemented in JoinMarket allows
Mallory up to three retries by default so honest users aren’t penalized for
occasional accidental failures, such as a loss of network connectivity.)
The idea is to adapt this protocol for LN in order to prevent attackers
from learning which available UTXOs are controlled by LN users.
Especially relevant to this post is the idea posted by Darosior here [6]
which was summarized as follows:
> One proposal to fix this would require the person proposing to open the
channel (e.g. Mallory) to provide their UTXO(s) in a ready-to-spend state
so that probing would cost money (e.g. transaction fees). A downside of
this approach is that the construction proposed would be easily
identifiable by block chain analysis, making it easy to determine when a
dual-funded channel was opened
The goals of this post is to (i) see if I understand the PoDLE idea
correctly, to (ii) refine Darosior's idea and to (iii) propose a minimal
alternative idea.
# Requirements
Informally, here are the desirable properties I came up with for a dual
funding protocol:
1. If a malicious initiator learns a peer UTXO, then the initiator should
have to spend their UTXOs before reusing them against the next peer (should
be forced to spend them to repeat attack -- *if attacking sequentially*).
2. A malicious initiator should not be able to use the same UTXOs in
parallel with multiple peers (to learn the UTXOs of multiple makers with a
single UTXO).
3. An honest initiator should not have to spend their UTXOs if they execute
with a malicious peer.
4. dual-funded opening transactions should not have any distinguishing
features (i.e. sighash flags).
5. An honest but intermittently failing initiator should not have their
UTXO details sent by an honest peer to other parties.
Note I am going to ignore property (2) because of proposals below can turn
their protection against sequential attacks (1) into protection against
parallel attacks (2) by having the peer choose a random time delay and see
if anything is gossiped to them that would indicate malicious behavior by
the initiator in some other channel.
# PoDLEs
To solve this problem in JoinMarket, Waxwing had the idea [8] of turning
knowledge of a secret key for a particular UTXO into a kind of unlinkable
credential.
Given a UTXO public key P1, the initiator projects their private key onto a
different generator J to produce P2.
P2 is unlinkable to P1 (without a proof) but is fully determined by P1.
This allows participants to maintain a blacklist of P2s without learning
the P1s.
Having the P1s in the blacklist would make the blacklist itself useful for
chain analysis because it contains a list of UTXOs that tried to open
channels (but perhaps accidentally failed).
The idea is like this:
1. Taker asks some maker's if they want to do a coinjoin and sends them all
SHA256(P2)
2. When they find the maker they want to proceed with they reveal P2 and
prove DLEQ((P1, G), (P2, J)) i.e. P1 and P2 have the same private key just
different base points.
3. If they haven't received SHA256(P2)from the gossip network (i.e. it's
not in the blacklist), the maker then sends their own UTXO data AND gossips
SHA256(P2)
4. They carry on the protocol.
The current lightning proposal [1] follows the same logic except that it
only gossips SHA256(P2) in case of malicious behavior (this seems sensible).
If I understood it correctly, then it achieves properties (1,4,5).
The main downside is that it introduces a new gossip message. The
difficulties associated with this are listed in [3].
Notably it is missing property (3) - protection against malicious peers who
gossip SHA256(P2) even when there was no wrongdoing.
A question I have is why is SHA256(P2) sent up front? I think that P2 can
just be sent along with the proof later on in the case of dual funding.
Waxwing gave an explanation of it in the case of joinmarket in [7] but I
didn't grasp it.
# Darosior's SIGHASH_SINGLE|SIGHASH_ANYONECANPAY
The proposal from Darosior [6] is to have the taker provide their inputs in
a ready to broadcast state using SIGHASH_SIGNLE|SIGHASH_ANYONECANPAY.
This way the peer never needs to send their inputs directly to the
initiator (the initiator will only find out about them when the transaction
is broadcast).
I encourage the reader to look at [6] which has nice diagrams and is very
short and to the point.
This achieves all properties except for (4 - distinguishable on-chain)
which is why it was dismissed.
I think it is possible to extend the idea to achieve (4) and therefore
obtain all desired properties.
Simply put peers can just use the SINGLE|ANYONECANPAY signature as back ups
in case of abort. Here's how it could work in my mind:
1. Initiator requests dual-funding and provides a TX_temp spending their
input set to a main output and a change output (does not sign it yet). They
also provide a sighash SIGNLE|ANYONECANPAY signature on the main output
spending into TX_backup-fund and a signature on the first commitment
transaction spending from TX_backup-fund (exactly as in [6]).
2. Peer responds with commitment TX signature for TX_backup-fund.
3. Initiator responds with the signatures for TX_temp.
*Peer now has a fully functional transaction chain with which to open the
channel -- now they can attempt to upgrade to a SIGHASH_ALL opening*.
4. Peer (if possible) checks there are no existing transactions in the
chain or mempool spending from the taker's inputs. If not it responds with
its inputs, change and commitment tx signature for a SIGHASH_ALL TX_fund.
5. Initiator responds with commitment TX signature and TX_fund input
signatures.
6. Peer broadcasts TX_fund.
*If at any point after step 3 Initiator does not respond for ~2 seconds
they broadcast TX_temp and TX_backup-funding*
We have (4) because the SINGLE|ANYONECANPAY signature only appears on-chain
in case of abort (i.e. TX_backup-funding makes it on-chain).
It appears to be pretty close to the ideal solution in terms of privacy and
security.
If the malicious initiator learns an output they will always have to spend
one of their inputs otherwise they will quickly get hit by the TX_temp +
TX_backup-funding.
Note that it is possible the node is just slow in which case even if step
TX_backup-funding makes it in both parties should just carry on with the
channel.
The downsides are that it involves six rounds of communication and cannot
use the "interactive tx building" protocol developed for the original
proposal
# Signaling Transactions
Finally I present a simple but unintuitive protocol that achieves roughly
the same properties as the PoDLE protocol but without lightning gossip
messages.
Whenever the initiator adds an input in the interactive tx building they
provide signatures on a "signaling" transaction spending that input (and
any inputs they have added so far).
The signaling transactions will typically spend the funds back to the
initiator's wallet.
Before revealing any of their inputs, the peer checks that none of the
inputs added by the initiator are in their mempool/chain.
If the initiator aborts the protocol after learning one of the peer's
inputs the peer broadcasts one of the signaling transactions.
Like the PoDLE proposal this doesn't achieve (3) since a malicious peer
could broadcast the signaling transaction making the honest initiator pay a
transaction fee before using the input in another session.
To mitigate this a bit, the transactions could be RBF and have a 1
sat-per-byte feerate to give the initiator a decent amount of time to use
their input productively before the tx confirms (and paying a low fee if it
ever does confirm).
The advantages of signaling transactions over PoDLE is that it doesn't
involve any wonky crypto or new gossip messages.
The advantage of the PoDLE proposal over this is that a malicious peer can
only blacklist the UTXO (not necessarily force you to spend it).
# Summary
The preference of protocol depends on how you weigh the importance of a
malicious non-initiating peer griefing the initiator.
To protect fully, the extended version of Darosior's protocol does not
allow griefing.
There is always a lot to be said for ruling out a class of attack even if
it costs you a few rounds of communication.
Is griefing a real concern though? Layer-2 is full of opportunities to
grief your counterparty and the ones presented here are hardly the worst.
If you're opening channels with someone who wants to grief you, you are
already in trouble.
PoDLEs have very weak griefing in the form of unfairly adding your UTXO to
the blacklist but comes at the cost of complexity and a few difficult to
answer questions.
I think the simplicity of signaling transactions may be worth the extra
griefing capabilities it offers a malicious peer given they are hardly as
bad as the griefing capabilities they will have if you open a channel to
them!
Cheers,
LL
[1] https://github.com/niftynei/lightning-rfc/pull/1
<https://github.com/lightningnetwork/lightning-rfc/pull/524>
[2] https://github.com/discreetlogcontracts/dlcspecs/pull/114
[3]
https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-February/002516.html
[4]
https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-January/002466.html
[5]
https://bitcoinops.org/en/newsletters/2020/02/05/#interactive-construction-of-ln-funding-transactions
[6]
https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-January/002475.html
[7]
https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-February/002522.html
[8] https://joinmarket.me/blog/blog/poodle/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210104/08adc787/attachment.html>

2023-06-09 13:01:47

- reply

📅 Original date posted:2020-12-17
📝 Original message:
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20201218/279bb4a7/attachment.html>

2023-06-09 13:01:47

- reply

📅 Original date posted:2020-12-20
📝 Original message:
On Sat, Dec 19, 2020 at 6:48 PM ZmnSCPxj <ZmnSCPxj at protonmail.com> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20201220/d95be22b/attachment.html>

2023-06-09 13:01:46

- reply

📅 Original date posted:2020-12-17
📝 Original message:
On Thu, Dec 17, 2020 at 1:56 AM ZmnSCPxj <ZmnSCPxj at protonmail.com> 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 data to surveillors, I also earn routing fees.
> The former case can only earn me selling fake data to surveillors, with
no opportunity to earn forwarding fees.
Correct and interesting analysis. I agree that you don't want to
accidentally opt in to having your peer have a way to cryptographically
prove you have a channel with them.
Except in the situation where you are already cryptographically proving to
everyone you have a channel with them in the channel announcement.
>
> > 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.
>
> If the user has all channels unpublished, it is not (normally) gossiped.
> So the well-established node would not have the ability to recover *all*
channels by backup-free scans of published nodes in the first place, only
those that are to published nodes.
>
> Or do you refer to something else?
I was thinking about public nodes with un-announced channels.
For completely private/unpublished nodes then I agree with your statement
that there is no hope no matter how you compute the keys to recover
automatically.
>
> It might be easier for the "client" here to make up different node IDs
for each "server" it connects to, by e.g. hashing its base privkey with the
server pubkey and using the hash as the privkey for its fake node ID with
that server.
>
Right. Something like this is what I was suggesting for public nodes who
want to have unpublished channels that they want to be able to channel scan
for but *do not want the other party* to be able to do so (to avoid
concerns you made clear earlier).
I think there's no strong reason to make up a new node id -- it can just be
an option in open_channel like "use this key instead of my node id for
everything in this channel".
Cheers,
LL
On Thu, Dec 17, 2020 at 1:56 AM ZmnSCPxj <ZmnSCPxj at protonmail.com> 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.9999% 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.
>
> 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.
>
> 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.
> On the other hand, it might not be possible (as you note about PTLCs).
>
> >
> > > 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.
>
> >
> > > 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.
>
> 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?
>
>
> >
> > 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.
>
> "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 data to surveillors, I also earn routing fees.
> The former case can only earn me selling fake data to surveillors, with no
> opportunity to earn forwarding fees.
>
> > 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.
>
> If the user has all channels unpublished, it is not (normally) gossiped.
> So the well-established node would not have the ability to recover *all*
> channels by backup-free scans of published nodes in the first place, only
> those that are to published nodes.
>
> Or do you refer to something else?
>
> It might be easier for the "client" here to make up different node IDs for
> each "server" it connects to, by e.g. hashing its base privkey with the
> server pubkey and using the hash as the privkey for its fake node ID with
> that server.
>
>
> > 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.
>
> If forwarding nodes are expected to have storage redundancy, deletion of
> data could be difficult as well --- there may be lots of replicas of that
> data in various places (including obsolete replicas that the node operator
> might not particularly care about, being obsolete), and deletion might not
> catch them all.
> "Honestly delete" seems like a best-effort to me.
>
> On the other hand, if the model is that privacy is to be trusted to your
> peers, then this is no worse than unpublished channels, which has the same
> model.
>
> Regards,
> ZmnSCPxj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20201218/d47a1446/attachment-0001.html>

2023-06-09 13:01:45

- reply

📅 Original date posted:2020-12-16
📝 Original message:
Hey Z,
On Tue, Dec 15, 2020 at 9:21 PM ZmnSCPxj <ZmnSCPxj at protonmail.com> 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.9999% 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

2023-06-09 13:01:44

- reply

📅 Original date posted:2020-12-15
📝 Original message:
> 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 <dave at dtrt.org> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20201215/7b1e9210/attachment.html>

2023-06-09 13:01:44

- reply

📅 Original date posted:2020-12-15
📝 Original message:
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 <lloyd.fourn at gmail.com> 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 <dave at dtrt.org> 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

2023-06-09 13:01:43

- reply

📅 Original date posted:2020-12-11
📝 Original message:
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&A
- 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 and also successfully decrypts the signature. Receiver security
is unconditional (Pedersen commitments are unconditionally hiding).
- Does this work for multiple signatures? Yes you can choose to receive N
signatures to close N channels or nothing. The signer just sends multiple
e_1, e_2 produced the same way and the receiver can decrypt them all if c =
0.
- Does it work for key aggregated signatures i.e. MuSig2? -- Yes
`encrypted_sign` just becomes a two round protocol to produce `e`.
- 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.
[1]
http://www.cs.nccu.edu.tw/~raylin/UndergraduateCourse/ComtenporaryCryptography/Spring2009/TSOINSPET2007.pdf
[2]
https://telaviv2019.scalingbitcoin.org/files/scriptless-lotteries-on-bitcoin-from-oblivious-transfer.pdf
Cheers,
LL
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20201211/0179a579/attachment.html>

2023-06-09 13:01:43

- reply

📅 Original date posted:2020-12-14
📝 Original message:
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 "aaaand
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20201214/160c7de0/attachment.html>

2023-06-09 13:01:42

- reply

📅 Original date posted:2020-12-10
📝 Original message:
On Wed, Dec 9, 2020 at 4:26 PM Rusty Russell <rusty at rustcorp.com.au> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20201210/28068208/attachment.html>

2023-06-09 13:01:42

- reply

📅 Original date posted:2020-12-09
📝 Original message:
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20201209/22894c20/attachment.html>

2023-06-09 13:01:41

- reply

📅 Original date posted:2020-12-06
📝 Original message:
Hi list,
I've been considering the problem of recovering lightning channels after
losing channel state in a boating accident. The modern way of doing this
seems to be "static channel backups" -- these are essentially lists of
channel ids and the nodes you had the channels with.
The idea is that with this backup you can remember who you had channels
with, connect to them and ask them to force close the channel (can someone
link me the concrete protocol messages you send to do this?).
It occurred to me that if the lightning protocol were changed slightly you
could do this without the channel backup at all. Consider the open channel
message and its two fields `funding_pubkey` and `temporary_channel_id`.
https://github.com/lightningnetwork/lightning-rfc/blob/master/02-peer-protocol.md#the-open_channel-message
The reason `temporary_channel_id` is necessarily "temporary" is because we
don't know the other party's `funding_pubkey`. Instead I propose using
deterministically randomized version of the node's static public key as the
`funding_pubkey` so we know it up front. Specifically, when opening a
channel with a remote node, do a Diffie-Hellman operation with their public
key and use the resulting shared secret to deterministically produce
scalars r1 and r2 and use 2-of-2(r1*G + P_local, r2*P_remote) as the script
pubkey of funding output. Now we know what the funding output would look
like with any node without interacting with them. Of course, to open
multiple channels with the same node we would have to generate a new shared
secret from each one by hashing a counter.
Now that we can figure out what our funding outputs with each node look
like non-interactively, when we lose our channel state we can find them in
the UTXO set as long as we can recreate a list of node's we may have had
channels with. For most non-enterprise users (such as myself) this can be
done automatically because we exclusively have channels with well known
reliable public nodes whose public keys can be discovered through routing
gossip or from public indexes. Therefore if I can just restore my node's
keypair from my seed I should be able to scan the network for nodes and
figure out if I have channels open with them and then carry out the
recovery process. From my perspective this seems to be a rather nice
improvement in user experience.
Thoughts?
Cheers,
LL
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20201207/5d78d233/attachment.html>

2023-06-09 13:01:39

- reply

📅 Original date posted:2020-12-02
📝 Original message:
> 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 <ZmnSCPxj at protonmail.com> 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 instead focus on mitigating the effects of the
> incompetence-based non-attacks [such as this proposal](
> https://github.com/ElementsProject/lightning/issues/2632#issuecomment-736438980),
> instead of attempting to defend against the mirage of loop attacks.
>
>
> I could be utterly wrong here though.
>
>
> Regards,
> ZmnSCPxj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20201202/c3d28486/attachment.html>

2023-06-09 13:01:38

- reply

📅 Original date posted:2020-11-30
📝 Original message:
On Mon, Nov 30, 2020 at 7:34 PM Gleb Naumenko <naumenko.gs at gmail.com> 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 <lloyd.fourn at gmail.com>,
> 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 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 <dave at dtrt.org> 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 at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20201201/84676029/attachment-0001.html>

2023-06-09 13:01:35

- reply

📅 Original date posted:2020-11-30
📝 Original message:
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 <dave at dtrt.org> 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20201130/a4049932/attachment.html>

2023-06-09 13:01:07

- reply

📅 Original date posted:2020-10-10
📝 Original message:
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 <lloyd.fourn at gmail.com> 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
> 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
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20201011/a3df0d91/attachment.html>

2023-06-09 13:01:07

- reply

📅 Original date posted:2020-10-09
📝 Original message:
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20201009/e40df51d/attachment.html>

2023-06-09 13:01:05

- reply

📅 Original date posted:2020-10-08
📝 Original message:
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 <lloyd.fourn at gmail.com> 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 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 therefore can produce:
>
> ra + rb' + H(Ra + Rb' || A + B || m)b
>
> which when subtracted from sa and divided by H(Ra + Rb' || A + B || m) will yield b (Bob's static secret key).
>
> The advantage of witness asymmetric channels using discrete keys over present lightning seems to boil down to a simpler transaction structure (in favour of using more complicated cryptography).
> However, for key aggregation there is a measurable improvement in communication complexity: It halves the amount of interactive signatures that need to be computed per payment.
> This is because each PTLC does not need to be duplicated across the asymmetric state of both parties.
>
> Zeeman pointed out in [2] that the number of signing rounds (which this does not improve) may be prohibitive anyway for payment applications at least so it remains to be seen whether this efficiency can be utilised for payment PTLCs in LN.
> Thankfully, there are still advancements being made in Schnorr key aggregated signing so the right answer to this might change over time.[3]
>
> [1] The caveats about not using deterministic nonces in MuSig can be avoided here since we necessarily have state in LN.
> [2] https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-December/002375.html
> [3] https://medium.com/blockstream/musig-dn-schnorr-multisignatures-with-verifiably-deterministic-nonces-27424b5df9d6
>
> Cheers,
>
> LL

2023-06-09 13:00:48

- reply

📅 Original date posted:2020-08-31
📝 Original message:
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 <ZmnSCPxj at protonmail.com> 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 token-passing message.
>
> This solution requires a good amount of bandwidth in such token-passing messages, which can multiply with the number of channels a single node has.
> If token-passing is not done in short time frames (sub-second) then it potentially increases the latency of forwarding, thus this represents a latency vs bandwidth tradeoff.
>
> There may be better solutions for this race-condition problem.
> For example, it seems to me that we can still have different histories for both sides of the channel, i.e. different transactions on both sides, the same as in current Poon-Dryja BOLT.
> After all, the witnesses are asymmetric anyway.
> But that completely negates the stated goal of removing the different transactions on both sides and the hoped-for reduction in complexity, so an exercise in futility.
>
>
> Regards,
> ZmnSCPxj

2023-06-09 13:00:48

- reply

📅 Original date posted:2020-09-01
📝 Original message:
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200902/ccfda71e/attachment.html>

2023-06-09 13:00:48

- reply

📅 Original date posted:2020-09-10
📝 Original message:
>
>
> 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 therefore can produce:
ra + rb' + H(Ra + Rb' || A + B || m)b
which when subtracted from sa and divided by H(Ra + Rb' || A + B || m) will
yield b (Bob's static secret key).
The advantage of witness asymmetric channels using discrete keys over
present lightning seems to boil down to a simpler transaction structure (in
favour of using more complicated cryptography).
However, for key aggregation there is a measurable improvement in
communication complexity: It halves the amount of interactive signatures
that need to be computed per payment.
This is because each PTLC does not need to be duplicated across the
asymmetric state of both parties.
Zeeman pointed out in [2] that the number of signing rounds (which this
does not improve) may be prohibitive anyway for payment applications at
least so it remains to be seen whether this efficiency can be utilised for
payment PTLCs in LN.
Thankfully, there are still advancements being made in Schnorr key
aggregated signing so the right answer to this might change over time.[3]
[1] The caveats about not using deterministic nonces in MuSig can be
avoided here since we necessarily have state in LN.
[2]
https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-December/002375.html
[3]
https://medium.com/blockstream/musig-dn-schnorr-multisignatures-with-verifiably-deterministic-nonces-27424b5df9d6
Cheers,
LL
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200910/db11d979/attachment.html>

2023-06-09 13:00:45

- reply

📅 Original date posted:2020-08-25
📝 Original message:
# 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 parties must exchange two curve
points each:
- A _publication_ point (denoted P) whose secret is revealed if that party
broadcasts the commitment transaction.
- A _revocation_ point (denoted R) whose secret is explicitly revealed to the
other party when revoking this commitment transaction.
Let (Pa, Ra) and (Pb, Rb) be the publication and revocation points of Alice and
Bob respectively. The scriptPubkey of all outputs on a commitment transaction is
2-of-2(Pa + Ra, Pb + Rb). To make it slightly harder to distinguish these
outputs from other uses of 2-of-2 you can imagine that we pseudorandomly
randomize each output so that they are not identical.
When signing a commitment transaction, the parties instead exchange adaptor
signatures such that the party who publishes the commitment transaction must
reveal their publication secret. This means that if a malicious party broadcasts
a commitment transaction for which they have already revealed their revocation
secret the other party will know both secrets and therefore both secret keys in
2-of-2(Pa + Ra, Pb + Rb). They can use this to unilaterally spend from all the
outputs on the commitment transaction to punish the malicious party.
As a point of interest there is no problem with both parties broadcasting the
same commitment transaction at the same time with their different signatures. In
theory, both parties seeing the other's commitment transaction over the Bitcoin
network could act as a kind of out of band optimization because it means they
both learn each other's publication secrets and can therefore settle all the
outputs without having to wait for relative time-locks (regardless of which
signature makes it into the blockchain).
## Balance outputs
A balance output going to Alice has a scriptPubkey of 2-of-2(Pb, Ra) and the
converse for Bob's balance output i.e. 2-of-2(Pa,Rb). Each balance output has a
pre-signed relative time-locked claim transaction spending it to an address
owned by the deserving party.
## PTLCs
PTLC outputs are added directly to commitment transactions in the form described
above. Each PTLC has two pre-signed transactions spending from it: PTLC-success
and PTLC-timeout. Broadcasting the PTLC-success transaction reveals the PTLC
secret in the usual way using an adaptor signatures. The PTLC-timeout
transaction has an absolute time-lock on it through the nlocktime transaction
value.
For a PTLC output being offered by Alice to Bob both transactions have a single
output with the following scriptPubkeys:
- PTLC-success: 2-of-2(Pa, Rb)
- PTLC-timeout: 2-of-2(Pb, Ra)
Both transactions have a pre-signed "claim" transaction that spends the funds to
an address owned by the desired party after a relative time-lock (i.e. it has a
sequence number set). Alternatively, the PTLC-success/timeout can be constructed
like HTLC-success/timeout transactions in lightning today where the destination
party can spend unilaterally after the relative time-lock enforced with OP_CSV.
I find this slightly unappealing because it means using an output that is not
just a 2-of-2.
Only the destination party needs to have the signature (or adaptor signature) on
the PTLC-success or PTLC-timeout transactions. So if it's a PTLC offered by
Alice to Bob then Bob will have an adaptor signature on PTLC-success and Alice
will have an ordinary signature on the PTLC-timeout transaction. There is no
theoretical security issue with both parties having the signatures it just makes
writing state machines easier if Alice can rule out a PTLC-success
transaction being broadcast unless she broadcasted it herself.
# Scenarios
To demonstrate the logical implications of the key combinations used in the
above 2-of-2s I'll somewhat tediously go through how each output is resolved.
I'll use the label "BOB OWNS" to indicate that Bob knows both keys for the
2-of-2 and Alice has no pending time-locked transactions that spend from the
output. Likewise I'll use "BOB MUST SPEND" to indicate that Bob knows both keys
but there *is* a pending time-locked transaction that Alice may use in the
future.
In these examples Alice is the one broadcasting the commitment transaction but
it could just as easily be Bob (remember it is the same transaction), in which
case the converse of each situation applies.
## Balance output
Here is what happens for balance outputs.
Alice broadcasts a non-revoked commitment transaction (reveals Pa):
1. Balance output for Alice: Alice waits for the relative time-lock and then
broadcasts her claim transaction.
2. Balance output for Bob: BOB OWNS. The output is 2-of-2(Pa,Rb) and Alice has
revealed Pa.
Alice broadcasts a revoked commitment transaction (reveals Pa and has already
revealed Ra):
1. Balance output for Alice: BOB MUST SPEND. The output is 2-of-2(Ra,Pb) so Bob
knows both keys but he needs to spend it before Alice's relative time-locked
claim transaction.
2. Balance output for Bob: BOB OWNS. The output is 2-of-2(Pa,Rb) and Alice has
revealed Pa.
## PTLC output
In each of the following scenarios Alice broadcasts the commitment transaction
and therefore reveals Pa. I describe what happens when the PTLC-success
transaction makes it in instead of the PTLC-timeout and vise versa.
Alice broadcasts a non-revoked commitment transaction which has a PTLC offered
to Bob (reveals Pa):
1. PTLC-success confirmed: BOB OWNS. The output is 2-of-2(Pa,Rb) and Alice
revealed Pa when she broadcasted the commitment transaction.
2. PTLC-timeout confirmed: Alice waits until the relative time lock expires and
then broadcasts the claim transaction.
Alice broadcasts a non-revoked commitment transaction which has a PTLC offered
to herself (reveals Pa):
1. PTLC-success confirmed: Alice waits for the relative time-lock to expire and
then broadcasts the claim transaction.
2. PTLC-timeout confirmed: BOB OWNS. The output is 2-of-2(Pa,Rb) and Alice
revealed Pa when she broadcasted the commitment transaction.
When Alice broadcasts a revoked commitment with a PTLC either Alice manages to
also confirm the PTLC-success or PTLC-timeout transactions (depending on the
direction of the PTLC) or Bob revokes the PTLC output in a transaction of his
choosing. Bob can unilaterally spend the PTLC output because he knows all keys
in 2-of-2(Pa + Ra, Pb + Rb). If he misses out, he gets another shot after the
PTLC-success and PTLC-timeout transactions are confirmed. This is very similar
to lightning today but here is what happens in the two scenarios for
completeness:
Alice broadcasts a revoked commitment transaction which has a PTLC towards Bob
(reveals Pa and has already revealed Ra):
1. PTLC-timeout confirmed: BOB MUST SPEND. The output is 2-of-2(Pb,Ra) and Alice
revealed Ra when she revoked the commitment transaction but Alice has a
pending claim transaction to spend the funds.
2. Revocation tx confirmed: Bob takes all the funds.
Alice broadcasts a revoked commitment transaction which has a PTLC towards
herself (reveals Pa and has already revealed Ra):
1. PTLC-success confirmed: BOB MUST SPEND. The output is 2-of-2(Pb,Ra) and Alice
revealed Ra when she revoked the commitment transaction but Alice has a
pending claim transaction to spend the funds.
2. Revocation tx confirmed: Bob takes all the funds.
# Misc Remarks
- It looks straightforward to apply anchor outputs to this scheme
- Each "claim" transaction can be `SIGHASH_SINGLE | SIGHASH_ANYONECANPAY` to
allow combining it into a larger transaction.
[1]: https://eprint.iacr.org/2020/476.pdf
[2]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2015-November/000339.html
[3]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-January/002448.html
[4]: https://github.com/lightningnetwork/lightning-rfc/blob/master/03-transactions.md
[5]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-December/002375.html
[6]: https://joinmarket.me/blog/blog/schnorrless-scriptless-scripts/
[7]: https://joinmarket.me/blog/blog/flipping-the-scriptless-script-on-schnorr/_
[8]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-July/002064.html
[9]: https://blockstream.com/eltoo.pdf
Please let me know if something is not clear or underdeveloped or you think I
have missed something. Thanks to those who have offered their comments so far
and thanks in advance for any ideas you have that could improve this scheme.
LL

2023-06-09 13:00:07

- reply

📅 Original date posted:2020-05-05
📝 Original message:
On Tue, May 5, 2020 at 9:01 PM Luke Dashjr via bitcoin-dev <
bitcoin-dev at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200505/549643a3/attachment.html>

2023-06-09 12:59:57

- reply

📅 Original date posted:2020-04-29
📝 Original message:
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 <
thibaut at 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 no routing), it also doesn’t require any
> intermediary, and only basic ECDSA.
>
>
> As already mentioned, both DLC channels and their integration in LN could
> be made much more easily in an eltoo world, as eltoo can be used as a
> generic framework for building off-chain contracts [3].
>
>
> DLC Channels
>
> ==================================
>
> I’ll skip the part about the broken naive construction (that has the free
> option problem), and go directly for the one that actually works. The
> main trick revolves around adding two types of transaction to the regular
> DLC construction:
>
> 1. The first type of transaction is the update transaction. It’s
> pretty much the same as an LN commitment transaction, and serves a
> similar purpose, that is keeping the balance of the channel. It is
> also revokable, meaning that each party holds a different version.
> 2. The second type is the buffer transaction, which spends both
> outputs of the update transactions to produce one output that will be
> consumed by the Contract Execution Transactions (CETs). The main point
> of the buffer transaction is to solve the free option problem in the
> protocol.
>
>
> Using these two new transaction types we can now describe the update
> protocol (please refer to figure 2 of the paper for some illustration). I
> skip the establishment protocol here as the update protocol is the crispy
> part, but the establishment is described in the paper as well.
>
> 1. Alice and Bob generate the set of transactions (update, buffer, CETs
> and refund) for the new contract, with the update transactions having
> output values equal to the outcome of the previous contract,
> 2. Alice sends her signatures for Bob’s update transaction, all CETs
> and the refund transactions,
> 3. Bob sends his signatures for Alice’s update transaction, all CETs, the
> refund transactions, as well as the revocation key for his previous
> update transaction,
> 4. Alice sends the revocation key for her previous update transaction, as
> well as the signature for her buffer transaction,
> 5. Bob sends his signatures for both buffer transactions.
> 6. Alice sends her signature for Bob’s buffer transaction.
>
> An informal analysis of the protocol is provided in the paper (Section
> 3.2.4), but the main point is that it’s always the case that for both
> parties, either they can enforce the outcome of the previous contract (and
> so close the channel in case of an uncooperative counter party), either
> they can force their counter party into the new contract, but there is no
> point at which a party can pick which one to enforce (the free option
> problem).
>
>
> In the non-cooperative case, a DLC channel requires 5 on-chain
> transaction (from opening to close), while in the cooperative case it’s
> still only two. That means two more transactions in the worst case compared
> to the on-chain version, but we believe this is offset by the ability to
> establish consecutive contracts (even with two consecutive contracts, the
> number of transaction is reduced).
>
>
> Integration to the Lightning Network
>
> ==================================
>
>
> Our proposed solution to integrate the DLC channels in LN is quite simple, but
> to the best of our knowledge has not been proposed before (apologies if
> that’s wrong, and happy to be corrected). The idea is to use a “split”
> transaction, which spends the output of the fund transaction, and
> contains a single output for every channel to be created (a basic example
> would be one LN channel and one DLC channel), which works as the new
> funding for these channel. In the paper, we made this split transaction
> revokable so that it’s possible to reallocate funds between the channels, and
> close/open channels as desired. Writing this I realized it might also be
> possible to not make it revokable, which would make it less flexible but
> would remove the drawback of doubling the number of transactions to be
> created and monitored.
>
>
> The advantage of this construction is that you can support as many
> sub-channels as you want for a single fund transaction, and have the
> ability to rebalance between the channels. The disadvantage is that you
> need to create and keep track of twice as many transactions due to the
> revocation mechanism in the split transaction (though as just mentioned
> if you don’t want to rebalance and/or add/remove channels this issue is
> removed).
>
>
> Conclusion and Questions
>
> ==================================
>
>
> We proposed a way to create DLC channels, and to integrate them in the
> Lightning Network. Both can be done with existing cryptographic constructs
> and Bitcoin transactions. We’d be happy to hear what people think of this
> approach, whether it is worth pursuing considering the recent development
> of ECDSA adaptor signatures which would enable simpler constructions, and
> how complex it would be to implement in practice.
>
>
> Regards,
>
>
> Thibaut
>
>
> [1] https://hackmd.io/@lpQxZaCeTG6OJZI3awxQPQ/LN-DLC
>
> [2] https://suredbits.com/discreet-log-contracts-on-lightning-network/
>
> [3]
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-September/002136.html
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200429/2d32b18e/attachment-0001.html>

2023-06-09 12:59:56

- reply

📅 Original date posted:2020-04-28
📝 Original message:
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 <nadav at suredbits.com> 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 <laolu32 at gmail.com>
>> 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 of
>>> this
>>> new technique allows for an even larger set of deployment possibilities.
>>> This latest ECDSA variant is much simpler than the prior ones (which had
>>> a
>>> few rounds of more involved ZKPs), but since it still uses OP_CMS, it
>>> can't
>>> be used to modify the funding output.
>>>
>>> [1]:
>>> https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-December/002375.html
>>>
>>> -- Laolu
>>>
>>>
>>> On Wed, Apr 22, 2020 at 8:13 AM Nadav Kohen <nadav at suredbits.com> wrote:
>>>
>>>> Hello all,
>>>>
>>>> I'd like to give an update on the current state of thinking and coding
>>>> surrounding replacing Hash-TimeLock Contracts (HTLCs) with Point-TimeLock
>>>> Contracts (PTLCs) (aka Payment Hashes -> Payment Points) in hopes of
>>>> sparking interest, discussion, development, etc.
>>>>
>>>>
>>>> We Want Payment Points!
>>>> -----------------------
>>>>
>>>> Using point-locks (in PTLCs) instead of hash-locks (in HTLCs) for
>>>> lightning payments is an all around improvement. HTLCs require the use of
>>>> the same hash across payment routes (barring fancy ZKPs which are inferior
>>>> to PTLCs) while PTLCs allow for payment de-correlation along routes. For an
>>>> introduction to the topic, see
>>>> https://suredbits.com/payment-points-part-1/.
>>>>
>>>> In addition to improving privacy in this way and protecting against
>>>> wormhole attacks, PTLC-based lightning channels open the door to a large
>>>> variety of interesting applications that cannot be accomplished with HTLCs:
>>>>
>>>> Stuckless (retry-able) Payments with proof of payment (
>>>> https://suredbits.com/payment-points-part-2-stuckless-payments/)
>>>>
>>>> Escrow contracts over Lightning (
>>>> https://suredbits.com/payment-points-part-3-escrow-contracts/)
>>>>
>>>> High/DLOG AMP (
>>>> https://docs.google.com/presentation/d/15l4h2_zEY4zXC6n1NqsImcjgA0fovl_lkgkKu1O3QT0/edit#slide=id.g64c15419e7_0_40
>>>> )
>>>>
>>>> Stuckless + AMP (an improvement on Boomerang) (
>>>> https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-October/002239.html
>>>> )
>>>>
>>>> Pay-for-signature (
>>>> https://suredbits.com/payment-points-part-4-selling-signatures/)
>>>>
>>>> Pay-for-commitment (
>>>> https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-September/002166.html
>>>> )
>>>>
>>>> Monotonic access structures on payment completion (
>>>> https://suredbits.com/payment-points-monotone-access-structures/)
>>>>
>>>> Ideal Barrier Escrow Implementation (
>>>> https://suredbits.com/payment-points-implementing-barrier-escrows/)
>>>>
>>>> And allowing for Barrier Escrows, we can even have
>>>>
>>>> Atomic multi-payment setup (
>>>> https://suredbits.com/payment-points-and-barrier-escrows/)
>>>>
>>>> Lightning Discreet Log Contract (
>>>> https://suredbits.com/discreet-log-contracts-on-lightning-network/)
>>>>
>>>> Atomic multi-payment update (
>>>> https://suredbits.com/updating-and-transferring-lightning-payments/)
>>>>
>>>> Lightning Discreet Log Contract Novation/Transfer (
>>>> https://suredbits.com/transferring-lightning-dlcs/)
>>>>
>>>> There are likely even more things that can be done with Payment Points
>>>> so make sure to respond if I've missed any known ones.
>>>>
>>>>
>>>> How Do We Get Payment Points?
>>>> -----------------------------
>>>>
>>>> Eventually, once we have Taproot, we can use 2p-Schnorr adaptor
>>>> signatures in Lightning channels. For a detailed thread by ZmnSCPxj, see
>>>> here
>>>> https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-December/002375.html
>>>>
>>>> In the meantime, Lloyd has written about a way to do 1p-ECDSA adaptor
>>>> sigs (https://github.com/LLFourn/one-time-VES) which can be paired
>>>> with OP_CHECKMULTISIG to allows us to execute PTLCs on Bitcoin today!
>>>>
>>>> Nickler has implemented this in a branch of secp256k1 (
>>>> https://github.com/jonasnick/secp256k1/pull/14) and I have implemented
>>>> it in Bouncy Castle in Bitcoin-S with some testing against this branch (
>>>> https://github.com/nkohen/bitcoin-s-core/tree/bouncy-adaptor). Do note
>>>> that as nickler states on his PR, "IT IS EXTREMELY DANGEROUS AND RECKLESS
>>>> TO USE THIS MODULE IN PRODUCTION. DON'T!"
>>>>
>>>> A demo of an on-chain PTLC I executed using nickler's implementation on
>>>> the backend + bitcoin-s can be seen here https://youtu.be/w9o4v7Idjno
>>>>
>>>> And waxwing did a lovely write-up about the crypto itself
>>>> https://joinmarket.me/blog/blog/schnorrless-scriptless-scripts/
>>>>
>>>> I would be very interested in having a fork of (at least) one lightning
>>>> implementation (or Rust Lightning) to be a proof of concept ECDSA-PTLC node
>>>> with which we can test and play with the plethora of PTLC-based proposals
>>>> above.
>>>>
>>>> I believe this would only require a few changes to existing nodes:
>>>>
>>>> 1) update_add_ptlc will have a 32 byte x-coordinate (of a point) rather
>>>> than a 32 byte hash. Additionally the onion's hop_data will contain a 32
>>>> byte scalar tweak for each hop. As per [link multi-hop locks]. The last
>>>> hop_data will instead include a 32 byte scalar equal to the sum of all
>>>> tweaks.
>>>>
>>>> 2) commitment_signed will have 162 byte adaptor ptlc_signatures rather
>>>> than valid (71/72 byte) ECDSA signatures on PTLC-success transactions.
>>>>
>>>> 3) The in-flight outputs on the commitment transaction itself become a
>>>> little simpler as we no longer need to explicitly check the payment
>>>> pre-image against a hash. Instead, delete all instances of "OP_HASH160
>>>> <RIPEMD160(payment_hash)> OP_EQUALVERIFY" in the scripts (leaving the rest
>>>> the same) and require no pre-image in the witness, only a valid signature.
>>>> The pre-image check is implicitly enforced by the <remoteptlc_sig> witness
>>>> since only an adaptor signature was provided by remote so that the payment
>>>> pre-image is required to create the valid signature (from which the
>>>> pre-image can be then deduced by comparing adaptor and valid signatures).
>>>>
>>>> If I've missed any other changes that need to happen, do respond with
>>>> them!
>>>>
>>>> I hope that as a community we can work towards having a PTLC-based
>>>> Lightning Network that is safe and stable as soon as possible, and so I
>>>> encourage further thinking, development and expirementation with PTLCs now
>>>> so that when Taproot is finally at our disposal we can cleanly start moving
>>>> towards a more ideal Lightning :)
>>>>
>>>> Best,
>>>> Nadav
>>>> _______________________________________________
>>>> Lightning-dev mailing list
>>>> Lightning-dev at lists.linuxfoundation.org
>>>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>>>
>>> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200428/e304daeb/attachment-0001.html>

2023-06-09 12:59:13

- reply

📅 Original date posted:2020-03-06
📝 Original message:
> 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.mazumdar1993 at 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&B (on channel AB) : A locks 0.1 BTC, HTLC B&A (on channel BA): B
> locks 0.1 BTC
>
> Pardon me if I am wrong but I am still confused why situation 1 will not
> be possible ?
>
> On Fri, Mar 6, 2020 at 12:00 PM Lloyd Fournier <lloyd.fourn at gmail.com>
> 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.mazumdar1993 at 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 at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>>
>>
>
> --
> Yours sincerely,
> Subhra Mazumdar.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200306/a36dadce/attachment.html>

2023-06-09 12:59:12

- reply

📅 Original date posted:2020-03-06
📝 Original message:
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.mazumdar1993 at 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 <lloyd.fourn at gmail.com>
> 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.mazumdar1993 at 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 at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>>
>>
>
> --
> Yours sincerely,
> Subhra Mazumdar.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200306/d4a9eca8/attachment-0001.html>

2023-06-09 12:59:12

- reply

📅 Original date posted:2020-03-06
📝 Original message:
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.mazumdar1993 at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200306/41465743/attachment.html>

2023-06-09 12:57:44

- reply

📅 Original date posted:2019-12-18
📝 Original message:
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20191218/b966b7d5/attachment-0001.html>

2023-06-09 12:56:36

- reply

📅 Original date posted:2019-10-10
📝 Original message:
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 <nadav at suredbits.com> 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 payment itself: the Escrow in this example
> knows nothing about this payment (other than that some payment exists)
> unless there is a dispute.
>
> Lastly, note that contracts following this scheme look indistinguishable
> to normal payments on the network, and are fully compatible with High AMPs
> since we can simply take the payment point specified by our contract and
> add that point to each partial payment point.
>
> Well this is all nice in theory, but is there anything that will actually
> come out of this thinking? I'll detail the two things I've thought of so
> far for which I'd love critique! I'd also love to hear if anyone else
> things of any cool application using this line of thought (or really
> anything cool with payment points :P).
>
> Idea 1: "MultiSignature" Lightning Contracts
> I mean "MultiSignature" here only in the sense that m-of-n parties must
> agree to the payment in order for it to happen, no actual signatures are
> used. A "MultiSignature" contract is simply a bunch of ANDs and ORs! For
> example a 2-of-3 multisig between parties A, B, and C can be represented as
> (A AND B) OR (B AND C) OR (C AND A). As such, if some seller has a point S
> and three parties have points A, B, and C where a certain payment must go
> through if any two of them think it should, then the payment point used for
> the payment should be S + KE(A + B, B + C, C + A). We add S to this point
> so that the scalar, s, can act as proof of payment. And that's it! I
> haven't thought long enough to come up with any situation where this might
> be useful but hoping someone who reads this will!
>
> 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 believe that this scheme can be extended to more events through the use
> of multiple payments being setup (usually in both directions) but this
> seems complicated and I've rambled for long enough. One last note is that
> DLC oracles can be composed in the usual way under this scheme (by
> addition) and potentially even threshold multi-oracles can be supported in
> this way, although this would require the oracles to attest to some shared
> key's points with other oracles which isn't necessarily optimal.
>
> Best,
> Nadav
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20191011/44faca88/attachment-0001.html>

2023-06-09 12:56:35

- reply

📅 Original date posted:2019-10-10
📝 Original message:
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 at 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 and onward to S,
> conditional on receiving the scalar behind `S + E`.
> * B gives a payment to X conditional on receiving the scalar behind `X +
> E`.
> * X continues to forward the payment, in the target asset, to S.
> * X contacts E and requests for the secret behind `E`.
> * S, on receiving the incoming payment, contacts E and requests for the
> secret behind `E`.
> * As E has now received both requests, it releases the secret
> simultaneously to both branches.
> * S and X can now claim their payments.
>
> Now, I would also like to observe the below fact:
>
> * Proof-of-payment can be reconsidered, under payment point + scalar
> scheme, to be "pay-for-scalar" scheme.
>
> I would also like to point out the below assumption, which underlies Bass
> Amplifier ("multipath payments", "base AMP") and its claim to atomicity:
>
> * If we agree that my secret `s` is worth `m` millisatoshi, then I (as a
> perfectly rational economic agent) will not claim any payments conditional
> on my revelation of `s` that sum up to less than `m` millisatoshi: I will
> only claim *all* of them when I can get multiple payments conditional on my
> revelation of `s` that sum up to `m` millisatoshi or more.
> * I now call this "economically-rational atomicity", and describe also
> them mildly here:
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-March/001109.html
>
> The above is *exactly* the behavior we want E to perform: only if it
> receives both requests to reveal its secret `e` behind `E`, will it
> actually reveal the secret.
> In our case, we turn the requests to E into partial payments of a single
> invoice (though of course, the payment from S to E would be in the asset
> that S wants rather than in Bitcoin).
> E would not like to "sell short" its secret `e` for less than the price of
> its service, thus if E is economically rational, it would only claim
> payments (and reveal `e`) once *all* incoming payments sum up to the price
> of its service.
>
> In particular, the existing High AMP scheme would be reused to implement
> the escrow E, and all that would be needed would be some way to request
> invoices from E!
> No additional code on top of High AMP is needed (very important, being a
> lazy developer is hard work).
> This should help make setting up new Es to be very simple, improving
> competition in this space and helping further ensure economically-rational
> behavior.
>
> If we squint, we can even say that:
>
> * This is actually a payment from B to E.
> * The payment is split into two paths, B->X->E and B->X->S->E.
> * X and S are just being paid surprisingly high fees, and are not in fact
> being paid premiums or payment-for-product/service.
>
> Thus, any argument that we could make, about the safety of Bass Amplifier,
> would also serve as an argument we could make about E behaving as we would
> like it to behave!
> This should greatly reduce the tr\*st requirement from B and X to E: they
> only need to trust that E operates econmically-rationally, and not trust
> that E will, from the goodness of its own heart, operate correctly.
>
> (A remaining issue for the above scheme is that B learns `s + e` and `x +
> e`, not either `s` or `x`, and thus does not actually get full
> proof-of-payment.)
>
>
> Further, this lets us extend this scheme to more than just two
> simultaneous transactions.
> If for example we need to set up 5 simultaneous transactions, and E
> charges 1000 millisatoshi for its service, then we just have each receiver
> forward 200 millisatoshi each to E once their incoming payment has been set
> up.
>
> In fact, the above problem, where B learns `s + e` and `x + e` but not
> either `s` or `x`, could be solved by splitting the payment to E three
> ways, with a third split from B to E, so that B learns `e` and can solve
> `(s + e) - e` == `s` and `(x + e) - e` == `x` to get proof-of-payment for
> both the actual purchase, and the premium charged by the exchange.
>
> In all of these, E remains unaware of the exact details of the
> arrangement, it only cares that it is paid, with the use of High AMP being
> the "coordination
>
>
> Thus this scheme is surprisingly flexible, and may solve more problems
> than you might think.
> Thank you for this insight, Nadav!
>
> Regards,
> ZmnSCPxj
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20191011/0c0cc4f2/attachment.html>

2023-06-09 12:56:26

- reply

📅 Original date posted:2019-10-06
📝 Original message:
Hi Thread,
I made a reply to the OP but didn't "reply all" so it just went directly to
Ethan. Since the comments were interesting I'll attempt to salvage them by
posting them in full:
== Lloyd's post ==
Hi Ethan,
I'd be interested to know what protocols you need OP_CAT for. I'm trying to
figure out if there really exists any script based protocol that doesn't
have a more efficient scriptless counterpart. For example,
A²L[1] achieves the same thing as Tumblebit but requires no script. I can
imagine paying based on a merkle path could be useful, but a protocol was
recently suggested on lightning-dev [2] that does this but without OP_CAT
(and without any script!).
[1] https://eprint.iacr.org/2019/589.pdf
[2]
https://www.mail-archive.com/lightning-dev@lists.linuxfoundation.org/msg01427.html
(*I linked to the wrong thread in the original email*).
LL
== Ethan's response ==
Hi Lloyd,
Thanks for your response. I am not sure if you intended to take this off
list or not.
I plan to at some point to enumerate in detail protocols that OP_CAT would
benefit. A more important point is that OP_CAT is a basic building block
and that we don't know what future protocols it would allow. In my own
research I have avoiding going down certain paths because it isn't worth
the time to investigate knowing that OP_CAT wouldn't make the protocol
practical.
In regards to scriptless scripts they almost always require an interactive
protocol and sometimes ZKPs. A2L is very impressive but like TumbleBit it
places a large burden on the developer. Additionally I am aware of no way
to reveal a subset of preimages with scriptless scripts, do a conditioned
reveal i.e. these preimages can only spend under these two pubkeys and
timelockA where after timelockZ this other pubkey can spend without a
preimages. Scriptless scripts are a fantastic tool but they shouldn't be
the only tool that we have.
I'm not sure I follow what you are saying with [2]
This brings me back a philosophical point:
Bitcoin should give people basic tools to build protocols without first
knowing what all those protocols are especially when those tools have very
little downside.
I really appreciate your comments.
Thanks,
Ethan
==
*Back to normal thread*
Hi Ethan,
Thanks for the insightful reply and sorry for my mailing list errors.
> I plan to at some point to enumerate in detail protocols that OP_CAT
would benefit.
Sweet. Thanks.
> Additionally I am aware of no way to reveal a subset of preimages with
scriptless scripts, do a conditioned reveal i.e. these preimages can only
spend under these two pubkeys and timelockA where after timelockZ this
other pubkey can spend without a preimages. Scriptless scripts are a
fantastic tool but they shouldn't be the only tool that we have.
Yes. With adaptor signatures there is no way to reveal more than one
pre-image; you are limited to revealing a single scalar. But you can have
multiple transactions spending from the same output, each with a different
set of scriptless conditions (absolute time locks, relative time locks and
pre-image reveal). This is enough to achieve what I think you are
describing. FWIW there's a growing consensus that you can do lightning
without script [1]. Perhaps we can't do everything with this technique. My
current focus is figuring out what useful things we can't do like this
(even if we were to go wild and add whatever opcodes we wanted). So far it
looks like covenants are the main exception.
> I'm not sure I follow what you are saying with [2]
That is perfectly understandable as I linked the wrong thread (sorry!).
Here's the right one:
https://www.mail-archive.com/lightning-dev@lists.linuxfoundation.org/msg01427.html
I was pointing to the surprising result that you can actually pay for a
merkle path with a particular merkle root leading to a particular leaf that
you're interested in without validating the merkle path on chain (e.g.
OP_CAT and OP_SHA256). The catch is that the leaves have to be pedersen
commitments and you prove the existence of your data in the merkle root by
showing an opening to the leaf pedersen commitment. This may not be general
enough to cover every merkle tree use case (but I'm not sure what those
are!).
> This brings me back a philosophical point:
> Bitcoin should give people basic tools to build protocols without first
knowing what all those protocols are especially when those tools have very
little downside.
This is a really powerful idea. But I've started feeling like you have to
just design the layer 2 protocols first and then design layer 1! It seems
like almost every protocol that people want to make requires very
particular fundamental changes: SegWit for LN-penalty and NOINPUT for eltoo
for example. On top of that it seems like just having the right signature
scheme (schnorr) at layer 1 is enough to enable most useful stuff in an
elegant way.
[1]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-September/017309.html
Cheers,
LL
On Fri, Oct 4, 2019 at 1:08 AM Ethan Heilman <eth3rs at gmail.com> wrote:
> To avoid derailing the NO_INPUT conversation, I have changed the
> subject to OP_CAT.
>
> Responding to:
> """
> * `SIGHASH` flags attached to signatures are a misdesign, sadly
> retained from the original BitCoin 0.1.0 Alpha for Windows design, on
> par with:
> [..]
> * `OP_CAT` and `OP_MULT` and `OP_ADD` and friends
> [..]
> """
>
> OP_CAT is an extremely valuable op code. I understand why it was
> removed as the situation at the time with scripts was dire. However
> most of the protocols I've wanted to build on Bitcoin run into the
> limitation that stack values can not be concatenated. For instance
> TumbleBit would have far smaller transaction sizes if OP_CAT was
> supported in Bitcoin. If it happens to me as a researcher it is
> probably holding other people back as well. If I could wave a magic
> wand and turn on one of the disabled op codes it would be OP_CAT. Of
> course with the change that size of each concatenated value must be 64
> Bytes or less.
>
>
> On Tue, Oct 1, 2019 at 10:04 PM ZmnSCPxj via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> >
> > Good morning lists,
> >
> > Let me propose the below radical idea:
> >
> > * `SIGHASH` flags attached to signatures are a misdesign, sadly retained
> from the original BitCoin 0.1.0 Alpha for Windows design, on par with:
> > * 1 RETURN
> > * higher-`nSequence` replacement
> > * DER-encoded pubkeys
> > * unrestricted `scriptPubKey`
> > * Payee-security-paid-by-payer (i.e. lack of P2SH)
> > * `OP_CAT` and `OP_MULT` and `OP_ADD` and friends
> > * transaction malleability
> > * probably many more
> >
> > So let me propose the more radical excision, starting with SegWit v1:
> >
> > * Remove `SIGHASH` from signatures.
> > * Put `SIGHASH` on public keys.
> >
> > Public keys are now encoded as either 33-bytes (implicit `SIGHASH_ALL`)
> or 34-bytes (`SIGHASH` byte, followed by pubkey type, followed by pubkey
> coordinate).
> > `OP_CHECKSIG` and friends then look at the *public key* to determine
> sighash algorithm rather than the signature.
> >
> > As we expect public keys to be indirectly committed to on every output
> `scriptPubKey`, this is automatically output tagging to allow particular
> `SIGHASH`.
> > However, we can then utilize the many many ways to hide public keys away
> until they are needed, exemplified in MAST-inside-Taproot.
> >
> > I propose also the addition of the opcode:
> >
> > <sighash> <pubkey> OP_SETPUBKEYSIGHASH
> >
> > * `sighash` must be one byte.
> > * `pubkey` may be the special byte `0x1`, meaning "just use the Taproot
> internal pubkey".
> > * `pubkey` may be 33-byte public key, in which case the `sighash` byte
> is just prepended to it.
> > * `pubkey` may be 34-byte public key with sighash, in which case the
> first byte is replaced with `sighash` byte.
> > * If `sighash` is `0x00` then the result is a 33-byte public key (the
> sighash byte is removed) i.e. `SIGHASH_ALL` implicit.
> >
> > This retains the old feature where the sighash is selected at
> time-of-spending rather than time-of-payment.
> > This is done by using the script:
> >
> > <pubkey> OP_SETPUBKEYSIGHASH OP_CHECKSIG
> >
> > Then the sighash can be put in the witness stack after the signature,
> letting the `SIGHASH` flag be selected at time-of-signing, but only if the
> SCRIPT specifically is formed to do so.
> > This is malleability-safe as the signature still commits to the
> `SIGHASH` it was created for.
> >
> > However, by default, public keys will not have an attached `SIGHASH`
> byte, implying `SIGHASH_ALL` (and disallowing-by-default non-`SIGHASH_ALL`).
> >
> > This removes the problems with `SIGHASH_NONE` `SIGHASH_SINGLE`, as they
> are allowed only if the output specifically says they are allowed.
> >
> > Would this not be a superior solution?
> >
> > Regards,
> > ZmnSCPxj
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20191006/f0e27c02/attachment-0001.html>

2023-06-09 12:56:13

- reply

📅 Original date posted:2019-09-25
📝 Original message:
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 <aj at erisian.com.au> wrote:
> On Wed, Sep 25, 2019 at 01:30:39PM +0000, 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190926/16f52927/attachment.html>

2023-06-09 12:55:38

- reply

📅 Original date posted:2019-07-17
📝 Original message:
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 <nadav at suredbits.com> 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190718/52d55a92/attachment.html>

2023-06-09 12:55:38

- reply

📅 Original date posted:2019-07-17
📝 Original message:
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 <nadav at suredbits.com> 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 <lloyd.fourn at gmail.com>
> 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 <nadav at suredbits.com> 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 at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190718/7d81834a/attachment.html>

2023-06-09 12:55:26

- reply

📅 Original date posted:2019-07-17
📝 Original message:
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.thyfronitis at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190718/06565966/attachment-0001.html>

2023-06-09 12:54:57

- reply

📅 Original date posted:2019-05-19
📝 Original message:
Hi ZmnSCPxj,
Sorry for the late reply I only recently had time to review your comments.
I didn't really get your motivation for multiple secrets. In my mind,
having the last hop put collateral into the HTLC to make a *Collateralized
HTLC* solves the problem without any extra complexity (your original
example captures this perfectly). You wrote:
The exchange can insist on getting a short timelock for receiving the
> collateral (i.e. limit the time horizon that the exchange hash is valid),
> to reduce the time horizon in which the payee can pay or not pay the
> collateral for the exchange (as before the payee releases the collateral,
> it still has the option of doing or not doing the swap, i.e. American
> Option).
I think this unnecessary. The "free option" time isn't limited by a
timelock (if it was, we wouldn't have solved the problem). The option is
limited by the exchange's willingness to wait for the other party to sign
the state update (assuming the exchange signs first). The minor point I was
trying to make was that normally when routing payments etc you can be
willing to wait for minutes or hours for the other party to come back
online if they went offline during a state update. But if you are doing a
swap and your partner is meant to be signing a collateralized HTLC you
shouldn't wait; you should force settlement to the blockchain within a few
seconds. As soon as the state gets onto the blockchain the other party has
lost any chance of getting an option.
At a glance, the simplest way to enable this functionality is to add a new
field to the "update_add_htlc" BOLT message [1] like
"collateral_amount_sat". The receiver of "collateral_amount_sat" would have
to contribute that amount to the HTLC (if they are willing to go through
with the update). Obviously you should only ever agree to do this if you
are last hop or are willing to risk your collateral on the honest behaviour
of nodes further down.
I was actually wondering if this could be a useful feature outside of
swaps. e.g. if there is a new node without much reputation who you are
routing a payment to, you could demand that they put up collateral into the
HLTC to receive the payment. This might help prevent attacks where people
try and tie up funds by receiving large payments they never release the
secrets for.
WRT to your final comments, it sounds a bit like [2] which also mentions
that their protocol can make atomic swaps fungible.
1.
https://github.com/lightningnetwork/lightning-rfc/blob/master/02-peer-protocol.md#adding-an-htlc-update_add_htlc
2. Anonymous Multi-Hop Locks for Blockchain Scalability and
Interoperability: https://eprint.iacr.org/2018/472.pdf
Cheers,
Lloyd
On Mon, May 6, 2019 at 2:51 PM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
> Good morning Lloyd,
>
> I think the most generic solution is to require multiple hashlocks.
> One hashlock for the payee, the other for the exchange.
>
> Payer acquires an exchange hash from the exchange, plus specs of the
> collateral.
> Then payer routes to the payee via the exchange using two hashlocks
> (hashlock for the payment hash, hashlock for the exchange hash) and from
> the payee to the exchange.
> The exchange onion hop includes the information that the cross-currency
> swap is allowed by pointing at the hashlock that the exchange hash is on.
> The exchange verifies that it is one of the exchange hashes it has issued
> and it releases the agreed amount to the next hop, plus the collateral
> agreed upon.
>
> The payee onion hop includes the information that it should proceed to
> give a single hashlock to succeeding hops, as well as the agreed-upon
> collateral to the exchange.
> The exchange receives the payment with a single hashlock containing the
> value of the collateral.
> It verifies that the collateral value is equal to the agreed collateral
> for that payment, then releases the exchange preimage.
> The payee can then release its preimage once it has acquired the exchange
> preimage.
>
> The above is similar to your solution, as it effectively means the payee
> offers collateral to the exchange, which it can only reclaim by properly
> completing the payment protocol.
> The exchange can insist on getting a short timelock for receiving the
> collateral (i.e. limit the time horizon that the exchange hash is valid),
> to reduce the time horizon in which the payee can pay or not pay the
> collateral for the exchange (as before the payee releases the collateral,
> it still has the option of doing or not doing the swap, i.e. American
> Option).
> The advantage is that it can go over multiple hops, and the exchange and
> payee do not know each other (but the payer does).
> Disadvantage is that it requires two hashlocks, which is rather obvious on
> the protocol and signals "this payment is a cross-currency exchange
> 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 <lloyd.fourn at gmail.com>
> 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 at 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 1000000000 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 1000000000 WJT from you, and
> 100000000 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 at lists.linuxfoundation.org
> > > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190519/b8ffbfb6/attachment-0001.html>

2023-06-09 12:54:57

- reply

📅 Original date posted:2019-05-04
📝 Original message:
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 at 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 1000000000 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 1000000000 WJT from you, and
> 100000000 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190504/e1b48144/attachment.html>

2023-06-09 12:53:45

- reply

📅 Original date posted:2019-01-05
📝 Original message:
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 at 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 <dave at dtrt.org>
> wrote:
>
> > On Thu, Dec 27, 2018 at 05:43:51AM +0000, 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 path to look like:
> >
> > Alice Bob Charlie Dan Eliza
> > 1.3 mBTC -> 1.3 mBTC -> 1.2 mBTC
> >
> > 1.2 mWJT -> 1.1 mWJT -> 1.0 mWJT
> >
> >
> > 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.
> >
> > 1. When this payment reaches the exchanger, Charlie, he checks that the
> > payment includes a hashlock he controls before routing the payment
> on to
> > a different asset.
> >
> > 2. When the payment reaches receiver Eliza's node, she releases her
> > PreImage (PI0) back along the path.
> >
> > 3. When Eliza's preimage reaches exchanger Charlie's node, he releases
> > his preimage (PI1) in both directions along the path and continues
> > forwarding PI0 backwards. Eventually everyone receives both preimages
> > through the usual offchain or onchain mechanisms.
> >
> > Alice Bob Charlie Dan Eliza
> > PI0 <- PI0 <- PI0 <- PI0 <- PI0 (start here)
> > PI1 <- PI1 <- PI1 -> PI1 -> PI1
> >
> >
> > However, if the exchange rate changes too much for Charlie's comfort
> > before both preimages have been released, Charlie can unilaterally
> > decide to cancel the payment by simply not releasing his preimage.
> >
> > Note that by making the payment contingent on the approval of the
> > exchanger, the ability to create an underhanded call option is
> > transferred to the exchanger. However, this may be less concerning
> > because the exchanger can only keep this option open by refusing to
> > immediately claim the routing fees.
> >
> > For example, our exchanger Charlie is being offered 0.1 mBTC to route
> > the payment (a made up number). If he can route 100 such payments in a
> > day (another made up number), he can earn 10.0 mBTC from routing. By
> > comparison, if he delays a payment of 1.2 mBTC, he'd need to expect the
> > exchange rate to change by an order of magnitude within a day to earn
> > the same amount. In ZmnSCPxj's terminology, the option is now no longer
> > free because Charlie must decide between potential routing income and
> > potential option income. Whether or not exchangers play the option game
> > will therefore likely be based on the amount of honest routing income
> > they can earn relative to the exchange rate volatility (and also on how
> > good nodes get at tracking reliable routes).
> >
> > This idea certainly complicates the current protocol (both routing and
> > transaction construction), but maybe there are simplifications
> > available.
> >
> > -Dave
>
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190105/3dc2a953/attachment-0001.html>

2023-06-09 12:53:41

- reply

📅 Original date posted:2019-01-02
📝 Original message:
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 different
asset-type/party combinations. This would allow you to buy an amount of the
desired asset in one of your channels by simply doing a state update where
you lose `A` in exchange for `B` with your direct peer (no HTLCs needed).
You can then just send `B` normally to the receiver. This is not quite as
good as a cross asset payment but it could still be useful*.
Quite simply, if you want to send someone asset `A` but they want to
receive asset `B` then just buy asset `B` with asset `A` and then send `B`
to them!
*I don't know much about non-native assets on Bitcoin and their suggested
integration with LN so I'm just guessing here.
All the best for 2019,
Lloyd
\n
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190102/5adacabb/attachment-0001.html>

- reply

- reply

- reply

- reply

- reply

- reply

- reply

- reply

- reply

- reply

- reply

📅 Original date posted:2023-05-11
🗒️ Summary of this message: Two developers discuss the usefulness of single signer adaptors in Bitcoin transactions, with one arguing they can be useful for revealing secrets in certain situations.
📝 Original message:On Thu, 11 May 2023 at 13:12, AdamISZ <AdamISZ at protonmail.com> wrote:
>
> A sidebar, but it immediately brings it to mind: the canonical adaptor
> based swap, you can do it with only one half being multisig like this,
> right? Alice can encrypt the single-key signature for her payment to Bob,
> with the encryption key being T= sG, where s is the partial signature of
> Bob, on the payout from a multisig, to Alice. That way Bob only gets his
> money in the single sig (A->B) tx, if he reveals his partial sig on the
> multisig. I don't think it's of practical interest (1 multisig instead of
> 2? meh), but .. I don't see anywhere that potential variant being written
> down? Is there some obvious flaw with that?
>
I think the problem is that Alice can still move the funds even if Bob
decrypts and broadcasts by revealing s if she gets confirmed first. I think
you always need a multisig in these kinds of situations but it need not be
a key aggregated multisig like MuSig -- this was the point I wanted to make
(in retrospect clumsily). I don't think I can name a useful use of a single
signer adaptor signature in Bitcoin at least not without some kind of other
spending constraint. So your intuitive point holds in practice most of the
time.
LL
Cheers,
> waxwing/AdamISZ
>
> Sent with Proton Mail <https://proton.me/> secure email.
>
> ------- Original Message -------
> On Monday, May 8th, 2023 at 05:37, Lloyd Fournier via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Hi Waxwing,
>
> On Tue, 2 May 2023 at 02:37, AdamISZ <AdamISZ at protonmail.com> wrote:
>
>> Hi Lloyd,
>> thanks for taking a look.
>>
>> > I think your view of the uselessness of single signer adaptors is too
>> pessimistic. The claim you make is that they "don't provide a way to create
>> enforcement that the publication of signature on a pre-defined message will
>> reveal a secret'' and so are useless. I think this is wrong. If I hold a
>> secret key for X and create a signature adaptor with some encryption key Y
>> with message m and do not create any further signatures (adaptor or
>> otherwise) on m, then any signature on m that is published necessarily
>> reveals the secret on Y to me. This is very useful and has already been
>> used for years by DLCs in production.
>>
>> I'm struggling with this one - say I hold privkey x for pubkey X. And I
>> publish adaptor for a point Y (DL y) for message m, like: s' = k - y +
>> H(R|X|m)x with k the nonce and R the nonce point.
>>
>> And to get the basics clear first, if I publish s = k + H(R|X|m)x then of
>> course the secret y is revealed.
>>
>> What do you mean in saying "any signature on m that is published reveals
>> y"? Clearly you don't mean any signature on any key (i.e. not the key X).
>> But I also can't parse it if you mean "any signature on m using key X",
>> because if I go ahead and publish s = k_2 + H(R_2|X|m)x, it has no
>> algebraic relationship to the adaptor s' as defined above, right?
>>
>
> Yes but suppose you do *not* create another signature adaptor or otherwise
> on m. Since you've only generated one adaptor signature on m and no other
> signatures on m there is no possibility that a signature on m that appears
> under your key would not reveal y to you. This is an useful property in
> theory and in practice.
>
>
>> I think the point of confusion is maybe about the DLC construct? I
>> referenced that in Section 4.2, parenthetically, because it's analogous in
>> one sense - in MuSig(2) you're fixing R via a negotiation, whereas in
>> Dryja's construct you're fixing R "by definition". When I was talking about
>> single key Schnorr, I was saying that's what's missing, and thereby making
>> them useless.
>>
>> I was not referencing the DLC oracle attestation protocol - I am pointing
> out that DLC client implementations have been using single signer adaptor
> signatures as signature encryption in practice for years for the
> transaction signatures. There are even channel implementations using them
> as well as atomic swaps doing this iirc. It's a pretty useful thing!
>
> Cheers,
>
> LL
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230511/d9dce7e2/attachment-0001.html>

2023-06-07 23:21:02

- reply

📅 Original date posted:2023-05-08
🗒️ Summary of this message: A discussion on the usefulness of single signer adaptors in Bitcoin transactions, with one participant arguing they can reveal a secret and have been used in production for years.
📝 Original message:Hi Waxwing,
On Tue, 2 May 2023 at 02:37, AdamISZ <AdamISZ at protonmail.com> wrote:
> Hi Lloyd,
> thanks for taking a look.
>
> > I think your view of the uselessness of single signer adaptors is too
> pessimistic. The claim you make is that they "don't provide a way to create
> enforcement that the publication of signature on a pre-defined message will
> reveal a secret'' and so are useless. I think this is wrong. If I hold a
> secret key for X and create a signature adaptor with some encryption key Y
> with message m and do not create any further signatures (adaptor or
> otherwise) on m, then any signature on m that is published necessarily
> reveals the secret on Y to me. This is very useful and has already been
> used for years by DLCs in production.
>
> I'm struggling with this one - say I hold privkey x for pubkey X. And I
> publish adaptor for a point Y (DL y) for message m, like: s' = k - y +
> H(R|X|m)x with k the nonce and R the nonce point.
>
> And to get the basics clear first, if I publish s = k + H(R|X|m)x then of
> course the secret y is revealed.
>
> What do you mean in saying "any signature on m that is published reveals
> y"? Clearly you don't mean any signature on any key (i.e. not the key X).
> But I also can't parse it if you mean "any signature on m using key X",
> because if I go ahead and publish s = k_2 + H(R_2|X|m)x, it has no
> algebraic relationship to the adaptor s' as defined above, right?
>
Yes but suppose you do *not* create another signature adaptor or otherwise
on m. Since you've only generated one adaptor signature on m and no other
signatures on m there is no possibility that a signature on m that appears
under your key would not reveal y to you. This is an useful property in
theory and in practice.
>
> I think the point of confusion is maybe about the DLC construct? I
> referenced that in Section 4.2, parenthetically, because it's analogous in
> one sense - in MuSig(2) you're fixing R via a negotiation, whereas in
> Dryja's construct you're fixing R "by definition". When I was talking about
> single key Schnorr, I was saying that's what's missing, and thereby making
> them useless.
>
>
I was not referencing the DLC oracle attestation protocol - I am pointing
out that DLC client implementations have been using single signer adaptor
signatures as signature encryption in practice for years for the
transaction signatures. There are even channel implementations using them
as well as atomic swaps doing this iirc. It's a pretty useful thing!
Cheers,
LL
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230508/3bfa2b54/attachment-0001.html>

2023-06-07 23:21:00

- reply

📅 Original date posted:2023-05-01
🗒️ Summary of this message: A new analysis on the security of using signature adaptors for multiparty swaps has been posted on GitHub, focusing on scenarios of multiple adaptors at once or multiple signing sessions at once with the same adaptor. The analysis is based on MuSig and not MuSig2.
📝 Original message:Hi waxwing,
I think your view of the uselessness of single signer adaptors is too
pessimistic. The claim you make is that they "don't provide a way to
create enforcement that the publication of signature on a pre-defined
message will reveal a secret'' and so are useless. I think this is wrong.
If I hold a secret key for X and create a signature adaptor with some
encryption key Y with message m and do not create any further signatures
(adaptor or otherwise) on m, then any signature on m that is published
necessarily reveals the secret on Y to me. This is very useful and has
already been used for years by DLCs in production.
I haven't read the proofs in detail but I am optimistic about your
approach. One thing I was considering while reading is that you could make
a general proof against all secure Schnorr signing scheme in the ROM by
simply extending the ROM forwarding approach from Aumayer et al to all
"tweak" operations on the elements that go into the Schnorr challenge hash
i.e. the public key and the nonce. After all whether it's MuSig2, MuSig,
FROST they all must call some RO. I think we can prove that if we apply any
bijective map to the (X,R) tuple before they go into the challenge hash
function then any Schnorr-like scheme that was secure before will be secure
when bip32/TR tweaking (i.e. tweaking X) and adaptor tweaking (tweaking R)
is applied to it. This would be cool because then we could prove all these
variants secure for all schemes past and present in one go. I haven't got a
concrete approach but the proofs I've looked at all seem to share this
structure.
Cheers,
LL
On Sun, 30 Apr 2023 at 00:20, AdamISZ via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hi list,
> I was motivated to look more carefully at the question of the security of
> using signature adaptors after recently getting quite enthused about the
> idea of using adaptors across N signing sessions to do a kind of multiparty
> swap. But of course security analysis is also much more important for the
> base case of 2 party swapping, which is of .. some considerable practical
> importance :)
>
> There is work (referenced in Section 3 here) that's pretty substantial on
> "how secure are adaptors" (think in terms of security reductions) already
> from I guess the 2019-2021 period. But I wanted to get into scenarios of
> multiple adaptors at once or multiple signing sessions at once with the
> *same* adaptor (as mentioned above, probably this is the most important
> scenario).
>
> To be clear this is the work of an amateur and is currently unreviewed -
> hence (a) me posting it here and (b) putting the paper on github so people
> can easily add specific corrections or comments if they like:
>
> https://github.com/AdamISZ/AdaptorSecurityDoc/blob/main/adaptorsecurity.pdf
>
> I'll note that I did the analysis only around MuSig, not MuSig2.
>
> The penultimate ("third case"), that as mentioned, of "multiple signing
> sessions, same adaptor" proved to be the most interesting: in trying to
> reduce this to ECDLP I found an issue around sequencing. It may just be
> irrelevant but I'd be curious to hear what others think about that.
>
> If nothing else, I'd be very interested to hear what experts in the field
> have to say about security reductions for this primitive in the case of
> multiple concurrent signing sessions (which of course has been analyzed
> very carefully already for base MuSig(2)).
>
> Cheers,
> AdamISZ/waxwing
>
>
>
>
> Sent with Proton Mail secure email.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230501/5c70f1ea/attachment.html>

2023-06-07 23:19:24

- reply

📅 Original date posted:2023-02-07
🗒️ Summary of this message: An attack on Taproot/Multi-Asset Script Transactions (MAST) allows the last input to use a larger signature to extract a fee from other parties, stealing fees from Alice et al. Mitigations include negotiating a lower feerate, enforcing a minimum weight before signing, or using a trusted coordinator.
📝 Original message:Hi Yuval,
This is an interesting attack. Usually I think of spending with a big
weight witness in the context of slowing down a confirmation of a
transaction, especially a DLC creation tx. There you can delay its
confirmation past some time (i.e. see if your team won the game, and then
either trying to confirm it by providing the slimmed down witness or double
cancelling it by double spending). In this case you are not trying to delay
it but to dilute your portion of the fee.
Another mitigation is to aggresively RBF double spend your input any time a
counterparty doesn't use the spending path they said they would and don't
deal with them again. Of course, various pinning attacks may prevent this
depending on how your joint tx is structured.
LL
On Tue, 7 Feb 2023 at 13:59, Yuval Kogman via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> ## Summary
>
> Since Taproot (more generally any kind of MAST) spends have variable size
> which
> depends on the path being used, the last such input to be signed in a
> multiparty
> transaction can always use a larger than estimated signature to unfairly
> extract
> a fee contribution from the other parties to the transaction (keeping the
> absolute fees the same and reducing the feerate for the transaction).
>
> ## Attack Scenario
>
> Alice et al wish to perform a multiparty transaction, such as a CoinJoin or
> lightning dual funding at a relatively high feerate.
>
> Mallory has a P2TR output with a large script spend path, e.g. an ordinal
> inscription commitment transaction output.
>
> Mallory registers this coin as an input into the multiparty transaction
> with a
> fee obligation calculated on the basis of a key spend. When all other
> participants have provided signatures, the script spend path can be used.
>
> Since the absolute fee amount is already committed to by the provided
> (`SIGHASH_ALL`) signatures but the total transaction weight is not,
> Mallory can
> broadcast any valid signatures up to the maximum standard weight and
> minimum
> relay fees, or in collusion with a miner, up to consensus limits.
>
> This effectively steals a fee from Alice et al, as their signatures do not
> commit to a feerate directly or indirectly.
>
> ## Mitigations
>
> ### RBF
>
> All parties could negotiate a (series of) transaction(s) ahead of time at a
> lower feerate, giving a lower bound minimum feerate that Mallory can force.
>
> ### Minimum Weight Before Signing
>
> Enforcing a minimal weight for all non-witness data in the transaction
> before
> the transaction is considered fully constructed can limit the
> effectiveness of
> this attack, since the difference between the predicted weight and the
> maximum
> weight decreases.
>
> ### Trusted Coordinator
>
> In the centralized setting if BIP-322 ownership proofs are required for
> participation and assuming the server can be trusted not to collude with
> Mallory, the server can reject signatures that do not exercise the same
> spend
> path as the ownership proof, which makes the ownership proof a commitment
> to the
> spend weight of the input.
>
> ### Reputation
>
> Multiparty protocols with publicly verifiable protocol transcripts can be
> provided as weak evidence of a history of honest participation in
> multiparty
> transactions.
>
> A ring signature from keys used in the transaction or its transcript
> committing
> to the new proposed transaction can provide weak evidence for the honesty
> of the
> peer.
>
> Such proofs are more compelling to an entity which has participated in
> (one of)
> the transcripts, or proximal transactions. Incentives are theoretically
> aligned
> if public coordinators publish these transcripts as a kind of server
> reputation.
>
> ### Increasing Costliness
>
> A minimum feerate for the previous transaction or a minimum confirmation
> age
> (coindays destroyed implies time value, analogous to fidelity bonds) can be
> required for inputs to be added, in order to make such attacks less
> lucrative
> (but there is still a positive payoff for the attacker).
>
> ### Signature Ordering
>
> Signatures from potentially exploitative inputs can be required ahead of
> legacy
> or SegWit v0 ones. The prescribed order can be determined based on
> reputation or
> costliness as described in the previous paragraphs.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230207/95202031/attachment.html>

2023-06-07 23:08:56

- reply

📅 Original date posted:2022-05-03
📝 Original message:Hi Vjudeu,
Perhaps this could make sense in some setting. e.g. instead of a hardware
device which protects your secret key via pin you use a pinless device but
you create a strong password and use a proper password hash to create
another key and put them in a 2-of-2. But make sure you don't use sha256 to
hash the password. Use a proper password hash. Keep in mind there's also
bip39 passwords which do a similar but this does involve entering them into
the possibly malicious hardware device.
Cheers,
LL
On Mon, 2 May 2022 at 03:56, vjudeu via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> It seems that Taproot allows us to protect each individual public key with
> a password. It could work in this way: we have some normal, Taproot-based
> public key, that is generated in a secure and random way, as it is today in
> Bitcoin Core wallet. Then, we can create another public key, just by taking
> password from the user, executing SHA-256 on that, and using it as a
> private key, so the second key will be just a brainwallet. Then, we can
> combine them in a Schnorr signature, forming 2-of-2 multisig, where the
> first key is totally random, and the second key is just a brainwallet that
> takes a password chosen by the user. By default, each key can be protected
> with the same password, used for the whole wallet, but it could be possible
> to choose different passwords for different addresses, if needed.
> Descriptors should handle that nicely, in the same way as they can be used
> to handle any other 2-of-2 multisig.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220504/f39b25f0/attachment.html>

2023-06-07 23:07:09

- reply

📅 Original date posted:2022-04-09
📝 Original message:Hey all,
A good first step might be to express this as a research problem on
bitcoinproblems.org! I've had in mind creating a problem page on how to
design a PQ TR commitment in each key so that if QC were to become a
reality we could softfork to enable that spend (and disable normal key path
spends):
https://github.com/bitcoin-problems/bitcoin-problems.github.io/issues/4
Becoming the author/maintainer of this problem is as simple as making a PR
to the repo. The problem doesn't have to be focused on a TR solution but
could be a general description of the problem with that and others as a
potential solution direction.
Cheers,
LL
On Sat, 9 Apr 2022 at 18:39, Christopher Allen via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>
> On Fri, Apr 8, 2022 at 4:33 PM Christopher Allen <
> ChristopherA at lifewithalacrity.com> wrote:
>
>> That being said, it is interesting research. Here is the best link about
>> this particular approach:
>>
>> https://ntruprime.cr.yp.to/software.html
>>
>
> Also I think this is the original academic paper:
>
> https://eprint.iacr.org/2021/826.pdf
>
> <https://ntruprime.cr.yp.to/software.html>
>>
> — Christopher Allen _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220410/e3a818db/attachment.html>

2023-06-07 23:03:49

- reply

📅 Original date posted:2022-02-06
📝 Original message:Hi Jeremy,
On Sat, 29 Jan 2022 at 04:21, Jeremy <jlrubin at mit.edu> wrote:
> Lloyd,
>
> This is an excellent write up, the idea and benefits are clear.
>
> Is it correct that in the case of a 3/5th threshold it is a total 10x *
> 30x = 300x improvement? Quite impressive.
>
Yes I think so but I am mostly guessing these numbers. The improvement is
several orders of magnitude. Enough to make almost any payout curve
possible without UX degredation I think.
> I have a few notes of possible added benefits / features of DLCs with CTV:
>
> 1) CTV also enables a "trustless timeout" branch, whereby you can have a
> failover claim that returns funds to both sides.
>
> There are a few ways to do this:
>
> A) The simplest is just an oracle-free <STH(timeout tx)> CTV whereby the
> timeout transaction has an absolute/relative timelock after the creation of
> the DLC in question.
>
> B) An alternative approach I like is to have the base DLC have a branch
> `<STH(begin timeout)> CTV` which pays into a DLC that is the exact same
> except it removes the just-used branch and replaces it with `<STH(timeout
> tx)> CTV` which contains a relative timelock R for the desired amount of
> time to resolve. This has the advantage of always guaranteeing at least R
> amount of time since the Oracles have been claimed to be non-live to
> "return funds" to parties participating
>
>
> 2) CTV DLCs are non-interactive asynchronously third-party unilaterally
> creatable.
>
> What I mean by this is that it is possible for a single party to create a
> DLC on behalf of another user since there is no required per-instance
> pre-signing or randomly generated state. E.g., if Alice wants to create a
> DLC with Bob, and knows the contract details, oracles, and a key for Bob,
> she can create the contract and pay to it unilaterally as a payment to Bob.
>
> This enables use cases like pay-to-DLC addresses. Pay-to-DLC addresses can
> also be constructed and then sent (along with a specific amount) to a third
> party service (such as an exchange or Lightning node) to create DLCs
> without requiring the third party service to do anything other than make
> the payment as requested.
>
This is an interesting point -- I hadn't thought about interactivity prior
to this.
I agree CTV makes possible an on-chain DEX kind of thing where you put in
orders by sending txs to a DLC address generated from a maker's public key.
You could cancel the order by spending out of it via some cancel path. You
need to inform the maker of (i) your public key (maybe you can use the
same public key as one of the inputs) and (ii) the amount the maker is
meant to put in (use fixed denominations?).
Although that's cool I'm not really a big fan of "putting the order book
on-chain" ideas because it brings up some of the problems that EVM DEXs
have.
I like centralized non-custodial order books.
For this I don't think that CTV makes a qualitative improvement given we
can use ANYONECANPAY to get some non-interactivity.
For example here's an alternative design:
The *taker* provides a HTTP REST api where you (a maker) can:
1. POST an order using SIGHASH_ANYONECANPAY signed inputs and contract
details needed to generate the single output (the CTV DLC). The maker can
take the signatures and complete the transaction (they need to provide an
exact input amount of course).
2. DELETE an order -- the maker does some sort of revocation on the DLC
output e.g. signs something giving away all the coins in one of the
branches. If a malicious taker refuses to delete you just double spend one
of your inputs.
If the taker wants to take a non-deleted order they *could* just finish the
transaction but if they still have a connection open with the maker then
they could re-contact them to do a normal tx signing (rather than useing
the ANYONECANPAY signatures).
The obvious advantage here is that there are no transactions on-chain
unless the order is taken.
Additionally, the maker can send the same order to multiple takers -- the
takers will cancel each other's transactions should they broadcast the
transactions.
Looking forward to see if you can come up with something better than this
with CTV.
The above is suboptimal as getting both sides to have a change output is
hard but I think it's also difficult in your suggestion.
It might be better to use SIGHASH_SINGLE + ANYONECANPAY so the maker has to
be the one to provide the right input amount but the taker can choose their
change output and the fee...
>
> 3) CTV DLCs can be composed in interesting ways
>
> Options over DLCs open up many exciting types of instrument where Alice
> can do things like:
> A) Create a Option expiring in 1 week where Bob can add funds to pay a
> premium and "Open" a DLC on an outcome closing in 1 year
> B) Create an Option expiring in 1 week where one-of-many Bobs can pay the
> premium (on-chain DEX?).
>
> See https://rubin.io/bitcoin/2021/12/20/advent-23/ for more concrete
> stuff around this.
>
> There are also opportunities for perpetual-like contracts where you could
> combine into one logical DLC 12 DLCs closing 1 per month that can either be
> payed out all at once at the end of the year, or profit pulled out
> partially at any time earlier.
>
> 4) This satisfies (I think?) my request to make DLCs expressible as Sapio
> contracts in https://rubin.io/bitcoin/2021/12/20/advent-23/
>
> 5) An additional performance improvement can be had for iterative DLCs in
> Lightning where you might trade over a fixed set of attestation points with
> variable payout curves (e.g., just modifying some set of the CTV points).
> Defer to you on performance, but this could help enable some more HFT-y
> experiences for DLCs in LN
>
I'm not sure what is meant concretely by (5) but I think overall
performance is ok here. You will always have 10mins or so to confirm the
DLC so you can't be too fussy about performance!
LL
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220206/93996aef/attachment.html>

2023-06-07 23:02:40

- reply

📅 Original date posted:2022-01-24
📝 Original message:Hi dlc-dev and bitcoin-dev,
tl;dr OP_CTV simplifies and improves performance of DLCs by a factor of *a lot*.
## Introduction
Dryja introduced the idea of Discreet Log Contracts (DLC) in his
breakthrough work[1].
Since then (DLC) has become an umbrella term for Bitcoin protocols
that map oracle secret revelation to an on-chain transaction which
apportions coins accordingly.
The key property that each protocol iteration preserves is that the
oracle is an *oblivious trusted party* -- they do not interact with
the blockchain and it is not possible to tell which event or which
oracle the two parties were betting on with blockchain data alone.
`OP_CHECKTEMPLATEVERIFY` (CTV) a.k.a. BIP119 [2] is a proposed
upgrade to Bitcoin which is being actively discussed.
CTV makes possible an optimized protocol which improves DLC
performance so dramatically that it solves several user experience
concerns and engineering difficulties.
To me this is the most compelling and practical application of CTV so
I thought it's about time to share it!
## Present state of DLC specification
The DLC specifications[3] use adaptor signatures to condition each
possible payout.
The protocol works roughly like this:
1. Oracle(s) announce events along with a nonce `R` for each event.
Let's say each event has `N` outcomes.
2. Two users who wish to make a bet take the `R` from the oracle
announcement and construct a set of attestation points `S` and their
corresponding payouts.
3. Each attestation point for each of the `N` outcomes is calculated
like `S_i = R + H(R || X || outcome_i) * X` where `X` is the oracle's
static key.
4. The users combine the attestation points into *contract execution
transaction* (CET) points e.g `CET_i = S1_i + S2_i + S3_i`.
Here `CET_i` is the conjunction (`AND`) between the event outcomes
represented by `S1_i, S2_i, S3_i`.
5. The oracle(s) reveals the attestation `s_i` where `s_i * G = S_i`
if the `i`th is the outcome transpired.
6. Either of the parties takes the `s_i`s from each of the
attestations and combines them e.g. `cet_i = s1_i + s2_i + s3_i` and
uses `cet_i` to decrypt the CET adaptor signature encrypted by `CET_i`
and broadcast the transaction.
## Performance issues with DLCs
In the current DLC protocol both parties compute:
- `E * N` attestation points where `E` is the number of events you
are combining and `N` is the number of outcomes per event. (1 mul)
- `C >= E * N` CET adaptor signatures and verify them. (2 mul -- or
with MuSig2, 3 muls).
Note that the number of CETs can be much greater than the number of
attestation points. For example,
if an oracle decomposes the price of BTC/USD into 20 binary digits
e.g. 0..(2^20 -1), you could have
`E=20,N=2,C=2^20`. So the biggest concern for worst case performance
is the adaptor signatures multiplications.
If we take a multiplication as roughly 50 microseconds computing
MuSig2 adaptor signatures for ~6000 CETs would take around a second of
cpu time (each) or so.
6000 CETs is by no means sufficient if you wanted, for example, to bet
on the BTC/USD price per dollar.
Note there may be various ways of precomputing multiplications and
using fast linear combination algorithms and so on but I hope this
provides an idea of the scale of the issue.
Then consider that you may want to use a threshold of oracles which
will combinatorially increase this number (e.g. 3/5 threshold would
10x this).
You also would end up sending data on the order of megabytes to each other.
## committing to each CET in a tapleaf with CHECKTEMPLATEVERIFY
What can we do with OP_CTV + Taproot to improve this?
Instead of creating an adaptor signature for every CET, commit to the
CET with OP_CTV in a tapleaf:
```
<CET-hash_i> CHECKTEMPLATEVERIFY <CET_i> CHECKSIG
```
When the oracle(s) reveals their attestations either party can combine
them to get the secret key
corresponding to `CET_i` and spend the coins to the CET (whose CTV
hash is `CET-hash`) which
distributes the funds according to the contract.
This replaces all the multiplications needed for the adaptor signature
with a few hashes!
You will still need to compute the `CET_i` which will involve a point
normalisation but it still brings the computational cost per CET down
from hundreds of microseconds to around 5 (per party).
There will be a bit more data on chain (and a small privacy loss) in
the uncooperative case but even with tens of thousands of outcomes
it's only going to roughly double the virtual size of the transaction.
Keep in mind the uncooperative case should hopefully be rare too esp
when we are doing this in channels.
The amount of data that the parties need to exchange is also reduced
to a small constant size.
## getting rid of combinatorial complexity of oracle thresholds
Now that we're using script it's very easy to do a threshold along
with the script. e.g. a 2/3:
```
<CET-hash> CHECKTEMPLATEVERIFY
<attestation-point1> CHECKSIG
<attestation-point2> CHECKSIGADD
<attestation-point3> CHECKSIGADD
2 EQUAL
```
The improvement here is that the amount of computation and
communication does not increase with the number of oracles in the
threshold.
The size of the witness only increases linearly in the number of
oracles and only in the un-cooperative case.
This also solves a security issue with the current spec because
attestation points from different oracles are no longer summed (which
is a problem [4]).
## Getting rid of the attestation point multiplication
It's possible to get rid of the EC multiplications from the
attestation point computation too.
This is optimistically a 10x improvement but in the most important
cases it's a negligible improvement since computing the `E*N`
attestion points is a small fraction of the total CET point
computation.
Recall the original Schnorr style DLC attestation point was computed like:
```
S_i = R + H(R || X || outcome_i) * X
```
So for each outcome we have to hash it and multiply the result by the
oracle's public key.
I don't think hashing is necessary[6].
First note that an oracle attestation scheme is not a signature scheme:
1. The users need to be able to compute the attestation point
beforehand (signature schemes do not require the verifier to be able
to compute anything before hand).
2. There is a very different concept of a forgery -- you don't care
about someone being able to forge signatures under the oracle's key in
general you only care about them being able to forge an attestation
corresponding to some previously announced event i.e. you only care
about forgeries of things that people are actually betting on.
Long story[6] short we can get rid of the hash and do the following
instead for the `outcome_i`:
```
S_i = R + i * X
```
For each `outcome_i` the oracle will reveal a different linear
combination of `R` and `X`.
However, if we still want to preserve the ability to add attestation
points together to create an AND like condition for points
attestations from the same oracle so we have to do:
```
S_i = i * R + X
```
which when we combine two attestations from the same oracle becomes:
`S1_i + S2_j = (i*R1 + X) + (j*R2 + X) = i*R1 + j*R2 + 2*X`
As you can see the addition preserves the linear structure.
If you were to do the original suggestion it would be:
`S1_i + S2_j = (i*X + R1 + (j*X + R2) = (i + j)*X + R1 + R2)`
Which loses the structure and creates collisions e.g. `S1_1 + S2_2 =
S1_2 + S2_1` .
Note that this collision problem also exists in the current spec and
original paper[4,5] but requires a solving a hashing k-sum that should
be hard to do in practice.
So, when we compute for `i in 1..N`, `S_1 = R + X` and each subsequent
is `S_i = S_{i-1} + R` and so we only need to do one addition for each
attestation point.
## In summary
In the worst case this improves DLC performance by ~30x compared to
using MuSig2 adaptor signatures because it gets rid of all
multiplications for both parties.
In the case of a 3/5 threshold performance would be improved by another 10x.
Depending on the kind of event, removing the attestation point
multiplication will also help.
Communication complexity also becomes constant.
In other words, from the user's perspective everything can happen
pretty much instantly even on more resource constrained devices and
bad internet connections.
The downside of the protocol is that in the un-cooperative case, the
size of the witness is bigger and the transaction is distinguishable
from other protocols (it's not longer scriptless).
## Credits
Special thanks to:
- Ruben Somsen who first made the observation that OP_CTV could be
applied to DLCs in the way presented here.
- Thibaut Le Guilly who did benchmarking on getting rid of the
attestation point multiplication.
- Nadav Cohen who pointed out that doing `R + i*X` was broken.
[1]: https://adiabat.github.io/dlc.pdf
[2]: https://github.com/bitcoin/bips/blob/master/bip-0119.mediawiki
[3]: https://github.com/discreetlogcontracts/dlcspecs
[4]: https://bitcoinproblems.org/problems/secure-dlcs.html
[5]: https://mailmanlists.org/pipermail/dlc-dev/2021-March/000065.html
[6]: https://github.com/LLFourn/dlc-sec/blob/master/main.pdf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220124/cec80a59/attachment-0001.html>

2023-06-07 22:54:32

- reply

📅 Original date posted:2021-06-15
📝 Original message:On Tue, 15 Jun 2021 at 10:59, Lloyd Fournier <lloyd.fourn at gmail.com> wrote:
>
>
> On Tue, 15 Jun 2021 at 02:47, Antoine Riard <antoine.riard at gmail.com>
> wrote:
>
>> > This makes a lot of sense as it matches the semantics of what we are
>> trying
>> to achieve: allow the owner of an output (whether an individual or group)
>> to reduce that output's value to pay a higher fee.
>>
>> Note, I think you're still struggling with some trust issue that anchor
>> upgrade is at least eliminating for LN, namely the pre-agreement among a
>> group of signers about the effective feerate to use at some unknown time
>> point in the future. If you authorize your counterparty for a broadcast at
>> feerate X, how do you prevent a broadcast at feerate Y, where Y is far
>> under X, thus maliciously burning a lot of your fee-bumping reserve ?
>>
>> Of course, one mitigation is to make a contribution to a common
>> fee-bumping output reserve proportional to what has been contributed as a
>> funding collateral. Thus disincentivizing misuse of the common fee-bumping
>> reserve in a game-theoretical way. But if you take the example of a LN
>> channel, you're now running into another issue. Off-chain balances might
>> fluctuate in a way that most of the time, your fee-bumping reserve
>> contribution is out-of-proportion with your balance amounts to protect ?
>> And as such enduring some significant timevalue bleeding on your
>> fee-bumping reserve.
>>
>> Single-party managed fee-bumping reserve doesn't seem to suffer from this
>> drawback ?
>>
>
> I claim that what I am suggesting is a single-party managed fee-bumping
> system that solves all fee-bumping requirements of lightning without
> needing external utxos and without additional interaction or fee
> pre-agreement between parties. On the commit tx you have your balance going
> exclusively towards you which you can unilaterally reduce to increase the
> fee up to whatever threshold you want. With a HTLC or PTLC you also always
> have a tx with an output that you can unilaterally drain to bump fee
> (either the hltc-success or htlc-timeout). Are you saying that there are
> protocols where this would require pre-arrangement or are you saying that
> it would require pre-arrangement in lightning for some reason I don't see?
>
Ok now I see what I am missing: We don't really know who owns certain
outputs in lightning until the most-recent-state-enforcement mechanism has
done its job. i.e. the outputs are 2-of-2s up until that has been resolved.
I was operating on some simplified imaginary lightning. Indeed this makes
the proposal far less attractive and does require interaction and
pre-agreement. This complexity here makes it worse than just keeping
external fee-bumping utxos around (as undesirable as this is). Thanks for
helping me figure this out.
LL
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210615/d94f53c0/attachment-0001.html>

2023-06-07 22:54:31

- reply

📅 Original date posted:2021-06-14
📝 Original message:On Tue, 15 Jun 2021 at 02:47, Antoine Riard <antoine.riard at gmail.com> wrote:
> > This makes a lot of sense as it matches the semantics of what we are
> trying
> to achieve: allow the owner of an output (whether an individual or group)
> to reduce that output's value to pay a higher fee.
>
> Note, I think you're still struggling with some trust issue that anchor
> upgrade is at least eliminating for LN, namely the pre-agreement among a
> group of signers about the effective feerate to use at some unknown time
> point in the future. If you authorize your counterparty for a broadcast at
> feerate X, how do you prevent a broadcast at feerate Y, where Y is far
> under X, thus maliciously burning a lot of your fee-bumping reserve ?
>
> Of course, one mitigation is to make a contribution to a common
> fee-bumping output reserve proportional to what has been contributed as a
> funding collateral. Thus disincentivizing misuse of the common fee-bumping
> reserve in a game-theoretical way. But if you take the example of a LN
> channel, you're now running into another issue. Off-chain balances might
> fluctuate in a way that most of the time, your fee-bumping reserve
> contribution is out-of-proportion with your balance amounts to protect ?
> And as such enduring some significant timevalue bleeding on your
> fee-bumping reserve.
>
> Single-party managed fee-bumping reserve doesn't seem to suffer from this
> drawback ?
>
I claim that what I am suggesting is a single-party managed fee-bumping
system that solves all fee-bumping requirements of lightning without
needing external utxos and without additional interaction or fee
pre-agreement between parties. On the commit tx you have your balance going
exclusively towards you which you can unilaterally reduce to increase the
fee up to whatever threshold you want. With a HTLC or PTLC you also always
have a tx with an output that you can unilaterally drain to bump fee
(either the hltc-success or htlc-timeout). Are you saying that there are
protocols where this would require pre-arrangement or are you saying that
it would require pre-arrangement in lightning for some reason I don't see?
To further emphasise the generality of this idea you can easily imagine a
world where this is enabled on all Bitcoin transactions (of course you have
to stomach tx malleability -- a bit more palatable with ANYPREVOUT
everywhere). Even for a normal wallet-to-wallet payment the receiver could
efficiently increase the tx fee by making a signature under the key of
their output and replacing the original tx without interacting with the
sender who actually provided the funds for the payment.
Cheers,
LL
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210615/5e288dda/attachment.html>

2023-06-07 22:54:29

- reply

📅 Original date posted:2021-06-13
📝 Original message:On Fri, 11 Jun 2021 at 07:45, Antoine Riard <antoine.riard at gmail.com> wrote:
> Hi Lloyd,
>
> Thanks for this tx mutation proposal extending the scope of fee-bumping
> techniques. IIUC, the <output_index> serves as a pointer to increase the
> output amount by value to recover the recompute the transaction hash
> against which the original signature is valid ?
>
Right.
> Let's do a quick analysis of this scheme.
> * onchain footprint : one tapleaf per contract participant, with O(log n)
> increase of witness size, also one output per contract participant
>
Yes but we can fix this (see below).
* tx-relay bandwidth rebroadcast : assuming aforementioned in-place mempool
> substitution policy, the mutated transaction
>
* batching : fee-bumping value is extract from contract transaction itself,
> so O(n) per contract
> * mempool flexibility : the mutated transaction
> * watchtower key management : to enable outsourcing, the mutating key must
> be shared, in theory enabling contract value siphoning to miner fees ?
>
Yes. You could use OP_LESSTHAN to make sure the value being deducted by the
watchtower is not above a threshold.
> Further, I think tx mutation scheme can be achieved in another way, with
> SIGHASH_ANYAMOUNT. A contract participant tapscript will be the following :
>
> <contract_key> <finalizing_alice_key>
>
> Where <contract_signature> is committed with SIGHASH_ANYAMOUNT, blanking
> nValue of one or more outputs. That way, the fee-to-contract-value
> distribution can be unilaterally finalized at a later time through the
> finalizing key [0].
>
Yes, that's also a way to do it. I was trying to preserve the original
external key signature in my attempt but this is probably not necessary. L2
protocols could just exchange two signatures instead. One optimistic one on
the external key and one pessimistic SIGHASH_ANYAMOUNT one on the
<contract_key>.
> Note, I think that the tx mutation proposal relies on interactivity in the
> worst-case scenario where a counterparty wants to increase its fee-bumping
> output from the contract balance. This interactivity may lure a
> counterparty to alway lock the worst-case fee-bumping reserve in the
> output. I believe anchor output enables more "real-time" fee-bumping
> reserve adjustment ?
>
Hmmm well I was hoping that you wouldn't need interaction ever. I can see
that my commitment TX example was too contrived because it has balance
outputs that go exclusively to one party.
Let's take a better example: A PTLC output with both timeout and success
pre-signed transactions spending from it. We must only let the person
offering the PTLC reduce the output of the timeout tx and the converse for
the success tx.
Note very carefully that if we naively apply OP_CHECKSIG_MUTATED or
SIGHASH_ANYAMOUNT with one tapleaf for each party then we risk one party
being able to lower the other party's output by doing a switcharoo on the
tapleaf after they see the signature for their counterparty's tx in the
mempool. In your example you could fix it by having a different
<contract_key> but this means we can't compress <contract_key> by just
using the taproot internal/external key.
What about this: Instead of party specific "finalizing_alice_key" or
p1-fee-bump-key as I denoted it, we just use the key of the output whose
value we are reducing. This also solves the O(log(n)) tapleaves for
OP_CHECKSIG_MUTATED approach as well -- just have one tapleaf for fee
bumping but authorize it under the key of the output we are reducing. Thus
we need something like OP_PUSH_TAPROOT_OUTPUT_KEY <output index> which
takes the taproot external key at that output (fail if not taproot) and
puts it on the stack. So to be clear you have the <output index> on the
witness stack rather than having it fixed in a particular tapleaf (as per
my original post) and then use OP_DUP to pass it to both
OP_CHECKSIG_MUTATED and OP_PUSH_TAPROOT_OUTPUT_KEY.
This makes a lot of sense as it matches the semantics of what we are trying
to achieve: allow the owner of an output (whether an individual or group)
to reduce that output's value to pay a higher fee.
Furthermore this removes all keys from the tapleaf since they are all
aliased to either the input we are spending or one of the output keys of
the tx we are spending to. This is quite a big improvement over my original
idea.
This works for lightning commit tx and for the case of a PTLC contract. It
also seems to work for the DLC funding output. I'd be interested to know if
anyone can think of a protocol where this would be inconvenient or
impossible to use as the main pre-signed tx fee bumping system.
Cheers,
LL
Le dim. 6 juin 2021 à 22:28, Lloyd Fournier <lloyd.fourn at gmail.com> a
> écrit :
>
>> Hi Antione,
>>
>> Thanks for bringing up this important topic. I think there might be
>> another class of solutions over input based, CPFP and sponsorship. I'll
>> call them tx mutation schemes. The idea is that you can set a key that can
>> increase the fee by lowering a particular output after the tx is signed
>> without invalidating the signature. The premise is that anytime you need to
>> bump the fee of a transaction you must necessarily have funds in an output
>> that are going to you and therefore you can sacrifice some of them to
>> increase the fee. This is obviously destructive to txids so child presigned
>> transactions will have to use ANYPREVOUT as in your proposal. The advantage
>> is that it does not require keeping extra inputs around to bump the fee.
>>
>> So imagine a new opcode OP_CHECKSIG_MUTATED <output index> <publickey>
>> <value> <signature>.
>> This would check that <signature> is valid against <publickey> if the
>> current transaction had the output at <output index> reduced by <value>. To
>> make this more efficient, if the public key is one byte: 0x02 it references
>> the taproot *external key* (similar to how ANYPREVOUT uses 0x01 to refer to
>> internal key[1]).
>> Now for our protocol we want both parties (p1 and p2) to be able to fee
>> bump a commitment transaction. They use MuSig to sign the commitment tx
>> under the external key with a decent fee for the current conditions. But in
>> case it proves insufficient they have added the following two leaves to
>> their key in the funding output as a backup so that p1 and p2 can
>> unilaterally bump the fee of anything they sign spending from the funding
>> output:
>>
>> 1. OP_CHECKSIG_MUTATED(0, 0x02, <fee-bump-value>, <original-signature>)
>> OP_CHECKSIGADD(p1-fee-bump-key, <p1-fee-bump-signature>) OP_2
>> OP_NUMEQUALVERIFY
>> 2. OP_CHECKSIG_MUTATED(1, 0x02, <fee-bump-value>, <original-signature>)
>> OP_CHECKSIGADD(p2-fee-bump-key, <p2-fee-bump-signature>) OP_2
>> OP_NUMEQUALVERIFY
>>
>> where <...> indicates the thing comes from the witness stack.
>> So to bump the fee of the commit tx after it has been signed either party
>> takes the <original-signature> and adds a signature under their
>> fee-bump-key for the new tx and reveals their fee bump leaf.
>> <original-signature> is checked against the old transaction while the fee
>> bumped transaction is checked against the fee bump key.
>>
>> I know I have left out how to change mempool eviction rules to
>> accommodate this kind of fee bumping without DoS or pinning attacks but
>> hopefully I have demonstrated that this class of solutions also exists.
>>
>> [1]
>> https://github.com/ajtowns/bips/blob/bip-anyprevout/bip-0118.mediawiki
>>
>> Cheers,
>>
>> LL
>>
>>
>>
>> On Fri, 28 May 2021 at 07:13, Antoine Riard via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>> Hi,
>>>
>>> This post is pursuing a wider discussion around better fee-bumping
>>> strategies for second-layer protocols. It draws out a comparison between
>>> input-based and CPFP fee-bumping techniques, and their apparent trade-offs
>>> in terms of onchain footprint, tx-relay bandwidth rebroadcast, batching
>>> opportunity and mempool flexibility.
>>>
>>> Thanks to Darosior for reviews, ideas and discussions.
>>>
>>> ## Child-Pay-For-Parent
>>>
>>> CPFP is a mature fee-bumping technique, known and used for a while in
>>> the Bitcoin ecosystem. However, its usage in contract protocols with
>>> distrusting counterparties raised some security issues. As mempool's chain
>>> of unconfirmed transactions are limited in size, if any output is spendable
>>> by any contract participant, it can be leveraged as a pinning vector to
>>> downgrade odds of transaction confirmation [0].
>>>
>>> That said, contract transactions interested to be protected under the
>>> carve-out logic require to add a new output for any contract participant,
>>> even if ultimately only one of them serves as an anchor to attach a CPFP.
>>>
>>> ## Input-Based
>>>
>>> I think input-based fee-bumping has been less studied as fee-bumping
>>> primitive for L2s [1]. One variant of input-based fee-bumping usable today
>>> is the leverage of the SIGHASH_ANYONECANPAY/SIGHASH_SINGLE malleability
>>> flags. If the transaction is the latest stage of the contract, a bumping
>>> input can be attached just-in-time, thus increasing the feerate of the
>>> whole package.
>>>
>>> However, as of today, input-based fee-bumping doesn't work to bump first
>>> stages of contract transactions as it's destructive of the txid, and as
>>> such breaks chain of pre-signed transactions. A first improvement would be
>>> the deployment of the SIGHASH_ANYPREVOUT softfork proposal. This new
>>> malleability flag allows a transaction to be signed without reference to
>>> any specific previous output. That way, spent transactions can be
>>> fee-bumped without altering validity of the chain of transactions.
>>>
>>> Even assuming SIGHASH_ANYPREVOUT, if the first stage contract
>>> transaction includes multiple outputs (e.g the LN's commitment tx has
>>> multiple HTLC outputs), SIGHASH_SINGLE can't be used and the fee-bumping
>>> input value might be wasted. This edge can be smoothed by broadcasting a
>>> preliminary fan-out transaction with a set of outputs providing a range of
>>> feerate points for the bumped transaction.
>>>
>>> This overhead could be smoothed even further in the future with more
>>> advanced sighash malleability flags like SIGHASH_IOMAP, allowing
>>> transaction signers to commit to a map of inputs/outputs [2]. In the
>>> context of input-based, the overflowed fee value could be redirected to an
>>> outgoing output.
>>>
>>> ## Onchain Footprint
>>>
>>> CPFP: One anchor output per participant must be included in the
>>> commitment transaction. To this anchor must be attached a child transaction
>>> with 2 inputs (one for the commitment, one for the bumping utxo) and 1
>>> output. Onchain footprint: 2 inputs + 3 outputs.
>>>
>>> Input-based (today): If the bumping utxo is offering an adequate feerate
>>> point in function of network mempools congestion at time of broadcast, only
>>> 1 input. If a preliminary fan-out transaction to adjust feerate point must
>>> be broadcasted first, 1 input and 2 outputs more must be accounted for.
>>> Onchain footprint: 2 inputs + 3 outputs.
>>>
>>> Input-based (SIGHASH_ANYPREVOUT+SIGHASH_IOMAP): As long as the bumping
>>> utxo's value is wide enough to cover the worst-case of mempools congestion,
>>> the bumped transaction can be attached 1 input and 1 output. Onchain
>>> footprint: 1 input + 1 output.
>>>
>>> ## Tx-Relay Bandwidth Rebroadcast
>>>
>>> CPFP: In the context of multi-party protocols, we should assume bounded
>>> rationality of the participants w.r.t to an unconfirmed spend of the
>>> contract utxo across network mempools. Under this assumption, the bumped
>>> transaction might have been replaced by a concurrent state. To guarantee
>>> efficiency of the CPFP the whole chain of transactions should be
>>> rebroadcast, perhaps wasting bandwidth consumption for a still-identical
>>> bumped transaction [3]. Rebroadcast footprint: the whole chain of
>>> transactions.
>>>
>>> Input-based (today): In case of rebroadcast, the fee-bumping input is
>>> attached to the root of the chain of transactions and as such breaks the
>>> chain validity in itself. Beyond the rebroadcast of the updated root under
>>> replacement policy, the remaining transactions must be updated and
>>> rebroadcast. Rebroadcast footprint: the whole chain of transactions.
>>>
>>> Input-based(SIGHASH_ANYPREVOUT+SIGHASH_IOMAP): In case of rebroadcast,
>>> the fee-bumping is attached to the root of the chain of transactions but it
>>> doesn't break the chain validity in itself. Assuming a future mempool
>>> acceptance logic to authorize in-place substitution, the rest of the chain
>>> could be preserved. Rebroadcast footprint: the root of the chain of
>>> transactions.
>>>
>>> ## Fee-Bumping Batching
>>>
>>> CPFP: In the context of multi-party protocols, in optimistic scenarios,
>>> we can assume aggregation of multiple chains of transactions. For e.g, a LN
>>> operator is desirous to non-cooperatively close multiple channels at the
>>> same time and would like to combine their fee-bumping. With CPFP, one
>>> anchor output and one bumping input must be consumed per aggregated chain,
>>> even if the child transaction fields can be shared. Batching perf: 1
>>> input/1 output per aggregated chain.
>>>
>>> Input-based (today): Unless the contract allows interactivity, multiple
>>> chains of transactions cannot be aggregated. One bumping input must be
>>> attached per chain, though if a preliminary fan-out transaction is relied
>>> on to offer multiple feerate points, transaction fields can be shared.
>>> Batching perf: 1 input/1 output per aggregated chain.
>>>
>>> Input-based (SIGHASH_ANYPREVOUT+SIGHASH_IOMAP): Multiple chains of
>>> transactions might be aggregated together *non-interactively*. One bumping
>>> input and outgoing output can be attached to the aggregated root. Batching
>>> perf: 1 input/1 output per aggregation.
>>>
>>> ## Fee-Bumping Mempool Flexibility
>>>
>>> CPFP: In the context of multi-party protocols, one of your
>>> counterparties might build a branch of transactions from one of the root
>>> outputs thus saturating the in-mempool package limits. To avoid these
>>> shenanigans, LN channels are relying on the carve-out mechanism. Though,
>>> the carve-out mechanism includes its own limitation and doesn't scale
>>> beyond 2 contract participants.
>>>
>>> Input-based: The root of the chain of transaction is the package's
>>> oldest ancestor, so package limits don't restrain its acceptance and it
>>> works whatever the number of contract participants.
>>>
>>> To conclude, this post scores 2 fee-bumping primitives for multi-party
>>> protocols on a range of factors. It hopes to unravel the ground for a real
>>> feerate performance framework of second-layers protocols .
>>>
>>> Beyond that, few points can be highlighted a) future soft forks allow
>>> significant onchain footprint savings, especially in case of batching, b)
>>> future package relay bandwidth efficiency should account for rebroadcast
>>> frequency of CPFPing multi-party protocols. On this latter point one
>>> follow-up might be to evaluate differing package relay *announcement*
>>> schemes in function of odds of non-cooperative protocol broadcast/odds of
>>> concurrent broadcast/rebroadcast frequencies.
>>>
>>> Thoughts ?
>>>
>>> Cheers,
>>> Antoine
>>>
>>> [0]
>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-November/016518.html
>>> [1] Beyond the revault architecture :
>>> https://github.com/revault/practical-revault/blob/master/revault.pdf
>>> [2] Already proposed a while back :
>>> https://bitcointalk.org/index.php?topic=252960.0
>>> [3] In theory, an already-relayed transaction shouldn't pass Core's
>>> `filterInventoryKnown`. In practice, if the transaction is announced as
>>> part of a package_id, the child might have changed, not the parent, leading
>>> to a redundant relay of the latter.
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210613/065d7cbf/attachment-0001.html>

2023-06-07 22:54:25

- reply

📅 Original date posted:2021-06-06
📝 Original message:Hi Antione,
Thanks for bringing up this important topic. I think there might be another
class of solutions over input based, CPFP and sponsorship. I'll call them
tx mutation schemes. The idea is that you can set a key that can increase
the fee by lowering a particular output after the tx is signed without
invalidating the signature. The premise is that anytime you need to bump
the fee of a transaction you must necessarily have funds in an output that
are going to you and therefore you can sacrifice some of them to increase
the fee. This is obviously destructive to txids so child presigned
transactions will have to use ANYPREVOUT as in your proposal. The advantage
is that it does not require keeping extra inputs around to bump the fee.
So imagine a new opcode OP_CHECKSIG_MUTATED <output index> <publickey>
<value> <signature>.
This would check that <signature> is valid against <publickey> if the
current transaction had the output at <output index> reduced by <value>. To
make this more efficient, if the public key is one byte: 0x02 it references
the taproot *external key* (similar to how ANYPREVOUT uses 0x01 to refer to
internal key[1]).
Now for our protocol we want both parties (p1 and p2) to be able to fee
bump a commitment transaction. They use MuSig to sign the commitment tx
under the external key with a decent fee for the current conditions. But in
case it proves insufficient they have added the following two leaves to
their key in the funding output as a backup so that p1 and p2 can
unilaterally bump the fee of anything they sign spending from the funding
output:
1. OP_CHECKSIG_MUTATED(0, 0x02, <fee-bump-value>, <original-signature>)
OP_CHECKSIGADD(p1-fee-bump-key, <p1-fee-bump-signature>) OP_2
OP_NUMEQUALVERIFY
2. OP_CHECKSIG_MUTATED(1, 0x02, <fee-bump-value>, <original-signature>)
OP_CHECKSIGADD(p2-fee-bump-key, <p2-fee-bump-signature>) OP_2
OP_NUMEQUALVERIFY
where <...> indicates the thing comes from the witness stack.
So to bump the fee of the commit tx after it has been signed either party
takes the <original-signature> and adds a signature under their
fee-bump-key for the new tx and reveals their fee bump leaf.
<original-signature> is checked against the old transaction while the fee
bumped transaction is checked against the fee bump key.
I know I have left out how to change mempool eviction rules to accommodate
this kind of fee bumping without DoS or pinning attacks but hopefully I
have demonstrated that this class of solutions also exists.
[1] https://github.com/ajtowns/bips/blob/bip-anyprevout/bip-0118.mediawiki
Cheers,
LL
On Fri, 28 May 2021 at 07:13, Antoine Riard via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hi,
>
> This post is pursuing a wider discussion around better fee-bumping
> strategies for second-layer protocols. It draws out a comparison between
> input-based and CPFP fee-bumping techniques, and their apparent trade-offs
> in terms of onchain footprint, tx-relay bandwidth rebroadcast, batching
> opportunity and mempool flexibility.
>
> Thanks to Darosior for reviews, ideas and discussions.
>
> ## Child-Pay-For-Parent
>
> CPFP is a mature fee-bumping technique, known and used for a while in the
> Bitcoin ecosystem. However, its usage in contract protocols with
> distrusting counterparties raised some security issues. As mempool's chain
> of unconfirmed transactions are limited in size, if any output is spendable
> by any contract participant, it can be leveraged as a pinning vector to
> downgrade odds of transaction confirmation [0].
>
> That said, contract transactions interested to be protected under the
> carve-out logic require to add a new output for any contract participant,
> even if ultimately only one of them serves as an anchor to attach a CPFP.
>
> ## Input-Based
>
> I think input-based fee-bumping has been less studied as fee-bumping
> primitive for L2s [1]. One variant of input-based fee-bumping usable today
> is the leverage of the SIGHASH_ANYONECANPAY/SIGHASH_SINGLE malleability
> flags. If the transaction is the latest stage of the contract, a bumping
> input can be attached just-in-time, thus increasing the feerate of the
> whole package.
>
> However, as of today, input-based fee-bumping doesn't work to bump first
> stages of contract transactions as it's destructive of the txid, and as
> such breaks chain of pre-signed transactions. A first improvement would be
> the deployment of the SIGHASH_ANYPREVOUT softfork proposal. This new
> malleability flag allows a transaction to be signed without reference to
> any specific previous output. That way, spent transactions can be
> fee-bumped without altering validity of the chain of transactions.
>
> Even assuming SIGHASH_ANYPREVOUT, if the first stage contract transaction
> includes multiple outputs (e.g the LN's commitment tx has multiple HTLC
> outputs), SIGHASH_SINGLE can't be used and the fee-bumping input value
> might be wasted. This edge can be smoothed by broadcasting a preliminary
> fan-out transaction with a set of outputs providing a range of feerate
> points for the bumped transaction.
>
> This overhead could be smoothed even further in the future with more
> advanced sighash malleability flags like SIGHASH_IOMAP, allowing
> transaction signers to commit to a map of inputs/outputs [2]. In the
> context of input-based, the overflowed fee value could be redirected to an
> outgoing output.
>
> ## Onchain Footprint
>
> CPFP: One anchor output per participant must be included in the commitment
> transaction. To this anchor must be attached a child transaction with 2
> inputs (one for the commitment, one for the bumping utxo) and 1 output.
> Onchain footprint: 2 inputs + 3 outputs.
>
> Input-based (today): If the bumping utxo is offering an adequate feerate
> point in function of network mempools congestion at time of broadcast, only
> 1 input. If a preliminary fan-out transaction to adjust feerate point must
> be broadcasted first, 1 input and 2 outputs more must be accounted for.
> Onchain footprint: 2 inputs + 3 outputs.
>
> Input-based (SIGHASH_ANYPREVOUT+SIGHASH_IOMAP): As long as the bumping
> utxo's value is wide enough to cover the worst-case of mempools congestion,
> the bumped transaction can be attached 1 input and 1 output. Onchain
> footprint: 1 input + 1 output.
>
> ## Tx-Relay Bandwidth Rebroadcast
>
> CPFP: In the context of multi-party protocols, we should assume bounded
> rationality of the participants w.r.t to an unconfirmed spend of the
> contract utxo across network mempools. Under this assumption, the bumped
> transaction might have been replaced by a concurrent state. To guarantee
> efficiency of the CPFP the whole chain of transactions should be
> rebroadcast, perhaps wasting bandwidth consumption for a still-identical
> bumped transaction [3]. Rebroadcast footprint: the whole chain of
> transactions.
>
> Input-based (today): In case of rebroadcast, the fee-bumping input is
> attached to the root of the chain of transactions and as such breaks the
> chain validity in itself. Beyond the rebroadcast of the updated root under
> replacement policy, the remaining transactions must be updated and
> rebroadcast. Rebroadcast footprint: the whole chain of transactions.
>
> Input-based(SIGHASH_ANYPREVOUT+SIGHASH_IOMAP): In case of rebroadcast, the
> fee-bumping is attached to the root of the chain of transactions but it
> doesn't break the chain validity in itself. Assuming a future mempool
> acceptance logic to authorize in-place substitution, the rest of the chain
> could be preserved. Rebroadcast footprint: the root of the chain of
> transactions.
>
> ## Fee-Bumping Batching
>
> CPFP: In the context of multi-party protocols, in optimistic scenarios, we
> can assume aggregation of multiple chains of transactions. For e.g, a LN
> operator is desirous to non-cooperatively close multiple channels at the
> same time and would like to combine their fee-bumping. With CPFP, one
> anchor output and one bumping input must be consumed per aggregated chain,
> even if the child transaction fields can be shared. Batching perf: 1
> input/1 output per aggregated chain.
>
> Input-based (today): Unless the contract allows interactivity, multiple
> chains of transactions cannot be aggregated. One bumping input must be
> attached per chain, though if a preliminary fan-out transaction is relied
> on to offer multiple feerate points, transaction fields can be shared.
> Batching perf: 1 input/1 output per aggregated chain.
>
> Input-based (SIGHASH_ANYPREVOUT+SIGHASH_IOMAP): Multiple chains of
> transactions might be aggregated together *non-interactively*. One bumping
> input and outgoing output can be attached to the aggregated root. Batching
> perf: 1 input/1 output per aggregation.
>
> ## Fee-Bumping Mempool Flexibility
>
> CPFP: In the context of multi-party protocols, one of your counterparties
> might build a branch of transactions from one of the root outputs thus
> saturating the in-mempool package limits. To avoid these shenanigans, LN
> channels are relying on the carve-out mechanism. Though, the carve-out
> mechanism includes its own limitation and doesn't scale beyond 2 contract
> participants.
>
> Input-based: The root of the chain of transaction is the package's oldest
> ancestor, so package limits don't restrain its acceptance and it works
> whatever the number of contract participants.
>
> To conclude, this post scores 2 fee-bumping primitives for multi-party
> protocols on a range of factors. It hopes to unravel the ground for a real
> feerate performance framework of second-layers protocols .
>
> Beyond that, few points can be highlighted a) future soft forks allow
> significant onchain footprint savings, especially in case of batching, b)
> future package relay bandwidth efficiency should account for rebroadcast
> frequency of CPFPing multi-party protocols. On this latter point one
> follow-up might be to evaluate differing package relay *announcement*
> schemes in function of odds of non-cooperative protocol broadcast/odds of
> concurrent broadcast/rebroadcast frequencies.
>
> Thoughts ?
>
> Cheers,
> Antoine
>
> [0]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-November/016518.html
> [1] Beyond the revault architecture :
> https://github.com/revault/practical-revault/blob/master/revault.pdf
> [2] Already proposed a while back :
> https://bitcointalk.org/index.php?topic=252960.0
> [3] In theory, an already-relayed transaction shouldn't pass Core's
> `filterInventoryKnown`. In practice, if the transaction is announced as
> part of a package_id, the child might have changed, not the parent, leading
> to a redundant relay of the latter.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210607/49ff1a08/attachment.html>

2023-06-07 22:54:15

- reply

📅 Original date posted:2021-06-16
📝 Original message:@James wrote:
On Tue, 15 Jun 2021 at 21:13, James MacWhyte <macwhyte at gmail.com> wrote:
>
> @Lloyd wrote:
>
> Of course in reality no one wants to keep their coin holding keys online
>> so in Alogorand you can authorize a set of "participation keys"[1] that
>> will be used to create blocks on your coin holding key's behalf.
>> Hopefully you've spotted the problem.
>> You can send your participation keys to any malicious party with a nice
>> website (see random example [2]) offering you a good return.
>> Damn it's still Proof-of-SquareSpace!
>>
>
> I believe we are talking about a comparison to PoW, correct? If you want
> to mine PoW, you need to buy expensive hardware and configure it to work,
> and wait a long time to get any return by solo mining. Or you can join a
> mining pool, which might use your hashing power for nefarious purposes.
>
A mining pool using your hashrate for nefarious purposes can easily be
observed since they send you the contents of the block you are mining
before your hardware starts working on it. This difference is crucial.
Mining pools exist just to reduce income variance.
> Or you might skip the hardware all together and fall for some "cloud
> mining" scheme with a pretty website and a high rate of advertised return.
> So as you can see, Proof-of-SquareSpace exists in PoW as well!
>
I'd agree that "cloud mining" pretty much is Proof-of-SquareSpace for PoW.
Fortunately these services make up a tiny fraction of hashrate.
> The PoS equivalent of buying mining hardware is setting up your own
> validator and not outsourcing that to anyone else. So both PoW and PoS have
> the professional/expert way of participating, and the fraud-prone, amateur
> way of participating. The only difference is, with PoS the
> professional/expert way is accessible to anyone with a raspberry Pi and a
> web connection, which is a much lower barrier to entry than PoW.
>
And yet despite this, the fraud-prone amteur way of participating accounts
for the majority of stake in PoS systems while the professional/expert way
of participating accounts for the overwhelming majority of hashpower in
Bitcoin. It looks like you have elegantly proved my point!
LL
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210617/672a53bd/attachment-0001.html>

2023-06-07 22:52:53

- reply

📅 Original date posted:2021-05-23
📝 Original message:Hi Billy,
I was going to write a post which started by dismissing many of the weak
arguments that are made against PoS made in this thread and elsewhere.
Although I don't agree with all your points you have done a decent job here
so I'll focus on the second part: why I think Proof-of-Stake is
inappropriate for a Bitcoin-like system.
Proof of stake is not fit for purpose for a global settlement layer in a
pure digital asset (i.e. "digital gold") which is what Bitcoin is trying to
be.
PoS necessarily gives responsibilities to the holders of coins that they do
not want and cannot handle.
In Bitcoin, large unsophisticated coin holders can put their coins in cold
storage without a second thought given to the health of the underlying
ledger.
As much as hardcore Bitcoiners try to convince them to run their own node,
most don't, and that's perfectly acceptable.
At no point do their personal decisions affect the underlying consensus --
it only affects their personal security assurance (not that of the system
itself).
In PoS systems this clean separation of responsibilities does not exist.
I think that the more rigorously studied PoS protocols will work fine
within the security claims made in their papers.
People who believe that these protocols are destined for catastrophic
consensus failure are certainly in for a surprise.
But the devil is in the detail.
Let's look at what the implications of using the leading proof of stake
protocols would have on Bitcoin:
### Proof of SquareSpace (Cardano, Polkdadot)
Cardano is a UTXO based PoS coin based on Ouroboros Praos[3] with an
inbuilt on-chain delegation system[5].
In these protocols, coin holders who do not want to run their node with
their hot keys in it delegate it to a "Stake Pool".
I call the resulting system Proof-of-SquareSpace since most will choose a
pool by looking around for one with a nice website and offering the largest
share of the block reward.
On the surface this might sound no different than someone with an mining
rig shopping around for a good mining pool but there are crucial
differences:
1. The person making the decision is forced into it just because they own
the currency -- someone with a mining rig has purchased it with the intent
to make profit by participating in consensus.
2. When you join a mining pool your systems are very much still online. You
are just partaking in a pool to reduce your profit variance. You still see
every block that you help create and *you never help create a block without
seeing it first*.
3. If by SquareSpace sybil attack you gain a dishonest majority and start
censoring transactions how are the users meant to redelegate their stake to
honest pools?
I guess they can just send a transaction delegating to another pool...oh
wait I guess that might be censored too! This seems really really bad.
In Bitcoin, miners can just join a different pool at a whim. There is
nothing the attacker can do to stop them. A temporary dishonest majority
heals relatively well.
There is another severe disadvantage to this on-chain delegation system:
every UTXO must indicate which staking account this UTXO belongs to so the
appropriate share of block rewards can be transferred there.
Being able to associate every UTXO to an account ruins one of the main
privacy advantages of the UTXO model.
It also grows the size of the blockchain significantly.
### "Pure" proof of stake (Algorand)
Algorand's[4] approach is to only allow online stake to participate in the
protocol.
Theoretically, This means that keys holding funds have to be online in
order for them to author blocks when they are chosen.
Of course in reality no one wants to keep their coin holding keys online so
in Alogorand you can authorize a set of "participation keys"[1] that will
be used to create blocks on your coin holding key's behalf.
Hopefully you've spotted the problem.
You can send your participation keys to any malicious party with a nice
website (see random example [2]) offering you a good return.
Damn it's still Proof-of-SquareSpace!
The minor advantage is that at least the participation keys expire after a
certain amount of time so eventually the SquareSpace attacker will lose
their hold on consensus.
Importantly there is also less junk on the blockchain because the
participation keys are delegated off-chain and so are not making as much of
a mess.
### Conclusion
I don't see a way to get around the conflicting requirement that the keys
for large amounts of coins should be kept offline but those are exactly the
coins we need online to make the scheme secure.
If we allow delegation then we open up a new social attack surface and it
degenerates to Proof-of-SquareSpace.
For a "digital gold" like system like Bitcoin we optimize for simplicity
and desperately want to avoid extraneous responsibilities for the holder of
the coin.
After all, gold is an inert element on the periodic table that doesn't
confer responsibilities on the holder to maintain the quality of all the
other bars of gold out there.
Bitcoin feels like this too and in many ways is more inert and beautifully
boring than gold.
For Bitcoin to succeed I think we need to keep it that way and
Proof-of-Stake makes everything a bit too exciting.
I suppose in the end the market will decide what is real digital gold and
whether these bad technical trade offs are worth being able to say it uses
less electricity. It goes without saying that making bad technical
decisions to appease the current political climate is an anathema to
Bitcoin.
Would be interested to know if you or others think differently on these
points.
[1]:
https://developer.algorand.org/docs/run-a-node/participate/generate_keys/
[2]: https://staking.staked.us/algorand-staking
[3]: https://eprint.iacr.org/2017/573.pdf
[4]:
https://algorandcom.cdn.prismic.io/algorandcom%2Fece77f38-75b3-44de-bc7f-805f0e53a8d9_theoretical.pdf
[5]:
https://hydra.iohk.io/build/790053/download/1/delegation_design_spec.pdf
Cheers,
LL
On Fri, 21 May 2021 at 19:21, Billy Tetrud via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> I think there is a lot of misinformation and bias against Proof of Stake.
> Yes there have been lots of shady coins that use insecure PoS mechanisms.
> Yes there have been massive issues with distribution of PoS coins (of
> course there have also been massive issues with PoW coins as well).
> However, I want to remind everyone that there is a difference between
> "proved to be impossible" and "have not achieved recognized success yet".
> Most of the arguments levied against PoS are out of date or rely on
> unproven assumptions or extrapolation from the analysis of a particular PoS
> system. I certainly don't think we should experiment with bitcoin by
> switching to PoS, but from my research, it seems very likely that there is
> a proof of stake consensus protocol we could build that has substantially
> higher security (cost / capital required to execute an attack) while at the
> same time costing far less resources (which do translate to fees on the
> network) *without* compromising any of the critical security properties
> bitcoin relies on. I think the critical piece of this is the disagreements
> around hardcoded checkpoints, which is a critical piece solving attacks
> that could be levied on a PoS chain, and how that does (or doesn't) affect
> the security model.
>
> @Eric Your proof of stake fallacy seems to be saying that PoS is worse
> when a 51% attack happens. While I agree, I think that line of thinking
> omits important facts:
> * The capital required to 51% attack a PoS chain can be made substantially
> greater than on a PoS chain.
> * The capital the attacker stands to lose can be substantially greater as
> well if the attack is successful.
> * The effectiveness of paying miners to raise the honest fraction of
> miners above 50% may be quite bad.
> * Allowing a 51% attack is already unacceptable. It should be considered
> whether what happens in the case of a 51% may not be significantly
> different. The currency would likely be critically damaged in a 51% attack
> regardless of consensus mechanism.
>
> > Proof-of-stake tends towards oligopolistic control
>
> People repeat this often, but the facts support this. There is no
> centralization pressure in any proof of stake mechanism that I'm aware of.
> IE if you have 10 times as much coin that you use to mint blocks, you
> should expect to earn 10x as much minting revenue - not more than 10x. By
> contrast, proof of work does in fact have clear centralization pressure -
> this is not disputed. Our goal in relation to that is to ensure that the
> centralization pressure remains insignifiant. Proof of work also clearly
> has a lot more barriers to entry than any proof of stake system does. Both
> of these mean the tendency towards oligopolistic control is worse for PoW.
>
> > Energy usage, in-and-of-itself, is nothing to be ashamed of!!
>
> I certainly agree. Bitcoin's energy usage at the moment is I think quite
> warranted. However, the question is: can we do substantially better. I
> think if we can, we probably should... eventually.
>
> > Proof of Stake is only resilient to ⅓ of the network demonstrating a
> Byzantine Fault, whilst Proof of Work is resilient up to the ½ threshold
>
> I see no mention of this in the pos.pdf
> <https://download.wpsoftware.net/bitcoin/pos.pdf> you linked to. I'm not
> aware of any proof that *all *PoS systems have a failure threshold of
> 1/3. I know that staking systems like Casper do in fact have that 1/3
> requirement. However there are PoS designs that should exceed that up to
> nearly 50% as far as I'm aware. Proof of work is not in fact resilient up
> to the 1/2 threshold in the way you would think. IE, if 100% of miners are
> currently honest and have a collective 100 exahashes/s hashpower, an
> attacker does not need to obtain 100 exahashes/s, but actually only needs
> to accumulate 50 exahashes/s. This is because as the attacker accumulates
> hashpower, it drives honest miners out of the market as the difficulty
> increases to beyond what is economically sustainable. Also, its been shown
> that the best proof of work can do is require an attacker to obtain 33% of
> the hashpower because of the selfish mining attack
> <https://github.com/fresheneesz/quantificationOfConsensusProtocolSecurity#the-selfish-economic-attack> discussed
> in depth in this paper: https://arxiv.org/abs/1311.0243. Together, both
> of these things reduce PoW's security by a factor of about 83% (1 -
> 50%*33%).
>
> > Proof of Stake requires other trade-offs which are incompatible with
> Bitcoin's objective (to be a trustless digital cash) — specifically the
> famous "security vs. liveness" guarantee
>
> Do you have a good source that talks about why you think proof of stake
> cannot be used for a trustless digital cash?
>
> > You cannot gain tokens without someone choosing to give up those coins -
> a form of permission.
>
> This is not a practical constraint. Just like in mining, some nodes may
> reject you, but there will likely be more that will accept you, some
> sellers may reject you, but most would accept your money as payment for
> bitcoins. I don't think requiring the "permission" of one of millions of
> people in the market can be reasonably considered a "permissioned
> currency".
>
> > 2. Proof of stake must have a trusted means of timestamping to regulate
> overproduction of blocks
>
> Both PoW and PoS could mine/mint blocks twice as fast if everyone agreed
> to double their clock speeds. Both systems rely on an honest majority
> sticking to standard time.
>
>
> On Wed, May 19, 2021 at 5:32 AM Michael Dubrovsky via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Ah sorry, I didn't realize this was, in fact, a different thread! :)
>>
>> On Wed, May 19, 2021 at 10:07 AM Michael Dubrovsky <mike at powx.org> wrote:
>>
>>> Folks, I suggest we keep the discussion to PoW, oPoW, and the BIP
>>> itself. PoS, VDFs, and so on are interesting but I guess there are other
>>> threads going on these topics already where they would be relevant.
>>>
>>> Also, it's important to distinguish between oPoW and these other
>>> "alternatives" to Hashcash. oPoW is a true Proof of Work that doesn't alter
>>> the core game theory or security assumptions of Hashcash and actually
>>> contains SHA (can be SHA3, SHA256, etc hash is interchangeable).
>>>
>>> Cheers,
>>> Mike
>>>
>>> On Tue, May 18, 2021 at 4:55 PM Erik Aronesty via bitcoin-dev <
>>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>
>>>> 1. i never suggested vdf's to replace pow.
>>>>
>>>> 2. my suggestion was specifically *in the context of* a working
>>>> proof-of-burn protocol
>>>>
>>>> - vdfs used only for timing (not block height)
>>>> - blind-burned coins of a specific age used to replace proof of work
>>>> - the required "work" per block would simply be a competition to
>>>> acquire rewards, and so miners would have to burn coins, well in
>>>> advance, and hope that their burned coins got rewarded in some far
>>>> future
>>>> - the point of burned coins is to mimic, in every meaningful way, the
>>>> value gained from proof of work... without some of the security
>>>> drawbacks
>>>> - the miner risks losing all of his burned coins (like all miners risk
>>>> losing their work in each block)
>>>> - new burns can't be used
>>>> - old burns age out (like ASICs do)
>>>> - other requirements on burns might be needed to properly mirror the
>>>> properties of PoW and the incentives Bitcoin uses to mine honestly.
>>>>
>>>> 3. i do believe it is *possible* that a "burned coin + vdf system"
>>>> might be more secure in the long run, and that if the entire space
>>>> agreed that such an endeavor was worthwhile, a test net could be spun
>>>> up, and a hard-fork could be initiated.
>>>>
>>>> 4. i would never suggest such a thing unless i believed it was
>>>> possible that consensus was possible. so no, this is not an "alt
>>>> coin"
>>>>
>>>> On Tue, May 18, 2021 at 10:02 AM Zac Greenwood <zachgrw at gmail.com>
>>>> wrote:
>>>> >
>>>> > Hi ZmnSCPxj,
>>>> >
>>>> > Please note that I am not suggesting VDFs as a means to save energy,
>>>> but solely as a means to make the time between blocks more constant.
>>>> >
>>>> > Zac
>>>> >
>>>> >
>>>> > On Tue, 18 May 2021 at 12:42, ZmnSCPxj <ZmnSCPxj at protonmail.com>
>>>> wrote:
>>>> >>
>>>> >> Good morning Zac,
>>>> >>
>>>> >> > VDFs might enable more constant block times, for instance by
>>>> having a two-step PoW:
>>>> >> >
>>>> >> > 1. Use a VDF that takes say 9 minutes to resolve (VDF being
>>>> subject to difficulty adjustments similar to the as-is). As per the
>>>> property of VDFs, miners are able show proof of work.
>>>> >> >
>>>> >> > 2. Use current PoW mechanism with lower difficulty so finding a
>>>> block takes 1 minute on average, again subject to as-is difficulty
>>>> adjustments.
>>>> >> >
>>>> >> > As a result, variation in block times will be greatly reduced.
>>>> >>
>>>> >> As I understand it, another weakness of VDFs is that they are not
>>>> inherently progress-free (their sequential nature prevents that; they are
>>>> inherently progress-requiring).
>>>> >>
>>>> >> Thus, a miner which focuses on improving the amount of energy that
>>>> it can pump into the VDF circuitry (by overclocking and freezing the
>>>> circuitry), could potentially get into a winner-takes-all situation,
>>>> possibly leading to even *worse* competition and even *more* energy
>>>> consumption.
>>>> >> After all, if you can start mining 0.1s faster than the competition,
>>>> that is a 0.1s advantage where *only you* can mine *in the entire world*.
>>>> >>
>>>> >> Regards,
>>>> >> ZmnSCPxj
>>>> _______________________________________________
>>>> bitcoin-dev mailing list
>>>> bitcoin-dev at lists.linuxfoundation.org
>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>
>>>
>>>
>>> --
>>> Michael Dubrovsky
>>> Founder; PoWx
>>> www.PoWx.org <http://www.powx.org/>
>>>
>>
>>
>> --
>> Michael Dubrovsky
>> Founder; PoWx
>> www.PoWx.org <http://www.powx.org/>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210523/732fa3c5/attachment-0001.html>

2023-06-07 22:51:15

- reply

📅 Original date posted:2021-04-16
📝 Original message:On Fri, 16 Apr 2021 at 13:47, ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
> Good morning LL,
>
> > On Tue, 16 Mar 2021 at 11:25, David A. Harding via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
> >
> > > I curious about whether anyone informed about ECC and QC
> > > knows how to create output scripts with lower difficulty that could be
> > > used to measure the progress of QC-based EC key cracking. E.g.,
> > > NUMS-based ECDSA- or taproot-compatible scripts with a security
> strength
> > > equivalent to 80, 96, and 112 bit security.
> >
> > Hi Dave,
> >
> > This is actually relatively easy if you are willing to use a trusted
> setup. The trusted party takes a secp256k1 secret key and verifiably
> encrypt it under a NUMS public key from the weaker group. Therefore if you
> can crack the weaker group's public key you get the secp256k1 secret key.
> Camenisch-Damgard[1] cut-and-choose verifiable encryption works here.
> > People then pay the secp256k1 public key funds to create the bounty. As
> long as the trusted party deletes the secret key afterwards the scheme is
> secure.
> >
> > Splitting the trusted setup among several parties where only one of them
> needs to be honest looks doable but would take some engineering and
> analysis work.
>
> To simplify this, perhaps `OP_CHECKMULTISIG` is sufficient?
> Simply have the N parties generate individual private keys, encrypt each
> of them with the NUMS pubkey from the weaker group, then pay out to an
> N-of-N `OP_CHECKMULTISIG` address of all the participants.
> Then a single honest participant is enough to ensure security of the
> bounty.
>
> Knowing the privkey from the weaker groups would then be enough to extract
> all of the SECP256K1 privkeys that would unlock the funds in Bitcoin.
Yes! Nice idea.
Another idea that came to mind is that you could also just prove equality
between the weak group's key and the secp256k1 key. e.g. generate a 160-bit
key and use it both as a secp256k1 and a 160-bit curve key and prove
equality between them and give funds to the secp256k1 key. I implemented a
proof between ed25519 and secp256k1 a little while ago for example:
https://docs.rs/sigma_fun/0.3.0/sigma_fun/ext/dl_secp256k1_ed25519_eq/index.html
This would come with the extra assumption that it's easier to break the
160-bit key on the 160-bit curve as opposed to just breaking the 160-bit
key on the 256-bit curve. Intuitively I think this is the case but I would
want to study that further before taking this approach.
LL
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210416/dc5ad2f2/attachment.html>

2023-06-07 22:51:15

- reply

📅 Original date posted:2021-04-04
📝 Original message:On Wed, 10 Mar 2021 at 11:20, Lloyd Fournier <lloyd.fourn at gmail.com> wrote:
> Hi Andrew & all,
>
> I've been working with PSBTs for a little while now. FWIW I agree with the
> change of removing the global tx and having the input/output data stored
> together in the new unified structures.
>
> One thing I've been wondering about is how output descriptors could fit
> into PSBTs. They are useful since they allow you to determine the maximum
> satisfaction weight for inputs so you can properly align fees as things get
> added. I haven't seen any discussion about including them in this revision.
> Is it simply a matter of time before they make it into a subsequent PSBT
> spec or is there something I'm missing conceptually?
>
Sipa replied to me off list some time ago and explained what I was missing.
PSBTs have all the information you could want from a descriptor already.
For example the maximum satisfaction weight can be determined from the
witness/redeem script (I had forgot these fields existed). Therefore
descriptors are more useful in higher level applications while PSBTs are
useful for communicating with signing devices. Therefore there is no reason
for PSBTs to support descriptors.
LL
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210405/911a07fe/attachment-0001.html>

2023-06-07 22:51:14

- reply

📅 Original date posted:2021-04-04
📝 Original message:On Tue, 16 Mar 2021 at 11:25, David A. Harding via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> I curious about whether anyone informed about ECC and QC
> knows how to create output scripts with lower difficulty that could be
> used to measure the progress of QC-based EC key cracking. E.g.,
> NUMS-based ECDSA- or taproot-compatible scripts with a security strength
> equivalent to 80, 96, and 112 bit security.
Hi Dave,
This is actually relatively easy if you are willing to use a trusted setup.
The trusted party takes a secp256k1 secret key and verifiably encrypt it
under a NUMS public key from the weaker group. Therefore if you can crack
the weaker group's public key you get the secp256k1 secret key.
Camenisch-Damgard[1] cut-and-choose verifiable encryption works here.
People then pay the secp256k1 public key funds to create the bounty. As
long as the trusted party deletes the secret key afterwards the scheme is
secure.
Splitting the trusted setup among several parties where only one of them
needs to be honest looks doable but would take some engineering and
analysis work.
[1] https://link.springer.com/content/pdf/10.1007/3-540-44448-3_25.pdf
Cheers,
LL
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210405/599aee9f/attachment-0001.html>

- reply

- reply

- reply

- reply

📅 Original date posted:2021-03-15
📝 Original message:On Tue, 16 Mar 2021 at 09:05, Matt Corallo via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> There have been many threads on this before, I'm not sure anything new has
> been brought up here.
>
> Matt
>
> On 3/15/21 17:48, Luke Dashjr via bitcoin-dev wrote:
> > I do not personally see this as a reason to NACK Taproot, but it has
> become
> > clear to me over the past week or so that many others are unaware of this
> > tradeoff, so I am sharing it here to ensure the wider community is aware
> of
> > it and can make their own judgements.
>
> Note that this is most definitely *not* news to this list, eg, Anthony
> brought it up in "Schnorr and taproot (etc)
> upgrade" and there was a whole thread on it in "Taproot: Privacy
> preserving switchable scripting". This issue has been
> beaten to death, I'm not sure why we need to keep hitting the poor horse
> corpse.
>
>
I read through this thread just now. The QC discussion starts roughly here:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-January/015620.html
My own (very possibly wrong) interpretation of the situation is:
1. Current addresses are very vulnerable to QC and would require hardfork
to fix (and not fix particularly well).
2. Once a QC resistant spending procedure has been developed it could be
added as a backup spending policy as a new tapleaf version (wallets would
have to opt into it).
3. If QC does get to the point where it can break ECC then we can disable
key-path spends via softfork
4. If everyone has moved their coins to Taproot addresses with a QC
resistant tapleaf backup then we're ok.
5. Since the above is almost certainly not going to happen we can simply
congratulate the new QC owners on the Bitcoin they take from old addresses
(specter of QC encourages moving to taproot which could be thought of as a
good thing).
6. Otherwise we have to hard fork to stop old addresses being spent without
a quantum resistant ZKP (oof!).
7. Once we know what we're up against a new quantum resistant segwit
version can be introduced (if it hasn't already).
8. If QC develop far enough to degrade SHA256 sufficiently (ECC probably
breaks first) then that's a whole other ball game since it affects PoW and
txids and so on and will likely require a hard fork.
The ordering of the above events is not predictable. IMO Mark's post is on
the wildly optimistic side of projected rate of progress from my limited
understanding. Either way it is strictly better to enter a QC world with
Taproot enabled and most people are using it so we can introduce QC
resistant backup spend paths without hardforks before they become
practical. Depending on what happens they may not be needed but it's good
to have the option.
On Tue, 16 Mar 2021 at 10:11, Karl-Johan Alm via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Tue, 16 Mar 2021 at 07:48, Matt Corallo via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> >
> > Overall, the tradeoffs here seem ludicrous, given that any QC issues in
> Bitcoin need to be solved in another way, and
> > can't practically be solved by just relying on the existing hash
> indirection.
>
> The important distinction here is that, with hashes, an attacker has
> to race against the spending transaction confirming, whereas with
> naked pubkeys, the attacker doesn't have to wait for a spend to occur,
> drastically increasing the available time to attack.
>
>
First note that I am enthusiastically ignorant of QC technology so please
take the following with a bowl of salt.
The premise of Mark's post is that QC progress is currently exponential
(debatable) and will continue to be (unknowable) so "months" will turn into
days and into minutes in short time period. Since QC progress is
exponential and the speedup that ECC quantum algorithms offer is
exponential you're not dealing with the typical "Moore's law" progress in
terms of time to solve a particular problem; It's like exponential
exponential (math person help me now). You could easily go from ten
thousand years to break ECC to a few seconds within a year with that rate
of progress so I don't think "slow quantum" is an adversary worth
protecting against. I would love to know if I am wrong on this point.
Cheers,
LL
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210316/62c7381f/attachment.html>