Bitcoin Technology Weekly: Statechain, Schnorr signature and BIP322

Note: The original text is from Bitcoin Optech

In this week's Bitcoin Technical Brief, we first described a proposal to deploy statechain on Bitcoin without making changes to the consensus layer, and then summarized the analysis that helps prevent differential power consumption ( DPA) Discussion of the Schnorr nonce generator function attacked, and the proposed update on the BIP322 general signmessage . Finally, we will also introduce some updates on popular Bitcoin infrastructure projects.

(Picture from: tucheng.com)

• Technical Guide | IPFS Relationship Genealogy, Technical Framework and Working Principle
• Technical Primer | GHAST Rule Upgrade (Part 1)
• Why is Filecoin different? IPFS founder talks about its proof system

1. Deploy statechain in the absence of Schnorr signature or eltoo

Statechain is an offchain system that allows a user (such as Alice) to delegate the ability to spend UTXO to another user (Bob), who can then delegate the spending authority to a third person User (Carol), and so on. The off-chain entrusted operations here are all performed in cooperation with trusted third parties. Only when conspired with the entrusted signer (such as the previous principal Alice or Bob), the third party can steal funds. Delegated signers can always spend UTXO without the permission of a trusted third party. It can be said that this makes the state chain more trustless than the alliance side chain. Because anyone who has been a principal can trigger on-chain spending, the original design of the statechain was to use the eltoo mechanism to ensure that the latest principal ’s (Carol) on-chain spending can take precedence over previous delegations Person (Alice and Bob), assuming that the trusted third party has not colluded with the previous client to cheat.

This week, Tom Trevethan published two changes to the statechain design on the Bitcoin developer mailing list, and these two changes can make the statechain (statechain) usable with the current Bitcoin protocol. Without waiting for schnorr signature and SIGHASH_ANYPREVOUT proposal soft fork:

1. Replace the eltoo mechanism with a decreasing locktime similar to that proposed for the duplex micropayment channel (this requires SIGHASH_NOINPUT of SIGHASH_NOINPUT or SIGHASH_ANYPREVOUT of bip- SIGHASH_ANYPREVOUT ). For example, when Alice gains control of the state chain UTXO, the time lock will prevent her from unilaterally spending UTXO for a period of 30 days, and when Alice transfers UTXO to Bob, the time lock will limit it At 29 days, this makes Bob's expenditure take priority over Alice's expenditure. The disadvantage of this method is that the client may have to wait a long time before spending his funds without permission from a trusted third party.
2. Using secure multi-party computing technology, replace the 2-of-2 schnorr multi-signature between the trusted third party and the current principal with a single signature. The main disadvantage of this method is that it adds complexity and makes security review more difficult.

Some developers commented on the proposal and proposed alternatives. In addition, someone discussed a previous patent application by Trevethan, which involved the use of decrement time locks by trusted third parties and off-chain payment methods guaranteed by multi-party ECDSA.

2. Alleviate the differential power analysis (DPA) attacks faced by Schnorr signatures

Lloyd Fournier initiated a discussion on the Bitcoin development mailing list about the proposal described in Newsletter # 87, which uses the recommended nonce generation function to update the BIP340 specification of schnorr signature (this function is said to be resistant to differential power analysis (DPA ) ).

It is reported that the so-called differential power analysis (DPA) attack can monitor the power used by the hardware wallet when generating different signatures to potentially understand what private key the user has used (or reveal enough information about the key so that it can be effectively Brute force). Fournier questioned the utility of using an exclusive-OR (xor) operation to combine private keys and randomness, rather than the standard method of hashing private keys and randomness.

Pieter Wuille, one of the authors of BIP340, replied:

"In the aggregation of keys and signatures, a mathematical relationship is established between the private keys of cooperating users, then an attacker (if he is one of the cooperating users) may be able to analyze the power consumption of his private key information from other users. Combine the signature generation information learned in to understand the private keys of other users. It is believed that compared to relatively trivial functions such as xor (binary addition), look at relatively complex hash functions such as SHA256 Power consumption, this attack will be easier to perform. "

For more information about Schnorr signatures and differential power analysis (DPA) attacks, Wuille and several other bitcoin cryptographers have discussed more here .

3. Proposed update on BIP322 general signmessage

A few weeks ago, bitcoin developers started discussing the common signmessage protocol, and recently, Karl-Johan Alm proposed a simplified solution that eliminates the ability to bundle multiple signature messages of different scripts. Removed an unused abstract proposal, which could have more easily extended the protocol to a storage proof similar to BIP127.

In addition to the above technical solution updates, this week's Bitcoin Lightning Network client LND also welcomed some updates. LND # 4078 added an estimatemode configuration setting (optional CONSERVATIVE or ECONOMICAL ), which is used to Adjust the cost estimation method when bitcoind back-end retrieval costs are estimated.

We will continue to update Blocking; if you have any questions or suggestions, please contact us!