Nostr notes by Lloyd Fournier [ARCHIVE]

📅 Original date posted:2023-08-10 🗒️ Summary of this ...

2023-08-11T01:09:38+02:00

In reply to nevent1q…gw0f
_________________________

📅 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>;

📅 Original date posted:2023-07-26 🗒️ Summary of this ...

2023-07-28T17:08:07+02:00

In reply to nevent1q…kmgd
_________________________

📅 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>;

📅 Original date posted:2023-01-04 🗒️ Summary of this ...

2023-06-09T15:12:25+02:00

In reply to nevent1q…2s9z
_________________________

📅 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>;

📅 Original date posted:2021-12-08 📝 Original message: Hi ...

2023-06-09T15:04:40+02:00

In reply to nevent1q…e5xr
_________________________

📅 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>;

📅 Original date posted:2021-12-07 📝 Original message: I was ...

2023-06-09T15:04:37+02:00

In reply to nevent1q…g05a
_________________________

📅 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>;

📅 Original date posted:2021-10-13 📝 Original message: Hi ...

2023-06-09T15:04:16+02:00

In reply to nevent1q…kcwd
_________________________

📅 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>;

📅 Original date posted:2021-10-13 📝 Original message: On ...

2023-06-09T15:04:10+02:00

In reply to nevent1q…r5r0
_________________________

📅 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>;

📅 Original date posted:2021-10-11 📝 Original message: On ...

2023-06-09T15:04:09+02:00

In reply to nevent1q…0kga
_________________________

📅 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>;

📅 Original date posted:2021-10-11 📝 Original message: On ...

2023-06-09T15:04:09+02:00

In reply to nevent1q…n0ae
_________________________

📅 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>;

📅 Original date posted:2021-10-11 📝 Original message: Hey ...

2023-06-09T15:04:08+02:00

In reply to nevent1q…tcjr
_________________________

📅 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>;

📅 Original date posted:2021-06-01 📝 Original message: Hi Z, ...

2023-06-09T15:02:31+02:00

In reply to nevent1q…33n4
_________________________

📅 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>;

📅 Original date posted:2021-01-09 📝 Original message: ...

2023-06-09T15:01:50+02:00

In reply to nevent1q…6vw5
_________________________

📅 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>;

📅 Original date posted:2021-01-14 📝 Original message: On ...

2023-06-09T15:01:50+02:00

In reply to nevent1q…l97l
_________________________

📅 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>;

📅 Original date posted:2021-01-04 📝 Original message: Happy ...

2023-06-09T15:01:49+02:00

In reply to nevent1q…jp9e
_________________________

📅 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>;

📅 Original date posted:2020-12-16 📝 Original message: Hey ...

2023-06-09T15:01:45+02:00

In reply to nevent1q…pw7l
_________________________

📅 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

📅 Original date posted:2020-12-15 📝 Original message: Errr ...

2023-06-09T15:01:44+02:00

In reply to nevent1q…ywr9
_________________________

📅 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

📅 Original date posted:2020-11-30 📝 Original message: Hi ...

2023-06-09T15:01:35+02:00

In reply to nevent1q…d450
_________________________

📅 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>;

📅 Original date posted:2020-10-09 📝 Original message: Hi ...

2023-06-09T15:01:07+02:00

In reply to nevent1q…n0cd
_________________________

📅 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>;

📅 Original date posted:2020-10-08 📝 Original message: For ...

2023-06-09T15:01:05+02:00

In reply to nevent1q…nhpw
_________________________

📅 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

📅 Original date posted:2020-05-05 📝 Original message: On ...

2023-06-09T15:00:07+02:00

In reply to nevent1q…9qhh
_________________________

📅 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>;

📅 Original date posted:2020-04-28 📝 Original message: Hi ...

2023-06-09T14:59:56+02:00

In reply to nevent1q…m6ug
_________________________

📅 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>;

📅 Original date posted:2020-03-06 📝 Original message: Hi ...

2023-06-09T14:59:12+02:00

In reply to nevent1q…8nwf
_________________________

📅 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>;

📅 Original date posted:2019-12-18 📝 Original message: Hi ...

2023-06-09T14:57:44+02:00

In reply to nevent1q…hjlk
_________________________

📅 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>;

📅 Original date posted:2019-10-06 📝 Original message: Hi ...

2023-06-09T14:56:26+02:00

In reply to nevent1q…lre6
_________________________

📅 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>;

📅 Original date posted:2019-09-25 📝 Original message: This ...

2023-06-09T14:56:13+02:00

In reply to nevent1q…4sd5
_________________________

📅 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>;

📅 Original date posted:2019-01-02 📝 Original message: Happy ...

2023-06-09T14:53:41+02:00

In reply to nevent1q…ewz8
_________________________

📅 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>;

📅 Original date posted:2021-04-20 📝 Original message: Hi ...

2023-06-09T14:39:53+02:00

In reply to nevent1q…50lt
_________________________

📅 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>;

📅 Original date posted:2023-05-08 🗒️ Summary of this ...

2023-06-08T01:21:02+02:00

In reply to nevent1q…vpz6
_________________________

📅 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>;

📅 Original date posted:2023-05-01 🗒️ Summary of this ...

2023-06-08T01:21:00+02:00

In reply to nevent1q…c8lm
_________________________

📅 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>;

📅 Original date posted:2023-02-07 🗒️ Summary of this ...

2023-06-08T01:19:24+02:00

In reply to nevent1q…fg08
_________________________

📅 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>;

📅 Original date posted:2022-01-24 📝 Original message:Hi ...

2023-06-08T01:02:40+02:00

In reply to nevent1q…jlg8
_________________________

📅 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>;

📅 Original date posted:2021-06-13 📝 Original message:On ...

2023-06-08T00:54:29+02:00

In reply to nevent1q…eq35
_________________________

📅 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>;

📅 Original date posted:2021-06-06 📝 Original message:Hi ...

2023-06-08T00:54:25+02:00

In reply to nevent1q…6384
_________________________

