[ad_1]
The Bitcoin Optech Newsletter provides readers with a high-level summary of the most important technical news about Bitcoin, along with resources to help them learn more. To help our readers stay up to date with Bitcoin, we are republishing the latest issue of this newsletter below. Remember to subscribe to receive this content straight to your inbox.
This week’s newsletter includes our regular sections describing how you can prepare for taproot, summarizing the latest releases and candidate releases, and listing notable changes to popular Bitcoin infrastructure projects.
New
No major news this week.
Taproot preparation # 7: multi-signature
A weekly series on how developers and service providers can prepare for the upcoming activation of taproot at block height 709,632.
In the 1000 blocks received before this write, 11% of all transaction entries contained a multisig opcode. Two of the most important and immediate benefits of taproot will be manifested if many users and departments creating these transactions switch from multisig opcodes to multisignatures without a script.
The first major benefit will be a reduction in the size of transactions. Script-based multisignatures grow in size as more keys and signatures are required, but multisignatures are consistently small in size. The smallest efficient multisig strategy (1 of 2) requires more space than a multi-signature strategy which can involve thousands of signers. The decrease in size results in a direct reduction in fees for multi-signature users and an indirect reduction in fees for all users, as the same request for confirmed transactions can be satisfied using a smaller block space.
The second major advantage is the improvement of confidentiality. Each multisig usage is recorded separately in the blockchain where supervisors can use them to make educated guesses about the portfolio history and current balance of individual users. For example, by looking at block 692.039, we can distinguish not only multisig expense from monosig expense, but also distinguish between different set sizes and thresholds for multisig.
By comparison, a third party looking only at blockchain data cannot say that a spender has used a multisignature. When a multi-signature is used for a keypath expense, it is indistinguishable from a single-signed expense. If all single-sig and multisigs in the above block were switched to P2TR keypath expenses, only a few exotic expenses would be distinguishable by their scripts (and even these could use keypath expenses in the best possible way). cases).
Use multisignatures
We know of three Schnorr-based multisignature schemes designed specifically for Bitcoin, all members of the MuSig family:
MuSig (also known as MuSig1), which should be simple to implement but requires three communication cycles during the signing process. MuSig2, which is also simple to implement. It eliminates a communication cycle and makes it possible to combine another cycle with the exchange of keys. This makes it possible to use a signing process somewhat similar to what we use today with script-based multisig. This requires storing additional data and ensuring that your signing software or hardware cannot unknowingly be made to repeat part of the signing session. implemented. Its communication between participants cannot be combined with key exchange, but it has the advantage of not being vulnerable to repeated session attacks.
All signatories must agree on which protocol to use, so there may be a network effect where many implementations choose to use the same protocol. The authors of the MuSig proposals suggest that it will be MuSig2 because of its relative simplicity and great utility.
There is an open and actively developed PR for the libsecp256k1-zkp project to add MuSig2 support. We would expect the basic multi-signature workflow to look like the following:
The wallet for each participant generates a BIP32 xpub which is shared with all other participants via an output script descriptor or other method (as is commonly done now for multisigs). The wallet also generates a set of nonces which are also shared with the other participants. The wallet can generate these nonces using the enhanced BIP32 derivation. Nonces are 32 bytes long and you need two per signature. For rarely used wallets, all the nuncios needed for the entire life of the wallet can be shared in advance. For more frequently used wallets (e.g. LN routing nodes), each wallet can send its signature for the current transaction along with its nonces for the next transaction. Any of the wallets can then generate an aggregated public key by combining their public key at a certain BIP32 depth with public keys at the same depth as all other wallets in the multi-signature association. The aggregated public key can be used to receive P2TR payments. When one of the wallets wants to spend the funds, it uses a similar PSBT-based workflow that it would use with a script-based multisig. Unlike multisig, the wallet uses its next nonces and the next nonces of all other participants to create a shared nonce according to the MuSig2 algorithm; it then creates a partial signature on this nonce and the transaction. When other wallets receive the PSBT, they use the same procedure. The partial signatures are then combined to create the final signature and the transaction is broadcast. Threshold signature
By itself, the MuSig multi-signature scheme family only gives you the n-of-n signature – each party that contributes a key to the aggregated public key must also contribute a partial signature to the final signature. This works perfectly well as a direct replacement for some uses of script-based multisig today, such as spending LN 2 out of 2 funding outflows, but it deviates from other popular policies such as scripting multisig 2 over. 3 used by many exchanges.
Several developers are working on threshold signing schemes that will bring the same efficiency and privacy benefits as multisignatures to k-of-n scenarios, but there is a simple trick that can be used until these schemes are available.
In many threshold cases, it is known in advance which participants are most likely to sign. For example, in a 2 of 3 situation, we can know that normally Alice and Bob co-sign, while Carol only signs if one of the others is not available. For this set of circumstances, primary keys can use multisignature for the pivot root key path spending (for example between Alice and Bob) and additional results (Alice and Carol, or Bob and Carol) can use multisignatures. with the OP_CHECKSIG opcode in separate branches in a tapscripts tree.
In the normal case, the above has exactly as much efficiency and confidentiality as a single signature or multiple signature transaction. In the abnormal case, spending still works as expected and remains more efficient and private than posting your multisig settings to chain.
While users wanting minimal fees and maximum privacy can optionally switch to pure threshold signing schemes, the scheme above can also continue to be used as it provides on-chain evidence to an auditor (if they know all participants’ public keys) private keys were used to sign.
Releases and candidates for release
New versions and candidate versions for popular Bitcoin infrastructure projects. Please consider upgrading to new versions or helping to test candidate versions.
C-Lightning 0.10.1rc2 is an upgrade candidate that contains a number of new features, several bug fixes, and some updates to development protocols (including double funding and offers). Notable changes to code and documentation
Notable changes this week in Bitcoin Core, C-Lightning, Eclair, LND, Rust-Lightning, libsecp256k1, Hardware Wallet Interface (HWI), Rust Bitcoin, BTCPay Server, Bitcoin Improvement Proposals (BIP) and Lightning BOLT.
Bitcoin Core # 22006 adds documentation for user space, statically defined tracing (USDT) and the first three trace points – build support and macros for which were added in Bitcoin Core # 19866. Users who build Bitcoin Core with eBPF tracing enabled can connect to trace points with the sample scripts provided or write their own trace scripts for better observability in the node when a new block is connected, incoming P2P messages are received and outgoing P2P messages are sent. The documentation also includes usage examples and guidelines for adding new track points. The Lightning # 1893 allows separate configuration of charges for unannounced channels, advertised channels and trampoline relay minimums. This PR also sets different default relay charges for unannounced channels (0.01%) compared to advertised channels (0.02%). With this change, all four LN implementations we cover will support sending keys. The author has also submitted the corresponding (not yet merged) documentation on Key Send Payments as Bitcoin Lightning Improvement Proposals (BLIP), a proposed way to document features and best practices that are not owned by the LN BOLTs specification
Find the original article here.
Please sign up directly for the Bitcoin Optech newsletter to receive this content straight to your inbox each month.
|
Sources 2/ https://bitcoinmagazine.com/technical/preparing-for-taproot-bitcoin The mention sources can contact us to remove/changing this article |
[ad_2]