The payment pool protocol may improve bitcoin privacy and scalability on the chain

Original title: Improving BTC Privacy and Chain Scalability through Payment Pool Protocol

Original author: Free and easy happy & NBSP;

This week's Bitcoin Technology Weekly involves a new CoinPool payment pool proposal that improves participant privacy and chain scalability by using TaProot. In addition, Wasabi contributors have proposed a new WabiSabi protocol that can implement coinjoin transactions of any amount. And finally, we'll look at some major updates to the bitcoin software infrastructure that took place in the middle of last week.

& have spent CoinPool payment pool protocol & NBSP; which improves privacy and extensibility on the chain;

Antoine Riard and Gleb Naumenko on the Bitcoin developer mailing list post about a new payment Pool technology that improves payment privacy by allowing multiple users to share control of a single UTXO without trust. Compared to previous payment pool designs such as JoinPool, the CoinPool design focuses on allowing participants to make off-chain commitments to transactions between members in the pool. Using TaProot, this allows collaborating participants to operate protocols such as Lightning networks or Vault using UTXO, which is indistishable from single-key UTXO, which improves participant privacy and scalability along the chain.

In this sense, the protocol ACTS as a kind of universal channel factory for not only lightning networks, but also for many protocols that create transactions on the chain with a unique fingerprint.

The authors give an overview of how CoinPool can use bitcoin + Taproot's existing feature SIGHASH_NOINPUT, as well as the ability to use the delete Only accumulator (such as Merkeltree; Perhaps it's the proposed BIP116 NBSP; OP_MERKLEBRANCHVERIFY). Rather than advocating a specific design, they seem to be discussing how CoinPool or the like could provide a common mechanism that wallets would use by default to eliminate the chain footprint of current and proposed multi-user protocols.

Text link:https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-June/017964.html

& have spent

Second, the new WabiSabi protocol can carry out coinjoin transaction of any output value

In the CoinJoin protocol, a group of users collaborates to create a trade template and spend some of their existing UTXO (inputs) on a new set of UTXO (outputs). The way this transaction template is created has an impact on the privacy provided by Coinjoin, and different implementations use different approaches:

1, Joinmarket  There are two types of users: Users who pay for Coinjoin (Market Taker) and users who are allowed to use its UTXO (Market Maker). To create a Coinjoin, Taker contacts several makers, collects their input and output information, and creates a transaction template. This enables Taker to know which inputs provide which outputs for all coinjoin participants, but also ensures that each maker only knows which inputs it has and funds which outputs it has. Taker was able to directly capture Coinjoin's privacy benefits, while Maker was able to directly capture the revenue that provided liquidity. If Taker kept his privacy, Maker indirectly gained more privacy for third-party blockchain monitors. Mr Maker, who wanted to ensure privacy, was always able to act as a Taker in several rounds of mixing. This model provides the taker with great flexibility to carry out its own input and output to the transaction template. For example, Taker can select the number of CoinJoins they want to create, or spend their money as part of coinJoins to third parties.

2. Wasabi USES a central coordinator to organize each coinjoin made using the software. To prevent the coordinator from knowing which inputs fund which outputs, users anonymously submit the outputs they want to create and receive a blind Chaumian signature. Each user then connects under another anonymous identity and submits each output and its unhidden signature. The signature can be proved to be from the coordinator, but the unhidden signature cannot establish a connection with the specific user who receives the blind signature. This allows the transaction template to be built without the coordinator knowing which inputs are funded and which outputs. Since the coordinator cannot see the output when creating its blind signature, it does not allow the user to specify any amount, otherwise the user might try to charge more than he would if he participated in coinJoin. This is not a security concern; the other participants will refuse to sign any ill-formed transactions, but this requires a restart of the agreement. Wasabi requires that all outputs either belong to a small set of allowable sizes (such as 0.1BTC, 0.2BTC, 0.4BTC, etc.) or be an unshielded change output. thisLimits the user's ability to use a specified amount through Wasabi, or to make any amount of payment.

This week, some Wasabi contributors released a new protocol on the Bitcoin developer mailing list they call WabiSabi, which conceptually extends the existing Wasabi protocol with a technology adapted from the Secure Transactions (CT). This allows the client to make a commitment to any output and, without disclosing the amount, prove that each amount is within a specified range (for example, 0.0001 BTC to 21 million BTC) and that their sum is the specified value.

The coordinator USES this specified value to verify that the total output to be created by the client is equal to the total of the inputs provided by the client (minus the cost).

The coordinator can then provide an anonymous credence to each output, allowing the client to anonymously submit the output to the coordinator later for inclusion in the trade template.

The software implementing the protocol will be able to create a coordinated CoinJoin that allows the client to select its output, thereby facilitating non-equivalent CoinJoins and in-CoinJoin payments.

The authors are seeking comments, criticisms and Suggestions on how best to use the new protocol, which has many differences from the current Wasabi protocol (such as verifying anonymous credentials with a key instead of a blind signature).

& have spent

Update bitcoin software Infrastructure & NBSP;

Caravan has added HD wallet support, Coin Control, and hardware wallet test suites. In addition to single-address multi-signature coordination, Caravan now supports HD wallet multi-signature coordination and coin control. Unchained Capital, creator of Caravan, also announced a test suite to test hardware wallet interactions and Trezor multi-check address recognition in a Web browser. & have spent

2. Bitpay's Copay and Bitcore projects now support native segwit: Bitpay's Copay wallet and back-end Bitcore services now support receiving and spending native segwit output.

Blockstream Green wallet for desktop: Blockstream has released Green wallet for macOS, Windows, and Linux desktops. The desktop version of the wallet supports 2-OF-3 and 2-OF-2 multiple signatures, Tor, and the test network.

4. Tankred Hase has Shared a new library, HB-lib, which supports the HD Wallet and lightweight client features, but is still in development and is not ready for production. & have spent

5. BIP85 describes a super Keychain, whose subkey can be used to create a traditional HD Keychain seed.

Text link:https://www.8btc.com

Welcome to join the official BlockBeats community:

Telegram Subscription Group: https://t.me/theblockbeats

Telegram Discussion Group: https://t.me/BlockBeats_App

Official Twitter Account: https://twitter.com/BlockBeatsAsia