📅 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>;

📅 Original date posted:2021-06-16 📝 Original message:@James ...

2023-06-08T00:54:15+02:00

In reply to nevent1q…evyk
_________________________

📅 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>;

📅 Original date posted:2021-05-23 📝 Original message:Hi ...

2023-06-08T00:52:53+02:00

In reply to nevent1q…9x3q
_________________________

📅 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>;

📅 Original date posted:2021-04-16 📝 Original message:On ...

2023-06-08T00:51:15+02:00

In reply to nevent1q…5y0f
_________________________

📅 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>;

📅 Original date posted:2021-04-04 📝 Original message:On ...

2023-06-08T00:51:14+02:00

In reply to nevent1q…5yng
_________________________

📅 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>;

📅 Original date posted:2021-04-04 📝 Original message:On ...

2023-06-07T20:31:12+02:00

In reply to nevent1q…l9lz
_________________________

📅 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>;

📅 Original date posted:2020-10-04 📝 Original message:Hi ...

2023-06-07T20:27:19+02:00

In reply to nevent1q…m3fl
_________________________

📅 Original date posted:2020-10-04
📝 Original message:Hi Leonardo,

I can't tell you what the BIP32 author was thinking but if I put
myself in their shoes these are the reasons I might have done it this
way:

1. Use HMAC rather than normal SHA2 -- this is just best practice for
key derivation (even though I don't think it would make a difference
to security if you are strictly following the spec).
2. Use 512-bit rather than 256-bit -- Probably something to do with
(1) -- since I'm using an HMAC I've gotta put something as the key. I
don't want re-use the 256-bits for the secp256k1 secret key for this
since an integer mod q is not the same as 256 random bits (or I don't
want to have to make the argument in the design doc that it actually
is; plus what if someone starts using this for different curve and I'm
not around to tell them no). So I split the 512-bits and use the last
256bits as the key for the child derivation.

I don't think there is any fundamental flaw with what you suggest (I
am doing something similar for a project). I guess the issues you
pointed out with the scheme were probably not on the author's mind. To
me they don't seem too severe but I haven't spent much time developing
wallets.

LL

On Wed, Sep 30, 2020 at 4:02 AM Leonardo Comandini via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Hi all,
>
> BIP32 [1] says: "In order to prevent these from depending solely on the key
> itself, we extend both private and public keys first with an extra 256 bits of
> entropy. This extension, called the chain code...".
>
> My argument is that the chain code is not needed.
> To support such claim, I'll show a schematic of BIP32 operations to be compared
> with an alternative proposal and discuss the differences.
>
> I have two main questions:
> - Is this claim false?
> - Has anyone shared this idea before?
>
> ## BIP32 schematic
>
> Let `G` be the secp256k1 generator.
> Let `i` be the child index.
> Let `(p, P=pG)` and `(p_i, P_i=p_iG)` be the parent and i-th child keypairs
> respectively.
> Let `c` and `c_i` be the corresponding chain codes.
> Let `h1, h2, h3, h4` be hash functions so that the formulae below match the
> definitions given in BIP32 [2].
> Define private and public child derivation as follow:
>
> p_i(p, c, i) = (i < 2^31) p + h1(c, pG, i)
> (i >= 2^31) p + h2(c, p, i)
>
> c_i(p, c, i) = (i < 2^31) h3(c, pG, i)
> (i >= 2^31) h4(c, p, i)
>
> P_i(P, c, i) = (i < 2^31) P + h1(c, P, i)G
> (i >= 2^31) not possible
>
> c_i(P, c, i) = (i < 2^31) h3(c, P, i)
> (i >= 2^31) not possible
>
> The above formula for unhardened public derivation resembles a pay-to-contract
> [3] scheme.
>
> ## Alternative proposal
>
> Let `h` be an adequately strong hash function which converts its output to
> integer.
> Consider the following derivation scheme:
>
> p_i(p, i) = (i < 2^31) p + h(pG, i)
> (i >= 2^31) h(p, i)
>
> P_i(P, i) = (i < 2^31) P + h(P, i)G
> (i >= 2^31) not possible
>
> Which is basically the above one without the chaincode.
>
> ## Considerations
>
> I claim that this has the same properties as BIP32 [4]:
> - The problem of finding `p` given `p_i, i` relies on brute-forcing `h` in the
> same way the analogous problem relies on brute-forcing `h2` in BIP32.
> - The problem of determining whether `{p_i, i}_i=1..n` are derived from a common
> parent `p` relies on brute-forcing `h` in the same way the analogous problem
> relies on brute-forcing `h2` in BIP32.
> - Given `i < 2^31, p_i, P`, an attacker can find `p`. This is analogous to
> BIP32, where the parent extended pubkey is needed (`P, c`). One could argue
> that `c` is never published on the blockchain, while `P` may be. On the other
> hand most wallets either use hardened derivation (so the attack does not work)
> or derive scriptpubkeys from keys at the same depth (so the parent key is
> never published on the blockchain).
> Anyway, if the parent public key is kept as secret as BIP32 extended keys are,
> then the situation is analogous to BIP32's.
>
> _If_ these claims are correct, the proposed derivation scheme has two main
> advantages:
>
> 1) Shorter backups for public and private derivable keys
>
> Backups are especially relevant for output descriptors. For instance, when using
> a NofM multisig, each participant must backup M-1 exteneded public keys and its
> extended private key, which can be included in an output descriptor. Using the
> proposed derivation reduces the backup size by `~M*32` bytes.
>
> 2) User-friendly backup for child keys
>
> Most wallets use user-friendly backups, such as BIP39 [5] mnemonics. They map
> 16-32 bytes of entropy to 12-24 words. However BIP32 exteneded keys are at least
> 64(65) bytes (key and chain code), so they cannot be mapped back to a
> mnemonic.
>
> A common wallet setup is (`->` one-way derivation, `<->` two-way mapping):
>
> entropy (16-32 bytes) <-> user-friendly backup
> -> BIP32 extended key (64-65 bytes)
> -> BIP32 extended child keys (64-65 bytes)
>
> With the proposed derivation, it would be possible to have:
>
> derivable private key (32 bytes) <-> user-friendly backup
> -> derivable public key (33 bytes) <-> user-friendly backup
> -> derivable child keys (32-33 bytes) <-> user-friendly backup
>
> This would allow having mnemonics for subaccount keys.
>
> ## References
>
> [1] https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki
>
> [2] h1, h2, h3 and h4 can be defined as follows
>
> Ip(c, p, i) = (i >= 2^31) HMAC-SHA512(c, 0x00 || ser256(p) || ser32(i))
> (i < 2^31) HMAC-SHA512(c, pG || ser32(i))
>
> IP(c, P, i) = (i >= 2^31) not possible
> (i < 2^31) HMAC-SHA512(c, P || ser32(i))
>
> h1(c, P, i) = parse256(IP(c, P, i)[:32])
> h2(c, p, i) = parse256(Ip(c, p, i)[:32])
> h3(c, P, i) = IP(c, P, i)[32:]
> h4(c, p, i) = Ip(c, p, i)[32:]
>
> [3] https://blockstream.com/sidechains.pdf Appendix A
>
> [4] https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki#security
>
> [5] https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki
>
>
> --
> Leonardo
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

