Nostr notes by

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

2023-07-31T00:54:54+02:00

In reply to nevent1q…7u08
_________________________

📅 Original date posted:2023-07-28
🗒️ Summary of this message: The email discusses a scheme for creating a multipath payment protocol using keysend, allowing the receiver to claim the payment once all parts have arrived.
📝 Original message:
Hi Z,

Or you can just use AMP and call it a day:
https://github.com/lightning/bolts/pull/658

-- Laolu

On Fri, Jul 28, 2023 at 12:24 AM ZmnSCPxj via Lightning-dev <
lightning-dev at lists.linuxfoundation.org> wrote:

> Good morning list,
>
> I would like to share a simple scheme for creating a `keysend` protocol
> that allows for multipath payments.
>
> In `keysend`, the preimage is embedded as TLV 5482373484 with length 32.
>
> In the multipath case, we want the receiver to only be able to claim the
> payment once all parts have arrived at the receiver.
>
> For example, suppose we want to split the `keysend` into 2 parts.
> Let us select a true preimage `p` at random.
> Then, we generate the payment hash `h = SHA256(p)`.
>
> Then, we generate a new 256-bit scalar, `a`.
> For one part, we send `a` for TLV 5482373484, and for the second part, we
> send `a ^ p`, where `^` is XOR.
> All parts use the same payment hash `h`.
>
> The receiver, on receiving either part, will find that the supposed
> preimage does not match the actual HTLC payment hashes.
> Instead of failing, it holds the payment, using the usual basic multipath
> payment rules.
>
> When the receiver receives another part, it will XOR together the supposed
> preimages.
> In the above case, it would get `a` and `a ^ p`, which when XORed together
> result in `a ^ a ^ p` or `p`, which is now the correct preimage, and the
> receiver can now claim the entire complete funds.
>
> The same technique would work with any number of parts --- if we split
> into `n` parts, we generate `n - 1` additional random scalars and use it
> for the first `n - 1` parts, then XOR all of them with the
> scalar-to-be-split for the `n`th part.
> This scheme also works for dynamic splitting, i.e. if you are splitting a
> part that was already split off from a part that was already split off from
> a part etc.
>
> A sender can detect if the receiver does not support multipath `keysend`
> if a part reaches the receiver and it errors with
> `incorrect_or_unknown_payment_details`.
> If the receiver is aware of multipath `keysend`, it would hold onto the
> incoming HTLCs until MPP timeout, and instead error with `mpp_timeout`.
> Thus, support for this on the receiver side does not need to be specially
> announced via a new feature bit --- an MPP-capable sender can simply try to
> split, and if it gets an `incorrect_or_unknown_payment_details`, knows that
> the receiver does not support multipath `keysend`.
> The same feature bit 55 can be reused.
>
> 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/20230728/540be4b8/attachment.html>;

📅 Original date posted:2023-06-13 🗒️ Summary of this ...

2023-06-14T16:16:41+02:00

In reply to nevent1q…2p2r
_________________________

📅 Original date posted:2023-06-13
🗒️ Summary of this message: An extension to BOLT-11 is proposed for invoices to contain two bundled payments with distinct preimages and amounts for non-custodial exchanges. This is useful for services that require prepayment of mining fees, such as submarine swaps and JIT channels. However, dedicated logic is still required for full verification of swap parameters and on-chain sweep/timeout, which is necessary for a trust-minimized swap.
📝 Original message:
> Their website shows an invoice to the user, whose wallet that is agnostic
> about the swap, and it would be unpractical for them to show two invoices
> to be paid simultaneously

In order to be properly non-custodial, a submarine swap client needs to be
able to unilaterally sweep or timeout an on chain HTLC and also validate all
the swap parameters.

Assuming I understand this web based flow correctly, it still requires
"dedicated logic" on the client side to sweep (reveal the preimage) or
timeout the on chain HTLC. If one wishes to avoid the awareness of the
subswap itself, then a user would need to manually go to the website in
order to obtain a signed sweep transaction (for a Loop Out like sub-swap, so
off-chain to on-chain). However, that would still require the wallet to
sign
the HTLC sweep path, once again requiring dedicated logic. A website could
have an option to give a user a signed sweep or refund transaction, but that
can't be created until user goes on chain as something like no_input doesn't
exist today on mainnet. Even then, a website can let the user act first,
then just never give them the necessary signed transaction.

In other words: one always requires dedicated logic in order to fully verify
the swap parameters and also perform an on-chain sweep/timeout, which is a
requirement for a trust minified swap. A user can trust the service to just
send to the given address or pay an invoice for them, but that's not a trust
minimized swap.

-- Laolu

On Tue, Jun 13, 2023 at 6:52 AM Thomas Voegtlin <thomasv at electrum.org>
wrote:

> Good morning list,
>
> I would like to propose an extension to BOLT-11, where an invoice can
> contain two bundled payments, with distinct preimages and amounts.
>
> The use case is for services that require the prepayment of a mining fee
> in order for a non-custodian exchange to take place:
> - Submarine swaps
> - JIT channels
>
> In both cases, the service provider receives a HTLC for which they do not
> have the preimage, have to send funds on-chain (to the channel or submarine
> swap funding address), and wait for the client to reveal the preimage when
> they claim the payment. Because there is no guarantee that the client will
> actually claim the payment, the service providers need to ask prepayment of
> mining fees.
>
> In the case of submarine swaps, services that use dedicated client
> software, such as Loop by Lightning Labs, can ask for a prepayment, because
> their software can handle it (this is called "no show penalty" on the Loop
> website). However, competitors who do require a dedicated wallet, not such
> as the Boltz exchange, cannot do that. Their website shows an invoice to
> the user, whose wallet that is agnostic about the swap, and it would be
> unpractical for them to show two invoices to be paid simultaneously. This
> creates a situation where Boltz is vulnerable to DoS attacks, where the
> attacker forces them to pay on-chain fees.
>
> In the case of JIT channels, providers who want to protect themselves
> against this mining fee attack need to ask the preimage of the main payment
> before they open the channel. I believe this is what Phoenix does (although
> their pay-to-open service is not open-source, so I cannot really check).
> The issue is that a service that asks for the preimage first becomes
> custodian. From a legal perspective, it does not matter whether they open
> the channel immediately after receiving the preimage, the ordering of
> events makes their service custodian. In Europe, such a service will fall
> within the European MICA regulation. Competitors who refuse to offer
> custodian services, such as Electrum, are excluded from that game.
>
> In order to solve that, it would be beneficial to bundle the prepayment
> and the main payment in the same BOLT-11 invoice.
>
> The semantics of bundled payments is as follows:
> - 1. the BOLT-11 invoice contains two preimages and two amounts:
> prepayment and main payment.
> - 2. the receiver should wait until all the HTLCs of both payments have
> arrived, before they fulfill the HTLCs of the pre-payment. If the main
> payment does not arrive, they should fail the pre-payment with a MPP
> timeout.
> - 3. once the HTLCs of both payments have arrived, the receiver fulfills
> the HTLCs of the prepayment, and they broadcast their on-chain transaction.
> Note that the main payment can still fail if the sender never reveal the
> preimage of the main payment.
>
> Of course, nothing in my proposal prevents the service provider from
> stealing the pre-payment, but that is already the case today.
>
> I believe this proposal would level the field in terms of competition
> between lightning service providers. Currently, you need to use a dedicated
> client in order to use Loop, and competitors who do not have an established
> user base running a dedicated client are exposed to the mining fee attack.
> I also believe that ACINQ would benefit from this, because it would make it
> possible for them to make their pay-to-open service fully non-custodian. My
> understanding is that in its current form, the 'pay-to-open' service used
> by Phoenix will fall into the scope of the European MICA regulation, which
> they should consider as a serious issue.
>
> Finally, I believe that such a change should be implemented in BOLT-11,
> and not using BOLT-12 or onion messages. Indeed, my proposal does not
> require the exchange of new messages. Some of the initial feedback I
> received was that this is a use case for BOLT-12 or OM, but I think that
> this is making things unnecessarily complicated. We should not add new
> messages when things can be done in a non-interactive way.
>
> Cheers,
> ThomasV
> _______________________________________________
> 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/20230613/f69bf61e/attachment.html>;

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

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

In reply to nevent1q…04vv
_________________________

📅 Original date posted:2023-01-04
🗒️ Summary of this message: A proposal for a faster way to move funds from an on-chain address to the Lightning Network using regular swaps, which simplifies the process and reduces trust requirements.
📝 Original message:
Hi Z,

> * Submarine swap/peerswap: Requires confirmation before the swap service
> will send out the HTLC on Lightning.

I might be missing something, but I don't see how this is different from a
normal on-chain to off-chain swap (calling this Loop In for short in the
remainder of the email).

