Self Custody

By combining Taproot with DHC, HelloBTU enable cryptographic trust for Bitcoin-Collateralized Stablecoin on native Bitcoin.

What is Taproot?

Taproot is a significant advancement in contract publication on the blockchain, addressing various concerns by enabling settlement through the publication of only relevant contract portions. This innovation not only enhances security but also introduces a new, expansive language for improved flexibility and scalability.

  1. Schnorr Signatures (BIP 340) SigHash(Signature Hash) is applied to the transactions, meaning that once a SigHash is applied, the information becomes immutable(unchangeable). If the information is changed, the trasaction loses validity. Nothing can be changed without destorying the SigHash. Previously, a small amount of information could be changed through "malleability" that would not result in the transaction losing its validity.

  2. Taproot (BIP 341) [MAST] Bitcoin Script Update allows the scripting language to use Schnorr signatures and integrates the Merkelized Alternative Script Trees(MAST).

  3. Tapscript Tapscript is a collection of "opcodes", which are essentially just lines of codes that execute commands on the Bitcoin protocol that have been updated to make way for the new changes installed by Taproot. It can be referred to as a language, but it is more like an update to Bitcoin Script.

What is TimeLock?

A Timelock is a smart contract primitive in Bitcoin that restricts the spending of bitcoins until a specified future time or block height. Simply put, Timelocks hinder miners from confirming a transaction until certain conditions are met.

There are four major options for Bitcoin timelocks - nLocktime, nSequence, OP_CHECKLOCKTIMEVERIFY (OP_CLTV), and OP_CHECKSEQUENCEVERIFY (OP_CSV). Two of these options are script-level time locks, while the other two are transaction-level time locks.

Multi-Sign Escape Hatch

Multi-Sign Escape Hatch uses the multi-sign tapscript and timelock tapscript to support joint asset maintenance by multiple parties. It has two payment methods, when all signers agree on a certain spending output, then execute a multi-sign trapscript script. If any of them do not agree and the time expires, the time lock trapscript is executed and the output is spent by the validator specified in the script.

How to build the Multi-Sign Escape Hatch address

Standard Taproot address generation formula:

Q= P+H(P|c)G
Q = the final Taproot public key
P = the internal public key
H(P|c) = A hash of the internal public key and the commitment
c = MAST

To sign a transaction with our private key, adjust the private key using the same hash value H (P|c) as the public key and commitment.

Taproot uses a simple trick involving something called a "merkle tree".

             hash(ab, cd)                  <- Final hash    (the root)
              /             \                
      hash(a, b)             hash(c, d)       <- Combined hash (the branches)
     /          \           /          \    
    hash(a) hash(b)        hash(c) hash(d)    <- Initial hash  (the leaves)
[ script(a), script(b), script(c), script(d) ]

Combine the previous knowledge to finally generate the Escape Hatch address:

Q = PK  +     H(PK | Fh)G                                  
                |    |                                     
    +-----------+    +----------------+                    
    |                                 |                    
    PK                   +-------Final|hash---+            
    |                    |                    |            
    |                    |                    |            
 PK1+PK2                 |                    |            
                     hash(a)                hash(b)        
                 Multi-sign script       Timelock script   
                +-------------------+   +-----------------+
                | PK1               |   | TIME            |
                | OP_CHECKSIGVERIFY |   | OP_CLTV         |
                | PK2               |   | OP_DROP         |
                | OP_CHECKSIG       |   | PK3             |
                |                   |   | OP_CHECKSIG     |
                +-------------------+   +-----------------+

Working Flow

The diagram illustrates the process of creating and spending various Bitcoin outputs through different transactions as described in the following paragraphs:

Types of transactions

There are four types of transactions in the HelloBTU system:

  • Mapping Credential Transaction

  • Burning Credential Transaction

  • Forced Withdrawal Transaction

  • Escape Hatch Transaction

Mapping Credential Transaction

The mapper generates WBTC by creating a mapping transaction. This is a Bitcoin transaction where a certain amount of bitcoins to be minted is submitted to a mapping script approved by HelloBTU. These scripts lock a selected number of BTC. The requirements for a valid mapping transaction are:

  • It can contain an arbitrary number of inputs.

  • It can contain any number of outputs. One of these outputs must be the taproot output submitted to the BTC mapping script recognized by HelloBTU. Hereafter called the mapping output. The output must also contain an OP_RETURN with the information that needs to be map.

OP_RETURN output description：