📅 Original date posted:2020-08-13 📝 Original message:Thanks ...

2023-06-07T20:26:20+02:00

In reply to nevent1q…ylp0
_________________________

📅 Original date posted:2020-08-13
📝 Original message:Thanks for bringing this discovery up and a big thanks to Peter Dettman for
working on this.

I second what Nadav said. Removing pointless complexity is worth it even at
this stage. I also maintain a non-libsecp implementation of BIP340 etc.
Having two ways to convert an xonly to a point is a pain if you are trying
to maintain type safe apis. If there is no performance penalty (or even a
small one in the short term) to unifying xonly -> point conversion it's
worth it from my perspective.

LL

On Thu, Aug 13, 2020 at 6:29 AM Nadav Kohen via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> Hello Pieter and all,
>
> I am one of the maintainers of Bitcoin-S[1] and I maintain our secp256k1
> bindings (via JNI) as well as our (inefficient) bouncy castle fallback
> implementations of all secp256k1 functionality we depend on including
> Schnorr signatures. In light of this new information that there is no real
> downside to using evenness as the nonce tie-breaker, I am personally very
> in favor of this change as it strictly simplifies things as well as making
> types consistent between nonces and persistent signing keys (I can get rid
> of our SchnorrNonce type :). An additional minor benefit not already
> mentioned is that in places in our codebase where deserialized data is just
> being passed around and not used, we currently require a computation to go
> from a (x-only) SchnorrNonce to an ECPublicKey whereas going from a
> SchnorrPublicKey simply requires pre-pending a 0x02 byte.
>
> I am likely not aware of the entire impact that changing the BIP at this
> stage would have but from my view (of having to update bindings and test
> vectors and my fallback implementation, as well as wanting to get a stable
> branch on secp256k1-zkp containing both ECDSA adaptor signatures and
> Schnorr signatures for use in Discreet Log Contracts), I think this change
> is totally worth it and it will only become harder to make this
> simplification in the future. The schnorrsig branch has not yet been merged
> into secp256k1 (and is nearing this stage I think) and so long as making
> this change doesn't set us back more than a month (which seems unlikely) I
> am personally in favor of making this change. Glad to hear other's thoughts
> on this of course but I figured I'd voice my support :)
>
> Best,
> Nadav
>
> [1] https://github.com/bitcoin-s/bitcoin-s/
>
>
>
> On Wed, Aug 12, 2020 at 2:04 PM Pieter Wuille via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Hello all,
>>
>> The current BIP340 draft[1] uses two different tiebreakers for conveying
>> the Y coordinate of points: for the R point inside signatures squaredness
>> is used, while for public keys evenness is used. Originally both used
>> squaredness, but it was changed[2] for public keys after observing this
>> results in additional complexity for compatibility with existing systems.
>>
>> The reason for choosing squaredness as tiebreaker was performance: in
>> non-batch signature validation, the recomputed R point must be verified to
>> have the correct sign, to guarantee consistency with batch validation.
>> Whether the Y coordinate is square can be computed directly in Jacobian
>> coordinates, while determining evenness requires a conversion to affine
>> coordinates first.
>>
>> This argument of course relies on the assumption that determining whether
>> the Y coordinate is square can be done more efficiently than a conversion
>> to affine coordinates. It appears now that this assumption is incorrect,
>> and the justification for picking the squaredness tiebreaking doesn't
>> really exist. As it comes with other trade-offs (it slows down signing, and
>> is a less conventional choice), it would seem that we should reconsider the
>> option of having the R point use the evenness tiebreaker (like public keys).
>>
>> It is late in the process, but I feel I owe this explanation so that at
>> least the possibility of changing can be discussed with all information. On
>> the upside, this was discovered in the context of looking into a cool
>> improvement to libsecp256k1[5], which makes things faster in general, but
>> specifically benefits the evenness variant.
>>
>>
>> # 1. What happened?
>>
>> Computing squaredness is done through the Jacobi symbol (same inventor,
>> but unrelated to Jacobian coordinates). Computing evenness requires
>> converting points to affine coordinates first, and that needs a modular
>> inverse. The assumption that Jacobi symbols are faster to compute than
>> inverses was based on:
>>
>> * A (possibly) mistaken belief about the theory: fast algorithms for both
>> Jacobi symbols and inverses are internally based on variants of the same
>> extended GCD algorithm[3]. Since an inverse needs to extract a full big
>> integer out of the transition steps made in the extgcd algorithm, while the
>> Jacobi symbol just extracts a single bit, it had seemed that any advances
>> applicable to one would be applicable to the other, but inverses would
>> always need additional work on top. It appears however that a class of
>> extgcd algorithms exists (LSB based ones) that cannot be used for Jacobi
>> calculations without losing efficiency. Recent developments[4] and a
>> proposed implementation in libsecp256k1[5] by Peter Dettman show that using
>> this, inverses in some cases can in fact be faster than Jacobi symbols.
>>
>> * A broken benchmark. This belief was incorrectly confirmed by a broken
>> benchmark[6] in libsecp256k1 for the libgmp-based Jacobi symbol calculation
>> and modular inverse. The benchmark was repeatedly testing the same constant
>> input, which apparently was around 2.5x faster than the average speed. It
>> is a variable-time algorithm, so a good variation of inputs matters. This
>> mistake had me (and probably others) convinced for years that Jacobi
>> symbols were amazingly fast, while in reality they were always very close
>> in performance to inverses.
>>
>>
>> # 2. What is the actual impact of picking evenness instead?
>>
>> It is hard to make very generic statements here, as BIP340 will hopefully
>> be used for a long time, and hardware advancements and algorithmic
>> improvements may change the balance. That said, performance on current
>> hardware with optimized algorithms is the best approximation we have.
>>
>> The numbers below give the expected performance change from squareness to
>> evenness, for single BIP340 validation, and for signing. Positive numbers
>> mean evenness is faster. Batch validation is not impacted at all.
>>
>> In the short term, for block validation in Bitcoin Core, the numbers for
>> master-nogmp are probably the most relevant (as Bitcoin Core uses
>> libsecp256k1 without libgmp, to reduce consensus-critical dependencies).
>> If/when [5] gets merged, safegcd-nogmp will be what matters. On a longer
>> time scale, the gmp numbers may be more relevant, as the Jacobi
>> implementation there is certainly closer to the state of the art.
>>
>> * i7-7820HQ: (verify) (sign)
>> - master-nogmp: -0.3% +16.1%
>> - safegcd-nogmp: +6.7% +17.1%
>> - master-gmp: +0.6% +7.7%
>> - safegcd-gmp: +1.6% +8.6%
>>
>> * Cortex-A53: (verify) (sign)
>> - master-nogmp: -0.3% +15.7%
>> - safegcd-nogmp: +7.5% +16.9%
>> - master-gmp: +0.3% +4.1%
>> - safegcd-gmp: 0.0% +3.5%
>>
>> * EPYC 7742: (verify) (sign)
>> - master-nogmp: -0.3% +16.8%
>> - safegcd-nogmp: +8.6% +18.4%
>> - master-gmp: 0.0% +7.4%
>> - safegcd-gmp: +2.3% +7.8%
>>
>> In well optimized cryptographic code speedups as large as a couple
>> percent are difficult to come by, so we would usually consider changes of
>> this magnitude relevant. Note however that while the percentages for
>> signing speed are larger, they are not what is unexpected here. The choice
>> for the square tiebreaker was intended to improve verification speed at the
>> cost of signing speed. As it turns out that it doesn't actually benefit
>> verification speed, this is a bad trade-off.
>>
>>
>> # 3. How big a change is it
>>
>> * In the BIP:
>> - Changing both invocations of `has_square_y` to `has_even_y`.
>> - Changing the `lift_x_square_y` invocation to `lift_x_even_y`.
>> - Applying the same change to the test vector generation code, and the
>> resulting test vectors.
>> * In the libsecp256k1:
>> - An 8-line patch to the proposed BIP340 implementation[7]: see [8]
>> * In Bitcoin Core:
>> - Similarly small changes to the Python test reimplementation[9]
>> * Duplicating these changes in other draft implementations that may
>> already exist.
>> * Review for all the above.
>>
>>
>> # 4. Conclusion
>>
>> We discovered that the justification for using squaredness tiebreakers in
>> BIP340 is based on a misunderstanding, and recent developments show that it
>> may in fact be a somewhat worse choice than the alternative. It is a
>> relatively simple change to address this, but that has be weighed against
>> the impact of changing the standard at this stage.
>>
>> Thoughts?
>>
>>
>> # 5. References
>>
>> [1]
>> https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki#design
>> [2]
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-February/017639.html
>> [3] https://en.wikipedia.org/wiki/Extended_Euclidean_algorithm
>> [4] https://gcd.cr.yp.to/safegcd-20190413.pdf
>> [5] https://github.com/bitcoin-core/secp256k1/pull/767
>> [6] https://github.com/bitcoin-core/secp256k1/pull/797
>> [7] https://github.com/bitcoin-core/secp256k1/pull/558
>> [8]
>> https://github.com/sipa/secp256k1/commit/822311ca230a48d2c373f3e48b91b2a59e1371d6
>> [9] https://github.com/bitcoin/bitcoin/pull/17977
>>
>>
>> Cheers,
>>
>> --
>> Pieter
>>
>> _______________________________________________
>> 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/20200813/45cce79a/attachment.html>;