Given some static swap server params (server key, user key, preimage), a
user can derive a tapscript tree and use that to make addresses that any 3rd
party can send to. Services like Loop return a few addrs (including P2TR!)
the client can use depending on their wallet sophistication [1] (in this
case the command is: `loop in --amt=X --external\, external means a 3rd
party will send to the addr). After a 3rd party sends to the script, the
swap can be completed at anytime as soon as the client is online (assuming
swap server is always there).

In the scenario above, the newly created outputs to our swap addr need to be
confirmed before the swap server will initiate the swap. As you mention,
this could even be zero conf assuming all sides take w/e precautions they're
comfortable with. If the swap server goes away for w/e reason, a long
timeout in the swap can let the user sweep the funds via some other
means eventually. This doesn't need to be a direct swap either, and it can
flow multi-hop like any other swap.

In your scheme you say that:

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

Which seems to be the exact same as the flow I described above. For our
newer musig2-enabled swaps, the top level keyspend can be spent by both
parties, so you also emulate the ability for Alice to move the funds on
chain anywhere else w/ the server's cooperation.

Using regular swaps also simplified the "Bob Security" section a lot, as Bob
sends out an HTLC w/ the corresponding swap hash (he watches the chain for
the scripts, then initiates the swap once they're seen).

[1]: https://lightning.engineering/api-docs/api/loop/swap-client/loop-in

-- Laolu

On Tue, Jan 3, 2023 at 5:58 AM 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/20230103/5b5b2cad/attachment-0001.html>;

📅 Original date posted:2023-01-05 📝 Original message: Hi Z, ...

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

In reply to nevent1q…j4y7
_________________________

📅 Original date posted:2023-01-05
📝 Original message:
Hi Z,

> Quick question: is the address given by the `loop in --external` command
safe
> for reuse?

Thx for this question, I think this is the key difference I was looking for
(not the aspect about confirmations, since that's no different). Since that
address contains a swap hash in the script, it's not safe to reuse (just
like a
vanilla invoice on LN today: ppl will learn the pre-image).

The potentiam swap is effectively a sort of deferred two stage swap. The
Loop
In swap I described earlier it complete after two transactions: initial
swap tx
confirmation, and the swap by the user. This swap can only be complete after
three transactions: initial deferred "no-premium swaption" (Alice can swap,
or
just leave it for a while), swap transaction confirmation (Alice initiates
w/
the HTLC added), and final sweep.

So this swap is less efficient from an on-chain perspective (2 vs 3 txns),
but
it gives Alice more optionality. Both variants however enable the final step
(sweeping on chain) to be batched with other related or distinct swaps.

I think one can make the Loop In swap addr pseudo-reusable by adding a
"cancel"
leaf in the rooted tapscript. It would slow down the process though, as
you'd
need another level of relative timeout for Alice to get the funds back. Ofc,
all this is muuuch nicer w/ proper covenants ;).

> The fact that `loop in` requires a specific `--amt=X` flag suggests to me
> that the address generated is not safe for address reuse

The amt field can in theory be left out of the flow, with the swap server
just
assuming w/e was sent to the address is the sending amt.

> Swap-in-potentiam is safe for address reuse, because each UTXO for the
same
> address backs a new, separate swap (if Alice wanted it). The advantage is
> that:

Indeed, if I were to re-write your initial post, I'd lead with this as (to
myself at least) it makes the contribution of this scheme much clearer.

-- Laolu

On Wed, Jan 4, 2023 at 7:11 AM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:

>
> Good morning Laolu,
>
>
> > Hi Z,
> >
> > > * Submarine swap/peerswap: Requires confirmation before the swap
> service
> > > will send out the HTLC on Lightning.
> >
> > I might be missing something, but I don't see how this is different from
> a
> > normal on-chain to off-chain swap (calling this Loop In for short in the
> > remainder of the email).
> >
> > Given some static swap server params (server key, user key, preimage), a
> > user can derive a tapscript tree and use that to make addresses that any
> 3rd
> > party can send to. Services like Loop return a few addrs (including
> P2TR!)
> > the client can use depending on their wallet sophistication [1] (in this
> > case the command is: `loop in --amt=X --external\, external means a 3rd
> > party will send to the addr). After a 3rd party sends to the script, the
> > swap can be completed at anytime as soon as the client is online
> (assuming
> > swap server is always there).
> >
> > In the scenario above, the newly created outputs to our swap addr need
> to be
> > confirmed before the swap server will initiate the swap. As you mention,
> > this could even be zero conf assuming all sides take w/e precautions
> they're
> > comfortable with. If the swap server goes away for w/e reason, a long
> > timeout in the swap can let the user sweep the funds via some other
> > means eventually. This doesn't need to be a direct swap either, and it
> can
> > flow multi-hop like any other swap.
> >
> > In your scheme you say that:
> >
> > > 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.
> >
> > Which seems to be the exact same as the flow I described above. For our
> > newer musig2-enabled swaps, the top level keyspend can be spent by both
> > parties, so you also emulate the ability for Alice to move the funds on
> > chain anywhere else w/ the server's cooperation.
> >
> > Using regular swaps also simplified the "Bob Security" section a lot, as
> Bob
> > sends out an HTLC w/ the corresponding swap hash (he watches the chain
> for
> > the scripts, then initiates the swap once they're seen).
> >
> > [1]: https://lightning.engineering/api-docs/api/loop/swap-client/loop-in
>
> Quick question: is the address given by the `loop in --external` command
> safe for reuse?
>
> In many common onchain-only wallets **available today**, you can do
> something like get a receive address and add it to your forum sig or on a
> static webpage or forum post or whatever, and then anyone can send to it,
> possibly multiple times with different amounts coming from different people.
>
> The fact that `loop in` requires a specific `--amt=X` flag suggests to me
> that the address generated is not safe for address reuse (in particular,
> once *one* swap has completed, I am almost sure that any future funds to
> the same address can be stolen by the swap server without handing it over
> to the purported owner of the funds).
>
> Swap-in-potentiam is safe for address reuse, because each UTXO for the
> same address backs a new, separate swap (if Alice wanted it).
> The advantage is that:
>
> * You get stable addresses that are safe for reuse (which is already
> possible today on non-Lightning wallets, so people already do this today).
> * Those stable addresses can still be spent from quickly on the Lightning
> Network as soon as they are reasonably confirmed.
>
> Regards,
> ZmnSCPxj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230104/75286083/attachment.html>;

📅 Original date posted:2022-11-04 📝 Original message: Hi ...

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

In reply to nevent1q…xc0h
_________________________

📅 Original date posted:2022-11-04
📝 Original message:
Hi Johan,

I haven't really been able to find a precise technical explanation of the
"utxo teleport" scheme, but after thinking about your example use cases a
bit, I don't think the scheme is actually sound. Consider that the scheme
attempts to target transmitting "ownership" to a UTXO. However, by the time
that transaction hits the chain, the UTXO may no longer exist. At that
point, what happens to the asset? Is it burned? Can you retry it again? Does
it go back to the sender?

As a concrete example, imagine I have a channel open, and give you an
address to "teleport" some additional assets to it. You take that addr, then
make a transaction to commit to the transfer. However, the block before you
commit to the transfer, my channel closes for w/e reason. As a result, when
the transaction committing to the UTXO (blinded or not), hits the chain, the
UTXO no longer exists. Alternatively, imagine the things happen in the
expected order, but then a re-org occurs, and my channel close is mined in a
block before the transfer. Ultimately, as a normal Bitcoin transaction isn't
used as a serialization point, the scheme seems to lack a necessary total
ordering to ensure safety.

If we look at Taro's state transition model in contrast, everything is fully
bound to a single synchronization point: a normal Bitcoin transaction with
inputs consumed and outputs created. All transfers, just like Bitcoin
transactions, end up consuming assets from the set of inputs, and
re-creating them with a different distribution with the set of outputs. As a
result, Taro transfers inherit the same re-org safety traits as regular
Bitcoin transactions. It also isn't possible to send to something that won't
ultimately exist, as sends create new outputs just like Bitcoin
transactions.

Taro's state transition model also means anything you can do today with
Bitcoin/LN also apply. As an example, it would be possible for you to
withdrawn from your exchange into a Loop In address (on chain to off chain
swap), and have everything work as expected, with you topping off your
channel. Stuff like splicing, and other interactive transaction construction
schemes (atomic swaps, MIMO swaps, on chain auctions, etc) also just work.

Ignoring the ordering issue I mentioned above, I don't think this is a great
model for anchoring assets in channels either. With Taro, when you make the
channel, you know how many assets are committed since they're all committed
to in the funding output when the channel is created. However, let's say we
do teleporting instead: at which point would we recognize the new asset
"deposits"? What if we close before a pending deposits confirms, how can one
regain those funds? Once again you lose the serialization of events/actions
the blockchain provides. I think you'd also run into similar issues when you
start to think about how these would even be advertised on a hypothetical
gossip network.

I think one other drawback of the teleport model iiuc is that: it either
requires an OP_RETURN, or additional out of band synchronization to complete
the transfer. Since it needs to commit to w/e hash description of the
teleport, it either needs to use an OP_RETURN (so the receiver can see the
on chain action), or the sender needs to contact the receiver to initiate
the resolution of the transfer (details committed to in a change addr or
w/e).

With Taro, sending to an address creates an on-chain taproot output just
like sending to a P2TR address. The creation of the output directly creates
the new asset anchor/output as well, which allows the receiver to look for
that address on chain just like a normal on chain transaction. To 3rd party
observers, it just looks like a normal P2TR transfer. In order to finalize
the receipt of the asset, the receiver needs to obtain the relevant
provenance proofs, which can be obtained from a multi-verse gRPC/HTTP
service keyed by the input outpoint and output index. In short, the send
process is fully async, with the sender and receiver using the blockchain
itself as a synchronization point like a normal Bitcoin wallet.

-- Laolu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20221104/354c256b/attachment.html>;

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

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

In reply to nevent1q…hgxf
_________________________

📅 Original date posted:2022-09-01
📝 Original message:
Hi Alex,

This is a super cool project! I've shared some thoughts here in a comment on
the draft PR:
PR:
https://github.com/lightningnetwork/lnd/pull/6843#issuecomment-1234933319

Also I cc'd the lnd mailing list on this reply, perhaps we can move the
discussion over there (or in the issue) since this is more of an lnd
specific thing. In the future, the lnd mailing list is also probably a
better place for lnd architecture specific proposals/discussions.

-- Laolu

On Thu, Sep 1, 2022 at 10:56 AM Alex Akselrod via Lightning-dev <
lightning-dev at lists.linuxfoundation.org> wrote:

> At NYDIG, we're considering ways to harden large LND deployments. Joost
> and I discussed that currently, when external untrusted peers make inbound
> connections, LND must verify the identity of the peer during the noise
> handshake, and it must do this before enforcing any potential key-based
> allow lists. This is done in the same process as the node's other critical
> tasks, such as monitoring the chain.
>
> To reduce the attack area of the main node process, we'd like to propose a
> means to optionally separate the peer communication into a separate
> process: something like CLN's connectd, running separately, and the
> connections would be multiplexed over a single network connection initiated
> from the node to the proxy. The core of our current idea is demonstrated in
> a draft PR: https://github.com/lightningnetwork/lnd/pull/6843
>
> I'd love some early feedback on the general direction of this. If this
> would be interesting, I'll build it out into a fully working feature.
>
> Thanks,
>
> Alex Akselrod
> _______________________________________________
> 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/20220901/a7c7cf81/attachment.html>;

📅 Original date posted:2022-06-07 📝 Original message: Hi ...

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

In reply to nevent1q…wqt5
_________________________

📅 Original date posted:2022-06-07
📝 Original message:
Hi y'all,

Last week nearly 30 (!) Lightning developers and researchers gathered in
Oakland, California for three day to discuss a number of matters related to
the current state and evolution of the protocol. This time around, we had
much better representation for all the major Lightning Node implementations
compared to the last LN Dev Summit (Zurich, Oct 2021).

Similar to the prior LN Dev Summit, notes were kept throughout the day that
attempted on a best effort basis to capture the relevant discussions,
decisions, and new relevant research or follow up areas to circle back on.
Last time around, I sent out an email that summarized some key takeaways
(from my PoV) of the last multi-day dev summit [1]. What follows in this
email is a similar summary/recap of the three day summit. Just like last
time: if you attended and felt I missed out on a key point, or inadvertently
misrepresented a statement/idea, please feel free to reply, correcting or
adding additional detail.

The meeting notes in full can be found here:
https://docs.google.com/document/d/1KHocBjlvg-XOFH5oG_HwWdvNBIvQgxwAok3ZQ6bnCW0/edit?usp=sharing

# Simple Taproot Channels

During the last summit, Taproot was a major discussion topic as though the
soft fork had been deployed, we we're all still watching the 🟩 's stack up
on the road to ultimately activation. Fast forward several months later and
Taproot has now been fully activated, with ecosystem starting to
progressively deploy more and more advanced systems/applications that take
advantage of the new features.

One key deployment model that came out of the last LN Dev summit was the
concept of an iterative roadmap that progressively revamped the system to
use more taprooty features, instead of a "big bang" approach that would
attempt to package up as many things as possible into one larger update. At
a high level the iterative roadmap proposed that we unroll an existing
larger proposal [2] into more bite sized pieces that can be incrementally
reviewed, implemented, and ultimately deployed (see my post on the LN Dev
Summit 2021 for more details).

## Extension BOLTs

Riiight before we started on the first day, I wrote up a minimal proposal
that attempted to tackle the first two items of the Taproot iterative
deployment schedule (musig2 funding outputs and simple tapscript mapping)
[3]. I called the proposal "Simple Taproot Channels" as it set out to do a
mechanical mapping of the current commitment and script structure to a more
taprooty domain. Rather than edit 4 or 5 different BOLTs with a series of
"if this feature bit applies" nested clauses, I instead opted to create a
new standalone "extension bolt" that defines _new_ behavior on top of the
existing BOLTs, referring to the BOLTs when necessary. The style of the
document was inspired by the "proposals" proposal (very meta), which was
popularized by cdecker and adopted by t-bast with his documents on
Trampoline and Blinded Paths.

If the concept catches on, extension BOLTs provide us with a new way to
extend the spec: rather than insert everything in-line, we could instead
create new standalone documents for larger features. Having a single self
contained document makes the proposal easier to review, and also gives the
author more room to provide any background knowledge, primaries, and also
rationale. Overtime, as the new extensions become widespread (eg: taproot is
the default channel type), we can fold in the extensions back to the main
set of "core" BOLTs (or make new ones as relevant).

Smaller changes to the spec like deprecating an old field or tightening up
some language will likely still follow the old approach of mutating the
existing BOLTs, but larger overhauls like the planned PTLC update may find
the extension BOLTs to be a better tool.

## Tapscript, Musig2, and Lightning

As mentioned above the Simple Taproot Channels proposal does two main
things:
1. Move the existing 2-of-2 p2wsh segwit v0 funding output to a _single
key_ p2tr output, with the single key actually being an aggregated musig2
key.

2. Map all our existing scripts to the tapscript domain, using the
internal key (keyspend path) for things like revocations, which an
potentially allow nodes to store less state for HTLCs.

Of the two components #1 is by far the trickiest. Musig2 is a very elegant
protocol (not to mention the spec which y'all should totally check out) but
as the signatures aren't deterministic (like RFC 6979 [5]), both signers
need to "protect themselves at all times" to ensure they don't ever re-use
nonces, which can lead to a private key leak (!!).

Rather than try to create some sort of psuedo-deterministic nonces scheme
(which maaybe works until the Blockstream Research team squints vaguely in
its direction), I opted to just make all nonces 100% ephemeral and tied to
the lifetime of a connection. Musig2 defines something called a public
nonces, which is actually two individual 33-byte nonces. This value needs to
be exchanged before signing can begin (but can be sent before sides know
they're aggregated keys). One important thing to note is that given that the
channels today have _asymmetric_ state, we actually need a _pair_ of public
nonces: one that I'll use to sign my commitment, and one I'll use to sign
yours. Lightning channels w/ symmetric state like eltoo can get by w/ only
exchange a single set of nonces, as there's only one message per state.

Nonce exchange takes place in a few places:

* During initial funding: I send my public nonce in the open_channel
message, you send yours in the accept_channel message. After this
exchange we can both generate signatures for the refund commitment
transactions.

* After the channel is "ready" we send another set of nonces, so we can
sign the next state. This is similar to the existing revocation key
exchange: I need your next nonce/key before I can sign a new state.

* Upon channel re-establishment a _new_ set of nonces is sent, as they're
100% ephemeral. The current draft also requires that if you were
re-transmitting a sig, then you use the _new_ nonces to sign again, as
it's possible you went to retransmit but left off an expired/trimmed
HLTC (could lead to nonce re-use and also needing to remember nonces).

* Each time I revoke my channel, I send to you a single nonce, my "local
nonce" (naming needs some work here), which lets you sign for a new
state.

* Each time I send a new sig, I also send you another nonce, my "remote"
nonce", which

* When I send a shutdown (co-op close) I send a single public nonce so we
can sign the next co-opc close offer.

* When I send a closing_signed I send another nonce so once you send your
offer, we sign another set.

The final flows aren't 100% yet finalized, as we'll need some
implementations drafted to make sure the nonce handling and script mapping
works out properly.

### Lightning Channels & Recursive Musig2

One other cool topic that came up is the concept of leveraging recursive
musig2 (so musig2 within musig2) to make channels even _more_ multi-sigy.
The benefit here is that Bob & Carol can each have their individual keys
(which might actually be aggregated keys themselves) and make a channel w/
Alice, who only knows of them as Barol, and doesn't know there're actually
another pair of keys at play. This is _really_ cool as it allows node
operators, wallets, and lightning platforms to experiment with various
key/signing trees that may add more security, redundancy, or flexibility.

When this first came up, someone brought up the fact that while the scheme
is "known" the initial paper as they weren't sure how to actually write a
proof for it. During the session, someone emailed one of the musig2 authors
asking for more details, and if it's safe to implement and roll out.
Thankfully they quickly replied and explained that the proof recursive musig
(pls someone correct me again here if I'm wrong) wasn't left out due to
impossibility, but that a proof in the existing Random Oracle Model (which
was used to derive a bound for the number of nonces needed) would lead to a
blow up in the number of nonces required. Attempting to write the proof in
some other model would likely lead to better results (proved w/ two nonces
as base musig2), but would end up being pretty complicated, so hard to read
and even review for correctness.

Assuming everything checks out, then a useful mental model explained by the
musig2 BIP author is a sort of tree structure. Assuming I'm a signer, and we
assemble the other signer as a sibling leaf in a binary tree, then I just
need to wait for the sibling nonce/key, before I can aggregate that into
the final value. So if there're 3 signers, I wait for the regular public
nonce, but the other signers sum their respective nonces into a single
nonce, then send that to me. A similar operation is carried out for key
aggregation, with the rest of the protocol being mostly the same.

Ultimately, even if wallets/nodes aren't ready to roll something like this
out today, we at least want to make sure the proposed flow is compatible
with Simple Taproot Channels, and ideally we'd have a toy implementation to
verify out understanding and show it's possible/sound. I volunteered to hack
up a simple recursive musig2 demo, as there doesn't seem to be any code in
the wild that implements it.

## Lightning Gossip

# Gossip V2: Now Or Later?

Another big topic related to Taproot was the question of how we should
update the gossip network: the gossip protocol today has all channels
validated by node, which requires that the nodes understand how to
reconstruct the funding output based on the set of advertised keys. The
protocol today assumes a segwit v0 p2wsh multi-sig is used. Assuming we had
everything implemented today, a node wouldn't be able to advertise its new
taproot channels to the rest of the public graph as they wouldn't understand
how to validate it.

This presents a new opportunity: we already need to rework gossip for
taproot, so should we go ahead and re-design the entire thing with an eye
for better privacy and future extensibility?

A proposal for the "re-design the entire thing" was floated in the past by
Rusty [6]. It does away with the strict coupling of channels to channel
announcements, and instead moves them to the _node_ level. Each node would
then advertise the set of "outputs" they have control of, which would then
be mapped to the total capacity of a node, without requiring that these
outputs self identify themselves on-chain as Lightning Channels. This also
opens up the door to different, potentially more privacy preserving
proofs-of-channel-ownership (something something zkp).

On the other hand, we could just follow the path of Simple Taproot Channels
and map musig2+schnorr onto the existing gossip network. This is less
changes in total, with the main benefit being the ability to only send 1 sig
(aggregated musig2 sig of keys) instead of 4 individual sigs. I made a very
lofty proposal in this direction here [7].

Ultimately we decided to take the "just musig2 aspects" from gossip v1.5
(not the real name), and the "let's refresh all the messages w/ TLV
goodness" from the gossip v2 proposal. This gives us a smaller package to
implement, and lets us potentially rejigger the messages to be more
extensible and remove cruft like the node color that almost nothing uses,
but we all validate/store.

The follow up work in this area is a more concrete proposal that updates the
relevant gossip messages to be taproot aware and TLV'd and also update the
set of requirements w.r.t _how_ to validate the channels in the first place
(so given two keys verify that applying the keyagg method of musig2 lead to
what' in the funding output).

Gossip v2 will likely happen "eventually", but the rather large design space
needs to be explored a bit more so we can properly analyze exactly what
privacy and extensibility properties we'll get out of it.

# Applying Mini Sketch to LN Gossip

One issue we have today, is that other than the initial scid query mechanism
added to the protocol, there isn't a great way to ensure you have all the
latest updates your peer has. These days, many nodes pretty aggressively
rate limit other nodes, so you might even have trouble sending out your
update in the first place. A recent paper (that I haven't actually fully
read yet) [8] analyzes the gossip network today to work out things like:
exactly how long it takes things to propagate, total bandwidth usage, etc.

Minisketch [9] (the grandchild of IBLTs ;)), is an efficient set
reconciliation protocol that was designed for Bitcoin p2p mempool syncing,
but can be applied to other protocols. An attendee has been working on
brushing off some older work to try to see how we could apply it to the LN
protocol to give nodes a more bandwidth efficient way to sync channel
updates, and also achieve better update propagation. This supplements some
existing investigative work done by Alex Meyers [10], with more concrete
designs w.r.t: what goes into the sketch, and the various size parameters
that need to be chosen.

# Channel Jamming

An attendee gave a talk on the various proposed solutions to channel
jamming, evaluating them on several axis including: punishment/monetary,
local vs global reputation, feasibility of mechanism design, UX
implications, and implementation complexity. The presenter didn't present a
new concrete proposal, but instead went through the various trade-offs,
ultimately concluding that they factor monetary penalties wherein the funds
are distributed across the route, rather than being provably burnt to
miners. However they alluded to some future upcoming work that attempts a
more rigorous analysis of the proposed solutions, their tradeoffs, and
potential ways we can parametrize solutions to be more effective (how much
should they pay, etc).

For those looking to brush up on the latest state of research/mitigations in
this area, I recommend this blog post by Bitmex research [11].

# Onion Messages & DoS

The topic of DoS concerns related to onion messages (in isolation, so not
necessarily related to things like bolt12 that take advantage of them came
up. During a white boarding session some argued that DoS isn't actually
much of an issue, as nodes can leverage "back propagation congestion
control" to inform the source (who may not actually be the sender) that
they'll start to drop or limit their packets, with each node doing this
iteratively until the actual source of the spam has been clamped. A few
lofty designs were thrown around, but more work needs to be done to
concretely specify something so it can be properly analyzed.

On the other side of the spectrum, rather than attempt to rate limit at the
node level (which each node having their own policy), nodes could opt
instead to forward _anything_ as long as the sender pays them enough. I
proposed a lofty approach that combined AMP and Onion Messages earlier this
year [12]. At a high level I make an AMP payment, which pushes extra coins
to all nodes on a route, and also drops off a special identifier to them.
When I send an onion message I include this identifier, with each node
performing their own account w.r.t the amount of bandwidth an ID has
remaining.

Ultimately a few implementations are pretty close to deploying their
implementation of onion messages, so no matter the intended use case, it
would be good to have code deployed along side to either rate limit or price
resource consumption accordingly. Otherwise, we might end up in a scenario
where DoS concerns were brushed aside, but end up being a huge issue later.

# Blinded Paths, QR Codes & Invoices

Blinded paths [13] is a new-er proposal to solve the "last mile" privacy
issue when receiving payments on LN. Today invoices to unadvertised channels
contain a set of hop hints, which are anchored at public nodes in the graph,
and also leak the scid of the unadvertised channel (points on-chain to the
channel receiving payments). A solution for the on-chain leak, SCID channel
aliases [15] are in the process of being widely rolled out. Channel aliases
instead use a random value in the invoice, allowing receiving nodes to break
that on-chain link and even rotate out the value periodically. With the
on-chain leak addressed, it's still the case that you give away your
"position" in the network, since as a sender I know that you're connected to
node N with a private channel.

Blinded paths address this node-level last mile privacy leak by replacing
hop hints with a new cryptographically blinded path. At a high level, the
receiver can construct a "hop hint" of length greater than 1, gather the
public keys of each of the nodes, then blinded them such that: the sender
can use them for path finding, but doesn't actually now exactly _which_
nodes they actually are.

There're two type of blinded paths: those in onion messages and those used
for actual payments. The latter variant was only formalized earlier this
year, as before people were mainly interested in using them to fetch BOLT 12
invoice via onion messages. One issue that pops up when attempting to use
blinded paths for normal payments is: the size of the resulting invoice. As
blinded paths are actually fragments of publicly known paths, as a receiver,
you want to stuff as many of them into the invoice as possible, since they
MUST be taken in order to route towards you. Invoices are typically
communicated via QR codes, which have a hard limit w.r.t the amount of
information that can be packed in. On the other hand for invoice fetching,
all that matters is that a path exists, so you can get by with stuffing less
of then in a QR code.

As a result, blinded paths aren't necessarily compatible with the widely
deployed BOLT 11 based QR codes. Instead a way to fetch invoice on demand is
required. Both BOLT-12 and LN-URL provide standardized ways for nodes to
fetch invoices, though their transport/signalling medium of choice differs.
Blinded routes are technically compatible with BOLT 11 invoices, but may be
hampered by the fact that you can only include so many routes.

Another consideration is that unlike hop hints, blinded paths require more
maintain once, as since they traverse public route, policy changes like a
fee update may invalidate an entire set set of routes. One proposed solution
is that forwarding nodes should observe their older policy for a period of
time (so a grace period), and also that blinded paths should have an
explicit expiry (similar to the existing invoice expiry).

One other implication is that the set of routes the receiver includes
matters
more: if they don't send enough or select them poorly, the sender may never
be
able to reach them even though a path exists in theory. More hands on
experience is needed so the spec authors can better guide implementations
and
wallets w.r.t best practices.

# Friend-of-a-friend Balance Sharing & Probing

A presentation was given on friend-of-a-friend balance sharing [16]. The
high level idea is that if we share _some_ information within a local
radius, then this gives the sender more information to choose a path that's
potentially more reliable. The tradeoff here ofc is that nodes will be
giving away more information that can potentially be used to ascertain
payment flows. In an attempt to minimize the amount of information shared,
the presenter proposed that just 2 bits of information be shared. Some
initial simulations showed that sharing local information actually performed
better than sharing global information (?). Some were puzzled w.r.t how
that's possible, but assuming the slides+methods are published others can
dig further into the model/parameter used to signal the inclusion.

Arguably, information like this is already available via probing, so one
line of thinking is something like: "why not just share _some_ of it" that
may actually lead to less internal failures? This is related to a sort of
tension between probing as a tool to increase payment reliability and also
as a tool to degrade privacy in the network. On the other hand, others
argued that probing provides natural cover traffic, since they actually
_are_ payments, though they may not be intended to succeed.

On the topic of channel probing, a sort of makeshift protocol was devised to
make it harder in practice, sacrificing too much on the axis of payment
reliability. At a high level it proposes that:

* nodes more diligently set both their max_htlc amount, as well as the
max_htlc_value_in_flight amount

* a 50ms (or select other value) timer should be used when sending out
commitment signatures, independent of HTLC arrival

* nodes leverage the max_htlc value to set a false ceiling on the max in
flight parameter

* for each HTLC sent/forwarded, select 2 other channels at random and
reduce the "fake" in-flight ceiling for a period of time

Some more details still need to be worked out, but some felt that this would
kick start more research into this area, and also make balance mapping
_slightly_ more difficult. From afar, it may be the case that achieving
balance privacy while also achieving acceptable levels of payment
reliability might be at odds with each other.

# Eltoo & ANYPREVOUT

One of the attendees is currently working on both fully implementing eltoo,
as well as specifying the exact channel funding+update interaction were it
to be rolled out align side the existing penalty based channels in the
protocol. As this version of eltoo is based on Taproot, we were able to
compare notes a bit to find the overlapping set of changes (nonce handling,
etc), which permits cross review of the proposals. This type of work is
cool, as only by fully implementing something end to end can you reaaally
work out all the edge cases and nuances.

ANYPREVOUT as hasn't changed significantly as of late. An attendee shared
plans to create a sort of mega all-future-feasible-soft-forks fork of
bitcoind, that would package up various unmerged (from bitcoind's) proposal
soft fork packages into an easy to run+install binary/project attached to a
signet. The hop is that by giving developers an easy way to interact with
proposed soft fork proposals (vs debasing some ancient pull request), wider
participation in testing/implementation/review can be facilitated.

# Trampoline Routing

There was a presentation on Trampoline routing explaining the motivation,
history, and current state of the proposal. The two main cases we've
narrowed down on are:

1. A mobile user doesn't necessarily want to sync the _entire_ graph, so
they can use trampoline to maintain a subset and still be able to send
payments.

2. A mobile user wants to be able to instate a payment, go offline, and
return at a later time to learn about the final state of the payment.

Use case #2 seems to be the most promising when combined with other
proposals for holding HTLCs at an origin node (call it an "LSP") [13].
Combined together, this would allow a mobile node to send a payment, then go
offline, with the LSP being able to retry the payment either continuously or
only when it knows the receiver is online to accept the payment. This may
potentially dramatically improve the UX for LN on mobile, as things suddenly
become a lot more asynchronous: I do something go offline, and the LSP node
can fulfil the payment in the background, then wait for me to come online to
settle the final. hop.

Trampoline can also be composed well with blinded routes (blinded route from
last trampoline to receiver) and also MPP (internal nodes can split
themselves with local information).

One added trade-off is that since the sender doesn't know the entire route,
they need to sort of overshoot w.r.t fees and CTLVs. This is something
we've known for a while, but until Trampoline is more widely rolled out, we
won't have a very good feel w.r.t how much extra senders will need to
allocate.

# Node Fee Optimization & Fee Rate Cards

Over the past few years, a common thread we've seen across successful
routing nodes is dynamic fee setting as a way to encourage/discourage
traffic. A routing nodes can utilize the set of fees of a channel to either
make it too expensive for other nodes to route through (it's already
depleted don't try unless you'll give be 10 mil sats, which no one would) or
very cheap, which'll incentivize flows in the other direction. If all nodes
are constantly sending out updates of this nature, then it can generate a
lot of traffic, and also sort of leak more balance information overtime
(which some nodes are already doing: using fees/max_htlc to communicate
available balances).

One attendee proposed allowing nodes to express a sort of fee gradient via a
static curve/bucket/function, instead of dynamically communicating what the
latest state of the fee+liquidity distribution looks like. A possible
manifestation could be a series of buckets, each of which with varying fee
rates. If your payment consumes 50% of channel balance, then you pay this
rate, otherwise if it's 5% you pay this rate, etc, etc. This might allow for
nodes to capture the same dynamics as they do with more dynamic fee updates,
but in a way that leaks less information and also consumes less gossip
bandwidth.

# The Return of Splicing

Splicing is one of those things that was discussed a long time ago, but was
never really fully implemented and rolled out. A few attendees have started
to take a closer look at the problem, building off of the interactive-tx
scheme that the dual-funding protocol extension uses. The main intricacy
discussed was if concurrent splices should be allowed or not, and if so, how
we would handle the various edge cases. As an example, if I propose a splice
to add more funds via my input, but that turns out to already be spent, then
the splicing transaction we created is invalid and can never be confirmed.
However if we allow _another_ splice to take place, and another one, and
another one, then ideally _one_ of them will confirm and serve as the new
anchor for the channel.

In a world of concurrent splices, the question of "what is my Lightning
balance" becomes even more murky. Wallet and implementations will likely
want to show the most pessimistic value, while also ensuring that the user
is able to effectively account for where all their funds and what they can
spend on/off chain.

# LN-URL + BOLT 12

LN-URL and BOLT 12 are both standardized ways that answer the question of:
how can I fetch an invoice from Bob? LN-URL differs from BOLT 12 in that it
uses the existing BOLT 11 invoice format, and uses an HTTP based protocol
for the negotiation process. BOLT 12 on the other hand is a suite of
protocol additions that includes (amongst other things) a new invoice format
(yay TLV!) and also a way to use onion messages to fetch an invoice _via_
the network.

Assuming blinded paths is widely rolled out, then the question of how
invoices are obtained becomes more important as blinded paths means that you
can't fit much in the traditional QR encoding. As a result, fetching
invoices on demand may become a more common place flow, with all its
trade-offs. There was a group discussion on how we could sort of unifying
everything either by allowing BOLT 12 to be used over LN-URL or the other
way around.

One proposal was to add a new query parameter to the normal LN-URL QR code
contents. This would mean that when a wallet goes to scan an LN-URL QR code,
if they know of the extra param, and what BOLT 12, they can just use the
enclosed offer to fetch the invoice.

An alternative proposal was to instead extract the BOLT 12 _invoice_ format
from the greater BOLT 12 "Offers" proposal. Assuming blinded paths is only
specified w.r.t BOLT 12 _invoices_, then this would mean an LN-URL extension
could be rolled out that allowed returning BOLT 12 invoice rather than BOLT
11 invoices. This would allow the ecosystem to slowly transition to a shared
invoice format, even if there may be fundamental disagreements w.r.t _how_
the invoices should be fetched in the first place.

It's worth noting that both of these proposals can be combined:

* If a wallet knows how to BOLT 12 Offers, they can take the enclosed
offer and run w/ it.

* If they don't know about Offers, but can send w/ the BOLT _invoice_
format, then they can fetch that and complete the payment.

This might be a nice middle ground as it would tend all
wallets/implementations to being able to decode and send w/ a BOLT 12
_invoice_, and leave the question of _how_ it should be fetched up to the
application/wallet/service. In the end, if paths never quite intersect, then
it's still possible to add route blinding to BOLT 11, with LN-URL sticking
with that invoice format to take advantage of the new privacy enhancements

[1]:
https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-November/003336.html
[2]:
https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-October/003278.html
[3]: https://github.com/lightning/bolts/pull/995
[4]: https://github.com/jonasnick/bips/blob/musig2/bip-musig2.mediawiki
[5]: https://datatracker.ietf.org/doc/html/rfc6979
[6]:
https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-February/003470.html
[7]:
https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-March/003526.html
[8]: https://arxiv.org/abs/2205.12737
[9]: https://bitcoinops.org/en/topics/minisketch/
[10]:
https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-April/003551.html
[11]: https://blog.bitmex.com/preventing-channel-jamming/
[12]:
https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-February/003498.html
[13]: https://github.com/lightning/bolts/pull/765
[14]:
https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-October/003307.html
[15]: https://github.com/lightning/bolts/pull/910
[16]: https://github.com/lightning/bolts/pull/780

-- Laolu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220607/eb9e8d17/attachment-0001.html>;

📅 Original date posted:2022-05-02 📝 Original message: Hi ...

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

In reply to nevent1q…evlh
_________________________

📅 Original date posted:2022-05-02
📝 Original message:
Hi John,

> That said, I believe that the correct approach to supporting "tokens on
> Lightning" is to make it a separate concern from Taro, and that LL should
> create a separate BOLT proposal from the current Taro BIPs to ensure it LN
> standards have a genericized protocol that all LN implementations would be
> interested in supporting.

The current Taro BIPs describe just about everything needed in order to
create, validate, and interact with assets on chain. Naturally, the system
needs to exist on-chain before any off-chain constructs can be built on top
of it.

On the topic of a BOLT, I don't think something like Taro (particularly our
vision for the deployment path) should exist at the _BOLT level_. Instead,
we aim to create a bLIP that fully specifies the _optional_ series of TLV
extensions needed to open channels using Taro assets, and send them
off-chain. IMO this isn't something that needs to be a BOLT as: it isn't
intended to be 100% universal (most LN routing nodes and users will only
know of the core bitcoin backbone), isn't critical to the operation of the
core LN network, and it's something that will only initial be deployed at
the edges (sender+receiver).

On the BOLT side, there're a number of important upgrades/extensions being
proposed, and imo it doesn't make sense to attempt to soak up the already
scarce review bandwidth into something like Taro that will live purely at
the edges of the network. I also don't want to speak for the other LN devs,
but I think most would prefer to just focus on the core LN protocol and
ignore anything non-bitcoin on the sides. The implementations/developers
that think this is something worth implementing will be able to contribute
to and review the bLIPs as they wish.

A few implementations support LTC today, but that was mainly an exercise in
helping to build consensus for segwit so we could ultimately deploy LN on
Bitcoin's mainnet (iirc some implementations are in the process of even
removing support). A prior version of the onion payload (now called the
legacy payload) had a "realm" field that was intended to be used for
multi-chain stuff. The newer modern TLV payload dropped that field as it
wasn't being used anywhere. IMO that was the right move as it allows us to
keep the core protocol simple and let other ppl be concerned w/ building
multi-asset stuff on top of the base protocol.

> but instead the requirement to add several feature concepts to LN that
> would allow tokens to interact with LN nodes and LN routing:

>From this list of items, I gather that your vision is actually pretty
different from ours. Rather than update the core network to understand the
existence of the various Taro assets, instead we plan on leaving the core
protocol essentially unchanged, with the addition of new TLV extensions to
allow the edges to be aware of and interact w/ the Taro assets. As an
example, we wouldn't need to do anything like advertise exchange rates in
the core network over the existing gossip protocol (which doesn't seem like
the best idea in any case given how quickly they can change and the existing
challenges we have today in ensuring speedy update propagation).

> So, I ask that Lightning Labs coordinate with the LN community to ensure
> such support for other networks and other assets not be dedicated only to
> Taro, and instead genericized enough so that other networks may compete
> fairly in the market,

If you're eager to create a generalized series of extensions to enable your
vision, then of course you're welcome to pursue that. However, I don't think
the other LN developers will really care much about building some
generalized multi-chain/multi-asset system given all the existing work we
still need to do to make sure the bitcoin backbone works properly and can
scale up sufficiently. I'd also caution you against making the same mistakes
that Interledger did: they set out to build a generalized off-chain system
which abstracts over the assets/chains entirely, but years later, and
several hundred wc3 mailing list posts later, virtually nothing uses it.
Why? IMO, because it was overly generalized and they assumed that if they
built it, the entities that actually needed it would magically pop up
(spoiler alert -- *SpongeBob narrator voice*: several years later, they
didn't).

> Otherwise, we will be left with LL's advantage being that LND supports
> Taro, and weird narratives that Taro is somehow superior because LND
> specifically added support for it, without creating a generic spec or BOLT
> that all nodes could adopt for multi-network, multi-asset LN-as-rails use
> cases.

Given that all the specs so far are in the open, and we opted to first build
out the specifications before releasing our own implementation, I don't
foresee Taro being something that only LL or lnd implements. All the BIPs
are public, and the bLIP will be soon as well, so any motivated individual
or set of individuals will also be able to implement and adopt the protocol.
If you or anyone else reading this is interested in contributing: I'm
accepting PRs to my fork of the BIP repo [1] (where I've already made
several modifications based on feedback from the wider community, and merged
a few PRs as well), and I'm also hanging out on IRC at ##taro on Libera.

[1]: https://github.com/Roasbeef/bips/tree/bip-taro

-- Laolu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220502/d9b6768e/attachment.html>;

📅 Original date posted:2021-11-03 📝 Original message: Oh, ...

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

In reply to nevent1q…lfkd
_________________________

📅 Original date posted:2021-11-03
📝 Original message:
Oh, also there's currently this sort of placeholder logo from waaay back
that's used as the org's avatar/image. Perhaps it's time we roll an
"official" logo/avatar? Otherwise we can just switch over the randomly
generated blocks thingy that Github uses when an account/org has no
avatar.

-- Laolu

On Tue, Nov 2, 2021 at 7:34 PM Olaoluwa Osuntokun <laolu32 at gmail.com> wrote:

> Circling back to close the loop here:
>
> * The new Github org (https://github.com/lightning) now exists, and all
> the
> major implementation maintainers have been added to the organization as
> admins.
>
> * A new blips repo (https://github.com/lightning/blips) has been
> created to
> continue the PR that was originally started in the lightning-rfc
> repo.
>
> * The old lightning-rfc repo has been moved over, and been renamed to
> "bolts"
> (https://github.com/lightning/bolts -- should it be all caps? )
>
> Thanks to all that participated in the discussion (particularly in
> meatspace
> during the recent protocol dev meetup!), happy we were able to resolve
> things
> and begin the next chapter in the evolution of the Lightning protocol!
>
> -- Laolu
>
>
> On Fri, Oct 15, 2021 at 1:49 AM Fabrice Drouin <fabrice.drouin at acinq.fr>
> wrote:
>
>> On Tue, 12 Oct 2021 at 21:57, Olaoluwa Osuntokun <laolu32 at gmail.com>
>> wrote:
>> > Also note that lnd has _never_ referred to itself as the "reference"
>> > implementation. A few years ago some other implementations adopted that
>> > title themselves, but have since adopted softer language.
>>
>> I don't remember that but if you're referring to c-lightning it was
>> the first lightning implementation, and the only one for a while, so
>> in a way it was a "reference" at the time ?
>> Or it could have been a reference to their policy of "implementing the
>> spec, all the spec and nothing but the spec" ?
>>
>> > I think it's worth briefly revisiting a bit of history here w.r.t the
>> github
>> > org in question. In the beginning, the lightningnetwork github org was
>> > created by Joseph, and the lightningnetwork/paper repo was added, the
>> > manuscript that kicked off this entire thing. Later
>> lightningnetwork/lnd was
>> > created where we started to work on an initial implementation (before
>> the
>> > BOLTs in their current form existed), and we were added as owners.
>> > Eventually we (devs of current impls) all met up in Milan and decided to
>> > converge on a single specification, thus we added the BOLTs to the same
>> > repo, despite it being used for lnd and knowingly so.
>>
>> Yes, work on c-lightning then eclair then lnd all began a long time
>> before the BOLTs process was implemented, and we all set up repos,
>> accounts...
>> I agree that we all inherited things from the "pre-BOLTS" era and
>> changing them will create some friction but I still believe it should
>> be done. You also mentioned potential admin rights issues on the
>> current specs repos which would be solved by moving them to a new
>> clean repo.
>>
>> > As it seems the primary grievance here is collocating an implementation
>> of
>> > Lightning along with the _specification_ of the protocol, and given
>> that the
>> > spec was added last, how about we move the spec to an independent repo
>> owned
>> > by the community? I currently have github.com/lightning, and would be
>> happy
>> > to donate it to the community, or we could create a new org like
>> > "lightning-specs" or something similar.
>>
>> Sounds great! github.com/lightning is nice (and I like Damian's idea
>> of using github.com/lightning/bolts) and seems to please everyone so
>> it looks that we have a plan!
>>
>> Fabrice
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20211102/4644941c/attachment.html>;

📅 Original date posted:2021-11-03 📝 Original message: ...

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

In reply to nevent1q…s6lt
_________________________

📅 Original date posted:2021-11-03
📝 Original message:
Circling back to close the loop here:

* The new Github org (https://github.com/lightning) now exists, and all
the
major implementation maintainers have been added to the organization as
admins.

* A new blips repo (https://github.com/lightning/blips) has been created
to
continue the PR that was originally started in the lightning-rfc
repo.

* The old lightning-rfc repo has been moved over, and been renamed to
"bolts"
(https://github.com/lightning/bolts -- should it be all caps? )

Thanks to all that participated in the discussion (particularly in meatspace
during the recent protocol dev meetup!), happy we were able to resolve
things
and begin the next chapter in the evolution of the Lightning protocol!

-- Laolu

On Fri, Oct 15, 2021 at 1:49 AM Fabrice Drouin <fabrice.drouin at acinq.fr>
wrote:

> On Tue, 12 Oct 2021 at 21:57, Olaoluwa Osuntokun <laolu32 at gmail.com>
> wrote:
> > Also note that lnd has _never_ referred to itself as the "reference"
> > implementation. A few years ago some other implementations adopted that
> > title themselves, but have since adopted softer language.
>
> I don't remember that but if you're referring to c-lightning it was
> the first lightning implementation, and the only one for a while, so
> in a way it was a "reference" at the time ?
> Or it could have been a reference to their policy of "implementing the
> spec, all the spec and nothing but the spec" ?
>
> > I think it's worth briefly revisiting a bit of history here w.r.t the
> github
> > org in question. In the beginning, the lightningnetwork github org was
> > created by Joseph, and the lightningnetwork/paper repo was added, the
> > manuscript that kicked off this entire thing. Later lightningnetwork/lnd
> was
> > created where we started to work on an initial implementation (before the
> > BOLTs in their current form existed), and we were added as owners.
> > Eventually we (devs of current impls) all met up in Milan and decided to
> > converge on a single specification, thus we added the BOLTs to the same
> > repo, despite it being used for lnd and knowingly so.
>
> Yes, work on c-lightning then eclair then lnd all began a long time
> before the BOLTs process was implemented, and we all set up repos,
> accounts...
> I agree that we all inherited things from the "pre-BOLTS" era and
> changing them will create some friction but I still believe it should
> be done. You also mentioned potential admin rights issues on the
> current specs repos which would be solved by moving them to a new
> clean repo.
>
> > As it seems the primary grievance here is collocating an implementation
> of
> > Lightning along with the _specification_ of the protocol, and given that
> the
> > spec was added last, how about we move the spec to an independent repo
> owned
> > by the community? I currently have github.com/lightning, and would be
> happy
> > to donate it to the community, or we could create a new org like
> > "lightning-specs" or something similar.
>
> Sounds great! github.com/lightning is nice (and I like Damian's idea
> of using github.com/lightning/bolts) and seems to please everyone so
> it looks that we have a plan!
>
> Fabrice
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20211102/c53feb8f/attachment.html>;

📅 Original date posted:2020-10-12 📝 Original message: > ...

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

In reply to nevent1q…ejm6
_________________________

📅 Original date posted:2020-10-12
📝 Original message:
> I suggest adding tlv records in `commitment_signed` to tell our channel >
> peer that we're changing the values of these fields.

I think this fits in nicely with the "parameter re-negotiation" portion of
my
loose Dynamic commitments proposal. Note that in that paradigm, something
like this would be a distinct message, and also only be allowed with a
"clean commitment" (as otherwise what if I reduce the number of slots to a
value that is lower than the number of active slots?). With this, both sides
would be able to propose/accept/deny updates to the flow control parameters
that can be used to either increase the security of a channel, or implement
a sort of "slow start" protocol for any new peers that connect to you.

Similar to congestion window expansion/contraction in TCP, when a new peer
connects to you, you likely don't want to allow them to be able to consume
all the newly allocated bandwidth in an outgoing direction. Instead, you may
want to only allow them to utilize say 10% of the available HTLC bandwidth,
slowly increasing based on successful payments, and drastically
(multiplicatively) decreasing when you encounter very long lived HTLCs, or
an excessive number of failures.

A dynamic HTLC bandwidth allocation mechanism would serve to mitigate
several classes of attacks (supplementing any mitigations by "channel
acceptor" hooks), and also give forwarding nodes more _control_ of exactly
how their allocated bandwidth is utilized by all connected peers. This is
possible to some degree today (by using an implicit value lower than
the negotiated values), but the implicit route doesn't give the other party
any information, and may end up in weird re-send loops (as they _why_ an
HTLC was rejected) wasn't communicated. Also if you end up in a half-sign
state, since we don't have any sort of "unadd", then the channel may end up
borked if the violating party keeps retransmitting the same update upon
reconnection.

> Are there other fields you think would need to become dynamic as well?

One other value that IMO should be dynamic to protect against future
unexpected events is the dust limit. "It Is Known", that this value "doesn't
really change", but we should be able to upgrade _all_ channels on the fly
if it does for w/e reason.

-- Laolu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20201012/1700eb6d/attachment.html>;

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

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

In reply to nevent1q…zsl5
_________________________

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

Great findings!

I think an even simpler mitigation is just for the non-initiator to _reject_
update_fee proposals that are "unreasonable". The non-initiator can run a
"fee leak calculation" to compute the worst-case leakage of fees in the
revocation case. This can be done to day without any significant updates to
implementations, and some implementations may already be doing this.

One issue is that we don't have a way to do a "soft reject" of an update_fee
as is. However, depending on the implementations, it may be possible to just
reconnect and issue a co-op close if there're no HTLCs on the commitment
transaction.

As you mentioned by setting proper values for max allowed htlcs, max in
flight, reserve, etc, nodes are able to quantify this fee leak risk ahead of
time, and set reasonable parameters based on their security model. One issue
is that these values are set in stone rn when the channel is opened, but
future iterations of dynamic commitments may allow us to update them on the
fly.

In the mid-term, implementations can start to phase out usage of update_fee
by setting a minimal commitment fee when the channel is first opened, then
relying on CPFP to bump up the commitment and any HTLCs if needed. This
discovery might very well hasten the demise of update_fee in the protocol
all together as well. I don't think we need to depend entirely on a
theoretical package relay Bitcoin p2p upgrade assuming implementations are
willing to make an assumption that say 20 sat/byte or w/e has a good chance
of widespread propagation into mempools.

>From the perspective of channel safety, and variations of attacks like
"flood & loot", imo it's absolutely critical that nodes are able to update
the fees on their second-level HTLC transactions. As this is where the real
danger lies: if nodes aren't able to get 2nd level HTLCs in the chain in
time, then the incoming HTLC expiry will expire, creating a race condition
across both commitments which can potentially cascade.

In lnd today, anchors is still behind a build flag, but we plan to enable
it by default for our upcoming 0.12 release. The blockers on our end were to
add support for towers, and add basic deadline aware bumping, both of which
are currently on track. We'll now also look into setting clamps on the
receiver end to just not accept unreasonable values for the fee rate of a
commitment, as this ends up eating into the true HTLC values for both sides.

-- Laolu

On Thu, Sep 10, 2020 at 9:28 AM Antoine Riard <antoine.riard at gmail.com>
wrote:

> Hi,
>
> In this post, I would like to expose a potential vulnerability introduced
> by the recent anchor output spec update related to the new usage of
> SIGHASH_SINGLE for HTLC transactions. This new malleability combined with
> the currently deployed mechanism of `update_fee` is likely harmful for
> funds safety.
>
> This has been previously shared with deployed implementations devs, as
> anchor channels are flagged as experimental it's better to discuss and
> solve this publicly. That said, if you're currently running experimental
> anchor channels with non-trusted parties on mainnet, you might prefer to
> close them.
>
> # SIGHASH_SINGLE and `update_fee` (skip it if you're familiar)
>
> First, let's get started by a quick reminder of the data set committed by
> signature digest algorithm of Segwit transactions (BIP 143):
> * nVersion
> * hashPrevouts
> * hashSequence
> * outpoint
> * scriptCode of the input
> * value of the output spent by this input
> * nSequence of the input
> * hashOutputs
> * nLocktime
> * sighash type of the signature
>
> Anchor output switched the sighash type from SIGHASH_ALL to SIGHASH_SINGLE
> | SIGHASH_ANYONECANPAY for HTLC signatures sent to your counterparty. Thus
> it can spend non-cooperatively its HTLC outputs on its commitment
> transactions. I.e when Alice broadcasts her commitment transaction, every
> Bob's signatures on Alice's HTLC-Success/Timeout transactions are now
> flagging the new sighash type.
>
> Thus `hashPrevouts`, `hashSequence` (ANYONECANPAY) and `hashOutputs`
> (SINGLE) aren't committed anymore. SINGLE only enforces commitment to the
> output scriptpubkey/amount at the same index that
> the spending input. Alice is free to attach additional inputs/outputs to
> her HTLC transaction. This change is aiming to let a single-party bump the
> feerate of 2nd-stage HTLC transactions in case of mempool-congestion,
> without counterparty cooperation and thus make HTLC funds safer.
>
> The attached outputs are _not_ encumbered by a revokeable redeemscript for
> a potential punishment.
>
> That said, anchor ouput spec didn't change disable the current fee
> mechanism already covering HTLC transactions. Pre/post-anchor channels are
> negotiating a feerate through `update_fee` exchange, initiated by the
> channel funder. This `update_fee` can be rejected by the receiver if it's
> deemed unreasonable compared to your local fee estimator view, but as of
> today implementations are pretty liberal in their acceptance, admitting a
> divergence from a scale of 1 to no-bound at all.
>
> This negotiated feerate (`feerate_per_kw`) is used by channel participants
> to compute effective fees which have to be deduced either from the funder
> balance output for commitment transactions or from HTLC output value for
> HTLC transactions.
>
> # The Vulnerability : a Penalty Escape Vector
>
> By increasing the feerate thanks to `update_fee`, a malicious party can
> inflate fees committed on HTLC input/output pairs and redirect this
> inflated fee to a single-controlled output attached to these malleable
> pairs. This won't be punishable by an honest party in case of revoked state
> broadcast and thus enable to partially escape the penalty.
>
> As an example, Alice and Bob have a 100_000 sats channel. `feerate_per_kw`
> is 10000 sats.
>
> At state N, Alice balance is all on her side. She announces 10 outgoing
> HTLCs of value 7000 sats.
>
> As Commitment tx weight with 10 outputs is 2844 (post-anchor), the
> absolute fee committed is 28440 sats.
>
> As HTLC-timeout weight is 666 (post-anchor), the absolute fee committed is
> of 6660 sat, the HTLC tx output as counter-signed by Bob is of 340 sat.
> This absolute fee aims to pay the miner fee in case Alice needs to timeout
> HTLC onchain.
>
> Her remaining balance is 1560 sat, above both dust_limit_satoshi and the
> channel reserve as constrained by Bob (likely 1%).
>
> Alice waits for HTLCs to expire and advances state to N+1. Then she
> empties her balance minus reserve by sending a HTLC relayed by Bob either
> to a colluding channel on the rest of network or back to an onchain address
> thanks to a swap service.
>
> At state N+2, Alice finalizes HTLC-timeout of state N by capturing almost
> all of the absolute fee to a new P2WPKH output only controlled by her. She
> broadcasts the revoked commitment tx N and burns 28440 sats in commitment
> fee.
>
> Her balance of 1560 sats is punished by Bob's justice transaction.
>
> After confirmation and thus maturing of the CSV of 1 on her HTLC output
> Alice broadcasts her 10 HTLC-timeout sending back to her 6660 sat - 660 to
> pay a low-fee. Bob punishes the 10 HTLC-timeout outputs of 340 sats.
>
> Alice gain = 99_000 (swap spend) + 66_660 (HTLCs escape) - 1560
> (commitment balance punishment) - 28440 (commitment fee) - 660*10 (HTLCs
> fees) - 340*10 (HTLCs output) = 125600 sats.
>
> Alice's gain is superior at channel value as it has been partially
> double-spend by bypassing the revocation punishment.
>
> # Limitations of Attacker Success
>
> A first limitation of attack success which can be point of is the fact
> that post-anchor HTLC outputs are CSV'ed by 1, which means in theory a
> honest party can punish this output before the malicious spend them with
> the revoked HTLC txn. In practice a malicious party can attach a branch of
> descendants to its anchor output and that way only allowing one more
> mempool victim's transaction on the revoked commitment. The victim must
> spend all outputs at once or otherwise they're going to obstrucate each
> other at mempool acceptance.
>
> Secondly, other limitations are the per-implementation channel policy
> `max_accepted_htlcs`, `max_htlc_value_in_flight`, `channel_reserve` and
> acceptance bound of `update_fee`. A quick look at default policies, even if
> they vary between deploy implementations, let it think there is room to
> escape a substantial part of channel value.
>
> Lastly, after the revoked commitment transaction is confirmed, both
> attacker and victim are in a feerate race to confirm either a justice
> transaction or a malicious HTLC-timeout. As fee estimator logic of the
> victim's implementation is a public piece of knowledge, it shouldn't be
> hard for the attacker to know the range of the first fee bid and override
> it by a bit to confirm it before the victim RBF at next block. Currently,
> not all implementations have RBF of justice transactions.
>
> As of today, if anchor output is deployed and given how LN implementations
> are managing fees/rebroadcast of onchain transactions, the chance of attack
> success sounds high in my opinion.
>
> # Countermeasures
>
> Channel policies could be tighter, like bounded further down
> `max_accepted_htlcs` or restraining acceptance of `update_fee`. For the
> latter, it's pretty hard as a) fee estimators diverge on mempool views b)
> an attacker can craft escape HTLC-txn in a period of high-fee and patiently
> waits a low-fee period to launch the exploitation.
>
> Justice transactions can adopt a scorched earth approach binding their
> feerate to the max to increase odds of winning the feerate race and thus
> deter attackers. But this sounds like introducing a griefing attack vector.
> Your counterparty can burn more of your lawful balance in fees than you'll
> punish its revoked balance.
>
> A workable option would be to patch current anchor spec to remove
> `feerate_per_kw` appliance on 2nd-stage transactions, maybe just committing
> a minimal relay fee.
>
> Thoughts of further countermeasures ?
>
> I think the vulnerability described is mostly right but please point any
> missing details.
>
> Cheers,
>
> Antoine
> _______________________________________________
> 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/20200910/24240038/attachment-0001.html>;

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

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

In reply to nevent1q…6ds8
_________________________

📅 Original date posted:2020-06-21
📝 Original message:
Hi Rene,

IMO this is mostly mitigated by anchor commitments. The impact of this
attack is predicated on the "victim" paying 5x on-chain fees (for their
confirmation target) to sweep all their HTLCs. Anchor commitments let the
initiator of the channel select a very low starting fee (just enough to get
into the mempool), and also let them actually bump the fees of second-level
HTLC transactions.

In addition to being able to pay much lower fees ("just enough" to get into
the chain), anchor commitments allow second-level HTLC _aggregation_, This
means that for HTLCs with the same expiry height, a peer is able to _batch_
them all into a single transaction, further saving on fees.

lnd shipped with a form of anchor commitments in our past major release
(v0.10.0-beta). In that release the format is opt in, and is enabled with a
startup command-line flag. For 0.11, we're planning on making this the
default commitment type, giving all users that update the ability to
_finally_ have proper fee control of their commitments, and second-level
HTLC transactions.

> The direction of HTLCs are chosen so that the amount is taken from the
> `to_remote` output of the attacker (obviously on the victims side it will
> be the `to_local` output)

One relevant detail here is that if the attacker is to attempt this with
minimal setup, then they'll need to be the ones that open the channel.
Since they're the initiator, they'll actually be the ones paying the fees
rendering this attempt moot.

Alternatively, they could use something like Lightning Loop to gain the
_outbound_ bandwidth (Loop In) needed to attempt this attack (using inbound
opened channels, but they'll need to pay for that bandwidth, adding a
further cost to the attack. Not to mention that they'll need to pay on-chain
fees to sweep the HTLCs they created themselves. In short, this attack isn't
costless as they'll need to acquire outbound liquidity for an incoming
channel, and also need to pay fees independent of the "success" of their
attack.

> I quote from BOLT 02 which suggests a buffer of a factor of 5

I'm not sure how many implementations actually follow this in practice.
FWIW, lnd doesn't.

> Additionally the victim will also have to swipe all offered HTLCs (which
> will be additional costs but could be done once the fees came down) so we
> neglect them.

No, the attacker is the one that needs to sweep these HTLCs, since they
offered them. This adds to their costs.

> Knowing that this will happen and that the victim has to spend those funds
> (publishing old state obviously does not work!) the attacker has a time
> window to blackmail the victim outside of the lightning network protocol

I don't think this is always the case. Depending on the minimum HTLC
settings in the channel (another mitigation), and the distribution of funds
in the channel, it may be the case that the victim doesn't have any funds in
the channel at all (everything was on the attacker's side). In that case,
the "victim" doesn't really care if this channel is clogged up as they
really have no stake in this channel.

> Also you might say that an attacker needs many incoming channels to
> execute this attack. This can be achieved by gaming the autopilot.

As mentioned above, gaining purely incoming channels doesn't allow the
attacker to launch this attack, as they'll be unable to _send out_ from any
of those channels.

> 1. The current solution is to just not use up the max value of htlc's.
> Eclaire and c-lightning by default only use up to 30 htlcs.

IMO, this isn't a solution. Lowering the max number of HTLCs in-flight just
makes it easier (lowers the capital costs) to jam a channel. The authors of
the paper you linked have another paper exploring these types of attacks
[1], and cite the _hard coded_ limit of 483 HTLCS as an enabling factor.

> 2. Probably the best fix (not sure if I understand the consequences
> correctly) is coming from this PR to bitcoin core

I think you're misinterpreting this PR, but see my first paragraph about
anchor commitments which that PR enables.

> 3. Don't overpay fees in commitment transactions. We can't foresee the
> future anyway

Anchors let you do this ;)

> 4. Don't add htlcs for which the on chain fee is higher than the HTLCs
> value (like we do with sub dust amounts and sub satoshi amounts.

This is already how "dust HTLCs" are calculated. The amount remaining from
the HTLC after it pays for its second-level transaction needs to be above
dust. This policy can be asymmetric across commitments in the channel.

> 5. Somehow be able to aggregate htlc's.

Anchors let you do this on the transaction level (MIMO 2nd level HTLC
transactions).

I hope other implementations join lnd in deploying anchor commitments to
mitigate nuisance attacks like this, and _finally_ give users better fee
control for channels and any off-chain contracts within those channels.

BTW, the "Flood & Loot" paper you linked mentions anchor commitments as a
solution towards the end of the paper. However, they erroneously state that
an attacker would be able to spend their HTLC with a _non replaceable_
transaction. This isn't the case since all redemption paths are encumbered
with a CSV delay of 1. This delay forces the attacker to spend the output
with an input that has a non-final sequence, meaning the transaction is
RBF-able.

[1]: https://arxiv.org/abs/2002.06564

-- Laolu

On Wed, Jun 17, 2020 at 3:30 AM René Pickhardt via Lightning-dev <
lightning-dev at lists.linuxfoundation.org> wrote:

> Hey everyone and of course good morning ZmnSCPxj (:
>
> about 11 months ago I discovered a potential blackmail attack with HTLCs
> after answering this question on stack exchange (c.f
> https://bitcoin.stackexchange.com/questions/89232/why-is-my-spendable-msat-much-lower-than-msatoshi-to-us/89235#89235).
> This attack is similar to the one that was possible with tx malleability on
> the funding transaction without the segwit upgrade (c.f.
> https://commons.wikimedia.org/w/index.php?title=File:Introduction_to_the_Lightning_Network_Protocol_and_the_Basics_of_Lightning_Technology_(BOLT_aka_Lightning-rfc).pdf&page=126).
> Meaning an attacker can force a victim to lose money and use this fact to
> blackmail the victim, to potentially gain / steal some of the lost funds.
>
> TL;DR:
> =====
> * Depending on the circumstances this attack allows an attacker to make
> channel partners lose a substantial amount of BTC without substantial costs
> for the attacker.
> * Depending on the exact circumstances this could be for example ~0.15
> BTC. In particular it demonstrates why opening a channel is not an entirely
> trustless activity.
> * The attacker will reliably only be able to force the victim to lose this
> amount of Bitcoin.
> * It is not clear how in practice the attacker could gain this amount or
> parts of it as this would involve not only game theory but also rather
> quick communication between attacker and victim and customized Lightning
> nodes which at least for the victim would be unlikely to exist.
> * None of the suggested fixes seems to be satisfying though the current
> solution of lowering the maximum amount of HTLCs that can concurrently be
> in flight seems to be a reasonable start for now.
>
>
> Timeline on Disclosure
> =================
> I have disclosed this attack on Sunday July 21st 2019 to Fabrice Drouin
> (and shortly after to Christian Decker) in a phone call who in turn has
> discussed it with people from the other implementations. From his feedback
> I understood that people working on implementations have been more or less
> aware of the possibility of this attack. Fabrice also mentioned that he
> believed implementations currently try to mitigate this by setting low
> limits of allowed / accepted HTLCs in flight. However at that time this was
> only true for e-clair. It is now also true for c-lightning and as far as I
> know still not true for lnd. Fabrice said that the people he talked to have
> suggested that I should eventually describe the attack in public to raise
> awareness (also from the group of node operators) for the problems related
> to this attack. He also suggested that - if I wanted to - I should update
> the rfc with recommendations and warnings. While I already have in mind
> how to change the rfc I wanted to start the discussion first. Maybe some
> people find better fixes than just a warning that I have in mind. So far I
> didn't do anything because I wanted to also give lnd the chance to handle
> the problem.
>
> There are two reasons I disclose this attack today:
> 1.) I think almost 1 year is enough time to do something about it. The
> only implementation that afaik didn't yet is lnd (see below) but I got
> roasbeefs ok last week to go ahead and publish the attack anyway so that we
> can have a broader discussion on mitigation strategies.
> 2.) The attack seems actually very similar to the one described in the
> "Flood & Loot: A Systemic Attack On The Lightning Network" - paper which
> came out 2 days ago (c.f.: https://arxiv.org/abs/2006.08513 ). I believe
> any person reading that paper will understand the possibility of the attack
> that I describe anyway so I believe it is now more or less public anyway
> and thus time for an open / public discussion.
>
> The main difference between the two attacks (if I understand this novel
> paper correctly) is: In the "flood and loot"-attack one tries to steal the
> HTLC output of the victims. Where in the "flood and blackmail"-attack that
> I describe I try to to force the victim to lose almost all its funds due to
> high on chain fees (Which I could use to blackmail the victim)
>
> Description of the attack
> ===================
> Let us assume the victim has funded a channel with an attacker meaning it
> will have to pay the fees for the commitment transaction in case of a force
> close.
>
> During a fee spike (let us assume fee estimators suggest 150 sat / byte)
> the attacker spams this channel with the maximum possible amount of HTLCs
> that the protocol allows. The HTLCs can be of a small value but need to be
> bigger than the dust limit so that additional outputs are actually added to
> the commitment transaction which makes it quite large in Bytes. According
> to the BOLTs these are 483 additional outputs to the commitment
> transaction.
> The direction of HTLCs are chosen so that the amount is taken from the
> `to_remote` output of the attacker (obviously on the victims side it will
> be the `to_local` output) For the actual attack it does not matter in which
> direction the HTLCs are spammed but economically the direction I propose
> makes even more sense for the attacker and can be achieved with circular
> onions.
>
> The attacked channel partner will happily - according to the protocol -
> use a higher fee than the current fee rate. I quote from BOLT 02 which
> suggests a buffer of a factor of 5
> https://github.com/lightningnetwork/lightning-rfc/blob/master/02-peer-protocol.md#updating-fees-update_fee:
>
>
> > The node responsible for paying the Bitcoin fee [...] SHOULD send
> update_fee to ensure the current fee rate is sufficient (by a significant
> margin) for timely processing of the commitment transaction. [...] Given
> the variance in fees, and the fact that the transaction may be spent in the
> future, it's a good idea for the fee payer to keep a good margin (say 5x
> the expected fee requirement); but, due to differing methods of fee
> estimation, an exact value is not specified.
>
> This overpayment of fees will result in 750 sat / byte for this fee spike
> scenario. This is by the way not completely unrealistic [I recently opened
> a channel with 2.56 sat / byte (c.f.:
> https://www.smartbit.com.au/tx/c0ac6cfe15e0d0c921362ab9fad998a8a8e16cd8d9d4159487dd69141ea2b9b0)
> and the channel was force closed a couple minutes later due to an
> implementation bug resulting in fees of 101.17 sat / byte (c.f.:
> https://www.smartbit.com.au/tx/e32135315ec147bb27f771b2e15c7178ea573afd16cd4970bf814c9b18bc46e3
> )
>
> As far as I understand the appendix of BOLT 03 offered HTLCs are 43 Byte
> in size (c.f.:
> https://github.com/lightningnetwork/lightning-rfc/blob/master/03-transactions.md#appendix-a-expected-weights)
> resulting in the following additional fees for the spammed commitment
> transaction:
>
> fee (for 483 htlcs) = 483 * 43 byte * 750 sat / byte = 15576750 sat =
> 0.1557675 BTC
>
> Additionally the victim will also have to swipe all offered HTLCs (which
> will be additional costs but could be done once the fees came down) so we
> neglect them.
>
> Once all HTLCs are set up the attacker will stop signing commitment
> transactions. In the beginning this is not suspicious as the HTLCs will
> take some time to settle anyway. But also when fees go down and the victim
> who funded the channel wants to update the fees the attacker will just not
> be responsive. Eventually the victim will dare to force close the channel
> with all those expensive HTLCs.
>
> Knowing that this will happen and that the victim has to spend those funds
> (publishing old state obviously does not work!) the attacker has a time
> window to blackmail the victim outside of the lightning network protocol:
> "Either you will pay those 0.1557675 BTC of fees or we will collaboratively
> close the channel but that will cost you part of the amount you lost." Game
> theory suggests that the attacker will be able to claim the major fraction
> of the BTC (c.f. https://en.wikipedia.org/wiki/Ultimatum_game that are
> frozen in tx fees as the victim effectively already has lost that money and
> can only gain something back.
>
>
> Thoughts
> =======
> You might say that the blackmail part of this attack is unrealistic as the
> blackmailing person will not have enough time to successfully do the
> blackmail as the channel that is not operational will fail.
>
> 1.) The only thing that lightning nodes might do is a fee update as the
> htlcs stuffed the channel so I believe there is actually some time to
> contact the victim.
> 2.) What if the attacker is a mining pool who is just interested in high
> fees who does not even need to do the blackmailing stuff but will just
> force close the channel once the htlcs are set up?
> 3.) The attacker might not even be interested in blackmailing the victim.
> The attacker could just be interested in harming the victim. Though it
> might certainly be a challenge to target a specific victim and trick it
> into opening a channel with an attacker.
>
> Also you might say that an attacker needs many incoming channels to
> execute this attack. This can be achieved by gaming the autopilot. an
> attacker can start by creating many channels making him a highly likely
> channel partner for autopilot users (who will also fund the channel). Such
> a highly connected node might also be interesting for non autopilot users.
>
> Implementations
> ============
>
> I looked at the code myself. I hope I do oversee things but to me it looks
> like only eclaire was somehow mitigating this attack from being exploited.
> (by a default config of 30 accepted htlcs which will protect the average
> user and is much lower than the 483) and c-lightning has merged a patch
> from me which I provided after I disclosed the attack:
>
> ## clightning:
>
> c-lightning did not by default set a hard cap on htlcs before version
> 0.7.2 but then merged my patch
> https://github.com/ElementsProject/lightning/pull/2858 which tried to
> resemble the eclair defaults
>
> ## eclaire:
>
> the max accepted htlc value per channel is set as a constant to 483 which
> follows the recommendation of the BOLTs:
>
> https://github.com/ACINQ/eclair/blob/e62adf2deae213d2cd0f2a6874227dcfc57880ae/eclair-core/src/main/scala/fr/acinq/eclair/channel/Channel.scala#L52
>
> The value is tested against at:
>
> https://github.com/ACINQ/eclair/blob/f724efaa76b256048de18f706e9cb58ecbebd6aa/eclair-core/src/main/scala/fr/acinq/eclair/channel/Helpers.scala#L99
>
> and:
>
> https://github.com/ACINQ/eclair/blob/f724efaa76b256048de18f706e9cb58ecbebd6aa/eclair-core/src/main/scala/fr/acinq/eclair/channel/Helpers.scala#L132
>
> and:
>
> https://github.com/ACINQ/eclair/blob/93d9369f900766171f2ddf579e8b12e28d8f0d25/eclair-core/src/main/scala/fr/acinq/eclair/channel/Commitments.scala#L154
>
> However the default config file specifies a maximum amount of 30 accepted
> htlcs at:
>
> https://github.com/ACINQ/eclair/blob/9afb26e09c69dd5d6a14732baf5dcdf2b7a9142b/eclair-core/src/main/resources/reference.conf#L62
>
>
> ## lnd
> It seems like lnd did not and last time I checked (maybe I oversaw
> something) does not set a hard cap on htlcs by default. The way how I
> understand the code they allow up to 483 htlcs by default:
>
> The test when adding an htlc if it is beyond the maximum accepted values
> is here:
>
> https://github.com/lightningnetwork/lnd/blob/970d7604071baae227db42d4665ef9d1b56988e8/lnwallet/channel.go#L3795
>
> the default configuration seems to be here (and in the most recent commit
> the line still exists):
>
> https://github.com/lightningnetwork/lnd/blob/8b04cfbf12f460853e8c55611cd1bba21b1510ef/input/size.go#L187
>
> the software will accept up to 483 htlcs according to this line:
>
> https://github.com/lightningnetwork/lnd/blob/111cbeaa990cba78563d6cc8c19b152e2d3042f6/lnwallet/reservation.go#L314
>
> I could not find any spec lower than that in the suggested sample config
> at:
> https://github.com/lightningnetwork/lnd/blob/master/sample-lnd.conf
>
>
> Ideas for Fixes
> ===========
>
> I am completely unhappy with each of the following ideas. I hope you will
> come up with smarter solutions. I believe the solution is not obvious. Thus
> I thought it makes sense in the brainstorm phase to even post some ideas
> with obvious drawbacks.
>
> 1. The current solution is to just not use up the max value of
> htlc's. Eclaire and c-lightning by default only use up to 30 htlcs.
> 2. Probably the best fix (not sure if I understand the consequences
> correctly) is coming from this PR to bitcoin core (c.f.
> https://github.com/bitcoin/bitcoin/pull/15681 by @TheBlueMatt . If I get
> it correctly with that we could always have low fees and ask the person who
> want to claim their outputs to pay fees. This excludes overpayment and
> could happen at a later stage when fees are not spiked. Still the victim
> who offered the htlcs would have to spend those outputs at some time.
> 3. Don't overpay fees in commitment transactions. We can't foresee the
> future anyway
> 4. Don't add htlcs for which the on chain fee is higher than the HTLCs
> value (like we do with sub dust amounts and sub satoshi amounts. This would
> at least make the attack expensive as the attacker would have to bind a lot
> of liquidity.
> 5. Somehow be able to aggregate htlc's. In a world where we use payment
> points instead of preimages we might be able to do so. It would be really
> cool if separate HTLC's could be combined to 1 single output. I played
> around a little bit but I have not come up with a scheme that is more
> compact in all cases. Thus I just threw in the idea.
> 6. Split onchain fees differently (now the attacker would also lose fees
> by conducting this attack) - No I don't want to start yet another fee
> bikeshadding debate. (In particular I believe that a different split of
> fees might make the Flood & Loot attack economically more viable which
> relies on the same principle)
>
> Independently I think we should have a hint in our readme file about where
> and how people can disclose attacks and vulnerabilities. Implementations
> have this but the BOLTs do not.
>
> with kind regards Rene
>
> --
>
> https://www.rene-pickhardt.de
>
> Skype: rene.pickhardt
> _______________________________________________
> 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/20200621/992826d6/attachment-0001.html>;

📅 Original date posted:2020-04-23 📝 Original message: (this ...

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

In reply to nevent1q…h2jj
_________________________

📅 Original date posted:2020-04-23
📝 Original message:
(this may be kind of off-topic, more about DLC deployment than PTLCs
themselves)

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

Without oracles, none of it really works. Although, it's also the case that
there're measures to prevent the oracles from equivocating (reporting two
conflicting prices/events for a particular instance), bootstrapping a new
oracle still requires a very high degree of trust as they can lie or report
incorrect data. As a result, actually deploying an oracle for a system like
this is tricky business, as it's a trusted centralized entity, so it will
run into all the normal meatspace/legal/operational risk that any trusted
centralized service would encounter.

Earlier today, Coinbase announced that they were releasing a new price
oracle for the ETH ecosystem [1]. This caught my attention as one can
imagine, that it would be even simpler for them to deploy a DLC oracle which
exports an API to obtain signed prices/events. As an existing large company
in the space (depending on who you talk to), they're a trusted entity, which
has earned a good reputation over the years (solving this
bootstrapping/trust issue). If they do eventually grow the service to also
encompass this use case, then it enables a number of possibilities, as
there's still a ton of value in just base DLC-specific channels (or one off
contracts), without all the fancy barrier escrow scriptless scipts swappy
swap swap stuff.

-- Laolu

[1]:
https://blog.coinbase.com/introducing-the-coinbase-price-oracle-6d1ee22c7068

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
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200423/61661e72/attachment-0001.html>;

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

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

In reply to nevent1q…nad8
_________________________

📅 Original date posted:2020-04-22
📝 Original message:
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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200422/9849bd91/attachment-0001.html>;

📅 Original date posted:2020-04-22 📝 Original message: > ...

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

In reply to nevent1q…sw6l
_________________________

📅 Original date posted:2020-04-22
📝 Original message:
> This seems like a somewhat unnecessary drive-by insult of a project you
> don't contribute to, but feel free to start with a concrete suggestion
> here :).

This wasn't intended as an insult at all. I'm simply saying if there's
concern about worst case eviction/replacement, optimizations likely exist.
Other developers that are interested in more complex multi-transaction
contracts have realized this as well, and there're various open PRs that
attempt to propose such optimizations [1].

> Hmm, maybe the proposal wasn't clear. The idea isn't to add signatures to
> braodcasted transactions, but instead to CPFP a maybe-broadcasted
> transaction by sending a transaction which spends it and seeing if it is
> accepted

Sorry I still don't follow. By "we clearly need to go the other direction -
all HTLC output spends need to be pre-signed.", you don't mean that the HTLC
spends of the non-broadcaster also need to be an off-chain 2-of-2 multi-sig
covenant? If the other party isn't restricted w.r.t _how_ they can spend the
output (non-rbf'd, ect), then I don't see how that addresses anything.

Also see my mail elsewhere in the thread that the other party is actually
forced to spend their HTLC output using an RBF-replaceable transaction. With
that, I think we're all good here? In the end both sides have the ability to
raise the fee rate of their spending transactions with the highest winning.
As long as one of them confirms within the CLTV-delta, then everyone is
made whole.

[1]: https://github.com/bitcoin/bitcoin/pull/18191

On Wed, Apr 22, 2020 at 9:50 AM Matt Corallo <lf-lists at mattcorallo.com>
wrote:

> A few replies inline.
>
> On 4/22/20 12:13 AM, Olaoluwa Osuntokun wrote:
> > Hi Matt,
> >
> >
> >> While this is somewhat unintuitive, there are any number of good
> anti-DoS
> >> reasons for this, eg:
> >
> > None of these really strikes me as "good" reasons for this limitation,
> which
> > is at the root of this issue, and will also plague any more complex
> Bitcoin
> > contracts which rely on nested trees of transaction to confirm (CTV,
> Duplex,
> > channel factories, etc). Regarding the various (seemingly arbitrary)
> package
> > limits it's likely the case that any issues w.r.t computational
> complexity
> > that may arise when trying to calculate evictions can be ameliorated with
> > better choice of internal data structures.
> >
> > In the end, the simplest heuristic (accept the higher fee rate package)
> side
> > steps all these issues and is also the most economically rationale from a
> > miner's perspective. Why would one prefer a higher absolute fee package
> > (which could be very large) over another package with a higher total _fee
> > rate_?
>
> This seems like a somewhat unnecessary drive-by insult of a project you
> don't contribute to, but feel free to start with
> a concrete suggestion here :).
>
> >> You'll note that B would be just fine if they had a way to safely
> monitor the
> >> global mempool, and while this seems like a prudent mitigation for
> >> lightning implementations to deploy today, it is itself a quagmire of
> >> complexity
> >
> > Is it really all that complex? Assuming we're talking about just watching
> > for a certain script template (the HTLC scipt) in the mempool to be able
> to
> > pull a pre-image as soon as possible. Early versions of lnd used the
> mempool
> > for commitment broadcast detection (which turned out to be a bad idea so
> we
> > removed it), but at a glance I don't see why watching the mempool is so
> > complex.
>
> Because watching your own mempool is not guaranteed to work, and during
> upgrade cycles that include changes to the
> policy rules an attacker could exploit your upgraded/non-upgraded status
> to perform the same attack.
>
> >> Further, this is a really obnoxious assumption to hoist onto lightning
> >> nodes - having an active full node with an in-sync mempool is a lot more
> >> CPU, bandwidth, and complexity than most lightning users were expecting
> to
> >> face.
> >
> > This would only be a requirement for Lightning nodes that seek to be a
> part
> > of the public routing network with a desire to _forward_ HTLCs. This
> isn't
> > doesn't affect laptops or mobile phones which likely mostly have private
> > channels and don't participate in HTLC forwarding. I think it's pretty
> > reasonable to expect a "proper" routing node on the network to be backed
> by
> > a full-node. The bandwidth concern is valid, but we'd need concrete
> numbers
> > that compare the bandwidth over head of mempool awareness (assuming the
> > latest and greatest mempool syncing) compared with the overhead of the
> > channel update gossip and gossip queries over head which LN nodes face
> today
> > as is to see how much worse off they really would be.
>
> If mempool-watching were practical, maybe, though there are a number of
> folks who are talking about designing
> partially-offline local lightning hubs which would be rendered impractical.
>
> > As detailed a bit below, if nodes watch the mempool, then this class of
> > attack assuming the anchor output format as described in the open
> > lightning-rfc PR is mitigated. At a glance, watching the mempool seems
> like
> > a far less involved process compared to modifying the state machine as
> its
> > defined today. By watching the mempool and implementing the changes in
> > #lightning-rfc/688, then this issue can be mitigated _today_. lnd 0.10
> > doesn't yet watch the mempool (but does include anchors [1]), but unless
> I'm
> > missing something it should be pretty straight forward to add which mor
> or less
> > resolves this issue all together.
> >
> >> not fixing this issue seems to render the whole exercise somewhat
> useless
> >
> > Depends on if one considers watching the mempool a fix. But even with
> that a
> > base version of anchors still resolves a number of issues including:
> > eliminating the commitment fee guessing game, allowing users to pay less
> on
> > force close, being able to coalesce 2nd level HTLC transactions with the
> > same CLTV expiry, and actually being able to reliably enforce multi-hop
> HTLC
> > resolution.
> >
> >> Instead of making the HTLC output spending more free-form with
> >> SIGHASH_ANYONECAN_PAY|SIGHASH_SINGLE, we clearly need to go the other
> >> direction - all HTLC output spends need to be pre-signed.
> >
> > I'm not sure this is actually immediately workable (need to think about
> it
> > more). To see why, remember that the commit_sig message includes HTLC
> > signatures for the _remote_ party's commitment transaction, so they can
> > spend the HTLCs if they broadcast their version of the commitment (force
> > close). If we don't somehow also _gain_ signatures (our new HTLC
> signatures)
> > allowing us to spend HTLCs on _their_ version of the commitment, then if
> > they broadcast that commitment (without revoking), then we're unable to
> > redeem any of those HTLCs at all, possibly losing money.
>
> Hmm, maybe the proposal wasn't clear. The idea isn't to add signatures to
> braodcasted transactions, but instead to CPFP
> a maybe-broadcasted transaction by sending a transaction which spends it
> and seeing if it is accepted. You only need to
> know the transaction's exact format (ie txid, which we do, since we sent a
> signature for it long ago) to do this, you
> don't have to actually *have* the fully-signed transaction (and you don't).
>
> > In an attempt to counteract this, we might say ok, the revoke message
> also
> > now includes HTLC signatures for their new commitment allowing us to
> spend
> > our HTLCs. This resolves things in a weaker security model, but doesn't
> > address the issue generally, as after they receive the commit_sig, they
> can
> > broadcast immediately, again leaving us without a way to redeem our
> HTLCs.
> >
> > I'd need to think about it more, but it seems that following this path
> would
> > require an overhaul in the channel state machine to make presenting a new
> > commitment actually take at least _two phases_ (at least a full round
> trip).
> > The first phase would tender the commitment, but render them unable to
> > broadcast it. The second phase would then <insert something something
> > scriptless scripts here> enter a new sub-protocol which upon conclusion,
> > gives the commitment proposer valid HTLC signatures, and gives the
> responder
> > what they need to be able to broadcast their commitment and claim their
> > HTCLs in an atomic manner.
> >
> > -- Laolu
> >
> > [1]: https://github.com/lightningnetwork/lnd/pull/3821
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200422/2392c438/attachment-0001.html>;

📅 Original date posted:2019-02-07 📝 Original message: Hi ...

2023-06-09T14:54:11+02:00

In reply to nevent1q…cl08
_________________________

📅 Original date posted:2019-02-07
📝 Original message:
Hi y'all,

Recently we've started to do more design work related to the Sphinx packet
(EOB format, rendezvous protocol). This prompted me to re-visit the original
Sphinx paper to refresh my memory w.r.t some of the finer details of the
protocol. While I was re-reading the paper, I realized that we may be able
to use use SURBs (single-use-reply-blocks) to implement a "payment ACK" for
each sent HTLC.

(it's worth mentioning that switching to HORNET down the line would solve
this problem as well since the receiver already gets a multi-use backwards
route that they can use to send information back to the receiver)

Right now HTLC routing is mainly a game of "send and hope it arrives", as
you have no clear indication of the _arrival_ of an HTLC at the destination.
Instead, you only receive a protocol level message if the HTLC failed for
w/e reason, or if it was successfully redeemed. As part of BOLT 1.1, it was
agreed upon that we should implement some sort of "payment ACK" feature. A
payment ACK scheme is strongly desired as it:

* Allows the sender to actually know when a payment has reached the
receiver which is useful for many higher level protocols. Atm, the
sender is unable to distinguish an HTLC being "black holed" from one
that's actually reached the sender, and they're just holding on to it.
* AMP implementations would be aided by being able to receive feedback on
successfully routed splits. If we're able to have the receiver ACK each
partial payment, then implementations can more aggressively split
payments as they're able to gain assurance that the first 2 BTC of 5
total have actually reached the sender, and weren't black holed.
* Enforcing and relying on ACKs may also thwart silly games receivers
might play, claiming that the HTLC "didn't actually arrive".

Some also call this feature a "soft error" as a possible implementation
might to re-use the existing onion error protocol we've deployed today. For
reference, in order to send back errors back long the route in a way that
doesn't reveal the sender of the HTLC to the receiver (or any of the
intermediate nodes) we re-use the shared secret each hop has derived, and
onion wrap a MAC'd error to the sender. Each hop can't actually check that
they've received a well formed error, but the sender is able to attribute an
error to a node in the route based on which shared secret they're able to
check the MAC with.

The original Sphinx packet format has a way for the receiver to send a
message back to the sender. This was originally envisioned to allow the
receiver to send a replay email/message back to the sender without knowing
who they were, and also in a manner that was bit-wise indistinguishable from
a regular forwarded packet. This is called a SURB or "single use reply
block". A SURB is composed of: a pre-crafted sphinx packet for the
"backwards route" (which can be distinct from the forwards route), the first
hop of the backwards route, and finally a symmetric key to use when
encrypting the reply.

When we more or less settled on using Sphinx, we started to remove things
that we didn't have a clear use for at the time. Two things that were
removed were the original end-to-end payload, and also the SURB. Removing
the payload made the packet size smaller, and it didn't seem realistic to
give _each_ hop a SURB to send reply back.

In order to implement payment ACKs, we can have the sender craft a SURB (for
the ACK), and mark the receipt of the SURB as the payment ACK itself.
Creating and processing a SURB is identical to the regular HTLC packets we
use today. As a result, the code impact to the code sphinx packet logic is
minimal. We'd then also re-introduce the e2e payload so we can carry the
SURB in the forward direction (HLTC add). The backwards packet would also
have a payload of random bytes with the same size as a regular packet to
make them look identical on the wire.

This payload can further be put to use in order to implement streaming or
subscription payments in a way. Since we must add a payload for in order to
send/reply look the same, we can also piggy back some useful additional
data. Each time a payment is sent, the receiver can use the extra payload to
stack on details such as:
* A new invoice to pay for the metered service being paid for.
* An invoice along with a deadline for when this must be paid, lest the
subscription service expire.
* Details of lightning-native API
* etc, etc

IMO, this approach is better than a potential client-server payment
negotiation protocol as it doesn't require any additional servers along side
the node, also maintains sender anonymity, and doesn't rely on any sort of
PKI.

>From the prospective of packet-analysis, errors today are identifiable due
to the packet size (though we do pad them out to avoid being able to
distinguish some errors from others on the wide). SURBs on the other hand,
have the same profile as regular HTLC adds since they use the same Sphinx
packet format. Unlike the wrapped onion errors, intermediate nodes are also
able to validate the integrity of the payment ACK as they'll check the
per-hop
MAC as normal. Additionally, the replies naturally create cover traffic as
they look like regular payments.

One down side is that this would essentially double the size of HTLC
messages on the network today, as they need to also carry SURB. Most
candidates for possible rendezvous schemes to deploy would also increase the
packet size if up to 20 hops it be allowed in both directions. We also
(from my PoV), don't really have a feel on how much of an issue the 1.2KB
HTLC packet size is today in the network.

By re-introducing SURBs, we have an opportunity to cleanly solve the payment
ACK issue, re-use a component of our favorite thing in Lightning, enable
protocol-level streaming/subscription payments and also make replies
indistinguishable-ish from regular payments.

Thoughts?

-- Laolu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190207/77cde3d7/attachment.html>;

📅 Original date posted:2018-11-06 📝 Original message: Hi ...

2023-06-09T14:52:17+02:00

In reply to nevent1q…6t8s
_________________________

📅 Original date posted:2018-11-06
📝 Original message:
Hi Fabrice,

I think HORNET would address this rather nicely!

During the set up phase (which uses Sphinx), the sender is able to get a
sense
of if the route is actually "lively" or not, as the circuit can't be
finalized
if all the nodes aren't available. Additionally, during the set up phase,
the
sender can drop a unique payload to each node. In this scenario, it may be
the
amount range the node is looking to send over this circuit. The intermediate
nodes then package up a "Forwarding Segment" (FS) which includes a symmetric
key to use for their portion of the hop, and can also be extended to include
fee information. If this set up phase is payment value aware, then each node
can use a private "fee function" that may take into account the level of
congestion in their channels, or other factors. This would differ from the
current approach in that this fee schedule need not be communicated to the
wider network, only those wishing to route across that link.

Another cool thing that it would allow is the ability to receive a
protocol-level payment ACK. This may be useful when implementing AMP, as it
would allow the sender to know exactly how many satoshis have arrived at the
other site, adjusting their payment sharding accordingly. Nodes on either
side
of the circuit can then also use the data forwarding phase to exchange
payment
hashes, perform cool zkcp set up protcols, etc, etc.

The created circuits can actually be re-used across several distinct
payments.
In the paper, they use a TTL for each circuit, in our case, we can use a
block
height, after which all nodes should reject attempted data forwarding
attempts.
A notable change is that each node no longer needs to maintain per-circuit
state as we do now with Sphinx. Instead, the packets that come across
contain
all the information required for forwarding (our current per-hop payload).
As a
result, we can eliminate the asymmetric crytpo from the critical forwarding
path!

Finally, this would let nodes easily rotate their onion keys to achieve
forward
secrecy during the data phase (but not the set up phase), as in the FS, they
essentially key-wrap a symmetric key (using the derived shared secret for
that
hop) that should be used for that data forwarding phase.

There're a number of other cool things integration HORNET would allow,
perhaps
a distinct thread would be a more appropriate place to extol the many
virtues
of HORNET ;)

-- Laolu

On Thu, Nov 1, 2018 at 3:05 PM Fabrice Drouin <fabrice.drouin at acinq.fr>
wrote:

> Context
> ======
>
> Sent payments that remain pending, i.e. payments which have not yet
> been failed or fulfilled, are currently a major UX challenge for LN
> and a common source of complaints from end-users.
> Why payments are not fulfilled quickly is not always easy to
> investigate, but we've seen problems caused by intermediate nodes
> which were stuck waiting for a revocation, and recipients who could
> take a very long time to reply with a payment preimage.
> It is already possible to partially mitigate this by disconnecting
> from a node that is taking too long to send a revocation (after 30
> seconds for example) and reconnecting immediately to the same node.
> This way pending downstream HTLCs can be forgotten and the
> corresponding upstream HTLCs failed.
>
> Proposed changes
> ===============
>
> It should be possible to provide a faster "proceed/try another route"
> answer to the sending node using probing with short timeout
> requirements: before sending the actual payment it would first send a
> "blank" probe request, along the same route. This request would be
> similar to a payment request, with the same onion packet formatting
> and processing, with the additional requirements that if the next node
> in the route has not replied within the timeout period (typically a
> few hundred milliseconds) then the current node will immediately send
> back an error message.
>
> There could be several options for the probe request:
> - include the same amounts and fee constraints than the actual payment
> request.
> - include no amount information, in which case we're just trying to
> "ping" every node on the route.
>
> Implementation
> ============
>
> I would like to discuss the possibility of implementing this with a "0
> satoshi" payment request that the receiving node would generate along
> with the real one. The sender would first try to "pay" the "0 satoshi"
> request using the route it computed with the actual payment
> parameters. I think that it would not require many changes to the
> existing protocol and implementations.
> Not using the actual amount and fees means that the actual payment
> could fail because of capacity issues but as long as this happens
> quickly, and it should since we checked first that all nodes on the
> route are alive and responsive, it still is much better than “stuck”
> payments.
> And it would not help if a node decides to misbehave, but would not
> make things worse than they are now (?)
>
> Cheers,
> Fabrice
> _______________________________________________
> 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/20181106/6aeb4330/attachment.html>;

📅 Original date posted:2018-11-06 📝 Original message: Hi ...

2023-06-09T14:52:11+02:00

In reply to nevent1q…nmkm
_________________________

📅 Original date posted:2018-11-06
📝 Original message:
Hi Rusty,

I'm a big fan in general of most of this! Amongst many other things, it'll:
simplify the whole static channel backup + recovery workflow, and avoid all
the fee related headaches we've run into over the past few months.

> - HTLC-timeout and HTLC-success txs sigs are
> SIGHASH_ANYONECANPAY|SIGHASH_SINGLE, so you can Bring Your Own Fees.

Would this mean that we no longer extend fees to the second-level
transactions as well? If so, then a dusty HTLC would be determined solely by
looking at the direct output, rather than the resulting output in the second
layer.

> - `localpubkey`, `remotepubkey`, `local_htlcpubkey`, `remote_htlcpubkey`,
> `local_delayedpubkey`, and `remote_delayedpubkey` derivation now uses a
> two-stage unhardened BIP-32 derivation based on the commitment number.

It seems enough to _only_ modify the derivation for local+remote pubkey (so
the direct "settle" keys). This constrains the change to only what's
necessary to simplify the backup+recovery workflow with the current
commitment design. By restricting the change to these two keys, we minimize
the code impact to the existing implementations, and avoid unnecessary
changes that don't make strides towards the immediate goal.

> - `to_remote` is now a P2WSH of:
> `to_self_delay` OP_CSV OP_DROP <remotepubkey> OP_CHECKSIG

This seems at odds with the goal of "if the remote party force closes, then
I get my funds back immediately without requiring knowledge of any secret
data". If it was just a plain p2wkh, then during a routine seed import and
rescan (assuming ample look ahead as we know this is a "special" key), I
would pick up outputs of channels that were force closed while I was down
due to my dog eating my hard drive.

Alternatively, since the range of CSV values can be known ahead of time, I
can brute force a set of scripts to look for in the chain. However, this
results in potentially a very large number of scripts (depending on how many
channels one has, and bounds on the acceptable CSV) I need to scan for.

-- Laolu

On Fri, Oct 12, 2018 at 3:57 PM Rusty Russell <rusty at rustcorp.com.au> wrote:

> Hi all,
>
> There have been a number of suggested changes to the commitment
> transaction format:
>
> 1. Rather than trying to agree on what fees will be in the future, we
> should use an OP_TRUE-style output to allow CPFP (Roasbeef)
> 2. The `remotepubkey` should be a BIP-32-style, to avoid the
> option_data_loss_protect "please tell me your current
> per_commitment_point" problem[1]
> 3. The CLTV timeout should be symmetrical to avoid trying to game the
> peer into closing. (Connor IIRC?).
>
> It makes sense to combine these into a single `commitment_style2`
> feature, rather than having a testing matrix of all these disabled and
> enabled.
>
> BOLT #2:
>
> - If `commitment_style2` negotiated, update_fee is a protocol error.
>
> This mainly changes BOLT #3:
>
> - The feerate for commitment transactions is always 253 satoshi/Sipa.
> - Commitment tx always has a P2WSH OP_TRUE output of 1000 satoshi.
> - Fees, OP_TRUE are always paid by the initial funder, because it's simple,
> unless they don't have funds (eg. push_msat can do this, unless we
> remove it?)
> - HTLC-timeout and HTLC-success txs sigs are
> SIGHASH_ANYONECANPAY|SIGHASH_SINGLE, so you can Bring Your Own Fees.
> - `localpubkey`, `remotepubkey`, `local_htlcpubkey`,
> `remote_htlcpubkey`, `local_delayedpubkey`, and `remote_delayedpubkey`
> derivation now uses a two-stage unhardened BIP-32 derivation based on
> the commitment number. Two-stage because we can have 2^48 txs and
> BIP-32 only supports 2^31: the first 17 bits are used to derive the
> parent for the next 31 bits?
> - `to_self_delay` for both sides is the maximum of either the
> `open_channel` or `accept_channel`.
> - `to_remote` is now a P2WSH of:
> `to_self_delay` OP_CSV OP_DROP <remotepubkey> OP_CHECKSIG
>
> Cheers,
> Rusty.
>
> [1] I recently removed checking this field from c-lightning, as I
> couldn't get it to reliably work under stress-test. I may just have
> a bug, but we could just fix the spec instead, then we can get our
> funds back even if we never talk to the peer.
> _______________________________________________
> 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/20181106/9aa80d96/attachment.html>;

📅 Original date posted:2018-10-15 📝 Original message: > ...

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

In reply to nevent1q…r98j
_________________________

📅 Original date posted:2018-10-15
📝 Original message:
> I would suggest more to consider the simpler method, despite its larger
> onchain footprint (which is galling),

The on-chain footprint is a shame, and also it gets worse if we start to
allow multiple pending splices. Also the lack of a non-blocking splice in is
a big draw back IMO.

> but mostly because I do not see splicing as being as important as AMP or
> watchtowers (and payment decorrelation seems to affect how AMP can be
> implemented, so its priority also goes up).

Most of what you mention here have _very_ different deployment timelines and
synchronization requirements across clients. For example, splicing is a link
level change and can start to be rolled out immediately. Decorrelation on
the other hand, is a _network_ level change, and would take a considerable
amount of time to reach widespread deployment as it essentially splits the
rouble paths in the network until all/most are upgraded.

If you think any of these items is a higher priority than splicing then you
can simply start working on them! There's no agency that prescribes what
should and shouldn't be pursued or developed, just your willingness to
write some code.

One thing that I think we should lift from the multiple funding output
approach is the "pre seating of inputs". This is cool as it would allow
clients to generate addresses, that others could deposit to, and then have
be spliced directly into the channel. Public derivation can be used, along
with a script template to do it non-interactively, with the clients picking
up these deposits, and initiating a splice in as needed.

-- Laolu

On Thu, Oct 11, 2018 at 11:14 PM ZmnSCPxj via Lightning-dev <
lightning-dev at lists.linuxfoundation.org> wrote:

> Good morning Rusty,
>
> >
> > > It may be good to start brainstorming possible failure modes during
> splice, and how to recover, and also to indicate the expected behavior in
> the proposal, as I believe these will be the points where splicing must be
> designed most precisely. What happens when a splice is ongoing and the
> communication gets disconnected? What happens when some channel failure
> occurs during splicing and we are forced to drop onchain? And so on.
> >
> > Agreed, but we're now debating two fairly different methods for
> > splicing. Once we've decided on that, we can try to design the
> > proposals themselves.
>
> I would suggest more to consider the simpler method, despite its larger
> onchain footprint (which is galling), but mostly because I do not see
> splicing as being as important as AMP or watchtowers (and payment
> decorrelation seems to affect how AMP can be implemented, so its priority
> also goes up). So I think getting *some* splicing design out would be
> better even if imperfect. Others may disagree on priority.
>
> 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/20181015/dca18600/attachment.html>;

📅 Original date posted:2018-10-15 📝 Original message: Hi ...

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

In reply to nevent1q…30mx
_________________________

📅 Original date posted:2018-10-15
📝 Original message:
Hi Rusty,

Happy to get the splicing train rolling!

> We've had increasing numbers of c-lightning users get upset they can't
> open multiple channels, so I guess we're most motivated to allow splicing
of
> existing channels

Splicing isn't a substitute for allowing multiple channels. Multiple
channels allow nodes to:

* create distinct channels with distinct acceptance policies.
* create a mix of public and non-advertised channels with a node.
* be able to send more than the (current) max HTLC amount
using various flavors of AMP.
* get past the (current) max channel size value
* allow a link to carry more HTLCs (due to the current super low max HTLC
values) given the additional HTLC pressure that
AMP may produce (alternative is a commitment fan out)

Is there a fundamental reason that CL will never allow nodes to create
multiple channels? It seems unnecessarily limiting.

> Splice Negotiation:

Any reason to now make the splicing_add_* messages allow one to add several
inputs in a single message? Given "acceptable" constraints for how large the
witness and pkScripts can be, we can easily enforce an upper limit on the
number of inputs/outputs to add.

I like that the intro messages have already been designed with the
concurrent case in mind beyond a simpler propose/accept flow. However is
there any reason why it doesn't also allow either side to fully re-negotiate
_all_ the funding details? Splicing is a good opportunity to garbage collect
the prior revocation state, and also free up obsolete space in watch towers.
Additionally, as the size of the channel is either expanding or contracting,
both sides should be allowed to modify things like the CSV param, reserve,
max accepted htlc's, max htlc size, etc. Many of these parameters like the
CSV value should scale with the size of the channel, not allowing these
parameters to be re-negotiated could result in odd scenarios like still
maintain a 1 week CSV when the channel size has dipped from 1 BTC to 100k
satoshis.

> 1. type: 40 (`splice_add_input`) (`option_splice`)

In order to add nested p2sh inputs, we'll need to also expose the redeem
script here, or add additional fields to allow sides to set a sig script as
well as witness during the signing phase.

> - scriptpubkey is empty, or of form 'HASH160 <20-byte-script-hash> EQUAL'

So no P2SH? :(

> * [`4`:`feerate_per_kw`]

What fee rate is this? IMO we should do commitmentv2 before splicing as then
we can more or less do away with the initiator distinction and have most
fees be ad hoc.

> Splice Signing

It seems that we're missing some fields here if we're to allow the splicing
of inputs to be done in a non-blocking manner. We'll need to send two
revocation points for the new commitment: one to allow it to be created, and
another to allow updates to proceed right after the signing is completed. In
this case we'll also need to update both commitments in tandem until the
splicing transaction has been sufficiently confirmed.

Also, what about change addresses? Are they to be explicitly specified as
splice outs?

> 1. type: 43 (`splice_commitment_signature`) (`option_splice`)

It may be worth pointing out there that we're able to transfer all existing
HTLCs over to the new commitment as additional context.

> 1. type: 45 (`splice_witness`) (`option_splice`)

Should also allow either side to specify the sig script here if we're to
allow nested p2sh (which we should IMO!).

> * [`2`:`len`]
> * [`len`:`witnesses`]

Is the extra length needed if all the witness elements themselves are length
delimited?

It isn't clear in the current draft, but I take it that the splice_signature
is for the old multi-sig?

> so we append to the existing `channel_update` for the original channel,
> using a new `message_flags` field:

IMO, we need to hold off on optional fields for now, until we revisit the
formatting in order to actually get it right. As is now, all the optional
fields are basically serial mandatory soft forks. So clients must understand
the prior in order to understand the following fields. Instead, we
essentially need more of a map design.

> The post-splice reserve is 1% of post-splice capcacity (rounded down).

This should be re-negotiated at time of splice creation, rather than a new
hard coded value in the protocol.

> In addition, you can forget everything about the old channel (including
> old HTLCs and revocation requirements).

We still have the same shachain state however (if we don't allow new state
to be exchanged during the start of the splicing scenario), correct?

-- Laolu

-- Laolu

On Tue, Oct 9, 2018 at 8:46 PM Rusty Russell <rusty at rustcorp.com.au> wrote:

> Hi all!
>
> We've had increasing numbers of c-lightning users get upset they
> can't open multiple channels, so I guess we're most motivated to allow
> splicing of existing channels. Hence this rough proposal.
>
> For simplicity, I've chosen to only allow a single splice at a time.
> It's still complex :(
>
> Feedback welcome!
> --
> Splice Negotiation:
>
> 1. type: 40 (`splice_add_input`) (`option_splice`)
> 2. data:
> * [`32`:`channel_id`]
> * [`8`: `satoshis`]
> * [`32`: `prevtxid`]
> * [`4`: `prevtxoutnum`]
> * [`2`: `scriptlen`]
> * [`scriptlen`: `scriptpubkey`]
>
> 1. type: 41 (`splice_add_output`) (`option_splice`)
> 2. data:
> * [`32`:`channel_id`]
> * [`8`: `satoshis`]
> * [`2`: `scriptlen`]
> * [`scriptlen`: `outscript`]
>
> 1. type: 42 (`splice_all_added`) (`option_splice`)
> 2. data:
> * [`32`:`channel_id`]
> * [`4`:`feerate_per_kw`]
> * [`4`:`minimum_depth`]
>
> Each side sends 0 or more `splice_add_input` and 0 or more
> `splice_add_output` followed by `spice_all_added` to complete the splice
> proposal. This is done either to initiate a splice, or to respond to a
> `splice_*` from the other party.
>
> `splice_add_input` is checked for the following:
> - must not be during a current splice
> - scriptpubkey is empty, or of form 'HASH160 <20-byte-script-hash> EQUAL'
> - `satoshis` doesn't wrap on addition.
> - MAY check that it matches outpoint specified (sig will simply be
> invalid if so), and that outpoint is segwit.
>
> `splice_add_output` is checked for the following:
> - must not be during a current splice
> - `satoshis` is less than or equal to amount owing to proposer, minus
> current reserve, and greater than or equal to `dust_limit_satoshis` we
> sent in our open_channel/accept_channel ,sg.
> - script is one of the approved forms as it is for `shutdown`.
>
> FIXME: Do we disallow splice-out if they specified
> option_upfront_shutdown_script?
>
> `splice_all_added` is checked for the following:
> - average of `feerate_per_kw` by both sides (round down) is sufficient.
> - average of `feerate_per_kw` by both sides not grossly excessive, if we're
> paying some of the fees (see below!)
> - both sides can afford the fees from their post-splice funds (see
> Verification Changes below)
> - maximum of the two `minimum_depth` is not grossly excessive.
> - There is at least one splice_add_input or splice_add_output.
>
> Splice negotiation, like closing negotiation, does not have persistent
> state. Reconnecting forgets previous negotiation.
>
>
> Splice Signing
> --------------
>
> Once `splice_all_added` is both sent and received, we need to create and
> sign both the splice tx itself, and the first commitment transaction
> which spends it (but not in that order!).
>
> 1. One input spends the current funding tx output.
> 2. There is one additional input for each splice_add_input.
> 3. One output creates the new funding tx.
> 4. There is one additional output for each splice_add_output.
> 5. The entire transaction is sorted into BIP69 order.
> 6. The feerate is the sum of the two `feerate_per_kw` divided by 2,
> rounded down.
>
> 1. type: 43 (`splice_commitment_signature`) (`option_splice`)
> 2. data:
> * [`32`:`channel_id`]
> * [`64`:`commitment_signature`]
> * [`2`:`num_htlcs`]
> * [`num_htlcs*64`:`htlc_signature`]
>
> 1. type: 44 (`splice_signature`) (`option_splice`)
> 2. data:
> * [`32`:`channel_id`]
> * [`64`:`splice_signature`]
>
> 1. type: 45 (`splice_witness`) (`option_splice`)
> 2. data:
> * [`32`:`channel_id`]
> * [`2`: `num_witness_elements`
> * [`2`:`len`]
> * [`len`:`witnesses`]
>
> `witnesses` itself is serialized as `num_witness_elements` of:
> * `2`:`len`
> * `len`: `witness_element`
>
> Each side sends `splice_commitment_signature` and waits to receive and
> verify the other side's `splice_commitment_signature` before sending
> `splice_signature` and `splice_witness` for each `splice_add_input` it
> proposed, in BIP69 input order.
>
> Once a node has sent `splice_commitment_signature` it should remember
> the splice proposal across reconnects. Once it has both sent
> `splice_signature`, the splice is locked in.
>
>
> Splice Announcement
> -------------------
>
> We have to tell the network about the new channel, otherwise there will
> be a distruption when it sees the old funding transaction spent. This
> is inevitable for older nodes who won't understand splicing anyway.
>
> We can't send out a `channel_announcement` or `channel_update` for the
> new channel until after the new funding transaction has 6 confirmations,
> so we append to the existing `channel_update` for the original channel,
> using a new `message_flags` field:
>
> | Bit Position | Name | Field
> |
> | ------------- | ------------------------- |
> -------------------------------- |
> | 0 | `option_channel_htlc_max` | `htlc_maximum_msat`
> |
> | 1 | `option_channel_moving` | `moving_txid
> |
>
> The `channel_update` gains the following field:
> * [`32`: moving_txid`] (option_channel_moving)
>
> If a current `channel_update` for a closing channel contains
> `option_channel_moving` a node SHOULD ignore the channel close for at
> least 100 blocks iff spent by `moving_txid`.
>
> A node SHOULD immediately forward a `channel_update` it sees containing
> `option_channel_moving` if neither previous `channel_update` for the
> channel contains `option_channel_moving`.
>
> Each side of the splice can send these unilaterally, and SHOULD allow a
> few minutes for propagation (remember, average propagation from old
> nodes is still 30 seconds) prior to broadcast of the splice transaction.
>
>
> Message Changes During Splicing
> -------------------------------
> Once you've sent `splice_commitment_signature` each commitment
> transaction is duplicated: one spends the old funding transaction, one
> spends the splice transaction:
>
> 1. type: 39 (`closing_signed`)
> 2. data:
> * [`32`:`channel_id`]
> * [`8`:`fee_satoshis`]
> * [`64`:`signature`]
> * [`64`:`splice_signature`] (`option_splice`)
>
> 1. type: 132 (`commitment_signed`)
> 2. data:
> * [`32`:`channel_id`]
> * [`64`:`signature`]
> * [`2`:`num_htlcs`]
> * [`num_htlcs*64`:`htlc_signature`]
> * [`num_htlcs*64`:`htlc_splice_signature`] (`option_splice`)
>
> If a reconnection occurs between between sending and receiving
> `splice_commitment_signature`) the peer's status is uncertain (similarly
> for closing). This we have a new field in `channel_reestablish` to flag
> that we consider ourselves to be splicing:
>
> 1. type: 136 (`channel_reestablish`)
> 2. data:
> * [`32`:`channel_id`]
> * [`8`:`next_local_commitment_number`]
> * [`8`:`next_remote_revocation_number`]
> * [`32`:`your_last_per_commitment_secret`] (`option_data_loss_protect`)
> * [`33`:`my_current_per_commitment_point`] (`option_data_loss_protect`)
> * [`32`:`splice_txid`] (`option_splice`)
>
> The splice_txid field indicates that this side considers itself to be
> splicing.
>
> The sender:
> - if it has sent `splice_commitment_signature` and not sent the
> corresponding
> `splice_closed`, MUST set `splice_txid` to the txid of the splice tx.
> - Otherwise MUST NOT.
>
> The recipient:
> - if it has sent `splice_commitment_signature` and not sent the
> corresponding
> `splice_closed`:
> - if `splice_txid` does not exist or does not match the current splice:
> - SHOULD fail the channel
> - otherwise:
> - MUST retransmit `splice_signature`
> - otherwise:
> - if `splice_txid` field exists and is not all zeroes:
> - MUST send `splice_closed`
>
>
> Validation Changes During Splicing
> ----------------------------------
> We track "post-splice" values as well as current values during
> splicing.
>
> The post-splice reserve is 1% of post-splice capcacity (rounded down).
>
> The fees for the splicing transaction itself are divided into parts by
> the number of `splice_add_input` plus `splice_add_output`, rounded up.
> Each side pays as many parts as it proposed `splice_add_input` plus
> `splice_add_output`.
>
> (So if Alice proposes two and Bob proposes one, and the total fee is 1000
> satoshi, each part is 334 satoshi: Alice pays 668 and Bob pays 334.)
>
> Each side's post-splice funds are debited their `splice_add_output`
> amounts, and credited their `splice_add_input` amounts, a debited the
> splice tx fees. If any debiting occurs, the funds must be above the
> post-splice reserve (ie. you can have below reserve, but you can't spend
> if you're below reserve).
>
> All update_add_htlc must be valid for the *both* the current and
> post-splice balances.
>
> Completing Splicing
> -------------------
> Once you've seen both side's `minimum_depth` confirmations of the splice
> transaction (ie. the maximum of the two `minimum_depth` values), you can
> complete the splice by sending:
>
> 1. type: 46 (`splice_closed`) (`option_splice`)
> 2. data:
> * [`32`:`channel_id`]
>
> Once you've sent and received `splice_closed` you can send
> `announcement_signatures` for the new channel as per normal rules (ie. 6
> confirmations, `announce_channel` bit set).
>
> In addition, you can forget everything about the old channel (including
> old HTLCs and revocation requirements).
> _______________________________________________
> 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/20181015/493ab074/attachment-0001.html>;

📅 Original date posted:2018-05-08 📝 Original message: FWIW, ...

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

In reply to nevent1q…4e3h
_________________________

📅 Original date posted:2018-05-08
📝 Original message:
FWIW, Conner pointed out that the initial ZK Proof for the correctness of
the
Paillier params (even w/ usage of bulletproofs) has multiple rounds of
interaction,
iirc up to 5+ (with additional pipelining) rounds of interaction.

-- Laolu

On Mon, May 7, 2018 at 5:14 PM Olaoluwa Osuntokun <laolu32 at gmail.com> wrote:

> Actually, just thought about this a bit more and I think it's possible to
> deploy this in unison with (or after) any sort of SS based on schnorr
> becomes
> possible in Bitcoin. My observation is that since both techniques are
> based on
> the same underlying technique (revealing a secret value in a signature) and
> they center around leveraging the onion payload to drop off a payment point
> (G*a, or G*a_1*a_2*a_3, etc), then the disclosure within the _links_ can be
> heterogeneous, as the same secret is still revealed in an end-to-end
> matter.
>
> As an illustration, consider: A <-> B <-> C. The A <-> B link could use
> the 2pc
> pailier technique, while the B <-> C link could use the OG SS technique
> based
> on schnorr. If i'm correct, then this would mean that we can deploy both
> techniques, without worrying about fragmenting the network due to the
> existence
> of two similar but incompatible e2e payment routing schemes!
>
> -- Laolu
>
>
> On Mon, May 7, 2018 at 4:57 PM Olaoluwa Osuntokun <laolu32 at gmail.com>
> wrote:
>
>> Hi Pedro,
>>
>> Very cool stuff! When I originally discovered the Lindell's technique, my
>> immediate thought was the we could phase this in as a way to
>> _immediately_ (no
>> additional Script upgrades required), replace the regular 2-of-2
>> mulit-sig with
>> a single p2wkh. The immediate advantages of this would: be lower fees for
>> opening/closing channels (as the public key script, and witness are
>> smaller),
>> openings and cooperative close transactions would blend in with the
>> anonymity
>> set of regular p2wkh transactions, and finally the htlc timeout+success
>> transactions can be made smaller as we can remove the multi-sig. The
>> second
>> benefit is nerfed a bit if the channel are advertised, but non-advertised
>> channels would be able to take advantage of this "stealth" feature.
>>
>> The upside of the original application I hand in mind is that it wouldn't
>> require any end-to-end changes, as it would only be a link level change
>> (diff
>> output for the funding transaction). If we wanted to allow these styles of
>> channels to be used outside of non-advertised channels, then we would
>> need to
>> update the way channels are verified in the gossip layer.
>>
>> Applying this to the realm of allowing us to use randomized payment
>> identifiers
>> across the route is obviously much, much doper. So then the question
>> would be
>> what the process of integrating the scheme into the existing protocol
>> would
>> look like. The primary thing we'd need to account for is the additional
>> cryptographic overhead this scheme would add if integrated. Re-reviewing
>> the
>> paper, there's an initial setup and verification phase (which was omitted
>> from
>> y'alls note for brevity) where both parties need to complete before the
>> actually signing process can take place. Ideally, we can piggy-back this
>> setup
>> on top of the existing accept_channel/open_channel dance both sides need
>> to go
>> through in order to advance the channel negotiation process today.
>>
>> Conner actually started to implement this when we first discovered the
>> scheme,
>> so we have a pretty good feel w.r.t the implementation of the initial set
>> of
>> proofs. The three proofs required for the set up phase are:
>>
>> 1. A proof that that the Paillier public key is well formed. In the
>> paper
>> they only execute this step for the party that wishes to _obtain_ the
>> signature. In our case, since we'll need to sign for HTLCs in both
>> directions, but parties will need to execute this step.
>>
>> 2. A dlog proof for the signing keys themselves. We already do this
>> more or
>> less, as if the remote party isn't able to sign with their target key,
>> then
>> we won't be able to update the channel, or even create a valid
>> commitment in
>> the first place.
>>
>> 3. A proof that value encrypted (the Paillier ciphertext) is actually
>> the
>> dlog of the public key to be used for signing. (as an aside this is the
>> part
>> of the protocol that made me do a double take when first reading it:
>> using one
>> cryptosystem to encrypt the private key of another cryptosystem in
>> order to
>> construct a 2pc to allow signing in the latter cryptosystem! soo
>> clever!)
>>
>> First, we'll examine the initial proof. This only needs to be done once
>> by both
>> parties AFAICT. As a result, we may be able to piggyback this onto the
>> initial
>> channel funding steps. Reviewing the paper cited on the Lindell paper
>> [1], it
>> appears this would take 1 RTT, so this shouldn't result in any additional
>> round
>> trips during the funding process. We should be able to use a Paillier
>> modulos
>> of 2048 bits, so nothing too crazy. This would just result in a slightly
>> bigger
>> opening message.
>>
>> Skipping the second proofs as it's pretty standard.
>>
>> The third proof as described (Section 6 of the Lindell paper) is
>> interactive.
>> It also contains a ZK range proof as a sub-protocol which as described in
>> Appendix A is also interactive. However, it was pointed out to us by Omer
>> Shlomovits on the lnd slack, that we can actually replace their custom
>> range
>> proofs with Bulletproofs. This would make this section non-interactive,
>> allowing the proof itself to take 1.5 RTT AFAICT. Additionally, this
>> would only
>> need to be done once at the start, as AFIACT, we can re-use the
>> encryption of
>> the secp256k1 private key of both parties.
>>
>> The current channel opening process requires 2 RTT, so it seems that we'd
>> be
>> able to easily piggy back all the opening proofs on top of the existing
>> funding
>> protocol. The main cost would be the increased size of these opening
>> messages,
>> and also the additional computational cost of operations within the
>> Paillier
>> modulus and the new range proof.
>>
>> The additional components that would need to be modified are the process
>> of
>> adding+settling an HTLC, and also the onion payload that drops off the
>> point
>> whose dlog is r_1*alpha. Within the current protocol, adding and settling
>> an
>> HTLC are more or less non-interactive, we have a single message for each,
>> which
>> is then staged to be committed in new commitments for both parties. With
>> this
>> new scheme (if I follow it correctly), adding an HTLC now requires N RTT:
>> 1. Alice sends A = G*alpha to Bob. Here alpha is the payment secret.
>> 2. Bob sends R_3 = (G*alpha)*r_2 (along w/ a proof of knowledge of r_2
>> and
>> relation to A)
>> 3. Alice sends R_3' = (G*alpha)*r_3 (along with a similar proof as
>> above) 4.
>> Bob then computes c3 (the encrypted partial sig which when completed
>> will
>> reveal a) to Alice.
>> 5. Alice decrypts c3 to get the plaintext partial sig (s'), then
>> finalizes
>> the set up by sending s'' to Bob.
>>
>> This process takes 2.5 RTT, and would require re-working the state machine
>> slightly to only actually commit an HTLC after step 5 has been
>> completed. When
>> Bob obtains a from the next party in the path, we Alice can then then
>> over the
>> signature, from which Alice can extract alpha. So adding HTLCs is now a
>> bit
>> more interactive, but settling them is the same a before.
>>
>> Finally, the onion payload would need to be re-interpreted in order to
>> encode
>> G*alpha which takes 33 bytes. We can shave this down to 32 by selecting
>> the x
>> coordinate (at the sender) to always be either even or odd. Currently, we
>> have
>> 12 unused bytes in the onion payload. The HMAC is currently 32 bytes. One
>> path
>> would be to allocate a portion of HMAC space to encoding this point. A
>> 16-byte
>> HMAC would probably have been enough in the beginning, so we can drop
>> down to
>> that. However, that still leaves 4 bytes somewhere that has to give...one
>> could
>> either obtain these extra bytes from the CLTV and Amount fields, or just
>> have
>> each hop consume an extra payload. The latter path would mean that the new
>> upper hop limit is actually 10.
>>
>> However, given that we would need need a new global feature bit in order
>> to
>> roll this out, it may make sense to re-work the onion format all together
>> which
>> would mean that we wouldn't need to hack the old format a bit to
>> accommodate
>> this additional data. One aspect of introducing a new end-to-end contract
>> type
>> which I hadn't considered before is that each new type effectively
>> partitions
>> the network. This is due to the fact that these HTLCs will now only be
>> able to
>> be carried along paths that understand this new feature. As a result,
>> plausible
>> path diversity takes as we can no longer utilize all channels on the
>> network
>> for routing. This would suggest that introducing new end to end contract
>> types
>> (if one wishes to use them widely across arbitrary channels and not for
>> specific contract protocols) may be a strong point of synchronization
>> w.r.t
>> updates across the network. As a result, we may need to be a bit more
>> discerning w.r.t new candidates for e2e contracts given the coordination
>> costs.
>>
>> So the takeaways are:
>> * we can probably piggy back the extra proofs onto the channel opening
>> process
>> * one of the subproofs can use bulletproofs to make the proof
>> shorter and
>> also non-interactive
>> * adding an HTLC would take 2.5 RTT's, but settling is just as quick as
>> before
>> * the onion payload would either need to be hacked, or extended to
>> support
>> packaging the point.
>> * the utility of the scheme won't shine until all/most of the network
>> uses it
>> * we could start w/ just the introduction of the OG 2PC scheme as a
>> multi-sig
>> replacement
>>
>>
>> [1]: https://eprint.iacr.org/2011/494.pdf (section 3.3)
>>
>> -- Laolu
>>
>>
>> On Fri, Apr 27, 2018 at 11:42 AM Pedro Moreno Sanchez <
>> pmorenos at purdue.edu> wrote:
>>
>>> Hello guys,
>>>
>>> as some of you already know, I am working on some cryptographic
>>> constructions that might be of interest and useful for the Lightning
>>> Network.
>>>
>>> Recently, I have come up with a scriptless version of the adaptor
>>> signatures and the contract required in the Lighting Network using only
>>> 2-party ECDSA signatures. The main advantage is that, instead of waiting
>>> for Schnorr signatures to be deployed in Bitcoin so that Poelstra's
>>> scriptless scripts can be used, I believe that this ECDSA-version of the
>>> scriptless scripts can be directly applied today.
>>>
>>> Details are in the attached PDF. I am looking forward to hearing your
>>> comments and suggestions.
>>>
>>> Cheers,
>>> Pedro.
>>>
>>> _______________________________________________
>>> 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/20180508/23f2dfc3/attachment.html>;

📅 Original date posted:2018-05-07 📝 Original message: Hi ...

2023-06-09T14:50:38+02:00

In reply to nevent1q…9c0k
_________________________

📅 Original date posted:2018-05-07
📝 Original message:
Hi Pedro,

Very cool stuff! When I originally discovered the Lindell's technique, my
immediate thought was the we could phase this in as a way to _immediately_
(no
additional Script upgrades required), replace the regular 2-of-2 mulit-sig
with
a single p2wkh. The immediate advantages of this would: be lower fees for
opening/closing channels (as the public key script, and witness are
smaller),
openings and cooperative close transactions would blend in with the
anonymity
set of regular p2wkh transactions, and finally the htlc timeout+success
transactions can be made smaller as we can remove the multi-sig. The second
benefit is nerfed a bit if the channel are advertised, but non-advertised
channels would be able to take advantage of this "stealth" feature.

The upside of the original application I hand in mind is that it wouldn't
require any end-to-end changes, as it would only be a link level change
(diff
output for the funding transaction). If we wanted to allow these styles of
channels to be used outside of non-advertised channels, then we would need
to
update the way channels are verified in the gossip layer.

Applying this to the realm of allowing us to use randomized payment
identifiers
across the route is obviously much, much doper. So then the question would
be
what the process of integrating the scheme into the existing protocol would
look like. The primary thing we'd need to account for is the additional
cryptographic overhead this scheme would add if integrated. Re-reviewing the
paper, there's an initial setup and verification phase (which was omitted
from
y'alls note for brevity) where both parties need to complete before the
actually signing process can take place. Ideally, we can piggy-back this
setup
on top of the existing accept_channel/open_channel dance both sides need to
go
through in order to advance the channel negotiation process today.

Conner actually started to implement this when we first discovered the
scheme,
so we have a pretty good feel w.r.t the implementation of the initial set of
proofs. The three proofs required for the set up phase are:

1. A proof that that the Paillier public key is well formed. In the paper
they only execute this step for the party that wishes to _obtain_ the
signature. In our case, since we'll need to sign for HTLCs in both
directions, but parties will need to execute this step.

2. A dlog proof for the signing keys themselves. We already do this more
or
less, as if the remote party isn't able to sign with their target key,
then
we won't be able to update the channel, or even create a valid commitment
in
the first place.

3. A proof that value encrypted (the Paillier ciphertext) is actually the
dlog of the public key to be used for signing. (as an aside this is the
part
of the protocol that made me do a double take when first reading it:
using one
cryptosystem to encrypt the private key of another cryptosystem in order
to
construct a 2pc to allow signing in the latter cryptosystem! soo clever!)

First, we'll examine the initial proof. This only needs to be done once by
both
parties AFAICT. As a result, we may be able to piggyback this onto the
initial
channel funding steps. Reviewing the paper cited on the Lindell paper [1],
it
appears this would take 1 RTT, so this shouldn't result in any additional
round
trips during the funding process. We should be able to use a Paillier
modulos
of 2048 bits, so nothing too crazy. This would just result in a slightly
bigger
opening message.

Skipping the second proofs as it's pretty standard.

The third proof as described (Section 6 of the Lindell paper) is
interactive.
It also contains a ZK range proof as a sub-protocol which as described in
Appendix A is also interactive. However, it was pointed out to us by Omer
Shlomovits on the lnd slack, that we can actually replace their custom range
proofs with Bulletproofs. This would make this section non-interactive,
allowing the proof itself to take 1.5 RTT AFAICT. Additionally, this would
only
need to be done once at the start, as AFIACT, we can re-use the encryption
of
the secp256k1 private key of both parties.

The current channel opening process requires 2 RTT, so it seems that we'd be
able to easily piggy back all the opening proofs on top of the existing
funding
protocol. The main cost would be the increased size of these opening
messages,
and also the additional computational cost of operations within the Paillier
modulus and the new range proof.

The additional components that would need to be modified are the process of
adding+settling an HTLC, and also the onion payload that drops off the point
whose dlog is r_1*alpha. Within the current protocol, adding and settling an
HTLC are more or less non-interactive, we have a single message for each,
which
is then staged to be committed in new commitments for both parties. With
this
new scheme (if I follow it correctly), adding an HTLC now requires N RTT:
1. Alice sends A = G*alpha to Bob. Here alpha is the payment secret.
2. Bob sends R_3 = (G*alpha)*r_2 (along w/ a proof of knowledge of r_2 and
relation to A)
3. Alice sends R_3' = (G*alpha)*r_3 (along with a similar proof as above)
4.
Bob then computes c3 (the encrypted partial sig which when completed will
reveal a) to Alice.
5. Alice decrypts c3 to get the plaintext partial sig (s'), then finalizes
the set up by sending s'' to Bob.

This process takes 2.5 RTT, and would require re-working the state machine
slightly to only actually commit an HTLC after step 5 has been completed.
When
Bob obtains a from the next party in the path, we Alice can then then over
the
signature, from which Alice can extract alpha. So adding HTLCs is now a bit
more interactive, but settling them is the same a before.

Finally, the onion payload would need to be re-interpreted in order to
encode
G*alpha which takes 33 bytes. We can shave this down to 32 by selecting the
x
coordinate (at the sender) to always be either even or odd. Currently, we
have
12 unused bytes in the onion payload. The HMAC is currently 32 bytes. One
path
would be to allocate a portion of HMAC space to encoding this point. A
16-byte
HMAC would probably have been enough in the beginning, so we can drop down
to
that. However, that still leaves 4 bytes somewhere that has to give...one
could
either obtain these extra bytes from the CLTV and Amount fields, or just
have
each hop consume an extra payload. The latter path would mean that the new
upper hop limit is actually 10.

However, given that we would need need a new global feature bit in order to
roll this out, it may make sense to re-work the onion format all together
which
would mean that we wouldn't need to hack the old format a bit to accommodate
this additional data. One aspect of introducing a new end-to-end contract
type
which I hadn't considered before is that each new type effectively
partitions
the network. This is due to the fact that these HTLCs will now only be able
to
be carried along paths that understand this new feature. As a result,
plausible
path diversity takes as we can no longer utilize all channels on the network
for routing. This would suggest that introducing new end to end contract
types
(if one wishes to use them widely across arbitrary channels and not for
specific contract protocols) may be a strong point of synchronization w.r.t
updates across the network. As a result, we may need to be a bit more
discerning w.r.t new candidates for e2e contracts given the coordination
costs.

So the takeaways are:
* we can probably piggy back the extra proofs onto the channel opening
process
* one of the subproofs can use bulletproofs to make the proof shorter
and
also non-interactive
* adding an HTLC would take 2.5 RTT's, but settling is just as quick as
before
* the onion payload would either need to be hacked, or extended to support
packaging the point.
* the utility of the scheme won't shine until all/most of the network
uses it
* we could start w/ just the introduction of the OG 2PC scheme as a
multi-sig
replacement

[1]: https://eprint.iacr.org/2011/494.pdf (section 3.3)

-- Laolu

On Fri, Apr 27, 2018 at 11:42 AM Pedro Moreno Sanchez <pmorenos at purdue.edu>
wrote:

> Hello guys,
>
> as some of you already know, I am working on some cryptographic
> constructions that might be of interest and useful for the Lightning
> Network.
>
> Recently, I have come up with a scriptless version of the adaptor
> signatures and the contract required in the Lighting Network using only
> 2-party ECDSA signatures. The main advantage is that, instead of waiting
> for Schnorr signatures to be deployed in Bitcoin so that Poelstra's
> scriptless scripts can be used, I believe that this ECDSA-version of the
> scriptless scripts can be directly applied today.
>
> Details are in the attached PDF. I am looking forward to hearing your
> comments and suggestions.
>
> Cheers,
> Pedro.
>
> _______________________________________________
> 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/20180507/32b51086/attachment-0001.html>;

📅 Original date posted:2018-05-07 📝 Original message: ...

2023-06-09T14:50:38+02:00

In reply to nevent1q…2qh2
_________________________

📅 Original date posted:2018-05-07
📝 Original message:
Actually, just thought about this a bit more and I think it's possible to
deploy this in unison with (or after) any sort of SS based on schnorr
becomes
possible in Bitcoin. My observation is that since both techniques are based
on
the same underlying technique (revealing a secret value in a signature) and
they center around leveraging the onion payload to drop off a payment point
(G*a, or G*a_1*a_2*a_3, etc), then the disclosure within the _links_ can be
heterogeneous, as the same secret is still revealed in an end-to-end matter.

As an illustration, consider: A <-> B <-> C. The A <-> B link could use the
2pc
pailier technique, while the B <-> C link could use the OG SS technique
based
on schnorr. If i'm correct, then this would mean that we can deploy both
techniques, without worrying about fragmenting the network due to the
existence
of two similar but incompatible e2e payment routing schemes!

-- Laolu

On Mon, May 7, 2018 at 4:57 PM Olaoluwa Osuntokun <laolu32 at gmail.com> wrote:

> Hi Pedro,
>
> Very cool stuff! When I originally discovered the Lindell's technique, my
> immediate thought was the we could phase this in as a way to _immediately_
> (no
> additional Script upgrades required), replace the regular 2-of-2 mulit-sig
> with
> a single p2wkh. The immediate advantages of this would: be lower fees for
> opening/closing channels (as the public key script, and witness are
> smaller),
> openings and cooperative close transactions would blend in with the
> anonymity
> set of regular p2wkh transactions, and finally the htlc timeout+success
> transactions can be made smaller as we can remove the multi-sig. The second
> benefit is nerfed a bit if the channel are advertised, but non-advertised
> channels would be able to take advantage of this "stealth" feature.
>
> The upside of the original application I hand in mind is that it wouldn't
> require any end-to-end changes, as it would only be a link level change
> (diff
> output for the funding transaction). If we wanted to allow these styles of
> channels to be used outside of non-advertised channels, then we would need
> to
> update the way channels are verified in the gossip layer.
>
> Applying this to the realm of allowing us to use randomized payment
> identifiers
> across the route is obviously much, much doper. So then the question would
> be
> what the process of integrating the scheme into the existing protocol would
> look like. The primary thing we'd need to account for is the additional
> cryptographic overhead this scheme would add if integrated. Re-reviewing
> the
> paper, there's an initial setup and verification phase (which was omitted
> from
> y'alls note for brevity) where both parties need to complete before the
> actually signing process can take place. Ideally, we can piggy-back this
> setup
> on top of the existing accept_channel/open_channel dance both sides need
> to go
> through in order to advance the channel negotiation process today.
>
> Conner actually started to implement this when we first discovered the
> scheme,
> so we have a pretty good feel w.r.t the implementation of the initial set
> of
> proofs. The three proofs required for the set up phase are:
>
> 1. A proof that that the Paillier public key is well formed. In the paper
> they only execute this step for the party that wishes to _obtain_ the
> signature. In our case, since we'll need to sign for HTLCs in both
> directions, but parties will need to execute this step.
>
> 2. A dlog proof for the signing keys themselves. We already do this more
> or
> less, as if the remote party isn't able to sign with their target key,
> then
> we won't be able to update the channel, or even create a valid
> commitment in
> the first place.
>
> 3. A proof that value encrypted (the Paillier ciphertext) is actually the
> dlog of the public key to be used for signing. (as an aside this is the
> part
> of the protocol that made me do a double take when first reading it:
> using one
> cryptosystem to encrypt the private key of another cryptosystem in order
> to
> construct a 2pc to allow signing in the latter cryptosystem! soo clever!)
>
> First, we'll examine the initial proof. This only needs to be done once by
> both
> parties AFAICT. As a result, we may be able to piggyback this onto the
> initial
> channel funding steps. Reviewing the paper cited on the Lindell paper [1],
> it
> appears this would take 1 RTT, so this shouldn't result in any additional
> round
> trips during the funding process. We should be able to use a Paillier
> modulos
> of 2048 bits, so nothing too crazy. This would just result in a slightly
> bigger
> opening message.
>
> Skipping the second proofs as it's pretty standard.
>
> The third proof as described (Section 6 of the Lindell paper) is
> interactive.
> It also contains a ZK range proof as a sub-protocol which as described in
> Appendix A is also interactive. However, it was pointed out to us by Omer
> Shlomovits on the lnd slack, that we can actually replace their custom
> range
> proofs with Bulletproofs. This would make this section non-interactive,
> allowing the proof itself to take 1.5 RTT AFAICT. Additionally, this would
> only
> need to be done once at the start, as AFIACT, we can re-use the encryption
> of
> the secp256k1 private key of both parties.
>
> The current channel opening process requires 2 RTT, so it seems that we'd
> be
> able to easily piggy back all the opening proofs on top of the existing
> funding
> protocol. The main cost would be the increased size of these opening
> messages,
> and also the additional computational cost of operations within the
> Paillier
> modulus and the new range proof.
>
> The additional components that would need to be modified are the process of
> adding+settling an HTLC, and also the onion payload that drops off the
> point
> whose dlog is r_1*alpha. Within the current protocol, adding and settling
> an
> HTLC are more or less non-interactive, we have a single message for each,
> which
> is then staged to be committed in new commitments for both parties. With
> this
> new scheme (if I follow it correctly), adding an HTLC now requires N RTT:
> 1. Alice sends A = G*alpha to Bob. Here alpha is the payment secret.
> 2. Bob sends R_3 = (G*alpha)*r_2 (along w/ a proof of knowledge of r_2
> and
> relation to A)
> 3. Alice sends R_3' = (G*alpha)*r_3 (along with a similar proof as
> above) 4.
> Bob then computes c3 (the encrypted partial sig which when completed will
> reveal a) to Alice.
> 5. Alice decrypts c3 to get the plaintext partial sig (s'), then
> finalizes
> the set up by sending s'' to Bob.
>
> This process takes 2.5 RTT, and would require re-working the state machine
> slightly to only actually commit an HTLC after step 5 has been completed.
> When
> Bob obtains a from the next party in the path, we Alice can then then over
> the
> signature, from which Alice can extract alpha. So adding HTLCs is now a bit
> more interactive, but settling them is the same a before.
>
> Finally, the onion payload would need to be re-interpreted in order to
> encode
> G*alpha which takes 33 bytes. We can shave this down to 32 by selecting
> the x
> coordinate (at the sender) to always be either even or odd. Currently, we
> have
> 12 unused bytes in the onion payload. The HMAC is currently 32 bytes. One
> path
> would be to allocate a portion of HMAC space to encoding this point. A
> 16-byte
> HMAC would probably have been enough in the beginning, so we can drop down
> to
> that. However, that still leaves 4 bytes somewhere that has to give...one
> could
> either obtain these extra bytes from the CLTV and Amount fields, or just
> have
> each hop consume an extra payload. The latter path would mean that the new
> upper hop limit is actually 10.
>
> However, given that we would need need a new global feature bit in order to
> roll this out, it may make sense to re-work the onion format all together
> which
> would mean that we wouldn't need to hack the old format a bit to
> accommodate
> this additional data. One aspect of introducing a new end-to-end contract
> type
> which I hadn't considered before is that each new type effectively
> partitions
> the network. This is due to the fact that these HTLCs will now only be
> able to
> be carried along paths that understand this new feature. As a result,
> plausible
> path diversity takes as we can no longer utilize all channels on the
> network
> for routing. This would suggest that introducing new end to end contract
> types
> (if one wishes to use them widely across arbitrary channels and not for
> specific contract protocols) may be a strong point of synchronization w.r.t
> updates across the network. As a result, we may need to be a bit more
> discerning w.r.t new candidates for e2e contracts given the coordination
> costs.
>
> So the takeaways are:
> * we can probably piggy back the extra proofs onto the channel opening
> process
> * one of the subproofs can use bulletproofs to make the proof
> shorter and
> also non-interactive
> * adding an HTLC would take 2.5 RTT's, but settling is just as quick as
> before
> * the onion payload would either need to be hacked, or extended to
> support
> packaging the point.
> * the utility of the scheme won't shine until all/most of the network
> uses it
> * we could start w/ just the introduction of the OG 2PC scheme as a
> multi-sig
> replacement
>
>
> [1]: https://eprint.iacr.org/2011/494.pdf (section 3.3)
>
> -- Laolu
>
>
> On Fri, Apr 27, 2018 at 11:42 AM Pedro Moreno Sanchez <pmorenos at purdue.edu>
> wrote:
>
>> Hello guys,
>>
>> as some of you already know, I am working on some cryptographic
>> constructions that might be of interest and useful for the Lightning
>> Network.
>>
>> Recently, I have come up with a scriptless version of the adaptor
>> signatures and the contract required in the Lighting Network using only
>> 2-party ECDSA signatures. The main advantage is that, instead of waiting
>> for Schnorr signatures to be deployed in Bitcoin so that Poelstra's
>> scriptless scripts can be used, I believe that this ECDSA-version of the
>> scriptless scripts can be directly applied today.
>>
>> Details are in the attached PDF. I am looking forward to hearing your
>> comments and suggestions.
>>
>> Cheers,
>> Pedro.
>>
>> _______________________________________________
>> 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/20180508/04e449be/attachment-0001.html>;

📅 Original date posted:2018-02-06 📝 Original message: Hi ...

2023-06-09T14:48:58+02:00

In reply to nevent1q…vf3a
_________________________

📅 Original date posted:2018-02-06
📝 Original message:
Hi ZmnSCPxj,

> This is excellent work!

Thanks!

> I think, a `globalfeatures` odd bit could be used for this. As it is
> end-ot-end, `localfeatures` is not appropriate.

Yep, it would need to be a global feature bit. In the case that we're
sending to a destination which isn't publicly advertised, then perhaps an
extension to BOLT-11 could be made to signal receiver support.

> I believe, currently, fees have not this super-linear component

Yep they don't. Arguably, we should also have a component that scales
according to the proposed CLTV value of the outgoing HTLC. At Scaling
Bitcoin Stanford, Aviv Zohar gave a talked titled "How to Charge Lightning"
where the authors analyzed the possible evolution of fees on the network
(and also suggested adding this super-linear component to extend the
lifetime of channels). However, the talk itself focused on a very simple
"mega super duper hub" topology. Towards the end he alluded to a forthcoming
paper that had more comprehensive analysis of more complex topologies. I
look forward to the publication of their finalized work.

> Indeed, the existence of per-hop fees (`fee_base_msat`) means, splitting
> the payment over multiple flows will be, very likely, more expensive,
> compared to using a single flow.

Well it's still to be seen how the fee structure on mainnet emerges once the
network is still fully bootstrapped. AFAIK, most running on mainnet atm are
using the default fee schedules for their respective implementations. For
example, the default fee_base_msat for lnd is 1000 msat (1 satoshi).

> I believe the `realm` byte is intended for this.

The realm byte is meant to signal "forward this to the dogecoin channel".
ATM, we just default to 0 as "Bitcoin". However, the byte itself only really
need significance between the sender and the intermediate node. So there
isn't necessarily pressure to have a globally synchronized set of realm
bytes.

> Thus, you can route over nodes that are unaware of AMP, and only provide
> an AMP realm byte to the destination node, who, is able to reconstruct
this
> your AMP data as per your algorithm.

Yes, the intermediate nodes don't need to be aware of the end-to-end
protocol. For the final hop, there are actually 53 free bytes (before one
needs to signal the existence of EOBs):

* 1 byte realm
* 8 bytes next addr (all zeroes to signal final dest)
* 32 bytes hmac (also all zeroes for the final dest)
* 12 bytes padding

So any combo of these bytes can be used to signal more advanced protocols to
the final destination.

A correction from the prior email description:

> We can further modify our usage of the per-hop payloads to send
> (H(BP), s_i) to consume most of the EOB sent from sender to receiver.

This should actually be (H(s_0 || s_1 || ...), s_i). So we still allow them
to check this finger print to see if they have all the final shares, but
don't allow them to preemptively pull all the payments.

-- Laolu

On Mon, Feb 5, 2018 at 11:12 PM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:

> Good morning Laolu,
>
> This is excellent work!
>
> Some minor comments...
>
>
> (Atomic Multi-path Payments). It can be experimented with on Lightning
> *today* with the addition of a new feature bit to gate this new
> feature. The beauty of the scheme is that it requires no fundamental
> changes
> to the protocol as is now, as the negotiation is strictly *end-to-end*
> between sender and receiver.
>
>
> I think, a `globalfeatures` odd bit could be used for this. As it is
> end-ot-end, `localfeatures` is not appropriate.
>
> - Potential fee savings for larger payments, contingent on there being a
> super-linear component to routed fees. It's possible that with
> modifications to the fee schedule, it's actually *cheaper* to send
> payments over multiple flows rather than one giant flow.
>
>
> I believe, currently, fees have not this super-linear component. Indeed,
> the existence of per-hop fees (`fee_base_msat`) means, splitting the
> payment over multiple flows will be, very likely, more expensive, compared
> to using a single flow. Tiny roundoffs in computing the proportional fees
> (`fee_proportional_millionths`) may make smaller flows give a slight fee
> advantage, but I think the multiplication of per-hop fees will dominate.
>
>
> - Using smaller payments increases the set of possible paths a partial
> payment could have taken, which reduces the effectiveness of static
> analysis techniques involving channel capacities and the plaintext
> values being forwarded.
>
>
> Strongly agree!
>
>
> In order to include the three tuple within the per-hop payload for the
> final
> destination, we repurpose the _first_ byte of the un-used padding bytes in
> the payload to signal version 0x01 of the AMP protocol (note this is a PoC
> outline, we would need to standardize signalling of these 12 bytes to
> support other protocols).
>
>
> I believe the `realm` byte is intended for this. Intermediate nodes do
> not need to understand realm bytes that are understood by other nodes in
> the route, including the realm bytes understood by the final destination,
> as intermediate nodes cannot, indeed, read the hop data of other nodes.
> Thus, you can route over nodes that are unaware of AMP, and only provide an
> AMP realm byte to the destination node, who, is able to reconstruct this
> your AMP data as per your algorithm.
>
> Indeed, the `realm` byte controls the interpretation of the rest of the
> 65-byte packet. If you define, instead, a separate `realm` that is
> understood by the destination node, you can redefine the entire 64 bytes of
> the final hop data as you wish.
>
> If we support AMP only at final payees, we can completely redefine the 64
> bytes in the final hop data for the new AMP `realm`, and not consume the
> next hop (which would reduce route length by 1).
>
> (If we want to support multiple routes converging to an intermediate node,
> then continue routing to a different final node after routes have merged
> (i.e. A->B->C->D, and A->E->C->D, with the payment being merged by C, who
> forwards the combination to D), then we need to follow the current hop data
> format, but I think supporting AMP at final payees is actually enough...
> AMP at intermediate nodes might not be used often enough by senders for it
> to matter, as taking advantage of that seems more complex than just asking
> your routing algo to provide you multiple routes to a destination, which
> you are probably already doing)
>
> ----
>
> Overall, good work I think.
>
> Regards,
> ZmnSCPxj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180207/3e9cf18e/attachment.html>;

📅 Original date posted:2018-02-06 📝 Original message: Hi ...

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

In reply to nevent1q…pg75
_________________________

📅 Original date posted:2018-02-06
📝 Original message:
Hi Y'all,

A common question I've seen concerning Lightning is: "I have five $2
channels, is it possible for me to *atomically* send $6 to fulfill a
payment?". The answer to this question is "yes", provided that the receiver
waits to pull all HTLC's until the sum matches their invoice. Typically, one
assumes that the receiver will supply a payment hash, and the sender will
re-use the payment hash for all streams. This has the downside of payment
hash re-use across *multiple* payments (which can already easily be
correlated), and also has a failure mode where if the sender fails to
actually satisfy all the payment flows, then the receiver can still just
pull the monies (and possibly not disperse a service, or w/e).

Conner Fromknecht and I have come up with a way to achieve this over
Lightning while (1) not re-using any payment hashes across all payment
flows, and (2) adding a *strong* guarantee that the receiver won't be paid
until *all* partial payment flows are extended. We call this scheme AMP
(Atomic Multi-path Payments). It can be experimented with on Lightning
*today* with the addition of a new feature bit to gate this new
feature. The beauty of the scheme is that it requires no fundamental changes
to the protocol as is now, as the negotiation is strictly *end-to-end*
between sender and receiver.

TL;DR: we repurpose some unused space in the onion per-hop payload of the
onion blob to signal our protocol (and deliver some protocol-specific data),
then use additive secret sharing to ensure that the receiver can't pull the
payment until they have enough shares to reconstruct the original pre-image.

Protocol Goals
==============
1. Atomicity: The logical transaction should either succeed or fail in
entirety. Naturally, this implies that the receiver should not be unable to
settle *any* of the partial payments, until all of them have arrived.

2. Avoid Payment Hash Reuse: The payment preimages validated by the
consensus layer should be distinct for each partial payment. Primarily,
this helps avoid correlation of the partial payments, and ensures that
malicious intermediaries straddling partial payments cannot steal funds.

3. Order Invariance: The protocol should be forgiving to the order in which
partial payments arrive at the destination, adding robustness in the face of
delays or routing failures.

4. Non-interactive Setup: It should be possible for the sender to perform an
AMP without directly coordinating with the receiving node. Predominantly,
this means that the *sender* is able to determine the number of partial
payments to use for a particular AMP, which makes sense since they will be
the one fronting the fees for the cost of this parameter. Plus, we can
always turn a non-interactive protocol into an interactive one for the
purposes of invoicing.

Protocol Benefits
=================

Sending pay payments predominantly over an AMP-like protocol has several
clear benefits:

- Eliminates the constraint that a single path from sender to receiver
with sufficient directional capacity. This reduces the pressure to have
larger channels in order to support larger payment flows. As a result,
the payment graph be very diffused, without sacrificing payment
utility

- Reduces strain from larger payments on individual paths, and allows the
liquidity imbalances to be more diffuse. We expect this to have a
non-negligible impact on channel longevity. This is due to the fact that
with usage of AMP, payment flows are typically *smaller* meaning that
each payment will unbalance a channel to a lesser degree that
with one giant flow.

- Potential fee savings for larger payments, contingent on there being a
super-linear component to routed fees. It's possible that with
modifications to the fee schedule, it's actually *cheaper* to send
payments over multiple flows rather than one giant flow.

- Allows for logical payments larger than the current maximum value of an
individual payment. Atm we have a (temporarily) limit on the max payment
size. With AMP, this can be side stepped as each flow can be up the max
size, with the sum of all flows exceeding the max.

- Given sufficient path diversity, AMPs may improve the privacy of LN
Intermediaries are now unaware to how much of the total payment they are
forwarding, or even if they are forwarding a partial payment at all.

- Using smaller payments increases the set of possible paths a partial
payment could have taken, which reduces the effectiveness of static
analysis techniques involving channel capacities and the plaintext
values being forwarded.

Protocol Overview
==================
This design can be seen as a generalization of the single, non-interactive
payment scheme, that uses decoding of extra onion blobs (EOBs?) to encode
extra data for the receiver. In that design, the extra data includes a
payment preimage that the receiver can use to settle back the payment. EOBs
and some method of parsing them are really the only requirement for this
protocol to work. Thus, only the sender and receiver need to implement this
feature in order for it to function, which can be announced using a feature
bit.

First, let's review the current format of the per-hop payload for each node
described in BOLT-0004.

┌───────────────┬───────────────────┬────────────────┬───────────────────────┬─────────────────┬─────────────────┐
│Realm (1 byte) │Next Addr (8 bytes)│Amount (8 bytes)│Outgoing CLTV (4
bytes)│Unused (12 bytes)│ HMAC (32 bytes) │
└───────────────┴───────────────────┴────────────────┴───────────────────────┴─────────────────┴─────────────────┘
■────────────────────────────────────────────────────────────────────────────────────────────────────────────────■
┌─────────────────┐
│65 Bytes Per Hop │
└─────────────────┘

Currently, *each* node gets a 65-byte payload. We use this payload to give
each node instructions on *how* to forward a payment. We tell each node: the
realm (or chain to forward on), then next node to forward to, the amount to
forward (this is where fees are extracted by forwarding out less than in),
the outgoing CLTV (allows verification that the prior node didn't modify any
values), and finally an HMAC over the entire thing.

Two important points:
1. We have 12 bytes for each hop that are currently unpurposed and can be
used by application protocols to signal new interpretation of bytes and
also deliver additional encrypted+authenticated data to *each* hop.

2. The protocol currently has a hard limit of 20-hops. With this feature
we ensure that the packet stays fixed sized during processing in order to
avoid leaking positional information. Typically most payments won't use
all 20 hops, as a result, we can use the remaining hops to stuff in *even
more* data.

Protocol Description
====================
The solution we propose is Atomic Multi-path Payments (AMPs). At a high
level, this leverages EOBs to deliver additive shares of a base preimage,
from which the payment preimages of partial payments can be derived. The
receiver can only construct this value after having received all of the
partial payments, satisfying the atomicity constraint.

The basic protocol:

Primitives
==========
Let H be a CRH function.
Let || denote concatenation.
Let ^ denote xor.

Sender Requirements
===================
The parameters to the sending procedure are a random identifier ID, the
number of partial payments n, and the total payment value V. Assume the
sender has some way of dividing V such that V = v_1 + … + v_n.

To begin, the sender builds the base preimage BP, from which n partial
preimages will be derived. Next, the sender samples n additive shares s_1,
…, s_n, and takes the sum to compute BP = s_1 ^ … ^ s_n.

With the base preimage created, the sender now moves on to constructing the
n partial payments. For each i in [1,n], the sender deterministically
computes the partial preimage r_i = H(BP || i), by concatenating the
sequence number i to the base preimage and hashing the result. Afterwards,
it applies H to determine the payment hash to use in the i’th partial
payment as h_i = H(r_i). Note that that with this preimage derivation
scheme, once the payments are pulled each pre-image is distinct and
indistinguishable from any other.

With all of the pieces in place, the sender initiates the i’th payment by
constructing a route to the destination with value v_i and payment hash h_i.
The tuple (ID, n, s_i) is included in the EOB to be opened by the receiver.

In order to include the three tuple within the per-hop payload for the final
destination, we repurpose the _first_ byte of the un-used padding bytes in
the payload to signal version 0x01 of the AMP protocol (note this is a PoC
outline, we would need to standardize signalling of these 12 bytes to
support other protocols). Typically this byte isn't set, so the existence of
this means that we're (1) using AMP, and (2) the receiver should consume the
_next_ hop as well. So if the payment length is actually 5, the sender tacks
on an additional dummy 6th hop, encrypted with the _same_ shared secret for
that hop to deliver the e2e encrypted data.

Note, the sender can retry partial payments just as they would normal
payments, since they are order invariant, and would be indistinguishable
from regular payments to intermediaries in the network.

Receiver Requirements
=====================

Upon the arrival of each partial payment, the receiver will iteratively
reconstruct BP, and do some bookkeeping to figure out when to settle the
partial payments. During this reconstruction process, the receiver does not
need to be aware of the order in which the payments were sent, and in fact
nothing about the incoming partial payments reveals this information to the
receiver, though this can be learned after reconstructing BP.

Each EOB is decoded to retrieve (ID, n, s_i), where i is the unique but
unknown index of the incoming partial payment. The receiver has access to
persistent key-value store DB that maps ID to (n, c*, BP*), where c*
represents the number of partial payments received, BP* is the sum of the
received additive shares, and the superscript * denotes that the value is
being updated iteratively. c* and BP* both have initial values of 0.

In the basic protocol, the receiver cache’s the first n it sees, and
verifies that all incoming partial payments have the same n. The receiver
should reject all partial payments if any EOB deviates. Next, the we update
our persistent store with DB[ID] = (n, c* + 1, BP* ^ s_i), advancing the
reconstruction by one step.

If c* + 1 < n, there are still more packets in flight, so we sit tight.
Otherwise, the receiver assumes all partial payments have arrived, and can
being settling them back. Using the base preimage BP = BP* ^ s_i from our
final iteration, the receiver can re-derive all n partial preimages and
payment hashes, using r_i = H(BP || i) and h_i = H(r_i) simply through
knowledge of n and BP.

Finally, the receiver settles back any outstanding payments that include
payment hash h_i using the partial preimage r_i. Each r_i will appear random
due to the nature of H, as will it’s corresponding h_i. Thus, each partial
payment should appear uncorrelated, and does not reveal that it is part of
an AMP nor the number of partial payments used.

Non-interactive to Interactive AMPs
===================================

Sender simply receives an ID and amount from the receiver in an invoice
before initiating the protocol. The receiver should only consider the
invoice settled if the total amount received in partial payments containing
ID matches or exceeds the amount specified in the invoice. With this
variant, the receiver is able to map all partial payments to a pre-generated
invoice statement.

Additive Shares vs Threshold-Shares
===================================

The biggest reason to use additive shares seems to be atomicity. Threshold
shares open the door to some partial payments being settled, even if others
are left in flight. Haven’t yet come up with a good reason for using
threshold schemes, but there seem to be plenty against it.

Reconstruction of additive shares can be done iteratively, and is win for
the storage and computation requirements on the receiving end. If the sender
decides to use fewer than n partial payments, the remaining shares could be
included in the EOB of the final partial payment to allow the sender to
reconstruct sooner. Sender could also optimistically do partial
reconstruction on this last aggregate value.

Adaptive AMPs
=============

The sender may not always be aware of how many partial payments they wish to
send at the time of the first partial payment, at which point the simplified
protocol would require n to be chosen. To accommodate, the above scheme can
be adapted to handle a dynamically chosen n by iteratively constructing the
shared secrets as follows.

Starting with a base preimage BP, the key trick is that the sender remember
the difference between the base preimage and the sum of all partial
preimages used so far. The relation is described using the following
equations:

X_0 = 0
X_i = X_{i-1} ^ s_i
X_n = BP ^ X_{n-1}

where if n=1, X_1 = BP, implying that this is in fact a generalization of
the single, non-interactive payment scheme mentioned above. For i=1, ...,
n-1, the sender sends s_i in the EOB, and X_n for the n-th share.

Iteratively reconstructing s_1 ^ …. ^ s_{n-1} ^ X_n = BP, allows the
receiver to compute all relevant r_i = H(BP || i) and h_i = H(r_i). Lastly,
the final number of partial payments n could be signaled in the final EOB,
which would also serve as a sentinel value for signaling completion. In
response to DOS vectors stemming from unknown values of n, implementations
could consider advertising a maximum value for n, or adopting some sort of
framing pattern for conveying that more partial payments are on the way.

We can further modify our usage of the per-hop payloads to send (H(BP),
s_i) to
consume most of the EOB sent from sender to receiver. In this scenario, we'd
repurpose the 11-bytes *after* our signalling byte in the unused byte
section
to store the payment ID (which should be unique for each payment). In the
case
of a non-interactive payment, this will be unused. While for interactive
payments, this will be the ID within the invoice. To deliver this slimmer
2-tuple, we'll use 32-bytes for the hash of the BP, and 32-bytes for the
partial pre-image share, leaving an un-used byte in the payload.

Cross-Chain AMPs
================

AMPs can be used to pay a receiver in multiple currencies atomically...which
is pretty cool :D

Open Research Questions
=======================

The above is a protocol sketch to achieve atomic multi-path payments over
Lightning. The details concerning onion blob usage serves as a template that
future protocols can draw upon in order to deliver additional data to *any*
hop in the route. However, there are still a few open questions before
something like this can be feasibly deployed.

1. How does the sender decide how many chunked payments to send, and the
size of each payment?

- Upon a closer examination, this seems to overlap with the task of
congestion control within TCP. The sender may be able to utilize
inspired heuristics to gauge: (1) how large the initial payment should
be
and (2) how many subsequent payments may be required. Note that if the
first payment succeeds, then the exchange is over in a signal round.

2. How can AMP and HORNET be composed?

- If we eventually integrate HORNET, then a distinct communications
sessions can be established to allow the sender+receiver to exchange
up-to-date partial payment information. This may allow the sender to
more
accurately size each partial payment.

3. Can the sender's initial strategy be governed by an instance of the
Push-relabel max flow algo?

4. How does this mesh with the current max HTLC limit on a commitment?

- ATM, we have a max limit on the number of active HTLC's on a particular
commitment transaction. We do this, as otherwise it's possible that the
transaction is too large, and exceeds standardness w.r.t transaction
size. In a world where most payments use an AMP-like protocol, then
overall ant any given instance there will be several pending HTLC's on
commitments network wise.

This may incentivize nodes to open more channels in order to support
the increased commitment space utilization.

Conclusion
==========

We've presented a design outline of how to integrate atomic multi-path
payments (AMP) into Lightning. The existence of such a construct allows a
sender to atomically split a payment flow amongst several individual payment
flows. As a result, larger channels aren't as important as it's possible to
utilize one total outbound payment bandwidth to send several channels.
Additionally, in order to support the increased load, internal routing nodes
are incensed have more active channels. The existence of AMP-like payments
may also increase the longevity of channels as there'll be smaller, more
numerous payment flows, making it unlikely that a single payment comes
across unbalances a channel entirely. We've also showed how one can utilize
the current onion packet format to deliver additional data from a sender to
receiver, that's still e2e authenticated.

-- Conner && Laolu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180206/8c4a40c4/attachment-0001.html>;

📅 Original date posted:2018-02-06 📝 Original message: Hi ...

2023-06-09T14:48:50+02:00

In reply to nevent1q…25g5
_________________________

📅 Original date posted:2018-02-06
📝 Original message:
Hi Y'all,

Definitely agree that we need a stop-gap solution to fix the naive table
dump on initial connect. I've been sketching out some fancier stuff, but we
would need time to properly tune the fanciness, and I'm inclined to get out
a stop-gap solution asap. On testnet, the zombie churn is pretty bad atm.
It results in uneasily wasted bandwidth as the churn is now almost constant.
There still exist some very old testnet nodes our there it seems. Beyond the
zombie churn, with the size of the testnet graph, we're forced to send tens
of thousands of messages (even if we're already fully synced) upon initial
connect, so very wasteful over all.

So I think the primary distinction between y'alls proposals is that
cdecker's proposal focuses on eventually synchronizing all the set of
_updates_, while Fabrice's proposal cares *only* about the newly created
channels. It only cares about new channels as the rationale is that if once
tries to route over a channel with a state channel update for it, then
you'll get an error with the latest update encapsulated.

Christian wrote:
> I propose adding a new feature bit (6, i.e., bitmask 0x40) indicating that
> the `init` message is extended with a u32 `gossip_timestamp`, interpreted
as
> a UNIX timestamp.

As the `init` message solely contains two variably sized byte slices, I
don't think we can actually safely extend it in this manner. Instead, a new
message is required, where the semantics of the feature bit _require_ the
other side to send it directly after receiving the `init` message from the
other side.

Aside from that, overall I like the simplicity of the protocol: it
eliminates both the zombie churn, and the intensive initial connection graph
dump without any extra messaging overhead (for reconciliation, etc).

Fabrice wrote:
> Just to be clear, you propose to use the timestamp of the most recent
> channel updates to filter the associated channel announcements ?

I think he's actually proposing just a general update horizon in which
vertexes+edges with a lower time stamp just shouldn't be set at all. In the
case of an old zombie channel which was resurrected, it would eventually be
re-propagated as the node on either end of the channel should broadcast a
fresh update along with the original chan ann.

> When a node that supports channel announcement filters receives
> a`channel_announcement_filters` message, it uses it to filter channel
> announcements (and, implicitly ,channel updates) before sending them

This seems to assume that both nodes have a strongly synchronized view of
the network. Otherwise, they'll fall back to sending everything that went on
during the entire epoch regularly. It also doesn't address the zombie churn
issue as they may eventually send you very old channels you'll have to deal
with (or discard).

> The use case we have in mind is mobile nodes, or more generally nodes
> which are often offline and need to resync very often.

How far back would this go? Weeks, months, years?

FWIW this approach optimizes for just learning of new channels instead of
learning of the freshest state you haven't yet seen.

-- Laolu

On Mon, Feb 5, 2018 at 7:08 AM Fabrice Drouin <fabrice.drouin at acinq.fr>
wrote:

> Hi,
>
> On 5 February 2018 at 14:02, Christian Decker
> <decker.christian at gmail.com> wrote:
> > Hi everyone
> >
> > The feature bit is even, meaning that it is required from the peer,
> > since we extend the `init` message itself, and a peer that does not
> > support this feature would be unable to parse any future extensions to
> > the `init` message. Alternatively we could create a new
> > `set_gossip_timestamp` message that is only sent if both endpoints
> > support this proposal, but that could result in duplicate messages being
> > delivered between the `init` and the `set_gossip_timestamp` message and
> > it'd require additional messages.
>
> We chose the other aproach and propose to use an optional feature
>
> > The reason I'm using timestamp and not the blockheight in the short
> > channel ID is that we already use the timestamp for pruning. In the
> > blockheight based timestamp we might ignore channels that were created,
> > then not announced or forgotten, and then later came back and are now
> > stable.
>
> Just to be clear, you propose to use the timestamp of the most recent
> channel updates to filter
> the associated channel announcements ?
>
> > I hope this rather simple proposal is sufficient to fix the short-term
> > issues we are facing with the initial sync, while we wait for a real
> > sync protocol. It is definitely not meant to allow perfect
> > synchronization of the topology between peers, but then again I don't
> > believe that is strictly necessary to make the routing successful.
> >
> > Please let me know what you think, and I'd love to discuss Pierre's
> > proposal as well.
> >
> > Cheers,
> > Christian
>
> Our idea is to group channel announcements by "buckets", create a
> filter for each bucket, exchange and use them to filter out channel
> announcements.
>
> We would add a new `use_channel_announcement_filters` optional feature
> bit (7 for example), and a new `channel_announcement_filters` message.
>
> When a node that supports channel announcement filters receives an
> `init` message with the `use_channel_announcement_filters` bit set, it
> sends back its channel filters.
>
> When a node that supports channel announcement filters receives
> a`channel_announcement_filters` message, it uses it to filter channel
> announcements (and, implicitly ,channel updates) before sending them.
>
> The filters we have in mind are simple:
> - Sort announcements by short channel id
> - Compute a marker height, which is `144 * ((now - 7 * 144) / 144)`
> (we round to multiples of 144 to make sync easier)
> - Group channel announcements that were created before this marker by
> groups of 144 blocks
> - Group channel announcements that were created after this marker by
> groups of 1 block
> - For each group, sort and concatenate all channel announcements short
> channel ids and hash the result (we could use sha256, or the first 16
> bytes of the sha256 hash)
>
> The new `channel_announcement_filters` would then be a list of
> (height, hash) pairs ordered by increasing heights.
>
> This implies that implementation can easily sort announcements by
> short channel id, which should not be very difficult.
> An additional step could be to send all short channel ids for all
> groups for which the group hash did not match. Alternatively we could
> use smarter filters
>
> The use case we have in mind is mobile nodes, or more generally nodes
> which are often offline and need to resync very often.
>
> Cheers,
> Fabrice
> _______________________________________________
> 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/20180207/2ea76f0a/attachment-0001.html>;

📅 Original date posted:2022-04-28 📝 Original ...

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

In reply to nevent1q…els5
_________________________

📅 Original date posted:2022-04-28
📝 Original message:Stating the taproot interaction more plainly: the taproot tweak is defined
as a function of the internal key itself h_tapTeak(internalKey || rootHash),
which means that the full tweak can't be known ahead of time. Instead, one
must aggregate the keys to obtain the internal key _then_ apply the tweaks
as normal.

-- Laolu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220427/1e777215/attachment-0001.html>;

📅 Original date posted:2022-04-27 📝 Original message:Hi ...

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

In reply to nevent1q…q6nw
_________________________

📅 Original date posted:2022-04-27
📝 Original message:Hi Jonas,

Great work on this BIP! Props to you and the other co-authors for putting
together such an excellent technical specification. I'm sure I'm not the
only developer stoked to see the much anticipated musig2 BIP published!

I made a PR earlier today to add some JSON test vectors [1], which'll make
it easier for other implementations to integrate the existing vectors and
more easily update implementations to account for any updates to the
vectors.

I've been following the BIP for a few months now, and have been updating my
implementation for `btcsuite/btcd` (mostly) in lock step. Admittedly, I miss
the earlier iterations of the BIP that were a bit simpler, but also commend
y'all's approach re specifying more performant (removal of that O(n^2)
loop), safe (the added aux input to nonce generation), and generalized
(support for both normal and x-only tweaks) algorithms.

We've also been integrating my implementation into lnd [2] as well in order
to get more familiar with my proposed API, as well as hands-on experience
crafting real transactions that use musig2 in the wild. There may, or may
not be a few musig2 spends in the main chain today created using our PR ;).
We hope to cut a release next month (lnd v0.15.0) that includes an
experimental API intended to give developers safe access to musig2 signing
and key aggregation. I've also concurrently started working on a proposal
for a new taproot native (taprooty level 1, so step 1 here [6]) LN channel
type that natively uses musig2 where applicable.

While exercising all the different signing combinations on regtest, we
realized that in order to support signing for a key that uses BIP 86
derivation (so commit to an empty root, and only the serialized internal) or
an external key that commits to a tapscript root, an implementation must
make the _pre tweaked_ combined key available to the caller. Without this
key a valid control block proof (in the script path spend case) can't be
constructed. Similarly, for the BIP 86 case, the pre-tweak combined key
needs to be used to apply the top-level taproot tweak.

As is the BIP doesn't touch on this case, which is something any
implementation will need to account for if they wish to support the two
signing modes I mentioned above. In practice, what we do now is compute the
aggregated key, stash that away, _then_ compute the tweaked key, making both
available to the caller [3]. We also add a special case for BIP 86 [5],
since in that case no real tweak needs to be specified, instead an
implementation should compute the BIP 340 tagged hash (tap tweak) of the
pre-tweaked aggregated key and use that as the main tweak.

In both of these cases, we use a special taproot specific options to make
the operations explicit [4] from the caller's PoV. This _does_ mean that an
implementation needs to know how to compute the BIP 341 taproot tweak fwiw.
So ideally any changes to the BIP in this direction can just link out to BIP
341 in place.

Finally, can you elaborate a bit on this fragment of the BIP that describes
a "short cut" when a specific signers is meant to send their nonces last:

> Second, if there is a unique signer who is supposed to send the pubnonce
> last, it is possible to modify nonce generation for this single signer to
> not require high-quality randomness

My reading here is that if there's a signer that will always send their
nonce last (possibly the responder to an LN funding attempt or a server for
a non-custodial service like Loop), then they don't actually need to
generate real randomness, and can just fully specify all the new optional
arguments? If so then this may end up really simplifying the implementation
of certain protocols since that last party doesn't (?) need to worry about
their nonces as long as all the other (?) parties are using strong
randomness?

-- Laolu

[1]: https://github.com/jonasnick/bips/pull/10
[2]: https://github.com/lightningnetwork/lnd/pull/6361
[3]:
https://github.com/Roasbeef/btcd/blob/afbf14a3a061b961c7fe0d21dcbbc6c941a33027/btcec/schnorr/musig2/keys.go#L320-L331
[4]:
https://github.com/Roasbeef/btcd/blob/afbf14a3a061b961c7fe0d21dcbbc6c941a33027/btcec/schnorr/musig2/keys.go#L211-L248
[5]:
https://github.com/Roasbeef/btcd/blob/afbf14a3a061b961c7fe0d21dcbbc6c941a33027/btcec/schnorr/musig2/keys.go#L406-L414
[6]:
https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-November/003336.html

On Tue, Apr 5, 2022 at 4:04 PM Jonas Nick via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> Tim Ruffing, Elliott Jin, and I are working on a MuSig2 BIP that we would
> like
> to propose to the community for discussion. The BIP is compatible with
> BIP340
> public keys and signatures. It supports tweaking, which allows deriving
> BIP32
> child keys from aggregate keys and creating BIP341 Taproot outputs with
> key and
> script paths. You can find the BIP draft at:
> https://github.com/jonasnick/bips/blob/musig2/bip-musig2.mediawiki
>
> The draft is in a state where it should be possible to write an
> implementation
> based on the BIP that passes the basic test vectors (as, e.g.,
> demonstrated by
> [0]). The draft BIP also contains a reference implementation in python.
> Please
> be aware that this is only a draft and that it may still be necessary to
> make
> small tweaks to the algorithms and test vectors.
>
> [0] https://github.com/btcsuite/btcd/pull/1820
> _______________________________________________
> 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/20220427/d56d7660/attachment.html>;

📅 Original date posted:2022-04-05 📝 Original message:Hi ...

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

In reply to nevent1q…pmd0
_________________________

📅 Original date posted:2022-04-05
📝 Original message:Hi y'all,

I'm excited to publicly publish a new protocol I've been working on over the
past few months: Taro. Taro is a Taproot Asset Representation Overlay which
allows the issuance of normal and also collectible assets on the main
Bitcoin
chain. Taro uses the Taproot script tree to commit extra asset structured
meta
data based on a hybrid merkle tree I call a Merkle Sum Sparse Merkle Tree or
MS-SMT. An MS-SMT combined the properties of a merkle sum tree, with a
sparse
merkle tree, enabling things like easily verifiable asset supply proofs and
also efficient proofs of non existence (eg: you prove to me you're no longer
committing to the 1-of-1 holographic beefzard card during our swap). Taro
asset
transfers are then embedded in a virtual/overlay transaction graph which
uses a
chain of asset witnesses to provably track the transfer of assets across
taproot outputs. Taro also has a scripting system, which allows for
programmatic unlocking/transfer of assets. In the first version, the
scripting
system is actually a recursive instance of the Bitcoin Script Taproot VM,
meaning anything that can be expressed in the latest version of Script can
be
expressed in the Taro scripting system. Future versions of the scripting
system
can introduce new functionality on the Taro layer, like covenants or other
updates.

The Taro design also supports integration with the Lightning Network
(BOLTs) as
the scripting system can be used to emulate the existing HTLC structure,
which
allows for multi-hop transfers of Taro assets. Rather than modify the
internal
network, the protocol proposes to instead only recognize "assets at the
edges",
which means that only the sender+receiver actually need to know about and
validate the assets. This deployment route means that we don't need to
build up
an entirely new network and liquidity for each asset. Instead, all asset
transfers will utilize the Bitcoin backbone of the Lightning Network, which
means that the internal routers just see Bitcoin transfers as normal, and
don't
even know about assets at the edges. As a result, increased demand for
transfers of these assets as the edges (say like a USD stablecoin), which in
will turn generate increased demand of LN capacity, result in more
transfers, and
also more routing revenue for the Bitcoin backbone nodes.

The set of BIPs are a multi-part suite, with the following breakdown:
* The main Taro protocol:
https://github.com/Roasbeef/bips/blob/bip-taro/bip-taro.mediawiki
* The MS-SMT structure:
https://github.com/Roasbeef/bips/blob/bip-taro/bip-taro-ms-smt.mediawiki
* The Taro VM:
https://github.com/Roasbeef/bips/blob/bip-taro/bip-taro-vm.mediawiki
* The Taro address format:
https://github.com/Roasbeef/bips/blob/bip-taro/bip-taro-addr.mediawiki
* The Taro Universe concept:
https://github.com/Roasbeef/bips/blob/bip-taro/bip-taro-universe.mediawiki
* The Taro flat file proof format:
https://github.com/Roasbeef/bips/blob/bip-taro/bip-taro-proof-file.mediawiki

Rather than post them all in line (as the text wouldn't fit in the allowed
size
limit), all the BIPs can be found above.

-- Laolu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220405/930b239c/attachment.html>;

📅 Original date posted:2018-06-12 📝 Original message:> ...

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

In reply to nevent1q…7wq7
_________________________

📅 Original date posted:2018-06-12
📝 Original message:> An example of that cost is you arguing against specifying and supporting
the
> design that is closer to one that would be softforked, which increases the
> time until we can make these filters secure because it
> slows convergence on the design of what would get committed

Agreed, since the commitment is just flat out better, and also also less
code to validate compared to the cross p2p validation, the filter should be
as close to the committed version. This way, wallet and other apps don't
need to modify their logic in X months when the commitment is rolled out.

> Great point, but it should probably exclude coinbase OP_RETURN output.
> This would exclude the current BIP141 style commitment and likely any
> other.

Definitely. I chatted offline with sipa recently, and he suggested this as
well. Upside is that the filters will get even smaller, and also the first
filter type becomes even more of a "barebones" wallet filter. If folks
reaally want to also search OP_RETURN in the filter (as no widely deployed
applications I know of really use it), then an additional filter type can be
added in the future. It would need to be special cased to filter out the
commitment itself.

Alright, color me convinced! I'll further edit my open BIP 158 PR to:

* exclude all OP_RETURN
* switch to prev scripts instead of outpoints
* update the test vectors to include the prev scripts from blocks in
addition to the block itself

-- Laolu

On Sat, Jun 9, 2018 at 8:45 AM Gregory Maxwell <greg at xiph.org> wrote:

> > So what's the cost in using
> > the current filter (as it lets the client verify the filter if they want
> to,
>
> An example of that cost is you arguing against specifying and
> supporting the design that is closer to one that would be softforked,
> which increases the time until we can make these filters secure
> because it slows convergence on the design of what would get
> committed.
>
> >> I don't agree at all, and I can't see why you say so.
> >
> > Sure it doesn't _have_ to, but from my PoV as "adding more commitments"
> is
> > on the top of every developers wish list for additions to Bitcoin, it
> would
> > make sense to coordinate on an "ultimate" extensible commitment once,
> rather
> > than special case a bunch of distinct commitments. I can see arguments
> for
> > either really.
>
> We have an extensible commitment style via BIP141 already. I don't see
> why this in particular demands a new one.
>
> > 1. The current filter format (even moving to prevouts) cannot be
> committed
> > in this fashion as it indexes each of the coinbase output scripts.
> This
> > creates a circular dependency: the commitment is modified by the
> > filter,
>
> Great point, but it should probably exclude coinbase OP_RETURN output.
> This would exclude the current BIP141 style commitment and likely any
> other.
>
> Should I start a new thread on excluding all OP_RETURN outputs from
> BIP-158 filters for all transactions? -- they can't be spent, so
> including them just pollutes the filters.
>
> > 2. Since the coinbase transaction is the first in a block, it has the
> > longest merkle proof path. As a result, it may be several hundred
> bytes
> > (and grows with future capacity increases) to present a proof to the
>
> If 384 bytes is a concern, isn't 3840 bytes (the filter size
> difference is in this ballpark) _much_ more of a concern? Path to the
> coinbase transaction increases only logarithmically so further
> capacity increases are unlikely to matter much, but the filter size
> increases linearly and so it should be much more of a concern.
>
> > In regards to the second item above, what do you think of the old Tier
> Nolan
> > proposal [1] to create a "constant" sized proof for future commitments by
> > constraining the size of the block and placing the commitments within the
> > last few transactions in the block?
>
> I think it's a fairly ugly hack. esp since it requires that mining
> template code be able to stuff the block if they just don't know
> enough actual transactions-- which means having a pool of spendable
> outputs in order to mine, managing private keys, etc... it also
> requires downstream software not tinker with the transaction count
> (which I wish it didn't but as of today it does). A factor of two
> difference in capacity-- if you constrain to get the smallest possible
> proof-- is pretty stark, optimal txn selection with this cardinality
> constraint would be pretty weird. etc.
>
> If the community considers tree depth for proofs like that to be such
> a concern to take on technical debt for that structure, we should
> probably be thinking about more drastic (incompatible) changes... but
> I don't think it's actually that interesting.
>
> > I don't think its fair to compare those that wish to implement this
> proposal
> > (and actually do the validation) to the legacy SPV software that to my
> > knowledge is all but abandoned. The project I work on that seeks to
> deploy
>
> Yes, maybe it isn't. But then that just means we don't have good
> information.
>
> When a lot of people were choosing electrum over SPV wallets when
> those SPV wallets weren't abandoned, sync time was frequently cited as
> an actual reason. BIP158 makes that worse, not better. So while I'm
> hopeful, I'm also somewhat sceptical. Certainly things that reduce
> the size of the 158 filters make them seem more likely to be a success
> to me.
>
> > too difficult to implement "full" validation, as they're bitcoin
> developers
> > with quite a bit of experience.
>
> ::shrugs:: Above you're also arguing against fetching down to the
> coinbase transaction to save a couple hundred bytes a block, which
> makes it impossible to validate a half dozen other things (including
> as mentioned in the other threads depth fidelity of returned proofs).
> There are a lot of reasons why things don't get implemented other than
> experience! :)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180612/d1dbb394/attachment-0001.html>;

📅 Original date posted:2018-06-12 📝 Original message:> ...

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

In reply to nevent1q…pu5a
_________________________

📅 Original date posted:2018-06-12
📝 Original message:> Doesn't the current BIP157 protocol have each filter commit to the filter
> for the previous block?

Yep!

> If that's the case, shouldn't validating the commitment at the tip of the
> chain (or buried back whatever number of blocks that the SPV client
trusts)
> obliviate the need to validate the commitments for any preceeding blocks
in
> the SPV trust model?

Yeah, just that there'll be a gap between the p2p version, and when it's
ultimately committed.

> It seems like you're claiming better security here without providing any
> evidence for it.

What I mean is that one allows you to fully verify the filter, while the
other allows you to only validate a portion of the filter and requires other
added heuristics.

> In the case of prevout+output filters, when a client receives
advertisements
> for different filters from different peers, it:

Alternatively, they can decompress the filter and at least verify that
proper _output scripts_ have been included. Maybe this is "good enough"
until its committed. If a command is added to fetch all the prev outs along
w/ a block (which would let you do another things like verify fees), then
they'd be able to fully validate the filter as well.

-- Laolu

On Sat, Jun 9, 2018 at 3:35 AM David A. Harding <dave at dtrt.org> wrote:

> On Fri, Jun 08, 2018 at 04:35:29PM -0700, Olaoluwa Osuntokun via
> bitcoin-dev wrote:
> > 2. Since the coinbase transaction is the first in a block, it has the
> > longest merkle proof path. As a result, it may be several hundred
> bytes
> > (and grows with future capacity increases) to present a proof to the
> > client.
>
> I'm not sure why commitment proof size is a significant issue. Doesn't
> the current BIP157 protocol have each filter commit to the filter for
> the previous block? If that's the case, shouldn't validating the
> commitment at the tip of the chain (or buried back whatever number of
> blocks that the SPV client trusts) obliviate the need to validate the
> commitments for any preceeding blocks in the SPV trust model?
>
> > Depending on the composition of blocks, this may outweigh the gains
> > had from taking advantage of the additional compression the prev outs
> > allow.
>
> I think those are unrelated points. The gain from using a more
> efficient filter is saved bytes. The gain from using block commitments
> is SPV-level security---that attacks have a definite cost in terms of
> generating proof of work instead of the variable cost of network
> compromise (which is effectively free in many situations).
>
> Comparing the extra bytes used by block commitments to the reduced bytes
> saved by prevout+output filters is like comparing the extra bytes used
> to download all blocks for full validation to the reduced bytes saved by
> only checking headers and merkle inclusion proofs in simplified
> validation. Yes, one uses more bytes than the other, but they're
> completely different security models and so there's no normative way for
> one to "outweigh the gains" from the other.
>
> > So should we optimize for the ability to validate in a particular
> > model (better security), or lower bandwidth in this case?
>
> It seems like you're claiming better security here without providing any
> evidence for it. The security model is "at least one of my peers is
> honest." In the case of outpoint+output filters, when a client receives
> advertisements for different filters from different peers, it:
>
> 1. Downloads the corresponding block
> 2. Locally generates the filter for that block
> 3. Kicks any peers that advertised a different filter than what it
> generated locally
>
> This ensures that as long as the client has at least one honest peer, it
> will see every transaction affecting its wallet. In the case of
> prevout+output filters, when a client receives advertisements for
> different filters from different peers, it:
>
> 1. Downloads the corresponding block and checks it for wallet
> transactions as if there had been a filter match
>
> This also ensures that as long as the client has at least one honest
> peer, it will see every transaction affecting its wallet. This is
> equivilant security.
>
> In the second case, it's possible for the client to eventually
> probabalistically determine which peer(s) are dishonest and kick them.
> The most space efficient of these protocols may disclose some bits of
> evidence for what output scripts the client is looking for, but a
> slightly less space-efficient protocol simply uses randomly-selected
> outputs saved from previous blocks to make the probabalistic
> determination (rather than the client's own outputs) and so I think
> should be quite private. Neither protocol seems significantly more
> complicated than keeping an associative array recording the number of
> false positive matches for each peer's filters.
>
> -Dave
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180612/295d1a52/attachment.html>;

📅 Original date posted:2018-06-08 📝 Original message:> ...

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

In reply to nevent1q…atdr
_________________________

📅 Original date posted:2018-06-08
📝 Original message:> That in argument against adopting the inferior version, as that will
> contribute more momentum to doing it in a way that doesn't make sense long
> term.

That was moreso an attempt at a disclosure, rather than may argument. But
also as noted further up in the thread, both approaches have a trade off:
one is better for light clients in a p2p "one honest peer mode", while the
other is more compact, but is less verifiable for the light clients. They're
"inferior" in different ways.

My argument goes more like: moving to prev scripts means clients cannot
verify in full unless a block message is added to include the prev outs.
This is a downgrade assuming a "one honest peer" model for the p2p
interactions. A commitment removes this drawback, but ofc requires a soft
fork. Soft forks take a "long" time to deploy. So what's the cost in using
the current filter (as it lets the client verify the filter if they want to,
or in an attempted "bamboozlement" scenario) in the short term (as we don't
yet have a proposal for committing the filters) which would allow us to
experiment more with the technique on mainnet before making the step up to
committing the filter. Also, depending on the way the commitment is done,
the filters themselves would need to be modified.

> I don't agree at all, and I can't see why you say so.

Sure it doesn't _have_ to, but from my PoV as "adding more commitments" is
on the top of every developers wish list for additions to Bitcoin, it would
make sense to coordinate on an "ultimate" extensible commitment once, rather
than special case a bunch of distinct commitments. I can see arguments for
either really.

> This is inherent in how e.g. the segwit commitment is encoded, the initial
> bytes are an identifying cookies. Different commitments would have
different
> cookies.

Indeed, if the filter were to be committed, using an output on the coinbase
would be a likely candidate. However, I see two issues with this:

1. The current filter format (even moving to prevouts) cannot be committed
in this fashion as it indexes each of the coinbase output scripts. This
creates a circular dependency: the commitment is modified by the
filter, which is modified by the commitment (the filter atm indexes the
commitment). So we'd need to add a special case to skip outputs with a
particular witness magic. However, we don't know what that witness
magic looks like (as there's no proposal). As a result, the type
filters that can be served over the p2p network may be distinct from
the type of filters that are to be committed, as the commitment may
have an impact on the filter itself.

2. Since the coinbase transaction is the first in a block, it has the
longest merkle proof path. As a result, it may be several hundred bytes
(and grows with future capacity increases) to present a proof to the
client. Depending on the composition of blocks, this may outweigh the
gains had from taking advantage of the additional compression the prev
outs allow.

In regards to the second item above, what do you think of the old Tier Nolan
proposal [1] to create a "constant" sized proof for future commitments by
constraining the size of the block and placing the commitments within the
last few transactions in the block?

> but with an added advantage of permitting expirementation ahead of the
> commitment.

Indeed! To my knowledge, lnd is the only software deployed that even has
code to experiment with the filtering proposal in general. Also, as I
pointed out above, we may require an additional modification in order to be
able to commit the filter. The nature of that modification may depend on how
the filter is to be committed. As a result, why hinder experimentation today
(since it might need to be changed anyway, and as you point out the filter
being committed can even be swapped) by delaying until we know what the
commitment will look like?

> You can still scan blocks directly when peers disagree on the filter
> content, regardless of how the filter is constructed

But the difference is that one options lets you fully construct the filter
from a block, while the other requires additional data.

> but it makes the attack ineffective and using outpoints considerably
increases
> bandwidth for everyone without an attack

So should we optimize for the ability to validate in a particular model
(better
security), or lower bandwidth in this case? It may also be the case that the
overhead of receiving proofs of the commitment outweigh the savings
depending
on block composition (ofc entire block that re-uses the same address is
super
small).

> It seems to me this point is being overplayed, especially considering the
> current state of non-existing validation in SPV software (if SPV software
> doesn't validate anything else they could be validating, why would they
> implement a considerable amount of logic for this?).

I don't think its fair to compare those that wish to implement this proposal
(and actually do the validation) to the legacy SPV software that to my
knowledge is all but abandoned. The project I work on that seeks to deploy
this proposal (already has, but mainnet support is behind a flag as I
anticipated further modifications) indeed has implemented the "considerable"
amount of logic to check for discrepancies and ban peers trying to bamboozle
the light clients. I'm confident that the other projects seeking to
implement
this (rust-bitcoin-spv, NBitcoin, bcoin, maybe missing a few too) won't
find it
too difficult to implement "full" validation, as they're bitcoin developers
with quite a bit of experience.

I think we've all learned from the past defects of past light clients, and
don't seek to repeat history by purposefully implementing as little
validation
as possible. With these new projects by new authors, I think we have an
opprotunity to implement light clients "correctly" this time around.

[1]:
https://github.com/TierNolan/bips/blob/00a8d3e1ac066ce3728658c6c40240e1c2ab859e/bip-aux-header.mediawiki

-- Laolu

On Fri, Jun 8, 2018 at 9:14 AM Gregory Maxwell <greg at xiph.org> wrote:

> On Fri, Jun 8, 2018 at 5:03 AM, Olaoluwa Osuntokun via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > As someone who's written and reviews code integrating the proposal all
> the
> > way up the stack (from node to wallet, to application), IMO, there's no
> > immediate cost to deferring the inclusion/creation of a filter that
> includes
> > prev scripts (b) instead of the outpoint as the "regular" filter does
> now.
> > Switching to prev script in the _short term_ would be costly for the set
> of
> > applications already deployed (or deployed in a minimal or flag flip
> gated
> > fashion) as the move from prev script to outpoint is a cascading one that
> > impacts wallet operation, rescans, HD seed imports, etc.
>
> It seems to me that you're making the argument against your own case
> here: I'm reading this as a "it's hard to switch so it should be done
> the inferior way". That in argument against adopting the inferior
> version, as that will contribute more momentum to doing it in a way
> that doesn't make sense long term.
>
> > Such a proposal would need to be generalized enough to allow several
> components to be committed,
>
> I don't agree at all, and I can't see why you say so.
>
> > likely have versioning,
>
> This is inherent in how e.g. the segwit commitment is encoded, the
> initial bytes are an identifying cookies. Different commitments would
> have different cookies.
>
> > and also provide the necessary extensibility to allow additional items
> to be committed in the future
>
> What was previously proposed is that the commitment be required to be
> consistent if present but not be required to be present. This would
> allow changing whats used by simply abandoning the old one. Sparsity
> in an optional commitment can be addressed when there is less than
> 100% participation by having each block that includes a commitment
> commit to the missing filters ones from their immediate ancestors.
>
> Additional optionality can be provided by the other well known
> mechanisms, e.g. have the soft fork expire at a block 5 years out
> past deployment, and continue to soft-fork it in for a longer term so
> long as its in use (or eventually without expiration if its clear that
> it's not going away).
>
> > wallets which wish to primarily use the filters for rescan purposes can't
> > just construct them locally for this particular use case independent of
> > what's currently deployed on the p2p network.
>
> Absolutely, but given the failure of BIP37 on the network-- and the
> apparent strong preference of end users for alternatives that don't
> scan (e.g. electrum and web wallets)-- supporting making this
> available via P2P was already only interesting to many as a nearly
> free side effect of having filters for local scanning. If it's a
> different filter, it's no longer attractive.
>
> It seems to me that some people have forgotten that this whole idea
> was originally proposed to be a committed data-- but with an added
> advantage of permitting expirementation ahead of the commitment.
>
> > Maintaining the outpoint also allows us to rely on a "single honest
> peer"security model in the short term.
>
> You can still scan blocks directly when peers disagree on the filter
> content, regardless of how the filter is constructed-- yes, it uses
> more bandwidth if you're attacked, but it makes the attack ineffective
> and using outpoints considerably increases bandwidth for everyone
> without an attack. These ineffective (except for increasing
> bandwidth) attacks would have to be common to offset the savings. It
> seems to me this point is being overplayed, especially considering the
> current state of non-existing validation in SPV software (if SPV
> software doesn't validate anything else they could be validating, why
> would they implement a considerable amount of logic for this?).
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180608/347a6539/attachment-0001.html>;

📅 Original date posted:2018-05-31 📝 Original message:Hi ...

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

In reply to nevent1q…d3mv
_________________________

📅 Original date posted:2018-05-31
📝 Original message:Hi y'all,

I've made a PR to the BIP repo to modify BIP 158 based on this thread, and
other recent threads giving feedback on the current version of the BIP:

* https://github.com/bitcoin/bips/pull/687

I've also updated the test vectors based on the current parameters (and
filter format), and also the code used to generate the test vectors. Due to
the change in parametrization, the test vectors now target (P=19 M=784931),
and there're no longer any cases related to extended filters.

One notable thing that I left off is the proposed change to use the previous
output script rather than the outpoint. Modifying the filters in this
fashion would be a downgrade in the security model for light clients, as it
would allow full nodes to lie by omission, just as they can with BIP 37. As
is now, if nodes present conflicting information, then the light client can
download the target block, fully reconstruct the filter itself, then ban any
nodes which advertised the incorrect filter. The inclusion of the filter
header checkpoints make it rather straight forward for light clients to
bisect the state to find the conflicting advertisement, and it's strongly
recommended that they do so.

To get a feel for the level of impact these changes would have on existing
applications that depend on the txid being included in the filter, I've
implemented these changes across btcutil, btcd, btcwallet, and lnd (which
previously relied on the txid for confirmation notifications). For lnd at
least, the code impact was rather minimal, as we use the pkScript for
matching a block, but then still scan the block manually to find the precise
transaction (by txid) that we were interested in (if it's there).

-- Laolu

On Mon, May 28, 2018 at 9:01 PM Olaoluwa Osuntokun <laolu32 at gmail.com>
wrote:

> > The additional benefit of the input script/outpoint filter is to watch
> for
> > unexpected spends (coins getting stolen or spent from another wallet) or
> > transactions without a unique change or output address. I think this is a
> > reasonable implementation, and it would be nice to be able to download
> that
> > filter without any input elements.
>
> As someone who's implemented a complete integration of the filtering
> technique into an existing wallet, and a higher application I disagree.
> There's not much gain to be had in splitting up the filters: it'll result
> in
> additional round trips (to fetch these distinct filter) during normal
> operation, complicate routine seed rescanning logic, and also is
> detrimental
> to privacy if one is fetching blocks from the same peer as they've
> downloaded the filters from.
>
> However, I'm now convinced that the savings had by including the prev
> output
> script (addr re-use and outputs spent in the same block as they're created)
> outweigh the additional booking keeping required in an implementation (when
> extracting the precise tx that matched) compared to using regular outpoint
> as we do currently. Combined with the recently proposed re-parametrization
> of the gcs parameters[1], the filter size should shrink by quite a bit!
>
> I'm very happy with the review the BIPs has been receiving as of late. It
> would've been nice to have this 1+ year ago when the draft was initially
> proposed, but better late that never!
>
> Based on this thread, [1], and discussions on various IRC channels, I plan
> to make the following modifications to the BIP:
>
> 1. use P=2^19 and M=784931 as gcs parameters, and also bind these to the
> filter instance, so future filter types may use distinct parameters
> 2. use the prev output script rather than the prev input script in the
> regular filter
> 3. remove the txid from the regular filter(as with some extra
> book-keeping
> the output script is enough)
> 4. do away with the extended filter all together, as our original use
> case
> for it has been nerfed as the filter size grew too large when doing
> recursive parsing. instead we watch for the outpoint being spent and
> extract the pre-image from it if it matches now
>
> The resulting changes should slash the size of the filters, yet still
> ensure
> that they're useful enough for our target use case.
>
> [1]:
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-May/016029.html
>
> -- Laolu
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180531/5499982f/attachment-0001.html>;

📅 Original date posted:2018-06-01 📝 Original message:> A ...

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

In reply to nevent1q…5pur
_________________________

📅 Original date posted:2018-06-01
📝 Original message:> A typical network attacker (e.g. someone on your lan or wifi segmet, or
> someone who has compromised or operates an upstream router) can be all of
> your peers.

This is true, but it cannot make us accept any invalid filters unless the
attacker is also creating invalid blocks w/ valid PoW.

> The original propsal for using these kinds of maps was that their digests
> could eventually be commited and then checked against the commitment,
> matching the same general security model used otherwise in SPV.

Indeed, but no such proposal for committing the filters has emerged yet.
Slinging filters with new p2p messages requires much less coordination that
adding a new committed structure to Bitcoin. One could imagine that if
consensus exists to add new committed structures, then there may also be
initiatives to start to commit sig-ops, block weight, utxo's etc. As a
result one could imagine a much longer deployment cycle compared to a pure
p2p roll out in the near term, and many applications are looking for a
viable alternative to BIP 37.

> Unfortunately, using the scripts instead of the outpoints takes us further
> away from a design that is optimized for committing (or, for that matter,
> use purely locally by a wallet)...

I agree that using the prev input scripts would indeed be optimal from a
size perspective when the filters are to be committed. The current proposal
makes way for future filter types and it's likely the case that only the
most optimal filters should be committed (while other more niche filters
perhaps, remain only on the p2p level).

-- Laolu

On Thu, May 31, 2018 at 9:14 PM Gregory Maxwell <gmaxwell at gmail.com> wrote:

> On Fri, Jun 1, 2018 at 2:52 AM, Olaoluwa Osuntokun via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > One notable thing that I left off is the proposed change to use the
> previous
> > output script rather than the outpoint. Modifying the filters in this
> > fashion would be a downgrade in the security model for light clients, as
> it
>
> Only if you make a very strong assumption about the integrity of the
> nodes the client is talkign to. A typical network attacker (e.g.
> someone on your lan or wifi segmet, or someone who has compromised or
> operates an upstream router) can be all of your peers.
>
> The original propsal for using these kinds of maps was that their
> digests could eventually be commited and then checked against the
> commitment, matching the same general security model used otherwise in
> SPV.
>
> Unfortunately, using the scripts instead of the outpoints takes us
> further away from a design that is optimized for committing (or, for
> that matter, use purely locally by a wallet)...
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180601/12faacf0/attachment.html>;

📅 Original date posted:2018-05-18 📝 Original message:Matt ...

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

In reply to nevent1q…jsnc
_________________________

📅 Original date posted:2018-05-18
📝 Original message:Matt wrote:
> I believe (1) could be skipped entirely - there is almost no reason why
> you'd not be able to filter for, eg, the set of output scripts in a
> transaction you know about

Depending on the use-case, the txid is more precise than searching for the
output script as it doesn't need to deal with duplicated output scripts. To
my knowledge, lnd is the only major project that currently utilizes BIP
157+158. At this point, we use the txid in the regular filter for
confirmations (channel confirmed, sweep tx confirmed, cltv confirmed, etc).
Switching to use output scripts instead wouldn't be _too_ invasive w.r.t
changes required in the codebase, only the need to deal with output script
duplication could be annoying.

> (2) and (3) may want to be split out - many wallets may wish to just find
> transactions paying to them, as transactions spending from their outputs
> should generally be things they've created.

FWIW, in the "rescan after importing by seed phrase" both are needed in
order to ensure the wallet ends up with the proper output set after the
scan. In lnd we actively use both (2) to detect deposits to the internal
wallet, and (3) to be notified when our channel outputs are spent on-chain
(and also generally when any of our special scripts are spent).

> In general, I'm concerned about the size of the filters making existing
SPV
> clients less willing to adopt BIP 158 instead of the existing bloom filter
> garbage and would like to see a further exploration of ways to split out
> filters to make them less bandwidth intensive.

Agreed that the current filter size may prevent adoption amongst wallets.
However, the other factor that will likely prevent adoption amongst current
BIP-37 mobile wallets is the lack of support for notifying _unconfirmed_
transactions. When we drafted up the protocol last year and asked around,
this was one of the major points of contention amongst existing mobile
wallets that utilize BIP 37.

On the other hand, the two "popular" BIP 37 wallets I'm aware of
(Breadwallet, and Andreas Schildbach's Bitcoin Wallet) have lagged massively
behind the existing set of wallet related protocol upgrades. For example,
neither of them have released versions of their applications that take
advantage of segwit in any manner. Breadwallet has more or less "pivoted"
(they did an ICO and have a token) and instead is prioritizing things like
adding random ICO tokens over catching up with the latest protocol updates.
Based on this behavior, even if the filter sizes were even _more_ bandwidth
efficient that BIP 37, I don't think they'd adopt the protocol.

> Some further ideas we should probably play with before finalizing moving
> forward is providing filters for certain script templates, eg being able
to
> only get outputs that are segwit version X or other similar ideas.

Why should this block active deployment of BIP 157+158 as is now? As
defined, the protocol already allows future updates to add additional filter
types. Before the filters are committed, each filter type requires a new
filter header. We could move to a single filter header that commits to the
hashes of _all_ filters, but that would mean that a node couldn't serve the
headers unless they had all currently defined features, defeating the
optionality offered.

Additionally, more filters entails more disk utilization for nodes serving
these filters. Nodes have the option to instead create the filters at "query
time", but then this counters the benefit of simply slinging the filters
from disk (or a memory map or w/e). IMO, it's a desirable feature that
serving light clients no longer requires active CPU+I/O and instead just
passive I/O (nodes could even write the filters to disk in protocol msg
format).

To get a feel for the current filter sizes, a txid-only filter size, and a
regular filter w/o txid's, I ran some stats on the last 10k blocks:

regular size: 217107653 bytes
regular avg: 21710.7653 bytes
regular median: 22332 bytes
regular max: 61901 bytes

txid-only size: 34518463 bytes
txid-only avg: 3451.8463 bytes
txid-only median: 3258 bytes
txid-only max: 10193 bytes

reg-no-txid size: 182663961 bytes
reg-no-txid avg: 18266.3961 bytes
reg-no-txid median: 19198 bytes
reg-no-txid max: 60172 bytes

So the median regular filter size over the past 10k blocks is 20KB. If we
extract the txid from the regular filter and add a txid-only filter, the
median size of that is 3.2KB. Finally, the median size of a modified regular
filter (no txid) is 19KB.

-- Laolu

On Thu, May 17, 2018 at 8:33 AM Matt Corallo via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> BIP 158 currently includes the following in the "basic" filter: 1)
> txids, 2) output scripts, 3) input prevouts.
>
> I believe (1) could be skipped entirely - there is almost no reason why
> you'd not be able to filter for, eg, the set of output scripts in a
> transaction you know about and (2) and (3) may want to be split out -
> many wallets may wish to just find transactions paying to them, as
> transactions spending from their outputs should generally be things
> they've created.
>
> In general, I'm concerned about the size of the filters making existing
> SPV clients less willing to adopt BIP 158 instead of the existing bloom
> filter garbage and would like to see a further exploration of ways to
> split out filters to make them less bandwidth intensive. Some further
> ideas we should probably play with before finalizing moving forward is
> providing filters for certain script templates, eg being able to only
> get outputs that are segwit version X or other similar ideas.
>
> Matt
> _______________________________________________
> 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/20180518/58337833/attachment.html>;

📅 Original date posted:2018-05-21 📝 Original message:Hi ...

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

In reply to nevent1q…2egf
_________________________

📅 Original date posted:2018-05-21
📝 Original message:Hi Y'all,

The script finished a few days ago with the following results:

reg-filter-prev-script total size: 161236078 bytes
reg-filter-prev-script avg: 16123.6078 bytes
reg-filter-prev-script median: 16584 bytes
reg-filter-prev-script max: 59480 bytes

Compared to the original median size of the same block range, but with the
current filter (has both txid, prev outpoint, output scripts), we see a
roughly 34% reduction in filter size (current median is 22258 bytes).
Compared to the suggested modified filter (no txid, prev outpoint, output
scripts), we see a 15% reduction in size (median of that was 19198 bytes).
This shows that script re-use is still pretty prevalent in the chain as of
recent.

One thing that occurred to me, is that on the application level, switching
to the input prev output script can make things a bit awkward. Observe that
when looking for matches in the filter, upon a match, one would need access
to an additional (outpoint -> script) map in order to locate _which_
particular transaction matched w/o access to an up-to-date UTOX set. In
contrast, as is atm, one can locate the matching transaction with no
additional information (as we're matching on the outpoint).

At this point, if we feel filter sizes need to drop further, then we may
need to consider raising the false positive rate.

Does anyone have any estimates or direct measures w.r.t how much bandwidth
current BIP 37 light clients consume? It would be nice to have a direct
comparison. We'd need to consider the size of their base bloom filter, the
accumulated bandwidth as a result of repeated filterload commands (to adjust
the fp rate), and also the overhead of receiving the merkle branch and
transactions in distinct messages (both due to matches and false positives).

Finally, I'd be open to removing the current "extended" filter from the BIP
as is all together for now. If a compelling use case for being able to
filter the sigScript/witness arises, then we can examine re-adding it with a
distinct service bit. After all it would be harder to phase out the filter
once wider deployment was already reached. Similarly, if the 16% savings
achieved by removing the txid is attractive, then we can create an
additional
filter just for the txids to allow those applications which need the
information to seek out that extra filter.

-- Laolu

On Fri, May 18, 2018 at 8:06 PM Pieter Wuille <pieter.wuille at gmail.com>
wrote:

> On Fri, May 18, 2018, 19:57 Olaoluwa Osuntokun via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Greg wrote:
>> > What about also making input prevouts filter based on the scriptpubkey
>> being
>> > _spent_? Layering wise in the processing it's a bit ugly, but if you
>> > validated the block you have the data needed.
>>
>> AFAICT, this would mean that in order for a new node to catch up the
>> filter
>> index (index all historical blocks), they'd either need to: build up a
>> utxo-set in memory during indexing, or would require a txindex in order to
>> look up the prev out's script. The first option increases the memory load
>> during indexing, and the second requires nodes to have a transaction index
>> (and would also add considerable I/O load). When proceeding from tip, this
>> doesn't add any additional load assuming that your synchronously index the
>> block as you validate it, otherwise the utxo set will already have been
>> updated (the spent scripts removed).
>>
>
> I was wondering about that too, but it turns out that isn't necessary. At
> least in Bitcoin Core, all the data needed for such a filter is in the
> block + undo files (the latter contain the scriptPubKeys of the outputs
> being spent).
>
> I have a script running to compare the filter sizes assuming the regular
>> filter switches to include the prev out's script rather than the prev
>> outpoint itself. The script hasn't yet finished (due to the increased I/O
>> load to look up the scripts when indexing), but I'll report back once it's
>> finished.
>>
>
> That's very helpful, thank you.
>
> Cheers,
>
> --
> Pieter
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180521/feb53119/attachment.html>;

📅 Original date posted:2018-05-19 📝 Original ...

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

In reply to nevent1q…e5ld
_________________________

📅 Original date posted:2018-05-19
📝 Original message:Riccardo wrote:
> The BIP recall some go code for how the parameter has been selected which
> I can hardly understand and run

The code you're linking to is for generating test vectors (to allow
implementations to check the correctness of their gcs filters. The name of
the file is 'gentestvectors.go'. It produces CSV files which contain test
vectors of various testnet blocks and at various false positive rates.

> it's totally my fault but if possible I would really like more details on
> the process, like charts and explanations

When we published the BIP draft last year (wow, time flies!), we put up code
(as well as an interactive website) showing the process we used to arrive at
the current false positive rate. The aim was to minimize the bandwidth
required to download each filter plus the expected bandwidth from
downloading "large-ish" full segwit blocks. The code simulated a few wallet
types (in terms of number of addrs, etc) focusing on a "mid-sized" wallet.
One could also model the selection as a Bernoulli process where we attempt
to compute the probability that after k queries (let's say you have k
addresses) we have k "successes". A success would mean the queries item
wasn't found in the filter, while a failure is a filter match (false
positive or not). A failure in the process requires fetching the entire
block.

-- Laolu

On Fri, May 18, 2018 at 5:35 AM Riccardo Casatta via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> Another parameter which heavily affects filter size is the false positive
> rate which is empirically set
> <https://github.com/bitcoin/bips/blob/master/bip-0158.mediawiki#construction>;
> to 2^-20
> The BIP recall some go code
> <https://github.com/Roasbeef/bips/blob/83b83c78e189be898573e0bfe936dd0c9b99ecb9/gcs_light_client/gentestvectors.go>;
> for how the parameter has been selected which I can hardly understand and
> run, it's totally my fault but if possible I would really like more details
> on the process, like charts and explanations (for example, which is the
> number of elements to search for which the filter has been optimized for?)
>
> Instinctively I feel 2^-20 is super low and choosing a lot higher alpha
> will shrink the total filter size by gigabytes at the cost of having to
> wastefully download just some megabytes of blocks.
>
>
> 2018-05-17 18:36 GMT+02:00 Gregory Maxwell via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org>:
>
>> On Thu, May 17, 2018 at 3:25 PM, Matt Corallo via bitcoin-dev
>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> > I believe (1) could be skipped entirely - there is almost no reason why
>> > you'd not be able to filter for, eg, the set of output scripts in a
>> > transaction you know about
>>
>> I think this is convincing for the txids themselves.
>>
>> What about also making input prevouts filter based on the scriptpubkey
>> being _spent_? Layering wise in the processing it's a bit ugly, but
>> if you validated the block you have the data needed.
>>
>> This would eliminate the multiple data type mixing entirely.
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
>
>
> --
> Riccardo Casatta - @RCasatta <https://twitter.com/RCasatta>;
> _______________________________________________
> 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/20180518/b40519c4/attachment.html>;

📅 Original date posted:2018-05-29 📝 Original message:> ...

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

In reply to nevent1q…c06w
_________________________

📅 Original date posted:2018-05-29
📝 Original message:> The additional benefit of the input script/outpoint filter is to watch for
> unexpected spends (coins getting stolen or spent from another wallet) or
> transactions without a unique change or output address. I think this is a
> reasonable implementation, and it would be nice to be able to download
that
> filter without any input elements.

As someone who's implemented a complete integration of the filtering
technique into an existing wallet, and a higher application I disagree.
There's not much gain to be had in splitting up the filters: it'll result in
additional round trips (to fetch these distinct filter) during normal
operation, complicate routine seed rescanning logic, and also is detrimental
to privacy if one is fetching blocks from the same peer as they've
downloaded the filters from.

However, I'm now convinced that the savings had by including the prev output
script (addr re-use and outputs spent in the same block as they're created)
outweigh the additional booking keeping required in an implementation (when
extracting the precise tx that matched) compared to using regular outpoint
as we do currently. Combined with the recently proposed re-parametrization
of the gcs parameters[1], the filter size should shrink by quite a bit!

I'm very happy with the review the BIPs has been receiving as of late. It
would've been nice to have this 1+ year ago when the draft was initially
proposed, but better late that never!

Based on this thread, [1], and discussions on various IRC channels, I plan
to make the following modifications to the BIP:

1. use P=2^19 and M=784931 as gcs parameters, and also bind these to the
filter instance, so future filter types may use distinct parameters
2. use the prev output script rather than the prev input script in the
regular filter
3. remove the txid from the regular filter(as with some extra book-keeping
the output script is enough)
4. do away with the extended filter all together, as our original use case
for it has been nerfed as the filter size grew too large when doing
recursive parsing. instead we watch for the outpoint being spent and
extract the pre-image from it if it matches now

The resulting changes should slash the size of the filters, yet still ensure
that they're useful enough for our target use case.

[1]:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-May/016029.html

-- Laolu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180528/8326d73b/attachment-0001.html>;

📅 Original date posted:2018-05-21 📝 Original message:> ...

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

In reply to nevent1q…kha5
_________________________

📅 Original date posted:2018-05-21
📝 Original message:> What if instead of trying to decide up front which subset of elements will
> be most useful to include in the filters, and the size tradeoff, we let
the
> full-node decide which subsets of elements it serves filters for?

This is already the case. The current "track" is to add new service bits
(while we're in the uncommitted phase) to introduce new fitler types. Light
clients can then filter out nodes before even connecting to them.

-- Laolu

On Mon, May 21, 2018 at 1:35 AM Johan Torås Halseth <johanth at gmail.com>
wrote:

> Hi all,
>
> Most light wallets will want to download the minimum amount of data
> required to operate, which means they would ideally download the smallest
> possible filters containing the subset of elements they need.
>
> What if instead of trying to decide up front which subset of elements will
> be most useful to include in the filters, and the size tradeoff, we let the
> full-node decide which subsets of elements it serves filters for?
>
> For instance, a full node would advertise that it could serve filters for
> the subsets 110 (txid+script+outpoint), 100 (txid only), 011 (script+outpoint)
> etc. A light client could then choose to download the minimal filter type
> covering its needs.
>
> The obvious benefit of this would be minimal bandwidth usage for the light
> client, but there are also some less obvious ones. We wouldn’t have to
> decide up front what each filter type should contain, only the possible
> elements a filter can contain (more can be added later without breaking
> existing clients). This, I think, would let the most served filter types
> grow organically, with full-node implementations coming with sane defaults
> for served filter types (maybe even all possible types as long as the
> number of elements is small), letting their operator add/remove types at
> will.
>
> The main disadvantage of this as I see it, is that there’s an exponential
> blowup in the number of possible filter types in the number of element
> types. However, this would let us start out small with only the elements we
> need, and in the worst case the node operators just choose to serve the
> subsets corresponding to what now is called “regular” + “extended” filters
> anyway, requiring no more resources.
>
> This would also give us some data on what is the most widely used filter
> types, which could be useful in making the decision on what should be part
> of filters to eventually commit to in blocks.
>
> - Johan
> On Sat, May 19, 2018 at 5:12, Olaoluwa Osuntokun via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> On Thu, May 17, 2018 at 2:44 PM Jim Posen via bitcoin-dev <bitcoin-
>
>> Monitoring inputs by scriptPubkey vs input-txid also has a massive
>>> advantage for parallel filtering: You can usually known your pubkeys
>>> well in advance, but if you have to change what you're watching block
>>> N+1 for based on the txids that paid you in N you can't filter them
>>> in parallel.
>>>
>>
>> Yes, I'll grant that this is a benefit of your suggestion.
>>
>
> Yeah parallel filtering would be pretty nice. We've implemented a serial
> filtering for btcwallet [1] for the use-case of rescanning after a seed
> phrase import. Parallel filtering would help here, but also we don't yet
> take advantage of batch querying for the filters themselves. This would
> speed up the scanning by quite a bit.
>
> I really like the filtering model though, it really simplifies the code,
> and we can leverage identical logic for btcd (which has RPCs to fetch the
> filters) as well.
>
> [1]:
> https://github.com/Roasbeef/btcwallet/blob/master/chain/neutrino.go#L180
>
> _______________________________________________ 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/20180521/92b184b8/attachment.html>;

📅 Original date posted:2018-05-09 📝 Original message:> ...

2023-06-07T20:11:56+02:00

In reply to nevent1q…3gkm
_________________________

📅 Original date posted:2018-05-09
📝 Original message:> Instead, would you consider to use ANYONECANPAY to sign the tx, so it is
> possible add more inputs for fees? The total tx size is bigger than the
> OP_TRUE approach, but you don’t need to ask for any protocol change.

If one has a "root" commitment with other nested descendent
multi-transaction contracts, then changing the txid of the root commitment
will invalidated all the nested multi tx contracts. In our specific case, we
have pre-signed 2-stage HTLC transaction which rely on a stable txid. As a
result, we can't use the ANYONECANPAY approach atm.

> In long-term, I think the right way is to have a more flexible SIGHASH
> system to allow people to add more inputs and outputs easily.

Agreed, see the recent proposal to introduce SIGHASH_NOINPUT as a new
sighash type. IMO it presents an opportunity to introduce more flexible fine
grained sighash inclusion control.

-- Laolu

On Wed, May 9, 2018 at 11:12 AM Johnson Lau via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> You should make a “0 fee tx with exactly one OP_TRUE output” standard, but
> nothing else. This makes sure CPFP will always be needed, so the OP_TRUE
> output won’t pollute the UTXO set
>
> Instead, would you consider to use ANYONECANPAY to sign the tx, so it is
> possible add more inputs for fees? The total tx size is bigger than the
> OP_TRUE approach, but you don’t need to ask for any protocol change.
>
> In long-term, I think the right way is to have a more flexible SIGHASH
> system to allow people to add more inputs and outputs easily.
>
>
>
> > On 9 May 2018, at 7:57 AM, Rusty Russell via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
> >
> > Hi all,
> >
> > The largest problem we are having today with the lightning
> > protocol is trying to predict future fees. Eltoo solves this elegantly,
> > but meanwhile we would like to include a 546 satoshi OP_TRUE output in
> > commitment transactions so that we use minimal fees and then use CPFP
> > (which can't be done at the moment due to CSV delays on outputs).
> >
> > Unfortunately, we'd have to P2SH it at the moment as a raw 'OP_TRUE' is
> > non-standard. Are there any reasons not to suggest such a policy
> > change?
> >
> > Thanks!
> > Rusty.
> > _______________________________________________
> > 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/20180509/e98eb0d4/attachment.html>;

📅 Original date posted:2018-05-08 📝 Original message:What ...

2023-06-07T20:11:54+02:00

In reply to nevent1q…pspe
_________________________

📅 Original date posted:2018-05-08
📝 Original message:What are the downsides of just using p2wsh? This route can be rolled out
immediately, while policy changes are pretty "fuzzy" and would require a
near uniform rollout in order to ensure wide propagation of the commitment
transactions.

On Tue, May 8, 2018, 4:58 PM Rusty Russell via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> Hi all,
>
> The largest problem we are having today with the lightning
> protocol is trying to predict future fees. Eltoo solves this elegantly,
> but meanwhile we would like to include a 546 satoshi OP_TRUE output in
> commitment transactions so that we use minimal fees and then use CPFP
> (which can't be done at the moment due to CSV delays on outputs).
>
> Unfortunately, we'd have to P2SH it at the moment as a raw 'OP_TRUE' is
> non-standard. Are there any reasons not to suggest such a policy
> change?
>
> Thanks!
> Rusty.
> _______________________________________________
> 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/20180509/63e18795/attachment.html>;

📅 Original date posted:2015-08-06 📝 Original message:Other ...

2023-06-07T19:33:18+02:00

In reply to nevent1q…4fzr
_________________________

📅 Original date posted:2015-08-06
📝 Original message:Other than the source code, the best documentation I've come across is a few
lines on IRC explaining the high-level design of the protocol:
https://botbot.me/freenode/bitcoin-wizards/2015-07-10/?msg=44146764&page=2

On Thu, Aug 6, 2015 at 10:18 AM Sergio Demian Lerner via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> Is there any up to date documentation about TheBlueMatt relay network
> including what kind of block compression it is currently doing? (apart from
> the source code)
>
> Regards, Sergio.
>
> On Wed, Aug 5, 2015 at 7:14 PM, Gregory Maxwell via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> On Wed, Aug 5, 2015 at 9:19 PM, Arnoud Kouwenhoven - Pukaki Corp
>> <arnoud at pukaki.bz> wrote:
>> > Thanks for this (direct) feedback. It would make sense that if blocks
>> can be
>> > submitted using ~5kb packets, that no further optimizations would be
>> needed
>> > at this point. I will look into the relay network transmission protocol
>> to
>> > understand how it works!
>> >
>> > I hear that you are saying that this network solves speed of
>> transmission
>> > and thereby (technical) block size issues. Presumably it would solve
>> speed
>> > of block validation too by prevalidating transactions.
>>
>>
>> Correct. Bitcoin Core has cached validation for many years now... if
>> not for that and other optimizations, things would be really broken
>> right now. :)
>>
>> > Assuming this is all
>> > true, and I have no reason to doubt that at this point, I do not
>> understand
>> > why there is any discussion at all about the (technical) impact of large
>> > blocks, why there are large numbers of miners building on invalid blocks
>> > (SPV mining, https://bitcoin.org/en/alert/2015-07-04-spv-mining), or
>> why
>> > there is any discussion about the speed of block validation (cpu
>> processing
>> > time to verify blocks and transactions in blocks being a limitation).
>>
>> I'm also mystified by a lot of the large block discussion, much of it
>> is completely divorced from the technology as deployed; much less what
>> we-- in industry-- know to be possible. I don't blame you or anyone in
>> particular on this; it's a new area and we don't yet know what we need
>> to know to know what we need to know; or to the extent that we do it
>> hasn't had time to get effectively communicated.
>>
>> The technical/security implications of larger blocks are related to
>> other things than propagation time, if you assume people are using the
>> available efficient relay protocol (or better).
>>
>> SPV mining is a bit of a misnomer (If I coined the term, I'm sorry).
>> What these parties are actually doing is blinding mining on top of
>> other pools' stratum work. You can think of it as sub-pooling with
>> hopping onto whatever pool has the highest block (I'll call it VFSSP
>> in this post-- validation free stratum subpooling). It's very easy to
>> implement, and there are other considerations.
>>
>> It was initially deployed at a time when a single pool in Europe has
>> amassed more than half of the hashrate. This pool had propagation
>> problems and a very high orphan rate, it may have (perhaps
>> unintentionally) been performing a selfish mining attack; mining off
>> their stratum work was an easy fix which massively cut down the orphan
>> rates for anyone who did it. This was before the relay network
>> protocol existed (the fact that all the hashpower was consolidating on
>> a single pool was a major motivation for creating it).
>>
>> VFSSP also cuts through a number of practical issues miners have had:
>> Miners that run their own bitcoin nodes in far away colocation
>> (>100ms) due to local bandwidth or connectivity issues (censored
>> internet); relay network hubs not being anywhere near by due to
>> strange internet routing (e.g. japan to china going via the US for ...
>> reasons...); the CreateNewBlock() function being very slow and
>> unoptimized, etc. There are many other things like this-- and VFSSP
>> avoids them causing delays even when you don't understand them or know
>> about them. So even when they're easily fixed the VFSSP is a more
>> general workaround.
>>
>> Mining operations are also usually operated in a largely fire and
>> forget manner. There is a long history in (esp pooled) mining where
>> someone sets up an operation and then hardly maintains it after the
>> fact... so some of the use of VFSSP appears to just be inertia-- we
>> have better solutions now, but they they work to deploy and changing
>> things involves risk (which is heightened by a lack of good
>> monitoring-- participants learn they are too latent by observing
>> orphaned blocks at a cost of 25 BTC each).
>>
>> One of the frustrating things about incentives in this space is that
>> bad outcomes are possible even when they're not necessary. E.g. if a
>> miner can lower their orphan rate by deploying a new protocol (or
>> simply fixing some faulty hardware in their infrastructure, like
>> Bitcoin nodes running on cheap VPSes with remote storage) OR they can
>> lower their orphan rate by pointing their hashpower at a free
>> centeralized pool, they're likely to do the latter because it takes
>> less effort.
>> _______________________________________________
>> 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/20150806/1a6f12be/attachment-0001.html>;

📅 Original date posted:2015-08-06 📝 Original message:Other ...

2023-06-07T17:45:27+02:00

In reply to nevent1q…jk8f
_________________________

📅 Original date posted:2015-08-06
📝 Original message:Other than the source code, the best documentation I've come across is a few
lines on IRC explaining the high-level design of the protocol:
https://botbot.me/freenode/bitcoin-wizards/2015-07-10/?msg=44146764&page=2

On Thu, Aug 6, 2015 at 10:18 AM Sergio Demian Lerner via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> Is there any up to date documentation about TheBlueMatt relay network
> including what kind of block compression it is currently doing? (apart from
> the source code)
>
> Regards, Sergio.
>
> On Wed, Aug 5, 2015 at 7:14 PM, Gregory Maxwell via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> On Wed, Aug 5, 2015 at 9:19 PM, Arnoud Kouwenhoven - Pukaki Corp
>> <arnoud at pukaki.bz> wrote:
>> > Thanks for this (direct) feedback. It would make sense that if blocks
>> can be
>> > submitted using ~5kb packets, that no further optimizations would be
>> needed
>> > at this point. I will look into the relay network transmission protocol
>> to
>> > understand how it works!
>> >
>> > I hear that you are saying that this network solves speed of
>> transmission
>> > and thereby (technical) block size issues. Presumably it would solve
>> speed
>> > of block validation too by prevalidating transactions.
>>
>>
>> Correct. Bitcoin Core has cached validation for many years now... if
>> not for that and other optimizations, things would be really broken
>> right now. :)
>>
>> > Assuming this is all
>> > true, and I have no reason to doubt that at this point, I do not
>> understand
>> > why there is any discussion at all about the (technical) impact of large
>> > blocks, why there are large numbers of miners building on invalid blocks
>> > (SPV mining, https://bitcoin.org/en/alert/2015-07-04-spv-mining), or
>> why
>> > there is any discussion about the speed of block validation (cpu
>> processing
>> > time to verify blocks and transactions in blocks being a limitation).
>>
>> I'm also mystified by a lot of the large block discussion, much of it
>> is completely divorced from the technology as deployed; much less what
>> we-- in industry-- know to be possible. I don't blame you or anyone in
>> particular on this; it's a new area and we don't yet know what we need
>> to know to know what we need to know; or to the extent that we do it
>> hasn't had time to get effectively communicated.
>>
>> The technical/security implications of larger blocks are related to
>> other things than propagation time, if you assume people are using the
>> available efficient relay protocol (or better).
>>
>> SPV mining is a bit of a misnomer (If I coined the term, I'm sorry).
>> What these parties are actually doing is blinding mining on top of
>> other pools' stratum work. You can think of it as sub-pooling with
>> hopping onto whatever pool has the highest block (I'll call it VFSSP
>> in this post-- validation free stratum subpooling). It's very easy to
>> implement, and there are other considerations.
>>
>> It was initially deployed at a time when a single pool in Europe has
>> amassed more than half of the hashrate. This pool had propagation
>> problems and a very high orphan rate, it may have (perhaps
>> unintentionally) been performing a selfish mining attack; mining off
>> their stratum work was an easy fix which massively cut down the orphan
>> rates for anyone who did it. This was before the relay network
>> protocol existed (the fact that all the hashpower was consolidating on
>> a single pool was a major motivation for creating it).
>>
>> VFSSP also cuts through a number of practical issues miners have had:
>> Miners that run their own bitcoin nodes in far away colocation
>> (>100ms) due to local bandwidth or connectivity issues (censored
>> internet); relay network hubs not being anywhere near by due to
>> strange internet routing (e.g. japan to china going via the US for ...
>> reasons...); the CreateNewBlock() function being very slow and
>> unoptimized, etc. There are many other things like this-- and VFSSP
>> avoids them causing delays even when you don't understand them or know
>> about them. So even when they're easily fixed the VFSSP is a more
>> general workaround.
>>
>> Mining operations are also usually operated in a largely fire and
>> forget manner. There is a long history in (esp pooled) mining where
>> someone sets up an operation and then hardly maintains it after the
>> fact... so some of the use of VFSSP appears to just be inertia-- we
>> have better solutions now, but they they work to deploy and changing
>> things involves risk (which is heightened by a lack of good
>> monitoring-- participants learn they are too latent by observing
>> orphaned blocks at a cost of 25 BTC each).
>>
>> One of the frustrating things about incentives in this space is that
>> bad outcomes are possible even when they're not necessary. E.g. if a
>> miner can lower their orphan rate by deploying a new protocol (or
>> simply fixing some faulty hardware in their infrastructure, like
>> Bitcoin nodes running on cheap VPSes with remote storage) OR they can
>> lower their orphan rate by pointing their hashpower at a free
>> centeralized pool, they're likely to do the latter because it takes
>> less effort.
>> _______________________________________________
>> 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/20150806/1a6f12be/attachment-0001.html>;