TxOut {
     Value: 0,
     PkScript: MapOpReturnScript
}

MapOpReturnScript = 0x6a || 0x47 || SerializedMapOpReturnData

type MapOpReturnData struct {
    dst_chain             []byte
    receiver_bytes_len      byte
    receiver_bytes        []byte
}

Fields description:

  • dst_chain: 4 bytes, u32 format of the EVM chain ID of the target chain.

  • receiver_bytes_len: 1 byte, Represents the length of the recipient's address.

  • receiver_bytes：The address of the recipient on the destination chain, expressed in bytes.

Burning Credential Transaction

When BTC mappers want to redeem their assets before the originally promised time lock expires, they use the burning credential transaction. The requirements for a valid burning credential transaction are:

  • It can contain any number of inputs that point to the mapping output of the mapping credential transaction。

  • It can contain at least two outputs, the first is the address of the BTC mapper. the second must also contain an OP_RETURN with burn information. If the selected input amount has excess BTC assets after deducting the burn amount, a taproot output of the BTC mapping script identified by HelloBTU is added.

OP_RETURN output description：

TxOut {
     Value: 0,
     PkScript: BurnOpReturnScript
}

BurnOpReturnScript = 0x6a || 0x47 || SerializedBurnOpReturnData

type BurnOpReturnData struct {
    uid                       []byte
}

Fields description：

  • uid: Unique identifier for the burn operation。

Forced Withdrawal Transaction

When the BTC mapper does not burn the assets before the time lock expires, due to disagreements over the content of the burning credential transaction, the committee will use a forced withdrawal transaction to transfer the assets out of the mapping script. The requirements for a valid forced withdrawal transaction are:

  • It can contain any number of inputs that point to the mapping output of the mapping transaction.

  • It contains only one output, which must be the taproot output submitted to the mapping script recognized by HelloBTU. Unlike mapping credential transaction, the output of a forced withdrawal transaction does not require an additional OP_RETURN.

Escape Hatch Transaction

When the BTC mapper did not burn the assets before the time expired, because the private key of the committee was lost, the validator used the escape hatch transaction to transfer the assets from the mapping script. The requirements for a valid escape hatch transaction are:

  • It can contain any number of inputs that point to the mapping output of the mapping credential transaction.

  • It can contain an arbitrary number of outputs.

Mapping Output Script

Mapping output is a taproot output that can only be spent via script spend paths. For the key spend path, we consider it unavailable by default because the internal key is a combination of the committee private key and the user private key. Minting output can be spent via three script spend paths.

1. Escaping path

Escaping path transfers the minter's Bitcoin to DAO. Its script form:

<TIME>  OP_CLTV OP_DROP <ValidatorPk> OP_CHECKSIG

  • < TIME > : It’s unbinding time.

  • < ValidatorPk >: The validator public key of the HelloBTU system.

2. Enforcing path

Enforcing path transfers assets locked by the mapper to the committee. Its script form:

<TIME>  OP_CLTV OP_DROP <CommitteePk> OP_CHECKSIG

  • < TIME > : It's unbinding time. The enforcing timelock is much smaller than the escaping timelock.

  • < CommitteePk >: The public key of the committee of the Bool Network system.

3. multi-sign path

The multi-sign path is used to burn the mapper's assets in case of double signatures. Its script form:

<MapperPK> OP_CHECKSIGVERIFY <CommitteePK> OP_CHECKSIG

  • < MapperPK >：BTC mapper public key.

  • < CommitteePK >：Dynamic committee public key for Bool Network system.

How to use

Verify

Usage:
       custody-cli verify [OPTIONS] --network <NETWORK> multi-sign-escape <COMMITTEE_PK> <MULTI_SIGN_PK> <ESCAPED_PK> <ESCAPED_TIME>
       custody-cli verify [OPTIONS] --network <NETWORK> multi-sign-escape-enforce <COMMITTEE_PK> <MULTI_SIGN_PK> <ESCAPED_PK> <ESCAPED_TIME> <ENFORCED_PK> <ENFORCED_TIME>
       custody-cli verify [OPTIONS] --network <NETWORK> multi-sign-threshold-escape <COMMITTEE_PK> <MULTI_SIGN_PK> <ESCAPED_PKS> <ESCAPED_TIME> <ESCAPED_THRESHOLD>
       custody-cli verify [OPTIONS] --network <NETWORK> multi-sign-threshold-escape-enforce <COMMITTEE_PK> <MULTI_SIGN_PK> <ESCAPED_PKS> <ESCAPED_TIME> <ESCAPED_THRESHOLD> <ENFORCED_PK> <ENFORCED_TIME>