📅 Original date posted:2020-05-12 📝 Original message:A ...

2023-06-07T20:24:39+02:00

In reply to nevent1q…lrru
_________________________

📅 Original date posted:2020-05-12
📝 Original message:A quick correction to my post:

>
> Here's where the truly novel part comes in. Ruben solves this by extending
> the standard *TLC contract:
> 1. Bob redeem with secret
> 2. Alice refund after T1
> 3. Bob redeem without secret after T2
>
> This is actually:

1. Bob redeem with redeem secret
2. Alice refund after T1 with refund secret
3. Bob redeem without secret after T2

The fact that Alice reveals a secret when she refunds is crucial.

LL
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200512/86347834/attachment.html>;

📅 Original date posted:2020-05-12 📝 Original message:Ruben, ...

2023-06-07T20:24:39+02:00

In reply to nevent1q…m2ec
_________________________

📅 Original date posted:2020-05-12
📝 Original message:Ruben,

In my opinion, this protocol is theoretical breakthrough as well as a
practical protocol. Well done! I want to try and distil the core abstract
ideas here as they appear to me. From my view, the protocol is a
combination of two existing ideas and one new one:

1. In atomic swaps you can make the refund transaction on one chain
dependent on the refund on the other using secret revelation. Thus only one
chain needs to have a timelock and the other refund can be conditioned on a
secret that is revealed when that first refund goes through. (This idea is
in the monero atomic swap [1]).
2. Secret revelations can be used to give unconstrained spending power to
one party. With an adaptor signature, rather than reveal a decryption key
for another signature, you can just make the decryption key your signing
key in the multisig so when you reveal it with the adaptor signautre the
other party gains full knowledge of the private key for the output and can
spend it arbitrarily. (this is just folklore and already what happens in
HTLCs -- though it looks like lightning people are about to get rid of the
unconstrained spend I think).

