+
+
-%3
-
+
DEFINED
@@ -16,7 +15,7 @@
DEFINED
-
+
DEFINED:sw->DEFINED:nw
@@ -32,10 +31,10 @@
DEFINED->STARTED
-height >= start_height
+height >= start_height
-
+
STARTED:sw->STARTED:nw
@@ -43,15 +42,15 @@
MUST_SIGNAL
-
-MUST_SIGNAL
+
+MUST_SIGNAL
STARTED->MUST_SIGNAL
-
-
-height + 2016 >= timeoutheight AND lockinontimeout
+
+
+height + 2016 >= timeoutheight AND lockinontimeout
@@ -64,57 +63,64 @@
STARTED->FAILED
-height >= timeoutheight
-AND
-NOT lockinontimeout
+height >= timeoutheight
+AND
+NOT lockinontimeout
LOCKED_IN
-
-LOCKED_IN
+
+LOCKED_IN
-
+
STARTED->LOCKED_IN
-
-
-height < timeoutheight
-AND
-threshold reached
+
+
+height < timeoutheight
+AND
+threshold reached
-
+
MUST_SIGNAL->LOCKED_IN
-
-
-always
+
+
+always
-
+
FAILED:sw->FAILED:nw
+
+
+LOCKED_IN:se->LOCKED_IN:ne
+
+
+height < minimum_activation_height
+
ACTIVE
-
-ACTIVE
+
+ACTIVE
LOCKED_IN->ACTIVE
-
-
-always
+
+
+height >= minimum_activation_height
-
+
ACTIVE:sw->ACTIVE:nw
-
-
+
+
diff --git a/bip-0009.mediawiki b/bip-0009.mediawiki
index f90919a8..f7fbad1c 100644
--- a/bip-0009.mediawiki
+++ b/bip-0009.mediawiki
@@ -19,9 +19,9 @@ This document specifies a proposed change to the semantics of the 'version' fiel
==Motivation==
-BIP 34 introduced a mechanism for doing soft-forking changes without a predefined flag timestamp (or flag block height), instead relying on measuring miner support indicated by a higher version number in block headers. As it relies on comparing version numbers as integers however, it only supports one single change being rolled out at once, requiring coordination between proposals, and does not allow for permanent rejection: as long as one soft fork is not fully rolled out, no future one can be scheduled.
+[[bip-0034.mediawiki|BIP 34]] introduced a mechanism for doing soft-forking changes without a predefined flag timestamp (or flag block height), instead relying on measuring miner support indicated by a higher version number in block headers. As it relies on comparing version numbers as integers however, it only supports one single change being rolled out at once, requiring coordination between proposals, and does not allow for permanent rejection: as long as one soft fork is not fully rolled out, no future one can be scheduled.
-In addition, BIP 34 made the integer comparison (nVersion >= 2) a consensus rule after its 95% threshold was reached, removing 231 +2 values from the set of valid version numbers (all negative numbers, as nVersion is interpreted as a signed integer, as well as 0 and 1). This indicates another downside this approach: every upgrade permanently restricts the set of allowed nVersion field values. This approach was later reused in BIP 66 and BIP 65, which further removed nVersions 2 and 3 as valid options. As will be shown further, this is unnecessary.
+In addition, BIP 34 made the integer comparison (nVersion >= 2) a consensus rule after its 95% threshold was reached, removing 231 +2 values from the set of valid version numbers (all negative numbers, as nVersion is interpreted as a signed integer, as well as 0 and 1). This indicates another downside this approach: every upgrade permanently restricts the set of allowed nVersion field values. This approach was later reused in [[bip-0066.mediawiki|BIP 66]] and [[bip-0065.mediawiki|BIP 65]], which further removed nVersions 2 and 3 as valid options. As will be shown further, this is unnecessary.
==Specification==
@@ -195,9 +195,9 @@ If versionbits is being used, "version" MUST be within the versionbits range of
Miners MAY clear or set bits in the block version WITHOUT any special "mutable" key, provided they are listed among the template's "vbavailable" and (when clearing is desired) NOT included as a bit in "vbrequired".
Softfork deployment names listed in "rules" or as keys in "vbavailable" may be prefixed by a '!' character.
-Without this prefix, GBT clients may assume the rule will not impact usage of the template as-is; typical examples of this would be when previously valid transactions cease to be valid, such as BIPs 16, 65, 66, 68, 112, and 113.
+Without this prefix, GBT clients may assume the rule will not impact usage of the template as-is; typical examples of this would be when previously valid transactions cease to be valid, such as BIPs [[bip-0016.mediawiki|16]], [[bip-0065.mediawiki|65]], [[bip-0066.mediawiki|66]], [[bip-0068.mediawiki|68]], [[bip-0112.mediawiki|112]], and [[bip-0113.mediawiki|113]].
If a client does not understand a rule without the prefix, it may use it unmodified for mining.
-On the other hand, when this prefix is used, it indicates a more subtle change to the block structure or generation transaction; examples of this would be BIP 34 (because it modifies coinbase construction) and 141 (since it modifies the txid hashing and adds a commitment to the generation transaction).
+On the other hand, when this prefix is used, it indicates a more subtle change to the block structure or generation transaction; examples of this would be [[bip-0034.mediawiki|BIP 34]] (because it modifies coinbase construction) and [[bip-0141.mediawiki|141]] (since it modifies the txid hashing and adds a commitment to the generation transaction).
A client that does not understand a rule prefixed by '!' must not attempt to process the template, and must not attempt to use it for mining even unmodified.
==Support for future changes==
@@ -205,7 +205,7 @@ A client that does not understand a rule prefixed by '!' must not attempt to pro
The mechanism described above is very generic, and variations are possible for future soft forks. Here are some ideas that can be taken into account.
'''Modified thresholds'''
-The 1916 threshold (based on in BIP 34's 95%) does not have to be maintained for eternity, but changes should take the effect on the warning system into account. In particular, having a lock-in threshold that is incompatible with the one used for the warning system may have long-term effects, as the warning system cannot rely on a permanently detectable condition anymore.
+The 1916 threshold (based on BIP 34's 95%) does not have to be maintained for eternity, but changes should take the effect on the warning system into account. In particular, having a lock-in threshold that is incompatible with the one used for the warning system may have long-term effects, as the warning system cannot rely on a permanently detectable condition anymore.
'''Conflicting soft forks'''
At some point, two mutually exclusive soft forks may be proposed. The naive way to deal with this is to never create software that implements both, but that is making a bet that at least one side is guaranteed to lose. Better would be to encode "soft fork X cannot be locked-in" as consensus rule for the conflicting soft fork - allowing software that supports both, but can never trigger conflicting changes.
diff --git a/bip-0021.mediawiki b/bip-0021.mediawiki
index cfab8564..0fba9bcf 100644
--- a/bip-0021.mediawiki
+++ b/bip-0021.mediawiki
@@ -58,10 +58,9 @@ The scheme component ("bitcoin:") is case-insensitive, and implementations must
*label: Label for that address (e.g. name of receiver)
*address: bitcoin address
*message: message that describes the transaction to the user ([[#Examples|see examples below]])
-*size: amount of base bitcoin units ([[#Transfer amount/size|see below]])
*(others): optional, for future extensions
-==== Transfer amount/size ====
+==== Transfer amount ====
If an amount is provided, it MUST be specified in decimal BTC.
All amounts MUST contain no commas and use a period (.) as the separating character to separate whole numbers and decimal fractions.
diff --git a/bip-0032.mediawiki b/bip-0032.mediawiki
index bec5fb0f..7a4ae84a 100644
--- a/bip-0032.mediawiki
+++ b/bip-0032.mediawiki
@@ -4,6 +4,7 @@ RECENT CHANGES:
* (25 May 2013) Added test vectors
* (15 Jan 2014) Rename keys with index ≥ 0x80000000 to hardened keys, and add explicit conversion functions.
* (24 Feb 2017) Added test vectors for hardened derivation with leading zeros
+* (4 Nov 2020) Added new test vectors for hardened derivation with leading zeros
BIP: 32
@@ -118,7 +119,7 @@ To shorten notation, we will write CKDpriv(CKDpriv(CKDpriv(m,3H ),2),5
* N(m/aH /b/c) = N(m/aH /b)/c = N(m/aH )/b/c.
However, N(m/aH ) cannot be rewritten as N(m)/aH , as the latter is not possible.
-Each leaf node in the tree corresponds to an actual key, while the internal nodes correspond to the collections of keys that descend from them. The chain codes of the leaf nodes are ignored, and only their embedded private or public key is relevant. Because of this construction, knowing an extended private key allows reconstruction of all descendant private keys and public keys, and knowing an extended public keys allows reconstruction of all descendant non-hardened public keys.
+Each leaf node in the tree corresponds to an actual key, while the internal nodes correspond to the collections of keys that descend from them. The chain codes of the leaf nodes are ignored, and only their embedded private or public key is relevant. Because of this construction, knowing an extended private key allows reconstruction of all descendant private keys and public keys, and knowing an extended public key allows reconstruction of all descendant non-hardened public keys.
===Key identifiers===
@@ -274,7 +275,22 @@ Seed (hex): 4b381541583be4423346c643850da4b320e46a87ae3d2a4e6da11eba819cd4acba45
===Test vector 4===
-This vector tests that invalid extended keys are recognized as invalid.
+These vectors test for the retention of leading zeros. See [https://github.com/btcsuite/btcutil/issues/172 btcsuite/btcutil#172] for more information.
+
+Seed (hex): 3ddd5602285899a946114506157c7997e5444528f3003f6134712147db19b678
+* Chain m
+** ext pub: xpub661MyMwAqRbcGczjuMoRm6dXaLDEhW1u34gKenbeYqAix21mdUKJyuyu5F1rzYGVxyL6tmgBUAEPrEz92mBXjByMRiJdba9wpnN37RLLAXa
+** ext prv: xprv9s21ZrQH143K48vGoLGRPxgo2JNkJ3J3fqkirQC2zVdk5Dgd5w14S7fRDyHH4dWNHUgkvsvNDCkvAwcSHNAQwhwgNMgZhLtQC63zxwhQmRv
+* Chain m/0H
+** ext pub: xpub69AUMk3qDBi3uW1sXgjCmVjJ2G6WQoYSnNHyzkmdCHEhSZ4tBok37xfFEqHd2AddP56Tqp4o56AePAgCjYdvpW2PU2jbUPFKsav5ut6Ch1m
+** ext prv: xprv9vB7xEWwNp9kh1wQRfCCQMnZUEG21LpbR9NPCNN1dwhiZkjjeGRnaALmPXCX7SgjFTiCTT6bXes17boXtjq3xLpcDjzEuGLQBM5ohqkao9G
+* Chain m/0H /1H
+** ext pub: xpub6BJA1jSqiukeaesWfxe6sNK9CCGaujFFSJLomWHprUL9DePQ4JDkM5d88n49sMGJxrhpjazuXYWdMf17C9T5XnxkopaeS7jGk1GyyVziaMt
+** ext prv: xprv9xJocDuwtYCMNAo3Zw76WENQeAS6WGXQ55RCy7tDJ8oALr4FWkuVoHJeHVAcAqiZLE7Je3vZJHxspZdFHfnBEjHqU5hG1Jaj32dVoS6XLT1
+
+===Test vector 5===
+
+These vectors test that invalid extended keys are recognized as invalid.
* xpub661MyMwAqRbcEYS8w7XLSVeEsBXy79zSzH1J8vCdxAZningWLdN3zgtU6LBpB85b3D2yc8sfvZU521AAwdZafEz7mnzBBsz4wKY5fTtTQBm (pubkey version / prvkey mismatch)
* xprv9s21ZrQH143K24Mfq5zL5MhWK9hUhhGbd45hLXo2Pq2oqzMMo63oStZzFGTQQD3dC4H2D5GBj7vWvSQaaBv5cxi9gafk7NF3pnBju6dwKvH (prvkey version / pubkey mismatch)
diff --git a/bip-0034.mediawiki b/bip-0034.mediawiki
index a993b7e7..88073c5c 100644
--- a/bip-0034.mediawiki
+++ b/bip-0034.mediawiki
@@ -22,7 +22,7 @@ Bitcoin blocks and transactions are versioned binary structures. Both currently
==Specification==
# Treat transactions with a version greater than 1 as non-standard (official Satoshi client will not mine or relay them).
-# Add height as the first item in the coinbase transaction's scriptSig, and increase block version to 2. The format of the height is "serialized CScript" -- first byte is number of bytes in the number (will be 0x03 on main net for the next 150 or so years with 223 -1 blocks), following bytes are little-endian representation of the number (including a sign bit). Height is the height of the mined block in the block chain, where the genesis block is height zero (0).
+# Add height as the first item in the coinbase transaction's scriptSig, and increase block version to 2. The format of the height is "minimally encoded serialized CScript" -- first byte is number of bytes in the number (will be 0x03 on main net for the next 150 or so years with 223 -1 blocks), following bytes are little-endian representation of the number (including a sign bit). Height is the height of the mined block in the block chain, where the genesis block is height zero (0).
# 75% rule: If 750 of the last 1,000 blocks are version 2 or greater, reject invalid version 2 blocks. (testnet3: 51 of last 100)
# 95% rule ("Point of no return"): If 950 of the last 1,000 blocks are version 2 or greater, reject all version 1 blocks. (testnet3: 75 of last 100)
diff --git a/bip-0039.mediawiki b/bip-0039.mediawiki
index c5ab9bb9..4ac3c556 100644
--- a/bip-0039.mediawiki
+++ b/bip-0039.mediawiki
@@ -113,7 +113,14 @@ will make the desired wallet available.
==Wordlists==
-* [[bip-0039/bip-0039-wordlists.md|Moved to separate document]]
+Since the vast majority of BIP39 wallets supports only the English wordlist,
+it is '''strongly discouraged''' to use non-English wordlists for generating
+the mnemonic sentences.
+
+If you still feel your application really needs to use a localized wordlist,
+use one of the following instead of inventing your own.
+
+* [[bip-0039/bip-0039-wordlists.md|Wordlists]]
==Test vectors==
@@ -137,6 +144,9 @@ http://github.com/trezor/python-mnemonic
Go:
* https://github.com/tyler-smith/go-bip39
+Python:
+* https://github.com/meherett/python-hdwallet
+
Elixir:
* https://github.com/aerosol/mnemo
@@ -153,7 +163,7 @@ Haskell:
* https://github.com/NicolasDorier/NBitcoin
JavaScript:
-* https://github.com/bitpay/bitcore-mnemonic
+* https://github.com/bitpay/bitcore/tree/master/packages/bitcore-mnemonic
* https://github.com/bitcoinjs/bip39 (used by [[https://github.com/blockchain/My-Wallet-V3/blob/v3.8.0/src/hd-wallet.js#L121-L146|blockchain.info]])
Java:
@@ -164,6 +174,10 @@ Ruby:
Rust:
* https://github.com/maciejhirsz/tiny-bip39/
+* https://github.com/koushiro/bip0039-rs
+
+Smalltalk:
+* https://github.com/eMaringolo/pharo-bip39mnemonic
Swift:
* https://github.com/CikeQiu/CKMnemonic
@@ -177,3 +191,6 @@ C++:
C (with Python/Java/Javascript bindings):
* https://github.com/ElementsProject/libwally-core
+
+Python:
+* https://github.com/scgbckbone/btc-hd-wallet
diff --git a/bip-0039/bip-0039-wordlists.md b/bip-0039/bip-0039-wordlists.md
index 589ceab3..f2c173c5 100644
--- a/bip-0039/bip-0039-wordlists.md
+++ b/bip-0039/bip-0039-wordlists.md
@@ -9,6 +9,7 @@
* [French](french.txt)
* [Italian](italian.txt)
* [Czech](czech.txt)
+* [Portuguese](portuguese.txt)
## Wordlists (Special Considerations)
@@ -98,3 +99,19 @@ Words chosen using the following rules:
6. No very similar words with 1 letter of difference.
7. Words are sorting according English alphabet (Czech sorting has difference in "ch").
8. No words already used in other language mnemonic sets (english, italian, french, spanish). Letters with diacritical marks from these sets are counted as analogous letters without diacritical marks.
+
+### Portuguese
+
+Credits: @alegotardo @bitmover-studio @brenorb @kuthullu @ninjastic @sabotag3x @Trimegistus
+
+1. Words can be uniquely determined typing the first 4 characters.
+2. No accents or special characters.
+3. No complex verb forms.
+4. No plural words, unless there's no singular form.
+5. No words with double spelling.
+6. No words with the exact sound of another word with different spelling.
+7. No offensive words.
+8. No words already used in other language mnemonic sets.
+9. The words which have not the same spelling in Brazil and in Portugal are excluded.
+10. No words that remind negative/sad/bad things.
+11. No very similar words with 1 letter of difference.
diff --git a/bip-0039/portuguese.txt b/bip-0039/portuguese.txt
new file mode 100644
index 00000000..4a891055
--- /dev/null
+++ b/bip-0039/portuguese.txt
@@ -0,0 +1,2048 @@
+abacate
+abaixo
+abalar
+abater
+abduzir
+abelha
+aberto
+abismo
+abotoar
+abranger
+abreviar
+abrigar
+abrupto
+absinto
+absoluto
+absurdo
+abutre
+acabado
+acalmar
+acampar
+acanhar
+acaso
+aceitar
+acelerar
+acenar
+acervo
+acessar
+acetona
+achatar
+acidez
+acima
+acionado
+acirrar
+aclamar
+aclive
+acolhida
+acomodar
+acoplar
+acordar
+acumular
+acusador
+adaptar
+adega
+adentro
+adepto
+adequar
+aderente
+adesivo
+adeus
+adiante
+aditivo
+adjetivo
+adjunto
+admirar
+adorar
+adquirir
+adubo
+adverso
+advogado
+aeronave
+afastar
+aferir
+afetivo
+afinador
+afivelar
+aflito
+afluente
+afrontar
+agachar
+agarrar
+agasalho
+agenciar
+agilizar
+agiota
+agitado
+agora
+agradar
+agreste
+agrupar
+aguardar
+agulha
+ajoelhar
+ajudar
+ajustar
+alameda
+alarme
+alastrar
+alavanca
+albergue
+albino
+alcatra
+aldeia
+alecrim
+alegria
+alertar
+alface
+alfinete
+algum
+alheio
+aliar
+alicate
+alienar
+alinhar
+aliviar
+almofada
+alocar
+alpiste
+alterar
+altitude
+alucinar
+alugar
+aluno
+alusivo
+alvo
+amaciar
+amador
+amarelo
+amassar
+ambas
+ambiente
+ameixa
+amenizar
+amido
+amistoso
+amizade
+amolador
+amontoar
+amoroso
+amostra
+amparar
+ampliar
+ampola
+anagrama
+analisar
+anarquia
+anatomia
+andaime
+anel
+anexo
+angular
+animar
+anjo
+anomalia
+anotado
+ansioso
+anterior
+anuidade
+anunciar
+anzol
+apagador
+apalpar
+apanhado
+apego
+apelido
+apertada
+apesar
+apetite
+apito
+aplauso
+aplicada
+apoio
+apontar
+aposta
+aprendiz
+aprovar
+aquecer
+arame
+aranha
+arara
+arcada
+ardente
+areia
+arejar
+arenito
+aresta
+argiloso
+argola
+arma
+arquivo
+arraial
+arrebate
+arriscar
+arroba
+arrumar
+arsenal
+arterial
+artigo
+arvoredo
+asfaltar
+asilado
+aspirar
+assador
+assinar
+assoalho
+assunto
+astral
+atacado
+atadura
+atalho
+atarefar
+atear
+atender
+aterro
+ateu
+atingir
+atirador
+ativo
+atoleiro
+atracar
+atrevido
+atriz
+atual
+atum
+auditor
+aumentar
+aura
+aurora
+autismo
+autoria
+autuar
+avaliar
+avante
+avaria
+avental
+avesso
+aviador
+avisar
+avulso
+axila
+azarar
+azedo
+azeite
+azulejo
+babar
+babosa
+bacalhau
+bacharel
+bacia
+bagagem
+baiano
+bailar
+baioneta
+bairro
+baixista
+bajular
+baleia
+baliza
+balsa
+banal
+bandeira
+banho
+banir
+banquete
+barato
+barbado
+baronesa
+barraca
+barulho
+baseado
+bastante
+batata
+batedor
+batida
+batom
+batucar
+baunilha
+beber
+beijo
+beirada
+beisebol
+beldade
+beleza
+belga
+beliscar
+bendito
+bengala
+benzer
+berimbau
+berlinda
+berro
+besouro
+bexiga
+bezerro
+bico
+bicudo
+bienal
+bifocal
+bifurcar
+bigorna
+bilhete
+bimestre
+bimotor
+biologia
+biombo
+biosfera
+bipolar
+birrento
+biscoito
+bisneto
+bispo
+bissexto
+bitola
+bizarro
+blindado
+bloco
+bloquear
+boato
+bobagem
+bocado
+bocejo
+bochecha
+boicotar
+bolada
+boletim
+bolha
+bolo
+bombeiro
+bonde
+boneco
+bonita
+borbulha
+borda
+boreal
+borracha
+bovino
+boxeador
+branco
+brasa
+braveza
+breu
+briga
+brilho
+brincar
+broa
+brochura
+bronzear
+broto
+bruxo
+bucha
+budismo
+bufar
+bule
+buraco
+busca
+busto
+buzina
+cabana
+cabelo
+cabide
+cabo
+cabrito
+cacau
+cacetada
+cachorro
+cacique
+cadastro
+cadeado
+cafezal
+caiaque
+caipira
+caixote
+cajado
+caju
+calafrio
+calcular
+caldeira
+calibrar
+calmante
+calota
+camada
+cambista
+camisa
+camomila
+campanha
+camuflar
+canavial
+cancelar
+caneta
+canguru
+canhoto
+canivete
+canoa
+cansado
+cantar
+canudo
+capacho
+capela
+capinar
+capotar
+capricho
+captador
+capuz
+caracol
+carbono
+cardeal
+careca
+carimbar
+carneiro
+carpete
+carreira
+cartaz
+carvalho
+casaco
+casca
+casebre
+castelo
+casulo
+catarata
+cativar
+caule
+causador
+cautelar
+cavalo
+caverna
+cebola
+cedilha
+cegonha
+celebrar
+celular
+cenoura
+censo
+centeio
+cercar
+cerrado
+certeiro
+cerveja
+cetim
+cevada
+chacota
+chaleira
+chamado
+chapada
+charme
+chatice
+chave
+chefe
+chegada
+cheiro
+cheque
+chicote
+chifre
+chinelo
+chocalho
+chover
+chumbo
+chutar
+chuva
+cicatriz
+ciclone
+cidade
+cidreira
+ciente
+cigana
+cimento
+cinto
+cinza
+ciranda
+circuito
+cirurgia
+citar
+clareza
+clero
+clicar
+clone
+clube
+coado
+coagir
+cobaia
+cobertor
+cobrar
+cocada
+coelho
+coentro
+coeso
+cogumelo
+coibir
+coifa
+coiote
+colar
+coleira
+colher
+colidir
+colmeia
+colono
+coluna
+comando
+combinar
+comentar
+comitiva
+comover
+complexo
+comum
+concha
+condor
+conectar
+confuso
+congelar
+conhecer
+conjugar
+consumir
+contrato
+convite
+cooperar
+copeiro
+copiador
+copo
+coquetel
+coragem
+cordial
+corneta
+coronha
+corporal
+correio
+cortejo
+coruja
+corvo
+cosseno
+costela
+cotonete
+couro
+couve
+covil
+cozinha
+cratera
+cravo
+creche
+credor
+creme
+crer
+crespo
+criada
+criminal
+crioulo
+crise
+criticar
+crosta
+crua
+cruzeiro
+cubano
+cueca
+cuidado
+cujo
+culatra
+culminar
+culpar
+cultura
+cumprir
+cunhado
+cupido
+curativo
+curral
+cursar
+curto
+cuspir
+custear
+cutelo
+damasco
+datar
+debater
+debitar
+deboche
+debulhar
+decalque
+decimal
+declive
+decote
+decretar
+dedal
+dedicado
+deduzir
+defesa
+defumar
+degelo
+degrau
+degustar
+deitado
+deixar
+delator
+delegado
+delinear
+delonga
+demanda
+demitir
+demolido
+dentista
+depenado
+depilar
+depois
+depressa
+depurar
+deriva
+derramar
+desafio
+desbotar
+descanso
+desenho
+desfiado
+desgaste
+desigual
+deslize
+desmamar
+desova
+despesa
+destaque
+desviar
+detalhar
+detentor
+detonar
+detrito
+deusa
+dever
+devido
+devotado
+dezena
+diagrama
+dialeto
+didata
+difuso
+digitar
+dilatado
+diluente
+diminuir
+dinastia
+dinheiro
+diocese
+direto
+discreta
+disfarce
+disparo
+disquete
+dissipar
+distante
+ditador
+diurno
+diverso
+divisor
+divulgar
+dizer
+dobrador
+dolorido
+domador
+dominado
+donativo
+donzela
+dormente
+dorsal
+dosagem
+dourado
+doutor
+drenagem
+drible
+drogaria
+duelar
+duende
+dueto
+duplo
+duquesa
+durante
+duvidoso
+eclodir
+ecoar
+ecologia
+edificar
+edital
+educado
+efeito
+efetivar
+ejetar
+elaborar
+eleger
+eleitor
+elenco
+elevador
+eliminar
+elogiar
+embargo
+embolado
+embrulho
+embutido
+emenda
+emergir
+emissor
+empatia
+empenho
+empinado
+empolgar
+emprego
+empurrar
+emulador
+encaixe
+encenado
+enchente
+encontro
+endeusar
+endossar
+enfaixar
+enfeite
+enfim
+engajado
+engenho
+englobar
+engomado
+engraxar
+enguia
+enjoar
+enlatar
+enquanto
+enraizar
+enrolado
+enrugar
+ensaio
+enseada
+ensino
+ensopado
+entanto
+enteado
+entidade
+entortar
+entrada
+entulho
+envergar
+enviado
+envolver
+enxame
+enxerto
+enxofre
+enxuto
+epiderme
+equipar
+ereto
+erguido
+errata
+erva
+ervilha
+esbanjar
+esbelto
+escama
+escola
+escrita
+escuta
+esfinge
+esfolar
+esfregar
+esfumado
+esgrima
+esmalte
+espanto
+espelho
+espiga
+esponja
+espreita
+espumar
+esquerda
+estaca
+esteira
+esticar
+estofado
+estrela
+estudo
+esvaziar
+etanol
+etiqueta
+euforia
+europeu
+evacuar
+evaporar
+evasivo
+eventual
+evidente
+evoluir
+exagero
+exalar
+examinar
+exato
+exausto
+excesso
+excitar
+exclamar
+executar
+exemplo
+exibir
+exigente
+exonerar
+expandir
+expelir
+expirar
+explanar
+exposto
+expresso
+expulsar
+externo
+extinto
+extrato
+fabricar
+fabuloso
+faceta
+facial
+fada
+fadiga
+faixa
+falar
+falta
+familiar
+fandango
+fanfarra
+fantoche
+fardado
+farelo
+farinha
+farofa
+farpa
+fartura
+fatia
+fator
+favorita
+faxina
+fazenda
+fechado
+feijoada
+feirante
+felino
+feminino
+fenda
+feno
+fera
+feriado
+ferrugem
+ferver
+festejar
+fetal
+feudal
+fiapo
+fibrose
+ficar
+ficheiro
+figurado
+fileira
+filho
+filme
+filtrar
+firmeza
+fisgada
+fissura
+fita
+fivela
+fixador
+fixo
+flacidez
+flamingo
+flanela
+flechada
+flora
+flutuar
+fluxo
+focal
+focinho
+fofocar
+fogo
+foguete
+foice
+folgado
+folheto
+forjar
+formiga
+forno
+forte
+fosco
+fossa
+fragata
+fralda
+frango
+frasco
+fraterno
+freira
+frente
+fretar
+frieza
+friso
+fritura
+fronha
+frustrar
+fruteira
+fugir
+fulano
+fuligem
+fundar
+fungo
+funil
+furador
+furioso
+futebol
+gabarito
+gabinete
+gado
+gaiato
+gaiola
+gaivota
+galega
+galho
+galinha
+galocha
+ganhar
+garagem
+garfo
+gargalo
+garimpo
+garoupa
+garrafa
+gasoduto
+gasto
+gata
+gatilho
+gaveta
+gazela
+gelado
+geleia
+gelo
+gemada
+gemer
+gemido
+generoso
+gengiva
+genial
+genoma
+genro
+geologia
+gerador
+germinar
+gesso
+gestor
+ginasta
+gincana
+gingado
+girafa
+girino
+glacial
+glicose
+global
+glorioso
+goela
+goiaba
+golfe
+golpear
+gordura
+gorjeta
+gorro
+gostoso
+goteira
+governar
+gracejo
+gradual
+grafite
+gralha
+grampo
+granada
+gratuito
+graveto
+graxa
+grego
+grelhar
+greve
+grilo
+grisalho
+gritaria
+grosso
+grotesco
+grudado
+grunhido
+gruta
+guache
+guarani
+guaxinim
+guerrear
+guiar
+guincho
+guisado
+gula
+guloso
+guru
+habitar
+harmonia
+haste
+haver
+hectare
+herdar
+heresia
+hesitar
+hiato
+hibernar
+hidratar
+hiena
+hino
+hipismo
+hipnose
+hipoteca
+hoje
+holofote
+homem
+honesto
+honrado
+hormonal
+hospedar
+humorado
+iate
+ideia
+idoso
+ignorado
+igreja
+iguana
+ileso
+ilha
+iludido
+iluminar
+ilustrar
+imagem
+imediato
+imenso
+imersivo
+iminente
+imitador
+imortal
+impacto
+impedir
+implante
+impor
+imprensa
+impune
+imunizar
+inalador
+inapto
+inativo
+incenso
+inchar
+incidir
+incluir
+incolor
+indeciso
+indireto
+indutor
+ineficaz
+inerente
+infantil
+infestar
+infinito
+inflamar
+informal
+infrator
+ingerir
+inibido
+inicial
+inimigo
+injetar
+inocente
+inodoro
+inovador
+inox
+inquieto
+inscrito
+inseto
+insistir
+inspetor
+instalar
+insulto
+intacto
+integral
+intimar
+intocado
+intriga
+invasor
+inverno
+invicto
+invocar
+iogurte
+iraniano
+ironizar
+irreal
+irritado
+isca
+isento
+isolado
+isqueiro
+italiano
+janeiro
+jangada
+janta
+jararaca
+jardim
+jarro
+jasmim
+jato
+javali
+jazida
+jejum
+joaninha
+joelhada
+jogador
+joia
+jornal
+jorrar
+jovem
+juba
+judeu
+judoca
+juiz
+julgador
+julho
+jurado
+jurista
+juro
+justa
+labareda
+laboral
+lacre
+lactante
+ladrilho
+lagarta
+lagoa
+laje
+lamber
+lamentar
+laminar
+lampejo
+lanche
+lapidar
+lapso
+laranja
+lareira
+largura
+lasanha
+lastro
+lateral
+latido
+lavanda
+lavoura
+lavrador
+laxante
+lazer
+lealdade
+lebre
+legado
+legendar
+legista
+leigo
+leiloar
+leitura
+lembrete
+leme
+lenhador
+lentilha
+leoa
+lesma
+leste
+letivo
+letreiro
+levar
+leveza
+levitar
+liberal
+libido
+liderar
+ligar
+ligeiro
+limitar
+limoeiro
+limpador
+linda
+linear
+linhagem
+liquidez
+listagem
+lisura
+litoral
+livro
+lixa
+lixeira
+locador
+locutor
+lojista
+lombo
+lona
+longe
+lontra
+lorde
+lotado
+loteria
+loucura
+lousa
+louvar
+luar
+lucidez
+lucro
+luneta
+lustre
+lutador
+luva
+macaco
+macete
+machado
+macio
+madeira
+madrinha
+magnata
+magreza
+maior
+mais
+malandro
+malha
+malote
+maluco
+mamilo
+mamoeiro
+mamute
+manada
+mancha
+mandato
+manequim
+manhoso
+manivela
+manobrar
+mansa
+manter
+manusear
+mapeado
+maquinar
+marcador
+maresia
+marfim
+margem
+marinho
+marmita
+maroto
+marquise
+marreco
+martelo
+marujo
+mascote
+masmorra
+massagem
+mastigar
+matagal
+materno
+matinal
+matutar
+maxilar
+medalha
+medida
+medusa
+megafone
+meiga
+melancia
+melhor
+membro
+memorial
+menino
+menos
+mensagem
+mental
+merecer
+mergulho
+mesada
+mesclar
+mesmo
+mesquita
+mestre
+metade
+meteoro
+metragem
+mexer
+mexicano
+micro
+migalha
+migrar
+milagre
+milenar
+milhar
+mimado
+minerar
+minhoca
+ministro
+minoria
+miolo
+mirante
+mirtilo
+misturar
+mocidade
+moderno
+modular
+moeda
+moer
+moinho
+moita
+moldura
+moleza
+molho
+molinete
+molusco
+montanha
+moqueca
+morango
+morcego
+mordomo
+morena
+mosaico
+mosquete
+mostarda
+motel
+motim
+moto
+motriz
+muda
+muito
+mulata
+mulher
+multar
+mundial
+munido
+muralha
+murcho
+muscular
+museu
+musical
+nacional
+nadador
+naja
+namoro
+narina
+narrado
+nascer
+nativa
+natureza
+navalha
+navegar
+navio
+neblina
+nebuloso
+negativa
+negociar
+negrito
+nervoso
+neta
+neural
+nevasca
+nevoeiro
+ninar
+ninho
+nitidez
+nivelar
+nobreza
+noite
+noiva
+nomear
+nominal
+nordeste
+nortear
+notar
+noticiar
+noturno
+novelo
+novilho
+novo
+nublado
+nudez
+numeral
+nupcial
+nutrir
+nuvem
+obcecado
+obedecer
+objetivo
+obrigado
+obscuro
+obstetra
+obter
+obturar
+ocidente
+ocioso
+ocorrer
+oculista
+ocupado
+ofegante
+ofensiva
+oferenda
+oficina
+ofuscado
+ogiva
+olaria
+oleoso
+olhar
+oliveira
+ombro
+omelete
+omisso
+omitir
+ondulado
+oneroso
+ontem
+opcional
+operador
+oponente
+oportuno
+oposto
+orar
+orbitar
+ordem
+ordinal
+orfanato
+orgasmo
+orgulho
+oriental
+origem
+oriundo
+orla
+ortodoxo
+orvalho
+oscilar
+ossada
+osso
+ostentar
+otimismo
+ousadia
+outono
+outubro
+ouvido
+ovelha
+ovular
+oxidar
+oxigenar
+pacato
+paciente
+pacote
+pactuar
+padaria
+padrinho
+pagar
+pagode
+painel
+pairar
+paisagem
+palavra
+palestra
+palheta
+palito
+palmada
+palpitar
+pancada
+panela
+panfleto
+panqueca
+pantanal
+papagaio
+papelada
+papiro
+parafina
+parcial
+pardal
+parede
+partida
+pasmo
+passado
+pastel
+patamar
+patente
+patinar
+patrono
+paulada
+pausar
+peculiar
+pedalar
+pedestre
+pediatra
+pedra
+pegada
+peitoral
+peixe
+pele
+pelicano
+penca
+pendurar
+peneira
+penhasco
+pensador
+pente
+perceber
+perfeito
+pergunta
+perito
+permitir
+perna
+perplexo
+persiana
+pertence
+peruca
+pescado
+pesquisa
+pessoa
+petiscar
+piada
+picado
+piedade
+pigmento
+pilastra
+pilhado
+pilotar
+pimenta
+pincel
+pinguim
+pinha
+pinote
+pintar
+pioneiro
+pipoca
+piquete
+piranha
+pires
+pirueta
+piscar
+pistola
+pitanga
+pivete
+planta
+plaqueta
+platina
+plebeu
+plumagem
+pluvial
+pneu
+poda
+poeira
+poetisa
+polegada
+policiar
+poluente
+polvilho
+pomar
+pomba
+ponderar
+pontaria
+populoso
+porta
+possuir
+postal
+pote
+poupar
+pouso
+povoar
+praia
+prancha
+prato
+praxe
+prece
+predador
+prefeito
+premiar
+prensar
+preparar
+presilha
+pretexto
+prevenir
+prezar
+primata
+princesa
+prisma
+privado
+processo
+produto
+profeta
+proibido
+projeto
+prometer
+propagar
+prosa
+protetor
+provador
+publicar
+pudim
+pular
+pulmonar
+pulseira
+punhal
+punir
+pupilo
+pureza
+puxador
+quadra
+quantia
+quarto
+quase
+quebrar
+queda
+queijo
+quente
+querido
+quimono
+quina
+quiosque
+rabanada
+rabisco
+rachar
+racionar
+radial
+raiar
+rainha
+raio
+raiva
+rajada
+ralado
+ramal
+ranger
+ranhura
+rapadura
+rapel
+rapidez
+raposa
+raquete
+raridade
+rasante
+rascunho
+rasgar
+raspador
+rasteira
+rasurar
+ratazana
+ratoeira
+realeza
+reanimar
+reaver
+rebaixar
+rebelde
+rebolar
+recado
+recente
+recheio
+recibo
+recordar
+recrutar
+recuar
+rede
+redimir
+redonda
+reduzida
+reenvio
+refinar
+refletir
+refogar
+refresco
+refugiar
+regalia
+regime
+regra
+reinado
+reitor
+rejeitar
+relativo
+remador
+remendo
+remorso
+renovado
+reparo
+repelir
+repleto
+repolho
+represa
+repudiar
+requerer
+resenha
+resfriar
+resgatar
+residir
+resolver
+respeito
+ressaca
+restante
+resumir
+retalho
+reter
+retirar
+retomada
+retratar
+revelar
+revisor
+revolta
+riacho
+rica
+rigidez
+rigoroso
+rimar
+ringue
+risada
+risco
+risonho
+robalo
+rochedo
+rodada
+rodeio
+rodovia
+roedor
+roleta
+romano
+roncar
+rosado
+roseira
+rosto
+rota
+roteiro
+rotina
+rotular
+rouco
+roupa
+roxo
+rubro
+rugido
+rugoso
+ruivo
+rumo
+rupestre
+russo
+sabor
+saciar
+sacola
+sacudir
+sadio
+safira
+saga
+sagrada
+saibro
+salada
+saleiro
+salgado
+saliva
+salpicar
+salsicha
+saltar
+salvador
+sambar
+samurai
+sanar
+sanfona
+sangue
+sanidade
+sapato
+sarda
+sargento
+sarjeta
+saturar
+saudade
+saxofone
+sazonal
+secar
+secular
+seda
+sedento
+sediado
+sedoso
+sedutor
+segmento
+segredo
+segundo
+seiva
+seleto
+selvagem
+semanal
+semente
+senador
+senhor
+sensual
+sentado
+separado
+sereia
+seringa
+serra
+servo
+setembro
+setor
+sigilo
+silhueta
+silicone
+simetria
+simpatia
+simular
+sinal
+sincero
+singular
+sinopse
+sintonia
+sirene
+siri
+situado
+soberano
+sobra
+socorro
+sogro
+soja
+solda
+soletrar
+solteiro
+sombrio
+sonata
+sondar
+sonegar
+sonhador
+sono
+soprano
+soquete
+sorrir
+sorteio
+sossego
+sotaque
+soterrar
+sovado
+sozinho
+suavizar
+subida
+submerso
+subsolo
+subtrair
+sucata
+sucesso
+suco
+sudeste
+sufixo
+sugador
+sugerir
+sujeito
+sulfato
+sumir
+suor
+superior
+suplicar
+suposto
+suprimir
+surdina
+surfista
+surpresa
+surreal
+surtir
+suspiro
+sustento
+tabela
+tablete
+tabuada
+tacho
+tagarela
+talher
+talo
+talvez
+tamanho
+tamborim
+tampa
+tangente
+tanto
+tapar
+tapioca
+tardio
+tarefa
+tarja
+tarraxa
+tatuagem
+taurino
+taxativo
+taxista
+teatral
+tecer
+tecido
+teclado
+tedioso
+teia
+teimar
+telefone
+telhado
+tempero
+tenente
+tensor
+tentar
+termal
+terno
+terreno
+tese
+tesoura
+testado
+teto
+textura
+texugo
+tiara
+tigela
+tijolo
+timbrar
+timidez
+tingido
+tinteiro
+tiragem
+titular
+toalha
+tocha
+tolerar
+tolice
+tomada
+tomilho
+tonel
+tontura
+topete
+tora
+torcido
+torneio
+torque
+torrada
+torto
+tostar
+touca
+toupeira
+toxina
+trabalho
+tracejar
+tradutor
+trafegar
+trajeto
+trama
+trancar
+trapo
+traseiro
+tratador
+travar
+treino
+tremer
+trepidar
+trevo
+triagem
+tribo
+triciclo
+tridente
+trilogia
+trindade
+triplo
+triturar
+triunfal
+trocar
+trombeta
+trova
+trunfo
+truque
+tubular
+tucano
+tudo
+tulipa
+tupi
+turbo
+turma
+turquesa
+tutelar
+tutorial
+uivar
+umbigo
+unha
+unidade
+uniforme
+urologia
+urso
+urtiga
+urubu
+usado
+usina
+usufruir
+vacina
+vadiar
+vagaroso
+vaidoso
+vala
+valente
+validade
+valores
+vantagem
+vaqueiro
+varanda
+vareta
+varrer
+vascular
+vasilha
+vassoura
+vazar
+vazio
+veado
+vedar
+vegetar
+veicular
+veleiro
+velhice
+veludo
+vencedor
+vendaval
+venerar
+ventre
+verbal
+verdade
+vereador
+vergonha
+vermelho
+verniz
+versar
+vertente
+vespa
+vestido
+vetorial
+viaduto
+viagem
+viajar
+viatura
+vibrador
+videira
+vidraria
+viela
+viga
+vigente
+vigiar
+vigorar
+vilarejo
+vinco
+vinheta
+vinil
+violeta
+virada
+virtude
+visitar
+visto
+vitral
+viveiro
+vizinho
+voador
+voar
+vogal
+volante
+voleibol
+voltagem
+volumoso
+vontade
+vulto
+vuvuzela
+xadrez
+xarope
+xeque
+xeretar
+xerife
+xingar
+zangado
+zarpar
+zebu
+zelador
+zombar
+zoologia
+zumbido
diff --git a/bip-0048.mediawiki b/bip-0048.mediawiki
new file mode 100644
index 00000000..0b099b3f
--- /dev/null
+++ b/bip-0048.mediawiki
@@ -0,0 +1,251 @@
+
+ BIP: 48
+ Layer: Applications
+ Title: Multi-Script Hierarchy for Multi-Sig Wallets
+ Author: Fontaine
+ Comments-Summary: No comments
+ Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0048
+ Status: Proposed
+ Type: Standards Track
+ Created: 2020-12-16
+ License: MIT
+
+
+==Abstract==
+
+This BIP defines a logical hierarchy for deterministic multi-sig wallets based on an algorithm
+described in BIP-0067 (BIP67 from now on), BIP-0032 (BIP32 from now on), purpose scheme described in
+BIP-0043 (BIP43 from now on), and multi-account hierarchy described in
+BIP-0044 (BIP44 from now on).
+
+This BIP is a particular application of BIP43.
+
+==Copyright==
+
+This BIP falls under the MIT License.
+
+==Motivation==
+
+The motivation of this BIP is to define the existing industry wide practice of utilizing m/48'
+derivation paths in hierarchical deterministic multi-sig wallets so that other developers may
+benefit from a standard. This BIP allows for future script types to easily be appended to the
+specification so that a new BIP is not required for every future script type.
+
+The hierarchy proposed in this paper is quite comprehensive. It allows the handling of
+multiple accounts, external and internal chains per account, multiple script types and
+millions of addresses per chain.
+
+This paper was inspired from BIP44.
+
+==Backwards compatibility==
+
+Currently a number of wallets utilize the m/48'
derivation scheme for HD multi-sig accounts.
+This BIP is intended to maintain the *existing* real world use of the m/48'
derivation.
+No breaking changes are made so as to avoid "loss of funds" to existing users.
+Wallet's which currently support the m/48'
derivation will not need to make any changes
+to comply with this BIP.
+
+==Specification==
+
+===Key sorting===
+
+Any wallet that supports BIP48 inherently supports deterministic key sorting as per BIP67 so that all possible
+multi-signature addresses/scripts are derived from deterministically sorted public keys.
+
+===Path levels===
+
+We define the following 6 levels in BIP32 path:
+
+
+m / purpose' / coin_type' / account' / script_type' / change / address_index
+
+
+h
or '
in the path indicates that BIP32 hardened derivation is used.
+
+Each level has a special meaning, described in the chapters below.
+
+===Purpose===
+
+Purpose is a constant set to 48' following the BIP43 recommendation.
+It indicates that the subtree of this node is used according to this specification.
+
+Hardened derivation is used at this level.
+
+===Coin type===
+
+One master node (seed) can be used for multiple Bitcoin networks.
+Sharing the same space for various networks has some disadvantages.
+
+Avoiding reusing addresses across networks and improving privacy issues.
+
+Coin type 0
for mainnet and 1
for testnet.
+
+Hardened derivation is used at this level.
+
+===Account===
+
+This level splits the key space into independent user identities, following the BIP44 pattern,
+so the wallet never mixes the coins across different accounts.
+
+Users can use these accounts to organize the funds in the same
+fashion as bank accounts; for donation purposes (where all
+addresses are considered public), for saving purposes,
+for common expenses etc.
+
+Accounts are numbered from index 0 in sequentially increasing manner.
+This number is used as child index in BIP32 derivation.
+
+Hardened derivation is used at this level.
+
+===Script===
+
+This level splits the key space into two separate script_type
(s). To provide
+forward compatibility for future script types this specification can be easily extended.
+
+Currently the only script types covered by this BIP are Native Segwit (p2wsh) and
+Nested Segwit (p2sh-p2wsh).
+
+The following path represents Nested Segwit (p2sh-p2wsh) mainnet, account 0:
+1'
: Nested Segwit (p2sh-p2wsh) m/48'/0'/0'/1'
+
+The following path represents Native Segwit (p2wsh) mainnet, account 0:
+2'
: Native Segwit (p2wsh) m/48'/0'/0'/2'
+
+The recommended default for wallets is pay to witness script hash m/48'/0'/0'/2'
.
+
+To add new script types submit a PR to this specification and include it in the list above:
+X'
: Future script type m/48'/0'/0'/X'
+
+===Change===
+
+Constant 0 is used for external chain and constant 1 for internal chain (also
+known as change addresses). External chain is used for addresses that are meant
+to be visible outside of the wallet (e.g. for receiving payments). Internal
+chain is used for addresses which are not meant to be visible outside of the
+wallet and is used for return transaction change.
+
+Public derivation is used at this level.
+
+===Index===
+
+Addresses are numbered from index 0 in sequentially increasing manner.
+This number is used as child index in BIP32 derivation.
+
+Public derivation is used at this level.
+
+==Examples==
+
+{|
+|network
+|account
+|script
+|chain
+|address
+|path
+|-
+|mainnet
+|first
+|p2wsh
+|external
+|first
+|m / 48' / 0' / 0' / 2' / 0 / 0
+|-
+|mainnet
+|first
+|p2wsh
+|external
+|second
+|m / 48' / 0' / 0' / 2' / 0 / 1
+|-
+|mainnet
+|first
+|p2wsh
+|change
+|first
+|m / 48' / 0' / 0' / 2' / 1 / 0
+|-
+|mainnet
+|first
+|p2wsh
+|change
+|second
+|m / 48' / 0' / 0' / 2' / 1 / 1
+|-
+|mainnet
+|second
+|p2wsh
+|external
+|first
+|m / 48' / 0' / 1' / 2' / 0 / 0
+|-
+|mainnet
+|second
+|p2wsh
+|external
+|second
+|m / 48' / 0' / 1' / 2' / 0 / 1
+|-
+|testnet
+|first
+|p2sh-p2wsh
+|external
+|first
+|m / 48' / 1' / 0' / 1' / 0 / 0
+|-
+|testnet
+|first
+|p2wsh
+|external
+|second
+|m / 48' / 1' / 0' / 2' / 0 / 1
+|-
+|testnet
+|first
+|p2wsh
+|change
+|first
+|m / 48' / 1' / 0' / 2' / 1 / 0
+|-
+|testnet
+|first
+|p2wsh
+|change
+|second
+|m / 48' / 1' / 0' / 2' / 1 / 1
+|-
+|testnet
+|second
+|p2wsh
+|external
+|first
+|m / 48' / 1' / 1' / 2' / 0 / 0
+|-
+|testnet
+|second
+|p2wsh
+|external
+|second
+|m / 48' / 1' / 1' / 2' / 0 / 1
+|-
+|testnet
+|second
+|p2wsh
+|change
+|first
+|m / 48' / 1' / 1' / 2' / 1 / 0
+|-
+|testnet
+|second
+|p2wsh
+|change
+|second
+|m / 48' / 1' / 1' / 2' / 1 / 1
+|}
+
+
+==Reference==
+
+* [[bip-0067.mediawiki|BIP67 - Deterministic Pay-to-script-hash multi-signature addresses through public key sorting]]
+* [[bip-0032.mediawiki|BIP32 - Hierarchical Deterministic Wallets]]
+* [[bip-0043.mediawiki|BIP43 - Purpose Field for Deterministic Wallets]]
+* [[bip-0044.mediawiki|BIP44 - Multi-Account Hierarchy for Deterministic Wallets]]
diff --git a/bip-0078.mediawiki b/bip-0078.mediawiki
index c7953438..3c2fe2ef 100644
--- a/bip-0078.mediawiki
+++ b/bip-0078.mediawiki
@@ -209,7 +209,7 @@ In such case, the receiver will need to increase the fee of the transaction afte
* The sender's wallet software is using round fee rate.
If the sender's fee rate is always round, then a blockchain analyst can easily spot the transactions of the sender involving payjoin by checking if, when removing a single input to the suspected payjoin transaction, the resulting fee rate is round.
-To prevent this, the sender can agree to pay more more fee so the receiver make sure that the payjoin transaction fee is also round.
+To prevent this, the sender can agree to pay more fee so the receiver make sure that the payjoin transaction fee is also round.
* The sender's transaction is time sensitive.
@@ -249,7 +249,7 @@ The receiver needs to do some check on the original PSBT before proceeding:
===Sender's payjoin proposal checklist===
The sender should check the payjoin proposal before signing it to prevent a malicious receiver from stealing money.
-
+
* Verify that the absolute fee of the payjoin proposal is equals or higher than the original PSBT.
* If the receiver's BIP21 signalled pjos=0
, disable payment output substitution.
* Verify that the transaction version, and the nLockTime are unchanged.
@@ -272,7 +272,7 @@ The sender should check the payjoin proposal before signing it to prevent a mali
** If the output is the [[#fee-output|fee output]]:
*** The amount that was substracted from the output's value is less than or equal to maxadditionalfeecontribution
. Let's call this amount actual contribution
.
*** Make sure the actual contribution is only paying fee: The actual contribution
is less than or equals to the difference of absolute fee between the payjoin proposal and the original PSBT.
-*** Make sure the actual contribution is only paying for fee incurred by additional inputs: actual contribution
is less than or equals to originalPSBTFeeRate * vsize(sender_input_type) * (count(original_psbt_inputs) - count(payjoin_proposal_inputs))
. (see [[#fee-output|Fee output]] section)
+*** Make sure the actual contribution is only paying for fee incurred by additional inputs: actual contribution
is less than or equals to originalPSBTFeeRate * vsize(sender_input_type) * (count(payjoin_proposal_inputs) - count(original_psbt_inputs))
. (see [[#fee-output|Fee output]] section)
** If the output is the payment output and payment output substitution is allowed.
*** Do not make any check
** Else
@@ -325,7 +325,7 @@ Because the receiver needs to bump the fee to keep the same fee rate as the orig
The validation (policy and consensus) of the original transaction is optional: a receiver without a full node can decide to create the payjoin transaction and automatically broadcast the original transaction after a timeout of 1 minute, and only verify that it has been propagated in the network.
-However, non-interactive receivers (like a payment processor) need to verify the transaction to prevent UTXO probing attacks.
+However, non-interactive receivers (like a payment processor) need to verify the transaction to prevent UTXO probing attacks.
This is not a concern for interactive receivers like Wasabi Wallet, because those receivers can just limit the number of original PSBT proposals of a specific address to one. With such wallets, the attacker has no way to generate new deposit addresses to probe the UTXOs.
@@ -498,7 +498,7 @@ public async Task RequestPayjoin(
if (proposedPSBTInput.NonWitnessUtxo != null || proposedPSBTInput.WitnessUtxo != null)
throw new PayjoinSenderException("The receiver added non_witness_utxo or witness_utxo to one of our inputs");
sequences.Add(proposedTxIn.Sequence);
-
+
// Fill up the info from the original PSBT input so we can sign and get fees.
proposedPSBTInput.NonWitnessUtxo = input.SignedPSBTInput.NonWitnessUtxo;
proposedPSBTInput.WitnessUtxo = input.SignedPSBTInput.WitnessUtxo;
@@ -660,7 +660,7 @@ A successful exchange with:
* [[https://github.com/BlueWallet/BlueWallet|BlueWallet]] is in the process of implementing the protocol.
* [[https://github.com/btcpayserver/btcpayserver|BTCPay Server]] has implemented sender and receiver side of this protocol.
* [[https://github.com/zkSNACKs/WalletWasabi/|Wasabi Wallet]] has merged sender's support.
-* [[https://github.com/JoinMarket-Org/joinmarket-clientserver|Join Market]] is in the process of implementing the protocol.
+* [[https://github.com/JoinMarket-Org/joinmarket-clientserver|Join Market]] has implemented sender and receiver side of this protocol.
* [[https://github.com/bitcoinjs/payjoin-client|JavaScript sender implementation]].
==Backward compatibility==
diff --git a/bip-0079.mediawiki b/bip-0079.mediawiki
index c8f2104b..797c8f14 100644
--- a/bip-0079.mediawiki
+++ b/bip-0079.mediawiki
@@ -68,7 +68,7 @@ The template transaction should be sent to the receiver via an HTTP POST to the
The receiver is then responsible for validating the template transaction. If there is a problem with the transaction, or the receiver is generally unhappy with the transaction (e.g. fees are too small) the HTTP response code of 422 should be used and a human-readable string containing information on why which can be directly given to the user.
-Should the receiver reject a transaction, it should not attempt to propagate it on the network. However it is important for the sender to be aware that the receiver *could* at any time (regardless of which error was given) send this transaction. The client should therefor assume the receiver will, and act accordingly (either retry with adjustments or just propagate the transaction). It is imperative that the sender never finds themselves in a situation where two payments to the sender could be valid.
+Should the receiver reject a transaction, it should not attempt to propagate it on the network. However it is important for the sender to be aware that the receiver *could* at any time (regardless of which error was given) send this transaction. The client should therefore assume the receiver will, and act accordingly (either retry with adjustments or just propagate the transaction). It is imperative that the sender never finds themselves in a situation where two payments to the sender could be valid.
=== Contributed Input Choice ===
@@ -118,7 +118,7 @@ For anyone wanting to implement bustapay payments, here are some notes for recei
== Backwards Compatibility ==
-Bustapay is an optional payment protocol and therefor has no backwards compatibility concerns. It in fact can only be supported in addition to normal transaction processing, as falling back to a normal bitcoin transaction is a required behavior.
+Bustapay is an optional payment protocol and therefore has no backwards compatibility concerns. It in fact can only be supported in addition to normal transaction processing, as falling back to a normal bitcoin transaction is a required behavior.
== Credits ==
diff --git a/bip-0085.mediawiki b/bip-0085.mediawiki
index 7c4cbcab..6e7dd0e9 100644
--- a/bip-0085.mediawiki
+++ b/bip-0085.mediawiki
@@ -25,6 +25,8 @@ As HD keychains are essentially derived from initial entropy, this proposal prov
==Definitions==
+The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
+
The terminology related to keychains used in the wild varies widely, for example `seed` has various different meanings. In this document we define the terms
# '''BIP32 root key''' is the root extended private key that is represented as the top root of the keychain in BIP32.
@@ -33,19 +35,19 @@ The terminology related to keychains used in the wild varies widely, for example
==Motivation==
-Most wallets implement BIP32 which defines how a BIP32 root key can be used to derive keychains. As a consequence, a backup of just the BIP32 root key is sufficient to include all keys derived from it. BIP32 does not have a human friendly serialization of the BIP32 root key (or BIP32 extended keys in general) which makes paper backups or manually restoring the key more error-prone. BIP39 was designed solve this problem but rather than serialize the BIP32 root key, it takes some entropy, encoded to a "seed mnemonic", which is then hashed to derive the BIP39 seed which can be turned into the BIP32 root key. Saving the BIP39 mnemonic is enough to reconstruct the entire BIP32 keychain, but a BIP32 root key cannot be reversed back to the BIP39 mnemonic.
+Most wallets implement BIP32 which defines how a BIP32 root key can be used to derive keychains. As a consequence, a backup of just the BIP32 root key is sufficient to include all keys derived from it. BIP32 does not have a human friendly serialization of the BIP32 root key (or BIP32 extended keys in general) which makes paper backups or manually restoring the key more error-prone. BIP39 was designed to solve this problem but rather than serialize the BIP32 root key, it takes some entropy, encoded to a "seed mnemonic", which is then hashed to derive the BIP39 seed which can be turned into the BIP32 root key. Saving the BIP39 mnemonic is enough to reconstruct the entire BIP32 keychain, but a BIP32 root key cannot be reversed back to the BIP39 mnemonic.
-Most wallets implement BIP39, so on initialization or restoration, the user must interact with a BIP39 mnemonic. Most wallets do not support of BIP32 extended private keys so each wallet must either share the same BIP39 mnemonic, or have a separate BIP39 mnemonic entirely. Neither scenarios are particularly satisfactory for security reasons. For example, some wallets may be inherently less secure like hot wallets on smartphones, Join Market servers, Lightning Network nodes. Having multiple seeds is far from desirable especially for those who rely on split key or redundancy backups in different geological locations. Adding is necessarily difficult and may result in users being more lazy with subsequent keys, such that compromises security or leads to key loss.
+Most wallets implement BIP39, so on initialization or restoration, the user must interact with a BIP39 mnemonic. Most wallets do not support BIP32 extended private keys, so each wallet must either share the same BIP39 mnemonic, or have a separate BIP39 mnemonic entirely. Neither scenarios are particularly satisfactory for security reasons. For example, some wallets may be inherently less secure like hot wallets on smartphones, Join Market servers, or Lightning Network nodes. Having multiple seeds is far from desirable, especially for those who rely on split key or redundancy backups in different geological locations. Adding is necessarily difficult and may result in users being more lazy with subsequent keys, resulting in compromised security or loss of keys.
-There is added complication with wallets that implement other standards, or no standards at all. Bitcoin Core wallet uses a WIF as the ''hdseed'', and yet other wallets use different mnemonic schemes like Electrum to derive the BIP32 root key. Other cryptocurrencies like Monero also use a different mnemonic scheme entirely.
+There is added complication with wallets that implement other standards, or no standards at all. Bitcoin Core wallet uses a WIF as the ''hdseed'', and yet other wallets like Electrum use different mnemonic schemes to derive the BIP32 root key. Other cryptocurrencies like Monero also use an entirely different mnemonic scheme.
-Ultimately, all of the mnemonic/seed schemes start with some "initial entropy" to derive a mnemonic/seed, and then process the mnemonic into a BIP32 key, or private key. We can use BIP32 itself to derive the "initial entropy" to then recreate the same mnemonic or seed according the specific application standard of the target wallet. We can use a BIP44 like categorization to ensure unitform derivation according to the target application type.
+Ultimately, all of the mnemonic/seed schemes start with some "initial entropy" to derive a mnemonic/seed, and then process the mnemonic into a BIP32 key, or private key. We can use BIP32 itself to derive the "initial entropy" to then recreate the same mnemonic or seed according to the specific application standard of the target wallet. We can use a BIP44-like categorization to ensure uniform derivation according to the target application type.
==Specification==
We assume a single BIP32 master root key. This specification is not concerned with how this was derived (e.g. directly or via a mnemonic scheme such as BIP39).
-For each application that requires its own wallet, a unique private key is derived from the BIP32 master root key using fully hardened derivation path. The resulting private key (k) is then processed with HMAC-SHA512, where the key is "bip-entropy-from-k", and the message payload is the private key k: HMAC-SHA512(key="bip-entropy-from-k", msg=k)
. The result produces 512 bits of entropy. Each application SHOULD use up to the required number of bits necessary for their operation truncating the rest
+For each application that requires its own wallet, a unique private key is derived from the BIP32 master root key using a fully hardened derivation path. The resulting private key (k) is then processed with HMAC-SHA512, where the key is "bip-entropy-from-k", and the message payload is the private key k: HMAC-SHA512(key="bip-entropy-from-k", msg=k)
. The result produces 512 bits of entropy. Each application SHOULD use up to the required number of bits necessary for their operation truncating the rest.
The HMAC-SHA512 function is specified in [http://tools.ietf.org/html/rfc4231 RFC 4231].
@@ -69,28 +71,57 @@ OUTPUT
* DERIVED KEY=503776919131758bb7de7beb6c0ae24894f4ec042c26032890c29359216e21ba
* DERIVED ENTROPY=70c6e3e8ebee8dc4c0dbba66076819bb8c09672527c4277ca8729532ad711872218f826919f6b67218adde99018a6df9095ab2b58d803b5b93ec9802085a690e
+==BIP85-DRNG==
+
+BIP85-DRNG-SHAKE256 is a deterministic random number generator for cryptographic functions that require deterministic outputs, but where the input to that function requires more than the 64 bytes provided by BIP85's HMAC output. BIP85-DRNG-SHAKE256 uses BIP85 to seed a SHAKE256 stream (from the SHA-3 standard). The input must be exactly 64 bytes long (from the BIP85 HMAC output).
+
+RSA key generation is an example of a function that requires orders of magnitude more than 64 bytes of random input. Further, it is not possible to precalculate the amount of random input required until the function has completed.
+
+ drng_reader = BIP85DRNG.new(bip85_entropy)
+ rsa_key = RSA.generate_key(4096, drng_reader.read())
+
+===Test Vectors===
+INPUT:
+xprv9s21ZrQH143K2LBWUUQRFXhucrQqBpKdRRxNVq2zBqsx8HVqFk2uYo8kmbaLLHRdqtQpUm98uKfu3vca1LqdGhUtyoFnCNkfmXRyPXLjbKb
+* MASTER BIP32 ROOT KEY: m/83696968'/0'/0'
+
+OUTPUT
+* DERIVED KEY=cca20ccb0e9a90feb0912870c3323b24874b0ca3d8018c4b96d0b97c0e82ded0
+* DERIVED ENTROPY=efecfbccffea313214232d29e71563d941229afb4338c21f9517c41aaa0d16f00b83d2a09ef747e7a64e8e2bd5a14869e693da66ce94ac2da570ab7ee48618f7
+
+* DRNG(80 bytes)=b78b1ee6b345eae6836c2d53d33c64cdaf9a696487be81b03e822dc84b3f1cd883d7559e53d175f243e4c349e822a957bbff9224bc5dde9492ef54e8a439f6bc8c7355b87a925a37ee405a7502991111
+
==Reference Implementation==
-Python library implementation: [https://github.com/ethankosakovsky/bipentropy python-bipentropy]
+* Python library implementation: [https://github.com/ethankosakovsky/bip85]
+* JavaScript library implementation: [https://github.com/hoganri/bip85-js]
===Other Implementations===
-Coldcard Firmware: [https://github.com/Coldcard/firmware/pull/39]
+* JavaScript library implementation: [https://github.com/hoganri/bip85-js]
+
+* Coldcard Firmware: [https://github.com/Coldcard/firmware/pull/39]
+
+* Ian Coleman's Mnemonic Code Converter: [https://github.com/iancoleman/bip39] and [https://iancoleman.io/bip39/]
+
+* AirGap Vault: [https://github.com/airgap-it/airgap-vault/commit/d64332fc2f332be622a1229acb27f621e23774d6]
+
+btc_hd_wallet: [https://github.com/scgbckbone/btc-hd-wallet]
==Applications==
-Application number define how entropy will be used post processing. Some basic examples follow:
+The Application number defines how entropy will be used post processing. Some basic examples follow:
-Derivation path uses the format m/83696968/' + /app_no' + /index'
where ''app_no'' path for the application, and `index` in the index.
+Derivation path uses the format m/83696968'/{app_no}'/{index}'
where ''{app_no}'' is the path for the application, and ''{index}'' is the index.
===BIP39===
Application number: 39'
-Truncate trailing (least significant) bytes of the entropy to the number of bits required to map to the relevant word length 128 bits for 12 words, 256 bits for 24 words.
+Truncate trailing (least significant) bytes of the entropy to the number of bits required to map to the relevant word length: 128 bits for 12 words, 256 bits for 24 words.
The derivation path format is: m/83696968'/39'/{language}'/{words}'/{index}'
-Example a BIP39 mnemonic with 12 English words (first index) would have the path m/83696968'/39'/0'/12'/0'
the next key would be m/83696968'/39'/0'/12'/1'
etc.
+Example: a BIP39 mnemonic with 12 English words (first index) would have the path m/83696968'/39'/0'/12'/0'
, the next key would be m/83696968'/39'/0'/12'/1'
etc.
Language Table
@@ -231,15 +262,45 @@ INPUT:
OUTPUT
* DERIVED ENTROPY=492db4698cf3b73a5a24998aa3e9d7fa96275d85724a91e71aa2d645442f878555d078fd1f1f67e368976f04137b1f7a0d19232136ca50c44614af72b5582a5c
+===RSA===
+
+Application number: 828365'
+
+The derivation path format is: m/83696968'/828365'/{key_bits}'/{key_index}'
+
+The RSA key generator should use BIP85-DRNG as the input RNG function.
+
+===RSA GPG===
+
+Keys allocated for RSA-GPG purposes use the following scheme:
+
+ - Main key m/83696968'/828365'/{key_bits}'/{key_index}'
+ - Sub keys: m/83696968'/828365'/{key_bits}'/{key_index}'/{sub_key}'
+
+ - key_index is the parent key for CERTIFY capability
+ - sub_key 0'
is used as the ENCRYPTION key
+ - sub_key 1'
is used as the AUTHENTICATION key
+ - sub_key 2'
is usually used as SIGNATURE key
+
+Note on timestamps:
+
+The resulting RSA key can be used to create a GPG key where the creation date MUST be fixed to unix Epoch timestamp 1231006505 (the Bitcoin genesis block time '2009-01-03 18:05:05'
UTC) because the key fingerprint is affected by the creation date (Epoch timestamp 0 was not chosen because of legacy behavior in GNUPG implementations for older keys). Additionally, when importing sub-keys under a key in GNUPG, the system time must be frozen to the same timestamp before importing (e.g. by use of faketime
).
+
+Note on GPG key capabilities on smartcard/hardware devices:
+
+GPG capable smart-cards SHOULD be be loaded as follows: The encryption slot SHOULD be loaded with the ENCRYPTION capable key; the authentication slot SHOULD be loaded with the AUTHENTICATION capable key. The signature capable slot SHOULD be loaded with the SIGNATURE capable key.
+
+However, depending on available slots on the smart-card, and preferred policy, the CERTIFY capable key MAY be flagged with CERTIFY and SIGNATURE capabilities and loaded into the SIGNATURE capable slot (for example where the smart-card has only three slots and the CERTIFY capability is required on the same card). In this case, the SIGNATURE capable sub-key would be disregarded because the CERTIFY capable key serves a dual purpose.
+
==Backwards Compatibility==
This specification is not backwards compatible with any other existing specification.
-This specification relies on BIP32 but is agnostic to how the BIP32 root key is derived, as such this standard is allows it to derive wallets with initialization schemes like BIP39 or Electrum wallet style mnemonics.
+This specification relies on BIP32 but is agnostic to how the BIP32 root key is derived. As such, this standard is able to derive wallets with initialization schemes like BIP39 or Electrum wallet style mnemonics.
==Discussion==
-The reason for running the derived key through HMAC-SHA512 and truncating the result as necessary is to prevent leakage of the parent tree should the derived key (k) be compromized. While the specification requires the use of hardended key derivation which would prevent this, we cannot enforce hardened derivation, so this method ensures the derived entropy is hardened. Also from a semantic point of view, since the purpose is to derive entropy and not a private key, we are required to transform the child key. This acts in an abundance of caution to ward off unwanted side effects should k be used for a dual purpose, including as a nonce hash(k), where undesirable and unforeseen interactions could occur.
+The reason for running the derived key through HMAC-SHA512 and truncating the result as necessary is to prevent leakage of the parent tree should the derived key (''k'') be compromized. While the specification requires the use of hardended key derivation which would prevent this, we cannot enforce hardened derivation, so this method ensures the derived entropy is hardened. Also, from a semantic point of view, since the purpose is to derive entropy and not a private key, we are required to transform the child key. This is done out of an abundance of caution, in order to ward off unwanted side effects should ''k'' be used for a dual purpose, including as a nonce ''hash(k)'', where undesirable and unforeseen interactions could occur.
==Acknowledgements==
@@ -251,10 +312,10 @@ BIP32, BIP39
==Footnotes==
-[1] There is a very small chance that you'll make an invalid key that is zero or bigger than the order of the curve. If this occurs, software should hard fail (forcing users should iterate to the next index).
+[1] There is a very small chance that you'll make an invalid key that is zero or bigger than the order of the curve. If this occurs, software should hard fail (forcing users to iterate to the next index).
From BIP32:
-> In case parse256 (IL ) is 0 or ≥ n, the resulting key is invalid, and one should proceed with the next value for i. (Note: this has probability lower than 1 in 2127 .)
+In case parse256 (IL ) is 0 or ≥ n, the resulting key is invalid, and one should proceed with the next value for i. (Note: this has probability lower than 1 in 2127 .)
==Copyright==
diff --git a/bip-0086.mediawiki b/bip-0086.mediawiki
new file mode 100644
index 00000000..f724884e
--- /dev/null
+++ b/bip-0086.mediawiki
@@ -0,0 +1,128 @@
+
+ BIP: 86
+ Layer: Applications
+ Title: Key Derivation for Single Key P2TR Outputs
+ Author: Andrew Chow
+ Comments-Summary: No comments yet.
+ Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0086
+ Status: Draft
+ Type: Standards Track
+ Created: 2021-06-22
+ License: BSD-2-Clause
+
+
+==Abstract==
+
+This document suggests a derivation scheme for HD wallets whose keys are involved in single key
+P2TR ([[bip-0341.mediawiki|BIP 341]]) outputs as the Taproot internal key.
+
+===Copyright===
+
+This BIP is licensed under the 2-clause BSD license.
+
+==Motivation==
+
+With the usage of single key P2TR transactions, it is useful to have a common derivation scheme so
+that HD wallets that only have a backup of the HD seed can be likely to recover single key Taproot
+outputs. Although there are now solutions which obviate the need for fixed derivation paths for
+specific script types, many software wallets and hardware signers still use seed backups which
+lack derivation path and script information. Thus we largely use the same approach used in BIPs
+[[bip-0049.mediawiki|49]] and [[bip-0084.mediawiki|84]] for ease of implementation.
+
+==Specifications==
+
+This BIP defines the two needed steps to derive multiple deterministic addresses based on a
+[[bip-0032.mediawiki|BIP 32]] master private key.
+
+===Public key derivation===
+
+To derive a public key from the root account, this BIP uses the same account-structure as
+defined in BIPs [[bip-0044.mediawiki|44]], [[bip-0049.mediawiki|49]], and [[bip-0084.mediawiki|84]],
+but with a different purpose value for the script type.
+
+
+m / purpose' / coin_type' / account' / change / address_index
+
+
+For the purpose -path level it uses 86' .
+The rest of the levels are used as defined in BIPs 44, 49, and 84.
+
+A key derived with this derivation path pattern will be referred to as derived_key further
+in this document.
+
+===Address derivation===
+
+
+[[bip-0341.mediawiki#cite_ref-22-0|BIP 341]] states: "If the spending conditions do not require a
+script path, the output key should commit to an unspendable script path instead of having no
+script path. This can be achieved by computing the output key point as
+''Q = P + int(hashTapTweak (bytes(P)))G''." Thus:
+
+
+internal_key: lift_x(derived_key)
+32_byte_output_key: internal_key + int(HashTapTweak(bytes(internal_key)))G
+
+
+In a transaction, the scripts and witnesses are as defined in
+[[bip-0341.mediawiki#specification|BIP 341]]:
+
+
+witness:
+scriptSig: (empty)
+scriptPubKey: 1 <32_byte_output_key>
+ (0x5120{32_byte_output_key})
+
+
+==Backwards Compatibility==
+
+This BIP is not backwards compatible by design.
+An incompatible wallet will not discover these accounts at all and the user will notice that
+something is wrong.
+
+However this BIP uses the same method used in BIPs 44, 49, and 84, so it should not be difficult
+to implement.
+
+==Test vectors==
+
+
+mnemonic = abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon about
+rootpriv = xprv9s21ZrQH143K3GJpoapnV8SFfukcVBSfeCficPSGfubmSFDxo1kuHnLisriDvSnRRuL2Qrg5ggqHKNVpxR86QEC8w35uxmGoggxtQTPvfUu
+rootpub = xpub661MyMwAqRbcFkPHucMnrGNzDwb6teAX1RbKQmqtEF8kK3Z7LZ59qafCjB9eCRLiTVG3uxBxgKvRgbubRhqSKXnGGb1aoaqLrpMBDrVxga8
+
+// Account 0, root = m/86'/0'/0'
+xprv = xprv9xgqHN7yz9MwCkxsBPN5qetuNdQSUttZNKw1dcYTV4mkaAFiBVGQziHs3NRSWMkCzvgjEe3n9xV8oYywvM8at9yRqyaZVz6TYYhX98VjsUk
+xpub = xpub6BgBgsespWvERF3LHQu6CnqdvfEvtMcQjYrcRzx53QJjSxarj2afYWcLteoGVky7D3UKDP9QyrLprQ3VCECoY49yfdDEHGCtMMj92pReUsQ
+
+// Account 0, first receiving address = m/86'/0'/0'/0/0
+xprv = xprvA449goEeU9okwCzzZaxiy475EQGQzBkc65su82nXEvcwzfSskb2hAt2WymrjyRL6kpbVTGL3cKtp9herYXSjjQ1j4stsXXiRF7kXkCacK3T
+xpub = xpub6H3W6JmYJXN49h5TfcVjLC3onS6uPeUTTJoVvRC8oG9vsTn2J8LwigLzq5tHbrwAzH9DGo6ThGUdWsqce8dGfwHVBxSbixjDADGGdzF7t2B
+internal_key = cc8a4bc64d897bddc5fbc2f670f7a8ba0b386779106cf1223c6fc5d7cd6fc115
+output_key = a60869f0dbcf1dc659c9cecbaf8050135ea9e8cdc487053f1dc6880949dc684c
+scriptPubKey = 5120a60869f0dbcf1dc659c9cecbaf8050135ea9e8cdc487053f1dc6880949dc684c
+address = bc1p5cyxnuxmeuwuvkwfem96lqzszd02n6xdcjrs20cac6yqjjwudpxqkedrcr
+
+// Account 0, second receiving address = m/86'/0'/0'/0/1
+xprv = xprvA449goEeU9okyiF1LmKiDaTgeXvmh87DVyRd35VPbsSop8n8uALpbtrUhUXByPFKK7C2yuqrB1FrhiDkEMC4RGmA5KTwsE1aB5jRu9zHsuQ
+xpub = xpub6H3W6JmYJXN4CCKUSnriaiQRCZmG6aq4sCMDqTu1ACyngw7HShf59hAxYjXgKDuuHThVEUzdHrc3aXCr9kfvQvZPit5dnD3K9xVRBzjK3rX
+internal_key = 83dfe85a3151d2517290da461fe2815591ef69f2b18a2ce63f01697a8b313145
+output_key = a82f29944d65b86ae6b5e5cc75e294ead6c59391a1edc5e016e3498c67fc7bbb
+scriptPubKey = 5120a82f29944d65b86ae6b5e5cc75e294ead6c59391a1edc5e016e3498c67fc7bbb
+address = bc1p4qhjn9zdvkux4e44uhx8tc55attvtyu358kutcqkudyccelu0was9fqzwh
+
+// Account 0, first change address = m/86'/0'/0'/1/0
+xprv = xprvA3Ln3Gt3aphvUgzgEDT8vE2cYqb4PjFfpmbiFKphxLg1FjXQpkAk5M1ZKDY15bmCAHA35jTiawbFuwGtbDZogKF1WfjwxML4gK7WfYW5JRP
+xpub = xpub6GL8SnQwRCGDhB59LEz9HMyM6sRYoByXBzXK3iEKWgCz8XrZNHUzd9L3AUBELW5NzA7dEFvMas1F84TuPH3xqdUA5tumaGWFgihJzWytXe3
+internal_key = 399f1b2f4393f29a18c937859c5dd8a77350103157eb880f02e8c08214277cef
+output_key = 882d74e5d0572d5a816cef0041a96b6c1de832f6f9676d9605c44d5e9a97d3dc
+scriptPubKey = 5120882d74e5d0572d5a816cef0041a96b6c1de832f6f9676d9605c44d5e9a97d3dc
+address = bc1p3qkhfews2uk44qtvauqyr2ttdsw7svhkl9nkm9s9c3x4ax5h60wqwruhk7
+
+
+==Reference==
+
+* [[bip-0032.mediawiki|BIP32 - Hierarchical Deterministic Wallets]]
+* [[bip-0043.mediawiki|BIP43 - Purpose Field for Deterministic Wallets]]
+* [[bip-0044.mediawiki|BIP44 - Multi-Account Hierarchy for Deterministic Wallets]]
+* [[bip-0049.mediawiki|BIP49 - Derivation scheme for P2WPKH-nested-in-P2SH based accounts]]
+* [[bip-0084.mediawiki|BIP84 - Derivation scheme for P2WPKH based accounts]]
+* [[bip-0341.mediawiki|BIP341 - Taproot: SegWit version 1 spending rules]]
diff --git a/bip-0087.mediawiki b/bip-0087.mediawiki
new file mode 100644
index 00000000..d270027e
--- /dev/null
+++ b/bip-0087.mediawiki
@@ -0,0 +1,274 @@
+
+ BIP: 87
+ Layer: Applications
+ Title: Hierarchy for Deterministic Multisig Wallets
+ Author: Robert Spigler
+ Comments-Summary: No comments yet.
+ Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0087
+ Status: Proposed
+ Type: Standards Track
+ Created: 2020-03-11
+ License: BSD-2-Clause
+
+
+==Abstract==
+
+This BIP defines a sane hierarchy for deterministic multisig wallets based on an algorithm described in BIP-0032 (BIP32 from now on), purpose scheme described in BIP-0043 (BIP43 from now on), and multi-account hierarchy described in BIP-0044 (BIP44 from now on).
+
+This BIP is a particular application of BIP43.
+
+==Copyright==
+
+This BIP is licensed under the 2-clause BSD license.
+
+==Motivation==
+
+With the increase of more user friendly (offline) multisignature wallets, and adoption of new technologies such as [https://github.com/bitcoin/bitcoin/blob/master/doc/descriptors.md the descriptor language] and [https://github.com/bitcoin/bips/blob/master/bip-0174.mediawiki BIP-0174 (Partially Signed Bitcoin Transactions)], it is necessary to create a common derivation scheme that makes use of all new technologies.
+
+As background, BIP 44/49/84 specifies:
+
+
+m / purpose' / coin_type' / account' / change / address_index
+
+
+where the BIP43 purpose'
path is separate for each script (P2PKH, P2WPKH-in-P2SH, and P2WPKH respectively). Having a script-per-derivation for single sig wallets allows for easy backup and restore, with just the private key information.
+
+Multisignature wallets need more information to backup and restore (such as all cosigner public keys), and these per-script derivations are made redundant with descriptors, which provide that information (while also specifying a collection of output scripts).
+A modern standardization is needed for multisig derivation paths. There are some in existence, but all have issues. For example, BIP45 specifies:
+
+
+m / purpose' / cosigner_index / change / address_index
+
+
+BIP45 unecessarily demands a single script type (here, P2SH). In addition, BIP45 sets cosigner_index
in order to sort the purpose'
public keys of each cosigner. This too is redundant, as descriptors can set the order of the public keys with multi
or have them sorted lexicographically (as described in [https://github.com/bitcoin/bips/blob/master/bip-0067.mediawiki BIP67]) with sortedmulti
. Sorting public keys between cosigners in order to create the full derivation path, prior to sending the key record to the coordinator to create the descriptor, merely adds additional unnecessary communication rounds.
+
+The second multisignature "standard" in use is m/48', which specifies:
+
+
+m / purpose' / coin_type' / account' / script_type' / change / address_index
+
+
+Rather than following in BIP 44/49/84's path and having a separate BIP per script after P2SH (BIP45), vendors decided to insert script_type'
into the derivation path (where P2SH-P2WSH=1, P2WSH=2, Future_Script=3, etc). As described previously, this is unnecessary, as the descriptor sets the script. While it attempts to reduce maintainence work by getting rid of new BIPs-per-script, it still requires maintaining an updated, redundant, script_type
list.
+
+The structure proposed later in this paper solves these issues and is quite comprehensive. It allows for the handling of multiple accounts, external and internal chains per account, and millions of addresses per chain, in a multi-party, multisignature, hierarchical deterministic wallet regardless of the script type ['''Why propose this structure only for multisignature wallets?''' Currently, single-sig wallets are able to restore funds using just the master private key data (in the format of BIP39 usually). Even if the user doesn't recall the derivation used, the wallet implementation can iterate through common schemes (BIP44/49/84). With this proposed hierarchy, the user would either have to now backup additional data (the descriptor), or the wallet would have to attempt all script types for every account level when restoring. Because of this, even though the descriptor language handles the signature type just like it does the script type, it is best to restrict this script-agnostic hierarchy to multisignature wallets only.].
+
+This paper was inspired from BIP44.
+
+==Specification==
+
+===Key sorting===
+
+Any wallet that supports descriptors inherently supports deterministic key sorting as per BIP67 (through the sortedmulti
function) so that all possible multisignature addresses/scripts are derived from deterministically sorted public keys.
+
+===Path levels===
+
+We should not be mixing keys and scripts in the same layer. The wallet should create extended private/public keys independent of the script type, whereas the descriptor language tells wallets to watch the multisig outputs with the specified public keys.
+
+We define the following 5 levels in the BIP32 path:
+
+
+m / purpose' / coin_type' / account' / change / address_index
+
+
+h
or '
in the path indicates that BIP32 hardened derivation is used.
+
+Each level has a special meaning, described in the chapters below.
+
+===Purpose===
+
+Purpose is a constant set to 87'
following the BIP43 recommendation.
+It indicates that the subtree of this node is used according to this specification.
+
+Hardened derivation is used at this level.
+
+===Coin type===
+
+One master node (seed) can be used for multiple Bitcoin networks.
+Sharing the same space for various networks has some disadvantages.
+
+This level creates a separate subtree for every network, avoiding reusing addresses across networks and improving privacy issues.
+
+Coin type 0
for mainnet and 1
for testnets (testnet, regtest, and signet).
+
+Hardened derivation is used at this level.
+
+===Account===
+
+This level splits the key space into independent user identities, following the BIP44 pattern, so the wallet never mixes the coins across different accounts.
+
+Users can use these accounts to organize the funds in the same fashion as bank accounts; for donation purposes (where all addresses are considered public), for saving purposes, for common expenses, etc.
+
+Accounts are numbered from index 0
in sequentially increasing manner.
+This number is used as child index in BIP32 derivation.
+
+Hardened derivation is used at this level.
+
+It is crucial that this level is increased for each new wallet joined or private/public keys created; for both privacy and cryptographic purposes.
+For example, before sending a new key record to a coordinator, the wallet must increment the account'
level.
+This prevents key reuse - across ECDSA and Schnorr signatures, across different script types, and inbetween the same wallet types.
+
+===Change===
+
+Constant 0
is used for external chain and constant 1
for internal chain (also known as change addresses). External chain is used for addresses that are meant to be visible outside of the wallet (e.g. for receiving payments). Internal chain is used for addresses which are not meant to be visible outside of the wallet and is used for return transaction change.
+
+Public derivation is used at this level.
+
+===Index===
+
+Addresses are numbered from index 0
in sequentially increasing manner.
+This number is used as child index in BIP32 derivation.
+
+Public derivation is used at this level.
+
+==Address Discovery==
+
+The multisig descriptors or descriptor template that is generated from the cosigners' combined key records should be used to generate and discover addresses.
+
+Please see [https://github.com/bitcoin/bips/blob/master/bip-0129.mediawiki BIP-0129 (Bitcoin Secure Multisig Setup)] for an introduction on descriptor templates.
+The descriptor or descriptor template should contain the key origin information for maximum compatibility with BIP-0174.
+
+For example:
+
+The following descriptor template and derivation path restrictions:
+
+wsh(sortedmulti(2,[xfpForA/87'/0'/0']XpubA/**,[xfpForB/87'/0'/0']XpubB/**))
+
+/0/*,/1/*
+
+Expands to the two concrete descriptors:
+
+wsh(sortedmulti(2,[xfpForA/87'/0'/0']XpubA/0/*,[xfpForB/87'/0'/0']XpubB/0/*))
+
+wsh(sortedmulti(2,[xfpForA/87'/0'/0']XpubA/1/*,[xfpForB/87'/0'/0']XpubB/1/*))
+
+To discover addresses, import both the receiving and change descriptors; respect the gap limit described below.
+
+===Address Gap Limit===
+
+Address gap limit is currently set to 20. If the software hits 20 unused addresses in a row, it expects there are no used addresses beyond this point and stops searching the address chain.
+
+Wallet software should warn when the user is trying to exceed the gap limit on an external descriptor by generating multiple unused addresses.
+
+==Backwards Compatibility==
+
+Any script that is supported by descriptors (and the specific wallet implementation) is compatible with this BIP.
+
+As wallets complying with this BIP are descriptor wallets, this therefore necessitates that the cosigners backup their private key information and the descriptor, in order to properly restore at a later time. This shouldn't be a user burden, since (to much user surprise), all cosigner public keys need to be supplied in addition to M
seeds in any M
of N
multisig restore operation. The descriptor provides this information in a standardized format, with key origin information and error detection.
+
+==Rationale==
+
+
+
+==Examples==
+
+{|
+|network
+|account
+|chain
+|address
+|path
+|-
+|mainnet
+|first
+|external
+|first
+|m / 87' / 0' / 0' / 0 / 0
+|-
+|mainnet
+|first
+|external
+|second
+|m / 87' / 0' / 0' / 0 / 1
+|-
+|mainnet
+|first
+|change
+|first
+|m / 87' / 0' / 0' / 1 / 0
+|-
+|mainnet
+|first
+|change
+|second
+|m / 87' / 0' / 0' / 1 / 1
+|-
+|mainnet
+|second
+|external
+|first
+|m / 87' / 0' / 1' / 0 / 0
+|-
+|mainnet
+|second
+|external
+|second
+|m / 87' / 0' / 1' / 0 / 1
+|-
+|testnet
+|first
+|external
+|first
+|m / 87' / 1' / 0' / 0 / 0
+|-
+|testnet
+|first
+|external
+|second
+|m / 87' / 1' / 0' / 0 / 1
+|-
+|testnet
+|first
+|change
+|first
+|m / 87' / 1' / 0' / 1 / 0
+|-
+|testnet
+|first
+|change
+|second
+|m / 87' / 1' / 0' / 1 / 1
+|-
+|testnet
+|second
+|external
+|first
+|m / 87' / 1' / 1' / 0 / 0
+|-
+|testnet
+|second
+|external
+|second
+|m / 87' / 1' / 1' / 0 / 1
+|-
+|testnet
+|second
+|change
+|first
+|m / 87' / 1' / 1' / 1 / 0
+|-
+|testnet
+|second
+|change
+|second
+|m / 87' / 1' / 1' / 1 / 1
+|}
+
+==Reference Implementation==
+
+None at the moment.
+
+==Acknowledgement==
+
+Special thanks to SomberNight, Craig Raw, David Harding, Jochen Hoenicke, Sjors Provoost, and others for their feedback on the specification.
+
+==References==
+
+Original mailing list thread: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-March/018630.html
+
+* [https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki BIP-0032 (Hierarchical Deterministic Wallets)]
+* [https://github.com/bitcoin/bips/blob/master/bip-0043.mediawiki BIP-0043 (Purpose Field for Deterministic Wallets)]
+* [https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki BIP-0044 (Multi-Account Hierarchy for Deterministic Wallets)]
+* [https://github.com/bitcoin/bitcoin/blob/master/doc/descriptors.md Output Descriptors]
+* [https://github.com/bitcoin/bips/blob/master/bip-0174.mediawiki BIP-0174 (Partially Signed Bitcoin Transaction Format)]
+* [https://github.com/bitcoin/bips/blob/master/bip-0067.mediawiki BIP-0067 (Deterministic Pay-to-script-hash multi-signature addresses through public key sorting)]
+* [https://github.com/bitcoin/bips/blob/master/bip-0129.mediawiki BIP-0129 (Bitcoin Secure Multisig Setup)]
diff --git a/bip-0088.mediawiki b/bip-0088.mediawiki
new file mode 100644
index 00000000..936f2ca9
--- /dev/null
+++ b/bip-0088.mediawiki
@@ -0,0 +1,233 @@
+
+ BIP: 88
+ Layer: Applications
+ Title: Hierarchical Deterministic Path Templates
+ Author: Dmitry Petukhov
+ Comments-Summary: No comments yet.
+ Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0088
+ Status: Proposed
+ Type: Informational
+ Created: 2020-06-23
+ License: BSD-2-Clause
+
+
+==Abstract==
+
+This document describes a format for the representation of the templates that specify
+the constraints that can be imposed on BIP32 derivation paths.
+
+The constraints specified by the templates allow to easily discern 'valid' paths,
+that match the constraints, and 'invalid' paths, that exceed the constraints.
+
+==Copyright==
+
+This BIP is licensed under the 2-clause BSD license.
+
+==Motivation==
+
+BIP32 derivation path format is universal, and a number of schemes for derivation were proposed
+in BIP43 and other documents, such as BIPs 44,45,49,84. The flexibility of the format also allowed
+industry participants to implement custom derivation shemes that fit particular purposes,
+but not necessarily useful in general.
+
+Even when existing BIPs for derivation schemes are used, their usage is not uniform across
+the different wallets, in part because software vendors might have different considerations
+and priorities when making decisions about derivation paths. This creates friction for users,
+which might face problems when they try to access their coins using the wallet that derives
+addresses differently than the one they used before.
+
+===Known solutions===
+
+The problem is common enough to warrant the creation of a dedicated website
+([https://walletsrecovery.org/ walletsrecovery.org]) that tracks paths used by different wallets.
+
+At the time of writing, this website has used their own format to succintly describe multiple
+derivation paths. As far as author knows, it was the only publicitly used format to describe
+path templates before introduction of this BIP. The format was not specified anywhere beside
+the main page of the website. It used |
to denote alternative derivation indexes
+(example: m/|44'|49'|84'/0'/0'
) or whole alternative paths (m/44'/0'/0'|m/44'/1'/0'
).
+
+It was not declared as a template format to use for processing by software, and seems to be
+an ad-hoc format only intended for illustration. In contrast to this ad-hoc format, the format
+described in this BIP is intended for unambigouos parsing by software, and to be easily read by humans
+at the same time. Humans can visually detect the 'templated' parts of the path more easily than the use
+of |
in the template could allow. Wider range of paths can be defined in a single template more
+succintly and unambiguously.
+
+===Intended use and advantages===
+
+Wallet software authors can use the proposed format to describe the derivation paths that
+their software uses. This can improve user experience when switching to different wallet
+software, restoring access to old wallets, etc.
+
+Unrestricted derivation path usage might be unsafe in certain contexts. In particular, when "change"
+outputs of a transaction are sent to the addresses derived via paths unknown to the sender, the sender
+might lose access to the whole change amount.
+
+A simplistic approach of hard-coding the checks for well-known paths into software and firmware leads
+to reduced interoperability. Vendors cannot choose custom paths that are appropriate for
+their particular, non-general-purpose applications, and are forced to shoehorn their solutions
+into using well-known paths, or convince other vendors to support their custom paths. This approach
+scales poorly.
+
+A flexible approach proposed in this document is to define a standard notation for "BIP32 path templates"
+that succintly describes the constraints to impose on the derivation path.
+
+Wide support for these path templates will increase interoperability and flexibility of solutions,
+and will allow vendors and individual developers to easily define their own custom restrictions.
+This way, they will be able to deal with the risks of accidental or malicious use of unrestricted
+derivation paths in a more flexible and precise manner.
+
+Well-known path templates can be pre-configured by default on devices and applications,
+but users can have an option to turn off the templates that are not relevant to their uses.
+
+Having a standardized format for custom path templates will enable a common approach to be developed
+in the enforcement of application-specific path restrictions in devices and applications.
+One example of such an approach might be for devices to allow application-specific profiles
+with path templates and possibly other custom parameters. Care must be taken to prevent the accidental
+installation of malicious or incorrect profiles, though.
+
+==Specification==
+
+The format for the template was choosen to make it easy to read, convenient and visually unambigous.
+
+Template starts with optional prefix m/
, and then one or more sections delimited by the slash character (/
).
+
+Implementations MAY limit the maximum number of sections.
+
+Each section consists of ''index template'', optionally followed by the hardened marker: either an apostrophe ('
) or letter h
.
+
+Index template can be:
+
+* An integer value from 0 to 2147483647 ("Unit index template")
+* A single *
character, which denotes any value from 0 to 2147483647 ("Wildcard index template")
+* The {
character, followed by a number of ''index ranges'' delimited by commas (,
), followed by }
character ("Ranged index template")
+
+Implementations MAY limit the maximum number of index ranges within the Ranged index template.
+
+If an index template is immediately followed by hardened marker, this means that all values specified in this index template is to be increased by 2147483648 for the purposes of matching.
+
+Index range can be:
+
+* An integer value from 0 to 2147483647 ("Unit range")
+* An integer value from 0 to 2147483647, followed by the -
character, followed by another integer value from 0 to 2147483647 ("Non-unit range")
+
+For Non-unit range, value on the left side of the -
character is the range_start, and the value on the right side of the -
character is the range_end.
+
+For Unit range, we say that range_start is equal to range_end, even though there is no start/end in the Unit range.
+
+Unit index template contains a single index range, which is the Unit range
+
+Wildcard index template contains a single index range, and we say that its range_start is set to 0 and its range_end is set to 2147483647
+
+Constraints:
+
+# To avoid ambiguity, whitespace MUST NOT appear within the path template.
+# Commas within the Ranged index template MUST only appear in between index ranges.
+# To avoid ambiguity, an index range that matches a single value MUST be specified as Unit range.
+# To avoid ambiguity, an index range 0-2147483647
is not allowed, and MUST be specified as Wildcard index template instead
+# For Non-unit range, range_end MUST be larger than range_start.
+# If there is more than one index range within the Ranged index template, range_start of the second and any subsequent range MUST be larger than the range_end of the preceeding range.
+# To avoid ambiguity, all representations of integer values larger than 0 MUST NOT start with character 0
(no leading zeroes allowed).
+# If hardened marker appears within any section in the path template, all preceding sections MUST also specify hardened matching.
+# To avoid ambiguity, if a hardened marker appears within any section in the path template, all preceding sections MUST also use the same hardened marker (either h
or '
).
+# To avoid ambiguity, trailing slashes (for example, 1/2/
) and duplicate slashes (for example, 0//1
) MUST NOT appear in the template.
+
+It may be desireable to have fully unambiguous encoding, where for each valid path template string, there is no other valid template string that matches the exact same set of paths. This would enable someone to compare templates for equality through a simple string equality check, without any parsing.
+
+To achieve this, two extra rules are needed:
+
+* Within Ranged index template, subsequent range MUST NOT start with the value that is equal to the end of the previous range plus one. Thus, {1,2,3-5}
is not allowed, and should be specified as {1-5}
instead. This rule might make templates less convenient for frequent edits, though.
+
+* Only one type of hardened marker should be allowed (either h
or '
).
+
+Instead of requiring the second extra rule, implementations can simply replace one type of marker with another in the template strings before comparing them.
+
+==Full and partial templates==
+
+If the template starts with m/
, that means that this is the "full" template, that matches the whole path.
+
+If the template does not start with m/
, that means that this is a "partial" template, and it can be used to match a part of the path, in the contexts where this might be appropriate (for example, when constraints for the suffix of the path might be dynamic, while constraints for the prefix of the path are fixed).
+
+Full template can be combined with partial template, where partial template extends full template,
+resulting in new, longer full template.
+
+Partial template can be combined with another partial template, resulting in new, longer partial template.
+
+Full template can not be combined with another full template.
+
+Implementations MUST support parsing full templates and matching paths against full templates.
+
+Implementations MAY support parsing partial templates and matching portions of the paths against partial templates, as well as combining the templates.
+
+==Parsing result==
+
+The result of successful parsing of a valid path template can be represented by a list of sections, where each section is a list of index ranges, where index range is a tuple of (range_start, range_end). The length of the list of sections is also referred to as the "length of the template".
+
+==Matching==
+
+The matching is to be performed against a list of integer values that represent a BIP32 path (or a portion of BIP32 path, for partial templates). The length of this list is referred to as the "length of the path".
+
+Non-hardened indexes in this list should be represented by values from 0 to 2147483647.
+
+Hardened indexes in this list should be represented by values from 2147483648 to 4294967295.
+
+The matching algorithm:
+
+ 1. If the length of the path differs from the length of the template, fail
+ 2. For each value V at position N in the path:
+ If for all index ranges within the section at position N in the template,
+ value V is either less than range_start, or greater than range_end, fail
+ 3. Otherwise, succeed
+
+==Formal specification==
+
+The finite state machine (FSM) for the parser of the described template format,
+and the matching formula are specified in TLA+ specification language at https://github.com/dgpv/bip32_template_parse_tplaplus_spec
+
+The specification can be used with TLC checker and accompanying script to generate test data for the implementations.
+
+==Implementations==
+
+While the formal specification specifies an FSM, which would be convenient for implementation without access to rich string handling facilities, when such facilities are available, the implementation might use the whole-string deconstruction approach where the templates are first split into sections, then sections are split into index templates, and then each index template are parsed individually.
+
+A FSM-based approach can be made close to the formal specification, though, and the test data generated with TLC checker would give much better coverage for a FSM based implementation. If the template string contains several errors, an implementation that uses deconstruction approach might detect some of these errors earlier than FSM-based implementation, and vise versa.
+
+At the moment, three implementations exist:
+
+* FSM implementation in C: https://github.com/dgpv/bip32_template_c_implementation
+* FSM implementation in Python (micropython compatible): https://github.com/dgpv/bip32_template_python_implementation
+* non-FSM implementation in python: BIP32PathTemplate class in bitcointx.core.key module of python-bitcointx library (https://github.com/Simplexum/python-bitcointx)
+
+==Compatibility==
+
+The full path template that only contains Unit index templates represents a fully valid BIP32 path.
+
+There's no other path template standards that is known to the author currently.
+
+There is a discussion on path templating for bitcoin script descriptors at https://github.com/bitcoin/bitcoin/issues/17190, which proposes the format xpub...{0,1}/*
, of which the {0,1}/*
part would correspond to the partial path template in the format of this BIP.
+
+==Examples==
+
+m/{44,49,84}'/0'/0'/{0-1}/{0-50000}
specifies a full template that matches both external and internal chains of BIP44, BIP49 and BIP84 paths, with a constraint that the address index cannot be larger than 50000
+
+Its representation after parsing can be (using Python syntax, ignoring full/partial distinction):
+ [[(2147483692, 2147483692), (2147483697, 2147483697), (2147483732, 2147483732)),
+ [(2147483648, 2147483648)],
+ [(2147483648, 2147483648)],
+ [(0, 1)],
+ [(0, 50000)]]
+
+{0-2,33,123}/*
specifies a partial template that matches non-hardened values 0, 1, 2, 33, 123 as first index, and any non-hardened value at second index
+
+Its representation after parsing can be:
+ [[(0, 2), (33, 33), (123, 123)], [(0, 2147483647)]]
+
+*h/0
specifies a partial template that matches any hardened index followed by non-hardened index 0
+
+Its representation after parsing can be:
+ [[(2147483648, 4294967295)], [(0, 0)]]
+
+==Acknowledgements==
+
+Special thanks to Peter D. Gray, Dr. Maxim Orlovsky, Robert Spigler and others for their feedback on the specification, and to Janine (github:@Enegnei) for the help in preparing the draft.
diff --git a/bip-0118.mediawiki b/bip-0118.mediawiki
index 1b2f27c2..a3a690bb 100644
--- a/bip-0118.mediawiki
+++ b/bip-0118.mediawiki
@@ -1,144 +1,213 @@
BIP: 118
Layer: Consensus (soft fork)
- Title: SIGHASH_NOINPUT
+ Title: SIGHASH_ANYPREVOUT for Taproot Scripts
Author: Christian Decker
+ Anthony Towns
Comments-Summary: No comments yet.
Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0118
Status: Draft
Type: Standards Track
Created: 2017-02-28
License: BSD-3-Clause
+ Requires: 340, 341, 342
-== Abstract ==
-This BIP describes a new signature hash flag (sighash -flag) for
-segwit transactions. It removes any commitment to the output being
-spent from the signature verification mechanism. This enables dynamic
-binding of transactions to outputs, predicated solely on the
-compatibility of output scripts to input scripts.
+== Introduction ==
-== Motivation ==
-Off-chain protocols make use of transactions that are not yet
-broadcast to the Bitcoin network in order to renegotiate the final
-state that should be settled on-chain.
-In a number of cases it is desirable to react to a given transaction
-being seen on-chain with a predetermined reaction in the form of
-another transaction.
-Often the reaction is identical, no matter which transaction is seen
-on-chain, but the application still needs to create many identical
-transactions.
-This is because signatures in the input of a transaction uniquely
-commit to the hash of the transaction that created the output being
-spent.
+=== Abstract ===
-This proposal introduces a new sighash flag that modifies the behavior
-of the transaction digest algorithm used in the signature creation and
-verification, to exclude the previous output commitment.
-By removing the commitment we enable dynamic rebinding of a signed
-transaction to outputs whose witnessProgram and value match the ones
-in the witness of the spending transaction.
+This BIP describes a new type of public key for tapscript ([[bip-0342.mediawiki|BIP 342]]) transactions.
+It allows signatures for these public keys to not commit to the exact UTXO being spent.
+This enables dynamic binding of transactions to different UTXOs, provided they have compatible scripts.
-The dynamic binding is opt-in and can further be restricted by using
-unique witnessProgram scripts that are specific to the application
-instance, e.g., using public keys that are specific to the off-chain
-protocol instance.
+=== Copyright ===
+
+This document is licensed under the 3-clause BSD license.
+
+=== Motivation ===
+
+Off-chain protocols make use of transactions that are not yet broadcast to the Bitcoin network in order to renegotiate the final state that should be settled on-chain.
+In a number of cases it is desirable to respond to a given transaction being seen on-chain with a predetermined reaction in the form of another transaction.
+Often the same reaction is desired for a variety of different transactions that may be seen on-chain, but because the input signatures in the response transaction commit to the exact transaction that is being reacted to, this means a new signature must be created for every possible transaction one wishes to be able to react to.
+
+This proposal introduces a new public key type['''Why a new public key type?'''
+New public key types for tapscript can be introduced in a soft fork by specifying new rules for ''unknown public key types'' as specified in [[bip-0342.mediawiki|BIP 342]], as this only requires adding restrictions to the pre-existing signature opcodes.
+Possible alternative approaches would be to define new script opcodes, to use a different taproot leaf version, or to use a different set of SegWit outputs than those specified by [[bip-0341.mediawiki|BIP 341]]; however all of these approaches are more complicated, and are better reserved for other upgrades where the additional flexibility is actually needed.
+In this case, we specify a new transaction digest, but retain the same elliptic curve and signature algorithm (ie, secp256k1 and [[bip-0340.mediawiki|BIP 340]]).]
+that modifies the behavior of the transaction digest algorithm used in the signature creation and verification, by excluding the commitment to the previous output (and, optionally, the witness script['''Why (and why not) commit to the witness script?'''
+The [https://blockstream.com/eltoo.pdf eltoo] paper provides an example of why committing to the witness script is not always appropriate.
+It uses script and the transaction ]nLockTime
to make signatures asymmetric, so that a transaction with an earlier signature can be spent by a transaction with a later signature, but a transaction with a later signature cannot be spent by a transaction with an earlier signature.
+As a result, a single signature for a third, even later transaction must be able to spend both the prior transactions, even though they have a different tapscript.
+On the other hand, these cases also provide a good reason to have the option to commit to the script: because each transaction has a new script, committing to the script allows you to produce a signature that applies to precisely one of these transactions.
+In the eltoo case, this allows you to have a signature for an update transaction that can be applied to any prior update, and a signature for a settlement transaction that applies only to the corresponding update transaction, while using the same key for both, which in turn allows for a more compact script.
+ and value ['''Why (and why not) commit to the input value?'''
+Committing to the input value may provide additional safety that a signature can't be maliciously reused to claim funds that the signer does not intend to spend, so by default it seems sensible to commit to it. However, doing so prevents being able to use a single signature to consolidate a group of UTXOs with the same spending condition into a single UTXO which may be useful for some protocols, such as the proposal for [https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-January/002448.html layered commitments with eltoo].]).
+Removing this commitment allows dynamic rebinding of a signed transaction to another previous output that requires authorisation by the same key.
+
+The dynamic rebinding is opt-in due to using a separate public key type, and the breadth of transactions the signature can be rebound to can be further restricted by using different keys, committing to the script being spent in the signature, using different amounts between UTXOs, using different nSequence values in the spending transaction, or using the codeseparator opcode to commit to the position in the script.
== Specification ==
-SIGHASH_NOINPUT is a flag with value 0x40 appended to a signature
-so that the signature does not commit to any of the inputs, and
-therefore to the outputs being spent. The flag applies solely to the
-verification of that single signature.
-The SIGHASH_NOINPUT flag is only active for segwit scripts with
-version 1 or higher. Should the flag be used in a non-segwit script or
-a segwit script of version 0, the current behavior is maintained and
-the script execution MUST abort with a failure.
+This BIP modifies the behaviour of the [[bip-0342.mediawiki|BIP 342]] signature opcodes['''What about key path spends?'''
+This proposal only supports ANYPREVOUT signatures via script path spends, and does not support ANYPREVOUT signatures for key path spends.
+This is for two reasons: first, not supporting key path spends allows this proposal to be independent of the core changes included in [[bip-0341.mediawiki|BIP 341]] and [[bip-0342.mediawiki|BIP 342]]; second, it allows addresses to opt-in or opt-out of ANYPREVOUT support while remaining indistinguishable prior to being spent.
+] (CHECKSIG
, CHECKSIGVERIFY
, and CHECKSIGADD
) for public keys that have a length of 33 bytes and a first byte of 0x01
or the public key which is precisely the single byte vector 0x01
['''Use of 0x01 public key type'''
+Because ]OP_0
leaves an empty vector on the stack it would not satisfy [[bip-0342.mediawiki|BIP 342]]'s rules for unknown public key types. As such, it is convenient to use one of OP_1..OP_16
or OP_1NEGATE
as a way to reference the taproot internal key.
+To keep things as simple as possible, we use the first of these, and add the same byte as a prefix to allow ANYPREVOUT signatures for explicitly specified keys.
+.
+These keys are termed '''BIP 118 public keys'''.
-The transaction digest algorithm from BIP 143 is used when verifying a
-SIGHASH_NOINPUT signature, with the following modifications:
+==== Rules for signature opcodes ====
- 2. hashPrevouts (32-byte hash) is 32 0x00 bytes
- 3. hashSequence (32-byte hash) is 32 0x00 bytes
- 4. outpoint (32-byte hash + 4-byte little endian) is
- set to 36 0x00 bytes
- 5. scriptCode of the input is set to an empty script
- 0x00
+The [[bip-0342.mediawiki|BIP 342]] rules for signature opcodes are modified by removing keys with the first byte 0x01
and length of either 1-byte or 33-bytes from the list of unknown public key types, and adding the following rule prior to the handling of unknown public key types:
-The value of the previous output remains part of the transaction
-digest and is therefore also committed to in the signature.
+* If the public key is the single byte 0x01
, or if the public key is 33 bytes and the first byte of the public key is 0x01
, it is considered to be a BIP 118 public key:
+** If the signature is not the empty vector, the signature is validated according to the [[bip-0341.mediawiki|BIP 341]] signing validation rules with the public key, allowable hash_type
values, and transaction digest modified as defined below.
-The NOINPUT flag MAY be combined with the SINGLE flag in which
-case the hashOutputs is modified as per BIP
-143[https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki]: it
-only commits to the output with the matching index, if such output exists, and
-is a uint256 0x0000......0000 otherwise.
+==== Public key ====
-Being a change in the digest algorithm, the NOINPUT flag applies to
-all segwit signature verification opcodes, specifically it applies to:
+To convert the 1-byte BIP 118 public key for use with [[bip-0340.mediawiki|BIP 340]], use the 32-byte taproot internal key, p
, as defined in [[bip-0341.mediawiki|BIP 341]].
-* OP_CHECKSIG
+To convert a 33-byte BIP 118 public key for use with [[bip-0340.mediawiki|BIP 340]], remove the 0x01
prefix and use the remaining 32 bytes.
-* OP_CHECKSIGVERIFY
+==== Signature message ====
-* OP_CHECKMULTISIG
+The function ''SigMsg118(hash_type, ext_flag)'' computes the message being signed as a byte array, analogously to ''SigMsg(hash_type, ext_flag)'' defined in [[bip-0341.mediawiki|BIP 341]], ''SigExt118(hash_type,key_version)'' computes the extension, similarly to [[bip-0342.mediawiki|BIP 342]].
-* OP_CHECKMULTISIGVERIFY
+The parameter ''hash_type'' is an 8-bit unsigned value, reusing values defined in [[bip-0341.mediawiki|BIP 341]], with the addition that the values 0x41
, 0x42
, 0x43
, 0xc1
, 0xc2
, and 0xc3
are also valid for BIP 118 public keys.
-== Binding through scripts ==
-Using NOINPUT the input containing the signature no longer
-references a specific output.
-Any participant can take a transaction and rewrite it by changing the
-hash reference to the previous output, without invalidating the
-signatures.
-This allows transactions to be bound to any output that matches the
-value committed to in the witness and whose witnessProgram ,
-combined with the spending transaction's witness returns true .
+We define the following constants using bits 6 and 7 of hash_type
:
-Previously, all information in the transaction was committed in the
-signature itself, while now the relationship between the spending
-transaction and the output being spent is solely based on the
-compatibility of the witnessProgram and the witness .
+* SIGHASH_ANYPREVOUT = 0x40
+* SIGHASH_ANYPREVOUTANYSCRIPT = 0xc0
-This also means that particular care has to be taken in order to avoid
-unintentionally enabling this rebinding mechanism. NOINPUT MUST NOT
-be used, unless it is explicitly needed for the application, e.g., it
-MUST NOT be a default signing flag in a wallet
-implementation. Rebinding is only possible when the outputs the
-transaction may bind to all use the same public keys. Any public key
-that is used in a NOINPUT signature MUST only be used for outputs
-that the input may bind to, and they MUST NOT be used for transactions
-that the input may not bind to. For example an application SHOULD
-generate a new key-pair for the application instance using NOINPUT
-signatures and MUST NOT reuse them afterwards.
+As per [[bip-0341.mediawiki|BIP 341]], the parameter ''ext_flag'' is an integer in the range 0-127, used for indicating that extensions are added at the end of the message. The parameter ''key_version'' is an 8-bit unsigned value (an integer in the range 0-255) used for committing to the public key version.
+
+The following restrictions apply and cause validation failure if violated:
+* Using any undefined ''hash_type'' (not ''0x00'', ''0x01'', ''0x02'', ''0x03'', ''0x41'', ''0x42'', ''0x43'', ''0x81'', ''0x82'', ''0x83'', ''0xc1'', ''0xc2'', or ''0xc3'').
+* Using SIGHASH_SINGLE
without a "corresponding output" (an output with the same index as the input being verified).
+
+If these restrictions aren't violated, ''SigMsg118(hash_type,ext_flag)'' evaluates to the concatenation of the following data, in order (with byte size of each item listed in parentheses). Numerical values in 2, 4, or 8-byte items are encoded in little-endian.
+
+* Control:
+** ''hash_type'' (1).
+* Transaction data:
+** ''nVersion'' (4): the ''nVersion'' of the transaction.
+** ''nLockTime'' (4): the ''nLockTime'' of the transaction.
+** If ''hash_type & 0xc0'' is zero:
+*** ''sha_prevouts'' (32): the SHA256 of the serialization of all input outpoints.
+*** ''sha_amounts'' (32): the SHA256 of the serialization of all spent output amounts.
+*** ''sha_scriptpubkeys'' (32): the SHA256 of the serialization of all spent output ''scriptPubKey''s.
+*** ''sha_sequences'' (32): the SHA256 of the serialization of all input ''nSequence''.
+** If ''hash_type & 3'' does not equal SIGHASH_NONE
or SIGHASH_SINGLE
:
+*** ''sha_outputs'' (32): the SHA256 of the serialization of all outputs in CTxOut
format.
+* Data about this input:
+** ''spend_type'' (1): equal to ''(ext_flag * 2) + annex_present'', where ''annex_present'' is 0 if no annex is present, or 1 otherwise (the original witness stack has two or more witness elements, and the first byte of the last element is ''0x50'')
+** If ''hash_type & 0xc0'' is non-zero:
+*** If ''hash_type & 0xc0'' is SIGHASH_ANYONECANPAY
:
+**** ''outpoint'' (36): the COutPoint
of this input (32-byte hash + 4-byte little-endian).
+*** If ''hash_type & 0xc0'' is SIGHASH_ANYONECANPAY
or SIGHASH_ANYPREVOUT
:
+**** ''amount'' (8): value of the previous output spent by this input.
+**** ''scriptPubKey'' (35): ''scriptPubKey'' of the previous output spent by this input, serialized as script inside CTxOut
. Its size is always 35 bytes.
+*** ''nSequence'' (4): ''nSequence'' of this input.
+** If ''hash_type & 0xc0'' is zero:
+*** ''input_index'' (4): index of this input in the transaction input vector. Index of the first input is 0.
+** If an annex is present (the lowest bit of ''spend_type'' is set):
+*** ''sha_annex'' (32): the SHA256 of ''(compact_size(size of annex) || annex)'', where ''annex'' includes the mandatory ''0x50'' prefix.
+* Data about this output:
+** If ''hash_type & 3'' equals SIGHASH_SINGLE
:
+*** ''sha_single_output'' (32): the SHA256 of the corresponding output in CTxOut
format.
+
+Similarly, ''SigExt118(hash_type,key_version)'' evaluates to the concatenation of:
+
+* Extension:
+** If ''hash_type & 0xc0'' is not SIGHASH_ANYPREVOUTANYSCRIPT
:
+*** ''tapleaf_hash'' (32): the tapleaf hash as defined in [[bip-0341.mediawiki|BIP 341]]
+** ''key_version'' (1).
+** ''codesep_pos'' (4): the opcode position of the last executed OP_CODESEPARATOR
before the currently executed signature opcode, with the value in little endian (or ''0xffffffff'' if none executed). The first opcode in a script has a position of 0. A multi-byte push opcode is counted as one opcode, regardless of the size of data being pushed.
+
+Note that if ''hash_type & 0x40'' is zero, ''SigMsg118(hash_type,ext_flag) == SigMsg(hash_type,ext_flag)'', and ''SigExt118(hash_type,0x00) == ext'' (where ''ext'' is the message extension as defined in [[bip-0342.mediawiki|BIP 342]]).
+
+To verify a signature ''sig'' for a BIP 118 public key ''p'':
+
+* If the ''sig'' is 64 bytes long, return ''Verify(p, hashTapSigHash (0x00 || SigMsg118(0x00, 1) || SigExt118(0x00, 0x01), sig)'', where ''Verify'' is defined in [[bip-0340.mediawiki|BIP 340]].
+* If the ''sig'' is 65 bytes long, return ''sig[64] ≠ 0x00 and Verify(p, hashTapSighash (0x00 || SigMsg118(sig[64], 1) || SigExt118(sig[64], 0x01), sig[0:64])''.
+* Otherwise, fail.
+
+The key differences from [[bip-0342.mediawiki|BIP 342]] signature verification are:
+
+* In all cases, key_version
is set to the constant value 0x01
instead of 0x00
.['''Why change key_version?''' Changing ]key_version
ensures that if the same private key is used to generate both a [[bip-0342.mediawiki|BIP 342]] key and a BIP 118 public key, that a signature for the [[bip-0342.mediawiki|BIP 342]] key is not also valid for the BIP 118 public key (and vice-versa).
+* If SIGHASH_ANYPREVOUT
is set, the digest is calculated as if SIGHASH_ANYONECANPAY
was set, except outpoint
is not included in the digest.
+* If SIGHASH_ANYPREVOUTANYSCRIPT
is set, the digest is calculated as if SIGHASH_ANYONECANPAY
was set, except outpoint
, scriptPubKey
and tapleaf_hash
are not included in the digest.
+
+== Security ==
+
+==== Signature replay ====
+
+By design, SIGHASH_ANYPREVOUT
and SIGHASH_ANYPREVOUTANYSCRIPT
introduce additional potential for signature replay (that is they allow the same signature to be reused on a different transaction) when compared to SIGHASH_ALL
and SIGHASH_ANYONECANPAY
signatures.
+
+Both SIGHASH_ALL
and SIGHASH_ANYONECANPAY
signatures prevent signature replay by committing to one or more inputs, so replay of the signature is only possible if the same input can be spent multiple times, which is not possible on the Bitcoin blockchain (due to enforcement of [[bip-0030.mediawiki|BIP 30]]).
+With SIGHASH_ANYPREVOUT
signature replay is possible for different UTXOs with the same scriptPubKey
and the same value, while with SIGHASH_ANYPREVOUTANYSCRIPT
signature replay is possible for any UTXOs that reuse the same BIP 118 public key in one of their potential scripts.
+
+As a consequence, implementors MUST ensure that BIP 118 public keys are only reused when signature replay cannot cause loss of funds (eg due to other features of the protocol or other constraints on the transaction), or when such a loss of funds is acceptable.
+
+==== Malleability ====
+
+Use of SIGHASH_ANYPREVOUT
or SIGHASH_ANYPREVOUTANYSCRIPT
may introduce additional malleability vectors.
+
+In particular, a transaction authenticated using only ANYPREVOUT signatures is malleable to anyone able to provide an alternate input satisfied by the signature -- an input changed in this way would produce a new, valid transaction paying the same recipient, but with a different txid.
+Depending on the changes to the inputs, this might conflict with the original transaction (if some inputs remain shared) or might result in a double-payment to the recipient (if they do not).
+
+Further, for a chain of transactions using the same scriptPubKey
and value, and only authenticated via ANYPREVOUT signatures (as envisioned in eltoo for failure cases), it may be possible for any third party to malleate the transactions (and their txids) without having access to any of the private keys, particularly by omitting intermediate transactions.
+
+This form of malleation can be dealt with by the child transactions also using ANYPREVOUT signatures -- when a parent transaction is malleated, its children can be adjusted to reference the new txid as the input and the ANYPREVOUT signatures remain valid.
+
+However child transactions that are authorised by a SIGHASH_ALL
or SIGHASH_ANYONECANPAY
signature will need new signatures if their inputs are malleated in this way.
+This risk may be mitigated somewhat by using [[bip-0068.mediawiki|BIP 68]]/[[bip-0112.mediawiki|BIP 112]] relative time locks before spending a UTXO that had been authorised via an ANYPREVOUT signature with SIGHASH_ALL
or SIGHASH_ANYONECANPAY
: a relative timelock can ensure that the inputs have enough confirmations that they can only be replaced in the event of a large block reorg.
+Note that this approach has drawbacks: relative timelocks prevent fee-bumping via child-pays-for-parent, and have the obvious drawback of making the funds temporarily unusable until the timelock expires.
+
+==== Privacy considerations ====
+
+It is expected that ANYPREVOUT signatures will only be rarely used in practice.
+Protocol and wallet designers should aim to have their transactions use Taproot key path spends whenever possible, both for efficiency reasons due to the lower transaction weight, but also for privacy reasons to avoid third parties being able to distinguish their transactions from those of other protocols.
+
+Transactions that do use ANYPREVOUT signatures will therefore reveal information about the transaction, potentially including that cooperation was impossible, or what protocol or software was used (due to the details of the script).
+
+In order to maximise privacy, it is therefore recommended that protocol designers only use BIP 118 public keys in scripts that will be spent using at least one ANYPREVOUT signature, and either use key path spends or alternate scripts in the taproot merkle tree for any spends that can be authorised without ANYPREVOUT signatures.
+Following this recommendation may require additional script branches, which may mean disregarding this recommendation may result in a better tradeoff between cost and privacy in some circumstances.
+
+== Rationale ==
+
+
== Deployment ==
-The NOINPUT sighash flag is to be deployed during a regular segwit
-script update.
-== Backward compatibility ==
-As a soft fork, older software will continue to operate without
-modification. Non-upgraded nodes, however, will not verify the
-validity of the new sighash flag and will consider the transaction
-valid by default. Being only applicable to segwit transactions,
-non-segwit nodes will see an anyone-can-spend script and will consider
-it valid.
+TODO
-== Acknowledgments ==
+This may be deployed as a soft-fork either concurrent with, or subsequent to the deployment of [[bip-0340.mediawiki|BIP 340]], [[bip-0341.mediawiki|BIP 341]] and [[bip-0342.mediawiki|BIP 342]].
-The NOINPUT sighash flag was first proposed by Joseph Poon in
-February 2016[https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-February/012460.html], after being mentioned in the original
-Lightning paper[http://lightning.network/lightning-network.pdf]. A formal proposal was however
-deferred until after the activation of segwit. This proposal is a
-continuation of this discussion and attempts to formalize it in such a
-way that it can be included in the Bitcoin protocol. As such we'd like
-acknowledge Joseph Poon and Thaddeus Dryja as the original inventors
-of the NOINPUT sighash flag, and its uses in off-chain protocols.
+== Backwards compatibility ==
-== References ==
+As a soft fork, older software will continue to operate without modification.
+Nodes that have not upgraded to support [[bip-0341.mediawiki|BIP 341]] will see all taproot witness programs as anyone-can-spend scripts, and nodes that have upgraded to support [[bip-0341.mediawiki|BIP 341]] and [[bip-0342.mediawiki|BIP 342]] but not BIP 118 will simply treat any non-empty signature against a BIP 118 public key as valid.
+As such, nodes are strongly encourage to upgrade in order to fully validate signatures for the new public key type.
-
+Non-upgraded wallets can receive and send bitcoin from non-upgraded and upgraded wallets using SegWit version 0 programs, traditional pay-to-pubkey-hash, etc.
+Depending on the implementation, non-upgraded wallets may be able to send to SegWit version 1 programs if they support sending to [[bip-0350.mediawiki|BIP350]] Bech32m addresses and do not prevent the transaction from being broadcast due to considering the outputs non-standard.
-== Copyright ==
+== Revisions ==
+
+Apart from being based on Taproot rather than SegWit v0, the main differences to prior revisions of this BIP are:
+
+* The sighash flag has been renamed from "NOINPUT" to "ANYPREVOUT" to reflect that while any prevout may potentially be used with the signature, some aspects of the input are still committed to, namely the input nSequence value, and (optionally) the spending conditions and amount.
+* Previously NOINPUT would have worked for direct public key spends (assuming deployment was fleshed out in a way similar to BIP 141 P2WPKH and P2WSH), however this proposal only applies to signatures via tapscript, and not direct key path spends. This means that addresses must opt-in to the ability to be spent by a SIGHASH_ANYPREVOUT
or SIGHASH_ANYPREVOUTANYSCRIPT
signature by including an appropriate tapscript path when the address is created.
+* NOINPUT signatures do not commit to the output's spending conditions either via scriptPubKey
or the redeem/witness script. This behaviour is preserved when SIGHASH_ANYPREVOUTANYSCRIPT
is used, but when SIGHASH_ANYPREVOUT
is used, the signature now commits to scriptPubKey
and the tapscript.
+* NOINPUT signatures did commit to the input's amount. This behaviour is preserved when SIGHASH_ANYPREVOUT
is used, but not when SIGHASH_ANYPREVOUTANYSCRIPT
is used.
+* OP_CODESEPARATOR
in script will affect both SIGHASH_ANYPREVOUT
and SIGHASH_ANYPREVOUTANYSCRIPT
signatures, whereas it would not have in the previous draft.
+
+== Acknowledgements ==
+
+The SIGHASH_NOINPUT
flag was first proposed by Joseph Poon in [https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-February/012460.html February 2016], after being mentioned in the original [http://lightning.network/lightning-network-paper.pdf Lightning paper] by Joseph Poon and Thaddeus Dryja.
+This document is the result of discussions with many people and had direct input from Greg Maxwell, Jonas Nick, Pieter Wuille and others.
-This document is licensed under the BSD 3 Clause license.
diff --git a/bip-0125.mediawiki b/bip-0125.mediawiki
index 7dfdcbe3..e43ddb1a 100644
--- a/bip-0125.mediawiki
+++ b/bip-0125.mediawiki
@@ -171,13 +171,9 @@ Actual replacement may be unreliable until two conditions have been satisfied:
# Enough hash rate has upgraded to support replacement, allowing for reasonable probability that a replacement can be mined.
-==Client support==
+==Backwards compatibility==
-No known wallet currently creates transactions by default with
-nSequence set below (0xffffffff - 1), so no known existing wallet
-explicitly signals replaceability by default. No known popular wallet
-spends other users' unconfirmed transactions by default, so no known
-existing wallets signals inherited replaceability.
+At the time opt-in RBF support was added/proposed, no known wallet created transactions by default with nSequence set below (0xffffffff - 1), so no known wallet explicitly signaled replaceability by default. Also no known popular wallet spent other users' unconfirmed transactions by default, so no known wallets signaled inherited replaceability.
==See also==
diff --git a/bip-0129.mediawiki b/bip-0129.mediawiki
new file mode 100644
index 00000000..8719fe42
--- /dev/null
+++ b/bip-0129.mediawiki
@@ -0,0 +1,462 @@
+
+ BIP: 129
+ Layer: Applications
+ Title: Bitcoin Secure Multisig Setup (BSMS)
+ Author: Hugo Nguyen
+ Peter Gray
+ Marko Bencun
+ Aaron Chen
+ Rodolfo Novak
+ Comments-Summary: No comments yet.
+ Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0129
+ Status: Proposed
+ Type: Standards Track
+ Created: 2020-11-10
+ License: BSD-2-Clause
+
+
+==Introduction==
+
+===Abstract===
+
+This document proposes a mechanism to set up multisig wallets securely.
+
+===Copyright===
+
+This BIP is licensed under the 2-clause BSD license.
+
+===Motivation===
+
+The Bitcoin multisig experience has been greatly streamlined under [https://github.com/bitcoin/bips/blob/master/bip-0174.mediawiki BIP-0174
+(Partially Signed Bitcoin Transaction)]. However, what is still missing is a standardized process for setting up multisig wallets securely across different vendors.
+
+There are a number of concerns when it comes to setting up a multisig wallet:
+
+# Whether the multisig configuration, such as Signer membership, script type, derivation paths and number of signatures required, is correct and not tampered with.
+# Whether the keys or the multisig configuration are leaked during the setup.
+# Whether the Signer persists the multisig configuration in their respective storage, and under what format.
+# Whether the Signer's storage is tamper-proof.
+# Whether the Signer subsequently uses the multisig configuration to generate and verify receive and change addresses.
+
+An attacker who can modify the multisig configuration can steal or hold funds for ransom by duping the user into sending funds to the wrong address. An attacker who cannot modify the configuration but can learn about the keys and/or the configuration can monitor transactions in the wallet, resulting in loss of privacy.
+
+This proposal seeks to address concerns #1, #2 and #3: to mitigate the risk of tampering during the initial setup phase, and to define an interoperable multisig configuration format.
+
+Concerns #4 and #5 should be handled by Signers and are out of scope of this proposal.
+
+==Specification==
+
+===Prerequisites===
+This proposal assumes the parties in the multisig support [https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki BIP-0032], [https://github.com/bitcoin/bips/blob/master/bip-0322.mediawiki BIP-0322], [https://github.com/bitcoin/bitcoin/blob/master/doc/descriptors.md the descriptor language] and [https://tools.ietf.org/html/rfc3686 AES encryption].
+
+===File Extensions===
+All descriptor and key records should have a .bsms file extension. Encrypted data should have a .dat extension.
+
+===Roles===
+====Coordinator====
+
+The Coordinator initiates the multisig setup. The Coordinator determines what type of multisig is used and the exact policy script. If encryption is enabled, the Coordinator also distributes a shared secret or shared secrets to the parties involved for secure communication. The Coordinator gathers information from the Signers to generate a descriptor record. The Coordinator distributes the descriptor record back to the Signers.
+
+====Signer====
+
+The Signer is any software or hardware that controls the private keys and can sign using those keys. The Signer is a participating member in the multisig. Its responsibilities include providing its key record -- which contains a public key or an Extended Public Key (XPUB) -- to the Coordinator, verifying that its KEY is included in the descriptor record and persisting the descriptor record in its storage.
+
+===Setup Process===
+
+====Round 1====
+
+=====Coordinator=====
+
+* The Coordinator creates a new multisig wallet creation session. The Coordinator constructs the multisig script and its policy parameters, such as the required number of signatures and the total number of Signers (M and N ).
+* The session should expire after some time period determined by the Coordinator, e.g., 24 hours. The timeout allows the encryption key to have lower entropy.
+* If encryption is enabled, the Coordinator distributes a secret TOKEN to each Signer over a secure channel. The Signer can use the TOKEN to derive an ENCRYPTION_KEY . Refer to the [[#Encryption]] section below for details on the TOKEN , the key derivation function and the encryption scheme. Depending on the use case, the Coordinator can decide whether to share one common TOKEN for all Signers, or to have one per Signer.
+* If encryption is disabled, the TOKEN is set to 0x00 , and all the encryption/decryption steps below can be skipped.
+
+=====Signer=====
+
+* The Signer initiates the multisig wallet creation session by setting the TOKEN . The Signer derives an ENCRYPTION_KEY from the TOKEN . The Signer can keep the session open until a different value for the TOKEN is set.
+* The Signer generates a key record by prompting the user for a multisig derivation path and retrieves the KEY at that derivation path. Alternatively, the Signer can choose a path on behalf of the user. If the Signer chooses the path, it should try to avoid reusing KEY s for different wallets.
+* The first line in the record must be the specification version (BSMS 1.0 as of this writing). The second line must be the hex-encoded TOKEN . The third line must be the KEY . The KEY is a public key or an XPUB plus the key origin information, written in the descriptor-defined format, i.e.: [{master key fingerprint}/{derivation path}]{KEY} . The fourth line is a text description of the key, 80 characters maximum. The fifth line must be a SIG , whereas SIG is the signature generated by using the private key associated with the public key or XPUB to sign the first four lines. The signature should follow [https://github.com/bitcoin/bips/blob/master/bip-0322.mediawiki BIP-0322], legacy format accepted.
+* The Signer calculates the Message Authentication Code (MAC ) for the record. The first 16 bytes of the MAC serves as the Initialization Vector (IV ) for the encryption.
+* The Signer encrypts the key record with the ENCRYPTION_KEY and IV .
+* The Signer encodes the MAC and the ciphertext into hexadecimal format, then concatenates the results: (MAC || ciphertext) .
+
+====Round 2====
+
+=====Coordinator=====
+
+* The Coordinator gathers key records from all participating Signers. The Coordinator verifies that there are exactly N unique key records before the wallet setup session expires.
+* For each key record, the Coordinator extracts the MAC from the data, sets IV to the first 16 bytes of the MAC , then decrypts the ciphertext using the ENCRYPTION_KEY and IV .
+* The Coordinator verifies that the included MAC is valid given the plaintext.
+* The Coordinator verifies that the key records have compatible specification versions.
+* The Coordinator verifies that the included SIG is valid given the KEY .
+* If all key records look good, the Coordinator fills in all necessary information to generate a descriptor record.
+* The first line in the descriptor record must be the specification version (BSMS 1.0 as of this writing). The second line must be a descriptor or a descriptor template. The third line must be a comma-separated list of derivation path restrictions. The paths must start with / and use non-hardened derivation. If there are no template or restrictions, it must say No path restrictions . The fourth line must be the wallet's first address. If there are path restrictions, use the first address from the first path restriction.
+* The Coordinator calculates the MAC for the record. The first 16 bytes of the MAC serves as the IV for the encryption..
+* The Coordinator encrypts the descriptor record with the ENCRYPTION_KEY and IV .
+* The Coordinator encodes the MAC and the ciphertext into hexadecimal format, then concatenates the results: (MAC || ciphertext) .
+* The Coordinator sends the encrypted descriptor record to all participating Signers.
+
+=====Signer=====
+
+* The Signer imports the descriptor record.
+* The Signer extracts the MAC from the data, sets IV to the first 16 bytes of the MAC , then decrypts the ciphertext using the ENCRYPTION_KEY (derived from the open session) and IV .
+* The Signer verifies that the included MAC is valid given the plaintext.
+* The Signer verifies that it can support the included specification version.
+* The Signer verifies that it can support the descriptor or descriptor template.
+* The Signer checks that its KEY is included in the descriptor or descriptor template, using path and fingerprint information provided. The check must perform an exact match on the KEY s and not using shortcuts such as matching fingerprints, which is trivial to spoof.
+* The Signer verifies that it is compatible with the derivation path restrictions.
+* The Signer verifies that the wallet's first address is valid.
+* For confirmation, the Signer must display to the user the wallet's first address and policy parameters, including, but not limited to: the derivation path restrictions, M , N , and the position(s) of the Signer's own KEY in the policy script. The total number of Signers, N , is important to prevent a KEY insertion attack. The position is important for scripts where KEY order matters. When applicable, all positions of the KEY must be displayed. The full descriptor or descriptor template must also be available for review upon user request.
+* Parties must check with each other that all Signers have the same confirmation (except for the KEY positions).
+* If all checks pass, the Signer must persist the descriptor record in its storage.
+
+This completes the setup.
+
+===Encryption===
+
+====The Token====
+We define three modes of encryption.
+
+# NO_ENCRYPTION : the TOKEN is set to 0x00 . Encryption is disabled.
+# STANDARD : the TOKEN is a 64-bit nonce.
+# EXTENDED : the TOKEN is a 128-bit nonce.
+
+The TOKEN can be converted to one of these formats:
+* A decimal number (recommended). The number must not exceed the maximum value of the nonce.
+* A mnemonic phrase using [https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki BIP-0039] word list. This would be 6 words in STANDARD mode. This encoding is not recommended in EXTENDED mode as it can result in potential confusion between seed mnemonics and TOKEN mnemonics.
+* A QR code.
+* Other formats.
+
+The flexibility in the data format allows each Signer to customize the User Experience based on its respective capabilities.
+
+====Key Derivation====
+The key derivation function is [https://tools.ietf.org/html/rfc2898 PBKDF2], with PRF = SHA512. Specifically:
+
+DKey = PBKDF2(PRF, Password, Salt, c, dkLen)
+
+Whereas:
+
+* PRF = SHA512
+* Password = "No SPOF"
+* Salt = TOKEN
+* c = 2048
+* dkLen = 256
+* DKey = Derived ENCRYPTION_KEY
+
+====Encryption Scheme====
+The encryption scheme is [https://tools.ietf.org/html/rfc3686 AES-256-CTR].
+
+MAC = HMAC-SHA256(HMAC_Key, hex-encoded TOKEN || Data)
+
+IV = First 16 bytes of MAC
+
+Ciphertext = AES-256-CTR-Encrypt(Plaintext, DKey, IV)
+
+Plaintext = AES-256-CTR-Decrypt(Ciphertext, DKey, IV)
+
+Whereas:
+* DKey = ENCRYPTION_KEY
+* HMAC_Key = SHA256(ENCRYPTION_KEY )
+* Data = the plaintext, e.g. the entire key record in round 1 and the entire descriptor record in round 2
+
+The MAC is to be sent along with the key and descriptor record, as specified above. Because it is a MAC over the entire plaintext, this is essentially an [https://en.wikipedia.org/wiki/Authenticated_encryption#Encrypt-and-MAC_(E&M) Encrypt-and-MAC] form of authenticated encryption.
+
+===Descriptor Template===
+The output descriptor language only supports one-dimensional lists. This proposal introduces a descriptor template to represent multi-dimensional lists:
+
+XPUB/**
+
+Whereas /** can be replaced by any number of derivation path restrictions.
+
+A descriptor template must be accompanied by derivation path restrictions. Signers should expand the template into concrete descriptors by replacing /** with the restrictions.
+
+For example, the following template and derivation path restrictions:
+* wsh(sortedmulti(2,XPUB1/**,XPUB2/**))
+* /0/*,/1/*
+
+Should translate to two concrete descriptors:
+* wsh(sortedmulti(2,XPUB1/0/*,XPUB2/0/*))
+* wsh(sortedmulti(2,XPUB1/1/*,XPUB2/1/*))
+
+==QR Codes==
+For signers that use QR codes to transmit data, key and descriptor records can be converted to QR codes, following [https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2020-005-ur.md the BCR standard].
+
+Also refer to [https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2020-015-account.md UR Type Definition for BIP44 Accounts] and [https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2020-010-output-desc.md UR Type Definition for Bitcoin Output Descriptors] for more details.
+
+==Compatibility==
+This specification is not backwards compatible with existing multisig implementations.
+
+BSMS is opt-in, meaning existing multisig implementations can continue working as-is, with the caveat that they are likely to have various pitfalls. Some of the problems with existing solutions have been described in the [[#Motivation]] section.
+
+To comply with this standard, a Signer must be able to persist the descriptor record in its storage.
+
+To use BSMS for a multisig wallet, the user should wait until all participating Signers in the multisig have implemented BSMS.
+
+==Security==
+
+This proposal introduces two layers of protection. The first one is a temporary, secret TOKEN . The second one is the confirmation of the wallet's first address.
+
+The TOKEN is used to encrypt the two rounds of communication between the Signer and the Coordinator. A MAC is also generated from the TOKEN and plaintext to authenticate the data being exchanged. The TOKEN is only needed during the setup phase, and can be safely discarded afterwards. It is not recommended to use the same TOKEN for multiple wallet creation sessions.
+
+The wallet's first address, on the other hand, can be used to verify the integrity of the multisig configuration. An attacker who tampers with the multisig configuration must also change the wallet's first address. Parties must check with each other that all Signers confirm to the same address and policy parameters to reduce the chance of tampering.
+
+==Privacy==
+Encryption helps improve the privacy of the wallet by avoiding sharing keys and descriptors in plaintext.
+
+If the parties wish to have stronger privacy, it is recommended to use a higher number of bits for the TOKEN , and to completely erase knowledge of the TOKEN after the multisig wallet has been set up.
+
+==Test Vectors==
+
+===Mode: NO_ENCRYPTION with Public Keys===
+====ROUND 1====
+* Coordinator
+** M-of-N: 1/2
+** ADDRESS_TYPE: NATIVE_SEGWIT
+** TOKEN: 0x00
+
+* Signer 1
+** MASTER_KEY_FINGERPRINT: 59865f44
+** PRIVATE_KEY (m/48'/0'/0'/2'): L5TXU4SdD9e6QGgBjxeegJKxt4FgATLG1TCnFM8JLyEkFuyHEqNM
+** Public Key (m/48'/0'/0'/2'): 026d15412460ba0d881c21837bb999233896085a9ed4e5445bd637c10e579768ba
+** Legacy signature
+** signer_1_key.bsms :
+BSMS 1.0
+00
+[59865f44/48'/0'/0'/2']026d15412460ba0d881c21837bb999233896085a9ed4e5445bd637c10e579768ba
+Signer 1 key
+H6DXgqkCb353BDPkzppMFpOcdJZlpur0WRetQhIBqSn6DFzoQWBtm+ibP5wERDRNi0bxxev9B+FIvyQWq0s6im4=
+
+* Signer 2
+** MASTER_KEY_FINGERPRINT: b7044ca6
+** PRIVATE_KEY (m/48'/0'/0'/2'): KwT7BZDWjos4JAdfKi8NqF46Kj3rppTwN8KGhPbzmmugiZioFW3r
+** Public Key (m/48'/0'/0'/2'): 030baf0497ab406ff50cb48b4013abac8a0338758d2fd54cd934927afa57cc2062
+** Legacy signature
+** signer_2_key.bsms :
+BSMS 1.0
+00
+[b7044ca6/48'/0'/0'/2']030baf0497ab406ff50cb48b4013abac8a0338758d2fd54cd934927afa57cc2062
+Signer 2 key
+H08mGNGN+NxX/snt+6eX2Q1HjjfDkOtotglshHi7xdsBdIrTVMCQbgQ5SdACNZ0B2AJcifK11nJj43SvaitSemI=
+
+====ROUND 2====
+* Coordinator
+** my_multisig_wallet.bsms :
+BSMS 1.0
+wsh(sortedmulti(1,[59865f44/48'/0'/0'/2']026d15412460ba0d881c21837bb999233896085a9ed4e5445bd637c10e579768ba,[b7044ca6/48'/0'/0'/2']030baf0497ab406ff50cb48b4013abac8a0338758d2fd54cd934927afa57cc2062))#rzx9dffd
+No path restrictions
+bc1quqy523xu3l8che3s8vja8n33qtg0uyugr9l5z092s3wa50p8t7rqy6zumf
+
+===Mode: NO_ENCRYPTION ===
+====ROUND 1====
+* Coordinator
+** M-of-N: 2/2
+** ADDRESS_TYPE: NATIVE_SEGWIT
+** TOKEN: 0x00
+
+* Signer 1
+** MASTER_KEY_FINGERPRINT: 1cf0bf7e
+** PRIVATE_KEY (m/48'/0'/0'/2'): L3q1sg7iso1L3QfzB1riC9bQpqMynWyBeuLLSKwCDGkHkahB7MgU
+** XPUB (m/48'/0'/0'/2'): xpub6FL8FhxNNUVnG64YurPd16AfGyvFLhh7S2uSsDqR3Qfcm6o9jtcMYwh6DvmcBF9qozxNQmTCVvWtxLpKTnhVLN3Pgnu2D3pAoXYFgVyd8Yz
+** Legacy signature
+** signer_1_key.bsms :
+BSMS 1.0
+00
+[1cf0bf7e/48'/0'/0'/2']xpub6FL8FhxNNUVnG64YurPd16AfGyvFLhh7S2uSsDqR3Qfcm6o9jtcMYwh6DvmcBF9qozxNQmTCVvWtxLpKTnhVLN3Pgnu2D3pAoXYFgVyd8Yz
+Signer 1 key
+IB7v+qi1b+Xrwm/3bF+Rjl8QbIJ/FMQ40kUsOOQo1SqUWn5QlFWbBD8BKPRetfo1L1N7DmYjVscZNsmMrqRJGWw=
+
+* Signer 2
+** MASTER_KEY_FINGERPRINT: 4fc1dd4a
+** PRIVATE_KEY (m/48'/0'/0'/2'): L4JNkJfLBDyWfTLbKJ1H3w56GUMsvdfjCkzRo5RHXfJ6bdHqm6cN
+** XPUB (m/48'/0'/0'/2'): xpub6EebMbEps7ZcV3FYEnddRsvrFWDrt2tiPmCeM7pPXQEmphvq9ZfJ1LWFUDjf3vxCeBuPrfyGrMazWUsYsetrnHatQZVLJH7LsgCjtMqdzgj
+** Legacy signature
+** signer_2_key.bsms :
+BSMS 1.0
+00
+[4fc1dd4a/48'/0'/0'/2']xpub6EebMbEps7ZcV3FYEnddRsvrFWDrt2tiPmCeM7pPXQEmphvq9ZfJ1LWFUDjf3vxCeBuPrfyGrMazWUsYsetrnHatQZVLJH7LsgCjtMqdzgj
+Signer 2 key
+HzUa4Z76PFHMl54flIIF3XKiHZ+KbWjjxCEG5G3ZqZSqTd6OgTiFFLqq9PXJXdfYm6/cnL8IVWQgjFF9DQhIqQs=
+
+====ROUND 2====
+* Coordinator
+** my_multisig_wallet.bsms :
+BSMS 1.0
+wsh(sortedmulti(2,[1cf0bf7e/48'/0'/0'/2']xpub6FL8FhxNNUVnG64YurPd16AfGyvFLhh7S2uSsDqR3Qfcm6o9jtcMYwh6DvmcBF9qozxNQmTCVvWtxLpKTnhVLN3Pgnu2D3pAoXYFgVyd8Yz/**,[4fc1dd4a/48'/0'/0'/2']xpub6EebMbEps7ZcV3FYEnddRsvrFWDrt2tiPmCeM7pPXQEmphvq9ZfJ1LWFUDjf3vxCeBuPrfyGrMazWUsYsetrnHatQZVLJH7LsgCjtMqdzgj/**))
+/0/*,/1/*
+bc1qrgc6p3kylfztu06ysl752gwwuekhvtfh9vr7zg43jvu60mutamcsv948ej
+
+===Mode: STANDARD Encryption===
+====ROUND 1====
+* Coordinator
+** M-of-N: 2/2
+** ADDRESS_TYPE: NATIVE_SEGWIT
+** TOKEN (hex): a54044308ceac9b7
+*** TOKEN (decimal): 11907592390080907703
+*** TOKEN (mnemonic): pipe acquire around border prosper swift
+** ENCRYPTION_KEY (hex): 7673ffd9efd70336a5442eda0b31457f7b6cdf7b42fe17f274434df55efa9839
+
+* Signer 1
+** MASTER_KEY_FINGERPRINT: b7868815
+** PRIVATE_KEY (m/48'/0'/0'/2'): KyKvR9kf8r7ZVtdn3kB9ifipr6UKnTNTpWJkGZbHwARDCz5iZ39E
+** XPUB (m/48'/0'/0'/2'): xpub6FA5rfxJc94K1kNtxRby1hoHwi7YDyTWwx1KUR3FwskaF6HzCbZMz3zQwGnCqdiFeMTPV3YneTGS2YQPiuNYsSvtggWWMQpEJD4jXU7ZzEh
+** Legacy signature
+** signer_1_key.bsms :
+BSMS 1.0
+a54044308ceac9b7
+[b7868815/48'/0'/0'/2']xpub6FA5rfxJc94K1kNtxRby1hoHwi7YDyTWwx1KUR3FwskaF6HzCbZMz3zQwGnCqdiFeMTPV3YneTGS2YQPiuNYsSvtggWWMQpEJD4jXU7ZzEh
+Signer 1 key
+H8DYht5P6ko0bQqDV6MtUxpzBSK+aVHxbvMavA5byvLrOlCEGmO1WFR7k2wu42J6dxXD8vrmDQSnGq5MTMMbZ98=
+
+* Signer 1 encryption
+** HMAC_KEY (hex): 3d4c422806ba8964c9ee45070cd675c024d96648a0ddb4001325818c84951de2
+** MAC (hex): fbdbdb64e6a8231c342131d9f13dcd5a954b4c5021658fa5afcb3fc74dc82706
+** IV (hex) : fbdbdb64e6a8231c342131d9f13dcd5a
+** CIPHERTEXT (hex): 53f491cfd1431c292d922ea5a5dec3eb8ddaa6ed38ae109e7b040f0f23013e89a89b4d27476761a01197a3277850b2bc1621ae626efe65f2081eec6eb571c4f787bf1c49d061b43f70fd73cb3f37fa591d2400973ac0644c8941a83f1d4155e98f01fa2fdeb9f86c2e2413154fd18566a28fb0d9d8bd6172efabcfa6dab09ee7029bf3dd43376df52c118a6d291ec168f4ec7f7df951dfc6135fd8cb4b234da62eaea6017dfe5ca418f083e02e3aba2962ba313ba17b6468c7672fb218329a9f3fe4e4887fb87dac57c63ebff0e715a44498d18de8afc10e1cfeb46a1fc65ce871fef8a43b289305433a90c342d025aa4c19454fcfbcf911e9e2f928d5affd0536a6ddc2e816
+** signer_1_key.dat : fbdbdb64e6a8231c342131d9f13dcd5a954b4c5021658fa5afcb3fc74dc8270653f491cfd1431c292d922ea5a5dec3eb8ddaa6ed38ae109e7b040f0f23013e89a89b4d27476761a01197a3277850b2bc1621ae626efe65f2081eec6eb571c4f787bf1c49d061b43f70fd73cb3f37fa591d2400973ac0644c8941a83f1d4155e98f01fa2fdeb9f86c2e2413154fd18566a28fb0d9d8bd6172efabcfa6dab09ee7029bf3dd43376df52c118a6d291ec168f4ec7f7df951dfc6135fd8cb4b234da62eaea6017dfe5ca418f083e02e3aba2962ba313ba17b6468c7672fb218329a9f3fe4e4887fb87dac57c63ebff0e715a44498d18de8afc10e1cfeb46a1fc65ce871fef8a43b289305433a90c342d025aa4c19454fcfbcf911e9e2f928d5affd0536a6ddc2e816
+
+* Signer 2
+** MASTER_KEY_FINGERPRINT: eedff89a
+** PRIVATE_KEY (m/48'/0'/0'/2'): Kz1ijnkDXmc65NWTYdg47DDaQgSGJAPfhJG9Unm36oqZPpPXuNR6
+** XPUB (m/48'/0'/0'/2'): xpub6EhJvMneoLWAf8cuyLBLQiKiwh89RAmqXEqYeFuaCEHdHwxSRfzLrUxKXEBap7nZSHAYP7Jfq6gZmucotNzpMQ9Sb1nTqerqW8hrtmx6Y6o
+** Legacy signature
+** signer_2_key.bsms :
+BSMS 1.0
+a54044308ceac9b7
+[eedff89a/48'/0'/0'/2']xpub6EhJvMneoLWAf8cuyLBLQiKiwh89RAmqXEqYeFuaCEHdHwxSRfzLrUxKXEBap7nZSHAYP7Jfq6gZmucotNzpMQ9Sb1nTqerqW8hrtmx6Y6o
+Signer 2 key
+H/IHW5dMGYsrRdYEz3ux+kKnkWBtxHzfYkREpnYbco38VnMvIxCbDuf7iu6960qDhBLR/RLjlb9UPtLmCMbczDE=
+
+* Signer 2 encryption
+** HMAC_KEY (hex): 3d4c422806ba8964c9ee45070cd675c024d96648a0ddb4001325818c84951de2
+** MAC (hex): 383d05b7351a2cef7cca2850450f5efbbc4a3f8ea35707dda87a3692f0f2ebae
+** IV (hex) : 383d05b7351a2cef7cca2850450f5efb
+** CIPHERTEXT (hex): 71860b7c69f3a7665c3c3e85c45735bff78535a37ec6610b724627c73696820d519a9251703b17626b63898580233bebbb310aedbc370224b044ee19600bfe583445a6f26fb9bb5790bae516892655adb0e5dfc12be4609c2e0818d4f1f3bfccc4cd1a36f419d6cd842c913ae81eef4865ad473c32c3ee69cd98d6d0a088e2abdd01fe68b5c0503bb9183f9a912506204e5a9c6bd5a1626ff7eac30312a0b85004307c525e52fa3ad45a0b02eabc8cfaea0215bb6e60ee5f32d6673955290e008fbaef362977a21fd9830e3a604f9bb318cdcde456eae91dbedaa069bcd1efb0f981d5b0e502bd4dada903205458a00914887226a8dde317c02a8be4342acb97a8fee79fbe23
+** signer_2_key.dat : 383d05b7351a2cef7cca2850450f5efbbc4a3f8ea35707dda87a3692f0f2ebae71860b7c69f3a7665c3c3e85c45735bff78535a37ec6610b724627c73696820d519a9251703b17626b63898580233bebbb310aedbc370224b044ee19600bfe583445a6f26fb9bb5790bae516892655adb0e5dfc12be4609c2e0818d4f1f3bfccc4cd1a36f419d6cd842c913ae81eef4865ad473c32c3ee69cd98d6d0a088e2abdd01fe68b5c0503bb9183f9a912506204e5a9c6bd5a1626ff7eac30312a0b85004307c525e52fa3ad45a0b02eabc8cfaea0215bb6e60ee5f32d6673955290e008fbaef362977a21fd9830e3a604f9bb318cdcde456eae91dbedaa069bcd1efb0f981d5b0e502bd4dada903205458a00914887226a8dde317c02a8be4342acb97a8fee79fbe23
+
+====ROUND 2====
+*Coordinator
+** my_multisig_wallet.bsms :
+BSMS 1.0
+wsh(sortedmulti(2,[b7868815/48'/0'/0'/2']xpub6FA5rfxJc94K1kNtxRby1hoHwi7YDyTWwx1KUR3FwskaF6HzCbZMz3zQwGnCqdiFeMTPV3YneTGS2YQPiuNYsSvtggWWMQpEJD4jXU7ZzEh/**,[eedff89a/48'/0'/0'/2']xpub6EhJvMneoLWAf8cuyLBLQiKiwh89RAmqXEqYeFuaCEHdHwxSRfzLrUxKXEBap7nZSHAYP7Jfq6gZmucotNzpMQ9Sb1nTqerqW8hrtmx6Y6o/**))
+/0/*,/1/*
+bc1qhs4u273g4azq7kqqpe6vh5wfhasfmrq7nheyzsnq77humd7rwtkqagvakf
+
+*Coordinator encryption
+** HMAC_KEY (hex): 3d4c422806ba8964c9ee45070cd675c024d96648a0ddb4001325818c84951de2
+** MAC (hex): 734ce791b466861945e1ef6f74c63faec590793de54831f0036b28d08714b71a
+** IV (hex) : 734ce791b466861945e1ef6f74c63fae
+** CIPHERTEXT (hex): 273cad18a5e1eff37dba6d850749594c9a3fd32b2069e8c69983ea269c5044b6bcaea26d9dbc8ad5d28bb8abfa02e3bfc7632fcc5c2b76e9abb1982ff11295858cfe44a8b97110ae970f58fff3fb6477f38ca9609eec78eedb1d640eaba489fd5e41e787b8d0bde48f1fa99cca641cabbee0f513fb1040cb73df10a57c9a34e4efcb069cd4c75467442c15d878ed9f40e3dffb98294931a6da4f444ae46f739b7fe002ce19fcfe71b05b9783d797ba45d568febbc8a2b0850da67f349d8567342352e1712c3d2a7ea1b2721df5efdb844431f0e5dcfa4acacb194c20785c9bb6dde90d64352fc913e9073b3b416be713bcc7632c821bbfddafa6199d471c54fb899f347f5fc706787ccaa82332dc8b93aeb3de3497d8e5c75f0f5d718c74bc6f8194fe999948e517f1c98398d9cb907d200f1d045394704b074dfb10e587f54fd78e95ef4bcbe77bf1376b390c3f47c91c12b2ed14073ea56bceab41f924302e62183c456b06d96b3da30439cb4320c764a0d6d1b3dabc06fc
+** my_multisig_wallet.dat : 734ce791b466861945e1ef6f74c63faec590793de54831f0036b28d08714b71a273cad18a5e1eff37dba6d850749594c9a3fd32b2069e8c69983ea269c5044b6bcaea26d9dbc8ad5d28bb8abfa02e3bfc7632fcc5c2b76e9abb1982ff11295858cfe44a8b97110ae970f58fff3fb6477f38ca9609eec78eedb1d640eaba489fd5e41e787b8d0bde48f1fa99cca641cabbee0f513fb1040cb73df10a57c9a34e4efcb069cd4c75467442c15d878ed9f40e3dffb98294931a6da4f444ae46f739b7fe002ce19fcfe71b05b9783d797ba45d568febbc8a2b0850da67f349d8567342352e1712c3d2a7ea1b2721df5efdb844431f0e5dcfa4acacb194c20785c9bb6dde90d64352fc913e9073b3b416be713bcc7632c821bbfddafa6199d471c54fb899f347f5fc706787ccaa82332dc8b93aeb3de3497d8e5c75f0f5d718c74bc6f8194fe999948e517f1c98398d9cb907d200f1d045394704b074dfb10e587f54fd78e95ef4bcbe77bf1376b390c3f47c91c12b2ed14073ea56bceab41f924302e62183c456b06d96b3da30439cb4320c764a0d6d1b3dabc06fc
+
+===Mode: EXTENDED Encryption===
+====ROUND 1====
+*Coordinator
+** M-of-N: 2/3
+** ADDRESS_TYPE: NESTED_SEGWIT
+** TOKEN for Signer 1 (hex): 108a2360adb302774eb521daebbeda5e
+*** TOKEN (decimal): 21984902443033505423410071144203475550
+*** ENCRYPTION_KEY (hex): 63dc1e57dfdc21fa11109d5088be01fb8078a383d2296925ad2b7612b7179777
+** TOKEN for Signer 2 (hex): d3fabc873b98165254fe18a71b5335b0
+*** TOKEN (decimal): 281769005132501859744421970528095647152
+*** ENCRYPTION_KEY (hex): 3dc860a53471ec03af14617fef60921cf215b45a9d684462fa65b9d804ad3ee7
+** TOKEN for Signer 3 (hex): 78a7d5e7549453d719150de5459c9ce5
+*** TOKEN (decimal): 160378811550692397333855096016467696869
+*** ENCRYPTION_KEY (hex): 62b90b4c08c03a0ee872e57aae73f9acfafb6cc09d20b5c9bc0bafaef33619db
+
+* Signer 1
+** MASTER_KEY_FINGERPRINT: 793cc70b
+** PRIVATE_KEY (m/48'/0'/0'/1'): L1ZEgZ4zNYxyNc8UyeqwyKW1UHVMp9sxwPgSi3s9SW8mc7KsiSwJ
+** XPUB (m/48'/0'/0'/1'): xpub6ErVmcYYHmavsMgxEcTZyzN5sqth1ZyRpFNJC26ij1wYGC2SBKYrgt9yariSbn7HLRoZUvhUhmPfsRTPrdhhGFscpPZzmch6UTdmRP1aZUj
+** Legacy signature
+** signer_1_key.bsms :
+BSMS 1.0
+108a2360adb302774eb521daebbeda5e
+[793cc70b/48'/0'/0'/1']xpub6ErVmcYYHmavsMgxEcTZyzN5sqth1ZyRpFNJC26ij1wYGC2SBKYrgt9yariSbn7HLRoZUvhUhmPfsRTPrdhhGFscpPZzmch6UTdmRP1aZUj
+Signer 1 key
+ILG47LpCtjoD9UxL87jo5QFqA90t8g9fDQp/KBojdKgPPGB1pMx2bf9hPdORNZIOdCc/2+Gs6AOs3BEK9ubIuBw=
+
+* Signer 1 encryption
+** HMAC_KEY (hex): 1162cdace4ac9fcde1f96924b93714143d057a701de83ebaed248d1c9154f9fd
+** MAC (hex): ea12776c73de4bd5ea57c2d19eb8e0be856ac0d7f5651f7b74be4563d61ba5b1
+** IV (hex) : ea12776c73de4bd5ea57c2d19eb8e0be
+** CIPHERTEXT (hex): a36f34232bff47a853092654a718fea4f5f57d6a1f3d38fede04e2414da12c90cefc24ef662f736886d9a7fd6e7db636ca47217803c86b7fbcebe4ad6b71cffc261069c135bd2b2430fb2b446ff0203df34fbbc6801243e8a930b9d0cd3a9b160b8dcdc9131ce6e97641e6314b3285ff341013f302e308c1b2eba7ced0103a8999fe2bd86f844392938e7926cd26d023b764d0b8ff92b2fbdf995884c738414b83563ef2a0050279bf46d0e8271ea5d6af8154847c5736129a7a83a35a3cc747b2be4b389886cb57456678353b60473ebc4ab85d9c9131a17a1e288717343d9008825b16c48d7e93927f37b530033192c67b70dec0411a3e5952d2525c7eb80721676e1a6299248c17f8078202f3bb0932e9f263b0ab
+** signer_1_key.dat : ea12776c73de4bd5ea57c2d19eb8e0be856ac0d7f5651f7b74be4563d61ba5b1a36f34232bff47a853092654a718fea4f5f57d6a1f3d38fede04e2414da12c90cefc24ef662f736886d9a7fd6e7db636ca47217803c86b7fbcebe4ad6b71cffc261069c135bd2b2430fb2b446ff0203df34fbbc6801243e8a930b9d0cd3a9b160b8dcdc9131ce6e97641e6314b3285ff341013f302e308c1b2eba7ced0103a8999fe2bd86f844392938e7926cd26d023b764d0b8ff92b2fbdf995884c738414b83563ef2a0050279bf46d0e8271ea5d6af8154847c5736129a7a83a35a3cc747b2be4b389886cb57456678353b60473ebc4ab85d9c9131a17a1e288717343d9008825b16c48d7e93927f37b530033192c67b70dec0411a3e5952d2525c7eb80721676e1a6299248c17f8078202f3bb0932e9f263b0ab
+
+* Signer 2
+** MASTER_KEY_FINGERPRINT: b3118e52
+** PRIVATE_KEY (m/48'/0'/0'/1'): L4SnPjcHszMg3Wi2YYxEYnzM2zFeFkFr5NcLZ18YQeyJwaSFbTud
+** XPUB (m/48'/0'/0'/1'): xpub6Du5Jn6eYZE96ccmAc1ZTFPzdnzrvqfG4mpamDun2qZYKywoiQJMCbS3kWWMr6U3XW6s125RLsaPABWgv2yA749ieaMe67FxkTjMsbcxCch
+** Legacy signature
+** signer_2_key.bsms :
+BSMS 1.0
+d3fabc873b98165254fe18a71b5335b0
+[b3118e52/48'/0'/0'/1']xpub6Du5Jn6eYZE96ccmAc1ZTFPzdnzrvqfG4mpamDun2qZYKywoiQJMCbS3kWWMr6U3XW6s125RLsaPABWgv2yA749ieaMe67FxkTjMsbcxCch
+Signer 2 key
+IDK4d/oO0pgfrwRu4Zb8vqlPEmJb9aKT1K2CCnI3RKepVAKs3fZsBrypcCdQfUy1TG/3O5vAR3gjldxcCA1Wzg8=
+
+* Signer 2 encryption
+** HMAC_KEY (hex): 43a4e704bd1bade703023004b00290f1a7b005474a581d869a217068eedf3f57
+** MAC (hex): 4a3ff970d027010e83b4fbf2845a23907a301b3df692a9265e2ca679697ac718
+** IV (hex) : 4a3ff970d027010e83b4fbf2845a2390
+** CIPHERTEXT (hex): c8f4a6a6714eff90aa48cbefe6750c2ee3cc72182eb455e964f0ba59ada3ecd758c29f0fab7e33aaa82a340a18d9c793ddab09dc7e714864faac1ecea370d4f102533b739da38aa0491433f35eadec08f203685f04d1f6ec35d397d99e4f8096a5691075e3f54fd9ff58faf947f276bbe1031f827b274bd2f60fcb526add7058889104b189d7da22ac7be1f7ddd380bbebd5c6983a8a3c5fa86913e3d23c40935072ce03d9bdeb07791dc836d44b4d4c62f364d0e4f3580369ea8f6ebb774b7fda4a7ac6f5ae6b2f52b10cd71bdf3cdb5889e77d5eb1f2f647b798cdd6b3e5b964c9265daea3668d7e4cb53f724151923da1a87bbcd2abd8b164de474d865c51af69885431d26f88a5c8eea7d0dfdb52ca622017808a
+** signer_2_key.dat : 4a3ff970d027010e83b4fbf2845a23907a301b3df692a9265e2ca679697ac718c8f4a6a6714eff90aa48cbefe6750c2ee3cc72182eb455e964f0ba59ada3ecd758c29f0fab7e33aaa82a340a18d9c793ddab09dc7e714864faac1ecea370d4f102533b739da38aa0491433f35eadec08f203685f04d1f6ec35d397d99e4f8096a5691075e3f54fd9ff58faf947f276bbe1031f827b274bd2f60fcb526add7058889104b189d7da22ac7be1f7ddd380bbebd5c6983a8a3c5fa86913e3d23c40935072ce03d9bdeb07791dc836d44b4d4c62f364d0e4f3580369ea8f6ebb774b7fda4a7ac6f5ae6b2f52b10cd71bdf3cdb5889e77d5eb1f2f647b798cdd6b3e5b964c9265daea3668d7e4cb53f724151923da1a87bbcd2abd8b164de474d865c51af69885431d26f88a5c8eea7d0dfdb52ca622017808a
+
+* Signer 3
+** MASTER_KEY_FINGERPRINT: 842bd2ed
+** PRIVATE_KEY (m/48'/0'/0'/1'): L1ehZHpo2UFHc1yaBWDU4bKVycUwcU2TESm92wbfq6xK6qpZZJP6
+** XPUB (m/48'/0'/0'/1'): xpub6Ex81KopPkEt9hJiWHabYy8LNsSR4A7sUQoFBk9dR8XxHrr4p9HrYWN3NCf5uwfopHnQkCG7FYnZMztKbtRtbh6tzZC4xtHPbmVVxRSN7ic
+** Legacy signature
+** signer_3_key.bsms :
+BSMS 1.0
+78a7d5e7549453d719150de5459c9ce5
+[842bd2ed/48'/0'/0'/1']xpub6Ex81KopPkEt9hJiWHabYy8LNsSR4A7sUQoFBk9dR8XxHrr4p9HrYWN3NCf5uwfopHnQkCG7FYnZMztKbtRtbh6tzZC4xtHPbmVVxRSN7ic
+Signer 3 key
+IL77mML0xo/O9dJn0T5EpQLuyRPPrdpgVJbtsdAugW5iX0MQ3Ci0f8jVnXu68Xm07CYjYGKX8af72jmkQKhNud0=
+
+* Signer 3 encryption
+** HMAC_KEY (hex): ab93ce7bf0f91c62a66d00ea9bf5e5c00b854ee2cfc2fb06f6eeff738abcdc26
+** MAC (hex): e82cfcccbd4bd4d3b76e28133eecd13f7362f4a8b4c4baa3e5f6ba2dfb4d69b8
+** IV (hex) : e82cfcccbd4bd4d3b76e28133eecd13f
+** CIPHERTEXT (hex): b44433f0b564ec35a1e71371f25844088084b47402c90d52fee7237167b58a60a28c234af9123e104773136e8446d799541c8566882787caee7cd1fa8628aba63aa9e9d7cca0ddee92f96dd881535b19a131a1f487a1909e42d62945fd0ba08dacd7dc09a22ffe47e0410b8b85df92e4a8bbf9b46f0062da02e3ae94144a00bae917acc1246d8d1a4dca105708f55379caefef9d4c152f56b65ab4bd7b48f60233f57ba6d705387c79aeaa2a279e3314004bf16fcd7e7d2adef34b0ab3c22bc5461f2c09dce69065605e4fb96958c55984391712b3547e3914ad4ecca2c088be280dfcfe374a112515674aeca57b885e81dbef6a353ca387f4514db3158eb69f0d2725d42ad8102c05c26ad501d48b889c624035ead4
+** signer_3_key.dat : e82cfcccbd4bd4d3b76e28133eecd13f7362f4a8b4c4baa3e5f6ba2dfb4d69b8b44433f0b564ec35a1e71371f25844088084b47402c90d52fee7237167b58a60a28c234af9123e104773136e8446d799541c8566882787caee7cd1fa8628aba63aa9e9d7cca0ddee92f96dd881535b19a131a1f487a1909e42d62945fd0ba08dacd7dc09a22ffe47e0410b8b85df92e4a8bbf9b46f0062da02e3ae94144a00bae917acc1246d8d1a4dca105708f55379caefef9d4c152f56b65ab4bd7b48f60233f57ba6d705387c79aeaa2a279e3314004bf16fcd7e7d2adef34b0ab3c22bc5461f2c09dce69065605e4fb96958c55984391712b3547e3914ad4ecca2c088be280dfcfe374a112515674aeca57b885e81dbef6a353ca387f4514db3158eb69f0d2725d42ad8102c05c26ad501d48b889c624035ead4
+
+====ROUND 2====
+* Coordinator
+** my_multisig_wallet.bsms :
+BSMS 1.0
+sh(wsh(multi(2,[793cc70b/48'/0'/0'/1']xpub6ErVmcYYHmavsMgxEcTZyzN5sqth1ZyRpFNJC26ij1wYGC2SBKYrgt9yariSbn7HLRoZUvhUhmPfsRTPrdhhGFscpPZzmch6UTdmRP1aZUj/**,[b3118e52/48'/0'/0'/1']xpub6Du5Jn6eYZE96ccmAc1ZTFPzdnzrvqfG4mpamDun2qZYKywoiQJMCbS3kWWMr6U3XW6s125RLsaPABWgv2yA749ieaMe67FxkTjMsbcxCch/**,[842bd2ed/48'/0'/0'/1']xpub6Ex81KopPkEt9hJiWHabYy8LNsSR4A7sUQoFBk9dR8XxHrr4p9HrYWN3NCf5uwfopHnQkCG7FYnZMztKbtRtbh6tzZC4xtHPbmVVxRSN7ic/**)))
+/0/*,/1/*
+3GzMtFXahiu4TpGNGFc4bHMvAcvz5vVQrT
+
+* Send to Signer 1:
+** HMAC_KEY (hex): 1162cdace4ac9fcde1f96924b93714143d057a701de83ebaed248d1c9154f9fd
+** MAC (hex): 01bf557b6d44b3fbf07f8ec155cbdec42d85d856e174342563dd83b40ad7c025
+** IV (hex) : 01bf557b6d44b3fbf07f8ec155cbdec4
+** CIPHERTEXT (hex): 617ed25b4b8fd88b806cbebcc1731b071465514a805f7ba2de60e291bc9493f31aa0f9b0665ba822cf9a2e21c02649b5c3f7dbad317ae898292cb6fe992520f68c0ebe9d1434b348af10453f1be0a392a616d43ba21e5e7fa3c995dce54db947fe5dbad4a9a77f37b3aef58c54ee3e496c8312d3033359aed0de8cf28b82035ee7a38c9b23c9d95682fb15936bf2247546d2ba9b3ada605f5c89f0a3bbaa86cb4b5dded9a65004912c0afbbfd01f0115447f5625e8523f9de16165d32c4b21103d8ac965e2f7e17641ee1a8c5902e8dbb461c6c7d05141f7bba66b8b3608037fb251b55fa461c9441c6427921545a34a1798127d5bf9cc92423f7e62c769e232c65db8cc5124577012d49941143c3b4758212a8afa0475c9b3597da2e99d585039339b7d73611aa277878d212875051683053db9c630391e0b32356523e9fa8a58a334e16fe6650472f336ddaa8c587992b6c0c0e480b680261579a11cf9d036614abc113dde53653273f5ce82ea0bc10e38ca52ac66838aa49ff46c3a7d5096db439c15d3c2e8de55e4ac7315a57eb9997f219c378af86c858867ce583ed84e4d9c68aecfbca9ebff16b0ac91531125e273b215db688ffe52c8033eb78914b87c0fa2001c52e90c92765712e50384ddcf4d0953ac3cc8137abcb2a85d603a6cc207472677
+** my_multisig_wallet_for_signer_1.dat : 01bf557b6d44b3fbf07f8ec155cbdec42d85d856e174342563dd83b40ad7c025617ed25b4b8fd88b806cbebcc1731b071465514a805f7ba2de60e291bc9493f31aa0f9b0665ba822cf9a2e21c02649b5c3f7dbad317ae898292cb6fe992520f68c0ebe9d1434b348af10453f1be0a392a616d43ba21e5e7fa3c995dce54db947fe5dbad4a9a77f37b3aef58c54ee3e496c8312d3033359aed0de8cf28b82035ee7a38c9b23c9d95682fb15936bf2247546d2ba9b3ada605f5c89f0a3bbaa86cb4b5dded9a65004912c0afbbfd01f0115447f5625e8523f9de16165d32c4b21103d8ac965e2f7e17641ee1a8c5902e8dbb461c6c7d05141f7bba66b8b3608037fb251b55fa461c9441c6427921545a34a1798127d5bf9cc92423f7e62c769e232c65db8cc5124577012d49941143c3b4758212a8afa0475c9b3597da2e99d585039339b7d73611aa277878d212875051683053db9c630391e0b32356523e9fa8a58a334e16fe6650472f336ddaa8c587992b6c0c0e480b680261579a11cf9d036614abc113dde53653273f5ce82ea0bc10e38ca52ac66838aa49ff46c3a7d5096db439c15d3c2e8de55e4ac7315a57eb9997f219c378af86c858867ce583ed84e4d9c68aecfbca9ebff16b0ac91531125e273b215db688ffe52c8033eb78914b87c0fa2001c52e90c92765712e50384ddcf4d0953ac3cc8137abcb2a85d603a6cc207472677
+
+* Send to Signer 2:
+** HMAC_KEY (hex): 43a4e704bd1bade703023004b00290f1a7b005474a581d869a217068eedf3f57
+** MAC (hex): 974ba77900c43c463dadaa6eaf24aaeb1b25b443cf155229b719bcbf8b343092
+** IV (hex) : 974ba77900c43c463dadaa6eaf24aaeb
+** CIPHERTEXT (hex): 86288c97a6341974a35015f97fbbc8db7655639c839fc438706f82fce36a82dd17e2d4d4a674516c4fc5c3a33d6097dd8fc5c6605018946741ed9f58d8fe530a808f16f0dd705cacfd273e34a158bd7566774dd31506b8280e448fabb72d0e7dfc05cee1142b61921dfaf0b0039d885cc0aa76c429025efc2ba49a8af15b58e75a5a83ba4838a9a4c9f13725f5aecefd8511513d93797f37b93150b9dca725685883188e39142dd8d3cf4b617c7936bdb3875415bbf6dfb2fe1a39ae2aed9fd2909aebd0355a5cc9a55bcb84048c851a1873948e495180f336edeb63f54bcf83feaa4d2453251260e24293e49815c2369c1c045083c412c973987fd7c9296a71cda424823ed32380ba442394500b7d2d2335818099090aaf08ca4e180869c546f58da4cb4ff0f95b796a35c40ea455e2ddd3e08bc494ffddc706aaf4d479f4f359e6a89a90df7c9b8f23cab355855a72b90795a0db83a96bce0dd4f77e3f58c0957b4ffe9663251565098e6c31fd4bbf3e1295faaff05e29912d9c37cb944da379a9b2193b466910d05a681e53a2dbe5aa18a2b4874153fe36d8a1aa4cc6e612bd6dbc9abb8e1e61b927fc5458d8e1be9536cd462e4c37672af7928c39e94bdc124a2da7b1bd3cad2cfe559adc33e62eb45bff89db8a47a72dda4f49f21c01a9432f4802a1
+** my_multisig_wallet_for_signer_2.dat : 974ba77900c43c463dadaa6eaf24aaeb1b25b443cf155229b719bcbf8b34309286288c97a6341974a35015f97fbbc8db7655639c839fc438706f82fce36a82dd17e2d4d4a674516c4fc5c3a33d6097dd8fc5c6605018946741ed9f58d8fe530a808f16f0dd705cacfd273e34a158bd7566774dd31506b8280e448fabb72d0e7dfc05cee1142b61921dfaf0b0039d885cc0aa76c429025efc2ba49a8af15b58e75a5a83ba4838a9a4c9f13725f5aecefd8511513d93797f37b93150b9dca725685883188e39142dd8d3cf4b617c7936bdb3875415bbf6dfb2fe1a39ae2aed9fd2909aebd0355a5cc9a55bcb84048c851a1873948e495180f336edeb63f54bcf83feaa4d2453251260e24293e49815c2369c1c045083c412c973987fd7c9296a71cda424823ed32380ba442394500b7d2d2335818099090aaf08ca4e180869c546f58da4cb4ff0f95b796a35c40ea455e2ddd3e08bc494ffddc706aaf4d479f4f359e6a89a90df7c9b8f23cab355855a72b90795a0db83a96bce0dd4f77e3f58c0957b4ffe9663251565098e6c31fd4bbf3e1295faaff05e29912d9c37cb944da379a9b2193b466910d05a681e53a2dbe5aa18a2b4874153fe36d8a1aa4cc6e612bd6dbc9abb8e1e61b927fc5458d8e1be9536cd462e4c37672af7928c39e94bdc124a2da7b1bd3cad2cfe559adc33e62eb45bff89db8a47a72dda4f49f21c01a9432f4802a1
+
+* Send to Signer 3:
+** HMAC_KEY (hex): ab93ce7bf0f91c62a66d00ea9bf5e5c00b854ee2cfc2fb06f6eeff738abcdc26
+** MAC (hex): bb3c93b67d758f244de7ee73e5e61261cea6dff5b3852df8faf265cdf1c73dae
+** IV (hex) : bb3c93b67d758f244de7ee73e5e61261
+** CIPHERTEXT (hex): 7ac33bd9719a3cef6c68e09b3c9677565418933f188bbe50dc70f46329706732fe28ab230468e2a8798d3fbf641867d5b3322113204a372e7650ed06cf94d6df5cc7425b1b3a07690a32e12fd9cdad2c9f42d496c1b02215a7d8d63565aa4935bb2b087af39eebc02d4a2d30a4dbf1e72b9a0dab11473c7254ecf9065eb4f9d80a164c489d5fdae0d15d97b6100b79c3999b91341dfb4f599f738d4d631ae413c17b55daa09a67cb34b40d89c26f0e95ddfbf416033f869da32e502815d720bb342ec1c0e5c6910c598f32162016229cd37ea030b4d3b60f560105abb75531dc960ddf6830c26604c67c2da05b8adc45297dda58b2da4671104969b819cdf1c362bc20d7bdfe4a2fbdb79b4a69e285434d991c269e3d23ce3d95675a0acbec2cae04a310581148d3422c1c0a621fb6d79ecac1743b0e76837389b67cd4734ec5ab560c43a183de35fa98834e1f347a0c0c9b14273b76233f55f04553efcde873de92d766f3cdc5e56bc649bf0cc4951f051619ee9b931cd3872044b0e62ea2c2dacad978dbb8df3afa0b9386535278c295c6a30a56950e57f805770568e937ffafbadb226120991d5ec10effa9f4334800010d141a2ddddc00ac743efa821af37f69840487e4db48036c1e0730788cddbca2f68b3769ec6989d76161e6605af50651b6e86e
+** my_multisig_wallet_for_signer_3.dat : bb3c93b67d758f244de7ee73e5e61261cea6dff5b3852df8faf265cdf1c73dae7ac33bd9719a3cef6c68e09b3c9677565418933f188bbe50dc70f46329706732fe28ab230468e2a8798d3fbf641867d5b3322113204a372e7650ed06cf94d6df5cc7425b1b3a07690a32e12fd9cdad2c9f42d496c1b02215a7d8d63565aa4935bb2b087af39eebc02d4a2d30a4dbf1e72b9a0dab11473c7254ecf9065eb4f9d80a164c489d5fdae0d15d97b6100b79c3999b91341dfb4f599f738d4d631ae413c17b55daa09a67cb34b40d89c26f0e95ddfbf416033f869da32e502815d720bb342ec1c0e5c6910c598f32162016229cd37ea030b4d3b60f560105abb75531dc960ddf6830c26604c67c2da05b8adc45297dda58b2da4671104969b819cdf1c362bc20d7bdfe4a2fbdb79b4a69e285434d991c269e3d23ce3d95675a0acbec2cae04a310581148d3422c1c0a621fb6d79ecac1743b0e76837389b67cd4734ec5ab560c43a183de35fa98834e1f347a0c0c9b14273b76233f55f04553efcde873de92d766f3cdc5e56bc649bf0cc4951f051619ee9b931cd3872044b0e62ea2c2dacad978dbb8df3afa0b9386535278c295c6a30a56950e57f805770568e937ffafbadb226120991d5ec10effa9f4334800010d141a2ddddc00ac743efa821af37f69840487e4db48036c1e0730788cddbca2f68b3769ec6989d76161e6605af50651b6e86e
+
+==Acknowledgement==
+
+Special thanks to Pavol Rusnak, Dmitry Petukhov, Christopher Allen, Craig Raw, Robert Spigler, Gregory Sanders, Ta Tat Tai, Michael Flaxman, Pieter Wuille, Salvatore Ingala, Andrew Chow and others for their feedback on the specification.
+
+==References==
+
+Related mailing list threads:
+* https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018385.html
+* https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-April/018732.html
+
diff --git a/bip-0136.mediawiki b/bip-0136.mediawiki
index f94171d4..1caa0273 100644
--- a/bip-0136.mediawiki
+++ b/bip-0136.mediawiki
@@ -16,312 +16,814 @@
== Introduction ==
=== Abstract ===
-This document proposes a convenient human useable format, '''"TxRef"''', as a standard way to refer to a transaction position within the Bitcoin Blockchain, and optionally a particular outpoint index within the referred transaction. The primary purpose of this format is to allow users to refer to a confirmed transaction (and optionally an outpoint index within) in a standard, reliable, and concise way.
+This document proposes a convenient, human usable encoding to refer to a '''confirmed transaction position''' within the Bitcoin blockchain--known as '''"TxRef"'''. The primary purpose of this encoding is to allow users to refer to a confirmed transaction (and optionally, a particular outpoint index within the transaction) in a standard, reliable, and concise way.
-''Please note: Unlike TxID where there is strong cryptographic link between the ID and the actual transaction, TxRef only provides a weak link to a particular transaction. TxRef locates an offset within a blockchain for a transaction, that may - or may not - point to an actual transaction, which in fact may change with reorganisations. We recommend that TxRef's should be not used for positions within the blockchain having a maturity less than 100 blocks.''
+''Please note: Unlike a transaction ID, '''"TxID"''', where there is a strong cryptographic link between the ID and the actual transaction, a '''TxRef''' only provides a weak link to a particular transaction. A '''TxRef''' locates an offset within a blockchain for a transaction, that may - or may not - point to an actual transaction, which in fact may change with reorganisations. We recommend that '''TxRef'''s should be not used for positions within the blockchain having a maturity less than 100 blocks.''
+
+The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [https://tools.ietf.org/html/rfc2119 RFC 2119].
=== Copyright ===
This BIP is licensed under the 2-clause BSD license.
=== Motivation ===
-Since the first version of Bitcoin, TxID's (Transaction Identifiers) have been a core part of the consensus protocol and have been routinely used to identify individual transactions between users.
+Since the first version of Bitcoin, '''TxID'''s have been a core part of the consensus protocol and are routinely used to identify individual transactions between users.
However, for many use-cases they have practical limitations:
-* TxIDs are expensive for full nodes to lookup (requiring either a linear scan of the blockchain, or an expensive TxID index).
-* TxIDs require third-party services for SPV wallets to lookup.
-* TxIDs are very long HEX encoded values (64 characters long).
+* '''TxID'''s are expensive for full nodes to lookup (requiring either a linear scan of the blockchain, or an expensive '''TxID''' index).
+* '''TxID'''s require third-party services for SPV wallets to lookup.
+* '''TxID'''s are 64 character HEX encoded values.
-For transactions that have been embedded in the blockchain, it is possible to reference them not by their TxID, but by their location within the blockchain itself. The encoding can be made friendly for occasional human transcription. In this document, we propose a standard for doing this.
+It is possible to reference transactions not only by their '''TxID''', but by their location within the blockchain itself. Rather than use the 64 character '''TxID''', an encoding of the position coordinates can be made friendly for occasional human transcription. In this document, we propose a standard for doing this.
=== Examples ===
-These examples are for Bitcoin Transactions.
-* Genesis Coinbase Transaction (Transaction #0 of Block #0): tx1:rqqq-qqqq-qmhu-qhp
-* Transaction #2205 of Block #466793: tx1:rjk0-uqay-zsrw-hqe
+
+{| class="wikitable"
+|-
+! Block # !! Transaction # !! Outpoint # !! TxRef !! TxID
+|-
+| 0 || 0 || 0 || tx1:rqqq‑qqqq‑qwtv‑vjr || 4a5e1e4baab89f3a32518a88c31bc87f618f76673e2cc77ab2127b7afdeda33b
+|-
+| 170 || 1 || 0 || tx1:r52q‑qqpq‑qpty‑cfg || f4184fc596403b9d638783cf57adfe4c75c605f6356fbc91338530e9831e9e16
+|-
+| 456789 || 1234 || 1 || tx1:y29u‑mqjx‑ppqq‑sfp2‑tt || 6fb8960f70667dc9666329728a19917937896fc476dfc54a3e802e887ecb4e82
+|}
== Specification ==
-A '''confirmed transaction position reference''', or '''TxRef''', is a reference to a particular location within the blockchain, specified by the block height and a transaction index within the block, and optionally a outpoint index within the transaction.
+A '''confirmed transaction position reference''', or '''TxRef''', is a reference to a particular location within the blockchain, specified by the block height and a transaction index within the block, and optionally, an outpoint index within the transaction.
''Please Note: All values in this specification are encoded in little-endian format.''
-=== Transaction Position Reference Considerations ===
-A TxRef may reference a location that doesn't exist because:
+=== TxRef Considerations ===
+It is possible for a '''TxRef''' to reference a transaction that doesn't really exist because:
-* The specified block hasn't yet been mined. Or,
+* The specified block hasn't yet been mined.
* The transaction index is greater than the total number of transactions included within the specified block.
* The optional outpoint index is greater than the total outpoints contained within the transaction.
-Therefore, implementers must be careful not to display TxRef's to users prematurely:
+Therefore, implementers must be careful not to display '''TxRef'''s to users prematurely:
-* Applications MUST NOT display TxRef's for transactions with less than 6 confirmations.
-* Application MUST show a warning for TxRef's for transactions with less than 100 confirmations.
-** This warning SHOULD state that in the case of a large reorganisation, the TxRefs Displayed may point to a different transaction, or to no transaction at all.
+* Applications MUST NOT display '''TxRef'''s for transactions with less than 6 confirmations.
+* Application MUST show a warning for '''TxRef'''s for transactions with less than 100 confirmations.
+** This warning SHOULD state that in the case of a large reorganisation, the '''TxRef'''s displayed may point to a different transaction, or to no transaction at all.
+
+=== TxRef Format ===
+
+'''TxRef''' MUST use the '''Bech32m'''['''Why use Bech32 Encoding for Confirmed Transaction References?''' The error detection and correction properties of this encoding format make it very attractive. We expect that it will be reasonable for software to correct a maximum of two characters; however, we haven’t specified this yet.] encoding as defined in [https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki BIP-0173] and later refined in [https://github.com/bitcoin/bips/blob/master/bip-0350.mediawiki BIP-0350]. The Bech32m encoding consists of:
+
+==== Human-Readable Part ====
+
+The '''HRP''' can be thought of as a label. We have chosen labels to distinguish between Main, Test, and Regtest networks:
+* Mainnet: '''"tx"'''.
+* Testnet: '''"txtest"'''.
+* Regtest: '''"txrt"'''.
+
+==== Separator ====
+
+The separator is the character '''"1"'''.
+
+==== Data Part ====
+
+The data part for a '''TxRef''' consists of the transaction's block height, transaction index within the block, and optionally, an outpoint index. Specific encoding details for the data are given below.
+
+''Please note: other specifications, such as [https://w3c-ccg.github.io/did-spec/ the Decentralized Identifiers spec], have implicitly encoded the information contained within the HRP elsewhere. In this case they may choose to not include the HRP as specified here.''
+
+==== Readability ====
+
+To increase portability and readability, additional separator characters SHOULD be added to the '''TxRef''':
+
+* A Colon['''Why add a colon here?''' This allows it to conform better with W3C URN/URL standards.] '''":"''' added after the separator character '1'.
+* Hyphens['''Why hyphens within the TxRef?''' As '''TxRef'''s are short, we expect that they will be quoted via voice or written by hand. The inclusion of hyphens every 4 characters breaks up the string and means people don't lose their place so easily.] '''"-"''' added after every 4 characters beyond the colon.
=== Encoding ===
-TxRef uses standard Bech32['''Why use Bech32 Encoding for Confirmed Transaction References?''' The error detection and correction properties of this encoding format make it very attractive. We expect that it will be reasonable for software to correct a maximum of two characters; however, we haven’t specified this yet.] encoding as defined in [https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki BIP-173] and therefore consists of:
+Encoding a '''TxRef''' requires 4 or 5 pieces of data: a magic code denoting which network is being used; a version number (currently always 0); the block height of the block containing the transaction; the index of the transaction within the block; and optionally, the index of the outpoint within the transaction. Only a certain number of bits are supported for each of these values, see the following table for details.
-* Human-readable Part, or "HRP", that provides namespacing. We have chosen to distinguish between Main and Test Networks:
-** For Any Mainnet Network: '''"tx"'''.
-** For Any Testnet Network: '''"txtest"'''.
-** Please see [https://github.com/satoshilabs/slips/blob/master/slip-0173.md SLIP-0173 : Registered human-readable parts for BIP-0173] for a full list of HRP's including these two and others relating to other projects.
-* Separator: '''"1"'''.
-* Data Part.
-
-Please note: other specifications, such as [https://w3c-ccg.github.io/did-spec/ the Decentralized Identifiers spec], have implicitly encoded the information contained within the HRP elsewhere. In this case they may choose to not include the HRP as specified here.
-
-To increase portability and readability additional separators SHOULD be added:
-
-* A Colon['''Why add a colon here?''' This allows it to conform better with W3C URN/URL standards.] '''":"''' added after '1'.
-* Hyphens['''Why hyphens within the TxRef?''' As TxRef's are short, we expect that they will be quoted via voice or written by hand. The inclusion of hyphens every 4 characters breaks up the string and means people don't lose their place so easily.] '''"-"''' added after every 4 characters beyond the colon.
-
-All non-bech32-alphabet characters after the bech32 code separator MUST be ignored/removed when parsing (except for terminating characters).['''Why strip all non-bech32-alphabet characters?''' We do not wish to expect the users to keep their TxRef's in good unicode form (hyphens, colons, invisible spaces, random unicode characters, etc). We expect them to copy, paste, write by-hand, write in a mix of character sets, etc. Parsers should automatically correct for all sorts of these common errors.
-]
{| class="wikitable"
-|+Text Encoding of the TxRef
!
-!Bit
-!Character
-!Characters
-!Value
+!Description
+!Possible Data Type
+!'''# of Bits used'''
+!Values
|-
-|Human Readable Part
+| style="background: #99DDFF; color: black; text-align : center;" | Magic Code
+|Chain Namespacing Code
+|uint8
+| style="background: #99DDFF; color: black; text-align : center;" | 5
+|'''3''': Mainnet '''4''': Mainnet with Outpoint '''6''': Testnet '''7''': Testnet with Outpoint '''0''': Regtest '''1''': Regtest with Outpoint
+|-
+| style="background: #DDDDDD; color: black; text-align : center;" | Version
+|For Future Use
+|uint8
+| style="background: #DDDDDD; color: black; text-align : center;" | 1
+|Must be '''0'''
+|-
+| style="background: #EEDD88; color: black; text-align : center;" | Block Height
+|The Block Height of the Tx
+|uint32
+| style="background: #EEDD88; color: black; text-align : center;" | 24
+|Block 0 to Block 16777215
+|-
+| style="background: #FFAABB; color: black; text-align : center;" | Transaction Index
+|The index of the Tx inside the block
+|uint16, uint32
+| style="background: #FFAABB; color: black; text-align : center;" | 15
+|Tx 0 to Tx 32767
+|-
+| style="background: #BBCC33; color: black; text-align : center;" | Outpoint Index
+|The index of the Outpoint inside the Tx
+|uint16, uint32
+| style="background: #BBCC33; color: black; text-align : center;" | 15
+|Outpoint 0 to Outpoint 32767
+|}
+
+==== Magic Notes ====
+The magic code provides namespacing between chains:
+
+* For Mainnet the magic code is: '''0x3''', leading to an '''"r"''' character when encoded.
+* For Mainnet with Outpoint Encoded the magic code is: '''0x4''', leading to a '''"y"''' character when encoded.
+* For Testnet the magic code is: '''0x6''', leading to an '''"x"''' character when encoded.
+* For Testnet with Outpoint Encoded the magic code is: '''0x7''', leading to an '''"8"''' character when encoded.
+* For Regtest the magic code is: '''0x0''', leading to a '''"q"''' character when encoded.
+* For Regtest with Outpoint Encoded the magic code is: '''0x1''', leading to a '''"p"''' character when encoded.
+
+==== Encoding Example ====
+
+We want to encode a '''TxRef''' that refers to Transaction #1234 of Block #456789 on the Mainnet chain. We use this data in preparation for the Bech32 encoding algorithm:
+
+{| class="wikitable"
+!
+!Decimal Value
+!Binary Value
+!'''# of Bits used'''
+!Bit Indexes and Values
+|-
+| style="background: #99DDFF; color: black; text-align : center;" | Magic Code
+| style="background: #99DDFF; color: black; text-align : center;" | 3
+|00000011
+| style="background: #99DDFF; color: black; text-align : center;" | 5
+|(mc04, mc03, mc02, mc01, mc00) = (0, 0, 0, 1, 1)
+|-
+| style="background: #DDDDDD; color: black; text-align : center;" | Version
+| style="background: #DDDDDD; color: black; text-align : center;" | 0
+|00000000
+| style="background: #DDDDDD; color: black; text-align : center;" | 1
+|(v0) = (0)
+|-
+| style="background: #EEDD88; color: black; text-align : center;" | Block Height
+| style="background: #EEDD88; color: black; text-align : center;" | 456789
+|00000110 11111000 01010101
+| style="background: #EEDD88; color: black; text-align : center;" | 24
+|(bh23, bh22, bh21, bh20, bh19, bh18, bh17, bh16) = (0, 0, 0, 0, 0, 1, 1, 0) (bh15, bh14, bh13, bh12, bh11, bh10, bh09, bh08) = (1, 1, 1, 1, 1, 0, 0, 0) (bh07, bh06, bh05, bh04, bh03, bh02, bh01, bh00) = (0, 1, 0, 1, 0, 1, 0, 1)
+|-
+| style="background: #FFAABB; color: black; text-align : center;" | Transaction Index
+| style="background: #FFAABB; color: black; text-align : center;" | 1234
+|00000100 11010010
+| style="background: #FFAABB; color: black; text-align : center;" | 15
+|(ti14, ti13, ti12, ti11, ti10, ti09, ti08) = (0, 0, 0, 0, 1, 0, 0) (ti07, ti06, ti05, ti04, ti03, ti02, ti01, ti00) = (1, 1, 0, 1, 0, 0, 1, 0)
+|}
+
+As shown in the last column, we take the necessary bits of each binary value and copy them into nine unsigned chars illustrated in the next table. We only set the lower five bits of each unsigned char as the bech32 algorithm only uses those bits.
+
+{| class="wikitable" style="text-align: center"
+!
+!
+!style="width:2em"|7
+!style="width:2em"|6
+!style="width:2em"|5
+!style="width:2em"|4
+!style="width:2em"|3
+!style="width:2em"|2
+!style="width:2em"|1
+!style="width:2em"|0
+!
+!Decimal Value
+!Bech32 Character
+|-
+| || || || || || || || || || || || ||
+|-
+| rowspan="2" | data[0] || Index
+|na
+|na
+|na
+| style="background: #99DDFF; color: black; text-align : center;" | mc04
+| style="background: #99DDFF; color: black; text-align : center;" | mc03
+| style="background: #99DDFF; color: black; text-align : center;" | mc02
+| style="background: #99DDFF; color: black; text-align : center;" | mc01
+| style="background: #99DDFF; color: black; text-align : center;" | mc00
+|
+|
|
-|1 – 2
-|2
-|Bitcoin Mainnet: "'''tx'''", Bitcoin Testnet: "'''txtest'''"
|-
-|Separator
+|Value
+|0
+|0
+|0
+|0
+|0
+|0
+|1
+|1
|
|3
+|r
+|-
+| || || || || || || || || || || ||
+|-
+| rowspan="2" | data[1] || Index
+|na
+|na
+|na
+| style="background: #EEDD88; color: black; text-align : center;" | bh03
+| style="background: #EEDD88; color: black; text-align : center;" | bh02
+| style="background: #EEDD88; color: black; text-align : center;" | bh01
+| style="background: #EEDD88; color: black; text-align : center;" | bh00
+| style="background: #DDDDDD; color: black; text-align : center;" | v0
+|
+|
+|
+|-
+|Value
+|0
+|0
+|0
+|0
|1
-|"'''1'''"
-|-
-|Colon
-|
-|4
+|0
|1
-|"''':'''"
+|0
+|
+|10
+|2
|-
-|Data
-|0 – 19
-|5 – 8
-|4
+| || || || || || || || || || || ||
+|-
+| rowspan="2" | data[2] || Index
+|na
+|na
+|na
+| style="background: #EEDD88; color: black; text-align : center;" | bh08
+| style="background: #EEDD88; color: black; text-align : center;" | bh07
+| style="background: #EEDD88; color: black; text-align : center;" | bh06
+| style="background: #EEDD88; color: black; text-align : center;" | bh05
+| style="background: #EEDD88; color: black; text-align : center;" | bh04
+|
+|
|
|-
-|Hyphen
+|Value
+|0
+|0
+|0
+|0
+|0
+|1
+|0
+|1
|
+|5
|9
+|-
+| || || || || || || || || || || ||
+|-
+| rowspan="2" | data[3] || Index
+|na
+|na
+|na
+| style="background: #EEDD88; color: black; text-align : center;" | bh13
+| style="background: #EEDD88; color: black; text-align : center;" | bh12
+| style="background: #EEDD88; color: black; text-align : center;" | bh11
+| style="background: #EEDD88; color: black; text-align : center;" | bh10
+| style="background: #EEDD88; color: black; text-align : center;" | bh09
+|
+|
+|
+|-
+|Value
+|0
+|0
+|0
|1
-|"'''-'''"
-|}
-The Data - Hyphen pattern is repeated for the entire length of data, ( a hyphen is inserted after every encoded 20 bits or 4 data characters).
-=== Data ===
-
-Depending on if an optional transaction outpoint is included, there can be 75 or 90 bits of data encoded in the string above. These bits are defined in this manner:
-
-{| class="wikitable"
-|+TxRef Binary Format for Bitcoin Mainnet and Bitcoin Testnet:
-!
-!'''Bit'''
-!'''Bit(s)'''
-!'''Type'''
-!'''Values'''
-!'''Notes'''
-|-
-|Magic Code
-|0 – 4
-|5
-|Chain Namespacing Code
-|'''0x3''' for Bitcoin Mainnet.
-'''0x4''' for Bitcoin Mainnet with Outpoint.
-'''0x6''' for Bitcoin Testnet.
-'''0x7''' for Bitcoin Testnet with Outpoint.
-|
-|-
-|Version
-|5
|1
-|For Future Use
-|Must be '''0x0'''
+|1
+|0
+|0
+|
+|28
+|u
+|-
+| || || || || || || || || || || ||
+|-
+| rowspan="2" | data[4] || Index
+|na
+|na
+|na
+| style="background: #EEDD88; color: black; text-align : center;" | bh18
+| style="background: #EEDD88; color: black; text-align : center;" | bh17
+| style="background: #EEDD88; color: black; text-align : center;" | bh16
+| style="background: #EEDD88; color: black; text-align : center;" | bh15
+| style="background: #EEDD88; color: black; text-align : center;" | bh14
+|
+|
|
|-
-|Block Height
-|6 – 29
-|24
-|The Block Height of the Tx
-|Block 0 (genesis) to block 16777215
-|Until Year ~2328
+|Value
+|0
+|0
+|0
+|1
+|1
+|0
+|1
+|1
+|
+|27
+|m
|-
-|Transaction Index
-|30 – 44
-|15
-|The index of the Tx inside the block
-|Tx 0 (coinbase) to Tx position 32767
-|Max Tx's in block is 16665
+| || || || || || || || || || || ||
+|-
+| rowspan="2" | data[5] || Index
+|na
+|na
+|na
+| style="background: #EEDD88; color: black; text-align : center;" | bh23
+| style="background: #EEDD88; color: black; text-align : center;" | bh22
+| style="background: #EEDD88; color: black; text-align : center;" | bh21
+| style="background: #EEDD88; color: black; text-align : center;" | bh20
+| style="background: #EEDD88; color: black; text-align : center;" | bh19
+|
+|
+|
+|-
+|Value
+|0
+|0
+|0
+|0
+|0
+|0
+|0
+|0
+|
+|0
+|q
+|-
+| || || || || || || || || || || ||
+|-
+| rowspan="2" | data[6] || Index
+|na
+|na
+|na
+| style="background: #FFAABB; color: black; text-align : center;" | ti04
+| style="background: #FFAABB; color: black; text-align : center;" | ti03
+| style="background: #FFAABB; color: black; text-align : center;" | ti02
+| style="background: #FFAABB; color: black; text-align : center;" | ti01
+| style="background: #FFAABB; color: black; text-align : center;" | ti00
+|
+|
+|
+|-
+|Value
+|0
+|0
+|0
+|1
+|0
+|0
+|1
+|0
+|
+|18
+|j
+|-
+| || || || || || || || || || || ||
+|-
+| rowspan="2" | data[7] || Index
+|na
+|na
+|na
+| style="background: #FFAABB; color: black; text-align : center;" | ti09
+| style="background: #FFAABB; color: black; text-align : center;" | ti08
+| style="background: #FFAABB; color: black; text-align : center;" | ti07
+| style="background: #FFAABB; color: black; text-align : center;" | ti06
+| style="background: #FFAABB; color: black; text-align : center;" | ti05
+|
+|
+|
+|-
+|Value
+|0
+|0
+|0
+|0
+|0
+|1
+|1
+|0
+|
+|6
+|x
+|-
+| || || || || || || || || || || ||
+|-
+| rowspan="2" | data[8] || Index
+|na
+|na
+|na
+| style="background: #FFAABB; color: black; text-align : center;" | ti14
+| style="background: #FFAABB; color: black; text-align : center;" | ti13
+| style="background: #FFAABB; color: black; text-align : center;" | ti12
+| style="background: #FFAABB; color: black; text-align : center;" | ti11
+| style="background: #FFAABB; color: black; text-align : center;" | ti10
+|
+|
+|
+|-
+|Value
+|0
+|0
+|0
+|0
+|0
+|0
+|0
+|1
+|
+|1
+|p
|}
-If the magic code is '''0x4''' or '''0x7''', an optional outpoint is included in the encoding:
+
+The Bech32 algorithm encodes the nine unsigned chars above and computes a checksum of those chars and encodes that as well--this gives a six character checksum (in this case, '''utt3p0''') which is appended to the final '''TxRef'''. The final '''TxRef''' given is: '''tx1:r29u-mqjx-putt-3p0''' and is illustrated in the following table:
+
+TxRef character indexes and descriptions
+{| class="wikitable" style="text-align: top"
+!style="width:2em"|Index
+!style="width:2em"|0
+!style="width:2em"|1
+!style="width:2em"|2
+!style="width:2em"|3
+!style="width:2em"|4
+!style="width:2em"|5
+!style="width:2em"|6
+!style="width:2em"|7
+!style="width:2em"|8
+!style="width:2em"|9
+!style="width:2em"|10
+!style="width:2em"|11
+!style="width:2em"|12
+!style="width:2em"|13
+!style="width:2em"|14
+!style="width:2em"|15
+!style="width:2em"|16
+!style="width:2em"|17
+!style="width:2em"|18
+!style="width:2em"|19
+!style="width:2em"|20
+!style="width:2em"|21
+|-
+|Char:
+| style="background: #BBCCEE; color: black; text-align : center;" | t
+| style="background: #BBCCEE; color: black; text-align : center;" | x
+| style="background: #FFCCCC; color: black; text-align : center;" | 1
+| style="background: #CCDDAA; color: black; text-align : center;" | :
+| style="background: #EEEEBB; color: black; text-align : center;" | r
+| style="background: #EEEEBB; color: black; text-align : center;" | 2
+| style="background: #EEEEBB; color: black; text-align : center;" | 9
+| style="background: #EEEEBB; color: black; text-align : center;" | u
+| style="background: #CCDDAA; color: black; text-align : center;" | -
+| style="background: #EEEEBB; color: black; text-align : center;" | m
+| style="background: #EEEEBB; color: black; text-align : center;" | q
+| style="background: #EEEEBB; color: black; text-align : center;" | j
+| style="background: #EEEEBB; color: black; text-align : center;" | x
+| style="background: #CCDDAA; color: black; text-align : center;" | -
+| style="background: #EEEEBB; color: black; text-align : center;" | p
+| style="background: #EEEEBB; color: black; text-align : center;" | u
+| style="background: #EEEEBB; color: black; text-align : center;" | t
+| style="background: #EEEEBB; color: black; text-align : center;" | t
+| style="background: #CCDDAA; color: black; text-align : center;" | -
+| style="background: #EEEEBB; color: black; text-align : center;" | 3
+| style="background: #EEEEBB; color: black; text-align : center;" | p
+| style="background: #EEEEBB; color: black; text-align : center;" | 0
+|}
+
+==== Outpoint Index ====
+
+Some uses of '''TxRef''' may want to refer to a specific outpoint of the transaction. In the previous example, since we did not specify the outpoint index, the '''TxRef''' '''tx1:r29u-mqjx-putt-3p0''' implicitly references the first (index 0) outpoint of the 1234th transaction in the 456789th block in the blockchain.
+
+If instead, for example, we want to reference the second (index 1) outpoint, we need to change the magic code from '''3''' to '''4''' and would include the following in the data to be encoded:
{| class="wikitable"
-|+Optional Outpoint Index Encoding:
!
-!'''Bit'''
-!'''Bit(s)'''
-!'''Type'''
-!'''Values'''
-!'''Notes'''
+!Decimal Value
+!Binary Value
+!'''# of Bits used'''
+!Bit Indexes and Values
|-
-|Outpoint Index
-|45 – 59
-|15
-|The index of the Outpoint inside the Tx
-|Outpoint 0 to Outpoint Position 32767
-|
+| style="background: #99DDFF; color: black; text-align : center;" | Magic Code
+| style="background: #99DDFF; color: black; text-align : center;" | 4
+|00000100
+| style="background: #99DDFF; color: black; text-align : center;" | 5
+|(mc04, mc03, mc02, mc01, mc00) = (0, 0, 1, 0, 0)
+|-
+| style="background: #BBCC33; color: black; text-align : center;" | Outpoint Index
+| style="background: #BBCC33; color: black; text-align : center;" | 1
+|00000000 00000001
+| style="background: #BBCC33; color: black; text-align : center;" | 15
+|(op14, op13, op12, op11, op10, op09, op08) = (0, 0, 0, 0, 0, 0, 0) (op07, op06, op05, op04, op03, op02, op01, op00) = (0, 0, 0, 0, 0, 0, 0, 1)
|}
-We include the 30-bit checksum last:
-{| class="wikitable"
-|+Bech32 Checksum Encoding:
+{| class="wikitable" style="text-align: center"
!
-!'''Bit'''
-!'''Bit(s)'''
-!'''Type'''
-!'''Values'''
-!'''Notes'''
+!
+!style="width:2em"|7
+!style="width:2em"|6
+!style="width:2em"|5
+!style="width:2em"|4
+!style="width:2em"|3
+!style="width:2em"|2
+!style="width:2em"|1
+!style="width:2em"|0
+!
+!Decimal Value
+!Bech32 Character
|-
-|Checksum
-|45 – 74 or 60 – 89
-|30
-|Bech32 Checksum
+| || || || || || || || || || || || ||
+|-
+| rowspan="2" | data[0] || Index
+|na
+|na
+|na
+| style="background: #99DDFF; color: black; text-align : center;" | mc04
+| style="background: #99DDFF; color: black; text-align : center;" | mc03
+| style="background: #99DDFF; color: black; text-align : center;" | mc02
+| style="background: #99DDFF; color: black; text-align : center;" | mc01
+| style="background: #99DDFF; color: black; text-align : center;" | mc00
|
|
+|
+|-
+|Value
+|0
+|0
+|0
+|0
+|0
+|1
+|0
+|0
+|
+|4
+|y
+|-
+| || || || || || || || || || || ||
+|-
+| rowspan="2" | data[9] || Index
+|na
+|na
+|na
+| style="background: #BBCC33; color: black; text-align : center;" | op04
+| style="background: #BBCC33; color: black; text-align : center;" | op03
+| style="background: #BBCC33; color: black; text-align : center;" | op02
+| style="background: #BBCC33; color: black; text-align : center;" | op01
+| style="background: #BBCC33; color: black; text-align : center;" | op00
+|
+|
+|
+|-
+|Value
+|0
+|0
+|0
+|0
+|0
+|0
+|0
+|1
+|
+|1
+|p
+|-
+| || || || || || || || || || || ||
+|-
+| rowspan="2" | data[10] || Index
+|na
+|na
+|na
+| style="background: #BBCC33; color: black; text-align : center;" | op09
+| style="background: #BBCC33; color: black; text-align : center;" | op08
+| style="background: #BBCC33; color: black; text-align : center;" | op07
+| style="background: #BBCC33; color: black; text-align : center;" | op06
+| style="background: #BBCC33; color: black; text-align : center;" | op05
+|
+|
+|
+|-
+|Value
+|0
+|0
+|0
+|0
+|0
+|0
+|0
+|0
+|
+|0
+|q
+|-
+| || || || || || || || || || || ||
+|-
+| rowspan="2" | data[11] || Index
+|na
+|na
+|na
+| style="background: #BBCC33; color: black; text-align : center;" | op14
+| style="background: #BBCC33; color: black; text-align : center;" | op13
+| style="background: #BBCC33; color: black; text-align : center;" | op12
+| style="background: #BBCC33; color: black; text-align : center;" | op11
+| style="background: #BBCC33; color: black; text-align : center;" | op10
+|
+|
+|
+|-
+| Value
+|0
+|0
+|0
+|0
+|0
+|0
+|0
+|0
+|
+|0
+|q
|}
-==== Magic Notes: ====
-The magic code provides namespacing between chains. 5-bit magic codes are used for the Bitcoin Mainnet and the Bitcoin Testnet. (it may be significantly longer for other projects/chains):
+After Bech32 encoding all twelve unsigned chars above, we get the checksum: '''sfp2tt'''. The final '''TxRef''' given is: '''tx1:y29u-mqjx-ppqq-sfp2-tt''' and is illustrated in the following table:
-* For Bitcoin Mainnet the magic code is: '''0x3''', leading to an '''"r"''' character when encoded.
-* For Bitcoin Mainnet with Outpoint Encoded the magic code is: '''0x4''', leading to an '''"y"''' character when encoded.
-* For Bitcoin Testnet the magic code is: '''0x6''', leading to an '''"x"''' character when encoded.
-* For Bitcoin Testnet with Outpoint Encoded the magic code is: '''0x7''', leading to an '''"8"''' character when encoded.
+TxRef character indexes and descriptions
+{| class="wikitable" style="text-align: top"
+!style="width:2em"|Index
+!style="width:2em"|0
+!style="width:2em"|1
+!style="width:2em"|2
+!style="width:2em"|3
+!style="width:2em"|4
+!style="width:2em"|5
+!style="width:2em"|6
+!style="width:2em"|7
+!style="width:2em"|8
+!style="width:2em"|9
+!style="width:2em"|10
+!style="width:2em"|11
+!style="width:2em"|12
+!style="width:2em"|13
+!style="width:2em"|14
+!style="width:2em"|15
+!style="width:2em"|16
+!style="width:2em"|17
+!style="width:2em"|18
+!style="width:2em"|19
+!style="width:2em"|20
+!style="width:2em"|21
+!style="width:2em"|22
+!style="width:2em"|23
+!style="width:2em"|24
+!style="width:2em"|25
+|-
+|Char:
+| style="background: #BBCCEE; color: black; text-align : center;" | t
+| style="background: #BBCCEE; color: black; text-align : center;" | x
+| style="background: #FFCCCC; color: black; text-align : center;" | 1
+| style="background: #CCDDAA; color: black; text-align : center;" | :
+| style="background: #EEEEBB; color: black; text-align : center;" | y
+| style="background: #EEEEBB; color: black; text-align : center;" | 2
+| style="background: #EEEEBB; color: black; text-align : center;" | 9
+| style="background: #EEEEBB; color: black; text-align : center;" | u
+| style="background: #CCDDAA; color: black; text-align : center;" | -
+| style="background: #EEEEBB; color: black; text-align : center;" | m
+| style="background: #EEEEBB; color: black; text-align : center;" | q
+| style="background: #EEEEBB; color: black; text-align : center;" | j
+| style="background: #EEEEBB; color: black; text-align : center;" | x
+| style="background: #CCDDAA; color: black; text-align : center;" | -
+| style="background: #EEEEBB; color: black; text-align : center;" | p
+| style="background: #EEEEBB; color: black; text-align : center;" | p
+| style="background: #EEEEBB; color: black; text-align : center;" | q
+| style="background: #EEEEBB; color: black; text-align : center;" | q
+| style="background: #CCDDAA; color: black; text-align : center;" | -
+| style="background: #EEEEBB; color: black; text-align : center;" | s
+| style="background: #EEEEBB; color: black; text-align : center;" | f
+| style="background: #EEEEBB; color: black; text-align : center;" | p
+| style="background: #EEEEBB; color: black; text-align : center;" | 2
+| style="background: #CCDDAA; color: black; text-align : center;" | -
+| style="background: #EEEEBB; color: black; text-align : center;" | t
+| style="background: #EEEEBB; color: black; text-align : center;" | t
+|}
-Codes '''0x0''', '''0x1''', '''0x2''', '''0x5''', are also reserved for future use within the Bitcoin project.
-''Any other chain MUST NOT start their magic code with any value between 0x0 and 0x7 inclusive.''
+=== Decoding ===
-Other magic codes will be specified in SLIP-XXXX "TxRef for Non-Bitcoin Chains and Networks".
+The Bech32 spec defines 32 valid characters as its "alphabet". All non-Bech32-alphabet characters present in a '''TxRef''' after the Bech32 separator character MUST be ignored/removed when parsing (except for terminating characters). We do not wish to expect the users to keep their '''TxRef'''s in good form and '''TxRef'''s may contains hyphens, colons, invisible spaces, uppercase or random characters. We expect users to copy, paste, write by-hand, write in a mix of character sets, etc. Parsers SHOULD attempt to correct for these and other common errors, reporting to the user any '''TxRef'''s that violate a proper Bech32 encoding.
-=== Compatibility ===
-There are no known compatibility issues.
+As of early 2021, '''TxRef''' has been in limited use for a couple of years and it is possible that there are some '''TxRef'''s in use which were created with the original specification of Bech32 before the Bech32m refinement was codified. Due to this possibility, a '''TxRef''' parser SHOULD be able to decode both Bech32m and Bech32 encoded '''TxRef'''s. In such a case, a '''TxRef''' parser SHOULD display or somehow notify the user that they are using an obsolete '''TxRef''' and that they should upgrade it to the Bech32m version. Additionally, the parser MAY also display the Bech32m version.
== Rationale ==
== Reference implementations ==
+
C Reference Implementation (supports magic codes 0x3 and 0x6): https://github.com/jonasschnelli/bitcoin_txref_code
Go Reference Implementation (supports magic codes 0x3 and 0x6): https://github.com/kulpreet/txref
-C++ Reference Implementation (support magic codes 0x3, 0x4, 0x6, 0x7): https://github.com/dcdpr/btcr-DID-method/
+C++ Reference Implementation (supports magic codes 0x3, 0x4, 0x6, 0x7, 0x0 and 0x1): https://github.com/dcdpr/libtxref/
+
+Java Reference Implementation (supports magic codes 0x3, 0x4, 0x6, 0x7, 0x0 and 0x1): https://github.com/dcdpr/libtxref-java/
== Appendices ==
-=== Test Vectors ===
-There are two sets of Test Vectors included here:
+=== Test Examples ===
-* Bech32 Encoding Test Vectors. These are to test if a implementation accepts the encoding, with the correct human readable part, and separator.
-* Bitcoin TxRef Test Vectors. These test the full specification, in particular, correct values for block height and the transaction index.
+The following examples show values for various combinations on mainnet and testnet; encoding block height, transaction index, and an optional output index.
-==== Bech32 Encoding (for TxRef). ====
-''Please Note: All test vectors are shown to help test if a string is compliant or not. All real-life applications (such as for Bitcoin) should comply with the Bitcoin Test Vectors listed Below.''
+==== TxRef ====
+The following list gives properly encoded mainnet '''TxRef'''s and the decoded hex values (block height, transaction index)
-The following strings have a valid Human Readable Part and Bech32 Checksum.
-* TX1A12UEL5L
-* tx1an83characterlonghumanreadablepartthatcontainsthenumber1andtheexcludedcharactersbio1tt5tgs
-* tx1abcdef1qpzry9x8gf2tvdw0s3jn54khce6mua7lmqqqxw
-* tx11qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqc8247j
+* tx1:rqqq-qqqq-qwtv-vjr : (0x0, 0x0)
+* tx1:rqqq-qqll-lj68-7n2 : (0x0, 0x7FFF)
+* tx1:r7ll-llqq-qats-vx9 : (0xFFFFFF, 0x0)
+* tx1:r7ll-llll-lp6m-78v : (0xFFFFFF, 0x7FFF)
-The following list gives invalid TxRef's and the reason for their invalidity.
-* bc1qw508d6qejxtdg4y5r3zarvary0c5xw7kg3g4ty : Invalid human-readable part
-* tx1qw508d6qejxtdg4y5r3zarvary0c5xw7kv8f3t5 : Invalid checksum
+The following list gives properly encoded testnet '''TxRef'''s and the decoded hex values (block height, transaction index)
-==== Bitcoin TxRef (mainnet and testnet) ====
-The following list gives properly encoded Bitcoin mainnet TxRef's and the values in hex. (block height, transaction index)
+* txtest1:xqqq-qqqq-qrrd-ksa : (0x0, 0x0)
+* txtest1:xqqq-qqll-lljx-y35 : (0x0, 0x7FFF)
+* txtest1:x7ll-llqq-qsr3-kym : (0xFFFFFF, 0x0)
+* txtest1:x7ll-llll-lvj6-y9j : (0xFFFFFF, 0x7FFF)
-* tx1:rqqq-qqqq-qmhu-qhp : (0x0, 0x0)
-* tx1:rqqq-qqll-l8xh-jkg : (0x0, 0x7FFF)
-* tx1:r7ll-llqq-qghq-qr8 : (0xFFFFFF, 0x0)
-* tx1:r7ll-llll-l5xt-jzw : (0xFFFFFF, 0x7FFF)
+The following list gives valid (sometimes strangely formatted) '''TxRef'''s and the decoded values (block height, transaction index)*
+* tx1:r29u-mqjx-putt-3p0 : (456789, 1234)
+* TX1R29UMQJXPUTT3P0 : (456789, 1234)
+* tx1 r29u mqjx putt 3p0 : (456789, 1234)
+* tx1!r29u/mqj*x-putt^^3p0 : (456789, 1234)
-The following list gives properly encoded Bitcoin testnet TxRef's and the values in hex. (block height, transaction index)
+The following list gives invalid '''TxRef'''s and the reason for their invalidity.
+* tx1:t7ll-llll-lcq3-aj4 : Magic 0xB instead of 0x3.
+* tx1:rlll-llll-lu9m-00x : Version 1 instead of 0.
+* tx1:r7ll-llll-lqfu-gss2 : Valid Bech32, but ten 5 bit unsigned chars instead of nine.
+* tx1:r7ll-llll-rt5h-wz : Valid Bech32, but eight 5 bit unsigned chars instead of nine.
+* tx1:r7ll-LLLL-lp6m-78v : Invalid Bech32 due to mixed case. Would decode correctly otherwise.
-* txtest1:xqqq-qqqq-qkla-64l : (0x0, 0x0)
-* txtest1:xqqq-qqll-l2wk-g5k : (0x0, 0x7FFF)
-* txtest1:x7ll-llqq-q9lp-6pe : (0xFFFFFF, 0x0)
-* txtest1:x7ll-llll-lew2-gqs : (0xFFFFFF, 0x7FFF)
+==== TxRef with Outpoints ====
+The following list gives properly encoded mainnet '''TxRef'''s with Outpoints and the decoded values (block height, transaction index, outpoint index)
-The following list gives valid (though strangely formatted) Bitcoin TxRef's and the values in hex. (block height, transaction index)
-* tx1:rjk0-uqay-zsrw-hqe : (0x71F69, 0x89D)
-* TX1RJK0UQAYZSRWHQE : (0x71F69, 0x89D)
-* TX1RJK0--UQaYZSRw----HQE : (0x71F69, 0x89D)
-* tx1 rjk0 uqay zsrw hqe : (0x71F69, 0x89D)
-* tx1!rjk0\uqay*zsrw^^hqe : (0x71F69, 0x89D)
+* tx1:yqqq-qqqq-qqqq-rvum-0c : (0x0, 0x0, 0x0)
+* tx1:yqqq-qqll-lqqq-en8x-05 : (0x0, 0x7FFF, 0x0)
+* tx1:y7ll-llqq-qqqq-ggjg-w6 : (0xFFFFFF, 0x0, 0x0)
+* tx1:y7ll-llll-lqqq-jhf4-wk : (0xFFFFFF, 0x7FFF, 0x0)
-The following list gives invalid Bitcoin TxRef's and the reason for their invalidity.
-* tx1:t7ll-llll-ldup-3hh : Magic 0xB instead of 0x3. (0xFFFFFF, 0x7FFF)
-* tx1:rlll-llll-lfet-r2y : Version 1 instead of 0. (0xFFFFFF, 0x7FFF)
-* tx1:rjk0-u5ng-gghq-fkg7 : Valid Bech32, but 10x5bit packages instead of 8.
-* tx1:rjk0-u5qd-s43z : Valid Bech32, but 6x5bit packages instead of 8.
+* tx1:yqqq-qqqq-qpqq-pw4v-kq : (0x0, 0x0, 0x1)
+* tx1:yqqq-qqll-lpqq-m3w3-kv : (0x0, 0x7FFF, 0x1)
+* tx1:y7ll-llqq-qpqq-22ml-hz : (0xFFFFFF, 0x0, 0x1)
+* tx1:y7ll-llll-lpqq-s4qz-hw : (0xFFFFFF, 0x7FFF, 0x1)
-==== Bitcoin TxRef with Outpoints (mainnet and testnet) ====
-The following list gives properly encoded Bitcoin mainnet TxRef's with Outpoints and the values in hex. (block height, transaction index, TXO index)
-
-* tx1:yqqq-qqqq-qqqq-ksvh-26 : (0x0, 0x0, 0x0)
-* tx1:yqqq-qqll-lqqq-v0h2-2k : (0x0, 0x7FFF, 0x0)
-* tx1:y7ll-llqq-qqqq-a5zy-tc : (0xFFFFFF, 0x0, 0x0)
-* tx1:y7ll-llll-lqqq-8tee-t5 : (0xFFFFFF, 0x7FFF, 0x0)
-
-* tx1:yqqq-qqqq-qpqq-5j9q-nz : (0x0, 0x0, 0x1)
-* tx1:yqqq-qqll-lpqq-wd7a-nw : (0x0, 0x7FFF, 0x1)
-* tx1:y7ll-llqq-qpqq-lktn-jq : (0xFFFFFF, 0x0, 0x1)
-* tx1:y7ll-llll-lpqq-9fsw-jv : (0xFFFFFF, 0x7FFF, 0x1)
-
-* tx1:yjk0-uqay-zrfq-g2cg-t8 : (0x71F69, 0x89D, 0x123)
-* tx1:yjk0-uqay-zu4x-nk6u-pc : (0x71F69, 0x89D, 0x1ABC)
-
-The following list gives properly encoded Bitcoin testnet TxRef's with Outpoints and the values in hex. (block height, transaction index, TXO index)
-
-* txtest1:8qqq-qqqq-qqqq-cgru-fa : (0x0, 0x0, 0x0)
-* txtest1:8qqq-qqll-lqqq-zhcp-f3 : (0x0, 0x7FFF, 0x0)
-* txtest1:87ll-llqq-qqqq-nvd0-gl : (0xFFFFFF, 0x0, 0x0)
-* txtest1:87ll-llll-lqqq-fnkj-gn : (0xFFFFFF, 0x7FFF, 0x0)
-
-* txtest1:8qqq-qqqq-qpqq-622t-s9 : (0x0, 0x0, 0x1)
-* txtest1:8qqq-qqll-lpqq-q43k-sf : (0x0, 0x7FFF, 0x1)
-* txtest1:87ll-llqq-qpqq-3wyc-38 : (0xFFFFFF, 0x0, 0x1)
-* txtest1:87ll-llll-lpqq-t3l9-3t : (0xFFFFFF, 0x7FFF, 0x1)
-
-* txtest1:8jk0-uqay-zrfq-xjhr-gq : (0x71F69, 0x89D, 0x123)
-* txtest1:8jk0-uqay-zu4x-aw4h-zl : (0x71F69, 0x89D, 0x1ABC)
+* tx1:y29u-mqjx-ppqq-sfp2-tt : (456789, 1234, 1)
-=== Bitcoin TxRef Payload Value Choice: ===
+The following list gives properly encoded testnet '''TxRef'''s with Outpoints and the decoded values (block height, transaction index, outpoint index)
+
+* txtest1:8qqq-qqqq-qqqq-d5ns-vl : (0x0, 0x0, 0x0)
+* txtest1:8qqq-qqll-lqqq-htgd-vn : (0x0, 0x7FFF, 0x0)
+* txtest1:87ll-llqq-qqqq-xsar-da : (0xFFFFFF, 0x0, 0x0)
+* txtest1:87ll-llll-lqqq-u0x7-d3 : (0xFFFFFF, 0x7FFF, 0x0)
+
+* txtest1:8qqq-qqqq-qpqq-0k68-48 : (0x0, 0x0, 0x1)
+* txtest1:8qqq-qqll-lpqq-4fp6-4t : (0x0, 0x7FFF, 0x1)
+* txtest1:87ll-llqq-qpqq-yj55-59 : (0xFFFFFF, 0x0, 0x1)
+* txtest1:87ll-llll-lpqq-7d0f-5f : (0xFFFFFF, 0x7FFF, 0x1)
+
+* txtest1:829u-mqjx-ppqq-73wp-gv : (456789, 1234, 1)
+
+
+=== TxRef Payload Value Choices: ===
Some calculations showing why we chose these particular bit-length of the block height and transaction index.
==== Block Height Value: ====
-24-bit: between 0, and 0xFFFFFF (16,777,216 blocks).
+24 bits: value can be between 0, and 0xFFFFFF (16777216 blocks).
-*There are ~52,500 blocks every year, leading to ~319 years of blocks addressable.
-*Therefore before year 2328 this specification should be extended. (We think that we have plenty of time).
+* In early April, 2021, there have been 677700 blocks
+* There are roughly (365 days * 24 hours * 6 blocks / hour) = 52560 blocks every year, implying about (16777216 - 677700) / 52560 = 306 more years of addressable blocks.
+* Some time before year 2327 this specification should be extended.
==== Tx Position Value: ====
-15-bit: between 0x0, and 0x7FFF. (32,768 transactions).
+15 bits: value can be between 0x0, and 0x7FFF (32768 transactions).
-*The ''realistic'' smallest Tx is 83 Bytes: Max 12047 tx in a block.
+*The ''realistic'' smallest Tx is 83 Bytes for maximum 12047 tx in a block.
**4B version + 1B tx_in count + 36B previous_output + 1B script length + 0B signature script + 4B sequence + 1B tx_out count + 8B amount + 1B script length + 23B pubkey script + 4B lock_time = 83B
-*The ''extreme'' smallest Tx is 60 Byte's: Max 16665 tx in a block.
+*The ''extreme'' smallest Tx is 60 Bytes for maximum 16665 tx in a block.
**4B version + 1B tx_in count + 36B previous_output + 1B script length + 0B signature script + 4B sequence + 1B tx_out count + 8B amount + 1B script length + 0B pubkey script + 4B lock_time = 60B
== Acknowledgements ==
diff --git a/bip-0141.mediawiki b/bip-0141.mediawiki
index 82f6abdc..85287296 100644
--- a/bip-0141.mediawiki
+++ b/bip-0141.mediawiki
@@ -127,7 +127,7 @@ Sigops per block is currently limited to 20,000. We change this restriction as f
Sigops in the current pubkey script, signature script, and P2SH check script are counted at 4 times their previous value.
The sigop limit is likewise quadrupled to ≤ 80,000.
-Each P2WPKH input is counted as 1 sigop. In addition, opcodes within a P2WSH witnessScript
are counted identically as previously within the P2SH redeemScript
. That is, CHECKSIG is counted as only 1 sigop, and CHECKMULTISIG is counted as 1 to 20 sigops according to the arguments. This rule applies to both native witness program and P2SH witness program.
+Each P2WPKH input is counted as 1 sigop. In addition, opcodes within a P2WSH witnessScript
are counted identically as previously within the P2SH redeemScript
. That is, CHECKSIG is counted as only 1 sigop. When preceded by OP_1 to OP_16 CHECKMULTISIG is counted as 1 to 16 sigops respectively, otherwise it is counted as 20 sigops. This rule applies to both native witness program and P2SH witness program.
=== Additional definitions ===
diff --git a/bip-0155.mediawiki b/bip-0155.mediawiki
index 71fe3cc0..3e7b0d82 100644
--- a/bip-0155.mediawiki
+++ b/bip-0155.mediawiki
@@ -44,8 +44,7 @@ interpreted as described in RFC 2119[[https://tools.ietf.org/html/rfc2119 RF
The ]addrv2
message is defined as a message where pchCommand == "addrv2"
.
It is serialized in the standard encoding for P2P messages.
-Its format is similar to the current addr
message format
-[[https://bitcoin.org/en/developer-reference#addr Bitcoin Developer Reference: addr message]], with the difference that the
+Its format is similar to the current addr
message format, with the difference that the
fixed 16-byte IP address is replaced by a network ID and a variable-length address, and the services format has been changed to [https://en.bitcoin.it/wiki/Protocol_documentation#Variable_length_integer CompactSize].
This means that the message contains a serialized std::vector
of the following structure:
@@ -132,9 +131,9 @@ See the appendices for the address encodings to be used for the various networks
==Signaling support and compatibility==
-Introduce a new message type sendaddrv2
. Sending such a message indicates that a node can understand and prefers to receive addrv2
messages instead of addr
messages. I.e. "Send me addrv2".
+Introduce a new message type sendaddrv2
. Sending such a message indicates that a node can understand and prefers to receive addrv2
messages instead of addr
messages. I.e. "Send me addrv2". Sending or not sending this message does not imply any preference with respect to receiving unrequested address messages.
-sendaddrv2
SHOULD be sent after receiving the verack
message from the peer.
+The sendaddrv2
message MUST only be sent in response to the version
message from a peer and prior to sending the verack
message.
For older peers, that did not emit sendaddrv2
, keep sending the legacy addr
message, ignoring addresses with the newly introduced address types.
diff --git a/bip-0173.mediawiki b/bip-0173.mediawiki
index c3ee0605..1fdd8bed 100644
--- a/bip-0173.mediawiki
+++ b/bip-0173.mediawiki
@@ -208,7 +208,7 @@ be of the same length as the mainnet counterpart (to simplify
implementations' assumptions about lengths), but still be visually
distinct. for testnet.
* The data-part values:
-** 1 byte: the witness version
+** 1 character (representing 5 bits of data): the witness version
** A conversion of the 2-to-40-byte witness program (as defined by [https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki BIP141]) to base32:
*** Start with the bits of the witness program, most significant bit per byte first.
*** Re-arrange those bits into groups of 5, and pad with zeroes at the end if needed.
diff --git a/bip-0174.mediawiki b/bip-0174.mediawiki
index c424c5d7..d70a7f18 100644
--- a/bip-0174.mediawiki
+++ b/bip-0174.mediawiki
@@ -5,7 +5,7 @@
Author: Andrew Chow
Comments-Summary: No comments yet.
Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0174
- Status: Proposed
+ Status: Final
Type: Standards Track
Created: 2017-07-12
License: BSD-2-Clause
@@ -21,6 +21,9 @@ signatures for an input while the input does not have a complete set of signatur
The signer can be offline as all necessary information will be provided in the
transaction.
+The generic format is described here in addition to the specification for version 0
+of this format.
+
===Copyright===
This BIP is licensed under the 2-clause BSD license.
@@ -48,272 +51,588 @@ is the separator here 0x00 instead of 0xff ?'''
The separator here is used to distinguish between each chunk of data. A separator of 0x00 would mean that
the unserializer can read it as a key length of 0, which would never occur with actual keys. It can thus
be used as a separator and allow for easier unserializer implementation..
-Each key-value pair must have a unique key within its scope; duplicates are not allowed. The format
-of a record is as follows:
-Note: <..> indicates that the data is prefixed by a compact size unsigned integer representing
-the length of that data. {..} indicates the raw data itself.
-
-|
-
+ := * *
+ := 0x70 0x73 0x62 0x74 0xFF
+ := * 0x00
+ := * 0x00
+ := * 0x00
+ :=
+ :=
+ :=
-{| class="wikitable" style="width: auto; text-align: center; font-size: smaller; table-layout: fixed;"
-!Name
-!Type
-!Description
-|-
-| Key Length
-| Compact Size Unsigned Integer
-| Specify how long the key is
-|-
-| Key
-| byte[]
-| The Key itself
-|-
-| Value Length
-| Compact Size Unsigned Integer
-| Specify how long the value is
-|-
-| Value
-| byte[]
-| The Value itself
-|}
+Where:
-The format of each key-value map is as follows:
-
-
-{key-value pair}|{key-value pair}|...|{0x00}
-
-
-{| class="wikitable" style="width: auto; text-align: center; font-size: smaller; table-layout: fixed;"
-!Field Size
-!Name
-!Type
-!Value
-!Description
-|-
-| 1+
-| Key-value pairs
-| Array of key-value pairs
-| varies
-| The key-value pairs.
-|-
-| 1
-| separator
-| char
-| 0x00
-| Must be 0x00 at the end of the map.
-|}
-
-At the beginning of each key is a compact size unsigned integer representing the type.
-This compact size unsigned integer must be minimally encoded, i.e. if the value can be represented using one byte, it must be represented as one byte.
-For convenience, this BIP will specify types using their full serialization, so a multi-byte type will have it's full prefix and zero padding as necessary.
-There are global types, per-input types, and per-output types.
+;
+: A compact size unsigned integer representing the type. This compact size unsigned integer must be minimally encoded, i.e. if the value can be represented using one byte, it must be represented as one byte. There can be multiple entries with the same within a specific , but the must be unique.
+;
+: The compact size unsigned integer containing the combined length of and
+;
+: The compact size unsigned integer containing the length of .
+;
+: Magic bytes which are ASCII for psbt ['''Why use 4 bytes for psbt?''' The
+transaction format needed to start with a 5 byte header which uniquely identifies
+it. The first bytes were chosen to be the ASCII for psbt because that stands for
+Partially Signed Bitcoin Transaction. ] followed by a separator of 0xFF ['''Why Use a separator after the magic bytes?''' The separator
+is part of the 5 byte header for PSBT. This byte is a separator of ]0xff because
+this will cause any non-PSBT unserializer to fail to properly unserialize the PSBT
+as a normal transaction. Likewise, since the 5 byte header is fixed, no transaction
+in the non-PSBT format will be able to be unserialized by a PSBT unserializer.. This integer must be serialized in most significant byte order.
The currently defined global types are as follows:
-* Type: Unsigned Transaction PSBT_GLOBAL_UNSIGNED_TX = 0x00
-** Key: None. The key must only contain the 1 byte type.
-*** {0x00}
-** Value: The transaction in network serialization. The scriptSigs and witnesses for each input must be empty. The transaction must be in the old serialization format (without witnesses). A PSBT must have a transaction, otherwise it is invalid.
-*** {transaction}
-** Note: Every PSBT must have a field with this type.
-
-* Type: Extended Public Key PSBT_GLOBAL_XPUB = 0x01
-** Key: The type followed by the 78 byte serialized extended public key as defined by BIP 32. Extended public keys are those that can be used to derive public keys used in the inputs and outputs of this transaction. It should be the public key at the highest hardened derivation index so that the unhardened child keys used in the transaction can be derived.
-*** {0x01}|{xpub}
-** Value: The master key fingerprint as defined by BIP 32 concatenated with the derivation path of the public key. The derivation path is represented as 32-bit little endian unsigned integer indexes concatenated with each other. The number of 32 bit unsigned integer indexes must match the depth provided in the extended public key.
-*** {master key fingerprint}|{32-bit uint}|...|{32-bit uint}
-
-* Type: Version Number PSBT_GLOBAL_VERSION = 0xFB
-** Key: None. The key must only contain the 1 byte type.
-*** {0xFB}
-** Value: The 32-bit little endian unsigned integer representing the version number of this PSBT. If ommitted, the version number is 0.
-*** {32-bit uint}
-
-* Type: Proprietary Use Type PSBT_GLOBAL_PROPRIETARY = 0xFC
-** Key: Variable length identifier prefix, followed by a subtype, followed by the key data itself.
-*** {0xFC}||{subtype}|{key data}
-** Value: Any value data as defined by the proprietary type user.
-***
+{|
+! Name
+!
+!
+! Description
+!
+! Description
+! Versions Requiring Inclusion
+! Versions Requiring Exclusion
+! Versions Allowing Inclusion
+! Parent BIP
+|-
+| Unsigned Transaction
+| PSBT_GLOBAL_UNSIGNED_TX = 0x00
+| None
+| No key data
+|
+| The transaction in network serialization. The scriptSigs and witnesses for each input must be empty. The transaction must be in the old serialization format (without witnesses).
+| 0
+|
+| 0
+| 174
+|-
+| Extended Public Key
+| PSBT_GLOBAL_XPUB = 0x01
+|
+| The 78 byte serialized extended public key as defined by BIP 32. Extended public keys are those that can be used to derive public keys used in the inputs and outputs of this transaction. It should be the public key at the highest hardened derivation index so that the unhardened child keys used in the transaction can be derived.
+| <32-bit uint> <32-bit uint>*
+| The master key fingerprint as defined by BIP 32 concatenated with the derivation path of the public key. The derivation path is represented as 32-bit little endian unsigned integer indexes concatenated with each other. The number of 32 bit unsigned integer indexes must match the depth provided in the extended public key.
+|
+|
+| 0, 2
+| 174
+|-
+| Transaction Version
+| PSBT_GLOBAL_TX_VERSION = 0x02
+| None
+| No key data
+| <32-bit uint>
+| The 32-bit little endian signed integer representing the version number of the transaction being created. Note that this is not the same as the PSBT version number specified by the PSBT_GLOBAL_VERSION field.
+| 2
+| 0
+| 2
+| [[bip-0370.mediawiki|370]]
+|-
+| Fallback Locktime
+| PSBT_GLOBAL_FALLBACK_LOCKTIME = 0x03
+| None
+| No key data
+| <32-bit uint>
+| The 32-bit little endian unsigned integer representing the transaction locktime to use if no inputs specify a required locktime.
+|
+| 0
+| 2
+| [[bip-0370.mediawiki|370]]
+|-
+| Input Count
+| PSBT_GLOBAL_INPUT_COUNT = 0x04
+| None
+| No key data
+|
+| Compact size unsigned integer representing the number of inputs in this PSBT.
+| 2
+| 0
+| 2
+| [[bip-0370.mediawiki|370]]
+|-
+| Output Count
+| PSBT_GLOBAL_OUTPUT_COUNT = 0x05
+| None
+| No key data
+|
+| Compact size unsigned integer representing the number of outputs in this PSBT.
+| 2
+| 0
+| 2
+| [[bip-0370.mediawiki|370]]
+|-
+| Transaction Modifiable Flags
+| PSBT_GLOBAL_TX_MODIFIABLE = 0x06
+| None
+| No key data
+|
+| A single byte boolean (0 for False, 1 for True) representing whether inputs can be modified, followed by a single byte boolean representing whether outputs can be modified.
+|
+| 0
+| 2
+| [[bip-0370.mediawiki|370]]
+|-
+| SIGHASH_SINGLE Inputs
+| PSBT_GLOBAL_SIGHASH_SINGLE_INPUTS = 0x07
+| None
+| No key data
+|
+| A bit vector representing which input indexes use SIGHASH_SINGLE. If the bit for an index is set to 1, then the input and output pair at that index are tied together with SIGHASH_SINGLE and must be moved together.
+|
+| 0
+| 2
+| [[bip-0370.mediawiki|370]]
+|-
+| PSBT Version Number
+| PSBT_GLOBAL_VERSION = 0xFB
+| None
+| No key data
+| <32-bit uint>
+| The 32-bit little endian unsigned integer representing the version number of this PSBT. If omitted, the version number is 0.
+|
+|
+| 0, 2
+| 174
+|-
+| Proprietary Use Type
+| PSBT_GLOBAL_PROPRIETARY = 0xFC
+|
+| Compact size unsigned integer , followed by identifier prefix of that length , followed by a subtype , followed by the key data itself .
+|
+| Any value data as defined by the proprietary type user.
+|
+|
+| 0, 2
+| 174
+|}
The currently defined per-input types are defined as follows:
-* Type: Non-Witness UTXO PSBT_IN_NON_WITNESS_UTXO = 0x00
-** Key: None. The key must only contain the 1 byte type.
-***{0x00}
-** Value: The transaction in network serialization format the current input spends from. This should be present for inputs that spend non-segwit outputs and can be present for inputs that spend segwit outputs. An input can have both PSBT_IN_NON_WITNESS_UTXO and PSBT_IN_WITNESS_UTXO . ['''Why can both UTXO types be provided?''' Many wallets began requiring the full previous transaction (i.e. ]PSBT_IN_NON_WITNESS_UTXO ) for segwit inputs when PSBT was already in use. In order to be compatible with software which were expecting PSBT_IN_WITNESS_UTXO , both UTXO types must be allowed.
-*** {transaction}
-
-* Type: Witness UTXO PSBT_IN_WITNESS_UTXO = 0x01
-** Key: None. The key must only contain the 1 byte type.
-*** {0x01}
-** Value: The entire transaction output in network serialization which the current input spends from. This should only be present for inputs which spend segwit outputs, including P2SH embedded ones. An input can have both PSBT_IN_NON_WITNESS_UTXO and PSBT_IN_WITNESS_UTXO
-*** {serialized transaction output({output value}|)}
-
-* Type: Partial Signature PSBT_IN_PARTIAL_SIG = 0x02
-** Key: The public key which corresponds to this signature.
-*** {0x02}|{public key}
-** Value: The signature as would be pushed to the stack from a scriptSig or witness.
-*** {signature}
-
-* Type: Sighash Type PSBT_IN_SIGHASH_TYPE = 0x03
-** Key: None. The key must only contain the 1 byte type.
-*** {0x03}
-** Value: The 32-bit unsigned integer specifying the sighash type to be used for this input. Signatures for this input must use the sighash type, finalizers must fail to finalize inputs which have signatures that do not match the specified sighash type. Signers who cannot produce signatures with the sighash type must not provide a signature.
-*** {sighash type}
-
-* Type: Redeem Script PSBT_IN_REDEEM_SCRIPT = 0x04
-** Key: None. The key must only contain the 1 byte type.
-*** {0x04}
-** Value: The redeemScript for this input if it has one.
-*** {redeemScript}
-
-* Type: Witness Script PSBT_IN_WITNESS_SCRIPT = 0x05
-** Key: None. The key must only contain the 1 byte type.
-*** {0x05}
-** Value: The witnessScript for this input if it has one.
-*** {witnessScript}
-
-* Type: BIP 32 Derivation Path PSBT_IN_BIP32_DERIVATION = 0x06
-** Key: The public key
-*** {0x06}|{public key}
-** Value: The master key fingerprint as defined by BIP 32 concatenated with the derivation path of the public key. The derivation path is represented as 32 bit unsigned integer indexes concatenated with each other. Public keys are those that will be needed to sign this input.
-*** {master key fingerprint}|{32-bit uint}|...|{32-bit uint}
-
-* Type: Finalized scriptSig PSBT_IN_FINAL_SCRIPTSIG = 0x07
-** Key: None. The key must only contain the 1 byte type.
-*** {0x07}
-** Value: The Finalized scriptSig contains a fully constructed scriptSig with signatures and any other scripts necessary for the input to pass validation.
-*** {scriptSig}
-
-* Type: Finalized scriptWitness PSBT_IN_FINAL_SCRIPTWITNESS = 0x08
-** Key: None. The key must only contain the 1 byte type.
-*** {0x08}
-** Value: The Finalized scriptWitness contains a fully constructed scriptWitness with signatures and any other scripts necessary for the input to pass validation.
-*** {scriptWitness}
-
-* Type: Proof-of-reserves commitment PSBT_IN_POR_COMMITMENT = 0x09
-** Key: None. The key must only contain the 1 byte type.
-*** {0x09}
-** Value: The UTF-8 encoded commitment message string for the proof-of-reserves. See [[bip-0127.mediawiki|BIP 127]] for more information.
-*** {porCommitment}
-
-* Type: RIPEMD160 preimage PSBT_IN_RIPEMD160 = 0x0a
-** Key: The resulting hash of the preimage
-*** {0x0a}|{20-byte hash}
-** Value: The hash preimage, encoded as a byte vector, which must equal the key when run through the `RIPEMD160` algorithm
-*** {preimage}
-
-* Type: SHA256 preimage PSBT_IN_SHA256 = 0x0b
-** Key: The resulting hash of the preimage
-*** {0x0b}|{32-byte hash}
-** Value: The hash preimage, encoded as a byte vector, which must equal the key when run through the `SHA256` algorithm
-*** {preimage}
-
-* Type: HASH160 preimage PSBT_IN_HASH160 = 0x0c
-** Key: The resulting hash of the preimage
-*** {0x0c}|{20-byte hash}
-** Value: The hash preimage, encoded as a byte vector, which must equal the key when run through the `SHA256` algorithm followed by the `RIPEMD160` algorithm
-*** {preimage}
-
-* Type: HASH256 preimage PSBT_IN_HASH256 = 0x0d
-** Key: The resulting hash of the preimage
-*** {0x0d}|{32-byte hash}
-** Value: The hash preimage, encoded as a byte vector, which must equal the key when run through the `SHA256` algorithm twice
-*** {preimage}
-
-* Type: Proprietary Use Type PSBT_IN_PROPRIETARY = 0xFC
-** Key: Variable length identifier prefix, followed by a subtype, followed by the key data itself.
-*** {0xFC}||{subtype}|{key data}
-** Value: Any value data as defined by the proprietary type user.
-***
+{|
+! Name
+!
+!
+! Description
+!
+! Description
+! Versions Requiring Inclusion
+! Versions Requiring Exclusion
+! Versions Allowing Inclusion
+! Parent BIP
+|-
+| Non-Witness UTXO
+| PSBT_IN_NON_WITNESS_UTXO = 0x00
+| None
+| No key data
+|
+| The transaction in network serialization format the current input spends from. This should be present for inputs that spend non-segwit outputs and can be present for inputs that spend segwit outputs. An input can have both PSBT_IN_NON_WITNESS_UTXO and PSBT_IN_WITNESS_UTXO . ['''Why can both UTXO types be provided?''' Many wallets began requiring the full previous transaction (i.e. ]PSBT_IN_NON_WITNESS_UTXO ) for segwit inputs when PSBT was already in use. In order to be compatible with software which were expecting PSBT_IN_WITNESS_UTXO , both UTXO types must be allowed.
+|
+|
+| 0, 2
+| 174
+|-
+| Witness UTXO
+| PSBT_IN_WITNESS_UTXO = 0x01
+| None
+| No key data
+| <64-bit int>
+| The entire transaction output in network serialization which the current input spends from. This should only be present for inputs which spend segwit outputs, including P2SH embedded ones. An input can have both PSBT_IN_NON_WITNESS_UTXO and PSBT_IN_WITNESS_UTXO
+|
+|
+| 0, 2
+| 174
+|-
+| Partial Signature
+| PSBT_IN_PARTIAL_SIG = 0x02
+|
+| The public key which corresponds to this signature.
+|
+| The signature as would be pushed to the stack from a scriptSig or witness.
+|
+|
+| 0, 2
+| 174
+|-
+| Sighash Type
+| PSBT_IN_SIGHASH_TYPE = 0x03
+| None
+| No key data
+| <32-bit uint>
+| The 32-bit unsigned integer specifying the sighash type to be used for this input. Signatures for this input must use the sighash type, finalizers must fail to finalize inputs which have signatures that do not match the specified sighash type. Signers who cannot produce signatures with the sighash type must not provide a signature.
+|
+|
+| 0, 2
+| 174
+|-
+| Redeem Script
+| PSBT_IN_REDEEM_SCRIPT = 0x04
+| None
+| No key data
+|
+| The redeemScript for this input if it has one.
+|
+|
+| 0, 2
+| 174
+|-
+| Witness Script
+| PSBT_IN_WITNESS_SCRIPT = 0x05
+| None
+| No key data
+|
+| The witnessScript for this input if it has one.
+|
+|
+| 0, 2
+| 174
+|-
+| BIP 32 Derivation Path
+| PSBT_IN_BIP32_DERIVATION = 0x06
+|
+| The public key
+| <32-bit uint> <32-bit uint>*
+| The master key fingerprint as defined by BIP 32 concatenated with the derivation path of the public key. The derivation path is represented as 32 bit unsigned integer indexes concatenated with each other. Public keys are those that will be needed to sign this input.
+|
+|
+| 0, 2
+| 174
+|-
+| Finalized scriptSig
+| PSBT_IN_FINAL_SCRIPTSIG = 0x07
+| None
+| No key data
+|
+| The Finalized scriptSig contains a fully constructed scriptSig with signatures and any other scripts necessary for the input to pass validation.
+|
+|
+| 0, 2
+| 174
+|-
+| Finalized scriptWitness
+| PSBT_IN_FINAL_SCRIPTWITNESS = 0x08
+| None
+| No key data
+|
+| The Finalized scriptWitness contains a fully constructed scriptWitness with signatures and any other scripts necessary for the input to pass validation.
+|
+|
+| 0, 2
+| 174
+|-
+| Proof-of-reserves commitment
+| PSBT_IN_POR_COMMITMENT = 0x09
+| None
+| No key data
+|
+| The UTF-8 encoded commitment message string for the proof-of-reserves. See [[bip-0127.mediawiki|BIP 127]] for more information.
+|
+|
+| 0, 2
+| [[bip-0127.mediawiki|127]]
+|-
+| RIPEMD160 preimage
+| PSBT_IN_RIPEMD160 = 0x0a
+| <20-byte hash>
+| The resulting hash of the preimage
+|
+| The hash preimage, encoded as a byte vector, which must equal the key when run through the RIPEMD160 algorithm
+|
+|
+| 0, 2
+| 174
+|-
+| SHA256 preimage
+| PSBT_IN_SHA256 = 0x0b
+| <32-byte hash>
+| The resulting hash of the preimage
+|
+| The hash preimage, encoded as a byte vector, which must equal the key when run through the SHA256 algorithm
+|
+|
+| 0, 2
+| 174
+|-
+| HASH160 preimage
+| PSBT_IN_HASH160 = 0x0c
+| <20-byte hash>
+| The resulting hash of the preimage
+|
+| The hash preimage, encoded as a byte vector, which must equal the key when run through the SHA256 algorithm followed by the RIPEMD160 algorithm
+|
+|
+| 0, 2
+| 174
+|-
+| HASH256 preimage
+| PSBT_IN_HASH256 = 0x0d
+| <32-byte hash>
+| The resulting hash of the preimage
+|
+| The hash preimage, encoded as a byte vector, which must equal the key when run through the SHA256 algorithm twice
+|
+|
+| 0, 2
+| 174
+|-
+| Previous TXID
+| PSBT_IN_PREVIOUS_TXID = 0x0e
+| None
+| No key data
+|
+| 32 byte txid of the previous transaction whose output at PSBT_IN_OUTPUT_INDEX is being spent.
+| 2
+| 0
+| 2
+| [[bip-0370.mediawiki|370]]
+|-
+| Spent Output Index
+| PSBT_IN_OUTPUT_INDEX = 0x0f
+| None
+| No key data
+| <32-bit uint>
+| 32 bit little endian integer representing the index of the output being spent in the transaction with the txid of PSBT_IN_PREVIOUS_TXID.
+| 2
+| 0
+| 2
+| [[bip-0370.mediawiki|370]]
+|-
+| Sequence Number
+| PSBT_IN_SEQUENCE = 0x10
+| None
+| No key data
+| <32-bit uint>
+| The 32 bit unsigned little endian integer for the sequence number of this input. If omitted, the sequence number is assumed to be the final sequence number (0xffffffff).
+|
+| 0
+| 2
+| [[bip-0370.mediawiki|370]]
+|-
+| Required Time-based Locktime
+| PSBT_IN_REQUIRED_TIME_LOCKTIME = 0x11
+| None
+| No key data
+| <32-bit uint>
+| 32 bit unsigned little endian integer greater than or equal to 500000000 representing the minimum Unix timestamp that this input requires to be set as the transaction's lock time.
+|
+| 0
+| 2
+| [[bip-0370.mediawiki|370]]
+|-
+| Required Height-based Locktime
+| PSBT_IN_REQUIRED_HEIGHT_LOCKTIME = 0x12
+| None
+| No key data
+| <32-bit uiht>
+| 32 bit unsigned little endian integer less than 500000000 representing the minimum block height that this input requires to be set as the transaction's lock time.
+|
+| 0
+| 2
+| [[bip-0370.mediawiki|370]]
+|-
+| Taproot Key Spend Signature
+| PSBT_IN_TAP_KEY_SIG = 0x13
+| None
+| No key data
+|
+| The 64 or 65 byte Schnorr signature for key path spending a Taproot output. Finalizers should remove this field after PSBT_IN_FINAL_SCRIPTWITNESS is constructed.
+|
+|
+| 0, 2
+| [[bip-0371.mediawiki|371]]
+|-
+| Taproot Script Spend Signature
+| PSBT_IN_TAP_SCRIPT_SIG = 0x14
+|
+| A 32 byte X-only public key involved in a leaf script concatenated with the 32 byte hash of the leaf it is part of.
+|
+| The 64 or 65 byte Schnorr signature for this pubkey and leaf combination. Finalizers should remove this field after PSBT_IN_FINAL_SCRIPTWITNESS is constructed.
+|
+|
+| 0, 2
+| [[bip-0371.mediawiki|371]]
+|-
+| Taproot Leaf Script
+| PSBT_IN_TAP_LEAF_SCRIPT = 0x15
+|
+| The control block for this leaf as specified in BIP 341. The control block contains the merkle tree path to this leaf.
+|