Options:
  -n, --network <NETWORK>  [possible values: bitcoin, testnet, signet, regtest]
  -p, --p2tr <P2TR>        
  -h, --help               Print help

For multi-sign-threshold-escape-enforce taproot, we get the committee's taproot build-related information from the public panel:

COMMITTEE_PK : 0x044f258e9da31aa67ce55b5d737547012e52b6b68af323a8ba312658a65965754286fb42b8b21ecc6f39d23b757a31ce26dc43ff1236904e25523a1f202a1a1994
MULTI_SIGN_PK : 0x034220c4f5722e6f3b28dac2ebbc97cb93d344a3ae1a8b77768fb2a395e8c68922
ESCAPED_PKS : 0x4220c4f5722e6f3b28dac2ebbc97cb93d344a3ae1a8b77768fb2a395e8c689224d4c4aed95dd566354285f77b4df0338c43cc258271f3e1920c9d58894c8001f
ESCAPED_TIME: 1735637262
ESCAPED_THRESHOLD: 2
ENFORCED_PK: 0x02d2b3f4627755201c93001b4cd8b6e73a3a53d1ff921b1e048779aa4e0575fb9b
ENFORCED_TIME: 1735488000

Then execution command includes the above parameters.

custody-cli verify --network testnet multi-sign-threshold-escape-enforce <<script parameters>>

We will enter the following and check the authenticity of the address.

>> p2tr: tb1pp0qeynm4mg2uraez5x9snn55kfu5aa0kw3rvlur3tjw2qe2j8xuqjsl7pv

Sign

Usage: custody-cli sign --secret <SECRET> --utxos <UTXOS> --receiver <RECEIVER> --amount <AMOUNT> --network <NETWORK> --spend <SPEND> multi-sign-escape <COMMITTEE_PK> <MULTI_SIGN_PK> <ESCAPED_PK> <ESCAPED_TIME>
       custody-cli sign --secret <SECRET> --utxos <UTXOS> --receiver <RECEIVER> --amount <AMOUNT> --network <NETWORK> --spend <SPEND> multi-sign-escape-enforce <COMMITTEE_PK> <MULTI_SIGN_PK> <ESCAPED_PK> <ESCAPED_TIME> <ENFORCED_PK> <ENFORCED_TIME>
       custody-cli sign --secret <SECRET> --utxos <UTXOS> --receiver <RECEIVER> --amount <AMOUNT> --network <NETWORK> --spend <SPEND> multi-sign-threshold-escape <COMMITTEE_PK> <MULTI_SIGN_PK> <ESCAPED_PKS> <ESCAPED_TIME> <ESCAPED_THRESHOLD>
       custody-cli sign --secret <SECRET> --utxos <UTXOS> --receiver <RECEIVER> --amount <AMOUNT> --network <NETWORK> --spend <SPEND> multi-sign-threshold-escape-enforce <COMMITTEE_PK> <MULTI_SIGN_PK> <ESCAPED_PKS> <ESCAPED_TIME> <ESCAPED_THRESHOLD> <ENFORCED_PK> <ENFORCED_TIME>

Options:
  -s, --secret <SECRET>      
      --fee-rate <FEE_RATE>  0.00001 represents 1 sat/vB [default: 0.00001]
      --utxos <UTXOS>        utxos list in json format. example: '[{"txid":"2946d93547be832d3fd63086c3894948a0f13ed29077d00aa5a3c8767ea83497","vout":0,"amount":10000000}]'
  -r, --receiver <RECEIVER>  
      --amount <AMOUNT>      
  -n, --network <NETWORK>    [possible values: bitcoin, testnet, signet, regtest]
  -s, --spend <SPEND>        [possible values: key, mulsig, escape-hatch, forced-withdrawal]
  -h, --help                 Print help

  1. Get the available utxos of the account.

    curl -sSL "https://mempool.space/testnet/api/address/<your address>/utxo"

  2. Build transaction

    custody-cli sign -- \