The combination of these two ideas is novel in itself. The problem with
idea (2) is that your unconstrained spending power over an output doesn't
matter much if there is a pre-signed refund transaction spending from it --
you still have to spend it before the refund becomes valid. But if you
bring in idea (1) this problem goes away!
However, you are left with a new problem: What if the party with the
timelock never refunds? Then the funds are locked forever.

Here's where the truly novel part comes in. Ruben solves this by extending
the standard *TLC contract:
1. Bob redeem with secret
2. Alice refund after T1
3. Bob redeem without secret after T2

We might call this a "Forced Refund *TLC". Alice must claim the refund or
lose her money. This forces the refund secret revelation through
punishment. If Alice refuses to refund Bob gets the asset he wanted anyway!

The resulting protocol you get from applying these ideas is three
transactions. At the end, one party has their funds in a non HD key output
but if they want that they can just transfer it to an HD output in which
case you get four transactions again. Thus I consider this to be a strict
improvement over the four transaction protocol. Furthermore, one of the
chains does not need a timelock. This is remarkable as the four transaction
atomic swap is one of the most basic and most studied protocols. I
considered it to be kind of "perfect" in a way. It just goes to show that
this field is still very new and there are still things to discover in what
we think is the most well trodden ground.

I don't want to ignore that Ruben presents us with a two transaction
protocol. He made a nice video explaining it here:
https://www.youtube.com/watch?v=TlCxpdNScCA. It is harder to see the
elegance of the idea in the two tx protocol because it involves revocation
and relative timelocks etc. Actually, it is straightforward to naively
achieve a two tx atomic swap with payment channels:
1. Alice and Bob set up payment channels to each other on different chains
2. They atomic swap the balances of the channels off-chain using HTLCs
using the standard protocol.
3. Since one party exclusively owns the funds in each channel the party
with no funds simply reveals their key in the funding OP_CHECKMULTISIG to
the other
4. Both parties now watch the chain to see if the other tries to post a
commitment transactions.

The advantages that Ruben's two tx protocol has over this is that timelocks
and monitoring is only needed on one of the chains. This is nothing to
scoff at but for me the three tx protocol is the most elegant expression of
the idea and the two tx protocol is a more optimised version that might
make sense in some circumstances.

[1] https://github.com/h4sh3d/xmr-btc-atomic-swap/blob/master/README.md

LL
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200512/b0a4d1a9/attachment.html>;

📅 Original date posted:2020-03-24 📝 Original message:Hi ...

2023-06-07T20:23:33+02:00

In reply to nevent1q…6rta
_________________________

📅 Original date posted:2020-03-24
📝 Original message:Hi List,

I felt this topic deserved it's own thread but it follows on from the
mailing list post [2] announcing a new PR [1] to change BIP-340 in several
ways, including adding random auxiliary data into the nonce
derivation function. Rather than hashing the randomness with the secret key
and message etc, the randomness is hashed then XOR'd (^) with the secret
key and the result is hashed like so to determine the secret nonce k:

(1) k = H_derive( sec_key ^ H_aux(rand) || pub_key_x || message)

The claim made in the mailing list post is that this is more secure against
"differential power analysis" (DPA) attacks than just doing the simpler and
more efficient:

(2) k = H_derive(sec_key || rand || pub_key_x || message)

The TL;DR here is that I don't think this is the case.

There was no citation for this claim, so I did some digging and found two
papers that seemed like they might be the origin of the idea [3,4] (I had
no idea about these attacks before). A relatively easy to understand
explanation of DPA attacks against is in [3]:

The fundamental principle behind all DPA attacks is that at some point in
> an algorithm’s execution, a function f exists that combines a fixed secret
> value with a variable which an attacker knows. An attacker can form
> hypotheses about the fixed secret value, and compute the corresponding
> output values of f by using an appropriate leakage model, such as the
> Hamming Distance model. The attacker can then use the acquired power
> consumption traces to verify her hypotheses, by partitioning the
> acquisitions or using Pearson’s correlation coefficient. These side-channel
> analysis attacks are aided by knowledge of details of the implementation
> under attack. Moreover, these attacks can be used to validate hypotheses
> about implementation details. In subsequent sections, these side-channel
> analysis attacks are referred to as DPA attacks.

For example, in the original BIP-340 proposal the nonce derivation was
vulnerable to DPA attacks as it was derived simply by doing
H_derive(sec_key || message). Since, the message is known to the attacker
and variable (even if it is not controller by her), the SHA256 compression
function run on (sec_key || message) may leak information about sec_key. It
is crucial to understand that just hashing sec_key before passing it into
the H_derive does *not* fix the problem. Although the attacker would be
unable to find sec_key directly, they could learn H(sec_key) and with that
know all the inputs into H_derive and therefore get the value of the secret
nonce k and from there extract the secret key from any signature made with
this nonce derivation algorithm.

The key thing I want to argue with this post is that there is no advantage
of (1) over (2) against DPA attacks, at least not given my understanding of
these papers. The way the attack in [3] works is by assuming that
operations in the compression function leak the "hamming distance" [5] (HD)
between the static secret thing that is being combined with the variable
public thing. In practice the attack involves many particulars about SHA256
but that is, at a high level, the right way to simplify it I think. The way
the paper suggests to fix the problem is to mask the secret data with
secret randomness before each sensitive operation and then strip off the
secret randomness afterwards. This seems to be the inspiration for the
structure of updated BIP-340 (1), however I don't believe that it provides
any extra protection over (2). My argument is as follows:

