BIP 0124: Difference between revisions
Created page with "{{bip}} <pre> BIP: 124 Title: Hierarchical Deterministic Script Templates Author: Eric Lombrozo <eric@ciphrex.com> William Swanson <swansontec@gmail.com> St..." |
Update BIP text with latest version from https://github.com/bitcoin/bips/blob/cf0b529e78860fa2/bip-0124.mediawiki |
||
(2 intermediate revisions by the same user not shown) | |||
Line 1: | Line 1: | ||
{{bip}} | {{bip}} | ||
{{BipMoved|bip-0124.mediawiki}} | |||
<pre> | <pre> | ||
BIP: 124 | BIP: 124 | ||
Layer: Applications | |||
Title: Hierarchical Deterministic Script Templates | Title: Hierarchical Deterministic Script Templates | ||
Author: Eric Lombrozo <eric@ciphrex.com> | Author: Eric Lombrozo <eric@ciphrex.com> | ||
William Swanson <swansontec@gmail.com> | William Swanson <swansontec@gmail.com> | ||
Status: | Comments-Summary: No comments yet. | ||
Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0124 | |||
Status: Rejected | |||
Type: Informational | Type: Informational | ||
Created: 2015-11-20 | Created: 2015-11-20 | ||
License: PD | |||
Post-History: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-November/011795.html | |||
</pre> | </pre> | ||
{{ | ==Abstract== | ||
This BIP defines a script template format that can be used by wallets to deterministically generate scripts with specific authorization policies using the key derivation mechanism defined in BIP32. | |||
==Motivation== | |||
Currently existing wallets typically issue scripts in only a tiny handful of widely used formats. The most popular formats are pay-to-pubkey-hash and m-of-n pay-to-script-hash (BIP16). However, different wallets tend to use mutually incompatible derivation schemes to generate signing keys and construct scripts from them. Moreover, with the advent of hashlocked and timelocked contracts (BIP65, BIP112), it is necessary for different wallets to be able to cooperatively generate even more sophisticated scripts. | |||
In addition, there's a lot of ongoing work in the development of multilayered protocols that use the blockchain as a settlement layer (i.e. the Lightning Network). These efforts require sufficiently generalized templates to allow for rapidly evolving script designs. | |||
This BIP provides a generalized format for constructing a script template that guarantees that different wallets will all produce the same scripts for a given set of derivation paths according to BIP32. | |||
==Specification== | |||
===Keys=== | |||
An individual key is determined by a BIP32 derivation path and an index. For convenience, we introduce the following notation: | |||
'''A'''<sub>k</sub> = (derivation path for A)/k | |||
===Key Groups=== | |||
Let '''m'''<sub>i</sub> denote distinct BIP32 derivation paths. We define a key group of n keys as a set of key derivation paths with a free index k: | |||
{'''K'''<sub>k</sub>} = { '''m'''<sub>1</sub>/k, '''m'''<sub>2</sub>/k, '''m'''<sub>3</sub>/k, ..., '''m'''<sub>n</sub>/k } | |||
Key groups are useful for constructing scripts that are symmetric in a set of keys. Scripts are symmetric in a set of keys if the semantics of the script is unaffected by permutations of the keys. Key groups enforce a canonical form and can improve privacy. | |||
===Sorting=== | |||
We define a lexicographic sorting of the keys. (TODO: specification of sorting conventions - compressed pubkeys, encoding, etc...) | |||
Define {'''K'''<sub>k</sub>}<sub>j</sub> to be the jth element of the sorted keys for derivation index k. | |||
===Script Templates=== | |||
We construct script templates by inserting placeholders for data into a script. To denote a placeholder, we use the following notation: | |||
''Script''('''A''') = opcodes ['''A'''] opcodes | |||
We extend this notation to an arbitrary number of placeholders: | |||
''Script''('''X1''', '''X2''', ..., '''Xn''') = opcodes ['''X1'''] opcodes ['''X2'''] opcodes ... opcodes ['''Xn'''] opcodes | |||
We introduce the following convenient notation for sorted key groups: | |||
[{'''K'''<sub>k</sub>}] = [{'''K'''<sub>k</sub>}<sub>1</sub>] [{'''K'''<sub>k</sub>}<sub>2</sub>] ... [{'''K'''<sub>k</sub>}<sub>n</sub>] | |||
===Operations on Keys=== | |||
In some applications, we might want to insert the result of some operation performed on a key rather than the key itself into the script. For example, we might want to insert a Hash160 of key '''A'''<sub>k</sub>. We can use the following notation: | |||
[''Hash160''('''A'''<sub>k</sub>)] | |||
===Encoding=== | |||
TODO | |||
==Examples== | |||
===2-of-3 Multisig=== | |||
The script template is defined by: | |||
''Script''('''X''') = 2 ['''X'''] 3 OP_CHECKMULTISIG | |||
Letting '''K'''<sub>k</sub> = { '''m'''<sub>1</sub>/k, '''m'''<sub>2</sub>/k, '''m'''<sub>3</sub>/k }, the ''k''th script for this key group is denoted by ''Script''({'''K'''<sub>k</sub>}). | |||
===1-of-1 or 2-of-3=== | |||
The script template is defined by: | |||
''Script''('''A''', '''B''') = <br> | |||
OP_DUP ['''A'''] OP_CHECKSIG<br> | |||
OP_NOTIF<br> | |||
2 ['''B'''] 3 OP_CHECKMULTISIGVERIFY <br> | |||
OP_NOTIF<br> | |||
OP_ENDIF<br> | |||
OP_TRUE<br> | |||
Let '''M'''<sub>k</sub> = '''m'''/k be a key of a superuser that can authorize all transactions and {'''K'''<sub>k</sub>} be a key group of three users that can only authorize transactions if at least two of them agree. | |||
The ''k''th script is given by ''Script''('''M'''<sub>k</sub>, {'''K'''<sub>k</sub>}). | |||
===Timelocked Contract=== | |||
The output is payable to Alice immediately if she knows the private key for '''A'''<sub>k</sub>. Bob must know the private key for '''B'''<sub>k</sub> and also wait for a timeout '''t''' before being able to spend the output. | |||
The script template is defined by: | |||
''Script''('''A''', '''B''', '''T''') = <br> | |||
OP_IF <br> | |||
OP_DUP OP_HASH160 [''Hash160''('''A''')] OP_EQUALVERIFY OP_CHECKSIG <br> | |||
OP_ELSE <br> | |||
['''T'''] OP_CHECKLOCKTIMEVERIFY OP_DROP <br> | |||
OP_DUP OP_HASH160 [''Hash160''('''B''')] OP_EQUALVERIFY OP_CHECKSIG <br> | |||
OP_ENDIF | |||
The ''k''th script with timeout '''t''' is given by ''Script''('''A'''<sub>k</sub>, '''B'''<sub>k</sub>, '''t'''). | |||
==References== | |||
* [[bip-0016.mediawiki|BIP16 - Pay to Script Hash]] | |||
* [[bip-0032.mediawiki|BIP32 - Hierarchical Deterministic Wallets]] | |||
* [[bip-0065.mediawiki|BIP65 - OP_CHECKLOCKTIMEVERIFY]] | |||
* [[bip-0112.mediawiki|BIP112 - CHECKSEQUENCEVERIFY]] | |||
* [[https://lightning.network/lightning-network-paper.pdf|Lightning Network Whitepaper]] | |||
==Copyright== | |||
This document is placed in the public domain. |
Latest revision as of 10:12, 1 January 2021
This page describes a BIP (Bitcoin Improvement Proposal). |
Please do not modify this page. This is a mirror of the BIP from the source Git repository here. |
BIP: 124 Layer: Applications Title: Hierarchical Deterministic Script Templates Author: Eric Lombrozo <eric@ciphrex.com> William Swanson <swansontec@gmail.com> Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0124 Status: Rejected Type: Informational Created: 2015-11-20 License: PD Post-History: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-November/011795.html
Abstract
This BIP defines a script template format that can be used by wallets to deterministically generate scripts with specific authorization policies using the key derivation mechanism defined in BIP32.
Motivation
Currently existing wallets typically issue scripts in only a tiny handful of widely used formats. The most popular formats are pay-to-pubkey-hash and m-of-n pay-to-script-hash (BIP16). However, different wallets tend to use mutually incompatible derivation schemes to generate signing keys and construct scripts from them. Moreover, with the advent of hashlocked and timelocked contracts (BIP65, BIP112), it is necessary for different wallets to be able to cooperatively generate even more sophisticated scripts.
In addition, there's a lot of ongoing work in the development of multilayered protocols that use the blockchain as a settlement layer (i.e. the Lightning Network). These efforts require sufficiently generalized templates to allow for rapidly evolving script designs.
This BIP provides a generalized format for constructing a script template that guarantees that different wallets will all produce the same scripts for a given set of derivation paths according to BIP32.
Specification
Keys
An individual key is determined by a BIP32 derivation path and an index. For convenience, we introduce the following notation:
Ak = (derivation path for A)/k
Key Groups
Let mi denote distinct BIP32 derivation paths. We define a key group of n keys as a set of key derivation paths with a free index k:
{Kk} = { m1/k, m2/k, m3/k, ..., mn/k }
Key groups are useful for constructing scripts that are symmetric in a set of keys. Scripts are symmetric in a set of keys if the semantics of the script is unaffected by permutations of the keys. Key groups enforce a canonical form and can improve privacy.
Sorting
We define a lexicographic sorting of the keys. (TODO: specification of sorting conventions - compressed pubkeys, encoding, etc...)
Define {Kk}j to be the jth element of the sorted keys for derivation index k.
Script Templates
We construct script templates by inserting placeholders for data into a script. To denote a placeholder, we use the following notation:
Script(A) = opcodes [A] opcodes
We extend this notation to an arbitrary number of placeholders:
Script(X1, X2, ..., Xn) = opcodes [X1] opcodes [X2] opcodes ... opcodes [Xn] opcodes
We introduce the following convenient notation for sorted key groups:
[{Kk}] = [{Kk}1] [{Kk}2] ... [{Kk}n]
Operations on Keys
In some applications, we might want to insert the result of some operation performed on a key rather than the key itself into the script. For example, we might want to insert a Hash160 of key Ak. We can use the following notation:
[Hash160(Ak)]
Encoding
TODO
Examples
2-of-3 Multisig
The script template is defined by:
Script(X) = 2 [X] 3 OP_CHECKMULTISIG
Letting Kk = { m1/k, m2/k, m3/k }, the kth script for this key group is denoted by Script({Kk}).
1-of-1 or 2-of-3
The script template is defined by:
Script(A, B) =
OP_DUP [A] OP_CHECKSIG
OP_NOTIF
2 [B] 3 OP_CHECKMULTISIGVERIFY
OP_NOTIF
OP_ENDIF
OP_TRUE
Let Mk = m/k be a key of a superuser that can authorize all transactions and {Kk} be a key group of three users that can only authorize transactions if at least two of them agree.
The kth script is given by Script(Mk, {Kk}).
Timelocked Contract
The output is payable to Alice immediately if she knows the private key for Ak. Bob must know the private key for Bk and also wait for a timeout t before being able to spend the output.
The script template is defined by:
Script(A, B, T) =
OP_IF
OP_DUP OP_HASH160 [Hash160(A)] OP_EQUALVERIFY OP_CHECKSIG
OP_ELSE
[T] OP_CHECKLOCKTIMEVERIFY OP_DROP
OP_DUP OP_HASH160 [Hash160(B)] OP_EQUALVERIFY OP_CHECKSIG
OP_ENDIF
The kth script with timeout t is given by Script(Ak, Bk, t).
References
- BIP16 - Pay to Script Hash
- BIP32 - Hierarchical Deterministic Wallets
- BIP65 - OP_CHECKLOCKTIMEVERIFY
- BIP112 - CHECKSEQUENCEVERIFY
- [Network Whitepaper]
Copyright
This document is placed in the public domain.