--secret <your_secret> \
--fee-rate 0.0055 \
--utxos '[{"txid":"258070821cf45f2e3425236aa24b61eaea729813fc147fc0e9d191df9d747eac","vout":0,"amount":10000000},{"txid":"a57c9d28310960ea721d6dace3990733065d0092042eb7b0b1cb293fc2f196d2","vout":0,"amount":15546460}]' \
--receiver tb1qpcfgz4q2nhsqx2vpew93dwnaaecn8cyy9v82ys \
--amount 1514946 \
--network testnet \
--spend escape-hatch \
multi-sign-threshold-escape-enforce <<script parameters>>

  3. Broadcast Transaction

    curl -X POST -sSLd "<output of step 2>" "https://mempool.space/testnet/api/tx"

Psbt

psbt is used to process partially signed transactions, which is beneficial to threshold escape hatches. In the case of multiple users, members sign in turn.

Usage: custody-cli psbt --secret <SECRET> --psbt <PSBT> multi-sign-escape
       custody-cli psbt --secret <SECRET> --psbt <PSBT> multi-sign-escape-enforce
       custody-cli psbt --secret <SECRET> --psbt <PSBT> multi-sign-threshold-escape
       custody-cli psbt --secret <SECRET> --psbt <PSBT> multi-sign-threshold-escape-enforce

Options:
  -s, --secret <SECRET>  
  -p, --psbt <PSBT>      
  -h, --help             Print help

After the first member selects the input and output and signs the transaction, the result is in base58 format, indicating that the conditions for being uploaded to the chain have not been met, and subsequent members can sign psbt:

custody-cli psbt -- \
    --secret <your_secret> \
    --psbt  CzA46Xjk5dDKhpR5okb8MKTtUqVqxGJ1iggZZzZzHgws1fzS1TCn1aiycyUaSnP2C1fMG3ciBeEnBobHeZu32Vzz4EVb8C8usZG3xyvDyPeewUCbc36tMRBZRUBTdpKfwh8ZdgQo1kuRuNosRxXGzMNn6fp9TLAvhqbryLB49Gv29onyrk3vL6a1XrWcunN5WmRQVABpCVxRBQ8T8rrSZm99z4PBMWjzTbs3LwrKYABWAwVNwgzAn8firKd3SLR6K37ii5U7b6fCFN3BjGjv3AJCtJJh5oj9yKAZGdZ3gSkZNyT88bUAsQL45GKTM4TGk8U1s5xBxvpGohA1rfGwWXf6wqvUuiTv96nvzee9cCt9MaJncPWkYVmdzhVDG9cSCyponNmKHJCuX2b3kMr4MGhgqouShVbsvSpkfNzSJEQvZkysom3abXyYDpSJkpXsVaqBRQoBCjt33dmQzi4ruKkNj3hJxJMmoGiko3nPMtra3nb2FrzUT3wGbaRCHjC8XgHFTet3prrtZAPWxS6iG5RMnNWD49MxdccfAekMWDWgdvwLH3vR72prx9KxiTyFXKLpjEMLhsD56biNyD5tqzSQ9KZYH6v6eveFyEymByTcZxEmoupxRgktfEt23ZexCghoGkMz4ccjKGZtwXyhsBMMt1mFSCpEUWYxD1AJw1srXNE3gZSLAMPJJrbQM4VyiHFELwLQng3oiRwJ4nyhzWqjZEDMi3E3mGoKwPhcB9NSbFTMwpCv35M54kgkoQSJ2Pfxua4Pvdeg8Zx6gAsZvqfnZGv8KA5XbrGPxfWJR6TVhYJvRd32dqNpm2jU2NAQFMqnwSUhgYuzN9hq95UMVZ33xW2E1oFa7xgECuxmJuHbBpmJvvZU6uucDS1L6Fyak886hGurtphJC3EeMi5PAVBS1pKgZ4jfYoTckGhFrj2AebUunTM9tAq83s1DpZDAhKMPyHBS24UST9cHQ8AbomGxmaFCJmqs2Srmh9C2mQ6LAwWy1AfXNxsuSaUbAsV9amKMLVQPHFcLsgBKYH3uzeMgkpGoijxHb24jpztUhMheLfeMDQAXySGb7o1Ajk1XtnZiw97MUHgC6bkg3BrKRP3BJ5BWn6mdPkiwndfUupxWmSFoDNtfETQJ8T84tPmi7PWFTw57gyb3dysyz7Yc1SmAqBdc7yz6wuMJ4CWjdNfPdTfWRPRzXKDiHNi5eMUGFVBzocwyQLX5PG5CGmP \
    multi-sign-threshold-escape-enforce
PreviousChannel AccountNextModule

Last updated