Claim A: If the randomness used during signing is kept secret from the
attacker then (2) is secure against DPA.

Since SHA256 has 64-byte blocks the hash H_derive(sec_key || rand ||
pub_key_x || message) will be split up into two 64 byte blocks, one
containing secret data (sec_key || rand) and the other containing data
known to the attacker (pub_key_x || message). The compression function will
run on (sec_key || rand) but DPA will be useless here because the
HD(sec_key, rand) will contain no information about sec_key since rand is
also secret. The output of the compression function on the first block will
be secret but *variable* so the intermediate hash state will not reveal
useful information when compressed with the second block.

Then I thought perhaps (1) is more robust in the case where the randomness
is known by the attacker (maybe the attacker can physically modify the
chipset to control the rng). We'd have to assume that the sec_key ^
H_aux(rand) isn't vulnerable to DPA (the LHS is under the control of the
attacker) to be true. Even under this assumption it turned out not to be
the case:

Claim B: If the randomness used during signing is known to the attacker,
then (1) is not secure against DPA.

In (1) there are 96 bytes to be hashed and therefore two SHA256 blocks:
(H_aux(sec_key) ^ rand || pub_key_x) and (message). During the first
compression function call the attacker gets the HD of:
HD( sec_key ^ H_aux(rand), pub_key_x)
which is equal to the following as applying the same XOR to both sides does
not change the HD.
HD(sec_key, H_aux(rand) ^ pub_key_x)
Since the LHS is secret and static, and the RHS is variable and known to
the adversary we have a successful DPA attack -- the attacker will learn
sec_key after enough runs.

Maybe it's just a general rule if you can't produce randomness hidden to
the attacker then no defence is possible against DPA but I wanted to check
this anyway.

My conclusion from this is that (2) is preferable to (1) because it is
simpler and more efficient (it has one less SHA256 compression run) and no
less secure against DPA (in this model). This is not really my area so
perhaps there is a justification for (1) over (2) that I don't understand
yet. If so, someone needs to write it down! If not then I think changing
the proposal to (2) is preferable.

Cheers,

LL

[1] https://github.com/bitcoin/bips/pull/893
[2]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-February/017639.html
[3] http://www.oocities.org/mike.tunstall/papers/MTMM07.pdf
[4] https://www.cryptoexperts.com/sbelaid/articleHMAC.pdf
[5] https://en.wikipedia.org/wiki/Hamming_distance
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200325/e3675bf9/attachment.html>;

📅 Original date posted:2020-03-04 📝 Original message:Hi ...

2023-06-07T20:23:17+02:00

In reply to nevent1q…2jhd
_________________________

📅 Original date posted:2020-03-04
📝 Original message:Hi List,

I recently presented a poster at the Financial Cryptography conference
'2020 which you can find here:
https://github.com/LLFourn/taproot-ggm/blob/master/main.pdf. It attempts
to show the security requirements for the tweak hash function in Taproot.
In this post I'll give a long description of it but first let me tl;dr:

Taproot requires no new assumptions of SHA256 over what are already made by
Schnorr signatures themselves with one exception: when using a
non-interactive key generation protocol to produce a Taproot internal key
(e.g MuSig). To prove security in this scenario we need a make an
additional assumption about SHA256: as well as being collision resistant
(i.e. find two hashes h_1 - h_2 = 0), it must satisfy a more general kind
of collision resistance where it is hard to find h_1 - h_2 = d for *any d*
when the adversary is challenged to find h_1 and h_2 with random prefixes.
This is obviously a plausible assumption. Put informally, it says that zero
is not a special case where finding collisions is difficult but rather
solving the 2-sum problem is hard for all values of d (when challenged with
random prefixes).

Now the long version.

My motivation for creating this poster came from questions I had after
discussions in Taproot Study Group #18 (this study group initiative was a
great idea btw). The main question I had was "Why is Taproot binding?" i.e.
why is it true that I can only commit to one Merkle root. Isn't it possible
that a malicious party could produce a second covert Taproot spend that
none of the other parties to the output agreed to? I submitted a poster
proposal to FC to force myself to get to the bottom of it.

The premise of the poster is to use the Generic Group Model to try and
figure out how the hash function would have to fail for Taproot to be
insecure. Most of the poster is taken up cartoon reductions I made to
remind myself as to why what I was saying might be true. They are
incomplete and difficult to parse on their own so hopefully this post is a
useful companion to them.

=== The Security of Taproot ===

There are three scenarios/games we must consider when asking whether
Taproot is secure in the context of Bitcoin:

1. Taproot Forge: Forging taproot spends must be hard. The adversary must
not be able to take a public key off the blockchain and produce a forged
Taproot spend from it.
2. Covert Taproot: When an adversary is executing a multi-party key
generation protocol (e.g. MuSig) it should be hard for them to produce a
covert malicious Taproot spend from the joint key i.e. when honest parties
think there is no Taproot on a key there shouldn't be any Taproot on the
key. Note this is not guaranteed to be hard by 1 being hard.
3. Second Covert Taproot: Like 2, except that if honest parties agree to a
Taproot spend then the adversary shouldn't be able to generate a second
Taproot spend they are unaware of.

