From 24cd4f19dec50d2bffc700d78a72b4b1c686b659 Mon Sep 17 00:00:00 2001 From: Patricio Date: Mon, 18 Jul 2022 07:46:40 -0600 Subject: [PATCH 1/2] Draft of FROST RSKIP --- IPs/RSKIPFROST.md | 194 ++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 194 insertions(+) create mode 100644 IPs/RSKIPFROST.md diff --git a/IPs/RSKIPFROST.md b/IPs/RSKIPFROST.md new file mode 100644 index 00000000..4d7a4cec --- /dev/null +++ b/IPs/RSKIPFROST.md @@ -0,0 +1,194 @@ +--- +rskip: ??? +title: Peg-out efficiency improvement (Taproot) +description: This RSKIP introduces Taproot (Bitcoin Soft Fork Nov. 2021) for use in peg-ins and peg-outs to improve performance, cost reductions, and security. +status: Draft +purpose: Sca Usa Sec +author: PDG (@patogallaiovlabs), RFV (@ramsesfv), NV (@NVescovo) +layer: Core +complexity: 3 +created: 2022-07-18 +--- + +# Peg-out efficiency improvement (Taproot) + +|RSKIP | ??? | +| :------------ |:-------------| +|**Title** |Peg-out efficiency improvement (Taproot) | +|**Created** |18-JUL-2022 | +|**Author** |Patricio Gallardo, Ramsès Fernàndez-València, Nicolás Vescovo| +|**Purpose** |Sca Usa Sec | +|**Layer** |Core | +|**Complexity** |3 | +|**Status** |Draft | + +## Abstract + +This RSKIP introduces Taproot (Bitcoin Soft Fork Nov. 2021) for use in peg-ins and peg-outs to improve performance, cost reductions, and security. + +## Motivation + +The RSK peg out uses multisignatures to implement a threshold scheme that protects the bitcoins locked. Multi-signatures are simple and relatively +efficient for small groups, but they become expensive as the number of signers increases. Each input signed in a peg-out transaction must transmit +m-out-of-n signatures, and each signature consumes 65 bytes, and n public keys, consuming 33 or 65 bytes each, depending on if they are compressed or not. +Bringing Taproot to the RSK peg will tackle all these problems. + +## Specification + +At the time of writing, the Bridge contract works with a Federation, which is an abstraction for a set of distinct secp256k1 public keys, which can ultimately be used to represent a Bitcoin multisig (N of M) P2SH. The upgrade to this native contract involves replacing the current representation format type with a Segwit Compatible (P2SH-P2WSH). + +### Create a new Federation type + +In order to replace the current federation representation, a new federation type is going to be created incrementing by one the value of the version type and save a new slot in the federation storage. For more information refer to [this detailed description](https://github.com/rsksmart/RSKIPs/blob/master/IPs/RSKIP123.md#storage-upgrade) on how a federation upgrade should be managed. + +Although the schema and content of this slot is not to be changed more than the version number, it will serve to indicate how the federation multisig redeem script should be regenerated. + +Currently the redeem script is as follow: +* ``: +``` +OP_NOTIF + OP_PUSHNUM_M + OP_PUSHBYTES_33 pubkey1 + ... + OP_PUSHBYTES_33 pubkeyN + OP_PUSHNUM_N +OP_ELSE + OP_PUSHBYTES_2 + OP_CSV + OP_DROP + OP_PUSHNUM_2 + OP_PUSHBYTES_33 emergencyPubkey1 + OP_PUSHBYTES_33 emergencyPubkey2 + OP_PUSHBYTES_33 emergencyPubkey3 + OP_PUSHNUM_3 +OP_ENDIF +OP_CHECKMULTISIG +``` + +To receive funds we calculate the ``: + +``` +HASH160 EQUAL +``` + +* Where `` is pre computed as follows: + +``` +hash160(sha256()) + +``` + +* With the **new version** a `` is added to the `` : + +``` +hash160( sha256()) +``` + + +### New Address + +Also, this new federation type will have a new way of calculating the address, and this is how Segwit compatible addresses are computed: + +``` +Base-58 ( “05” + hash160 ( sha256 ( ) ) ) +``` +Where: +- `` is represented by: `“OP_0 ”` +- `` by pre computing: `sha256 ( )` +- and finally “05” is the *P2SH version byte* + + + +### Spend output - Peg out + +With this new implementation comes a new way of spending the output. Although it does not change much, it changes: the *transaction id computation*, the *scriptSig* field and the *segregated witness data*. +We can describe each of the changes as follow: + +* **Transaction id computation** + +SegWit can separate witness data from the block, thereby making it unavailable for modifications to change transaction IDs. +The Segregated Witness protocol upgrade develops a sidechain for storing witness data separately from the main blockchain network. +As a result, transaction IDs cannot be modified depending on witness data modifications. + +* **scriptSig** + +It will cointain the following content: +``` + +``` + +* **Segregated witness data** + +While segregated witness data will contain the redeeming data (signatures and flag for activating the ERP - [Emergency Recovery Protocol](https://github.com/rsksmart/RSKIPs/blob/master/IPs/RSKIP201.md)) and the actual redeem script (mentioned before as ``) + +Example: +``` + ... +``` + +### Summary +Putting it all together, the following is a list of the most important fields with their new values: + +* witness: + +``` + ... +``` + +* scriptSig: + +``` + +``` + +* scriptPubKey: + +``` +HASH160 hash160( sha256()) EQUAL +``` + +### Migration to the new federation + +During migration, both mechanisms (legacy and Segwit compatible) will be working at the same time. Legacy would be for the federation leaving and Segwit compatible for the incoming federation. +All the funds (outputs) will be transferred from the current address to the new Segwit compatible address before mentioned (New Address section). + +But once the migration is completed, only Segwit compatible will be the accepted address and the unique mechanism to support the peg outs. +The migration process description can be [found here (RSKIP186)](https://github.com/rsksmart/RSKIPs/blob/master/IPs/RSKIP186.md). + + +## Rationale +Segwit stands for segregated witness, and it is an upgrade to the Bitcoin consensus rules and network protocol proposed and implemented as a BIP – 91 (https://github.com/bitcoin/bips/blob/master/bip-0091.mediawiki) soft-fork that was activated on Bitcoin’s mainnet in 2017. + +Before segwit’s introduction, every input in a transaction was followed by the witness data that unlocked it. The witness data was embedded in the transaction as part of each input. It is called segregated witness because it implies separating the signature or unlocking script of a specific output. The witness data is moved outside the transaction. +In Segwit v0, the Block Size concept is replaced by Block Weight. Block Size is measured in Bytes and Block Weight is measured in Weight Units (WU). The maximum weight of a 1 MB block is 4000 WU. In calculating the weight of a transaction, a non-witness 1 byte weighs 4 WU and a witness byte weighs 1 WU. + +We first analyze two other protocols Frost and MuSig2 (part of Segwit v1: [BIP 340](https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki), [BIP 341](https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki), and [BIP 342](https://github.com/bitcoin/bips/blob/master/bip-0342.mediawiki)). Although some advantage is obtained in relation to performance, this is not enough to counteract the greater difficulty of implementation that they need. This is why we consider that implementing Segwit v0 is the best option in the medium/short term. +After doing a deep and detailed analysis of these protocols involved we summarized in a table a comparison between the different protocols in terms of complexity, fee costs and robustness. + +| Topics | FROST | Musig2 | Segwit |P2SH (current) | +| ----------------- |:----------:| ---------:| ---------:| --------------:| +|PowHSM Complexity | High | Low | Low | - | +|Fee Cost type | Fixed | Variable | Variable | Variable | +|INPUT Fee Cost (vbytes) 7/13| 16| 120 | 238.75 | 955 | +|INPUT Fee Cost reductions (%)7/13| -98% | -87% | -75% | - | +|TX Fee Cost (vbytes) (1)| 106 | 210 | 328.75 | 1045 | +|TX Fee Cost reductions (%) (1)| -89% | -78% | -66% | - | +|Verification Complexity|Medium/Low| High | Low | Low | +|Robustness | Medium/Low | Low | High | High | +|Implementation time| Long term |Medium term|Short/Medium-term| - | +|Threshold N limit (2)|Unlimited (3)| 34 | 67 | 15 | + +**Observations* +1. *A TX is composed of 1 input and 2 outputs.* +2. *This is the higher N, independent of M. We are considering M as the half of N, which is the worst-case scenario. If M is more or less than half of N, the total starts to decrease.* +3. *FROST unlimited threshold limits it just in theory and what we can represent through aggregated signatures, practically we would have restrictions at the Bridge complexity level.* + + +## Backwards Compatibility + +This change is a hard-fork and therefore all full nodes must be updated. SPV light-clients do not need to be updated. + + +### Copyright + +Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). From 56d020d8a7a9ec6e3b8725714e09a661c4342372 Mon Sep 17 00:00:00 2001 From: Patricio Date: Mon, 18 Jul 2022 07:48:09 -0600 Subject: [PATCH 2/2] assign # to FROST RSKIP, 343 --- IPs/{RSKIPFROST.md => RSKIP343.md} | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) rename IPs/{RSKIPFROST.md => RSKIP343.md} (99%) diff --git a/IPs/RSKIPFROST.md b/IPs/RSKIP343.md similarity index 99% rename from IPs/RSKIPFROST.md rename to IPs/RSKIP343.md index 4d7a4cec..15c9a2e8 100644 --- a/IPs/RSKIPFROST.md +++ b/IPs/RSKIP343.md @@ -1,5 +1,5 @@ --- -rskip: ??? +rskip: 343 title: Peg-out efficiency improvement (Taproot) description: This RSKIP introduces Taproot (Bitcoin Soft Fork Nov. 2021) for use in peg-ins and peg-outs to improve performance, cost reductions, and security. status: Draft @@ -12,7 +12,7 @@ created: 2022-07-18 # Peg-out efficiency improvement (Taproot) -|RSKIP | ??? | +|RSKIP | 343 | | :------------ |:-------------| |**Title** |Peg-out efficiency improvement (Taproot) | |**Created** |18-JUL-2022 |