Re: [bitcoin-dev] Scaling Lightning With Simple Covenants
Hi John, Thanks for the proposal, few feedback after a first look. > If Bitcoin and Lightning are to become widely-used, they will have to be > adopted by casual users who want to send and receive bitcoin, but > who do > not want to go to any effort in order to provide the infrastructure for > making payments. > Instead, it's reasonable to expect that the Lightning infrastructure will be > provided by dedicated users who are far less numerous than I don't know if it is that simple to classify expected users in "casual"-vs"dedicated" and then design protocols accordingly. In practice, if you take today Lightning as an example the trust assumptions is more a matrix than a dichotomie, e.g you have the choice between full-node vs light client to get block-relay, large-sized mempool vs small mempool or no mempool at all for fee estimations, routing HTLCs or not, running local watchtower or not... without all those choices being necessarily interdependent. Generally, I would say "tell me your IO disk/bandwidth/CPU performance/fees ressources and level of technical knowledge and I'll tell you what level of trust-minimization you can afford". > This difference in numbers implies that the key challenge in scaling Bitcoin > and Lightning is providing bitcoin and Lightning to casual > users. > As a result, the rest of this post will focus on this challenge. I think few different scaling notions can be introduced to measure the performance of an off-chain construction. Onboarding scaling defining how many users can co-exist off-chain, considering throughput limits (e.g blocksize, average block interval). Transactional scaling defining how many transfers can be performed off-chain per on-chain transaction, considering the properties of the off-chain system. Users resource scaling defining how much resource a user should mobilize / consume (e.g average weight cost for cooperative / non-cooperative close) to make a trust-minimized usage of the off-chain construction. I think the proposal is mainly considering onboarding scalability, i.e maxing out the number of channels that can be owned by a user though it is unclear if other scalability dimensions are weighted in. In particular, no known protocol that uses the current Bitcoin consensus rules allows a large number (e.g., tens-of-thousands to millions) of Lightning channels, each co-owned by a casual user, to be created from a single on-chain unspent transaction output (UTXO). I’m not sure if this statement is 100% accurate. One could create a radixpool with replacing CTV usage with Musig2 where the end transactions outputs bear Lightning channel: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-June/017968.html. Of course there is no N-party update mechanism to rebalance the channel internally and it’s a nightmare if a subranch of transactions with some depth hit the chain, though I think it works with today Bitcoin consensus rules. The requirement for casual users to sign transactions that specify the exact set of casual users whose signatures are required creates a very difficult group coordination problem that's not well-suited to the behavior of casual users [9, Section 2.2]. I think you have two more precise problems designated under this group coordination problem. One is the dynamic novation of this group, i.e how you add / remove user, if possible in a compact fashion. The second the dynamic update of the “account” / channels owned by the users of this group, if possible with minimal interactivity. > On the other hand, sometime shortly before E, casual user A_i can use the > Lightning Network to send all of their balance in the channel > > (A_i, B) to > themselves in some other Lightning channel that is the leaf of some other > timeout-tree. I think there is an uncertainty in this model as there is no guarantee that you have a dedicated user ready to be the gateway to route the balance, neither the dedicated user have adequate channel topology allowing to send the funds in the part of the network you wish to do so. And this is unclear what the casual user is left to do if an intermediate hop withhold the HTLC in-flight until the timeout-tree mature in favor of the dedicated user, iiuc. So I think draining is uncertain in a world where jamming is possible, even assuming economic mitigation as one might earn more to jam a casual user draining than loosing in jamming upfront fees. > Of course, sometime between E - to_self_delay_i and E, A_i should verify that > B has created such a new timeout-tree. I think this requirement is altering the design goal introduced at first on casual users “performing actions at specific times in the future” as from my understanding there is no guarantee B broadcast an on-chain transaction triggering the move of A funds to the new timeout-tree. This becomes unclear when A should take correction actions like broadcasting its own control transaction (?) when B fails to dos, especially in a world whe
Re: [bitcoin-dev] Actuarial System To Reduce Interactivity In N-of-N (N > 2) Multiparticipant Offchain Mechanisms
Hi Zeeman
> What we can do is to add the actuary to the contract that
> controls the funds, but with the condition that the
> actuary signature has a specific `R`.
> As we know, `R` reuse --- creating a new signature for a
> different message but the same `R` --- will leak the
> private key.
> The actuary can be forced to put up an onchain bond.
> The bond can be spent using the private key of the actuary.
> If the actuary signs a transaction once, with a fixed `R`,
> then its private key is still safe.
> However, if the actuary signs one transaction that spends
> some transaction output, and then signs a different
> transaction that spends the same transaction output, both
> signatures need to use the same fixed `R`.
> Because of the `R` reuse, this lets anyone who expected
> one transaction to be confirmed, but finds that the other
> one was confirmed, to derive the secret key of the
> actuary from the two signatures, and then slash the bond
> of the actuary.
>From my understanding, if an off-chain state N1 with a negotiated group of
40 is halted in the middle of the actuary's R reveals due to the 40th
participant non-interactivity, there is no guarantee than a new off-chain
state N1' with a new negotiated group of 39 (from which evicted 40th's
output is absent) do not re-use R reveals on N1. So for the actuary bond
security, I think the R reveal should only happen once all the group
participants have revealed their own signature. It sounds like some loose
interactivity is still assumed, i.e all the non-actuary participants must
be online at the same time, and lack of contribution is to blame as you
have a "flat" off-chain construction (i.e no layering of the promised
off-chain outputs in subgroups to lower novation interactivity).
More fundamentally, I think this actuarial system does not solve the
"multi-party off-chain state correction" problem as there is no guarantee
that the actuary does not slash the bond itself. And if the bond is guarded
by users' pubkeys, there is no guarantee that the user will cooperate after
the actuary equivocation is committed to sign a "fair" slashing transaction.
Best,
Antoine
Le sam. 9 sept. 2023 à 02:28, ZmnSCPxj via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> a écrit :
> (N > 2) Multiparticipant Offchain Mechanisms
>
> Introduction
>
>
> The blockchain layer of Bitcoin provides an excellent non-interactivity:
> users can go offline, then come online, synchronize, and broadcast
> transactions to the mempool.
> Always-online miners then get the transactions and add them to blocks,
> thereby confirming them.
>
> There are two important properties here:
>
> * Users do not need to be persistently online, only online when they
> need to create and send a transaction.
> * Miners only dictate transaction ordering (i.e. which of two
> conflicting transactions "comes first" and the second one is thus
> invalid), and do ***not*** have custody of any user funds at all.
>
> Both properties are difficult to achieve for offchain mechanisms like
> 2-participant Lightning channels.
> But without these two properties, the requirement to be interative
> and thus always online creates additional friction in the use of the
> technology.
>
> When we move on from 2-participant offchain mechanisms ("channels")
> and towards N > 2, the interactivity problem is exacerbated.
> Generally, it is not possible to advance the state of an offchain
> mechanism that uses N-of-N signing without all users being online
> simultaneously.
>
> In this writeup, I present a new role that N-of-N offchain mechanisms
> can include.
> This role, the actuary role, is similar to the role of miners on the
> blockchain: they have high uptime (so users can connect to them to
> send a transaction "for confirmation") and they only decide
> transaction ordeering and do ***not*** have custody of the coins.
>
> Required Softforks
> --
>
> To enable the actuary role I propose here, we need to have two
> softforks:
>
> * `SIGHASH_ANYPREVOUT`
> * `OP_CHECKSEPARATEDSIG`
> - Instead of accepting `(R, s)` signature as a single stack item,
> this accepts `s` and `R` as two separate stack items.
>
> I expect that neither is significantly controversial.
> Neither seems to modify miner incentives, and thus isolates the
> new role away from actual miners.
>
> I will describe later how both are used by the proposed mechanism.
>
> Actuaries In An N-of-N Offchain Mechanism
> =
>
> Mechanisms like Decker-Wattenhofer, Poon-Dryja, and
> Decker-Russell-Osuntokun ("eltoo") can have an N-of-N signatory
> set.
> I will not discuss them deeply, other than to note that
> Decker-Russell-Osuntokun requires `SIGHAH_ANYPREVOUT`, supports
> N > 2 (unlike Poon-Dryja), and does not require significant
> number of transactions with varaible relative locktimes in the
> unilateral close case (unlike Decker-Wattenhofer).
>
> Using an N-of-N signatory set pr
Re: [bitcoin-dev] New BIP to align descriptors, xpub derivation and miniscript
Maxim,
That does not sound compelling. Let's go through your points.
First you point how some wallets supporting descriptors keep vague BIP44
compatibility. There are multiple reasons for this, but first you say that the
derivation path "commits to" (i think you mean describe? that's rather what you
want for a backup) output types such as P2WSH or P2TR. It's incorrect. That's
the whole point of descriptors. There are standardized paths for Taproot
*keyspend* and weird multisig P2WSH templates. But you can't keep an infinite
list of BIP44 templates for all the scripts it's possible to use under those
output types.
As for the reasons for keeping BIP44 compatibility in some wallets:
- It makes sense for some output types to keep compatibility with
non-descriptor wallets. For instance see how the Bitcoin Core wallet uses BIP86
for Taproot keyspend despite it being descriptor-based. [0]
- Some signing devices whitelist the paths you can extract an xpub from without
user confirmation. (It's the case of Ledger and the reason we have to resort to
using legacy BIP48-derived paths in Liana.)
You then go to point out how it's useless to use legacy standards within
descriptors. Sure, but that doesn't call for one more unscalable legacy
standard. Just don't use it if you can afford to? I'd even go for
`m/network'/account'/<0;1>/*` (rather than your
`m/89'/network'/account'/branch/<0;1>/*`) if Ledger would let us.
You third point is about how you can't reuse public keys across spending paths
within a Miniscript. But it doesn't prevent you from reusing the same signer,
you can simply:
- Derive a different hardened xpub from the signing device for each occurrence
(cumbersome); or
- Query a single xpub from the device and then append an unhardened derivation
step. To reduce the number of steps you can even reuse the multipath step.
(`xpub/<0;1>/*` for the first appearance, then `xpub/<2;3>/*`, `xpub/<4;5>/*`,
...)
(Small correction passing by: you mention the Miniscript duplicate key check
doesn't apply under Taproot context, but it absolutely does. I think you meant
across Taproot branches, but keep in mind you can have multiple spending paths
within a single leaf.)
Your final point is about how your client-side validation project introduces
some "descriptor-level concepts" which are not handled by current standards. If
your new standard is incompatible with descriptors, fix it instead of trying to
convince all existing wallets to become aware of it?
Cheers,
Antoine
[0] The motivation section of BIP86 says it all.
https://github.com/bitcoin/bips/blob/master/bip-0086.mediawiki#motivation
--- Original Message ---
On Sunday, September 10th, 2023 at 7:13 PM, Dr Maxim Orlovsky via bitcoin-dev
wrote:
> Hi,
>
> Script output descriptors ("output descriptors", "wallet descriptors", or
> simply "descriptors") are getting more and more traction. Descriptors work
> in combination with miniscript, extended BIP32 keys (xpub/xprivs
> "descriptors" equipped with origin and derivation information) and are used
> to construct new primitives like "wallet templates" used in Ledger and
> BitBox today.
>
> Nevertheless, due to historical reasons, the resulting combination of the
> mentioned technologies is frequently redundant and leaves a lot of
> unspecified caveats, when it is unclear how descriptor with
> internally-conflicting data has to be handled by wallets and/or devices.
> For instance,
> - derivation path standards (following BIP44) commit to the type of the
> script pubkey (P2PKH, P2SH, P2WSH, P2WPKH, P2TR), but the same information
> is present in the descriptor itself;
> - each of the public keys within the descriptor replicates the derivation
> information and information about Bitcoin network (testnet or mainnet);
> - if the same signer participates in different miniscript branches, due
> to miniscript anti-malleability rules a new derivation path has to be used
> in pre-Taproot context (but not in Taproot) -= and multiple contradictory
> approaches exist on how to handle that;
> - client-side-validation approach, used by several projects, introduces new
> descriptor-level concepts, like taproot-ebmedded OP_RETURN commitments
> (so-called "tapret"), which are not handled by existing standards.
>
> As a result, descriptors contain a lot of redundant information, which makes
> them bulk, hard to read or type, and impossible to handle in the narrow UI
> of hardware wallets.
>
> At LNP/BP Standards Association we'd like to work/coordinate efforts on
> a new BIP proposal removing all the issues above. Before working on the
> BIP proposal text I would like to start by discussing an approach, seeking
> Concept (n)ACKs and Approach (n)ACKs from this mail list.
>
>
> The approach
>
>
> Existing separate BIP44 standards, committing to a specific form of script
> pubkey are made redundant with the introduction of output descriptors. Thus,
> I think we need a new BIP44
Re: [bitcoin-dev] Trustless 2-way-peg without softfork
Any chance of a quick tldr to pique our interest by explaining how exactly
this works "and the protocol will reach consensus on whether the state
reported by the oracle is correct" in presumably a permissionless,
anonymous, decentralized fashion, and what caveats there are?
Regards,
Andrew
On Sun, Sep 10, 2023 at 4:06 PM Dr Maxim Orlovsky via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Hi,
>
> Several years ago my team from Pandora Project working on
> censorship-resistant distributed machine learning proposed Prometheus: a
> protocol for high-load computing on top of Bitcoin. The protocol operates
> as a multi-party game setting where an oracle ("worker") is provided with
> an arbitrary computationally complex task (any Turing-complete computing,
> machine learning training or inference etc) and the network is able to
> reach a consensus on whether a result reported by the worker is true. The
> consensus is reached via optional rounds of verification and arbitrage. The
> protocol is cryptoeconomically-safe, i.e. has a proven Nash equilibrium.
> The protocol was later transferred to LNP/BP Standards Association (
> https://lnp-bp.org) and was kept in a backlog of what can be done in a
> future as a layer on top of Bitcoin.
>
> I'd like to emphasize that Prometheus works on Bitcoin, requires just
> several Bitcoin tx per task, and _doesn't require any soft fork_. All
> economic setting is done with Bitcoin as a means of payment, and using
> existing Bitcoin script capabilities.
>
> Link to the paper describing the protocol: <
> https://github.com/Prometheus-WG/prometheus-spec/blob/master/prometheus.pdf
> >
>
> Only today I have realized that Prometheus protocol can be used to build
> cryptoeconomically-safe (i.e. trustless) 2-way-peg on the Bitcoin
> blockchain without any soft-forks: a "worker" in such a case acts as an
> oracle for some extra-bitcoin system (sidechain, client-side-validated
> protocol, zk rollup etc) validating it, and the protocol will reach
> consensus on whether the state reported by the oracle is correct.
>
> In other words, this is an alternative to BIP-300 and other similar
> soft-forks having the only purpose of doing 2-way pegs. It also enables the
> two-way trustless transfer of Bitcoins between Bitcoin blockchain, RGB and,
> in a future, potential new layer 1 called "prime" (to learn more about
> prime you can check my Baltic Honeybadger talk <
> https://www.youtube.com/live/V3vvybsc1A4?feature=shared&t=23631>).
>
>
> Kind regards,
> Dr Maxim Orlovsky
> Twitter: @dr_orlovsky
> Nostr: npub13mhg7ksq9efna8ullmc5cufa53yuy06k73q4u7v425s8tgpdr5msk5mnym
>
> LNP/BP Standards Association
> Twitter: @lnp_bp
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