Properties (1) and (2) can be argued succinctly if we just prove that
Taproot is a secure commitment scheme. It should be clear that if a Taproot
external key T = X + H(X||m)*G is a secure commitment scheme (Hiding and
Binding) to any arbitrary message m, then it is a secure commitment scheme
to a Merkle root. If so, then properties (1) and (3) hold. (1) holds
because if you can create an opening to a commitment not generated by you,
you either broke hiding (if your opening is the same as the honest one) or
broke binding (if it's different). (3) holds because you must have broken
binding as there are now two openings to the same commitment.

Property (2) is more difficult to argue as it depends on the multi-party
key generation protocol. Case in point: Taproot is completely broken when
combined with a proof of knowledge key generation protocol where along with
their public keys each party provides a proof of knowledge of the secret
key. Where X_1 is the key of the honest party, the malicious party can
choose their key X_2 to be G*H(X_1 || m) where m is a malicious Merkle
root. Clearly the malicious party has a covert Taproot for X = X_1 + X_2
and can produce a proof of knowledge for X_2.

Given this definition of security, we now move onto how we should model the
problem to prove they hold.

=== Generic Group Model vs Random Oracle Model ===

For practical cryptographic schemes you often have to idealise one of its
components to prove it secure. The most popular candidate for idealisation
is the hash function in the Random Oracle Model (ROM), which idealises a
hash function as a "random oracle", a black box which spits out random
values for each input. For example, the original "forking lemma" proof by
Pointcheval and Stern [1] shows the Schnorr signature scheme is unforgeable
in this model if the discrete logarithm problem is hard. In other words,
idealising the hash function allows us to isolate what security assumptions
we are making about the group (e.g. the discrete logarithm problem being
hard in it).

But what if we want to know what assumptions we are making about the hash
function? Does the challenge hash in Schnorr signatures have to be
collision resistant or pre-image resistant or something else? To answer
this question Neven et al.[2] analysed Schnorr signatures by idealising the
group in the "Generic Group Model" (GGM). By idealising the group, they
were able to isolate the security requirements of the hash function away
from any assumptions being made about the group. In the GGM, the group
becomes a black box which, when given two group elements, spits out their
subtraction (for technical reasons it's subtraction rather than addition).
The adversary can only produce new group elements by querying the oracle.
Using the GGM they prove that the hash function needs to be Random-Prefix
Preimage (RPP) resistant (and Random-Prefix Second-Preimage resistant)
which are strictly weaker assumptions than collision resistance.

=== Taproot in the Random Oracle Model ===

Proving that Taproot is a binding commitment scheme in the ROM is
straightforward (hiding is too but I'm going to skip that). To produce two
openings for the same external key, the adversary must have two random
oracle queries H(X || m) that result in the same external key T = X +
H(X||m)*G. Since H(X||m)*G is an (almost) uniformly distributed group
element in the ROM, T is also uniformly distributed, thus breaking the
binding of Taproot is equivalent to solving a birthday problem of size
2^256 (the same as finding hash collisions in the ROM). Note that this
statement is true regardless of the discrete logarithm problem being hard
or not. This proves properties (1) and (3).

For property (2) let's consider MuSig as the key generation protocol. If we
model the MuSig key tweak hash function as a random oracle as well then for
every key X_2, the adversary has to query the MuSig hash oracle to
determine the joint key X = X_1*H(X_1||L) + X_2*H(X_2| L). As before, it is
clear to see that this makes X a uniform group element for every X_2 in the
ROM. Liekwise for every covert Taproot internal key C and message pair the
external key T = C + H(C||m) *G will be uniform as before in the ROM. Thus,
breaking property (2) is the same as finding T = X, where you the adversary
can only sample T and X from uniform distributions and so we have another
birthday problem. This completes the proof of all three properties.

Poelstra presented a proof in the ROM for the security of Taproot [3]. It
frames Taproot as a way of combining two signature schemes into one public
key (in our case Schnorr and Tapscript). He uses a similar line of
reasoning to what I have just presented in his proof (Lemma 1, step 3) but
this approach brings in many other considerations that I think can be
avoided by modelling it as a commitment scheme. Note that this proof only
shows that Taproot forgeries are hard i.e. property (1).

=== Taproot in the Generic Group Model ===

The ROM proof is an important first step -- if it couldn't be proved secure
in ROM then it would probably be completely broken. But Taproot, unlike
Schnorr, only relies on the security of its hash function when viewed as a
commitment scheme so it would be prudent to figure out what those
properties are. By using the ROM we artificially hide what those properties
from our analysis. As in the case of Schnorr, we can idealise the group in
the GGM to help isolate the hash function's properties.

To prove Taproot was a binding commitment scheme in the GGM I had to
introduce a new property I called "Chosen Offset Prefix-Collision" (COPC)
resistance. The precise security game is sketched in the poster, but I like
to describe it as a more general kind of collision resistance. Instead of
it being hard to find two preimages a and b where H(a) - H(b) = 0, it must
be hard to find H(P_1 || a) - H(P_2 || b) = d for any d (not just d = 0)
with random prefixes P_1 and P_2 given by the challenger (d chosen by the
adversary). COPC is necessary and sufficient to prove Taproot is a secure
commitment scheme in the GGM (the proof for this isn't in the poster but is
very similar to Second Covert Taproot proof).

This was not the ideal outcome, so I decided to analyse properties Taproot
(1) and (3) independently rather than just imply them from the commitment
scheme result. What ended up in the poster is three independent proofs for
each Taproot security property with MuSig assumed to be key generation
scheme for properties (2) and (3). Here's a summary of what I concluded for
each property.

1. Taproot Forge: In the GGM, an adversary who forges Taproot openings can
be used as a black box to mount a "Random Prefix-Preimage" (RPP) attack
against the hash function. This is a very good result as RPP is already
required by Schnorr. Essentially, this means anyone who can forge Taproot
spends can also forge Schnorr signatures.

2. Covert Taproot (MuSig): For this problem I had to split the adversary
into two types: those who query their MuSig public key X_2 from the group
oracle before their malicious internal key C and those that query C first
or set X_2 = C. For the first case I was able to show another reduction
from RRP (which shown in the poster). The other case I was able to break
preimage resistance as long as I modelled the MuSig hash function as a
random oracle (not shown in the poster and this is only from memory). In
both cases the reduction does not work for n-party MuSig (only for 2
parties). Obviously, this is not totally satisfying. The problem with
n-party MuSig is it becomes exponentially more unlikely (in n) for the
reduction to guess which keys the adversary will use for their MuSig keys.

3. Second Covert Taproot (MuSig): Once again, this is where honest parties
agree on a joint key and Taproot spend from it, but the adversary is
somehow able to create a second covert spend during the key generation
phase. This is where I found that COPC does actually need to be hard to
ensure this property. This is true regardless of the number of parties.
Thus this is the only scenario where you need the additional security
assumption to prove security.

== Concluding Remarks ==

The main important take away of this is that there is actually a small
security cost to using a group element as both a commitment scheme and as a
public key. It would be very surprising if we got this for free. By using
the random oracle model we merely hide this in the idealisation of the hash
function. The generic group model exposes it. The question is: is the cost
worth it and who bears it? Here's what I consider to be the most important
points:

1. You only take on this COPC assumption if you use Tapscript. If you're
just putting your funds into a Taproot output without an internal key,
either as a group or an individual there is no extra security assumption.
(with the caveat that my technique only really works for 2-party MuSig).
2. The COPC assumption seems to be very plausible.
3. Even if COPC is broken and an adversary can output two openings to the
same external key, both those openings must be valid taproot spends for
anyone to lose coins (i.e. Merkle roots with valid paths to leaves with
valid tapscript).
4. Even if COPC was that badly broken on SHA256, old taproot outputs would
not be affected, the adversary has to break it during key generation before
funds are put into the output.
5. You can completely circumvent this result by using coin-tossing rather
than MuSig for the key generation protocol. In most cases this doesn't even
add any extra rounds of communication since you are doing 3-round coin
tossing to choose the R values for the signatures that spend from the joint
output anyway. You can just toss your public keys in parallel.

In my opinion, the cost of Taproot is mostly borne by theoreticians. They
can no longer treat a a public key ideally but have to consider the
implications of it also being a commitment. For the user and Bitcoin as a
whole it seems to offer an overwhelming benefit. In exchange for the
complexity it adds to making security claims in the GGM (if using
Taprscript and MuSig), it offers exciting new opportunities for
non-interactivity and fungibility over what just what Schnorr would provide.

I don't consider my work to be a final proof of anything. I would welcome
anyone who wants to take over this research direction and do a proper job
of it! I didn't have any personal motivation for doing this work other than
curiosity and that curiosity has been satisfied. Questions and thoughts
welcome :)

[1] https://www.di.ens.fr/david.pointcheval/Documents/Papers/2000_joc.pdf
[2] http://www.neven.org/papers/schnorr.pdf
[3] https://github.com/apoelstra/taproot/blob/master/main.pdf

Cheers,

LL
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200304/1254933a/attachment-0001.html>;

📅 Original date posted:2020-03-05 📝 Original message:> I ...

2023-06-07T20:23:17+02:00

In reply to nevent1q…85rc
_________________________

📅 Original date posted:2020-03-05
📝 Original message:> I am uncertain what you mean here by "coin-tossing".
> From the comparison to MuSig, I imagine it is an interactive key
generation protocol like this:

> * Everybody generates fresh keypairs.
> * Everybody sends the hash of their pubkey to everyone else.
> * After receiving a hash of pubkey from everyone else, everybody sends
their pubkey to everyone else.
> * They add all their pubkeys to generate the aggregate key (and if using
Taproot, use it as the internal key).

> Is that correct?

Yes exactly. The reason it's called coin tossing is that the resulting key
is guaranteed to be uniformly random (in the random oracle model at least),
so it's like tossing a fair 2^256 sided coin. This is not true in MuSig for
example, where the aggregate key is not guaranteed to be from a uniform
distribution against a malicious party (but still secure as an aggregate
key).

> However, it can generally be pointed out that, before you put anything
into an n-of-n, you would damn well sure want to have *some* assurance that
you can get it out later. So in general you would need coordination and
interaction anyway to arrange getting into an n-of-n in the first place.

Right. Taking your example of a lightning channel, when you set it up I
don't *think* there is a way to use the non-interactivity of MuSig to
remove any rounds of communication to get to the starting state where there
is a channel funding on-chain and both parties have a tx that spends from
it which returns their funds. Doing coin tossing for the aggregate key as
well as the aggregate nonce shouldn't lead to any extra rounds of
communication. The downside of coin tossing is that it requires honest
parties to sample their keys non-deterministically (or at least have a
counter to avoid using the same key twice).

> On the other hand, it would be best to have at least some minimum of
privacy by always interacting over Tor and having a Tor .onion address,
which has absolutely horrid latency because human beings cry when peeling
onions.
> So in general reducing the latency by reducing communication rounds is
better in general.
> Counter to this, assuming you use an n-of-n in an offchain protocol of
some sort, the number of communication rounds to generate the aggregate key
may be dwarfed by the total number of communication rounds to create
signatures to update the offchain protocol.
> Counter counter to this is that one plan for reducing communications
rounds for creating signatures during offchain operation is to (haha) use a
Taproot with an n-of-n internal key and a tapscript that has n
`OP_CHECKSIG` operations, so that for normal operation you just toss
individual signatures at each other but at termination of the offchain
protocol you can do the heavy MuSig-style signing with the n-of-n aggregate
key.

Counter³ to this is that, in the case of lightning, the aggregate key for a
PTLC does not need to be chosen at payment time. They channel members
could simply use the "master" aggregate key they generated by coin tossing
at the channel's inception and pseudorandomly randomise it every time they
need a new joint key (so the keys do not look related to everyone else on
the chain but you would effectively just be reusing the same public key).

Having said that if there is some advantage to using MuSig in some
particular case I wouldn't hesitate to use it in combination with Taproot.
I don't think the new assumption that I think you have to make wrt to the
hash function really weighs up against most design considerations. In
general, it is probably worth considering whether your protocol actually
benefits from the non-interactivity MuSig gives in the key generation
stage. If it doesn't due to the fact that it doesn't make signing anymore
non-interactive, then coin tossing might be the answer.

LL
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200305/fdfb6b5c/attachment.html>;

📅 Original date posted:2019-10-06 📝 Original message:Hi ...

2023-06-07T20:20:58+02:00

In reply to nevent1q…cmnp
_________________________

📅 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/bitcoin-dev/attachments/20191006/f0e27c02/attachment-0001.html>;