From 41efd1361e0421730b059be5ac14c397e2d0513c Mon Sep 17 00:00:00 2001
From: avirgovi <avirgovi@cisco.com>
Date: Thu, 25 Jun 2020 14:07:01 +0200
Subject: added 'btc_hd_wallet' amongst implementations in bip32, bip39, bip85

---
 bip-0032.mediawiki | 4 ++--
 bip-0039.mediawiki | 3 +++
 bip-0085.mediawiki | 4 +++-
 3 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/bip-0032.mediawiki b/bip-0032.mediawiki
index 9339307..a7f5297 100644
--- a/bip-0032.mediawiki
+++ b/bip-0032.mediawiki
@@ -274,9 +274,9 @@ Seed (hex): 4b381541583be4423346c643850da4b320e46a87ae3d2a4e6da11eba819cd4acba45
 
 ==Implementations==
 
-Two Python implementations exist:
+Three Python implementations exist:
 
-PyCoin (https://github.com/richardkiss/pycoin) is a suite of utilities for dealing with Bitcoin that includes BIP0032 wallet features.  BIP32Utils (https://pypi.org/project/bip32utils/) is a library and command line interface specifically focused on BIP0032 wallets and scripting.
+PyCoin (https://github.com/richardkiss/pycoin) is a suite of utilities for dealing with Bitcoin that includes BIP0032 wallet features.  BIP32Utils (https://pypi.org/project/bip32utils/) is a library and command line interface specifically focused on BIP0032 wallets and scripting. btc_hd_wallet (https://github.com/scgbckbone/btc-hd-wallet) easy to use python HD (paper) wallet implementation.
 
 2 Java implementations exist: https://github.com/bitsofproof/supernode/blob/1.1/api/src/main/java/com/bitsofproof/supernode/api/ExtendedKey.java and https://github.com/bushidowallet/bushido-java-core/tree/master/src/main/java/com/bushidowallet/core/bitcoin/bip32
 
diff --git a/bip-0039.mediawiki b/bip-0039.mediawiki
index 2b95c51..eef8155 100644
--- a/bip-0039.mediawiki
+++ b/bip-0039.mediawiki
@@ -175,3 +175,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-0085.mediawiki b/bip-0085.mediawiki
index 029de1a..1780f1c 100644
--- a/bip-0085.mediawiki
+++ b/bip-0085.mediawiki
@@ -77,6 +77,8 @@ Python library implementation: [https://github.com/ethankosakovsky/bipentropy py
 
 Coldcard Firmware: [https://github.com/Coldcard/firmware/pull/39]
 
+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:
@@ -147,7 +149,7 @@ Words Table
 |}
 
 ====12 English words====
-BIP39 English 12 word mnemonic seed 
+BIP39 English 12 word mnemonic seed
 
 128 bits of entropy as input to BIP39 to derive 12 word mnemonic
 
-- 
cgit v1.2.3


From 3d297861eb78db6151f282e4eaff0be4cd819aec Mon Sep 17 00:00:00 2001
From: "Dr. Maxim Orlovsky" <orlovsky@pandoracore.com>
Date: Mon, 7 Sep 2020 13:06:43 +0200
Subject: Require creator to initialize empty output fields

The current version of the spec requires creator role to initialize empty input fields, but says nothing about output field initialization. At the same time, the following role, updater, "should also add redeemScripts, witnessScripts, and BIP 32 derivation paths to the input and output data if it knows them.", which does not make any sense if the fields were uninitialized. The [current Bitcoin Core implementation does this](https://github.com/bitcoin/bitcoin/blob/a24806c25d7a81a9c436de58eb5778d93abab16b/src/psbt.cpp#L12), and [other PSBT implementations, like rust-bitcoin, follow this practice](https://github.com/rust-bitcoin/rust-bitcoin/blob/master/src/util/psbt/mod.rs#L59)
---
 bip-0174.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-0174.mediawiki b/bip-0174.mediawiki
index 65fa9a9..9bb35c8 100644
--- a/bip-0174.mediawiki
+++ b/bip-0174.mediawiki
@@ -357,7 +357,7 @@ Using the transaction format involves many different responsibilities. Multiple
 ===Creator===
 
 The Creator creates a new PSBT. It must create an unsigned transaction and place it in the PSBT.
-The Creator must create empty input fields.
+The Creator must create empty input and output fields fields.
 
 ===Updater===
 
-- 
cgit v1.2.3


From d509aa2110cf46a697356f7a83c7356e7f5b2650 Mon Sep 17 00:00:00 2001
From: "Dr. Maxim Orlovsky" <orlovsky@pandoracore.com>
Date: Mon, 7 Sep 2020 18:38:23 +0200
Subject: BIP 174: removing extra "fields" word

---
 bip-0174.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-0174.mediawiki b/bip-0174.mediawiki
index 9bb35c8..80c7284 100644
--- a/bip-0174.mediawiki
+++ b/bip-0174.mediawiki
@@ -357,7 +357,7 @@ Using the transaction format involves many different responsibilities. Multiple
 ===Creator===
 
 The Creator creates a new PSBT. It must create an unsigned transaction and place it in the PSBT.
-The Creator must create empty input and output fields fields.
+The Creator must create empty input and output fields.
 
 ===Updater===
 
-- 
cgit v1.2.3


From d353c54154bac64a88eb18cf2d47d15ead083de4 Mon Sep 17 00:00:00 2001
From: sabotag3x <sabotage.sta@gmail.com>
Date: Tue, 1 Sep 2020 10:58:18 -0300
Subject: Create portuguese.txt

Co-authored-by: Breno Rodrigues Brito <brenorb@gmail.com>
Co-authored-by: ninjastic <ninjasticdev@protonmail.com>
Co-authored-by: sabotag3x <sabotage.sta@gmail.com>
Co-authored-by: bitmover <67111541+bitmover-studio@users.noreply.github.com>
Co-authored-by: alegotardo <40860228+alegotardo@users.noreply.github.com>
Co-authored-by: kuthullu <kuthullu@gmail.com>
Co-authored-by: Trimegistus <trimegisto@rocketmail.com>
---
 bip-0039/bip-0039-wordlists.md |   17 +
 bip-0039/portuguese.txt        | 2048 ++++++++++++++++++++++++++++++++++++++++
 2 files changed, 2065 insertions(+)
 create mode 100644 bip-0039/portuguese.txt

diff --git a/bip-0039/bip-0039-wordlists.md b/bip-0039/bip-0039-wordlists.md
index 0940f35..5971197 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 0000000..4a89105
--- /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
-- 
cgit v1.2.3


From eb57dc00dd49ce10fd463bd64aca3c4fadf60e04 Mon Sep 17 00:00:00 2001
From: Prayank <prayank23@outlook.com>
Date: Tue, 6 Oct 2020 02:37:02 +0530
Subject: Change 'Client support' to 'Backwards compatibility'

+ Change 'Client support' section to 'Backwards compatibility'
+ Reasons: avoid confusion and according to the format mentioned in the below link:
https://github.com/bitcoin/bips/blob/master/bip-0002.mediawiki#specification
+ Discussed changes in https://github.com/bitcoin/bips/pull/994
---
 bip-0125.mediawiki | 8 ++------
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/bip-0125.mediawiki b/bip-0125.mediawiki
index 7dfdcbe..e43ddb1 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==
 
-- 
cgit v1.2.3


From dfa5042dc57bde230dea7a74f151efe58c632586 Mon Sep 17 00:00:00 2001
From: richard <36215881+hoganri@users.noreply.github.com>
Date: Fri, 16 Oct 2020 21:18:20 -0400
Subject: Update bip-0085.mediawiki

---
 bip-0085.mediawiki | 1 +
 1 file changed, 1 insertion(+)

diff --git a/bip-0085.mediawiki b/bip-0085.mediawiki
index 7c4cbca..659d5fc 100644
--- a/bip-0085.mediawiki
+++ b/bip-0085.mediawiki
@@ -72,6 +72,7 @@ OUTPUT
 ==Reference Implementation==
 
 Python library implementation: [https://github.com/ethankosakovsky/bipentropy python-bipentropy]
+JavaScript library implementation: [https://github.com/hoganri/bip85-js]
 
 ===Other Implementations===
 
-- 
cgit v1.2.3


From 9a119ce46af235a7711c137f8683e5c499cca026 Mon Sep 17 00:00:00 2001
From: Anthony Towns <aj@erisian.com.au>
Date: Sat, 17 Oct 2020 17:47:19 +1000
Subject: BIP8: Make signalling during LOCKED_IN recommended rather than
 mandatory

---
 bip-0008.mediawiki | 14 +++++---------
 1 file changed, 5 insertions(+), 9 deletions(-)

diff --git a/bip-0008.mediawiki b/bip-0008.mediawiki
index dc2291a..565331b 100644
--- a/bip-0008.mediawiki
+++ b/bip-0008.mediawiki
@@ -77,12 +77,13 @@ for the purposes of this proposal, and support two future upgrades for different
 When a block nVersion does not have top bits 001, it is treated as if all
 bits are 0 for the purposes of deployments.
 
+Miners should continue setting the bit in LOCKED_IN phase so uptake is visible, though this has no effect on consensus rules.
+
 ===New consensus rules===
 
 The new consensus rules for each soft fork are enforced for each block that has ACTIVE state.
 
-During the MUST_SIGNAL and LOCKED_IN phases, blocks that fail to signal are invalid.
-For flexibility, during the LOCKED_IN phase only, this rule does NOT require the top 3 bits to be set any particular way.
+During the MUST_SIGNAL phase, blocks that fail to signal are invalid.
 
 ===State transitions===
 
@@ -174,18 +175,13 @@ block, indexed by its parent.
 
 ===Mandatory signalling===
 
-Blocks received while in the MUST_SIGNAL and LOCKED_IN phases must be checked to ensure that they signal. For example:
+Blocks received while in the MUST_SIGNAL phase must be checked to ensure that they signal. For example:
 
     if (GetStateForBlock(block) == MUST_SIGNAL) {
         if ((block.nVersion & 0xE0000000) != 0x20000000 || ((block.nVersion >> bit) & 1) != 1) {
             return state.Invalid(BlockValidationResult::RECENT_CONSENSUS_CHANGE, "bad-version-bip8-must-signal");
         }
     }
-    if (GetStateForBlock(block) == LOCKED_IN) {
-        if (((block.nVersion >> bit) & 1) != 1) {
-            return state.Invalid(BlockValidationResult::RECENT_CONSENSUS_CHANGE, "bad-version-bip8-locked-in");
-        }
-    }
 
 Implementations should be careful not to ban peers that send blocks that are invalid due to not signalling (or blocks that build on those blocks), as that would allow an incompatible chain that is only briefly longer than the compliant chain to cause a split of the p2p network. If that occurred, nodes that have not set ''lockinontimeout'' may not see new blocks in the compliant chain, and thus not reorg to it at the point when it has more work, and would thus not be following the valid chain with the most work.
 
@@ -224,7 +220,7 @@ The template Object is also extended:
 The "version" key of the template is retained, and used to indicate the server's preference of deployments.
 If versionbits is being used, "version" MUST be within the versionbits range of [0x20000000...0x3FFFFFFF].
 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".
-Servers MUST set bits in "vbrequired" for deployments in MUST_SIGNAL and LOCKED_IN states, to ensure blocks produced are valid.
+Servers MUST set bits in "vbrequired" for deployments in MUST_SIGNAL state, to ensure blocks produced are valid.
 
 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.
-- 
cgit v1.2.3


From afe97b2eeeeaf8cd1a0658bb191da15b36a4dd3a Mon Sep 17 00:00:00 2001
From: Anthony Towns <aj@erisian.com.au>
Date: Sat, 17 Oct 2020 18:18:27 +1000
Subject: BIP8: allow some MUST_SIGNAL blocks to not signal

Using the same threshold for MUST_SIGNAL as STARTED means that any chain
that would have resulted in activation with lockinontimeout=false will
also result in activation with lockinontimeout=true (and vice-versa).
This reduces the ways in which a consensus split can occur, and avoids
a way in which miners could attempt to discourage users from setting
lockinontimeout=true.
---
 bip-0008.mediawiki | 20 ++++++++++++++++----
 1 file changed, 16 insertions(+), 4 deletions(-)

diff --git a/bip-0008.mediawiki b/bip-0008.mediawiki
index 565331b..394b80d 100644
--- a/bip-0008.mediawiki
+++ b/bip-0008.mediawiki
@@ -83,7 +83,7 @@ Miners should continue setting the bit in LOCKED_IN phase so uptake is visible,
 
 The new consensus rules for each soft fork are enforced for each block that has ACTIVE state.
 
-During the MUST_SIGNAL phase, blocks that fail to signal are invalid.
+During the MUST_SIGNAL phase, if '''(2016 - threshold)''' blocks in the retarget period have already failed to signal, any further blocks that fail to signal are invalid.
 
 ===State transitions===
 
@@ -175,11 +175,23 @@ block, indexed by its parent.
 
 ===Mandatory signalling===
 
-Blocks received while in the MUST_SIGNAL phase must be checked to ensure that they signal. For example:
+Blocks received while in the MUST_SIGNAL phase must be checked to ensure that they signal as required. For example:
 
     if (GetStateForBlock(block) == MUST_SIGNAL) {
-        if ((block.nVersion & 0xE0000000) != 0x20000000 || ((block.nVersion >> bit) & 1) != 1) {
-            return state.Invalid(BlockValidationResult::RECENT_CONSENSUS_CHANGE, "bad-version-bip8-must-signal");
+        int nonsignal = 0;
+        int count = 1 + (block.nHeight % 2016);
+        walk = block;
+        while (count > 0) {
+            --count;
+            if ((walk.nVersion & 0xE0000000) != 0x20000000 || ((walk.nVersion >> bit) & 1) != 1) {
+                ++nonsignal;
+                if (nonsignal + threshold > 2016) {
+                    return state.Invalid(BlockValidationResult::RECENT_CONSENSUS_CHANGE, "bad-version-bip8-must-signal");
+                }
+            } else if (nonsignal == 0) {
+                break;
+            }
+            walk = walk.parent;
         }
     }
 
-- 
cgit v1.2.3


From 1fbcd28584f6b295a1d8a735e265415c1b3eb7e8 Mon Sep 17 00:00:00 2001
From: Adam Gibson <ekaggata@gmail.com>
Date: Sun, 18 Oct 2020 13:37:50 +0100
Subject: update Joinmarket BIP78 status

---
 bip-0078.mediawiki | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/bip-0078.mediawiki b/bip-0078.mediawiki
index c795343..b775191 100644
--- a/bip-0078.mediawiki
+++ b/bip-0078.mediawiki
@@ -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 <code>pjos=0</code>, disable payment output substitution.
 * Verify that the transaction version, and the nLockTime are unchanged.
@@ -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<PSBT> 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==
-- 
cgit v1.2.3


From 77ed66afd5331414ee0d46611d612bb24eb78693 Mon Sep 17 00:00:00 2001
From: richard <36215881+hoganri@users.noreply.github.com>
Date: Wed, 21 Oct 2020 20:31:29 -0400
Subject: Update bip-0085.mediawiki

---
 bip-0085.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-0085.mediawiki b/bip-0085.mediawiki
index 659d5fc..b6c1333 100644
--- a/bip-0085.mediawiki
+++ b/bip-0085.mediawiki
@@ -71,7 +71,7 @@ OUTPUT
 
 ==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===
-- 
cgit v1.2.3


From d771818c9e96b1d9bfa62efdee3a24ae903a7a03 Mon Sep 17 00:00:00 2001
From: richard <36215881+hoganri@users.noreply.github.com>
Date: Wed, 21 Oct 2020 21:41:59 -0400
Subject: Update formatting

---
 bip-0085.mediawiki | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/bip-0085.mediawiki b/bip-0085.mediawiki
index b6c1333..40cff9b 100644
--- a/bip-0085.mediawiki
+++ b/bip-0085.mediawiki
@@ -71,12 +71,12 @@ OUTPUT
 
 ==Reference Implementation==
 
-Python library implementation: [https://github.com/ethankosakovsky/bip85]
-JavaScript library implementation: [https://github.com/hoganri/bip85-js]
+* 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]
+* Coldcard Firmware: [https://github.com/Coldcard/firmware/pull/39]
 
 ==Applications==
 
-- 
cgit v1.2.3


From 8744a4dd11e207953e2544d40fab3c7204434031 Mon Sep 17 00:00:00 2001
From: Rita Kitic <rikitau@protonmail.com>
Date: Tue, 27 Oct 2020 19:15:49 +0100
Subject: fix typo

---
 bip-0085.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-0085.mediawiki b/bip-0085.mediawiki
index 7c4cbca..02b1879 100644
--- a/bip-0085.mediawiki
+++ b/bip-0085.mediawiki
@@ -81,7 +81,7 @@ Coldcard Firmware: [https://github.com/Coldcard/firmware/pull/39]
 
 Application number define how entropy will be used post processing. Some basic examples follow:
 
-Derivation path uses the format <code>m/83696968/' + /app_no' + /index'</code> where ''app_no'' path for the application, and `index` in the index.
+Derivation path uses the format <code>m/83696968' + /app_no' + /index'</code> where ''app_no'' path for the application, and `index` in the index.
 
 ===BIP39===
 Application number: 39'
-- 
cgit v1.2.3


From 55d37134cf751959839315cb6a2223c376ca8f75 Mon Sep 17 00:00:00 2001
From: rage-proof <47944736+rage-proof@users.noreply.github.com>
Date: Thu, 29 Oct 2020 23:58:50 +0100
Subject: Update bip-0078.mediawiki

the payjoin proposal has more inputs
---
 bip-0078.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-0078.mediawiki b/bip-0078.mediawiki
index c795343..299d202 100644
--- a/bip-0078.mediawiki
+++ b/bip-0078.mediawiki
@@ -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 <code>maxadditionalfeecontribution</code>. Let's call this amount <code>actual contribution</code>.
 *** Make sure the actual contribution is only paying fee: The <code>actual contribution</code> 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: <code>actual contribution</code> is less than or equals to <code>originalPSBTFeeRate * vsize(sender_input_type) * (count(original_psbt_inputs) - count(payjoin_proposal_inputs))</code>. (see [[#fee-output|Fee output]] section)
+*** Make sure the actual contribution is only paying for fee incurred by additional inputs: <code>actual contribution</code> is less than or equals to <code>originalPSBTFeeRate * vsize(sender_input_type) * (count(payjoin_proposal_inputs) - count(original_psbt_inputs))</code>. (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
-- 
cgit v1.2.3


From dfbbe04ddf9644e49eefb3de437d092c8563ef8f Mon Sep 17 00:00:00 2001
From: Meheret Tesfaye <meherett@zoho.com>
Date: Tue, 3 Nov 2020 11:31:20 +0300
Subject: Update bip-0039.mediawiki

Add Python-HDWallet on Other Implementation.
---
 bip-0039.mediawiki | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/bip-0039.mediawiki b/bip-0039.mediawiki
index c5ab9bb..8241da7 100644
--- a/bip-0039.mediawiki
+++ b/bip-0039.mediawiki
@@ -137,6 +137,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
 
-- 
cgit v1.2.3


From b0521f076c0b40208e82208f5476c48071aab785 Mon Sep 17 00:00:00 2001
From: silencer-Tsai <596964113@qq.com>
Date: Wed, 4 Nov 2020 16:29:24 +0800
Subject: BIP32: Added new test vectors for hardened derivation with leading
 zeros

---
 bip-0032.mediawiki | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/bip-0032.mediawiki b/bip-0032.mediawiki
index f2f1e48..b8152e7 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
 
 <pre>
   BIP: 32
@@ -272,6 +273,21 @@ Seed (hex): 4b381541583be4423346c643850da4b320e46a87ae3d2a4e6da11eba819cd4acba45
 ** ext pub: xpub68NZiKmJWnxxS6aaHmn81bvJeTESw724CRDs6HbuccFQN9Ku14VQrADWgqbhhTHBaohPX4CjNLf9fq9MYo6oDaPPLPxSb7gwQN3ih19Zm4Y
 ** ext prv: xprv9uPDJpEQgRQfDcW7BkF7eTya6RPxXeJCqCJGHuCJ4GiRVLzkTXBAJMu2qaMWPrS7AANYqdq6vcBcBUdJCVVFceUvJFjaPdGZ2y9WACViL4L
 
+===Test vector 4===
+
+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/0<sub>H</sub>
+** ext pub: xpub69AUMk3qDBi3uW1sXgjCmVjJ2G6WQoYSnNHyzkmdCHEhSZ4tBok37xfFEqHd2AddP56Tqp4o56AePAgCjYdvpW2PU2jbUPFKsav5ut6Ch1m
+** ext prv: xprv9vB7xEWwNp9kh1wQRfCCQMnZUEG21LpbR9NPCNN1dwhiZkjjeGRnaALmPXCX7SgjFTiCTT6bXes17boXtjq3xLpcDjzEuGLQBM5ohqkao9G
+* Chain m/0<sub>H</sub>/1<sub>H</sub>
+** ext pub: xpub6BJA1jSqiukeaesWfxe6sNK9CCGaujFFSJLomWHprUL9DePQ4JDkM5d88n49sMGJxrhpjazuXYWdMf17C9T5XnxkopaeS7jGk1GyyVziaMt
+** ext prv: xprv9xJocDuwtYCMNAo3Zw76WENQeAS6WGXQ55RCy7tDJ8oALr4FWkuVoHJeHVAcAqiZLE7Je3vZJHxspZdFHfnBEjHqU5hG1Jaj32dVoS6XLT1
+
 
 ==Acknowledgements==
 
-- 
cgit v1.2.3


From fcd5c5d4ca6cac8027e4c5f4dee864f7743740f7 Mon Sep 17 00:00:00 2001
From: PandaBread2 <72713080+PandaBread2@users.noreply.github.com>
Date: Sat, 7 Nov 2020 22:52:14 +0000
Subject: Update bip-0079.mediawiki

---
 bip-0079.mediawiki | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/bip-0079.mediawiki b/bip-0079.mediawiki
index c8f2104..797c8f1 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 ==
-- 
cgit v1.2.3


From 1a7eaa9c7f3c38221e63b6b3b001054e4502fe79 Mon Sep 17 00:00:00 2001
From: Karl-Johan Alm <karljohan-alm@garage.co.jp>
Date: Fri, 30 Oct 2020 16:00:54 +0900
Subject: BIP-322: minor clarification

---
 bip-0322.mediawiki | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/bip-0322.mediawiki b/bip-0322.mediawiki
index e515b56..7aca5d1 100644
--- a/bip-0322.mediawiki
+++ b/bip-0322.mediawiki
@@ -25,7 +25,7 @@ More importantly, it does not prove ownership nor access to any funds, even if t
 
 == Specification ==
 
-This BIP follows the specification of BIP-325 challenges and solutions (see Signet comparison below).
+This BIP follows the specification of BIP-325 challenges and solutions.
 
 Let there be two virtual transactions to_spend and to_sign.
 
@@ -63,7 +63,7 @@ When a proof of funds is being created, additional inputs should be included for
 
 Proofs of funds are the base64-encoding of the to_spend and to_sign transactions concatenated in standard network serialisation, and proofs without additional inputs or time locks (simple proofs) are the base64-encoding of the to_sign script witness.
 
-A validator must verify it is valid and meets the description of virtual transactions as specified above. See "Validation" below.
+A validator must verify the proof is valid and meets the description of virtual transactions as specified above. See "Validation" below.
 
 === Validation ===
 
-- 
cgit v1.2.3


From c12af49c17b1bcf19cc73703bded3bd6abfa570d Mon Sep 17 00:00:00 2001
From: fametrano <ferdinando@ametrano.net>
Date: Sun, 15 Nov 2020 09:53:06 +0100
Subject: fixed typos

---
 bip-0174.mediawiki | 28 ++++++++++++++--------------
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/bip-0174.mediawiki b/bip-0174.mediawiki
index c424c5d..b2b996e 100644
--- a/bip-0174.mediawiki
+++ b/bip-0174.mediawiki
@@ -129,7 +129,7 @@ The currently defined global types are as follows:
 * Type: Version Number <tt>PSBT_GLOBAL_VERSION = 0xFB</tt>
 ** Key: None. The key must only contain the 1 byte type.
 *** <tt>{0xFB}</tt>
-** Value: The 32-bit little endian unsigned integer representing the version number of this PSBT. If ommitted, the version number is 0.
+** Value: The 32-bit little endian unsigned integer representing the version number of this PSBT. If omitted, the version number is 0.
 *** <tt>{32-bit uint}</tt>
 
 * Type: Proprietary Use Type <tt>PSBT_GLOBAL_PROPRIETARY = 0xFC</tt>
@@ -549,55 +549,55 @@ The following are invalid PSBTs:
 ** Bytes in Hex: <pre>70736274ff0100750200000001268171371edff285e937adeea4b37b78000c0566cbb3ad64641713ca42171bf60000000000feffffff02d3dff505000000001976a914d0c59903c5bac2868760e90fd521a4665aa7652088ac00e1f5050000000017a9143545e6e33b832c47050f24d3eeb93c9c03948bc787b32e1300000100fda5010100000000010289a3c71eab4d20e0371bbba4cc698fa295c9463afa2e397f8533ccb62f9567e50100000017160014be18d152a9b012039daf3da7de4f53349eecb985ffffffff86f8aa43a71dff1448893a530a7237ef6b4608bbb2dd2d0171e63aec6a4890b40100000017160014fe3e9ef1a745e974d902c4355943abcb34bd5353ffffffff0200c2eb0b000000001976a91485cff1097fd9e008bb34af709c62197b38978a4888ac72fef84e2c00000017a914339725ba21efd62ac753a9bcd067d6c7a6a39d05870247304402202712be22e0270f394f568311dc7ca9a68970b8025fdd3b240229f07f8a5f3a240220018b38d7dcd314e734c9276bd6fb40f673325bc4baa144c800d2f2f02db2765c012103d2e15674941bad4a996372cb87e1856d3652606d98562fe39c5e9e7e413f210502483045022100d12b852d85dcd961d2f5f4ab660654df6eedcc794c0c33ce5cc309ffb5fce58d022067338a8e0e1725c197fb1a88af59f51e44e4255b20167c8684031c05d1f2592a01210223b72beef0965d10be0778efecd61fcac6f79a4ea169393380734464f84f2ab30000000001003f0200000001ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff0000000000ffffffff010000000000000000036a010000000000000000</pre>
 ** Base64 String: <pre>cHNidP8BAHUCAAAAASaBcTce3/KF6Tet7qSze3gADAVmy7OtZGQXE8pCFxv2AAAAAAD+////AtPf9QUAAAAAGXapFNDFmQPFusKGh2DpD9UhpGZap2UgiKwA4fUFAAAAABepFDVF5uM7gyxHBQ8k0+65PJwDlIvHh7MuEwAAAQD9pQEBAAAAAAECiaPHHqtNIOA3G7ukzGmPopXJRjr6Ljl/hTPMti+VZ+UBAAAAFxYAFL4Y0VKpsBIDna89p95PUzSe7LmF/////4b4qkOnHf8USIk6UwpyN+9rRgi7st0tAXHmOuxqSJC0AQAAABcWABT+Pp7xp0XpdNkCxDVZQ6vLNL1TU/////8CAMLrCwAAAAAZdqkUhc/xCX/Z4Ai7NK9wnGIZeziXikiIrHL++E4sAAAAF6kUM5cluiHv1irHU6m80GfWx6ajnQWHAkcwRAIgJxK+IuAnDzlPVoMR3HyppolwuAJf3TskAinwf4pfOiQCIAGLONfc0xTnNMkna9b7QPZzMlvEuqFEyADS8vAtsnZcASED0uFWdJQbrUqZY3LLh+GFbTZSYG2YVi/jnF6efkE/IQUCSDBFAiEA0SuFLYXc2WHS9fSrZgZU327tzHlMDDPOXMMJ/7X85Y0CIGczio4OFyXBl/saiK9Z9R5E5CVbIBZ8hoQDHAXR8lkqASECI7cr7vCWXRC+B3jv7NYfysb3mk6haTkzgHNEZPhPKrMAAAAAAQA/AgAAAAH//////////////////////////////////////////wAAAAAA/////wEAAAAAAAAAAANqAQAAAAAAAAAA</pre>
 
-* Case: PSBT With invalid global transaction typed key
+* Case: PSBT with invalid global transaction typed key
 ** Bytes in Hex: <pre>70736274ff020001550200000001279a2323a5dfb51fc45f220fa58b0fc13e1e3342792a85d7e36cd6333b5cbc390000000000ffffffff01a05aea0b000000001976a914ffe9c0061097cc3b636f2cb0460fa4fc427d2b4588ac0000000000010120955eea0b0000000017a9146345200f68d189e1adc0df1c4d16ea8f14c0dbeb87220203b1341ccba7683b6af4f1238cd6e97e7167d569fac47f1e48d47541844355bd4646304302200424b58effaaa694e1559ea5c93bbfd4a89064224055cdf070b6771469442d07021f5c8eb0fea6516d60b8acb33ad64ede60e8785bfb3aa94b99bdf86151db9a9a010104220020771fd18ad459666dd49f3d564e3dbc42f4c84774e360ada16816a8ed488d5681010547522103b1341ccba7683b6af4f1238cd6e97e7167d569fac47f1e48d47541844355bd462103de55d1e1dac805e3f8a58c1fbf9b94c02f3dbaafe127fefca4995f26f82083bd52ae220603b1341ccba7683b6af4f1238cd6e97e7167d569fac47f1e48d47541844355bd4610b4a6ba67000000800000008004000080220603de55d1e1dac805e3f8a58c1fbf9b94c02f3dbaafe127fefca4995f26f82083bd10b4a6ba670000008000000080050000800000</pre>
 ** Base64 String: <pre>cHNidP8CAAFVAgAAAAEnmiMjpd+1H8RfIg+liw/BPh4zQnkqhdfjbNYzO1y8OQAAAAAA/////wGgWuoLAAAAABl2qRT/6cAGEJfMO2NvLLBGD6T8Qn0rRYisAAAAAAABASCVXuoLAAAAABepFGNFIA9o0YnhrcDfHE0W6o8UwNvrhyICA7E0HMunaDtq9PEjjNbpfnFn1Wn6xH8eSNR1QYRDVb1GRjBDAiAEJLWO/6qmlOFVnqXJO7/UqJBkIkBVzfBwtncUaUQtBwIfXI6w/qZRbWC4rLM61k7eYOh4W/s6qUuZvfhhUduamgEBBCIAIHcf0YrUWWZt1J89Vk49vEL0yEd042CtoWgWqO1IjVaBAQVHUiEDsTQcy6doO2r08SOM1ul+cWfVafrEfx5I1HVBhENVvUYhA95V0eHayAXj+KWMH7+blMAvPbqv4Sf+/KSZXyb4IIO9Uq4iBgOxNBzLp2g7avTxI4zW6X5xZ9Vp+sR/HkjUdUGEQ1W9RhC0prpnAAAAgAAAAIAEAACAIgYD3lXR4drIBeP4pYwfv5uUwC89uq/hJ/78pJlfJvggg70QtKa6ZwAAAIAAAACABQAAgAAA</pre>
 
-* Case: PSBT With invalid input witness utxo typed key
+* Case: PSBT with invalid input witness utxo typed key
 ** Bytes in Hex: <pre>70736274ff0100550200000001279a2323a5dfb51fc45f220fa58b0fc13e1e3342792a85d7e36cd6333b5cbc390000000000ffffffff01a05aea0b000000001976a914ffe9c0061097cc3b636f2cb0460fa4fc427d2b4588ac000000000002010020955eea0b0000000017a9146345200f68d189e1adc0df1c4d16ea8f14c0dbeb87220203b1341ccba7683b6af4f1238cd6e97e7167d569fac47f1e48d47541844355bd4646304302200424b58effaaa694e1559ea5c93bbfd4a89064224055cdf070b6771469442d07021f5c8eb0fea6516d60b8acb33ad64ede60e8785bfb3aa94b99bdf86151db9a9a010104220020771fd18ad459666dd49f3d564e3dbc42f4c84774e360ada16816a8ed488d5681010547522103b1341ccba7683b6af4f1238cd6e97e7167d569fac47f1e48d47541844355bd462103de55d1e1dac805e3f8a58c1fbf9b94c02f3dbaafe127fefca4995f26f82083bd52ae220603b1341ccba7683b6af4f1238cd6e97e7167d569fac47f1e48d47541844355bd4610b4a6ba67000000800000008004000080220603de55d1e1dac805e3f8a58c1fbf9b94c02f3dbaafe127fefca4995f26f82083bd10b4a6ba670000008000000080050000800000</pre>
 ** Base64 String: <pre>cHNidP8BAFUCAAAAASeaIyOl37UfxF8iD6WLD8E+HjNCeSqF1+Ns1jM7XLw5AAAAAAD/////AaBa6gsAAAAAGXapFP/pwAYQl8w7Y28ssEYPpPxCfStFiKwAAAAAAAIBACCVXuoLAAAAABepFGNFIA9o0YnhrcDfHE0W6o8UwNvrhyICA7E0HMunaDtq9PEjjNbpfnFn1Wn6xH8eSNR1QYRDVb1GRjBDAiAEJLWO/6qmlOFVnqXJO7/UqJBkIkBVzfBwtncUaUQtBwIfXI6w/qZRbWC4rLM61k7eYOh4W/s6qUuZvfhhUduamgEBBCIAIHcf0YrUWWZt1J89Vk49vEL0yEd042CtoWgWqO1IjVaBAQVHUiEDsTQcy6doO2r08SOM1ul+cWfVafrEfx5I1HVBhENVvUYhA95V0eHayAXj+KWMH7+blMAvPbqv4Sf+/KSZXyb4IIO9Uq4iBgOxNBzLp2g7avTxI4zW6X5xZ9Vp+sR/HkjUdUGEQ1W9RhC0prpnAAAAgAAAAIAEAACAIgYD3lXR4drIBeP4pYwfv5uUwC89uq/hJ/78pJlfJvggg70QtKa6ZwAAAIAAAACABQAAgAAA</pre>
 
-* Case: PSBT With invalid pubkey length for input partial signature typed key
+* Case: PSBT with invalid pubkey length for input partial signature typed key
 ** Bytes in Hex: <pre>70736274ff0100550200000001279a2323a5dfb51fc45f220fa58b0fc13e1e3342792a85d7e36cd6333b5cbc390000000000ffffffff01a05aea0b000000001976a914ffe9c0061097cc3b636f2cb0460fa4fc427d2b4588ac0000000000010120955eea0b0000000017a9146345200f68d189e1adc0df1c4d16ea8f14c0dbeb87210203b1341ccba7683b6af4f1238cd6e97e7167d569fac47f1e48d47541844355bd46304302200424b58effaaa694e1559ea5c93bbfd4a89064224055cdf070b6771469442d07021f5c8eb0fea6516d60b8acb33ad64ede60e8785bfb3aa94b99bdf86151db9a9a010104220020771fd18ad459666dd49f3d564e3dbc42f4c84774e360ada16816a8ed488d5681010547522103b1341ccba7683b6af4f1238cd6e97e7167d569fac47f1e48d47541844355bd462103de55d1e1dac805e3f8a58c1fbf9b94c02f3dbaafe127fefca4995f26f82083bd52ae220603b1341ccba7683b6af4f1238cd6e97e7167d569fac47f1e48d47541844355bd4610b4a6ba67000000800000008004000080220603de55d1e1dac805e3f8a58c1fbf9b94c02f3dbaafe127fefca4995f26f82083bd10b4a6ba670000008000000080050000800000</pre>
 ** Base64 String: <pre>cHNidP8BAFUCAAAAASeaIyOl37UfxF8iD6WLD8E+HjNCeSqF1+Ns1jM7XLw5AAAAAAD/////AaBa6gsAAAAAGXapFP/pwAYQl8w7Y28ssEYPpPxCfStFiKwAAAAAAAEBIJVe6gsAAAAAF6kUY0UgD2jRieGtwN8cTRbqjxTA2+uHIQIDsTQcy6doO2r08SOM1ul+cWfVafrEfx5I1HVBhENVvUYwQwIgBCS1jv+qppThVZ6lyTu/1KiQZCJAVc3wcLZ3FGlELQcCH1yOsP6mUW1guKyzOtZO3mDoeFv7OqlLmb34YVHbmpoBAQQiACB3H9GK1FlmbdSfPVZOPbxC9MhHdONgraFoFqjtSI1WgQEFR1IhA7E0HMunaDtq9PEjjNbpfnFn1Wn6xH8eSNR1QYRDVb1GIQPeVdHh2sgF4/iljB+/m5TALz26r+En/vykmV8m+CCDvVKuIgYDsTQcy6doO2r08SOM1ul+cWfVafrEfx5I1HVBhENVvUYQtKa6ZwAAAIAAAACABAAAgCIGA95V0eHayAXj+KWMH7+blMAvPbqv4Sf+/KSZXyb4IIO9ELSmumcAAACAAAAAgAUAAIAAAA==</pre>
 
-* Case: PSBT With invalid redeemscript typed key
+* Case: PSBT with invalid redeemscript typed key
 ** Bytes in Hex: <pre>70736274ff0100550200000001279a2323a5dfb51fc45f220fa58b0fc13e1e3342792a85d7e36cd6333b5cbc390000000000ffffffff01a05aea0b000000001976a914ffe9c0061097cc3b636f2cb0460fa4fc427d2b4588ac0000000000010120955eea0b0000000017a9146345200f68d189e1adc0df1c4d16ea8f14c0dbeb87220203b1341ccba7683b6af4f1238cd6e97e7167d569fac47f1e48d47541844355bd4646304302200424b58effaaa694e1559ea5c93bbfd4a89064224055cdf070b6771469442d07021f5c8eb0fea6516d60b8acb33ad64ede60e8785bfb3aa94b99bdf86151db9a9a01020400220020771fd18ad459666dd49f3d564e3dbc42f4c84774e360ada16816a8ed488d5681010547522103b1341ccba7683b6af4f1238cd6e97e7167d569fac47f1e48d47541844355bd462103de55d1e1dac805e3f8a58c1fbf9b94c02f3dbaafe127fefca4995f26f82083bd52ae220603b1341ccba7683b6af4f1238cd6e97e7167d569fac47f1e48d47541844355bd4610b4a6ba67000000800000008004000080220603de55d1e1dac805e3f8a58c1fbf9b94c02f3dbaafe127fefca4995f26f82083bd10b4a6ba670000008000000080050000800000</pre>
 ** Base64 String: <pre>cHNidP8BAFUCAAAAASeaIyOl37UfxF8iD6WLD8E+HjNCeSqF1+Ns1jM7XLw5AAAAAAD/////AaBa6gsAAAAAGXapFP/pwAYQl8w7Y28ssEYPpPxCfStFiKwAAAAAAAEBIJVe6gsAAAAAF6kUY0UgD2jRieGtwN8cTRbqjxTA2+uHIgIDsTQcy6doO2r08SOM1ul+cWfVafrEfx5I1HVBhENVvUZGMEMCIAQktY7/qqaU4VWepck7v9SokGQiQFXN8HC2dxRpRC0HAh9cjrD+plFtYLisszrWTt5g6Hhb+zqpS5m9+GFR25qaAQIEACIAIHcf0YrUWWZt1J89Vk49vEL0yEd042CtoWgWqO1IjVaBAQVHUiEDsTQcy6doO2r08SOM1ul+cWfVafrEfx5I1HVBhENVvUYhA95V0eHayAXj+KWMH7+blMAvPbqv4Sf+/KSZXyb4IIO9Uq4iBgOxNBzLp2g7avTxI4zW6X5xZ9Vp+sR/HkjUdUGEQ1W9RhC0prpnAAAAgAAAAIAEAACAIgYD3lXR4drIBeP4pYwfv5uUwC89uq/hJ/78pJlfJvggg70QtKa6ZwAAAIAAAACABQAAgAAA</pre>
 
-* Case: PSBT With invalid witnessscript typed key
+* Case: PSBT with invalid witnessscript typed key
 ** Bytes in Hex: <pre>70736274ff0100550200000001279a2323a5dfb51fc45f220fa58b0fc13e1e3342792a85d7e36cd6333b5cbc390000000000ffffffff01a05aea0b000000001976a914ffe9c0061097cc3b636f2cb0460fa4fc427d2b4588ac0000000000010120955eea0b0000000017a9146345200f68d189e1adc0df1c4d16ea8f14c0dbeb87220203b1341ccba7683b6af4f1238cd6e97e7167d569fac47f1e48d47541844355bd4646304302200424b58effaaa694e1559ea5c93bbfd4a89064224055cdf070b6771469442d07021f5c8eb0fea6516d60b8acb33ad64ede60e8785bfb3aa94b99bdf86151db9a9a010104220020771fd18ad459666dd49f3d564e3dbc42f4c84774e360ada16816a8ed488d568102050047522103b1341ccba7683b6af4f1238cd6e97e7167d569fac47f1e48d47541844355bd462103de55d1e1dac805e3f8a58c1fbf9b94c02f3dbaafe127fefca4995f26f82083bd52ae220603b1341ccba7683b6af4f1238cd6e97e7167d569fac47f1e48d47541844355bd4610b4a6ba67000000800000008004000080220603de55d1e1dac805e3f8a58c1fbf9b94c02f3dbaafe127fefca4995f26f82083bd10b4a6ba670000008000000080050000800000</pre>
 ** Base64 String: <pre>cHNidP8BAFUCAAAAASeaIyOl37UfxF8iD6WLD8E+HjNCeSqF1+Ns1jM7XLw5AAAAAAD/////AaBa6gsAAAAAGXapFP/pwAYQl8w7Y28ssEYPpPxCfStFiKwAAAAAAAEBIJVe6gsAAAAAF6kUY0UgD2jRieGtwN8cTRbqjxTA2+uHIgIDsTQcy6doO2r08SOM1ul+cWfVafrEfx5I1HVBhENVvUZGMEMCIAQktY7/qqaU4VWepck7v9SokGQiQFXN8HC2dxRpRC0HAh9cjrD+plFtYLisszrWTt5g6Hhb+zqpS5m9+GFR25qaAQEEIgAgdx/RitRZZm3Unz1WTj28QvTIR3TjYK2haBao7UiNVoECBQBHUiEDsTQcy6doO2r08SOM1ul+cWfVafrEfx5I1HVBhENVvUYhA95V0eHayAXj+KWMH7+blMAvPbqv4Sf+/KSZXyb4IIO9Uq4iBgOxNBzLp2g7avTxI4zW6X5xZ9Vp+sR/HkjUdUGEQ1W9RhC0prpnAAAAgAAAAIAEAACAIgYD3lXR4drIBeP4pYwfv5uUwC89uq/hJ/78pJlfJvggg70QtKa6ZwAAAIAAAACABQAAgAAA</pre>
 
-* Case: PSBT With invalid bip32 typed key
+* Case: PSBT with invalid bip32 typed key
 ** Bytes in Hex: <pre>70736274ff0100550200000001279a2323a5dfb51fc45f220fa58b0fc13e1e3342792a85d7e36cd6333b5cbc390000000000ffffffff01a05aea0b000000001976a914ffe9c0061097cc3b636f2cb0460fa4fc427d2b4588ac0000000000010120955eea0b0000000017a9146345200f68d189e1adc0df1c4d16ea8f14c0dbeb87220203b1341ccba7683b6af4f1238cd6e97e7167d569fac47f1e48d47541844355bd4646304302200424b58effaaa694e1559ea5c93bbfd4a89064224055cdf070b6771469442d07021f5c8eb0fea6516d60b8acb33ad64ede60e8785bfb3aa94b99bdf86151db9a9a010104220020771fd18ad459666dd49f3d564e3dbc42f4c84774e360ada16816a8ed488d5681010547522103b1341ccba7683b6af4f1238cd6e97e7167d569fac47f1e48d47541844355bd462103de55d1e1dac805e3f8a58c1fbf9b94c02f3dbaafe127fefca4995f26f82083bd52ae210603b1341ccba7683b6af4f1238cd6e97e7167d569fac47f1e48d47541844355bd10b4a6ba67000000800000008004000080220603de55d1e1dac805e3f8a58c1fbf9b94c02f3dbaafe127fefca4995f26f82083bd10b4a6ba670000008000000080050000800000</pre>
 ** Base64 String: <pre>cHNidP8BAFUCAAAAASeaIyOl37UfxF8iD6WLD8E+HjNCeSqF1+Ns1jM7XLw5AAAAAAD/////AaBa6gsAAAAAGXapFP/pwAYQl8w7Y28ssEYPpPxCfStFiKwAAAAAAAEBIJVe6gsAAAAAF6kUY0UgD2jRieGtwN8cTRbqjxTA2+uHIgIDsTQcy6doO2r08SOM1ul+cWfVafrEfx5I1HVBhENVvUZGMEMCIAQktY7/qqaU4VWepck7v9SokGQiQFXN8HC2dxRpRC0HAh9cjrD+plFtYLisszrWTt5g6Hhb+zqpS5m9+GFR25qaAQEEIgAgdx/RitRZZm3Unz1WTj28QvTIR3TjYK2haBao7UiNVoEBBUdSIQOxNBzLp2g7avTxI4zW6X5xZ9Vp+sR/HkjUdUGEQ1W9RiED3lXR4drIBeP4pYwfv5uUwC89uq/hJ/78pJlfJvggg71SriEGA7E0HMunaDtq9PEjjNbpfnFn1Wn6xH8eSNR1QYRDVb0QtKa6ZwAAAIAAAACABAAAgCIGA95V0eHayAXj+KWMH7+blMAvPbqv4Sf+/KSZXyb4IIO9ELSmumcAAACAAAAAgAUAAIAAAA==</pre>
 
-* Case: PSBT With invalid non-witness utxo typed key
+* Case: PSBT with invalid non-witness utxo typed key
 ** Bytes in Hex: <pre>70736274ff01009a020000000258e87a21b56daf0c23be8e7070456c336f7cbaa5c8757924f545887bb2abdd750000000000ffffffff838d0427d0ec650a68aa46bb0b098aea4422c071b2ca78352a077959d07cea1d0100000000ffffffff0270aaf00800000000160014d85c2b71d0060b09c9886aeb815e50991dda124d00e1f5050000000016001400aea9a2e5f0f876a588df5546e8742d1d87008f0000000000020000bb0200000001aad73931018bd25f84ae400b68848be09db706eac2ac18298babee71ab656f8b0000000048473044022058f6fc7c6a33e1b31548d481c826c015bd30135aad42cd67790dab66d2ad243b02204a1ced2604c6735b6393e5b41691dd78b00f0c5942fb9f751856faa938157dba01feffffff0280f0fa020000000017a9140fb9463421696b82c833af241c78c17ddbde493487d0f20a270100000017a91429ca74f8a08f81999428185c97b5d852e4063f6187650000000107da00473044022074018ad4180097b873323c0015720b3684cc8123891048e7dbcd9b55ad679c99022073d369b740e3eb53dcefa33823c8070514ca55a7dd9544f157c167913261118c01483045022100f61038b308dc1da865a34852746f015772934208c6d24454393cd99bdf2217770220056e675a675a6d0a02b85b14e5e29074d8a25a9b5760bea2816f661910a006ea01475221029583bf39ae0a609747ad199addd634fa6108559d6c5cd39b4c2183f1ab96e07f2102dab61ff49a14db6a7d02b0cd1fbb78fc4b18312b5b4e54dae4dba2fbfef536d752ae0001012000c2eb0b0000000017a914b7f5faf40e3d40a5a459b1db3535f2b72fa921e8870107232200208c2353173743b595dfb4a07b72ba8e42e3797da74e87fe7d9d7497e3b20289030108da0400473044022062eb7a556107a7c73f45ac4ab5a1dddf6f7075fb1275969a7f383efff784bcb202200c05dbb7470dbf2f08557dd356c7325c1ed30913e996cd3840945db12228da5f01473044022065f45ba5998b59a27ffe1a7bed016af1f1f90d54b3aa8f7450aa5f56a25103bd02207f724703ad1edb96680b284b56d4ffcb88f7fb759eabbe08aa30f29b851383d20147522103089dc10c7ac6db54f91329af617333db388cead0c231f723379d1b99030b02dc21023add904f3d6dcf59ddb906b0dee23529b7ffb9ed50e5e86151926860221f0e7352ae00220203a9a4c37f5996d3aa25dbac6b570af0650394492942460b354753ed9eeca5877110d90c6a4f000000800000008004000080002202027f6399757d2eff55a136ad02c684b1838b6556e5f1b6b34282a94b6b5005109610d90c6a4f00000080000000800500008000</pre>
 ** Base64 String: <pre>cHNidP8BAJoCAAAAAljoeiG1ba8MI76OcHBFbDNvfLqlyHV5JPVFiHuyq911AAAAAAD/////g40EJ9DsZQpoqka7CwmK6kQiwHGyyng1Kgd5WdB86h0BAAAAAP////8CcKrwCAAAAAAWABTYXCtx0AYLCcmIauuBXlCZHdoSTQDh9QUAAAAAFgAUAK6pouXw+HaliN9VRuh0LR2HAI8AAAAAAAIAALsCAAAAAarXOTEBi9JfhK5AC2iEi+CdtwbqwqwYKYur7nGrZW+LAAAAAEhHMEQCIFj2/HxqM+GzFUjUgcgmwBW9MBNarULNZ3kNq2bSrSQ7AiBKHO0mBMZzW2OT5bQWkd14sA8MWUL7n3UYVvqpOBV9ugH+////AoDw+gIAAAAAF6kUD7lGNCFpa4LIM68kHHjBfdveSTSH0PIKJwEAAAAXqRQpynT4oI+BmZQoGFyXtdhS5AY/YYdlAAAAAQfaAEcwRAIgdAGK1BgAl7hzMjwAFXILNoTMgSOJEEjn282bVa1nnJkCIHPTabdA4+tT3O+jOCPIBwUUylWn3ZVE8VfBZ5EyYRGMAUgwRQIhAPYQOLMI3B2oZaNIUnRvAVdyk0IIxtJEVDk82ZvfIhd3AiAFbmdaZ1ptCgK4WxTl4pB02KJam1dgvqKBb2YZEKAG6gFHUiEClYO/Oa4KYJdHrRma3dY0+mEIVZ1sXNObTCGD8auW4H8hAtq2H/SaFNtqfQKwzR+7ePxLGDErW05U2uTbovv+9TbXUq4AAQEgAMLrCwAAAAAXqRS39fr0Dj1ApaRZsds1NfK3L6kh6IcBByMiACCMI1MXN0O1ld+0oHtyuo5C43l9p06H/n2ddJfjsgKJAwEI2gQARzBEAiBi63pVYQenxz9FrEq1od3fb3B1+xJ1lpp/OD7/94S8sgIgDAXbt0cNvy8IVX3TVscyXB7TCRPpls04QJRdsSIo2l8BRzBEAiBl9FulmYtZon/+GnvtAWrx8fkNVLOqj3RQql9WolEDvQIgf3JHA60e25ZoCyhLVtT/y4j3+3Weq74IqjDym4UTg9IBR1IhAwidwQx6xttU+RMpr2FzM9s4jOrQwjH3IzedG5kDCwLcIQI63ZBPPW3PWd25BrDe4jUpt/+57VDl6GFRkmhgIh8Oc1KuACICA6mkw39ZltOqJdusa1cK8GUDlEkpQkYLNUdT7Z7spYdxENkMak8AAACAAAAAgAQAAIAAIgICf2OZdX0u/1WhNq0CxoSxg4tlVuXxtrNCgqlLa1AFEJYQ2QxqTwAAAIAAAACABQAAgAA=</pre>
 
-* Case: PSBT With invalid final scriptsig typed key
+* Case: PSBT with invalid final scriptsig typed key
 ** Bytes in Hex: <pre>70736274ff01009a020000000258e87a21b56daf0c23be8e7070456c336f7cbaa5c8757924f545887bb2abdd750000000000ffffffff838d0427d0ec650a68aa46bb0b098aea4422c071b2ca78352a077959d07cea1d0100000000ffffffff0270aaf00800000000160014d85c2b71d0060b09c9886aeb815e50991dda124d00e1f5050000000016001400aea9a2e5f0f876a588df5546e8742d1d87008f00000000000100bb0200000001aad73931018bd25f84ae400b68848be09db706eac2ac18298babee71ab656f8b0000000048473044022058f6fc7c6a33e1b31548d481c826c015bd30135aad42cd67790dab66d2ad243b02204a1ced2604c6735b6393e5b41691dd78b00f0c5942fb9f751856faa938157dba01feffffff0280f0fa020000000017a9140fb9463421696b82c833af241c78c17ddbde493487d0f20a270100000017a91429ca74f8a08f81999428185c97b5d852e4063f618765000000020700da00473044022074018ad4180097b873323c0015720b3684cc8123891048e7dbcd9b55ad679c99022073d369b740e3eb53dcefa33823c8070514ca55a7dd9544f157c167913261118c01483045022100f61038b308dc1da865a34852746f015772934208c6d24454393cd99bdf2217770220056e675a675a6d0a02b85b14e5e29074d8a25a9b5760bea2816f661910a006ea01475221029583bf39ae0a609747ad199addd634fa6108559d6c5cd39b4c2183f1ab96e07f2102dab61ff49a14db6a7d02b0cd1fbb78fc4b18312b5b4e54dae4dba2fbfef536d752ae0001012000c2eb0b0000000017a914b7f5faf40e3d40a5a459b1db3535f2b72fa921e8870107232200208c2353173743b595dfb4a07b72ba8e42e3797da74e87fe7d9d7497e3b20289030108da0400473044022062eb7a556107a7c73f45ac4ab5a1dddf6f7075fb1275969a7f383efff784bcb202200c05dbb7470dbf2f08557dd356c7325c1ed30913e996cd3840945db12228da5f01473044022065f45ba5998b59a27ffe1a7bed016af1f1f90d54b3aa8f7450aa5f56a25103bd02207f724703ad1edb96680b284b56d4ffcb88f7fb759eabbe08aa30f29b851383d20147522103089dc10c7ac6db54f91329af617333db388cead0c231f723379d1b99030b02dc21023add904f3d6dcf59ddb906b0dee23529b7ffb9ed50e5e86151926860221f0e7352ae00220203a9a4c37f5996d3aa25dbac6b570af0650394492942460b354753ed9eeca5877110d90c6a4f000000800000008004000080002202027f6399757d2eff55a136ad02c684b1838b6556e5f1b6b34282a94b6b5005109610d90c6a4f00000080000000800500008000</pre>
 ** Base64 String: <pre>cHNidP8BAJoCAAAAAljoeiG1ba8MI76OcHBFbDNvfLqlyHV5JPVFiHuyq911AAAAAAD/////g40EJ9DsZQpoqka7CwmK6kQiwHGyyng1Kgd5WdB86h0BAAAAAP////8CcKrwCAAAAAAWABTYXCtx0AYLCcmIauuBXlCZHdoSTQDh9QUAAAAAFgAUAK6pouXw+HaliN9VRuh0LR2HAI8AAAAAAAEAuwIAAAABqtc5MQGL0l+ErkALaISL4J23BurCrBgpi6vucatlb4sAAAAASEcwRAIgWPb8fGoz4bMVSNSByCbAFb0wE1qtQs1neQ2rZtKtJDsCIEoc7SYExnNbY5PltBaR3XiwDwxZQvufdRhW+qk4FX26Af7///8CgPD6AgAAAAAXqRQPuUY0IWlrgsgzryQceMF9295JNIfQ8gonAQAAABepFCnKdPigj4GZlCgYXJe12FLkBj9hh2UAAAACBwDaAEcwRAIgdAGK1BgAl7hzMjwAFXILNoTMgSOJEEjn282bVa1nnJkCIHPTabdA4+tT3O+jOCPIBwUUylWn3ZVE8VfBZ5EyYRGMAUgwRQIhAPYQOLMI3B2oZaNIUnRvAVdyk0IIxtJEVDk82ZvfIhd3AiAFbmdaZ1ptCgK4WxTl4pB02KJam1dgvqKBb2YZEKAG6gFHUiEClYO/Oa4KYJdHrRma3dY0+mEIVZ1sXNObTCGD8auW4H8hAtq2H/SaFNtqfQKwzR+7ePxLGDErW05U2uTbovv+9TbXUq4AAQEgAMLrCwAAAAAXqRS39fr0Dj1ApaRZsds1NfK3L6kh6IcBByMiACCMI1MXN0O1ld+0oHtyuo5C43l9p06H/n2ddJfjsgKJAwEI2gQARzBEAiBi63pVYQenxz9FrEq1od3fb3B1+xJ1lpp/OD7/94S8sgIgDAXbt0cNvy8IVX3TVscyXB7TCRPpls04QJRdsSIo2l8BRzBEAiBl9FulmYtZon/+GnvtAWrx8fkNVLOqj3RQql9WolEDvQIgf3JHA60e25ZoCyhLVtT/y4j3+3Weq74IqjDym4UTg9IBR1IhAwidwQx6xttU+RMpr2FzM9s4jOrQwjH3IzedG5kDCwLcIQI63ZBPPW3PWd25BrDe4jUpt/+57VDl6GFRkmhgIh8Oc1KuACICA6mkw39ZltOqJdusa1cK8GUDlEkpQkYLNUdT7Z7spYdxENkMak8AAACAAAAAgAQAAIAAIgICf2OZdX0u/1WhNq0CxoSxg4tlVuXxtrNCgqlLa1AFEJYQ2QxqTwAAAIAAAACABQAAgAA=</pre>
 
-* Case: PSBT With invalid final script witness typed key
+* Case: PSBT with invalid final script witness typed key
 ** Bytes in Hex: <pre>70736274ff01009a020000000258e87a21b56daf0c23be8e7070456c336f7cbaa5c8757924f545887bb2abdd750000000000ffffffff838d0427d0ec650a68aa46bb0b098aea4422c071b2ca78352a077959d07cea1d0100000000ffffffff0270aaf00800000000160014d85c2b71d0060b09c9886aeb815e50991dda124d00e1f5050000000016001400aea9a2e5f0f876a588df5546e8742d1d87008f00000000000100bb0200000001aad73931018bd25f84ae400b68848be09db706eac2ac18298babee71ab656f8b0000000048473044022058f6fc7c6a33e1b31548d481c826c015bd30135aad42cd67790dab66d2ad243b02204a1ced2604c6735b6393e5b41691dd78b00f0c5942fb9f751856faa938157dba01feffffff0280f0fa020000000017a9140fb9463421696b82c833af241c78c17ddbde493487d0f20a270100000017a91429ca74f8a08f81999428185c97b5d852e4063f6187650000000107da00473044022074018ad4180097b873323c0015720b3684cc8123891048e7dbcd9b55ad679c99022073d369b740e3eb53dcefa33823c8070514ca55a7dd9544f157c167913261118c01483045022100f61038b308dc1da865a34852746f015772934208c6d24454393cd99bdf2217770220056e675a675a6d0a02b85b14e5e29074d8a25a9b5760bea2816f661910a006ea01475221029583bf39ae0a609747ad199addd634fa6108559d6c5cd39b4c2183f1ab96e07f2102dab61ff49a14db6a7d02b0cd1fbb78fc4b18312b5b4e54dae4dba2fbfef536d752ae0001012000c2eb0b0000000017a914b7f5faf40e3d40a5a459b1db3535f2b72fa921e8870107232200208c2353173743b595dfb4a07b72ba8e42e3797da74e87fe7d9d7497e3b2028903020800da0400473044022062eb7a556107a7c73f45ac4ab5a1dddf6f7075fb1275969a7f383efff784bcb202200c05dbb7470dbf2f08557dd356c7325c1ed30913e996cd3840945db12228da5f01473044022065f45ba5998b59a27ffe1a7bed016af1f1f90d54b3aa8f7450aa5f56a25103bd02207f724703ad1edb96680b284b56d4ffcb88f7fb759eabbe08aa30f29b851383d20147522103089dc10c7ac6db54f91329af617333db388cead0c231f723379d1b99030b02dc21023add904f3d6dcf59ddb906b0dee23529b7ffb9ed50e5e86151926860221f0e7352ae00220203a9a4c37f5996d3aa25dbac6b570af0650394492942460b354753ed9eeca5877110d90c6a4f000000800000008004000080002202027f6399757d2eff55a136ad02c684b1838b6556e5f1b6b34282a94b6b5005109610d90c6a4f00000080000000800500008000</pre>
 ** Base64 String: <pre>cHNidP8BAJoCAAAAAljoeiG1ba8MI76OcHBFbDNvfLqlyHV5JPVFiHuyq911AAAAAAD/////g40EJ9DsZQpoqka7CwmK6kQiwHGyyng1Kgd5WdB86h0BAAAAAP////8CcKrwCAAAAAAWABTYXCtx0AYLCcmIauuBXlCZHdoSTQDh9QUAAAAAFgAUAK6pouXw+HaliN9VRuh0LR2HAI8AAAAAAAEAuwIAAAABqtc5MQGL0l+ErkALaISL4J23BurCrBgpi6vucatlb4sAAAAASEcwRAIgWPb8fGoz4bMVSNSByCbAFb0wE1qtQs1neQ2rZtKtJDsCIEoc7SYExnNbY5PltBaR3XiwDwxZQvufdRhW+qk4FX26Af7///8CgPD6AgAAAAAXqRQPuUY0IWlrgsgzryQceMF9295JNIfQ8gonAQAAABepFCnKdPigj4GZlCgYXJe12FLkBj9hh2UAAAABB9oARzBEAiB0AYrUGACXuHMyPAAVcgs2hMyBI4kQSOfbzZtVrWecmQIgc9Npt0Dj61Pc76M4I8gHBRTKVafdlUTxV8FnkTJhEYwBSDBFAiEA9hA4swjcHahlo0hSdG8BV3KTQgjG0kRUOTzZm98iF3cCIAVuZ1pnWm0KArhbFOXikHTYolqbV2C+ooFvZhkQoAbqAUdSIQKVg785rgpgl0etGZrd1jT6YQhVnWxc05tMIYPxq5bgfyEC2rYf9JoU22p9ArDNH7t4/EsYMStbTlTa5Nui+/71NtdSrgABASAAwusLAAAAABepFLf1+vQOPUClpFmx2zU18rcvqSHohwEHIyIAIIwjUxc3Q7WV37Sge3K6jkLjeX2nTof+fZ10l+OyAokDAggA2gQARzBEAiBi63pVYQenxz9FrEq1od3fb3B1+xJ1lpp/OD7/94S8sgIgDAXbt0cNvy8IVX3TVscyXB7TCRPpls04QJRdsSIo2l8BRzBEAiBl9FulmYtZon/+GnvtAWrx8fkNVLOqj3RQql9WolEDvQIgf3JHA60e25ZoCyhLVtT/y4j3+3Weq74IqjDym4UTg9IBR1IhAwidwQx6xttU+RMpr2FzM9s4jOrQwjH3IzedG5kDCwLcIQI63ZBPPW3PWd25BrDe4jUpt/+57VDl6GFRkmhgIh8Oc1KuACICA6mkw39ZltOqJdusa1cK8GUDlEkpQkYLNUdT7Z7spYdxENkMak8AAACAAAAAgAQAAIAAIgICf2OZdX0u/1WhNq0CxoSxg4tlVuXxtrNCgqlLa1AFEJYQ2QxqTwAAAIAAAACABQAAgAA=</pre>
 
-* Case: PSBT With invalid pubkey in output BIP 32 derivation paths typed key
+* Case: PSBT with invalid pubkey in output BIP 32 derivation paths typed key
 ** Bytes in Hex: <pre>70736274ff01009a020000000258e87a21b56daf0c23be8e7070456c336f7cbaa5c8757924f545887bb2abdd750000000000ffffffff838d0427d0ec650a68aa46bb0b098aea4422c071b2ca78352a077959d07cea1d0100000000ffffffff0270aaf00800000000160014d85c2b71d0060b09c9886aeb815e50991dda124d00e1f5050000000016001400aea9a2e5f0f876a588df5546e8742d1d87008f00000000000100bb0200000001aad73931018bd25f84ae400b68848be09db706eac2ac18298babee71ab656f8b0000000048473044022058f6fc7c6a33e1b31548d481c826c015bd30135aad42cd67790dab66d2ad243b02204a1ced2604c6735b6393e5b41691dd78b00f0c5942fb9f751856faa938157dba01feffffff0280f0fa020000000017a9140fb9463421696b82c833af241c78c17ddbde493487d0f20a270100000017a91429ca74f8a08f81999428185c97b5d852e4063f6187650000000107da00473044022074018ad4180097b873323c0015720b3684cc8123891048e7dbcd9b55ad679c99022073d369b740e3eb53dcefa33823c8070514ca55a7dd9544f157c167913261118c01483045022100f61038b308dc1da865a34852746f015772934208c6d24454393cd99bdf2217770220056e675a675a6d0a02b85b14e5e29074d8a25a9b5760bea2816f661910a006ea01475221029583bf39ae0a609747ad199addd634fa6108559d6c5cd39b4c2183f1ab96e07f2102dab61ff49a14db6a7d02b0cd1fbb78fc4b18312b5b4e54dae4dba2fbfef536d752ae0001012000c2eb0b0000000017a914b7f5faf40e3d40a5a459b1db3535f2b72fa921e8870107232200208c2353173743b595dfb4a07b72ba8e42e3797da74e87fe7d9d7497e3b20289030108da0400473044022062eb7a556107a7c73f45ac4ab5a1dddf6f7075fb1275969a7f383efff784bcb202200c05dbb7470dbf2f08557dd356c7325c1ed30913e996cd3840945db12228da5f01473044022065f45ba5998b59a27ffe1a7bed016af1f1f90d54b3aa8f7450aa5f56a25103bd02207f724703ad1edb96680b284b56d4ffcb88f7fb759eabbe08aa30f29b851383d20147522103089dc10c7ac6db54f91329af617333db388cead0c231f723379d1b99030b02dc21023add904f3d6dcf59ddb906b0dee23529b7ffb9ed50e5e86151926860221f0e7352ae00210203a9a4c37f5996d3aa25dbac6b570af0650394492942460b354753ed9eeca58710d90c6a4f000000800000008004000080002202027f6399757d2eff55a136ad02c684b1838b6556e5f1b6b34282a94b6b5005109610d90c6a4f00000080000000800500008000</pre>
 ** Base64 String: <pre>cHNidP8BAJoCAAAAAljoeiG1ba8MI76OcHBFbDNvfLqlyHV5JPVFiHuyq911AAAAAAD/////g40EJ9DsZQpoqka7CwmK6kQiwHGyyng1Kgd5WdB86h0BAAAAAP////8CcKrwCAAAAAAWABTYXCtx0AYLCcmIauuBXlCZHdoSTQDh9QUAAAAAFgAUAK6pouXw+HaliN9VRuh0LR2HAI8AAAAAAAEAuwIAAAABqtc5MQGL0l+ErkALaISL4J23BurCrBgpi6vucatlb4sAAAAASEcwRAIgWPb8fGoz4bMVSNSByCbAFb0wE1qtQs1neQ2rZtKtJDsCIEoc7SYExnNbY5PltBaR3XiwDwxZQvufdRhW+qk4FX26Af7///8CgPD6AgAAAAAXqRQPuUY0IWlrgsgzryQceMF9295JNIfQ8gonAQAAABepFCnKdPigj4GZlCgYXJe12FLkBj9hh2UAAAABB9oARzBEAiB0AYrUGACXuHMyPAAVcgs2hMyBI4kQSOfbzZtVrWecmQIgc9Npt0Dj61Pc76M4I8gHBRTKVafdlUTxV8FnkTJhEYwBSDBFAiEA9hA4swjcHahlo0hSdG8BV3KTQgjG0kRUOTzZm98iF3cCIAVuZ1pnWm0KArhbFOXikHTYolqbV2C+ooFvZhkQoAbqAUdSIQKVg785rgpgl0etGZrd1jT6YQhVnWxc05tMIYPxq5bgfyEC2rYf9JoU22p9ArDNH7t4/EsYMStbTlTa5Nui+/71NtdSrgABASAAwusLAAAAABepFLf1+vQOPUClpFmx2zU18rcvqSHohwEHIyIAIIwjUxc3Q7WV37Sge3K6jkLjeX2nTof+fZ10l+OyAokDAQjaBABHMEQCIGLrelVhB6fHP0WsSrWh3d9vcHX7EnWWmn84Pv/3hLyyAiAMBdu3Rw2/LwhVfdNWxzJcHtMJE+mWzThAlF2xIijaXwFHMEQCIGX0W6WZi1mif/4ae+0BavHx+Q1Us6qPdFCqX1aiUQO9AiB/ckcDrR7blmgLKEtW1P/LiPf7dZ6rvgiqMPKbhROD0gFHUiEDCJ3BDHrG21T5EymvYXMz2ziM6tDCMfcjN50bmQMLAtwhAjrdkE89bc9Z3bkGsN7iNSm3/7ntUOXoYVGSaGAiHw5zUq4AIQIDqaTDf1mW06ol26xrVwrwZQOUSSlCRgs1R1PtnuylhxDZDGpPAAAAgAAAAIAEAACAACICAn9jmXV9Lv9VoTatAsaEsYOLZVbl8bazQoKpS2tQBRCWENkMak8AAACAAAAAgAUAAIAA</pre>
 
-* Case: PSBT With invalid input sighash type typed key
+* Case: PSBT with invalid input sighash type typed key
 ** Bytes in Hex: <pre>70736274ff0100730200000001301ae986e516a1ec8ac5b4bc6573d32f83b465e23ad76167d68b38e730b4dbdb0000000000ffffffff02747b01000000000017a91403aa17ae882b5d0d54b25d63104e4ffece7b9ea2876043993b0000000017a914b921b1ba6f722e4bfa83b6557a3139986a42ec8387000000000001011f00ca9a3b00000000160014d2d94b64ae08587eefc8eeb187c601e939f9037c0203000100000000010016001462e9e982fff34dd8239610316b090cd2a3b747cb000100220020876bad832f1d168015ed41232a9ea65a1815d9ef13c0ef8759f64b5b2b278a65010125512103b7ce23a01c5b4bf00a642537cdfabb315b668332867478ef51309d2bd57f8a8751ae00</pre>
 ** Base64 String: <pre>cHNidP8BAHMCAAAAATAa6YblFqHsisW0vGVz0y+DtGXiOtdhZ9aLOOcwtNvbAAAAAAD/////AnR7AQAAAAAAF6kUA6oXrogrXQ1Usl1jEE5P/s57nqKHYEOZOwAAAAAXqRS5IbG6b3IuS/qDtlV6MTmYakLsg4cAAAAAAAEBHwDKmjsAAAAAFgAU0tlLZK4IWH7vyO6xh8YB6Tn5A3wCAwABAAAAAAEAFgAUYunpgv/zTdgjlhAxawkM0qO3R8sAAQAiACCHa62DLx0WgBXtQSMqnqZaGBXZ7xPA74dZ9ktbKyeKZQEBJVEhA7fOI6AcW0vwCmQlN836uzFbZoMyhnR471EwnSvVf4qHUa4A</pre>
 
-* Case: PSBT With invalid output redeemScript typed key
+* Case: PSBT with invalid output redeemScript typed key
 ** Bytes in Hex: <pre>70736274ff0100730200000001301ae986e516a1ec8ac5b4bc6573d32f83b465e23ad76167d68b38e730b4dbdb0000000000ffffffff02747b01000000000017a91403aa17ae882b5d0d54b25d63104e4ffece7b9ea2876043993b0000000017a914b921b1ba6f722e4bfa83b6557a3139986a42ec8387000000000001011f00ca9a3b00000000160014d2d94b64ae08587eefc8eeb187c601e939f9037c0002000016001462e9e982fff34dd8239610316b090cd2a3b747cb000100220020876bad832f1d168015ed41232a9ea65a1815d9ef13c0ef8759f64b5b2b278a65010125512103b7ce23a01c5b4bf00a642537cdfabb315b668332867478ef51309d2bd57f8a8751ae00</pre>
 ** Base64 String: <pre>cHNidP8BAHMCAAAAATAa6YblFqHsisW0vGVz0y+DtGXiOtdhZ9aLOOcwtNvbAAAAAAD/////AnR7AQAAAAAAF6kUA6oXrogrXQ1Usl1jEE5P/s57nqKHYEOZOwAAAAAXqRS5IbG6b3IuS/qDtlV6MTmYakLsg4cAAAAAAAEBHwDKmjsAAAAAFgAU0tlLZK4IWH7vyO6xh8YB6Tn5A3wAAgAAFgAUYunpgv/zTdgjlhAxawkM0qO3R8sAAQAiACCHa62DLx0WgBXtQSMqnqZaGBXZ7xPA74dZ9ktbKyeKZQEBJVEhA7fOI6AcW0vwCmQlN836uzFbZoMyhnR471EwnSvVf4qHUa4A</pre>
 
-* Case: PSBT With invalid output witnessScript typed key
+* Case: PSBT with invalid output witnessScript typed key
 ** Bytes in Hex: <pre>70736274ff0100730200000001301ae986e516a1ec8ac5b4bc6573d32f83b465e23ad76167d68b38e730b4dbdb0000000000ffffffff02747b01000000000017a91403aa17ae882b5d0d54b25d63104e4ffece7b9ea2876043993b0000000017a914b921b1ba6f722e4bfa83b6557a3139986a42ec8387000000000001011f00ca9a3b00000000160014d2d94b64ae08587eefc8eeb187c601e939f9037c00010016001462e9e982fff34dd8239610316b090cd2a3b747cb000100220020876bad832f1d168015ed41232a9ea65a1815d9ef13c0ef8759f64b5b2b278a6521010025512103b7ce23a01c5b4bf00a642537cdfabb315b668332867478ef51309d06d57f8a8751ae00</pre>
 ** Base64 String: <pre>cHNidP8BAHMCAAAAATAa6YblFqHsisW0vGVz0y+DtGXiOtdhZ9aLOOcwtNvbAAAAAAD/////AnR7AQAAAAAAF6kUA6oXrogrXQ1Usl1jEE5P/s57nqKHYEOZOwAAAAAXqRS5IbG6b3IuS/qDtlV6MTmYakLsg4cAAAAAAAEBHwDKmjsAAAAAFgAU0tlLZK4IWH7vyO6xh8YB6Tn5A3wAAQAWABRi6emC//NN2COWEDFrCQzSo7dHywABACIAIIdrrYMvHRaAFe1BIyqeploYFdnvE8Dvh1n2S1srJ4plIQEAJVEhA7fOI6AcW0vwCmQlN836uzFbZoMyhnR471EwnQbVf4qHUa4A</pre>
 
-- 
cgit v1.2.3


From 456c8c50886bbddb7c6e3a36ccc6e8adf330aba1 Mon Sep 17 00:00:00 2001
From: "Ferdinando M. Ametrano" <fametrano@users.noreply.github.com>
Date: Mon, 16 Nov 2020 21:58:41 +0100
Subject: fixed input test case description as per output test case description

---
 bip-0174.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-0174.mediawiki b/bip-0174.mediawiki
index b2b996e..09b4b7d 100644
--- a/bip-0174.mediawiki
+++ b/bip-0174.mediawiki
@@ -569,7 +569,7 @@ The following are invalid PSBTs:
 ** Bytes in Hex: <pre>70736274ff0100550200000001279a2323a5dfb51fc45f220fa58b0fc13e1e3342792a85d7e36cd6333b5cbc390000000000ffffffff01a05aea0b000000001976a914ffe9c0061097cc3b636f2cb0460fa4fc427d2b4588ac0000000000010120955eea0b0000000017a9146345200f68d189e1adc0df1c4d16ea8f14c0dbeb87220203b1341ccba7683b6af4f1238cd6e97e7167d569fac47f1e48d47541844355bd4646304302200424b58effaaa694e1559ea5c93bbfd4a89064224055cdf070b6771469442d07021f5c8eb0fea6516d60b8acb33ad64ede60e8785bfb3aa94b99bdf86151db9a9a010104220020771fd18ad459666dd49f3d564e3dbc42f4c84774e360ada16816a8ed488d568102050047522103b1341ccba7683b6af4f1238cd6e97e7167d569fac47f1e48d47541844355bd462103de55d1e1dac805e3f8a58c1fbf9b94c02f3dbaafe127fefca4995f26f82083bd52ae220603b1341ccba7683b6af4f1238cd6e97e7167d569fac47f1e48d47541844355bd4610b4a6ba67000000800000008004000080220603de55d1e1dac805e3f8a58c1fbf9b94c02f3dbaafe127fefca4995f26f82083bd10b4a6ba670000008000000080050000800000</pre>
 ** Base64 String: <pre>cHNidP8BAFUCAAAAASeaIyOl37UfxF8iD6WLD8E+HjNCeSqF1+Ns1jM7XLw5AAAAAAD/////AaBa6gsAAAAAGXapFP/pwAYQl8w7Y28ssEYPpPxCfStFiKwAAAAAAAEBIJVe6gsAAAAAF6kUY0UgD2jRieGtwN8cTRbqjxTA2+uHIgIDsTQcy6doO2r08SOM1ul+cWfVafrEfx5I1HVBhENVvUZGMEMCIAQktY7/qqaU4VWepck7v9SokGQiQFXN8HC2dxRpRC0HAh9cjrD+plFtYLisszrWTt5g6Hhb+zqpS5m9+GFR25qaAQEEIgAgdx/RitRZZm3Unz1WTj28QvTIR3TjYK2haBao7UiNVoECBQBHUiEDsTQcy6doO2r08SOM1ul+cWfVafrEfx5I1HVBhENVvUYhA95V0eHayAXj+KWMH7+blMAvPbqv4Sf+/KSZXyb4IIO9Uq4iBgOxNBzLp2g7avTxI4zW6X5xZ9Vp+sR/HkjUdUGEQ1W9RhC0prpnAAAAgAAAAIAEAACAIgYD3lXR4drIBeP4pYwfv5uUwC89uq/hJ/78pJlfJvggg70QtKa6ZwAAAIAAAACABQAAgAAA</pre>
 
-* Case: PSBT with invalid bip32 typed key
+* Case: PSBT with invalid pubkey in input BIP 32 derivation paths typed key
 ** Bytes in Hex: <pre>70736274ff0100550200000001279a2323a5dfb51fc45f220fa58b0fc13e1e3342792a85d7e36cd6333b5cbc390000000000ffffffff01a05aea0b000000001976a914ffe9c0061097cc3b636f2cb0460fa4fc427d2b4588ac0000000000010120955eea0b0000000017a9146345200f68d189e1adc0df1c4d16ea8f14c0dbeb87220203b1341ccba7683b6af4f1238cd6e97e7167d569fac47f1e48d47541844355bd4646304302200424b58effaaa694e1559ea5c93bbfd4a89064224055cdf070b6771469442d07021f5c8eb0fea6516d60b8acb33ad64ede60e8785bfb3aa94b99bdf86151db9a9a010104220020771fd18ad459666dd49f3d564e3dbc42f4c84774e360ada16816a8ed488d5681010547522103b1341ccba7683b6af4f1238cd6e97e7167d569fac47f1e48d47541844355bd462103de55d1e1dac805e3f8a58c1fbf9b94c02f3dbaafe127fefca4995f26f82083bd52ae210603b1341ccba7683b6af4f1238cd6e97e7167d569fac47f1e48d47541844355bd10b4a6ba67000000800000008004000080220603de55d1e1dac805e3f8a58c1fbf9b94c02f3dbaafe127fefca4995f26f82083bd10b4a6ba670000008000000080050000800000</pre>
 ** Base64 String: <pre>cHNidP8BAFUCAAAAASeaIyOl37UfxF8iD6WLD8E+HjNCeSqF1+Ns1jM7XLw5AAAAAAD/////AaBa6gsAAAAAGXapFP/pwAYQl8w7Y28ssEYPpPxCfStFiKwAAAAAAAEBIJVe6gsAAAAAF6kUY0UgD2jRieGtwN8cTRbqjxTA2+uHIgIDsTQcy6doO2r08SOM1ul+cWfVafrEfx5I1HVBhENVvUZGMEMCIAQktY7/qqaU4VWepck7v9SokGQiQFXN8HC2dxRpRC0HAh9cjrD+plFtYLisszrWTt5g6Hhb+zqpS5m9+GFR25qaAQEEIgAgdx/RitRZZm3Unz1WTj28QvTIR3TjYK2haBao7UiNVoEBBUdSIQOxNBzLp2g7avTxI4zW6X5xZ9Vp+sR/HkjUdUGEQ1W9RiED3lXR4drIBeP4pYwfv5uUwC89uq/hJ/78pJlfJvggg71SriEGA7E0HMunaDtq9PEjjNbpfnFn1Wn6xH8eSNR1QYRDVb0QtKa6ZwAAAIAAAACABAAAgCIGA95V0eHayAXj+KWMH7+blMAvPbqv4Sf+/KSZXyb4IIO9ELSmumcAAACAAAAAgAUAAIAAAA==</pre>
 
-- 
cgit v1.2.3


From 08844fd6eff55e756c453c6d2e16de40e8f80e73 Mon Sep 17 00:00:00 2001
From: Greg-Griffith <probablyaplebeian@protonmail.com>
Date: Wed, 18 Nov 2020 12:17:04 -0800
Subject: BIP34 specifies it requires minimal encoding.

Non minimal encodings are rejected by the bitcoin-core client because it
only checks against a specific encoding
---
 bip-0034.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-0034.mediawiki b/bip-0034.mediawiki
index a993b7e..88073c5 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 2<sup>23</sup>-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 2<sup>23</sup>-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)
 
-- 
cgit v1.2.3


From 6fb34f2a510391a80371a4616577b5615e494700 Mon Sep 17 00:00:00 2001
From: Ethan Kosakovsky <ethankosakovsky@protonmail.com>
Date: Fri, 30 Oct 2020 12:47:29 +0000
Subject: Add BIP85-DRNG and other key derivations

---
 bip-0085.mediawiki | 60 +++++++++++++++++++++++++++++++++++++++++++++++++++---
 1 file changed, 57 insertions(+), 3 deletions(-)

diff --git a/bip-0085.mediawiki b/bip-0085.mediawiki
index 7c4cbca..b9bafdb 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.
@@ -69,19 +71,41 @@ 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=6bea85e51a05e6dbaf2ccee05097758213807997ba936589cef01c8f19c0079f395a0cd045efa3438677f3ef9ad34c9a68506626c5a17e51ed5e177852ee7fdc
+
+* DRNG(80 bytes)=b78b1ee6b345eae6836c2d53d33c64cdaf9a696487be81b03e822dc84b3f1cd883d7559e53d175f243e4c349e822a957bbff9224bc5dde9492ef54e8a439f6bc8c7355b87a925a37ee405a7502991111
+
 ==Reference Implementation==
 
-Python library implementation: [https://github.com/ethankosakovsky/bipentropy python-bipentropy]
+Python library implementation: [https://github.com/ethankosakovsky/bip85]
 
 ===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]
 
 ==Applications==
 
 Application number define how entropy will be used post processing. Some basic examples follow:
 
-Derivation path uses the format <code>m/83696968/' + /app_no' + /index'</code> where ''app_no'' path for the application, and `index` in the index.
+Derivation path uses the format <code>m/83696968/{app_no}'/{index}'</code> where ''{app_no}'' path for the application, and ''{index}'' in the index.
 
 ===BIP39===
 Application number: 39'
@@ -231,6 +255,36 @@ INPUT:
 OUTPUT
 * DERIVED ENTROPY=492db4698cf3b73a5a24998aa3e9d7fa96275d85724a91e71aa2d645442f878555d078fd1f1f67e368976f04137b1f7a0d19232136ca50c44614af72b5582a5c
 
+===RSA===
+
+Application number: 828365'
+
+The derivation path format is: <code>m/83696968'/828365'/{key_bits}'/{key_index}'</code>
+
+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 <code>m/83696968'/828365'/{key_bits}'/{key_index}'</code>
+ - Sub keys:  <code>m/83696968'/828365'/{key_bits}'/{key_index}'/{sub_key}'</code>
+
+    - key_index is the parent key for CERTIFY capability
+    - sub_key <code>0'</code> is used as the ENCRYPTION key
+    - sub_key <code>1'</code> is used as the AUTHENTICATION key
+    - sub_key <code>2'</code> 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 <code>'2009-01-03 18:05:05'</code> 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 <code>faketime</code>).
+
+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 dual purpose.
+
 ==Backwards Compatibility==
 
 This specification is not backwards compatible with any other existing specification.
-- 
cgit v1.2.3


From cf32b7bd397607a972eb1e0be311ce919c01cd47 Mon Sep 17 00:00:00 2001
From: Orfeas Litos <o.thyfronitis@ed.ac.uk>
Date: Mon, 30 Nov 2020 12:31:10 +0000
Subject: Say that public nonce is R and private nonce is s

---
 bip-0340.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-0340.mediawiki b/bip-0340.mediawiki
index f22194f..97c1db4 100644
--- a/bip-0340.mediawiki
+++ b/bip-0340.mediawiki
@@ -227,7 +227,7 @@ Moreover, Schnorr signatures are compatible with [https://web.archive.org/web/20
 
 === Adaptor Signatures ===
 
-[https://download.wpsoftware.net/bitcoin/wizardry/mw-slides/2018-05-18-l2/slides.pdf Adaptor signatures] can be produced by a signer by offsetting his public nonce with a known point ''T = t⋅G'', but not offsetting his secret nonce.
+[https://download.wpsoftware.net/bitcoin/wizardry/mw-slides/2018-05-18-l2/slides.pdf Adaptor signatures] can be produced by a signer by offsetting his public nonce ''R'' with a known point ''T = t⋅G'', but not offsetting his secret nonce ''s''.
 A correct signature (or partial signature, as individual signers' contributions to a multisignature are called) on the same message with same nonce will then be equal to the adaptor signature offset by ''t'', meaning that learning ''t'' is equivalent to learning a correct signature.
 This can be used to enable atomic swaps or even [https://eprint.iacr.org/2018/472 general payment channels] in which the atomicity of disjoint transactions is ensured using the signatures themselves, rather than Bitcoin script support. The resulting transactions will appear to verifiers to be no different from ordinary single-signer transactions, except perhaps for the inclusion of locktime refund logic.
 
-- 
cgit v1.2.3


From 23782b869342a59340a3d842ddf01a5e5495a91b Mon Sep 17 00:00:00 2001
From: Orfeas Litos <o.thyfronitis@ed.ac.uk>
Date: Mon, 30 Nov 2020 14:30:47 +0000
Subject: Remove the term "secret nonce", only refer to s

---
 bip-0340.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-0340.mediawiki b/bip-0340.mediawiki
index 97c1db4..1de7faa 100644
--- a/bip-0340.mediawiki
+++ b/bip-0340.mediawiki
@@ -227,7 +227,7 @@ Moreover, Schnorr signatures are compatible with [https://web.archive.org/web/20
 
 === Adaptor Signatures ===
 
-[https://download.wpsoftware.net/bitcoin/wizardry/mw-slides/2018-05-18-l2/slides.pdf Adaptor signatures] can be produced by a signer by offsetting his public nonce ''R'' with a known point ''T = t⋅G'', but not offsetting his secret nonce ''s''.
+[https://download.wpsoftware.net/bitcoin/wizardry/mw-slides/2018-05-18-l2/slides.pdf Adaptor signatures] can be produced by a signer by offsetting his public nonce ''R'' with a known point ''T = t⋅G'', but not offsetting the signature's ''s'' value.
 A correct signature (or partial signature, as individual signers' contributions to a multisignature are called) on the same message with same nonce will then be equal to the adaptor signature offset by ''t'', meaning that learning ''t'' is equivalent to learning a correct signature.
 This can be used to enable atomic swaps or even [https://eprint.iacr.org/2018/472 general payment channels] in which the atomicity of disjoint transactions is ensured using the signatures themselves, rather than Bitcoin script support. The resulting transactions will appear to verifiers to be no different from ordinary single-signer transactions, except perhaps for the inclusion of locktime refund logic.
 
-- 
cgit v1.2.3


From e549ed36e8bbb0d15b1bd245cc5bb2c5664d5aa2 Mon Sep 17 00:00:00 2001
From: Vasil Dimov <vd@FreeBSD.org>
Date: Mon, 7 Dec 2020 15:57:33 +0100
Subject: BIP155: change when sendaddrv2 is to be sent

Mandate to send `sendaddrv2` to the peer before sending our `verack`
to them.

This way we know that the peer does not support `addrv2` if we did not
receive `sendaddrv2` from them before receiving their `verack`.
---
 bip-0155.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-0155.mediawiki b/bip-0155.mediawiki
index 71fe3cc..ab3c0fc 100644
--- a/bip-0155.mediawiki
+++ b/bip-0155.mediawiki
@@ -134,7 +134,7 @@ See the appendices for the address encodings to be used for the various networks
 
 Introduce a new message type <code>sendaddrv2</code>. Sending such a message indicates that a node can understand and prefers to receive <code>addrv2</code> messages instead of <code>addr</code> messages. I.e. "Send me addrv2".
 
-<code>sendaddrv2</code> SHOULD be sent after receiving the <code>verack</code> message from the peer.
+The <code>sendaddrv2</code> message MUST only be sent in response to the <code>version</code> message from a peer and prior to sending the <code>verack</code> message.
 
 For older peers, that did not emit <code>sendaddrv2</code>, keep sending the legacy <code>addr</code> message, ignoring addresses with the newly introduced address types.
 
-- 
cgit v1.2.3


From e6b9822142eb41771dbaaa4dfd39d99432e92d49 Mon Sep 17 00:00:00 2001
From: Fonta1n3 <fontainedenton@googlemail.com>
Date: Wed, 16 Dec 2020 19:22:20 +0800
Subject: Create bip-0048.mediawiki

---
 bip-0048.mediawiki | 253 +++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 253 insertions(+)
 create mode 100644 bip-0048.mediawiki

diff --git a/bip-0048.mediawiki b/bip-0048.mediawiki
new file mode 100644
index 0000000..7c39823
--- /dev/null
+++ b/bip-0048.mediawiki
@@ -0,0 +1,253 @@
+<pre>
+  BIP: 48
+  Layer: Applications
+  Title: Multi-Account/Multi-Script Hierarchy for Deterministic Multi Signature Wallets
+  Author: Peter Denton <dentondevelopment@protonmail.com>
+  Comments-Summary: Mixed review (one person)
+  Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0048
+  Status: Proposed
+  Type: Standards Track
+  Created: 2020-12-16
+</pre>
+
+==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) and purpose scheme described in
+BIP-0043 (BIP43 from now on).
+
+This BIP is a particular application of BIP43.
+
+==Motivation==
+
+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.
+
+==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 ordered public keys.
+
+==Path levels==
+
+We define the following 6 levels in BIP32 path:
+
+<pre>
+m / purpose' / coin_type' / account' / script_type' / change / address_index
+</pre>
+
+`h` 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 either 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,
+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.
+
+Software should prevent a creation of an account if a previous account does not
+have a transaction history (meaning none of its addresses have been used before).
+
+Software needs to discover all used accounts after importing the seed from
+an external source. Such an algorithm is described in "Account discovery" chapter.
+
+===Script===
+
+This level splits the key space into three separate `script_type`(s). To provide
+optimum backward compatibility.
+
+The recommended default is pay to witness script hash `m/48'/0'/0'/2'`.
+
+The following represent mainnet, account 0.
+
+`1'`: Nested Segwit (p2sh-p2wsh) `m/48'/0'/0'/1'`</br>
+`2'`: Native Segwit (p2wsh) `m/48'/0'/0'/2'`</br>
+`3'`: Legacy (p2sh) `m/48'/0'/0'/3'`</br>
+
+===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.
+
+==Account discovery==
+
+When the master seed is imported from an external source the software should
+start to discover the accounts in the following manner:
+
+* derive the first accounts node (index = 0)
+* derive the external chain node of this account
+* scan addresses of the external chain; respect the gap limit described below
+* if no transactions are found on the external chain, stop discovery
+* if there are some transactions, increase the account index and go to step 1
+
+This algorithm is successful because software should disallow creation of new
+accounts if previous one has no transaction history, as described in chapter
+"Account" above.
+
+Please note that the algorithm works with the transaction history, not account
+balances, so you can have an account with 0 total coins and the algorithm will
+still continue with discovery.
+
+===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. We scan just the external chains, because
+internal chains receive only coins that come from the associated external chains.
+
+Wallet software should warn when the user is trying to exceed the gap limit on
+an external chain by generating a new address.
+
+==Examples==
+
+{|
+!coin
+!account
+!script
+!chain
+!address
+!path
+|-
+|Bitcoin
+|first
+|external
+|first
+|m / 48' / 0' / 0' / 2' / 0 / 0
+|-
+|Bitcoin
+|first
+|external
+|second
+|m / 48' / 0' / 0' / 2' / 0 / 1
+|-
+|Bitcoin
+|first
+|change
+|first
+|m / 48' / 0' / 0' / 2' / 1 / 0
+|-
+|Bitcoin
+|first
+|change
+|second
+|m / 48' / 0' / 0' / 2' / 1 / 1
+|-
+|Bitcoin
+|second
+|external
+|first
+|m / 48' / 0' / 1' / 2' / 0 / 0
+|-
+|Bitcoin
+|second
+|external
+|second
+|m / 48' / 0' / 1' / 2' / 0 / 1
+|-
+|Bitcoin
+|second
+|change
+|first
+|m / 48' / 0' / 1' / 2' / 1 / 0
+|-
+|Bitcoin
+|second
+|change
+|second
+|m / 48' / 1' / 1' / 2' / 1 / 1
+|-
+|Bitcoin Testnet
+|first
+|external
+|first
+|m / 48' / 1' / 0' / 2' / 0 / 0
+|-
+|Bitcoin Testnet
+|first
+|external
+|second
+|m / 48' / 1' / 0' / 2' / 0 / 1
+|-
+|Bitcoin Testnet
+|first
+|change
+|first
+|m / 48' / 1' / 0' / 2' / 1 / 0
+|-
+|Bitcoin Testnet
+|first
+|change
+|second
+|m / 48' / 1' / 0' / 2' / 1 / 1
+|-
+|Bitcoin Testnet
+|second
+|external
+|first
+|m / 48' / 1' / 1' / 2' / 0 / 0
+|-
+|Bitcoin Testnet
+|second
+|external
+|second
+|m / 48' / 1' / 1' / 2' / 0 / 1
+|-
+|Bitcoin Testnet
+|second
+|change
+|first
+|m / 48' / 1' / 1' / 2' / 1 / 0
+|-
+|Bitcoin Testnet
+|second
+|change
+|second
+|m / 48 h / 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]]
-- 
cgit v1.2.3


From c9517ecf8708f9745cc9d608b7936dff6c541b57 Mon Sep 17 00:00:00 2001
From: Fonta1n3 <fontainedenton@googlemail.com>
Date: Wed, 16 Dec 2020 22:05:54 +0800
Subject: fixes

---
 .DS_Store          | Bin 0 -> 18436 bytes
 bip-0048.mediawiki |  90 ++++++++++++++++++++++++++++++++---------------------
 2 files changed, 55 insertions(+), 35 deletions(-)
 create mode 100644 .DS_Store

diff --git a/.DS_Store b/.DS_Store
new file mode 100644
index 0000000..6f80a1e
Binary files /dev/null and b/.DS_Store differ
diff --git a/bip-0048.mediawiki b/bip-0048.mediawiki
index 7c39823..386b410 100644
--- a/bip-0048.mediawiki
+++ b/bip-0048.mediawiki
@@ -3,7 +3,7 @@
   Layer: Applications
   Title: Multi-Account/Multi-Script Hierarchy for Deterministic Multi Signature Wallets
   Author: Peter Denton <dentondevelopment@protonmail.com>
-  Comments-Summary: Mixed review (one person)
+  Comments-Summary: No comments
   Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0048
   Status: Proposed
   Type: Standards Track
@@ -27,7 +27,7 @@ millions of addresses per chain.
 ==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 ordered public keys.
+multi-signature addresses/scripts are derived from deterministically sorted public keys.
 
 ==Path levels==
 
@@ -37,7 +37,7 @@ We define the following 6 levels in BIP32 path:
 m / purpose' / coin_type' / account' / script_type' / change / address_index
 </pre>
 
-`h` in the path indicates that BIP32 hardened derivation is used.
+<code>h</code> or <code>'</code> in the path indicates that BIP32 hardened derivation is used.
 
 Each level has a special meaning, described in the chapters below.
 
@@ -55,7 +55,7 @@ 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.
+Coin type <code>0</code> for mainnet and <code>1</code> for testnet.
 
 Hardened derivation is used at this level.
 
@@ -82,16 +82,18 @@ an external source. Such an algorithm is described in "Account discovery" chapte
 
 ===Script===
 
-This level splits the key space into three separate `script_type`(s). To provide
+This level splits the key space into three separate <code>script_type</code>(s). To provide
 optimum backward compatibility.
 
-The recommended default is pay to witness script hash `m/48'/0'/0'/2'`.
+The recommended default is pay to witness script hash <code>m/48'/0'/0'/2'</code>.
 
 The following represent mainnet, account 0.
 
-`1'`: Nested Segwit (p2sh-p2wsh) `m/48'/0'/0'/1'`</br>
-`2'`: Native Segwit (p2wsh) `m/48'/0'/0'/2'`</br>
-`3'`: Legacy (p2sh) `m/48'/0'/0'/3'`</br>
+<code>1'</code>: Nested Segwit (p2sh-p2wsh) <code>m/48'/0'/0'/1'</code></br>
+<code>2'</code>: Native Segwit (p2wsh) <code>m/48'/0'/0'/2'</code></br>
+<code>3'</code>: Legacy (p2sh) <code>m/48'/0'/0'/3'</code></br>
+
+Easily expanded to account for new script types.
 
 ===Change===
 
@@ -142,109 +144,127 @@ an external chain by generating a new address.
 ==Examples==
 
 {|
-!coin
-!account
-!script
-!chain
-!address
-!path
+|network
+|account
+|script
+|chain
+|address
+|path
 |-
-|Bitcoin
+|mainnet
 |first
+|p2wsh
 |external
 |first
 |m / 48' / 0' / 0' / 2' / 0 / 0
 |-
-|Bitcoin
+|mainnet
 |first
+|p2wsh
 |external
 |second
 |m / 48' / 0' / 0' / 2' / 0 / 1
 |-
-|Bitcoin
+|mainnet
 |first
+|p2wsh
 |change
 |first
 |m / 48' / 0' / 0' / 2' / 1 / 0
 |-
-|Bitcoin
+|mainnet
 |first
+|p2wsh
 |change
 |second
 |m / 48' / 0' / 0' / 2' / 1 / 1
 |-
-|Bitcoin
+|mainnet
 |second
+|p2wsh
 |external
 |first
 |m / 48' / 0' / 1' / 2' / 0 / 0
 |-
-|Bitcoin
+|mainnet
 |second
+|p2wsh
 |external
 |second
 |m / 48' / 0' / 1' / 2' / 0 / 1
 |-
-|Bitcoin
+|mainnet
 |second
+|p2sh
 |change
 |first
-|m / 48' / 0' / 1' / 2' / 1 / 0
+|m / 48' / 0' / 1' / 3' / 1 / 0
 |-
-|Bitcoin
+|mainnet
 |second
+|p2sh
 |change
 |second
-|m / 48' / 1' / 1' / 2' / 1 / 1
+|m / 48' / 1' / 1' / 3' / 1 / 1
 |-
-|Bitcoin Testnet
+|testnet
 |first
+|p2sh-p2wsh
 |external
 |first
-|m / 48' / 1' / 0' / 2' / 0 / 0
+|m / 48' / 1' / 0' / 1' / 0 / 0
 |-
-|Bitcoin Testnet
+|testnet
 |first
+|p2wsh
 |external
 |second
 |m / 48' / 1' / 0' / 2' / 0 / 1
 |-
-|Bitcoin Testnet
+|testnet
 |first
+|p2wsh
 |change
 |first
 |m / 48' / 1' / 0' / 2' / 1 / 0
 |-
-|Bitcoin Testnet
+|testnet
 |first
+|p2wsh
 |change
 |second
 |m / 48' / 1' / 0' / 2' / 1 / 1
 |-
-|Bitcoin Testnet
+|testnet
 |second
+|p2wsh
 |external
 |first
 |m / 48' / 1' / 1' / 2' / 0 / 0
 |-
-|Bitcoin Testnet
+|testnet
 |second
+|p2wsh
 |external
 |second
 |m / 48' / 1' / 1' / 2' / 0 / 1
 |-
-|Bitcoin Testnet
+|testnet
 |second
+|p2wsh
 |change
 |first
 |m / 48' / 1' / 1' / 2' / 1 / 0
 |-
-|Bitcoin Testnet
+|testnet
 |second
+|p2wsh
 |change
 |second
 |m / 48 h / 1' / 1' / 2' / 1 / 1
-|}
+|-
+}|
+
 
 ==Reference==
 
-- 
cgit v1.2.3


From 23d57cb9ad0378abaeeb3ddeecced87384498eca Mon Sep 17 00:00:00 2001
From: Fonta1n3 <fontainedenton@googlemail.com>
Date: Wed, 16 Dec 2020 22:31:24 +0800
Subject: typo

---
 bip-0048.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-0048.mediawiki b/bip-0048.mediawiki
index 386b410..470febf 100644
--- a/bip-0048.mediawiki
+++ b/bip-0048.mediawiki
@@ -261,7 +261,7 @@ an external chain by generating a new address.
 |p2wsh
 |change
 |second
-|m / 48 h / 1' / 1' / 2' / 1 / 1
+|m / 48' / 1' / 1' / 2' / 1 / 1
 |-
 }|
 
-- 
cgit v1.2.3


From 42b9148ceaa30f7c7a60b4e29ad07ffb47e31b05 Mon Sep 17 00:00:00 2001
From: Fonta1n3 <fontainedenton@googlemail.com>
Date: Wed, 16 Dec 2020 22:35:09 +0800
Subject: minor

---
 bip-0048.mediawiki | 8 +++-----
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/bip-0048.mediawiki b/bip-0048.mediawiki
index 470febf..bfea5f0 100644
--- a/bip-0048.mediawiki
+++ b/bip-0048.mediawiki
@@ -83,18 +83,16 @@ an external source. Such an algorithm is described in "Account discovery" chapte
 ===Script===
 
 This level splits the key space into three separate <code>script_type</code>(s). To provide
-optimum backward compatibility.
+backward and forward compatibility.
 
-The recommended default is pay to witness script hash <code>m/48'/0'/0'/2'</code>.
+The following represent mainnet, account 0:
 
-The following represent mainnet, account 0.
+The recommended default is pay to witness script hash <code>m/48'/0'/0'/2'</code>.
 
 <code>1'</code>: Nested Segwit (p2sh-p2wsh) <code>m/48'/0'/0'/1'</code></br>
 <code>2'</code>: Native Segwit (p2wsh) <code>m/48'/0'/0'/2'</code></br>
 <code>3'</code>: Legacy (p2sh) <code>m/48'/0'/0'/3'</code></br>
 
-Easily expanded to account for new script types.
-
 ===Change===
 
 Constant 0 is used for external chain and constant 1 for internal chain (also
-- 
cgit v1.2.3


From ff04f6cea417038c8a382c0b141faea2d1dd26fb Mon Sep 17 00:00:00 2001
From: Fonta1n3 <fontainedenton@googlemail.com>
Date: Wed, 16 Dec 2020 22:36:43 +0800
Subject: Update bip-0048.mediawiki

---
 bip-0048.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-0048.mediawiki b/bip-0048.mediawiki
index bfea5f0..2b0df31 100644
--- a/bip-0048.mediawiki
+++ b/bip-0048.mediawiki
@@ -50,7 +50,7 @@ Hardened derivation is used at this level.
 
 ===Coin type===
 
-One master node (seed) can be used for either multiple Bitcoin networks.
+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.
-- 
cgit v1.2.3


From bfebc4b047eac88c86a2cd98fcd37ee110be85b1 Mon Sep 17 00:00:00 2001
From: benk10 <ben.kaufman10@gmail.com>
Date: Wed, 16 Dec 2020 16:43:21 +0200
Subject: Mention BIP 44 as the Multi-Account standard

---
 bip-0048.mediawiki | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/bip-0048.mediawiki b/bip-0048.mediawiki
index 2b0df31..b164bea 100644
--- a/bip-0048.mediawiki
+++ b/bip-0048.mediawiki
@@ -13,8 +13,9 @@
 ==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) and purpose scheme described in
-BIP-0043 (BIP43 from now on).
+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.
 
@@ -61,7 +62,7 @@ Hardened derivation is used at this level.
 
 ===Account===
 
-This level splits the key space into independent user identities,
+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
@@ -269,3 +270,4 @@ an external chain by generating a new address.
 * [[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]]
-- 
cgit v1.2.3


From 4e81e16224d647c5268e21a2bb280f9678f5f91a Mon Sep 17 00:00:00 2001
From: Fonta1n3 <fontainedenton@googlemail.com>
Date: Wed, 16 Dec 2020 22:54:41 +0800
Subject: Update bip-0048.mediawiki

---
 bip-0048.mediawiki | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/bip-0048.mediawiki b/bip-0048.mediawiki
index 2b0df31..06d8471 100644
--- a/bip-0048.mediawiki
+++ b/bip-0048.mediawiki
@@ -18,6 +18,9 @@ BIP-0043 (BIP43 from now on).
 
 This BIP is a particular application of BIP43.
 
+Credit to Marek Palatinus <slush@satoshilabs.com> and Pavol Rusnak <stick@satoshilabs.com> who wrote BIP-0044
+which was used as the basis for this BIP.
+
 ==Motivation==
 
 The hierarchy proposed in this paper is quite comprehensive. It allows the handling of
-- 
cgit v1.2.3


From 9ec6bf64b715724ffcc607d156cd99429665d8bd Mon Sep 17 00:00:00 2001
From: benk10 <ben.kaufman10@gmail.com>
Date: Wed, 16 Dec 2020 16:55:38 +0200
Subject: Fix the table

---
 bip-0048.mediawiki | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/bip-0048.mediawiki b/bip-0048.mediawiki
index b164bea..a4dbbcc 100644
--- a/bip-0048.mediawiki
+++ b/bip-0048.mediawiki
@@ -261,8 +261,7 @@ an external chain by generating a new address.
 |change
 |second
 |m / 48' / 1' / 1' / 2' / 1 / 1
-|-
-}|
+|}
 
 
 ==Reference==
-- 
cgit v1.2.3


From eae5288ffdca6866d93c3b6ca99e24afea82cd46 Mon Sep 17 00:00:00 2001
From: Fonta1n3 <fontainedenton@googlemail.com>
Date: Wed, 16 Dec 2020 22:59:10 +0800
Subject: Update bip-0048.mediawiki

---
 bip-0048.mediawiki | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/bip-0048.mediawiki b/bip-0048.mediawiki
index 06d8471..2b0df31 100644
--- a/bip-0048.mediawiki
+++ b/bip-0048.mediawiki
@@ -18,9 +18,6 @@ BIP-0043 (BIP43 from now on).
 
 This BIP is a particular application of BIP43.
 
-Credit to Marek Palatinus <slush@satoshilabs.com> and Pavol Rusnak <stick@satoshilabs.com> who wrote BIP-0044
-which was used as the basis for this BIP.
-
 ==Motivation==
 
 The hierarchy proposed in this paper is quite comprehensive. It allows the handling of
-- 
cgit v1.2.3


From 38096cedd9863b9fe9f363f0e2127e73609b79b0 Mon Sep 17 00:00:00 2001
From: Fonta1n3 <fontainedenton@googlemail.com>
Date: Wed, 16 Dec 2020 23:12:19 +0800
Subject: remove bip44 stuff

---
 bip-0048.mediawiki | 29 -----------------------------
 1 file changed, 29 deletions(-)

diff --git a/bip-0048.mediawiki b/bip-0048.mediawiki
index a4dbbcc..2662404 100644
--- a/bip-0048.mediawiki
+++ b/bip-0048.mediawiki
@@ -111,35 +111,6 @@ This number is used as child index in BIP32 derivation.
 
 Public derivation is used at this level.
 
-==Account discovery==
-
-When the master seed is imported from an external source the software should
-start to discover the accounts in the following manner:
-
-* derive the first accounts node (index = 0)
-* derive the external chain node of this account
-* scan addresses of the external chain; respect the gap limit described below
-* if no transactions are found on the external chain, stop discovery
-* if there are some transactions, increase the account index and go to step 1
-
-This algorithm is successful because software should disallow creation of new
-accounts if previous one has no transaction history, as described in chapter
-"Account" above.
-
-Please note that the algorithm works with the transaction history, not account
-balances, so you can have an account with 0 total coins and the algorithm will
-still continue with discovery.
-
-===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. We scan just the external chains, because
-internal chains receive only coins that come from the associated external chains.
-
-Wallet software should warn when the user is trying to exceed the gap limit on
-an external chain by generating a new address.
-
 ==Examples==
 
 {|
-- 
cgit v1.2.3


From e963414eee7ac8f85a5a92f9d170f5f3d38f816d Mon Sep 17 00:00:00 2001
From: koushiro <koushiro.cqx@gmail.com>
Date: Thu, 17 Dec 2020 22:20:40 +0800
Subject: Add a link of another Rust implmentation of BIP-0039

Signed-off-by: koushiro <koushiro.cqx@gmail.com>
---
 bip-0039.mediawiki | 1 +
 1 file changed, 1 insertion(+)

diff --git a/bip-0039.mediawiki b/bip-0039.mediawiki
index c5ab9bb..30e02e6 100644
--- a/bip-0039.mediawiki
+++ b/bip-0039.mediawiki
@@ -164,6 +164,7 @@ Ruby:
 
 Rust:
 * https://github.com/maciejhirsz/tiny-bip39/
+* https://github.com/koushiro/bip0039-rs
 
 Swift:
 * https://github.com/CikeQiu/CKMnemonic
-- 
cgit v1.2.3


From 518bb8bf4f62ce9f40bff4fb3084cc63b736726c Mon Sep 17 00:00:00 2001
From: Luke Dashjr <luke-jr+git@utopios.org>
Date: Fri, 18 Dec 2020 03:53:37 +0000
Subject: README: Link BIP 2 for submissions

---
 README.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/README.mediawiki b/README.mediawiki
index 83120ab..294b02f 100644
--- a/README.mediawiki
+++ b/README.mediawiki
@@ -1,4 +1,4 @@
-People wishing to submit BIPs, first should propose their idea or document to the [https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev bitcoin-dev@lists.linuxfoundation.org] mailing list. After discussion, please open a PR. After copy-editing and acceptance, it will be published here.
+People wishing to submit BIPs, first should propose their idea or document to the [https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev bitcoin-dev@lists.linuxfoundation.org] mailing list (do <em>not</em> assign a number - read <a href="bip-0002.mediawiki">BIP 2</a> for the full process). After discussion, please open a PR. After copy-editing and acceptance, it will be published here.
 
 We are fairly liberal with approving BIPs, and try not to be too involved in decision making on behalf of the community. The exception is in very rare cases of dispute resolution when a decision is contentious and cannot be agreed upon. In those cases, the conservative option will always be preferred.
 
-- 
cgit v1.2.3


From a78b211d23788dd0bcbc57f54abf6a223356b839 Mon Sep 17 00:00:00 2001
From: Pavol Rusnak <pavol@rusnak.io>
Date: Sun, 20 Dec 2020 16:39:42 +0100
Subject: bip39: discourage from using localized wordlists

---
 bip-0039.mediawiki | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/bip-0039.mediawiki b/bip-0039.mediawiki
index c5ab9bb..08985ac 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==
 
-- 
cgit v1.2.3


From f778098debfbc31a4c98dc569fc9cd407b65407a Mon Sep 17 00:00:00 2001
From: Andrew Poelstra <apoelstra@wpsoftware.net>
Date: Wed, 23 Dec 2020 15:39:45 +0000
Subject: bip-0322: replace motivation, add myself to the "thanks to" list

---
 bip-0322.mediawiki | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/bip-0322.mediawiki b/bip-0322.mediawiki
index e515b56..f13544f 100644
--- a/bip-0322.mediawiki
+++ b/bip-0322.mediawiki
@@ -17,11 +17,11 @@ A standard for interoperable signed messages based on the Bitcoin Script format,
 
 == Motivation ==
 
-The current message signing standard only works for P2PKH (1...) invoice addresses. We propose to extend and generalize the standard by using a Bitcoin Script based approach. This approach minimizes the burden for implementers as message signing can be expected to be part of a library or project that includes Bitcoin Script interpreters already.
+The current message signing standard only works for P2PKH (1...) invoice addresses. We propose to extend and generalize the standard by using a Bitcoin Script based approach. This ensures that any coins, no matter what script they are controlled by, can in-principle be signed for. For easy interoperability with existing signing hardware, we also define a signature message format which resembles a Bitcoin transaction (except that it contains an invalid input, so it cannot be spent on any real network).
 
-Additionally, the current message signing only proves that the message has been committed to by the recipient of a given invoice address.
-It does not prove anything about the invoice address itself, nor that the signer has access to the private keys used to implement this invoice.
-More importantly, it does not prove ownership nor access to any funds, even if the same private key would be a valid signer for spending them - and this is a commonly desired use case.
+Additionally, the current message signature format uses ECDSA signatures which do not commit to the public key, meaning that they do not actually prove knowledge of any secret keys. (Indeed, valid signatures can be tweaked by 3rd parties to become valid signatures on certain related keys.)
+
+Ultimately no message signing protocol can actually prove control of funds, both because a signature is obsolete as soon as it is created, and because the possessor of a secret key may be willing to sign messages on others' behalf even if it would not sign actual transactions. No signmessage protocol can fix these limitations.
 
 == Specification ==
 
@@ -121,7 +121,7 @@ TODO
 
 == Acknowledgements ==
 
-Thanks to David Harding, Jim Posen, Kalle Rosenbaum, Pieter Wuille, and many others for their feedback on the specification.
+Thanks to David Harding, Jim Posen, Kalle Rosenbaum, Pieter Wuille, Andrew Poelstra, and many others for their feedback on the specification.
 
 == References ==
 
-- 
cgit v1.2.3


From dbb81b36525aabf4ae5d0ad015b4865494aed33e Mon Sep 17 00:00:00 2001
From: Andrew Poelstra <apoelstra@wpsoftware.net>
Date: Wed, 23 Dec 2020 15:42:41 +0000
Subject: bip-0322: move "legacy" section up, separate "proof of funds",
 summarize the signature types

---
 bip-0322.mediawiki | 42 +++++++++++++++++++++++++++++++++---------
 1 file changed, 33 insertions(+), 9 deletions(-)

diff --git a/bip-0322.mediawiki b/bip-0322.mediawiki
index f13544f..065eb7b 100644
--- a/bip-0322.mediawiki
+++ b/bip-0322.mediawiki
@@ -23,11 +23,31 @@ Additionally, the current message signature format uses ECDSA signatures which d
 
 Ultimately no message signing protocol can actually prove control of funds, both because a signature is obsolete as soon as it is created, and because the possessor of a secret key may be willing to sign messages on others' behalf even if it would not sign actual transactions. No signmessage protocol can fix these limitations.
 
-== Specification ==
+== Types of Signatures ==
 
-This BIP follows the specification of BIP-325 challenges and solutions (see Signet comparison below).
+This BIP specifies three formats for signing messages: ''legacy'', ''simple'' and ''full''. Additionally, a variant of the ''full'' format can be used to demonstrate control over a set of UTXOs.
 
-Let there be two virtual transactions to_spend and to_sign.
+=== Legacy ===
+
+New proofs should use the new format for all invoice address formats, including P2PKH.
+
+The legacy format MAY be used, but must be restricted to the legacy P2PKH invoice address format.
+
+=== Simple ===
+
+A ''simple'' signature consists of a witness stack, consensus encoded as a vector of vectors of bytes, and base64-encoded. Validators should construct <code>to_spend</code> and <code>to_sign</code> as defined below, with default values for all fields except that
+
+* <code>message_hash</code> is a BIP340-tagged hash of the message, as specified below
+* <code>message_challenge</code> in <code>to_spend</code> is set to the scriptPubKey being signed with
+* <code>message_signature</code> in <code>to_sign</code> is set to the provided simple signature.
+
+and then proceed as they would for a full signature.
+
+=== Full ===
+
+Full signatures follow an analogous specification to the BIP-325 challenges and solutions used by Signet.
+
+Let there be two virtual transactions <code>to_spend</code> and <code>to_sign</code>.
 
 The "to_spend" transaction is:
 
@@ -63,6 +83,16 @@ When a proof of funds is being created, additional inputs should be included for
 
 Proofs of funds are the base64-encoding of the to_spend and to_sign transactions concatenated in standard network serialisation, and proofs without additional inputs or time locks (simple proofs) are the base64-encoding of the to_sign script witness.
 
+=== Full (Proof of Funds) ===
+
+A signer may construct a proof of funds, demonstrating control of a set of UTXOs, by constructing a full signature as above, with the following modifications.
+
+* <code>message_challenge</code> is unused and shall be set to <code>OP_TRUE</code>
+* Similarly, <code>message_signature</code> is then empty.
+* All outputs that the signer wishes to demonstrate control of are included as additional inputs of <code>to_sign</code>, and their witness and scriptSig data should be set as though these outputs were actually being spent.
+
+Unlike an ordinary signature, validators of a proof of funds need access to the current UTXO set, to learn that the claimed inputs exist on the blockchain, and to learn their scriptPubKeys.
+
 A validator must verify it is valid and meets the description of virtual transactions as specified above. See "Validation" below.
 
 === Validation ===
@@ -83,12 +113,6 @@ To validate a proof of funds, the following steps must be taken:
 # for each proof of fund input, set the corresponding values in the coins map; abort if the input cannot be found
 # check the signature of each input using consensus rules, then upgradable rules
 
-== Legacy format ==
-
-New proofs should use the new format for all invoice address formats, including P2PKH.
-
-The legacy format MAY be used, but must be restricted to the legacy P2PKH invoice address format.
-
 === Signing ===
 
 Given the P2PKH invoice address <code>a</code> and the message <code>m</code>, and the pubkey-hash function <code>pkh(P) = ripemd160(sha256(P))</code>:
-- 
cgit v1.2.3


From 9e1beef6acabffd4a53ff1396b4cb453615de19f Mon Sep 17 00:00:00 2001
From: Andrew Poelstra <apoelstra@wpsoftware.net>
Date: Wed, 23 Dec 2020 15:47:27 +0000
Subject: bip-0322: overhaul/rewrite verification rules

---
 bip-0322.mediawiki | 128 +++++++++++++++++++++--------------------------------
 1 file changed, 50 insertions(+), 78 deletions(-)

diff --git a/bip-0322.mediawiki b/bip-0322.mediawiki
index 065eb7b..4eda7b0 100644
--- a/bip-0322.mediawiki
+++ b/bip-0322.mediawiki
@@ -49,7 +49,7 @@ Full signatures follow an analogous specification to the BIP-325 challenges and
 
 Let there be two virtual transactions <code>to_spend</code> and <code>to_sign</code>.
 
-The "to_spend" transaction is:
+The <code>to_spend</code> transaction is:
 
     nVersion = 0
     nLockTime = 0
@@ -61,10 +61,9 @@ The "to_spend" transaction is:
     vout[0].nValue = 0
     vout[0].scriptPubKey = message_challenge
 
-where message_hash is a BIP340-tagged hash of the message, i.e. sha256_tag(m), where tag = "BIP0322-signed-message", and message_challenge is the to be proven (public) key script.
-For proving funds, message_challenge shall be simply OP_TRUE.
+where <code>message_hash</code> is a BIP340-tagged hash of the message, i.e. sha256_tag(m), where tag = <code>BIP0322-signed-message</code>, and <code>message_challenge</code> is the to be proven (public) key script.
 
-The "to_sign" transaction is:
+The <code>to_sign</code> transaction is:
 
     nVersion = 0 or as appropriate (e.g. 2, for time locks)
     nLockTime = 0 or as appropriate (for time locks)
@@ -75,13 +74,7 @@ The "to_sign" transaction is:
     vout[0].nValue = 0
     vout[0].scriptPubKey = OP_RETURN
 
-When a proof of funds is being created, additional inputs should be included for virtually spending transaction outputs of desired value.
-
-* All signatures must use the SIGHASH_ALL flag.
-* The proof is considered valid, inconclusive, or invalid based on whether the to_sign transaction is a valid spend of the to_spend transaction or not, according to the rules specified in the "Consensus and standard flags" section below.
-* Proofs of funds may be encumbered with the in_future flag, according to the rules specified in the "Locktime and Sequence" section below, in which case we refer to the result in text form as "valid_in_future", "inconclusive_in_future", etc.
-
-Proofs of funds are the base64-encoding of the to_spend and to_sign transactions concatenated in standard network serialisation, and proofs without additional inputs or time locks (simple proofs) are the base64-encoding of the to_sign script witness.
+A full signature consists of the base64-encoding of the <code>to_spend</code> and <code>to_sign</code> transactions concatenated in standard network serialisation.
 
 === Full (Proof of Funds) ===
 
@@ -93,47 +86,58 @@ A signer may construct a proof of funds, demonstrating control of a set of UTXOs
 
 Unlike an ordinary signature, validators of a proof of funds need access to the current UTXO set, to learn that the claimed inputs exist on the blockchain, and to learn their scriptPubKeys.
 
-A validator must verify it is valid and meets the description of virtual transactions as specified above. See "Validation" below.
-
-=== Validation ===
-
-To validate a simple proof, the following steps must be taken:
-
-# construct the to_spend and to_sign transactions, based on the specification above
-# check the signature using consensus rules, then upgradable rules
-
-To validate a proof of funds, the following steps must be taken:
-
-# deserialize the to_spend and to_sign transactions from the proof, and fail if the proof contains extraneous bytes
-# verify that the to_sign transaction uses all inputs covered by the proof of funds, exactly once
-# reconstruct the to_spend' and to_sign' transactions, based on the specification above, copying the version, lock time, and sequence values
-# verify that to_spend = to_spend', that to_sign has at least 1 input, has exactly 1 output, and that to_sign.vin[0] = to_sign'.vin[0]
-# set the "in_future" flag if the transaction's lock time is in the future according to consensus rules
-# establish a "coins map", a mapping of outpoints (hash, vout) to coins (scriptPubKey, amount), initialized to coins_map(to_spend.txid, 0) = (to_spend.vout[0], 0)
-# for each proof of fund input, set the corresponding values in the coins map; abort if the input cannot be found
-# check the signature of each input using consensus rules, then upgradable rules
+== Detailed Specification ==
+
+For all signature types, except legacy, the <code>to_spend</code> and <code>to_sign</code> transactions must be valid transactions which pass all consensus checks, except of course that the output with prevout <code>000...000:FFFFFFFF</code> does not exist.
+
+=== Verification ===
+
+A validator is given as input an address ''A'' (which may be omitted in a proof-of-funds), signature ''s'' and message ''m'', and outputs one of three states
+* ''valid at time T and age S'' indicates that the signature has set timelocks but is otherwise valid
+* ''inconclusive'' means the validator was unable to check the scripts
+* ''invalid'' means that some check failed
+
+==== Verification Process ====
+
+Validation consists of the following steps:
+
+# Basic validation
+## Decode ''s'' as the transactions <code>to_sign</code> and <code>to_spend</code>
+## Confirm that <code>message_hash</code> is the correct hash of ''m''
+## Confirm that <code>message_challenge</code> is the scriptPubKey corresponding to ''A'' if ''A'' is present, and otherwise must be <code>OP_TRUE</code>
+## Confirm that all other fields are set as specified above; in particular that
+##* <code>to_spend</code> has exactly one input and one output
+##* <code>to_sign</code> has at least one input and its first input spends the output of </code>to_spend</code>
+##* <code>to_sign</code> has exactly one output, as specified above
+## Confirm that the two transactions together satisfy all consensus rules, except for <code>to_spend</code>'s missing input, and except that ''nSequence'' of <code>to_sign</code>'s first input and ''nLockTime'' of <code>to_sign</code> are not checked.
+# (Optional) If the validator does not have a full script interpreter, it should check that it understands all scripts being satisfied. If not, it should stop here and output ''inconclusive''.
+# Check the **required rules**:
+## All signatures must use the SIGHASH_ALL flag.
+## The use of <code>CODESEPARATOR</code> or <code>FindAndDelete</code> is forbidden.
+## <code>LOW_S</code>, <code>STRICTENC</code> and <code>NULLFAIL</code>: valid ECDSA signatures must be strictly DER-encoded and have a low-S value; invalid ECDSA signature must be the empty push
+## <code>MINIMALDATA</code>: all pushes must be minimally encoded
+## <code>CLEANSTACK</code>: require that only a single stack element remains after evaluation
+## <code>MINIMALIF</code>: the argument of <code>IF</code>/<code>NOTIF</code> must be exactly 0x01 or empty push
+## If any of the above steps failed, the validator should stop and output the ''invalid'' state.
+# Check the **upgradeable rules**
+## The use of NOPs reserved for upgrades is forbidden.
+## The use of segwit versions greater than 0 are forbidden.
+## If any of the above steps failed, the validator should stop and output the ''inconclusive'' state.
+# Let ''T'' by the nLockTime of <code>to_sign</code> and ''S'' be the nSequence of the first input of <code>to_sign</code>. Output the state ''valid at time T and age S''.
 
 === Signing ===
 
-Given the P2PKH invoice address <code>a</code> and the message <code>m</code>, and the pubkey-hash function <code>pkh(P) = ripemd160(sha256(P))</code>:
-
-# let <code>p</code> be the pubkey-hash <code>pkh(P)</code> for the pubkey <code>P</code>, contained in <code>a</code>
-# let <code>x</code> be the private key associated with <code>P</code> so that <code>pkh(xG) = p</code>
-# let <code>digest</code> be <code>SHA56d(0x18||"Bitcoin Signed Message:\n"||compactint(len(m))||m)</code>
-# create a compact signature <code>sig</code> (aka "recoverable ECDSA signature") using <code>x</code> on <code>digest</code>
-
-The resulting proof is <code>sig</code>, serialized using the base64 encoding.
+Signers who control an address ''A'' who wish to sign a message ''m'' act as follows:
 
-=== Verifying ===
+# They construct <code>to_spend</code> and <code>to_sign</code> as specified above, using the scriptPubKey of ''A'' for <code>message_challenge</code> and tagged hash of ''m'' as <code>message_hash</code>.
+# Optionally, they may set nLockTime of <code>to_sign</code> or nSequence of its first input.
+# Optionally, they may add any additional outputs to <code>to_sign</code> that they wish to prove control of.
+# They satisfy <code>to_sign</code> as they would any other transaction.
 
-Given the P2PKH invoice address <code>a</code>, the message <code>m</code>, the compact signature <code>sig</code>, and the pubkey-hash function <code>pkh(P) = ripemd160(sha256(P))</code>:
+They then encode their signature, choosing either ''simple'' or ''full'' as follows:
 
-# let <code>p</code> be the pubkey-hash <code>pkh(P)</code> for the pubkey <code>P</code>, contained in <code>a</code>
-# let <code>digest</code> be <code>SHA56d(0x18||"Bitcoin Signed Message:\n"||compactint(len(m))||m)</code>
-# attempt pubkey recovery for <code>digest</code> using the signature <code>sig</code> and store the resulting pubkey into <code>Q</code>
-## fail verification if pubkey recovery above fails
-# let <code>q</code> be the pubkey-hash <code>pkh(Q)</code> for the pubkey <code>Q</code>
-# if <code>p == q</code>, the proof is valid, otherwise it is invalid
+* If they added no inputs to <code>to_sign</code>, left nSequence and nLockTime at 0, and ''A'' is a Segwit address (either pure or P2SH-wrapped), then they may base64-encode <code>message_signature</code>
+* Otherwise they must base64-encode the concatenation of <code>to_spend</code> followed by <code>to_sign</code>.
 
 == Compatibility ==
 
@@ -155,38 +159,6 @@ Thanks to David Harding, Jim Posen, Kalle Rosenbaum, Pieter Wuille, Andrew Poels
 
 This document is licensed under the Creative Commons CC0 1.0 Universal license.
 
-== Consensus and standard flags ==
-
-Each flag is associated with some type of enforced rule (most often a soft fork). There are two sets of flags: consensus flags (which result in a block being rejected, if violated), and upgradable flags (which are typically policy-rejected by nodes specifically for the purpose of future network upgrades). The upgradable flags are a super-set of the consensus flags.
-
-This BIP specifies that a proof that validates for both rulesets is valid, a proof that validates for consensus rules, but not for upgradable rules, is "inconclusive", and a proof that does not validate for consensus rules is "invalid" (regardless of upgradable rule validation).
-
-The ruleset sometimes changes. This BIP does not intend to be complete, nor does it indicate enforcement of rules, it simply lists the rules as they stand at the point of writing.
-
-=== Consensus rules ===
-
-* P2SH: evaluate P2SH ([https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki BIP16]) subscripts
-* DERSIG: enforce strict DER ([https://github.com/bitcoin/bips/blob/master/bip-0066.mediawiki BIP66]) compliance
-* NULLDUMMY: enforce NULLDUMMY ([https://github.com/bitcoin/bips/blob/master/bip-0147.mediawiki BIP147])
-* CHECKLOCKTIMEVERIFY: enable CHECKLOCKTIMEVERIFY ([https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki BIP65])
-* CHECKSEQUENCEVERIFY: enable CHECKSEQUENCEVERIFY ([https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki BIP112])
-* WITNESS: enable WITNESS ([https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki BIP141])
-
-=== Upgradable rules ===
-
-All of the above, plus (subject to change):
-
-* STRICTENC: non-strict DER signature or undefined hashtype
-* MINIMALDATA: require minimal encodings for all push operations
-* DISCOURAGE_UPGRADABLE_NOPS: discourage use of NOPs reserved for upgrades
-* CLEANSTACK: require that only a single stack element remains after evaluation
-* MINIMALIF: Segwit script only: require the argument of OP_IF/NOTIF to be exactly 0x01 or empty vector
-* NULLFAIL: signature(s) must be empty vector if a CHECK(MULTI)SIG operation failed
-* LOW_S: signature with S > order/2 in a checksig operation
-* DISCOURAGE_UPGRADABLE_WITNESS_PROGRAM: v1-16 witness programs are non-standard (i.e. forbidden)
-* WITNESS_PUBKEYTYPE: public keys in segregated witness scripts must be compressed
-* CONST_SCRIPTCODE: OP_CODESEPARATOR and FindAndDelete fail any non-segwit scripts
-
 == Test vectors ==
 
 TODO
-- 
cgit v1.2.3


From c624414119573e41466dcf407b3c53507624678f Mon Sep 17 00:00:00 2001
From: Andrew Poelstra <apoelstra@wpsoftware.net>
Date: Wed, 23 Dec 2020 15:35:47 +0000
Subject: bip-0322: remove the 'to_spend' transaction from serialization

---
 bip-0322.mediawiki | 13 ++++++-------
 1 file changed, 6 insertions(+), 7 deletions(-)

diff --git a/bip-0322.mediawiki b/bip-0322.mediawiki
index 4eda7b0..5f4704d 100644
--- a/bip-0322.mediawiki
+++ b/bip-0322.mediawiki
@@ -74,7 +74,7 @@ The <code>to_sign</code> transaction is:
     vout[0].nValue = 0
     vout[0].scriptPubKey = OP_RETURN
 
-A full signature consists of the base64-encoding of the <code>to_spend</code> and <code>to_sign</code> transactions concatenated in standard network serialisation.
+A full signature consists of the base64-encoding of the <code>to_sign</code> transaction in standard network serialisation.
 
 === Full (Proof of Funds) ===
 
@@ -102,11 +102,9 @@ A validator is given as input an address ''A'' (which may be omitted in a proof-
 Validation consists of the following steps:
 
 # Basic validation
-## Decode ''s'' as the transactions <code>to_sign</code> and <code>to_spend</code>
-## Confirm that <code>message_hash</code> is the correct hash of ''m''
-## Confirm that <code>message_challenge</code> is the scriptPubKey corresponding to ''A'' if ''A'' is present, and otherwise must be <code>OP_TRUE</code>
-## Confirm that all other fields are set as specified above; in particular that
-##* <code>to_spend</code> has exactly one input and one output
+## Compute the transaction <code>to_spend</code> from ''m'' and ''A''
+## Decode ''s'' as the transaction <code>to_sign</code>
+## If ''s'' was a full transaction, confirm all fields are set as specified above; in particular that
 ##* <code>to_sign</code> has at least one input and its first input spends the output of </code>to_spend</code>
 ##* <code>to_sign</code> has exactly one output, as specified above
 ## Confirm that the two transactions together satisfy all consensus rules, except for <code>to_spend</code>'s missing input, and except that ''nSequence'' of <code>to_sign</code>'s first input and ''nLockTime'' of <code>to_sign</code> are not checked.
@@ -120,6 +118,7 @@ Validation consists of the following steps:
 ## <code>MINIMALIF</code>: the argument of <code>IF</code>/<code>NOTIF</code> must be exactly 0x01 or empty push
 ## If any of the above steps failed, the validator should stop and output the ''invalid'' state.
 # Check the **upgradeable rules**
+## The version of <code>to_sign</code> must be 0 or 2.
 ## The use of NOPs reserved for upgrades is forbidden.
 ## The use of segwit versions greater than 0 are forbidden.
 ## If any of the above steps failed, the validator should stop and output the ''inconclusive'' state.
@@ -137,7 +136,7 @@ Signers who control an address ''A'' who wish to sign a message ''m'' act as fol
 They then encode their signature, choosing either ''simple'' or ''full'' as follows:
 
 * If they added no inputs to <code>to_sign</code>, left nSequence and nLockTime at 0, and ''A'' is a Segwit address (either pure or P2SH-wrapped), then they may base64-encode <code>message_signature</code>
-* Otherwise they must base64-encode the concatenation of <code>to_spend</code> followed by <code>to_sign</code>.
+* Otherwise they must base64-encode <code>to_sign</code>.
 
 == Compatibility ==
 
-- 
cgit v1.2.3


From e1e7b77c027b3d40d07d306cc75c2b5859c91db2 Mon Sep 17 00:00:00 2001
From: Matthew Zipkin <pinheadmz@gmail.com>
Date: Tue, 5 Jan 2021 10:10:50 -0500
Subject: BIP173: segwit address witness version is one 5-bit char not one byte

---
 bip-0173.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-0173.mediawiki b/bip-0173.mediawiki
index c3ee060..1fdd8be 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.</ref> 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.
-- 
cgit v1.2.3


From 5f18700477e2c09653591b940caa40d285a21d95 Mon Sep 17 00:00:00 2001
From: Suhas Daftuar <sdaftuar@gmail.com>
Date: Thu, 3 Sep 2020 16:51:17 -0400
Subject: p2p: Add disabletx message

This message, valid between version/verack for peers with version >= 70017,
would allow establishing at the time of connection that no transactions will be
announced/requested between those peers.
---
 bip-disable-tx.mediawiki | 100 +++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 100 insertions(+)
 create mode 100644 bip-disable-tx.mediawiki

diff --git a/bip-disable-tx.mediawiki b/bip-disable-tx.mediawiki
new file mode 100644
index 0000000..c2bca25
--- /dev/null
+++ b/bip-disable-tx.mediawiki
@@ -0,0 +1,100 @@
+<pre>
+  BIP: XXX
+  Layer: Peer Services
+  Title: Disable transaction relay message
+  Author: Suhas Daftuar <sdaftuar@chaincode.com>
+  Comments-Summary: No comments yet.
+  Comments-URI:
+  Status: Draft
+  Type: Standards Track
+  Created: 2020-09-03
+  License: BSD-2-Clause
+</pre>
+
+==Abstract==
+
+This BIP describes a change to the p2p protocol to allow a node to tell a peer
+that a connection will not be used for transaction relay, to support
+block-relay-only connections that are currently in use on the network.
+
+==Motivation==
+
+For nearly the past year, software has been deployed[1] which initiates
+connections on the Bitcoin network and sets the transaction relay field
+(introduced by BIP 37 and also defined in BIP 60) to false, to prevent
+transaction relay from occurring on the connection. Additionally, addr messages
+received from the peer are ignored by this software.
+
+The purpose of these connections is two-fold: by making additional
+low-bandwidth connections on which blocks can propagate, the robustness of a
+node to network partitioning attacks is strengthened.  Additionally, by not
+relaying transactions and ignoring received addresses, the ability of an
+adversary to learn the complete network graph (or a subgraph) is reduced[2],
+which in turn increases the cost or difficulty to an attacker seeking to carry
+out a network partitioning attack (when compared with having such knowledge).
+
+The low-bandwidth / minimal-resource nature of these connections is currently
+known only by the initiator of the connection; this is because the transaction
+relay field in the version message is not a permanent setting for the lifetime
+of the connection.  Consequently, a node receiving an inbound connection with
+transaction relay disabled cannot distinguish between a peer that will never
+enable transaction relay (as described in BIP 37) and one that will.  Moreover,
+the node also cannot determine that the incoming connection will ignore relayed
+addresses; with that knowledge a node would likely choose other peers to
+receive announced addresses instead.
+
+This proposal adds a new, optional message that a node can send a peer when
+initiating a connection to that peer, to indicate that connection should not be
+used for transaction-relay for the connection's lifetime. In addition, without
+a current mechanism to negotiate whether addresses should be relayed on a
+connection, this BIP suggests that address messages not be sent on links where
+tx-relay has been disabled.
+
+==Specification==
+
+# A new disabletx message is added, which is defined as an empty message where pchCommand == "disabletx".
+# The protocol version of nodes implementing this BIP must be set to 70017 or higher.
+# If a node sets the transaction relay field in the version message to a peer to false, then the disabletx message MAY also be sent in response to a version message from that peer if the peer's protocol version is >= 70017. If sent, the disabletx message MUST be sent prior to sending a verack.
+# A node that has sent or received a disabletx message to/from a peer MUST NOT send any of these messages to the peer:
+## inv messages for transactions
+## getdata messages for transactions
+## getdata messages for merkleblock (BIP 37)
+## filteradd/filterload/filterclear (BIP 37)
+## mempool (BIP 35)
+# It is RECOMMENDED that a node that has sent or received a disabletx message to/from a peer not send any of these messages to the peer:
+## addr/getaddr
+## addrv2 (BIP 155)
+# The behavior regarding sending or processing other message types is not specified by this BIP.
+# Nodes MAY decide to not remain connected to peers that send this message (for example, if trying to find a peer that will relay transactions).
+
+==Compatibility==
+
+Nodes with protocol version >= 70017 that do not implement this BIP, and nodes
+with protocol version < 70017, will continue to remain compatible with
+implementing software: transactions would not be relayed to peers sending the
+disabletx message (provided that BIP 37 or BIP 60 has been implemented), and while
+periodic address relay may still take place, software implementing this BIP
+should not be disconnecting such peers solely for that reason.
+
+Disabling address relay is suggested but not required by this BIP, to allow for
+future protocol extensions that might specify more carefully how address relay
+is to be negotiated. This BIP's recommendations for software to not relay
+addresses is intended to be interpreted as guidance in the absence of any such
+future protocol extension, to accommodate existing software behavior.
+
+Note that all messages specified in BIP 152, including blocktxn and
+getblocktxn, are permitted between peers that have sent/received a disabletx
+message, subject to the feature negotiation of BIP 152.
+
+==Implementation==
+
+TBD
+
+==References==
+
+# Bitcoin Core has [https://github.com/bitcoin/bitcoin/pull/15759 implemented this functionality] since version 0.19.0.1, released in November 2019.
+# For example, see https://www.cs.umd.edu/projects/coinscope/coinscope.pdf and https://arxiv.org/pdf/1812.00942.pdf.
+
+==Copyright==
+
+This BIP is licensed under the 2-clause BSD license.
-- 
cgit v1.2.3


From 644610f7b87e3e5f4757fb9e80d24f8e6e75d93e Mon Sep 17 00:00:00 2001
From: Antoine Poinsot <darosior@protonmail.com>
Date: Sun, 10 Jan 2021 12:41:05 +0100
Subject: bip-0141: clarify the sigop count calculation for CHECKMULTISIG

Since the sigOpCount calculation was copied from P2SH, and P2SH
restricts the use of CHECKMULTISIG with pushed integers the reference
implementation would not take into account the number of public keys for
17 to 20 keys (not representable with an OP_N) even for P2WSH.
Therefore it fallbacks to accounting for 20 sigops in this case, which
this sentence seemed to mismatch with.

Btcd and Libbitcoin use the same calculation as in Bitcoin Core.

Signed-off-by: Antoine Poinsot <darosior@protonmail.com>
---
 bip-0141.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-0141.mediawiki b/bip-0141.mediawiki
index 82f6abd..8528729 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 <code>witnessScript</code> are counted identically as previously within the P2SH <code>redeemScript</code>. 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 <code>witnessScript</code> are counted identically as previously within the P2SH <code>redeemScript</code>. 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 ===
 
-- 
cgit v1.2.3


From 6057fede052900d442e8fe826f789263769b002d Mon Sep 17 00:00:00 2001
From: Rusty Russell <rusty@rustcorp.com.au>
Date: Tue, 28 Jul 2020 11:33:06 +0930
Subject: BIP 174: clarify format of proprietary extensions.

"Variable length string identifier" is not defined anywhere, and the suggestion
to use "0x00" is also deeply unclear.  I assumed it meant a nul-terminated
string!

Be explicit: you mean it must be a compact siz1\e unsigned int length, followed
by that many identifier bytes, followed by a compact size unsigned int subtype,
followed by optional keydata.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
---
 bip-0174.mediawiki | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/bip-0174.mediawiki b/bip-0174.mediawiki
index c424c5d..30a2bc2 100644
--- a/bip-0174.mediawiki
+++ b/bip-0174.mediawiki
@@ -133,8 +133,8 @@ The currently defined global types are as follows:
 *** <tt>{32-bit uint}</tt>
 
 * Type: Proprietary Use Type <tt>PSBT_GLOBAL_PROPRIETARY = 0xFC</tt>
-** Key: Variable length identifier prefix, followed by a subtype, followed by the key data itself.
-*** <tt>{0xFC}|<prefix>|{subtype}|{key data}</tt>
+** Key: Compact size unsigned integer, followed by identifier prefix of that length, followed by a subtype, followed by the key data itself.
+*** <tt>{0xFC}|{prefixlen}|<prefix>|{subtype}|{key data}</tt>
 ** Value: Any value data as defined by the proprietary type user.
 *** <tt><data></tt>
 
@@ -225,8 +225,8 @@ The currently defined per-input types are defined as follows:
 *** <tt>{preimage}</tt>
 
 * Type: Proprietary Use Type <tt>PSBT_IN_PROPRIETARY = 0xFC</tt>
-** Key: Variable length identifier prefix, followed by a subtype, followed by the key data itself.
-*** <tt>{0xFC}|<prefix>|{subtype}|{key data}</tt>
+** Key: Compact size unsigned integer, followed by identifier prefix of that length, followed by a subtype, followed by the key data itself.
+*** <tt>{0xFC}|{prefixlen}|<prefix>|{subtype}|{key data}</tt>
 ** Value: Any value data as defined by the proprietary type user.
 *** <tt><data></tt>
 
@@ -253,8 +253,8 @@ determine which outputs are change outputs and verify that the change is returni
 *** <tt>{master key fingerprint}|{32-bit uint}|...|{32-bit uint}</tt>
 
 * Type: Proprietary Use Type <tt>PSBT_OUT_PROPRIETARY = 0xFC</tt>
-** Key: Variable length identifier prefix, followed by a subtype, followed by the key data itself.
-*** <tt>{0xFC}|<prefix>|{subtype}|{key data}</tt>
+** Key: Compact size unsigned integer, followed by identifier prefix of that length, followed by a subtype, followed by the key data itself.
+*** <tt>{0xFC}|{prefixlen}|<prefix>|{subtype}|{key data}</tt>
 ** Value: Any value data as defined by the proprietary type user.
 *** <tt><data></tt>
 
@@ -336,10 +336,10 @@ values are valid, then it does not matter which is chosen as either way the tran
 ===Proprietary Use Type===
 
 For all global, per-input, and per-output maps, the types <tt>0xFC</tt> is reserved for proprietary use.
-The proprietary use type requires keys that follow the type with a variable length string identifer, then a subtype.
+The proprietary use type requires keys that follow the type with a compact size unsigned integer representing the length of the string identifer, followed by the string identifier, then a subtype, and finally any key data.
 
 The identifier can be any variable length string that software can use to identify whether the particular data in the proprietary type can be used by it.
-It can also be the empty string and just be a single <tt>0x00</tt> byte although this is not recommended.
+It can also be the empty string although this is not recommended.
 
 The subtype is defined by the proprietary type user and can mean whatever they want it to mean.
 The subtype must also be a compact size unsigned integer in the same form as the normal types.
-- 
cgit v1.2.3


From 50fdf5435ebbc2e9dfb98b74b2ff4a835ef94034 Mon Sep 17 00:00:00 2001
From: Andrew Chow <achow101-github@achow101.com>
Date: Wed, 13 Jan 2021 17:09:35 -0500
Subject: Reformat BIP 174

---
 bip-0174.mediawiki | 463 ++++++++++++++++++++++++-----------------------------
 1 file changed, 212 insertions(+), 251 deletions(-)

diff --git a/bip-0174.mediawiki b/bip-0174.mediawiki
index 30a2bc2..a20432a 100644
--- a/bip-0174.mediawiki
+++ b/bip-0174.mediawiki
@@ -48,272 +48,233 @@ is the separator here <tt>0x00</tt> instead of <tt>0xff</tt>?'''
 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.</ref>.
-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: <tt><..></tt> indicates that the data is prefixed by a compact size unsigned integer representing
-the length of that data. <tt>{..}</tt> indicates the raw data itself.
 
-<pre>
-<key>|<value>
-</pre>
-
-{| 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
-|}
-
-The format of each key-value map is as follows:
-
-<pre>
-{key-value pair}|{key-value pair}|...|{0x00}
-</pre>
-
-{| 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
-| <tt>0x00</tt>
-| Must be <tt>0x00</tt> 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.
+ <psbt> := <magic> <global-map> <input-map>* <output-map>*
+ <magic> := 0x70 0x73 0x62 0x74 0xFF
+ <global-map> := <keypair>* 0x00
+ <input-map> := <keypair>* 0x00
+ <output-map> := <keypair>* 0x00
+ <keypair> := <key> <value>
+ <key> := <keylen> <keytype> <keydata>
+ <value> := <valuelen> <valuedata>
+
+Where:
+
+;<tt><keytype></tt>
+: 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. This must be unique within a specific <tt><map></tt>.
+;<tt><keylen></tt>
+: The compact size unsigned integer containing the combined length of <tt><keytype></tt> and <tt><keydata></tt>
+;<tt><valuelen></tt>
+: The compact size unsigned integer containing the length of <tt><valuedata></tt>.
+;<tt><magic></tt>
+: Magic bytes which are ASCII for psbt <ref>'''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. </ref> followed by a separator of <tt>0xFF</tt>
+<ref>'''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 <tt>0xff</tt> 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.</ref>. This integer must be serialized
+in most significant byte order.
 
 The currently defined global types are as follows:
 
-* Type: Unsigned Transaction <tt>PSBT_GLOBAL_UNSIGNED_TX = 0x00</tt>
-** Key: None. The key must only contain the 1 byte type.
-*** <tt>{0x00}</tt>
-** 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.
-*** <tt>{transaction}</tt>
-** Note: Every PSBT must have a field with this type.
-
-* Type: Extended Public Key <tt>PSBT_GLOBAL_XPUB = 0x01</tt>
-** 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.
-*** <tt>{0x01}|{xpub}</tt>
-** 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.
-*** <tt>{master key fingerprint}|{32-bit uint}|...|{32-bit uint}</tt>
-
-* Type: Version Number <tt>PSBT_GLOBAL_VERSION = 0xFB</tt>
-** Key: None. The key must only contain the 1 byte type.
-*** <tt>{0xFB}</tt>
-** Value: The 32-bit little endian unsigned integer representing the version number of this PSBT. If ommitted, the version number is 0.
-*** <tt>{32-bit uint}</tt>
-
-* Type: Proprietary Use Type <tt>PSBT_GLOBAL_PROPRIETARY = 0xFC</tt>
-** Key: Compact size unsigned integer, followed by identifier prefix of that length, followed by a subtype, followed by the key data itself.
-*** <tt>{0xFC}|{prefixlen}|<prefix>|{subtype}|{key data}</tt>
-** Value: Any value data as defined by the proprietary type user.
-*** <tt><data></tt>
+{|
+! Name
+! <tt><keytype></tt>
+! <tt><keydata></tt>
+! <tt><keydata></tt> Description
+! <tt><valuedata></tt>
+! <tt><valuedata></tt> Description
+|-
+| Unsigned Transaction
+| <tt>PSBT_GLOBAL_UNSIGNED_TX = 0x00</tt>
+| None
+| No key data
+| <tt><transaction></tt>
+| 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.
+|-
+| Extended Public Key
+| <tt>PSBT_GLOBAL_XPUB = 0x01</tt>
+| <tt><xpub></tt>
+| 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.
+| <tt><32-bit uint> <32-bit uint>*</tt>
+| 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.
+|-
+| PSBT Version Number
+| <tt>PSBT_GLOBAL_VERSION = 0xFB</tt>
+| None
+| No key data
+| <tt><32-bit uint></tt>
+| The 32-bit little endian unsigned integer representing the version number of this PSBT. If ommitted, the version number is 0.
+|-
+| Proprietary Use Type
+| <tt>PSBT_GLOBAL_PROPRIETARY = 0xFC</tt>
+| <tt><identifierlen> <identifier> <subtype> <subkeydata></tt>
+| Compact size unsigned integer <tt><identifierlen></tt>, followed by identifier prefix of that length <tt><identifer></tt>, followed by a subtype <tt><subtype></tt>, followed by the key data itself <tt><subkeydata></tt>.
+| <tt><data></tt>
+| Any value data as defined by the proprietary type user.
+|}
 
 The currently defined per-input types are defined as follows:
 
-* Type: Non-Witness UTXO <tt>PSBT_IN_NON_WITNESS_UTXO = 0x00</tt>
-** Key: None. The key must only contain the 1 byte type.
-***<tt>{0x00}</tt>
-** 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 <tt>PSBT_IN_NON_WITNESS_UTXO</tt> and <tt>PSBT_IN_WITNESS_UTXO</tt>. <ref>'''Why can both UTXO types be provided?''' Many wallets began requiring the full previous transaction (i.e. <tt>PSBT_IN_NON_WITNESS_UTXO</tt>) for segwit inputs when PSBT was already in use. In order to be compatible with software which were expecting <tt>PSBT_IN_WITNESS_UTXO</tt>, both UTXO types must be allowed.</ref>
-*** <tt>{transaction}</tt>
-
-* Type: Witness UTXO <tt>PSBT_IN_WITNESS_UTXO = 0x01</tt>
-** Key: None. The key must only contain the 1 byte type.
-*** <tt>{0x01}</tt>
-** 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 <tt>PSBT_IN_NON_WITNESS_UTXO</tt> and <tt>PSBT_IN_WITNESS_UTXO</tt>
-*** <tt>{serialized transaction output({output value}|<scriptPubKey>)}</tt>
-
-* Type: Partial Signature <tt>PSBT_IN_PARTIAL_SIG = 0x02</tt>
-** Key: The public key which corresponds to this signature.
-*** <tt>{0x02}|{public key}</tt>
-** Value: The signature as would be pushed to the stack from a scriptSig or witness.
-*** <tt>{signature}</tt>
-
-* Type: Sighash Type <tt>PSBT_IN_SIGHASH_TYPE = 0x03</tt>
-** Key: None. The key must only contain the 1 byte type.
-*** <tt>{0x03}</tt>
-** 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.
-*** <tt>{sighash type}</tt>
-
-* Type: Redeem Script <tt>PSBT_IN_REDEEM_SCRIPT = 0x04</tt>
-** Key: None. The key must only contain the 1 byte type.
-*** <tt>{0x04}</tt>
-** Value: The redeemScript for this input if it has one.
-*** <tt>{redeemScript}</tt>
-
-* Type: Witness Script <tt>PSBT_IN_WITNESS_SCRIPT = 0x05</tt>
-** Key: None. The key must only contain the 1 byte type.
-*** <tt>{0x05}</tt>
-** Value: The witnessScript for this input if it has one.
-*** <tt>{witnessScript}</tt>
-
-* Type:  BIP 32 Derivation Path <tt>PSBT_IN_BIP32_DERIVATION = 0x06</tt>
-** Key: The public key
-*** <tt>{0x06}|{public key}</tt>
-** 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.
-*** <tt>{master key fingerprint}|{32-bit uint}|...|{32-bit uint}</tt>
-
-* Type: Finalized scriptSig <tt>PSBT_IN_FINAL_SCRIPTSIG = 0x07</tt>
-** Key: None. The key must only contain the 1 byte type.
-*** <tt>{0x07}</tt>
-** Value: The Finalized scriptSig contains a fully constructed scriptSig with signatures and any other scripts necessary for the input to pass validation.
-*** <tt>{scriptSig}</tt>
-
-* Type: Finalized scriptWitness <tt>PSBT_IN_FINAL_SCRIPTWITNESS = 0x08</tt>
-** Key: None. The key must only contain the 1 byte type.
-*** <tt>{0x08}</tt>
-** Value: The Finalized scriptWitness contains a fully constructed scriptWitness with signatures and any other scripts necessary for the input to pass validation.
-*** <tt>{scriptWitness}</tt>
-
-* Type: Proof-of-reserves commitment <tt>PSBT_IN_POR_COMMITMENT = 0x09</tt>
-** Key: None. The key must only contain the 1 byte type.
-*** <tt>{0x09}</tt>
-** Value: The UTF-8 encoded commitment message string for the proof-of-reserves.  See [[bip-0127.mediawiki|BIP 127]] for more information.
-*** <tt>{porCommitment}</tt>
-
-* Type: RIPEMD160 preimage <tt>PSBT_IN_RIPEMD160 = 0x0a</tt>
-** Key: The resulting hash of the preimage
-*** <tt>{0x0a}|{20-byte hash}</tt>
-** Value: The hash preimage, encoded as a byte vector, which must equal the key when run through the `RIPEMD160` algorithm
-*** <tt>{preimage}</tt>
-
-* Type: SHA256 preimage <tt>PSBT_IN_SHA256 = 0x0b</tt>
-** Key: The resulting hash of the preimage
-*** <tt>{0x0b}|{32-byte hash}</tt>
-** Value: The hash preimage, encoded as a byte vector, which must equal the key when run through the `SHA256` algorithm
-*** <tt>{preimage}</tt>
-
-* Type: HASH160 preimage <tt>PSBT_IN_HASH160 = 0x0c</tt>
-** Key: The resulting hash of the preimage
-*** <tt>{0x0c}|{20-byte hash}</tt>
-** 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
-*** <tt>{preimage}</tt>
-
-* Type: HASH256 preimage <tt>PSBT_IN_HASH256 = 0x0d</tt>
-** Key: The resulting hash of the preimage
-*** <tt>{0x0d}|{32-byte hash}</tt>
-** Value: The hash preimage, encoded as a byte vector, which must equal the key when run through the `SHA256` algorithm twice
-*** <tt>{preimage}</tt>
-
-* Type: Proprietary Use Type <tt>PSBT_IN_PROPRIETARY = 0xFC</tt>
-** Key: Compact size unsigned integer, followed by identifier prefix of that length, followed by a subtype, followed by the key data itself.
-*** <tt>{0xFC}|{prefixlen}|<prefix>|{subtype}|{key data}</tt>
-** Value: Any value data as defined by the proprietary type user.
-*** <tt><data></tt>
+{|
+! Name
+! <tt><keytype></tt>
+! <tt><keydata></tt>
+! <tt><keydata></tt> Description
+! <tt><valuedata></tt>
+! <tt><valuedata></tt> Description
+|-
+| Non-Witness UTXO
+| <tt>PSBT_IN_NON_WITNESS_UTXO = 0x00</tt>
+| None
+| No key data
+| <tt><transaction></tt>
+| 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 <tt>PSBT_IN_NON_WITNESS_UTXO</tt> and <tt>PSBT_IN_WITNESS_UTXO</tt>. <ref>'''Why can both UTXO types be provided?''' Many wallets began requiring the full previous transaction (i.e. <tt>PSBT_IN_NON_WITNESS_UTXO</tt>) for segwit inputs when PSBT was already in use. In order to be compatible with software which were expecting <tt>PSBT_IN_WITNESS_UTXO</tt>, both UTXO types must be allowed.</ref>
+|-
+| Witness UTXO
+| <tt>PSBT_IN_WITNESS_UTXO = 0x01</tt>
+| None
+| No key data
+| <tt><64-bit uint> <scriptPubKeylen> <scriptPubKey></tt>
+| 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 <tt>PSBT_IN_NON_WITNESS_UTXO</tt> and <tt>PSBT_IN_WITNESS_UTXO</tt>
+|-
+| Partial Signature
+| <tt>PSBT_IN_PARTIAL_SIG = 0x02</tt>
+| <tt><pubkey></tt>
+| The public key which corresponds to this signature.
+| <tt><signature></tt>
+| The signature as would be pushed to the stack from a scriptSig or witness.
+|-
+| Sighash Type
+| <tt>PSBT_IN_SIGHASH_TYPE = 0x03</tt>
+| None
+| No key data
+| <tt><32-bit uint></tt>
+| 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.
+|-
+| Redeem Script
+| <tt>PSBT_IN_REDEEM_SCRIPT = 0x04</tt>
+| None
+| No key data
+| <tt><redeemScript></tt>
+| The redeemScript for this input if it has one.
+|-
+| Witness Script
+| <tt>PSBT_IN_WITNESS_SCRIPT = 0x05</tt>
+| None
+| No key data
+| <tt><witnessScript></tt>
+| The witnessScript for this input if it has one.
+|-
+| BIP 32 Derivation Path
+| <tt>PSBT_IN_BIP32_DERIVATION = 0x06</tt>
+| <tt><pubkey></tt>
+| The public key
+| <tt><32-bit uint> <32-bit uint>*</tt>
+| 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.
+|-
+| Finalized scriptSig
+| <tt>PSBT_IN_FINAL_SCRIPTSIG = 0x07</tt>
+| None
+| No key data
+| <tt><scriptSig></tt>
+| The Finalized scriptSig contains a fully constructed scriptSig with signatures and any other scripts necessary for the input to pass validation.
+|-
+| Finalized scriptWitness
+| <tt>PSBT_IN_FINAL_SCRIPTWITNESS = 0x08</tt>
+| None
+| No key data
+| <tt><scriptWitness></tt>
+| The Finalized scriptWitness contains a fully constructed scriptWitness with signatures and any other scripts necessary for the input to pass validation.
+|-
+| Proof-of-reserves commitment
+| <tt>PSBT_IN_POR_COMMITMENT = 0x09</tt>
+| None
+| No key data
+| <tt><porCommitment></tt>
+| The UTF-8 encoded commitment message string for the proof-of-reserves.  See [[bip-0127.mediawiki|BIP 127]] for more information.
+|-
+| RIPEMD160 preimage
+| <tt>PSBT_IN_RIPEMD160 = 0x0a</tt>
+| <tt><20-byte hash></tt>
+| The resulting hash of the preimage
+| <tt><preimage></tt>
+| The hash preimage, encoded as a byte vector, which must equal the key when run through the <tt>RIPEMD160</tt> algorithm
+|-
+| SHA256 preimage
+| <tt>PSBT_IN_SHA256 = 0x0b</tt>
+| <tt><32-byte hash></tt>
+| The resulting hash of the preimage
+| <tt><preimage></tt>
+| The hash preimage, encoded as a byte vector, which must equal the key when run through the <tt>SHA256</tt> algorithm
+|-
+| HASH160 preimage
+| <tt>PSBT_IN_HASH160 = 0x0c</tt>
+| <tt><20-byte hash></tt>
+| The resulting hash of the preimage
+| <tt><preimage></tt>
+| The hash preimage, encoded as a byte vector, which must equal the key when run through the <tt>SHA256</tt> algorithm followed by the <tt>RIPEMD160</tt> algorithm
+|-
+| HASH256 preimage
+| <tt>PSBT_IN_HASH256 = 0x0d</tt>
+| <tt><32-byte hash></tt>
+| The resulting hash of the preimage
+| <tt><preimage></tt>
+| The hash preimage, encoded as a byte vector, which must equal the key when run through the <tt>SHA256</tt> algorithm twice
+|-
+| Proprietary Use Type
+| <tt>PSBT_IN_PROPRIETARY = 0xFC</tt>
+| <tt><identifierlen> <identifier> <subtype> <subkeydata></tt>
+| Compact size unsigned integer <tt><identifierlen></tt>, followed by identifier prefix of that length <tt><identifer></tt>, followed by a subtype <tt><subtype></tt>, followed by the key data itself <tt><subkeydata></tt>.
+| <tt><data></tt>
+| Any value data as defined by the proprietary type user.
+|}
 
 The currently defined per-output <ref>'''Why do we need per-output data?''' Per-output data allows signers
 to verify that the outputs are going to the intended recipient. The output data can also be use by signers to
 determine which outputs are change outputs and verify that the change is returning to the correct place.</ref> types are defined as follows:
 
-* Type: Redeem Script <tt>PSBT_OUT_REDEEM_SCRIPT = 0x00</tt>
-** Key: None. The key must only contain the 1 byte type.
-*** <tt>{0x00}</tt>
-** Value: The redeemScript for this output if it has one.
-*** <tt>{redeemScript}</tt>
-
-* Type: Witness Script <tt>PSBT_OUT_WITNESS_SCRIPT = 0x01</tt>
-** Key: None. The key must only contain the 1 byte type.
-*** <tt>{0x01}</tt>
-** Value: The witnessScript for this output if it has one.
-*** <tt>{witnessScript}</tt>
-
-* Type:  BIP 32 Derivation Path <tt>PSBT_OUT_BIP32_DERIVATION = 0x02</tt>
-** Key: The public key
-*** <tt>{0x02}|{public key}</tt>
-** Value: The master key fingerprint 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. Public keys are those needed to spend this output.
-*** <tt>{master key fingerprint}|{32-bit uint}|...|{32-bit uint}</tt>
-
-* Type: Proprietary Use Type <tt>PSBT_OUT_PROPRIETARY = 0xFC</tt>
-** Key: Compact size unsigned integer, followed by identifier prefix of that length, followed by a subtype, followed by the key data itself.
-*** <tt>{0xFC}|{prefixlen}|<prefix>|{subtype}|{key data}</tt>
-** Value: Any value data as defined by the proprietary type user.
-*** <tt><data></tt>
-
-The transaction format is specified as follows:
-
-
-<pre>
-    {0x70736274}|{0xff}|{global key-value map}|{input key-value map}|...|{input key-value map}|{output key-value map}|...|{output key-value map}|
-</pre>
-
-{| class="wikitable" style="width: auto; text-align: center; font-size: smaller; table-layout: fixed;"
-!Field Size
-!Name
-!Type
-!Value
-!Description
-|-
-| 4
-| Magic Bytes
-| int32_t
-| <tt>0x70736274</tt>
-| Magic bytes which are ASCII for psbt. <ref>'''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. </ref> This integer should be serialized
-in most significant byte order.
-|-
-| 1
-| separator
-| char
-| <tt>0xff</tt>
-| Must be <tt>0xff</tt> <ref>'''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 <tt>0xff</tt> 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.</ref>
-|-
-| 1+
-| Global data
-| Key-value Map
-| varies
-| The key-value pairs for all global data.
-|-
-| 1+
-| Inputs
-| Array of key-value maps
-| varies
-| The key-value pairs for each input as described above. Every input in the unsigned transaction must have a corresponding input map.
-|-
-| 1+
-| Outputs
-| Array of key-value maps
-| varies
-| The key-value pairs for each output as described above. Every output in the unsigned transaction must have a corresponding output map.
+{|
+! Name
+! <tt><keytype></tt>
+! <tt><keydata></tt>
+! <tt><keydata></tt> Description
+! <tt><valuedata></tt>
+! <tt><valuedata></tt> Description
+|-
+| Redeem Script
+| <tt>PSBT_OUT_REDEEM_SCRIPT = 0x00</tt>
+| None
+| No key data
+| <tt><redeemScript></tt>
+| The redeemScript for this output if it has one.
+|-
+| Witness Script
+| <tt>PSBT_OUT_WITNESS_SCRIPT = 0x01</tt>
+| None
+| No key data
+| <tt><witnessScript></tt>
+| The witnessScript for this output if it has one.
+|-
+| BIP 32 Derivation Path
+| <tt>PSBT_OUT_BIP32_DERIVATION = 0x02</tt>
+| <tt><public key></tt>
+| The public key
+| <tt><{32-bit uint> <32-bit uint>*</tt>
+| The master key fingerprint 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. Public keys are those needed to spend this output.
+|-
+| Proprietary Use Type
+| <tt>PSBT_OUT_PROPRIETARY = 0xFC</tt>
+| <tt><identifierlen> <identifier> <subtype> <subkeydata></tt>
+| Compact size unsigned integer <tt><identifierlen></tt>, followed by identifier prefix of that length <tt><identifer></tt>, followed by a subtype <tt><subtype></tt>, followed by the key data itself <tt><subkeydata></tt>.
+| <tt><data></tt>
+| Any value data as defined by the proprietary type user.
 |}
 
-Each block of data between separators can be viewed as a scope, and all separators
-are required<ref>'''Why are all separators required?''' The separators are required
-so that the unserializer knows which input it is unserializing data for.</ref>.
 Types can be skipped when they are unnecessary. For example, if an input is a witness
 input, then it should not have a Non-Witness UTXO key-value pair.
 
-- 
cgit v1.2.3


From c0991047e25a35d1ddf241f304a079e9893eed69 Mon Sep 17 00:00:00 2001
From: Andrew Chow <achow101-github@achow101.com>
Date: Thu, 14 Jan 2021 13:31:15 -0500
Subject: Explicitly specify PSBTv0

---
 README.mediawiki      |  2 +-
 bip-0174.mediawiki    | 13 +++++++++++--
 scripts/buildtable.pl |  2 +-
 3 files changed, 13 insertions(+), 4 deletions(-)

diff --git a/README.mediawiki b/README.mediawiki
index 83120ab..e9fe705 100644
--- a/README.mediawiki
+++ b/README.mediawiki
@@ -850,7 +850,7 @@ Those proposing changes should consider that ultimately consent may rest with th
 |- style="background-color: #ffffcf"
 | [[bip-0174.mediawiki|174]]
 | Applications
-| Partially Signed Bitcoin Transaction Format
+| Partially Signed Bitcoin Transaction Format and Version 0
 | Andrew Chow
 | Standard
 | Proposed
diff --git a/bip-0174.mediawiki b/bip-0174.mediawiki
index a20432a..a1beaef 100644
--- a/bip-0174.mediawiki
+++ b/bip-0174.mediawiki
@@ -1,7 +1,7 @@
 <pre>
   BIP: 174
   Layer: Applications
-  Title: Partially Signed Bitcoin Transaction Format
+  Title: Partially Signed Bitcoin Transaction Format and Version 0
   Author: Andrew Chow <achow101@gmail.com>
   Comments-Summary: No comments yet.
   Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0174
@@ -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.
@@ -94,7 +97,7 @@ The currently defined global types are as follows:
 | None
 | No key data
 | <tt><transaction></tt>
-| 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.
+| 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).
 |-
 | Extended Public Key
 | <tt>PSBT_GLOBAL_XPUB = 0x01</tt>
@@ -311,6 +314,12 @@ It is useful when there are additional data that they need attached to a PSBT bu
 The proprietary use type is not to be used by any public specification and there is no expectation that any publicly available software be able to understand any specific meanings of it and the subtypes.
 This type must be used for internal processes only.
 
+==Version 0==
+
+Partially Signed Bitcoin Transactions version 0 is the first version of the PSBT format.
+Version 0 PSBTs must either omit PSBT_GLOBAL_VERSION or include it and set it to 0.
+Version 0 PSBTs must include PSBT_GLOBAL_UNSIGNED_TX, if omitted, the PSBT is invalid.
+
 ==Roles==
 
 Using the transaction format involves many different roles. Multiple roles can be handled by a single entity, but each role is specialized in what it should be capable of doing.
diff --git a/scripts/buildtable.pl b/scripts/buildtable.pl
index 1edd8c0..ed71f7c 100755
--- a/scripts/buildtable.pl
+++ b/scripts/buildtable.pl
@@ -89,7 +89,7 @@ my %DefinedLicenses = (
 );
 my %GrandfatheredPD = map { $_ => undef } qw(9 36 37 38 42 49 50 60 65 67 69 74 80 81 83 90 99 105 107 109 111 112 113 114 122 124 125 126 130 131 132 133 140 141 142 143 144 146 147 150 151 152);
 my %TolerateMissingLicense = map { $_ => undef } qw(1 10 11 12 13 14 15 16 21 31 33 34 35 39 43 44 45 47 61 64 68 70 71 72 73 101 102 106 120 121);
-my %TolerateTitleTooLong = map { $_ => undef } qw(39 44 45 47 49 60 67 68 69 73 74 75 80 81 99 105 106 109 113 122 126 131 143 145 147 173);
+my %TolerateTitleTooLong = map { $_ => undef } qw(39 44 45 47 49 60 67 68 69 73 74 75 80 81 99 105 106 109 113 122 126 131 143 145 147 173 174);
 
 my %emails;
 
-- 
cgit v1.2.3


From a4fb1b9de0997ef5f47cca6e684353a89ad0b440 Mon Sep 17 00:00:00 2001
From: Andrew Chow <achow101-github@achow101.com>
Date: Thu, 14 Jan 2021 13:50:00 -0500
Subject: Specify procedure for new fields and versions

---
 bip-0174.mediawiki | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/bip-0174.mediawiki b/bip-0174.mediawiki
index a1beaef..3ea95d5 100644
--- a/bip-0174.mediawiki
+++ b/bip-0174.mediawiki
@@ -479,6 +479,18 @@ Updaters and combiners that need to add a version number to a PSBT should use th
 For example, if a combiner sees two PSBTs for the same transaction, one with version 0, and the other with version 1, then it should combine them and produce a PSBT with version 1.
 If an updater is updating a PSBT and needs to add a field that is only available in version 1, then it should set the PSBT version number to 1 unless a version higher than that is already specified.
 
+===Procedure For New Fields===
+
+New fields should first be proposed on the bitcoin-dev mailing list.
+If a field requires significatn description as to its usage, it should be accompanied by a separate BIP.
+The field must be added to the field listing tables in the Specification section.
+
+===Procedure For New Versions===
+
+New PSBT versions must be described in a separate BIP.
+The BIP may reference this BIP and any components of PSBT version 0 that are retained in the new version.
+Any new fields described in the new version must be added to the field listing tables in the Specification section.
+
 ==Compatibility==
 
 This transaction format is designed so that it is unable to be properly unserialized
-- 
cgit v1.2.3


From 80df41818ecbd2a16f351513da8e33e0ac17a4fd Mon Sep 17 00:00:00 2001
From: Andrew Chow <achow101-github@achow101.com>
Date: Thu, 14 Jan 2021 13:52:07 -0500
Subject: Include PSBT versions that can or must include field

---
 bip-0174.mediawiki | 78 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 78 insertions(+)

diff --git a/bip-0174.mediawiki b/bip-0174.mediawiki
index 3ea95d5..9e1de13 100644
--- a/bip-0174.mediawiki
+++ b/bip-0174.mediawiki
@@ -91,6 +91,9 @@ The currently defined global types are as follows:
 ! <tt><keydata></tt> Description
 ! <tt><valuedata></tt>
 ! <tt><valuedata></tt> Description
+! Versions Requiring Inclusion
+! Versions Requiring Exclusion
+! Versions Allowing Inclusion
 |-
 | Unsigned Transaction
 | <tt>PSBT_GLOBAL_UNSIGNED_TX = 0x00</tt>
@@ -98,6 +101,9 @@ The currently defined global types are as follows:
 | No key data
 | <tt><transaction></tt>
 | 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
 |-
 | Extended Public Key
 | <tt>PSBT_GLOBAL_XPUB = 0x01</tt>
@@ -105,6 +111,9 @@ The currently defined global types are as follows:
 | 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.
 | <tt><32-bit uint> <32-bit uint>*</tt>
 | 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
 |-
 | PSBT Version Number
 | <tt>PSBT_GLOBAL_VERSION = 0xFB</tt>
@@ -112,6 +121,9 @@ The currently defined global types are as follows:
 | No key data
 | <tt><32-bit uint></tt>
 | The 32-bit little endian unsigned integer representing the version number of this PSBT. If ommitted, the version number is 0.
+|
+|
+| 0
 |-
 | Proprietary Use Type
 | <tt>PSBT_GLOBAL_PROPRIETARY = 0xFC</tt>
@@ -119,6 +131,9 @@ The currently defined global types are as follows:
 | Compact size unsigned integer <tt><identifierlen></tt>, followed by identifier prefix of that length <tt><identifer></tt>, followed by a subtype <tt><subtype></tt>, followed by the key data itself <tt><subkeydata></tt>.
 | <tt><data></tt>
 | Any value data as defined by the proprietary type user.
+|
+|
+| 0
 |}
 
 The currently defined per-input types are defined as follows:
@@ -130,6 +145,9 @@ The currently defined per-input types are defined as follows:
 ! <tt><keydata></tt> Description
 ! <tt><valuedata></tt>
 ! <tt><valuedata></tt> Description
+! Versions Requiring Inclusion
+! Versions Requiring Exclusion
+! Versions Allowing Inclusion
 |-
 | Non-Witness UTXO
 | <tt>PSBT_IN_NON_WITNESS_UTXO = 0x00</tt>
@@ -137,6 +155,9 @@ The currently defined per-input types are defined as follows:
 | No key data
 | <tt><transaction></tt>
 | 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 <tt>PSBT_IN_NON_WITNESS_UTXO</tt> and <tt>PSBT_IN_WITNESS_UTXO</tt>. <ref>'''Why can both UTXO types be provided?''' Many wallets began requiring the full previous transaction (i.e. <tt>PSBT_IN_NON_WITNESS_UTXO</tt>) for segwit inputs when PSBT was already in use. In order to be compatible with software which were expecting <tt>PSBT_IN_WITNESS_UTXO</tt>, both UTXO types must be allowed.</ref>
+|
+|
+| 0
 |-
 | Witness UTXO
 | <tt>PSBT_IN_WITNESS_UTXO = 0x01</tt>
@@ -144,6 +165,9 @@ The currently defined per-input types are defined as follows:
 | No key data
 | <tt><64-bit uint> <scriptPubKeylen> <scriptPubKey></tt>
 | 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 <tt>PSBT_IN_NON_WITNESS_UTXO</tt> and <tt>PSBT_IN_WITNESS_UTXO</tt>
+|
+|
+| 0
 |-
 | Partial Signature
 | <tt>PSBT_IN_PARTIAL_SIG = 0x02</tt>
@@ -151,6 +175,9 @@ The currently defined per-input types are defined as follows:
 | The public key which corresponds to this signature.
 | <tt><signature></tt>
 | The signature as would be pushed to the stack from a scriptSig or witness.
+|
+|
+| 0
 |-
 | Sighash Type
 | <tt>PSBT_IN_SIGHASH_TYPE = 0x03</tt>
@@ -158,6 +185,9 @@ The currently defined per-input types are defined as follows:
 | No key data
 | <tt><32-bit uint></tt>
 | 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
 |-
 | Redeem Script
 | <tt>PSBT_IN_REDEEM_SCRIPT = 0x04</tt>
@@ -165,6 +195,9 @@ The currently defined per-input types are defined as follows:
 | No key data
 | <tt><redeemScript></tt>
 | The redeemScript for this input if it has one.
+|
+|
+| 0
 |-
 | Witness Script
 | <tt>PSBT_IN_WITNESS_SCRIPT = 0x05</tt>
@@ -172,6 +205,9 @@ The currently defined per-input types are defined as follows:
 | No key data
 | <tt><witnessScript></tt>
 | The witnessScript for this input if it has one.
+|
+|
+| 0
 |-
 | BIP 32 Derivation Path
 | <tt>PSBT_IN_BIP32_DERIVATION = 0x06</tt>
@@ -179,6 +215,9 @@ The currently defined per-input types are defined as follows:
 | The public key
 | <tt><32-bit uint> <32-bit uint>*</tt>
 | 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
 |-
 | Finalized scriptSig
 | <tt>PSBT_IN_FINAL_SCRIPTSIG = 0x07</tt>
@@ -186,6 +225,9 @@ The currently defined per-input types are defined as follows:
 | No key data
 | <tt><scriptSig></tt>
 | The Finalized scriptSig contains a fully constructed scriptSig with signatures and any other scripts necessary for the input to pass validation.
+|
+|
+| 0
 |-
 | Finalized scriptWitness
 | <tt>PSBT_IN_FINAL_SCRIPTWITNESS = 0x08</tt>
@@ -193,6 +235,9 @@ The currently defined per-input types are defined as follows:
 | No key data
 | <tt><scriptWitness></tt>
 | The Finalized scriptWitness contains a fully constructed scriptWitness with signatures and any other scripts necessary for the input to pass validation.
+|
+|
+| 0
 |-
 | Proof-of-reserves commitment
 | <tt>PSBT_IN_POR_COMMITMENT = 0x09</tt>
@@ -200,6 +245,9 @@ The currently defined per-input types are defined as follows:
 | No key data
 | <tt><porCommitment></tt>
 | The UTF-8 encoded commitment message string for the proof-of-reserves.  See [[bip-0127.mediawiki|BIP 127]] for more information.
+|
+|
+| 0
 |-
 | RIPEMD160 preimage
 | <tt>PSBT_IN_RIPEMD160 = 0x0a</tt>
@@ -207,6 +255,9 @@ The currently defined per-input types are defined as follows:
 | The resulting hash of the preimage
 | <tt><preimage></tt>
 | The hash preimage, encoded as a byte vector, which must equal the key when run through the <tt>RIPEMD160</tt> algorithm
+|
+|
+| 0
 |-
 | SHA256 preimage
 | <tt>PSBT_IN_SHA256 = 0x0b</tt>
@@ -214,6 +265,9 @@ The currently defined per-input types are defined as follows:
 | The resulting hash of the preimage
 | <tt><preimage></tt>
 | The hash preimage, encoded as a byte vector, which must equal the key when run through the <tt>SHA256</tt> algorithm
+|
+|
+| 0
 |-
 | HASH160 preimage
 | <tt>PSBT_IN_HASH160 = 0x0c</tt>
@@ -221,6 +275,9 @@ The currently defined per-input types are defined as follows:
 | The resulting hash of the preimage
 | <tt><preimage></tt>
 | The hash preimage, encoded as a byte vector, which must equal the key when run through the <tt>SHA256</tt> algorithm followed by the <tt>RIPEMD160</tt> algorithm
+|
+|
+| 0
 |-
 | HASH256 preimage
 | <tt>PSBT_IN_HASH256 = 0x0d</tt>
@@ -228,6 +285,9 @@ The currently defined per-input types are defined as follows:
 | The resulting hash of the preimage
 | <tt><preimage></tt>
 | The hash preimage, encoded as a byte vector, which must equal the key when run through the <tt>SHA256</tt> algorithm twice
+|
+|
+| 0
 |-
 | Proprietary Use Type
 | <tt>PSBT_IN_PROPRIETARY = 0xFC</tt>
@@ -235,6 +295,9 @@ The currently defined per-input types are defined as follows:
 | Compact size unsigned integer <tt><identifierlen></tt>, followed by identifier prefix of that length <tt><identifer></tt>, followed by a subtype <tt><subtype></tt>, followed by the key data itself <tt><subkeydata></tt>.
 | <tt><data></tt>
 | Any value data as defined by the proprietary type user.
+|
+|
+| 0
 |}
 
 The currently defined per-output <ref>'''Why do we need per-output data?''' Per-output data allows signers
@@ -248,6 +311,9 @@ determine which outputs are change outputs and verify that the change is returni
 ! <tt><keydata></tt> Description
 ! <tt><valuedata></tt>
 ! <tt><valuedata></tt> Description
+! Versions Requiring Inclusion
+! Versions Requiring Exclusion
+! Versions Allowing Inclusion
 |-
 | Redeem Script
 | <tt>PSBT_OUT_REDEEM_SCRIPT = 0x00</tt>
@@ -255,6 +321,9 @@ determine which outputs are change outputs and verify that the change is returni
 | No key data
 | <tt><redeemScript></tt>
 | The redeemScript for this output if it has one.
+|
+|
+| 0
 |-
 | Witness Script
 | <tt>PSBT_OUT_WITNESS_SCRIPT = 0x01</tt>
@@ -262,6 +331,9 @@ determine which outputs are change outputs and verify that the change is returni
 | No key data
 | <tt><witnessScript></tt>
 | The witnessScript for this output if it has one.
+|
+|
+| 0
 |-
 | BIP 32 Derivation Path
 | <tt>PSBT_OUT_BIP32_DERIVATION = 0x02</tt>
@@ -269,6 +341,9 @@ determine which outputs are change outputs and verify that the change is returni
 | The public key
 | <tt><{32-bit uint> <32-bit uint>*</tt>
 | The master key fingerprint 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. Public keys are those needed to spend this output.
+|
+|
+| 0
 |-
 | Proprietary Use Type
 | <tt>PSBT_OUT_PROPRIETARY = 0xFC</tt>
@@ -276,6 +351,9 @@ determine which outputs are change outputs and verify that the change is returni
 | Compact size unsigned integer <tt><identifierlen></tt>, followed by identifier prefix of that length <tt><identifer></tt>, followed by a subtype <tt><subtype></tt>, followed by the key data itself <tt><subkeydata></tt>.
 | <tt><data></tt>
 | Any value data as defined by the proprietary type user.
+|
+|
+| 0
 |}
 
 Types can be skipped when they are unnecessary. For example, if an input is a witness
-- 
cgit v1.2.3


From c27d5e8b9643a478ed7b6fd4e7cda15238f418fe Mon Sep 17 00:00:00 2001
From: Andrew Chow <achow101-github@achow101.com>
Date: Thu, 14 Jan 2021 14:38:36 -0500
Subject: Mark BIP 174 as final

---
 README.mediawiki   | 4 ++--
 bip-0174.mediawiki | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/README.mediawiki b/README.mediawiki
index e9fe705..f77ce56 100644
--- a/README.mediawiki
+++ b/README.mediawiki
@@ -847,13 +847,13 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Pieter Wuille, Greg Maxwell
 | Informational
 | Final
-|- style="background-color: #ffffcf"
+|- style="background-color: #cfffcf"
 | [[bip-0174.mediawiki|174]]
 | Applications
 | Partially Signed Bitcoin Transaction Format and Version 0
 | Andrew Chow
 | Standard
-| Proposed
+| Final
 |-
 | [[bip-0175.mediawiki|175]]
 | Applications
diff --git a/bip-0174.mediawiki b/bip-0174.mediawiki
index 9e1de13..303c001 100644
--- a/bip-0174.mediawiki
+++ b/bip-0174.mediawiki
@@ -5,7 +5,7 @@
   Author: Andrew Chow <achow101@gmail.com>
   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
-- 
cgit v1.2.3


From 88fb2052647f5f7a73127dad7ad6f4d46149cf79 Mon Sep 17 00:00:00 2001
From: Andrew Chow <achow101-github@achow101.com>
Date: Thu, 14 Jan 2021 16:09:52 -0500
Subject: Combine Appendix with field listing tables

---
 bip-0174.mediawiki | 152 +++++++++--------------------------------------------
 1 file changed, 26 insertions(+), 126 deletions(-)

diff --git a/bip-0174.mediawiki b/bip-0174.mediawiki
index 303c001..81958fd 100644
--- a/bip-0174.mediawiki
+++ b/bip-0174.mediawiki
@@ -94,6 +94,7 @@ The currently defined global types are as follows:
 ! Versions Requiring Inclusion
 ! Versions Requiring Exclusion
 ! Versions Allowing Inclusion
+! Parent BIP
 |-
 | Unsigned Transaction
 | <tt>PSBT_GLOBAL_UNSIGNED_TX = 0x00</tt>
@@ -104,6 +105,7 @@ The currently defined global types are as follows:
 | 0
 |
 | 0
+| 174
 |-
 | Extended Public Key
 | <tt>PSBT_GLOBAL_XPUB = 0x01</tt>
@@ -114,6 +116,7 @@ The currently defined global types are as follows:
 |
 |
 | 0
+| 174
 |-
 | PSBT Version Number
 | <tt>PSBT_GLOBAL_VERSION = 0xFB</tt>
@@ -124,6 +127,7 @@ The currently defined global types are as follows:
 |
 |
 | 0
+| 174
 |-
 | Proprietary Use Type
 | <tt>PSBT_GLOBAL_PROPRIETARY = 0xFC</tt>
@@ -134,6 +138,7 @@ The currently defined global types are as follows:
 |
 |
 | 0
+| 174
 |}
 
 The currently defined per-input types are defined as follows:
@@ -148,6 +153,7 @@ The currently defined per-input types are defined as follows:
 ! Versions Requiring Inclusion
 ! Versions Requiring Exclusion
 ! Versions Allowing Inclusion
+! Parent BIP
 |-
 | Non-Witness UTXO
 | <tt>PSBT_IN_NON_WITNESS_UTXO = 0x00</tt>
@@ -158,6 +164,7 @@ The currently defined per-input types are defined as follows:
 |
 |
 | 0
+| 174
 |-
 | Witness UTXO
 | <tt>PSBT_IN_WITNESS_UTXO = 0x01</tt>
@@ -168,6 +175,7 @@ The currently defined per-input types are defined as follows:
 |
 |
 | 0
+| 174
 |-
 | Partial Signature
 | <tt>PSBT_IN_PARTIAL_SIG = 0x02</tt>
@@ -178,6 +186,7 @@ The currently defined per-input types are defined as follows:
 |
 |
 | 0
+| 174
 |-
 | Sighash Type
 | <tt>PSBT_IN_SIGHASH_TYPE = 0x03</tt>
@@ -188,6 +197,7 @@ The currently defined per-input types are defined as follows:
 |
 |
 | 0
+| 174
 |-
 | Redeem Script
 | <tt>PSBT_IN_REDEEM_SCRIPT = 0x04</tt>
@@ -198,6 +208,7 @@ The currently defined per-input types are defined as follows:
 |
 |
 | 0
+| 174
 |-
 | Witness Script
 | <tt>PSBT_IN_WITNESS_SCRIPT = 0x05</tt>
@@ -208,6 +219,7 @@ The currently defined per-input types are defined as follows:
 |
 |
 | 0
+| 174
 |-
 | BIP 32 Derivation Path
 | <tt>PSBT_IN_BIP32_DERIVATION = 0x06</tt>
@@ -218,6 +230,7 @@ The currently defined per-input types are defined as follows:
 |
 |
 | 0
+| 174
 |-
 | Finalized scriptSig
 | <tt>PSBT_IN_FINAL_SCRIPTSIG = 0x07</tt>
@@ -228,6 +241,7 @@ The currently defined per-input types are defined as follows:
 |
 |
 | 0
+| 174
 |-
 | Finalized scriptWitness
 | <tt>PSBT_IN_FINAL_SCRIPTWITNESS = 0x08</tt>
@@ -238,6 +252,7 @@ The currently defined per-input types are defined as follows:
 |
 |
 | 0
+| 174
 |-
 | Proof-of-reserves commitment
 | <tt>PSBT_IN_POR_COMMITMENT = 0x09</tt>
@@ -248,6 +263,7 @@ The currently defined per-input types are defined as follows:
 |
 |
 | 0
+| [[bip-0127.mediawiki|127]]
 |-
 | RIPEMD160 preimage
 | <tt>PSBT_IN_RIPEMD160 = 0x0a</tt>
@@ -258,6 +274,7 @@ The currently defined per-input types are defined as follows:
 |
 |
 | 0
+| 174
 |-
 | SHA256 preimage
 | <tt>PSBT_IN_SHA256 = 0x0b</tt>
@@ -268,6 +285,7 @@ The currently defined per-input types are defined as follows:
 |
 |
 | 0
+| 174
 |-
 | HASH160 preimage
 | <tt>PSBT_IN_HASH160 = 0x0c</tt>
@@ -278,6 +296,7 @@ The currently defined per-input types are defined as follows:
 |
 |
 | 0
+| 174
 |-
 | HASH256 preimage
 | <tt>PSBT_IN_HASH256 = 0x0d</tt>
@@ -288,6 +307,7 @@ The currently defined per-input types are defined as follows:
 |
 |
 | 0
+| 174
 |-
 | Proprietary Use Type
 | <tt>PSBT_IN_PROPRIETARY = 0xFC</tt>
@@ -298,6 +318,7 @@ The currently defined per-input types are defined as follows:
 |
 |
 | 0
+| 174
 |}
 
 The currently defined per-output <ref>'''Why do we need per-output data?''' Per-output data allows signers
@@ -314,6 +335,7 @@ determine which outputs are change outputs and verify that the change is returni
 ! Versions Requiring Inclusion
 ! Versions Requiring Exclusion
 ! Versions Allowing Inclusion
+! Parent BIP
 |-
 | Redeem Script
 | <tt>PSBT_OUT_REDEEM_SCRIPT = 0x00</tt>
@@ -324,6 +346,7 @@ determine which outputs are change outputs and verify that the change is returni
 |
 |
 | 0
+| 174
 |-
 | Witness Script
 | <tt>PSBT_OUT_WITNESS_SCRIPT = 0x01</tt>
@@ -334,6 +357,7 @@ determine which outputs are change outputs and verify that the change is returni
 |
 |
 | 0
+| 174
 |-
 | BIP 32 Derivation Path
 | <tt>PSBT_OUT_BIP32_DERIVATION = 0x02</tt>
@@ -344,6 +368,7 @@ determine which outputs are change outputs and verify that the change is returni
 |
 |
 | 0
+| 174
 |-
 | Proprietary Use Type
 | <tt>PSBT_OUT_PROPRIETARY = 0xFC</tt>
@@ -354,6 +379,7 @@ determine which outputs are change outputs and verify that the change is returni
 |
 |
 | 0
+| 174
 |}
 
 Types can be skipped when they are unnecessary. For example, if an input is a witness
@@ -817,129 +843,3 @@ and for coming up with the name and abbreviation of PSBT.
 
 Thanks to Pieter Wuille, Gregory Maxwell, Jonathan Underwood, Daniel Cousens and those who commented on the bitcoin-dev mailing list for additional comments
 and suggestions for improving this proposal.
-
-==Appendix A: Data types and their specifications==
-
-Any data types, their associated scope and BIP number must be defined here
-
-{| class="wikitable" style="width: auto; text-align: center; font-size: smaller; table-layout: fixed;"
-!Scope
-!Type values
-!Name
-!BIP Number
-|-
-| Global
-| 0
-| PSBT_GLOBAL_UNSIGNED_TX
-| BIP 174
-|-
-| Global
-| 1
-| PSBT_GLOBAL_XPUB
-| BIP 174
-|-
-| Global
-| 251
-| PSBT_GLOBAL_VERSION
-| BIP 174
-|-
-| Global
-| 252
-| PSBT_GLOBAL_PROPRIETARY
-| BIP 174
-|-
-| Input
-| 0
-| PSBT_IN_NON_WITNESS_UTXO
-| BIP 174
-|-
-| Input
-| 1
-| PSBT_IN_WITNESS_UTXO
-| BIP 174
-|-
-| Input
-| 2
-| PSBT_IN_PARTIAL_SIG
-| BIP 174
-|-
-| Input
-| 3
-| PSBT_IN_SIGHASH_TYPE
-| BIP 174
-|-
-| Input
-| 4
-| PSBT_IN_REDEEM_SCRIPT
-| BIP 174
-|-
-| Input
-| 5
-| PSBT_IN_WITNESS_SCRIPT
-| BIP 174
-|-
-| Input
-| 6
-| PSBT_IN_BIP32_DERIVATION
-| BIP 174
-|-
-| Input
-| 7
-| PSBT_IN_FINAL_SCRIPTSIG
-| BIP 174
-|-
-| Input
-| 8
-| PSBT_IN_FINAL_SCRIPTWITNESS
-| BIP 174
-|-
-| Input
-| 9
-| PSBT_IN_POR_COMMITMENT
-| [[bip-0127.mediawiki|BIP 127]]
-|-
-| Input
-| 10
-| PSBT_IN_RIPEMD160
-| BIP 174
-|-
-| Input
-| 11
-| PSBT_IN_SHA256
-| BIP 174
-|-
-| Input
-| 12
-| PSBT_IN_HASH160
-| BIP 174
-|-
-| Input
-| 13
-| PSBT_IN_HASH256
-| BIP 174
-|-
-| Input
-| 252
-| PSBT_IN_PROPRIETARY
-| BIP 174
-|-
-| Output
-| 0
-| PSBT_OUT_REDEEM_SCRIPT
-| BIP 174
-|-
-| Output
-| 1
-| PSBT_OUT_WITNESS_SCRIPT
-| BIP 174
-|-
-| Output
-| 2
-| PSBT_OUT_BIP32_DERIVATION
-| BIP 174
-|-
-| Output
-| 252
-| PSBT_OUT_PROPRIETARY
-| BIP 174
-|}
-- 
cgit v1.2.3


From 794f20a13148536e7627451adaf0534e5862f7fa Mon Sep 17 00:00:00 2001
From: Suhas Daftuar <sdaftuar@gmail.com>
Date: Tue, 26 Jan 2021 11:46:35 -0500
Subject: Add link to implementation

Also change the phrasing to more clearly indicate when block-relay-only peering
was deployed.
---
 bip-disable-tx.mediawiki | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/bip-disable-tx.mediawiki b/bip-disable-tx.mediawiki
index c2bca25..a5f2f77 100644
--- a/bip-disable-tx.mediawiki
+++ b/bip-disable-tx.mediawiki
@@ -19,7 +19,7 @@ block-relay-only connections that are currently in use on the network.
 
 ==Motivation==
 
-For nearly the past year, software has been deployed[1] which initiates
+Since 2019, software has been deployed[1] which initiates
 connections on the Bitcoin network and sets the transaction relay field
 (introduced by BIP 37 and also defined in BIP 60) to false, to prevent
 transaction relay from occurring on the connection. Additionally, addr messages
@@ -88,7 +88,7 @@ message, subject to the feature negotiation of BIP 152.
 
 ==Implementation==
 
-TBD
+https://github.com/bitcoin/bitcoin/pull/20726
 
 ==References==
 
-- 
cgit v1.2.3


From 6128a7bcb60ae2eca2461ccb17d29b5186d13820 Mon Sep 17 00:00:00 2001
From: Pieter Wuille <pieter@wuille.net>
Date: Thu, 24 Dec 2020 14:37:19 -0800
Subject: Add BIP 350 (bech32m)

---
 README.mediawiki   |   7 ++
 bip-0350.mediawiki | 333 +++++++++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 340 insertions(+)
 create mode 100644 bip-0350.mediawiki

diff --git a/README.mediawiki b/README.mediawiki
index 83120ab..e83769b 100644
--- a/README.mediawiki
+++ b/README.mediawiki
@@ -980,6 +980,13 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Pieter Wuille, Jonas Nick, Anthony Towns
 | Standard
 | Draft
+|-
+| [[bip-0350.mediawiki|350]]
+| Applications
+| Bech32m format for v1+ witness addresses
+| Pieter Wuille
+| Standard
+| Draft
 |}
 
 <!-- IMPORTANT!  See the instructions at the top of this page, do NOT JUST add BIPs here! -->
diff --git a/bip-0350.mediawiki b/bip-0350.mediawiki
new file mode 100644
index 0000000..a7b5047
--- /dev/null
+++ b/bip-0350.mediawiki
@@ -0,0 +1,333 @@
+<pre>
+  BIP: 350
+  Layer: Applications
+  Title: Bech32m format for v1+ witness addresses
+  Author: Pieter Wuille <pieter@wuille.net>
+  Comments-Summary: No comments yet.
+  Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0350
+  Status: Draft
+  Type: Standards Track
+  Created: 2020-12-16
+  License: BSD-2-Clause
+  Replaces: 173
+  Post-History: 2021-01-05: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-January/018338.html [bitcoin-dev] Bech32m BIP: new checksum, and usage for segwit address
+</pre>
+
+==Introduction==
+
+===Abstract===
+
+This document defines an improved variant of Bech32 called '''Bech32m''', and amends BIP173 to use Bech32m for native segregated witness outputs of version 1 and later. Bech32 remains in use for segregated witness outputs of version 0.
+
+===Copyright===
+
+This BIP is licensed under the 2-clause BSD license.
+
+===Motivation===
+
+[[bip-0173.mediawiki|BIP173]] defined a generic checksummed base 32 encoded format called Bech32. It is in use for segregated witness outputs of version 0 (P2WPKH and P2WSH, see [[bip-0141.mediawiki|BIP141]]), and other applications.
+
+Bech32 has an unexpected [https://github.com/sipa/bech32/issues/51 weakness]: whenever the final character is a 'p', inserting or deleting any number of 'q' characters immediately preceding it does not invalidate the checksum. This does not affect existing uses of witness version 0 BIP173 addresses due to their restriction to two specific lengths, but may affect future uses and/or other applications using the Bech32 encoding.
+
+This document addresses that by specifying Bech32m, a variant of Bech32 that mitigates this insertion weakness and related issues.
+
+==Specification==
+
+We first specify the new checksum algorithm, and then document how it should be used for future Bitcoin addresses.
+
+===Bech32m===
+
+Bech32m modifies the checksum of the Bech32 specification, replacing the constant ''1'' that is xored into the checksum at the end with ''0x2bc830a3''. The resulting checksum verification and creation algorithm (in Python, cf. the code in [https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki#Bech32|BIP173 Bech32 section]):
+
+<pre>
+BECH32M_CONST = 0x2bc830a3
+
+def bech32m_polymod(values):
+  GEN = [0x3b6a57b2, 0x26508e6d, 0x1ea119fa, 0x3d4233dd, 0x2a1462b3]
+  chk = 1
+  for v in values:
+    b = (chk >> 25)
+    chk = (chk & 0x1ffffff) << 5 ^ v
+    for i in range(5):
+      chk ^= GEN[i] if ((b >> i) & 1) else 0
+  return chk
+
+def bech32m_hrp_expand(s):
+  return [ord(x) >> 5 for x in s] + [0] + [ord(x) & 31 for x in s]
+
+def bech32m_verify_checksum(hrp, data):
+  return bech32m_polymod(bech32m_hrp_expand(hrp) + data) == BECH32M_CONST
+
+def bech32m_create_checksum(hrp, data):
+  values = bech32m_hrp_expand(hrp) + data
+  polymod = bech32m_polymod(values + [0,0,0,0,0,0]) ^ BECH32M_CONST
+  return [(polymod >> 5 * (5 - i)) & 31 for i in range(6)]
+</pre>
+
+All other aspects of Bech32 remain unchanged, including its human-readable parts (HRPs).
+
+A combined function to decode both Bech32 and Bech32m simultaneously could be written using:
+
+<pre>
+class Encoding(Enum):
+    BECH32 = 1
+    BECH32M = 2
+
+def bech32_bech32m_verify_checksum(hrp, data):
+    check = bech32_polymod(bech32_hrp_expand(hrp) + data)
+    if check == 1:
+        return Encoding.BECH32
+    if const == BECH32M_CONST:
+        return Encoding.BECH32M
+    return None
+</pre>
+
+which returns either None for failure, or one of the BECH32 / BECH32M enumeration values to indicate successful decoding according to the respective standard.
+
+===Addresses for segregated witness outputs===
+
+Version 0 outputs (specifically, P2WPKH and P2WSH addresses) continue to use Bech32<ref>'''Why not permit both Bech32 and Bech32m for v0 addresses?''' Permitting both encodings reduces the error detection capabilities (it makes it equivalent to only have 29 bits of checksum).</ref> as specified in BIP173. Addresses for segregated witness outputs version 1 through 16 use Bech32m. Again, all other aspects of the encoding remain the same, including the 'bc' HRP.
+
+To generate an address for a segregated witness output:
+
+* If its witness version is 0, encode it using Bech32.
+* If its witness version is 1 or higher, encode it using Bech32m.
+
+To decode an address, client software should either decode with both a Bech32 and a Bech32m decoder<ref>'''Can a single string simultaneously be valid as Bech32 and Bech32m?''' No, a valid Bech32 and Bech32m string will always differ by at least 3 characters if they are the same length.</ref>, or use a decoder that supports both simultaneously. In both cases, the address decoder has to verify that the encoding matches what is expected for the decoded witness version (Bech32 for version 0, Bech32m for others).
+
+The following code demonstrates the checks that need to be performed. Refer to the Python code linked in the reference implementation section below for full details of the called functions.
+
+<pre>
+def decode(hrp, addr):
+    hrpgot, data, spec = bech32_decode(addr)
+    if hrpgot != hrp:
+        return (None, None)
+    decoded = convertbits(data[1:], 5, 8, False)
+    # Witness programs are between 2 and 40 bytes in length.
+    if decoded is None or len(decoded) < 2 or len(decoded) > 40:
+        return (None, None)
+    # Witness versions are in range 0..16.
+    if data[0] > 16:
+        return (None, None)
+    # Witness v0 programs must be exactly length 20 or 32.
+    if data[0] == 0 and len(decoded) != 20 and len(decoded) != 32:
+        return (None, None)
+    # Witness v0 uses Bech32; v1 through v16 use Bech32m.
+    if data[0] == 0 and spec != Encoding.BECH32 or data[0] != 0 and spec != Encoding.BECH32M:
+        return (None, None)
+    # Success.
+    return (data[0], decoded)
+</pre>
+
+'''Error locating'''
+
+Bech32m, like Bech32m, does support locating<ref>'''What about error correction?''' As explained in BIP173, introducing error correction reduces the ability to detect errors. While it is technically possible to correct a small number of errors due to Bech32(m)'s nature as a BCH code, implementations should refrain from using this for more than indicating where an error may be present.</ref> the positions of a few substitution errors. To combine this functionality with
+the segregated witness addresses proposed by this document, simply try locating errors for both Bech32 and Bech32m. If only one finds error locations, report that one. If both do (which should be very rare),
+there are a number of options:
+* Report the one that needs fewer corrections (if they differ).
+* Eliminate the response(s) that are inconsistent. Any symbol that isn't on an error location can be checked. For example, if the witness version symbol is not an error location, and it doesn't correspond to the specification used (0 for Bech32, 1+ for Bech32m), that response can be eliminated.
+
+See the fancy Javascript decoder below for example of the above.
+
+==Compatibility==
+
+This document introduces a new encoding for v1 segregated witness outputs and higher versions. There should not be any compatibility issues on the receiver side; no wallets are creating v1 segregated witness addresses yet, as the output type is not usable on mainnet.
+
+On the other hand, the Bech32m proposal breaks forward-compatibility for sending to v1 and higher version segregated witness addresses. This incompatibility is [https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-October/018236.html intentional]. An alternative design was [https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-November/017460.html considered] where Bech32 remained in use for certain subsets of future addresses, but ultimately [https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-December/018293.html discarded]. By introducing a clean break, we protect not only new software but also existing senders from the mutation issue, as new addresses will be incompatible with the existing Bech32 address validation. [https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-November/018268.html Experiments] by Taproot proponents had shown that hardly any wallets and services supported sending to higher segregated witness output versions, so little is lost by [https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-December/018298.html breaking] forward-compatibility. Furthermore, those experiments identified cases in which segregated witness implementations would have caused wallets to burn funds when sending to version 1 addresses. In case it is still in use, the chosen approach will prevent such software from destroying funds when attempting to send to a Bech32m address.
+
+==Reference implementations==
+
+* Reference encoder and decoder:
+** [https://github.com/sipa/bech32/tree/bech32m/ref/python Reference Python implementation]
+** [https://github.com/sipa/bech32/tree/bech32m/ref/c Reference C implementation]
+** [https://github.com/sipa/bech32/tree/bech32m/ref/c++ Reference C++ implementation]
+** [https://github.com/bitcoin/bitcoin/pull/20861 Bitcoin Core C++ implementation]
+** [https://github.com/sipa/bech32/tree/bech32m/ref/javascript Reference Javascript implementation]
+
+* Fancy decoder that localizes errors:
+** [https://github.com/sipa/bech32/tree/bech32m/ecc/javascript For JavaScript] ([http://bitcoin.sipa.be/bech32/demo/demo.html demo website])
+
+==Test vectors==
+
+'''Implementation advice''' Experiments testing BIP173 implementations found that many wallets and services did not support sending to higher version segregated witness outputs. In anticipation of the proposed [https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki Taproot] soft fork introducing v1 segregated witness outputs on the network, we emphatically recommend employing the complete set of test vectors provided below as well as ensuring that your implementation supports sending to v1 '''and higher versions'''. All higher versions of native segregated witness outputs should be recognized as valid recipients. As higher versions are not defined on the network, no wallet should ever create them and no recipient should ever provide them to a sender. Nor should a recipient ever want to falsely provide them as the recipient would simply see a payment intended to themselves burned instead. However, by defining higher versions as valid recipients now, future soft forks introducing higher versions of native segwit outputs will be forward-compatible to all wallets correctly implementing the Bech32m specification.
+
+===Test vectors for Bech32m===
+
+The following strings are valid Bech32m:
+* <tt>A1LQFN3A</tt>
+* <tt>a1lqfn3a</tt>
+* <tt>an83characterlonghumanreadablepartthatcontainsthetheexcludedcharactersbioandnumber11sg7hg6</tt>
+* <tt>abcdef1l7aum6echk45nj3s0wdvt2fg8x9yrzpqzd3ryx</tt>
+* <tt>11llllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllludsr8</tt>
+* <tt>split1checkupstagehandshakeupstreamerranterredcaperredlc445v</tt>
+* <tt>?1v759aa</tt>
+
+No string can be simultaneously valid Bech32 and Bech32m, so the above examples also serve as invalid test vectors for Bech32.
+
+The following string are not valid Bech32m (with reason for invalidity):
+* 0x20 + <tt>1xj0phk</tt>: HRP character out of range
+* 0x7F + <tt>1g6xzxy</tt>: HRP character out of range
+* 0x80 + <tt>1vctc34</tt>: HRP character out of range
+* <tt>an84characterslonghumanreadablepartthatcontainsthetheexcludedcharactersbioandnumber11d6pts4</tt>: overall max length exceeded
+* <tt>qyrz8wqd2c9m</tt>: No separator character
+* <tt>1qyrz8wqd2c9m</tt>: Empty HRP
+* <tt>y1b0jsk6g</tt>: Invalid data character
+* <tt>lt1igcx5c0</tt>: Invalid data character
+* <tt>in1muywd</tt>: Too short checksum
+* <tt>mm1crxm3i</tt>: Invalid character in checksum
+* <tt>au1s5cgom</tt>: Invalid character in checksum
+* <tt>M1VUXWEZ</tt>: checksum calculated with uppercase form of HRP
+* <tt>16plkw9</tt>: empty HRP
+* <tt>1p2gdwpf</tt>: empty HRP
+
+===Test vectors for v0-v16 native segregated witness addresses===
+
+The following list gives valid segwit addresses and the scriptPubKey that they
+translate to in hex.
+* <tt>BC1QW508D6QEJXTDG4Y5R3ZARVARY0C5XW7KV8F3T4</tt>: <tt>0014751e76e8199196d454941c45d1b3a323f1433bd6</tt>
+* <tt>tb1qrp33g0q5c5txsp9arysrx4k6zdkfs4nce4xj0gdcccefvpysxf3q0sl5k7</tt>: <tt>00201863143c14c5166804bd19203356da136c985678cd4d27a1b8c6329604903262</tt>
+* <tt>bc1pw508d6qejxtdg4y5r3zarvary0c5xw7kw508d6qejxtdg4y5r3zarvary0c5xw7kt5nd6y</tt>: <tt>5128751e76e8199196d454941c45d1b3a323f1433bd6751e76e8199196d454941c45d1b3a323f1433bd6</tt>
+* <tt>BC1SW50QGDZ25J</tt>: <tt>6002751e</tt>
+* <tt>bc1zw508d6qejxtdg4y5r3zarvaryvaxxpcs</tt>: <tt>5210751e76e8199196d454941c45d1b3a323</tt>
+* <tt>tb1qqqqqp399et2xygdj5xreqhjjvcmzhxw4aywxecjdzew6hylgvsesrxh6hy</tt>: <tt>0020000000c4a5cad46221b2a187905e5266362b99d5e91c6ce24d165dab93e86433</tt>
+* <tt>tb1pqqqqp399et2xygdj5xreqhjjvcmzhxw4aywxecjdzew6hylgvsesf3hn0c</tt>: <tt>5120000000c4a5cad46221b2a187905e5266362b99d5e91c6ce24d165dab93e86433</tt>
+* <tt>bc1p0xlxvlhemja6c4dqv22uapctqupfhlxm9h8z3k2e72q4k9hcz7vqzk5jj0</tt>: <tt>512079be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798</tt>
+
+The following list gives invalid segwit addresses and the reason for
+their invalidity.
+* <tt>tc1p0xlxvlhemja6c4dqv22uapctqupfhlxm9h8z3k2e72q4k9hcz7vq5zuyut</tt>: Invalid human-readable part
+* <tt>bc1p0xlxvlhemja6c4dqv22uapctqupfhlxm9h8z3k2e72q4k9hcz7vqh2y7hd</tt>: Invalid checksum (Bech32 instead of Bech32m)
+* <tt>tb1z0xlxvlhemja6c4dqv22uapctqupfhlxm9h8z3k2e72q4k9hcz7vqglt7rf</tt>: Invalid checksum (Bech32 instead of Bech32m)
+* <tt>BC1S0XLXVLHEMJA6C4DQV22UAPCTQUPFHLXM9H8Z3K2E72Q4K9HCZ7VQ54WELL</tt>: Invalid checksum (Bech32 instead of Bech32m)
+* <tt>bc1qw508d6qejxtdg4y5r3zarvary0c5xw7kemeawh</tt>: Invalid checksum (Bech32m instead of Bech32)
+* <tt>tb1q0xlxvlhemja6c4dqv22uapctqupfhlxm9h8z3k2e72q4k9hcz7vq24jc47</tt>: Invalid checksum (Bech32m instead of Bech32)
+* <tt>bc1p38j9r5y49hruaue7wxjce0updqjuyyx0kh56v8s25huc6995vvpql3jow4</tt>: Invalid character in checksum
+* <tt>BC130XLXVLHEMJA6C4DQV22UAPCTQUPFHLXM9H8Z3K2E72Q4K9HCZ7VQ7ZWS8R</tt>: Invalid witness version
+* <tt>bc1pw5dgrnzv</tt>: Invalid program length (1 byte)
+* <tt>bc1p0xlxvlhemja6c4dqv22uapctqupfhlxm9h8z3k2e72q4k9hcz7v8n0nx0muaewav253zgeav</tt>: Invalid program length (41 bytes)
+* <tt>BC1QR508D6QEJXTDG4Y5R3ZARVARYV98GJ9P</tt>: Invalid program length for witness version 0 (per BIP141)
+* <tt>tb1p0xlxvlhemja6c4dqv22uapctqupfhlxm9h8z3k2e72q4k9hcz7vq47Zagq</tt>: Mixed case
+* <tt>bc1p0xlxvlhemja6c4dqv22uapctqupfhlxm9h8z3k2e72q4k9hcz7v07qwwzcrf</tt>: zero padding of more than 4 bits
+* <tt>tb1p0xlxvlhemja6c4dqv22uapctqupfhlxm9h8z3k2e72q4k9hcz7vpggkg4j</tt>: Non-zero padding in 8-to-5 conversion
+* <tt>bc1gmk9yu</tt>: Empty data section
+
+
+==Appendix: checksum design & properties==
+
+Checksums are used to detect errors introduced into data during transfer. A hash function-based checksum such as Base58Check detects any type of error uniformly, but not all classes of errors are equally likely to occur in practice. Bech32 prioritizes detection of substitution errors, but improving detection of one error class inevitably worsens detection of other error classes. During the design of Bech32, it was assumed that other simple error patterns beside substitutions would have a similar detection rate as in a hash function-based design, and detection would only be worse for complex, impractical errors. The discovered insertion weakness shows that this is not the case.
+
+For Bech32m, we aim to retain Bech32's guarantees for substitution errors, but make sure that other common errors don't perform worse than a hash function-based checksum would. To make sure the new standard is easy to implement, we restrict the design space to only amending the final constant that is xored in, as it was [https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-December/017521.html observed] that that is sufficient to mitigate the 'q' insertion issue while retaining the intended substitution error detection. In what follows, we explain how the new constant ''0x2bc830a3'' was chosen.
+
+===Error patterns & detection probability===
+
+We define an error pattern as a sequence of first one or more deletions, then swaps of adjacent characters, followed by substitutions, insertions, and duplications, in that order, all in specific positions, applied to a string with valid checksum that is otherwise randomly chosen. For insertions and substitutions we assume a uniformly random new character. For example, "delete the 17th character, swap the 11th character with the 12th character, and insert a random character in the 24th position" is an error pattern. "Replace the 43th through 48th character with 'aardvark'" is not a valid error pattern, because the new characters are not random and there is no reason why this particular string is more likely than any other to be substituted.
+
+A hash function-based checksum design with a 30-bit hash would have a probability of incorrectly accepting equal to ''2<sup>-30</sup>'', for every error pattern. Bech32 has a probability of 0 to incorrectly accept error patterns consisting of up to 4 substitutions—they are always detected. The 'q'-insertion issue shows that for Bech32 a simple error pattern ("insert a random character in the penultimate position") with probability ''2<sup>-10</sup>'' exists: it requires the final character to be 'p' (leaving only  1 in 32 strings), and requires the inserted character to be 'q' (permitting only 1 of 32 possible inserted characters).
+
+Note that the choice of ''what'' the error pattern is (which types of errors, and where) isn't part of our probabilities: we try to make sure that ''every'' pattern behaves well, not just randomly chosen ones, because presumably humans
+make some kinds of errors more than others, and we cannot easily model which ones.
+
+===Detection properties of Bech32m===
+
+The table below shows the error detection properties of Bech32m, and a comparison with Bech32. The code used for this analysis can be found [https://gist.github.com/sipa/14c248c288c3880a3b191f978a34508e#file-const_analysis-cpp here]. Every row specifies one error pattern via the constraints in the left four columns. The remaining columns report what percentage of those patterns have certain probabilities of not being detected. The columns are:
+
+* '''errors''' The maximum number of individual errors considered
+* '''of type''' What type of errors are considered (either "subst. only" for just substitutions, or "any" to also include deletions, swaps, insertions, and duplications)
+* '''window''' The maximum size of the window in which the errors have to occur<ref>'''What is an error pattern’s window size?''' The window size of an error pattern is the length of the smallest consecutive range of characters that contains all modified characters (on input or output; whichever is larger). For example, an error pattern that turns "abcdef" into "accdbef" has a window size of 4, as it is replacing "bcd" with "ccdb", a 4 character string. Window size is only meaningful when the pattern consists of two or more errors.</ref>
+* '''code/verifier''' Whether it about Bech32 or Bech32m encoded strings, and whether they are evaluated regarding their probability of being accepted by either a Bech32 or a Bech32m verifier.<ref>'''Why do we care about probability of accepting Bech32m strings in Bech32 verifiers?''' For applications where Bech32m replaces an existing use of Bech32 (such as segregated witness addresses), we want to make sure that a Bech32m string created by new software won’t be erroneously accepted by old software that assumes Bech32 - even when a small number of errors were introduced as well.</ref><ref>'''Should we also take into account failures that occur due to taking a valid Bech32m string, and after errors it becoming acceptable to a Bech32 verifier?''' This situation may in theory occur for segregated witness addresses when errors occur that change the version number in a v1+ address to v0. Due to the specificity of this type of error, plus the additional constraints that apply for v0 addresses, this is both unlikely and hard to analyze.</ref>
+* '''error patterns with failure probability''' For each probability (''0'', ''2<sup>-30</sup>'', ''2<sup>-25</sup>'', ''2<sup>-20</sup>'', ''2<sup>-15</sup>'', and ''2<sup>-10</sup>'') this reports what percentage of error patterns restricted by the constraints in the previous columns have those probabilities of being incorrectly accepted.
+
+The properties are divided into two classes: those that hold over all strings when averaged over all possible HRPs (human readable parts), and those specific to the "bc1" HRP with the length restrictions imposed by segregated witness addresses<ref>'''What restrictions were taken into account for the "bc1"-specific analysis?''' The minimum length (due to witness programs being at least 2 bytes), the maximum length (due to witness programs being at most 40 bytes), and the fact that the witness programs are a multiple of 8 bits. The fact that the first data symbol cannot be over 16, or that the padding has to be 0, is not taken into account.</ref>.
+
+{| class="wikitable"
+! rowspan="2" | errors
+! rowspan="2" | of type
+! rowspan="2" | window
+! rowspan="2" | code/verifier
+! colspan="6" | error patterns with failure probability
+|-
+! ''0'' !! ''2<sup>-30</sup>'' !! ''2<sup>-25</sup>'' !! ''2<sup>-20</sup>'' !! ''2<sup>-15</sup>'' !! ''2<sup>-10</sup>''
+|-
+! colspan="10" | Properties averaged over all HRPs
+|-
+| &leq; 4 || only subst. || any      || rowspan="6" | Bech32m/Bech32m || 100.00%|| colspan="5" | none<sup>(a)</sup>
+|-
+| any     || any         || &leq; 4  || 56.16%|| 43.84%|| colspan="4" | none<sup>(b)</sup>
+|-
+| &leq; 2 || any         || &leq; 68 || 7.71%|| 92.28%|| colspan="4" | none<sup>(b)</sup>
+|-
+| &leq; 2 || any         || any      || 7.79%|| 92.20%|| 0.004%|| colspan="3" | none<sup>(b)</sup>
+|-
+| &leq; 3 || any         || &leq; 69 || 7.73%|| 92.23%|| 0.033%<sup>(d)</sup> || colspan="3" | none<sup>(b)</sup>
+|-
+| &leq; 3 || any         || any      || 7.77%|| 92.19%|| 0.034%|| 0.000065% || colspan="2" | none<sup>(b)</sup>
+|-
+| &leq; 4 || only subst. || any      || rowspan="6" | Bech32/Bech32 || 100.00%|| colspan="5" | none
+|-
+| any     || any         || &leq; 4  || 54.00%|| 43.84%|| 1.08%|| 0.90%|| 0.17%|| 0.0091%
+|-
+| &leq; 2 || any         || &leq; 68 || 4.59%|| 92.29%|| 1.09%|| 1.01%|| 0.99%|| 0.039%
+|-
+| &leq; 2 || any         || any      || 4.58%|| 92.21%|| 1.11%|| 1.04%|| 1.02%|| 0.038%
+|-
+| &leq; 3 || any         || &leq; 69 || 6.69%|| 92.23%|| 0.56%|| 0.48%|| 0.041%|| 0.00055%
+|-
+| &leq; 3 || any         || any      || 6.66%|| 92.19%|| 0.59%|| 0.52%|| 0.041%|| 0.00053%
+|-
+| &leq; 1 || any         || -        || rowspan="3" | Bech32m/Bech32 ||  46.53%|| 53.46%|| colspan="4" | none<sup>(b)</sup>
+|-
+| 0       || -           || -        || 100.00%|| colspan="5" | none<sup>(a)</sup>
+|-
+| &leq; 2 || any         || any      || 22.18%|| 77.77%|| 0.048%|| colspan="3" | none<sup>(b)</sup>
+|-
+! colspan="10" | Properties for segregated witness addresses with HRP "bc"
+|-
+| &leq; 4 || only subst. || any      || rowspan="6" | Bech32m/Bech32m || 100.00%|| colspan="5" | none<sup>(a)</sup>
+|-
+| &leq; 1 || any         || -        ||  24.34%|| 75.66%|| colspan="4" | none<sup>(c)</sup>
+|-
+| &leq; 2 || any         || &leq; 28 ||  16.85%|| 83.15%|| colspan="4" | none<sup>(c)</sup>
+|-
+| &leq; 2 || any         || any      ||  15.72%|| 84.23%|| 0.038%|| 0.0053%|| colspan="2" | none<sup>(c)</sup>
+|-
+| any     || any         || &leq; 4  ||  74.74%|| 25.25%|| 0.0015%|| colspan="3" | none<sup>(c)</sup>
+|-
+| &leq; 3 || any         || any      ||  13.98%|| 85.94%|| 0.078%|| 0.00063%|| colspan="2" | none<sup>(c)</sup>
+|-
+| &leq; 4 || only subst. || any      || rowspan="6" | Bech32/Bech32 || 100.00%|| colspan="5" | none
+|-
+| &leq; 1 || any         || -        ||  14.63%|| 75.71%|| 2.43%|| 2.43%|| 2.43%|| 2.38%
+|-
+| &leq; 2 || any         || &leq; 28 ||  14.22%|| 83.15%|| 0.94%|| 0.84%|| 0.79%|| 0.054%
+|-
+| &leq; 2 || any         || any      ||  12.79%|| 84.24%|| 1.06%|| 0.95%|| 0.92%|| 0.041%
+|-
+| any     || any         || &leq; 4  ||  73.23%|| 25.26%|| 0.76%|| 0.63%|| 0.12%|| 0.0064%
+|-
+| &leq; 3 || any         || any      ||  13.00%|| 85.94%|| 0.57%|| 0.45%|| 0.044%|| 0.00067%
+|-
+| &leq; 3 || only subst. || any      || rowspan="3" | Bech32m/Bech32 || 100.00%|| colspan="5" | none<sup>(c)</sup>
+|-
+| &leq; 1 || any         || -        ||  70.89%|| 29.11%|| colspan="4" | none<sup>(c)</sup>
+|-
+| &leq; 2 || any         || any      ||  36.12%|| 63.79%|| 0.092%|| 0.00049%|| colspan="2" | none<sup>(c)</sup>
+|}
+
+The numbers in this table, as well as a comparison with the numbers for the ‘’1’’ constant and earlier proposed improved constants, can be found [https://gist.github.com/sipa/14c248c288c3880a3b191f978a34508e#file-results_final-txt here].
+
+
+===Selection process===
+
+The details of the selection process can be found [https://gist.github.com/sipa/14c248c288c3880a3b191f978a34508e here], but in short:
+* Start with the set of all ''2<sup>30</sup>-1'' constants different from Bech32's ''1''. All of these satisfy the properties marked <sup>(a)</sup> in the table above.
+* Through exhaustive analysis, reject all constants that do not exhibit the properties<ref>'''How were the properties to select for chosen?''' All these properties are as strong as they can be without rejecting every constant: rejecting constants with lower probabilities, or more errors, or wider windows all result in nothing left.</ref> marked <sup>(b)</sup> in the table above (e.g. all constants that permit any error pattern of 2 errors or less in a window of 68 characters or less with a detection probability ''&geq; 2<sup>-20</sup>''). This selection leaves us with 12054 candidates.
+* Reject all constants that do not exhibit the <sup>(c)</sup> properties in the table above<ref>'''Why optimize for segregated witness addresses (with HRP "bc1") specifically?''' Our analysis for generic HRP has limitations (see the detailed description [https://gist.github.com/sipa/14c248c288c3880a3b191f978a34508e#file-bech32m_mail-txt here], under "Technical details"). We optimize for generic usage first, but optimize for segregated witness addresses as a tiebreaker.</ref>. This leaves us with 79 candidates.
+* Finally, select the candidate that minimizes the number of error classes matching <sup>(d)</sup> in the table above as a final tiebreaker. The result is the single constant ''0x2bc830a3''.
+
+==Footnotes==
+
+<references />
+
+==Acknowledgements==
+
+Thanks to Rusty Russell for starting the discussion around intentionally breaking compatibility with existing senders, which is used in this specification. Thanks to Greg Maxwell for doing most of the computation for code selection and analysis.
-- 
cgit v1.2.3


From e192983f5b1fc7a2a0739906103fd6ed8f383c8d Mon Sep 17 00:00:00 2001
From: Pieter Wuille <pieter@wuille.net>
Date: Fri, 29 Jan 2021 11:33:20 -0800
Subject: Update bip-0350.mediawiki

Co-authored-by: andrewtoth <andrewstoth@gmail.com>
---
 bip-0350.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-0350.mediawiki b/bip-0350.mediawiki
index a7b5047..3ad41c8 100644
--- a/bip-0350.mediawiki
+++ b/bip-0350.mediawiki
@@ -234,7 +234,7 @@ The table below shows the error detection properties of Bech32m, and a compariso
 * '''errors''' The maximum number of individual errors considered
 * '''of type''' What type of errors are considered (either "subst. only" for just substitutions, or "any" to also include deletions, swaps, insertions, and duplications)
 * '''window''' The maximum size of the window in which the errors have to occur<ref>'''What is an error pattern’s window size?''' The window size of an error pattern is the length of the smallest consecutive range of characters that contains all modified characters (on input or output; whichever is larger). For example, an error pattern that turns "abcdef" into "accdbef" has a window size of 4, as it is replacing "bcd" with "ccdb", a 4 character string. Window size is only meaningful when the pattern consists of two or more errors.</ref>
-* '''code/verifier''' Whether it about Bech32 or Bech32m encoded strings, and whether they are evaluated regarding their probability of being accepted by either a Bech32 or a Bech32m verifier.<ref>'''Why do we care about probability of accepting Bech32m strings in Bech32 verifiers?''' For applications where Bech32m replaces an existing use of Bech32 (such as segregated witness addresses), we want to make sure that a Bech32m string created by new software won’t be erroneously accepted by old software that assumes Bech32 - even when a small number of errors were introduced as well.</ref><ref>'''Should we also take into account failures that occur due to taking a valid Bech32m string, and after errors it becoming acceptable to a Bech32 verifier?''' This situation may in theory occur for segregated witness addresses when errors occur that change the version number in a v1+ address to v0. Due to the specificity of this type of error, plus the additional constraints that apply for v0 addresses, this is both unlikely and hard to analyze.</ref>
+* '''code/verifier''' Whether it is about Bech32 or Bech32m encoded strings, and whether they are evaluated regarding their probability of being accepted by either a Bech32 or a Bech32m verifier.<ref>'''Why do we care about probability of accepting Bech32m strings in Bech32 verifiers?''' For applications where Bech32m replaces an existing use of Bech32 (such as segregated witness addresses), we want to make sure that a Bech32m string created by new software won’t be erroneously accepted by old software that assumes Bech32 - even when a small number of errors were introduced as well.</ref><ref>'''Should we also take into account failures that occur due to taking a valid Bech32m string, and after errors it becoming acceptable to a Bech32 verifier?''' This situation may in theory occur for segregated witness addresses when errors occur that change the version number in a v1+ address to v0. Due to the specificity of this type of error, plus the additional constraints that apply for v0 addresses, this is both unlikely and hard to analyze.</ref>
 * '''error patterns with failure probability''' For each probability (''0'', ''2<sup>-30</sup>'', ''2<sup>-25</sup>'', ''2<sup>-20</sup>'', ''2<sup>-15</sup>'', and ''2<sup>-10</sup>'') this reports what percentage of error patterns restricted by the constraints in the previous columns have those probabilities of being incorrectly accepted.
 
 The properties are divided into two classes: those that hold over all strings when averaged over all possible HRPs (human readable parts), and those specific to the "bc1" HRP with the length restrictions imposed by segregated witness addresses<ref>'''What restrictions were taken into account for the "bc1"-specific analysis?''' The minimum length (due to witness programs being at least 2 bytes), the maximum length (due to witness programs being at most 40 bytes), and the fact that the witness programs are a multiple of 8 bits. The fact that the first data symbol cannot be over 16, or that the padding has to be 0, is not taken into account.</ref>.
-- 
cgit v1.2.3


From d3874ff3ec0ca090a12a0f48560f3d819d9bee10 Mon Sep 17 00:00:00 2001
From: Pieter Wuille <pieter@wuille.net>
Date: Fri, 29 Jan 2021 11:33:27 -0800
Subject: Update bip-0350.mediawiki

Co-authored-by: andrewtoth <andrewstoth@gmail.com>
---
 bip-0350.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-0350.mediawiki b/bip-0350.mediawiki
index 3ad41c8..d09ae6b 100644
--- a/bip-0350.mediawiki
+++ b/bip-0350.mediawiki
@@ -220,7 +220,7 @@ For Bech32m, we aim to retain Bech32's guarantees for substitution errors, but m
 
 ===Error patterns & detection probability===
 
-We define an error pattern as a sequence of first one or more deletions, then swaps of adjacent characters, followed by substitutions, insertions, and duplications, in that order, all in specific positions, applied to a string with valid checksum that is otherwise randomly chosen. For insertions and substitutions we assume a uniformly random new character. For example, "delete the 17th character, swap the 11th character with the 12th character, and insert a random character in the 24th position" is an error pattern. "Replace the 43th through 48th character with 'aardvark'" is not a valid error pattern, because the new characters are not random and there is no reason why this particular string is more likely than any other to be substituted.
+We define an error pattern as a sequence of first one or more deletions, then swaps of adjacent characters, followed by substitutions, insertions, and duplications, in that order, all in specific positions, applied to a string with valid checksum that is otherwise randomly chosen. For insertions and substitutions we assume a uniformly random new character. For example, "delete the 17th character, swap the 11th character with the 12th character, and insert a random character in the 24th position" is an error pattern. "Replace the 43rd through 48th character with 'aardvark'" is not a valid error pattern, because the new characters are not random and there is no reason why this particular string is more likely than any other to be substituted.
 
 A hash function-based checksum design with a 30-bit hash would have a probability of incorrectly accepting equal to ''2<sup>-30</sup>'', for every error pattern. Bech32 has a probability of 0 to incorrectly accept error patterns consisting of up to 4 substitutions—they are always detected. The 'q'-insertion issue shows that for Bech32 a simple error pattern ("insert a random character in the penultimate position") with probability ''2<sup>-10</sup>'' exists: it requires the final character to be 'p' (leaving only  1 in 32 strings), and requires the inserted character to be 'q' (permitting only 1 of 32 possible inserted characters).
 
-- 
cgit v1.2.3


From 6446f2af0a75e513a0c4bad0ddaad8d798bd5e2d Mon Sep 17 00:00:00 2001
From: Pieter Wuille <pieter@wuille.net>
Date: Fri, 29 Jan 2021 11:33:33 -0800
Subject: Update bip-0350.mediawiki

Co-authored-by: andrewtoth <andrewstoth@gmail.com>
---
 bip-0350.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-0350.mediawiki b/bip-0350.mediawiki
index d09ae6b..f34da56 100644
--- a/bip-0350.mediawiki
+++ b/bip-0350.mediawiki
@@ -121,7 +121,7 @@ def decode(hrp, addr):
 
 '''Error locating'''
 
-Bech32m, like Bech32m, does support locating<ref>'''What about error correction?''' As explained in BIP173, introducing error correction reduces the ability to detect errors. While it is technically possible to correct a small number of errors due to Bech32(m)'s nature as a BCH code, implementations should refrain from using this for more than indicating where an error may be present.</ref> the positions of a few substitution errors. To combine this functionality with
+Bech32m, like Bech32, does support locating<ref>'''What about error correction?''' As explained in BIP173, introducing error correction reduces the ability to detect errors. While it is technically possible to correct a small number of errors due to Bech32(m)'s nature as a BCH code, implementations should refrain from using this for more than indicating where an error may be present.</ref> the positions of a few substitution errors. To combine this functionality with
 the segregated witness addresses proposed by this document, simply try locating errors for both Bech32 and Bech32m. If only one finds error locations, report that one. If both do (which should be very rare),
 there are a number of options:
 * Report the one that needs fewer corrections (if they differ).
-- 
cgit v1.2.3


From e2cfb55f2fa1c1dbac55ae3ccf0994d3e10aa375 Mon Sep 17 00:00:00 2001
From: omar shibli <omarshib@gmail.com>
Date: Sun, 31 Jan 2021 21:38:39 +0200
Subject: reject BIP175

---
 README.mediawiki   | 4 ++--
 bip-0175.mediawiki | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/README.mediawiki b/README.mediawiki
index 83120ab..d3a4bdd 100644
--- a/README.mediawiki
+++ b/README.mediawiki
@@ -854,13 +854,13 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Andrew Chow
 | Standard
 | Proposed
-|-
+|- style="background-color: #ffcfcf"
 | [[bip-0175.mediawiki|175]]
 | Applications
 | Pay to Contract Protocol
 | Omar Shibli, Nicholas Gregory
 | Informational
-| Draft
+| Rejected
 |-
 | [[bip-0176.mediawiki|176]]
 |
diff --git a/bip-0175.mediawiki b/bip-0175.mediawiki
index a3ffd1c..30c7985 100644
--- a/bip-0175.mediawiki
+++ b/bip-0175.mediawiki
@@ -6,7 +6,7 @@
           Nicholas Gregory <nicholas@commerceblock.com>
   Comments-Summary: No comments yet.
   Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0175
-  Status: Draft
+  Status: Rejected
   Type: Informational
   Created: 2017-07-17
   License: BSD-2-Clause
-- 
cgit v1.2.3


From f70132e58bce9ad88844d0b5c5500f3a6c98557b Mon Sep 17 00:00:00 2001
From: Luke Dashjr <luke-jr+git@utopios.org>
Date: Wed, 3 Feb 2021 22:33:18 +0000
Subject: BIP 174: Revert title change to fit length limit

This partially reverts c0991047e25a35d1ddf241f304a079e9893eed69.
---
 README.mediawiki      | 2 +-
 bip-0174.mediawiki    | 2 +-
 scripts/buildtable.pl | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/README.mediawiki b/README.mediawiki
index da943d9..b8f971b 100644
--- a/README.mediawiki
+++ b/README.mediawiki
@@ -850,7 +850,7 @@ Those proposing changes should consider that ultimately consent may rest with th
 |- style="background-color: #cfffcf"
 | [[bip-0174.mediawiki|174]]
 | Applications
-| Partially Signed Bitcoin Transaction Format and Version 0
+| Partially Signed Bitcoin Transaction Format
 | Andrew Chow
 | Standard
 | Final
diff --git a/bip-0174.mediawiki b/bip-0174.mediawiki
index 81958fd..235d01a 100644
--- a/bip-0174.mediawiki
+++ b/bip-0174.mediawiki
@@ -1,7 +1,7 @@
 <pre>
   BIP: 174
   Layer: Applications
-  Title: Partially Signed Bitcoin Transaction Format and Version 0
+  Title: Partially Signed Bitcoin Transaction Format
   Author: Andrew Chow <achow101@gmail.com>
   Comments-Summary: No comments yet.
   Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0174
diff --git a/scripts/buildtable.pl b/scripts/buildtable.pl
index ed71f7c..1edd8c0 100755
--- a/scripts/buildtable.pl
+++ b/scripts/buildtable.pl
@@ -89,7 +89,7 @@ my %DefinedLicenses = (
 );
 my %GrandfatheredPD = map { $_ => undef } qw(9 36 37 38 42 49 50 60 65 67 69 74 80 81 83 90 99 105 107 109 111 112 113 114 122 124 125 126 130 131 132 133 140 141 142 143 144 146 147 150 151 152);
 my %TolerateMissingLicense = map { $_ => undef } qw(1 10 11 12 13 14 15 16 21 31 33 34 35 39 43 44 45 47 61 64 68 70 71 72 73 101 102 106 120 121);
-my %TolerateTitleTooLong = map { $_ => undef } qw(39 44 45 47 49 60 67 68 69 73 74 75 80 81 99 105 106 109 113 122 126 131 143 145 147 173 174);
+my %TolerateTitleTooLong = map { $_ => undef } qw(39 44 45 47 49 60 67 68 69 73 74 75 80 81 99 105 106 109 113 122 126 131 143 145 147 173);
 
 my %emails;
 
-- 
cgit v1.2.3


From c5b392cce1990134763d0b7604f51b8d5af057d4 Mon Sep 17 00:00:00 2001
From: Pieter Wuille <pieter@wuille.net>
Date: Wed, 3 Feb 2021 16:15:31 -0800
Subject: Add back a few lost improvements

---
 bip-0350.mediawiki | 29 ++++++++++++++++-------------
 1 file changed, 16 insertions(+), 13 deletions(-)

diff --git a/bip-0350.mediawiki b/bip-0350.mediawiki
index f34da56..d70bc20 100644
--- a/bip-0350.mediawiki
+++ b/bip-0350.mediawiki
@@ -77,9 +77,10 @@ def bech32_bech32m_verify_checksum(hrp, data):
     check = bech32_polymod(bech32_hrp_expand(hrp) + data)
     if check == 1:
         return Encoding.BECH32
-    if const == BECH32M_CONST:
+    elif check == BECH32M_CONST:
         return Encoding.BECH32M
-    return None
+    else:
+        return None
 </pre>
 
 which returns either None for failure, or one of the BECH32 / BECH32M enumeration values to indicate successful decoding according to the respective standard.
@@ -234,7 +235,7 @@ The table below shows the error detection properties of Bech32m, and a compariso
 * '''errors''' The maximum number of individual errors considered
 * '''of type''' What type of errors are considered (either "subst. only" for just substitutions, or "any" to also include deletions, swaps, insertions, and duplications)
 * '''window''' The maximum size of the window in which the errors have to occur<ref>'''What is an error pattern’s window size?''' The window size of an error pattern is the length of the smallest consecutive range of characters that contains all modified characters (on input or output; whichever is larger). For example, an error pattern that turns "abcdef" into "accdbef" has a window size of 4, as it is replacing "bcd" with "ccdb", a 4 character string. Window size is only meaningful when the pattern consists of two or more errors.</ref>
-* '''code/verifier''' Whether it is about Bech32 or Bech32m encoded strings, and whether they are evaluated regarding their probability of being accepted by either a Bech32 or a Bech32m verifier.<ref>'''Why do we care about probability of accepting Bech32m strings in Bech32 verifiers?''' For applications where Bech32m replaces an existing use of Bech32 (such as segregated witness addresses), we want to make sure that a Bech32m string created by new software won’t be erroneously accepted by old software that assumes Bech32 - even when a small number of errors were introduced as well.</ref><ref>'''Should we also take into account failures that occur due to taking a valid Bech32m string, and after errors it becoming acceptable to a Bech32 verifier?''' This situation may in theory occur for segregated witness addresses when errors occur that change the version number in a v1+ address to v0. Due to the specificity of this type of error, plus the additional constraints that apply for v0 addresses, this is both unlikely and hard to analyze.</ref>
+* '''code/verifier''' Whether this line is about Bech32 or Bech32m encoded strings, and whether those are evaluated regarding their probability of being accepted by either a Bech32 or a Bech32m verifier.<ref>'''Why do we care about probability of accepting Bech32m strings in Bech32 verifiers?''' For applications where Bech32m replaces an existing use of Bech32 (such as segregated witness addresses), we want to make sure that a Bech32m string created by new software won’t be erroneously accepted by old software that assumes Bech32 - even when a small number of errors were introduced as well.</ref><ref>'''Should we also take into account failures that occur due to taking a valid Bech32m string, and after errors it becoming acceptable to a Bech32 verifier?''' This situation may in theory occur for segregated witness addresses when errors occur that change the version number in a v1+ address to v0. Due to the specificity of this type of error, plus the additional constraints that apply for v0 addresses, this is both unlikely and hard to analyze.</ref>
 * '''error patterns with failure probability''' For each probability (''0'', ''2<sup>-30</sup>'', ''2<sup>-25</sup>'', ''2<sup>-20</sup>'', ''2<sup>-15</sup>'', and ''2<sup>-10</sup>'') this reports what percentage of error patterns restricted by the constraints in the previous columns have those probabilities of being incorrectly accepted.
 
 The properties are divided into two classes: those that hold over all strings when averaged over all possible HRPs (human readable parts), and those specific to the "bc1" HRP with the length restrictions imposed by segregated witness addresses<ref>'''What restrictions were taken into account for the "bc1"-specific analysis?''' The minimum length (due to witness programs being at least 2 bytes), the maximum length (due to witness programs being at most 40 bytes), and the fact that the witness programs are a multiple of 8 bits. The fact that the first data symbol cannot be over 16, or that the padding has to be 0, is not taken into account.</ref>.
@@ -274,9 +275,9 @@ The properties are divided into two classes: those that hold over all strings wh
 |-
 | &leq; 3 || any         || any      || 6.66%|| 92.19%|| 0.59%|| 0.52%|| 0.041%|| 0.00053%
 |-
-| &leq; 1 || any         || -        || rowspan="3" | Bech32m/Bech32 ||  46.53%|| 53.46%|| colspan="4" | none<sup>(b)</sup>
+|       0 || -           || -        || rowspan="3" | Bech32m/Bech32 ||  100.00%|| colspan="5" | none<sup>(a)</sup>
 |-
-| 0       || -           || -        || 100.00%|| colspan="5" | none<sup>(a)</sup>
+|       1 || any         || -        || 46.53%|| 53.46%|| colspan="4" | none<sup>(b)</sup>
 |-
 | &leq; 2 || any         || any      || 22.18%|| 77.77%|| 0.048%|| colspan="3" | none<sup>(b)</sup>
 |-
@@ -284,31 +285,31 @@ The properties are divided into two classes: those that hold over all strings wh
 |-
 | &leq; 4 || only subst. || any      || rowspan="6" | Bech32m/Bech32m || 100.00%|| colspan="5" | none<sup>(a)</sup>
 |-
-| &leq; 1 || any         || -        ||  24.34%|| 75.66%|| colspan="4" | none<sup>(c)</sup>
+|       1 || any         || -        ||  24.34%|| 75.66%|| colspan="4" | none<sup>(c)</sup>
 |-
 | &leq; 2 || any         || &leq; 28 ||  16.85%|| 83.15%|| colspan="4" | none<sup>(c)</sup>
 |-
-| &leq; 2 || any         || any      ||  15.72%|| 84.23%|| 0.038%|| 0.0053%|| colspan="2" | none<sup>(c)</sup>
+| any     || any         || &leq; 4  ||  74.74%|| 25.25%|| 0.0016%|| colspan="3" | none<sup>(c)</sup>
 |-
-| any     || any         || &leq; 4  ||  74.74%|| 25.25%|| 0.0015%|| colspan="3" | none<sup>(c)</sup>
+| &leq; 2 || any         || any      ||  15.72%|| 84.23%|| 0.039%|| 0.0053%|| colspan="2" | none<sup>(c)</sup>
 |-
 | &leq; 3 || any         || any      ||  13.98%|| 85.94%|| 0.078%|| 0.00063%|| colspan="2" | none<sup>(c)</sup>
 |-
 | &leq; 4 || only subst. || any      || rowspan="6" | Bech32/Bech32 || 100.00%|| colspan="5" | none
 |-
-| &leq; 1 || any         || -        ||  14.63%|| 75.71%|| 2.43%|| 2.43%|| 2.43%|| 2.38%
+|       1 || any         || -        ||  14.63%|| 75.71%|| 2.43%|| 2.43%|| 2.43%|| 2.38%
 |-
 | &leq; 2 || any         || &leq; 28 ||  14.22%|| 83.15%|| 0.94%|| 0.84%|| 0.79%|| 0.054%
 |-
-| &leq; 2 || any         || any      ||  12.79%|| 84.24%|| 1.06%|| 0.95%|| 0.92%|| 0.041%
-|-
 | any     || any         || &leq; 4  ||  73.23%|| 25.26%|| 0.76%|| 0.63%|| 0.12%|| 0.0064%
 |-
+| &leq; 2 || any         || any      ||  12.79%|| 84.24%|| 1.06%|| 0.95%|| 0.92%|| 0.041%
+|-
 | &leq; 3 || any         || any      ||  13.00%|| 85.94%|| 0.57%|| 0.45%|| 0.044%|| 0.00067%
 |-
 | &leq; 3 || only subst. || any      || rowspan="3" | Bech32m/Bech32 || 100.00%|| colspan="5" | none<sup>(c)</sup>
 |-
-| &leq; 1 || any         || -        ||  70.89%|| 29.11%|| colspan="4" | none<sup>(c)</sup>
+|       1 || any         || -        ||  70.89%|| 29.11%|| colspan="4" | none<sup>(c)</sup>
 |-
 | &leq; 2 || any         || any      ||  36.12%|| 63.79%|| 0.092%|| 0.00049%|| colspan="2" | none<sup>(c)</sup>
 |}
@@ -330,4 +331,6 @@ The details of the selection process can be found [https://gist.github.com/sipa/
 
 ==Acknowledgements==
 
-Thanks to Rusty Russell for starting the discussion around intentionally breaking compatibility with existing senders, which is used in this specification. Thanks to Greg Maxwell for doing most of the computation for code selection and analysis.
+Thanks to Greg Maxwell for doing most of the computation for code selection and analysis, and comments.
+Thanks to Mark Erhardt for help with writing and editing this document.
+Thanks to Rusty Russell and others on the bitcoin-dev list for the discussion around intentionally breaking compatibility with existing senders, which is used in this specification.
-- 
cgit v1.2.3


From 63d2800fabe4393382f699ba1e41260ab7b01727 Mon Sep 17 00:00:00 2001
From: Anthony Towns <aj@erisian.com.au>
Date: Thu, 4 Feb 2021 12:25:25 +1000
Subject: bip 8: simplify MUST_SIGNAL check

---
 bip-0008.mediawiki | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/bip-0008.mediawiki b/bip-0008.mediawiki
index d5cb191..8800b43 100644
--- a/bip-0008.mediawiki
+++ b/bip-0008.mediawiki
@@ -181,16 +181,16 @@ Blocks received while in the MUST_SIGNAL phase must be checked to ensure that th
 
     if (GetStateForBlock(block) == MUST_SIGNAL) {
         int nonsignal = 0;
-        int count = 1 + (block.nHeight % 2016);
         walk = block;
-        while (count > 0) {
-            --count;
+        while (true) {
             if ((walk.nVersion & 0xE0000000) != 0x20000000 || ((walk.nVersion >> bit) & 1) != 1) {
                 ++nonsignal;
-                if (nonsignal + threshold > 2016) {
+                if (nonsignal > 2016 - threshold) {
                     return state.Invalid(BlockValidationResult::RECENT_CONSENSUS_CHANGE, "bad-version-bip8-must-signal");
                 }
-            } else if (nonsignal == 0) {
+            }
+            if (walk.nHeight % 2016 == 0) {
+                // checked every block in this retarget period
                 break;
             }
             walk = walk.parent;
-- 
cgit v1.2.3


From b58dd7bc1a15d91c979e1fa2ebbf1f1a83784547 Mon Sep 17 00:00:00 2001
From: SomberNight <somber.night@protonmail.com>
Date: Fri, 5 Feb 2021 18:36:34 +0100
Subject: bip-0350: fix links for reference implementations

---
 bip-0350.mediawiki | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/bip-0350.mediawiki b/bip-0350.mediawiki
index f34da56..a184380 100644
--- a/bip-0350.mediawiki
+++ b/bip-0350.mediawiki
@@ -138,14 +138,14 @@ On the other hand, the Bech32m proposal breaks forward-compatibility for sending
 ==Reference implementations==
 
 * Reference encoder and decoder:
-** [https://github.com/sipa/bech32/tree/bech32m/ref/python Reference Python implementation]
-** [https://github.com/sipa/bech32/tree/bech32m/ref/c Reference C implementation]
-** [https://github.com/sipa/bech32/tree/bech32m/ref/c++ Reference C++ implementation]
+** [https://github.com/sipa/bech32/blob/master/ref/python Reference Python implementation]
+** [https://github.com/sipa/bech32/blob/master/ref/c Reference C implementation]
+** [https://github.com/sipa/bech32/blob/master/ref/c++ Reference C++ implementation]
 ** [https://github.com/bitcoin/bitcoin/pull/20861 Bitcoin Core C++ implementation]
-** [https://github.com/sipa/bech32/tree/bech32m/ref/javascript Reference Javascript implementation]
+** [https://github.com/sipa/bech32/blob/master/ref/javascript Reference Javascript implementation]
 
 * Fancy decoder that localizes errors:
-** [https://github.com/sipa/bech32/tree/bech32m/ecc/javascript For JavaScript] ([http://bitcoin.sipa.be/bech32/demo/demo.html demo website])
+** [https://github.com/sipa/bech32/blob/master/ecc/javascript For JavaScript] ([http://bitcoin.sipa.be/bech32/demo/demo.html demo website])
 
 ==Test vectors==
 
-- 
cgit v1.2.3


From cd1f225a0bd008efe1be5a1d60af3f68573b0ff4 Mon Sep 17 00:00:00 2001
From: kiminuo <58662979+kiminuo@users.noreply.github.com>
Date: Tue, 15 Dec 2020 10:02:17 +0100
Subject: BIP 155: Remove bitcoin.org link.

---
 bip-0155.mediawiki | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/bip-0155.mediawiki b/bip-0155.mediawiki
index ab3c0fc..19f92f2 100644
--- a/bip-0155.mediawiki
+++ b/bip-0155.mediawiki
@@ -44,8 +44,7 @@ interpreted as described in RFC 2119<ref>[https://tools.ietf.org/html/rfc2119 RF
 
 The <code>addrv2</code> message is defined as a message where <code>pchCommand == "addrv2"</code>.
 It is serialized in the standard encoding for P2P messages.
-Its format is similar to the current <code>addr</code> message format
-<ref>[https://bitcoin.org/en/developer-reference#addr Bitcoin Developer Reference: addr message]</ref>, with the difference that the 
+Its format is similar to the current <code>addr</code> 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 <code>std::vector</code> of the following structure:
-- 
cgit v1.2.3


From 55a31eb8ee304984534e6de8a9ef18691defa983 Mon Sep 17 00:00:00 2001
From: Suhas Daftuar <sdaftuar@gmail.com>
Date: Thu, 11 Feb 2021 13:45:26 -0500
Subject: Add more language in hope of BIP number assignment

---
 bip-disable-tx.mediawiki | 13 +++++++++++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/bip-disable-tx.mediawiki b/bip-disable-tx.mediawiki
index a5f2f77..98789ae 100644
--- a/bip-disable-tx.mediawiki
+++ b/bip-disable-tx.mediawiki
@@ -19,6 +19,10 @@ block-relay-only connections that are currently in use on the network.
 
 ==Motivation==
 
+This proposal is part of an effort to increase the number of inbound
+connections that a peer can service, by distinguishing peers which will not
+relay transactions from those that do.
+
 Since 2019, software has been deployed[1] which initiates
 connections on the Bitcoin network and sets the transaction relay field
 (introduced by BIP 37 and also defined in BIP 60) to false, to prevent
@@ -45,10 +49,15 @@ receive announced addresses instead.
 
 This proposal adds a new, optional message that a node can send a peer when
 initiating a connection to that peer, to indicate that connection should not be
-used for transaction-relay for the connection's lifetime. In addition, without
+used for transaction relay for the connection's lifetime. In addition, without
 a current mechanism to negotiate whether addresses should be relayed on a
 connection, this BIP suggests that address messages not be sent on links where
-tx-relay has been disabled.
+transaction relay has been disabled.
+
+After this BIP is deployed, nodes could more easily implement inbound
+connection limiting that differentiates low-resource nodes (such as those
+sending disabletx) from full-relay peers, potentially allowing for an increase
+in the number of block-relay-only connections that can be made on the network.
 
 ==Specification==
 
-- 
cgit v1.2.3


From 332b9a4854963e8afa8ab89682b9686b79956b95 Mon Sep 17 00:00:00 2001
From: Suhas Daftuar <sdaftuar@gmail.com>
Date: Fri, 12 Feb 2021 08:20:07 -0500
Subject: Note that tx messages are never allowed on disabletx links

---
 bip-disable-tx.mediawiki | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/bip-disable-tx.mediawiki b/bip-disable-tx.mediawiki
index 98789ae..12baf43 100644
--- a/bip-disable-tx.mediawiki
+++ b/bip-disable-tx.mediawiki
@@ -61,7 +61,7 @@ in the number of block-relay-only connections that can be made on the network.
 
 ==Specification==
 
-# A new disabletx message is added, which is defined as an empty message where pchCommand == "disabletx".
+# A new disabletx message is added, which is defined as an empty message with message type set to "disabletx".
 # The protocol version of nodes implementing this BIP must be set to 70017 or higher.
 # If a node sets the transaction relay field in the version message to a peer to false, then the disabletx message MAY also be sent in response to a version message from that peer if the peer's protocol version is >= 70017. If sent, the disabletx message MUST be sent prior to sending a verack.
 # A node that has sent or received a disabletx message to/from a peer MUST NOT send any of these messages to the peer:
@@ -70,6 +70,7 @@ in the number of block-relay-only connections that can be made on the network.
 ## getdata messages for merkleblock (BIP 37)
 ## filteradd/filterload/filterclear (BIP 37)
 ## mempool (BIP 35)
+## tx message
 # It is RECOMMENDED that a node that has sent or received a disabletx message to/from a peer not send any of these messages to the peer:
 ## addr/getaddr
 ## addrv2 (BIP 155)
-- 
cgit v1.2.3


From 31f61e71759c8c205294b2065a8383a91c60b436 Mon Sep 17 00:00:00 2001
From: Suhas Daftuar <sdaftuar@gmail.com>
Date: Fri, 12 Feb 2021 08:46:49 -0500
Subject: Mention compatibility with bip 37

---
 bip-disable-tx.mediawiki | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/bip-disable-tx.mediawiki b/bip-disable-tx.mediawiki
index 12baf43..ace7da1 100644
--- a/bip-disable-tx.mediawiki
+++ b/bip-disable-tx.mediawiki
@@ -96,6 +96,8 @@ Note that all messages specified in BIP 152, including blocktxn and
 getblocktxn, are permitted between peers that have sent/received a disabletx
 message, subject to the feature negotiation of BIP 152.
 
+This proposal is compatible with, but independent of, BIP 37.
+
 ==Implementation==
 
 https://github.com/bitcoin/bitcoin/pull/20726
-- 
cgit v1.2.3


From d2853bcc511989d2ba96c0e3cffe51dd8b042879 Mon Sep 17 00:00:00 2001
From: Luke Dashjr <luke-jr+git@utopios.org>
Date: Fri, 12 Feb 2021 21:02:49 +0000
Subject: Assign BIP 338 for Disable transaction relay message

---
 README.mediawiki         |   7 +++
 bip-0338.mediawiki       | 112 +++++++++++++++++++++++++++++++++++++++++++++++
 bip-disable-tx.mediawiki | 112 -----------------------------------------------
 3 files changed, 119 insertions(+), 112 deletions(-)
 create mode 100644 bip-0338.mediawiki
 delete mode 100644 bip-disable-tx.mediawiki

diff --git a/README.mediawiki b/README.mediawiki
index ca28339..374556c 100644
--- a/README.mediawiki
+++ b/README.mediawiki
@@ -953,6 +953,13 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Standard
 | Draft
 |-
+| [[bip-0338.mediawiki|338]]
+| Peer Services
+| Disable transaction relay message
+| Suhas Daftuar
+| Standard
+| Draft
+|-
 | [[bip-0339.mediawiki|339]]
 | Peer Services
 | WTXID-based transaction relay
diff --git a/bip-0338.mediawiki b/bip-0338.mediawiki
new file mode 100644
index 0000000..4e2c220
--- /dev/null
+++ b/bip-0338.mediawiki
@@ -0,0 +1,112 @@
+<pre>
+  BIP: 338
+  Layer: Peer Services
+  Title: Disable transaction relay message
+  Author: Suhas Daftuar <sdaftuar@chaincode.com>
+  Comments-Summary: No comments yet.
+  Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0338
+  Status: Draft
+  Type: Standards Track
+  Created: 2020-09-03
+  License: BSD-2-Clause
+</pre>
+
+==Abstract==
+
+This BIP describes a change to the p2p protocol to allow a node to tell a peer
+that a connection will not be used for transaction relay, to support
+block-relay-only connections that are currently in use on the network.
+
+==Motivation==
+
+This proposal is part of an effort to increase the number of inbound
+connections that a peer can service, by distinguishing peers which will not
+relay transactions from those that do.
+
+Since 2019, software has been deployed[1] which initiates
+connections on the Bitcoin network and sets the transaction relay field
+(introduced by BIP 37 and also defined in BIP 60) to false, to prevent
+transaction relay from occurring on the connection. Additionally, addr messages
+received from the peer are ignored by this software.
+
+The purpose of these connections is two-fold: by making additional
+low-bandwidth connections on which blocks can propagate, the robustness of a
+node to network partitioning attacks is strengthened.  Additionally, by not
+relaying transactions and ignoring received addresses, the ability of an
+adversary to learn the complete network graph (or a subgraph) is reduced[2],
+which in turn increases the cost or difficulty to an attacker seeking to carry
+out a network partitioning attack (when compared with having such knowledge).
+
+The low-bandwidth / minimal-resource nature of these connections is currently
+known only by the initiator of the connection; this is because the transaction
+relay field in the version message is not a permanent setting for the lifetime
+of the connection.  Consequently, a node receiving an inbound connection with
+transaction relay disabled cannot distinguish between a peer that will never
+enable transaction relay (as described in BIP 37) and one that will.  Moreover,
+the node also cannot determine that the incoming connection will ignore relayed
+addresses; with that knowledge a node would likely choose other peers to
+receive announced addresses instead.
+
+This proposal adds a new, optional message that a node can send a peer when
+initiating a connection to that peer, to indicate that connection should not be
+used for transaction relay for the connection's lifetime. In addition, without
+a current mechanism to negotiate whether addresses should be relayed on a
+connection, this BIP suggests that address messages not be sent on links where
+transaction relay has been disabled.
+
+After this BIP is deployed, nodes could more easily implement inbound
+connection limiting that differentiates low-resource nodes (such as those
+sending disabletx) from full-relay peers, potentially allowing for an increase
+in the number of block-relay-only connections that can be made on the network.
+
+==Specification==
+
+# A new disabletx message is added, which is defined as an empty message with message type set to "disabletx".
+# The protocol version of nodes implementing this BIP must be set to 70017 or higher.
+# If a node sets the transaction relay field in the version message to a peer to false, then the disabletx message MAY also be sent in response to a version message from that peer if the peer's protocol version is >= 70017. If sent, the disabletx message MUST be sent prior to sending a verack.
+# A node that has sent or received a disabletx message to/from a peer MUST NOT send any of these messages to the peer:
+## inv messages for transactions
+## getdata messages for transactions
+## getdata messages for merkleblock (BIP 37)
+## filteradd/filterload/filterclear (BIP 37)
+## mempool (BIP 35)
+## tx message
+# It is RECOMMENDED that a node that has sent or received a disabletx message to/from a peer not send any of these messages to the peer:
+## addr/getaddr
+## addrv2 (BIP 155)
+# The behavior regarding sending or processing other message types is not specified by this BIP.
+# Nodes MAY decide to not remain connected to peers that send this message (for example, if trying to find a peer that will relay transactions).
+
+==Compatibility==
+
+Nodes with protocol version >= 70017 that do not implement this BIP, and nodes
+with protocol version < 70017, will continue to remain compatible with
+implementing software: transactions would not be relayed to peers sending the
+disabletx message (provided that BIP 37 or BIP 60 has been implemented), and while
+periodic address relay may still take place, software implementing this BIP
+should not be disconnecting such peers solely for that reason.
+
+Disabling address relay is suggested but not required by this BIP, to allow for
+future protocol extensions that might specify more carefully how address relay
+is to be negotiated. This BIP's recommendations for software to not relay
+addresses is intended to be interpreted as guidance in the absence of any such
+future protocol extension, to accommodate existing software behavior.
+
+Note that all messages specified in BIP 152, including blocktxn and
+getblocktxn, are permitted between peers that have sent/received a disabletx
+message, subject to the feature negotiation of BIP 152.
+
+This proposal is compatible with, but independent of, BIP 37.
+
+==Implementation==
+
+https://github.com/bitcoin/bitcoin/pull/20726
+
+==References==
+
+# Bitcoin Core has [https://github.com/bitcoin/bitcoin/pull/15759 implemented this functionality] since version 0.19.0.1, released in November 2019.
+# For example, see https://www.cs.umd.edu/projects/coinscope/coinscope.pdf and https://arxiv.org/pdf/1812.00942.pdf.
+
+==Copyright==
+
+This BIP is licensed under the 2-clause BSD license.
diff --git a/bip-disable-tx.mediawiki b/bip-disable-tx.mediawiki
deleted file mode 100644
index ace7da1..0000000
--- a/bip-disable-tx.mediawiki
+++ /dev/null
@@ -1,112 +0,0 @@
-<pre>
-  BIP: XXX
-  Layer: Peer Services
-  Title: Disable transaction relay message
-  Author: Suhas Daftuar <sdaftuar@chaincode.com>
-  Comments-Summary: No comments yet.
-  Comments-URI:
-  Status: Draft
-  Type: Standards Track
-  Created: 2020-09-03
-  License: BSD-2-Clause
-</pre>
-
-==Abstract==
-
-This BIP describes a change to the p2p protocol to allow a node to tell a peer
-that a connection will not be used for transaction relay, to support
-block-relay-only connections that are currently in use on the network.
-
-==Motivation==
-
-This proposal is part of an effort to increase the number of inbound
-connections that a peer can service, by distinguishing peers which will not
-relay transactions from those that do.
-
-Since 2019, software has been deployed[1] which initiates
-connections on the Bitcoin network and sets the transaction relay field
-(introduced by BIP 37 and also defined in BIP 60) to false, to prevent
-transaction relay from occurring on the connection. Additionally, addr messages
-received from the peer are ignored by this software.
-
-The purpose of these connections is two-fold: by making additional
-low-bandwidth connections on which blocks can propagate, the robustness of a
-node to network partitioning attacks is strengthened.  Additionally, by not
-relaying transactions and ignoring received addresses, the ability of an
-adversary to learn the complete network graph (or a subgraph) is reduced[2],
-which in turn increases the cost or difficulty to an attacker seeking to carry
-out a network partitioning attack (when compared with having such knowledge).
-
-The low-bandwidth / minimal-resource nature of these connections is currently
-known only by the initiator of the connection; this is because the transaction
-relay field in the version message is not a permanent setting for the lifetime
-of the connection.  Consequently, a node receiving an inbound connection with
-transaction relay disabled cannot distinguish between a peer that will never
-enable transaction relay (as described in BIP 37) and one that will.  Moreover,
-the node also cannot determine that the incoming connection will ignore relayed
-addresses; with that knowledge a node would likely choose other peers to
-receive announced addresses instead.
-
-This proposal adds a new, optional message that a node can send a peer when
-initiating a connection to that peer, to indicate that connection should not be
-used for transaction relay for the connection's lifetime. In addition, without
-a current mechanism to negotiate whether addresses should be relayed on a
-connection, this BIP suggests that address messages not be sent on links where
-transaction relay has been disabled.
-
-After this BIP is deployed, nodes could more easily implement inbound
-connection limiting that differentiates low-resource nodes (such as those
-sending disabletx) from full-relay peers, potentially allowing for an increase
-in the number of block-relay-only connections that can be made on the network.
-
-==Specification==
-
-# A new disabletx message is added, which is defined as an empty message with message type set to "disabletx".
-# The protocol version of nodes implementing this BIP must be set to 70017 or higher.
-# If a node sets the transaction relay field in the version message to a peer to false, then the disabletx message MAY also be sent in response to a version message from that peer if the peer's protocol version is >= 70017. If sent, the disabletx message MUST be sent prior to sending a verack.
-# A node that has sent or received a disabletx message to/from a peer MUST NOT send any of these messages to the peer:
-## inv messages for transactions
-## getdata messages for transactions
-## getdata messages for merkleblock (BIP 37)
-## filteradd/filterload/filterclear (BIP 37)
-## mempool (BIP 35)
-## tx message
-# It is RECOMMENDED that a node that has sent or received a disabletx message to/from a peer not send any of these messages to the peer:
-## addr/getaddr
-## addrv2 (BIP 155)
-# The behavior regarding sending or processing other message types is not specified by this BIP.
-# Nodes MAY decide to not remain connected to peers that send this message (for example, if trying to find a peer that will relay transactions).
-
-==Compatibility==
-
-Nodes with protocol version >= 70017 that do not implement this BIP, and nodes
-with protocol version < 70017, will continue to remain compatible with
-implementing software: transactions would not be relayed to peers sending the
-disabletx message (provided that BIP 37 or BIP 60 has been implemented), and while
-periodic address relay may still take place, software implementing this BIP
-should not be disconnecting such peers solely for that reason.
-
-Disabling address relay is suggested but not required by this BIP, to allow for
-future protocol extensions that might specify more carefully how address relay
-is to be negotiated. This BIP's recommendations for software to not relay
-addresses is intended to be interpreted as guidance in the absence of any such
-future protocol extension, to accommodate existing software behavior.
-
-Note that all messages specified in BIP 152, including blocktxn and
-getblocktxn, are permitted between peers that have sent/received a disabletx
-message, subject to the feature negotiation of BIP 152.
-
-This proposal is compatible with, but independent of, BIP 37.
-
-==Implementation==
-
-https://github.com/bitcoin/bitcoin/pull/20726
-
-==References==
-
-# Bitcoin Core has [https://github.com/bitcoin/bitcoin/pull/15759 implemented this functionality] since version 0.19.0.1, released in November 2019.
-# For example, see https://www.cs.umd.edu/projects/coinscope/coinscope.pdf and https://arxiv.org/pdf/1812.00942.pdf.
-
-==Copyright==
-
-This BIP is licensed under the 2-clause BSD license.
-- 
cgit v1.2.3


From bb9af2ac042961ceb0b2c573bff23aeaa5ba56e8 Mon Sep 17 00:00:00 2001
From: Luke Dashjr <luke-jr+git@utopios.org>
Date: Fri, 12 Feb 2021 21:04:33 +0000
Subject: README: Fix colour for BIP 79

---
 README.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/README.mediawiki b/README.mediawiki
index dd70653..366e1fa 100644
--- a/README.mediawiki
+++ b/README.mediawiki
@@ -392,7 +392,7 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Nicolas Dorier
 | Standard
 | Draft
-|- style="background-color: #ffffcf"
+|- style="background-color: #ffcfcf"
 | [[bip-0079.mediawiki|79]]
 | Applications
 | Bustapay :: a practical coinjoin protocol
-- 
cgit v1.2.3


From b3d224f384f3bae6e38d4fcf0028b046b414784b Mon Sep 17 00:00:00 2001
From: Andrew Chow <achow101-github@achow101.com>
Date: Thu, 14 Jan 2021 15:04:06 -0500
Subject: Specify BIP 370 PSBTv2

---
 README.mediawiki   |   7 ++
 bip-0174.mediawiki | 189 +++++++++++++++++++++++++++++----
 bip-0370.mediawiki | 305 +++++++++++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 478 insertions(+), 23 deletions(-)
 create mode 100644 bip-0370.mediawiki

diff --git a/README.mediawiki b/README.mediawiki
index dd70653..32b7f68 100644
--- a/README.mediawiki
+++ b/README.mediawiki
@@ -987,6 +987,13 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Pieter Wuille
 | Standard
 | Draft
+|-
+| [[bip-0370.mediawiki|370]]
+| Applications
+| PSBT Version 2
+| Andrew Chow
+| Standard
+| Draft
 |}
 
 <!-- IMPORTANT!  See the instructions at the top of this page, do NOT JUST add BIPs here! -->
diff --git a/bip-0174.mediawiki b/bip-0174.mediawiki
index c034f05..6f50891 100644
--- a/bip-0174.mediawiki
+++ b/bip-0174.mediawiki
@@ -115,9 +115,75 @@ The currently defined global types are as follows:
 | 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
+| 0, 2
 | 174
 |-
+| Transaction Version
+| <tt>PSBT_GLOBAL_TX_VERSION = 0x02</tt>
+| None
+| No key data
+| <tt><32-bit uint></tt>
+| 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-psb2.mediawiki|psbt2]]
+|-
+| Fallback Locktime
+| <tt>PSBT_GLOBAL_FALLBACK_LOCKTIME = 0x03</tt>
+| None
+| No key data
+| <tt><32-bit uint></tt>
+| The 32-bit little endian unsigned integer representing the transaction locktime to use if no inputs specify a required locktime.
+|
+| 0
+| 2
+| [[bip-psb2.mediawiki|psbt2]]
+|-
+| Input Count
+| <tt>PSBT_GLOBAL_INPUT_COUNT = 0x04</tt>
+| None
+| No key data
+| <tt><compact size uint></tt>
+| Compact size unsigned integer representing the number of inputs in this PSBT.
+| 2
+| 0
+| 2
+| [[bip-psb2.mediawiki|psbt2]]
+|-
+| Output Count
+| <tt>PSBT_GLOBAL_OUTPUT_COUNT = 0x05</tt>
+| None
+| No key data
+| <tt><compact size uint></tt>
+| Compact size unsigned integer representing the number of outputs in this PSBT.
+| 2
+| 0
+| 2
+| [[bip-psb2.mediawiki|psbt2]]
+|-
+| Transaction Modifiable Flags
+| <tt>PSBT_GLOBAL_TX_MODIFIABLE = 0x06</tt>
+| None
+| No key data
+| <tt><single byte boolean> <single byte boolean> <bitvector></tt>
+| 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-psb2.mediawiki|psbt2]]
+|-
+| SIGHASH_SINGLE Inputs
+| <tt>PSBT_GLOBAL_SIGHASH_SINGLE_INPUTS = 0x07</tt>
+| None
+| No key data
+| <tt><bit vector></tt>
+| 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-psb2.mediawiki|psbt2]]
+|-
 | PSBT Version Number
 | <tt>PSBT_GLOBAL_VERSION = 0xFB</tt>
 | None
@@ -126,7 +192,7 @@ The currently defined global types are as follows:
 | The 32-bit little endian unsigned integer representing the version number of this PSBT. If ommitted, the version number is 0.
 |
 |
-| 0
+| 0, 2
 | 174
 |-
 | Proprietary Use Type
@@ -137,7 +203,7 @@ The currently defined global types are as follows:
 | Any value data as defined by the proprietary type user.
 |
 |
-| 0
+| 0, 2
 | 174
 |}
 
@@ -163,18 +229,18 @@ The currently defined per-input types are defined as follows:
 | 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 <tt>PSBT_IN_NON_WITNESS_UTXO</tt> and <tt>PSBT_IN_WITNESS_UTXO</tt>. <ref>'''Why can both UTXO types be provided?''' Many wallets began requiring the full previous transaction (i.e. <tt>PSBT_IN_NON_WITNESS_UTXO</tt>) for segwit inputs when PSBT was already in use. In order to be compatible with software which were expecting <tt>PSBT_IN_WITNESS_UTXO</tt>, both UTXO types must be allowed.</ref>
 |
 |
-| 0
+| 0, 2
 | 174
 |-
 | Witness UTXO
 | <tt>PSBT_IN_WITNESS_UTXO = 0x01</tt>
 | None
 | No key data
-| <tt><64-bit uint> <scriptPubKeylen> <scriptPubKey></tt>
+| <tt><64-bit int> <scriptPubKeylen> <scriptPubKey></tt>
 | 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 <tt>PSBT_IN_NON_WITNESS_UTXO</tt> and <tt>PSBT_IN_WITNESS_UTXO</tt>
 |
 |
-| 0
+| 0, 2
 | 174
 |-
 | Partial Signature
@@ -185,7 +251,7 @@ The currently defined per-input types are defined as follows:
 | The signature as would be pushed to the stack from a scriptSig or witness.
 |
 |
-| 0
+| 0, 2
 | 174
 |-
 | Sighash Type
@@ -196,7 +262,7 @@ The currently defined per-input types are defined as follows:
 | 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
+| 0, 2
 | 174
 |-
 | Redeem Script
@@ -207,7 +273,7 @@ The currently defined per-input types are defined as follows:
 | The redeemScript for this input if it has one.
 |
 |
-| 0
+| 0, 2
 | 174
 |-
 | Witness Script
@@ -218,7 +284,7 @@ The currently defined per-input types are defined as follows:
 | The witnessScript for this input if it has one.
 |
 |
-| 0
+| 0, 2
 | 174
 |-
 | BIP 32 Derivation Path
@@ -229,7 +295,7 @@ The currently defined per-input types are defined as follows:
 | 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
+| 0, 2
 | 174
 |-
 | Finalized scriptSig
@@ -240,7 +306,7 @@ The currently defined per-input types are defined as follows:
 | The Finalized scriptSig contains a fully constructed scriptSig with signatures and any other scripts necessary for the input to pass validation.
 |
 |
-| 0
+| 0, 2
 | 174
 |-
 | Finalized scriptWitness
@@ -251,7 +317,7 @@ The currently defined per-input types are defined as follows:
 | The Finalized scriptWitness contains a fully constructed scriptWitness with signatures and any other scripts necessary for the input to pass validation.
 |
 |
-| 0
+| 0, 2
 | 174
 |-
 | Proof-of-reserves commitment
@@ -262,7 +328,7 @@ The currently defined per-input types are defined as follows:
 | The UTF-8 encoded commitment message string for the proof-of-reserves.  See [[bip-0127.mediawiki|BIP 127]] for more information.
 |
 |
-| 0
+| 0, 2
 | [[bip-0127.mediawiki|127]]
 |-
 | RIPEMD160 preimage
@@ -273,7 +339,7 @@ The currently defined per-input types are defined as follows:
 | The hash preimage, encoded as a byte vector, which must equal the key when run through the <tt>RIPEMD160</tt> algorithm
 |
 |
-| 0
+| 0, 2
 | 174
 |-
 | SHA256 preimage
@@ -284,7 +350,7 @@ The currently defined per-input types are defined as follows:
 | The hash preimage, encoded as a byte vector, which must equal the key when run through the <tt>SHA256</tt> algorithm
 |
 |
-| 0
+| 0, 2
 | 174
 |-
 | HASH160 preimage
@@ -295,7 +361,7 @@ The currently defined per-input types are defined as follows:
 | The hash preimage, encoded as a byte vector, which must equal the key when run through the <tt>SHA256</tt> algorithm followed by the <tt>RIPEMD160</tt> algorithm
 |
 |
-| 0
+| 0, 2
 | 174
 |-
 | HASH256 preimage
@@ -306,9 +372,64 @@ The currently defined per-input types are defined as follows:
 | The hash preimage, encoded as a byte vector, which must equal the key when run through the <tt>SHA256</tt> algorithm twice
 |
 |
-| 0
+| 0, 2
 | 174
 |-
+| Previous TXID
+| <tt>PSBT_IN_PREVIOUS_TXID = 0x0e</tt>
+| None
+| No key data
+| <tt><txid></tt>
+| 32 byte txid of the previous transaction whose output at PSBT_IN_OUTPUT_INDEX is being spent.
+| 2
+| 0
+| 2
+| [[bip-psb2.mediawiki|psbt2]]
+|-
+| Spent Output Index
+| <tt>PSBT_IN_OUTPUT_INDEX = 0x0f</tt>
+| None
+| No key data
+| <tt><32-bit uint></tt>
+| 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-psb2.mediawiki|psbt2]]
+|-
+| Sequence Number
+| <tt>PSBT_IN_SEQUENCE = 0x10</tt>
+| None
+| No key data
+| <tt><32-bit uint></tt>
+| 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-psb2.mediawiki|psbt2]]
+|-
+| Required Time-based Locktime
+| <tt>PSBT_IN_REQUIRED_TIME_LOCKTIME = 0x11</tt>
+| None
+| No key data
+| <tt><32-bit uint></tt>
+| 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-psb2.mediawiki|psbt2]]
+|-
+| Required Height-based Locktime
+| <tt>PSBT_IN_REQUIRED_HEIGHT_LOCKTIME = 0x12</tt>
+| None
+| No key data
+| <tt><32-bit uiht></tt>
+| 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-psb2.mediawiki|psbt2]]
+|-
 | Proprietary Use Type
 | <tt>PSBT_IN_PROPRIETARY = 0xFC</tt>
 | <tt><identifierlen> <identifier> <subtype> <subkeydata></tt>
@@ -317,7 +438,7 @@ The currently defined per-input types are defined as follows:
 | Any value data as defined by the proprietary type user.
 |
 |
-| 0
+| 0, 2
 | 174
 |}
 
@@ -345,7 +466,7 @@ determine which outputs are change outputs and verify that the change is returni
 | The redeemScript for this output if it has one.
 |
 |
-| 0
+| 0, 2
 | 174
 |-
 | Witness Script
@@ -356,7 +477,7 @@ determine which outputs are change outputs and verify that the change is returni
 | The witnessScript for this output if it has one.
 |
 |
-| 0
+| 0, 2
 | 174
 |-
 | BIP 32 Derivation Path
@@ -367,9 +488,31 @@ determine which outputs are change outputs and verify that the change is returni
 | The master key fingerprint 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. Public keys are those needed to spend this output.
 |
 |
-| 0
+| 0, 2
 | 174
 |-
+| Output Amount
+| <tt>PSBT_OUT_AMOUNT = 0x03</tt>
+| None
+| No key data
+| <tt><64-bit int></tt>
+| 64 bit signed little endian integer representing the output's amount in satoshis.
+| 2
+| 0
+| 2
+| [[bip-psb2.mediawiki|psbt2]]
+|-
+| Output Script
+| <tt>PSBT_OUT_SCRIPT = 0x03</tt>
+| None
+| No key data
+| <tt><script></tt>
+| The script for this output, also known as the scriptPubKey. Must be omitted in PSBTv0. Must be provided in PSBTv2.
+| 2
+| 0
+| 2
+| [[bip-psb2.mediawiki|psbt2]]
+|-
 | Proprietary Use Type
 | <tt>PSBT_OUT_PROPRIETARY = 0xFC</tt>
 | <tt><identifierlen> <identifier> <subtype> <subkeydata></tt>
@@ -378,7 +521,7 @@ determine which outputs are change outputs and verify that the change is returni
 | Any value data as defined by the proprietary type user.
 |
 |
-| 0
+| 0, 2
 | 174
 |}
 
diff --git a/bip-0370.mediawiki b/bip-0370.mediawiki
new file mode 100644
index 0000000..0bd8764
--- /dev/null
+++ b/bip-0370.mediawiki
@@ -0,0 +1,305 @@
+<pre>
+  BIP: 370
+  Layer: Applications
+  Title: PSBT Version 2
+  Author: Andrew Chow <achow101@gmail.com>
+  Comments-Summary: No comments yet.
+  Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-PSBT2
+  Status: Draft
+  Type: Standards Track
+  Created: 2021-01-14
+  License: BSD-2-Clause
+</pre>
+
+==Introduction==
+
+===Abstract===
+
+This document proposes a second version of the Partially Signed Bitcoin Transaction format
+described in BIP 174 which allows for inputs and outputs to be added to the PSBT after creation.
+
+===Copyright===
+
+This BIP is licensed under the 2-clause BSD license.
+
+===Motivation===
+
+Partially Signed Bitcoin Transaction Version 0 as described in BIP 174 is unable to have new
+inputs and outputs be added to the transaction. The fixed global unsigned transaction
+cannot be changed which prevents any additional inputs or outputs to be added.
+PSBT Version 2 is intended to rectify this problem.
+
+An additional benficial side effect is that all information for a given input or output will be
+provided by its <tt><input-map></tt> or <tt><output-map></tt>. With Version 0, to retrieve
+all of the information for an input or output, data would need to be found in two locations:
+the <tt><input-map></tt>/<tt><output-map></tt> and the global unsigned transaction. PSBT
+Version 2 now moves all related information to one place.
+
+==Specification==
+
+PSBT Version 2 (PSBTv2) only specifies new fields and field inclusion/exclusion requirements.
+
+<tt>PSBT_GLOBAL_UNSIGNED_TX</tt> must be excluded in PSBTv2.
+<tt>PSBT_GLOBAL_VERSION</tt> must be included in PSBTv2 and set to version number 2<ref>'''What happened to version number 1?'''
+Version number 1 is skipped because PSBT Version 0 has been colloquially referred to as version 1. Originally this BIP was to be
+version 1, but because it has been colloquially referred to as version 2 during its design phrase, it was decided to change the
+version number to 2 so that there would not be any confusion</ref>.
+
+The new global types for PSBT Version 2 are as follows:
+
+{|
+! Name
+! <tt><keytype></tt>
+! <tt><keydata></tt>
+! <tt><keydata></tt> Description
+! <tt><valuedata></tt>
+! <tt><valuedata></tt> Description
+! Versions Requiring Inclusion
+! Versions Requiring Exclusion
+! Versions Allowing Inclusion
+|-
+| Transaction Version
+| <tt>PSBT_GLOBAL_TX_VERSION = 0x02</tt>
+| None
+| No key data
+| <tt><32-bit uint></tt>
+| 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
+|-
+| Fallback Locktime
+| <tt>PSBT_GLOBAL_FALLBACK_LOCKTIME = 0x03</tt>
+| None
+| No key data
+| <tt><32-bit uint></tt>
+| The 32-bit little endian unsigned integer representing the transaction locktime to use if no inputs specify a required locktime.
+|
+| 0
+| 2
+|-
+| Input Count
+| <tt>PSBT_GLOBAL_INPUT_COUNT = 0x04</tt>
+| None
+| No key data
+| <tt><compact size uint></tt>
+| Compact size unsigned integer representing the number of inputs in this PSBT.
+| 2
+| 0
+| 2
+|-
+| Output Count
+| <tt>PSBT_GLOBAL_OUTPUT_COUNT = 0x05</tt>
+| None
+| No key data
+| <tt><compact size uint></tt>
+| Compact size unsigned integer representing the number of outputs in this PSBT.
+| 2
+| 0
+| 2
+|-
+| Transaction Modifiable Flags
+| <tt>PSBT_GLOBAL_TX_MODIFIABLE = 0x06</tt>
+| None
+| No key data
+| <tt><8-bit uint></tt>
+| An 8 bit little endian unsigned integer as a bitfield for various transaction modification flags. Bit 0 is the Inputs Modifiable Flag and indicates whether inputs can be modified. Bit 1 is the Outputs Modifiable Flag and indicates whether outputs can be modified. Bit 2 is the Has SIGHASH_SINGLE flag and indicates whether the transaction has a SIGHASH_SINGLE signature who's input and output pairing must be preserved. Bit 2 essentially indicates that the Constructor must iterate the inputs to determine whether and how to add an input.
+|
+| 0
+| 2
+|}
+
+The new per-input types for PSBT Version 2 are defined as follows:
+
+{|
+! Name
+! <tt><keytype></tt>
+! <tt><keydata></tt>
+! <tt><keydata></tt> Description
+! <tt><valuedata></tt>
+! <tt><valuedata></tt> Description
+! Versions Requiring Inclusion
+! Versions Requiring Exclusion
+! Versions Allowing Inclusion
+|-
+| Previous TXID
+| <tt>PSBT_IN_PREVIOUS_TXID = 0x0e</tt>
+| None
+| No key data
+| <tt><txid></tt>
+| 32 byte txid of the previous transaction whose output at PSBT_IN_OUTPUT_INDEX is being spent.
+| 2
+| 0
+| 2
+|-
+| Spent Output Index
+| <tt>PSBT_IN_OUTPUT_INDEX = 0x0f</tt>
+| None
+| No key data
+| <tt><32-bit uint></tt>
+| 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
+|-
+| Sequence Number
+| <tt>PSBT_IN_SEQUENCE = 0x10</tt>
+| None
+| No key data
+| <tt><32-bit uint></tt>
+| 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
+|-
+| Required Time-based Locktime
+| <tt>PSBT_IN_REQUIRED_TIME_LOCKTIME = 0x11</tt>
+| None
+| No key data
+| <tt><32-bit uint></tt>
+| 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
+|-
+| Required Height-based Locktime
+| <tt>PSBT_IN_REQUIRED_HEIGHT_LOCKTIME = 0x12</tt>
+| None
+| No key data
+| <tt><32-bit uiht></tt>
+| 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
+|}
+
+The new per-output types for PSBT Version 2 are defined as follows:
+
+{|
+! Name
+! <tt><keytype></tt>
+! <tt><keydata></tt>
+! <tt><keydata></tt> Description
+! <tt><valuedata></tt>
+! <tt><valuedata></tt> Description
+! Versions Requiring Inclusion
+! Versions Requiring Exclusion
+! Versions Allowing Inclusion
+|-
+| Output Amount
+| <tt>PSBT_OUT_AMOUNT = 0x03</tt>
+| None
+| No key data
+| <tt><64-bit int></tt>
+| 64 bit signed little endian integer representing the output's amount in satoshis.
+| 2
+| 0
+| 2
+|-
+| Output Script
+| <tt>PSBT_OUT_SCRIPT = 0x03</tt>
+| None
+| No key data
+| <tt><script></tt>
+| The script for this output, also known as the scriptPubKey. Must be omitted in PSBTv0. Must be provided in PSBTv2.
+| 2
+| 0
+| 2
+|}
+
+===Determining Lock Time===
+
+The nLockTime field of a transaction is determined by inspecting the PSBT_GLOBAL_PREFERRED_LOCKTIME and each input's PSBT_IN_REQUIRED_TIME_LOCKTIME and PSBT_IN_REQUIRED_HEIGHT_LOCKTIME fields.
+If none of the inputs have a PSBT_IN_REQUIRED_TIME_LOCKTIME and PSBT_IN_REQUIRED_HEIGHT_LOCKTIME, then PSBT_GLOBAL_PREFERRED_LOCKTIME must be used.
+If PSBT_GLOBAL_PREFERRED_LOCKTIME is not provided, then it is assumed to be 0.
+
+If one or more inuts have a PSBT_IN_REQUIRED_TIME_LOCKTIME or PSBT_IN_REQUIRED_HEIGHT_LOCKTIME, then the field chosen is the one which is supported by all of the inputs.
+This can be determined by looking at all of the inputs which specify a locktime in either of those fields, and choosing the field which is present in all of those inputs.
+Inputs not specifying a lock time field can take both types of lock times, as can those that specify both.
+The lock time chosen is then the maximum value of the chosen type of lock time.
+
+===Unique Identification===
+
+PSBTv2s can be uniquely identified by constructing an unsigned transaction given the information provided in the PSBT and computing the transaction ID of that transaction.
+Since PSBT_IN_SEQUENCE can be changed by Updaters and Combiners, the sequence number in this unsigned transaction must be set to 0 (not final, nor the sequence in PSBT_IN_SEQUENCE).
+The lock time in this unsigned transaction must be computed as described previously.
+
+==Roles==
+
+PSBTv2 introduces new roles and modifies some existing roles.
+
+===Creator===
+
+In PSBTv2, the Creator initializes the PSBT with 0 inputs and 0 outputs.
+The PSBT version number is set to 2. The transaction version number must be set to at least 2. <ref>'''Why does the transaction version number need to be at least 2?''' The transaction version number is part of the validation rules for some features such as OP_CHECKSEQUENCEVERIFY. Since it is backwards compatible, and there are other ways to disable those features (e.g. through sequence numbers), it is easier to require transactions be able to support these features than to try to negotiate the transaction version number.</ref>
+The Creator should also set PSBT_GLOBAL_PREFERRED_LOCKTIME.
+If the Creator is not also a Constructor and will be giving the PSBT to others to add inputs and outputs, the PSBT_GLOBAL_TX_MODIFIABLE field must be present and and the Inputs Modifiable and Outputs Modifiable flags set appropriately.
+If the Creator is a Constructor and no inputs and outputs will be added by other entities, PSBT_GLOBAL_TX_MODIFIABLE may be omitted.
+
+===Constructor===
+
+This Constructor is only present for PSBTv2.
+Once a Creator initializes the PSBT, a constructor will add inputs and outputs.
+Before any input or output may be added, the constructor must check the PSBT_GLOBAL_TX_MODIFIABLE field.
+Inputs may only be added if the Inputs Modifiable flag is True.
+Outputs may only be added if the Outputs Modifiable flag is True.
+
+When an input or output is added, the corresponding PSBT_GLOBAL_INPUT_COUNT or PSBT_GLOBAL_OUTPUT_COUNT must be incremeted to reflect the number of inputs and outputs in the PSBT.
+When an input is added, it must have PSBT_IN_PREVIOUS_TXID and PSBT_IN_OUTPUT_INDEX set.
+When an output is added, it must have PSBT_OUT_VALUE and PSBT_OUT_OUTPUT_SCRIPT set.
+If the input has a required timelock, Constructors must set the requisite timelock field.
+If the input has a required time based timelock, then PSBT_IN_REQUIRED_TIME_TIMELOCK must be set
+If the input has a required height based timelock, then PSBT_IN_REQUIRED_HEIGHT_TIMELOCK must be set.
+If an input has both types of timelocks, then both may be set.
+In some cases, an input that can allow both types, but a particular branch supporting only one type of timelock will be taken, then the type of timelock that will be used can be the only one set.
+
+If an input being added specifies a required time lock, then the Constructor must iterate through all of the existing inputs and ensure that the time lock types are compatible.
+Additionally, if during this iteration, it finds that any inputs have signatures, it must ensure that the newly added input does not change the transaction's locktime.
+If the newly added input has an incompatible time lock, then it must not be added.
+If it changes the transaction's locktime when there are existing signatures, it must not be added.
+
+If the Has SIGHASH_SINGLE flag is True, then the Constructor must iterate through the inputs and find the inputs which have signatures that use SIGHASH_SINGLE.
+The same number of inputs and outputs must be added before those inputs and their corresponding outputs.
+
+A Constructor may choose to declare that no further inputs and outputs can be added to the transaction by setting the booleans in PSBT_GLOBAL_TX_MODIFIABLE to False or by removing this field entirely.
+
+A single entity is likely to be both a Creator and Constructor.
+
+===Updater===
+
+For PSBTv2, an Updater can set the sequence number.
+
+===Signer===
+
+For PSBTv2s, a signer must update the PSBT_GLOBAL_TX_MODIFIABLE field after signing inputs so that it accurately reflects the state of the PSBT.
+If the Signer added a signature that does not use SIGHASH_ANYONECANPAY, the Input Modifiable flag must be set to False.
+If the Signer added a signature that does not use SIGHASH_NONE, the Outputs Modifiable flag must be set to False.
+If the Signer added a signature that uses SIGHASH_SINGLE, the Has SIGHASH_SINGLE flag must be set to True.
+
+===Transaction Extractor===
+
+For PSBTv2s, the transaction is constructed using the PSBTv2 fields.
+The lock time for this transaction is determined as described in the Determining Lock Time section.
+The Extractor should produce a fully valid, network serialized transaction if all inputs are complete.
+
+==Backwards Compatibility==
+
+PSBTv2 shares the same gemeric format as PSBTv0 as defined in BIP 174. Parsers for PSBTv0 should
+be able to deserialize PSBTv2 with only changes to support the new fields.
+
+However PSBTv2 is incompatible with PSBTv0, and vice versa due to the use of the PSBT_GLOBAL_VERSION.
+This incompatibility is intentional so that PSBT_GLOBAL_UNSIGNED_TX could be removed in PSBTv2.
+However it is possible to convert a PSBTv2 to a PSBTv0 by creating an unsigned
+transaction from the PSBTv2 fields.
+
+==Test Vectors==
+
+TBD
+
+==Rationale==
+
+<references/>
+
+==Reference implementation==
+
+The reference implementation of the PSBT format is available at https://github.com/achow101/bitcoin/tree/psbt2.
-- 
cgit v1.2.3


From febdf1312a6ba50c8ab938151130d50dcb7096c7 Mon Sep 17 00:00:00 2001
From: Luke Dashjr <luke-jr+git@utopios.org>
Date: Wed, 17 Feb 2021 20:58:22 +0000
Subject: BIP 8: Make threshold a parameter

---
 bip-0008.mediawiki | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/bip-0008.mediawiki b/bip-0008.mediawiki
index 8800b43..2b8f39e 100644
--- a/bip-0008.mediawiki
+++ b/bip-0008.mediawiki
@@ -38,6 +38,7 @@ Each soft fork deployment is specified by the following per-chain parameters (fu
 # The '''bit''' determines which bit in the nVersion field of the block is to be used to signal the soft fork lock-in and activation. It is chosen from the set {0,1,2,...,28}.
 # The '''startheight''' specifies the height of the first block at which the bit gains its meaning.
 # The '''timeoutheight''' specifies a block height at which the miner signalling ends. Once this height has been reached, if the soft fork has not yet locked in (excluding this block's bit state), the deployment is considered failed on all descendants of the block.
+# The '''threshold''' specifies the minimum number of block per retarget period which indicate lock-in of the soft fork during the subsequent period.
 # The '''lockinontimeout''' boolean if set to true, blocks are required to signal in the final period, ensuring the soft fork has locked in by timeoutheight.
 
 ===Selection guidelines===
@@ -48,6 +49,7 @@ The following guidelines are suggested for selecting these parameters for a soft
 # '''bit''' should be selected such that no two concurrent softforks use the same bit.
 # '''startheight''' should be set to some block height in the future, approximately 30 days (or 4320 blocks) after a software release date including the soft fork.  This allows for some release delays, while preventing triggers as a result of parties running pre-release software, and ensures a reasonable number of full nodes have upgraded prior to activation. It should be rounded up to the next height which begins a retarget period for simplicity.
 # '''timeoutheight''' should be 1 year, or 52416 blocks (26 retarget intervals) after '''startheight'''.
+# '''threshold''' should be 1916 blocks (95% of 2016), or 1512 (75%) for testnet.
 # '''lockinontimeout''' should be set to true for any softfork that is expected or found to have political opposition from a non-negligible percent of miners. (It can be set after the initial deployment, but cannot be cleared once set.)
 
 A later deployment using the same bit is possible as long as the startheight is after the previous one's
@@ -122,7 +124,7 @@ We remain in the initial state until we reach the start block height.
 
 After a period in the STARTED state, we tally the bits set,
 and transition to LOCKED_IN if a sufficient number of blocks in the past period set the deployment bit in their
-version numbers. The threshold is ≥1916 blocks (95% of 2016), or ≥1512 for testnet (75% of 2016).
+version numbers.
 If the threshold hasn't been met, lockinontimeout is true, and we are at the last period before the timeout, then we transition to MUST_SIGNAL.
 If the threshold hasn't been met and we reach the timeout, we transition directly to FAILED.
 
-- 
cgit v1.2.3


From 6ea5857b62d37724b1ea6947e0dc847afbc1b644 Mon Sep 17 00:00:00 2001
From: Luke Dashjr <luke-jr+git@utopios.org>
Date: Wed, 17 Feb 2021 20:58:33 +0000
Subject: BIP 8: Reduce threshold recommendation to 90%

---
 bip-0008.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-0008.mediawiki b/bip-0008.mediawiki
index 2b8f39e..5c6c783 100644
--- a/bip-0008.mediawiki
+++ b/bip-0008.mediawiki
@@ -49,7 +49,7 @@ The following guidelines are suggested for selecting these parameters for a soft
 # '''bit''' should be selected such that no two concurrent softforks use the same bit.
 # '''startheight''' should be set to some block height in the future, approximately 30 days (or 4320 blocks) after a software release date including the soft fork.  This allows for some release delays, while preventing triggers as a result of parties running pre-release software, and ensures a reasonable number of full nodes have upgraded prior to activation. It should be rounded up to the next height which begins a retarget period for simplicity.
 # '''timeoutheight''' should be 1 year, or 52416 blocks (26 retarget intervals) after '''startheight'''.
-# '''threshold''' should be 1916 blocks (95% of 2016), or 1512 (75%) for testnet.
+# '''threshold''' should be 1815 blocks (90% of 2016), or 1512 (75%) for testnet.
 # '''lockinontimeout''' should be set to true for any softfork that is expected or found to have political opposition from a non-negligible percent of miners. (It can be set after the initial deployment, but cannot be cleared once set.)
 
 A later deployment using the same bit is possible as long as the startheight is after the previous one's
-- 
cgit v1.2.3


From 663efa52d462b63cf15ba83ad7438e0f04702377 Mon Sep 17 00:00:00 2001
From: Luke Dashjr <luke-jr+git@utopios.org>
Date: Wed, 17 Feb 2021 21:01:03 +0000
Subject: BIP 8: Move recommendation for "name" to "Selection guidelines"

---
 bip-0008.mediawiki | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/bip-0008.mediawiki b/bip-0008.mediawiki
index 8800b43..c09a179 100644
--- a/bip-0008.mediawiki
+++ b/bip-0008.mediawiki
@@ -34,7 +34,7 @@ Block time is somewhat unreliable and may be intentionally or unintentionally in
 
 Each soft fork deployment is specified by the following per-chain parameters (further elaborated below):
 
-# The '''name''' specifies a very brief description of the soft fork, reasonable for use as an identifier. For deployments described in a single BIP, it is recommended to use the name "bipN" where N is the appropriate BIP number.
+# The '''name''' specifies a very brief description of the soft fork, reasonable for use as an identifier.
 # The '''bit''' determines which bit in the nVersion field of the block is to be used to signal the soft fork lock-in and activation. It is chosen from the set {0,1,2,...,28}.
 # The '''startheight''' specifies the height of the first block at which the bit gains its meaning.
 # The '''timeoutheight''' specifies a block height at which the miner signalling ends. Once this height has been reached, if the soft fork has not yet locked in (excluding this block's bit state), the deployment is considered failed on all descendants of the block.
@@ -44,7 +44,7 @@ Each soft fork deployment is specified by the following per-chain parameters (fu
 
 The following guidelines are suggested for selecting these parameters for a soft fork:
 
-# '''name''' should be selected such that no two softforks, concurrent or otherwise, ever use the same name.
+# '''name''' should be selected such that no two softforks, concurrent or otherwise, ever use the same name. For deployments described in a single BIP, it is recommended to use the name "bipN" where N is the appropriate BIP number.
 # '''bit''' should be selected such that no two concurrent softforks use the same bit.
 # '''startheight''' should be set to some block height in the future, approximately 30 days (or 4320 blocks) after a software release date including the soft fork.  This allows for some release delays, while preventing triggers as a result of parties running pre-release software, and ensures a reasonable number of full nodes have upgraded prior to activation. It should be rounded up to the next height which begins a retarget period for simplicity.
 # '''timeoutheight''' should be 1 year, or 52416 blocks (26 retarget intervals) after '''startheight'''.
-- 
cgit v1.2.3


From 1e25eb98f646f546dd1757eabecc016aceb1cbc3 Mon Sep 17 00:00:00 2001
From: Luke Dashjr <luke-jr+git@utopios.org>
Date: Wed, 17 Feb 2021 21:02:51 +0000
Subject: BIP 8: Advise not choosing a bit being used for other things

---
 bip-0008.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-0008.mediawiki b/bip-0008.mediawiki
index c09a179..ddf0890 100644
--- a/bip-0008.mediawiki
+++ b/bip-0008.mediawiki
@@ -45,7 +45,7 @@ Each soft fork deployment is specified by the following per-chain parameters (fu
 The following guidelines are suggested for selecting these parameters for a soft fork:
 
 # '''name''' should be selected such that no two softforks, concurrent or otherwise, ever use the same name. For deployments described in a single BIP, it is recommended to use the name "bipN" where N is the appropriate BIP number.
-# '''bit''' should be selected such that no two concurrent softforks use the same bit.
+# '''bit''' should be selected such that no two concurrent softforks use the same bit. The bit chosen should not overlap with active usage (legitimately or otherwise) for other purposes.
 # '''startheight''' should be set to some block height in the future, approximately 30 days (or 4320 blocks) after a software release date including the soft fork.  This allows for some release delays, while preventing triggers as a result of parties running pre-release software, and ensures a reasonable number of full nodes have upgraded prior to activation. It should be rounded up to the next height which begins a retarget period for simplicity.
 # '''timeoutheight''' should be 1 year, or 52416 blocks (26 retarget intervals) after '''startheight'''.
 # '''lockinontimeout''' should be set to true for any softfork that is expected or found to have political opposition from a non-negligible percent of miners. (It can be set after the initial deployment, but cannot be cleared once set.)
-- 
cgit v1.2.3


From 72bf969a1719aefdbd1094378cfd0386e4e4e9bc Mon Sep 17 00:00:00 2001
From: Luke Dashjr <luke-jr+git@utopios.org>
Date: Wed, 17 Feb 2021 21:07:56 +0000
Subject: BIP 8: Avoid speculating precisely on how soon the economic majority
 might be upgraded

---
 bip-0008.mediawiki | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/bip-0008.mediawiki b/bip-0008.mediawiki
index ddf0890..01c963c 100644
--- a/bip-0008.mediawiki
+++ b/bip-0008.mediawiki
@@ -46,8 +46,8 @@ The following guidelines are suggested for selecting these parameters for a soft
 
 # '''name''' should be selected such that no two softforks, concurrent or otherwise, ever use the same name. For deployments described in a single BIP, it is recommended to use the name "bipN" where N is the appropriate BIP number.
 # '''bit''' should be selected such that no two concurrent softforks use the same bit. The bit chosen should not overlap with active usage (legitimately or otherwise) for other purposes.
-# '''startheight''' should be set to some block height in the future, approximately 30 days (or 4320 blocks) after a software release date including the soft fork.  This allows for some release delays, while preventing triggers as a result of parties running pre-release software, and ensures a reasonable number of full nodes have upgraded prior to activation. It should be rounded up to the next height which begins a retarget period for simplicity.
-# '''timeoutheight''' should be 1 year, or 52416 blocks (26 retarget intervals) after '''startheight'''.
+# '''startheight''' should be set to some block height in the future when a majority of economic activity is expected to have upgraded to a software release including the activation parameters. Some allowance should be made for potential release delays. It should be rounded up to the next height which begins a retarget period for simplicity.
+# '''timeoutheight''' should be set to a block height when it is considered reasonable to expect the entire economy to have upgraded by, probably at least 1 year, or 52416 blocks (26 retarget intervals) after '''startheight'''.
 # '''lockinontimeout''' should be set to true for any softfork that is expected or found to have political opposition from a non-negligible percent of miners. (It can be set after the initial deployment, but cannot be cleared once set.)
 
 A later deployment using the same bit is possible as long as the startheight is after the previous one's
-- 
cgit v1.2.3


From 86e77903bac083f70f19a3356e28eb5174e8cab7 Mon Sep 17 00:00:00 2001
From: Fonta1n3 <fontainedenton@googlemail.com>
Date: Wed, 24 Feb 2021 21:27:15 +0800
Subject: fix: remove legacy references

---
 bip-0048.mediawiki | 15 ---------------
 1 file changed, 15 deletions(-)

diff --git a/bip-0048.mediawiki b/bip-0048.mediawiki
index 2662404..245a066 100644
--- a/bip-0048.mediawiki
+++ b/bip-0048.mediawiki
@@ -92,7 +92,6 @@ The recommended default is pay to witness script hash <code>m/48'/0'/0'/2'</code
 
 <code>1'</code>: Nested Segwit (p2sh-p2wsh) <code>m/48'/0'/0'/1'</code></br>
 <code>2'</code>: Native Segwit (p2wsh) <code>m/48'/0'/0'/2'</code></br>
-<code>3'</code>: Legacy (p2sh) <code>m/48'/0'/0'/3'</code></br>
 
 ===Change===
 
@@ -163,20 +162,6 @@ Public derivation is used at this level.
 |second
 |m / 48' / 0' / 1' / 2' / 0 / 1
 |-
-|mainnet
-|second
-|p2sh
-|change
-|first
-|m / 48' / 0' / 1' / 3' / 1 / 0
-|-
-|mainnet
-|second
-|p2sh
-|change
-|second
-|m / 48' / 1' / 1' / 3' / 1 / 1
-|-
 |testnet
 |first
 |p2sh-p2wsh
-- 
cgit v1.2.3


From bf8c208da516143b75d62241279887e61b86e1bb Mon Sep 17 00:00:00 2001
From: Fonta1n3 <fontainedenton@googlemail.com>
Date: Wed, 24 Feb 2021 21:36:10 +0800
Subject: fix: define motivation, remove account creation blurb.

---
 bip-0048.mediawiki | 18 +++++++++---------
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/bip-0048.mediawiki b/bip-0048.mediawiki
index 245a066..4f8d542 100644
--- a/bip-0048.mediawiki
+++ b/bip-0048.mediawiki
@@ -21,10 +21,16 @@ This BIP is a particular application of BIP43.
 
 ==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.
+
 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.
+
 ==Key sorting==
 
 Any wallet that supports BIP48 inherently supports deterministic key sorting as per BIP67 so that all possible
@@ -75,21 +81,15 @@ This number is used as child index in BIP32 derivation.
 
 Hardened derivation is used at this level.
 
-Software should prevent a creation of an account if a previous account does not
-have a transaction history (meaning none of its addresses have been used before).
-
-Software needs to discover all used accounts after importing the seed from
-an external source. Such an algorithm is described in "Account discovery" chapter.
-
 ===Script===
 
-This level splits the key space into three separate <code>script_type</code>(s). To provide
+This level splits the key space into two separate <code>script_type</code>(s). To provide
 backward and forward compatibility.
 
-The following represent mainnet, account 0:
-
 The recommended default is pay to witness script hash <code>m/48'/0'/0'/2'</code>.
 
+The following represent mainnet, account 0:
+
 <code>1'</code>: Nested Segwit (p2sh-p2wsh) <code>m/48'/0'/0'/1'</code></br>
 <code>2'</code>: Native Segwit (p2wsh) <code>m/48'/0'/0'/2'</code></br>
 
-- 
cgit v1.2.3


From 32d6ee217ab96845a1ead620cfe595c366d2bd79 Mon Sep 17 00:00:00 2001
From: Fonta1n3 <fontainedenton@googlemail.com>
Date: Wed, 24 Feb 2021 21:38:46 +0800
Subject: fix: bip number not actually assigned

---
 bip-0048.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-0048.mediawiki b/bip-0048.mediawiki
index 4f8d542..a266afd 100644
--- a/bip-0048.mediawiki
+++ b/bip-0048.mediawiki
@@ -1,5 +1,5 @@
 <pre>
-  BIP: 48
+  BIP: Number not assigned
   Layer: Applications
   Title: Multi-Account/Multi-Script Hierarchy for Deterministic Multi Signature Wallets
   Author: Peter Denton <dentondevelopment@protonmail.com>
-- 
cgit v1.2.3


From ca77342417f09148f00e8cc5c72f4e25920ac816 Mon Sep 17 00:00:00 2001
From: Antoine Poinsot <darosior@protonmail.com>
Date: Fri, 26 Feb 2021 13:33:36 +0100
Subject: bip8: remove recommendation to force activation after a year

Signed-off-by: Antoine Poinsot <darosior@protonmail.com>
---
 bip-0008.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-0008.mediawiki b/bip-0008.mediawiki
index 01c963c..669574a 100644
--- a/bip-0008.mediawiki
+++ b/bip-0008.mediawiki
@@ -22,7 +22,7 @@ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "S
 
 ==Motivation==
 
-BIP9 introduced a mechanism for doing parallel soft forking deployments based on repurposing the block nVersion field. Activation is dependent on near unanimous hashrate signalling which may be impractical and result in veto by a small minority of non-signalling hashrate. Super majority hashrate based activation triggers allow for accelerated activation where the majority hash power enforces the new rules in lieu of full nodes upgrading. Since all consensus rules are ultimately enforced by full nodes, eventually any new soft fork will be enforced by the economy. This proposal combines these two aspects to provide eventual flag day activation after a reasonable time (recommended a year), as well as for accelerated activation by majority of hash rate before the flag date.
+BIP9 introduced a mechanism for doing parallel soft forking deployments based on repurposing the block nVersion field. Activation is dependent on near unanimous hashrate signalling which may be impractical and result in veto by a small minority of non-signalling hashrate. Super majority hashrate based activation triggers allow for accelerated activation where the majority hash power enforces the new rules in lieu of full nodes upgrading. Since all consensus rules are ultimately enforced by full nodes, eventually any new soft fork will be enforced by the economy. This proposal combines these two aspects to provide eventual flag day activation after a reasonable time, as well as for accelerated activation by majority of hash rate before the flag date.
 
 Due to using timestamps rather than block heights, it was found to be a risk that a sudden loss of significant hashrate could interfere with a late activation.
 
-- 
cgit v1.2.3


From a118ef42a684491f9e4c731c407478d615fabd3c Mon Sep 17 00:00:00 2001
From: Antoine Poinsot <darosior@protonmail.com>
Date: Fri, 26 Feb 2021 13:12:55 +0100
Subject: bip8: mention in intro the forced activation is optional

Signed-off-by: Antoine Poinsot <darosior@protonmail.com>
---
 bip-0008.mediawiki | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/bip-0008.mediawiki b/bip-0008.mediawiki
index 8800b43..9fc285b 100644
--- a/bip-0008.mediawiki
+++ b/bip-0008.mediawiki
@@ -16,13 +16,13 @@
 
 This document specifies an alternative to [[bip-0009.mediawiki|BIP9]] that corrects for a number of perceived mistakes.
 Block heights are used for start and timeout rather than POSIX timestamps.
-It additionally introduces an additional activation parameter to guarantee activation of backward-compatible changes (further called "soft forks").
+It additionally introduces an activation parameter that can guarantee activation of backward-compatible changes (further called "soft forks").
 
 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.
 
 ==Motivation==
 
-BIP9 introduced a mechanism for doing parallel soft forking deployments based on repurposing the block nVersion field. Activation is dependent on near unanimous hashrate signalling which may be impractical and result in veto by a small minority of non-signalling hashrate. Super majority hashrate based activation triggers allow for accelerated activation where the majority hash power enforces the new rules in lieu of full nodes upgrading. Since all consensus rules are ultimately enforced by full nodes, eventually any new soft fork will be enforced by the economy. This proposal combines these two aspects to provide eventual flag day activation after a reasonable time (recommended a year), as well as for accelerated activation by majority of hash rate before the flag date.
+BIP9 introduced a mechanism for doing parallel soft forking deployments based on repurposing the block nVersion field. Activation is dependent on near unanimous hashrate signalling which may be impractical and result in veto by a small minority of non-signalling hashrate. Super majority hashrate based activation triggers allow for accelerated activation where the majority hash power enforces the new rules in lieu of full nodes upgrading. Since all consensus rules are ultimately enforced by full nodes, eventually any new soft fork will be enforced by the economy. This proposal combines these two aspects to provide optional flag day activation after a reasonable time (recommended a year), as well as for accelerated activation by majority of hash rate before the flag date.
 
 Due to using timestamps rather than block heights, it was found to be a risk that a sudden loss of significant hashrate could interfere with a late activation.
 
-- 
cgit v1.2.3


From dd3033f0dd48f930d4eb3d7f2a8faba22d974855 Mon Sep 17 00:00:00 2001
From: Fonta1n3 <fontainedenton@googlemail.com>
Date: Sat, 27 Feb 2021 11:29:31 +0800
Subject: fix: this is specific to an existing standard only

---
 bip-0048.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-0048.mediawiki b/bip-0048.mediawiki
index a266afd..a738408 100644
--- a/bip-0048.mediawiki
+++ b/bip-0048.mediawiki
@@ -84,7 +84,7 @@ Hardened derivation is used at this level.
 ===Script===
 
 This level splits the key space into two separate <code>script_type</code>(s). To provide
-backward and forward compatibility.
+backward compatibility.
 
 The recommended default is pay to witness script hash <code>m/48'/0'/0'/2'</code>.
 
-- 
cgit v1.2.3


From 8a3a8bd04279537066a504de1211a7fb48087526 Mon Sep 17 00:00:00 2001
From: Fonta1n3 <fontainedenton@googlemail.com>
Date: Sun, 28 Feb 2021 09:24:59 +0800
Subject: fix: update to provide for future extensibility

---
 bip-0048.mediawiki | 18 +++++++++++++-----
 1 file changed, 13 insertions(+), 5 deletions(-)

diff --git a/bip-0048.mediawiki b/bip-0048.mediawiki
index a738408..96c01af 100644
--- a/bip-0048.mediawiki
+++ b/bip-0048.mediawiki
@@ -23,7 +23,8 @@ This BIP is a particular application of BIP43.
 
 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.
+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
@@ -84,15 +85,22 @@ Hardened derivation is used at this level.
 ===Script===
 
 This level splits the key space into two separate <code>script_type</code>(s). To provide
-backward compatibility.
+forward compatibility for future script types this specification can be easily extended.
 
-The recommended default is pay to witness script hash <code>m/48'/0'/0'/2'</code>.
-
-The following represent mainnet, account 0:
+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:
 <code>1'</code>: Nested Segwit (p2sh-p2wsh) <code>m/48'/0'/0'/1'</code></br>
+
+The following paths represent Native Segwit (p2wsh) mainnet, account 0:
 <code>2'</code>: Native Segwit (p2wsh) <code>m/48'/0'/0'/2'</code></br>
 
+The recommended default for wallets is pay to witness script hash <code>m/48'/0'/0'/2'</code>.
+
+To add new script types submit a PR to this specification and include it in the list above:
+<code>X'</code>: Future script type <code>m/48'/0'/0'/X'</code></br>
+
 ===Change===
 
 Constant 0 is used for external chain and constant 1 for internal chain (also
-- 
cgit v1.2.3


From 0b667770d821ade047fdebe562e77eb974ed745f Mon Sep 17 00:00:00 2001
From: Fonta1n3 <fontainedenton@googlemail.com>
Date: Sun, 28 Feb 2021 09:48:29 +0800
Subject: fix: typo

---
 bip-0048.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-0048.mediawiki b/bip-0048.mediawiki
index 96c01af..68c0190 100644
--- a/bip-0048.mediawiki
+++ b/bip-0048.mediawiki
@@ -93,7 +93,7 @@ Nested Segwit (p2sh-p2wsh).
 The following path represents Nested Segwit (p2sh-p2wsh) mainnet, account 0:
 <code>1'</code>: Nested Segwit (p2sh-p2wsh) <code>m/48'/0'/0'/1'</code></br>
 
-The following paths represent Native Segwit (p2wsh) mainnet, account 0:
+The following path represents Native Segwit (p2wsh) mainnet, account 0:
 <code>2'</code>: Native Segwit (p2wsh) <code>m/48'/0'/0'/2'</code></br>
 
 The recommended default for wallets is pay to witness script hash <code>m/48'/0'/0'/2'</code>.
-- 
cgit v1.2.3


From c3f7e6fe566299a18384a266471e15630afa657e Mon Sep 17 00:00:00 2001
From: Sanket Kanjalkar <sanket1729@gmail.com>
Date: Mon, 1 Mar 2021 23:01:26 -0800
Subject: Change `witness` to signature

As per my understanding, the value is committed in the signature(sighash msg) and is not being supplied as an additional witness
---
 bip-0118.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-0118.mediawiki b/bip-0118.mediawiki
index 1b2f27c..afbfde6 100644
--- a/bip-0118.mediawiki
+++ b/bip-0118.mediawiki
@@ -92,7 +92,7 @@ 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 <tt>witness</tt> and whose <tt>witnessProgram</tt>,
+value committed to in the signature and whose <tt>witnessProgram</tt>,
 combined with the spending transaction's <tt>witness</tt> returns <tt>true</tt>.
 
 Previously, all information in the transaction was committed in the
-- 
cgit v1.2.3


From 6db1e164861ba71617f132dc8bf8be1421aec8d8 Mon Sep 17 00:00:00 2001
From: "Dr. Maxim Orlovsky" <orlovsky@pandoracore.com>
Date: Tue, 2 Mar 2021 20:26:59 +0100
Subject: Fixing Simple Signer Algorithm

Simple Signer Algorithm was lacking an index argument (last one) on all function calls
---
 bip-0174.mediawiki | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/bip-0174.mediawiki b/bip-0174.mediawiki
index 9f6ad41..8abdb4c 100644
--- a/bip-0174.mediawiki
+++ b/bip-0174.mediawiki
@@ -494,9 +494,9 @@ for input,i in enumerate(psbt.inputs):
         assert(sha256d(non_witness_utxo) == psbt.tx.input[i].prevout.hash)
         if redeemScript.exists:
             assert(non_witness_utxo.vout[psbt.tx.input[i].prevout.n].scriptPubKey == P2SH(redeemScript))
-            sign_non_witness(redeemScript)
+            sign_non_witness(redeemScript, i)
         else:
-            sign_non_witness(non_witness_utxo.vout[psbt.tx.input[i].prevout.n].scriptPubKey)
+            sign_non_witness(non_witness_utxo.vout[psbt.tx.input[i].prevout.n].scriptPubKey, i)
     else if witness_utxo.exists:
         if redeemScript.exists:
             assert(witness_utxo.scriptPubKey == P2SH(redeemScript))
@@ -504,10 +504,10 @@ for input,i in enumerate(psbt.inputs):
         else:
             script = witness_utxo.scriptPubKey
         if IsP2WPKH(script):
-            sign_witness(P2PKH(script[2:22]))
+            sign_witness(P2PKH(script[2:22]), i)
         else if IsP2WSH(script):
             assert(script == P2WSH(witnessScript))
-            sign_witness(witnessScript)
+            sign_witness(witnessScript, i)
     else:
         assert False
 </pre>
-- 
cgit v1.2.3


From eaaf3760991a86c9b509466b0a61c5caeb92e146 Mon Sep 17 00:00:00 2001
From: Andrew Chow <achow101-github@achow101.com>
Date: Thu, 4 Mar 2021 16:14:45 -0500
Subject: 174: Change PSBT unknown fields test to use higher numbers

Previously these tests were using 0x0f as the unknown field number. As
these have now been defined, change them to use 0xf0 instead as it is
unlikely we will use those anything soon.
---
 bip-0174.mediawiki | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/bip-0174.mediawiki b/bip-0174.mediawiki
index 6f50891..f2b6bd3 100644
--- a/bip-0174.mediawiki
+++ b/bip-0174.mediawiki
@@ -857,8 +857,8 @@ The following are valid PSBTs:
 ** Base64 String: <pre>cHNidP8BAFICAAAAAZ38ZijCbFiZ/hvT3DOGZb/VXXraEPYiCXPfLTht7BJ2AQAAAAD/////AfA9zR0AAAAAFgAUezoAv9wU0neVwrdJAdCdpu8TNXkAAAAATwEENYfPAto/0AiAAAAAlwSLGtBEWx7IJ1UXcnyHtOTrwYogP/oPlMAVZr046QADUbdDiH7h1A3DKmBDck8tZFmztaTXPa7I+64EcvO8Q+IM2QxqT64AAIAAAACATwEENYfPAto/0AiAAAABuQRSQnE5zXjCz/JES+NTzVhgXj5RMoXlKLQH+uP2FzUD0wpel8itvFV9rCrZp+OcFyLrrGnmaLbyZnzB1nHIPKsM2QxqT64AAIABAACAAAEBKwBlzR0AAAAAIgAgLFSGEmxJeAeagU4TcV1l82RZ5NbMre0mbQUIZFuvpjIBBUdSIQKdoSzbWyNWkrkVNq/v5ckcOrlHPY5DtTODarRWKZyIcSEDNys0I07Xz5wf6l0F1EFVeSe+lUKxYusC4ass6AIkwAtSriIGAp2hLNtbI1aSuRU2r+/lyRw6uUc9jkO1M4NqtFYpnIhxENkMak+uAACAAAAAgAAAAAAiBgM3KzQjTtfPnB/qXQXUQVV5J76VQrFi6wLhqyzoAiTACxDZDGpPrgAAgAEAAIAAAAAAACICA57/H1R6HV+S36K6evaslxpL0DukpzSwMVaiVritOh75EO3kXMUAAACAAAAAgAEAAIAA</pre>
 
 * Case: PSBT with unknown types in the inputs.
-** Bytes in Hex: <pre>70736274ff01003f0200000001ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff0000000000ffffffff010000000000000000036a010000000000000a0f0102030405060708090f0102030405060708090a0b0c0d0e0f0000</pre>
-** Base64 String: <pre>cHNidP8BAD8CAAAAAf//////////////////////////////////////////AAAAAAD/////AQAAAAAAAAAAA2oBAAAAAAAACg8BAgMEBQYHCAkPAQIDBAUGBwgJCgsMDQ4PAAA=</pre>
+** Bytes in Hex: <pre>70736274ff01003f0200000001ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff0000000000ffffffff010000000000000000036a010000000000000af00102030405060708090f0102030405060708090a0b0c0d0e0f0000</pre>
+** Base64 String: <pre>cHNidP8BAD8CAAAAAf//////////////////////////////////////////AAAAAAD/////AQAAAAAAAAAAA2oBAAAAAAAACvABAgMEBQYHCAkPAQIDBAUGBwgJCgsMDQ4PAAA=</pre>
 
 * Case: PSBT with `PSBT_GLOBAL_XPUB`.
 ** Bytes in Hex: <pre>70736274ff01009d0100000002710ea76ab45c5cb6438e607e59cc037626981805ae9e0dfd9089012abb0be5350100000000ffffffff190994d6a8b3c8c82ccbcfb2fba4106aa06639b872a8d447465c0d42588d6d670000000000ffffffff0200e1f505000000001976a914b6bc2c0ee5655a843d79afedd0ccc3f7dd64340988ac605af405000000001600141188ef8e4ce0449eaac8fb141cbf5a1176e6a088000000004f010488b21e039e530cac800000003dbc8a5c9769f031b17e77fea1518603221a18fd18f2b9a54c6c8c1ac75cbc3502f230584b155d1c7f1cd45120a653c48d650b431b67c5b2c13f27d7142037c1691027569c503100008000000080000000800001011f00e1f5050000000016001433b982f91b28f160c920b4ab95e58ce50dda3a4a220203309680f33c7de38ea6a47cd4ecd66f1f5a49747c6ffb8808ed09039243e3ad5c47304402202d704ced830c56a909344bd742b6852dccd103e963bae92d38e75254d2bb424502202d86c437195df46c0ceda084f2a291c3da2d64070f76bf9b90b195e7ef28f77201220603309680f33c7de38ea6a47cd4ecd66f1f5a49747c6ffb8808ed09039243e3ad5c1827569c5031000080000000800000008000000000010000000001011f00e1f50500000000160014388fb944307eb77ef45197d0b0b245e079f011de220202c777161f73d0b7c72b9ee7bde650293d13f095bc7656ad1f525da5fd2e10b11047304402204cb1fb5f869c942e0e26100576125439179ae88dca8a9dc3ba08f7953988faa60220521f49ca791c27d70e273c9b14616985909361e25be274ea200d7e08827e514d01220602c777161f73d0b7c72b9ee7bde650293d13f095bc7656ad1f525da5fd2e10b1101827569c5031000080000000800000008000000000000000000000220202d20ca502ee289686d21815bd43a80637b0698e1fbcdbe4caed445f6c1a0a90ef1827569c50310000800000008000000080000000000400000000</pre>
@@ -960,16 +960,16 @@ Given the above PSBT, a transaction extractor must create this Bitcoin transacti
 * Bytes in Hex: <pre>0200000000010258e87a21b56daf0c23be8e7070456c336f7cbaa5c8757924f545887bb2abdd7500000000da00473044022074018ad4180097b873323c0015720b3684cc8123891048e7dbcd9b55ad679c99022073d369b740e3eb53dcefa33823c8070514ca55a7dd9544f157c167913261118c01483045022100f61038b308dc1da865a34852746f015772934208c6d24454393cd99bdf2217770220056e675a675a6d0a02b85b14e5e29074d8a25a9b5760bea2816f661910a006ea01475221029583bf39ae0a609747ad199addd634fa6108559d6c5cd39b4c2183f1ab96e07f2102dab61ff49a14db6a7d02b0cd1fbb78fc4b18312b5b4e54dae4dba2fbfef536d752aeffffffff838d0427d0ec650a68aa46bb0b098aea4422c071b2ca78352a077959d07cea1d01000000232200208c2353173743b595dfb4a07b72ba8e42e3797da74e87fe7d9d7497e3b2028903ffffffff0270aaf00800000000160014d85c2b71d0060b09c9886aeb815e50991dda124d00e1f5050000000016001400aea9a2e5f0f876a588df5546e8742d1d87008f000400473044022062eb7a556107a7c73f45ac4ab5a1dddf6f7075fb1275969a7f383efff784bcb202200c05dbb7470dbf2f08557dd356c7325c1ed30913e996cd3840945db12228da5f01473044022065f45ba5998b59a27ffe1a7bed016af1f1f90d54b3aa8f7450aa5f56a25103bd02207f724703ad1edb96680b284b56d4ffcb88f7fb759eabbe08aa30f29b851383d20147522103089dc10c7ac6db54f91329af617333db388cead0c231f723379d1b99030b02dc21023add904f3d6dcf59ddb906b0dee23529b7ffb9ed50e5e86151926860221f0e7352ae00000000</pre>
 
 Given these two PSBTs with unknown key-value pairs:
-* Bytes in Hex: <pre>70736274ff01003f0200000001ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff0000000000ffffffff010000000000000000036a0100000000000a0f0102030405060708090f0102030405060708090a0b0c0d0e0f000a0f0102030405060708090f0102030405060708090a0b0c0d0e0f000a0f0102030405060708090f0102030405060708090a0b0c0d0e0f00</pre>
-** Base64 String: <pre>cHNidP8BAD8CAAAAAf//////////////////////////////////////////AAAAAAD/////AQAAAAAAAAAAA2oBAAAAAAAKDwECAwQFBgcICQ8BAgMEBQYHCAkKCwwNDg8ACg8BAgMEBQYHCAkPAQIDBAUGBwgJCgsMDQ4PAAoPAQIDBAUGBwgJDwECAwQFBgcICQoLDA0ODwA=</pre>
+* Bytes in Hex: <pre>70736274ff01003f0200000001ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff0000000000ffffffff010000000000000000036a0100000000000af00102030405060708090f0102030405060708090a0b0c0d0e0f000af00102030405060708090f0102030405060708090a0b0c0d0e0f000af00102030405060708090f0102030405060708090a0b0c0d0e0f00</pre>
+** Base64 String: <pre>cHNidP8BAD8CAAAAAf//////////////////////////////////////////AAAAAAD/////AQAAAAAAAAAAA2oBAAAAAAAK8AECAwQFBgcICQ8BAgMEBQYHCAkKCwwNDg8ACvABAgMEBQYHCAkPAQIDBAUGBwgJCgsMDQ4PAArwAQIDBAUGBwgJDwECAwQFBgcICQoLDA0ODwA=</pre>
 
-* Bytes in Hex: <pre>70736274ff01003f0200000001ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff0000000000ffffffff010000000000000000036a0100000000000a0f0102030405060708100f0102030405060708090a0b0c0d0e0f000a0f0102030405060708100f0102030405060708090a0b0c0d0e0f000a0f0102030405060708100f0102030405060708090a0b0c0d0e0f00</pre>
-** Base64 String: <pre>cHNidP8BAD8CAAAAAf//////////////////////////////////////////AAAAAAD/////AQAAAAAAAAAAA2oBAAAAAAAKDwECAwQFBgcIEA8BAgMEBQYHCAkKCwwNDg8ACg8BAgMEBQYHCBAPAQIDBAUGBwgJCgsMDQ4PAAoPAQIDBAUGBwgQDwECAwQFBgcICQoLDA0ODwA=</pre>
+* Bytes in Hex: <pre>70736274ff01003f0200000001ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff0000000000ffffffff010000000000000000036a0100000000000af00102030405060708100f0102030405060708090a0b0c0d0e0f000af00102030405060708100f0102030405060708090a0b0c0d0e0f000af00102030405060708100f0102030405060708090a0b0c0d0e0f00</pre>
+** Base64 String: <pre>cHNidP8BAD8CAAAAAf//////////////////////////////////////////AAAAAAD/////AQAAAAAAAAAAA2oBAAAAAAAK8AECAwQFBgcIEA8BAgMEBQYHCAkKCwwNDg8ACvABAgMEBQYHCBAPAQIDBAUGBwgJCgsMDQ4PAArwAQIDBAUGBwgQDwECAwQFBgcICQoLDA0ODwA=</pre>
 
 A combiner which orders keys lexicographically must produce the following PSBT:
 
-* Bytes in Hex: <pre>70736274ff01003f0200000001ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff0000000000ffffffff010000000000000000036a0100000000000a0f0102030405060708090f0102030405060708090a0b0c0d0e0f0a0f0102030405060708100f0102030405060708090a0b0c0d0e0f000a0f0102030405060708090f0102030405060708090a0b0c0d0e0f0a0f0102030405060708100f0102030405060708090a0b0c0d0e0f000a0f0102030405060708090f0102030405060708090a0b0c0d0e0f0a0f0102030405060708100f0102030405060708090a0b0c0d0e0f00</pre>
-* Base64 String: <pre>cHNidP8BAD8CAAAAAf//////////////////////////////////////////AAAAAAD/////AQAAAAAAAAAAA2oBAAAAAAAKDwECAwQFBgcICQ8BAgMEBQYHCAkKCwwNDg8KDwECAwQFBgcIEA8BAgMEBQYHCAkKCwwNDg8ACg8BAgMEBQYHCAkPAQIDBAUGBwgJCgsMDQ4PCg8BAgMEBQYHCBAPAQIDBAUGBwgJCgsMDQ4PAAoPAQIDBAUGBwgJDwECAwQFBgcICQoLDA0ODwoPAQIDBAUGBwgQDwECAwQFBgcICQoLDA0ODwA=</pre>
+* Bytes in Hex: <pre>70736274ff01003f0200000001ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff0000000000ffffffff010000000000000000036a0100000000000af00102030405060708090f0102030405060708090a0b0c0d0e0f0af00102030405060708100f0102030405060708090a0b0c0d0e0f000af00102030405060708090f0102030405060708090a0b0c0d0e0f0af00102030405060708100f0102030405060708090a0b0c0d0e0f000af00102030405060708090f0102030405060708090a0b0c0d0e0f0af00102030405060708100f0102030405060708090a0b0c0d0e0f00</pre>
+* Base64 String: <pre>cHNidP8BAD8CAAAAAf//////////////////////////////////////////AAAAAAD/////AQAAAAAAAAAAA2oBAAAAAAAK8AECAwQFBgcICQ8BAgMEBQYHCAkKCwwNDg8K8AECAwQFBgcIEA8BAgMEBQYHCAkKCwwNDg8ACvABAgMEBQYHCAkPAQIDBAUGBwgJCgsMDQ4PCvABAgMEBQYHCBAPAQIDBAUGBwgJCgsMDQ4PAArwAQIDBAUGBwgJDwECAwQFBgcICQoLDA0ODwrwAQIDBAUGBwgQDwECAwQFBgcICQoLDA0ODwA=</pre>
 
 ==Rationale==
 
-- 
cgit v1.2.3


From a29c14f66464b411db44a5a369a2cad5d8e5b44a Mon Sep 17 00:00:00 2001
From: "Dr. Maxim Orlovsky" <orlovsky@pandoracore.com>
Date: Sat, 6 Mar 2021 02:13:08 +0100
Subject: Removing size param (not used anymore)

---
 bip-0021.mediawiki | 1 -
 1 file changed, 1 deletion(-)

diff --git a/bip-0021.mediawiki b/bip-0021.mediawiki
index cfab856..8aec855 100644
--- a/bip-0021.mediawiki
+++ b/bip-0021.mediawiki
@@ -58,7 +58,6 @@ 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 ====
-- 
cgit v1.2.3


From 726cbf100cae0b1b7ada4b2e01977799fcfdd364 Mon Sep 17 00:00:00 2001
From: Matthijs Roelink <matthijs@roelink.eu>
Date: Sat, 6 Mar 2021 20:24:56 +0100
Subject: Fix typos in BIP 2

---
 bip-0002.mediawiki | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/bip-0002.mediawiki b/bip-0002.mediawiki
index 3bf5aec..35d38c2 100644
--- a/bip-0002.mediawiki
+++ b/bip-0002.mediawiki
@@ -192,7 +192,7 @@ A BIP may only change status from Draft (or Rejected) to Proposed, when the auth
 
 BIPs should be changed from Draft or Proposed status, to Rejected status, upon request by any person, if they have not made progress in three years. Such a BIP may be changed to Draft status if the champion provides revisions that meaningfully address public criticism of the proposal, or to Proposed status if it meets the criteria required as described in the previous paragraph.
 
-An Proposed BIP may progress to Final only when specific criteria reflecting real-world adoption has occurred. This is different for each BIP depending on the nature of its proposed changes, which will be expanded on below. Evaluation of this status change should be objectively verifiable, and/or be discussed on the development mailing list.
+A Proposed BIP may progress to Final only when specific criteria reflecting real-world adoption has occurred. This is different for each BIP depending on the nature of its proposed changes, which will be expanded on below. Evaluation of this status change should be objectively verifiable, and/or be discussed on the development mailing list.
 
 When a Final BIP is no longer relevant, its status may be changed to Replaced or Obsolete (which is equivalent to Replaced). This change must also be objectively verifiable and/or discussed.
 
@@ -326,7 +326,7 @@ For example, a preamble might include the following License header:
 
 In this case, the BIP text is fully licensed under both the OSI-approved BSD 2-clause license as well as the GNU All-Permissive License, and anyone may modify and redistribute the text provided they comply with the terms of *either* license. In other words, the license list is an "OR choice", not an "AND also" requirement.
 
-It is also possible to license source code differently from the BIP text. A optional License-Code header is placed after the License header. Again, each license must be referenced by their respective abbreviation given below.
+It is also possible to license source code differently from the BIP text. An optional License-Code header is placed after the License header. Again, each license must be referenced by their respective abbreviation given below.
 
 For example, a preamble specifying the optional License-Code header might look like:
 
-- 
cgit v1.2.3


From 38d245421041b57ebc6f8e45b7c3a5322c5f9292 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?D=C3=A1vid=20Moln=C3=A1r?= <molnardavid84@gmail.com>
Date: Tue, 9 Mar 2021 09:09:52 +0100
Subject: Fix word duplication

---
 bip-0078.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-0078.mediawiki b/bip-0078.mediawiki
index c795343..25bff0e 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.
 
-- 
cgit v1.2.3


From 3635e0ec66b2c0dae13b7c87e888d59eefeb2733 Mon Sep 17 00:00:00 2001
From: 8go <cccc@tuta.io>
Date: Tue, 9 Mar 2021 17:12:08 +0000
Subject: fixed some typos and minor English mistakes

---
 bip-0085.mediawiki | 28 ++++++++++++++--------------
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/bip-0085.mediawiki b/bip-0085.mediawiki
index cbd3a2a..e885e2d 100644
--- a/bip-0085.mediawiki
+++ b/bip-0085.mediawiki
@@ -35,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: <code>HMAC-SHA512(key="bip-entropy-from-k", msg=k)</code>. 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: <code>HMAC-SHA512(key="bip-entropy-from-k", msg=k)</code>. 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].
 
@@ -104,18 +104,18 @@ OUTPUT
 
 ==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 <code>m/83696968'/{app_no}'/{index}'</code> where ''{app_no}'' path for the application, and ''{index}'' in the index.
+Derivation path uses the format <code>m/83696968'/{app_no}'/{index}'</code> 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: <code>m/83696968'/39'/{language}'/{words}'/{index}'</code>
 
-Example a BIP39 mnemonic with 12 English words (first index) would have the path <code>m/83696968'/39'/0'/12'/0'</code> the next key would be <code>m/83696968'/39'/0'/12'/1'</code> etc.
+Example: a BIP39 mnemonic with 12 English words (first index) would have the path <code>m/83696968'/39'/0'/12'/0'</code>, the next key would be <code>m/83696968'/39'/0'/12'/1'</code> etc.
 
 Language Table
 
@@ -284,17 +284,17 @@ 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 dual purpose.
+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==
 
@@ -306,10 +306,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 parse<sub>256</sub>(I<sub>L</sub>) 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 2<sup>127</sup>.)
+In case parse<sub>256</sub>(I<sub>L</sub>) 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 2<sup>127</sup>.)
 
 ==Copyright==
 
-- 
cgit v1.2.3


From 675c3a8703d79e09807d6426c73f7c301c1d3eb7 Mon Sep 17 00:00:00 2001
From: Robert Spigler <RobertSpigler@ProtonMail.ch>
Date: Thu, 11 Mar 2021 03:11:51 -0500
Subject: Create Multisig Derivation Standard.mediawiki

Draft
---
 Multisig Derivation Standard.mediawiki | 237 +++++++++++++++++++++++++++++++++
 1 file changed, 237 insertions(+)
 create mode 100644 Multisig Derivation Standard.mediawiki

diff --git a/Multisig Derivation Standard.mediawiki b/Multisig Derivation Standard.mediawiki
new file mode 100644
index 0000000..6d11c6e
--- /dev/null
+++ b/Multisig Derivation Standard.mediawiki	
@@ -0,0 +1,237 @@
+<pre>
+  BIP: Number not assigned
+  Layer: Applications
+  Title: Modern Hierarchy for Deterministic Multisignature Wallets
+  Author: Robert Spigler <RobertSpigler@ProtonMail.ch>
+  Comments-Summary: No comments
+  Comments-URI:
+  Status: Proposed
+  Type: Standards Track
+  Created: 2020-03-11
+</pre>
+
+===Copyright===
+
+This BIP is licensed under the 2-clause BSD license.
+
+==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.
+
+==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.
+
+There are many issues with the current standards. As background, BIP 44/49/84 specifies:
+
+<pre>
+m / purpose' / coin_type' / account' / change / address_index
+</pre>
+
+where the BIP43 <code>purpose'</code> path is separate for each script (P2PKH, P2WPKH-in-P2SH, and P2WPKH respectively).  However, these per-script derivations 
+are made redundant with descriptors, which describe a collection of output scripts.  Note also that these are single sig derivations (which souldn't be reused for 
+multisig).
+
+Standardization is needed for multisig derivation paths.  There are some in existence, but all have issues.  For example, BIP45 specifies:
+
+<pre>
+m / purpose' / cosigner_index / change / address_index
+</pre>
+
+Like BIP44/49/84, BIP45 unecessarily demands a single script type (here, P2SH).  In addition, BIP45 sets <code>cosigner_index</code> in order to sort the 
+<code>purpose'</code> public keys of each cosigner.  This too is redundant, as descriptors can set the order of the public keys with <code>multi</code> or have 
+them sorted lexicographically (as described in [https://github.com/bitcoin/bips/blob/master/bip-0067.mediawiki BIP67) with <code>sortedmulti</code>.  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.
+
+There is an additional multisig derivation path in use "BIP"48 (there is no real standard), which specifies:
+
+<pre>
+m / purpose' / coin_type' / account' / script_type' / change / address_index
+</pre>
+
+Rather than having a separate BIP per script type after P2SH (BIP45), vendors decided to insert <code>script_type'</code> 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 hierarchy proposed in this paper is quite comprehensive. It allows the handling of multiple accounts, external and internal chains per account, and millions 
+of addresses per chain.
+
+Any script that is supported by descriptors (and the specific wallet implementation) is compatible with this BIP.
+
+This paper was inspired from BIP44.
+
+==Key sorting==
+
+Any wallet that supports descriptors inherently supports deterministic key sorting as per BIP67 (through the <code>sortedmulti</code> function) so that all 
+possible multisignature addresses/scripts are derived from deterministically sorted public keys.
+
+==Path levels==
+
+You should not be mixing keys and scripts. We define the following 5 levels in the BIP32 path:
+
+<pre>
+m / purpose' / coin_type' / account' / change / address_index
+</pre>
+
+<code>h</code> or <code>'</code> 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 XY' 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 <code>0</code> for mainnet and <code>1</code> 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.
+
+===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
+|chain
+|address
+|path
+|-
+|mainnet
+|first
+|external
+|first
+|m / XY' / 0' / 0' / 0 / 0
+|-
+|mainnet
+|first
+|external
+|second
+|m / XY' / 0' / 0' / 0 / 1
+|-
+|mainnet
+|first
+|change
+|first
+|m / XY' / 0' / 0' / 1 / 0
+|-
+|mainnet
+|first
+|change
+|second
+|m / XY' / 0' / 0' / 1 / 1
+|-
+|mainnet
+|second
+|external
+|first
+|m / XY' / 0' / 1' / 0 / 0
+|-
+|mainnet
+|second
+|external
+|second
+|m / XY' / 0' / 1' / 0 / 1
+|-
+|testnet
+|first
+|external
+|first
+|m / XY' / 1' / 0' / 0 / 0
+|-
+|testnet
+|first
+|external
+|second
+|m / XY' / 1' / 0' / 0 / 1
+|-
+|testnet
+|first
+|change
+|first
+|m / XY' / 1' / 0' / 1 / 0
+|-
+|testnet
+|first
+|change
+|second
+|m / XY' / 1' / 0' / 1 / 1
+|-
+|testnet
+|second
+|external
+|first
+|m / XY' / 1' / 1' / 0 / 0
+|-
+|testnet
+|second
+|external
+|second
+|m / XY' / 1' / 1' / 0 / 1
+|-
+|testnet
+|second
+|change
+|first
+|m / XY' / 1' / 1' / 1 / 0
+|-
+|testnet
+|second
+|change
+|second
+|m / XY' / 1' / 1' / 1 / 1
+|}
+
+==Acknowledgement==
+
+
+==References==
+
+Original mailing list thread: TBD
+
+* [[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]]
+* [[https://github.com/bitcoin/bitcoin/blob/master/doc/descriptors.md - Output Descriptors]]
+* [[bip-0174.mediawiki|BIP174 - Partially Signed Bitcoin Transaction Format]]
+* [[bip-0067.mediawiki|BIP67 - Deterministic Pay-to-script-hash multi-signature addresses through public key sorting]]
-- 
cgit v1.2.3


From a067f9ca085e296d383399aa62e1752b09117523 Mon Sep 17 00:00:00 2001
From: Robert Spigler <RobertSpigler@ProtonMail.ch>
Date: Thu, 11 Mar 2021 16:17:51 -0500
Subject: Formatting

---
 Multisig Derivation Standard.mediawiki | 41 +++++++++++-----------------------
 1 file changed, 13 insertions(+), 28 deletions(-)

diff --git a/Multisig Derivation Standard.mediawiki b/Multisig Derivation Standard.mediawiki
index 6d11c6e..e44dcdc 100644
--- a/Multisig Derivation Standard.mediawiki	
+++ b/Multisig Derivation Standard.mediawiki	
@@ -16,16 +16,13 @@ This BIP is licensed under the 2-clause BSD license.
 
 ==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 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.
 
 ==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.
+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.
 
 There are many issues with the current standards. As background, BIP 44/49/84 specifies:
 
@@ -33,9 +30,7 @@ There are many issues with the current standards. As background, BIP 44/49/84 sp
 m / purpose' / coin_type' / account' / change / address_index
 </pre>
 
-where the BIP43 <code>purpose'</code> path is separate for each script (P2PKH, P2WPKH-in-P2SH, and P2WPKH respectively).  However, these per-script derivations 
-are made redundant with descriptors, which describe a collection of output scripts.  Note also that these are single sig derivations (which souldn't be reused for 
-multisig).
+where the BIP43 <code>purpose'</code> path is separate for each script (P2PKH, P2WPKH-in-P2SH, and P2WPKH respectively).  However, these per-script derivations are made redundant with descriptors, which describe a collection of output scripts.  Note also that these are single sig derivations (which shouldn't be reused for multisig).
 
 Standardization is needed for multisig derivation paths.  There are some in existence, but all have issues.  For example, BIP45 specifies:
 
@@ -43,24 +38,17 @@ Standardization is needed for multisig derivation paths.  There are some in exis
 m / purpose' / cosigner_index / change / address_index
 </pre>
 
-Like BIP44/49/84, BIP45 unecessarily demands a single script type (here, P2SH).  In addition, BIP45 sets <code>cosigner_index</code> in order to sort the 
-<code>purpose'</code> public keys of each cosigner.  This too is redundant, as descriptors can set the order of the public keys with <code>multi</code> or have 
-them sorted lexicographically (as described in [https://github.com/bitcoin/bips/blob/master/bip-0067.mediawiki BIP67) with <code>sortedmulti</code>.  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.
+Like BIP44/49/84, BIP45 unecessarily demands a single script type (here, P2SH).  In addition, BIP45 sets <code>cosigner_index</code> in order to sort the <code>purpose'</code> public keys of each cosigner.  This too is redundant, as descriptors can set the order of the public keys with <code>multi</code> or have them sorted lexicographically (as described in [https://github.com/bitcoin/bips/blob/master/bip-0067.mediawiki BIP67]) with <code>sortedmulti</code>.  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.
 
-There is an additional multisig derivation path in use "BIP"48 (there is no real standard), which specifies:
+The second multisignature "standard" in use is m/48', which specifies:
 
 <pre>
 m / purpose' / coin_type' / account' / script_type' / change / address_index
 </pre>
 
-Rather than having a separate BIP per script type after P2SH (BIP45), vendors decided to insert <code>script_type'</code> 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.
+Rather than having a separate BIP per script after P2SH (BIP45), vendors decided to insert <code>script_type'</code> 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, <code>script_type</code> list.
 
-The hierarchy proposed in this paper is quite comprehensive. It allows the handling of multiple accounts, external and internal chains per account, and millions 
-of addresses per chain.
+The hierarchy proposed later in this paper solves these issues and is quite comprehensive. It allows the handling of multiple accounts, external and internal chains per account, and millions of addresses per chain.
 
 Any script that is supported by descriptors (and the specific wallet implementation) is compatible with this BIP.
 
@@ -68,8 +56,7 @@ This paper was inspired from BIP44.
 
 ==Key sorting==
 
-Any wallet that supports descriptors inherently supports deterministic key sorting as per BIP67 (through the <code>sortedmulti</code> function) so that all 
-possible multisignature addresses/scripts are derived from deterministically sorted public keys.
+Any wallet that supports descriptors inherently supports deterministic key sorting as per BIP67 (through the <code>sortedmulti</code> function) so that all possible multisignature addresses/scripts are derived from deterministically sorted public keys.
 
 ==Path levels==
 
@@ -95,7 +82,7 @@ Hardened derivation is used at this level.
 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.
+This level creates a separate subtree for every network, avoiding reusing addresses across networks and improving privacy issues.
 
 Coin type <code>0</code> for mainnet and <code>1</code> for testnet.
 
@@ -105,8 +92,7 @@ Hardened derivation is used at this level.
 
 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.
+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.
@@ -115,9 +101,7 @@ Hardened derivation is used at this level.
 
 ===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.
+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.
 
@@ -232,6 +216,7 @@ Original mailing list thread: TBD
 * [[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]]
-* [[https://github.com/bitcoin/bitcoin/blob/master/doc/descriptors.md - Output Descriptors]]
+* [https://github.com/bitcoin/bitcoin/blob/master/doc/descriptors.md Output Descriptors]
 * [[bip-0174.mediawiki|BIP174 - Partially Signed Bitcoin Transaction Format]]
 * [[bip-0067.mediawiki|BIP67 - Deterministic Pay-to-script-hash multi-signature addresses through public key sorting]]
+
-- 
cgit v1.2.3


From ef3a16eeec646da955591371127c103da33aa80a Mon Sep 17 00:00:00 2001
From: Robert Spigler <RobertSpigler@ProtonMail.ch>
Date: Fri, 12 Mar 2021 16:57:55 -0500
Subject: Update and rename Multisig Derivation Standard.mediawiki to Modern
 Derivation Standard.mediawiki

Multisig and singlesig support
---
 Modern Derivation Standard.mediawiki   | 227 +++++++++++++++++++++++++++++++++
 Multisig Derivation Standard.mediawiki | 222 --------------------------------
 2 files changed, 227 insertions(+), 222 deletions(-)
 create mode 100644 Modern Derivation Standard.mediawiki
 delete mode 100644 Multisig Derivation Standard.mediawiki

diff --git a/Modern Derivation Standard.mediawiki b/Modern Derivation Standard.mediawiki
new file mode 100644
index 0000000..c8d5a84
--- /dev/null
+++ b/Modern Derivation Standard.mediawiki	
@@ -0,0 +1,227 @@
+<pre>
+  BIP: Number not assigned
+  Layer: Applications
+  Title: Signature and Script Independant Hierarchy for Deterministic Wallets
+  Author: Robert Spigler <RobertSpigler@ProtonMail.ch>
+  Comments-Summary: No comments
+  Comments-URI:
+  Status: Proposed
+  Type: Standards Track
+  Created: 2020-03-11
+</pre>
+
+===Copyright===
+
+This BIP is licensed under the 2-clause BSD license.
+
+==Abstract==
+
+This BIP defines a sane hierarchy for deterministic 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.
+
+==Motivation==
+
+With the increase of adoption of new technologies such as [https://github.com/bitcoin/bitcoin/blob/master/doc/descriptors.md the descriptor language] it is necessary to create a common derivation scheme that makes use of all new technologies.
+
+There are many issues with the current standards. As background, BIP 44/49/84 specifies:
+
+<pre>
+m / purpose' / coin_type' / account' / change / address_index
+</pre>
+
+where the BIP43 <code>purpose'</code> path is separate for each script (P2PKH, P2WPKH-in-P2SH, and P2WPKH respectively).  However, these per-script derivations are made redundant with descriptors, which describe a collection of output scripts.  Note also that these BIPs are restricted for single sig wallets. This is unecessary, as descriptors handle whether the scripts are single-key or multi-key.
+
+Modification is also needed for multisig derivation paths.  For example, BIP45 specifies:
+
+<pre>
+m / purpose' / cosigner_index / change / address_index
+</pre>
+
+Like BIP44/49/84, BIP45 unecessarily demands a single script type (here, P2SH).  In addition, BIP45 sets <code>cosigner_index</code> in order to sort the <code>purpose'</code> public keys of each cosigner.  This too is redundant, as descriptors can set the order of the public keys with <code>multi</code> or have them sorted lexicographically (as described in [https://github.com/bitcoin/bips/blob/master/bip-0067.mediawiki BIP67]) with <code>sortedmulti</code>.  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:
+
+<pre>
+m / purpose' / coin_type' / account' / script_type' / change / address_index
+</pre>
+
+Rather than following in BIP 44/49/84's path and having a separate BIP per script after P2SH (BIP45), vendors decided to insert <code>script_type'</code> 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, <code>script_type</code> list.
+
+The hierarchy proposed later in this paper solves these issues and is quite comprehensive. It allows the handling of multiple accounts, external and internal chains per account, and millions of addresses per chain, regardless of the script or signature type.
+
+Any script that is supported by descriptors (and the specific wallet implementation) is compatible with this BIP.
+
+This paper was inspired from BIP44.
+
+==Key sorting==
+
+Any wallet that supports descriptors inherently supports deterministic key sorting as per BIP67 (through the <code>sortedmulti</code> 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 or signature type, whereas the descriptor language tells wallets to watch (single or multi-sig) outputs with the specified public keys.
+
+We define the following 5 levels in the BIP32 path:
+
+<pre>
+m / purpose' / coin_type' / account' / change / address_index
+</pre>
+
+<code>h</code> or <code>'</code> 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 XY' 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 <code>0</code> for mainnet and <code>1</code> 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.
+
+It is crucial that the index is increased for each new wallet joined or private/public keys created; for both privacy and cryptographic purposes.
+For example, in multisignature wallets, before sending a new key record to a coordinator, the wallet must increment the <code>account'</code> level.  Before creating it's own single signature wallet, the <code>account'</code> level must again be incremented.
+This prevents key reuse - across single signature and multisignature wallets, across ECDSA and Schnorr signatures, 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.
+
+==Examples==
+
+{|
+|network
+|account
+|chain
+|address
+|path
+|-
+|mainnet
+|first
+|external
+|first
+|m / XY' / 0' / 0' / 0 / 0
+|-
+|mainnet
+|first
+|external
+|second
+|m / XY' / 0' / 0' / 0 / 1
+|-
+|mainnet
+|first
+|change
+|first
+|m / XY' / 0' / 0' / 1 / 0
+|-
+|mainnet
+|first
+|change
+|second
+|m / XY' / 0' / 0' / 1 / 1
+|-
+|mainnet
+|second
+|external
+|first
+|m / XY' / 0' / 1' / 0 / 0
+|-
+|mainnet
+|second
+|external
+|second
+|m / XY' / 0' / 1' / 0 / 1
+|-
+|testnet
+|first
+|external
+|first
+|m / XY' / 1' / 0' / 0 / 0
+|-
+|testnet
+|first
+|external
+|second
+|m / XY' / 1' / 0' / 0 / 1
+|-
+|testnet
+|first
+|change
+|first
+|m / XY' / 1' / 0' / 1 / 0
+|-
+|testnet
+|first
+|change
+|second
+|m / XY' / 1' / 0' / 1 / 1
+|-
+|testnet
+|second
+|external
+|first
+|m / XY' / 1' / 1' / 0 / 0
+|-
+|testnet
+|second
+|external
+|second
+|m / XY' / 1' / 1' / 0 / 1
+|-
+|testnet
+|second
+|change
+|first
+|m / XY' / 1' / 1' / 1 / 0
+|-
+|testnet
+|second
+|change
+|second
+|m / XY' / 1' / 1' / 1 / 1
+|}
+
+==Acknowledgement==
+
+
+==References==
+
+Original mailing list thread: TBD
+
+* [[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]]
+* [https://github.com/bitcoin/bitcoin/blob/master/doc/descriptors.md Output Descriptors]
+* [[bip-0067.mediawiki|BIP67 - Deterministic Pay-to-script-hash multi-signature addresses through public key sorting]]
+
diff --git a/Multisig Derivation Standard.mediawiki b/Multisig Derivation Standard.mediawiki
deleted file mode 100644
index e44dcdc..0000000
--- a/Multisig Derivation Standard.mediawiki	
+++ /dev/null
@@ -1,222 +0,0 @@
-<pre>
-  BIP: Number not assigned
-  Layer: Applications
-  Title: Modern Hierarchy for Deterministic Multisignature Wallets
-  Author: Robert Spigler <RobertSpigler@ProtonMail.ch>
-  Comments-Summary: No comments
-  Comments-URI:
-  Status: Proposed
-  Type: Standards Track
-  Created: 2020-03-11
-</pre>
-
-===Copyright===
-
-This BIP is licensed under the 2-clause BSD license.
-
-==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.
-
-==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.
-
-There are many issues with the current standards. As background, BIP 44/49/84 specifies:
-
-<pre>
-m / purpose' / coin_type' / account' / change / address_index
-</pre>
-
-where the BIP43 <code>purpose'</code> path is separate for each script (P2PKH, P2WPKH-in-P2SH, and P2WPKH respectively).  However, these per-script derivations are made redundant with descriptors, which describe a collection of output scripts.  Note also that these are single sig derivations (which shouldn't be reused for multisig).
-
-Standardization is needed for multisig derivation paths.  There are some in existence, but all have issues.  For example, BIP45 specifies:
-
-<pre>
-m / purpose' / cosigner_index / change / address_index
-</pre>
-
-Like BIP44/49/84, BIP45 unecessarily demands a single script type (here, P2SH).  In addition, BIP45 sets <code>cosigner_index</code> in order to sort the <code>purpose'</code> public keys of each cosigner.  This too is redundant, as descriptors can set the order of the public keys with <code>multi</code> or have them sorted lexicographically (as described in [https://github.com/bitcoin/bips/blob/master/bip-0067.mediawiki BIP67]) with <code>sortedmulti</code>.  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:
-
-<pre>
-m / purpose' / coin_type' / account' / script_type' / change / address_index
-</pre>
-
-Rather than having a separate BIP per script after P2SH (BIP45), vendors decided to insert <code>script_type'</code> 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, <code>script_type</code> list.
-
-The hierarchy proposed later in this paper solves these issues and is quite comprehensive. It allows the handling of multiple accounts, external and internal chains per account, and millions of addresses per chain.
-
-Any script that is supported by descriptors (and the specific wallet implementation) is compatible with this BIP.
-
-This paper was inspired from BIP44.
-
-==Key sorting==
-
-Any wallet that supports descriptors inherently supports deterministic key sorting as per BIP67 (through the <code>sortedmulti</code> function) so that all possible multisignature addresses/scripts are derived from deterministically sorted public keys.
-
-==Path levels==
-
-You should not be mixing keys and scripts. We define the following 5 levels in the BIP32 path:
-
-<pre>
-m / purpose' / coin_type' / account' / change / address_index
-</pre>
-
-<code>h</code> or <code>'</code> 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 XY' 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 <code>0</code> for mainnet and <code>1</code> 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.
-
-===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
-|chain
-|address
-|path
-|-
-|mainnet
-|first
-|external
-|first
-|m / XY' / 0' / 0' / 0 / 0
-|-
-|mainnet
-|first
-|external
-|second
-|m / XY' / 0' / 0' / 0 / 1
-|-
-|mainnet
-|first
-|change
-|first
-|m / XY' / 0' / 0' / 1 / 0
-|-
-|mainnet
-|first
-|change
-|second
-|m / XY' / 0' / 0' / 1 / 1
-|-
-|mainnet
-|second
-|external
-|first
-|m / XY' / 0' / 1' / 0 / 0
-|-
-|mainnet
-|second
-|external
-|second
-|m / XY' / 0' / 1' / 0 / 1
-|-
-|testnet
-|first
-|external
-|first
-|m / XY' / 1' / 0' / 0 / 0
-|-
-|testnet
-|first
-|external
-|second
-|m / XY' / 1' / 0' / 0 / 1
-|-
-|testnet
-|first
-|change
-|first
-|m / XY' / 1' / 0' / 1 / 0
-|-
-|testnet
-|first
-|change
-|second
-|m / XY' / 1' / 0' / 1 / 1
-|-
-|testnet
-|second
-|external
-|first
-|m / XY' / 1' / 1' / 0 / 0
-|-
-|testnet
-|second
-|external
-|second
-|m / XY' / 1' / 1' / 0 / 1
-|-
-|testnet
-|second
-|change
-|first
-|m / XY' / 1' / 1' / 1 / 0
-|-
-|testnet
-|second
-|change
-|second
-|m / XY' / 1' / 1' / 1 / 1
-|}
-
-==Acknowledgement==
-
-
-==References==
-
-Original mailing list thread: TBD
-
-* [[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]]
-* [https://github.com/bitcoin/bitcoin/blob/master/doc/descriptors.md Output Descriptors]
-* [[bip-0174.mediawiki|BIP174 - Partially Signed Bitcoin Transaction Format]]
-* [[bip-0067.mediawiki|BIP67 - Deterministic Pay-to-script-hash multi-signature addresses through public key sorting]]
-
-- 
cgit v1.2.3


From c747ee9880866935da9f74cd15946be480666be1 Mon Sep 17 00:00:00 2001
From: Robert Spigler <RobertSpigler@ProtonMail.ch>
Date: Fri, 12 Mar 2021 17:32:50 -0500
Subject: Update Modern Derivation Standard.mediawiki

minor edit
---
 Modern Derivation Standard.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Modern Derivation Standard.mediawiki b/Modern Derivation Standard.mediawiki
index c8d5a84..5cf3665 100644
--- a/Modern Derivation Standard.mediawiki	
+++ b/Modern Derivation Standard.mediawiki	
@@ -101,7 +101,7 @@ This number is used as child index in BIP32 derivation.
 
 Hardened derivation is used at this level.
 
-It is crucial that the index is increased for each new wallet joined or private/public keys created; for both privacy and cryptographic purposes.
+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, in multisignature wallets, before sending a new key record to a coordinator, the wallet must increment the <code>account'</code> level.  Before creating it's own single signature wallet, the <code>account'</code> level must again be incremented.
 This prevents key reuse - across single signature and multisignature wallets, across ECDSA and Schnorr signatures, and inbetween the same wallet types.
 
-- 
cgit v1.2.3


From 07d208ed09b479a37a5afad2a8300e430c300fbb Mon Sep 17 00:00:00 2001
From: ethankosakovsky <ethankosakovsky@protonmail.com>
Date: Sat, 13 Mar 2021 14:38:27 +0800
Subject: BIP85: fixed test vector.

---
 bip-0085.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-0085.mediawiki b/bip-0085.mediawiki
index cbd3a2a..f952148 100644
--- a/bip-0085.mediawiki
+++ b/bip-0085.mediawiki
@@ -87,7 +87,7 @@ xprv9s21ZrQH143K2LBWUUQRFXhucrQqBpKdRRxNVq2zBqsx8HVqFk2uYo8kmbaLLHRdqtQpUm98uKfu
 
 OUTPUT
 * DERIVED KEY=cca20ccb0e9a90feb0912870c3323b24874b0ca3d8018c4b96d0b97c0e82ded0
-* DERIVED ENTROPY=6bea85e51a05e6dbaf2ccee05097758213807997ba936589cef01c8f19c0079f395a0cd045efa3438677f3ef9ad34c9a68506626c5a17e51ed5e177852ee7fdc
+* DERIVED ENTROPY=efecfbccffea313214232d29e71563d941229afb4338c21f9517c41aaa0d16f00b83d2a09ef747e7a64e8e2bd5a14869e693da66ce94ac2da570ab7ee48618f7
 
 * DRNG(80 bytes)=b78b1ee6b345eae6836c2d53d33c64cdaf9a696487be81b03e822dc84b3f1cd883d7559e53d175f243e4c349e822a957bbff9224bc5dde9492ef54e8a439f6bc8c7355b87a925a37ee405a7502991111
 
-- 
cgit v1.2.3


From deba2a75be9f8151f4d77d21ef517ad280cc1a61 Mon Sep 17 00:00:00 2001
From: Robert Spigler <RobertSpigler@ProtonMail.ch>
Date: Sun, 14 Mar 2021 16:02:45 -0400
Subject: Clarify testnets

---
 Modern Derivation Standard.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Modern Derivation Standard.mediawiki b/Modern Derivation Standard.mediawiki
index 5cf3665..61a4fef 100644
--- a/Modern Derivation Standard.mediawiki	
+++ b/Modern Derivation Standard.mediawiki	
@@ -86,7 +86,7 @@ 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 <code>0</code> for mainnet and <code>1</code> for testnet.
+Coin type <code>0</code> for mainnet and <code>1</code> for testnets (testnet, regtest, and signet).
 
 Hardened derivation is used at this level.
 
-- 
cgit v1.2.3


From 4edd978046234f9f7e88b4879422ea527f072e8b Mon Sep 17 00:00:00 2001
From: Luke Dashjr <luke-jr+git@utopios.org>
Date: Mon, 15 Mar 2021 20:16:20 +0000
Subject: Fix Comments-URI for BIP 370

---
 bip-0370.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-0370.mediawiki b/bip-0370.mediawiki
index 0bd8764..8dd557a 100644
--- a/bip-0370.mediawiki
+++ b/bip-0370.mediawiki
@@ -4,7 +4,7 @@
   Title: PSBT Version 2
   Author: Andrew Chow <achow101@gmail.com>
   Comments-Summary: No comments yet.
-  Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-PSBT2
+  Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0370
   Status: Draft
   Type: Standards Track
   Created: 2021-01-14
-- 
cgit v1.2.3


From 4817829dc89697fe3a258a9b80e0e9819659aa75 Mon Sep 17 00:00:00 2001
From: 8go <cccc@tuta.io>
Date: Mon, 15 Mar 2021 21:28:48 +0000
Subject: BIP-85: Added Ian Coleman's Mnemonic Code Converter

- Added Ian Coleman's Mnemonic Code Converter to the "Other Implementations" section
- https://iancoleman.io/bip39/ is a nice tool to play around with and to derive test data for BIP-85

PS: Sorry that I did not include this in the previous PR #1083. I just found this this very moment, but I think it is worth while to include because it gives the user/reader an instant tool to play with and to see results of BIP-85.
---
 bip-0085.mediawiki | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/bip-0085.mediawiki b/bip-0085.mediawiki
index 182404f..efbc268 100644
--- a/bip-0085.mediawiki
+++ b/bip-0085.mediawiki
@@ -102,6 +102,8 @@ OUTPUT
 
 * 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/]
+
 ==Applications==
 
 The Application number defines how entropy will be used post processing. Some basic examples follow:
-- 
cgit v1.2.3


From 8c346ca3ba5d82ee35a91c5bd9c803a758dd68f5 Mon Sep 17 00:00:00 2001
From: Robert Spigler <RobertSpigler@ProtonMail.ch>
Date: Thu, 18 Mar 2021 17:15:07 -0400
Subject: Revert to multisig only

---
 Modern Derivation Standard.mediawiki               | 227 ---------------------
 ... Deterministic Multisignature Wallets.mediawiki | 227 +++++++++++++++++++++
 2 files changed, 227 insertions(+), 227 deletions(-)
 delete mode 100644 Modern Derivation Standard.mediawiki
 create mode 100644 Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki

diff --git a/Modern Derivation Standard.mediawiki b/Modern Derivation Standard.mediawiki
deleted file mode 100644
index 61a4fef..0000000
--- a/Modern Derivation Standard.mediawiki	
+++ /dev/null
@@ -1,227 +0,0 @@
-<pre>
-  BIP: Number not assigned
-  Layer: Applications
-  Title: Signature and Script Independant Hierarchy for Deterministic Wallets
-  Author: Robert Spigler <RobertSpigler@ProtonMail.ch>
-  Comments-Summary: No comments
-  Comments-URI:
-  Status: Proposed
-  Type: Standards Track
-  Created: 2020-03-11
-</pre>
-
-===Copyright===
-
-This BIP is licensed under the 2-clause BSD license.
-
-==Abstract==
-
-This BIP defines a sane hierarchy for deterministic 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.
-
-==Motivation==
-
-With the increase of adoption of new technologies such as [https://github.com/bitcoin/bitcoin/blob/master/doc/descriptors.md the descriptor language] it is necessary to create a common derivation scheme that makes use of all new technologies.
-
-There are many issues with the current standards. As background, BIP 44/49/84 specifies:
-
-<pre>
-m / purpose' / coin_type' / account' / change / address_index
-</pre>
-
-where the BIP43 <code>purpose'</code> path is separate for each script (P2PKH, P2WPKH-in-P2SH, and P2WPKH respectively).  However, these per-script derivations are made redundant with descriptors, which describe a collection of output scripts.  Note also that these BIPs are restricted for single sig wallets. This is unecessary, as descriptors handle whether the scripts are single-key or multi-key.
-
-Modification is also needed for multisig derivation paths.  For example, BIP45 specifies:
-
-<pre>
-m / purpose' / cosigner_index / change / address_index
-</pre>
-
-Like BIP44/49/84, BIP45 unecessarily demands a single script type (here, P2SH).  In addition, BIP45 sets <code>cosigner_index</code> in order to sort the <code>purpose'</code> public keys of each cosigner.  This too is redundant, as descriptors can set the order of the public keys with <code>multi</code> or have them sorted lexicographically (as described in [https://github.com/bitcoin/bips/blob/master/bip-0067.mediawiki BIP67]) with <code>sortedmulti</code>.  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:
-
-<pre>
-m / purpose' / coin_type' / account' / script_type' / change / address_index
-</pre>
-
-Rather than following in BIP 44/49/84's path and having a separate BIP per script after P2SH (BIP45), vendors decided to insert <code>script_type'</code> 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, <code>script_type</code> list.
-
-The hierarchy proposed later in this paper solves these issues and is quite comprehensive. It allows the handling of multiple accounts, external and internal chains per account, and millions of addresses per chain, regardless of the script or signature type.
-
-Any script that is supported by descriptors (and the specific wallet implementation) is compatible with this BIP.
-
-This paper was inspired from BIP44.
-
-==Key sorting==
-
-Any wallet that supports descriptors inherently supports deterministic key sorting as per BIP67 (through the <code>sortedmulti</code> 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 or signature type, whereas the descriptor language tells wallets to watch (single or multi-sig) outputs with the specified public keys.
-
-We define the following 5 levels in the BIP32 path:
-
-<pre>
-m / purpose' / coin_type' / account' / change / address_index
-</pre>
-
-<code>h</code> or <code>'</code> 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 XY' 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 <code>0</code> for mainnet and <code>1</code> 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, in multisignature wallets, before sending a new key record to a coordinator, the wallet must increment the <code>account'</code> level.  Before creating it's own single signature wallet, the <code>account'</code> level must again be incremented.
-This prevents key reuse - across single signature and multisignature wallets, across ECDSA and Schnorr signatures, 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.
-
-==Examples==
-
-{|
-|network
-|account
-|chain
-|address
-|path
-|-
-|mainnet
-|first
-|external
-|first
-|m / XY' / 0' / 0' / 0 / 0
-|-
-|mainnet
-|first
-|external
-|second
-|m / XY' / 0' / 0' / 0 / 1
-|-
-|mainnet
-|first
-|change
-|first
-|m / XY' / 0' / 0' / 1 / 0
-|-
-|mainnet
-|first
-|change
-|second
-|m / XY' / 0' / 0' / 1 / 1
-|-
-|mainnet
-|second
-|external
-|first
-|m / XY' / 0' / 1' / 0 / 0
-|-
-|mainnet
-|second
-|external
-|second
-|m / XY' / 0' / 1' / 0 / 1
-|-
-|testnet
-|first
-|external
-|first
-|m / XY' / 1' / 0' / 0 / 0
-|-
-|testnet
-|first
-|external
-|second
-|m / XY' / 1' / 0' / 0 / 1
-|-
-|testnet
-|first
-|change
-|first
-|m / XY' / 1' / 0' / 1 / 0
-|-
-|testnet
-|first
-|change
-|second
-|m / XY' / 1' / 0' / 1 / 1
-|-
-|testnet
-|second
-|external
-|first
-|m / XY' / 1' / 1' / 0 / 0
-|-
-|testnet
-|second
-|external
-|second
-|m / XY' / 1' / 1' / 0 / 1
-|-
-|testnet
-|second
-|change
-|first
-|m / XY' / 1' / 1' / 1 / 0
-|-
-|testnet
-|second
-|change
-|second
-|m / XY' / 1' / 1' / 1 / 1
-|}
-
-==Acknowledgement==
-
-
-==References==
-
-Original mailing list thread: TBD
-
-* [[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]]
-* [https://github.com/bitcoin/bitcoin/blob/master/doc/descriptors.md Output Descriptors]
-* [[bip-0067.mediawiki|BIP67 - Deterministic Pay-to-script-hash multi-signature addresses through public key sorting]]
-
diff --git a/Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki b/Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki
new file mode 100644
index 0000000..0960fa9
--- /dev/null
+++ b/Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki	
@@ -0,0 +1,227 @@
+<pre>
+  BIP: Number not assigned
+  Layer: Applications
+  Title: Modern Hierarchy for Deterministic Multisignature Wallets
+  Author: Robert Spigler <RobertSpigler@ProtonMail.ch>
+  Comments-Summary: No comments
+  Comments-URI:
+  Status: Proposed
+  Type: Standards Track
+  Created: 2020-03-11
+</pre>
+
+===Copyright===
+
+This BIP is licensed under the 2-clause BSD license.
+
+==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.
+
+==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:
+
+<pre>
+m / purpose' / coin_type' / account' / change / address_index
+</pre>
+
+where the BIP43 <code>purpose'</code> path is separate for each script (P2PKH, P2WPKH-in-P2SH, and P2WPKH respectively).  However, these per-script derivations are made redundant with descriptors, which describe a collection of output scripts.  Note also that these are single sig derivations (which shouldn't be reused for multisig).
+
+Standardization is needed for multisig derivation paths.  There are some in existence, but all have issues.  For example, BIP45 specifies:
+
+<pre>
+m / purpose' / cosigner_index / change / address_index
+</pre>
+
+Like BIP44/49/84, BIP45 unecessarily demands a single script type (here, P2SH).  In addition, BIP45 sets <code>cosigner_index</code> in order to sort the <code>purpose'</code> public keys of each cosigner.  This too is redundant, as descriptors can set the order of the public keys with <code>multi</code> or have them sorted lexicographically (as described in [https://github.com/bitcoin/bips/blob/master/bip-0067.mediawiki BIP67]) with <code>sortedmulti</code>.  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:
+
+<pre>
+m / purpose' / coin_type' / account' / script_type' / change / address_index
+</pre>
+
+Rather than following in BIP 44/49/84's path and having a separate BIP per script after P2SH (BIP45), vendors decided to insert <code>script_type'</code> 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, <code>script_type</code> list.
+
+The structure proposed later in this paper solves these issues and is quite comprehensive. It allows 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.
+
+Any script that is supported by descriptors (and the specific wallet implementation) is compatible with this BIP.
+
+This paper was inspired from BIP44.
+
+==Key sorting==
+
+Any wallet that supports descriptors inherently supports deterministic key sorting as per BIP67 (through the <code>sortedmulti</code> 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:
+
+<pre>
+m / purpose' / coin_type' / account' / change / address_index
+</pre>
+
+<code>h</code> or <code>'</code> 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 XY' 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 <code>0</code> for mainnet and <code>1</code> 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 <code>account'</code> 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.
+
+==Examples==
+
+{|
+|network
+|account
+|chain
+|address
+|path
+|-
+|mainnet
+|first
+|external
+|first
+|m / XY' / 0' / 0' / 0 / 0
+|-
+|mainnet
+|first
+|external
+|second
+|m / XY' / 0' / 0' / 0 / 1
+|-
+|mainnet
+|first
+|change
+|first
+|m / XY' / 0' / 0' / 1 / 0
+|-
+|mainnet
+|first
+|change
+|second
+|m / XY' / 0' / 0' / 1 / 1
+|-
+|mainnet
+|second
+|external
+|first
+|m / XY' / 0' / 1' / 0 / 0
+|-
+|mainnet
+|second
+|external
+|second
+|m / XY' / 0' / 1' / 0 / 1
+|-
+|testnet
+|first
+|external
+|first
+|m / XY' / 1' / 0' / 0 / 0
+|-
+|testnet
+|first
+|external
+|second
+|m / XY' / 1' / 0' / 0 / 1
+|-
+|testnet
+|first
+|change
+|first
+|m / XY' / 1' / 0' / 1 / 0
+|-
+|testnet
+|first
+|change
+|second
+|m / XY' / 1' / 0' / 1 / 1
+|-
+|testnet
+|second
+|external
+|first
+|m / XY' / 1' / 1' / 0 / 0
+|-
+|testnet
+|second
+|external
+|second
+|m / XY' / 1' / 1' / 0 / 1
+|-
+|testnet
+|second
+|change
+|first
+|m / XY' / 1' / 1' / 1 / 0
+|-
+|testnet
+|second
+|change
+|second
+|m / XY' / 1' / 1' / 1 / 1
+|}
+
+==Acknowledgement==
+
+
+==References==
+
+Original mailing list thread: TBD
+
+* [[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]]
+* [https://github.com/bitcoin/bitcoin/blob/master/doc/descriptors.md Output Descriptors]
+* [[bip-0067.mediawiki|BIP67 - Deterministic Pay-to-script-hash multi-signature addresses through public key sorting]]
+
-- 
cgit v1.2.3


From b4af07c8a7f10fb28e6c5233d603310cc9db072f Mon Sep 17 00:00:00 2001
From: Robert Spigler <RobertSpigler@ProtonMail.ch>
Date: Thu, 18 Mar 2021 17:16:15 -0400
Subject: Add PSBT and ML reference

---
 Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki b/Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki
index 0960fa9..8ac2888 100644
--- a/Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki	
+++ b/Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki	
@@ -217,11 +217,12 @@ Public derivation is used at this level.
 
 ==References==
 
-Original mailing list thread: TBD
+Original mailing list thread: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-March/018630.html
 
 * [[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]]
 * [https://github.com/bitcoin/bitcoin/blob/master/doc/descriptors.md Output Descriptors]
+* [[bip-0174.mediawiki|BIP174 - Partially Signed Bitcoin Transaction Format]]
 * [[bip-0067.mediawiki|BIP67 - Deterministic Pay-to-script-hash multi-signature addresses through public key sorting]]
 
-- 
cgit v1.2.3


From f4cea61a4edec51c72a965861c0cb63553adf68c Mon Sep 17 00:00:00 2001
From: Robert Spigler <RobertSpigler@ProtonMail.ch>
Date: Thu, 18 Mar 2021 18:00:39 -0400
Subject: Clarifications

---
 Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki b/Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki
index 8ac2888..e69f9cf 100644
--- a/Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki	
+++ b/Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki	
@@ -30,9 +30,10 @@ As background, BIP 44/49/84 specifies:
 m / purpose' / coin_type' / account' / change / address_index
 </pre>
 
-where the BIP43 <code>purpose'</code> path is separate for each script (P2PKH, P2WPKH-in-P2SH, and P2WPKH respectively).  However, these per-script derivations are made redundant with descriptors, which describe a collection of output scripts.  Note also that these are single sig derivations (which shouldn't be reused for multisig).
+where the BIP43 <code>purpose'</code> 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.
 
-Standardization is needed for multisig derivation paths.  There are some in existence, but all have issues.  For example, BIP45 specifies:
+Multisignature wallets need more information to backup and restore, and these per-script derivations are made redundant with descriptors, which describe 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:
 
 <pre>
 m / purpose' / cosigner_index / change / address_index
-- 
cgit v1.2.3


From 54fe11608cd36f66260e525217ab32b07efaec62 Mon Sep 17 00:00:00 2001
From: Andrew Chow <achow101-github@achow101.com>
Date: Mon, 8 Mar 2021 16:49:33 -0500
Subject: Add minimum activation height to BIP 8

---
 bip-0008.mediawiki  |  21 +++++++++-----
 bip-0008/states.dot |   3 +-
 bip-0008/states.png | Bin 46310 -> 60743 bytes
 bip-0008/states.svg |  82 ++++++++++++++++++++++++++++------------------------
 4 files changed, 60 insertions(+), 46 deletions(-)

diff --git a/bip-0008.mediawiki b/bip-0008.mediawiki
index 7b61eaa..59bbb99 100644
--- a/bip-0008.mediawiki
+++ b/bip-0008.mediawiki
@@ -39,6 +39,7 @@ Each soft fork deployment is specified by the following per-chain parameters (fu
 # The '''startheight''' specifies the height of the first block at which the bit gains its meaning.
 # The '''timeoutheight''' specifies a block height at which the miner signalling ends. Once this height has been reached, if the soft fork has not yet locked in (excluding this block's bit state), the deployment is considered failed on all descendants of the block.
 # The '''threshold''' specifies the minimum number of block per retarget period which indicate lock-in of the soft fork during the subsequent period.
+# The '''minimum_activation_height''' specifies the height of the first block at which the soft fork is allowed to become active.
 # The '''lockinontimeout''' boolean if set to true, blocks are required to signal in the final period, ensuring the soft fork has locked in by timeoutheight.
 
 ===Selection guidelines===
@@ -47,15 +48,16 @@ The following guidelines are suggested for selecting these parameters for a soft
 
 # '''name''' should be selected such that no two softforks, concurrent or otherwise, ever use the same name. For deployments described in a single BIP, it is recommended to use the name "bipN" where N is the appropriate BIP number.
 # '''bit''' should be selected such that no two concurrent softforks use the same bit. The bit chosen should not overlap with active usage (legitimately or otherwise) for other purposes.
-# '''startheight''' should be set to some block height in the future when a majority of economic activity is expected to have upgraded to a software release including the activation parameters. Some allowance should be made for potential release delays. It should be rounded up to the next height which begins a retarget period for simplicity.
+# '''startheight''' should be set to some block height in the future. It should be rounded up to the next height which begins a retarget period for simplicity. If '''minimum_activation_height''' is not going to be set, then '''startheight''' should be set to a height when a majority of economic activity is expected to have upgraded to software including the activation parameters. Some allowance should be made for potential release delays. If '''minimum_activation_height''' is going to be set, then '''startheight''' can be set to be soon after software with parameters is expected to be released. This shifts the time for upgrading from before signaling begins to during the LOCKED_IN state.
 # '''timeoutheight''' should be set to a block height when it is considered reasonable to expect the entire economy to have upgraded by, probably at least 1 year, or 52416 blocks (26 retarget intervals) after '''startheight'''.
 # '''threshold''' should be 1815 blocks (90% of 2016), or 1512 (75%) for testnet.
+# '''minimum_activation_height''' should be set to several retarget periods in the future if the '''startheight''' is to be very soon after software with parameters is expected to be released. '''minimum_activation_height''' should be set to a height when a majority of economic activity is expected to have upgraded to software including the activation parameters. This allows more time to be spent in the LOCKED_IN state so that nodes can upgrade. This may be set to 0 to have the LOCKED_IN state be a single retarget period.
 # '''lockinontimeout''' should be set to true for any softfork that is expected or found to have political opposition from a non-negligible percent of miners. (It can be set after the initial deployment, but cannot be cleared once set.)
 
 A later deployment using the same bit is possible as long as the startheight is after the previous one's
 timeoutheight or activation, but it is discouraged until necessary, and even then recommended to have a pause in between to detect buggy software.
 
-'''startheight''' and '''timeoutheight''' must be an exact multiple of 2016 (ie, at a retarget boundary), and '''timeoutheight''' must be at least 4096 blocks (2 retarget intervals) after '''startheight'''.
+'''startheight''', '''timeoutheight''', and '''minimum_activation_height''' must be an exact multiple of 2016 (ie, at a retarget boundary), and '''timeoutheight''' must be at least 4096 blocks (2 retarget intervals) after '''startheight'''.
 
 ===States===
 
@@ -64,8 +66,8 @@ With each block and soft fork, we associate a deployment state. The possible sta
 # '''DEFINED''' is the first state that each soft fork starts out as. The genesis block is by definition in this state for each deployment.
 # '''STARTED''' for blocks at or beyond the startheight.
 # '''MUST_SIGNAL''' for one retarget period prior to the timeout, if LOCKED_IN was not reached and '''lockinontimeout''' is true.
-# '''LOCKED_IN''' for one retarget period after the first retarget period with STARTED (or MUST_SIGNAL) blocks of which at least threshold have the associated bit set in nVersion.
-# '''ACTIVE''' for all blocks after the LOCKED_IN retarget period.
+# '''LOCKED_IN''' for at least one retarget period after the first retarget period with STARTED (or MUST_SIGNAL) blocks of which at least threshold have the associated bit set in nVersion. A soft fork remains in LOCKED_IN until at least '''minimum_activation_height''' is reached.
+# '''ACTIVE''' for all blocks after the LOCKED_IN state.
 # '''FAILED''' for all blocks after the timeoutheight if LOCKED_IN is not reached.
 
 ===Bit flags===
@@ -93,7 +95,8 @@ During the MUST_SIGNAL phase, if '''(2016 - threshold)''' blocks in the retarget
 
 <img src="bip-0008/states.png" align="middle"></img>
 
-Note that when '''lockinontimeout''' is true, the LOCKED_IN state will be reached no later than at a height of '''timeoutheight''', and ACTIVE will be reached no later than at a height of '''timeoutheight + 2016'''.
+Note that when '''lockinontimeout''' is true, the LOCKED_IN state will be reached no later than at a height of '''timeoutheight'''.
+Regardless of the value of '''lockinontimeout''', if LOCKED_IN is reached, ACTIVE will be reached either one retarget period later, or at '''minimum_activation_height''', whichever comes later.
 
 The genesis block has state DEFINED for each deployment, by definition.
 
@@ -153,10 +156,14 @@ If we have finished a period of MUST_SIGNAL, we transition directly to LOCKED_IN
         case MUST_SIGNAL:
             return LOCKED_IN;
 
-After a retarget period of LOCKED_IN, we automatically transition to ACTIVE.
+After at least one retarget period of LOCKED_IN, we automatically transition to ACTIVE if the minimum activation height is reached. Otherwise LOCKED_IN continues.
 
         case LOCKED_IN:
-            return ACTIVE;
+            if (block.height >= minimum_activation_height) {
+                return ACTIVE;
+            } else {
+                return LOCKED_IN;
+            }
 
 And ACTIVE and FAILED are terminal states, which a deployment stays in once they're reached.
 
diff --git a/bip-0008/states.dot b/bip-0008/states.dot
index aa919ff..8615978 100644
--- a/bip-0008/states.dot
+++ b/bip-0008/states.dot
@@ -7,7 +7,8 @@ digraph {
   "DEFINED" -> "STARTED" [label="height >= start_height"];
   "STARTED" -> "MUST_SIGNAL" [label="height + 2016 >= timeoutheight AND lockinontimeout"];
   "STARTED" -> "FAILED" [label="height >= timeoutheight\nAND\nNOT lockinontimeout"];
-  "LOCKED_IN" -> "ACTIVE" [label="always"];
+  "LOCKED_IN" -> "ACTIVE" [label="height >= minimum_activation_height"];
+  "LOCKED_IN":se -> "LOCKED_IN":ne [label="height < minimum_activation_height"];
   "MUST_SIGNAL" -> "LOCKED_IN" [label="always"];
 
   edge [weight = 1];
diff --git a/bip-0008/states.png b/bip-0008/states.png
index 6477ed3..f15efdb 100644
Binary files a/bip-0008/states.png and b/bip-0008/states.png differ
diff --git a/bip-0008/states.svg b/bip-0008/states.svg
index 3503c34..63fe634 100644
--- a/bip-0008/states.svg
+++ b/bip-0008/states.svg
@@ -1,14 +1,13 @@
 <?xml version="1.0" encoding="UTF-8" standalone="no"?>
 <!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN"
  "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
-<!-- Generated by graphviz version 2.42.3 (20191010.1750)
+<!-- Generated by graphviz version 2.46.1 (0)
  -->
-<!-- Title: %3 Pages: 1 -->
-<svg width="563pt" height="348pt"
- viewBox="0.00 0.00 563.00 348.37" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
+<!-- Pages: 1 -->
+<svg width="937pt" height="348pt"
+ viewBox="0.00 0.00 937.00 348.37" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
 <g id="graph0" class="graph" transform="scale(1 1) rotate(0) translate(4 344.37)">
-<title>%3</title>
-<polygon fill="white" stroke="transparent" points="-4,4 -4,-344.37 559,-344.37 559,4 -4,4"/>
+<polygon fill="white" stroke="transparent" points="-4,4 -4,-344.37 933,-344.37 933,4 -4,4"/>
 <!-- DEFINED -->
 <g id="node1" class="node">
 <title>DEFINED</title>
@@ -16,7 +15,7 @@
 <text text-anchor="middle" x="72" y="-312.05" font-family="Arial" font-size="14.00">DEFINED</text>
 </g>
 <!-- DEFINED&#45;&gt;DEFINED -->
-<g id="edge8" class="edge">
+<g id="edge9" class="edge">
 <title>DEFINED:sw&#45;&gt;DEFINED:nw</title>
 <path fill="none" stroke="black" d="M18,-297.75C12,-287.25 0,-287.25 0,-315.75 0,-334.01 4.92,-340.57 10.04,-340.17"/>
 <polygon fill="black" stroke="black" points="12.41,-342.75 18,-333.75 8.02,-337.3 12.41,-342.75"/>
@@ -32,10 +31,10 @@
 <title>DEFINED&#45;&gt;STARTED</title>
 <path fill="none" stroke="black" d="M72,-297.55C72,-285.91 72,-270.3 72,-256.99"/>
 <polygon fill="black" stroke="black" points="75.5,-256.93 72,-246.93 68.5,-256.93 75.5,-256.93"/>
-<text text-anchor="middle" x="133" y="-268.55" font-family="Times,serif" font-size="14.00">height &gt;= start_height</text>
+<text text-anchor="middle" x="155" y="-268.55" font-family="Times,serif" font-size="14.00">height &gt;= start_height</text>
 </g>
 <!-- STARTED&#45;&gt;STARTED -->
-<g id="edge9" class="edge">
+<g id="edge10" class="edge">
 <title>STARTED:sw&#45;&gt;STARTED:nw</title>
 <path fill="none" stroke="black" d="M18,-210.75C12,-200.25 0,-200.25 0,-228.75 0,-247.01 4.92,-253.57 10.04,-253.17"/>
 <polygon fill="black" stroke="black" points="12.41,-255.75 18,-246.75 8.02,-250.3 12.41,-255.75"/>
@@ -43,15 +42,15 @@
 <!-- MUST_SIGNAL -->
 <g id="node3" class="node">
 <title>MUST_SIGNAL</title>
-<path fill="#a0a0ff" stroke="black" stroke-width="2" d="M543,-246.75C543,-246.75 459,-246.75 459,-246.75 453,-246.75 447,-240.75 447,-234.75 447,-234.75 447,-222.75 447,-222.75 447,-216.75 453,-210.75 459,-210.75 459,-210.75 543,-210.75 543,-210.75 549,-210.75 555,-216.75 555,-222.75 555,-222.75 555,-234.75 555,-234.75 555,-240.75 549,-246.75 543,-246.75"/>
-<text text-anchor="middle" x="501" y="-225.05" font-family="Arial" font-size="14.00">MUST_SIGNAL</text>
+<path fill="#a0a0ff" stroke="black" stroke-width="2" d="M634,-246.75C634,-246.75 550,-246.75 550,-246.75 544,-246.75 538,-240.75 538,-234.75 538,-234.75 538,-222.75 538,-222.75 538,-216.75 544,-210.75 550,-210.75 550,-210.75 634,-210.75 634,-210.75 640,-210.75 646,-216.75 646,-222.75 646,-222.75 646,-234.75 646,-234.75 646,-240.75 640,-246.75 634,-246.75"/>
+<text text-anchor="middle" x="592" y="-225.05" font-family="Arial" font-size="14.00">MUST_SIGNAL</text>
 </g>
 <!-- STARTED&#45;&gt;MUST_SIGNAL -->
 <g id="edge2" class="edge">
 <title>STARTED&#45;&gt;MUST_SIGNAL</title>
-<path fill="none" stroke="black" d="M126.33,-228.75C205.44,-228.75 352.08,-228.75 436.54,-228.75"/>
-<polygon fill="black" stroke="black" points="436.77,-232.25 446.77,-228.75 436.77,-225.25 436.77,-232.25"/>
-<text text-anchor="middle" x="286.5" y="-235.55" font-family="Times,serif" font-size="14.00">height + 2016 &gt;= timeoutheight AND lockinontimeout</text>
+<path fill="none" stroke="black" d="M126.18,-228.75C222.75,-228.75 424.19,-228.75 527.64,-228.75"/>
+<polygon fill="black" stroke="black" points="527.94,-232.25 537.94,-228.75 527.94,-225.25 527.94,-232.25"/>
+<text text-anchor="middle" x="332" y="-235.55" font-family="Times,serif" font-size="14.00">height + 2016 &gt;= timeoutheight AND lockinontimeout</text>
 </g>
 <!-- FAILED -->
 <g id="node4" class="node">
@@ -64,57 +63,64 @@
 <title>STARTED&#45;&gt;FAILED</title>
 <path fill="none" stroke="black" d="M72,-210.28C72,-191.69 72,-161.99 72,-140.25"/>
 <polygon fill="black" stroke="black" points="75.5,-140 72,-130 68.5,-140 75.5,-140"/>
-<text text-anchor="middle" x="139" y="-181.55" font-family="Times,serif" font-size="14.00">height &gt;= timeoutheight</text>
-<text text-anchor="middle" x="139" y="-166.55" font-family="Times,serif" font-size="14.00">AND</text>
-<text text-anchor="middle" x="139" y="-151.55" font-family="Times,serif" font-size="14.00">NOT lockinontimeout</text>
+<text text-anchor="middle" x="162.5" y="-181.55" font-family="Times,serif" font-size="14.00">height &gt;= timeoutheight</text>
+<text text-anchor="middle" x="162.5" y="-166.55" font-family="Times,serif" font-size="14.00">AND</text>
+<text text-anchor="middle" x="162.5" y="-151.55" font-family="Times,serif" font-size="14.00">NOT lockinontimeout</text>
 </g>
 <!-- LOCKED_IN -->
 <g id="node5" class="node">
 <title>LOCKED_IN</title>
-<path fill="#ffffa0" stroke="black" stroke-width="2" d="M543,-129.75C543,-129.75 459,-129.75 459,-129.75 453,-129.75 447,-123.75 447,-117.75 447,-117.75 447,-105.75 447,-105.75 447,-99.75 453,-93.75 459,-93.75 459,-93.75 543,-93.75 543,-93.75 549,-93.75 555,-99.75 555,-105.75 555,-105.75 555,-117.75 555,-117.75 555,-123.75 549,-129.75 543,-129.75"/>
-<text text-anchor="middle" x="501" y="-108.05" font-family="Arial" font-size="14.00">LOCKED_IN</text>
+<path fill="#ffffa0" stroke="black" stroke-width="2" d="M634,-129.75C634,-129.75 550,-129.75 550,-129.75 544,-129.75 538,-123.75 538,-117.75 538,-117.75 538,-105.75 538,-105.75 538,-99.75 544,-93.75 550,-93.75 550,-93.75 634,-93.75 634,-93.75 640,-93.75 646,-99.75 646,-105.75 646,-105.75 646,-117.75 646,-117.75 646,-123.75 640,-129.75 634,-129.75"/>
+<text text-anchor="middle" x="592" y="-108.05" font-family="Arial" font-size="14.00">LOCKED_IN</text>
 </g>
 <!-- STARTED&#45;&gt;LOCKED_IN -->
-<g id="edge6" class="edge">
+<g id="edge7" class="edge">
 <title>STARTED&#45;&gt;LOCKED_IN</title>
-<path fill="none" stroke="black" d="M126.15,-214.34C151.63,-207.94 182.41,-200.1 210,-192.75 281.79,-173.62 299.35,-167.41 371,-147.75 392.5,-141.85 416.03,-135.49 437.09,-129.83"/>
-<polygon fill="black" stroke="black" points="438.14,-133.17 446.89,-127.19 436.32,-126.41 438.14,-133.17"/>
-<text text-anchor="middle" x="434" y="-181.55" font-family="Times,serif" font-size="14.00">height &lt; timeoutheight</text>
-<text text-anchor="middle" x="434" y="-166.55" font-family="Times,serif" font-size="14.00">AND</text>
-<text text-anchor="middle" x="434" y="-151.55" font-family="Times,serif" font-size="14.00">threshold reached</text>
+<path fill="none" stroke="black" d="M126.08,-218.75C163.11,-212.29 213.23,-202.95 257,-192.75 329.78,-175.79 346.33,-165.17 419,-147.75 454.78,-139.17 495.06,-130.94 527.74,-124.62"/>
+<polygon fill="black" stroke="black" points="528.47,-128.04 537.63,-122.72 527.15,-121.17 528.47,-128.04"/>
+<text text-anchor="middle" x="503.5" y="-181.55" font-family="Times,serif" font-size="14.00">height &lt; timeoutheight</text>
+<text text-anchor="middle" x="503.5" y="-166.55" font-family="Times,serif" font-size="14.00">AND</text>
+<text text-anchor="middle" x="503.5" y="-151.55" font-family="Times,serif" font-size="14.00">threshold reached</text>
 </g>
 <!-- MUST_SIGNAL&#45;&gt;LOCKED_IN -->
-<g id="edge5" class="edge">
+<g id="edge6" class="edge">
 <title>MUST_SIGNAL&#45;&gt;LOCKED_IN</title>
-<path fill="none" stroke="black" d="M501,-210.28C501,-191.69 501,-161.99 501,-140.25"/>
-<polygon fill="black" stroke="black" points="504.5,-140 501,-130 497.5,-140 504.5,-140"/>
-<text text-anchor="middle" x="520" y="-166.55" font-family="Times,serif" font-size="14.00">always</text>
+<path fill="none" stroke="black" d="M592,-210.28C592,-191.69 592,-161.99 592,-140.25"/>
+<polygon fill="black" stroke="black" points="595.5,-140 592,-130 588.5,-140 595.5,-140"/>
+<text text-anchor="middle" x="616.5" y="-166.55" font-family="Times,serif" font-size="14.00">always</text>
 </g>
 <!-- FAILED&#45;&gt;FAILED -->
-<g id="edge11" class="edge">
+<g id="edge12" class="edge">
 <title>FAILED:sw&#45;&gt;FAILED:nw</title>
 <path fill="none" stroke="black" d="M18,-93.75C12,-83.25 0,-83.25 0,-111.75 0,-130.01 4.92,-136.57 10.04,-136.17"/>
 <polygon fill="black" stroke="black" points="12.41,-138.75 18,-129.75 8.02,-133.3 12.41,-138.75"/>
 </g>
 <!-- FAILED&#45;&gt;LOCKED_IN -->
+<!-- LOCKED_IN&#45;&gt;LOCKED_IN -->
+<g id="edge5" class="edge">
+<title>LOCKED_IN:se&#45;&gt;LOCKED_IN:ne</title>
+<path fill="none" stroke="black" d="M646,-93.75C652,-83.25 664,-83.25 664,-111.75 664,-130.01 659.08,-136.57 653.96,-136.17"/>
+<polygon fill="black" stroke="black" points="655.98,-133.3 646,-129.75 651.59,-138.75 655.98,-133.3"/>
+<text text-anchor="middle" x="796.5" y="-108.05" font-family="Times,serif" font-size="14.00">height &lt; minimum_activation_height</text>
+</g>
 <!-- ACTIVE -->
 <g id="node6" class="node">
 <title>ACTIVE</title>
-<path fill="#a0ffa0" stroke="black" stroke-width="2" d="M543,-42.75C543,-42.75 459,-42.75 459,-42.75 453,-42.75 447,-36.75 447,-30.75 447,-30.75 447,-18.75 447,-18.75 447,-12.75 453,-6.75 459,-6.75 459,-6.75 543,-6.75 543,-6.75 549,-6.75 555,-12.75 555,-18.75 555,-18.75 555,-30.75 555,-30.75 555,-36.75 549,-42.75 543,-42.75"/>
-<text text-anchor="middle" x="501" y="-21.05" font-family="Arial" font-size="14.00">ACTIVE</text>
+<path fill="#a0ffa0" stroke="black" stroke-width="2" d="M634,-42.75C634,-42.75 550,-42.75 550,-42.75 544,-42.75 538,-36.75 538,-30.75 538,-30.75 538,-18.75 538,-18.75 538,-12.75 544,-6.75 550,-6.75 550,-6.75 634,-6.75 634,-6.75 640,-6.75 646,-12.75 646,-18.75 646,-18.75 646,-30.75 646,-30.75 646,-36.75 640,-42.75 634,-42.75"/>
+<text text-anchor="middle" x="592" y="-21.05" font-family="Arial" font-size="14.00">ACTIVE</text>
 </g>
 <!-- LOCKED_IN&#45;&gt;ACTIVE -->
 <g id="edge4" class="edge">
 <title>LOCKED_IN&#45;&gt;ACTIVE</title>
-<path fill="none" stroke="black" d="M501,-93.55C501,-81.91 501,-66.3 501,-52.99"/>
-<polygon fill="black" stroke="black" points="504.5,-52.93 501,-42.93 497.5,-52.93 504.5,-52.93"/>
-<text text-anchor="middle" x="520" y="-64.55" font-family="Times,serif" font-size="14.00">always</text>
+<path fill="none" stroke="black" d="M592,-93.55C592,-81.91 592,-66.3 592,-52.99"/>
+<polygon fill="black" stroke="black" points="595.5,-52.93 592,-42.93 588.5,-52.93 595.5,-52.93"/>
+<text text-anchor="middle" x="730.5" y="-64.55" font-family="Times,serif" font-size="14.00">height &gt;= minimum_activation_height</text>
 </g>
 <!-- ACTIVE&#45;&gt;ACTIVE -->
-<g id="edge10" class="edge">
+<g id="edge11" class="edge">
 <title>ACTIVE:sw&#45;&gt;ACTIVE:nw</title>
-<path fill="none" stroke="black" d="M447,-6.75C441,3.75 429,3.75 429,-24.75 429,-43.01 433.92,-49.57 439.04,-49.17"/>
-<polygon fill="black" stroke="black" points="441.41,-51.75 447,-42.75 437.02,-46.3 441.41,-51.75"/>
+<path fill="none" stroke="black" d="M538,-6.75C532,3.75 520,3.75 520,-24.75 520,-43.01 524.92,-49.57 530.04,-49.17"/>
+<polygon fill="black" stroke="black" points="532.41,-51.75 538,-42.75 528.02,-46.3 532.41,-51.75"/>
 </g>
 </g>
 </svg>
-- 
cgit v1.2.3


From 73dce7aafce941969ce96da5fe3e64084b3705e6 Mon Sep 17 00:00:00 2001
From: Robert Spigler <RobertSpigler@ProtonMail.ch>
Date: Mon, 22 Mar 2021 00:59:46 -0400
Subject: BIP2 compliance.  Add rationale, addresss discovery, etc.

---
 ... Deterministic Multisignature Wallets.mediawiki | 53 +++++++++++++++++++---
 1 file changed, 46 insertions(+), 7 deletions(-)

diff --git a/Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki b/Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki
index e69f9cf..8748762 100644
--- a/Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki	
+++ b/Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki	
@@ -8,18 +8,19 @@
   Status: Proposed
   Type: Standards Track
   Created: 2020-03-11
+  License: BSD-2-Clause
 </pre>
 
-===Copyright===
-
-This BIP is licensed under the 2-clause BSD license.
-
 ==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.
@@ -49,17 +50,19 @@ 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 <code>script_type'</code> 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, <code>script_type</code> list.
 
-The structure proposed later in this paper solves these issues and is quite comprehensive. It allows 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.
+The structure proposed later in this paper solves these issues and is quite comprehensive. It allows 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 <ref>**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. Co-signers in multisignature wallets need to backup all other cosigner public keys anyway in order to restore, so the descriptor provides this information with the benefit of key origin information and error detection.</ref>.
 
 Any script that is supported by descriptors (and the specific wallet implementation) is compatible with this BIP.
 
 This paper was inspired from BIP44.
 
-==Key sorting==
+==Specification==
+
+===Key sorting===
 
 Any wallet that supports descriptors inherently supports deterministic key sorting as per BIP67 (through the <code>sortedmulti</code> function) so that all possible multisignature addresses/scripts are derived from deterministically sorted public keys.
 
-==Path levels==
+===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.
 
@@ -119,6 +122,37 @@ This number is used as child index in BIP32 derivation.
 
 Public derivation is used at this level.
 
+==Address Discovery==
+
+The multisig descriptor that is generated from the cosigners combined key records should be used to generate and discover addresses. For example:
+<code>wsh(sortedmulti(2,[xfpForA/XY'/0'/0']XpubA/*,[xfpForB/XY'/0'/0']XpubB/*))#Checksum</code>
+
+# Derive the wallet's first account's node (index = 0)
+# Derive the external chain node of this account (index = 0)
+# Scan addresses of the external chain; respect the gap limit described below
+# If there are some transactions, increase the account index and go to step 2
+# If no transactions are found on the external chain, continue to search the following account indexes in compliance with the account gap limit described below.
+
+Please note that the algorithm works with the transaction history, not account
+balances, so you can have an account with 0 total coins and the algorithm will
+still continue with discovery.
+
+The wallet implementation should scan the accounts and addresses following the parent descriptor string.
+
+===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. We scan just the external chains, because internal chains receive only coins that come from the associated external chains.
+
+Wallet software should warn when the user is trying to exceed the gap limit on an external chain by generating a new address.
+
+===Account Gap Limit===
+
+Account gap limit is currently set to 5.  When the software hits an account that contains 20 unused addresses in a row, it will search the the next 4 accounts (while obeying the address gap limit), before stoping discovery.  If any transactions are found during this process, discovery is restarted (after finding 20 unused addresses) on the next account index, and the account gap limit is reset.  Only when the address gap limit is found consecutively for the account gap limit is discovery stopped.
+
+==Rationale==
+
+<references/>
+
 ==Examples==
 
 {|
@@ -213,8 +247,13 @@ Public derivation is used at this level.
 |m / XY' / 1' / 1' / 1 / 1
 |}
 
+==Reference Implementation==
+
+None at the moment.
+
 ==Acknowledgement==
 
+Special thanks to SomberNight, Craig Raw, David Harding, Jochen Hoenicke, and others for their feedback on the specification.
 
 ==References==
 
-- 
cgit v1.2.3


From ba9f775ef6680cc8834e0787c92edd73705cb803 Mon Sep 17 00:00:00 2001
From: Robert Spigler <RobertSpigler@ProtonMail.ch>
Date: Mon, 22 Mar 2021 01:01:55 -0400
Subject: Formatting

---
 Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki b/Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki
index 8748762..68eeae0 100644
--- a/Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki	
+++ b/Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki	
@@ -50,7 +50,7 @@ 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 <code>script_type'</code> 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, <code>script_type</code> list.
 
-The structure proposed later in this paper solves these issues and is quite comprehensive. It allows 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 <ref>**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. Co-signers in multisignature wallets need to backup all other cosigner public keys anyway in order to restore, so the descriptor provides this information with the benefit of key origin information and error detection.</ref>.
+The structure proposed later in this paper solves these issues and is quite comprehensive. It allows 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 <ref>'''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. Co-signers in multisignature wallets need to backup all other cosigner public keys anyway in order to restore, so the descriptor provides this information with the benefit of key origin information and error detection.</ref>.
 
 Any script that is supported by descriptors (and the specific wallet implementation) is compatible with this BIP.
 
-- 
cgit v1.2.3


From 453d3282659e7fab9fbcfab9e8c09b0c16c861d4 Mon Sep 17 00:00:00 2001
From: Robert Spigler <RobertSpigler@ProtonMail.ch>
Date: Mon, 22 Mar 2021 01:27:52 -0400
Subject: Grammar/formatting

---
 ...rarchy for Deterministic Multisignature Wallets.mediawiki | 12 +++++-------
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki b/Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki
index 68eeae0..b0c8f26 100644
--- a/Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki	
+++ b/Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki	
@@ -124,18 +124,16 @@ Public derivation is used at this level.
 
 ==Address Discovery==
 
-The multisig descriptor that is generated from the cosigners combined key records should be used to generate and discover addresses. For example:
+The multisig descriptor that is generated from the cosigners' combined key records should be used to generate and discover addresses. For example:
 <code>wsh(sortedmulti(2,[xfpForA/XY'/0'/0']XpubA/*,[xfpForB/XY'/0'/0']XpubB/*))#Checksum</code>
 
 # Derive the wallet's first account's node (index = 0)
 # Derive the external chain node of this account (index = 0)
 # Scan addresses of the external chain; respect the gap limit described below
-# If there are some transactions, increase the account index and go to step 2
-# If no transactions are found on the external chain, continue to search the following account indexes in compliance with the account gap limit described below.
+# If there are some transactions, increase the account index and go to Step 2
+# If no transactions are found on the external chain, continue to search the following account indices in compliance with the account gap limit described below.
 
-Please note that the algorithm works with the transaction history, not account
-balances, so you can have an account with 0 total coins and the algorithm will
-still continue with discovery.
+Please note that the algorithm works with the transaction history, not account balances, so you can have an account with 0 total coins and the algorithm will still continue with discovery.
 
 The wallet implementation should scan the accounts and addresses following the parent descriptor string.
 
@@ -147,7 +145,7 @@ Wallet software should warn when the user is trying to exceed the gap limit on a
 
 ===Account Gap Limit===
 
-Account gap limit is currently set to 5.  When the software hits an account that contains 20 unused addresses in a row, it will search the the next 4 accounts (while obeying the address gap limit), before stoping discovery.  If any transactions are found during this process, discovery is restarted (after finding 20 unused addresses) on the next account index, and the account gap limit is reset.  Only when the address gap limit is found consecutively for the account gap limit is discovery stopped.
+Account gap limit is currently set to 5.  When the software hits an account that contains 20 unused addresses in a row, it will search the next 4 accounts (while obeying the address gap limit), before stopping discovery.  If any transactions are found during this process, discovery is restarted (after finding 20 unused addresses) on the next account index, and the account gap limit is reset.  Only when the address gap limit is found consecutively for the account gap limit is discovery stopped.
 
 ==Rationale==
 
-- 
cgit v1.2.3


From f5a3140f2188905b5c5ca4217341332f4857ff1f Mon Sep 17 00:00:00 2001
From: Jonas Nick <jonasd.nick@gmail.com>
Date: Tue, 16 Mar 2021 16:01:02 +0000
Subject: BIP8: remove redundant and conflicting sentence from param selection

At the end of the param selection section it's explicitly stated that
startheight _must_ be a multiple of 2016.
---
 bip-0008.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-0008.mediawiki b/bip-0008.mediawiki
index 59bbb99..02aaaa4 100644
--- a/bip-0008.mediawiki
+++ b/bip-0008.mediawiki
@@ -48,7 +48,7 @@ The following guidelines are suggested for selecting these parameters for a soft
 
 # '''name''' should be selected such that no two softforks, concurrent or otherwise, ever use the same name. For deployments described in a single BIP, it is recommended to use the name "bipN" where N is the appropriate BIP number.
 # '''bit''' should be selected such that no two concurrent softforks use the same bit. The bit chosen should not overlap with active usage (legitimately or otherwise) for other purposes.
-# '''startheight''' should be set to some block height in the future. It should be rounded up to the next height which begins a retarget period for simplicity. If '''minimum_activation_height''' is not going to be set, then '''startheight''' should be set to a height when a majority of economic activity is expected to have upgraded to software including the activation parameters. Some allowance should be made for potential release delays. If '''minimum_activation_height''' is going to be set, then '''startheight''' can be set to be soon after software with parameters is expected to be released. This shifts the time for upgrading from before signaling begins to during the LOCKED_IN state.
+# '''startheight''' should be set to some block height in the future. If '''minimum_activation_height''' is not going to be set, then '''startheight''' should be set to a height when a majority of economic activity is expected to have upgraded to software including the activation parameters. Some allowance should be made for potential release delays. If '''minimum_activation_height''' is going to be set, then '''startheight''' can be set to be soon after software with parameters is expected to be released. This shifts the time for upgrading from before signaling begins to during the LOCKED_IN state.
 # '''timeoutheight''' should be set to a block height when it is considered reasonable to expect the entire economy to have upgraded by, probably at least 1 year, or 52416 blocks (26 retarget intervals) after '''startheight'''.
 # '''threshold''' should be 1815 blocks (90% of 2016), or 1512 (75%) for testnet.
 # '''minimum_activation_height''' should be set to several retarget periods in the future if the '''startheight''' is to be very soon after software with parameters is expected to be released. '''minimum_activation_height''' should be set to a height when a majority of economic activity is expected to have upgraded to software including the activation parameters. This allows more time to be spent in the LOCKED_IN state so that nodes can upgrade. This may be set to 0 to have the LOCKED_IN state be a single retarget period.
-- 
cgit v1.2.3


From e1def09d6d75877a447dcc418a85291c80803a33 Mon Sep 17 00:00:00 2001
From: Jonas Nick <jonasd.nick@gmail.com>
Date: Fri, 19 Mar 2021 08:20:52 +0000
Subject: BIP8: fix typo: 2 retarget intervals are 4032 blocks.

---
 bip-0008.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-0008.mediawiki b/bip-0008.mediawiki
index 02aaaa4..d357401 100644
--- a/bip-0008.mediawiki
+++ b/bip-0008.mediawiki
@@ -57,7 +57,7 @@ The following guidelines are suggested for selecting these parameters for a soft
 A later deployment using the same bit is possible as long as the startheight is after the previous one's
 timeoutheight or activation, but it is discouraged until necessary, and even then recommended to have a pause in between to detect buggy software.
 
-'''startheight''', '''timeoutheight''', and '''minimum_activation_height''' must be an exact multiple of 2016 (ie, at a retarget boundary), and '''timeoutheight''' must be at least 4096 blocks (2 retarget intervals) after '''startheight'''.
+'''startheight''', '''timeoutheight''', and '''minimum_activation_height''' must be an exact multiple of 2016 (ie, at a retarget boundary), and '''timeoutheight''' must be at least 4032 blocks (2 retarget intervals) after '''startheight'''.
 
 ===States===
 
-- 
cgit v1.2.3


From b1c2b5c67106196c2c02cc7fca33d6d63bbbe33f Mon Sep 17 00:00:00 2001
From: Robert Spigler <RobertSpigler@ProtonMail.ch>
Date: Mon, 22 Mar 2021 15:27:20 -0400
Subject: Fix errors

---
 ... Deterministic Multisignature Wallets.mediawiki | 23 ++++++++--------------
 1 file changed, 8 insertions(+), 15 deletions(-)

diff --git a/Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki b/Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki
index b0c8f26..2d1ea5a 100644
--- a/Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki	
+++ b/Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki	
@@ -23,7 +23,7 @@ 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.
+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:
 
@@ -33,7 +33,7 @@ m / purpose' / coin_type' / account' / change / address_index
 
 where the BIP43 <code>purpose'</code> 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, and these per-script derivations are made redundant with descriptors, which describe a collection of output scripts.
+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:
 
 <pre>
@@ -100,7 +100,7 @@ This level splits the key space into independent user identities, following the
 
 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.
+Accounts are numbered from index <code>0</code> in sequentially increasing manner.
 This number is used as child index in BIP32 derivation.
 
 Hardened derivation is used at this level.
@@ -111,13 +111,13 @@ This prevents key reuse - across ECDSA and Schnorr signatures, across different
 
 ===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.
+Constant <code0</code> is used for external chain and constant <code>1</code> 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.
+Addresses are numbered from index <code>0</code> in sequentially increasing manner.
 This number is used as child index in BIP32 derivation.
 
 Public derivation is used at this level.
@@ -127,15 +127,12 @@ Public derivation is used at this level.
 The multisig descriptor that is generated from the cosigners' combined key records should be used to generate and discover addresses. For example:
 <code>wsh(sortedmulti(2,[xfpForA/XY'/0'/0']XpubA/*,[xfpForB/XY'/0'/0']XpubB/*))#Checksum</code>
 
-# Derive the wallet's first account's node (index = 0)
-# Derive the external chain node of this account (index = 0)
+# Derive the external chain node of this account (constant = 0)
 # Scan addresses of the external chain; respect the gap limit described below
-# If there are some transactions, increase the account index and go to Step 2
-# If no transactions are found on the external chain, continue to search the following account indices in compliance with the account gap limit described below.
 
-Please note that the algorithm works with the transaction history, not account balances, so you can have an account with 0 total coins and the algorithm will still continue with discovery.
+Please note that the algorithm works with the transaction history, not account balances, so you can have an address with 0 total coins and the algorithm will still continue with discovery.
 
-The wallet implementation should scan the accounts and addresses following the parent descriptor string.
+The wallet implementation should scan the addresses following the parent descriptor string.
 
 ===Address Gap Limit===
 
@@ -143,10 +140,6 @@ Address gap limit is currently set to 20. If the software hits 20 unused address
 
 Wallet software should warn when the user is trying to exceed the gap limit on an external chain by generating a new address.
 
-===Account Gap Limit===
-
-Account gap limit is currently set to 5.  When the software hits an account that contains 20 unused addresses in a row, it will search the next 4 accounts (while obeying the address gap limit), before stopping discovery.  If any transactions are found during this process, discovery is restarted (after finding 20 unused addresses) on the next account index, and the account gap limit is reset.  Only when the address gap limit is found consecutively for the account gap limit is discovery stopped.
-
 ==Rationale==
 
 <references/>
-- 
cgit v1.2.3


From c7cd5e990b82c9f788afa9239fd1495fbd0ef066 Mon Sep 17 00:00:00 2001
From: Robert Spigler <RobertSpigler@ProtonMail.ch>
Date: Mon, 22 Mar 2021 15:34:18 -0400
Subject: Formatting

---
 Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki b/Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki
index 2d1ea5a..0bf6734 100644
--- a/Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki	
+++ b/Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki	
@@ -111,7 +111,7 @@ This prevents key reuse - across ECDSA and Schnorr signatures, across different
 
 ===Change===
 
-Constant <code0</code> is used for external chain and constant <code>1</code> 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.
+Constant <code>0</code> is used for external chain and constant <code>1</code> 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.
 
-- 
cgit v1.2.3


From a516c135ab622dcf0a4ecf204476034cb086d287 Mon Sep 17 00:00:00 2001
From: Anthony Towns <aj@erisian.com.au>
Date: Thu, 25 Mar 2021 15:36:51 +1000
Subject: BIP341/342: document current deployment status

---
 bip-0341.mediawiki | 4 +++-
 bip-0342.mediawiki | 4 ++++
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/bip-0341.mediawiki b/bip-0341.mediawiki
index 0f8d32a..1e579e1 100644
--- a/bip-0341.mediawiki
+++ b/bip-0341.mediawiki
@@ -294,7 +294,9 @@ Examples of preimage for sighashing for each of the sighash modes.
 
 == Deployment ==
 
-TODO
+This BIP is deployed concurrently with [[bip-0342.mediawiki|BIP342]].
+
+For Bitcoin signet, these BIPs are always active.
 
 == Backwards compatibility ==
 As a soft fork, older software will continue to operate without modification.
diff --git a/bip-0342.mediawiki b/bip-0342.mediawiki
index 7e00a2e..1e36a54 100644
--- a/bip-0342.mediawiki
+++ b/bip-0342.mediawiki
@@ -133,6 +133,10 @@ In addition to changing the semantics of a number of opcodes, there are also som
 
 <references />
 
+==Deployment==
+
+This proposal is deployed identically to Taproot ([[bip-0341.mediawiki|BIP341]]).
+
 ==Examples==
 
 ==Acknowledgements==
-- 
cgit v1.2.3


From 1145b99735a40447329f33f75a52b28e39ed5746 Mon Sep 17 00:00:00 2001
From: MarcoFalke <falke.marco@gmail.com>
Date: Mon, 29 Mar 2021 13:52:28 +0200
Subject: BIP 325: Remove empty section "Acknowledgement"

---
 bip-0325.mediawiki | 4 ----
 1 file changed, 4 deletions(-)

diff --git a/bip-0325.mediawiki b/bip-0325.mediawiki
index 5a9f3f1..be4ad02 100644
--- a/bip-0325.mediawiki
+++ b/bip-0325.mediawiki
@@ -110,10 +110,6 @@ Other software need not add block signature validation code that they will not u
 
 Pull request at https://github.com/bitcoin/bitcoin/pull/18267
 
-== Acknowledgements ==
-
-TODO
-
 == References ==
 
 # Original mailing list thread: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-March/016734.html
-- 
cgit v1.2.3


From f45d7c578481540fd88436a53b4123e332355ded Mon Sep 17 00:00:00 2001
From: kiminuo <58662979+kiminuo@users.noreply.github.com>
Date: Wed, 31 Mar 2021 10:22:39 +0200
Subject: Update bip-0174.mediawiki

I, personally, find this easier to read.
---
 bip-0174.mediawiki | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/bip-0174.mediawiki b/bip-0174.mediawiki
index 75fea0e..56d9cdb 100644
--- a/bip-0174.mediawiki
+++ b/bip-0174.mediawiki
@@ -74,13 +74,11 @@ Where:
 : Magic bytes which are ASCII for psbt <ref>'''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. </ref> followed by a separator of <tt>0xFF</tt>
-<ref>'''Why Use a separator after the magic bytes?''' The separator
+Partially Signed Bitcoin Transaction. </ref> followed by a separator of <tt>0xFF</tt><ref>'''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 <tt>0xff</tt> 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.</ref>. This integer must be serialized
-in most significant byte order.
+in the non-PSBT format will be able to be unserialized by a PSBT unserializer.</ref>. This integer must be serialized in most significant byte order.
 
 The currently defined global types are as follows:
 
-- 
cgit v1.2.3


From 15503232255e82e70d2dc4443709221a2e5dbfd4 Mon Sep 17 00:00:00 2001
From: "Esteban A. Maringolo" <emaringolo@gmail.com>
Date: Wed, 31 Mar 2021 17:01:51 -0300
Subject: Add reference implementation

---
 bip-0039.mediawiki | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/bip-0039.mediawiki b/bip-0039.mediawiki
index ab1c3b8..2093454 100644
--- a/bip-0039.mediawiki
+++ b/bip-0039.mediawiki
@@ -176,6 +176,9 @@ 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
 * https://github.com/yuzushioh/WalletKit
-- 
cgit v1.2.3


From 89c7529650913ec890c77aa71d5874cb09195e9e Mon Sep 17 00:00:00 2001
From: Hugo Nguyen <hugh.hn@gmail.com>
Date: Sun, 4 Apr 2021 23:46:06 -0700
Subject: BIP: Bitcoin Secure Multisig Setup (BSMS)

---
 bip-hugonguyen-bsms.mediawiki | 394 ++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 394 insertions(+)
 create mode 100644 bip-hugonguyen-bsms.mediawiki

diff --git a/bip-hugonguyen-bsms.mediawiki b/bip-hugonguyen-bsms.mediawiki
new file mode 100644
index 0000000..95493aa
--- /dev/null
+++ b/bip-hugonguyen-bsms.mediawiki
@@ -0,0 +1,394 @@
+<pre>
+  BIP: To be determined
+  Layer: Applications
+  Title: Bitcoin Secure Multisig Setup (BSMS)
+  Author: Hugo Nguyen <hugo at nunchuk.io>, Peter Gray <peter at coinkite.com>, Marko Bencun <marko at shiftcrypto.ch>, Aaron Chen <aarondongchen at gmail.com>, Rodolfo Novak <rodolfo at coinkite.com>
+  Comments-Summary: No comments yet.
+  Comments-URI:
+  Status: Proposed
+  Type: Standards Track
+  Created: 2020-11-10
+  License: BSD-2-Clause
+</pre>
+
+==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 Extension===
+All descriptor and key records should have a <tt>.bsms</tt> file extension. Encrypted data should have a <tt>.dat</tt> 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 a participating member in the multisig. Its responsibilities include providing its key record -- which contains an Extended Public Key (XPUB) -- to the Coordinator, verifying that its XPUB 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 (<tt>M</tt> and <tt>N</tt>).
+* 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 <tt>TOKEN</tt> to each Signer over a secure channel. The Signer can use the <tt>TOKEN</tt> to derive an <tt>ENCRYPTION_KEY</tt>. Refer to the Encryption section below for details on the <tt>TOKEN</tt>, the key derivation function and the encryption scheme. Depending on the use case, the Coordinator can decide whether to share one common <tt>TOKEN</tt> for all Signers, or to have one per Signer.
+* If encryption is disabled, the <tt>TOKEN</tt> is set to <tt>0</tt>, and all the encryption/decryption steps below can be skipped.
+
+=====Signer=====
+
+* The Signer initiates the multisig wallet creation session by setting the <tt>TOKEN</tt>. The Signer derives an <tt>ENCRYPTION_KEY</tt> from the <tt>TOKEN</tt>. The Signer can keep the session open until a different value for the <tt>TOKEN</tt> is set.
+* The Signer generates a key record by prompting the user for a multisig derivation path and retrieves the XPUB 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 XPUBs for different wallets.
+* The first line in the record must be the specification version (<tt>BSMS 1.0</tt> as of this writing). The second line must be the hex-encoded <tt>TOKEN</tt>. The third line must be the <tt>KEY</tt>. The <tt>KEY</tt> is an XPUB plus its key origin information, written in the descriptor-defined format, i.e.: <tt>[{master key fingerprint}/{derivation path}]{XPUB}</tt>. The fourth line is a text description of the key, 80 characters maximum. The fifth line must be a <tt>SIG</tt>, whereas <tt>SIG</tt> is the signature generated by using the private key associated with the 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 (<tt>MAC</tt>) for the record. The first 16 bytes of the <tt>MAC</tt> serves as the Initialization Vector (<tt>IV</tt>) for the encryption.
+* The Signer encrypts the key record with the <tt>ENCRYPTION_KEY</tt> and <tt>IV</tt>.
+* The Signer encodes the <tt>MAC</tt> and the ciphertext into hexadecimal format, then concatenates the results: <tt>(MAC || ciphertext)</tt>.
+
+====Round 2====
+
+=====Coordinator=====
+
+* The Coordinator gathers key records from all participating Signers. The Coordinator verifies that there are exactly <tt>N</tt> unique key records before the wallet setup session expires.
+* For each key record, the Coordinator extracts the <tt>MAC</tt> from the data, sets <tt>IV</tt> to the first 16 bytes of the <tt>MAC</tt>, then decrypts the ciphertext using the <tt>ENCRYPTION_KEY</tt> and <tt>IV</tt>.
+* The Coordinator verifies that the included <tt>MAC</tt> is valid given the plaintext.
+* The Coordinator verifies that the key records have compatible specification versions.
+* The Coordinator verifies that the included <tt>SIG</tt> is valid given the <tt>KEY</tt>.
+* 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 (<tt>BSMS 1.0</tt> as of this writing). The second line must be a comma-separated list of accepted derivation paths that the Signers can use to generate addresses from the included XPUBs. The paths must start with <tt>/</tt> and use non-hardened derivation. For example, <tt>/0/*</tt> and <tt>/1/*</tt> are some common paths. If there are no restrictions, it must say <tt>No path restrictions</tt>. The third line must be the descriptor string plus a <tt>CHECKSUM</tt>, all in one line. The <tt>CHECKSUM</tt> has [https://github.com/bitcoin/bitcoin/blob/master/doc/descriptors.md#checksums BECH32 encoding].
+* The Coordinator calculates the <tt>MAC</tt> for the record. The first 16 bytes of the <tt>MAC</tt> serves as the <tt>IV</tt> for the encryption.. 
+* The Coordinator encrypts the descriptor record with the <tt>ENCRYPTION_KEY</tt> and <tt>IV</tt>.
+* The Coordinator encodes the <tt>MAC</tt> and the ciphertext into hexadecimal format, then concatenates the results: <tt>(MAC || ciphertext)</tt>.
+* The Coordinator sends the encrypted descriptor record to all participating Signers.
+
+=====Signer=====
+
+* The Signer imports the descriptor record.
+* The Signer extracts the <tt>MAC</tt> from the data, sets <tt>IV</tt> to the first 16 bytes of the <tt>MAC</tt>, then decrypts the ciphertext using the <tt>ENCRYPTION_KEY</tt> (derived from the open session) and <tt>IV</tt>.
+* The Signer verifies that the included <tt>MAC</tt> is valid given the plaintext.
+* The Signer verifies that it can support the included specification version.
+* The Signer verifies that it is compatible with the derivation path restrictions.
+* The Signer verifies the descriptor’s <tt>CHECKSUM</tt>.
+* The Signer verifies that it can support the descriptor.
+* The Signer checks that its <tt>KEY</tt> is included in the descriptor, using path and fingerprint information provided. The check must perform an exact match on the <tt>KEY</tt>s and not using shortcuts such as matching fingerprints, which is trivial to spoof.
+* For confirmation, the Signer must display to the user the <tt>CHECKSUM</tt>, the derivation path restrictions and the policy parameters, such as <tt>M</tt>, <tt>N</tt> and the position(s) of its own XPUB in the policy script. The total number of Signers, <tt>N</tt>, is important to prevent a <tt>KEY</tt> insertion attack. The position is important for scripts where key order matters. When applicable, all positions of the XPUB must be displayed. The full descriptor must also be available for review upon user request. 
+* When possible, the Signer should also show a preview of the first address(es) of the wallet.
+* Parties must check with each other that all Signers have verified the descriptor and has 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.
+
+# <tt>NO_ENCRYPTION</tt> : the <tt>TOKEN</tt> is set to <tt>0</tt>. Encryption is disabled.
+# <tt>STANDARD</tt> : the <tt>TOKEN</tt> is a 64-bit nonce.
+# <tt>EXTENDED</tt> : the <tt>TOKEN</tt> is a 96-bit nonce.
+
+The <tt>TOKEN</tt> 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 (6 words in <tt>STANDARD</tt> mode; 9 words in <tt>EXTENDED</tt> mode).
+* 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:
+
+<tt>DKey = PBKDF2(PRF, Password, Salt, c, dkLen)</tt>
+
+Whereas:
+
+* PRF = SHA512
+* Password = "No SPOF"
+* Salt = <tt>TOKEN</tt>
+* c = 2048
+* dkLen = 256
+* DKey = Derived <tt>ENCRYPTION_KEY</tt>
+
+====Encryption Scheme====
+The encryption scheme is [https://tools.ietf.org/html/rfc3686 AES-256-CTR].
+
+<tt>MAC = HMAC-SHA256(HMAC_Key, hex-encoded TOKEN || Data)</tt>
+
+<tt>IV = First 16 bytes of MAC</tt>
+
+<tt>Ciphertext = AES-256-CTR-Encrypt(Plaintext, DKey, IV)</tt>
+
+<tt>Plaintext = AES-256-CTR-Decrypt(Ciphertext, DKey, IV)</tt>
+
+Whereas:
+* DKey = <tt>ENCRYPTION_KEY</tt>
+* HMAC_Key = SHA256(<tt>ENCRYPTION_KEY</tt>)
+* Data = the plaintext, e.g. the entire key record in round 1 and the entire descriptor record in round 2
+
+The <tt>MAC</tt> is to be sent along with the key and descriptor record, as specified above. Because it is a <tt>MAC</tt> 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.
+
+==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.
+
+==Security==
+
+This proposal introduces two layers of protection. The first one is a temporary, secret <tt>TOKEN</tt>. The second one is the descriptor <tt>CHECKSUM</tt>.
+
+The <tt>TOKEN</tt> is used to encrypt the two rounds of communication between the Signer and the Coordinator. A <tt>MAC</tt> is also generated from the <tt>TOKEN</tt> and plaintext to authenticate the data being exchanged. The <tt>TOKEN</tt> is only needed during the setup phase, and can be safely discarded afterwards.
+
+The descriptor <tt>CHECKSUM</tt>, 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 descriptor <tt>CHECKSUM</tt>. Parties must check with each other that all Signers have the same <tt>CHECKSUM</tt>, along with the policy parameters, to reduce the chance of tampering. The <tt>CHECKSUM</tt> must be persisted along with the descriptor in each Signer’s storage.
+
+The <tt>TOKEN</tt> and the <tt>CHECKSUM</tt> can’t guarantee complete protection, since that depends on the overall security of all parties in the setup, but they can make it significantly harder for an attacker to tamper with the multisig configuration.
+
+==Privacy==
+Encryption helps improve the privacy of the wallet by avoiding sharing XPUBs and descriptors in plaintext.
+
+If the parties wish to have stronger privacy, it is recommended to use a higher number of bits for the <tt>TOKEN</tt>, and to completely erase knowledge of the <tt>TOKEN</tt> after the multisig wallet has been set up.
+
+==Test Vectors==
+
+===Mode: <tt>NO_ENCRYPTION</tt>===
+====ROUND 1====
+* Coordinator
+** M-of-N: 2/2
+** ADDRESS_TYPE: NATIVE_SEGWIT
+** TOKEN: 0
+
+* Signer 1
+** MASTER_KEY_FINGERPRINT: 539f3d89
+** PRIVATE_KEY (m/48'/0'/0'/2'): KyoXqiwiz6qm21BSYebiZFfNF7obkhiJW6TdPMZTQQMF4kZtfD78
+** XPUB (m/48'/0'/0'/2'): xpub6ETerig7tq89mtaD8Gau2xRWxouRMBy6XHqciA8GZzC2dJv3w6FxfgoegH4b2qYF4oG6VBrhpLrauPs5E1q58GLCnhKp6g9QsV9ZA7J5JNa
+** Legacy signature
+** <tt>signer_1_key.bsms</tt>:
+<pre>BSMS 1.0
+00
+[539f3d89/48'/0'/0'/2']xpub6ETerig7tq89mtaD8Gau2xRWxouRMBy6XHqciA8GZzC2dJv3w6FxfgoegH4b2qYF4oG6VBrhpLrauPs5E1q58GLCnhKp6g9QsV9ZA7J5JNa
+Signer 1 key
+IPXsnNSZb8M6H4fAWtpjAc75hyHHd89fskpM5o7qFg+mPDzEPc1k2mjuIpVIIzaCe45FwPfAAa91RaStfC5Sak0=</pre>
+
+* Signer 2
+** MASTER_KEY_FINGERPRINT: f8b12aa6
+** PRIVATE_KEY (m/48'/0'/0'/2'): L1zht7muKnUYFMdzC3jwXd78u8tGoKr46AXGh4waF9nphUYWq7ow
+** XPUB (m/48'/0'/0'/2'): xpub6EWPNhGSX86SN4J2DrBUaQ826o6V4egHqAJZUDJqnsthv9CcjBZV79u68M3YZkuTJnJBXfCrHuJy97fkVurntwgt3V7Ms5hXpJV2vS8fQZM
+** Legacy signature
+** <tt>signer_2_key.bsms</tt>:
+<pre>BSMS 1.0
+00
+[f8b12aa6/48'/0'/0'/2']xpub6EWPNhGSX86SN4J2DrBUaQ826o6V4egHqAJZUDJqnsthv9CcjBZV79u68M3YZkuTJnJBXfCrHuJy97fkVurntwgt3V7Ms5hXpJV2vS8fQZM
+Signer 2 key
+H38+lp9iaesBeCN05BDTH/SnmarlH6+X+Kmw1pgCk+c1Pc1evYIdBag9Nc0nsKhvPtfEbRt9r/qsUVZ5onCtBTc=</pre>
+
+====ROUND 2====
+* Coordinator
+** <tt>my_multisig_wallet.bsms</tt>:
+<pre>BSMS 1.0
+/0/*,/1/*
+wsh(sortedmulti(2,[539f3d89/48'/0'/0'/2']xpub6ETerig7tq89mtaD8Gau2xRWxouRMBy6XHqciA8GZzC2dJv3w6FxfgoegH4b2qYF4oG6VBrhpLrauPs5E1q58GLCnhKp6g9QsV9ZA7J5JNa/*,[f8b12aa6/48'/0'/0'/2']xpub6EWPNhGSX86SN4J2DrBUaQ826o6V4egHqAJZUDJqnsthv9CcjBZV79u68M3YZkuTJnJBXfCrHuJy97fkVurntwgt3V7Ms5hXpJV2vS8fQZM/*))#fntxdj7p</pre>
+
+===Mode: <tt>STANDARD</tt> Encryption===
+====ROUND 1====
+* Coordinator
+** M-of-N: 2/2
+** ADDRESS_TYPE: NATIVE_SEGWIT
+** TOKEN (hex): 1ed4ba49e96336b8
+*** TOKEN (decimal): 2221605342811469496
+*** TOKEN (mnemonic): burst place mystery spot cricket foster
+** ENCRYPTION_KEY (hex): 72185a0e25b4efc5d6ac0f8ed32b0165199100e32385040e3a48eb30164bf492
+
+* Signer 1
+** MASTER_KEY_FINGERPRINT: 98d79e95
+** PRIVATE_KEY (m/48'/0'/0'/2'): KydC7hZFtWe56oQUAw14HvQ3gKeKVd3m8frFgVMxUqpuhKHvcmm3
+** XPUB (m/48'/0'/0'/2'): xpub6DvvwHS5pd1D36xt4YBGJvtdThWXfn8L9qRj9DbFMExMeP6eBE6Aw9WyBC7XUQwiPPDFurirewsKZpYv68yTV5RBy7SZmw45QEkaLka5BCt
+** Legacy signature
+** <tt>signer_1_key.bsms</tt>:
+<pre>BSMS 1.0
+1ed4ba49e96336b8
+[98d79e95/48'/0'/0'/2']xpub6DvvwHS5pd1D36xt4YBGJvtdThWXfn8L9qRj9DbFMExMeP6eBE6Aw9WyBC7XUQwiPPDFurirewsKZpYv68yTV5RBy7SZmw45QEkaLka5BCt
+Signer 1 key
+HxtPoP0DrQSac/7ypcwC07R2s6jjpXR6Li2Q92zXj/FSIMQcV5yOU0/ONsDgHXamq0gD5DfPbvuVCp9ZJubclV4=</pre>
+
+* Signer 1 encryption
+** HMAC_KEY (hex): 4dab3988cbc683ad7a8c93d43f9b11a78b63a93d5e33ea19c603f4b7b87ac284
+** MAC (hex): afe99e92f0eadc3308eb990045e90a4f54e9f59d22aae5034ac3d866d29c508d
+** IV (hex) : afe99e92f0eadc3308eb990045e90a4f
+** CIPHERTEXT (hex): 214ec9a861a238ba7f0412305a97a6e0faa332be15af09127e131d669e5d55d73891580a5808cea5d2bf39f43496d3c0f8236eff3854fcc7446daf9d2b58fd40d97ce3b1745de2959e29767039b99969821400eca0c3517fae56d2d24d5235a3430af1ed894b68681d706cce7c75adf35d8580603aa302bc01fef06d0336a37f19dd46100baa9e4eabd8796a810e13941ad0980c126ad55d6a4bbef11a7bf893b7d2ed8fb0d8324c4c9b512d4d1e75096c63511e15018fc832816b5639d58fc28c60c049487d04bd5a6cb32aa1381d0809660d54376b9f63325c18cfd1ac5024088e74cb703fe165972cc4485abb1feefe92a0b4ea297fe2f4f7416eeee1efc9b942540931ef
+** <tt>signer_1_key.dat</tt>: <pre>afe99e92f0eadc3308eb990045e90a4f54e9f59d22aae5034ac3d866d29c508d214ec9a861a238ba7f0412305a97a6e0faa332be15af09127e131d669e5d55d73891580a5808cea5d2bf39f43496d3c0f8236eff3854fcc7446daf9d2b58fd40d97ce3b1745de2959e29767039b99969821400eca0c3517fae56d2d24d5235a3430af1ed894b68681d706cce7c75adf35d8580603aa302bc01fef06d0336a37f19dd46100baa9e4eabd8796a810e13941ad0980c126ad55d6a4bbef11a7bf893b7d2ed8fb0d8324c4c9b512d4d1e75096c63511e15018fc832816b5639d58fc28c60c049487d04bd5a6cb32aa1381d0809660d54376b9f63325c18cfd1ac5024088e74cb703fe165972cc4485abb1feefe92a0b4ea297fe2f4f7416eeee1efc9b942540931ef</pre>
+
+* Signer 2
+** MASTER_KEY_FINGERPRINT: 3e94b5a1
+** PRIVATE_KEY (m/48'/0'/0'/2'): KyPh5XYjExjNHPiBjYhp8iAntAehrDziiwRv7y9Ln6eK9QU2xP55
+** XPUB (m/48'/0'/0'/2'): xpub6E1W1DUYY29V2b8czCcpi36GG2uD33B11vwNopgTZwsVyfgAkA4kPCqLP5R4YzaRvzW17CQrDkgmDQbA848AdkR7W18nNvMKXzzCBSnZP9c
+** Legacy signature
+** <tt>signer_2_key.bsms</tt>:
+<pre>BSMS 1.0
+1ed4ba49e96336b8
+[3e94b5a1/48'/0'/0'/2']xpub6E1W1DUYY29V2b8czCcpi36GG2uD33B11vwNopgTZwsVyfgAkA4kPCqLP5R4YzaRvzW17CQrDkgmDQbA848AdkR7W18nNvMKXzzCBSnZP9c
+Signer 2 key
+ILR49QLy9+xkMS11TIXJRSMgOQOzGbAaooq4/ZRcd8VgM6j5upJMI0mjJHseQOMYSGk8FqjXZbMvBGyiX9wdutM=</pre>
+
+* Signer 2 encryption
+** HMAC_KEY (hex): 4dab3988cbc683ad7a8c93d43f9b11a78b63a93d5e33ea19c603f4b7b87ac284
+** MAC (hex): 5c7cb2ac407cd60b1f2b86ef46077d3a312b6ce921df2a141347e8bf1e5c6573
+** IV (hex) : 5c7cb2ac407cd60b1f2b86ef46077d3a
+** CIPHERTEXT (hex): f23e6c76ff45d308dea6014030a274127ad437228f1d5ec2431d2ea9e3cedd5b0a207a9efa6f926d5420205003f3cb9c4b82b2d595180e62a173a2e5aa0322de48a70a873f641bdae1764e6b1667c241e0fe03a4ccdc3fe0cfa5f75b239d6497c3b69dca17bb685ba70b307d1243836d8fb198ce727cfae4057ee0b4fdcb09f4ba5ae127f49c5de780edb4e40aec96303c8a7b98b1b8e53dd5e07e01d4f3ffd836763209a1f0cbc61adcfdc2951e77528ee7b6e68114c3a4bec38875d285021e68ae8aa913bb1e2e65dd52c649a0e98bfb4e8bab6dd10295c1167a0854ba44f094feb75d2fb00c944f07d4b47114f483df9838459316f3ddbc4a82e6507881931f8e20f5b805
+** <tt>signer_2_key.dat</tt>: <pre>5c7cb2ac407cd60b1f2b86ef46077d3a312b6ce921df2a141347e8bf1e5c6573f23e6c76ff45d308dea6014030a274127ad437228f1d5ec2431d2ea9e3cedd5b0a207a9efa6f926d5420205003f3cb9c4b82b2d595180e62a173a2e5aa0322de48a70a873f641bdae1764e6b1667c241e0fe03a4ccdc3fe0cfa5f75b239d6497c3b69dca17bb685ba70b307d1243836d8fb198ce727cfae4057ee0b4fdcb09f4ba5ae127f49c5de780edb4e40aec96303c8a7b98b1b8e53dd5e07e01d4f3ffd836763209a1f0cbc61adcfdc2951e77528ee7b6e68114c3a4bec38875d285021e68ae8aa913bb1e2e65dd52c649a0e98bfb4e8bab6dd10295c1167a0854ba44f094feb75d2fb00c944f07d4b47114f483df9838459316f3ddbc4a82e6507881931f8e20f5b805</pre>
+
+====ROUND 2====
+*Coordinator
+** <tt>my_multisig_wallet.bsms</tt>:
+<pre>BSMS 1.0
+/0/*,/1/*
+wsh(sortedmulti(2,[98d79e95/48'/0'/0'/2']xpub6DvvwHS5pd1D36xt4YBGJvtdThWXfn8L9qRj9DbFMExMeP6eBE6Aw9WyBC7XUQwiPPDFurirewsKZpYv68yTV5RBy7SZmw45QEkaLka5BCt/*,[3e94b5a1/48'/0'/0'/2']xpub6E1W1DUYY29V2b8czCcpi36GG2uD33B11vwNopgTZwsVyfgAkA4kPCqLP5R4YzaRvzW17CQrDkgmDQbA848AdkR7W18nNvMKXzzCBSnZP9c/*))#x0lx92qk</pre>
+
+*Coordinator encryption
+** HMAC_KEY (hex): 4dab3988cbc683ad7a8c93d43f9b11a78b63a93d5e33ea19c603f4b7b87ac284
+** MAC (hex): df3d06db6c8b8a5f25de202e10ea225df6415d1ed0e36c64cc2be1b7e86c2a38
+** IV (hex) : df3d06db6c8b8a5f25de202e10ea225d
+** CIPHERTEXT (hex): 2761e6bfe839586b4c90954200bc4ce6d39ef164c5d14997755575d1691ee249ffd20beda526f57a7424907f839c6c2e3ecd46889ede290a2c81de22d3f33a7fa5e55ec95c0e26005c596d0f6346f819823f361f9f9f54d1eae48b325240d66c5888bd5ebab843061dcdd73b675346da982646c83026694d757661d31c2d654fb263c9ab3e874a258bc234c48532f15e9450c982fcf161404746e9f23d25e17b74139cd799983fd0c7a7a0386a823d3789b4578879a764172cc8ef96ab003eee24f6288007d31e2b999aff5a6d30cc524a0111a99730a29cf28ae41dbff6ce21ca6bc1df37074228178048e835584e6e70dba941154d024cd03cb6c56d0bde441ce464aa749de5e814dd30e21b75f62e831ac1f28eda1a7ba7e122076789e284402c8ba85b5a0e864bce220e3c78fa2f465e2bcf6b1d378816319de99f99ce7068
+** <tt>my_multisig_wallet.dat</tt>: <pre>df3d06db6c8b8a5f25de202e10ea225df6415d1ed0e36c64cc2be1b7e86c2a382761e6bfe839586b4c90954200bc4ce6d39ef164c5d14997755575d1691ee249ffd20beda526f57a7424907f839c6c2e3ecd46889ede290a2c81de22d3f33a7fa5e55ec95c0e26005c596d0f6346f819823f361f9f9f54d1eae48b325240d66c5888bd5ebab843061dcdd73b675346da982646c83026694d757661d31c2d654fb263c9ab3e874a258bc234c48532f15e9450c982fcf161404746e9f23d25e17b74139cd799983fd0c7a7a0386a823d3789b4578879a764172cc8ef96ab003eee24f6288007d31e2b999aff5a6d30cc524a0111a99730a29cf28ae41dbff6ce21ca6bc1df37074228178048e835584e6e70dba941154d024cd03cb6c56d0bde441ce464aa749de5e814dd30e21b75f62e831ac1f28eda1a7ba7e122076789e284402c8ba85b5a0e864bce220e3c78fa2f465e2bcf6b1d378816319de99f99ce7068</pre>
+
+===Mode: <tt>EXTENDED</tt> Encryption===
+====ROUND 1====
+*Coordinator
+** M-of-N: 2/3
+** ADDRESS_TYPE: NESTED_SEGWIT
+** TOKEN for Signer 1 (hex): 654d63309464afcda558c6aa
+*** TOKEN (decimal): 31351541690484562733651510954
+*** TOKEN (mnemonic): grab help slow churn enough traffic nice boat price
+*** ENCRYPTION_KEY (hex): 4073adac2351e164b8d68039abd9d4b8e4d07adccfdf73ece6e236d60b107802
+** TOKEN for Signer 2 (hex): b0344f51d5cb04083d598fa3
+*** TOKEN (decimal): 54532600447720520868878192547
+*** TOKEN (mnemonic): rabbit pen stamp process raccoon advice voice cradle person
+*** ENCRYPTION_KEY (hex): 6bae6b670e257d7468c3e90194029dd468a2f39d8b9a3ff187b08209b1d409b6
+** TOKEN for Signer 3 (hex): 163fd307195982c4c39d50bb
+*** TOKEN (decimal): 6885829092987042066541138107
+*** TOKEN (mnemonic): bike write scrub crawl oblige give attack present rookie
+*** ENCRYPTION_KEY (hex): c78b94589214b6dc98b337ba4ce54380553ed00a1e5b1955fc540ce3b30d6566
+
+* Signer 1
+** MASTER_KEY_FINGERPRINT: 110dc257
+** PRIVATE_KEY (m/48'/0'/0'/1'): KzshDDEBhzyiwXHoyE7ZiLegzztEy54AG6Wq8N844LqHSQMHt4Ji
+** XPUB (m/48'/0'/0'/1'): xpub6EPQbDFezXYvVFHqnc8R7QUSE8hTepbyCXU7jJBT4dVm2rQHe1i6isqoj59qhyBiCdKquo6QsgMZNHvEz3BM4cNSszF25siTqLUCznBm8vk
+** Legacy signature
+** <tt>signer_1_key.bsms</tt>:
+<pre>BSMS 1.0
+654d63309464afcda558c6aa
+[110dc257/48'/0'/0'/1']xpub6EPQbDFezXYvVFHqnc8R7QUSE8hTepbyCXU7jJBT4dVm2rQHe1i6isqoj59qhyBiCdKquo6QsgMZNHvEz3BM4cNSszF25siTqLUCznBm8vk
+Signer 1 key
+IDX6xLdM4XjetYPvVfpVBXAfT7oE3tHAOB4blZpbIst8bjJ+LbDeP4tZl4O8utAuys9igXE0G3kaHz1mg/+OU8w=</pre>
+
+* Signer 1 encryption
+** HMAC_KEY (hex): f43c359a4b3d7b2e01be73c54519b12545ca9a23a86f824aadf577b314a7caa7
+** MAC (hex): 40b6b43e2f1bc01b748eb242235d7e09fa8a2fd6cebe35784cf3adf81910ec98
+** IV (hex) : 40b6b43e2f1bc01b748eb242235d7e09
+** CIPHERTEXT (hex): 0877987764401c27e6c60ed2f1bb89dff1dbc5e8204149f682d53049bffe39553f24af3928aa2f78ac2d04ac5baa0c3ec39aaccf0d258e7bb6659a7b92e92f2c2784a94f4df8e8af2270d9d411bfff2cfb9f71b4e1ac87561c7d2ac57ca86a1f9716d5da7571719d24830fc8d015a0daf04b3742439484488798335357f2eeaa8e2db2ba630f9dffd88236e327ab5bfcfb6e29ee3ef6cc18e0b71c1731465c2351e76b92f7b1bd28ef6eff5414c22aa6c80090fa59b973c22e3044e92dbf3688990a49a42828e52c1e686f1193dcdf7b7118930e01419fe938c6811c58c84c36d692fd52846f998bc328471f1e73c22261791a08cda096ee3ac8b37f31afd0b1d9c335ff9ac67ff230eb0d69f2d7
+** <tt>signer_1_key.dat</tt>: <pre>40b6b43e2f1bc01b748eb242235d7e09fa8a2fd6cebe35784cf3adf81910ec980877987764401c27e6c60ed2f1bb89dff1dbc5e8204149f682d53049bffe39553f24af3928aa2f78ac2d04ac5baa0c3ec39aaccf0d258e7bb6659a7b92e92f2c2784a94f4df8e8af2270d9d411bfff2cfb9f71b4e1ac87561c7d2ac57ca86a1f9716d5da7571719d24830fc8d015a0daf04b3742439484488798335357f2eeaa8e2db2ba630f9dffd88236e327ab5bfcfb6e29ee3ef6cc18e0b71c1731465c2351e76b92f7b1bd28ef6eff5414c22aa6c80090fa59b973c22e3044e92dbf3688990a49a42828e52c1e686f1193dcdf7b7118930e01419fe938c6811c58c84c36d692fd52846f998bc328471f1e73c22261791a08cda096ee3ac8b37f31afd0b1d9c335ff9ac67ff230eb0d69f2d7</pre>
+
+* Signer 2
+** MASTER_KEY_FINGERPRINT: 5c890401
+** PRIVATE_KEY (m/48'/0'/0'/1'): L41Jnc9CdBtBJd18429MDGcTgP2DNoXaKyyGr271ndTprvrHXDQf
+** XPUB (m/48'/0'/0'/1'): xpub6EW1SmjSXq9YwVwcan5qWEncgx89SozMvGNpYF6hfZHYNTikNZ4gsXuVhHTi6xYJCkmY4X4wpPPS5Gr7aY39dVJMS2TGfihr25oaspKtU8q
+** Legacy signature
+** <tt>signer_2_key.bsms</tt>:
+<pre>BSMS 1.0
+b0344f51d5cb04083d598fa3
+[5c890401/48'/0'/0'/1']xpub6EW1SmjSXq9YwVwcan5qWEncgx89SozMvGNpYF6hfZHYNTikNZ4gsXuVhHTi6xYJCkmY4X4wpPPS5Gr7aY39dVJMS2TGfihr25oaspKtU8q
+Signer 2 key
+H5kN6UHaK2xACB6iYdTxxQPD8qyFEYv9iMsQs5B0MRfCM7NA5GB+7EFgmBpSctwt6B122zWBr6mRjpYjKmj+7hs=</pre>
+
+* Signer 2 encryption
+** HMAC_KEY (hex): e0a20b5f5285fbaa35aad08fb70f5626c9abbe1b384a4950735b28aca6325ff2
+** MAC (hex): 3a6deec8dbdbd6606a52c7d7e64eca4f972a293cbabac6f62736629fbe77928a
+** IV (hex) : 3a6deec8dbdbd6606a52c7d7e64eca4f
+** CIPHERTEXT (hex): bb0fb72f61b0c4858bd9c65235390b67651b94c4b0329238b0116dd6d3365ade33cb1c1b1619638968791a5d2d1d263d90280bdad8d9ca24c34a78e320076e0dccf59e7f729b541b44bbe40ba803dedd3b17c49765377cb2d913a856b86c3dd383dab475790e89226ed8ef2301574212d2809ed9c099aa67be434024ee2a4e82a146300acf755863da64807cb7bb2636f6616489636d254a870778d3540832aea44abac4328b5d90f3e6045ef36a526ce5d575f2305e3e4699dccbc713e9e68f50364036c1054c2a506aab77ea7c43a89536947c24330b09a62a90c3b4ae2d452f96ef34ec871af2c52d68ddede2503c87e2ba68d5cf9be589457879e06021ea6a6176f7dded820ba4c0e709e2a2
+** <tt>signer_2_key.dat</tt>: <pre>3a6deec8dbdbd6606a52c7d7e64eca4f972a293cbabac6f62736629fbe77928abb0fb72f61b0c4858bd9c65235390b67651b94c4b0329238b0116dd6d3365ade33cb1c1b1619638968791a5d2d1d263d90280bdad8d9ca24c34a78e320076e0dccf59e7f729b541b44bbe40ba803dedd3b17c49765377cb2d913a856b86c3dd383dab475790e89226ed8ef2301574212d2809ed9c099aa67be434024ee2a4e82a146300acf755863da64807cb7bb2636f6616489636d254a870778d3540832aea44abac4328b5d90f3e6045ef36a526ce5d575f2305e3e4699dccbc713e9e68f50364036c1054c2a506aab77ea7c43a89536947c24330b09a62a90c3b4ae2d452f96ef34ec871af2c52d68ddede2503c87e2ba68d5cf9be589457879e06021ea6a6176f7dded820ba4c0e709e2a2</pre>
+
+* Signer 3
+** MASTER_KEY_FINGERPRINT: 614cbf5f
+** PRIVATE_KEY (m/48'/0'/0'/1'): L2ccRLzH7GfVxWpU8YSY9y5UGyRoqW3UdeNT1vGfVbxAGhwU5qhD
+** XPUB (m/48'/0'/0'/1'): xpub6F9TfWTFcMYy5Ycd2ka2az1brJj78J2isLAWptZnCpFsesss5sZv5B8xsgt71ZXfhDWhUtf4vng4zY6HUVrQbDMPDYRLYvFFoLnAYfzgYPH
+** Legacy signature
+** <tt>signer_3_key.bsms</tt>:
+<pre>BSMS 1.0
+163fd307195982c4c39d50bb
+[614cbf5f/48'/0'/0'/1']xpub6F9TfWTFcMYy5Ycd2ka2az1brJj78J2isLAWptZnCpFsesss5sZv5B8xsgt71ZXfhDWhUtf4vng4zY6HUVrQbDMPDYRLYvFFoLnAYfzgYPH
+Signer 3 key
+H0jf2JMtke5zDDIWys6fihOCA6QBmC5+hbgVB/c2mMPNPLB6tDXt0TFZU1f9wvaCR9762anKSc8CCqXLogw8V00=</pre>
+
+* Signer 3 encryption
+** HMAC_KEY (hex): 1f51ea067c121e2f86af5e1d484905046bc63e861573157d8b1ae9e7e47e224b
+** MAC (hex): 1a5624fcb39cebabb6174456173eec19b756bc916cf2c9d815e9bcce070898c4
+** IV (hex) : 1a5624fcb39cebabb6174456173eec19
+** CIPHERTEXT (hex): 48d6e139bdc8c19e93cbbf5b4478340c8cf08aa91c28803084d5f58618773f7e615e0134492b496c4e7c130351c0350701f686918033f621378552d7040efedd5539d38c258bf936475de775f23da3953fe3ba5bbbd24816b8902b87a9a09700c446b085119dedee2395dd69665e742f72f2fb6da4ebe3f4704eaf45486fbfb84d764b718cc0b756e72f72ab6069d47765bdd3ebd4074af4fa99a95691a659675ce5f72235c28ddf3c3d53179e598cddc967fc896adc6e97edeeffc85b9e44611df748d923ff3dd921ad4d6e98e0de12359a37558e326faf585ba57e73ab45bc4a49f6e8a756f365f5d204e70f7c7bed269e81e9524a41e5d4cbaad0b6b442d6eea1e5da1ca345cc665a0cffe2c3
+** <tt>signer_3_key.dat</tt>: <pre>1a5624fcb39cebabb6174456173eec19b756bc916cf2c9d815e9bcce070898c448d6e139bdc8c19e93cbbf5b4478340c8cf08aa91c28803084d5f58618773f7e615e0134492b496c4e7c130351c0350701f686918033f621378552d7040efedd5539d38c258bf936475de775f23da3953fe3ba5bbbd24816b8902b87a9a09700c446b085119dedee2395dd69665e742f72f2fb6da4ebe3f4704eaf45486fbfb84d764b718cc0b756e72f72ab6069d47765bdd3ebd4074af4fa99a95691a659675ce5f72235c28ddf3c3d53179e598cddc967fc896adc6e97edeeffc85b9e44611df748d923ff3dd921ad4d6e98e0de12359a37558e326faf585ba57e73ab45bc4a49f6e8a756f365f5d204e70f7c7bed269e81e9524a41e5d4cbaad0b6b442d6eea1e5da1ca345cc665a0cffe2c3</pre>
+
+====ROUND 2====
+* Coordinator
+** <tt>my_multisig_wallet.bsms</tt>:
+<pre>BSMS 1.0
+/0/*,/1/*
+sh(wsh(multi(2,[110dc257/48'/0'/0'/1']xpub6EPQbDFezXYvVFHqnc8R7QUSE8hTepbyCXU7jJBT4dVm2rQHe1i6isqoj59qhyBiCdKquo6QsgMZNHvEz3BM4cNSszF25siTqLUCznBm8vk/*,[5c890401/48'/0'/0'/1']xpub6EW1SmjSXq9YwVwcan5qWEncgx89SozMvGNpYF6hfZHYNTikNZ4gsXuVhHTi6xYJCkmY4X4wpPPS5Gr7aY39dVJMS2TGfihr25oaspKtU8q/*,[614cbf5f/48'/0'/0'/1']xpub6F9TfWTFcMYy5Ycd2ka2az1brJj78J2isLAWptZnCpFsesss5sZv5B8xsgt71ZXfhDWhUtf4vng4zY6HUVrQbDMPDYRLYvFFoLnAYfzgYPH/*)))#j3ykhz7f</pre>
+
+* Send to Signer 1:
+** HMAC_KEY (hex): f43c359a4b3d7b2e01be73c54519b12545ca9a23a86f824aadf577b314a7caa7
+** MAC (hex): ee74a0f50943d7d1b65270028bb05133e87c832cdc1ef0a07c79db2093ca3432
+** IV (hex) : ee74a0f50943d7d1b65270028bb05133
+** CIPHERTEXT (hex): 8e3ba3dac0f979fad0d160bd00c8294ff1726d51b95ff3e1534e5a1900f3d7cd4f6d929985a94b9da2c11e4e0f7770cc53c6739fd099477323bd26a3eca9c8016e79848d15e274463424b8355cd73cced61f1816ac8bac87f8c650ee9052f50e347c52ad24b00794a9d5523714be2fdcf731f14b7a8d7c93eab44c258e1c417d2837b9676832e8ce7239dc28b4e1166803209947b8a875a99b9478ee94f7bc17399e886179ab2a0285dc11a3883f6fa439d0f2277dadbec8c355c379fc50e945897e1a738f6a55b09f6b8b6bdf6d4bc248219cbad3662a78a2f539c989e055e00b8efd42fbff978e1a5cc10f83df56117ece4d17f94a0a6d3803778ed53531419250c5a0fff6cad4ab401468dd054915b068cc8826ae1308a71b38060d68c9248d59eea11c2c52a66d5f6bc0d7ae6cb44305c36e56068456d293b70037902e7b05a3ee0af710201128dffc0c16c3306b66bd19b9ae5b91aded35ef33f07743e5b185a9f88a5c67d40270e3bbcf592167ceaf82ead693728d5129b50075edd5ce24863f3484b4b063599ed1327e1c87d0a2051fed3b1234a702722b686e4c9392a403b79726800dd6b691e516e44d9e836c190b10cf2bb262bba98293c97f2c323e59acd0a1f988c5
+** <tt>my_multisig_wallet_for_signer_1.dat</tt>: <pre>ee74a0f50943d7d1b65270028bb05133e87c832cdc1ef0a07c79db2093ca34328e3ba3dac0f979fad0d160bd00c8294ff1726d51b95ff3e1534e5a1900f3d7cd4f6d929985a94b9da2c11e4e0f7770cc53c6739fd099477323bd26a3eca9c8016e79848d15e274463424b8355cd73cced61f1816ac8bac87f8c650ee9052f50e347c52ad24b00794a9d5523714be2fdcf731f14b7a8d7c93eab44c258e1c417d2837b9676832e8ce7239dc28b4e1166803209947b8a875a99b9478ee94f7bc17399e886179ab2a0285dc11a3883f6fa439d0f2277dadbec8c355c379fc50e945897e1a738f6a55b09f6b8b6bdf6d4bc248219cbad3662a78a2f539c989e055e00b8efd42fbff978e1a5cc10f83df56117ece4d17f94a0a6d3803778ed53531419250c5a0fff6cad4ab401468dd054915b068cc8826ae1308a71b38060d68c9248d59eea11c2c52a66d5f6bc0d7ae6cb44305c36e56068456d293b70037902e7b05a3ee0af710201128dffc0c16c3306b66bd19b9ae5b91aded35ef33f07743e5b185a9f88a5c67d40270e3bbcf592167ceaf82ead693728d5129b50075edd5ce24863f3484b4b063599ed1327e1c87d0a2051fed3b1234a702722b686e4c9392a403b79726800dd6b691e516e44d9e836c190b10cf2bb262bba98293c97f2c323e59acd0a1f988c5</pre>
+
+* Send to Signer 2:
+** HMAC_KEY (hex): e0a20b5f5285fbaa35aad08fb70f5626c9abbe1b384a4950735b28aca6325ff2
+** MAC (hex): 81df9e064f1de1d5f754c4e20f9286f9d81b856d3965677a9f2430cb9297ad1f
+** IV (hex) : 81df9e064f1de1d5f754c4e20f9286f9
+** CIPHERTEXT (hex): dcd82038ef627d6cb2deb62d04c4ccbaa3a354633d960e46312c22791f039f23fd9782a1e3a63504c1e5b3a0770bb8d32fdf168738b6c03278f1391dd5d01e9aafee7be2c8136ee018feff6fc8cdb926df13a36e115ddca8254934f56b7f700768c94cb8388a8297834de9affcd959417ae3d6ec3251387904f50f51f06306cc4d36eefc51418dd3b2c5454910a23ec67a40a3b918d2a740e812929aae949d8dde2c41cbbb3a2b7c2103788421c147f4794d6a26947c15ef4a99ceb825d0c5aaa78b8737d0ef712ba8e269a9941b1af5d217dcdd9cd06727fbdc70fabe3f5a8c09acff4e76992be7f27c6b12ca84739f62a6da86e5b79103d632c0dc8ab3f91fddb3cfbe67084dc4b861c4ac7c86fb171a058c98c67cffdc40ff17ae1533361cc6fb7b63657af0408cf30bf9d6d97aaacf9d3ff443eee61f207228cd91769ce83a0709c1be1847884c6a8fdc86ede66aef8e34fc509c49edf30f743bdc8f9052961ee340924ec2d1caadc6fd286bb3e233c153cd08c1934127752dc28e0d12efa92a050c4061653edb1cbf2fd4b2ba4e038f0b44f5735f198e92571c029156f65f534bfc149f38d611829901372cfc0176b9d2f9ac6512b7f37941a02dff701df0bceadaacfc6935
+** <tt>my_multisig_wallet_for_signer_2.dat</tt>: <pre>81df9e064f1de1d5f754c4e20f9286f9d81b856d3965677a9f2430cb9297ad1fdcd82038ef627d6cb2deb62d04c4ccbaa3a354633d960e46312c22791f039f23fd9782a1e3a63504c1e5b3a0770bb8d32fdf168738b6c03278f1391dd5d01e9aafee7be2c8136ee018feff6fc8cdb926df13a36e115ddca8254934f56b7f700768c94cb8388a8297834de9affcd959417ae3d6ec3251387904f50f51f06306cc4d36eefc51418dd3b2c5454910a23ec67a40a3b918d2a740e812929aae949d8dde2c41cbbb3a2b7c2103788421c147f4794d6a26947c15ef4a99ceb825d0c5aaa78b8737d0ef712ba8e269a9941b1af5d217dcdd9cd06727fbdc70fabe3f5a8c09acff4e76992be7f27c6b12ca84739f62a6da86e5b79103d632c0dc8ab3f91fddb3cfbe67084dc4b861c4ac7c86fb171a058c98c67cffdc40ff17ae1533361cc6fb7b63657af0408cf30bf9d6d97aaacf9d3ff443eee61f207228cd91769ce83a0709c1be1847884c6a8fdc86ede66aef8e34fc509c49edf30f743bdc8f9052961ee340924ec2d1caadc6fd286bb3e233c153cd08c1934127752dc28e0d12efa92a050c4061653edb1cbf2fd4b2ba4e038f0b44f5735f198e92571c029156f65f534bfc149f38d611829901372cfc0176b9d2f9ac6512b7f37941a02dff701df0bceadaacfc6935</pre>
+
+* Send to Signer 3:
+** HMAC_KEY (hex): 1f51ea067c121e2f86af5e1d484905046bc63e861573157d8b1ae9e7e47e224b
+** MAC (hex): 159a91100cacd123480b7d085c8bb32ec8eb06f0391b6dc8fac07ae67eb37b81
+** IV (hex) : 159a91100cacd123480b7d085c8bb32e
+** CIPHERTEXT (hex): c7269d8be21d1cfe172e35aa106760f1fdc929fce19da8fb7f74f759efec1ee02796fb1e8b008cf177f60a2021570f17aeeb41f8636858654082734b90959b98fd08419f901683c4ca3e76b3e482fea4c67162775e0d80bcb45df729f646c1364a3d8a7d1ff961717b00897e877c1c0554d3502942149726806269c546ad2dd34ba286ddf5cd336b83aabf7091fa25e607faf7e54017d84113e1e3ec440b3704addea188b89293469306fc0a98570afdcf269026b2d2e760f466c1f75bcf75fdf030c0a692e5681fd4487e59d6e96451ff5b6b9f2521b8e95e796ef4ab0a917794d91a30fdac7ee9ddbd89d174831bd133ab12a74f52f6283ee2c5fe3d5a957a7c1a15530b2c5224f76d90057dc94f2ee34e28b037ae7f518cc6dfe725cd3e657648de82b200ea77830eb93219f883998d3207a4ef5902d1119b0cde6b364bc1effb86109d9c2babc8ab26dce90329779d8cd0d737e9825a25586aa3c8fa5317e3e433ff235b82f629de0504e3c992f8e8de299f62751bc1fcb2e75e0262c7a27be7068cea69b14f303e97c24b99ed29cae142564e285657704b4c411d0d4f8c58819e2c0e0ffc3667eb5a408aad8a3023a5f00875e7deab95dc365d8757f7b79815a4fd9e6de2b3
+** <tt>my_multisig_wallet_for_signer_3.dat</tt>: <pre>159a91100cacd123480b7d085c8bb32ec8eb06f0391b6dc8fac07ae67eb37b81c7269d8be21d1cfe172e35aa106760f1fdc929fce19da8fb7f74f759efec1ee02796fb1e8b008cf177f60a2021570f17aeeb41f8636858654082734b90959b98fd08419f901683c4ca3e76b3e482fea4c67162775e0d80bcb45df729f646c1364a3d8a7d1ff961717b00897e877c1c0554d3502942149726806269c546ad2dd34ba286ddf5cd336b83aabf7091fa25e607faf7e54017d84113e1e3ec440b3704addea188b89293469306fc0a98570afdcf269026b2d2e760f466c1f75bcf75fdf030c0a692e5681fd4487e59d6e96451ff5b6b9f2521b8e95e796ef4ab0a917794d91a30fdac7ee9ddbd89d174831bd133ab12a74f52f6283ee2c5fe3d5a957a7c1a15530b2c5224f76d90057dc94f2ee34e28b037ae7f518cc6dfe725cd3e657648de82b200ea77830eb93219f883998d3207a4ef5902d1119b0cde6b364bc1effb86109d9c2babc8ab26dce90329779d8cd0d737e9825a25586aa3c8fa5317e3e433ff235b82f629de0504e3c992f8e8de299f62751bc1fcb2e75e0262c7a27be7068cea69b14f303e97c24b99ed29cae142564e285657704b4c411d0d4f8c58819e2c0e0ffc3667eb5a408aad8a3023a5f00875e7deab95dc365d8757f7b79815a4fd9e6de2b3</pre>
+
+==Acknowledgement==
+
+Special thanks to Pavol Rusnak, Dmitry Petukhov, Christopher Allen, Craig Raw, Robert Spigler, Gregory Sanders, Ta Tat Tai, Michael Flaxman, Pieter Wuille and others for their feedback on the specification.
+
+==References==
+
+Original mailing list thread: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018385.html
+
-- 
cgit v1.2.3


From 0f95720639c743df2546730a5549eb7ead610529 Mon Sep 17 00:00:00 2001
From: Anthony Towns <aj@erisian.com.au>
Date: Wed, 24 Mar 2021 20:35:24 +1000
Subject: BIP341: bip9 speedy trial parameters

---
 bip-0341.mediawiki | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/bip-0341.mediawiki b/bip-0341.mediawiki
index 1e579e1..c464b59 100644
--- a/bip-0341.mediawiki
+++ b/bip-0341.mediawiki
@@ -298,6 +298,16 @@ This BIP is deployed concurrently with [[bip-0342.mediawiki|BIP342]].
 
 For Bitcoin signet, these BIPs are always active.
 
+For Bitcoin mainnet, these BIPs will be deployed by "version bits" with the name "taproot" and bit 2, using BIP9 modified to use a lower threshold, and with an additional ''min_activation_height'' parameter and changing the state transition logic for LOCKED_IN to the following:
+
+    case LOCKED_IN:
+        if (block.nHeight < min_activation_height) {
+            return LOCKED_IN;
+        }
+        return ACTIVE;
+
+For Bitcoin mainnet, the BIP9 starttime is epoch timestamp 1619222400 (midnight 24 April 2021 UTC), BIP9 timeout is epoch timestamp 1628640000 (midnight 11 August 2021 UTC), the threshold is 1815 blocks (90%) instead of 1916 blocks (95%), and the min_activation_height is block 709632 (expected approximately 12 November 2021).
+
 == Backwards compatibility ==
 As a soft fork, older software will continue to operate without modification.
 Non-upgraded nodes, however, will consider all SegWit version 1 witness programs as anyone-can-spend scripts.
-- 
cgit v1.2.3


From d582d0bd3162ac7a3f6f1aae46daf7eeb24b201e Mon Sep 17 00:00:00 2001
From: Anthony Towns <aj@erisian.com.au>
Date: Thu, 8 Apr 2021 18:30:51 +1000
Subject: BIP341: document simplified bip9 states

---
 bip-0341.mediawiki | 26 ++++++++++++++++++++++++--
 1 file changed, 24 insertions(+), 2 deletions(-)

diff --git a/bip-0341.mediawiki b/bip-0341.mediawiki
index c464b59..ec26250 100644
--- a/bip-0341.mediawiki
+++ b/bip-0341.mediawiki
@@ -298,7 +298,29 @@ This BIP is deployed concurrently with [[bip-0342.mediawiki|BIP342]].
 
 For Bitcoin signet, these BIPs are always active.
 
-For Bitcoin mainnet, these BIPs will be deployed by "version bits" with the name "taproot" and bit 2, using BIP9 modified to use a lower threshold, and with an additional ''min_activation_height'' parameter and changing the state transition logic for LOCKED_IN to the following:
+For Bitcoin mainnet, these BIPs will be deployed by "version bits" with the name "taproot" and bit 2, using [[bip-0009.mediawiki|BIP9]] modified to use a lower threshold, with an additional ''min_activation_height'' parameter and replacing the state transition logic for the DEFINED, STARTED and LOCKED_IN states as follows:
+
+    case DEFINED:
+        if (GetMedianTimePast(block.parent) >= starttime) {
+            return STARTED;
+        }
+        return DEFINED;
+
+    case STARTED:
+        int count = 0;
+        walk = block;
+        for (i = 0; i < 2016; i++) {
+            walk = walk.parent;
+            if (walk.nVersion & 0xE0000000 == 0x20000000 && (walk.nVersion >> bit) & 1 == 1) {
+                count++;
+            }
+        }
+        if (count >= threshold) {
+            return LOCKED_IN;
+        } else if (GetMedianTimePast(block.parent) >= timeout) {
+            return FAILED;
+        }
+        return STARTED;
 
     case LOCKED_IN:
         if (block.nHeight < min_activation_height) {
@@ -306,7 +328,7 @@ For Bitcoin mainnet, these BIPs will be deployed by "version bits" with the name
         }
         return ACTIVE;
 
-For Bitcoin mainnet, the BIP9 starttime is epoch timestamp 1619222400 (midnight 24 April 2021 UTC), BIP9 timeout is epoch timestamp 1628640000 (midnight 11 August 2021 UTC), the threshold is 1815 blocks (90%) instead of 1916 blocks (95%), and the min_activation_height is block 709632 (expected approximately 12 November 2021).
+For Bitcoin mainnet, the starttime is epoch timestamp 1619222400 (midnight 24 April 2021 UTC), timeout is epoch timestamp 1628640000 (midnight 11 August 2021 UTC), the threshold is 1815 blocks (90%) instead of 1916 blocks (95%), and the min_activation_height is block 709632 (expected approximately 12 November 2021).
 
 == Backwards compatibility ==
 As a soft fork, older software will continue to operate without modification.
-- 
cgit v1.2.3


From 754b77a915007e96fca3b9440e7ddd4498ccae83 Mon Sep 17 00:00:00 2001
From: Andrew Chow <achow101-github@achow101.com>
Date: Thu, 8 Apr 2021 13:34:18 -0400
Subject: BIP 174: Add test vectors for additional unsigned tx serialization

There are some edge cases with unsigned tx serialization, so this adds
test vectors for them. Specifically, an unsigned tx with witness
serialization is invalid, a transaction with 0 inputs and 0 outputs is
valid, and a transaction with 0 inputs and non-0 outputs is valid.
---
 bip-0174.mediawiki | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/bip-0174.mediawiki b/bip-0174.mediawiki
index 75fea0e..8551d3c 100644
--- a/bip-0174.mediawiki
+++ b/bip-0174.mediawiki
@@ -830,6 +830,10 @@ The following are invalid PSBTs:
 ** Bytes in Hex: <pre>70736274ff0100730200000001301ae986e516a1ec8ac5b4bc6573d32f83b465e23ad76167d68b38e730b4dbdb0000000000ffffffff02747b01000000000017a91403aa17ae882b5d0d54b25d63104e4ffece7b9ea2876043993b0000000017a914b921b1ba6f722e4bfa83b6557a3139986a42ec8387000000000001011f00ca9a3b00000000160014d2d94b64ae08587eefc8eeb187c601e939f9037c00010016001462e9e982fff34dd8239610316b090cd2a3b747cb000100220020876bad832f1d168015ed41232a9ea65a1815d9ef13c0ef8759f64b5b2b278a6521010025512103b7ce23a01c5b4bf00a642537cdfabb315b668332867478ef51309d06d57f8a8751ae00</pre>
 ** Base64 String: <pre>cHNidP8BAHMCAAAAATAa6YblFqHsisW0vGVz0y+DtGXiOtdhZ9aLOOcwtNvbAAAAAAD/////AnR7AQAAAAAAF6kUA6oXrogrXQ1Usl1jEE5P/s57nqKHYEOZOwAAAAAXqRS5IbG6b3IuS/qDtlV6MTmYakLsg4cAAAAAAAEBHwDKmjsAAAAAFgAU0tlLZK4IWH7vyO6xh8YB6Tn5A3wAAQAWABRi6emC//NN2COWEDFrCQzSo7dHywABACIAIIdrrYMvHRaAFe1BIyqeploYFdnvE8Dvh1n2S1srJ4plIQEAJVEhA7fOI6AcW0vwCmQlN836uzFbZoMyhnR471EwnQbVf4qHUa4A</pre>
 
+* Case: PSBT with unsigned tx serialized with witness serialization format
+** Bytes in Hex: <pre>70736274ff01007802000000000101268171371edff285e937adeea4b37b78000c0566cbb3ad64641713ca42171bf60000000000feffffff02d3dff505000000001976a914d0c59903c5bac2868760e90fd521a4665aa7652088ac00e1f5050000000017a9143545e6e33b832c47050f24d3eeb93c9c03948bc78700b32e1300000100fda5010100000000010289a3c71eab4d20e0371bbba4cc698fa295c9463afa2e397f8533ccb62f9567e50100000017160014be18d152a9b012039daf3da7de4f53349eecb985ffffffff86f8aa43a71dff1448893a530a7237ef6b4608bbb2dd2d0171e63aec6a4890b40100000017160014fe3e9ef1a745e974d902c4355943abcb34bd5353ffffffff0200c2eb0b000000001976a91485cff1097fd9e008bb34af709c62197b38978a4888ac72fef84e2c00000017a914339725ba21efd62ac753a9bcd067d6c7a6a39d05870247304402202712be22e0270f394f568311dc7ca9a68970b8025fdd3b240229f07f8a5f3a240220018b38d7dcd314e734c9276bd6fb40f673325bc4baa144c800d2f2f02db2765c012103d2e15674941bad4a996372cb87e1856d3652606d98562fe39c5e9e7e413f210502483045022100d12b852d85dcd961d2f5f4ab660654df6eedcc794c0c33ce5cc309ffb5fce58d022067338a8e0e1725c197fb1a88af59f51e44e4255b20167c8684031c05d1f2592a01210223b72beef0965d10be0778efecd61fcac6f79a4ea169393380734464f84f2ab300000000000000</pre>
+** Base64 String: <pre>cHNidP8BAHgCAAAAAAEBJoFxNx7f8oXpN63upLN7eAAMBWbLs61kZBcTykIXG/YAAAAAAP7///8C09/1BQAAAAAZdqkU0MWZA8W6woaHYOkP1SGkZlqnZSCIrADh9QUAAAAAF6kUNUXm4zuDLEcFDyTT7rk8nAOUi8eHALMuEwAAAQD9pQEBAAAAAAECiaPHHqtNIOA3G7ukzGmPopXJRjr6Ljl/hTPMti+VZ+UBAAAAFxYAFL4Y0VKpsBIDna89p95PUzSe7LmF/////4b4qkOnHf8USIk6UwpyN+9rRgi7st0tAXHmOuxqSJC0AQAAABcWABT+Pp7xp0XpdNkCxDVZQ6vLNL1TU/////8CAMLrCwAAAAAZdqkUhc/xCX/Z4Ai7NK9wnGIZeziXikiIrHL++E4sAAAAF6kUM5cluiHv1irHU6m80GfWx6ajnQWHAkcwRAIgJxK+IuAnDzlPVoMR3HyppolwuAJf3TskAinwf4pfOiQCIAGLONfc0xTnNMkna9b7QPZzMlvEuqFEyADS8vAtsnZcASED0uFWdJQbrUqZY3LLh+GFbTZSYG2YVi/jnF6efkE/IQUCSDBFAiEA0SuFLYXc2WHS9fSrZgZU327tzHlMDDPOXMMJ/7X85Y0CIGczio4OFyXBl/saiK9Z9R5E5CVbIBZ8hoQDHAXR8lkqASECI7cr7vCWXRC+B3jv7NYfysb3mk6haTkzgHNEZPhPKrMAAAAAAAAA</pre>
+
 The following are valid PSBTs:
 
 * Case: PSBT with one P2PKH input. Outputs are empty
@@ -864,6 +868,14 @@ The following are valid PSBTs:
 ** Bytes in Hex: <pre>70736274ff01009d0100000002710ea76ab45c5cb6438e607e59cc037626981805ae9e0dfd9089012abb0be5350100000000ffffffff190994d6a8b3c8c82ccbcfb2fba4106aa06639b872a8d447465c0d42588d6d670000000000ffffffff0200e1f505000000001976a914b6bc2c0ee5655a843d79afedd0ccc3f7dd64340988ac605af405000000001600141188ef8e4ce0449eaac8fb141cbf5a1176e6a088000000004f010488b21e039e530cac800000003dbc8a5c9769f031b17e77fea1518603221a18fd18f2b9a54c6c8c1ac75cbc3502f230584b155d1c7f1cd45120a653c48d650b431b67c5b2c13f27d7142037c1691027569c503100008000000080000000800001011f00e1f5050000000016001433b982f91b28f160c920b4ab95e58ce50dda3a4a220203309680f33c7de38ea6a47cd4ecd66f1f5a49747c6ffb8808ed09039243e3ad5c47304402202d704ced830c56a909344bd742b6852dccd103e963bae92d38e75254d2bb424502202d86c437195df46c0ceda084f2a291c3da2d64070f76bf9b90b195e7ef28f77201220603309680f33c7de38ea6a47cd4ecd66f1f5a49747c6ffb8808ed09039243e3ad5c1827569c5031000080000000800000008000000000010000000001011f00e1f50500000000160014388fb944307eb77ef45197d0b0b245e079f011de220202c777161f73d0b7c72b9ee7bde650293d13f095bc7656ad1f525da5fd2e10b11047304402204cb1fb5f869c942e0e26100576125439179ae88dca8a9dc3ba08f7953988faa60220521f49ca791c27d70e273c9b14616985909361e25be274ea200d7e08827e514d01220602c777161f73d0b7c72b9ee7bde650293d13f095bc7656ad1f525da5fd2e10b1101827569c5031000080000000800000008000000000000000000000220202d20ca502ee289686d21815bd43a80637b0698e1fbcdbe4caed445f6c1a0a90ef1827569c50310000800000008000000080000000000400000000</pre>
 ** Base64 String: <pre>cHNidP8BAJ0BAAAAAnEOp2q0XFy2Q45gflnMA3YmmBgFrp4N/ZCJASq7C+U1AQAAAAD/////GQmU1qizyMgsy8+y+6QQaqBmObhyqNRHRlwNQliNbWcAAAAAAP////8CAOH1BQAAAAAZdqkUtrwsDuVlWoQ9ea/t0MzD991kNAmIrGBa9AUAAAAAFgAUEYjvjkzgRJ6qyPsUHL9aEXbmoIgAAAAATwEEiLIeA55TDKyAAAAAPbyKXJdp8DGxfnf+oVGGAyIaGP0Y8rmlTGyMGsdcvDUC8jBYSxVdHH8c1FEgplPEjWULQxtnxbLBPyfXFCA3wWkQJ1acUDEAAIAAAACAAAAAgAABAR8A4fUFAAAAABYAFDO5gvkbKPFgySC0q5XljOUN2jpKIgIDMJaA8zx9446mpHzU7NZvH1pJdHxv+4gI7QkDkkPjrVxHMEQCIC1wTO2DDFapCTRL10K2hS3M0QPpY7rpLTjnUlTSu0JFAiAthsQ3GV30bAztoITyopHD2i1kBw92v5uQsZXn7yj3cgEiBgMwloDzPH3jjqakfNTs1m8fWkl0fG/7iAjtCQOSQ+OtXBgnVpxQMQAAgAAAAIAAAACAAAAAAAEAAAAAAQEfAOH1BQAAAAAWABQ4j7lEMH63fvRRl9CwskXgefAR3iICAsd3Fh9z0LfHK57nveZQKT0T8JW8dlatH1Jdpf0uELEQRzBEAiBMsftfhpyULg4mEAV2ElQ5F5rojcqKncO6CPeVOYj6pgIgUh9JynkcJ9cOJzybFGFphZCTYeJb4nTqIA1+CIJ+UU0BIgYCx3cWH3PQt8crnue95lApPRPwlbx2Vq0fUl2l/S4QsRAYJ1acUDEAAIAAAACAAAAAgAAAAAAAAAAAAAAiAgLSDKUC7iiWhtIYFb1DqAY3sGmOH7zb5MrtRF9sGgqQ7xgnVpxQMQAAgAAAAIAAAACAAAAAAAQAAAAA</pre>
 
+* Case: PSBT with global unsigned tx that has 0 inputs and 0 outputs
+** Bytes in Hex: <pre>70736274ff01000a0000000000000000000000</pre>
+** Base64 String: <pre>cHNidP8BAAoAAAAAAAAAAAAAAA==</pre>
+
+* Case: PSBT with 0 inputs
+** Bytes in Hex: <pre>70736274ff01004c020000000002d3dff505000000001976a914d0c59903c5bac2868760e90fd521a4665aa7652088ac00e1f5050000000017a9143545e6e33b832c47050f24d3eeb93c9c03948bc787b32e1300000000</pre>
+** Base64 String: <pre>cHNidP8BAEwCAAAAAALT3/UFAAAAABl2qRTQxZkDxbrChodg6Q/VIaRmWqdlIIisAOH1BQAAAAAXqRQ1RebjO4MsRwUPJNPuuTycA5SLx4ezLhMAAAAA</pre>
+
 Fails Signer checks
 
 * Case: A Witness UTXO is provided for a non-witness input
-- 
cgit v1.2.3


From ce5f89fe0ddd99a00bcd1457df407cccd60a9336 Mon Sep 17 00:00:00 2001
From: Anthony Towns <aj@erisian.com.au>
Date: Thu, 8 Apr 2021 18:31:04 +1000
Subject: BIP341: add testnet3 parameters

---
 bip-0341.mediawiki | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/bip-0341.mediawiki b/bip-0341.mediawiki
index ec26250..f682d96 100644
--- a/bip-0341.mediawiki
+++ b/bip-0341.mediawiki
@@ -298,7 +298,7 @@ This BIP is deployed concurrently with [[bip-0342.mediawiki|BIP342]].
 
 For Bitcoin signet, these BIPs are always active.
 
-For Bitcoin mainnet, these BIPs will be deployed by "version bits" with the name "taproot" and bit 2, using [[bip-0009.mediawiki|BIP9]] modified to use a lower threshold, with an additional ''min_activation_height'' parameter and replacing the state transition logic for the DEFINED, STARTED and LOCKED_IN states as follows:
+For Bitcoin mainnet and testnet3, these BIPs will be deployed by "version bits" with the name "taproot" and bit 2, using [[bip-0009.mediawiki|BIP9]] modified to use a lower threshold, with an additional ''min_activation_height'' parameter and replacing the state transition logic for the DEFINED, STARTED and LOCKED_IN states as follows:
 
     case DEFINED:
         if (GetMedianTimePast(block.parent) >= starttime) {
@@ -330,6 +330,8 @@ For Bitcoin mainnet, these BIPs will be deployed by "version bits" with the name
 
 For Bitcoin mainnet, the starttime is epoch timestamp 1619222400 (midnight 24 April 2021 UTC), timeout is epoch timestamp 1628640000 (midnight 11 August 2021 UTC), the threshold is 1815 blocks (90%) instead of 1916 blocks (95%), and the min_activation_height is block 709632 (expected approximately 12 November 2021).
 
+For Bitcoin testnet3, the starttime is epoch timestamp 1619222400 (midnight 24 April 2021 UTC), timeout is epoch timestamp 1628640000 (midnight 11 August 2021 UTC), the threshold is 1512 blocks (75%), and the min_activation_height is block 0.
+
 == Backwards compatibility ==
 As a soft fork, older software will continue to operate without modification.
 Non-upgraded nodes, however, will consider all SegWit version 1 witness programs as anyone-can-spend scripts.
-- 
cgit v1.2.3


From cda85c75c176ebeba4152a238998b4c54aa74e89 Mon Sep 17 00:00:00 2001
From: fresheneesz <bitetrudpublic@gmail.com>
Date: Mon, 12 Apr 2021 08:26:18 -1000
Subject: Minor: linking BIPs in BIP9

---
 bip-0009.mediawiki | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/bip-0009.mediawiki b/bip-0009.mediawiki
index f90919a..b2d6741 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.
+[https://github.com/bitcoin/bips/blob/master/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 2<sup>31</sup>+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 2<sup>31</sup>+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 [https://github.com/bitcoin/bips/blob/master/bip-0066.mediawiki BIP 66] and [https://github.com/bitcoin/bips/blob/master/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,7 +195,7 @@ 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 [https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki 16], [https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki 65], [https://github.com/bitcoin/bips/blob/master/bip-0066.mediawiki 66], [https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki 68], [https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki 112], and [https://github.com/bitcoin/bips/blob/master/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).
 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.
-- 
cgit v1.2.3


From 43b5f171dcf2b3cd8a2f1b0a71f0dfe31946f46a Mon Sep 17 00:00:00 2001
From: Jonas Nick <jonasd.nick@gmail.com>
Date: Tue, 13 Apr 2021 14:52:44 +0000
Subject: BIP 341/342: Add link to Bitcoin Core test vectors

Also remove mention of non-existing examples.
---
 bip-0341.mediawiki | 4 +---
 bip-0342.mediawiki | 2 ++
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/bip-0341.mediawiki b/bip-0341.mediawiki
index 0f8d32a..a1c45cc 100644
--- a/bip-0341.mediawiki
+++ b/bip-0341.mediawiki
@@ -284,9 +284,7 @@ The reason for this is to increase leaf entropy and prevent an observer from lea
 
 == Test vectors ==
 
-Examples with creation transaction and spending transaction pairs, valid and invalid.
-
-Examples of preimage for sighashing for each of the sighash modes.
+The test vectors used in the [https://github.com/bitcoin/bitcoin/blob/3820090bd619ac85ab35eff376c03136fe4a9f04/src/test/script_tests.cpp#L1718 Bitcoin Core unit test framework] can be found [https://github.com/bitcoin-core/qa-assets/blob/main/unit_test_data/script_assets_test.json?raw=true here].
 
 == Rationale ==
 
diff --git a/bip-0342.mediawiki b/bip-0342.mediawiki
index 7e00a2e..fa27598 100644
--- a/bip-0342.mediawiki
+++ b/bip-0342.mediawiki
@@ -135,6 +135,8 @@ In addition to changing the semantics of a number of opcodes, there are also som
 
 ==Examples==
 
+The Taproot ([[bip-0341.mediawiki|BIP341]]) test vectors also contain examples for Tapscript execution.
+
 ==Acknowledgements==
 
 This document is the result of many discussions and contains contributions by a number of people. The authors wish to thank all those who provided valuable feedback and reviews, including the participants of the [https://github.com/ajtowns/taproot-review structured reviews].
-- 
cgit v1.2.3


From 93d1b1528592ca129109b4630c17fa5372e4048a Mon Sep 17 00:00:00 2001
From: Anthony Towns <aj@erisian.com.au>
Date: Tue, 13 Apr 2021 10:45:02 +1000
Subject: BIP341: add brackets to avoid ambiguity due to precendence rules
 around bipwise ops

---
 bip-0341.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-0341.mediawiki b/bip-0341.mediawiki
index f682d96..5450a08 100644
--- a/bip-0341.mediawiki
+++ b/bip-0341.mediawiki
@@ -311,7 +311,7 @@ For Bitcoin mainnet and testnet3, these BIPs will be deployed by "version bits"
         walk = block;
         for (i = 0; i < 2016; i++) {
             walk = walk.parent;
-            if (walk.nVersion & 0xE0000000 == 0x20000000 && (walk.nVersion >> bit) & 1 == 1) {
+            if ((walk.nVersion & 0xE0000000) == 0x20000000 && ((walk.nVersion >> bit) & 1) == 1) {
                 count++;
             }
         }
-- 
cgit v1.2.3


From 593324754f0494070bb4a6a472e02080af5c3c0e Mon Sep 17 00:00:00 2001
From: fresheneesz <bitetrudpublic@gmail.com>
Date: Wed, 14 Apr 2021 08:53:21 -1000
Subject: Changing BIP links in BIP9 to relative urls.

---
 bip-0009.mediawiki | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/bip-0009.mediawiki b/bip-0009.mediawiki
index b2d6741..c9fcd6f 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==
 
-[https://github.com/bitcoin/bips/blob/master/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.
+[[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 2<sup>31</sup>+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 [https://github.com/bitcoin/bips/blob/master/bip-0066.mediawiki BIP 66] and [https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki 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 2<sup>31</sup>+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,7 +195,7 @@ 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 [https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki 16], [https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki 65], [https://github.com/bitcoin/bips/blob/master/bip-0066.mediawiki 66], [https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki 68], [https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki 112], and [https://github.com/bitcoin/bips/blob/master/bip-0113.mediawiki 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).
 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.
-- 
cgit v1.2.3


From f31fa9c1e41bfcb3e4a6faaec149d7ffff5b7e25 Mon Sep 17 00:00:00 2001
From: Hugo Nguyen <hugh.hn@gmail.com>
Date: Thu, 15 Apr 2021 21:13:53 -0700
Subject: clarify Signer definition and add reference links

---
 bip-hugonguyen-bsms.mediawiki | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/bip-hugonguyen-bsms.mediawiki b/bip-hugonguyen-bsms.mediawiki
index 95493aa..cb15d5b 100644
--- a/bip-hugonguyen-bsms.mediawiki
+++ b/bip-hugonguyen-bsms.mediawiki
@@ -55,7 +55,7 @@ The Coordinator initiates the multisig setup. The Coordinator determines what ty
 
 ====Signer====
 
-The Signer is a participating member in the multisig. Its responsibilities include providing its key record -- which contains an Extended Public Key (XPUB) -- to the Coordinator, verifying that its XPUB is included in the descriptor record and persisting the descriptor record in its storage.
+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 an Extended Public Key (XPUB) -- to the Coordinator, verifying that its XPUB is included in the descriptor record and persisting the descriptor record in its storage.
 
 ===Setup Process===
 
@@ -390,5 +390,7 @@ Special thanks to Pavol Rusnak, Dmitry Petukhov, Christopher Allen, Craig Raw, R
 
 ==References==
 
-Original mailing list thread: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018385.html
+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
 
-- 
cgit v1.2.3


From f2e81c8c5028f373538ff9121af3437afb530da1 Mon Sep 17 00:00:00 2001
From: Hugo Nguyen <hugh.hn@gmail.com>
Date: Fri, 16 Apr 2021 02:38:58 -0700
Subject: include and verify the wallet's first address in round 2

---
 bip-hugonguyen-bsms.mediawiki | 21 ++++++++++-----------
 1 file changed, 10 insertions(+), 11 deletions(-)

diff --git a/bip-hugonguyen-bsms.mediawiki b/bip-hugonguyen-bsms.mediawiki
index cb15d5b..0ce18c5 100644
--- a/bip-hugonguyen-bsms.mediawiki
+++ b/bip-hugonguyen-bsms.mediawiki
@@ -66,7 +66,7 @@ The Signer is any software or hardware that controls the private keys and can si
 * 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 (<tt>M</tt> and <tt>N</tt>).
 * 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 <tt>TOKEN</tt> to each Signer over a secure channel. The Signer can use the <tt>TOKEN</tt> to derive an <tt>ENCRYPTION_KEY</tt>. Refer to the Encryption section below for details on the <tt>TOKEN</tt>, the key derivation function and the encryption scheme. Depending on the use case, the Coordinator can decide whether to share one common <tt>TOKEN</tt> for all Signers, or to have one per Signer.
-* If encryption is disabled, the <tt>TOKEN</tt> is set to <tt>0</tt>, and all the encryption/decryption steps below can be skipped.
+* If encryption is disabled, the <tt>TOKEN</tt> is set to <tt>0x00</tt>, and all the encryption/decryption steps below can be skipped.
 
 =====Signer=====
 
@@ -87,7 +87,7 @@ The Signer is any software or hardware that controls the private keys and can si
 * The Coordinator verifies that the key records have compatible specification versions.
 * The Coordinator verifies that the included <tt>SIG</tt> is valid given the <tt>KEY</tt>.
 * 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 (<tt>BSMS 1.0</tt> as of this writing). The second line must be a comma-separated list of accepted derivation paths that the Signers can use to generate addresses from the included XPUBs. The paths must start with <tt>/</tt> and use non-hardened derivation. For example, <tt>/0/*</tt> and <tt>/1/*</tt> are some common paths. If there are no restrictions, it must say <tt>No path restrictions</tt>. The third line must be the descriptor string plus a <tt>CHECKSUM</tt>, all in one line. The <tt>CHECKSUM</tt> has [https://github.com/bitcoin/bitcoin/blob/master/doc/descriptors.md#checksums BECH32 encoding].
+* The first line in the descriptor record must be the specification version (<tt>BSMS 1.0</tt> as of this writing). The second line must be a comma-separated list of accepted derivation paths that the Signers can use to generate addresses from the included XPUBs. The paths must start with <tt>/</tt> and use non-hardened derivation. For example, <tt>/0/*</tt> and <tt>/1/*</tt> are some common paths. If there are no restrictions, it must say <tt>No path restrictions</tt>. The third line must be the descriptor string plus a <tt>CHECKSUM</tt>, all in one line. The <tt>CHECKSUM</tt> has [https://github.com/bitcoin/bitcoin/blob/master/doc/descriptors.md#checksums BECH32 encoding]. 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 <tt>MAC</tt> for the record. The first 16 bytes of the <tt>MAC</tt> serves as the <tt>IV</tt> for the encryption.. 
 * The Coordinator encrypts the descriptor record with the <tt>ENCRYPTION_KEY</tt> and <tt>IV</tt>.
 * The Coordinator encodes the <tt>MAC</tt> and the ciphertext into hexadecimal format, then concatenates the results: <tt>(MAC || ciphertext)</tt>.
@@ -103,9 +103,9 @@ The Signer is any software or hardware that controls the private keys and can si
 * The Signer verifies the descriptor’s <tt>CHECKSUM</tt>.
 * The Signer verifies that it can support the descriptor.
 * The Signer checks that its <tt>KEY</tt> is included in the descriptor, using path and fingerprint information provided. The check must perform an exact match on the <tt>KEY</tt>s and not using shortcuts such as matching fingerprints, which is trivial to spoof.
-* For confirmation, the Signer must display to the user the <tt>CHECKSUM</tt>, the derivation path restrictions and the policy parameters, such as <tt>M</tt>, <tt>N</tt> and the position(s) of its own XPUB in the policy script. The total number of Signers, <tt>N</tt>, is important to prevent a <tt>KEY</tt> insertion attack. The position is important for scripts where key order matters. When applicable, all positions of the XPUB must be displayed. The full descriptor must also be available for review upon user request. 
-* When possible, the Signer should also show a preview of the first address(es) of the wallet.
-* Parties must check with each other that all Signers have verified the descriptor and has the same confirmation (except for the key positions).
+* The Signer verifies that the wallet's first address is valid given the descriptor and the path restrictions.
+* 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, <tt>M</tt>, <tt>N</tt>, and the position(s) of the Signer's own XPUB in the policy script. The total number of Signers, <tt>N</tt>, is important to prevent a <tt>KEY</tt> insertion attack. The position is important for scripts where key order matters. When applicable, all positions of the XPUB must be displayed. The full descriptor 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.
@@ -115,7 +115,7 @@ This completes the setup.
 ====The Token====
 We define three modes of encryption.
 
-# <tt>NO_ENCRYPTION</tt> : the <tt>TOKEN</tt> is set to <tt>0</tt>. Encryption is disabled.
+# <tt>NO_ENCRYPTION</tt> : the <tt>TOKEN</tt> is set to <tt>0x00</tt>. Encryption is disabled.
 # <tt>STANDARD</tt> : the <tt>TOKEN</tt> is a 64-bit nonce.
 # <tt>EXTENDED</tt> : the <tt>TOKEN</tt> is a 96-bit nonce.
 
@@ -166,13 +166,11 @@ Also refer to [https://github.com/BlockchainCommons/Research/blob/master/papers/
 
 ==Security==
 
-This proposal introduces two layers of protection. The first one is a temporary, secret <tt>TOKEN</tt>. The second one is the descriptor <tt>CHECKSUM</tt>.
+This proposal introduces two layers of protection. The first one is a temporary, secret <tt>TOKEN</tt>. The second one is the confirmation of the wallet's first address.
 
 The <tt>TOKEN</tt> is used to encrypt the two rounds of communication between the Signer and the Coordinator. A <tt>MAC</tt> is also generated from the <tt>TOKEN</tt> and plaintext to authenticate the data being exchanged. The <tt>TOKEN</tt> is only needed during the setup phase, and can be safely discarded afterwards.
 
-The descriptor <tt>CHECKSUM</tt>, 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 descriptor <tt>CHECKSUM</tt>. Parties must check with each other that all Signers have the same <tt>CHECKSUM</tt>, along with the policy parameters, to reduce the chance of tampering. The <tt>CHECKSUM</tt> must be persisted along with the descriptor in each Signer’s storage.
-
-The <tt>TOKEN</tt> and the <tt>CHECKSUM</tt> can’t guarantee complete protection, since that depends on the overall security of all parties in the setup, but they can make it significantly harder for an attacker to tamper with the multisig configuration.
+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 XPUBs and descriptors in plaintext.
@@ -217,7 +215,8 @@ H38+lp9iaesBeCN05BDTH/SnmarlH6+X+Kmw1pgCk+c1Pc1evYIdBag9Nc0nsKhvPtfEbRt9r/qsUVZ5
 ** <tt>my_multisig_wallet.bsms</tt>:
 <pre>BSMS 1.0
 /0/*,/1/*
-wsh(sortedmulti(2,[539f3d89/48'/0'/0'/2']xpub6ETerig7tq89mtaD8Gau2xRWxouRMBy6XHqciA8GZzC2dJv3w6FxfgoegH4b2qYF4oG6VBrhpLrauPs5E1q58GLCnhKp6g9QsV9ZA7J5JNa/*,[f8b12aa6/48'/0'/0'/2']xpub6EWPNhGSX86SN4J2DrBUaQ826o6V4egHqAJZUDJqnsthv9CcjBZV79u68M3YZkuTJnJBXfCrHuJy97fkVurntwgt3V7Ms5hXpJV2vS8fQZM/*))#fntxdj7p</pre>
+wsh(sortedmulti(2,[539f3d89/48'/0'/0'/2']xpub6ETerig7tq89mtaD8Gau2xRWxouRMBy6XHqciA8GZzC2dJv3w6FxfgoegH4b2qYF4oG6VBrhpLrauPs5E1q58GLCnhKp6g9QsV9ZA7J5JNa/*,[f8b12aa6/48'/0'/0'/2']xpub6EWPNhGSX86SN4J2DrBUaQ826o6V4egHqAJZUDJqnsthv9CcjBZV79u68M3YZkuTJnJBXfCrHuJy97fkVurntwgt3V7Ms5hXpJV2vS8fQZM/*))#fntxdj7p
+bc1qqqen0mj98v3mpr5esh4g22llu0wj4c6y2wj3q7l5tcqlr5au4nesyfh7rr</pre>
 
 ===Mode: <tt>STANDARD</tt> Encryption===
 ====ROUND 1====
-- 
cgit v1.2.3


From 633dab3952fbcb4ffe5d21dbb7a11903a6b1d01d Mon Sep 17 00:00:00 2001
From: Hugo Nguyen <hugh.hn@gmail.com>
Date: Fri, 16 Apr 2021 19:28:04 -0700
Subject: move descriptor to the second line in the descriptor record

---
 bip-hugonguyen-bsms.mediawiki | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/bip-hugonguyen-bsms.mediawiki b/bip-hugonguyen-bsms.mediawiki
index 0ce18c5..9e7ec7c 100644
--- a/bip-hugonguyen-bsms.mediawiki
+++ b/bip-hugonguyen-bsms.mediawiki
@@ -87,7 +87,7 @@ The Signer is any software or hardware that controls the private keys and can si
 * The Coordinator verifies that the key records have compatible specification versions.
 * The Coordinator verifies that the included <tt>SIG</tt> is valid given the <tt>KEY</tt>.
 * 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 (<tt>BSMS 1.0</tt> as of this writing). The second line must be a comma-separated list of accepted derivation paths that the Signers can use to generate addresses from the included XPUBs. The paths must start with <tt>/</tt> and use non-hardened derivation. For example, <tt>/0/*</tt> and <tt>/1/*</tt> are some common paths. If there are no restrictions, it must say <tt>No path restrictions</tt>. The third line must be the descriptor string plus a <tt>CHECKSUM</tt>, all in one line. The <tt>CHECKSUM</tt> has [https://github.com/bitcoin/bitcoin/blob/master/doc/descriptors.md#checksums BECH32 encoding]. 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 first line in the descriptor record must be the specification version (<tt>BSMS 1.0</tt> as of this writing). The second line must be the descriptor string plus a <tt>CHECKSUM</tt>, all in one line. The <tt>CHECKSUM</tt> has [https://github.com/bitcoin/bitcoin/blob/master/doc/descriptors.md#checksums BECH32 encoding]. The third line must be a comma-separated list of accepted derivation paths that the Signers can use to generate addresses from the included XPUBs. The paths must start with <tt>/</tt> and use non-hardened derivation. For example, <tt>/0/*</tt> and <tt>/1/*</tt> are some common paths. If there are no restrictions, it must say <tt>No path restrictions</tt>. 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 <tt>MAC</tt> for the record. The first 16 bytes of the <tt>MAC</tt> serves as the <tt>IV</tt> for the encryption.. 
 * The Coordinator encrypts the descriptor record with the <tt>ENCRYPTION_KEY</tt> and <tt>IV</tt>.
 * The Coordinator encodes the <tt>MAC</tt> and the ciphertext into hexadecimal format, then concatenates the results: <tt>(MAC || ciphertext)</tt>.
@@ -99,10 +99,10 @@ The Signer is any software or hardware that controls the private keys and can si
 * The Signer extracts the <tt>MAC</tt> from the data, sets <tt>IV</tt> to the first 16 bytes of the <tt>MAC</tt>, then decrypts the ciphertext using the <tt>ENCRYPTION_KEY</tt> (derived from the open session) and <tt>IV</tt>.
 * The Signer verifies that the included <tt>MAC</tt> is valid given the plaintext.
 * The Signer verifies that it can support the included specification version.
-* The Signer verifies that it is compatible with the derivation path restrictions.
 * The Signer verifies the descriptor’s <tt>CHECKSUM</tt>.
 * The Signer verifies that it can support the descriptor.
 * The Signer checks that its <tt>KEY</tt> is included in the descriptor, using path and fingerprint information provided. The check must perform an exact match on the <tt>KEY</tt>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 given the descriptor and the path restrictions.
 * 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, <tt>M</tt>, <tt>N</tt>, and the position(s) of the Signer's own XPUB in the policy script. The total number of Signers, <tt>N</tt>, is important to prevent a <tt>KEY</tt> insertion attack. The position is important for scripts where key order matters. When applicable, all positions of the XPUB must be displayed. The full descriptor 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).
@@ -214,8 +214,8 @@ H38+lp9iaesBeCN05BDTH/SnmarlH6+X+Kmw1pgCk+c1Pc1evYIdBag9Nc0nsKhvPtfEbRt9r/qsUVZ5
 * Coordinator
 ** <tt>my_multisig_wallet.bsms</tt>:
 <pre>BSMS 1.0
-/0/*,/1/*
 wsh(sortedmulti(2,[539f3d89/48'/0'/0'/2']xpub6ETerig7tq89mtaD8Gau2xRWxouRMBy6XHqciA8GZzC2dJv3w6FxfgoegH4b2qYF4oG6VBrhpLrauPs5E1q58GLCnhKp6g9QsV9ZA7J5JNa/*,[f8b12aa6/48'/0'/0'/2']xpub6EWPNhGSX86SN4J2DrBUaQ826o6V4egHqAJZUDJqnsthv9CcjBZV79u68M3YZkuTJnJBXfCrHuJy97fkVurntwgt3V7Ms5hXpJV2vS8fQZM/*))#fntxdj7p
+/0/*,/1/*
 bc1qqqen0mj98v3mpr5esh4g22llu0wj4c6y2wj3q7l5tcqlr5au4nesyfh7rr</pre>
 
 ===Mode: <tt>STANDARD</tt> Encryption===
-- 
cgit v1.2.3


From 01e9ce937349f03e7adc9b93d84f0e70ed1013ee Mon Sep 17 00:00:00 2001
From: Hugo Nguyen <hugh.hn@gmail.com>
Date: Fri, 16 Apr 2021 20:19:33 -0700
Subject: update test vectors

---
 bip-hugonguyen-bsms.mediawiki | 212 +++++++++++++++++++++---------------------
 1 file changed, 107 insertions(+), 105 deletions(-)

diff --git a/bip-hugonguyen-bsms.mediawiki b/bip-hugonguyen-bsms.mediawiki
index 9e7ec7c..f3dbb0e 100644
--- a/bip-hugonguyen-bsms.mediawiki
+++ b/bip-hugonguyen-bsms.mediawiki
@@ -187,201 +187,203 @@ If the parties wish to have stronger privacy, it is recommended to use a higher
 ** TOKEN: 0
 
 * Signer 1
-** MASTER_KEY_FINGERPRINT: 539f3d89
-** PRIVATE_KEY (m/48'/0'/0'/2'): KyoXqiwiz6qm21BSYebiZFfNF7obkhiJW6TdPMZTQQMF4kZtfD78
-** XPUB (m/48'/0'/0'/2'): xpub6ETerig7tq89mtaD8Gau2xRWxouRMBy6XHqciA8GZzC2dJv3w6FxfgoegH4b2qYF4oG6VBrhpLrauPs5E1q58GLCnhKp6g9QsV9ZA7J5JNa
+** MASTER_KEY_FINGERPRINT: 00e41fee
+** PRIVATE_KEY (m/48'/0'/0'/2'): Kwm5qHwBJsETapvfzBcdSAE9rU1BMBkC4cEvLAKDDBE9FPCz8ppB
+** XPUB (m/48'/0'/0'/2'): xpub6DrL7eCUEzkd2wy3tJDUKK6MobKt2ijAxUYyAHGVojjUysj5zY2yw8NgpgbLd85EDFSKGXkLL5cdKBJr9rjFvRRagEWWkNKvgFsezSHsPKz
 ** Legacy signature
 ** <tt>signer_1_key.bsms</tt>:
 <pre>BSMS 1.0
 00
-[539f3d89/48'/0'/0'/2']xpub6ETerig7tq89mtaD8Gau2xRWxouRMBy6XHqciA8GZzC2dJv3w6FxfgoegH4b2qYF4oG6VBrhpLrauPs5E1q58GLCnhKp6g9QsV9ZA7J5JNa
+[00e41fee/48'/0'/0'/2']xpub6DrL7eCUEzkd2wy3tJDUKK6MobKt2ijAxUYyAHGVojjUysj5zY2yw8NgpgbLd85EDFSKGXkLL5cdKBJr9rjFvRRagEWWkNKvgFsezSHsPKz
 Signer 1 key
-IPXsnNSZb8M6H4fAWtpjAc75hyHHd89fskpM5o7qFg+mPDzEPc1k2mjuIpVIIzaCe45FwPfAAa91RaStfC5Sak0=</pre>
+HzNPcPGSOQLxOX0890nAZmLndSjtz33/Swt9jPtz+K5bLBQXZ1fBPC0y3khgvgD9o9ZSA7hPqxdLUDjPEnMj5UE=</pre>
 
 * Signer 2
-** MASTER_KEY_FINGERPRINT: f8b12aa6
-** PRIVATE_KEY (m/48'/0'/0'/2'): L1zht7muKnUYFMdzC3jwXd78u8tGoKr46AXGh4waF9nphUYWq7ow
-** XPUB (m/48'/0'/0'/2'): xpub6EWPNhGSX86SN4J2DrBUaQ826o6V4egHqAJZUDJqnsthv9CcjBZV79u68M3YZkuTJnJBXfCrHuJy97fkVurntwgt3V7Ms5hXpJV2vS8fQZM
+** MASTER_KEY_FINGERPRINT: 041a5f9d
+** PRIVATE_KEY (m/48'/0'/0'/2'): KyfXyyvgv5DmaPnnWFsBPann23Rt4ExkgEwL4hR2wHmP1wiRQMWT
+** XPUB (m/48'/0'/0'/2'): xpub6Ep74UnuW7KA8u2zgyAW11BEy9n7aZgcrjZsef65ZjHub8tPh6ZE8YaVNdP5UDQtuqYN7ABbBEde6DBLcv1QQVJdXYfSNwLnvMeqvnDM15b
 ** Legacy signature
 ** <tt>signer_2_key.bsms</tt>:
 <pre>BSMS 1.0
 00
-[f8b12aa6/48'/0'/0'/2']xpub6EWPNhGSX86SN4J2DrBUaQ826o6V4egHqAJZUDJqnsthv9CcjBZV79u68M3YZkuTJnJBXfCrHuJy97fkVurntwgt3V7Ms5hXpJV2vS8fQZM
+[041a5f9d/48'/0'/0'/2']xpub6Ep74UnuW7KA8u2zgyAW11BEy9n7aZgcrjZsef65ZjHub8tPh6ZE8YaVNdP5UDQtuqYN7ABbBEde6DBLcv1QQVJdXYfSNwLnvMeqvnDM15b
 Signer 2 key
-H38+lp9iaesBeCN05BDTH/SnmarlH6+X+Kmw1pgCk+c1Pc1evYIdBag9Nc0nsKhvPtfEbRt9r/qsUVZ5onCtBTc=</pre>
+H2q51+r17NY3oMi7kkuCz6gA3Ze+FtPfOYWcpI03gmYnaJScfXunGwjRSG5WpdBmAEYRH+clVmqeaahsgPccqeo=</pre>
 
 ====ROUND 2====
 * Coordinator
 ** <tt>my_multisig_wallet.bsms</tt>:
 <pre>BSMS 1.0
-wsh(sortedmulti(2,[539f3d89/48'/0'/0'/2']xpub6ETerig7tq89mtaD8Gau2xRWxouRMBy6XHqciA8GZzC2dJv3w6FxfgoegH4b2qYF4oG6VBrhpLrauPs5E1q58GLCnhKp6g9QsV9ZA7J5JNa/*,[f8b12aa6/48'/0'/0'/2']xpub6EWPNhGSX86SN4J2DrBUaQ826o6V4egHqAJZUDJqnsthv9CcjBZV79u68M3YZkuTJnJBXfCrHuJy97fkVurntwgt3V7Ms5hXpJV2vS8fQZM/*))#fntxdj7p
+wsh(sortedmulti(2,[00e41fee/48'/0'/0'/2']xpub6DrL7eCUEzkd2wy3tJDUKK6MobKt2ijAxUYyAHGVojjUysj5zY2yw8NgpgbLd85EDFSKGXkLL5cdKBJr9rjFvRRagEWWkNKvgFsezSHsPKz/*,[041a5f9d/48'/0'/0'/2']xpub6Ep74UnuW7KA8u2zgyAW11BEy9n7aZgcrjZsef65ZjHub8tPh6ZE8YaVNdP5UDQtuqYN7ABbBEde6DBLcv1QQVJdXYfSNwLnvMeqvnDM15b/*))#x5ckx6kc
 /0/*,/1/*
-bc1qqqen0mj98v3mpr5esh4g22llu0wj4c6y2wj3q7l5tcqlr5au4nesyfh7rr</pre>
+bc1qgh7jg86mj7lt2gcd7rqdyz2hx8vj3h60f0plquaqxpcw9efxfaks7yx7y5</pre>
 
 ===Mode: <tt>STANDARD</tt> Encryption===
 ====ROUND 1====
 * Coordinator
 ** M-of-N: 2/2
 ** ADDRESS_TYPE: NATIVE_SEGWIT
-** TOKEN (hex): 1ed4ba49e96336b8
-*** TOKEN (decimal): 2221605342811469496
-*** TOKEN (mnemonic): burst place mystery spot cricket foster
-** ENCRYPTION_KEY (hex): 72185a0e25b4efc5d6ac0f8ed32b0165199100e32385040e3a48eb30164bf492
+** TOKEN (hex): 2c872a7af4b2f520
+*** TOKEN (decimal): 3208579967104513312
+*** TOKEN (mnemonic): clutch deer pact truly consider mosquito
+** ENCRYPTION_KEY (hex): 822d802f4670abbf01fc2b6fe71d9a372bc4e819569154cfc1db4be567a80336
 
 * Signer 1
-** MASTER_KEY_FINGERPRINT: 98d79e95
-** PRIVATE_KEY (m/48'/0'/0'/2'): KydC7hZFtWe56oQUAw14HvQ3gKeKVd3m8frFgVMxUqpuhKHvcmm3
-** XPUB (m/48'/0'/0'/2'): xpub6DvvwHS5pd1D36xt4YBGJvtdThWXfn8L9qRj9DbFMExMeP6eBE6Aw9WyBC7XUQwiPPDFurirewsKZpYv68yTV5RBy7SZmw45QEkaLka5BCt
+** MASTER_KEY_FINGERPRINT: 5a2ea679
+** PRIVATE_KEY (m/48'/0'/0'/2'): L1R9BexLnWSbtzdeL9F6GL8w2i4eM3qwvvRL6iXVfVerCG79J9YN
+** XPUB (m/48'/0'/0'/2'): xpub6EbVsEmr7VHTj4GSQJ8J3YuaKthihAg33dodnZ8ocvj9EMNVCBq2dCoMSkSjsshqpKVdBSua5pUaqWTHbNkxVm4f9MDAMY7LE5wsvTctSQP
 ** Legacy signature
 ** <tt>signer_1_key.bsms</tt>:
 <pre>BSMS 1.0
-1ed4ba49e96336b8
-[98d79e95/48'/0'/0'/2']xpub6DvvwHS5pd1D36xt4YBGJvtdThWXfn8L9qRj9DbFMExMeP6eBE6Aw9WyBC7XUQwiPPDFurirewsKZpYv68yTV5RBy7SZmw45QEkaLka5BCt
+2c872a7af4b2f520
+[5a2ea679/48'/0'/0'/2']xpub6EbVsEmr7VHTj4GSQJ8J3YuaKthihAg33dodnZ8ocvj9EMNVCBq2dCoMSkSjsshqpKVdBSua5pUaqWTHbNkxVm4f9MDAMY7LE5wsvTctSQP
 Signer 1 key
-HxtPoP0DrQSac/7ypcwC07R2s6jjpXR6Li2Q92zXj/FSIMQcV5yOU0/ONsDgHXamq0gD5DfPbvuVCp9ZJubclV4=</pre>
+IKaOunXsMpnQOuEsbOeD2207uwKAoStp73VS1LeqbGfZQLJPdeQ49rAM/1CLJpUAWO9LUYQKsIu8pB56jjrUOmA=</pre>
 
 * Signer 1 encryption
-** HMAC_KEY (hex): 4dab3988cbc683ad7a8c93d43f9b11a78b63a93d5e33ea19c603f4b7b87ac284
-** MAC (hex): afe99e92f0eadc3308eb990045e90a4f54e9f59d22aae5034ac3d866d29c508d
-** IV (hex) : afe99e92f0eadc3308eb990045e90a4f
-** CIPHERTEXT (hex): 214ec9a861a238ba7f0412305a97a6e0faa332be15af09127e131d669e5d55d73891580a5808cea5d2bf39f43496d3c0f8236eff3854fcc7446daf9d2b58fd40d97ce3b1745de2959e29767039b99969821400eca0c3517fae56d2d24d5235a3430af1ed894b68681d706cce7c75adf35d8580603aa302bc01fef06d0336a37f19dd46100baa9e4eabd8796a810e13941ad0980c126ad55d6a4bbef11a7bf893b7d2ed8fb0d8324c4c9b512d4d1e75096c63511e15018fc832816b5639d58fc28c60c049487d04bd5a6cb32aa1381d0809660d54376b9f63325c18cfd1ac5024088e74cb703fe165972cc4485abb1feefe92a0b4ea297fe2f4f7416eeee1efc9b942540931ef
-** <tt>signer_1_key.dat</tt>: <pre>afe99e92f0eadc3308eb990045e90a4f54e9f59d22aae5034ac3d866d29c508d214ec9a861a238ba7f0412305a97a6e0faa332be15af09127e131d669e5d55d73891580a5808cea5d2bf39f43496d3c0f8236eff3854fcc7446daf9d2b58fd40d97ce3b1745de2959e29767039b99969821400eca0c3517fae56d2d24d5235a3430af1ed894b68681d706cce7c75adf35d8580603aa302bc01fef06d0336a37f19dd46100baa9e4eabd8796a810e13941ad0980c126ad55d6a4bbef11a7bf893b7d2ed8fb0d8324c4c9b512d4d1e75096c63511e15018fc832816b5639d58fc28c60c049487d04bd5a6cb32aa1381d0809660d54376b9f63325c18cfd1ac5024088e74cb703fe165972cc4485abb1feefe92a0b4ea297fe2f4f7416eeee1efc9b942540931ef</pre>
+** HMAC_KEY (hex): cf629cab57753f5975a8f5b023fa033af66fb104f69245a99dc823f2a0db6791
+** MAC (hex): ac4589ae73e4a5e1459c3087cbcc0db52dd93e8495ca4b410704d9a6ddb2e905
+** IV (hex) : ac4589ae73e4a5e1459c3087cbcc0db5
+** CIPHERTEXT (hex): 2abd1534e395d44047417ede3d4b61fbdc05c948e965b550075d8432ebe9f1b10eb37e69dfd972d8dc944a3a906a8bbcd00551b075eb4556f66f3e809c2798e7c0d8b06675a5c513fc65f9858d97259cc48a3224a23eadb5d7035899bdcbf792f62397fed4ab4a606526c1e40a7edd4a0f3e44470a26d850f64edbca71da6c14aa9e495ae5f9079bac7efb3cf0e4f49f8f7aaac976af42659fbf540c7717c29b7944be27f9bd6023c2c86ff290a6e66d49c627eddd8a5190f2e40d58e8a127e5b95c61fa183ac446619138b233bdec28eda87f5f4c0fc7493d8be924d3f75214c26c774bf21cbf781a44abeca6b984322eaff4ea330f87528d69514d83e816aaea2434bdee15
+** <tt>signer_1_key.dat</tt>: <pre>ac4589ae73e4a5e1459c3087cbcc0db52dd93e8495ca4b410704d9a6ddb2e9052abd1534e395d44047417ede3d4b61fbdc05c948e965b550075d8432ebe9f1b10eb37e69dfd972d8dc944a3a906a8bbcd00551b075eb4556f66f3e809c2798e7c0d8b06675a5c513fc65f9858d97259cc48a3224a23eadb5d7035899bdcbf792f62397fed4ab4a606526c1e40a7edd4a0f3e44470a26d850f64edbca71da6c14aa9e495ae5f9079bac7efb3cf0e4f49f8f7aaac976af42659fbf540c7717c29b7944be27f9bd6023c2c86ff290a6e66d49c627eddd8a5190f2e40d58e8a127e5b95c61fa183ac446619138b233bdec28eda87f5f4c0fc7493d8be924d3f75214c26c774bf21cbf781a44abeca6b984322eaff4ea330f87528d69514d83e816aaea2434bdee15</pre>
 
 * Signer 2
-** MASTER_KEY_FINGERPRINT: 3e94b5a1
-** PRIVATE_KEY (m/48'/0'/0'/2'): KyPh5XYjExjNHPiBjYhp8iAntAehrDziiwRv7y9Ln6eK9QU2xP55
-** XPUB (m/48'/0'/0'/2'): xpub6E1W1DUYY29V2b8czCcpi36GG2uD33B11vwNopgTZwsVyfgAkA4kPCqLP5R4YzaRvzW17CQrDkgmDQbA848AdkR7W18nNvMKXzzCBSnZP9c
+** MASTER_KEY_FINGERPRINT: 21383fe9
+** PRIVATE_KEY (m/48'/0'/0'/2'): KzpgvbUzVeDCn8rdHiSsYWTC75ZrmWK58aJF2dkzdxaBTEwjsgeK
+** XPUB (m/48'/0'/0'/2'): xpub6DqrTSNEY3aVyVxZaxMZvPnERg3NWWPCj4NQYqCDbd4eau2v9yQ81rwnopiMnVVE3YGjNtEZJVRc7YEDY5L3dG1dsgWzvXoE587QA8Dzr1c
 ** Legacy signature
 ** <tt>signer_2_key.bsms</tt>:
 <pre>BSMS 1.0
-1ed4ba49e96336b8
-[3e94b5a1/48'/0'/0'/2']xpub6E1W1DUYY29V2b8czCcpi36GG2uD33B11vwNopgTZwsVyfgAkA4kPCqLP5R4YzaRvzW17CQrDkgmDQbA848AdkR7W18nNvMKXzzCBSnZP9c
+2c872a7af4b2f520
+[21383fe9/48'/0'/0'/2']xpub6DqrTSNEY3aVyVxZaxMZvPnERg3NWWPCj4NQYqCDbd4eau2v9yQ81rwnopiMnVVE3YGjNtEZJVRc7YEDY5L3dG1dsgWzvXoE587QA8Dzr1c
 Signer 2 key
-ILR49QLy9+xkMS11TIXJRSMgOQOzGbAaooq4/ZRcd8VgM6j5upJMI0mjJHseQOMYSGk8FqjXZbMvBGyiX9wdutM=</pre>
+H4pj0+/d89BrY4v1mDw+oobMhuJAjiRh/Ia1jSMwoENEao3kyqEcuHgvizOqGo7X0vdwlhQvOYBmjgV5xn2nvgk=</pre>
 
 * Signer 2 encryption
-** HMAC_KEY (hex): 4dab3988cbc683ad7a8c93d43f9b11a78b63a93d5e33ea19c603f4b7b87ac284
-** MAC (hex): 5c7cb2ac407cd60b1f2b86ef46077d3a312b6ce921df2a141347e8bf1e5c6573
-** IV (hex) : 5c7cb2ac407cd60b1f2b86ef46077d3a
-** CIPHERTEXT (hex): f23e6c76ff45d308dea6014030a274127ad437228f1d5ec2431d2ea9e3cedd5b0a207a9efa6f926d5420205003f3cb9c4b82b2d595180e62a173a2e5aa0322de48a70a873f641bdae1764e6b1667c241e0fe03a4ccdc3fe0cfa5f75b239d6497c3b69dca17bb685ba70b307d1243836d8fb198ce727cfae4057ee0b4fdcb09f4ba5ae127f49c5de780edb4e40aec96303c8a7b98b1b8e53dd5e07e01d4f3ffd836763209a1f0cbc61adcfdc2951e77528ee7b6e68114c3a4bec38875d285021e68ae8aa913bb1e2e65dd52c649a0e98bfb4e8bab6dd10295c1167a0854ba44f094feb75d2fb00c944f07d4b47114f483df9838459316f3ddbc4a82e6507881931f8e20f5b805
-** <tt>signer_2_key.dat</tt>: <pre>5c7cb2ac407cd60b1f2b86ef46077d3a312b6ce921df2a141347e8bf1e5c6573f23e6c76ff45d308dea6014030a274127ad437228f1d5ec2431d2ea9e3cedd5b0a207a9efa6f926d5420205003f3cb9c4b82b2d595180e62a173a2e5aa0322de48a70a873f641bdae1764e6b1667c241e0fe03a4ccdc3fe0cfa5f75b239d6497c3b69dca17bb685ba70b307d1243836d8fb198ce727cfae4057ee0b4fdcb09f4ba5ae127f49c5de780edb4e40aec96303c8a7b98b1b8e53dd5e07e01d4f3ffd836763209a1f0cbc61adcfdc2951e77528ee7b6e68114c3a4bec38875d285021e68ae8aa913bb1e2e65dd52c649a0e98bfb4e8bab6dd10295c1167a0854ba44f094feb75d2fb00c944f07d4b47114f483df9838459316f3ddbc4a82e6507881931f8e20f5b805</pre>
+** HMAC_KEY (hex): cf629cab57753f5975a8f5b023fa033af66fb104f69245a99dc823f2a0db6791
+** MAC (hex): 8682c41113aa3a5f42891f3dc513dd5d3ee8c817136cfa7998e7917e2b74d801
+** IV (hex) : 8682c41113aa3a5f42891f3dc513dd5d
+** CIPHERTEXT (hex): eff104d3fed1615f39d0a399b399e272b8a15dd74f6d8167555bbdac7787c24d603fc6fc90c7e9049cceb2f48d8f524f4ca284337ca894fff0602e9e42b83a9884159e47c89778ed15dbacc5a73ca16e3cb10e4cfb927f072c7d7dc2bf25311d0ac4541e240bf69bb921cfbb260b2b0adcf4893c3f6693116ef4806bbd9ae47e99eb5e03a6b4502122a5900956785169813190a500ae65c4aa7aea58771a5630b2594fdca09cfd1135ef796da1266b65d40eebfe583595ced217be59ef68534c9d9292f29a7f1e83f57a10e8ec371055e7da05d6b67be29e2d003da406dfdbb0fdef52d0a977fb0050f465338a918d4ea3cfc8669c78708d5eeb30efe3e2ae9a0e72ab7e25bf
+** <tt>signer_2_key.dat</tt>: <pre>8682c41113aa3a5f42891f3dc513dd5d3ee8c817136cfa7998e7917e2b74d801eff104d3fed1615f39d0a399b399e272b8a15dd74f6d8167555bbdac7787c24d603fc6fc90c7e9049cceb2f48d8f524f4ca284337ca894fff0602e9e42b83a9884159e47c89778ed15dbacc5a73ca16e3cb10e4cfb927f072c7d7dc2bf25311d0ac4541e240bf69bb921cfbb260b2b0adcf4893c3f6693116ef4806bbd9ae47e99eb5e03a6b4502122a5900956785169813190a500ae65c4aa7aea58771a5630b2594fdca09cfd1135ef796da1266b65d40eebfe583595ced217be59ef68534c9d9292f29a7f1e83f57a10e8ec371055e7da05d6b67be29e2d003da406dfdbb0fdef52d0a977fb0050f465338a918d4ea3cfc8669c78708d5eeb30efe3e2ae9a0e72ab7e25bf</pre>
 
 ====ROUND 2====
 *Coordinator
 ** <tt>my_multisig_wallet.bsms</tt>:
 <pre>BSMS 1.0
+wsh(sortedmulti(2,[5a2ea679/48'/0'/0'/2']xpub6EbVsEmr7VHTj4GSQJ8J3YuaKthihAg33dodnZ8ocvj9EMNVCBq2dCoMSkSjsshqpKVdBSua5pUaqWTHbNkxVm4f9MDAMY7LE5wsvTctSQP/*,[21383fe9/48'/0'/0'/2']xpub6DqrTSNEY3aVyVxZaxMZvPnERg3NWWPCj4NQYqCDbd4eau2v9yQ81rwnopiMnVVE3YGjNtEZJVRc7YEDY5L3dG1dsgWzvXoE587QA8Dzr1c/*))#lfv5nh7v
 /0/*,/1/*
-wsh(sortedmulti(2,[98d79e95/48'/0'/0'/2']xpub6DvvwHS5pd1D36xt4YBGJvtdThWXfn8L9qRj9DbFMExMeP6eBE6Aw9WyBC7XUQwiPPDFurirewsKZpYv68yTV5RBy7SZmw45QEkaLka5BCt/*,[3e94b5a1/48'/0'/0'/2']xpub6E1W1DUYY29V2b8czCcpi36GG2uD33B11vwNopgTZwsVyfgAkA4kPCqLP5R4YzaRvzW17CQrDkgmDQbA848AdkR7W18nNvMKXzzCBSnZP9c/*))#x0lx92qk</pre>
+bc1qr3cmly26qp4elq6dhp6zm4fe7sw46w8fqe6ut4cp6e6zckewx7eqmqjk3r</pre>
 
 *Coordinator encryption
-** HMAC_KEY (hex): 4dab3988cbc683ad7a8c93d43f9b11a78b63a93d5e33ea19c603f4b7b87ac284
-** MAC (hex): df3d06db6c8b8a5f25de202e10ea225df6415d1ed0e36c64cc2be1b7e86c2a38
-** IV (hex) : df3d06db6c8b8a5f25de202e10ea225d
-** CIPHERTEXT (hex): 2761e6bfe839586b4c90954200bc4ce6d39ef164c5d14997755575d1691ee249ffd20beda526f57a7424907f839c6c2e3ecd46889ede290a2c81de22d3f33a7fa5e55ec95c0e26005c596d0f6346f819823f361f9f9f54d1eae48b325240d66c5888bd5ebab843061dcdd73b675346da982646c83026694d757661d31c2d654fb263c9ab3e874a258bc234c48532f15e9450c982fcf161404746e9f23d25e17b74139cd799983fd0c7a7a0386a823d3789b4578879a764172cc8ef96ab003eee24f6288007d31e2b999aff5a6d30cc524a0111a99730a29cf28ae41dbff6ce21ca6bc1df37074228178048e835584e6e70dba941154d024cd03cb6c56d0bde441ce464aa749de5e814dd30e21b75f62e831ac1f28eda1a7ba7e122076789e284402c8ba85b5a0e864bce220e3c78fa2f465e2bcf6b1d378816319de99f99ce7068
-** <tt>my_multisig_wallet.dat</tt>: <pre>df3d06db6c8b8a5f25de202e10ea225df6415d1ed0e36c64cc2be1b7e86c2a382761e6bfe839586b4c90954200bc4ce6d39ef164c5d14997755575d1691ee249ffd20beda526f57a7424907f839c6c2e3ecd46889ede290a2c81de22d3f33a7fa5e55ec95c0e26005c596d0f6346f819823f361f9f9f54d1eae48b325240d66c5888bd5ebab843061dcdd73b675346da982646c83026694d757661d31c2d654fb263c9ab3e874a258bc234c48532f15e9450c982fcf161404746e9f23d25e17b74139cd799983fd0c7a7a0386a823d3789b4578879a764172cc8ef96ab003eee24f6288007d31e2b999aff5a6d30cc524a0111a99730a29cf28ae41dbff6ce21ca6bc1df37074228178048e835584e6e70dba941154d024cd03cb6c56d0bde441ce464aa749de5e814dd30e21b75f62e831ac1f28eda1a7ba7e122076789e284402c8ba85b5a0e864bce220e3c78fa2f465e2bcf6b1d378816319de99f99ce7068</pre>
+** HMAC_KEY (hex): cf629cab57753f5975a8f5b023fa033af66fb104f69245a99dc823f2a0db6791
+** MAC (hex): 34a56c778bb14b3625637ab4290c1b3b5fb3f7e20d2fba4052643cc6cdcd2fc5
+** IV (hex) : 34a56c778bb14b3625637ab4290c1b3b
+** CIPHERTEXT (hex): 0a94b74762223a31c29ba343d47f563d5ed7f464afc62ca1dc332ba0eed1c06cf02462acfeed0d2fe4013e6c6693aae56fe9f0cb85db81b7bc46c219f942ed23ec8a326b1d8323e43f67f61dc5f3032e58216c6ce2923839feb4068506c978fd33c83be01fcfd033954228bf64dd97631715508adbb02e7176b7d90992b819a71c29b7b3288672ce64ff28d881eb994327e783f1895a157d7decfb6d048b4b3eb442ca618d0550f98b1d1251877332b0c5ea27e2c72d7fa948ba0fdb6fdc956a59e7a00f020ef78e8638c39f29c287ea5fdfd2d3cf5ac2dca51597284052e2bad6290a4d422a15e7b43d09e9a368cc9268fce3eab49632aee80679228bdee3914ece509e638949215d2d3ad6392b5927bdc7c8f8d664c7d1e8d9adaa0bb35fbd86bd9082ca2d53b0922a1871c9deda2ea86dedc0269bea6f8d29cb989e4df277dadf5da2d41668c585f8b219cda52e537ee31b9b896b6fb6fe47de6859c1dfc7d652fc7c65f99598500ab4aeb27973996ac528fcfccd76c0dee1d8e83b8099aa
+** <tt>my_multisig_wallet.dat</tt>: <pre>34a56c778bb14b3625637ab4290c1b3b5fb3f7e20d2fba4052643cc6cdcd2fc50a94b74762223a31c29ba343d47f563d5ed7f464afc62ca1dc332ba0eed1c06cf02462acfeed0d2fe4013e6c6693aae56fe9f0cb85db81b7bc46c219f942ed23ec8a326b1d8323e43f67f61dc5f3032e58216c6ce2923839feb4068506c978fd33c83be01fcfd033954228bf64dd97631715508adbb02e7176b7d90992b819a71c29b7b3288672ce64ff28d881eb994327e783f1895a157d7decfb6d048b4b3eb442ca618d0550f98b1d1251877332b0c5ea27e2c72d7fa948ba0fdb6fdc956a59e7a00f020ef78e8638c39f29c287ea5fdfd2d3cf5ac2dca51597284052e2bad6290a4d422a15e7b43d09e9a368cc9268fce3eab49632aee80679228bdee3914ece509e638949215d2d3ad6392b5927bdc7c8f8d664c7d1e8d9adaa0bb35fbd86bd9082ca2d53b0922a1871c9deda2ea86dedc0269bea6f8d29cb989e4df277dadf5da2d41668c585f8b219cda52e537ee31b9b896b6fb6fe47de6859c1dfc7d652fc7c65f99598500ab4aeb27973996ac528fcfccd76c0dee1d8e83b8099aa</pre>
 
 ===Mode: <tt>EXTENDED</tt> Encryption===
 ====ROUND 1====
 *Coordinator
 ** M-of-N: 2/3
 ** ADDRESS_TYPE: NESTED_SEGWIT
-** TOKEN for Signer 1 (hex): 654d63309464afcda558c6aa
-*** TOKEN (decimal): 31351541690484562733651510954
-*** TOKEN (mnemonic): grab help slow churn enough traffic nice boat price
-*** ENCRYPTION_KEY (hex): 4073adac2351e164b8d68039abd9d4b8e4d07adccfdf73ece6e236d60b107802
-** TOKEN for Signer 2 (hex): b0344f51d5cb04083d598fa3
-*** TOKEN (decimal): 54532600447720520868878192547
-*** TOKEN (mnemonic): rabbit pen stamp process raccoon advice voice cradle person
-*** ENCRYPTION_KEY (hex): 6bae6b670e257d7468c3e90194029dd468a2f39d8b9a3ff187b08209b1d409b6
-** TOKEN for Signer 3 (hex): 163fd307195982c4c39d50bb
-*** TOKEN (decimal): 6885829092987042066541138107
-*** TOKEN (mnemonic): bike write scrub crawl oblige give attack present rookie
-*** ENCRYPTION_KEY (hex): c78b94589214b6dc98b337ba4ce54380553ed00a1e5b1955fc540ce3b30d6566
+** TOKEN for Signer 1 (hex): 3e4e9f4a9bab074a1416b506
+*** TOKEN (decimal): 19283119055400240376301663494
+*** TOKEN (mnemonic): dinner insane sport dance race pink expect stove alcohol
+*** ENCRYPTION_KEY (hex): 06eb820f8343d941740e3f960c4df2ace84026abc3c1faca5ca487974341ccc0
+** TOKEN for Signer 2 (hex): 4c6d6215d13f7a1e9183f810
+*** TOKEN (decimal): 23653096855135070925426522128
+*** TOKEN (mnemonic): erase help lyrics pen waste aunt ecology lecture awkward
+*** ENCRYPTION_KEY (hex): f5d79f32ad11cec172e088ab84bbfbea65790c9a5f7292912edc2ca42c6bfd1d
+** TOKEN for Signer 3 (hex): 70d41aaf4c4561c19205d819
+*** TOKEN (decimal): 34918739388953622996442273817
+*** TOKEN (mnemonic): ignore patch profit obtain figure this elite roast book
+*** ENCRYPTION_KEY (hex): b2bd2e480807f374177c0136bf14b318608e376a6c64ac026a3081a26d2664ca
 
 * Signer 1
-** MASTER_KEY_FINGERPRINT: 110dc257
-** PRIVATE_KEY (m/48'/0'/0'/1'): KzshDDEBhzyiwXHoyE7ZiLegzztEy54AG6Wq8N844LqHSQMHt4Ji
-** XPUB (m/48'/0'/0'/1'): xpub6EPQbDFezXYvVFHqnc8R7QUSE8hTepbyCXU7jJBT4dVm2rQHe1i6isqoj59qhyBiCdKquo6QsgMZNHvEz3BM4cNSszF25siTqLUCznBm8vk
+** MASTER_KEY_FINGERPRINT: 1af5fed9
+** PRIVATE_KEY (m/48'/0'/0'/1'): L4VABXeok8NSrEewRijcHY1AfzDpqQfzrbHDgmnj3j7vBgRaoofF
+** XPUB (m/48'/0'/0'/1'): xpub6Dk872oqUVGBi8rUjch8SBmvjYcXe4Ege93fsZ4utmZmyVgtjYiRqnvdUX3L8TfRdbPGXPuB8F7dBvecsgC75oSzCje9824wMtM4R3qDtoZ
 ** Legacy signature
 ** <tt>signer_1_key.bsms</tt>:
 <pre>BSMS 1.0
-654d63309464afcda558c6aa
-[110dc257/48'/0'/0'/1']xpub6EPQbDFezXYvVFHqnc8R7QUSE8hTepbyCXU7jJBT4dVm2rQHe1i6isqoj59qhyBiCdKquo6QsgMZNHvEz3BM4cNSszF25siTqLUCznBm8vk
+3e4e9f4a9bab074a1416b506
+[1af5fed9/48'/0'/0'/1']xpub6Dk872oqUVGBi8rUjch8SBmvjYcXe4Ege93fsZ4utmZmyVgtjYiRqnvdUX3L8TfRdbPGXPuB8F7dBvecsgC75oSzCje9824wMtM4R3qDtoZ
 Signer 1 key
-IDX6xLdM4XjetYPvVfpVBXAfT7oE3tHAOB4blZpbIst8bjJ+LbDeP4tZl4O8utAuys9igXE0G3kaHz1mg/+OU8w=</pre>
+IIB9bS+1UiqePqzeuQjOYVxr/ElW7ZpDazsmLC1WXgopB1PuEM0VDVVMybHXPPCnR8jB3JBO+1G2H2fYAbo5Td8=</pre>
 
 * Signer 1 encryption
-** HMAC_KEY (hex): f43c359a4b3d7b2e01be73c54519b12545ca9a23a86f824aadf577b314a7caa7
-** MAC (hex): 40b6b43e2f1bc01b748eb242235d7e09fa8a2fd6cebe35784cf3adf81910ec98
-** IV (hex) : 40b6b43e2f1bc01b748eb242235d7e09
-** CIPHERTEXT (hex): 0877987764401c27e6c60ed2f1bb89dff1dbc5e8204149f682d53049bffe39553f24af3928aa2f78ac2d04ac5baa0c3ec39aaccf0d258e7bb6659a7b92e92f2c2784a94f4df8e8af2270d9d411bfff2cfb9f71b4e1ac87561c7d2ac57ca86a1f9716d5da7571719d24830fc8d015a0daf04b3742439484488798335357f2eeaa8e2db2ba630f9dffd88236e327ab5bfcfb6e29ee3ef6cc18e0b71c1731465c2351e76b92f7b1bd28ef6eff5414c22aa6c80090fa59b973c22e3044e92dbf3688990a49a42828e52c1e686f1193dcdf7b7118930e01419fe938c6811c58c84c36d692fd52846f998bc328471f1e73c22261791a08cda096ee3ac8b37f31afd0b1d9c335ff9ac67ff230eb0d69f2d7
-** <tt>signer_1_key.dat</tt>: <pre>40b6b43e2f1bc01b748eb242235d7e09fa8a2fd6cebe35784cf3adf81910ec980877987764401c27e6c60ed2f1bb89dff1dbc5e8204149f682d53049bffe39553f24af3928aa2f78ac2d04ac5baa0c3ec39aaccf0d258e7bb6659a7b92e92f2c2784a94f4df8e8af2270d9d411bfff2cfb9f71b4e1ac87561c7d2ac57ca86a1f9716d5da7571719d24830fc8d015a0daf04b3742439484488798335357f2eeaa8e2db2ba630f9dffd88236e327ab5bfcfb6e29ee3ef6cc18e0b71c1731465c2351e76b92f7b1bd28ef6eff5414c22aa6c80090fa59b973c22e3044e92dbf3688990a49a42828e52c1e686f1193dcdf7b7118930e01419fe938c6811c58c84c36d692fd52846f998bc328471f1e73c22261791a08cda096ee3ac8b37f31afd0b1d9c335ff9ac67ff230eb0d69f2d7</pre>
+** HMAC_KEY (hex): c9d881d28107d51c05b5c4252de0afac9dcfbe056f78ae690fc1cfed2a39d17c
+** MAC (hex): 9ee541d02fdd920c9be4528f262f2b4799a1cb0360d43fa4d3cfa436710d958a
+** IV (hex) : 9ee541d02fdd920c9be4528f262f2b47
+** CIPHERTEXT (hex): 16c870dbe0393a982b2e0a62e0f5a9e5b0eecece8ae27412bd4c9a66df562207aa0bd138a1ca122cbe5fa7feedd74b34009dd018c9454d8dc0d794551d76cc996502da04b5510f70d721ebba89c4135ac1e65075ec5da004b108f5b9d5119acb8bd25c7f8711512f25dcad66cefcba1de2844dcc537ce4c1579415c43141bf28e3c910e349229356a15c5db7b637f618a519ee6972abe06f0100d71e91603bbfbfecabe99cdfec8e036c7f739f1bbb0c502372696a9eb7f4d313b5d16a96d9b2e67a2c24738e2833f39d47e081370c66ad47fe5385adcc492129697cbda2507df9addc993e1fb0310fdb05ea7ad5cced8f23fc7a42101690520113dcad9a759c514b4ef7c93e4d7093f4b6d2de8b
+** <tt>signer_1_key.dat</tt>: <pre>9ee541d02fdd920c9be4528f262f2b4799a1cb0360d43fa4d3cfa436710d958a16c870dbe0393a982b2e0a62e0f5a9e5b0eecece8ae27412bd4c9a66df562207aa0bd138a1ca122cbe5fa7feedd74b34009dd018c9454d8dc0d794551d76cc996502da04b5510f70d721ebba89c4135ac1e65075ec5da004b108f5b9d5119acb8bd25c7f8711512f25dcad66cefcba1de2844dcc537ce4c1579415c43141bf28e3c910e349229356a15c5db7b637f618a519ee6972abe06f0100d71e91603bbfbfecabe99cdfec8e036c7f739f1bbb0c502372696a9eb7f4d313b5d16a96d9b2e67a2c24738e2833f39d47e081370c66ad47fe5385adcc492129697cbda2507df9addc993e1fb0310fdb05ea7ad5cced8f23fc7a42101690520113dcad9a759c514b4ef7c93e4d7093f4b6d2de8b</pre>
 
 * Signer 2
-** MASTER_KEY_FINGERPRINT: 5c890401
-** PRIVATE_KEY (m/48'/0'/0'/1'): L41Jnc9CdBtBJd18429MDGcTgP2DNoXaKyyGr271ndTprvrHXDQf
-** XPUB (m/48'/0'/0'/1'): xpub6EW1SmjSXq9YwVwcan5qWEncgx89SozMvGNpYF6hfZHYNTikNZ4gsXuVhHTi6xYJCkmY4X4wpPPS5Gr7aY39dVJMS2TGfihr25oaspKtU8q
+** MASTER_KEY_FINGERPRINT: bbe4987a
+** PRIVATE_KEY (m/48'/0'/0'/1'): L3chGYUbvkxJuv61Vx6mmBWmDyBi7HnWDqLtTKokeKuy5GmKRx53
+** XPUB (m/48'/0'/0'/1'): xpub6EC1EmDURTiXqb4FCmANE1u5jybxqv8qyxXp6JKVJQTzGaF4JWzPhASkHb9RUuHS7hEKZ3iouARzCrhG3E6SauuefL1LrLoAtKHvmDJ1JFK
 ** Legacy signature
 ** <tt>signer_2_key.bsms</tt>:
 <pre>BSMS 1.0
-b0344f51d5cb04083d598fa3
-[5c890401/48'/0'/0'/1']xpub6EW1SmjSXq9YwVwcan5qWEncgx89SozMvGNpYF6hfZHYNTikNZ4gsXuVhHTi6xYJCkmY4X4wpPPS5Gr7aY39dVJMS2TGfihr25oaspKtU8q
+4c6d6215d13f7a1e9183f810
+[bbe4987a/48'/0'/0'/1']xpub6EC1EmDURTiXqb4FCmANE1u5jybxqv8qyxXp6JKVJQTzGaF4JWzPhASkHb9RUuHS7hEKZ3iouARzCrhG3E6SauuefL1LrLoAtKHvmDJ1JFK
 Signer 2 key
-H5kN6UHaK2xACB6iYdTxxQPD8qyFEYv9iMsQs5B0MRfCM7NA5GB+7EFgmBpSctwt6B122zWBr6mRjpYjKmj+7hs=</pre>
+H4tcaRaEGIPHDg+e+8MxPyYyo3qk9ZKPAIdYQY3iXZOPfb1W96FqzP+6KMj5ov8OSIjeA9PEtRVLUmsMoVnR7EA=</pre>
 
 * Signer 2 encryption
-** HMAC_KEY (hex): e0a20b5f5285fbaa35aad08fb70f5626c9abbe1b384a4950735b28aca6325ff2
-** MAC (hex): 3a6deec8dbdbd6606a52c7d7e64eca4f972a293cbabac6f62736629fbe77928a
-** IV (hex) : 3a6deec8dbdbd6606a52c7d7e64eca4f
-** CIPHERTEXT (hex): bb0fb72f61b0c4858bd9c65235390b67651b94c4b0329238b0116dd6d3365ade33cb1c1b1619638968791a5d2d1d263d90280bdad8d9ca24c34a78e320076e0dccf59e7f729b541b44bbe40ba803dedd3b17c49765377cb2d913a856b86c3dd383dab475790e89226ed8ef2301574212d2809ed9c099aa67be434024ee2a4e82a146300acf755863da64807cb7bb2636f6616489636d254a870778d3540832aea44abac4328b5d90f3e6045ef36a526ce5d575f2305e3e4699dccbc713e9e68f50364036c1054c2a506aab77ea7c43a89536947c24330b09a62a90c3b4ae2d452f96ef34ec871af2c52d68ddede2503c87e2ba68d5cf9be589457879e06021ea6a6176f7dded820ba4c0e709e2a2
-** <tt>signer_2_key.dat</tt>: <pre>3a6deec8dbdbd6606a52c7d7e64eca4f972a293cbabac6f62736629fbe77928abb0fb72f61b0c4858bd9c65235390b67651b94c4b0329238b0116dd6d3365ade33cb1c1b1619638968791a5d2d1d263d90280bdad8d9ca24c34a78e320076e0dccf59e7f729b541b44bbe40ba803dedd3b17c49765377cb2d913a856b86c3dd383dab475790e89226ed8ef2301574212d2809ed9c099aa67be434024ee2a4e82a146300acf755863da64807cb7bb2636f6616489636d254a870778d3540832aea44abac4328b5d90f3e6045ef36a526ce5d575f2305e3e4699dccbc713e9e68f50364036c1054c2a506aab77ea7c43a89536947c24330b09a62a90c3b4ae2d452f96ef34ec871af2c52d68ddede2503c87e2ba68d5cf9be589457879e06021ea6a6176f7dded820ba4c0e709e2a2</pre>
+** HMAC_KEY (hex): 8050b80716db042130c7aaf086a0b3e59d8d3e59c0d689c6b61fb2e5ccd9644b
+** MAC (hex): 991dc1aa90ccb22ff410208efc4f8132a5d11586e21d76f273180b53d30046f8
+** IV (hex) : 991dc1aa90ccb22ff410208efc4f8132
+** CIPHERTEXT (hex): 6759a008f1e9eaad15c3be3669994402654919c5993d64198a00d9073c8fde97696beeed89b5cf9c0f9b0cacb1e0b769cb9fdaa92b74bb4d1574c8ba9056d05d25950652da5bd61ba1a4194b7a6fdb28ec09f4697e5cc825ce9738d0852096f5030498272feec82766b59848dd1e3a4941da59b5f74af6291a9638be980c6961a0f094db72efdabc1bca1fa9a0aa32cfdf0216e4b4af760b9e542d4944a5d25d68c2b901131c735148392b48c642b619b74f7fa5e2575a053de0cddedeefee352b31b52e89bf7e0f5f2c147437740c5167e11890172d1813293c405379107f54fc74b56e06dc2da7eb1a361074b84fccc2e865227382a0d5a6bf69b223d9d202656fd3f86d665b12500a66749624
+** <tt>signer_2_key.dat</tt>: <pre>991dc1aa90ccb22ff410208efc4f8132a5d11586e21d76f273180b53d30046f86759a008f1e9eaad15c3be3669994402654919c5993d64198a00d9073c8fde97696beeed89b5cf9c0f9b0cacb1e0b769cb9fdaa92b74bb4d1574c8ba9056d05d25950652da5bd61ba1a4194b7a6fdb28ec09f4697e5cc825ce9738d0852096f5030498272feec82766b59848dd1e3a4941da59b5f74af6291a9638be980c6961a0f094db72efdabc1bca1fa9a0aa32cfdf0216e4b4af760b9e542d4944a5d25d68c2b901131c735148392b48c642b619b74f7fa5e2575a053de0cddedeefee352b31b52e89bf7e0f5f2c147437740c5167e11890172d1813293c405379107f54fc74b56e06dc2da7eb1a361074b84fccc2e865227382a0d5a6bf69b223d9d202656fd3f86d665b12500a66749624</pre>
 
 * Signer 3
-** MASTER_KEY_FINGERPRINT: 614cbf5f
-** PRIVATE_KEY (m/48'/0'/0'/1'): L2ccRLzH7GfVxWpU8YSY9y5UGyRoqW3UdeNT1vGfVbxAGhwU5qhD
-** XPUB (m/48'/0'/0'/1'): xpub6F9TfWTFcMYy5Ycd2ka2az1brJj78J2isLAWptZnCpFsesss5sZv5B8xsgt71ZXfhDWhUtf4vng4zY6HUVrQbDMPDYRLYvFFoLnAYfzgYPH
+** MASTER_KEY_FINGERPRINT: 887d1ce9
+** PRIVATE_KEY (m/48'/0'/0'/1'): L384ku43jpVYKWWaD1nxRifALPNXyHL3hWNtThByByP5ZMQxs427
+** XPUB (m/48'/0'/0'/1'): xpub6Eof6ipAiAqiGdnFdoKA4nJv19rQwR1NFCKWvjpcNeB3ZyLPHBek9rotgxCKyGn8CumDagZzTXwHaAyZPxQujRZVTDP3KmpceWZHiwe4bZP
 ** Legacy signature
 ** <tt>signer_3_key.bsms</tt>:
 <pre>BSMS 1.0
-163fd307195982c4c39d50bb
-[614cbf5f/48'/0'/0'/1']xpub6F9TfWTFcMYy5Ycd2ka2az1brJj78J2isLAWptZnCpFsesss5sZv5B8xsgt71ZXfhDWhUtf4vng4zY6HUVrQbDMPDYRLYvFFoLnAYfzgYPH
+70d41aaf4c4561c19205d819
+[887d1ce9/48'/0'/0'/1']xpub6Eof6ipAiAqiGdnFdoKA4nJv19rQwR1NFCKWvjpcNeB3ZyLPHBek9rotgxCKyGn8CumDagZzTXwHaAyZPxQujRZVTDP3KmpceWZHiwe4bZP
 Signer 3 key
-H0jf2JMtke5zDDIWys6fihOCA6QBmC5+hbgVB/c2mMPNPLB6tDXt0TFZU1f9wvaCR9762anKSc8CCqXLogw8V00=</pre>
+ICQQ5vlCvv8+6z+peuvKTtSRRs7rodHmfcDQZkArxr5DQ8PkHvjIA92y6FrGCUDG0ruO46qYiFTeRUi0HCX8CcU=</pre>
 
 * Signer 3 encryption
-** HMAC_KEY (hex): 1f51ea067c121e2f86af5e1d484905046bc63e861573157d8b1ae9e7e47e224b
-** MAC (hex): 1a5624fcb39cebabb6174456173eec19b756bc916cf2c9d815e9bcce070898c4
-** IV (hex) : 1a5624fcb39cebabb6174456173eec19
-** CIPHERTEXT (hex): 48d6e139bdc8c19e93cbbf5b4478340c8cf08aa91c28803084d5f58618773f7e615e0134492b496c4e7c130351c0350701f686918033f621378552d7040efedd5539d38c258bf936475de775f23da3953fe3ba5bbbd24816b8902b87a9a09700c446b085119dedee2395dd69665e742f72f2fb6da4ebe3f4704eaf45486fbfb84d764b718cc0b756e72f72ab6069d47765bdd3ebd4074af4fa99a95691a659675ce5f72235c28ddf3c3d53179e598cddc967fc896adc6e97edeeffc85b9e44611df748d923ff3dd921ad4d6e98e0de12359a37558e326faf585ba57e73ab45bc4a49f6e8a756f365f5d204e70f7c7bed269e81e9524a41e5d4cbaad0b6b442d6eea1e5da1ca345cc665a0cffe2c3
-** <tt>signer_3_key.dat</tt>: <pre>1a5624fcb39cebabb6174456173eec19b756bc916cf2c9d815e9bcce070898c448d6e139bdc8c19e93cbbf5b4478340c8cf08aa91c28803084d5f58618773f7e615e0134492b496c4e7c130351c0350701f686918033f621378552d7040efedd5539d38c258bf936475de775f23da3953fe3ba5bbbd24816b8902b87a9a09700c446b085119dedee2395dd69665e742f72f2fb6da4ebe3f4704eaf45486fbfb84d764b718cc0b756e72f72ab6069d47765bdd3ebd4074af4fa99a95691a659675ce5f72235c28ddf3c3d53179e598cddc967fc896adc6e97edeeffc85b9e44611df748d923ff3dd921ad4d6e98e0de12359a37558e326faf585ba57e73ab45bc4a49f6e8a756f365f5d204e70f7c7bed269e81e9524a41e5d4cbaad0b6b442d6eea1e5da1ca345cc665a0cffe2c3</pre>
+** HMAC_KEY (hex): 52f0fc79116014738144d4e04d88d581267f15f004c29492ea65f05b7489ce66
+** MAC (hex): 9240bac748bbc04138e20b0efb11655fdaa2067897bb375f0c274c9e6b168cba
+** IV (hex) : 9240bac748bbc04138e20b0efb11655f
+** CIPHERTEXT (hex): ba8953cbfa0ccf4c5aaa1c35981876c050401b37e05f1d9f4464f85ded7a5aae35aab218970413e4937daea6e44e89b8e61b04e0524b214f33d6cae4c24b729d8447de4b9f0296a4b37149e3000e9990c82c7d3691bcc9fee76d0334bf9325acb0f84644e2749a292f84d7e5c4ad985559fcd64c188b385cac3e833ec71d530af690894afab7d4122f98e912e8f4dee561f6d50e48e6c0f9761f1474eef2bea5a1c0fde11e8fd0992fe17a2e5c1a80a558c3cb98eb19946b87ebbada192d671a629dde718a3800124f64d747d3a1b5613566706e44ab4634489d77f09951d488590b6b887dda54bf5605da457f6f79a12ebebfc1925dfd2d9d67cd328d1c0dd7ef9eba21c7b1ceda2208effa779a
+** <tt>signer_3_key.dat</tt>: <pre>9240bac748bbc04138e20b0efb11655fdaa2067897bb375f0c274c9e6b168cbaba8953cbfa0ccf4c5aaa1c35981876c050401b37e05f1d9f4464f85ded7a5aae35aab218970413e4937daea6e44e89b8e61b04e0524b214f33d6cae4c24b729d8447de4b9f0296a4b37149e3000e9990c82c7d3691bcc9fee76d0334bf9325acb0f84644e2749a292f84d7e5c4ad985559fcd64c188b385cac3e833ec71d530af690894afab7d4122f98e912e8f4dee561f6d50e48e6c0f9761f1474eef2bea5a1c0fde11e8fd0992fe17a2e5c1a80a558c3cb98eb19946b87ebbada192d671a629dde718a3800124f64d747d3a1b5613566706e44ab4634489d77f09951d488590b6b887dda54bf5605da457f6f79a12ebebfc1925dfd2d9d67cd328d1c0dd7ef9eba21c7b1ceda2208effa779a</pre>
 
 ====ROUND 2====
 * Coordinator
 ** <tt>my_multisig_wallet.bsms</tt>:
 <pre>BSMS 1.0
+sh(wsh(multi(2,[1af5fed9/48'/0'/0'/1']xpub6Dk872oqUVGBi8rUjch8SBmvjYcXe4Ege93fsZ4utmZmyVgtjYiRqnvdUX3L8TfRdbPGXPuB8F7dBvecsgC75oSzCje9824wMtM4R3qDtoZ/*,[bbe4987a/48'/0'/0'/1']xpub6EC1EmDURTiXqb4FCmANE1u5jybxqv8qyxXp6JKVJQTzGaF4JWzPhASkHb9RUuHS7hEKZ3iouARzCrhG3E6SauuefL1LrLoAtKHvmDJ1JFK/*,[887d1ce9/48'/0'/0'/1']xpub6Eof6ipAiAqiGdnFdoKA4nJv19rQwR1NFCKWvjpcNeB3ZyLPHBek9rotgxCKyGn8CumDagZzTXwHaAyZPxQujRZVTDP3KmpceWZHiwe4bZP/*)))#uf57h08d
 /0/*,/1/*
-sh(wsh(multi(2,[110dc257/48'/0'/0'/1']xpub6EPQbDFezXYvVFHqnc8R7QUSE8hTepbyCXU7jJBT4dVm2rQHe1i6isqoj59qhyBiCdKquo6QsgMZNHvEz3BM4cNSszF25siTqLUCznBm8vk/*,[5c890401/48'/0'/0'/1']xpub6EW1SmjSXq9YwVwcan5qWEncgx89SozMvGNpYF6hfZHYNTikNZ4gsXuVhHTi6xYJCkmY4X4wpPPS5Gr7aY39dVJMS2TGfihr25oaspKtU8q/*,[614cbf5f/48'/0'/0'/1']xpub6F9TfWTFcMYy5Ycd2ka2az1brJj78J2isLAWptZnCpFsesss5sZv5B8xsgt71ZXfhDWhUtf4vng4zY6HUVrQbDMPDYRLYvFFoLnAYfzgYPH/*)))#j3ykhz7f</pre>
+3ApQjkfMvzZiWxpdJeNex4c71aWjHyMkPk</pre>
 
 * Send to Signer 1:
-** HMAC_KEY (hex): f43c359a4b3d7b2e01be73c54519b12545ca9a23a86f824aadf577b314a7caa7
-** MAC (hex): ee74a0f50943d7d1b65270028bb05133e87c832cdc1ef0a07c79db2093ca3432
-** IV (hex) : ee74a0f50943d7d1b65270028bb05133
-** CIPHERTEXT (hex): 8e3ba3dac0f979fad0d160bd00c8294ff1726d51b95ff3e1534e5a1900f3d7cd4f6d929985a94b9da2c11e4e0f7770cc53c6739fd099477323bd26a3eca9c8016e79848d15e274463424b8355cd73cced61f1816ac8bac87f8c650ee9052f50e347c52ad24b00794a9d5523714be2fdcf731f14b7a8d7c93eab44c258e1c417d2837b9676832e8ce7239dc28b4e1166803209947b8a875a99b9478ee94f7bc17399e886179ab2a0285dc11a3883f6fa439d0f2277dadbec8c355c379fc50e945897e1a738f6a55b09f6b8b6bdf6d4bc248219cbad3662a78a2f539c989e055e00b8efd42fbff978e1a5cc10f83df56117ece4d17f94a0a6d3803778ed53531419250c5a0fff6cad4ab401468dd054915b068cc8826ae1308a71b38060d68c9248d59eea11c2c52a66d5f6bc0d7ae6cb44305c36e56068456d293b70037902e7b05a3ee0af710201128dffc0c16c3306b66bd19b9ae5b91aded35ef33f07743e5b185a9f88a5c67d40270e3bbcf592167ceaf82ead693728d5129b50075edd5ce24863f3484b4b063599ed1327e1c87d0a2051fed3b1234a702722b686e4c9392a403b79726800dd6b691e516e44d9e836c190b10cf2bb262bba98293c97f2c323e59acd0a1f988c5
-** <tt>my_multisig_wallet_for_signer_1.dat</tt>: <pre>ee74a0f50943d7d1b65270028bb05133e87c832cdc1ef0a07c79db2093ca34328e3ba3dac0f979fad0d160bd00c8294ff1726d51b95ff3e1534e5a1900f3d7cd4f6d929985a94b9da2c11e4e0f7770cc53c6739fd099477323bd26a3eca9c8016e79848d15e274463424b8355cd73cced61f1816ac8bac87f8c650ee9052f50e347c52ad24b00794a9d5523714be2fdcf731f14b7a8d7c93eab44c258e1c417d2837b9676832e8ce7239dc28b4e1166803209947b8a875a99b9478ee94f7bc17399e886179ab2a0285dc11a3883f6fa439d0f2277dadbec8c355c379fc50e945897e1a738f6a55b09f6b8b6bdf6d4bc248219cbad3662a78a2f539c989e055e00b8efd42fbff978e1a5cc10f83df56117ece4d17f94a0a6d3803778ed53531419250c5a0fff6cad4ab401468dd054915b068cc8826ae1308a71b38060d68c9248d59eea11c2c52a66d5f6bc0d7ae6cb44305c36e56068456d293b70037902e7b05a3ee0af710201128dffc0c16c3306b66bd19b9ae5b91aded35ef33f07743e5b185a9f88a5c67d40270e3bbcf592167ceaf82ead693728d5129b50075edd5ce24863f3484b4b063599ed1327e1c87d0a2051fed3b1234a702722b686e4c9392a403b79726800dd6b691e516e44d9e836c190b10cf2bb262bba98293c97f2c323e59acd0a1f988c5</pre>
+** HMAC_KEY (hex): c9d881d28107d51c05b5c4252de0afac9dcfbe056f78ae690fc1cfed2a39d17c
+** MAC (hex): b432a7312b64b561592876cb0d63ec5d2f3fb9b24fe0fd6200a4733f4cb0fa2b
+** IV (hex) : b432a7312b64b561592876cb0d63ec5d
+** CIPHERTEXT (hex): 8893171bdfb77c6cd603a2b659832bfef3d7b5f94bfd4a513a91d0abe4d2a81410108a08a9621ecd50c8e8c7b1849c66b88198e683072052dc9f4ac8b769c2390a753404e5c9ad446a757822c788fe52762c176dc0e721503c58fe0207b961693a7cf5f83ff1c1f5307b28ffc6827437560ef7d1d93e9700098488c7cc2b5b607481ae0d5ab063c5dd2ca3af3f198520f7e49b026236978ac1059fd88ce0b297b82600d049d8e35a355fc413d1b216baf7999db4506cb1f024efe7d08e45fde486d7f9b6950d4c03f45a93c99b1d8f5f7a17d13551373032a498bf8e1402f2c02bc462ff9a1ad0e9c3d8360ae3edba0d0f7a9c27a27ea5ab8b755b080dd30e4563f2905dfe3a26db66ac81daa4e8d37cc49ddf7a82d9cec622b81ce56db7baa7e9143a1d1a6ffef2a2d1fc96888897defa2de7d1c36a6acc42eaae4646f5c612296970f8f8529cfa4e494471c5d3748e6885d800f6e2bcd4d40dd665eda4febffe50e2e39fc6b92c70888aa1bd74bf4fc4fcc2fd995a2a823a739c6c366b681de30bb7431f6ad20861da415277f189a6b3d71ee99803115c48ae54b32d4b4c3d50cccd09e658289685bf2c11e3198845236db612849c60032fae9b697c184ffa0b693e16d255c2c9a785e27a42a4e22c5d0deb9bf7665487ca69a021284e26bc662ac398f126982f79adb0
+** <tt>my_multisig_wallet_for_signer_1.dat</tt>: <pre>b432a7312b64b561592876cb0d63ec5d2f3fb9b24fe0fd6200a4733f4cb0fa2b8893171bdfb77c6cd603a2b659832bfef3d7b5f94bfd4a513a91d0abe4d2a81410108a08a9621ecd50c8e8c7b1849c66b88198e683072052dc9f4ac8b769c2390a753404e5c9ad446a757822c788fe52762c176dc0e721503c58fe0207b961693a7cf5f83ff1c1f5307b28ffc6827437560ef7d1d93e9700098488c7cc2b5b607481ae0d5ab063c5dd2ca3af3f198520f7e49b026236978ac1059fd88ce0b297b82600d049d8e35a355fc413d1b216baf7999db4506cb1f024efe7d08e45fde486d7f9b6950d4c03f45a93c99b1d8f5f7a17d13551373032a498bf8e1402f2c02bc462ff9a1ad0e9c3d8360ae3edba0d0f7a9c27a27ea5ab8b755b080dd30e4563f2905dfe3a26db66ac81daa4e8d37cc49ddf7a82d9cec622b81ce56db7baa7e9143a1d1a6ffef2a2d1fc96888897defa2de7d1c36a6acc42eaae4646f5c612296970f8f8529cfa4e494471c5d3748e6885d800f6e2bcd4d40dd665eda4febffe50e2e39fc6b92c70888aa1bd74bf4fc4fcc2fd995a2a823a739c6c366b681de30bb7431f6ad20861da415277f189a6b3d71ee99803115c48ae54b32d4b4c3d50cccd09e658289685bf2c11e3198845236db612849c60032fae9b697c184ffa0b693e16d255c2c9a785e27a42a4e22c5d0deb9bf7665487ca69a021284e26bc662ac398f126982f79adb0</pre>
 
 * Send to Signer 2:
-** HMAC_KEY (hex): e0a20b5f5285fbaa35aad08fb70f5626c9abbe1b384a4950735b28aca6325ff2
-** MAC (hex): 81df9e064f1de1d5f754c4e20f9286f9d81b856d3965677a9f2430cb9297ad1f
-** IV (hex) : 81df9e064f1de1d5f754c4e20f9286f9
-** CIPHERTEXT (hex): dcd82038ef627d6cb2deb62d04c4ccbaa3a354633d960e46312c22791f039f23fd9782a1e3a63504c1e5b3a0770bb8d32fdf168738b6c03278f1391dd5d01e9aafee7be2c8136ee018feff6fc8cdb926df13a36e115ddca8254934f56b7f700768c94cb8388a8297834de9affcd959417ae3d6ec3251387904f50f51f06306cc4d36eefc51418dd3b2c5454910a23ec67a40a3b918d2a740e812929aae949d8dde2c41cbbb3a2b7c2103788421c147f4794d6a26947c15ef4a99ceb825d0c5aaa78b8737d0ef712ba8e269a9941b1af5d217dcdd9cd06727fbdc70fabe3f5a8c09acff4e76992be7f27c6b12ca84739f62a6da86e5b79103d632c0dc8ab3f91fddb3cfbe67084dc4b861c4ac7c86fb171a058c98c67cffdc40ff17ae1533361cc6fb7b63657af0408cf30bf9d6d97aaacf9d3ff443eee61f207228cd91769ce83a0709c1be1847884c6a8fdc86ede66aef8e34fc509c49edf30f743bdc8f9052961ee340924ec2d1caadc6fd286bb3e233c153cd08c1934127752dc28e0d12efa92a050c4061653edb1cbf2fd4b2ba4e038f0b44f5735f198e92571c029156f65f534bfc149f38d611829901372cfc0176b9d2f9ac6512b7f37941a02dff701df0bceadaacfc6935
-** <tt>my_multisig_wallet_for_signer_2.dat</tt>: <pre>81df9e064f1de1d5f754c4e20f9286f9d81b856d3965677a9f2430cb9297ad1fdcd82038ef627d6cb2deb62d04c4ccbaa3a354633d960e46312c22791f039f23fd9782a1e3a63504c1e5b3a0770bb8d32fdf168738b6c03278f1391dd5d01e9aafee7be2c8136ee018feff6fc8cdb926df13a36e115ddca8254934f56b7f700768c94cb8388a8297834de9affcd959417ae3d6ec3251387904f50f51f06306cc4d36eefc51418dd3b2c5454910a23ec67a40a3b918d2a740e812929aae949d8dde2c41cbbb3a2b7c2103788421c147f4794d6a26947c15ef4a99ceb825d0c5aaa78b8737d0ef712ba8e269a9941b1af5d217dcdd9cd06727fbdc70fabe3f5a8c09acff4e76992be7f27c6b12ca84739f62a6da86e5b79103d632c0dc8ab3f91fddb3cfbe67084dc4b861c4ac7c86fb171a058c98c67cffdc40ff17ae1533361cc6fb7b63657af0408cf30bf9d6d97aaacf9d3ff443eee61f207228cd91769ce83a0709c1be1847884c6a8fdc86ede66aef8e34fc509c49edf30f743bdc8f9052961ee340924ec2d1caadc6fd286bb3e233c153cd08c1934127752dc28e0d12efa92a050c4061653edb1cbf2fd4b2ba4e038f0b44f5735f198e92571c029156f65f534bfc149f38d611829901372cfc0176b9d2f9ac6512b7f37941a02dff701df0bceadaacfc6935</pre>
+** HMAC_KEY (hex): 8050b80716db042130c7aaf086a0b3e59d8d3e59c0d689c6b61fb2e5ccd9644b
+** MAC (hex): 116a2bf035dcd99c6e8bb16487ce14028b1824d64968bf0d59abeb4a34f703bd
+** IV (hex) : 116a2bf035dcd99c6e8bb16487ce1402
+** CIPHERTEXT (hex): 90dcbe85cff4475cad3aff55e59f15411fa343fb12e71a06b8d048f41121af1a16385e85be34785f6c1dcd62f0d5460824dcd4a4e2089c3869fb4c563d8dfd9d69d03c9140062aee3c6dd2de3c3f31a4852edd319b0d3357d1a3ccb62a1907aa787d34e2bd60a6f692a462ab9480255a2b5462fc6b6b95e41dc66873d78c7a3585f75f25100a8a3092bd3d9d655deb4d6a0d2c1b0e74e5631a5089f87334bfc5570d2d9f5d53bd0e5c3bb97bf27fb251f409b0b20617919c7164a10d244258b76bb9d9c51f6f89431dea437e2af0998f9c2d94f5d2d79915fb3439fd9077ed5af84772b17789cbb359c8092048999969020c3f9b6600239ed39547d2a71a36f0e06f92c89cd1d026a424a148c2aa76ea9451a71a674e15486d66ac35edac83bae49cc452a2c4ecd61d84dddec02a9ad9197a3128cd3f3f02d32f54674ab844c04e15086d9b6f0ae09ec4d66b484a2ddb24ccd8bf6837c25f9ad87a7b4ee6028a8c0ebdd8bfe5eb0be434cfd97a0fd25a8fb0b6d6de3f2a4bda2c511d834e0cf6bc264513d6135e6ec5ce8f017c123f61129f0ffa3531c735a32e87945901ed5efa07e077ba97ddb8a7ef48e653298e45e22d9be6c2662145443e9657e77003a7fb5d28623121b5ff7a2c82dfb92e8b6151539d329cf0ccc5ce0df9064a628f27fd7274f53bdd4191f424f2
+** <tt>my_multisig_wallet_for_signer_2.dat</tt>: <pre>116a2bf035dcd99c6e8bb16487ce14028b1824d64968bf0d59abeb4a34f703bd90dcbe85cff4475cad3aff55e59f15411fa343fb12e71a06b8d048f41121af1a16385e85be34785f6c1dcd62f0d5460824dcd4a4e2089c3869fb4c563d8dfd9d69d03c9140062aee3c6dd2de3c3f31a4852edd319b0d3357d1a3ccb62a1907aa787d34e2bd60a6f692a462ab9480255a2b5462fc6b6b95e41dc66873d78c7a3585f75f25100a8a3092bd3d9d655deb4d6a0d2c1b0e74e5631a5089f87334bfc5570d2d9f5d53bd0e5c3bb97bf27fb251f409b0b20617919c7164a10d244258b76bb9d9c51f6f89431dea437e2af0998f9c2d94f5d2d79915fb3439fd9077ed5af84772b17789cbb359c8092048999969020c3f9b6600239ed39547d2a71a36f0e06f92c89cd1d026a424a148c2aa76ea9451a71a674e15486d66ac35edac83bae49cc452a2c4ecd61d84dddec02a9ad9197a3128cd3f3f02d32f54674ab844c04e15086d9b6f0ae09ec4d66b484a2ddb24ccd8bf6837c25f9ad87a7b4ee6028a8c0ebdd8bfe5eb0be434cfd97a0fd25a8fb0b6d6de3f2a4bda2c511d834e0cf6bc264513d6135e6ec5ce8f017c123f61129f0ffa3531c735a32e87945901ed5efa07e077ba97ddb8a7ef48e653298e45e22d9be6c2662145443e9657e77003a7fb5d28623121b5ff7a2c82dfb92e8b6151539d329cf0ccc5ce0df9064a628f27fd7274f53bdd4191f424f2</pre>
 
 * Send to Signer 3:
-** HMAC_KEY (hex): 1f51ea067c121e2f86af5e1d484905046bc63e861573157d8b1ae9e7e47e224b
-** MAC (hex): 159a91100cacd123480b7d085c8bb32ec8eb06f0391b6dc8fac07ae67eb37b81
-** IV (hex) : 159a91100cacd123480b7d085c8bb32e
-** CIPHERTEXT (hex): c7269d8be21d1cfe172e35aa106760f1fdc929fce19da8fb7f74f759efec1ee02796fb1e8b008cf177f60a2021570f17aeeb41f8636858654082734b90959b98fd08419f901683c4ca3e76b3e482fea4c67162775e0d80bcb45df729f646c1364a3d8a7d1ff961717b00897e877c1c0554d3502942149726806269c546ad2dd34ba286ddf5cd336b83aabf7091fa25e607faf7e54017d84113e1e3ec440b3704addea188b89293469306fc0a98570afdcf269026b2d2e760f466c1f75bcf75fdf030c0a692e5681fd4487e59d6e96451ff5b6b9f2521b8e95e796ef4ab0a917794d91a30fdac7ee9ddbd89d174831bd133ab12a74f52f6283ee2c5fe3d5a957a7c1a15530b2c5224f76d90057dc94f2ee34e28b037ae7f518cc6dfe725cd3e657648de82b200ea77830eb93219f883998d3207a4ef5902d1119b0cde6b364bc1effb86109d9c2babc8ab26dce90329779d8cd0d737e9825a25586aa3c8fa5317e3e433ff235b82f629de0504e3c992f8e8de299f62751bc1fcb2e75e0262c7a27be7068cea69b14f303e97c24b99ed29cae142564e285657704b4c411d0d4f8c58819e2c0e0ffc3667eb5a408aad8a3023a5f00875e7deab95dc365d8757f7b79815a4fd9e6de2b3
-** <tt>my_multisig_wallet_for_signer_3.dat</tt>: <pre>159a91100cacd123480b7d085c8bb32ec8eb06f0391b6dc8fac07ae67eb37b81c7269d8be21d1cfe172e35aa106760f1fdc929fce19da8fb7f74f759efec1ee02796fb1e8b008cf177f60a2021570f17aeeb41f8636858654082734b90959b98fd08419f901683c4ca3e76b3e482fea4c67162775e0d80bcb45df729f646c1364a3d8a7d1ff961717b00897e877c1c0554d3502942149726806269c546ad2dd34ba286ddf5cd336b83aabf7091fa25e607faf7e54017d84113e1e3ec440b3704addea188b89293469306fc0a98570afdcf269026b2d2e760f466c1f75bcf75fdf030c0a692e5681fd4487e59d6e96451ff5b6b9f2521b8e95e796ef4ab0a917794d91a30fdac7ee9ddbd89d174831bd133ab12a74f52f6283ee2c5fe3d5a957a7c1a15530b2c5224f76d90057dc94f2ee34e28b037ae7f518cc6dfe725cd3e657648de82b200ea77830eb93219f883998d3207a4ef5902d1119b0cde6b364bc1effb86109d9c2babc8ab26dce90329779d8cd0d737e9825a25586aa3c8fa5317e3e433ff235b82f629de0504e3c992f8e8de299f62751bc1fcb2e75e0262c7a27be7068cea69b14f303e97c24b99ed29cae142564e285657704b4c411d0d4f8c58819e2c0e0ffc3667eb5a408aad8a3023a5f00875e7deab95dc365d8757f7b79815a4fd9e6de2b3</pre>
+** HMAC_KEY (hex): 52f0fc79116014738144d4e04d88d581267f15f004c29492ea65f05b7489ce66
+** MAC (hex): 6a724e518881d033337d536b4ae08402322da89c6024926d497006edcb44ba3a
+** IV (hex) : 6a724e518881d033337d536b4ae08402
+** CIPHERTEXT (hex): d5d6945f08e994de3cef2737601e2f9640611d58e018594c9e341091e14a7d83f7135b183efba239f2cb052ba6f454ee5b11dd808be6d0e18c0d44c8f8b51acc71300cf46bb0b52244ac0e147e9b1bc756a2760efe3d3c94b76f893f548bf6b44507bb4aef037a676fe66ea2011a7a68bcf9a610b4351c8469c3201f8ffddbb3f67bb90d2fe44668b17be2aa5688a35036d76f61f398527229a3db06abfe97698ef131b3e4feba5da6b80b4b93cbab84b6bbf83d82b4df997b9dc283f748baa1f67937f025c0ca1d8a47049bf39d3fad8dddc08e8e068473739fa7857c992272b5c73ae9ac4a0cbb2aa2a3a9113c5b57522a73e225c210932b5c19e0a2b7f42deebe6f3bd9ed48b8275962cd0ac1917926107e2b937de71d846a5bd87edd22d49a3555ba6506c8a7c49056e722480549e79cdbbd77a792f74a0d67677b9c16f810b35bc07835a32e4000c09564f70c1672b4ac103cb5b4d9a1b484e83486f71e14c52d4a3fdb5c2b9e9a6e94e6fa369e527d97042b03649617609db981dba86735b598e967a0db2f3d73bbfb449b150a741c6dadc31a2308e0128edc587dcdb18d5f362922df8ddb8c0c4dcbe1c7e76617c8114ca37157ed406f6ac1c033a083ac9daabba4fd924de55b91c9decb01b03ce5a272ef0a56c8770ed15398c401dbde7739283c3cf90941f23e
+** <tt>my_multisig_wallet_for_signer_3.dat</tt>: <pre>6a724e518881d033337d536b4ae08402322da89c6024926d497006edcb44ba3ad5d6945f08e994de3cef2737601e2f9640611d58e018594c9e341091e14a7d83f7135b183efba239f2cb052ba6f454ee5b11dd808be6d0e18c0d44c8f8b51acc71300cf46bb0b52244ac0e147e9b1bc756a2760efe3d3c94b76f893f548bf6b44507bb4aef037a676fe66ea2011a7a68bcf9a610b4351c8469c3201f8ffddbb3f67bb90d2fe44668b17be2aa5688a35036d76f61f398527229a3db06abfe97698ef131b3e4feba5da6b80b4b93cbab84b6bbf83d82b4df997b9dc283f748baa1f67937f025c0ca1d8a47049bf39d3fad8dddc08e8e068473739fa7857c992272b5c73ae9ac4a0cbb2aa2a3a9113c5b57522a73e225c210932b5c19e0a2b7f42deebe6f3bd9ed48b8275962cd0ac1917926107e2b937de71d846a5bd87edd22d49a3555ba6506c8a7c49056e722480549e79cdbbd77a792f74a0d67677b9c16f810b35bc07835a32e4000c09564f70c1672b4ac103cb5b4d9a1b484e83486f71e14c52d4a3fdb5c2b9e9a6e94e6fa369e527d97042b03649617609db981dba86735b598e967a0db2f3d73bbfb449b150a741c6dadc31a2308e0128edc587dcdb18d5f362922df8ddb8c0c4dcbe1c7e76617c8114ca37157ed406f6ac1c033a083ac9daabba4fd924de55b91c9decb01b03ce5a272ef0a56c8770ed15398c401dbde7739283c3cf90941f23e</pre>
 
 ==Acknowledgement==
 
-- 
cgit v1.2.3


From 17a5a858e2045c6689a7e2f0cc4b77b90cdcf6f7 Mon Sep 17 00:00:00 2001
From: Hugo Nguyen <hugh.hn@gmail.com>
Date: Mon, 19 Apr 2021 09:03:42 -0700
Subject: introduce descriptor template

---
 bip-hugonguyen-bsms.mediawiki | 24 ++++++++++++++++++++----
 1 file changed, 20 insertions(+), 4 deletions(-)

diff --git a/bip-hugonguyen-bsms.mediawiki b/bip-hugonguyen-bsms.mediawiki
index f3dbb0e..84c5f88 100644
--- a/bip-hugonguyen-bsms.mediawiki
+++ b/bip-hugonguyen-bsms.mediawiki
@@ -87,7 +87,7 @@ The Signer is any software or hardware that controls the private keys and can si
 * The Coordinator verifies that the key records have compatible specification versions.
 * The Coordinator verifies that the included <tt>SIG</tt> is valid given the <tt>KEY</tt>.
 * 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 (<tt>BSMS 1.0</tt> as of this writing). The second line must be the descriptor string plus a <tt>CHECKSUM</tt>, all in one line. The <tt>CHECKSUM</tt> has [https://github.com/bitcoin/bitcoin/blob/master/doc/descriptors.md#checksums BECH32 encoding]. The third line must be a comma-separated list of accepted derivation paths that the Signers can use to generate addresses from the included XPUBs. The paths must start with <tt>/</tt> and use non-hardened derivation. For example, <tt>/0/*</tt> and <tt>/1/*</tt> are some common paths. If there are no restrictions, it must say <tt>No path restrictions</tt>. 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 first line in the descriptor record must be the specification version (<tt>BSMS 1.0</tt> 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 accepted derivation paths, to be applied to the template. The paths must start with <tt>/</tt> and use non-hardened derivation. If there are no template or restrictions, it must say <tt>No path restrictions</tt>. 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 <tt>MAC</tt> for the record. The first 16 bytes of the <tt>MAC</tt> serves as the <tt>IV</tt> for the encryption.. 
 * The Coordinator encrypts the descriptor record with the <tt>ENCRYPTION_KEY</tt> and <tt>IV</tt>.
 * The Coordinator encodes the <tt>MAC</tt> and the ciphertext into hexadecimal format, then concatenates the results: <tt>(MAC || ciphertext)</tt>.
@@ -99,8 +99,7 @@ The Signer is any software or hardware that controls the private keys and can si
 * The Signer extracts the <tt>MAC</tt> from the data, sets <tt>IV</tt> to the first 16 bytes of the <tt>MAC</tt>, then decrypts the ciphertext using the <tt>ENCRYPTION_KEY</tt> (derived from the open session) and <tt>IV</tt>.
 * The Signer verifies that the included <tt>MAC</tt> is valid given the plaintext.
 * The Signer verifies that it can support the included specification version.
-* The Signer verifies the descriptor’s <tt>CHECKSUM</tt>.
-* The Signer verifies that it can support the descriptor.
+* The Signer verifies that it can support the descriptor or descriptor template.
 * The Signer checks that its <tt>KEY</tt> is included in the descriptor, using path and fingerprint information provided. The check must perform an exact match on the <tt>KEY</tt>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 given the descriptor and the path restrictions.
@@ -177,6 +176,23 @@ Encryption helps improve the privacy of the wallet by avoiding sharing XPUBs and
 
 If the parties wish to have stronger privacy, it is recommended to use a higher number of bits for the <tt>TOKEN</tt>, and to completely erase knowledge of the <tt>TOKEN</tt> after the multisig wallet has been set up.
 
+==Descriptor Template==
+The output descriptor language only supports one-dimensional lists. This proposal introduces a descriptor template to represent multi-dimensional lists:
+
+<tt>XPUB/**</tt>
+
+Whereas <tt>**</tt> can be replaced by any number of derivation paths.
+
+If there is a descriptor template in the descriptor record, Signers should expand the template into concrete descriptors by using the derivations paths provided in the record.
+
+For example, the following template and derivation paths:
+* <tt>wsh(sortedmulti(2,XPUB1/**,XPUB2/**))</tt>
+* <tt>/0/*,/1/*</tt>
+
+Should translate to two concrete descriptors:
+* <tt>wsh(sortedmulti(2,XPUB1/0/*,XPUB2/0/*))</tt>
+* <tt>wsh(sortedmulti(2,XPUB1/1/*,XPUB2/1/*))</tt>
+
 ==Test Vectors==
 
 ===Mode: <tt>NO_ENCRYPTION</tt>===
@@ -387,7 +403,7 @@ sh(wsh(multi(2,[1af5fed9/48'/0'/0'/1']xpub6Dk872oqUVGBi8rUjch8SBmvjYcXe4Ege93fsZ
 
 ==Acknowledgement==
 
-Special thanks to Pavol Rusnak, Dmitry Petukhov, Christopher Allen, Craig Raw, Robert Spigler, Gregory Sanders, Ta Tat Tai, Michael Flaxman, Pieter Wuille and others for their feedback on the specification.
+Special thanks to Pavol Rusnak, Dmitry Petukhov, Christopher Allen, Craig Raw, Robert Spigler, Gregory Sanders, Ta Tat Tai, Michael Flaxman, Pieter Wuille, Salvatore Ingala and others for their feedback on the specification.
 
 ==References==
 
-- 
cgit v1.2.3


From 9771c5e2a8a04a68499604d8d2c2f8ac7e8594b4 Mon Sep 17 00:00:00 2001
From: Hugo Nguyen <hugh.hn@gmail.com>
Date: Mon, 19 Apr 2021 09:19:28 -0700
Subject: replace XPUBs with keys to be more generic

---
 bip-hugonguyen-bsms.mediawiki | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/bip-hugonguyen-bsms.mediawiki b/bip-hugonguyen-bsms.mediawiki
index 84c5f88..cf2e9c9 100644
--- a/bip-hugonguyen-bsms.mediawiki
+++ b/bip-hugonguyen-bsms.mediawiki
@@ -55,7 +55,7 @@ The Coordinator initiates the multisig setup. The Coordinator determines what ty
 
 ====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 an Extended Public Key (XPUB) -- to the Coordinator, verifying that its XPUB is included in the descriptor record and persisting the descriptor record in its storage.
+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===
 
@@ -71,8 +71,8 @@ The Signer is any software or hardware that controls the private keys and can si
 =====Signer=====
 
 * The Signer initiates the multisig wallet creation session by setting the <tt>TOKEN</tt>. The Signer derives an <tt>ENCRYPTION_KEY</tt> from the <tt>TOKEN</tt>. The Signer can keep the session open until a different value for the <tt>TOKEN</tt> is set.
-* The Signer generates a key record by prompting the user for a multisig derivation path and retrieves the XPUB 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 XPUBs for different wallets.
-* The first line in the record must be the specification version (<tt>BSMS 1.0</tt> as of this writing). The second line must be the hex-encoded <tt>TOKEN</tt>. The third line must be the <tt>KEY</tt>. The <tt>KEY</tt> is an XPUB plus its key origin information, written in the descriptor-defined format, i.e.: <tt>[{master key fingerprint}/{derivation path}]{XPUB}</tt>. The fourth line is a text description of the key, 80 characters maximum. The fifth line must be a <tt>SIG</tt>, whereas <tt>SIG</tt> is the signature generated by using the private key associated with the 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 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 keys for different wallets.
+* The first line in the record must be the specification version (<tt>BSMS 1.0</tt> as of this writing). The second line must be the hex-encoded <tt>TOKEN</tt>. The third line must be the <tt>KEY</tt>. The <tt>KEY</tt> is a public key or an XPUB plus the key origin information, written in the descriptor-defined format, i.e.: <tt>[{master key fingerprint}/{derivation path}]{KEY}</tt>. The fourth line is a text description of the key, 80 characters maximum. The fifth line must be a <tt>SIG</tt>, whereas <tt>SIG</tt> 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 (<tt>MAC</tt>) for the record. The first 16 bytes of the <tt>MAC</tt> serves as the Initialization Vector (<tt>IV</tt>) for the encryption.
 * The Signer encrypts the key record with the <tt>ENCRYPTION_KEY</tt> and <tt>IV</tt>.
 * The Signer encodes the <tt>MAC</tt> and the ciphertext into hexadecimal format, then concatenates the results: <tt>(MAC || ciphertext)</tt>.
@@ -103,8 +103,8 @@ The Signer is any software or hardware that controls the private keys and can si
 * The Signer checks that its <tt>KEY</tt> is included in the descriptor, using path and fingerprint information provided. The check must perform an exact match on the <tt>KEY</tt>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 given the descriptor and the path restrictions.
-* 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, <tt>M</tt>, <tt>N</tt>, and the position(s) of the Signer's own XPUB in the policy script. The total number of Signers, <tt>N</tt>, is important to prevent a <tt>KEY</tt> insertion attack. The position is important for scripts where key order matters. When applicable, all positions of the XPUB must be displayed. The full descriptor 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).
+* 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, <tt>M</tt>, <tt>N</tt>, and the position(s) of the Signer's own <tt>KEY</tt> in the policy script. The total number of Signers, <tt>N</tt>, is important to prevent a <tt>KEY</tt> insertion attack. The position is important for scripts where <tt>KEY</tt> order matters. When applicable, all positions of the <tt>KEY</tt> must be displayed. The full descriptor 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 <tt>KEY</tt> positions).
 * If all checks pass, the Signer must persist the descriptor record in its storage.
 
 This completes the setup.
@@ -172,7 +172,7 @@ The <tt>TOKEN</tt> is used to encrypt the two rounds of communication between th
 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 XPUBs and descriptors in plaintext.
+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 <tt>TOKEN</tt>, and to completely erase knowledge of the <tt>TOKEN</tt> after the multisig wallet has been set up.
 
@@ -403,7 +403,7 @@ sh(wsh(multi(2,[1af5fed9/48'/0'/0'/1']xpub6Dk872oqUVGBi8rUjch8SBmvjYcXe4Ege93fsZ
 
 ==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 and others for their feedback on the specification.
+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==
 
-- 
cgit v1.2.3


From 3eb481c5519597584fb7a00203d81a6dce41a709 Mon Sep 17 00:00:00 2001
From: Hugo Nguyen <hugh.hn@gmail.com>
Date: Mon, 19 Apr 2021 09:48:59 -0700
Subject: minor edit

---
 bip-hugonguyen-bsms.mediawiki | 34 +++++++++++++++++-----------------
 1 file changed, 17 insertions(+), 17 deletions(-)

diff --git a/bip-hugonguyen-bsms.mediawiki b/bip-hugonguyen-bsms.mediawiki
index cf2e9c9..afa4f47 100644
--- a/bip-hugonguyen-bsms.mediawiki
+++ b/bip-hugonguyen-bsms.mediawiki
@@ -158,6 +158,23 @@ Whereas:
 
 The <tt>MAC</tt> is to be sent along with the key and descriptor record, as specified above. Because it is a <tt>MAC</tt> 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:
+
+<tt>XPUB/**</tt>
+
+Whereas <tt>**</tt> can be replaced by any number of derivation paths.
+
+If there is a descriptor template in the descriptor record, Signers should expand the template into concrete descriptors by using the derivations paths provided in the record.
+
+For example, the following template and derivation paths:
+* <tt>wsh(sortedmulti(2,XPUB1/**,XPUB2/**))</tt>
+* <tt>/0/*,/1/*</tt>
+
+Should translate to two concrete descriptors:
+* <tt>wsh(sortedmulti(2,XPUB1/0/*,XPUB2/0/*))</tt>
+* <tt>wsh(sortedmulti(2,XPUB1/1/*,XPUB2/1/*))</tt>
+
 ==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].
 
@@ -176,23 +193,6 @@ Encryption helps improve the privacy of the wallet by avoiding sharing keys and
 
 If the parties wish to have stronger privacy, it is recommended to use a higher number of bits for the <tt>TOKEN</tt>, and to completely erase knowledge of the <tt>TOKEN</tt> after the multisig wallet has been set up.
 
-==Descriptor Template==
-The output descriptor language only supports one-dimensional lists. This proposal introduces a descriptor template to represent multi-dimensional lists:
-
-<tt>XPUB/**</tt>
-
-Whereas <tt>**</tt> can be replaced by any number of derivation paths.
-
-If there is a descriptor template in the descriptor record, Signers should expand the template into concrete descriptors by using the derivations paths provided in the record.
-
-For example, the following template and derivation paths:
-* <tt>wsh(sortedmulti(2,XPUB1/**,XPUB2/**))</tt>
-* <tt>/0/*,/1/*</tt>
-
-Should translate to two concrete descriptors:
-* <tt>wsh(sortedmulti(2,XPUB1/0/*,XPUB2/0/*))</tt>
-* <tt>wsh(sortedmulti(2,XPUB1/1/*,XPUB2/1/*))</tt>
-
 ==Test Vectors==
 
 ===Mode: <tt>NO_ENCRYPTION</tt>===
-- 
cgit v1.2.3


From d95aa3329d87c1081d0f3ffdd1179f96ead44bdc Mon Sep 17 00:00:00 2001
From: Robert Spigler <RobertSpigler@ProtonMail.ch>
Date: Mon, 19 Apr 2021 18:03:24 -0400
Subject: Update Modern Hierarchy for Deterministic Multisignature
 Wallets.mediawiki

Some minor fixes, address gap fixes, backup clarification
---
 ... Deterministic Multisignature Wallets.mediawiki | 24 ++++++++++++++--------
 1 file changed, 15 insertions(+), 9 deletions(-)

diff --git a/Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki b/Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki
index 0bf6734..391b88a 100644
--- a/Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki	
+++ b/Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki	
@@ -40,7 +40,7 @@ A modern standardization is needed for multisig derivation paths.  There are som
 m / purpose' / cosigner_index / change / address_index
 </pre>
 
-Like BIP44/49/84, BIP45 unecessarily demands a single script type (here, P2SH).  In addition, BIP45 sets <code>cosigner_index</code> in order to sort the <code>purpose'</code> public keys of each cosigner.  This too is redundant, as descriptors can set the order of the public keys with <code>multi</code> or have them sorted lexicographically (as described in [https://github.com/bitcoin/bips/blob/master/bip-0067.mediawiki BIP67]) with <code>sortedmulti</code>.  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.
+BIP45 unecessarily demands a single script type (here, P2SH).  In addition, BIP45 sets <code>cosigner_index</code> in order to sort the <code>purpose'</code> public keys of each cosigner.  This too is redundant, as descriptors can set the order of the public keys with <code>multi</code> or have them sorted lexicographically (as described in [https://github.com/bitcoin/bips/blob/master/bip-0067.mediawiki BIP67]) with <code>sortedmulti</code>.  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:
 
@@ -50,7 +50,7 @@ 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 <code>script_type'</code> 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, <code>script_type</code> list.
 
-The structure proposed later in this paper solves these issues and is quite comprehensive. It allows 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 <ref>'''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. Co-signers in multisignature wallets need to backup all other cosigner public keys anyway in order to restore, so the descriptor provides this information with the benefit of key origin information and error detection.</ref>.
+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 <ref>'''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. Co-signers in multisignature wallets need to backup all other cosigner public keys anyway in order to restore, so the descriptor provides this information with the benefit of key origin information and error detection.</ref>.
 
 Any script that is supported by descriptors (and the specific wallet implementation) is compatible with this BIP.
 
@@ -124,15 +124,21 @@ Public derivation is used at this level.
 
 ==Address Discovery==
 
-The multisig descriptor that is generated from the cosigners' combined key records should be used to generate and discover addresses. For example:
-<code>wsh(sortedmulti(2,[xfpForA/XY'/0'/0']XpubA/*,[xfpForB/XY'/0'/0']XpubB/*))#Checksum</code>
+The multisig descriptors or descriptor template that is generated from the cosigners' combined key records should be used to generate and discover addresses. 
 
-# Derive the external chain node of this account (constant = 0)
-# Scan addresses of the external chain; respect the gap limit described below
+For example:
+
+The following descriptor template and derivation path:
+<code>wsh(sortedmulti(2,[xfpForA/XY'/0'/0']XpubA/**,[xfpForB/XY'/0'/0']XpubB/**))</code>
+<code>/0/*,/1/*</code>
 
-Please note that the algorithm works with the transaction history, not account balances, so you can have an address with 0 total coins and the algorithm will still continue with discovery.
+Expands to the two concrete descriptors:
+<code>wsh(sortedmulti(2,[xfpForA/XY'/0'/0']XpubA/0/*,[xfpForB/XY'/0'/0']XpubB/0/*))#Checksum</code>
+<code>wsh(sortedmulti(2,[xfpForA/XY'/0'/0']XpubA/1/*,[xfpForB/XY'/0'/0']XpubB/1/*))#Checksum</code>
+
+# Scan addresses of the external chain; respect the gap limit described below
 
-The wallet implementation should scan the addresses following the parent descriptor string.
+Note: This therefore necessitates that multisig wallets backup their private key information and their 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 <code>M</code> seeds in any <code>M</code> of <code>N</code> multisig restore operation. The descriptor provides this information in a standardized format, with key origin information and error detection.
 
 ===Address Gap Limit===
 
@@ -244,7 +250,7 @@ None at the moment.
 
 ==Acknowledgement==
 
-Special thanks to SomberNight, Craig Raw, David Harding, Jochen Hoenicke, and others for their feedback on the specification.
+Special thanks to SomberNight, Craig Raw, David Harding, Jochen Hoenicke, Sjors Provoost, and others for their feedback on the specification.
 
 ==References==
 
-- 
cgit v1.2.3


From 25bacdc21d897e289d2d12640b702f83bca59905 Mon Sep 17 00:00:00 2001
From: Robert Spigler <RobertSpigler@ProtonMail.ch>
Date: Mon, 19 Apr 2021 18:08:52 -0400
Subject: Update Modern Hierarchy for Deterministic Multisignature
 Wallets.mediawiki

Fix formatting
---
 Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki b/Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki
index 391b88a..6be0a65 100644
--- a/Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki	
+++ b/Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki	
@@ -129,14 +129,16 @@ The multisig descriptors or descriptor template that is generated from the cosig
 For example:
 
 The following descriptor template and derivation path:
+
 <code>wsh(sortedmulti(2,[xfpForA/XY'/0'/0']XpubA/**,[xfpForB/XY'/0'/0']XpubB/**))</code>
 <code>/0/*,/1/*</code>
 
 Expands to the two concrete descriptors:
+
 <code>wsh(sortedmulti(2,[xfpForA/XY'/0'/0']XpubA/0/*,[xfpForB/XY'/0'/0']XpubB/0/*))#Checksum</code>
 <code>wsh(sortedmulti(2,[xfpForA/XY'/0'/0']XpubA/1/*,[xfpForB/XY'/0'/0']XpubB/1/*))#Checksum</code>
 
-# Scan addresses of the external chain; respect the gap limit described below
+To discover addresses, scan addresses of the external chain; respect the gap limit described below
 
 Note: This therefore necessitates that multisig wallets backup their private key information and their 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 <code>M</code> seeds in any <code>M</code> of <code>N</code> multisig restore operation. The descriptor provides this information in a standardized format, with key origin information and error detection.
 
-- 
cgit v1.2.3


From f18ddfbfa5d44a3f4432844c34b6d954a6a022b7 Mon Sep 17 00:00:00 2001
From: Robert Spigler <RobertSpigler@ProtonMail.ch>
Date: Mon, 19 Apr 2021 18:09:59 -0400
Subject: Update Modern Hierarchy for Deterministic Multisignature
 Wallets.mediawiki

Formatting
---
 Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki b/Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki
index 6be0a65..2783cea 100644
--- a/Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki	
+++ b/Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki	
@@ -131,11 +131,13 @@ For example:
 The following descriptor template and derivation path:
 
 <code>wsh(sortedmulti(2,[xfpForA/XY'/0'/0']XpubA/**,[xfpForB/XY'/0'/0']XpubB/**))</code>
+
 <code>/0/*,/1/*</code>
 
 Expands to the two concrete descriptors:
 
 <code>wsh(sortedmulti(2,[xfpForA/XY'/0'/0']XpubA/0/*,[xfpForB/XY'/0'/0']XpubB/0/*))#Checksum</code>
+
 <code>wsh(sortedmulti(2,[xfpForA/XY'/0'/0']XpubA/1/*,[xfpForB/XY'/0'/0']XpubB/1/*))#Checksum</code>
 
 To discover addresses, scan addresses of the external chain; respect the gap limit described below
-- 
cgit v1.2.3


From ccc8af43b076de2e4ad669ccd58dead4684c6ed2 Mon Sep 17 00:00:00 2001
From: Robert Spigler <RobertSpigler@ProtonMail.ch>
Date: Wed, 21 Apr 2021 15:13:23 -0400
Subject: Address Discovery Fixes

---
 Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki b/Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki
index 2783cea..b607933 100644
--- a/Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki	
+++ b/Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki	
@@ -140,13 +140,13 @@ Expands to the two concrete descriptors:
 
 <code>wsh(sortedmulti(2,[xfpForA/XY'/0'/0']XpubA/1/*,[xfpForB/XY'/0'/0']XpubB/1/*))#Checksum</code>
 
-To discover addresses, scan addresses of the external chain; respect the gap limit described below
+To discover addresses, import both the receiving and change descriptors; respect the gap limit described below.
 
 Note: This therefore necessitates that multisig wallets backup their private key information and their 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 <code>M</code> seeds in any <code>M</code> of <code>N</code> multisig restore operation. The descriptor provides this information in a standardized format, with key origin information and error detection.
 
 ===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. We scan just the external chains, because internal chains receive only coins that come from the associated external chains.
+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 chain by generating a new address.
 
-- 
cgit v1.2.3


From abbb76e987cf0ecba43131a5dfcc98771ea6848f Mon Sep 17 00:00:00 2001
From: Hugo Nguyen <hugh.hn@gmail.com>
Date: Sat, 24 Apr 2021 00:46:24 -0700
Subject: Minor edit

---
 bip-hugonguyen-bsms.mediawiki | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/bip-hugonguyen-bsms.mediawiki b/bip-hugonguyen-bsms.mediawiki
index afa4f47..855c5ed 100644
--- a/bip-hugonguyen-bsms.mediawiki
+++ b/bip-hugonguyen-bsms.mediawiki
@@ -55,7 +55,7 @@ The Coordinator initiates the multisig setup. The Coordinator determines what ty
 
 ====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.
+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 <tt>KEY</tt> is included in the descriptor record and persisting the descriptor record in its storage.
 
 ===Setup Process===
 
@@ -71,7 +71,7 @@ The Signer is any software or hardware that controls the private keys and can si
 =====Signer=====
 
 * The Signer initiates the multisig wallet creation session by setting the <tt>TOKEN</tt>. The Signer derives an <tt>ENCRYPTION_KEY</tt> from the <tt>TOKEN</tt>. The Signer can keep the session open until a different value for the <tt>TOKEN</tt> 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 keys for different wallets.
+* The Signer generates a key record by prompting the user for a multisig derivation path and retrieves the <tt>KEY</tt> 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 <tt>KEY</tt>s for different wallets.
 * The first line in the record must be the specification version (<tt>BSMS 1.0</tt> as of this writing). The second line must be the hex-encoded <tt>TOKEN</tt>. The third line must be the <tt>KEY</tt>. The <tt>KEY</tt> is a public key or an XPUB plus the key origin information, written in the descriptor-defined format, i.e.: <tt>[{master key fingerprint}/{derivation path}]{KEY}</tt>. The fourth line is a text description of the key, 80 characters maximum. The fifth line must be a <tt>SIG</tt>, whereas <tt>SIG</tt> 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 (<tt>MAC</tt>) for the record. The first 16 bytes of the <tt>MAC</tt> serves as the Initialization Vector (<tt>IV</tt>) for the encryption.
 * The Signer encrypts the key record with the <tt>ENCRYPTION_KEY</tt> and <tt>IV</tt>.
@@ -100,10 +100,10 @@ The Signer is any software or hardware that controls the private keys and can si
 * The Signer verifies that the included <tt>MAC</tt> 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 <tt>KEY</tt> is included in the descriptor, using path and fingerprint information provided. The check must perform an exact match on the <tt>KEY</tt>s and not using shortcuts such as matching fingerprints, which is trivial to spoof.
+* The Signer checks that its <tt>KEY</tt> is included in the descriptor or descriptor template, using path and fingerprint information provided. The check must perform an exact match on the <tt>KEY</tt>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 given the descriptor and the path restrictions.
-* 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, <tt>M</tt>, <tt>N</tt>, and the position(s) of the Signer's own <tt>KEY</tt> in the policy script. The total number of Signers, <tt>N</tt>, is important to prevent a <tt>KEY</tt> insertion attack. The position is important for scripts where <tt>KEY</tt> order matters. When applicable, all positions of the <tt>KEY</tt> must be displayed. The full descriptor must also be available for review upon user request. 
+* 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, <tt>M</tt>, <tt>N</tt>, and the position(s) of the Signer's own <tt>KEY</tt> in the policy script. The total number of Signers, <tt>N</tt>, is important to prevent a <tt>KEY</tt> insertion attack. The position is important for scripts where <tt>KEY</tt> order matters. When applicable, all positions of the <tt>KEY</tt> 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 <tt>KEY</tt> positions).
 * If all checks pass, the Signer must persist the descriptor record in its storage.
 
@@ -184,7 +184,7 @@ Also refer to [https://github.com/BlockchainCommons/Research/blob/master/papers/
 
 This proposal introduces two layers of protection. The first one is a temporary, secret <tt>TOKEN</tt>. The second one is the confirmation of the wallet's first address.
 
-The <tt>TOKEN</tt> is used to encrypt the two rounds of communication between the Signer and the Coordinator. A <tt>MAC</tt> is also generated from the <tt>TOKEN</tt> and plaintext to authenticate the data being exchanged. The <tt>TOKEN</tt> is only needed during the setup phase, and can be safely discarded afterwards.
+The <tt>TOKEN</tt> is used to encrypt the two rounds of communication between the Signer and the Coordinator. A <tt>MAC</tt> is also generated from the <tt>TOKEN</tt> and plaintext to authenticate the data being exchanged. The <tt>TOKEN</tt> is only needed during the setup phase, and can be safely discarded afterwards. It is not recommended to use the same <tt>TOKEN</tt> 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.
 
-- 
cgit v1.2.3


From 3ecad81bea81c3be6188139a7318562b9f7797e6 Mon Sep 17 00:00:00 2001
From: Hugo Nguyen <hugh.hn@gmail.com>
Date: Sat, 24 Apr 2021 01:21:19 -0700
Subject: update test vectors

---
 bip-hugonguyen-bsms.mediawiki | 216 +++++++++++++++++++++---------------------
 1 file changed, 108 insertions(+), 108 deletions(-)

diff --git a/bip-hugonguyen-bsms.mediawiki b/bip-hugonguyen-bsms.mediawiki
index 855c5ed..865827a 100644
--- a/bip-hugonguyen-bsms.mediawiki
+++ b/bip-hugonguyen-bsms.mediawiki
@@ -200,206 +200,206 @@ If the parties wish to have stronger privacy, it is recommended to use a higher
 * Coordinator
 ** M-of-N: 2/2
 ** ADDRESS_TYPE: NATIVE_SEGWIT
-** TOKEN: 0
+** TOKEN: 0x00
 
 * Signer 1
-** MASTER_KEY_FINGERPRINT: 00e41fee
-** PRIVATE_KEY (m/48'/0'/0'/2'): Kwm5qHwBJsETapvfzBcdSAE9rU1BMBkC4cEvLAKDDBE9FPCz8ppB
-** XPUB (m/48'/0'/0'/2'): xpub6DrL7eCUEzkd2wy3tJDUKK6MobKt2ijAxUYyAHGVojjUysj5zY2yw8NgpgbLd85EDFSKGXkLL5cdKBJr9rjFvRRagEWWkNKvgFsezSHsPKz
+** MASTER_KEY_FINGERPRINT: 1cf0bf7e
+** PRIVATE_KEY (m/48'/0'/0'/2'): L3q1sg7iso1L3QfzB1riC9bQpqMynWyBeuLLSKwCDGkHkahB7MgU
+** XPUB (m/48'/0'/0'/2'): xpub6FL8FhxNNUVnG64YurPd16AfGyvFLhh7S2uSsDqR3Qfcm6o9jtcMYwh6DvmcBF9qozxNQmTCVvWtxLpKTnhVLN3Pgnu2D3pAoXYFgVyd8Yz
 ** Legacy signature
 ** <tt>signer_1_key.bsms</tt>:
 <pre>BSMS 1.0
 00
-[00e41fee/48'/0'/0'/2']xpub6DrL7eCUEzkd2wy3tJDUKK6MobKt2ijAxUYyAHGVojjUysj5zY2yw8NgpgbLd85EDFSKGXkLL5cdKBJr9rjFvRRagEWWkNKvgFsezSHsPKz
+[1cf0bf7e/48'/0'/0'/2']xpub6FL8FhxNNUVnG64YurPd16AfGyvFLhh7S2uSsDqR3Qfcm6o9jtcMYwh6DvmcBF9qozxNQmTCVvWtxLpKTnhVLN3Pgnu2D3pAoXYFgVyd8Yz
 Signer 1 key
-HzNPcPGSOQLxOX0890nAZmLndSjtz33/Swt9jPtz+K5bLBQXZ1fBPC0y3khgvgD9o9ZSA7hPqxdLUDjPEnMj5UE=</pre>
+IB7v+qi1b+Xrwm/3bF+Rjl8QbIJ/FMQ40kUsOOQo1SqUWn5QlFWbBD8BKPRetfo1L1N7DmYjVscZNsmMrqRJGWw=</pre>
 
 * Signer 2
-** MASTER_KEY_FINGERPRINT: 041a5f9d
-** PRIVATE_KEY (m/48'/0'/0'/2'): KyfXyyvgv5DmaPnnWFsBPann23Rt4ExkgEwL4hR2wHmP1wiRQMWT
-** XPUB (m/48'/0'/0'/2'): xpub6Ep74UnuW7KA8u2zgyAW11BEy9n7aZgcrjZsef65ZjHub8tPh6ZE8YaVNdP5UDQtuqYN7ABbBEde6DBLcv1QQVJdXYfSNwLnvMeqvnDM15b
+** MASTER_KEY_FINGERPRINT: 4fc1dd4a
+** PRIVATE_KEY (m/48'/0'/0'/2'): L4JNkJfLBDyWfTLbKJ1H3w56GUMsvdfjCkzRo5RHXfJ6bdHqm6cN
+** XPUB (m/48'/0'/0'/2'): xpub6EebMbEps7ZcV3FYEnddRsvrFWDrt2tiPmCeM7pPXQEmphvq9ZfJ1LWFUDjf3vxCeBuPrfyGrMazWUsYsetrnHatQZVLJH7LsgCjtMqdzgj
 ** Legacy signature
 ** <tt>signer_2_key.bsms</tt>:
 <pre>BSMS 1.0
 00
-[041a5f9d/48'/0'/0'/2']xpub6Ep74UnuW7KA8u2zgyAW11BEy9n7aZgcrjZsef65ZjHub8tPh6ZE8YaVNdP5UDQtuqYN7ABbBEde6DBLcv1QQVJdXYfSNwLnvMeqvnDM15b
+[4fc1dd4a/48'/0'/0'/2']xpub6EebMbEps7ZcV3FYEnddRsvrFWDrt2tiPmCeM7pPXQEmphvq9ZfJ1LWFUDjf3vxCeBuPrfyGrMazWUsYsetrnHatQZVLJH7LsgCjtMqdzgj
 Signer 2 key
-H2q51+r17NY3oMi7kkuCz6gA3Ze+FtPfOYWcpI03gmYnaJScfXunGwjRSG5WpdBmAEYRH+clVmqeaahsgPccqeo=</pre>
+HzUa4Z76PFHMl54flIIF3XKiHZ+KbWjjxCEG5G3ZqZSqTd6OgTiFFLqq9PXJXdfYm6/cnL8IVWQgjFF9DQhIqQs=</pre>
 
 ====ROUND 2====
 * Coordinator
 ** <tt>my_multisig_wallet.bsms</tt>:
 <pre>BSMS 1.0
-wsh(sortedmulti(2,[00e41fee/48'/0'/0'/2']xpub6DrL7eCUEzkd2wy3tJDUKK6MobKt2ijAxUYyAHGVojjUysj5zY2yw8NgpgbLd85EDFSKGXkLL5cdKBJr9rjFvRRagEWWkNKvgFsezSHsPKz/*,[041a5f9d/48'/0'/0'/2']xpub6Ep74UnuW7KA8u2zgyAW11BEy9n7aZgcrjZsef65ZjHub8tPh6ZE8YaVNdP5UDQtuqYN7ABbBEde6DBLcv1QQVJdXYfSNwLnvMeqvnDM15b/*))#x5ckx6kc
+wsh(sortedmulti(2,[1cf0bf7e/48'/0'/0'/2']xpub6FL8FhxNNUVnG64YurPd16AfGyvFLhh7S2uSsDqR3Qfcm6o9jtcMYwh6DvmcBF9qozxNQmTCVvWtxLpKTnhVLN3Pgnu2D3pAoXYFgVyd8Yz/**,[4fc1dd4a/48'/0'/0'/2']xpub6EebMbEps7ZcV3FYEnddRsvrFWDrt2tiPmCeM7pPXQEmphvq9ZfJ1LWFUDjf3vxCeBuPrfyGrMazWUsYsetrnHatQZVLJH7LsgCjtMqdzgj/**))
 /0/*,/1/*
-bc1qgh7jg86mj7lt2gcd7rqdyz2hx8vj3h60f0plquaqxpcw9efxfaks7yx7y5</pre>
+bc1qrgc6p3kylfztu06ysl752gwwuekhvtfh9vr7zg43jvu60mutamcsv948ej</pre>
 
 ===Mode: <tt>STANDARD</tt> Encryption===
 ====ROUND 1====
 * Coordinator
 ** M-of-N: 2/2
 ** ADDRESS_TYPE: NATIVE_SEGWIT
-** TOKEN (hex): 2c872a7af4b2f520
-*** TOKEN (decimal): 3208579967104513312
-*** TOKEN (mnemonic): clutch deer pact truly consider mosquito
-** ENCRYPTION_KEY (hex): 822d802f4670abbf01fc2b6fe71d9a372bc4e819569154cfc1db4be567a80336
+** TOKEN (hex): a54044308ceac9b7
+*** TOKEN (decimal): 11907592390080907703
+*** TOKEN (mnemonic): pipe acquire around border prosper swift
+** ENCRYPTION_KEY (hex): 7673ffd9efd70336a5442eda0b31457f7b6cdf7b42fe17f274434df55efa9839
 
 * Signer 1
-** MASTER_KEY_FINGERPRINT: 5a2ea679
-** PRIVATE_KEY (m/48'/0'/0'/2'): L1R9BexLnWSbtzdeL9F6GL8w2i4eM3qwvvRL6iXVfVerCG79J9YN
-** XPUB (m/48'/0'/0'/2'): xpub6EbVsEmr7VHTj4GSQJ8J3YuaKthihAg33dodnZ8ocvj9EMNVCBq2dCoMSkSjsshqpKVdBSua5pUaqWTHbNkxVm4f9MDAMY7LE5wsvTctSQP
+** MASTER_KEY_FINGERPRINT: b7868815
+** PRIVATE_KEY (m/48'/0'/0'/2'): KyKvR9kf8r7ZVtdn3kB9ifipr6UKnTNTpWJkGZbHwARDCz5iZ39E
+** XPUB (m/48'/0'/0'/2'): xpub6FA5rfxJc94K1kNtxRby1hoHwi7YDyTWwx1KUR3FwskaF6HzCbZMz3zQwGnCqdiFeMTPV3YneTGS2YQPiuNYsSvtggWWMQpEJD4jXU7ZzEh
 ** Legacy signature
 ** <tt>signer_1_key.bsms</tt>:
 <pre>BSMS 1.0
-2c872a7af4b2f520
-[5a2ea679/48'/0'/0'/2']xpub6EbVsEmr7VHTj4GSQJ8J3YuaKthihAg33dodnZ8ocvj9EMNVCBq2dCoMSkSjsshqpKVdBSua5pUaqWTHbNkxVm4f9MDAMY7LE5wsvTctSQP
+a54044308ceac9b7
+[b7868815/48'/0'/0'/2']xpub6FA5rfxJc94K1kNtxRby1hoHwi7YDyTWwx1KUR3FwskaF6HzCbZMz3zQwGnCqdiFeMTPV3YneTGS2YQPiuNYsSvtggWWMQpEJD4jXU7ZzEh
 Signer 1 key
-IKaOunXsMpnQOuEsbOeD2207uwKAoStp73VS1LeqbGfZQLJPdeQ49rAM/1CLJpUAWO9LUYQKsIu8pB56jjrUOmA=</pre>
+H8DYht5P6ko0bQqDV6MtUxpzBSK+aVHxbvMavA5byvLrOlCEGmO1WFR7k2wu42J6dxXD8vrmDQSnGq5MTMMbZ98=</pre>
 
 * Signer 1 encryption
-** HMAC_KEY (hex): cf629cab57753f5975a8f5b023fa033af66fb104f69245a99dc823f2a0db6791
-** MAC (hex): ac4589ae73e4a5e1459c3087cbcc0db52dd93e8495ca4b410704d9a6ddb2e905
-** IV (hex) : ac4589ae73e4a5e1459c3087cbcc0db5
-** CIPHERTEXT (hex): 2abd1534e395d44047417ede3d4b61fbdc05c948e965b550075d8432ebe9f1b10eb37e69dfd972d8dc944a3a906a8bbcd00551b075eb4556f66f3e809c2798e7c0d8b06675a5c513fc65f9858d97259cc48a3224a23eadb5d7035899bdcbf792f62397fed4ab4a606526c1e40a7edd4a0f3e44470a26d850f64edbca71da6c14aa9e495ae5f9079bac7efb3cf0e4f49f8f7aaac976af42659fbf540c7717c29b7944be27f9bd6023c2c86ff290a6e66d49c627eddd8a5190f2e40d58e8a127e5b95c61fa183ac446619138b233bdec28eda87f5f4c0fc7493d8be924d3f75214c26c774bf21cbf781a44abeca6b984322eaff4ea330f87528d69514d83e816aaea2434bdee15
-** <tt>signer_1_key.dat</tt>: <pre>ac4589ae73e4a5e1459c3087cbcc0db52dd93e8495ca4b410704d9a6ddb2e9052abd1534e395d44047417ede3d4b61fbdc05c948e965b550075d8432ebe9f1b10eb37e69dfd972d8dc944a3a906a8bbcd00551b075eb4556f66f3e809c2798e7c0d8b06675a5c513fc65f9858d97259cc48a3224a23eadb5d7035899bdcbf792f62397fed4ab4a606526c1e40a7edd4a0f3e44470a26d850f64edbca71da6c14aa9e495ae5f9079bac7efb3cf0e4f49f8f7aaac976af42659fbf540c7717c29b7944be27f9bd6023c2c86ff290a6e66d49c627eddd8a5190f2e40d58e8a127e5b95c61fa183ac446619138b233bdec28eda87f5f4c0fc7493d8be924d3f75214c26c774bf21cbf781a44abeca6b984322eaff4ea330f87528d69514d83e816aaea2434bdee15</pre>
+** HMAC_KEY (hex): 3d4c422806ba8964c9ee45070cd675c024d96648a0ddb4001325818c84951de2
+** MAC (hex): fbdbdb64e6a8231c342131d9f13dcd5a954b4c5021658fa5afcb3fc74dc82706
+** IV (hex) : fbdbdb64e6a8231c342131d9f13dcd5a
+** CIPHERTEXT (hex): 53f491cfd1431c292d922ea5a5dec3eb8ddaa6ed38ae109e7b040f0f23013e89a89b4d27476761a01197a3277850b2bc1621ae626efe65f2081eec6eb571c4f787bf1c49d061b43f70fd73cb3f37fa591d2400973ac0644c8941a83f1d4155e98f01fa2fdeb9f86c2e2413154fd18566a28fb0d9d8bd6172efabcfa6dab09ee7029bf3dd43376df52c118a6d291ec168f4ec7f7df951dfc6135fd8cb4b234da62eaea6017dfe5ca418f083e02e3aba2962ba313ba17b6468c7672fb218329a9f3fe4e4887fb87dac57c63ebff0e715a44498d18de8afc10e1cfeb46a1fc65ce871fef8a43b289305433a90c342d025aa4c19454fcfbcf911e9e2f928d5affd0536a6ddc2e816
+** <tt>signer_1_key.dat</tt>: <pre>fbdbdb64e6a8231c342131d9f13dcd5a954b4c5021658fa5afcb3fc74dc8270653f491cfd1431c292d922ea5a5dec3eb8ddaa6ed38ae109e7b040f0f23013e89a89b4d27476761a01197a3277850b2bc1621ae626efe65f2081eec6eb571c4f787bf1c49d061b43f70fd73cb3f37fa591d2400973ac0644c8941a83f1d4155e98f01fa2fdeb9f86c2e2413154fd18566a28fb0d9d8bd6172efabcfa6dab09ee7029bf3dd43376df52c118a6d291ec168f4ec7f7df951dfc6135fd8cb4b234da62eaea6017dfe5ca418f083e02e3aba2962ba313ba17b6468c7672fb218329a9f3fe4e4887fb87dac57c63ebff0e715a44498d18de8afc10e1cfeb46a1fc65ce871fef8a43b289305433a90c342d025aa4c19454fcfbcf911e9e2f928d5affd0536a6ddc2e816</pre>
 
 * Signer 2
-** MASTER_KEY_FINGERPRINT: 21383fe9
-** PRIVATE_KEY (m/48'/0'/0'/2'): KzpgvbUzVeDCn8rdHiSsYWTC75ZrmWK58aJF2dkzdxaBTEwjsgeK
-** XPUB (m/48'/0'/0'/2'): xpub6DqrTSNEY3aVyVxZaxMZvPnERg3NWWPCj4NQYqCDbd4eau2v9yQ81rwnopiMnVVE3YGjNtEZJVRc7YEDY5L3dG1dsgWzvXoE587QA8Dzr1c
+** MASTER_KEY_FINGERPRINT: eedff89a
+** PRIVATE_KEY (m/48'/0'/0'/2'): Kz1ijnkDXmc65NWTYdg47DDaQgSGJAPfhJG9Unm36oqZPpPXuNR6
+** XPUB (m/48'/0'/0'/2'): xpub6EhJvMneoLWAf8cuyLBLQiKiwh89RAmqXEqYeFuaCEHdHwxSRfzLrUxKXEBap7nZSHAYP7Jfq6gZmucotNzpMQ9Sb1nTqerqW8hrtmx6Y6o
 ** Legacy signature
 ** <tt>signer_2_key.bsms</tt>:
 <pre>BSMS 1.0
-2c872a7af4b2f520
-[21383fe9/48'/0'/0'/2']xpub6DqrTSNEY3aVyVxZaxMZvPnERg3NWWPCj4NQYqCDbd4eau2v9yQ81rwnopiMnVVE3YGjNtEZJVRc7YEDY5L3dG1dsgWzvXoE587QA8Dzr1c
+a54044308ceac9b7
+[eedff89a/48'/0'/0'/2']xpub6EhJvMneoLWAf8cuyLBLQiKiwh89RAmqXEqYeFuaCEHdHwxSRfzLrUxKXEBap7nZSHAYP7Jfq6gZmucotNzpMQ9Sb1nTqerqW8hrtmx6Y6o
 Signer 2 key
-H4pj0+/d89BrY4v1mDw+oobMhuJAjiRh/Ia1jSMwoENEao3kyqEcuHgvizOqGo7X0vdwlhQvOYBmjgV5xn2nvgk=</pre>
+H/IHW5dMGYsrRdYEz3ux+kKnkWBtxHzfYkREpnYbco38VnMvIxCbDuf7iu6960qDhBLR/RLjlb9UPtLmCMbczDE=</pre>
 
 * Signer 2 encryption
-** HMAC_KEY (hex): cf629cab57753f5975a8f5b023fa033af66fb104f69245a99dc823f2a0db6791
-** MAC (hex): 8682c41113aa3a5f42891f3dc513dd5d3ee8c817136cfa7998e7917e2b74d801
-** IV (hex) : 8682c41113aa3a5f42891f3dc513dd5d
-** CIPHERTEXT (hex): eff104d3fed1615f39d0a399b399e272b8a15dd74f6d8167555bbdac7787c24d603fc6fc90c7e9049cceb2f48d8f524f4ca284337ca894fff0602e9e42b83a9884159e47c89778ed15dbacc5a73ca16e3cb10e4cfb927f072c7d7dc2bf25311d0ac4541e240bf69bb921cfbb260b2b0adcf4893c3f6693116ef4806bbd9ae47e99eb5e03a6b4502122a5900956785169813190a500ae65c4aa7aea58771a5630b2594fdca09cfd1135ef796da1266b65d40eebfe583595ced217be59ef68534c9d9292f29a7f1e83f57a10e8ec371055e7da05d6b67be29e2d003da406dfdbb0fdef52d0a977fb0050f465338a918d4ea3cfc8669c78708d5eeb30efe3e2ae9a0e72ab7e25bf
-** <tt>signer_2_key.dat</tt>: <pre>8682c41113aa3a5f42891f3dc513dd5d3ee8c817136cfa7998e7917e2b74d801eff104d3fed1615f39d0a399b399e272b8a15dd74f6d8167555bbdac7787c24d603fc6fc90c7e9049cceb2f48d8f524f4ca284337ca894fff0602e9e42b83a9884159e47c89778ed15dbacc5a73ca16e3cb10e4cfb927f072c7d7dc2bf25311d0ac4541e240bf69bb921cfbb260b2b0adcf4893c3f6693116ef4806bbd9ae47e99eb5e03a6b4502122a5900956785169813190a500ae65c4aa7aea58771a5630b2594fdca09cfd1135ef796da1266b65d40eebfe583595ced217be59ef68534c9d9292f29a7f1e83f57a10e8ec371055e7da05d6b67be29e2d003da406dfdbb0fdef52d0a977fb0050f465338a918d4ea3cfc8669c78708d5eeb30efe3e2ae9a0e72ab7e25bf</pre>
+** HMAC_KEY (hex): 3d4c422806ba8964c9ee45070cd675c024d96648a0ddb4001325818c84951de2
+** MAC (hex): 383d05b7351a2cef7cca2850450f5efbbc4a3f8ea35707dda87a3692f0f2ebae
+** IV (hex) : 383d05b7351a2cef7cca2850450f5efb
+** CIPHERTEXT (hex): 71860b7c69f3a7665c3c3e85c45735bff78535a37ec6610b724627c73696820d519a9251703b17626b63898580233bebbb310aedbc370224b044ee19600bfe583445a6f26fb9bb5790bae516892655adb0e5dfc12be4609c2e0818d4f1f3bfccc4cd1a36f419d6cd842c913ae81eef4865ad473c32c3ee69cd98d6d0a088e2abdd01fe68b5c0503bb9183f9a912506204e5a9c6bd5a1626ff7eac30312a0b85004307c525e52fa3ad45a0b02eabc8cfaea0215bb6e60ee5f32d6673955290e008fbaef362977a21fd9830e3a604f9bb318cdcde456eae91dbedaa069bcd1efb0f981d5b0e502bd4dada903205458a00914887226a8dde317c02a8be4342acb97a8fee79fbe23
+** <tt>signer_2_key.dat</tt>: <pre>383d05b7351a2cef7cca2850450f5efbbc4a3f8ea35707dda87a3692f0f2ebae71860b7c69f3a7665c3c3e85c45735bff78535a37ec6610b724627c73696820d519a9251703b17626b63898580233bebbb310aedbc370224b044ee19600bfe583445a6f26fb9bb5790bae516892655adb0e5dfc12be4609c2e0818d4f1f3bfccc4cd1a36f419d6cd842c913ae81eef4865ad473c32c3ee69cd98d6d0a088e2abdd01fe68b5c0503bb9183f9a912506204e5a9c6bd5a1626ff7eac30312a0b85004307c525e52fa3ad45a0b02eabc8cfaea0215bb6e60ee5f32d6673955290e008fbaef362977a21fd9830e3a604f9bb318cdcde456eae91dbedaa069bcd1efb0f981d5b0e502bd4dada903205458a00914887226a8dde317c02a8be4342acb97a8fee79fbe23</pre>
 
 ====ROUND 2====
 *Coordinator
 ** <tt>my_multisig_wallet.bsms</tt>:
 <pre>BSMS 1.0
-wsh(sortedmulti(2,[5a2ea679/48'/0'/0'/2']xpub6EbVsEmr7VHTj4GSQJ8J3YuaKthihAg33dodnZ8ocvj9EMNVCBq2dCoMSkSjsshqpKVdBSua5pUaqWTHbNkxVm4f9MDAMY7LE5wsvTctSQP/*,[21383fe9/48'/0'/0'/2']xpub6DqrTSNEY3aVyVxZaxMZvPnERg3NWWPCj4NQYqCDbd4eau2v9yQ81rwnopiMnVVE3YGjNtEZJVRc7YEDY5L3dG1dsgWzvXoE587QA8Dzr1c/*))#lfv5nh7v
+wsh(sortedmulti(2,[b7868815/48'/0'/0'/2']xpub6FA5rfxJc94K1kNtxRby1hoHwi7YDyTWwx1KUR3FwskaF6HzCbZMz3zQwGnCqdiFeMTPV3YneTGS2YQPiuNYsSvtggWWMQpEJD4jXU7ZzEh/**,[eedff89a/48'/0'/0'/2']xpub6EhJvMneoLWAf8cuyLBLQiKiwh89RAmqXEqYeFuaCEHdHwxSRfzLrUxKXEBap7nZSHAYP7Jfq6gZmucotNzpMQ9Sb1nTqerqW8hrtmx6Y6o/**))
 /0/*,/1/*
-bc1qr3cmly26qp4elq6dhp6zm4fe7sw46w8fqe6ut4cp6e6zckewx7eqmqjk3r</pre>
+bc1qhs4u273g4azq7kqqpe6vh5wfhasfmrq7nheyzsnq77humd7rwtkqagvakf</pre>
 
 *Coordinator encryption
-** HMAC_KEY (hex): cf629cab57753f5975a8f5b023fa033af66fb104f69245a99dc823f2a0db6791
-** MAC (hex): 34a56c778bb14b3625637ab4290c1b3b5fb3f7e20d2fba4052643cc6cdcd2fc5
-** IV (hex) : 34a56c778bb14b3625637ab4290c1b3b
-** CIPHERTEXT (hex): 0a94b74762223a31c29ba343d47f563d5ed7f464afc62ca1dc332ba0eed1c06cf02462acfeed0d2fe4013e6c6693aae56fe9f0cb85db81b7bc46c219f942ed23ec8a326b1d8323e43f67f61dc5f3032e58216c6ce2923839feb4068506c978fd33c83be01fcfd033954228bf64dd97631715508adbb02e7176b7d90992b819a71c29b7b3288672ce64ff28d881eb994327e783f1895a157d7decfb6d048b4b3eb442ca618d0550f98b1d1251877332b0c5ea27e2c72d7fa948ba0fdb6fdc956a59e7a00f020ef78e8638c39f29c287ea5fdfd2d3cf5ac2dca51597284052e2bad6290a4d422a15e7b43d09e9a368cc9268fce3eab49632aee80679228bdee3914ece509e638949215d2d3ad6392b5927bdc7c8f8d664c7d1e8d9adaa0bb35fbd86bd9082ca2d53b0922a1871c9deda2ea86dedc0269bea6f8d29cb989e4df277dadf5da2d41668c585f8b219cda52e537ee31b9b896b6fb6fe47de6859c1dfc7d652fc7c65f99598500ab4aeb27973996ac528fcfccd76c0dee1d8e83b8099aa
-** <tt>my_multisig_wallet.dat</tt>: <pre>34a56c778bb14b3625637ab4290c1b3b5fb3f7e20d2fba4052643cc6cdcd2fc50a94b74762223a31c29ba343d47f563d5ed7f464afc62ca1dc332ba0eed1c06cf02462acfeed0d2fe4013e6c6693aae56fe9f0cb85db81b7bc46c219f942ed23ec8a326b1d8323e43f67f61dc5f3032e58216c6ce2923839feb4068506c978fd33c83be01fcfd033954228bf64dd97631715508adbb02e7176b7d90992b819a71c29b7b3288672ce64ff28d881eb994327e783f1895a157d7decfb6d048b4b3eb442ca618d0550f98b1d1251877332b0c5ea27e2c72d7fa948ba0fdb6fdc956a59e7a00f020ef78e8638c39f29c287ea5fdfd2d3cf5ac2dca51597284052e2bad6290a4d422a15e7b43d09e9a368cc9268fce3eab49632aee80679228bdee3914ece509e638949215d2d3ad6392b5927bdc7c8f8d664c7d1e8d9adaa0bb35fbd86bd9082ca2d53b0922a1871c9deda2ea86dedc0269bea6f8d29cb989e4df277dadf5da2d41668c585f8b219cda52e537ee31b9b896b6fb6fe47de6859c1dfc7d652fc7c65f99598500ab4aeb27973996ac528fcfccd76c0dee1d8e83b8099aa</pre>
+** HMAC_KEY (hex): 3d4c422806ba8964c9ee45070cd675c024d96648a0ddb4001325818c84951de2
+** MAC (hex): 734ce791b466861945e1ef6f74c63faec590793de54831f0036b28d08714b71a
+** IV (hex) : 734ce791b466861945e1ef6f74c63fae
+** CIPHERTEXT (hex): 273cad18a5e1eff37dba6d850749594c9a3fd32b2069e8c69983ea269c5044b6bcaea26d9dbc8ad5d28bb8abfa02e3bfc7632fcc5c2b76e9abb1982ff11295858cfe44a8b97110ae970f58fff3fb6477f38ca9609eec78eedb1d640eaba489fd5e41e787b8d0bde48f1fa99cca641cabbee0f513fb1040cb73df10a57c9a34e4efcb069cd4c75467442c15d878ed9f40e3dffb98294931a6da4f444ae46f739b7fe002ce19fcfe71b05b9783d797ba45d568febbc8a2b0850da67f349d8567342352e1712c3d2a7ea1b2721df5efdb844431f0e5dcfa4acacb194c20785c9bb6dde90d64352fc913e9073b3b416be713bcc7632c821bbfddafa6199d471c54fb899f347f5fc706787ccaa82332dc8b93aeb3de3497d8e5c75f0f5d718c74bc6f8194fe999948e517f1c98398d9cb907d200f1d045394704b074dfb10e587f54fd78e95ef4bcbe77bf1376b390c3f47c91c12b2ed14073ea56bceab41f924302e62183c456b06d96b3da30439cb4320c764a0d6d1b3dabc06fc
+** <tt>my_multisig_wallet.dat</tt>: <pre>734ce791b466861945e1ef6f74c63faec590793de54831f0036b28d08714b71a273cad18a5e1eff37dba6d850749594c9a3fd32b2069e8c69983ea269c5044b6bcaea26d9dbc8ad5d28bb8abfa02e3bfc7632fcc5c2b76e9abb1982ff11295858cfe44a8b97110ae970f58fff3fb6477f38ca9609eec78eedb1d640eaba489fd5e41e787b8d0bde48f1fa99cca641cabbee0f513fb1040cb73df10a57c9a34e4efcb069cd4c75467442c15d878ed9f40e3dffb98294931a6da4f444ae46f739b7fe002ce19fcfe71b05b9783d797ba45d568febbc8a2b0850da67f349d8567342352e1712c3d2a7ea1b2721df5efdb844431f0e5dcfa4acacb194c20785c9bb6dde90d64352fc913e9073b3b416be713bcc7632c821bbfddafa6199d471c54fb899f347f5fc706787ccaa82332dc8b93aeb3de3497d8e5c75f0f5d718c74bc6f8194fe999948e517f1c98398d9cb907d200f1d045394704b074dfb10e587f54fd78e95ef4bcbe77bf1376b390c3f47c91c12b2ed14073ea56bceab41f924302e62183c456b06d96b3da30439cb4320c764a0d6d1b3dabc06fc</pre>
 
 ===Mode: <tt>EXTENDED</tt> Encryption===
 ====ROUND 1====
 *Coordinator
 ** M-of-N: 2/3
 ** ADDRESS_TYPE: NESTED_SEGWIT
-** TOKEN for Signer 1 (hex): 3e4e9f4a9bab074a1416b506
-*** TOKEN (decimal): 19283119055400240376301663494
-*** TOKEN (mnemonic): dinner insane sport dance race pink expect stove alcohol
-*** ENCRYPTION_KEY (hex): 06eb820f8343d941740e3f960c4df2ace84026abc3c1faca5ca487974341ccc0
-** TOKEN for Signer 2 (hex): 4c6d6215d13f7a1e9183f810
-*** TOKEN (decimal): 23653096855135070925426522128
-*** TOKEN (mnemonic): erase help lyrics pen waste aunt ecology lecture awkward
-*** ENCRYPTION_KEY (hex): f5d79f32ad11cec172e088ab84bbfbea65790c9a5f7292912edc2ca42c6bfd1d
-** TOKEN for Signer 3 (hex): 70d41aaf4c4561c19205d819
-*** TOKEN (decimal): 34918739388953622996442273817
-*** TOKEN (mnemonic): ignore patch profit obtain figure this elite roast book
-*** ENCRYPTION_KEY (hex): b2bd2e480807f374177c0136bf14b318608e376a6c64ac026a3081a26d2664ca
+** TOKEN for Signer 1 (hex): a71ef33a642bd2ef53d2df2c
+*** TOKEN (decimal): 51721413026937653704357240620
+*** TOKEN (mnemonic): poem wasp soldier sign rule jeans exercise fossil club
+*** ENCRYPTION_KEY (hex): c27c4acbe0de3a25f4b3a55f97d1982cb82aa4ff45830f809d036ac2aaf76266
+** TOKEN for Signer 2 (hex): 99d2f458b3b3b42b1e9cf923
+*** TOKEN (decimal): 47606234818469057772362987811
+*** TOKEN (mnemonic): oil nut bike guess deputy better kidney palace casual
+*** ENCRYPTION_KEY (hex): 4775b101cfcce41071e1a9cecb0747485de04b87ebe8dacec402cef67931d2cd
+** TOKEN for Signer 3 (hex): af2f471d6aa8a7b728b9f030
+*** TOKEN (decimal): 54217032062918713649646923824
+*** TOKEN (mnemonic): quality kick shrug stem media swear pepper dignity couch
+*** ENCRYPTION_KEY (hex): a243c05b5ca2bf0c9a53cd68b72d389b63eb63e3016e8f614ea6554c937e47c4
 
 * Signer 1
-** MASTER_KEY_FINGERPRINT: 1af5fed9
-** PRIVATE_KEY (m/48'/0'/0'/1'): L4VABXeok8NSrEewRijcHY1AfzDpqQfzrbHDgmnj3j7vBgRaoofF
-** XPUB (m/48'/0'/0'/1'): xpub6Dk872oqUVGBi8rUjch8SBmvjYcXe4Ege93fsZ4utmZmyVgtjYiRqnvdUX3L8TfRdbPGXPuB8F7dBvecsgC75oSzCje9824wMtM4R3qDtoZ
+** MASTER_KEY_FINGERPRINT: 6e359358
+** PRIVATE_KEY (m/48'/0'/0'/1'): L3DkcAeLVhkSnLWBhtDcKn1tsQAd65TekAd2pPSNM26skzLR1p58
+** XPUB (m/48'/0'/0'/1'): xpub6FNL53N3hxLSRi2DbgBNzaZ4548QbkaQ8R1BwxsK47xfoEL6UMbqaLpueeH8K9PtJacrVTCCgd1ac8dQB8hPMTUXpttutwrAtyPfuScQ7YS
 ** Legacy signature
 ** <tt>signer_1_key.bsms</tt>:
 <pre>BSMS 1.0
-3e4e9f4a9bab074a1416b506
-[1af5fed9/48'/0'/0'/1']xpub6Dk872oqUVGBi8rUjch8SBmvjYcXe4Ege93fsZ4utmZmyVgtjYiRqnvdUX3L8TfRdbPGXPuB8F7dBvecsgC75oSzCje9824wMtM4R3qDtoZ
+a71ef33a642bd2ef53d2df2c
+[6e359358/48'/0'/0'/1']xpub6FNL53N3hxLSRi2DbgBNzaZ4548QbkaQ8R1BwxsK47xfoEL6UMbqaLpueeH8K9PtJacrVTCCgd1ac8dQB8hPMTUXpttutwrAtyPfuScQ7YS
 Signer 1 key
-IIB9bS+1UiqePqzeuQjOYVxr/ElW7ZpDazsmLC1WXgopB1PuEM0VDVVMybHXPPCnR8jB3JBO+1G2H2fYAbo5Td8=</pre>
+IKRvZ3kFnKpgkZ0Va78ohKxWjX3y0Jy2TKPd3INefSh5d60nIg+3663/drerA/HM8i/jl/vyHhOrydft/6mOwA8=</pre>
 
 * Signer 1 encryption
-** HMAC_KEY (hex): c9d881d28107d51c05b5c4252de0afac9dcfbe056f78ae690fc1cfed2a39d17c
-** MAC (hex): 9ee541d02fdd920c9be4528f262f2b4799a1cb0360d43fa4d3cfa436710d958a
-** IV (hex) : 9ee541d02fdd920c9be4528f262f2b47
-** CIPHERTEXT (hex): 16c870dbe0393a982b2e0a62e0f5a9e5b0eecece8ae27412bd4c9a66df562207aa0bd138a1ca122cbe5fa7feedd74b34009dd018c9454d8dc0d794551d76cc996502da04b5510f70d721ebba89c4135ac1e65075ec5da004b108f5b9d5119acb8bd25c7f8711512f25dcad66cefcba1de2844dcc537ce4c1579415c43141bf28e3c910e349229356a15c5db7b637f618a519ee6972abe06f0100d71e91603bbfbfecabe99cdfec8e036c7f739f1bbb0c502372696a9eb7f4d313b5d16a96d9b2e67a2c24738e2833f39d47e081370c66ad47fe5385adcc492129697cbda2507df9addc993e1fb0310fdb05ea7ad5cced8f23fc7a42101690520113dcad9a759c514b4ef7c93e4d7093f4b6d2de8b
-** <tt>signer_1_key.dat</tt>: <pre>9ee541d02fdd920c9be4528f262f2b4799a1cb0360d43fa4d3cfa436710d958a16c870dbe0393a982b2e0a62e0f5a9e5b0eecece8ae27412bd4c9a66df562207aa0bd138a1ca122cbe5fa7feedd74b34009dd018c9454d8dc0d794551d76cc996502da04b5510f70d721ebba89c4135ac1e65075ec5da004b108f5b9d5119acb8bd25c7f8711512f25dcad66cefcba1de2844dcc537ce4c1579415c43141bf28e3c910e349229356a15c5db7b637f618a519ee6972abe06f0100d71e91603bbfbfecabe99cdfec8e036c7f739f1bbb0c502372696a9eb7f4d313b5d16a96d9b2e67a2c24738e2833f39d47e081370c66ad47fe5385adcc492129697cbda2507df9addc993e1fb0310fdb05ea7ad5cced8f23fc7a42101690520113dcad9a759c514b4ef7c93e4d7093f4b6d2de8b</pre>
+** HMAC_KEY (hex): a7dd8a1097f21ad0a36169c6e7aca518d21aecb05e9a7541d5a210394ffd0c23
+** MAC (hex): 79de8f7e6973577b90fa92a53448056fd83529e6e6a6ad326eab0374875ec76f
+** IV (hex) : 79de8f7e6973577b90fa92a53448056f
+** CIPHERTEXT (hex): 11341286cc9acf95b7933a2d416dad8ae3436b1b6f40a3b58e85a6632e6dbf5452d536ac93d29c49cfa153b164c08c4198fb0e043e7f435bedcbeed1c146e94d78f13ddf001682325b68401c70946d71e33267bf17918fac97c196020e317b0d1727f9d73cf87612187b9dfbff7e933fc8d71dd951fdf16b7087b8aaf1ebe54d1b7ae77ca69a82404a2d01d21fd50f0a18c48bac150720d52c02e8c71ed935a946c231a90613222c5085619a09a6428ceafde75479121071061af56a8585dc8d9edf5be9c02360b737eae4871cb661b5132d0bb3aca1dd9092e3c63b4c5c6ec7c0ff1725d17fc1ce305afcb8859389824ddcf5845e3f3aef2e7037aa860bb21adcc828372c0c272e38b2bbf09bca
+** <tt>signer_1_key.dat</tt>: <pre>79de8f7e6973577b90fa92a53448056fd83529e6e6a6ad326eab0374875ec76f11341286cc9acf95b7933a2d416dad8ae3436b1b6f40a3b58e85a6632e6dbf5452d536ac93d29c49cfa153b164c08c4198fb0e043e7f435bedcbeed1c146e94d78f13ddf001682325b68401c70946d71e33267bf17918fac97c196020e317b0d1727f9d73cf87612187b9dfbff7e933fc8d71dd951fdf16b7087b8aaf1ebe54d1b7ae77ca69a82404a2d01d21fd50f0a18c48bac150720d52c02e8c71ed935a946c231a90613222c5085619a09a6428ceafde75479121071061af56a8585dc8d9edf5be9c02360b737eae4871cb661b5132d0bb3aca1dd9092e3c63b4c5c6ec7c0ff1725d17fc1ce305afcb8859389824ddcf5845e3f3aef2e7037aa860bb21adcc828372c0c272e38b2bbf09bca</pre>
 
 * Signer 2
-** MASTER_KEY_FINGERPRINT: bbe4987a
-** PRIVATE_KEY (m/48'/0'/0'/1'): L3chGYUbvkxJuv61Vx6mmBWmDyBi7HnWDqLtTKokeKuy5GmKRx53
-** XPUB (m/48'/0'/0'/1'): xpub6EC1EmDURTiXqb4FCmANE1u5jybxqv8qyxXp6JKVJQTzGaF4JWzPhASkHb9RUuHS7hEKZ3iouARzCrhG3E6SauuefL1LrLoAtKHvmDJ1JFK
+** MASTER_KEY_FINGERPRINT: 478740ec
+** PRIVATE_KEY (m/48'/0'/0'/1'): KzdFU8eiwuCtoBSkkyzWZVS55BpvT6opJt2u8kVmsMpMrJarBowJ
+** XPUB (m/48'/0'/0'/1'): xpub6EYCJXggYLmwbFgkhwcFAauukuEqGUi9Wj7YoL5YerCxGom82v6ioSgzjcW9iadLqSV9XihXHXKey61jwv1cZykPRhwzxhCDQBJompv6Gdv
 ** Legacy signature
 ** <tt>signer_2_key.bsms</tt>:
 <pre>BSMS 1.0
-4c6d6215d13f7a1e9183f810
-[bbe4987a/48'/0'/0'/1']xpub6EC1EmDURTiXqb4FCmANE1u5jybxqv8qyxXp6JKVJQTzGaF4JWzPhASkHb9RUuHS7hEKZ3iouARzCrhG3E6SauuefL1LrLoAtKHvmDJ1JFK
+99d2f458b3b3b42b1e9cf923
+[478740ec/48'/0'/0'/1']xpub6EYCJXggYLmwbFgkhwcFAauukuEqGUi9Wj7YoL5YerCxGom82v6ioSgzjcW9iadLqSV9XihXHXKey61jwv1cZykPRhwzxhCDQBJompv6Gdv
 Signer 2 key
-H4tcaRaEGIPHDg+e+8MxPyYyo3qk9ZKPAIdYQY3iXZOPfb1W96FqzP+6KMj5ov8OSIjeA9PEtRVLUmsMoVnR7EA=</pre>
+Hwe3RlD/a/MEqsLUWKJvSLOKvEx2uRBe7TvCJSZTfk1iKNy9BnsC08Rt78kBIHnoyL+QFmBnXQgywnJrmxlJLM4=</pre>
 
 * Signer 2 encryption
-** HMAC_KEY (hex): 8050b80716db042130c7aaf086a0b3e59d8d3e59c0d689c6b61fb2e5ccd9644b
-** MAC (hex): 991dc1aa90ccb22ff410208efc4f8132a5d11586e21d76f273180b53d30046f8
-** IV (hex) : 991dc1aa90ccb22ff410208efc4f8132
-** CIPHERTEXT (hex): 6759a008f1e9eaad15c3be3669994402654919c5993d64198a00d9073c8fde97696beeed89b5cf9c0f9b0cacb1e0b769cb9fdaa92b74bb4d1574c8ba9056d05d25950652da5bd61ba1a4194b7a6fdb28ec09f4697e5cc825ce9738d0852096f5030498272feec82766b59848dd1e3a4941da59b5f74af6291a9638be980c6961a0f094db72efdabc1bca1fa9a0aa32cfdf0216e4b4af760b9e542d4944a5d25d68c2b901131c735148392b48c642b619b74f7fa5e2575a053de0cddedeefee352b31b52e89bf7e0f5f2c147437740c5167e11890172d1813293c405379107f54fc74b56e06dc2da7eb1a361074b84fccc2e865227382a0d5a6bf69b223d9d202656fd3f86d665b12500a66749624
-** <tt>signer_2_key.dat</tt>: <pre>991dc1aa90ccb22ff410208efc4f8132a5d11586e21d76f273180b53d30046f86759a008f1e9eaad15c3be3669994402654919c5993d64198a00d9073c8fde97696beeed89b5cf9c0f9b0cacb1e0b769cb9fdaa92b74bb4d1574c8ba9056d05d25950652da5bd61ba1a4194b7a6fdb28ec09f4697e5cc825ce9738d0852096f5030498272feec82766b59848dd1e3a4941da59b5f74af6291a9638be980c6961a0f094db72efdabc1bca1fa9a0aa32cfdf0216e4b4af760b9e542d4944a5d25d68c2b901131c735148392b48c642b619b74f7fa5e2575a053de0cddedeefee352b31b52e89bf7e0f5f2c147437740c5167e11890172d1813293c405379107f54fc74b56e06dc2da7eb1a361074b84fccc2e865227382a0d5a6bf69b223d9d202656fd3f86d665b12500a66749624</pre>
+** HMAC_KEY (hex): 3973f29e11405adaa9df7e15484e26df8dea82a48c8461011fcb173420b46ea9
+** MAC (hex): 3a225aaa6424fcc4e071da2fa601ac502c4a2456cad0b133ea613b1c54890583
+** IV (hex) : 3a225aaa6424fcc4e071da2fa601ac50
+** CIPHERTEXT (hex): d23efeb048417c1677c4db0de69ccaedd2648822727f7151c96b7c364ddee75665c2c49bd4caf3b61e2cafc3366c50a72844d47c3a1e6d0dbf263e7507846e3a12a339d475a333aec33b3b15343d58a70e88ed9affc1159bd68a865ef8293e05020b8f019ca0df80522777063a96c48fdc2f89504ba5571df31ba31285eb0063fafd973aae93ebf9a581b7580cdc08d4aa77b08a175c5e06198fa9c8eefc6dd5969664e28f2098751c5a2576ce28d55baf2dd7897cd5ddb08d2b2a979fbfa066e139d7f11d6948a5298cb3b41b15272fda24ac16eb6aacc9e2ab80b317c0aca173451a892006798e31a3a50b38ec9d8419863765dd5fa2d030d46df8e71c425deb866db8f0b9c4aa34825dcfe93c
+** <tt>signer_2_key.dat</tt>: <pre>3a225aaa6424fcc4e071da2fa601ac502c4a2456cad0b133ea613b1c54890583d23efeb048417c1677c4db0de69ccaedd2648822727f7151c96b7c364ddee75665c2c49bd4caf3b61e2cafc3366c50a72844d47c3a1e6d0dbf263e7507846e3a12a339d475a333aec33b3b15343d58a70e88ed9affc1159bd68a865ef8293e05020b8f019ca0df80522777063a96c48fdc2f89504ba5571df31ba31285eb0063fafd973aae93ebf9a581b7580cdc08d4aa77b08a175c5e06198fa9c8eefc6dd5969664e28f2098751c5a2576ce28d55baf2dd7897cd5ddb08d2b2a979fbfa066e139d7f11d6948a5298cb3b41b15272fda24ac16eb6aacc9e2ab80b317c0aca173451a892006798e31a3a50b38ec9d8419863765dd5fa2d030d46df8e71c425deb866db8f0b9c4aa34825dcfe93c</pre>
 
 * Signer 3
-** MASTER_KEY_FINGERPRINT: 887d1ce9
-** PRIVATE_KEY (m/48'/0'/0'/1'): L384ku43jpVYKWWaD1nxRifALPNXyHL3hWNtThByByP5ZMQxs427
-** XPUB (m/48'/0'/0'/1'): xpub6Eof6ipAiAqiGdnFdoKA4nJv19rQwR1NFCKWvjpcNeB3ZyLPHBek9rotgxCKyGn8CumDagZzTXwHaAyZPxQujRZVTDP3KmpceWZHiwe4bZP
+** MASTER_KEY_FINGERPRINT: ff6be335
+** PRIVATE_KEY (m/48'/0'/0'/1'): L35ukMXHBwwVgzSEc6RLM4GKoLmC1e1KeujC8nqXbD63iPb8BRkJ
+** XPUB (m/48'/0'/0'/1'): xpub6EUJJMcoJFhsnyCzNzQNU9caFNHkvK1Y8iyUoufbWV4Uyq1rK594SZ7mz5NREF6aowE845sGmPY4KnMgXezy43Sp2FGE9UgsaMQD5bcBaGX
 ** Legacy signature
 ** <tt>signer_3_key.bsms</tt>:
 <pre>BSMS 1.0
-70d41aaf4c4561c19205d819
-[887d1ce9/48'/0'/0'/1']xpub6Eof6ipAiAqiGdnFdoKA4nJv19rQwR1NFCKWvjpcNeB3ZyLPHBek9rotgxCKyGn8CumDagZzTXwHaAyZPxQujRZVTDP3KmpceWZHiwe4bZP
+af2f471d6aa8a7b728b9f030
+[ff6be335/48'/0'/0'/1']xpub6EUJJMcoJFhsnyCzNzQNU9caFNHkvK1Y8iyUoufbWV4Uyq1rK594SZ7mz5NREF6aowE845sGmPY4KnMgXezy43Sp2FGE9UgsaMQD5bcBaGX
 Signer 3 key
-ICQQ5vlCvv8+6z+peuvKTtSRRs7rodHmfcDQZkArxr5DQ8PkHvjIA92y6FrGCUDG0ruO46qYiFTeRUi0HCX8CcU=</pre>
+H3EcehsCYhHx9jRbqrqWRuRcd2gJMGBhrsCbiYRvhe9ycfVAtxeeX2tWmtAIvlLc2ye9Ad9QI6iZUnVULAFMrEI=</pre>
 
 * Signer 3 encryption
-** HMAC_KEY (hex): 52f0fc79116014738144d4e04d88d581267f15f004c29492ea65f05b7489ce66
-** MAC (hex): 9240bac748bbc04138e20b0efb11655fdaa2067897bb375f0c274c9e6b168cba
-** IV (hex) : 9240bac748bbc04138e20b0efb11655f
-** CIPHERTEXT (hex): ba8953cbfa0ccf4c5aaa1c35981876c050401b37e05f1d9f4464f85ded7a5aae35aab218970413e4937daea6e44e89b8e61b04e0524b214f33d6cae4c24b729d8447de4b9f0296a4b37149e3000e9990c82c7d3691bcc9fee76d0334bf9325acb0f84644e2749a292f84d7e5c4ad985559fcd64c188b385cac3e833ec71d530af690894afab7d4122f98e912e8f4dee561f6d50e48e6c0f9761f1474eef2bea5a1c0fde11e8fd0992fe17a2e5c1a80a558c3cb98eb19946b87ebbada192d671a629dde718a3800124f64d747d3a1b5613566706e44ab4634489d77f09951d488590b6b887dda54bf5605da457f6f79a12ebebfc1925dfd2d9d67cd328d1c0dd7ef9eba21c7b1ceda2208effa779a
-** <tt>signer_3_key.dat</tt>: <pre>9240bac748bbc04138e20b0efb11655fdaa2067897bb375f0c274c9e6b168cbaba8953cbfa0ccf4c5aaa1c35981876c050401b37e05f1d9f4464f85ded7a5aae35aab218970413e4937daea6e44e89b8e61b04e0524b214f33d6cae4c24b729d8447de4b9f0296a4b37149e3000e9990c82c7d3691bcc9fee76d0334bf9325acb0f84644e2749a292f84d7e5c4ad985559fcd64c188b385cac3e833ec71d530af690894afab7d4122f98e912e8f4dee561f6d50e48e6c0f9761f1474eef2bea5a1c0fde11e8fd0992fe17a2e5c1a80a558c3cb98eb19946b87ebbada192d671a629dde718a3800124f64d747d3a1b5613566706e44ab4634489d77f09951d488590b6b887dda54bf5605da457f6f79a12ebebfc1925dfd2d9d67cd328d1c0dd7ef9eba21c7b1ceda2208effa779a</pre>
+** HMAC_KEY (hex): 330f062ad717fffea29292f763f2e81188ba99a3b6315436ffcb47dc06208da3
+** MAC (hex): 9879fd1456a53bf806c98d3ffc2856000f27a9a7f1eb3c77701165f16882188a
+** IV (hex) : 9879fd1456a53bf806c98d3ffc285600
+** CIPHERTEXT (hex): fa034e67bdab25b8b35c490c56e792f24140f8f76cb1a429ee39da53b978cc2954349238cff09fe915b502a3a75326ee9a605c76f971560b2a101927f48916724062ad7d25f97182a11d17d6da745ddcf84ee794214f629971d6a6599179fd170475678aa985e0fd75646516383c8e56c2eeff975ab9d20b75899e1f39f0c02d114495b71733fd29542feea6e7b10a5b4ee32db11d3668776e7f0d6800212d29ca4b173a01e210e61f04bfea05e36bc4f9ac49e1c4e3f7e8e48aaaa1275e1ed6c4f5e2faf3a1fdd4953d8796d1104ac2aee6422fc70521a0ce0bd92828d9fc9411e614cc1ba26c9f402bb3d29823b3f253c00b4bccf42c829b9aa687fb490bb18d7991f22998dd281a80fe865cc6
+** <tt>signer_3_key.dat</tt>: <pre>9879fd1456a53bf806c98d3ffc2856000f27a9a7f1eb3c77701165f16882188afa034e67bdab25b8b35c490c56e792f24140f8f76cb1a429ee39da53b978cc2954349238cff09fe915b502a3a75326ee9a605c76f971560b2a101927f48916724062ad7d25f97182a11d17d6da745ddcf84ee794214f629971d6a6599179fd170475678aa985e0fd75646516383c8e56c2eeff975ab9d20b75899e1f39f0c02d114495b71733fd29542feea6e7b10a5b4ee32db11d3668776e7f0d6800212d29ca4b173a01e210e61f04bfea05e36bc4f9ac49e1c4e3f7e8e48aaaa1275e1ed6c4f5e2faf3a1fdd4953d8796d1104ac2aee6422fc70521a0ce0bd92828d9fc9411e614cc1ba26c9f402bb3d29823b3f253c00b4bccf42c829b9aa687fb490bb18d7991f22998dd281a80fe865cc6</pre>
 
 ====ROUND 2====
 * Coordinator
 ** <tt>my_multisig_wallet.bsms</tt>:
 <pre>BSMS 1.0
-sh(wsh(multi(2,[1af5fed9/48'/0'/0'/1']xpub6Dk872oqUVGBi8rUjch8SBmvjYcXe4Ege93fsZ4utmZmyVgtjYiRqnvdUX3L8TfRdbPGXPuB8F7dBvecsgC75oSzCje9824wMtM4R3qDtoZ/*,[bbe4987a/48'/0'/0'/1']xpub6EC1EmDURTiXqb4FCmANE1u5jybxqv8qyxXp6JKVJQTzGaF4JWzPhASkHb9RUuHS7hEKZ3iouARzCrhG3E6SauuefL1LrLoAtKHvmDJ1JFK/*,[887d1ce9/48'/0'/0'/1']xpub6Eof6ipAiAqiGdnFdoKA4nJv19rQwR1NFCKWvjpcNeB3ZyLPHBek9rotgxCKyGn8CumDagZzTXwHaAyZPxQujRZVTDP3KmpceWZHiwe4bZP/*)))#uf57h08d
+sh(wsh(multi(2,[6e359358/48'/0'/0'/1']xpub6FNL53N3hxLSRi2DbgBNzaZ4548QbkaQ8R1BwxsK47xfoEL6UMbqaLpueeH8K9PtJacrVTCCgd1ac8dQB8hPMTUXpttutwrAtyPfuScQ7YS/**,[478740ec/48'/0'/0'/1']xpub6EYCJXggYLmwbFgkhwcFAauukuEqGUi9Wj7YoL5YerCxGom82v6ioSgzjcW9iadLqSV9XihXHXKey61jwv1cZykPRhwzxhCDQBJompv6Gdv/**,[ff6be335/48'/0'/0'/1']xpub6EUJJMcoJFhsnyCzNzQNU9caFNHkvK1Y8iyUoufbWV4Uyq1rK594SZ7mz5NREF6aowE845sGmPY4KnMgXezy43Sp2FGE9UgsaMQD5bcBaGX/**)))
 /0/*,/1/*
-3ApQjkfMvzZiWxpdJeNex4c71aWjHyMkPk</pre>
+3A4tfQoLviGREWmVuHN9WNLuo81nPtRv2W</pre>
 
 * Send to Signer 1:
-** HMAC_KEY (hex): c9d881d28107d51c05b5c4252de0afac9dcfbe056f78ae690fc1cfed2a39d17c
-** MAC (hex): b432a7312b64b561592876cb0d63ec5d2f3fb9b24fe0fd6200a4733f4cb0fa2b
-** IV (hex) : b432a7312b64b561592876cb0d63ec5d
-** CIPHERTEXT (hex): 8893171bdfb77c6cd603a2b659832bfef3d7b5f94bfd4a513a91d0abe4d2a81410108a08a9621ecd50c8e8c7b1849c66b88198e683072052dc9f4ac8b769c2390a753404e5c9ad446a757822c788fe52762c176dc0e721503c58fe0207b961693a7cf5f83ff1c1f5307b28ffc6827437560ef7d1d93e9700098488c7cc2b5b607481ae0d5ab063c5dd2ca3af3f198520f7e49b026236978ac1059fd88ce0b297b82600d049d8e35a355fc413d1b216baf7999db4506cb1f024efe7d08e45fde486d7f9b6950d4c03f45a93c99b1d8f5f7a17d13551373032a498bf8e1402f2c02bc462ff9a1ad0e9c3d8360ae3edba0d0f7a9c27a27ea5ab8b755b080dd30e4563f2905dfe3a26db66ac81daa4e8d37cc49ddf7a82d9cec622b81ce56db7baa7e9143a1d1a6ffef2a2d1fc96888897defa2de7d1c36a6acc42eaae4646f5c612296970f8f8529cfa4e494471c5d3748e6885d800f6e2bcd4d40dd665eda4febffe50e2e39fc6b92c70888aa1bd74bf4fc4fcc2fd995a2a823a739c6c366b681de30bb7431f6ad20861da415277f189a6b3d71ee99803115c48ae54b32d4b4c3d50cccd09e658289685bf2c11e3198845236db612849c60032fae9b697c184ffa0b693e16d255c2c9a785e27a42a4e22c5d0deb9bf7665487ca69a021284e26bc662ac398f126982f79adb0
-** <tt>my_multisig_wallet_for_signer_1.dat</tt>: <pre>b432a7312b64b561592876cb0d63ec5d2f3fb9b24fe0fd6200a4733f4cb0fa2b8893171bdfb77c6cd603a2b659832bfef3d7b5f94bfd4a513a91d0abe4d2a81410108a08a9621ecd50c8e8c7b1849c66b88198e683072052dc9f4ac8b769c2390a753404e5c9ad446a757822c788fe52762c176dc0e721503c58fe0207b961693a7cf5f83ff1c1f5307b28ffc6827437560ef7d1d93e9700098488c7cc2b5b607481ae0d5ab063c5dd2ca3af3f198520f7e49b026236978ac1059fd88ce0b297b82600d049d8e35a355fc413d1b216baf7999db4506cb1f024efe7d08e45fde486d7f9b6950d4c03f45a93c99b1d8f5f7a17d13551373032a498bf8e1402f2c02bc462ff9a1ad0e9c3d8360ae3edba0d0f7a9c27a27ea5ab8b755b080dd30e4563f2905dfe3a26db66ac81daa4e8d37cc49ddf7a82d9cec622b81ce56db7baa7e9143a1d1a6ffef2a2d1fc96888897defa2de7d1c36a6acc42eaae4646f5c612296970f8f8529cfa4e494471c5d3748e6885d800f6e2bcd4d40dd665eda4febffe50e2e39fc6b92c70888aa1bd74bf4fc4fcc2fd995a2a823a739c6c366b681de30bb7431f6ad20861da415277f189a6b3d71ee99803115c48ae54b32d4b4c3d50cccd09e658289685bf2c11e3198845236db612849c60032fae9b697c184ffa0b693e16d255c2c9a785e27a42a4e22c5d0deb9bf7665487ca69a021284e26bc662ac398f126982f79adb0</pre>
+** HMAC_KEY (hex): a7dd8a1097f21ad0a36169c6e7aca518d21aecb05e9a7541d5a210394ffd0c23
+** MAC (hex): 91798c713660b9eea04aed38bb83e10e998b04fd1fb887c42a6062c0b2a96528
+** IV (hex) : 91798c713660b9eea04aed38bb83e10e
+** CIPHERTEXT (hex): 7cd33615188054d07ca049f5aad956a36a14f4ea5eddaeceb0887d489f3981952ddd56f37236b515caf52aca9e2b2a4a365e93e3c9ab7cc96cfc3886df698e20faf860d30b8893cacc51fa99a623cceb02985f3876244f6a861611761123578bff9bcea8d958b4854c66385485ec5b299a46fc2900ee861b890889580a435b4f92ff2e19172eceb8f257e66b6c11b3d314293bfdcaee4c9991e0e27b3c3d5e43419c7749eca0074d51e9b3e9fd85ab61727574a6e79c77cba746a349ea4c5eade184a90461a6c1d5e6381ea9e6483be16159bfa2fbe911b31761087091041f352a65842bca9cb66bd8e9069f9872ecc021351dee29d8e4e3c0704e96974fe8ba8e2a4677f3b26c64f3b8cf793754ea5bbbe86d933ea8b7837fbb63d410e7690e7e27cb675da178df7b298050a8795c5cd24b840925f2d3e0007751200065088f5c612d9b7bfa55011577066a8d219094ac4516e958790c7d483ab48fd5a73a4897acbf91c85f6b7bfe50272273f7aa003ebf6860de51e0c905b427cde61699bb88ade90a1ae1adbd9b12deed4ae5988791fd989567a34ad1c9916dca95ac86d4689ab38182df973f2d1c2bc7968726ef1f503ba50a6a65356f536d3173af8db9ddb344520dc57ac03a5576795b7a7abc714349024675c89803422044f6339eecd701b3bbed
+** <tt>my_multisig_wallet_for_signer_1.dat</tt>: <pre>91798c713660b9eea04aed38bb83e10e998b04fd1fb887c42a6062c0b2a965287cd33615188054d07ca049f5aad956a36a14f4ea5eddaeceb0887d489f3981952ddd56f37236b515caf52aca9e2b2a4a365e93e3c9ab7cc96cfc3886df698e20faf860d30b8893cacc51fa99a623cceb02985f3876244f6a861611761123578bff9bcea8d958b4854c66385485ec5b299a46fc2900ee861b890889580a435b4f92ff2e19172eceb8f257e66b6c11b3d314293bfdcaee4c9991e0e27b3c3d5e43419c7749eca0074d51e9b3e9fd85ab61727574a6e79c77cba746a349ea4c5eade184a90461a6c1d5e6381ea9e6483be16159bfa2fbe911b31761087091041f352a65842bca9cb66bd8e9069f9872ecc021351dee29d8e4e3c0704e96974fe8ba8e2a4677f3b26c64f3b8cf793754ea5bbbe86d933ea8b7837fbb63d410e7690e7e27cb675da178df7b298050a8795c5cd24b840925f2d3e0007751200065088f5c612d9b7bfa55011577066a8d219094ac4516e958790c7d483ab48fd5a73a4897acbf91c85f6b7bfe50272273f7aa003ebf6860de51e0c905b427cde61699bb88ade90a1ae1adbd9b12deed4ae5988791fd989567a34ad1c9916dca95ac86d4689ab38182df973f2d1c2bc7968726ef1f503ba50a6a65356f536d3173af8db9ddb344520dc57ac03a5576795b7a7abc714349024675c89803422044f6339eecd701b3bbed</pre>
 
 * Send to Signer 2:
-** HMAC_KEY (hex): 8050b80716db042130c7aaf086a0b3e59d8d3e59c0d689c6b61fb2e5ccd9644b
-** MAC (hex): 116a2bf035dcd99c6e8bb16487ce14028b1824d64968bf0d59abeb4a34f703bd
-** IV (hex) : 116a2bf035dcd99c6e8bb16487ce1402
-** CIPHERTEXT (hex): 90dcbe85cff4475cad3aff55e59f15411fa343fb12e71a06b8d048f41121af1a16385e85be34785f6c1dcd62f0d5460824dcd4a4e2089c3869fb4c563d8dfd9d69d03c9140062aee3c6dd2de3c3f31a4852edd319b0d3357d1a3ccb62a1907aa787d34e2bd60a6f692a462ab9480255a2b5462fc6b6b95e41dc66873d78c7a3585f75f25100a8a3092bd3d9d655deb4d6a0d2c1b0e74e5631a5089f87334bfc5570d2d9f5d53bd0e5c3bb97bf27fb251f409b0b20617919c7164a10d244258b76bb9d9c51f6f89431dea437e2af0998f9c2d94f5d2d79915fb3439fd9077ed5af84772b17789cbb359c8092048999969020c3f9b6600239ed39547d2a71a36f0e06f92c89cd1d026a424a148c2aa76ea9451a71a674e15486d66ac35edac83bae49cc452a2c4ecd61d84dddec02a9ad9197a3128cd3f3f02d32f54674ab844c04e15086d9b6f0ae09ec4d66b484a2ddb24ccd8bf6837c25f9ad87a7b4ee6028a8c0ebdd8bfe5eb0be434cfd97a0fd25a8fb0b6d6de3f2a4bda2c511d834e0cf6bc264513d6135e6ec5ce8f017c123f61129f0ffa3531c735a32e87945901ed5efa07e077ba97ddb8a7ef48e653298e45e22d9be6c2662145443e9657e77003a7fb5d28623121b5ff7a2c82dfb92e8b6151539d329cf0ccc5ce0df9064a628f27fd7274f53bdd4191f424f2
-** <tt>my_multisig_wallet_for_signer_2.dat</tt>: <pre>116a2bf035dcd99c6e8bb16487ce14028b1824d64968bf0d59abeb4a34f703bd90dcbe85cff4475cad3aff55e59f15411fa343fb12e71a06b8d048f41121af1a16385e85be34785f6c1dcd62f0d5460824dcd4a4e2089c3869fb4c563d8dfd9d69d03c9140062aee3c6dd2de3c3f31a4852edd319b0d3357d1a3ccb62a1907aa787d34e2bd60a6f692a462ab9480255a2b5462fc6b6b95e41dc66873d78c7a3585f75f25100a8a3092bd3d9d655deb4d6a0d2c1b0e74e5631a5089f87334bfc5570d2d9f5d53bd0e5c3bb97bf27fb251f409b0b20617919c7164a10d244258b76bb9d9c51f6f89431dea437e2af0998f9c2d94f5d2d79915fb3439fd9077ed5af84772b17789cbb359c8092048999969020c3f9b6600239ed39547d2a71a36f0e06f92c89cd1d026a424a148c2aa76ea9451a71a674e15486d66ac35edac83bae49cc452a2c4ecd61d84dddec02a9ad9197a3128cd3f3f02d32f54674ab844c04e15086d9b6f0ae09ec4d66b484a2ddb24ccd8bf6837c25f9ad87a7b4ee6028a8c0ebdd8bfe5eb0be434cfd97a0fd25a8fb0b6d6de3f2a4bda2c511d834e0cf6bc264513d6135e6ec5ce8f017c123f61129f0ffa3531c735a32e87945901ed5efa07e077ba97ddb8a7ef48e653298e45e22d9be6c2662145443e9657e77003a7fb5d28623121b5ff7a2c82dfb92e8b6151539d329cf0ccc5ce0df9064a628f27fd7274f53bdd4191f424f2</pre>
+** HMAC_KEY (hex): 3973f29e11405adaa9df7e15484e26df8dea82a48c8461011fcb173420b46ea9
+** MAC (hex): 6cfb40b2ecbde71752e3d273afe190add5ae2dfc93ee4499e1f2c3ea5f5033fe
+** IV (hex) : 6cfb40b2ecbde71752e3d273afe190ad
+** CIPHERTEXT (hex): 965344af904b244a8b943fb6af95f813cb138a37b29e9556a8eb8553347ce7c447f28892b4d3e4d449be767ba9cf4cbe07db86e38585fc9be8d6843edcb52e738405a4ae9d042866fcd77438d1d2e0e9ff5b09dc71d8eb07a2ce41de605189687d6a6873a320b99d0bbc314c76c2e4ec172db5cfbb7661a4e656ca4ba016c8f8e6441721170e5c7b10c5648726d7e546ce58d54d4aa73d37ef27b3968bc7f3ec5c592993fc63a6a3664854f7427ab41c6fac12d0a84e3221a8bc8518217810bf9bda4b2c9962e028041e3840430634600daa6544c3d12403c0aba59ad32a7848311eac1bb956b36770c4166307157a3047078a57c7a93989988d176f2c5d531705e9d523b4672643c3ee05a570c41079267bc128d8a2533cf1dd18f17e7792c2ebb3d0e9ff4ac8522f5163e6ea5ca1ecc24d87ab8b05e4fd93ce8a443c952c01734cde5943b87f4b0bba73ac48d5d151b6ea774f2b39c36739fdf16817ef32afbfa34afd2f919b9f755b7b850f2f08e0e2b9b82ca8b668b7c1db1a218b7ecc8c7e5726808c4bd3a9a4f85098213d2f29040763c9656bef84a5218db39124b56df24d7457f943704964336cf4e196e7a4575b7624a3e0b210164e8cdb078b816cc88622420f60fdb98702031e6675b85087844b5ded9b4b29258c2a050f5bb42a13a3cab8ba
+** <tt>my_multisig_wallet_for_signer_2.dat</tt>: <pre>6cfb40b2ecbde71752e3d273afe190add5ae2dfc93ee4499e1f2c3ea5f5033fe965344af904b244a8b943fb6af95f813cb138a37b29e9556a8eb8553347ce7c447f28892b4d3e4d449be767ba9cf4cbe07db86e38585fc9be8d6843edcb52e738405a4ae9d042866fcd77438d1d2e0e9ff5b09dc71d8eb07a2ce41de605189687d6a6873a320b99d0bbc314c76c2e4ec172db5cfbb7661a4e656ca4ba016c8f8e6441721170e5c7b10c5648726d7e546ce58d54d4aa73d37ef27b3968bc7f3ec5c592993fc63a6a3664854f7427ab41c6fac12d0a84e3221a8bc8518217810bf9bda4b2c9962e028041e3840430634600daa6544c3d12403c0aba59ad32a7848311eac1bb956b36770c4166307157a3047078a57c7a93989988d176f2c5d531705e9d523b4672643c3ee05a570c41079267bc128d8a2533cf1dd18f17e7792c2ebb3d0e9ff4ac8522f5163e6ea5ca1ecc24d87ab8b05e4fd93ce8a443c952c01734cde5943b87f4b0bba73ac48d5d151b6ea774f2b39c36739fdf16817ef32afbfa34afd2f919b9f755b7b850f2f08e0e2b9b82ca8b668b7c1db1a218b7ecc8c7e5726808c4bd3a9a4f85098213d2f29040763c9656bef84a5218db39124b56df24d7457f943704964336cf4e196e7a4575b7624a3e0b210164e8cdb078b816cc88622420f60fdb98702031e6675b85087844b5ded9b4b29258c2a050f5bb42a13a3cab8ba</pre>
 
 * Send to Signer 3:
-** HMAC_KEY (hex): 52f0fc79116014738144d4e04d88d581267f15f004c29492ea65f05b7489ce66
-** MAC (hex): 6a724e518881d033337d536b4ae08402322da89c6024926d497006edcb44ba3a
-** IV (hex) : 6a724e518881d033337d536b4ae08402
-** CIPHERTEXT (hex): d5d6945f08e994de3cef2737601e2f9640611d58e018594c9e341091e14a7d83f7135b183efba239f2cb052ba6f454ee5b11dd808be6d0e18c0d44c8f8b51acc71300cf46bb0b52244ac0e147e9b1bc756a2760efe3d3c94b76f893f548bf6b44507bb4aef037a676fe66ea2011a7a68bcf9a610b4351c8469c3201f8ffddbb3f67bb90d2fe44668b17be2aa5688a35036d76f61f398527229a3db06abfe97698ef131b3e4feba5da6b80b4b93cbab84b6bbf83d82b4df997b9dc283f748baa1f67937f025c0ca1d8a47049bf39d3fad8dddc08e8e068473739fa7857c992272b5c73ae9ac4a0cbb2aa2a3a9113c5b57522a73e225c210932b5c19e0a2b7f42deebe6f3bd9ed48b8275962cd0ac1917926107e2b937de71d846a5bd87edd22d49a3555ba6506c8a7c49056e722480549e79cdbbd77a792f74a0d67677b9c16f810b35bc07835a32e4000c09564f70c1672b4ac103cb5b4d9a1b484e83486f71e14c52d4a3fdb5c2b9e9a6e94e6fa369e527d97042b03649617609db981dba86735b598e967a0db2f3d73bbfb449b150a741c6dadc31a2308e0128edc587dcdb18d5f362922df8ddb8c0c4dcbe1c7e76617c8114ca37157ed406f6ac1c033a083ac9daabba4fd924de55b91c9decb01b03ce5a272ef0a56c8770ed15398c401dbde7739283c3cf90941f23e
-** <tt>my_multisig_wallet_for_signer_3.dat</tt>: <pre>6a724e518881d033337d536b4ae08402322da89c6024926d497006edcb44ba3ad5d6945f08e994de3cef2737601e2f9640611d58e018594c9e341091e14a7d83f7135b183efba239f2cb052ba6f454ee5b11dd808be6d0e18c0d44c8f8b51acc71300cf46bb0b52244ac0e147e9b1bc756a2760efe3d3c94b76f893f548bf6b44507bb4aef037a676fe66ea2011a7a68bcf9a610b4351c8469c3201f8ffddbb3f67bb90d2fe44668b17be2aa5688a35036d76f61f398527229a3db06abfe97698ef131b3e4feba5da6b80b4b93cbab84b6bbf83d82b4df997b9dc283f748baa1f67937f025c0ca1d8a47049bf39d3fad8dddc08e8e068473739fa7857c992272b5c73ae9ac4a0cbb2aa2a3a9113c5b57522a73e225c210932b5c19e0a2b7f42deebe6f3bd9ed48b8275962cd0ac1917926107e2b937de71d846a5bd87edd22d49a3555ba6506c8a7c49056e722480549e79cdbbd77a792f74a0d67677b9c16f810b35bc07835a32e4000c09564f70c1672b4ac103cb5b4d9a1b484e83486f71e14c52d4a3fdb5c2b9e9a6e94e6fa369e527d97042b03649617609db981dba86735b598e967a0db2f3d73bbfb449b150a741c6dadc31a2308e0128edc587dcdb18d5f362922df8ddb8c0c4dcbe1c7e76617c8114ca37157ed406f6ac1c033a083ac9daabba4fd924de55b91c9decb01b03ce5a272ef0a56c8770ed15398c401dbde7739283c3cf90941f23e</pre>
+** HMAC_KEY (hex): 330f062ad717fffea29292f763f2e81188ba99a3b6315436ffcb47dc06208da3
+** MAC (hex): b126ed9ebf0d935145d3ff187476e256f875be9ed930ecd1ab805f5125b69e0b
+** IV (hex) : b126ed9ebf0d935145d3ff187476e256
+** CIPHERTEXT (hex): 1fdbcb176d2b3fa00cb81448ae413cef4a567cdac3cd3d985349ed296f8e578ef5222e91b7c7dd7bff5ae9fc49c545938b256e2d3f526810172e196d8d374569ff3f4a7e3a2c3e67c13fd13bb829dd731b14ec3bef6454616162dd59e4653a7465c5f97ca84ebf25be56907c56c50f1c3a2e3b86ed2d70770db7c04781ef4b9d55feb05f80e0d8125d8427a59ff60dfab68212d8d25c2cad669572864fbb6d554c005fd88b95fab7d5861786d4c335bcda915c8992381c3452d9ab5d4a8f59b49edf6022fd2de1df70c6fc2850ebb4f781fb6efb7bf8faac2871fb15b17d5b9ff8963b48be68a949ce40b7b1a7196ca8cbfe1da2458d0ed8ba2743a05b23cd98a153373f13e7cf9c0b6ed014a2e665d7597736a0761e0dafbb9040260166b5fc90258efce90b37f614c1dcbcae160c990df975767bccba73f1977da4992ba7bdb9009f24641fd122d85293db0d3b3fd19ef3b303c46a452402ef15d214d33445319139ce4346ab638fb8a03948aee27e6d81f95156345ac0af3b8419ae0a8eb62dac21ec4125e4bb168b0454a8b3022ce65f08b304c0712d2f7db0dd00c979f812b61904a6d94f5d3932a385d18084970e0e6b4a4bc661606f3eb6a357a2d7dd05819d03ad8a61d1db87375795371d77177cc19581b5d736774a53f7d45e63ffa9f92935ec
+** <tt>my_multisig_wallet_for_signer_3.dat</tt>: <pre>b126ed9ebf0d935145d3ff187476e256f875be9ed930ecd1ab805f5125b69e0b1fdbcb176d2b3fa00cb81448ae413cef4a567cdac3cd3d985349ed296f8e578ef5222e91b7c7dd7bff5ae9fc49c545938b256e2d3f526810172e196d8d374569ff3f4a7e3a2c3e67c13fd13bb829dd731b14ec3bef6454616162dd59e4653a7465c5f97ca84ebf25be56907c56c50f1c3a2e3b86ed2d70770db7c04781ef4b9d55feb05f80e0d8125d8427a59ff60dfab68212d8d25c2cad669572864fbb6d554c005fd88b95fab7d5861786d4c335bcda915c8992381c3452d9ab5d4a8f59b49edf6022fd2de1df70c6fc2850ebb4f781fb6efb7bf8faac2871fb15b17d5b9ff8963b48be68a949ce40b7b1a7196ca8cbfe1da2458d0ed8ba2743a05b23cd98a153373f13e7cf9c0b6ed014a2e665d7597736a0761e0dafbb9040260166b5fc90258efce90b37f614c1dcbcae160c990df975767bccba73f1977da4992ba7bdb9009f24641fd122d85293db0d3b3fd19ef3b303c46a452402ef15d214d33445319139ce4346ab638fb8a03948aee27e6d81f95156345ac0af3b8419ae0a8eb62dac21ec4125e4bb168b0454a8b3022ce65f08b304c0712d2f7db0dd00c979f812b61904a6d94f5d3932a385d18084970e0e6b4a4bc661606f3eb6a357a2d7dd05819d03ad8a61d1db87375795371d77177cc19581b5d736774a53f7d45e63ffa9f92935ec</pre>
 
 ==Acknowledgement==
 
-- 
cgit v1.2.3


From 45bc31d83d31a5c688072ac7e060d16f8513aad9 Mon Sep 17 00:00:00 2001
From: Hugo Nguyen <hugh.hn@gmail.com>
Date: Sat, 24 Apr 2021 20:24:30 -0700
Subject: minor edit

---
 bip-hugonguyen-bsms.mediawiki | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/bip-hugonguyen-bsms.mediawiki b/bip-hugonguyen-bsms.mediawiki
index 865827a..32bd063 100644
--- a/bip-hugonguyen-bsms.mediawiki
+++ b/bip-hugonguyen-bsms.mediawiki
@@ -163,11 +163,11 @@ The output descriptor language only supports one-dimensional lists. This proposa
 
 <tt>XPUB/**</tt>
 
-Whereas <tt>**</tt> can be replaced by any number of derivation paths.
+Whereas <tt>/**</tt> can be replaced by any number of derivation path restrictions.
 
-If there is a descriptor template in the descriptor record, Signers should expand the template into concrete descriptors by using the derivations paths provided in the record.
+A descriptor template must be accompanied by derivation path restrictions. Signers should expand the template into concrete descriptors by replacing <tt>/**</tt> with the restrictions.
 
-For example, the following template and derivation paths:
+For example, the following template and derivation path restrictions:
 * <tt>wsh(sortedmulti(2,XPUB1/**,XPUB2/**))</tt>
 * <tt>/0/*,/1/*</tt>
 
-- 
cgit v1.2.3


From de79a73b49aae1dc98fd0c05e548f1b7844c3065 Mon Sep 17 00:00:00 2001
From: Hugo Nguyen <hugh.hn@gmail.com>
Date: Sat, 24 Apr 2021 20:32:36 -0700
Subject: add a test vector for public keys

---
 bip-hugonguyen-bsms.mediawiki | 39 +++++++++++++++++++++++++++++++++++++++
 1 file changed, 39 insertions(+)

diff --git a/bip-hugonguyen-bsms.mediawiki b/bip-hugonguyen-bsms.mediawiki
index 32bd063..60ead63 100644
--- a/bip-hugonguyen-bsms.mediawiki
+++ b/bip-hugonguyen-bsms.mediawiki
@@ -195,6 +195,45 @@ If the parties wish to have stronger privacy, it is recommended to use a higher
 
 ==Test Vectors==
 
+===Mode: <tt>NO_ENCRYPTION</tt> with Public Keys===
+====ROUND 1====
+* Coordinator
+** M-of-N: 1/2
+** ADDRESS_TYPE: NATIVE_SEGWIT
+** TOKEN: 0x00
+
+* Signer 1
+** MASTER_KEY_FINGERPRINT: 2607aabc
+** PRIVATE_KEY (m/48'/0'/0'/2'): L2Vt7N6mHLgcP1A6zLWHsm7G9iGCFPqLwiGQdZsCsHwYfXPuCUHc
+** Public Key (m/48'/0'/0'/2'): 038328f50eb45eada196d02ebb6a3b980be3c0706ded17eaa774d77974c15ae2fe
+** Legacy signature
+** <tt>signer_1_key.bsms</tt>:
+<pre>BSMS 1.0
+05dc6edbff65b399654fd6b837c0e4aa
+[2607aabc/48'/0'/0'/2']038328f50eb45eada196d02ebb6a3b980be3c0706ded17eaa774d77974c15ae2fe
+Signer 1 key
+H7pdMwSJ0JFeFwLTHvO6+IMpnyDtmabtDosdebcD+dMPRNLKD7cvbo4GTN1z5rfbTuKnpHTznexA4d8P9yK3c74=</pre>
+
+* Signer 2
+** MASTER_KEY_FINGERPRINT: 3ff797d2
+** PRIVATE_KEY (m/48'/0'/0'/2'): KxeLc5AVxYtK1yFqroLtqpgjm8YAMrYs66Kfcx28fBk9zg22M4V4
+** Public Key (m/48'/0'/0'/2'): 02d6a29eccd2c7621e7e1ea1c251ef1a18bd5f773392cf66ff40b8ef1cb1b2fe0b
+** Legacy signature
+** <tt>signer_2_key.bsms</tt>:
+<pre>BSMS 1.0
+70f7538ffc8d4f8f52aa8e465581b9a0
+[3ff797d2/48'/0'/0'/2']02d6a29eccd2c7621e7e1ea1c251ef1a18bd5f773392cf66ff40b8ef1cb1b2fe0b
+Signer 2 key
+IBROlN9mAZZFgK92cAp5Ws+EtkOPGGDoESx/oyXb73MdJaZb1/3+vMFw9pYfmpvsbQGMglUoKmHc6AVRmyFIYiE=</pre>
+
+====ROUND 2====
+* Coordinator
+** <tt>my_multisig_wallet.bsms</tt>:
+<pre>BSMS 1.0
+wsh(sortedmulti(1,[2607aabc/48'/0'/0'/2']038328f50eb45eada196d02ebb6a3b980be3c0706ded17eaa774d77974c15ae2fe,[3ff797d2/48'/0'/0'/2']02d6a29eccd2c7621e7e1ea1c251ef1a18bd5f773392cf66ff40b8ef1cb1b2fe0b))#uje27sjy
+No path restrictions
+bc1qfvtnp7aturvmrd5x42mtexqkkktl993n0xpu5sjcnf6nx5dve5zqcxsyda</pre>
+
 ===Mode: <tt>NO_ENCRYPTION</tt>===
 ====ROUND 1====
 * Coordinator
-- 
cgit v1.2.3


From 75bb056596b19d1cb5bd440a83ccd579ffb3188a Mon Sep 17 00:00:00 2001
From: Hugo Nguyen <hugh.hn@gmail.com>
Date: Sat, 24 Apr 2021 20:57:24 -0700
Subject: minor edit

---
 bip-hugonguyen-bsms.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-hugonguyen-bsms.mediawiki b/bip-hugonguyen-bsms.mediawiki
index 60ead63..f0e7abd 100644
--- a/bip-hugonguyen-bsms.mediawiki
+++ b/bip-hugonguyen-bsms.mediawiki
@@ -87,7 +87,7 @@ The Signer is any software or hardware that controls the private keys and can si
 * The Coordinator verifies that the key records have compatible specification versions.
 * The Coordinator verifies that the included <tt>SIG</tt> is valid given the <tt>KEY</tt>.
 * 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 (<tt>BSMS 1.0</tt> 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 accepted derivation paths, to be applied to the template. The paths must start with <tt>/</tt> and use non-hardened derivation. If there are no template or restrictions, it must say <tt>No path restrictions</tt>. 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 first line in the descriptor record must be the specification version (<tt>BSMS 1.0</tt> 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 <tt>/</tt> and use non-hardened derivation. If there are no template or restrictions, it must say <tt>No path restrictions</tt>. 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 <tt>MAC</tt> for the record. The first 16 bytes of the <tt>MAC</tt> serves as the <tt>IV</tt> for the encryption.. 
 * The Coordinator encrypts the descriptor record with the <tt>ENCRYPTION_KEY</tt> and <tt>IV</tt>.
 * The Coordinator encodes the <tt>MAC</tt> and the ciphertext into hexadecimal format, then concatenates the results: <tt>(MAC || ciphertext)</tt>.
-- 
cgit v1.2.3


From e82de1d3bb7313e500e75ed17deeb8463f53b305 Mon Sep 17 00:00:00 2001
From: Hugo Nguyen <hugh.hn@gmail.com>
Date: Sat, 24 Apr 2021 21:02:18 -0700
Subject: minor edit

---
 bip-hugonguyen-bsms.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-hugonguyen-bsms.mediawiki b/bip-hugonguyen-bsms.mediawiki
index f0e7abd..bcde640 100644
--- a/bip-hugonguyen-bsms.mediawiki
+++ b/bip-hugonguyen-bsms.mediawiki
@@ -45,7 +45,7 @@ Concerns #4 and #5 should be handled by Signers and are out of scope of this pro
 ===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 Extension===
+===File Extensions===
 All descriptor and key records should have a <tt>.bsms</tt> file extension. Encrypted data should have a <tt>.dat</tt> extension.
 
 ===Roles===
-- 
cgit v1.2.3


From cf00b456798eedb829f2d247eaf974b9668f5376 Mon Sep 17 00:00:00 2001
From: Hugo Nguyen <hugh.hn@gmail.com>
Date: Sat, 24 Apr 2021 22:00:03 -0700
Subject: upgrade EXTENDED mode to 128-bit

---
 bip-hugonguyen-bsms.mediawiki | 125 +++++++++++++++++++++---------------------
 1 file changed, 61 insertions(+), 64 deletions(-)

diff --git a/bip-hugonguyen-bsms.mediawiki b/bip-hugonguyen-bsms.mediawiki
index bcde640..a5225f0 100644
--- a/bip-hugonguyen-bsms.mediawiki
+++ b/bip-hugonguyen-bsms.mediawiki
@@ -116,11 +116,11 @@ We define three modes of encryption.
 
 # <tt>NO_ENCRYPTION</tt> : the <tt>TOKEN</tt> is set to <tt>0x00</tt>. Encryption is disabled.
 # <tt>STANDARD</tt> : the <tt>TOKEN</tt> is a 64-bit nonce.
-# <tt>EXTENDED</tt> : the <tt>TOKEN</tt> is a 96-bit nonce.
+# <tt>EXTENDED</tt> : the <tt>TOKEN</tt> is a 128-bit nonce.
 
 The <tt>TOKEN</tt> 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 (6 words in <tt>STANDARD</tt> mode; 9 words in <tt>EXTENDED</tt> mode).
+* A mnemonic phrase using [https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki BIP-0039] word list. This would be 6 words in <tt>STANDARD</tt> mode. This encoding is not recommended in <tt>EXTENDED</tt> mode as it can result in potential confusion between seed mnemonics and <tt>TOKEN</tt> mnemonics. 
 * A QR code.
 * Other formats.
 
@@ -341,104 +341,101 @@ bc1qhs4u273g4azq7kqqpe6vh5wfhasfmrq7nheyzsnq77humd7rwtkqagvakf</pre>
 *Coordinator
 ** M-of-N: 2/3
 ** ADDRESS_TYPE: NESTED_SEGWIT
-** TOKEN for Signer 1 (hex): a71ef33a642bd2ef53d2df2c
-*** TOKEN (decimal): 51721413026937653704357240620
-*** TOKEN (mnemonic): poem wasp soldier sign rule jeans exercise fossil club
-*** ENCRYPTION_KEY (hex): c27c4acbe0de3a25f4b3a55f97d1982cb82aa4ff45830f809d036ac2aaf76266
-** TOKEN for Signer 2 (hex): 99d2f458b3b3b42b1e9cf923
-*** TOKEN (decimal): 47606234818469057772362987811
-*** TOKEN (mnemonic): oil nut bike guess deputy better kidney palace casual
-*** ENCRYPTION_KEY (hex): 4775b101cfcce41071e1a9cecb0747485de04b87ebe8dacec402cef67931d2cd
-** TOKEN for Signer 3 (hex): af2f471d6aa8a7b728b9f030
-*** TOKEN (decimal): 54217032062918713649646923824
-*** TOKEN (mnemonic): quality kick shrug stem media swear pepper dignity couch
-*** ENCRYPTION_KEY (hex): a243c05b5ca2bf0c9a53cd68b72d389b63eb63e3016e8f614ea6554c937e47c4
+** 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: 6e359358
-** PRIVATE_KEY (m/48'/0'/0'/1'): L3DkcAeLVhkSnLWBhtDcKn1tsQAd65TekAd2pPSNM26skzLR1p58
-** XPUB (m/48'/0'/0'/1'): xpub6FNL53N3hxLSRi2DbgBNzaZ4548QbkaQ8R1BwxsK47xfoEL6UMbqaLpueeH8K9PtJacrVTCCgd1ac8dQB8hPMTUXpttutwrAtyPfuScQ7YS
+** MASTER_KEY_FINGERPRINT: 793cc70b
+** PRIVATE_KEY (m/48'/0'/0'/1'): L1ZEgZ4zNYxyNc8UyeqwyKW1UHVMp9sxwPgSi3s9SW8mc7KsiSwJ
+** XPUB (m/48'/0'/0'/1'): xpub6ErVmcYYHmavsMgxEcTZyzN5sqth1ZyRpFNJC26ij1wYGC2SBKYrgt9yariSbn7HLRoZUvhUhmPfsRTPrdhhGFscpPZzmch6UTdmRP1aZUj
 ** Legacy signature
 ** <tt>signer_1_key.bsms</tt>:
 <pre>BSMS 1.0
-a71ef33a642bd2ef53d2df2c
-[6e359358/48'/0'/0'/1']xpub6FNL53N3hxLSRi2DbgBNzaZ4548QbkaQ8R1BwxsK47xfoEL6UMbqaLpueeH8K9PtJacrVTCCgd1ac8dQB8hPMTUXpttutwrAtyPfuScQ7YS
+108a2360adb302774eb521daebbeda5e
+[793cc70b/48'/0'/0'/1']xpub6ErVmcYYHmavsMgxEcTZyzN5sqth1ZyRpFNJC26ij1wYGC2SBKYrgt9yariSbn7HLRoZUvhUhmPfsRTPrdhhGFscpPZzmch6UTdmRP1aZUj
 Signer 1 key
-IKRvZ3kFnKpgkZ0Va78ohKxWjX3y0Jy2TKPd3INefSh5d60nIg+3663/drerA/HM8i/jl/vyHhOrydft/6mOwA8=</pre>
+ILG47LpCtjoD9UxL87jo5QFqA90t8g9fDQp/KBojdKgPPGB1pMx2bf9hPdORNZIOdCc/2+Gs6AOs3BEK9ubIuBw=</pre>
 
 * Signer 1 encryption
-** HMAC_KEY (hex): a7dd8a1097f21ad0a36169c6e7aca518d21aecb05e9a7541d5a210394ffd0c23
-** MAC (hex): 79de8f7e6973577b90fa92a53448056fd83529e6e6a6ad326eab0374875ec76f
-** IV (hex) : 79de8f7e6973577b90fa92a53448056f
-** CIPHERTEXT (hex): 11341286cc9acf95b7933a2d416dad8ae3436b1b6f40a3b58e85a6632e6dbf5452d536ac93d29c49cfa153b164c08c4198fb0e043e7f435bedcbeed1c146e94d78f13ddf001682325b68401c70946d71e33267bf17918fac97c196020e317b0d1727f9d73cf87612187b9dfbff7e933fc8d71dd951fdf16b7087b8aaf1ebe54d1b7ae77ca69a82404a2d01d21fd50f0a18c48bac150720d52c02e8c71ed935a946c231a90613222c5085619a09a6428ceafde75479121071061af56a8585dc8d9edf5be9c02360b737eae4871cb661b5132d0bb3aca1dd9092e3c63b4c5c6ec7c0ff1725d17fc1ce305afcb8859389824ddcf5845e3f3aef2e7037aa860bb21adcc828372c0c272e38b2bbf09bca
-** <tt>signer_1_key.dat</tt>: <pre>79de8f7e6973577b90fa92a53448056fd83529e6e6a6ad326eab0374875ec76f11341286cc9acf95b7933a2d416dad8ae3436b1b6f40a3b58e85a6632e6dbf5452d536ac93d29c49cfa153b164c08c4198fb0e043e7f435bedcbeed1c146e94d78f13ddf001682325b68401c70946d71e33267bf17918fac97c196020e317b0d1727f9d73cf87612187b9dfbff7e933fc8d71dd951fdf16b7087b8aaf1ebe54d1b7ae77ca69a82404a2d01d21fd50f0a18c48bac150720d52c02e8c71ed935a946c231a90613222c5085619a09a6428ceafde75479121071061af56a8585dc8d9edf5be9c02360b737eae4871cb661b5132d0bb3aca1dd9092e3c63b4c5c6ec7c0ff1725d17fc1ce305afcb8859389824ddcf5845e3f3aef2e7037aa860bb21adcc828372c0c272e38b2bbf09bca</pre>
+** HMAC_KEY (hex): 1162cdace4ac9fcde1f96924b93714143d057a701de83ebaed248d1c9154f9fd
+** MAC (hex): ea12776c73de4bd5ea57c2d19eb8e0be856ac0d7f5651f7b74be4563d61ba5b1
+** IV (hex) : ea12776c73de4bd5ea57c2d19eb8e0be
+** CIPHERTEXT (hex): a36f34232bff47a853092654a718fea4f5f57d6a1f3d38fede04e2414da12c90cefc24ef662f736886d9a7fd6e7db636ca47217803c86b7fbcebe4ad6b71cffc261069c135bd2b2430fb2b446ff0203df34fbbc6801243e8a930b9d0cd3a9b160b8dcdc9131ce6e97641e6314b3285ff341013f302e308c1b2eba7ced0103a8999fe2bd86f844392938e7926cd26d023b764d0b8ff92b2fbdf995884c738414b83563ef2a0050279bf46d0e8271ea5d6af8154847c5736129a7a83a35a3cc747b2be4b389886cb57456678353b60473ebc4ab85d9c9131a17a1e288717343d9008825b16c48d7e93927f37b530033192c67b70dec0411a3e5952d2525c7eb80721676e1a6299248c17f8078202f3bb0932e9f263b0ab
+** <tt>signer_1_key.dat</tt>: <pre>ea12776c73de4bd5ea57c2d19eb8e0be856ac0d7f5651f7b74be4563d61ba5b1a36f34232bff47a853092654a718fea4f5f57d6a1f3d38fede04e2414da12c90cefc24ef662f736886d9a7fd6e7db636ca47217803c86b7fbcebe4ad6b71cffc261069c135bd2b2430fb2b446ff0203df34fbbc6801243e8a930b9d0cd3a9b160b8dcdc9131ce6e97641e6314b3285ff341013f302e308c1b2eba7ced0103a8999fe2bd86f844392938e7926cd26d023b764d0b8ff92b2fbdf995884c738414b83563ef2a0050279bf46d0e8271ea5d6af8154847c5736129a7a83a35a3cc747b2be4b389886cb57456678353b60473ebc4ab85d9c9131a17a1e288717343d9008825b16c48d7e93927f37b530033192c67b70dec0411a3e5952d2525c7eb80721676e1a6299248c17f8078202f3bb0932e9f263b0ab</pre>
 
 * Signer 2
-** MASTER_KEY_FINGERPRINT: 478740ec
-** PRIVATE_KEY (m/48'/0'/0'/1'): KzdFU8eiwuCtoBSkkyzWZVS55BpvT6opJt2u8kVmsMpMrJarBowJ
-** XPUB (m/48'/0'/0'/1'): xpub6EYCJXggYLmwbFgkhwcFAauukuEqGUi9Wj7YoL5YerCxGom82v6ioSgzjcW9iadLqSV9XihXHXKey61jwv1cZykPRhwzxhCDQBJompv6Gdv
+** MASTER_KEY_FINGERPRINT: b3118e52
+** PRIVATE_KEY (m/48'/0'/0'/1'): L4SnPjcHszMg3Wi2YYxEYnzM2zFeFkFr5NcLZ18YQeyJwaSFbTud
+** XPUB (m/48'/0'/0'/1'): xpub6Du5Jn6eYZE96ccmAc1ZTFPzdnzrvqfG4mpamDun2qZYKywoiQJMCbS3kWWMr6U3XW6s125RLsaPABWgv2yA749ieaMe67FxkTjMsbcxCch
 ** Legacy signature
 ** <tt>signer_2_key.bsms</tt>:
 <pre>BSMS 1.0
-99d2f458b3b3b42b1e9cf923
-[478740ec/48'/0'/0'/1']xpub6EYCJXggYLmwbFgkhwcFAauukuEqGUi9Wj7YoL5YerCxGom82v6ioSgzjcW9iadLqSV9XihXHXKey61jwv1cZykPRhwzxhCDQBJompv6Gdv
+d3fabc873b98165254fe18a71b5335b0
+[b3118e52/48'/0'/0'/1']xpub6Du5Jn6eYZE96ccmAc1ZTFPzdnzrvqfG4mpamDun2qZYKywoiQJMCbS3kWWMr6U3XW6s125RLsaPABWgv2yA749ieaMe67FxkTjMsbcxCch
 Signer 2 key
-Hwe3RlD/a/MEqsLUWKJvSLOKvEx2uRBe7TvCJSZTfk1iKNy9BnsC08Rt78kBIHnoyL+QFmBnXQgywnJrmxlJLM4=</pre>
+IDK4d/oO0pgfrwRu4Zb8vqlPEmJb9aKT1K2CCnI3RKepVAKs3fZsBrypcCdQfUy1TG/3O5vAR3gjldxcCA1Wzg8=</pre>
 
 * Signer 2 encryption
-** HMAC_KEY (hex): 3973f29e11405adaa9df7e15484e26df8dea82a48c8461011fcb173420b46ea9
-** MAC (hex): 3a225aaa6424fcc4e071da2fa601ac502c4a2456cad0b133ea613b1c54890583
-** IV (hex) : 3a225aaa6424fcc4e071da2fa601ac50
-** CIPHERTEXT (hex): d23efeb048417c1677c4db0de69ccaedd2648822727f7151c96b7c364ddee75665c2c49bd4caf3b61e2cafc3366c50a72844d47c3a1e6d0dbf263e7507846e3a12a339d475a333aec33b3b15343d58a70e88ed9affc1159bd68a865ef8293e05020b8f019ca0df80522777063a96c48fdc2f89504ba5571df31ba31285eb0063fafd973aae93ebf9a581b7580cdc08d4aa77b08a175c5e06198fa9c8eefc6dd5969664e28f2098751c5a2576ce28d55baf2dd7897cd5ddb08d2b2a979fbfa066e139d7f11d6948a5298cb3b41b15272fda24ac16eb6aacc9e2ab80b317c0aca173451a892006798e31a3a50b38ec9d8419863765dd5fa2d030d46df8e71c425deb866db8f0b9c4aa34825dcfe93c
-** <tt>signer_2_key.dat</tt>: <pre>3a225aaa6424fcc4e071da2fa601ac502c4a2456cad0b133ea613b1c54890583d23efeb048417c1677c4db0de69ccaedd2648822727f7151c96b7c364ddee75665c2c49bd4caf3b61e2cafc3366c50a72844d47c3a1e6d0dbf263e7507846e3a12a339d475a333aec33b3b15343d58a70e88ed9affc1159bd68a865ef8293e05020b8f019ca0df80522777063a96c48fdc2f89504ba5571df31ba31285eb0063fafd973aae93ebf9a581b7580cdc08d4aa77b08a175c5e06198fa9c8eefc6dd5969664e28f2098751c5a2576ce28d55baf2dd7897cd5ddb08d2b2a979fbfa066e139d7f11d6948a5298cb3b41b15272fda24ac16eb6aacc9e2ab80b317c0aca173451a892006798e31a3a50b38ec9d8419863765dd5fa2d030d46df8e71c425deb866db8f0b9c4aa34825dcfe93c</pre>
+** HMAC_KEY (hex): 43a4e704bd1bade703023004b00290f1a7b005474a581d869a217068eedf3f57
+** MAC (hex): 4a3ff970d027010e83b4fbf2845a23907a301b3df692a9265e2ca679697ac718
+** IV (hex) : 4a3ff970d027010e83b4fbf2845a2390
+** CIPHERTEXT (hex): c8f4a6a6714eff90aa48cbefe6750c2ee3cc72182eb455e964f0ba59ada3ecd758c29f0fab7e33aaa82a340a18d9c793ddab09dc7e714864faac1ecea370d4f102533b739da38aa0491433f35eadec08f203685f04d1f6ec35d397d99e4f8096a5691075e3f54fd9ff58faf947f276bbe1031f827b274bd2f60fcb526add7058889104b189d7da22ac7be1f7ddd380bbebd5c6983a8a3c5fa86913e3d23c40935072ce03d9bdeb07791dc836d44b4d4c62f364d0e4f3580369ea8f6ebb774b7fda4a7ac6f5ae6b2f52b10cd71bdf3cdb5889e77d5eb1f2f647b798cdd6b3e5b964c9265daea3668d7e4cb53f724151923da1a87bbcd2abd8b164de474d865c51af69885431d26f88a5c8eea7d0dfdb52ca622017808a
+** <tt>signer_2_key.dat</tt>: <pre>4a3ff970d027010e83b4fbf2845a23907a301b3df692a9265e2ca679697ac718c8f4a6a6714eff90aa48cbefe6750c2ee3cc72182eb455e964f0ba59ada3ecd758c29f0fab7e33aaa82a340a18d9c793ddab09dc7e714864faac1ecea370d4f102533b739da38aa0491433f35eadec08f203685f04d1f6ec35d397d99e4f8096a5691075e3f54fd9ff58faf947f276bbe1031f827b274bd2f60fcb526add7058889104b189d7da22ac7be1f7ddd380bbebd5c6983a8a3c5fa86913e3d23c40935072ce03d9bdeb07791dc836d44b4d4c62f364d0e4f3580369ea8f6ebb774b7fda4a7ac6f5ae6b2f52b10cd71bdf3cdb5889e77d5eb1f2f647b798cdd6b3e5b964c9265daea3668d7e4cb53f724151923da1a87bbcd2abd8b164de474d865c51af69885431d26f88a5c8eea7d0dfdb52ca622017808a</pre>
 
 * Signer 3
-** MASTER_KEY_FINGERPRINT: ff6be335
-** PRIVATE_KEY (m/48'/0'/0'/1'): L35ukMXHBwwVgzSEc6RLM4GKoLmC1e1KeujC8nqXbD63iPb8BRkJ
-** XPUB (m/48'/0'/0'/1'): xpub6EUJJMcoJFhsnyCzNzQNU9caFNHkvK1Y8iyUoufbWV4Uyq1rK594SZ7mz5NREF6aowE845sGmPY4KnMgXezy43Sp2FGE9UgsaMQD5bcBaGX
+** MASTER_KEY_FINGERPRINT: 842bd2ed
+** PRIVATE_KEY (m/48'/0'/0'/1'): L1ehZHpo2UFHc1yaBWDU4bKVycUwcU2TESm92wbfq6xK6qpZZJP6
+** XPUB (m/48'/0'/0'/1'): xpub6Ex81KopPkEt9hJiWHabYy8LNsSR4A7sUQoFBk9dR8XxHrr4p9HrYWN3NCf5uwfopHnQkCG7FYnZMztKbtRtbh6tzZC4xtHPbmVVxRSN7ic
 ** Legacy signature
 ** <tt>signer_3_key.bsms</tt>:
 <pre>BSMS 1.0
-af2f471d6aa8a7b728b9f030
-[ff6be335/48'/0'/0'/1']xpub6EUJJMcoJFhsnyCzNzQNU9caFNHkvK1Y8iyUoufbWV4Uyq1rK594SZ7mz5NREF6aowE845sGmPY4KnMgXezy43Sp2FGE9UgsaMQD5bcBaGX
+78a7d5e7549453d719150de5459c9ce5
+[842bd2ed/48'/0'/0'/1']xpub6Ex81KopPkEt9hJiWHabYy8LNsSR4A7sUQoFBk9dR8XxHrr4p9HrYWN3NCf5uwfopHnQkCG7FYnZMztKbtRtbh6tzZC4xtHPbmVVxRSN7ic
 Signer 3 key
-H3EcehsCYhHx9jRbqrqWRuRcd2gJMGBhrsCbiYRvhe9ycfVAtxeeX2tWmtAIvlLc2ye9Ad9QI6iZUnVULAFMrEI=</pre>
+IL77mML0xo/O9dJn0T5EpQLuyRPPrdpgVJbtsdAugW5iX0MQ3Ci0f8jVnXu68Xm07CYjYGKX8af72jmkQKhNud0=</pre>
 
 * Signer 3 encryption
-** HMAC_KEY (hex): 330f062ad717fffea29292f763f2e81188ba99a3b6315436ffcb47dc06208da3
-** MAC (hex): 9879fd1456a53bf806c98d3ffc2856000f27a9a7f1eb3c77701165f16882188a
-** IV (hex) : 9879fd1456a53bf806c98d3ffc285600
-** CIPHERTEXT (hex): fa034e67bdab25b8b35c490c56e792f24140f8f76cb1a429ee39da53b978cc2954349238cff09fe915b502a3a75326ee9a605c76f971560b2a101927f48916724062ad7d25f97182a11d17d6da745ddcf84ee794214f629971d6a6599179fd170475678aa985e0fd75646516383c8e56c2eeff975ab9d20b75899e1f39f0c02d114495b71733fd29542feea6e7b10a5b4ee32db11d3668776e7f0d6800212d29ca4b173a01e210e61f04bfea05e36bc4f9ac49e1c4e3f7e8e48aaaa1275e1ed6c4f5e2faf3a1fdd4953d8796d1104ac2aee6422fc70521a0ce0bd92828d9fc9411e614cc1ba26c9f402bb3d29823b3f253c00b4bccf42c829b9aa687fb490bb18d7991f22998dd281a80fe865cc6
-** <tt>signer_3_key.dat</tt>: <pre>9879fd1456a53bf806c98d3ffc2856000f27a9a7f1eb3c77701165f16882188afa034e67bdab25b8b35c490c56e792f24140f8f76cb1a429ee39da53b978cc2954349238cff09fe915b502a3a75326ee9a605c76f971560b2a101927f48916724062ad7d25f97182a11d17d6da745ddcf84ee794214f629971d6a6599179fd170475678aa985e0fd75646516383c8e56c2eeff975ab9d20b75899e1f39f0c02d114495b71733fd29542feea6e7b10a5b4ee32db11d3668776e7f0d6800212d29ca4b173a01e210e61f04bfea05e36bc4f9ac49e1c4e3f7e8e48aaaa1275e1ed6c4f5e2faf3a1fdd4953d8796d1104ac2aee6422fc70521a0ce0bd92828d9fc9411e614cc1ba26c9f402bb3d29823b3f253c00b4bccf42c829b9aa687fb490bb18d7991f22998dd281a80fe865cc6</pre>
+** HMAC_KEY (hex): ab93ce7bf0f91c62a66d00ea9bf5e5c00b854ee2cfc2fb06f6eeff738abcdc26
+** MAC (hex): e82cfcccbd4bd4d3b76e28133eecd13f7362f4a8b4c4baa3e5f6ba2dfb4d69b8
+** IV (hex) : e82cfcccbd4bd4d3b76e28133eecd13f
+** CIPHERTEXT (hex): b44433f0b564ec35a1e71371f25844088084b47402c90d52fee7237167b58a60a28c234af9123e104773136e8446d799541c8566882787caee7cd1fa8628aba63aa9e9d7cca0ddee92f96dd881535b19a131a1f487a1909e42d62945fd0ba08dacd7dc09a22ffe47e0410b8b85df92e4a8bbf9b46f0062da02e3ae94144a00bae917acc1246d8d1a4dca105708f55379caefef9d4c152f56b65ab4bd7b48f60233f57ba6d705387c79aeaa2a279e3314004bf16fcd7e7d2adef34b0ab3c22bc5461f2c09dce69065605e4fb96958c55984391712b3547e3914ad4ecca2c088be280dfcfe374a112515674aeca57b885e81dbef6a353ca387f4514db3158eb69f0d2725d42ad8102c05c26ad501d48b889c624035ead4
+** <tt>signer_3_key.dat</tt>: <pre>e82cfcccbd4bd4d3b76e28133eecd13f7362f4a8b4c4baa3e5f6ba2dfb4d69b8b44433f0b564ec35a1e71371f25844088084b47402c90d52fee7237167b58a60a28c234af9123e104773136e8446d799541c8566882787caee7cd1fa8628aba63aa9e9d7cca0ddee92f96dd881535b19a131a1f487a1909e42d62945fd0ba08dacd7dc09a22ffe47e0410b8b85df92e4a8bbf9b46f0062da02e3ae94144a00bae917acc1246d8d1a4dca105708f55379caefef9d4c152f56b65ab4bd7b48f60233f57ba6d705387c79aeaa2a279e3314004bf16fcd7e7d2adef34b0ab3c22bc5461f2c09dce69065605e4fb96958c55984391712b3547e3914ad4ecca2c088be280dfcfe374a112515674aeca57b885e81dbef6a353ca387f4514db3158eb69f0d2725d42ad8102c05c26ad501d48b889c624035ead4</pre>
 
 ====ROUND 2====
 * Coordinator
 ** <tt>my_multisig_wallet.bsms</tt>:
 <pre>BSMS 1.0
-sh(wsh(multi(2,[6e359358/48'/0'/0'/1']xpub6FNL53N3hxLSRi2DbgBNzaZ4548QbkaQ8R1BwxsK47xfoEL6UMbqaLpueeH8K9PtJacrVTCCgd1ac8dQB8hPMTUXpttutwrAtyPfuScQ7YS/**,[478740ec/48'/0'/0'/1']xpub6EYCJXggYLmwbFgkhwcFAauukuEqGUi9Wj7YoL5YerCxGom82v6ioSgzjcW9iadLqSV9XihXHXKey61jwv1cZykPRhwzxhCDQBJompv6Gdv/**,[ff6be335/48'/0'/0'/1']xpub6EUJJMcoJFhsnyCzNzQNU9caFNHkvK1Y8iyUoufbWV4Uyq1rK594SZ7mz5NREF6aowE845sGmPY4KnMgXezy43Sp2FGE9UgsaMQD5bcBaGX/**)))
+sh(wsh(multi(2,[793cc70b/48'/0'/0'/1']xpub6ErVmcYYHmavsMgxEcTZyzN5sqth1ZyRpFNJC26ij1wYGC2SBKYrgt9yariSbn7HLRoZUvhUhmPfsRTPrdhhGFscpPZzmch6UTdmRP1aZUj/**,[b3118e52/48'/0'/0'/1']xpub6Du5Jn6eYZE96ccmAc1ZTFPzdnzrvqfG4mpamDun2qZYKywoiQJMCbS3kWWMr6U3XW6s125RLsaPABWgv2yA749ieaMe67FxkTjMsbcxCch/**,[842bd2ed/48'/0'/0'/1']xpub6Ex81KopPkEt9hJiWHabYy8LNsSR4A7sUQoFBk9dR8XxHrr4p9HrYWN3NCf5uwfopHnQkCG7FYnZMztKbtRtbh6tzZC4xtHPbmVVxRSN7ic/**)))
 /0/*,/1/*
-3A4tfQoLviGREWmVuHN9WNLuo81nPtRv2W</pre>
+3GzMtFXahiu4TpGNGFc4bHMvAcvz5vVQrT</pre>
 
 * Send to Signer 1:
-** HMAC_KEY (hex): a7dd8a1097f21ad0a36169c6e7aca518d21aecb05e9a7541d5a210394ffd0c23
-** MAC (hex): 91798c713660b9eea04aed38bb83e10e998b04fd1fb887c42a6062c0b2a96528
-** IV (hex) : 91798c713660b9eea04aed38bb83e10e
-** CIPHERTEXT (hex): 7cd33615188054d07ca049f5aad956a36a14f4ea5eddaeceb0887d489f3981952ddd56f37236b515caf52aca9e2b2a4a365e93e3c9ab7cc96cfc3886df698e20faf860d30b8893cacc51fa99a623cceb02985f3876244f6a861611761123578bff9bcea8d958b4854c66385485ec5b299a46fc2900ee861b890889580a435b4f92ff2e19172eceb8f257e66b6c11b3d314293bfdcaee4c9991e0e27b3c3d5e43419c7749eca0074d51e9b3e9fd85ab61727574a6e79c77cba746a349ea4c5eade184a90461a6c1d5e6381ea9e6483be16159bfa2fbe911b31761087091041f352a65842bca9cb66bd8e9069f9872ecc021351dee29d8e4e3c0704e96974fe8ba8e2a4677f3b26c64f3b8cf793754ea5bbbe86d933ea8b7837fbb63d410e7690e7e27cb675da178df7b298050a8795c5cd24b840925f2d3e0007751200065088f5c612d9b7bfa55011577066a8d219094ac4516e958790c7d483ab48fd5a73a4897acbf91c85f6b7bfe50272273f7aa003ebf6860de51e0c905b427cde61699bb88ade90a1ae1adbd9b12deed4ae5988791fd989567a34ad1c9916dca95ac86d4689ab38182df973f2d1c2bc7968726ef1f503ba50a6a65356f536d3173af8db9ddb344520dc57ac03a5576795b7a7abc714349024675c89803422044f6339eecd701b3bbed
-** <tt>my_multisig_wallet_for_signer_1.dat</tt>: <pre>91798c713660b9eea04aed38bb83e10e998b04fd1fb887c42a6062c0b2a965287cd33615188054d07ca049f5aad956a36a14f4ea5eddaeceb0887d489f3981952ddd56f37236b515caf52aca9e2b2a4a365e93e3c9ab7cc96cfc3886df698e20faf860d30b8893cacc51fa99a623cceb02985f3876244f6a861611761123578bff9bcea8d958b4854c66385485ec5b299a46fc2900ee861b890889580a435b4f92ff2e19172eceb8f257e66b6c11b3d314293bfdcaee4c9991e0e27b3c3d5e43419c7749eca0074d51e9b3e9fd85ab61727574a6e79c77cba746a349ea4c5eade184a90461a6c1d5e6381ea9e6483be16159bfa2fbe911b31761087091041f352a65842bca9cb66bd8e9069f9872ecc021351dee29d8e4e3c0704e96974fe8ba8e2a4677f3b26c64f3b8cf793754ea5bbbe86d933ea8b7837fbb63d410e7690e7e27cb675da178df7b298050a8795c5cd24b840925f2d3e0007751200065088f5c612d9b7bfa55011577066a8d219094ac4516e958790c7d483ab48fd5a73a4897acbf91c85f6b7bfe50272273f7aa003ebf6860de51e0c905b427cde61699bb88ade90a1ae1adbd9b12deed4ae5988791fd989567a34ad1c9916dca95ac86d4689ab38182df973f2d1c2bc7968726ef1f503ba50a6a65356f536d3173af8db9ddb344520dc57ac03a5576795b7a7abc714349024675c89803422044f6339eecd701b3bbed</pre>
+** HMAC_KEY (hex): 1162cdace4ac9fcde1f96924b93714143d057a701de83ebaed248d1c9154f9fd
+** MAC (hex): 01bf557b6d44b3fbf07f8ec155cbdec42d85d856e174342563dd83b40ad7c025
+** IV (hex) : 01bf557b6d44b3fbf07f8ec155cbdec4
+** CIPHERTEXT (hex): 617ed25b4b8fd88b806cbebcc1731b071465514a805f7ba2de60e291bc9493f31aa0f9b0665ba822cf9a2e21c02649b5c3f7dbad317ae898292cb6fe992520f68c0ebe9d1434b348af10453f1be0a392a616d43ba21e5e7fa3c995dce54db947fe5dbad4a9a77f37b3aef58c54ee3e496c8312d3033359aed0de8cf28b82035ee7a38c9b23c9d95682fb15936bf2247546d2ba9b3ada605f5c89f0a3bbaa86cb4b5dded9a65004912c0afbbfd01f0115447f5625e8523f9de16165d32c4b21103d8ac965e2f7e17641ee1a8c5902e8dbb461c6c7d05141f7bba66b8b3608037fb251b55fa461c9441c6427921545a34a1798127d5bf9cc92423f7e62c769e232c65db8cc5124577012d49941143c3b4758212a8afa0475c9b3597da2e99d585039339b7d73611aa277878d212875051683053db9c630391e0b32356523e9fa8a58a334e16fe6650472f336ddaa8c587992b6c0c0e480b680261579a11cf9d036614abc113dde53653273f5ce82ea0bc10e38ca52ac66838aa49ff46c3a7d5096db439c15d3c2e8de55e4ac7315a57eb9997f219c378af86c858867ce583ed84e4d9c68aecfbca9ebff16b0ac91531125e273b215db688ffe52c8033eb78914b87c0fa2001c52e90c92765712e50384ddcf4d0953ac3cc8137abcb2a85d603a6cc207472677
+** <tt>my_multisig_wallet_for_signer_1.dat</tt>: <pre>01bf557b6d44b3fbf07f8ec155cbdec42d85d856e174342563dd83b40ad7c025617ed25b4b8fd88b806cbebcc1731b071465514a805f7ba2de60e291bc9493f31aa0f9b0665ba822cf9a2e21c02649b5c3f7dbad317ae898292cb6fe992520f68c0ebe9d1434b348af10453f1be0a392a616d43ba21e5e7fa3c995dce54db947fe5dbad4a9a77f37b3aef58c54ee3e496c8312d3033359aed0de8cf28b82035ee7a38c9b23c9d95682fb15936bf2247546d2ba9b3ada605f5c89f0a3bbaa86cb4b5dded9a65004912c0afbbfd01f0115447f5625e8523f9de16165d32c4b21103d8ac965e2f7e17641ee1a8c5902e8dbb461c6c7d05141f7bba66b8b3608037fb251b55fa461c9441c6427921545a34a1798127d5bf9cc92423f7e62c769e232c65db8cc5124577012d49941143c3b4758212a8afa0475c9b3597da2e99d585039339b7d73611aa277878d212875051683053db9c630391e0b32356523e9fa8a58a334e16fe6650472f336ddaa8c587992b6c0c0e480b680261579a11cf9d036614abc113dde53653273f5ce82ea0bc10e38ca52ac66838aa49ff46c3a7d5096db439c15d3c2e8de55e4ac7315a57eb9997f219c378af86c858867ce583ed84e4d9c68aecfbca9ebff16b0ac91531125e273b215db688ffe52c8033eb78914b87c0fa2001c52e90c92765712e50384ddcf4d0953ac3cc8137abcb2a85d603a6cc207472677</pre>
 
 * Send to Signer 2:
-** HMAC_KEY (hex): 3973f29e11405adaa9df7e15484e26df8dea82a48c8461011fcb173420b46ea9
-** MAC (hex): 6cfb40b2ecbde71752e3d273afe190add5ae2dfc93ee4499e1f2c3ea5f5033fe
-** IV (hex) : 6cfb40b2ecbde71752e3d273afe190ad
-** CIPHERTEXT (hex): 965344af904b244a8b943fb6af95f813cb138a37b29e9556a8eb8553347ce7c447f28892b4d3e4d449be767ba9cf4cbe07db86e38585fc9be8d6843edcb52e738405a4ae9d042866fcd77438d1d2e0e9ff5b09dc71d8eb07a2ce41de605189687d6a6873a320b99d0bbc314c76c2e4ec172db5cfbb7661a4e656ca4ba016c8f8e6441721170e5c7b10c5648726d7e546ce58d54d4aa73d37ef27b3968bc7f3ec5c592993fc63a6a3664854f7427ab41c6fac12d0a84e3221a8bc8518217810bf9bda4b2c9962e028041e3840430634600daa6544c3d12403c0aba59ad32a7848311eac1bb956b36770c4166307157a3047078a57c7a93989988d176f2c5d531705e9d523b4672643c3ee05a570c41079267bc128d8a2533cf1dd18f17e7792c2ebb3d0e9ff4ac8522f5163e6ea5ca1ecc24d87ab8b05e4fd93ce8a443c952c01734cde5943b87f4b0bba73ac48d5d151b6ea774f2b39c36739fdf16817ef32afbfa34afd2f919b9f755b7b850f2f08e0e2b9b82ca8b668b7c1db1a218b7ecc8c7e5726808c4bd3a9a4f85098213d2f29040763c9656bef84a5218db39124b56df24d7457f943704964336cf4e196e7a4575b7624a3e0b210164e8cdb078b816cc88622420f60fdb98702031e6675b85087844b5ded9b4b29258c2a050f5bb42a13a3cab8ba
-** <tt>my_multisig_wallet_for_signer_2.dat</tt>: <pre>6cfb40b2ecbde71752e3d273afe190add5ae2dfc93ee4499e1f2c3ea5f5033fe965344af904b244a8b943fb6af95f813cb138a37b29e9556a8eb8553347ce7c447f28892b4d3e4d449be767ba9cf4cbe07db86e38585fc9be8d6843edcb52e738405a4ae9d042866fcd77438d1d2e0e9ff5b09dc71d8eb07a2ce41de605189687d6a6873a320b99d0bbc314c76c2e4ec172db5cfbb7661a4e656ca4ba016c8f8e6441721170e5c7b10c5648726d7e546ce58d54d4aa73d37ef27b3968bc7f3ec5c592993fc63a6a3664854f7427ab41c6fac12d0a84e3221a8bc8518217810bf9bda4b2c9962e028041e3840430634600daa6544c3d12403c0aba59ad32a7848311eac1bb956b36770c4166307157a3047078a57c7a93989988d176f2c5d531705e9d523b4672643c3ee05a570c41079267bc128d8a2533cf1dd18f17e7792c2ebb3d0e9ff4ac8522f5163e6ea5ca1ecc24d87ab8b05e4fd93ce8a443c952c01734cde5943b87f4b0bba73ac48d5d151b6ea774f2b39c36739fdf16817ef32afbfa34afd2f919b9f755b7b850f2f08e0e2b9b82ca8b668b7c1db1a218b7ecc8c7e5726808c4bd3a9a4f85098213d2f29040763c9656bef84a5218db39124b56df24d7457f943704964336cf4e196e7a4575b7624a3e0b210164e8cdb078b816cc88622420f60fdb98702031e6675b85087844b5ded9b4b29258c2a050f5bb42a13a3cab8ba</pre>
+** HMAC_KEY (hex): 43a4e704bd1bade703023004b00290f1a7b005474a581d869a217068eedf3f57
+** MAC (hex): 974ba77900c43c463dadaa6eaf24aaeb1b25b443cf155229b719bcbf8b343092
+** IV (hex) : 974ba77900c43c463dadaa6eaf24aaeb
+** CIPHERTEXT (hex): 86288c97a6341974a35015f97fbbc8db7655639c839fc438706f82fce36a82dd17e2d4d4a674516c4fc5c3a33d6097dd8fc5c6605018946741ed9f58d8fe530a808f16f0dd705cacfd273e34a158bd7566774dd31506b8280e448fabb72d0e7dfc05cee1142b61921dfaf0b0039d885cc0aa76c429025efc2ba49a8af15b58e75a5a83ba4838a9a4c9f13725f5aecefd8511513d93797f37b93150b9dca725685883188e39142dd8d3cf4b617c7936bdb3875415bbf6dfb2fe1a39ae2aed9fd2909aebd0355a5cc9a55bcb84048c851a1873948e495180f336edeb63f54bcf83feaa4d2453251260e24293e49815c2369c1c045083c412c973987fd7c9296a71cda424823ed32380ba442394500b7d2d2335818099090aaf08ca4e180869c546f58da4cb4ff0f95b796a35c40ea455e2ddd3e08bc494ffddc706aaf4d479f4f359e6a89a90df7c9b8f23cab355855a72b90795a0db83a96bce0dd4f77e3f58c0957b4ffe9663251565098e6c31fd4bbf3e1295faaff05e29912d9c37cb944da379a9b2193b466910d05a681e53a2dbe5aa18a2b4874153fe36d8a1aa4cc6e612bd6dbc9abb8e1e61b927fc5458d8e1be9536cd462e4c37672af7928c39e94bdc124a2da7b1bd3cad2cfe559adc33e62eb45bff89db8a47a72dda4f49f21c01a9432f4802a1
+** <tt>my_multisig_wallet_for_signer_2.dat</tt>: <pre>974ba77900c43c463dadaa6eaf24aaeb1b25b443cf155229b719bcbf8b34309286288c97a6341974a35015f97fbbc8db7655639c839fc438706f82fce36a82dd17e2d4d4a674516c4fc5c3a33d6097dd8fc5c6605018946741ed9f58d8fe530a808f16f0dd705cacfd273e34a158bd7566774dd31506b8280e448fabb72d0e7dfc05cee1142b61921dfaf0b0039d885cc0aa76c429025efc2ba49a8af15b58e75a5a83ba4838a9a4c9f13725f5aecefd8511513d93797f37b93150b9dca725685883188e39142dd8d3cf4b617c7936bdb3875415bbf6dfb2fe1a39ae2aed9fd2909aebd0355a5cc9a55bcb84048c851a1873948e495180f336edeb63f54bcf83feaa4d2453251260e24293e49815c2369c1c045083c412c973987fd7c9296a71cda424823ed32380ba442394500b7d2d2335818099090aaf08ca4e180869c546f58da4cb4ff0f95b796a35c40ea455e2ddd3e08bc494ffddc706aaf4d479f4f359e6a89a90df7c9b8f23cab355855a72b90795a0db83a96bce0dd4f77e3f58c0957b4ffe9663251565098e6c31fd4bbf3e1295faaff05e29912d9c37cb944da379a9b2193b466910d05a681e53a2dbe5aa18a2b4874153fe36d8a1aa4cc6e612bd6dbc9abb8e1e61b927fc5458d8e1be9536cd462e4c37672af7928c39e94bdc124a2da7b1bd3cad2cfe559adc33e62eb45bff89db8a47a72dda4f49f21c01a9432f4802a1</pre>
 
 * Send to Signer 3:
-** HMAC_KEY (hex): 330f062ad717fffea29292f763f2e81188ba99a3b6315436ffcb47dc06208da3
-** MAC (hex): b126ed9ebf0d935145d3ff187476e256f875be9ed930ecd1ab805f5125b69e0b
-** IV (hex) : b126ed9ebf0d935145d3ff187476e256
-** CIPHERTEXT (hex): 1fdbcb176d2b3fa00cb81448ae413cef4a567cdac3cd3d985349ed296f8e578ef5222e91b7c7dd7bff5ae9fc49c545938b256e2d3f526810172e196d8d374569ff3f4a7e3a2c3e67c13fd13bb829dd731b14ec3bef6454616162dd59e4653a7465c5f97ca84ebf25be56907c56c50f1c3a2e3b86ed2d70770db7c04781ef4b9d55feb05f80e0d8125d8427a59ff60dfab68212d8d25c2cad669572864fbb6d554c005fd88b95fab7d5861786d4c335bcda915c8992381c3452d9ab5d4a8f59b49edf6022fd2de1df70c6fc2850ebb4f781fb6efb7bf8faac2871fb15b17d5b9ff8963b48be68a949ce40b7b1a7196ca8cbfe1da2458d0ed8ba2743a05b23cd98a153373f13e7cf9c0b6ed014a2e665d7597736a0761e0dafbb9040260166b5fc90258efce90b37f614c1dcbcae160c990df975767bccba73f1977da4992ba7bdb9009f24641fd122d85293db0d3b3fd19ef3b303c46a452402ef15d214d33445319139ce4346ab638fb8a03948aee27e6d81f95156345ac0af3b8419ae0a8eb62dac21ec4125e4bb168b0454a8b3022ce65f08b304c0712d2f7db0dd00c979f812b61904a6d94f5d3932a385d18084970e0e6b4a4bc661606f3eb6a357a2d7dd05819d03ad8a61d1db87375795371d77177cc19581b5d736774a53f7d45e63ffa9f92935ec
-** <tt>my_multisig_wallet_for_signer_3.dat</tt>: <pre>b126ed9ebf0d935145d3ff187476e256f875be9ed930ecd1ab805f5125b69e0b1fdbcb176d2b3fa00cb81448ae413cef4a567cdac3cd3d985349ed296f8e578ef5222e91b7c7dd7bff5ae9fc49c545938b256e2d3f526810172e196d8d374569ff3f4a7e3a2c3e67c13fd13bb829dd731b14ec3bef6454616162dd59e4653a7465c5f97ca84ebf25be56907c56c50f1c3a2e3b86ed2d70770db7c04781ef4b9d55feb05f80e0d8125d8427a59ff60dfab68212d8d25c2cad669572864fbb6d554c005fd88b95fab7d5861786d4c335bcda915c8992381c3452d9ab5d4a8f59b49edf6022fd2de1df70c6fc2850ebb4f781fb6efb7bf8faac2871fb15b17d5b9ff8963b48be68a949ce40b7b1a7196ca8cbfe1da2458d0ed8ba2743a05b23cd98a153373f13e7cf9c0b6ed014a2e665d7597736a0761e0dafbb9040260166b5fc90258efce90b37f614c1dcbcae160c990df975767bccba73f1977da4992ba7bdb9009f24641fd122d85293db0d3b3fd19ef3b303c46a452402ef15d214d33445319139ce4346ab638fb8a03948aee27e6d81f95156345ac0af3b8419ae0a8eb62dac21ec4125e4bb168b0454a8b3022ce65f08b304c0712d2f7db0dd00c979f812b61904a6d94f5d3932a385d18084970e0e6b4a4bc661606f3eb6a357a2d7dd05819d03ad8a61d1db87375795371d77177cc19581b5d736774a53f7d45e63ffa9f92935ec</pre>
+** HMAC_KEY (hex): ab93ce7bf0f91c62a66d00ea9bf5e5c00b854ee2cfc2fb06f6eeff738abcdc26
+** MAC (hex): bb3c93b67d758f244de7ee73e5e61261cea6dff5b3852df8faf265cdf1c73dae
+** IV (hex) : bb3c93b67d758f244de7ee73e5e61261
+** CIPHERTEXT (hex): 7ac33bd9719a3cef6c68e09b3c9677565418933f188bbe50dc70f46329706732fe28ab230468e2a8798d3fbf641867d5b3322113204a372e7650ed06cf94d6df5cc7425b1b3a07690a32e12fd9cdad2c9f42d496c1b02215a7d8d63565aa4935bb2b087af39eebc02d4a2d30a4dbf1e72b9a0dab11473c7254ecf9065eb4f9d80a164c489d5fdae0d15d97b6100b79c3999b91341dfb4f599f738d4d631ae413c17b55daa09a67cb34b40d89c26f0e95ddfbf416033f869da32e502815d720bb342ec1c0e5c6910c598f32162016229cd37ea030b4d3b60f560105abb75531dc960ddf6830c26604c67c2da05b8adc45297dda58b2da4671104969b819cdf1c362bc20d7bdfe4a2fbdb79b4a69e285434d991c269e3d23ce3d95675a0acbec2cae04a310581148d3422c1c0a621fb6d79ecac1743b0e76837389b67cd4734ec5ab560c43a183de35fa98834e1f347a0c0c9b14273b76233f55f04553efcde873de92d766f3cdc5e56bc649bf0cc4951f051619ee9b931cd3872044b0e62ea2c2dacad978dbb8df3afa0b9386535278c295c6a30a56950e57f805770568e937ffafbadb226120991d5ec10effa9f4334800010d141a2ddddc00ac743efa821af37f69840487e4db48036c1e0730788cddbca2f68b3769ec6989d76161e6605af50651b6e86e
+** <tt>my_multisig_wallet_for_signer_3.dat</tt>: <pre>bb3c93b67d758f244de7ee73e5e61261cea6dff5b3852df8faf265cdf1c73dae7ac33bd9719a3cef6c68e09b3c9677565418933f188bbe50dc70f46329706732fe28ab230468e2a8798d3fbf641867d5b3322113204a372e7650ed06cf94d6df5cc7425b1b3a07690a32e12fd9cdad2c9f42d496c1b02215a7d8d63565aa4935bb2b087af39eebc02d4a2d30a4dbf1e72b9a0dab11473c7254ecf9065eb4f9d80a164c489d5fdae0d15d97b6100b79c3999b91341dfb4f599f738d4d631ae413c17b55daa09a67cb34b40d89c26f0e95ddfbf416033f869da32e502815d720bb342ec1c0e5c6910c598f32162016229cd37ea030b4d3b60f560105abb75531dc960ddf6830c26604c67c2da05b8adc45297dda58b2da4671104969b819cdf1c362bc20d7bdfe4a2fbdb79b4a69e285434d991c269e3d23ce3d95675a0acbec2cae04a310581148d3422c1c0a621fb6d79ecac1743b0e76837389b67cd4734ec5ab560c43a183de35fa98834e1f347a0c0c9b14273b76233f55f04553efcde873de92d766f3cdc5e56bc649bf0cc4951f051619ee9b931cd3872044b0e62ea2c2dacad978dbb8df3afa0b9386535278c295c6a30a56950e57f805770568e937ffafbadb226120991d5ec10effa9f4334800010d141a2ddddc00ac743efa821af37f69840487e4db48036c1e0730788cddbca2f68b3769ec6989d76161e6605af50651b6e86e</pre>
 
 ==Acknowledgement==
 
-- 
cgit v1.2.3


From 7ae9e025e809a870c1d1c9077c2ebc4515734365 Mon Sep 17 00:00:00 2001
From: Robert Spigler <RobertSpigler@ProtonMail.ch>
Date: Sun, 25 Apr 2021 23:52:46 -0400
Subject: Minor edits, + backwards compatibility

---
 ...hy for Deterministic Multisignature Wallets.mediawiki | 16 +++++++++-------
 1 file changed, 9 insertions(+), 7 deletions(-)

diff --git a/Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki b/Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki
index b607933..ff3ca9a 100644
--- a/Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki	
+++ b/Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki	
@@ -50,9 +50,7 @@ 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 <code>script_type'</code> 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, <code>script_type</code> 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 <ref>'''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. Co-signers in multisignature wallets need to backup all other cosigner public keys anyway in order to restore, so the descriptor provides this information with the benefit of key origin information and error detection.</ref>.
-
-Any script that is supported by descriptors (and the specific wallet implementation) is compatible with this BIP.
+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 <ref>'''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.</ref>.
 
 This paper was inspired from BIP44.
 
@@ -128,7 +126,7 @@ The multisig descriptors or descriptor template that is generated from the cosig
 
 For example:
 
-The following descriptor template and derivation path:
+The following descriptor template and derivation path restrictions:
 
 <code>wsh(sortedmulti(2,[xfpForA/XY'/0'/0']XpubA/**,[xfpForB/XY'/0'/0']XpubB/**))</code>
 
@@ -142,13 +140,17 @@ Expands to the two concrete descriptors:
 
 To discover addresses, import both the receiving and change descriptors; respect the gap limit described below.
 
-Note: This therefore necessitates that multisig wallets backup their private key information and their 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 <code>M</code> seeds in any <code>M</code> of <code>N</code> multisig restore operation. The descriptor provides this information in a standardized format, with key origin information and error detection.
-
 ===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 chain by generating a new address.
+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 <code>M</code> seeds in any <code>M</code> of <code>N</code> multisig restore operation. The descriptor provides this information in a standardized format, with key origin information and error detection.
 
 ==Rationale==
 
-- 
cgit v1.2.3


From 653b965f15c1d3bb9aad654488402c69588fd61d Mon Sep 17 00:00:00 2001
From: Robert Spigler <RobertSpigler@ProtonMail.ch>
Date: Mon, 26 Apr 2021 14:55:39 -0400
Subject: Add BSMS reference and key origin info

---
 ...ierarchy for Deterministic Multisignature Wallets.mediawiki | 10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki b/Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki
index ff3ca9a..88dd46f 100644
--- a/Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki	
+++ b/Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki	
@@ -122,7 +122,9 @@ 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. 
+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 BIP__ (Bitcoin Secure Multisig Setup) for an introduction on descriptor templates.  [Waiting for merge of BSMS to link here].  The descriptor or descriptor template should contain the key origin information for maximum compatibility with BIP-0174.
 
 For example:
 
@@ -134,9 +136,9 @@ The following descriptor template and derivation path restrictions:
 
 Expands to the two concrete descriptors:
 
-<code>wsh(sortedmulti(2,[xfpForA/XY'/0'/0']XpubA/0/*,[xfpForB/XY'/0'/0']XpubB/0/*))#Checksum</code>
+<code>wsh(sortedmulti(2,[xfpForA/XY'/0'/0']XpubA/0/*,[xfpForB/XY'/0'/0']XpubB/0/*))</code>
 
-<code>wsh(sortedmulti(2,[xfpForA/XY'/0'/0']XpubA/1/*,[xfpForB/XY'/0'/0']XpubB/1/*))#Checksum</code>
+<code>wsh(sortedmulti(2,[xfpForA/XY'/0'/0']XpubA/1/*,[xfpForB/XY'/0'/0']XpubB/1/*))</code>
 
 To discover addresses, import both the receiving and change descriptors; respect the gap limit described below.
 
@@ -268,4 +270,4 @@ Original mailing list thread: https://lists.linuxfoundation.org/pipermail/bitcoi
 * [https://github.com/bitcoin/bitcoin/blob/master/doc/descriptors.md Output Descriptors]
 * [[bip-0174.mediawiki|BIP174 - Partially Signed Bitcoin Transaction Format]]
 * [[bip-0067.mediawiki|BIP67 - Deterministic Pay-to-script-hash multi-signature addresses through public key sorting]]
-
+* Bitcoin Secure Multisig Setup [Waiting For Merge]
-- 
cgit v1.2.3


From dd39e2234c23e6efbc77802caa7e74093ae6a66e Mon Sep 17 00:00:00 2001
From: "Dr. Maxim Orlovsky" <orlovsky@pandoracore.com>
Date: Mon, 26 Apr 2021 22:55:25 +0200
Subject: BIP-21 remove of all "size" mentions

---
 bip-0021.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-0021.mediawiki b/bip-0021.mediawiki
index 8aec855..0fba9bc 100644
--- a/bip-0021.mediawiki
+++ b/bip-0021.mediawiki
@@ -60,7 +60,7 @@ The scheme component ("bitcoin:") is case-insensitive, and implementations must
 *message: message that describes the transaction to the user ([[#Examples|see examples 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.
-- 
cgit v1.2.3


From b1dbe62a21381661dff8d670480944c7a70eff61 Mon Sep 17 00:00:00 2001
From: eugene <elzeigel@gmail.com>
Date: Fri, 23 Apr 2021 17:32:49 -0400
Subject: BIP 341: fix tuple index

---
 bip-0341.mediawiki | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/bip-0341.mediawiki b/bip-0341.mediawiki
index 586bb39..fb6e222 100644
--- a/bip-0341.mediawiki
+++ b/bip-0341.mediawiki
@@ -173,7 +173,7 @@ First, we define <code>taproot_tweak_pubkey</code> for 32-byte [[bip-0340.mediaw
 The function returns a bit indicating the tweaked public key's Y coordinate as well as the public key byte array.
 The parity bit will be required for spending the output with a script path.
 In order to allow spending with the key path, we define <code>taproot_tweak_seckey</code> to compute the secret key for a tweaked public key.
-For any byte string <code>h</code> it holds that <code>taproot_tweak_pubkey(pubkey_gen(seckey), h)[0] == pubkey_gen(taproot_tweak_seckey(seckey, h))</code>.
+For any byte string <code>h</code> it holds that <code>taproot_tweak_pubkey(pubkey_gen(seckey), h)[1] == pubkey_gen(taproot_tweak_seckey(seckey, h))</code>.
 
 <source lang="python">
 def taproot_tweak_pubkey(pubkey, h):
@@ -219,7 +219,7 @@ def taproot_output_script(internal_pubkey, script_tree):
         h = bytes()
     else:
         _, h = taproot_tree_helper(script_tree)
-    output_pubkey, _ = taproot_tweak_pubkey(internal_pubkey, h)
+    _, output_pubkey = taproot_tweak_pubkey(internal_pubkey, h)
     return bytes([0x51, 0x20]) + output_pubkey
 </source>
 
-- 
cgit v1.2.3


From 3f050db64e7716a62993e6ff9fae7b0768b217f8 Mon Sep 17 00:00:00 2001
From: Hugo Nguyen <hugh.hn@gmail.com>
Date: Wed, 28 Apr 2021 08:25:43 -0700
Subject: add Compatibility section

---
 bip-hugonguyen-bsms.mediawiki | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/bip-hugonguyen-bsms.mediawiki b/bip-hugonguyen-bsms.mediawiki
index a5225f0..dc04d5e 100644
--- a/bip-hugonguyen-bsms.mediawiki
+++ b/bip-hugonguyen-bsms.mediawiki
@@ -180,6 +180,9 @@ For signers that use QR codes to transmit data, key and descriptor records can b
 
 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==
+To comply with this standard, a Signer must be able to persist the descriptor record in its storage. 
+
 ==Security==
 
 This proposal introduces two layers of protection. The first one is a temporary, secret <tt>TOKEN</tt>. The second one is the confirmation of the wallet's first address.
-- 
cgit v1.2.3


From 83e9b39eb9159b367bb04a2477d5f8677f05632d Mon Sep 17 00:00:00 2001
From: Hugo Nguyen <hugh.hn@gmail.com>
Date: Wed, 28 Apr 2021 08:44:25 -0700
Subject: fix test vector

---
 bip-hugonguyen-bsms.mediawiki | 28 ++++++++++++++--------------
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/bip-hugonguyen-bsms.mediawiki b/bip-hugonguyen-bsms.mediawiki
index dc04d5e..11107b4 100644
--- a/bip-hugonguyen-bsms.mediawiki
+++ b/bip-hugonguyen-bsms.mediawiki
@@ -206,36 +206,36 @@ If the parties wish to have stronger privacy, it is recommended to use a higher
 ** TOKEN: 0x00
 
 * Signer 1
-** MASTER_KEY_FINGERPRINT: 2607aabc
-** PRIVATE_KEY (m/48'/0'/0'/2'): L2Vt7N6mHLgcP1A6zLWHsm7G9iGCFPqLwiGQdZsCsHwYfXPuCUHc
-** Public Key (m/48'/0'/0'/2'): 038328f50eb45eada196d02ebb6a3b980be3c0706ded17eaa774d77974c15ae2fe
+** MASTER_KEY_FINGERPRINT: 59865f44
+** PRIVATE_KEY (m/48'/0'/0'/2'): L5TXU4SdD9e6QGgBjxeegJKxt4FgATLG1TCnFM8JLyEkFuyHEqNM
+** Public Key (m/48'/0'/0'/2'): 026d15412460ba0d881c21837bb999233896085a9ed4e5445bd637c10e579768ba
 ** Legacy signature
 ** <tt>signer_1_key.bsms</tt>:
 <pre>BSMS 1.0
-05dc6edbff65b399654fd6b837c0e4aa
-[2607aabc/48'/0'/0'/2']038328f50eb45eada196d02ebb6a3b980be3c0706ded17eaa774d77974c15ae2fe
+00
+[59865f44/48'/0'/0'/2']026d15412460ba0d881c21837bb999233896085a9ed4e5445bd637c10e579768ba
 Signer 1 key
-H7pdMwSJ0JFeFwLTHvO6+IMpnyDtmabtDosdebcD+dMPRNLKD7cvbo4GTN1z5rfbTuKnpHTznexA4d8P9yK3c74=</pre>
+H6DXgqkCb353BDPkzppMFpOcdJZlpur0WRetQhIBqSn6DFzoQWBtm+ibP5wERDRNi0bxxev9B+FIvyQWq0s6im4=</pre>
 
 * Signer 2
-** MASTER_KEY_FINGERPRINT: 3ff797d2
-** PRIVATE_KEY (m/48'/0'/0'/2'): KxeLc5AVxYtK1yFqroLtqpgjm8YAMrYs66Kfcx28fBk9zg22M4V4
-** Public Key (m/48'/0'/0'/2'): 02d6a29eccd2c7621e7e1ea1c251ef1a18bd5f773392cf66ff40b8ef1cb1b2fe0b
+** MASTER_KEY_FINGERPRINT: b7044ca6
+** PRIVATE_KEY (m/48'/0'/0'/2'): KwT7BZDWjos4JAdfKi8NqF46Kj3rppTwN8KGhPbzmmugiZioFW3r
+** Public Key (m/48'/0'/0'/2'): 030baf0497ab406ff50cb48b4013abac8a0338758d2fd54cd934927afa57cc2062
 ** Legacy signature
 ** <tt>signer_2_key.bsms</tt>:
 <pre>BSMS 1.0
-70f7538ffc8d4f8f52aa8e465581b9a0
-[3ff797d2/48'/0'/0'/2']02d6a29eccd2c7621e7e1ea1c251ef1a18bd5f773392cf66ff40b8ef1cb1b2fe0b
+00
+[b7044ca6/48'/0'/0'/2']030baf0497ab406ff50cb48b4013abac8a0338758d2fd54cd934927afa57cc2062
 Signer 2 key
-IBROlN9mAZZFgK92cAp5Ws+EtkOPGGDoESx/oyXb73MdJaZb1/3+vMFw9pYfmpvsbQGMglUoKmHc6AVRmyFIYiE=</pre>
+H08mGNGN+NxX/snt+6eX2Q1HjjfDkOtotglshHi7xdsBdIrTVMCQbgQ5SdACNZ0B2AJcifK11nJj43SvaitSemI=</pre>
 
 ====ROUND 2====
 * Coordinator
 ** <tt>my_multisig_wallet.bsms</tt>:
 <pre>BSMS 1.0
-wsh(sortedmulti(1,[2607aabc/48'/0'/0'/2']038328f50eb45eada196d02ebb6a3b980be3c0706ded17eaa774d77974c15ae2fe,[3ff797d2/48'/0'/0'/2']02d6a29eccd2c7621e7e1ea1c251ef1a18bd5f773392cf66ff40b8ef1cb1b2fe0b))#uje27sjy
+wsh(sortedmulti(1,[59865f44/48'/0'/0'/2']026d15412460ba0d881c21837bb999233896085a9ed4e5445bd637c10e579768ba,[b7044ca6/48'/0'/0'/2']030baf0497ab406ff50cb48b4013abac8a0338758d2fd54cd934927afa57cc2062))#rzx9dffd
 No path restrictions
-bc1qfvtnp7aturvmrd5x42mtexqkkktl993n0xpu5sjcnf6nx5dve5zqcxsyda</pre>
+bc1quqy523xu3l8che3s8vja8n33qtg0uyugr9l5z092s3wa50p8t7rqy6zumf</pre>
 
 ===Mode: <tt>NO_ENCRYPTION</tt>===
 ====ROUND 1====
-- 
cgit v1.2.3


From 83aa04776d38e18f03cd766102cfcefb5b244c9f Mon Sep 17 00:00:00 2001
From: Hugo Nguyen <hugh.hn@gmail.com>
Date: Tue, 4 May 2021 21:35:05 -0700
Subject: update Compatibility section

---
 bip-hugonguyen-bsms.mediawiki | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/bip-hugonguyen-bsms.mediawiki b/bip-hugonguyen-bsms.mediawiki
index 11107b4..a41900d 100644
--- a/bip-hugonguyen-bsms.mediawiki
+++ b/bip-hugonguyen-bsms.mediawiki
@@ -2,7 +2,11 @@
   BIP: To be determined
   Layer: Applications
   Title: Bitcoin Secure Multisig Setup (BSMS)
-  Author: Hugo Nguyen <hugo at nunchuk.io>, Peter Gray <peter at coinkite.com>, Marko Bencun <marko at shiftcrypto.ch>, Aaron Chen <aarondongchen at gmail.com>, Rodolfo Novak <rodolfo at coinkite.com>
+  Author: Hugo Nguyen <hugo at nunchuk.io>
+          Peter Gray <peter at coinkite.com>
+          Marko Bencun <marko at shiftcrypto.ch>
+          Aaron Chen <aarondongchen at gmail.com>
+          Rodolfo Novak <rodolfo at coinkite.com>
   Comments-Summary: No comments yet.
   Comments-URI:
   Status: Proposed
@@ -183,6 +187,8 @@ Also refer to [https://github.com/BlockchainCommons/Research/blob/master/papers/
 ==Compatibility==
 To comply with this standard, a Signer must be able to persist the descriptor record in its storage. 
 
+Existing multisig wallets should delay upgrading to the BSMS scheme until all participating Signers in the multisig wallet have added support for BSMS.
+
 ==Security==
 
 This proposal introduces two layers of protection. The first one is a temporary, secret <tt>TOKEN</tt>. The second one is the confirmation of the wallet's first address.
-- 
cgit v1.2.3


From 0408b412f9147e402a2205b23c5ef942a75ddcb7 Mon Sep 17 00:00:00 2001
From: Hugo Nguyen <hugh.hn@gmail.com>
Date: Tue, 4 May 2021 21:58:10 -0700
Subject: minor edit

---
 bip-hugonguyen-bsms.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-hugonguyen-bsms.mediawiki b/bip-hugonguyen-bsms.mediawiki
index a41900d..9adc11d 100644
--- a/bip-hugonguyen-bsms.mediawiki
+++ b/bip-hugonguyen-bsms.mediawiki
@@ -187,7 +187,7 @@ Also refer to [https://github.com/BlockchainCommons/Research/blob/master/papers/
 ==Compatibility==
 To comply with this standard, a Signer must be able to persist the descriptor record in its storage. 
 
-Existing multisig wallets should delay upgrading to the BSMS scheme until all participating Signers in the multisig wallet have added support for BSMS.
+Existing multisig wallets should delay upgrading to the BSMS scheme until all participating Signers have added support for BSMS.
 
 ==Security==
 
-- 
cgit v1.2.3


From f13cd8dde9e67003fcc952de02d0b63c4db5bbac Mon Sep 17 00:00:00 2001
From: Hugo Nguyen <hugh.hn@gmail.com>
Date: Wed, 5 May 2021 20:05:08 -0700
Subject: update Compatibility section

---
 bip-hugonguyen-bsms.mediawiki | 10 +++++++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/bip-hugonguyen-bsms.mediawiki b/bip-hugonguyen-bsms.mediawiki
index 9adc11d..8153ae6 100644
--- a/bip-hugonguyen-bsms.mediawiki
+++ b/bip-hugonguyen-bsms.mediawiki
@@ -69,7 +69,7 @@ The Signer is any software or hardware that controls the private keys and can si
 
 * 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 (<tt>M</tt> and <tt>N</tt>).
 * 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 <tt>TOKEN</tt> to each Signer over a secure channel. The Signer can use the <tt>TOKEN</tt> to derive an <tt>ENCRYPTION_KEY</tt>. Refer to the Encryption section below for details on the <tt>TOKEN</tt>, the key derivation function and the encryption scheme. Depending on the use case, the Coordinator can decide whether to share one common <tt>TOKEN</tt> for all Signers, or to have one per Signer.
+* If encryption is enabled, the Coordinator distributes a secret <tt>TOKEN</tt> to each Signer over a secure channel. The Signer can use the <tt>TOKEN</tt> to derive an <tt>ENCRYPTION_KEY</tt>. Refer to the [[#Encryption]] section below for details on the <tt>TOKEN</tt>, the key derivation function and the encryption scheme. Depending on the use case, the Coordinator can decide whether to share one common <tt>TOKEN</tt> for all Signers, or to have one per Signer.
 * If encryption is disabled, the <tt>TOKEN</tt> is set to <tt>0x00</tt>, and all the encryption/decryption steps below can be skipped.
 
 =====Signer=====
@@ -185,9 +185,13 @@ For signers that use QR codes to transmit data, key and descriptor records can b
 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==
-To comply with this standard, a Signer must be able to persist the descriptor record in its storage. 
+BSMS is opt-in, meaning existing multisig wallets can continue working as-is, with the caveat that current multisig solutions are full of pitfalls. Some of the problems have been described in the [[#Motivation]] section.
 
-Existing multisig wallets should delay upgrading to the BSMS scheme until all participating Signers have added support for BSMS.
+To comply with this standard, a Signer must be able to persist the descriptor record in its storage.
+
+Once a Signer has implemented BSMS, the user can create new multisig wallets using BSMS or migrate existing ones to BSMS.
+
+Existing multisig wallets should delay upgrading to BSMS until all participating Signers have implemented BSMS.
 
 ==Security==
 
-- 
cgit v1.2.3


From 229a60bf8e180f6d78acce111018d261b8327dec Mon Sep 17 00:00:00 2001
From: Hugo Nguyen <hugh.hn@gmail.com>
Date: Fri, 7 May 2021 19:42:44 -0700
Subject: update Compatibility section

---
 bip-hugonguyen-bsms.mediawiki | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/bip-hugonguyen-bsms.mediawiki b/bip-hugonguyen-bsms.mediawiki
index 8153ae6..5d9ef85 100644
--- a/bip-hugonguyen-bsms.mediawiki
+++ b/bip-hugonguyen-bsms.mediawiki
@@ -185,7 +185,9 @@ For signers that use QR codes to transmit data, key and descriptor records can b
 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==
-BSMS is opt-in, meaning existing multisig wallets can continue working as-is, with the caveat that current multisig solutions are full of pitfalls. Some of the problems have been described in the [[#Motivation]] section.
+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 full of pitfalls. Some of the problems 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.
 
-- 
cgit v1.2.3


From 37b55d2fde5d7d724822ab121492aac9731ac286 Mon Sep 17 00:00:00 2001
From: Michael Folkson <michaelfolkson@gmail.com>
Date: Sun, 9 May 2021 10:03:13 +0100
Subject: BIP: Mandatory activation of taproot deployment

---
 bip-mandatory-activation.mediawiki | 62 ++++++++++++++++++++++++++++++++++++++
 1 file changed, 62 insertions(+)
 create mode 100644 bip-mandatory-activation.mediawiki

diff --git a/bip-mandatory-activation.mediawiki b/bip-mandatory-activation.mediawiki
new file mode 100644
index 0000000..1c03159
--- /dev/null
+++ b/bip-mandatory-activation.mediawiki
@@ -0,0 +1,62 @@
+<pre>
+BIP: ???
+Layer: Consensus (soft fork)
+Title: Mandatory activation of taproot deployment
+Author: Shinobius <quantumedusa@gmail.com> 
+        Michael Folkson <michaelfolkson@gmail.com>
+Comments-Summary: No comments yet.
+Comments-URI:
+Status: Proposed
+Type: Standards Track
+Created: 2021-04-25
+License: BSD-3-Clause
+         CC0-1.0
+</pre>
+
+==Abstract==
+
+This document specifies a BIP8 (LOT=true) deployment to activate taproot.
+
+==Motivation==
+
+The Taproot soft fork upgrade has been assessed to have overwhelming community consensus and hence should attempt to be activated. Lessons have been learned from the BIP148 and BIP91 deployments in 2017 with regards to giving many months of advance warning before the mandatory signaling is attempted. The mandatory signaling is only required if miners have failed to meet the signaling threshold during the BIP8 deployment. It is important that mandatory signaling is included as without it miners would effectively have the ability to indefinitely block the activation of a soft fork with overwhelming consensus. 
+
+==Specification==
+
+This BIP will begin an activation signaling period using bit 2 at blockheight 681408 with a minimum activation height of 709632 and an activation threshold of 90%. The signaling period will timeout at blockheight 760032 with a latest activation height of 762048. Lockinontimeout (LOT) is set to true so mandatory signaling will be enforced in the last signaling period before the timeout height. Blocks without the signaling bit 2 set run the risk of being rejected during this period if taproot is not locked in prior. This BIP will cease to be active when taproot is locked in.
+
+==Reference implementation==
+
+*[[https://github.com/BitcoinActivation/bitcoin]]
+
+==Backward Compatibility==
+
+As a soft fork, older software will continue to operate without modification. Non-upgraded nodes, however, will consider all SegWit version 1 witness programs as anyone-can-spend scripts. They are strongly encouraged to upgrade in order to fully validate the new programs.
+
+==Compatibility with later alternative activations==
+
+The activation mechanism “Speedy Trial” as proposed by Russell O’Connor and outlined in this bitcoin-dev mailing list [https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-March/018583.html post] by David Harding was released in Bitcoin Core. It is effectively a BIP8 activation mechanism with one exception: start height and timeout height were defined using median time past (MTP) rather than block heights. It uses signaling bit 2, was deployed between midnight April 24th 2021 and midnight August 11th 2021, has a minimum activation height of 709632 and intends to activate BIPs 340, 341, and 342. The BIP8(LOT=true) deployment is compatible with the “Speedy Trial” deployment in Bitcoin Core as there was not a discrepancy between MTP and block height for the defined start heights.
+
+The BIP8 (LOT=true) deployment has also been deliberately designed to be compatible with a future BIP8(LOT=false) or BIP8(LOT=true) deployment in Bitcoin Core assuming Bitcoin Core releases one of these activation mechanisms in the event of the Speedy Trial deployment failing to activate.
+
+==Rationale==
+
+The deployment of BIP148 demonstrated that multiple implementations with different activation mechanisms can incentivize the necessary actors to act so that the different deployments activate in sync. A BIP8 LOT=true deployment can run in parallel with other BIP8 activation mechanisms that have eventual mandatory signaling or no mandatory signaling. Eventual mandatory signaling ensures that miners cannot prevent the activation of a desired feature with community consensus indefinitely.
+
+==Acknowledgements==
+
+Thanks to Shaolin Fry and Luke Dashjr for their work on BIP148 and BIP8 which were important prerequisites for this proposal.
+
+==References==
+
+*[[bip-0008.mediawiki|BIP8 Version bits with lock-in by height]]
+*[[bip-0148.mediawiki|BIP148 Mandatory activation of segwit deployment]]
+*[[bip-0340.mediawiki|BIP340 Schnorr Signatures for secp256k1]]
+*[[bip-0341.mediawiki|BIP341 Taproot: SegWit version 1 spending rules]]
+*[[bip-0342.mediawiki|BIP342 Validation of Taproot Scripts]]
+*[https://taproot.works/taproot-faq/ Taproot benefits]
+
+==Copyright==
+
+This document is dual licensed as BSD 3-clause, and Creative Commons CC0 1.0 Universal.
+
-- 
cgit v1.2.3


From 47847fe874764a0ffc9addbcfc692e5199a7339d Mon Sep 17 00:00:00 2001
From: Hugo Nguyen <hugh.hn@gmail.com>
Date: Tue, 11 May 2021 03:36:32 -0700
Subject: minor edit

---
 bip-hugonguyen-bsms.mediawiki | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/bip-hugonguyen-bsms.mediawiki b/bip-hugonguyen-bsms.mediawiki
index 5d9ef85..d34a42f 100644
--- a/bip-hugonguyen-bsms.mediawiki
+++ b/bip-hugonguyen-bsms.mediawiki
@@ -187,13 +187,11 @@ Also refer to [https://github.com/BlockchainCommons/Research/blob/master/papers/
 ==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 full of pitfalls. Some of the problems have been described in the [[#Motivation]] section.
+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.
 
-Once a Signer has implemented BSMS, the user can create new multisig wallets using BSMS or migrate existing ones to BSMS.
-
-Existing multisig wallets should delay upgrading to BSMS until all participating Signers have implemented BSMS.
+To use BSMS for a multisig wallet, the user should wait until all participating Signers in the multisig have implemented BSMS.
 
 ==Security==
 
-- 
cgit v1.2.3


From 4a1077d40e5166a032ce0dbfdbeb06d5199c4add Mon Sep 17 00:00:00 2001
From: t-bast <bastuc@hotmail.fr>
Date: Tue, 11 May 2021 16:17:40 +0200
Subject: BIP 174: clarify key uniqueness

The description of keytype incorrectly said it had to be unique: it's the
whole key that must be unique, not the keytype (since we can for instance
have multiple xpubs in the global map).
---
 bip-0174.mediawiki | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/bip-0174.mediawiki b/bip-0174.mediawiki
index 9434ce6..b211434 100644
--- a/bip-0174.mediawiki
+++ b/bip-0174.mediawiki
@@ -65,7 +65,7 @@ be used as a separator and allow for easier unserializer implementation.</ref>.
 Where:
 
 ;<tt><keytype></tt>
-: 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. This must be unique within a specific <tt><map></tt>.
+: 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 <tt><keytype></tt> within a specific <tt><map></tt>, but the <tt><key></tt> must be unique.
 ;<tt><keylen></tt>
 : The compact size unsigned integer containing the combined length of <tt><keytype></tt> and <tt><keydata></tt>
 ;<tt><valuelen></tt>
@@ -544,7 +544,7 @@ values are valid, then it does not matter which is chosen as either way the tran
 
 ===Proprietary Use Type===
 
-For all global, per-input, and per-output maps, the types <tt>0xFC</tt> is reserved for proprietary use.
+For all global, per-input, and per-output maps, the type <tt>0xFC</tt> is reserved for proprietary use.
 The proprietary use type requires keys that follow the type with a compact size unsigned integer representing the length of the string identifer, followed by the string identifier, then a subtype, and finally any key data.
 
 The identifier can be any variable length string that software can use to identify whether the particular data in the proprietary type can be used by it.
@@ -554,7 +554,7 @@ The subtype is defined by the proprietary type user and can mean whatever they w
 The subtype must also be a compact size unsigned integer in the same form as the normal types.
 The key data and value data are defined by the proprietary type user.
 
-The proprietary use types is for private use by individuals and organizations who wish to use PSBT in their processes.
+The proprietary use type is for private use by individuals and organizations who wish to use PSBT in their processes.
 It is useful when there are additional data that they need attached to a PSBT but such data are not useful or available for the general public.
 The proprietary use type is not to be used by any public specification and there is no expectation that any publicly available software be able to understand any specific meanings of it and the subtypes.
 This type must be used for internal processes only.
@@ -727,7 +727,7 @@ If an updater is updating a PSBT and needs to add a field that is only available
 ===Procedure For New Fields===
 
 New fields should first be proposed on the bitcoin-dev mailing list.
-If a field requires significatn description as to its usage, it should be accompanied by a separate BIP.
+If a field requires significant description as to its usage, it should be accompanied by a separate BIP.
 The field must be added to the field listing tables in the Specification section.
 
 ===Procedure For New Versions===
-- 
cgit v1.2.3


From 349d2ee295ea585c00331c88e963289e3d8a8209 Mon Sep 17 00:00:00 2001
From: "Daniel X. Pape" <dpape@dpape.com>
Date: Thu, 18 Mar 2021 14:52:48 -0700
Subject: updates data encoding/decoding examples due to bech32m/bech32

---
 bip-0136.mediawiki | 898 +++++++++++++++++++++++++++++++++++++++++------------
 1 file changed, 700 insertions(+), 198 deletions(-)

diff --git a/bip-0136.mediawiki b/bip-0136.mediawiki
index f94171d..1caa027 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): <tt>tx1:rqqq-qqqq-qmhu-qhp</tt>
-* Transaction #2205 of Block #466793: <tt>tx1:rjk0-uqay-zsrw-hqe</tt>
+
+{| class="wikitable"
+|-
+! Block # !! Transaction # !! Outpoint # !! TxRef !! TxID
+|-
+| 0 || 0 || 0 || tx1:rqqq&#8209;qqqq&#8209;qwtv&#8209;vjr || 4a5e1e4baab89f3a32518a88c31bc87f618f76673e2cc77ab2127b7afdeda33b
+|-
+| 170 || 1 || 0 || tx1:r52q&#8209;qqpq&#8209;qpty&#8209;cfg || f4184fc596403b9d638783cf57adfe4c75c605f6356fbc91338530e9831e9e16
+|-
+| 456789 || 1234 || 1 || tx1:y29u&#8209;mqjx&#8209;ppqq&#8209;sfp2&#8209;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 '''TxRef'''s displayed may point to a different transaction, or to no transaction at all.
+
+=== TxRef Format ===
+
+'''TxRef''' MUST use the '''Bech32m'''<ref>'''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.</ref> 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:
 
-* 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.
+==== 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<ref>'''Why add a colon here?''' This allows it to conform better with W3C URN/URL standards.</ref> '''":"'''  added after the separator character '1'.
+* Hyphens<ref>'''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.</ref> '''"-"''' added after every 4 characters beyond the colon.
 
 === Encoding ===
 
-TxRef uses standard Bech32<ref name=":0">'''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.</ref> 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.
+
+{| class="wikitable"
+!
+!Description
+!Possible Data Type
+!'''# of Bits used'''
+!Values
+|-
+| 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<br>'''4''': Mainnet with Outpoint<br>'''6''': Testnet<br>'''7''': Testnet with Outpoint<br>'''0''': Regtest<br>'''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<br>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<br>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<br>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
+|}
 
-* 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.
+==== Magic Notes ====
+The magic code provides namespacing between chains:
 
-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.
+* 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.
 
-To increase portability and readability additional separators SHOULD be added:
+==== Encoding Example ====
 
-* A Colon<ref>'''Why add a colon here?''' This allows it to conform better with W3C URN/URL standards.</ref> '''":"'''  added after '1'.
-* Hyphens<ref>'''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.</ref> '''"-"''' added after every 4 characters beyond the colon.
+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:
 
-All non-bech32-alphabet characters after the bech32 code separator MUST be ignored/removed when parsing (except for terminating characters).<ref>'''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.
-</ref>
 {| class="wikitable"
-|+Text Encoding of the TxRef
 !
-!Bit
-!Character
-!Characters
-!Value
+!Decimal<br>Value
+!Binary<br>Value
+!'''# of Bits<br>used'''
+!Bit Indexes and Values
+|-
+| style="background: #99DDFF; color: black; text-align : center;" | Magic<br>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<br>Height
+| style="background: #EEDD88; color: black; text-align : center;" | 456789
+|00000110<br>11111000<br>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)<br>(bh15, bh14, bh13, bh12, bh11, bh10, bh09, bh08) = (1, 1, 1, 1, 1, 0, 0, 0)<br>(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<br>Index
+| style="background: #FFAABB; color: black; text-align : center;" | 1234
+|00000100<br>11010010
+| style="background: #FFAABB; color: black; text-align : center;" | 15
+|(ti14, ti13, ti12, ti11, ti10, ti09, ti08) = (0, 0, 0, 0, 1, 0, 0)<br>(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<br>Value
+!Bech32<br>Character
 |-
-|Human Readable Part
+| || || || || || || || || || || || ||
+|-
+| 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
-|1
-|"'''1'''"
+|r
+|-
+| || || || || || || || || || || ||
 |-
-|Colon
+| 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
 |
-|4
+|
+|
+|-
+|Value
+|0
+|0
+|0
+|0
+|1
+|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.
+|1
+|1
+|0
+|0
 |
+|28
+|u
 |-
-|Version
-|5
+| || || || || || || || || || || ||
+|-
+| 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
+|
+|
+|
+|-
+|Value
+|0
+|0
+|0
+|1
+|1
+|0
+|1
 |1
-|For Future Use
-|Must be '''0x0'''
 |
+|27
+|m
 |-
-|Block Height
-|6 – 29
-|24
-|The Block Height of the Tx
-|Block 0 (genesis) to block 16777215
-|Until Year ~2328
+| || || || || || || || || || || ||
 |-
-|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;" | &#58;
+|  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'''
-|-
-|Outpoint Index
-|45 – 59
-|15
-|The index of the Outpoint inside the Tx
-|Outpoint 0 to Outpoint Position 32767
-|
+!Decimal<br>Value
+!Binary<br>Value
+!'''# of Bits<br>used'''
+!Bit Indexes and Values
+|-
+| style="background: #99DDFF; color: black; text-align : center;" | Magic<br>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)<br>(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<br>Value
+!Bech32<br>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
+|
+|
+|
+|-
+|Value
+|0
+|0
+|0
+|0
+|0
+|1
+|0
+|0
+|
+|4
+|y
+|-
+| || || || || || || || || || || ||
 |-
-|Checksum
-|45 – 74 or 60 – 89
-|30
-|Bech32 Checksum
+| 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):
-
-* 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.
+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:
+
+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;" | &#58;
+|  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 ==
 
 <references />
 
 == 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/
 
-== Appendices ==
+Java Reference Implementation (supports magic codes 0x3, 0x4, 0x6, 0x7, 0x0 and 0x1): https://github.com/dcdpr/libtxref-java/
 
-=== Test Vectors ===
-There are two sets of Test Vectors included here:
-
-* 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.
+== Appendices ==
 
-==== 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.''
+=== Test Examples ===
 
-The following strings have a valid Human Readable Part and Bech32 Checksum.
-* <tt>TX1A12UEL5L</tt>
-* <tt>tx1an83characterlonghumanreadablepartthatcontainsthenumber1andtheexcludedcharactersbio1tt5tgs</tt>
-* <tt>tx1abcdef1qpzry9x8gf2tvdw0s3jn54khce6mua7lmqqqxw</tt>
-* <tt>tx11qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqc8247j</tt>
+The following examples show values for various combinations on mainnet and testnet; encoding block height, transaction index, and an optional output index.
 
-The following list gives invalid TxRef's and the reason for their invalidity.
-* <tt>bc1qw508d6qejxtdg4y5r3zarvary0c5xw7kg3g4ty</tt>: Invalid human-readable part
-* <tt>tx1qw508d6qejxtdg4y5r3zarvary0c5xw7kv8f3t5</tt>: Invalid checksum
+==== TxRef ====
+The following list gives properly encoded mainnet '''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)
+* <tt>tx1:rqqq-qqqq-qwtv-vjr</tt>: <tt>(0x0, 0x0)</tt>
+* <tt>tx1:rqqq-qqll-lj68-7n2</tt>: <tt>(0x0, 0x7FFF)</tt>
+* <tt>tx1:r7ll-llqq-qats-vx9</tt>: <tt>(0xFFFFFF, 0x0)</tt>
+* <tt>tx1:r7ll-llll-lp6m-78v</tt>: <tt>(0xFFFFFF, 0x7FFF)</tt>
 
-* <tt>tx1:rqqq-qqqq-qmhu-qhp</tt>: <tt>(0x0, 0x0)</tt>
-* <tt>tx1:rqqq-qqll-l8xh-jkg</tt>: <tt>(0x0, 0x7FFF)</tt>
-* <tt>tx1:r7ll-llqq-qghq-qr8</tt>: <tt>(0xFFFFFF, 0x0)</tt>
-* <tt>tx1:r7ll-llll-l5xt-jzw</tt>: <tt>(0xFFFFFF, 0x7FFF)</tt>
+The following list gives properly encoded testnet '''TxRef'''s and the decoded hex values (block height, transaction index)
 
-The following list gives properly encoded Bitcoin testnet TxRef's and the values in hex. (block height, transaction index)
+* <tt>txtest1:xqqq-qqqq-qrrd-ksa</tt>: <tt>(0x0, 0x0)</tt>
+* <tt>txtest1:xqqq-qqll-lljx-y35</tt>: <tt>(0x0, 0x7FFF)</tt>
+* <tt>txtest1:x7ll-llqq-qsr3-kym</tt>: <tt>(0xFFFFFF, 0x0)</tt>
+* <tt>txtest1:x7ll-llll-lvj6-y9j</tt>: <tt>(0xFFFFFF, 0x7FFF)</tt>
 
-* <tt>txtest1:xqqq-qqqq-qkla-64l</tt>: <tt>(0x0, 0x0)</tt>
-* <tt>txtest1:xqqq-qqll-l2wk-g5k</tt>: <tt>(0x0, 0x7FFF)</tt>
-* <tt>txtest1:x7ll-llqq-q9lp-6pe</tt>: <tt>(0xFFFFFF, 0x0)</tt>
-* <tt>txtest1:x7ll-llll-lew2-gqs</tt>: <tt>(0xFFFFFF, 0x7FFF)</tt>
+The following list gives valid (sometimes strangely formatted) '''TxRef'''s and the decoded values (block height, transaction index)*
+* <tt>tx1:r29u-mqjx-putt-3p0</tt>: <tt>(456789, 1234)</tt>
+* <tt>TX1R29UMQJXPUTT3P0</tt>: <tt>(456789, 1234)</tt>
+* <tt>tx1 r29u mqjx putt 3p0</tt>: <tt>(456789, 1234)</tt>
+* <tt>tx1!r29u/mqj*x-putt^^3p0</tt>: <tt>(456789, 1234)</tt>
 
-The following list gives valid (though strangely formatted) Bitcoin TxRef's and the values in hex. (block height, transaction index)
-* <tt>tx1:rjk0-uqay-zsrw-hqe</tt>: <tt>(0x71F69, 0x89D)</tt>
-* <tt>TX1RJK0UQAYZSRWHQE</tt>:  <tt>(0x71F69, 0x89D)</tt>
-* <tt>TX1RJK0--UQaYZSRw----HQE</tt>:  <tt>(0x71F69, 0x89D)</tt>
-* <tt>tx1 rjk0 uqay zsrw hqe</tt>: <tt>(0x71F69, 0x89D)</tt>
-* <tt>tx1!rjk0\uqay*zsrw^^hqe</tt>: <tt>(0x71F69, 0x89D)</tt>
+The following list gives invalid '''TxRef'''s and the reason for their invalidity.
+* <tt>tx1:t7ll-llll-lcq3-aj4</tt>: Magic 0xB instead of 0x3.
+* <tt>tx1:rlll-llll-lu9m-00x</tt>: Version 1 instead of 0.
+* <tt>tx1:r7ll-llll-lqfu-gss2</tt>: Valid Bech32, but ten 5 bit unsigned chars instead of nine.
+* <tt>tx1:r7ll-llll-rt5h-wz</tt>: Valid Bech32, but eight 5 bit unsigned chars instead of nine.
+* <tt>tx1:r7ll-LLLL-lp6m-78v</tt>: Invalid Bech32 due to mixed case. Would decode correctly otherwise.
 
-The following list gives invalid Bitcoin TxRef's and the reason for their invalidity.
-* <tt>tx1:t7ll-llll-ldup-3hh</tt>: Magic 0xB instead of 0x3.  <tt>(0xFFFFFF, 0x7FFF)</tt>
-* <tt>tx1:rlll-llll-lfet-r2y</tt>: Version 1 instead of 0. <tt>(0xFFFFFF, 0x7FFF)</tt>
-* <tt>tx1:rjk0-u5ng-gghq-fkg7</tt>: Valid Bech32, but 10x5bit packages instead of 8.
-* <tt>tx1:rjk0-u5qd-s43z</tt>: Valid Bech32, but 6x5bit packages instead of 8.
+==== TxRef with Outpoints ====
+The following list gives properly encoded mainnet '''TxRef'''s with Outpoints and the decoded values (block height, transaction index, outpoint index)
 
-==== 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)
+* <tt>tx1:yqqq-qqqq-qqqq-rvum-0c</tt>: <tt>(0x0, 0x0, 0x0)</tt>
+* <tt>tx1:yqqq-qqll-lqqq-en8x-05</tt>: <tt>(0x0, 0x7FFF, 0x0)</tt>
+* <tt>tx1:y7ll-llqq-qqqq-ggjg-w6</tt>: <tt>(0xFFFFFF, 0x0, 0x0)</tt>
+* <tt>tx1:y7ll-llll-lqqq-jhf4-wk</tt>: <tt>(0xFFFFFF, 0x7FFF, 0x0)</tt>
 
-* <tt>tx1:yqqq-qqqq-qqqq-ksvh-26</tt>: <tt>(0x0, 0x0, 0x0)</tt>
-* <tt>tx1:yqqq-qqll-lqqq-v0h2-2k</tt>: <tt>(0x0, 0x7FFF, 0x0)</tt>
-* <tt>tx1:y7ll-llqq-qqqq-a5zy-tc</tt>: <tt>(0xFFFFFF, 0x0, 0x0)</tt>
-* <tt>tx1:y7ll-llll-lqqq-8tee-t5</tt>: <tt>(0xFFFFFF, 0x7FFF, 0x0)</tt>
+* <tt>tx1:yqqq-qqqq-qpqq-pw4v-kq</tt>: <tt>(0x0, 0x0, 0x1)</tt>
+* <tt>tx1:yqqq-qqll-lpqq-m3w3-kv</tt>: <tt>(0x0, 0x7FFF, 0x1)</tt>
+* <tt>tx1:y7ll-llqq-qpqq-22ml-hz</tt>: <tt>(0xFFFFFF, 0x0, 0x1)</tt>
+* <tt>tx1:y7ll-llll-lpqq-s4qz-hw</tt>: <tt>(0xFFFFFF, 0x7FFF, 0x1)</tt>
 
-* <tt>tx1:yqqq-qqqq-qpqq-5j9q-nz</tt>: <tt>(0x0, 0x0, 0x1)</tt>
-* <tt>tx1:yqqq-qqll-lpqq-wd7a-nw</tt>: <tt>(0x0, 0x7FFF, 0x1)</tt>
-* <tt>tx1:y7ll-llqq-qpqq-lktn-jq</tt>: <tt>(0xFFFFFF, 0x0, 0x1)</tt>
-* <tt>tx1:y7ll-llll-lpqq-9fsw-jv</tt>: <tt>(0xFFFFFF, 0x7FFF, 0x1)</tt>
+* <tt>tx1:y29u-mqjx-ppqq-sfp2-tt</tt>: <tt>(456789, 1234, 1)</tt>
 
-* <tt>tx1:yjk0-uqay-zrfq-g2cg-t8</tt>: <tt>(0x71F69, 0x89D, 0x123)</tt>
-* <tt>tx1:yjk0-uqay-zu4x-nk6u-pc</tt>: <tt>(0x71F69, 0x89D, 0x1ABC)</tt>
 
-The following list gives properly encoded Bitcoin testnet TxRef's with Outpoints and the values in hex. (block height, transaction index, TXO index)
+The following list gives properly encoded testnet '''TxRef'''s with Outpoints and the decoded values (block height, transaction index, outpoint index)
 
-* <tt>txtest1:8qqq-qqqq-qqqq-cgru-fa</tt>: <tt>(0x0, 0x0, 0x0)</tt>
-* <tt>txtest1:8qqq-qqll-lqqq-zhcp-f3</tt>: <tt>(0x0, 0x7FFF, 0x0)</tt>
-* <tt>txtest1:87ll-llqq-qqqq-nvd0-gl</tt>: <tt>(0xFFFFFF, 0x0, 0x0)</tt>
-* <tt>txtest1:87ll-llll-lqqq-fnkj-gn</tt>: <tt>(0xFFFFFF, 0x7FFF, 0x0)</tt>
+* <tt>txtest1:8qqq-qqqq-qqqq-d5ns-vl</tt>: <tt>(0x0, 0x0, 0x0)</tt>
+* <tt>txtest1:8qqq-qqll-lqqq-htgd-vn</tt>: <tt>(0x0, 0x7FFF, 0x0)</tt>
+* <tt>txtest1:87ll-llqq-qqqq-xsar-da</tt>: <tt>(0xFFFFFF, 0x0, 0x0)</tt>
+* <tt>txtest1:87ll-llll-lqqq-u0x7-d3</tt>: <tt>(0xFFFFFF, 0x7FFF, 0x0)</tt>
 
-* <tt>txtest1:8qqq-qqqq-qpqq-622t-s9</tt>: <tt>(0x0, 0x0, 0x1)</tt>
-* <tt>txtest1:8qqq-qqll-lpqq-q43k-sf</tt>: <tt>(0x0, 0x7FFF, 0x1)</tt>
-* <tt>txtest1:87ll-llqq-qpqq-3wyc-38</tt>: <tt>(0xFFFFFF, 0x0, 0x1)</tt>
-* <tt>txtest1:87ll-llll-lpqq-t3l9-3t</tt>: <tt>(0xFFFFFF, 0x7FFF, 0x1)</tt>
+* <tt>txtest1:8qqq-qqqq-qpqq-0k68-48</tt>: <tt>(0x0, 0x0, 0x1)</tt>
+* <tt>txtest1:8qqq-qqll-lpqq-4fp6-4t</tt>: <tt>(0x0, 0x7FFF, 0x1)</tt>
+* <tt>txtest1:87ll-llqq-qpqq-yj55-59</tt>: <tt>(0xFFFFFF, 0x0, 0x1)</tt>
+* <tt>txtest1:87ll-llll-lpqq-7d0f-5f</tt>: <tt>(0xFFFFFF, 0x7FFF, 0x1)</tt>
 
-* <tt>txtest1:8jk0-uqay-zrfq-xjhr-gq</tt>: <tt>(0x71F69, 0x89D, 0x123)</tt>
-* <tt>txtest1:8jk0-uqay-zu4x-aw4h-zl</tt>: <tt>(0x71F69, 0x89D, 0x1ABC)</tt>
+* <tt>txtest1:829u-mqjx-ppqq-73wp-gv</tt>: <tt>(456789, 1234, 1)</tt>
 
 
-=== Bitcoin TxRef Payload Value Choice: ===
+=== 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 ==
-- 
cgit v1.2.3


From b644e2933e98b1a30f442e711c3b2049f531a997 Mon Sep 17 00:00:00 2001
From: Hugo Nguyen <hugh.hn@gmail.com>
Date: Fri, 14 May 2021 18:14:08 -0700
Subject: update BIP number and rename file

---
 bip-0139.mediawiki            | 462 ++++++++++++++++++++++++++++++++++++++++++
 bip-hugonguyen-bsms.mediawiki | 462 ------------------------------------------
 2 files changed, 462 insertions(+), 462 deletions(-)
 create mode 100644 bip-0139.mediawiki
 delete mode 100644 bip-hugonguyen-bsms.mediawiki

diff --git a/bip-0139.mediawiki b/bip-0139.mediawiki
new file mode 100644
index 0000000..3d4e601
--- /dev/null
+++ b/bip-0139.mediawiki
@@ -0,0 +1,462 @@
+<pre>
+  BIP: 139
+  Layer: Applications
+  Title: Bitcoin Secure Multisig Setup (BSMS)
+  Author: Hugo Nguyen <hugo at nunchuk.io>
+          Peter Gray <peter at coinkite.com>
+          Marko Bencun <marko at shiftcrypto.ch>
+          Aaron Chen <aarondongchen at gmail.com>
+          Rodolfo Novak <rodolfo at coinkite.com>
+  Comments-Summary: No comments yet.
+  Comments-URI:
+  Status: Proposed
+  Type: Standards Track
+  Created: 2020-11-10
+  License: BSD-2-Clause
+</pre>
+
+==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 <tt>.bsms</tt> file extension. Encrypted data should have a <tt>.dat</tt> 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 <tt>KEY</tt> 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 (<tt>M</tt> and <tt>N</tt>).
+* 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 <tt>TOKEN</tt> to each Signer over a secure channel. The Signer can use the <tt>TOKEN</tt> to derive an <tt>ENCRYPTION_KEY</tt>. Refer to the [[#Encryption]] section below for details on the <tt>TOKEN</tt>, the key derivation function and the encryption scheme. Depending on the use case, the Coordinator can decide whether to share one common <tt>TOKEN</tt> for all Signers, or to have one per Signer.
+* If encryption is disabled, the <tt>TOKEN</tt> is set to <tt>0x00</tt>, and all the encryption/decryption steps below can be skipped.
+
+=====Signer=====
+
+* The Signer initiates the multisig wallet creation session by setting the <tt>TOKEN</tt>. The Signer derives an <tt>ENCRYPTION_KEY</tt> from the <tt>TOKEN</tt>. The Signer can keep the session open until a different value for the <tt>TOKEN</tt> is set.
+* The Signer generates a key record by prompting the user for a multisig derivation path and retrieves the <tt>KEY</tt> 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 <tt>KEY</tt>s for different wallets.
+* The first line in the record must be the specification version (<tt>BSMS 1.0</tt> as of this writing). The second line must be the hex-encoded <tt>TOKEN</tt>. The third line must be the <tt>KEY</tt>. The <tt>KEY</tt> is a public key or an XPUB plus the key origin information, written in the descriptor-defined format, i.e.: <tt>[{master key fingerprint}/{derivation path}]{KEY}</tt>. The fourth line is a text description of the key, 80 characters maximum. The fifth line must be a <tt>SIG</tt>, whereas <tt>SIG</tt> 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 (<tt>MAC</tt>) for the record. The first 16 bytes of the <tt>MAC</tt> serves as the Initialization Vector (<tt>IV</tt>) for the encryption.
+* The Signer encrypts the key record with the <tt>ENCRYPTION_KEY</tt> and <tt>IV</tt>.
+* The Signer encodes the <tt>MAC</tt> and the ciphertext into hexadecimal format, then concatenates the results: <tt>(MAC || ciphertext)</tt>.
+
+====Round 2====
+
+=====Coordinator=====
+
+* The Coordinator gathers key records from all participating Signers. The Coordinator verifies that there are exactly <tt>N</tt> unique key records before the wallet setup session expires.
+* For each key record, the Coordinator extracts the <tt>MAC</tt> from the data, sets <tt>IV</tt> to the first 16 bytes of the <tt>MAC</tt>, then decrypts the ciphertext using the <tt>ENCRYPTION_KEY</tt> and <tt>IV</tt>.
+* The Coordinator verifies that the included <tt>MAC</tt> is valid given the plaintext.
+* The Coordinator verifies that the key records have compatible specification versions.
+* The Coordinator verifies that the included <tt>SIG</tt> is valid given the <tt>KEY</tt>.
+* 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 (<tt>BSMS 1.0</tt> 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 <tt>/</tt> and use non-hardened derivation. If there are no template or restrictions, it must say <tt>No path restrictions</tt>. 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 <tt>MAC</tt> for the record. The first 16 bytes of the <tt>MAC</tt> serves as the <tt>IV</tt> for the encryption.. 
+* The Coordinator encrypts the descriptor record with the <tt>ENCRYPTION_KEY</tt> and <tt>IV</tt>.
+* The Coordinator encodes the <tt>MAC</tt> and the ciphertext into hexadecimal format, then concatenates the results: <tt>(MAC || ciphertext)</tt>.
+* The Coordinator sends the encrypted descriptor record to all participating Signers.
+
+=====Signer=====
+
+* The Signer imports the descriptor record.
+* The Signer extracts the <tt>MAC</tt> from the data, sets <tt>IV</tt> to the first 16 bytes of the <tt>MAC</tt>, then decrypts the ciphertext using the <tt>ENCRYPTION_KEY</tt> (derived from the open session) and <tt>IV</tt>.
+* The Signer verifies that the included <tt>MAC</tt> 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 <tt>KEY</tt> is included in the descriptor or descriptor template, using path and fingerprint information provided. The check must perform an exact match on the <tt>KEY</tt>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, <tt>M</tt>, <tt>N</tt>, and the position(s) of the Signer's own <tt>KEY</tt> in the policy script. The total number of Signers, <tt>N</tt>, is important to prevent a <tt>KEY</tt> insertion attack. The position is important for scripts where <tt>KEY</tt> order matters. When applicable, all positions of the <tt>KEY</tt> 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 <tt>KEY</tt> 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.
+
+# <tt>NO_ENCRYPTION</tt> : the <tt>TOKEN</tt> is set to <tt>0x00</tt>. Encryption is disabled.
+# <tt>STANDARD</tt> : the <tt>TOKEN</tt> is a 64-bit nonce.
+# <tt>EXTENDED</tt> : the <tt>TOKEN</tt> is a 128-bit nonce.
+
+The <tt>TOKEN</tt> 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 <tt>STANDARD</tt> mode. This encoding is not recommended in <tt>EXTENDED</tt> mode as it can result in potential confusion between seed mnemonics and <tt>TOKEN</tt> 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:
+
+<tt>DKey = PBKDF2(PRF, Password, Salt, c, dkLen)</tt>
+
+Whereas:
+
+* PRF = SHA512
+* Password = "No SPOF"
+* Salt = <tt>TOKEN</tt>
+* c = 2048
+* dkLen = 256
+* DKey = Derived <tt>ENCRYPTION_KEY</tt>
+
+====Encryption Scheme====
+The encryption scheme is [https://tools.ietf.org/html/rfc3686 AES-256-CTR].
+
+<tt>MAC = HMAC-SHA256(HMAC_Key, hex-encoded TOKEN || Data)</tt>
+
+<tt>IV = First 16 bytes of MAC</tt>
+
+<tt>Ciphertext = AES-256-CTR-Encrypt(Plaintext, DKey, IV)</tt>
+
+<tt>Plaintext = AES-256-CTR-Decrypt(Ciphertext, DKey, IV)</tt>
+
+Whereas:
+* DKey = <tt>ENCRYPTION_KEY</tt>
+* HMAC_Key = SHA256(<tt>ENCRYPTION_KEY</tt>)
+* Data = the plaintext, e.g. the entire key record in round 1 and the entire descriptor record in round 2
+
+The <tt>MAC</tt> is to be sent along with the key and descriptor record, as specified above. Because it is a <tt>MAC</tt> 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:
+
+<tt>XPUB/**</tt>
+
+Whereas <tt>/**</tt> 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 <tt>/**</tt> with the restrictions.
+
+For example, the following template and derivation path restrictions:
+* <tt>wsh(sortedmulti(2,XPUB1/**,XPUB2/**))</tt>
+* <tt>/0/*,/1/*</tt>
+
+Should translate to two concrete descriptors:
+* <tt>wsh(sortedmulti(2,XPUB1/0/*,XPUB2/0/*))</tt>
+* <tt>wsh(sortedmulti(2,XPUB1/1/*,XPUB2/1/*))</tt>
+
+==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 <tt>TOKEN</tt>. The second one is the confirmation of the wallet's first address.
+
+The <tt>TOKEN</tt> is used to encrypt the two rounds of communication between the Signer and the Coordinator. A <tt>MAC</tt> is also generated from the <tt>TOKEN</tt> and plaintext to authenticate the data being exchanged. The <tt>TOKEN</tt> is only needed during the setup phase, and can be safely discarded afterwards. It is not recommended to use the same <tt>TOKEN</tt> 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 <tt>TOKEN</tt>, and to completely erase knowledge of the <tt>TOKEN</tt> after the multisig wallet has been set up.
+
+==Test Vectors==
+
+===Mode: <tt>NO_ENCRYPTION</tt> 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
+** <tt>signer_1_key.bsms</tt>:
+<pre>BSMS 1.0
+00
+[59865f44/48'/0'/0'/2']026d15412460ba0d881c21837bb999233896085a9ed4e5445bd637c10e579768ba
+Signer 1 key
+H6DXgqkCb353BDPkzppMFpOcdJZlpur0WRetQhIBqSn6DFzoQWBtm+ibP5wERDRNi0bxxev9B+FIvyQWq0s6im4=</pre>
+
+* Signer 2
+** MASTER_KEY_FINGERPRINT: b7044ca6
+** PRIVATE_KEY (m/48'/0'/0'/2'): KwT7BZDWjos4JAdfKi8NqF46Kj3rppTwN8KGhPbzmmugiZioFW3r
+** Public Key (m/48'/0'/0'/2'): 030baf0497ab406ff50cb48b4013abac8a0338758d2fd54cd934927afa57cc2062
+** Legacy signature
+** <tt>signer_2_key.bsms</tt>:
+<pre>BSMS 1.0
+00
+[b7044ca6/48'/0'/0'/2']030baf0497ab406ff50cb48b4013abac8a0338758d2fd54cd934927afa57cc2062
+Signer 2 key
+H08mGNGN+NxX/snt+6eX2Q1HjjfDkOtotglshHi7xdsBdIrTVMCQbgQ5SdACNZ0B2AJcifK11nJj43SvaitSemI=</pre>
+
+====ROUND 2====
+* Coordinator
+** <tt>my_multisig_wallet.bsms</tt>:
+<pre>BSMS 1.0
+wsh(sortedmulti(1,[59865f44/48'/0'/0'/2']026d15412460ba0d881c21837bb999233896085a9ed4e5445bd637c10e579768ba,[b7044ca6/48'/0'/0'/2']030baf0497ab406ff50cb48b4013abac8a0338758d2fd54cd934927afa57cc2062))#rzx9dffd
+No path restrictions
+bc1quqy523xu3l8che3s8vja8n33qtg0uyugr9l5z092s3wa50p8t7rqy6zumf</pre>
+
+===Mode: <tt>NO_ENCRYPTION</tt>===
+====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
+** <tt>signer_1_key.bsms</tt>:
+<pre>BSMS 1.0
+00
+[1cf0bf7e/48'/0'/0'/2']xpub6FL8FhxNNUVnG64YurPd16AfGyvFLhh7S2uSsDqR3Qfcm6o9jtcMYwh6DvmcBF9qozxNQmTCVvWtxLpKTnhVLN3Pgnu2D3pAoXYFgVyd8Yz
+Signer 1 key
+IB7v+qi1b+Xrwm/3bF+Rjl8QbIJ/FMQ40kUsOOQo1SqUWn5QlFWbBD8BKPRetfo1L1N7DmYjVscZNsmMrqRJGWw=</pre>
+
+* Signer 2
+** MASTER_KEY_FINGERPRINT: 4fc1dd4a
+** PRIVATE_KEY (m/48'/0'/0'/2'): L4JNkJfLBDyWfTLbKJ1H3w56GUMsvdfjCkzRo5RHXfJ6bdHqm6cN
+** XPUB (m/48'/0'/0'/2'): xpub6EebMbEps7ZcV3FYEnddRsvrFWDrt2tiPmCeM7pPXQEmphvq9ZfJ1LWFUDjf3vxCeBuPrfyGrMazWUsYsetrnHatQZVLJH7LsgCjtMqdzgj
+** Legacy signature
+** <tt>signer_2_key.bsms</tt>:
+<pre>BSMS 1.0
+00
+[4fc1dd4a/48'/0'/0'/2']xpub6EebMbEps7ZcV3FYEnddRsvrFWDrt2tiPmCeM7pPXQEmphvq9ZfJ1LWFUDjf3vxCeBuPrfyGrMazWUsYsetrnHatQZVLJH7LsgCjtMqdzgj
+Signer 2 key
+HzUa4Z76PFHMl54flIIF3XKiHZ+KbWjjxCEG5G3ZqZSqTd6OgTiFFLqq9PXJXdfYm6/cnL8IVWQgjFF9DQhIqQs=</pre>
+
+====ROUND 2====
+* Coordinator
+** <tt>my_multisig_wallet.bsms</tt>:
+<pre>BSMS 1.0
+wsh(sortedmulti(2,[1cf0bf7e/48'/0'/0'/2']xpub6FL8FhxNNUVnG64YurPd16AfGyvFLhh7S2uSsDqR3Qfcm6o9jtcMYwh6DvmcBF9qozxNQmTCVvWtxLpKTnhVLN3Pgnu2D3pAoXYFgVyd8Yz/**,[4fc1dd4a/48'/0'/0'/2']xpub6EebMbEps7ZcV3FYEnddRsvrFWDrt2tiPmCeM7pPXQEmphvq9ZfJ1LWFUDjf3vxCeBuPrfyGrMazWUsYsetrnHatQZVLJH7LsgCjtMqdzgj/**))
+/0/*,/1/*
+bc1qrgc6p3kylfztu06ysl752gwwuekhvtfh9vr7zg43jvu60mutamcsv948ej</pre>
+
+===Mode: <tt>STANDARD</tt> 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
+** <tt>signer_1_key.bsms</tt>:
+<pre>BSMS 1.0
+a54044308ceac9b7
+[b7868815/48'/0'/0'/2']xpub6FA5rfxJc94K1kNtxRby1hoHwi7YDyTWwx1KUR3FwskaF6HzCbZMz3zQwGnCqdiFeMTPV3YneTGS2YQPiuNYsSvtggWWMQpEJD4jXU7ZzEh
+Signer 1 key
+H8DYht5P6ko0bQqDV6MtUxpzBSK+aVHxbvMavA5byvLrOlCEGmO1WFR7k2wu42J6dxXD8vrmDQSnGq5MTMMbZ98=</pre>
+
+* Signer 1 encryption
+** HMAC_KEY (hex): 3d4c422806ba8964c9ee45070cd675c024d96648a0ddb4001325818c84951de2
+** MAC (hex): fbdbdb64e6a8231c342131d9f13dcd5a954b4c5021658fa5afcb3fc74dc82706
+** IV (hex) : fbdbdb64e6a8231c342131d9f13dcd5a
+** CIPHERTEXT (hex): 53f491cfd1431c292d922ea5a5dec3eb8ddaa6ed38ae109e7b040f0f23013e89a89b4d27476761a01197a3277850b2bc1621ae626efe65f2081eec6eb571c4f787bf1c49d061b43f70fd73cb3f37fa591d2400973ac0644c8941a83f1d4155e98f01fa2fdeb9f86c2e2413154fd18566a28fb0d9d8bd6172efabcfa6dab09ee7029bf3dd43376df52c118a6d291ec168f4ec7f7df951dfc6135fd8cb4b234da62eaea6017dfe5ca418f083e02e3aba2962ba313ba17b6468c7672fb218329a9f3fe4e4887fb87dac57c63ebff0e715a44498d18de8afc10e1cfeb46a1fc65ce871fef8a43b289305433a90c342d025aa4c19454fcfbcf911e9e2f928d5affd0536a6ddc2e816
+** <tt>signer_1_key.dat</tt>: <pre>fbdbdb64e6a8231c342131d9f13dcd5a954b4c5021658fa5afcb3fc74dc8270653f491cfd1431c292d922ea5a5dec3eb8ddaa6ed38ae109e7b040f0f23013e89a89b4d27476761a01197a3277850b2bc1621ae626efe65f2081eec6eb571c4f787bf1c49d061b43f70fd73cb3f37fa591d2400973ac0644c8941a83f1d4155e98f01fa2fdeb9f86c2e2413154fd18566a28fb0d9d8bd6172efabcfa6dab09ee7029bf3dd43376df52c118a6d291ec168f4ec7f7df951dfc6135fd8cb4b234da62eaea6017dfe5ca418f083e02e3aba2962ba313ba17b6468c7672fb218329a9f3fe4e4887fb87dac57c63ebff0e715a44498d18de8afc10e1cfeb46a1fc65ce871fef8a43b289305433a90c342d025aa4c19454fcfbcf911e9e2f928d5affd0536a6ddc2e816</pre>
+
+* Signer 2
+** MASTER_KEY_FINGERPRINT: eedff89a
+** PRIVATE_KEY (m/48'/0'/0'/2'): Kz1ijnkDXmc65NWTYdg47DDaQgSGJAPfhJG9Unm36oqZPpPXuNR6
+** XPUB (m/48'/0'/0'/2'): xpub6EhJvMneoLWAf8cuyLBLQiKiwh89RAmqXEqYeFuaCEHdHwxSRfzLrUxKXEBap7nZSHAYP7Jfq6gZmucotNzpMQ9Sb1nTqerqW8hrtmx6Y6o
+** Legacy signature
+** <tt>signer_2_key.bsms</tt>:
+<pre>BSMS 1.0
+a54044308ceac9b7
+[eedff89a/48'/0'/0'/2']xpub6EhJvMneoLWAf8cuyLBLQiKiwh89RAmqXEqYeFuaCEHdHwxSRfzLrUxKXEBap7nZSHAYP7Jfq6gZmucotNzpMQ9Sb1nTqerqW8hrtmx6Y6o
+Signer 2 key
+H/IHW5dMGYsrRdYEz3ux+kKnkWBtxHzfYkREpnYbco38VnMvIxCbDuf7iu6960qDhBLR/RLjlb9UPtLmCMbczDE=</pre>
+
+* Signer 2 encryption
+** HMAC_KEY (hex): 3d4c422806ba8964c9ee45070cd675c024d96648a0ddb4001325818c84951de2
+** MAC (hex): 383d05b7351a2cef7cca2850450f5efbbc4a3f8ea35707dda87a3692f0f2ebae
+** IV (hex) : 383d05b7351a2cef7cca2850450f5efb
+** CIPHERTEXT (hex): 71860b7c69f3a7665c3c3e85c45735bff78535a37ec6610b724627c73696820d519a9251703b17626b63898580233bebbb310aedbc370224b044ee19600bfe583445a6f26fb9bb5790bae516892655adb0e5dfc12be4609c2e0818d4f1f3bfccc4cd1a36f419d6cd842c913ae81eef4865ad473c32c3ee69cd98d6d0a088e2abdd01fe68b5c0503bb9183f9a912506204e5a9c6bd5a1626ff7eac30312a0b85004307c525e52fa3ad45a0b02eabc8cfaea0215bb6e60ee5f32d6673955290e008fbaef362977a21fd9830e3a604f9bb318cdcde456eae91dbedaa069bcd1efb0f981d5b0e502bd4dada903205458a00914887226a8dde317c02a8be4342acb97a8fee79fbe23
+** <tt>signer_2_key.dat</tt>: <pre>383d05b7351a2cef7cca2850450f5efbbc4a3f8ea35707dda87a3692f0f2ebae71860b7c69f3a7665c3c3e85c45735bff78535a37ec6610b724627c73696820d519a9251703b17626b63898580233bebbb310aedbc370224b044ee19600bfe583445a6f26fb9bb5790bae516892655adb0e5dfc12be4609c2e0818d4f1f3bfccc4cd1a36f419d6cd842c913ae81eef4865ad473c32c3ee69cd98d6d0a088e2abdd01fe68b5c0503bb9183f9a912506204e5a9c6bd5a1626ff7eac30312a0b85004307c525e52fa3ad45a0b02eabc8cfaea0215bb6e60ee5f32d6673955290e008fbaef362977a21fd9830e3a604f9bb318cdcde456eae91dbedaa069bcd1efb0f981d5b0e502bd4dada903205458a00914887226a8dde317c02a8be4342acb97a8fee79fbe23</pre>
+
+====ROUND 2====
+*Coordinator
+** <tt>my_multisig_wallet.bsms</tt>:
+<pre>BSMS 1.0
+wsh(sortedmulti(2,[b7868815/48'/0'/0'/2']xpub6FA5rfxJc94K1kNtxRby1hoHwi7YDyTWwx1KUR3FwskaF6HzCbZMz3zQwGnCqdiFeMTPV3YneTGS2YQPiuNYsSvtggWWMQpEJD4jXU7ZzEh/**,[eedff89a/48'/0'/0'/2']xpub6EhJvMneoLWAf8cuyLBLQiKiwh89RAmqXEqYeFuaCEHdHwxSRfzLrUxKXEBap7nZSHAYP7Jfq6gZmucotNzpMQ9Sb1nTqerqW8hrtmx6Y6o/**))
+/0/*,/1/*
+bc1qhs4u273g4azq7kqqpe6vh5wfhasfmrq7nheyzsnq77humd7rwtkqagvakf</pre>
+
+*Coordinator encryption
+** HMAC_KEY (hex): 3d4c422806ba8964c9ee45070cd675c024d96648a0ddb4001325818c84951de2
+** MAC (hex): 734ce791b466861945e1ef6f74c63faec590793de54831f0036b28d08714b71a
+** IV (hex) : 734ce791b466861945e1ef6f74c63fae
+** CIPHERTEXT (hex): 273cad18a5e1eff37dba6d850749594c9a3fd32b2069e8c69983ea269c5044b6bcaea26d9dbc8ad5d28bb8abfa02e3bfc7632fcc5c2b76e9abb1982ff11295858cfe44a8b97110ae970f58fff3fb6477f38ca9609eec78eedb1d640eaba489fd5e41e787b8d0bde48f1fa99cca641cabbee0f513fb1040cb73df10a57c9a34e4efcb069cd4c75467442c15d878ed9f40e3dffb98294931a6da4f444ae46f739b7fe002ce19fcfe71b05b9783d797ba45d568febbc8a2b0850da67f349d8567342352e1712c3d2a7ea1b2721df5efdb844431f0e5dcfa4acacb194c20785c9bb6dde90d64352fc913e9073b3b416be713bcc7632c821bbfddafa6199d471c54fb899f347f5fc706787ccaa82332dc8b93aeb3de3497d8e5c75f0f5d718c74bc6f8194fe999948e517f1c98398d9cb907d200f1d045394704b074dfb10e587f54fd78e95ef4bcbe77bf1376b390c3f47c91c12b2ed14073ea56bceab41f924302e62183c456b06d96b3da30439cb4320c764a0d6d1b3dabc06fc
+** <tt>my_multisig_wallet.dat</tt>: <pre>734ce791b466861945e1ef6f74c63faec590793de54831f0036b28d08714b71a273cad18a5e1eff37dba6d850749594c9a3fd32b2069e8c69983ea269c5044b6bcaea26d9dbc8ad5d28bb8abfa02e3bfc7632fcc5c2b76e9abb1982ff11295858cfe44a8b97110ae970f58fff3fb6477f38ca9609eec78eedb1d640eaba489fd5e41e787b8d0bde48f1fa99cca641cabbee0f513fb1040cb73df10a57c9a34e4efcb069cd4c75467442c15d878ed9f40e3dffb98294931a6da4f444ae46f739b7fe002ce19fcfe71b05b9783d797ba45d568febbc8a2b0850da67f349d8567342352e1712c3d2a7ea1b2721df5efdb844431f0e5dcfa4acacb194c20785c9bb6dde90d64352fc913e9073b3b416be713bcc7632c821bbfddafa6199d471c54fb899f347f5fc706787ccaa82332dc8b93aeb3de3497d8e5c75f0f5d718c74bc6f8194fe999948e517f1c98398d9cb907d200f1d045394704b074dfb10e587f54fd78e95ef4bcbe77bf1376b390c3f47c91c12b2ed14073ea56bceab41f924302e62183c456b06d96b3da30439cb4320c764a0d6d1b3dabc06fc</pre>
+
+===Mode: <tt>EXTENDED</tt> 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
+** <tt>signer_1_key.bsms</tt>:
+<pre>BSMS 1.0
+108a2360adb302774eb521daebbeda5e
+[793cc70b/48'/0'/0'/1']xpub6ErVmcYYHmavsMgxEcTZyzN5sqth1ZyRpFNJC26ij1wYGC2SBKYrgt9yariSbn7HLRoZUvhUhmPfsRTPrdhhGFscpPZzmch6UTdmRP1aZUj
+Signer 1 key
+ILG47LpCtjoD9UxL87jo5QFqA90t8g9fDQp/KBojdKgPPGB1pMx2bf9hPdORNZIOdCc/2+Gs6AOs3BEK9ubIuBw=</pre>
+
+* Signer 1 encryption
+** HMAC_KEY (hex): 1162cdace4ac9fcde1f96924b93714143d057a701de83ebaed248d1c9154f9fd
+** MAC (hex): ea12776c73de4bd5ea57c2d19eb8e0be856ac0d7f5651f7b74be4563d61ba5b1
+** IV (hex) : ea12776c73de4bd5ea57c2d19eb8e0be
+** CIPHERTEXT (hex): a36f34232bff47a853092654a718fea4f5f57d6a1f3d38fede04e2414da12c90cefc24ef662f736886d9a7fd6e7db636ca47217803c86b7fbcebe4ad6b71cffc261069c135bd2b2430fb2b446ff0203df34fbbc6801243e8a930b9d0cd3a9b160b8dcdc9131ce6e97641e6314b3285ff341013f302e308c1b2eba7ced0103a8999fe2bd86f844392938e7926cd26d023b764d0b8ff92b2fbdf995884c738414b83563ef2a0050279bf46d0e8271ea5d6af8154847c5736129a7a83a35a3cc747b2be4b389886cb57456678353b60473ebc4ab85d9c9131a17a1e288717343d9008825b16c48d7e93927f37b530033192c67b70dec0411a3e5952d2525c7eb80721676e1a6299248c17f8078202f3bb0932e9f263b0ab
+** <tt>signer_1_key.dat</tt>: <pre>ea12776c73de4bd5ea57c2d19eb8e0be856ac0d7f5651f7b74be4563d61ba5b1a36f34232bff47a853092654a718fea4f5f57d6a1f3d38fede04e2414da12c90cefc24ef662f736886d9a7fd6e7db636ca47217803c86b7fbcebe4ad6b71cffc261069c135bd2b2430fb2b446ff0203df34fbbc6801243e8a930b9d0cd3a9b160b8dcdc9131ce6e97641e6314b3285ff341013f302e308c1b2eba7ced0103a8999fe2bd86f844392938e7926cd26d023b764d0b8ff92b2fbdf995884c738414b83563ef2a0050279bf46d0e8271ea5d6af8154847c5736129a7a83a35a3cc747b2be4b389886cb57456678353b60473ebc4ab85d9c9131a17a1e288717343d9008825b16c48d7e93927f37b530033192c67b70dec0411a3e5952d2525c7eb80721676e1a6299248c17f8078202f3bb0932e9f263b0ab</pre>
+
+* Signer 2
+** MASTER_KEY_FINGERPRINT: b3118e52
+** PRIVATE_KEY (m/48'/0'/0'/1'): L4SnPjcHszMg3Wi2YYxEYnzM2zFeFkFr5NcLZ18YQeyJwaSFbTud
+** XPUB (m/48'/0'/0'/1'): xpub6Du5Jn6eYZE96ccmAc1ZTFPzdnzrvqfG4mpamDun2qZYKywoiQJMCbS3kWWMr6U3XW6s125RLsaPABWgv2yA749ieaMe67FxkTjMsbcxCch
+** Legacy signature
+** <tt>signer_2_key.bsms</tt>:
+<pre>BSMS 1.0
+d3fabc873b98165254fe18a71b5335b0
+[b3118e52/48'/0'/0'/1']xpub6Du5Jn6eYZE96ccmAc1ZTFPzdnzrvqfG4mpamDun2qZYKywoiQJMCbS3kWWMr6U3XW6s125RLsaPABWgv2yA749ieaMe67FxkTjMsbcxCch
+Signer 2 key
+IDK4d/oO0pgfrwRu4Zb8vqlPEmJb9aKT1K2CCnI3RKepVAKs3fZsBrypcCdQfUy1TG/3O5vAR3gjldxcCA1Wzg8=</pre>
+
+* Signer 2 encryption
+** HMAC_KEY (hex): 43a4e704bd1bade703023004b00290f1a7b005474a581d869a217068eedf3f57
+** MAC (hex): 4a3ff970d027010e83b4fbf2845a23907a301b3df692a9265e2ca679697ac718
+** IV (hex) : 4a3ff970d027010e83b4fbf2845a2390
+** CIPHERTEXT (hex): c8f4a6a6714eff90aa48cbefe6750c2ee3cc72182eb455e964f0ba59ada3ecd758c29f0fab7e33aaa82a340a18d9c793ddab09dc7e714864faac1ecea370d4f102533b739da38aa0491433f35eadec08f203685f04d1f6ec35d397d99e4f8096a5691075e3f54fd9ff58faf947f276bbe1031f827b274bd2f60fcb526add7058889104b189d7da22ac7be1f7ddd380bbebd5c6983a8a3c5fa86913e3d23c40935072ce03d9bdeb07791dc836d44b4d4c62f364d0e4f3580369ea8f6ebb774b7fda4a7ac6f5ae6b2f52b10cd71bdf3cdb5889e77d5eb1f2f647b798cdd6b3e5b964c9265daea3668d7e4cb53f724151923da1a87bbcd2abd8b164de474d865c51af69885431d26f88a5c8eea7d0dfdb52ca622017808a
+** <tt>signer_2_key.dat</tt>: <pre>4a3ff970d027010e83b4fbf2845a23907a301b3df692a9265e2ca679697ac718c8f4a6a6714eff90aa48cbefe6750c2ee3cc72182eb455e964f0ba59ada3ecd758c29f0fab7e33aaa82a340a18d9c793ddab09dc7e714864faac1ecea370d4f102533b739da38aa0491433f35eadec08f203685f04d1f6ec35d397d99e4f8096a5691075e3f54fd9ff58faf947f276bbe1031f827b274bd2f60fcb526add7058889104b189d7da22ac7be1f7ddd380bbebd5c6983a8a3c5fa86913e3d23c40935072ce03d9bdeb07791dc836d44b4d4c62f364d0e4f3580369ea8f6ebb774b7fda4a7ac6f5ae6b2f52b10cd71bdf3cdb5889e77d5eb1f2f647b798cdd6b3e5b964c9265daea3668d7e4cb53f724151923da1a87bbcd2abd8b164de474d865c51af69885431d26f88a5c8eea7d0dfdb52ca622017808a</pre>
+
+* Signer 3
+** MASTER_KEY_FINGERPRINT: 842bd2ed
+** PRIVATE_KEY (m/48'/0'/0'/1'): L1ehZHpo2UFHc1yaBWDU4bKVycUwcU2TESm92wbfq6xK6qpZZJP6
+** XPUB (m/48'/0'/0'/1'): xpub6Ex81KopPkEt9hJiWHabYy8LNsSR4A7sUQoFBk9dR8XxHrr4p9HrYWN3NCf5uwfopHnQkCG7FYnZMztKbtRtbh6tzZC4xtHPbmVVxRSN7ic
+** Legacy signature
+** <tt>signer_3_key.bsms</tt>:
+<pre>BSMS 1.0
+78a7d5e7549453d719150de5459c9ce5
+[842bd2ed/48'/0'/0'/1']xpub6Ex81KopPkEt9hJiWHabYy8LNsSR4A7sUQoFBk9dR8XxHrr4p9HrYWN3NCf5uwfopHnQkCG7FYnZMztKbtRtbh6tzZC4xtHPbmVVxRSN7ic
+Signer 3 key
+IL77mML0xo/O9dJn0T5EpQLuyRPPrdpgVJbtsdAugW5iX0MQ3Ci0f8jVnXu68Xm07CYjYGKX8af72jmkQKhNud0=</pre>
+
+* Signer 3 encryption
+** HMAC_KEY (hex): ab93ce7bf0f91c62a66d00ea9bf5e5c00b854ee2cfc2fb06f6eeff738abcdc26
+** MAC (hex): e82cfcccbd4bd4d3b76e28133eecd13f7362f4a8b4c4baa3e5f6ba2dfb4d69b8
+** IV (hex) : e82cfcccbd4bd4d3b76e28133eecd13f
+** CIPHERTEXT (hex): b44433f0b564ec35a1e71371f25844088084b47402c90d52fee7237167b58a60a28c234af9123e104773136e8446d799541c8566882787caee7cd1fa8628aba63aa9e9d7cca0ddee92f96dd881535b19a131a1f487a1909e42d62945fd0ba08dacd7dc09a22ffe47e0410b8b85df92e4a8bbf9b46f0062da02e3ae94144a00bae917acc1246d8d1a4dca105708f55379caefef9d4c152f56b65ab4bd7b48f60233f57ba6d705387c79aeaa2a279e3314004bf16fcd7e7d2adef34b0ab3c22bc5461f2c09dce69065605e4fb96958c55984391712b3547e3914ad4ecca2c088be280dfcfe374a112515674aeca57b885e81dbef6a353ca387f4514db3158eb69f0d2725d42ad8102c05c26ad501d48b889c624035ead4
+** <tt>signer_3_key.dat</tt>: <pre>e82cfcccbd4bd4d3b76e28133eecd13f7362f4a8b4c4baa3e5f6ba2dfb4d69b8b44433f0b564ec35a1e71371f25844088084b47402c90d52fee7237167b58a60a28c234af9123e104773136e8446d799541c8566882787caee7cd1fa8628aba63aa9e9d7cca0ddee92f96dd881535b19a131a1f487a1909e42d62945fd0ba08dacd7dc09a22ffe47e0410b8b85df92e4a8bbf9b46f0062da02e3ae94144a00bae917acc1246d8d1a4dca105708f55379caefef9d4c152f56b65ab4bd7b48f60233f57ba6d705387c79aeaa2a279e3314004bf16fcd7e7d2adef34b0ab3c22bc5461f2c09dce69065605e4fb96958c55984391712b3547e3914ad4ecca2c088be280dfcfe374a112515674aeca57b885e81dbef6a353ca387f4514db3158eb69f0d2725d42ad8102c05c26ad501d48b889c624035ead4</pre>
+
+====ROUND 2====
+* Coordinator
+** <tt>my_multisig_wallet.bsms</tt>:
+<pre>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</pre>
+
+* Send to Signer 1:
+** HMAC_KEY (hex): 1162cdace4ac9fcde1f96924b93714143d057a701de83ebaed248d1c9154f9fd
+** MAC (hex): 01bf557b6d44b3fbf07f8ec155cbdec42d85d856e174342563dd83b40ad7c025
+** IV (hex) : 01bf557b6d44b3fbf07f8ec155cbdec4
+** CIPHERTEXT (hex): 617ed25b4b8fd88b806cbebcc1731b071465514a805f7ba2de60e291bc9493f31aa0f9b0665ba822cf9a2e21c02649b5c3f7dbad317ae898292cb6fe992520f68c0ebe9d1434b348af10453f1be0a392a616d43ba21e5e7fa3c995dce54db947fe5dbad4a9a77f37b3aef58c54ee3e496c8312d3033359aed0de8cf28b82035ee7a38c9b23c9d95682fb15936bf2247546d2ba9b3ada605f5c89f0a3bbaa86cb4b5dded9a65004912c0afbbfd01f0115447f5625e8523f9de16165d32c4b21103d8ac965e2f7e17641ee1a8c5902e8dbb461c6c7d05141f7bba66b8b3608037fb251b55fa461c9441c6427921545a34a1798127d5bf9cc92423f7e62c769e232c65db8cc5124577012d49941143c3b4758212a8afa0475c9b3597da2e99d585039339b7d73611aa277878d212875051683053db9c630391e0b32356523e9fa8a58a334e16fe6650472f336ddaa8c587992b6c0c0e480b680261579a11cf9d036614abc113dde53653273f5ce82ea0bc10e38ca52ac66838aa49ff46c3a7d5096db439c15d3c2e8de55e4ac7315a57eb9997f219c378af86c858867ce583ed84e4d9c68aecfbca9ebff16b0ac91531125e273b215db688ffe52c8033eb78914b87c0fa2001c52e90c92765712e50384ddcf4d0953ac3cc8137abcb2a85d603a6cc207472677
+** <tt>my_multisig_wallet_for_signer_1.dat</tt>: <pre>01bf557b6d44b3fbf07f8ec155cbdec42d85d856e174342563dd83b40ad7c025617ed25b4b8fd88b806cbebcc1731b071465514a805f7ba2de60e291bc9493f31aa0f9b0665ba822cf9a2e21c02649b5c3f7dbad317ae898292cb6fe992520f68c0ebe9d1434b348af10453f1be0a392a616d43ba21e5e7fa3c995dce54db947fe5dbad4a9a77f37b3aef58c54ee3e496c8312d3033359aed0de8cf28b82035ee7a38c9b23c9d95682fb15936bf2247546d2ba9b3ada605f5c89f0a3bbaa86cb4b5dded9a65004912c0afbbfd01f0115447f5625e8523f9de16165d32c4b21103d8ac965e2f7e17641ee1a8c5902e8dbb461c6c7d05141f7bba66b8b3608037fb251b55fa461c9441c6427921545a34a1798127d5bf9cc92423f7e62c769e232c65db8cc5124577012d49941143c3b4758212a8afa0475c9b3597da2e99d585039339b7d73611aa277878d212875051683053db9c630391e0b32356523e9fa8a58a334e16fe6650472f336ddaa8c587992b6c0c0e480b680261579a11cf9d036614abc113dde53653273f5ce82ea0bc10e38ca52ac66838aa49ff46c3a7d5096db439c15d3c2e8de55e4ac7315a57eb9997f219c378af86c858867ce583ed84e4d9c68aecfbca9ebff16b0ac91531125e273b215db688ffe52c8033eb78914b87c0fa2001c52e90c92765712e50384ddcf4d0953ac3cc8137abcb2a85d603a6cc207472677</pre>
+
+* Send to Signer 2:
+** HMAC_KEY (hex): 43a4e704bd1bade703023004b00290f1a7b005474a581d869a217068eedf3f57
+** MAC (hex): 974ba77900c43c463dadaa6eaf24aaeb1b25b443cf155229b719bcbf8b343092
+** IV (hex) : 974ba77900c43c463dadaa6eaf24aaeb
+** CIPHERTEXT (hex): 86288c97a6341974a35015f97fbbc8db7655639c839fc438706f82fce36a82dd17e2d4d4a674516c4fc5c3a33d6097dd8fc5c6605018946741ed9f58d8fe530a808f16f0dd705cacfd273e34a158bd7566774dd31506b8280e448fabb72d0e7dfc05cee1142b61921dfaf0b0039d885cc0aa76c429025efc2ba49a8af15b58e75a5a83ba4838a9a4c9f13725f5aecefd8511513d93797f37b93150b9dca725685883188e39142dd8d3cf4b617c7936bdb3875415bbf6dfb2fe1a39ae2aed9fd2909aebd0355a5cc9a55bcb84048c851a1873948e495180f336edeb63f54bcf83feaa4d2453251260e24293e49815c2369c1c045083c412c973987fd7c9296a71cda424823ed32380ba442394500b7d2d2335818099090aaf08ca4e180869c546f58da4cb4ff0f95b796a35c40ea455e2ddd3e08bc494ffddc706aaf4d479f4f359e6a89a90df7c9b8f23cab355855a72b90795a0db83a96bce0dd4f77e3f58c0957b4ffe9663251565098e6c31fd4bbf3e1295faaff05e29912d9c37cb944da379a9b2193b466910d05a681e53a2dbe5aa18a2b4874153fe36d8a1aa4cc6e612bd6dbc9abb8e1e61b927fc5458d8e1be9536cd462e4c37672af7928c39e94bdc124a2da7b1bd3cad2cfe559adc33e62eb45bff89db8a47a72dda4f49f21c01a9432f4802a1
+** <tt>my_multisig_wallet_for_signer_2.dat</tt>: <pre>974ba77900c43c463dadaa6eaf24aaeb1b25b443cf155229b719bcbf8b34309286288c97a6341974a35015f97fbbc8db7655639c839fc438706f82fce36a82dd17e2d4d4a674516c4fc5c3a33d6097dd8fc5c6605018946741ed9f58d8fe530a808f16f0dd705cacfd273e34a158bd7566774dd31506b8280e448fabb72d0e7dfc05cee1142b61921dfaf0b0039d885cc0aa76c429025efc2ba49a8af15b58e75a5a83ba4838a9a4c9f13725f5aecefd8511513d93797f37b93150b9dca725685883188e39142dd8d3cf4b617c7936bdb3875415bbf6dfb2fe1a39ae2aed9fd2909aebd0355a5cc9a55bcb84048c851a1873948e495180f336edeb63f54bcf83feaa4d2453251260e24293e49815c2369c1c045083c412c973987fd7c9296a71cda424823ed32380ba442394500b7d2d2335818099090aaf08ca4e180869c546f58da4cb4ff0f95b796a35c40ea455e2ddd3e08bc494ffddc706aaf4d479f4f359e6a89a90df7c9b8f23cab355855a72b90795a0db83a96bce0dd4f77e3f58c0957b4ffe9663251565098e6c31fd4bbf3e1295faaff05e29912d9c37cb944da379a9b2193b466910d05a681e53a2dbe5aa18a2b4874153fe36d8a1aa4cc6e612bd6dbc9abb8e1e61b927fc5458d8e1be9536cd462e4c37672af7928c39e94bdc124a2da7b1bd3cad2cfe559adc33e62eb45bff89db8a47a72dda4f49f21c01a9432f4802a1</pre>
+
+* Send to Signer 3:
+** HMAC_KEY (hex): ab93ce7bf0f91c62a66d00ea9bf5e5c00b854ee2cfc2fb06f6eeff738abcdc26
+** MAC (hex): bb3c93b67d758f244de7ee73e5e61261cea6dff5b3852df8faf265cdf1c73dae
+** IV (hex) : bb3c93b67d758f244de7ee73e5e61261
+** CIPHERTEXT (hex): 7ac33bd9719a3cef6c68e09b3c9677565418933f188bbe50dc70f46329706732fe28ab230468e2a8798d3fbf641867d5b3322113204a372e7650ed06cf94d6df5cc7425b1b3a07690a32e12fd9cdad2c9f42d496c1b02215a7d8d63565aa4935bb2b087af39eebc02d4a2d30a4dbf1e72b9a0dab11473c7254ecf9065eb4f9d80a164c489d5fdae0d15d97b6100b79c3999b91341dfb4f599f738d4d631ae413c17b55daa09a67cb34b40d89c26f0e95ddfbf416033f869da32e502815d720bb342ec1c0e5c6910c598f32162016229cd37ea030b4d3b60f560105abb75531dc960ddf6830c26604c67c2da05b8adc45297dda58b2da4671104969b819cdf1c362bc20d7bdfe4a2fbdb79b4a69e285434d991c269e3d23ce3d95675a0acbec2cae04a310581148d3422c1c0a621fb6d79ecac1743b0e76837389b67cd4734ec5ab560c43a183de35fa98834e1f347a0c0c9b14273b76233f55f04553efcde873de92d766f3cdc5e56bc649bf0cc4951f051619ee9b931cd3872044b0e62ea2c2dacad978dbb8df3afa0b9386535278c295c6a30a56950e57f805770568e937ffafbadb226120991d5ec10effa9f4334800010d141a2ddddc00ac743efa821af37f69840487e4db48036c1e0730788cddbca2f68b3769ec6989d76161e6605af50651b6e86e
+** <tt>my_multisig_wallet_for_signer_3.dat</tt>: <pre>bb3c93b67d758f244de7ee73e5e61261cea6dff5b3852df8faf265cdf1c73dae7ac33bd9719a3cef6c68e09b3c9677565418933f188bbe50dc70f46329706732fe28ab230468e2a8798d3fbf641867d5b3322113204a372e7650ed06cf94d6df5cc7425b1b3a07690a32e12fd9cdad2c9f42d496c1b02215a7d8d63565aa4935bb2b087af39eebc02d4a2d30a4dbf1e72b9a0dab11473c7254ecf9065eb4f9d80a164c489d5fdae0d15d97b6100b79c3999b91341dfb4f599f738d4d631ae413c17b55daa09a67cb34b40d89c26f0e95ddfbf416033f869da32e502815d720bb342ec1c0e5c6910c598f32162016229cd37ea030b4d3b60f560105abb75531dc960ddf6830c26604c67c2da05b8adc45297dda58b2da4671104969b819cdf1c362bc20d7bdfe4a2fbdb79b4a69e285434d991c269e3d23ce3d95675a0acbec2cae04a310581148d3422c1c0a621fb6d79ecac1743b0e76837389b67cd4734ec5ab560c43a183de35fa98834e1f347a0c0c9b14273b76233f55f04553efcde873de92d766f3cdc5e56bc649bf0cc4951f051619ee9b931cd3872044b0e62ea2c2dacad978dbb8df3afa0b9386535278c295c6a30a56950e57f805770568e937ffafbadb226120991d5ec10effa9f4334800010d141a2ddddc00ac743efa821af37f69840487e4db48036c1e0730788cddbca2f68b3769ec6989d76161e6605af50651b6e86e</pre>
+
+==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-hugonguyen-bsms.mediawiki b/bip-hugonguyen-bsms.mediawiki
deleted file mode 100644
index d34a42f..0000000
--- a/bip-hugonguyen-bsms.mediawiki
+++ /dev/null
@@ -1,462 +0,0 @@
-<pre>
-  BIP: To be determined
-  Layer: Applications
-  Title: Bitcoin Secure Multisig Setup (BSMS)
-  Author: Hugo Nguyen <hugo at nunchuk.io>
-          Peter Gray <peter at coinkite.com>
-          Marko Bencun <marko at shiftcrypto.ch>
-          Aaron Chen <aarondongchen at gmail.com>
-          Rodolfo Novak <rodolfo at coinkite.com>
-  Comments-Summary: No comments yet.
-  Comments-URI:
-  Status: Proposed
-  Type: Standards Track
-  Created: 2020-11-10
-  License: BSD-2-Clause
-</pre>
-
-==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 <tt>.bsms</tt> file extension. Encrypted data should have a <tt>.dat</tt> 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 <tt>KEY</tt> 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 (<tt>M</tt> and <tt>N</tt>).
-* 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 <tt>TOKEN</tt> to each Signer over a secure channel. The Signer can use the <tt>TOKEN</tt> to derive an <tt>ENCRYPTION_KEY</tt>. Refer to the [[#Encryption]] section below for details on the <tt>TOKEN</tt>, the key derivation function and the encryption scheme. Depending on the use case, the Coordinator can decide whether to share one common <tt>TOKEN</tt> for all Signers, or to have one per Signer.
-* If encryption is disabled, the <tt>TOKEN</tt> is set to <tt>0x00</tt>, and all the encryption/decryption steps below can be skipped.
-
-=====Signer=====
-
-* The Signer initiates the multisig wallet creation session by setting the <tt>TOKEN</tt>. The Signer derives an <tt>ENCRYPTION_KEY</tt> from the <tt>TOKEN</tt>. The Signer can keep the session open until a different value for the <tt>TOKEN</tt> is set.
-* The Signer generates a key record by prompting the user for a multisig derivation path and retrieves the <tt>KEY</tt> 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 <tt>KEY</tt>s for different wallets.
-* The first line in the record must be the specification version (<tt>BSMS 1.0</tt> as of this writing). The second line must be the hex-encoded <tt>TOKEN</tt>. The third line must be the <tt>KEY</tt>. The <tt>KEY</tt> is a public key or an XPUB plus the key origin information, written in the descriptor-defined format, i.e.: <tt>[{master key fingerprint}/{derivation path}]{KEY}</tt>. The fourth line is a text description of the key, 80 characters maximum. The fifth line must be a <tt>SIG</tt>, whereas <tt>SIG</tt> 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 (<tt>MAC</tt>) for the record. The first 16 bytes of the <tt>MAC</tt> serves as the Initialization Vector (<tt>IV</tt>) for the encryption.
-* The Signer encrypts the key record with the <tt>ENCRYPTION_KEY</tt> and <tt>IV</tt>.
-* The Signer encodes the <tt>MAC</tt> and the ciphertext into hexadecimal format, then concatenates the results: <tt>(MAC || ciphertext)</tt>.
-
-====Round 2====
-
-=====Coordinator=====
-
-* The Coordinator gathers key records from all participating Signers. The Coordinator verifies that there are exactly <tt>N</tt> unique key records before the wallet setup session expires.
-* For each key record, the Coordinator extracts the <tt>MAC</tt> from the data, sets <tt>IV</tt> to the first 16 bytes of the <tt>MAC</tt>, then decrypts the ciphertext using the <tt>ENCRYPTION_KEY</tt> and <tt>IV</tt>.
-* The Coordinator verifies that the included <tt>MAC</tt> is valid given the plaintext.
-* The Coordinator verifies that the key records have compatible specification versions.
-* The Coordinator verifies that the included <tt>SIG</tt> is valid given the <tt>KEY</tt>.
-* 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 (<tt>BSMS 1.0</tt> 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 <tt>/</tt> and use non-hardened derivation. If there are no template or restrictions, it must say <tt>No path restrictions</tt>. 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 <tt>MAC</tt> for the record. The first 16 bytes of the <tt>MAC</tt> serves as the <tt>IV</tt> for the encryption.. 
-* The Coordinator encrypts the descriptor record with the <tt>ENCRYPTION_KEY</tt> and <tt>IV</tt>.
-* The Coordinator encodes the <tt>MAC</tt> and the ciphertext into hexadecimal format, then concatenates the results: <tt>(MAC || ciphertext)</tt>.
-* The Coordinator sends the encrypted descriptor record to all participating Signers.
-
-=====Signer=====
-
-* The Signer imports the descriptor record.
-* The Signer extracts the <tt>MAC</tt> from the data, sets <tt>IV</tt> to the first 16 bytes of the <tt>MAC</tt>, then decrypts the ciphertext using the <tt>ENCRYPTION_KEY</tt> (derived from the open session) and <tt>IV</tt>.
-* The Signer verifies that the included <tt>MAC</tt> 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 <tt>KEY</tt> is included in the descriptor or descriptor template, using path and fingerprint information provided. The check must perform an exact match on the <tt>KEY</tt>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, <tt>M</tt>, <tt>N</tt>, and the position(s) of the Signer's own <tt>KEY</tt> in the policy script. The total number of Signers, <tt>N</tt>, is important to prevent a <tt>KEY</tt> insertion attack. The position is important for scripts where <tt>KEY</tt> order matters. When applicable, all positions of the <tt>KEY</tt> 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 <tt>KEY</tt> 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.
-
-# <tt>NO_ENCRYPTION</tt> : the <tt>TOKEN</tt> is set to <tt>0x00</tt>. Encryption is disabled.
-# <tt>STANDARD</tt> : the <tt>TOKEN</tt> is a 64-bit nonce.
-# <tt>EXTENDED</tt> : the <tt>TOKEN</tt> is a 128-bit nonce.
-
-The <tt>TOKEN</tt> 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 <tt>STANDARD</tt> mode. This encoding is not recommended in <tt>EXTENDED</tt> mode as it can result in potential confusion between seed mnemonics and <tt>TOKEN</tt> 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:
-
-<tt>DKey = PBKDF2(PRF, Password, Salt, c, dkLen)</tt>
-
-Whereas:
-
-* PRF = SHA512
-* Password = "No SPOF"
-* Salt = <tt>TOKEN</tt>
-* c = 2048
-* dkLen = 256
-* DKey = Derived <tt>ENCRYPTION_KEY</tt>
-
-====Encryption Scheme====
-The encryption scheme is [https://tools.ietf.org/html/rfc3686 AES-256-CTR].
-
-<tt>MAC = HMAC-SHA256(HMAC_Key, hex-encoded TOKEN || Data)</tt>
-
-<tt>IV = First 16 bytes of MAC</tt>
-
-<tt>Ciphertext = AES-256-CTR-Encrypt(Plaintext, DKey, IV)</tt>
-
-<tt>Plaintext = AES-256-CTR-Decrypt(Ciphertext, DKey, IV)</tt>
-
-Whereas:
-* DKey = <tt>ENCRYPTION_KEY</tt>
-* HMAC_Key = SHA256(<tt>ENCRYPTION_KEY</tt>)
-* Data = the plaintext, e.g. the entire key record in round 1 and the entire descriptor record in round 2
-
-The <tt>MAC</tt> is to be sent along with the key and descriptor record, as specified above. Because it is a <tt>MAC</tt> 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:
-
-<tt>XPUB/**</tt>
-
-Whereas <tt>/**</tt> 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 <tt>/**</tt> with the restrictions.
-
-For example, the following template and derivation path restrictions:
-* <tt>wsh(sortedmulti(2,XPUB1/**,XPUB2/**))</tt>
-* <tt>/0/*,/1/*</tt>
-
-Should translate to two concrete descriptors:
-* <tt>wsh(sortedmulti(2,XPUB1/0/*,XPUB2/0/*))</tt>
-* <tt>wsh(sortedmulti(2,XPUB1/1/*,XPUB2/1/*))</tt>
-
-==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 <tt>TOKEN</tt>. The second one is the confirmation of the wallet's first address.
-
-The <tt>TOKEN</tt> is used to encrypt the two rounds of communication between the Signer and the Coordinator. A <tt>MAC</tt> is also generated from the <tt>TOKEN</tt> and plaintext to authenticate the data being exchanged. The <tt>TOKEN</tt> is only needed during the setup phase, and can be safely discarded afterwards. It is not recommended to use the same <tt>TOKEN</tt> 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 <tt>TOKEN</tt>, and to completely erase knowledge of the <tt>TOKEN</tt> after the multisig wallet has been set up.
-
-==Test Vectors==
-
-===Mode: <tt>NO_ENCRYPTION</tt> 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
-** <tt>signer_1_key.bsms</tt>:
-<pre>BSMS 1.0
-00
-[59865f44/48'/0'/0'/2']026d15412460ba0d881c21837bb999233896085a9ed4e5445bd637c10e579768ba
-Signer 1 key
-H6DXgqkCb353BDPkzppMFpOcdJZlpur0WRetQhIBqSn6DFzoQWBtm+ibP5wERDRNi0bxxev9B+FIvyQWq0s6im4=</pre>
-
-* Signer 2
-** MASTER_KEY_FINGERPRINT: b7044ca6
-** PRIVATE_KEY (m/48'/0'/0'/2'): KwT7BZDWjos4JAdfKi8NqF46Kj3rppTwN8KGhPbzmmugiZioFW3r
-** Public Key (m/48'/0'/0'/2'): 030baf0497ab406ff50cb48b4013abac8a0338758d2fd54cd934927afa57cc2062
-** Legacy signature
-** <tt>signer_2_key.bsms</tt>:
-<pre>BSMS 1.0
-00
-[b7044ca6/48'/0'/0'/2']030baf0497ab406ff50cb48b4013abac8a0338758d2fd54cd934927afa57cc2062
-Signer 2 key
-H08mGNGN+NxX/snt+6eX2Q1HjjfDkOtotglshHi7xdsBdIrTVMCQbgQ5SdACNZ0B2AJcifK11nJj43SvaitSemI=</pre>
-
-====ROUND 2====
-* Coordinator
-** <tt>my_multisig_wallet.bsms</tt>:
-<pre>BSMS 1.0
-wsh(sortedmulti(1,[59865f44/48'/0'/0'/2']026d15412460ba0d881c21837bb999233896085a9ed4e5445bd637c10e579768ba,[b7044ca6/48'/0'/0'/2']030baf0497ab406ff50cb48b4013abac8a0338758d2fd54cd934927afa57cc2062))#rzx9dffd
-No path restrictions
-bc1quqy523xu3l8che3s8vja8n33qtg0uyugr9l5z092s3wa50p8t7rqy6zumf</pre>
-
-===Mode: <tt>NO_ENCRYPTION</tt>===
-====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
-** <tt>signer_1_key.bsms</tt>:
-<pre>BSMS 1.0
-00
-[1cf0bf7e/48'/0'/0'/2']xpub6FL8FhxNNUVnG64YurPd16AfGyvFLhh7S2uSsDqR3Qfcm6o9jtcMYwh6DvmcBF9qozxNQmTCVvWtxLpKTnhVLN3Pgnu2D3pAoXYFgVyd8Yz
-Signer 1 key
-IB7v+qi1b+Xrwm/3bF+Rjl8QbIJ/FMQ40kUsOOQo1SqUWn5QlFWbBD8BKPRetfo1L1N7DmYjVscZNsmMrqRJGWw=</pre>
-
-* Signer 2
-** MASTER_KEY_FINGERPRINT: 4fc1dd4a
-** PRIVATE_KEY (m/48'/0'/0'/2'): L4JNkJfLBDyWfTLbKJ1H3w56GUMsvdfjCkzRo5RHXfJ6bdHqm6cN
-** XPUB (m/48'/0'/0'/2'): xpub6EebMbEps7ZcV3FYEnddRsvrFWDrt2tiPmCeM7pPXQEmphvq9ZfJ1LWFUDjf3vxCeBuPrfyGrMazWUsYsetrnHatQZVLJH7LsgCjtMqdzgj
-** Legacy signature
-** <tt>signer_2_key.bsms</tt>:
-<pre>BSMS 1.0
-00
-[4fc1dd4a/48'/0'/0'/2']xpub6EebMbEps7ZcV3FYEnddRsvrFWDrt2tiPmCeM7pPXQEmphvq9ZfJ1LWFUDjf3vxCeBuPrfyGrMazWUsYsetrnHatQZVLJH7LsgCjtMqdzgj
-Signer 2 key
-HzUa4Z76PFHMl54flIIF3XKiHZ+KbWjjxCEG5G3ZqZSqTd6OgTiFFLqq9PXJXdfYm6/cnL8IVWQgjFF9DQhIqQs=</pre>
-
-====ROUND 2====
-* Coordinator
-** <tt>my_multisig_wallet.bsms</tt>:
-<pre>BSMS 1.0
-wsh(sortedmulti(2,[1cf0bf7e/48'/0'/0'/2']xpub6FL8FhxNNUVnG64YurPd16AfGyvFLhh7S2uSsDqR3Qfcm6o9jtcMYwh6DvmcBF9qozxNQmTCVvWtxLpKTnhVLN3Pgnu2D3pAoXYFgVyd8Yz/**,[4fc1dd4a/48'/0'/0'/2']xpub6EebMbEps7ZcV3FYEnddRsvrFWDrt2tiPmCeM7pPXQEmphvq9ZfJ1LWFUDjf3vxCeBuPrfyGrMazWUsYsetrnHatQZVLJH7LsgCjtMqdzgj/**))
-/0/*,/1/*
-bc1qrgc6p3kylfztu06ysl752gwwuekhvtfh9vr7zg43jvu60mutamcsv948ej</pre>
-
-===Mode: <tt>STANDARD</tt> 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
-** <tt>signer_1_key.bsms</tt>:
-<pre>BSMS 1.0
-a54044308ceac9b7
-[b7868815/48'/0'/0'/2']xpub6FA5rfxJc94K1kNtxRby1hoHwi7YDyTWwx1KUR3FwskaF6HzCbZMz3zQwGnCqdiFeMTPV3YneTGS2YQPiuNYsSvtggWWMQpEJD4jXU7ZzEh
-Signer 1 key
-H8DYht5P6ko0bQqDV6MtUxpzBSK+aVHxbvMavA5byvLrOlCEGmO1WFR7k2wu42J6dxXD8vrmDQSnGq5MTMMbZ98=</pre>
-
-* Signer 1 encryption
-** HMAC_KEY (hex): 3d4c422806ba8964c9ee45070cd675c024d96648a0ddb4001325818c84951de2
-** MAC (hex): fbdbdb64e6a8231c342131d9f13dcd5a954b4c5021658fa5afcb3fc74dc82706
-** IV (hex) : fbdbdb64e6a8231c342131d9f13dcd5a
-** CIPHERTEXT (hex): 53f491cfd1431c292d922ea5a5dec3eb8ddaa6ed38ae109e7b040f0f23013e89a89b4d27476761a01197a3277850b2bc1621ae626efe65f2081eec6eb571c4f787bf1c49d061b43f70fd73cb3f37fa591d2400973ac0644c8941a83f1d4155e98f01fa2fdeb9f86c2e2413154fd18566a28fb0d9d8bd6172efabcfa6dab09ee7029bf3dd43376df52c118a6d291ec168f4ec7f7df951dfc6135fd8cb4b234da62eaea6017dfe5ca418f083e02e3aba2962ba313ba17b6468c7672fb218329a9f3fe4e4887fb87dac57c63ebff0e715a44498d18de8afc10e1cfeb46a1fc65ce871fef8a43b289305433a90c342d025aa4c19454fcfbcf911e9e2f928d5affd0536a6ddc2e816
-** <tt>signer_1_key.dat</tt>: <pre>fbdbdb64e6a8231c342131d9f13dcd5a954b4c5021658fa5afcb3fc74dc8270653f491cfd1431c292d922ea5a5dec3eb8ddaa6ed38ae109e7b040f0f23013e89a89b4d27476761a01197a3277850b2bc1621ae626efe65f2081eec6eb571c4f787bf1c49d061b43f70fd73cb3f37fa591d2400973ac0644c8941a83f1d4155e98f01fa2fdeb9f86c2e2413154fd18566a28fb0d9d8bd6172efabcfa6dab09ee7029bf3dd43376df52c118a6d291ec168f4ec7f7df951dfc6135fd8cb4b234da62eaea6017dfe5ca418f083e02e3aba2962ba313ba17b6468c7672fb218329a9f3fe4e4887fb87dac57c63ebff0e715a44498d18de8afc10e1cfeb46a1fc65ce871fef8a43b289305433a90c342d025aa4c19454fcfbcf911e9e2f928d5affd0536a6ddc2e816</pre>
-
-* Signer 2
-** MASTER_KEY_FINGERPRINT: eedff89a
-** PRIVATE_KEY (m/48'/0'/0'/2'): Kz1ijnkDXmc65NWTYdg47DDaQgSGJAPfhJG9Unm36oqZPpPXuNR6
-** XPUB (m/48'/0'/0'/2'): xpub6EhJvMneoLWAf8cuyLBLQiKiwh89RAmqXEqYeFuaCEHdHwxSRfzLrUxKXEBap7nZSHAYP7Jfq6gZmucotNzpMQ9Sb1nTqerqW8hrtmx6Y6o
-** Legacy signature
-** <tt>signer_2_key.bsms</tt>:
-<pre>BSMS 1.0
-a54044308ceac9b7
-[eedff89a/48'/0'/0'/2']xpub6EhJvMneoLWAf8cuyLBLQiKiwh89RAmqXEqYeFuaCEHdHwxSRfzLrUxKXEBap7nZSHAYP7Jfq6gZmucotNzpMQ9Sb1nTqerqW8hrtmx6Y6o
-Signer 2 key
-H/IHW5dMGYsrRdYEz3ux+kKnkWBtxHzfYkREpnYbco38VnMvIxCbDuf7iu6960qDhBLR/RLjlb9UPtLmCMbczDE=</pre>
-
-* Signer 2 encryption
-** HMAC_KEY (hex): 3d4c422806ba8964c9ee45070cd675c024d96648a0ddb4001325818c84951de2
-** MAC (hex): 383d05b7351a2cef7cca2850450f5efbbc4a3f8ea35707dda87a3692f0f2ebae
-** IV (hex) : 383d05b7351a2cef7cca2850450f5efb
-** CIPHERTEXT (hex): 71860b7c69f3a7665c3c3e85c45735bff78535a37ec6610b724627c73696820d519a9251703b17626b63898580233bebbb310aedbc370224b044ee19600bfe583445a6f26fb9bb5790bae516892655adb0e5dfc12be4609c2e0818d4f1f3bfccc4cd1a36f419d6cd842c913ae81eef4865ad473c32c3ee69cd98d6d0a088e2abdd01fe68b5c0503bb9183f9a912506204e5a9c6bd5a1626ff7eac30312a0b85004307c525e52fa3ad45a0b02eabc8cfaea0215bb6e60ee5f32d6673955290e008fbaef362977a21fd9830e3a604f9bb318cdcde456eae91dbedaa069bcd1efb0f981d5b0e502bd4dada903205458a00914887226a8dde317c02a8be4342acb97a8fee79fbe23
-** <tt>signer_2_key.dat</tt>: <pre>383d05b7351a2cef7cca2850450f5efbbc4a3f8ea35707dda87a3692f0f2ebae71860b7c69f3a7665c3c3e85c45735bff78535a37ec6610b724627c73696820d519a9251703b17626b63898580233bebbb310aedbc370224b044ee19600bfe583445a6f26fb9bb5790bae516892655adb0e5dfc12be4609c2e0818d4f1f3bfccc4cd1a36f419d6cd842c913ae81eef4865ad473c32c3ee69cd98d6d0a088e2abdd01fe68b5c0503bb9183f9a912506204e5a9c6bd5a1626ff7eac30312a0b85004307c525e52fa3ad45a0b02eabc8cfaea0215bb6e60ee5f32d6673955290e008fbaef362977a21fd9830e3a604f9bb318cdcde456eae91dbedaa069bcd1efb0f981d5b0e502bd4dada903205458a00914887226a8dde317c02a8be4342acb97a8fee79fbe23</pre>
-
-====ROUND 2====
-*Coordinator
-** <tt>my_multisig_wallet.bsms</tt>:
-<pre>BSMS 1.0
-wsh(sortedmulti(2,[b7868815/48'/0'/0'/2']xpub6FA5rfxJc94K1kNtxRby1hoHwi7YDyTWwx1KUR3FwskaF6HzCbZMz3zQwGnCqdiFeMTPV3YneTGS2YQPiuNYsSvtggWWMQpEJD4jXU7ZzEh/**,[eedff89a/48'/0'/0'/2']xpub6EhJvMneoLWAf8cuyLBLQiKiwh89RAmqXEqYeFuaCEHdHwxSRfzLrUxKXEBap7nZSHAYP7Jfq6gZmucotNzpMQ9Sb1nTqerqW8hrtmx6Y6o/**))
-/0/*,/1/*
-bc1qhs4u273g4azq7kqqpe6vh5wfhasfmrq7nheyzsnq77humd7rwtkqagvakf</pre>
-
-*Coordinator encryption
-** HMAC_KEY (hex): 3d4c422806ba8964c9ee45070cd675c024d96648a0ddb4001325818c84951de2
-** MAC (hex): 734ce791b466861945e1ef6f74c63faec590793de54831f0036b28d08714b71a
-** IV (hex) : 734ce791b466861945e1ef6f74c63fae
-** CIPHERTEXT (hex): 273cad18a5e1eff37dba6d850749594c9a3fd32b2069e8c69983ea269c5044b6bcaea26d9dbc8ad5d28bb8abfa02e3bfc7632fcc5c2b76e9abb1982ff11295858cfe44a8b97110ae970f58fff3fb6477f38ca9609eec78eedb1d640eaba489fd5e41e787b8d0bde48f1fa99cca641cabbee0f513fb1040cb73df10a57c9a34e4efcb069cd4c75467442c15d878ed9f40e3dffb98294931a6da4f444ae46f739b7fe002ce19fcfe71b05b9783d797ba45d568febbc8a2b0850da67f349d8567342352e1712c3d2a7ea1b2721df5efdb844431f0e5dcfa4acacb194c20785c9bb6dde90d64352fc913e9073b3b416be713bcc7632c821bbfddafa6199d471c54fb899f347f5fc706787ccaa82332dc8b93aeb3de3497d8e5c75f0f5d718c74bc6f8194fe999948e517f1c98398d9cb907d200f1d045394704b074dfb10e587f54fd78e95ef4bcbe77bf1376b390c3f47c91c12b2ed14073ea56bceab41f924302e62183c456b06d96b3da30439cb4320c764a0d6d1b3dabc06fc
-** <tt>my_multisig_wallet.dat</tt>: <pre>734ce791b466861945e1ef6f74c63faec590793de54831f0036b28d08714b71a273cad18a5e1eff37dba6d850749594c9a3fd32b2069e8c69983ea269c5044b6bcaea26d9dbc8ad5d28bb8abfa02e3bfc7632fcc5c2b76e9abb1982ff11295858cfe44a8b97110ae970f58fff3fb6477f38ca9609eec78eedb1d640eaba489fd5e41e787b8d0bde48f1fa99cca641cabbee0f513fb1040cb73df10a57c9a34e4efcb069cd4c75467442c15d878ed9f40e3dffb98294931a6da4f444ae46f739b7fe002ce19fcfe71b05b9783d797ba45d568febbc8a2b0850da67f349d8567342352e1712c3d2a7ea1b2721df5efdb844431f0e5dcfa4acacb194c20785c9bb6dde90d64352fc913e9073b3b416be713bcc7632c821bbfddafa6199d471c54fb899f347f5fc706787ccaa82332dc8b93aeb3de3497d8e5c75f0f5d718c74bc6f8194fe999948e517f1c98398d9cb907d200f1d045394704b074dfb10e587f54fd78e95ef4bcbe77bf1376b390c3f47c91c12b2ed14073ea56bceab41f924302e62183c456b06d96b3da30439cb4320c764a0d6d1b3dabc06fc</pre>
-
-===Mode: <tt>EXTENDED</tt> 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
-** <tt>signer_1_key.bsms</tt>:
-<pre>BSMS 1.0
-108a2360adb302774eb521daebbeda5e
-[793cc70b/48'/0'/0'/1']xpub6ErVmcYYHmavsMgxEcTZyzN5sqth1ZyRpFNJC26ij1wYGC2SBKYrgt9yariSbn7HLRoZUvhUhmPfsRTPrdhhGFscpPZzmch6UTdmRP1aZUj
-Signer 1 key
-ILG47LpCtjoD9UxL87jo5QFqA90t8g9fDQp/KBojdKgPPGB1pMx2bf9hPdORNZIOdCc/2+Gs6AOs3BEK9ubIuBw=</pre>
-
-* Signer 1 encryption
-** HMAC_KEY (hex): 1162cdace4ac9fcde1f96924b93714143d057a701de83ebaed248d1c9154f9fd
-** MAC (hex): ea12776c73de4bd5ea57c2d19eb8e0be856ac0d7f5651f7b74be4563d61ba5b1
-** IV (hex) : ea12776c73de4bd5ea57c2d19eb8e0be
-** CIPHERTEXT (hex): a36f34232bff47a853092654a718fea4f5f57d6a1f3d38fede04e2414da12c90cefc24ef662f736886d9a7fd6e7db636ca47217803c86b7fbcebe4ad6b71cffc261069c135bd2b2430fb2b446ff0203df34fbbc6801243e8a930b9d0cd3a9b160b8dcdc9131ce6e97641e6314b3285ff341013f302e308c1b2eba7ced0103a8999fe2bd86f844392938e7926cd26d023b764d0b8ff92b2fbdf995884c738414b83563ef2a0050279bf46d0e8271ea5d6af8154847c5736129a7a83a35a3cc747b2be4b389886cb57456678353b60473ebc4ab85d9c9131a17a1e288717343d9008825b16c48d7e93927f37b530033192c67b70dec0411a3e5952d2525c7eb80721676e1a6299248c17f8078202f3bb0932e9f263b0ab
-** <tt>signer_1_key.dat</tt>: <pre>ea12776c73de4bd5ea57c2d19eb8e0be856ac0d7f5651f7b74be4563d61ba5b1a36f34232bff47a853092654a718fea4f5f57d6a1f3d38fede04e2414da12c90cefc24ef662f736886d9a7fd6e7db636ca47217803c86b7fbcebe4ad6b71cffc261069c135bd2b2430fb2b446ff0203df34fbbc6801243e8a930b9d0cd3a9b160b8dcdc9131ce6e97641e6314b3285ff341013f302e308c1b2eba7ced0103a8999fe2bd86f844392938e7926cd26d023b764d0b8ff92b2fbdf995884c738414b83563ef2a0050279bf46d0e8271ea5d6af8154847c5736129a7a83a35a3cc747b2be4b389886cb57456678353b60473ebc4ab85d9c9131a17a1e288717343d9008825b16c48d7e93927f37b530033192c67b70dec0411a3e5952d2525c7eb80721676e1a6299248c17f8078202f3bb0932e9f263b0ab</pre>
-
-* Signer 2
-** MASTER_KEY_FINGERPRINT: b3118e52
-** PRIVATE_KEY (m/48'/0'/0'/1'): L4SnPjcHszMg3Wi2YYxEYnzM2zFeFkFr5NcLZ18YQeyJwaSFbTud
-** XPUB (m/48'/0'/0'/1'): xpub6Du5Jn6eYZE96ccmAc1ZTFPzdnzrvqfG4mpamDun2qZYKywoiQJMCbS3kWWMr6U3XW6s125RLsaPABWgv2yA749ieaMe67FxkTjMsbcxCch
-** Legacy signature
-** <tt>signer_2_key.bsms</tt>:
-<pre>BSMS 1.0
-d3fabc873b98165254fe18a71b5335b0
-[b3118e52/48'/0'/0'/1']xpub6Du5Jn6eYZE96ccmAc1ZTFPzdnzrvqfG4mpamDun2qZYKywoiQJMCbS3kWWMr6U3XW6s125RLsaPABWgv2yA749ieaMe67FxkTjMsbcxCch
-Signer 2 key
-IDK4d/oO0pgfrwRu4Zb8vqlPEmJb9aKT1K2CCnI3RKepVAKs3fZsBrypcCdQfUy1TG/3O5vAR3gjldxcCA1Wzg8=</pre>
-
-* Signer 2 encryption
-** HMAC_KEY (hex): 43a4e704bd1bade703023004b00290f1a7b005474a581d869a217068eedf3f57
-** MAC (hex): 4a3ff970d027010e83b4fbf2845a23907a301b3df692a9265e2ca679697ac718
-** IV (hex) : 4a3ff970d027010e83b4fbf2845a2390
-** CIPHERTEXT (hex): c8f4a6a6714eff90aa48cbefe6750c2ee3cc72182eb455e964f0ba59ada3ecd758c29f0fab7e33aaa82a340a18d9c793ddab09dc7e714864faac1ecea370d4f102533b739da38aa0491433f35eadec08f203685f04d1f6ec35d397d99e4f8096a5691075e3f54fd9ff58faf947f276bbe1031f827b274bd2f60fcb526add7058889104b189d7da22ac7be1f7ddd380bbebd5c6983a8a3c5fa86913e3d23c40935072ce03d9bdeb07791dc836d44b4d4c62f364d0e4f3580369ea8f6ebb774b7fda4a7ac6f5ae6b2f52b10cd71bdf3cdb5889e77d5eb1f2f647b798cdd6b3e5b964c9265daea3668d7e4cb53f724151923da1a87bbcd2abd8b164de474d865c51af69885431d26f88a5c8eea7d0dfdb52ca622017808a
-** <tt>signer_2_key.dat</tt>: <pre>4a3ff970d027010e83b4fbf2845a23907a301b3df692a9265e2ca679697ac718c8f4a6a6714eff90aa48cbefe6750c2ee3cc72182eb455e964f0ba59ada3ecd758c29f0fab7e33aaa82a340a18d9c793ddab09dc7e714864faac1ecea370d4f102533b739da38aa0491433f35eadec08f203685f04d1f6ec35d397d99e4f8096a5691075e3f54fd9ff58faf947f276bbe1031f827b274bd2f60fcb526add7058889104b189d7da22ac7be1f7ddd380bbebd5c6983a8a3c5fa86913e3d23c40935072ce03d9bdeb07791dc836d44b4d4c62f364d0e4f3580369ea8f6ebb774b7fda4a7ac6f5ae6b2f52b10cd71bdf3cdb5889e77d5eb1f2f647b798cdd6b3e5b964c9265daea3668d7e4cb53f724151923da1a87bbcd2abd8b164de474d865c51af69885431d26f88a5c8eea7d0dfdb52ca622017808a</pre>
-
-* Signer 3
-** MASTER_KEY_FINGERPRINT: 842bd2ed
-** PRIVATE_KEY (m/48'/0'/0'/1'): L1ehZHpo2UFHc1yaBWDU4bKVycUwcU2TESm92wbfq6xK6qpZZJP6
-** XPUB (m/48'/0'/0'/1'): xpub6Ex81KopPkEt9hJiWHabYy8LNsSR4A7sUQoFBk9dR8XxHrr4p9HrYWN3NCf5uwfopHnQkCG7FYnZMztKbtRtbh6tzZC4xtHPbmVVxRSN7ic
-** Legacy signature
-** <tt>signer_3_key.bsms</tt>:
-<pre>BSMS 1.0
-78a7d5e7549453d719150de5459c9ce5
-[842bd2ed/48'/0'/0'/1']xpub6Ex81KopPkEt9hJiWHabYy8LNsSR4A7sUQoFBk9dR8XxHrr4p9HrYWN3NCf5uwfopHnQkCG7FYnZMztKbtRtbh6tzZC4xtHPbmVVxRSN7ic
-Signer 3 key
-IL77mML0xo/O9dJn0T5EpQLuyRPPrdpgVJbtsdAugW5iX0MQ3Ci0f8jVnXu68Xm07CYjYGKX8af72jmkQKhNud0=</pre>
-
-* Signer 3 encryption
-** HMAC_KEY (hex): ab93ce7bf0f91c62a66d00ea9bf5e5c00b854ee2cfc2fb06f6eeff738abcdc26
-** MAC (hex): e82cfcccbd4bd4d3b76e28133eecd13f7362f4a8b4c4baa3e5f6ba2dfb4d69b8
-** IV (hex) : e82cfcccbd4bd4d3b76e28133eecd13f
-** CIPHERTEXT (hex): b44433f0b564ec35a1e71371f25844088084b47402c90d52fee7237167b58a60a28c234af9123e104773136e8446d799541c8566882787caee7cd1fa8628aba63aa9e9d7cca0ddee92f96dd881535b19a131a1f487a1909e42d62945fd0ba08dacd7dc09a22ffe47e0410b8b85df92e4a8bbf9b46f0062da02e3ae94144a00bae917acc1246d8d1a4dca105708f55379caefef9d4c152f56b65ab4bd7b48f60233f57ba6d705387c79aeaa2a279e3314004bf16fcd7e7d2adef34b0ab3c22bc5461f2c09dce69065605e4fb96958c55984391712b3547e3914ad4ecca2c088be280dfcfe374a112515674aeca57b885e81dbef6a353ca387f4514db3158eb69f0d2725d42ad8102c05c26ad501d48b889c624035ead4
-** <tt>signer_3_key.dat</tt>: <pre>e82cfcccbd4bd4d3b76e28133eecd13f7362f4a8b4c4baa3e5f6ba2dfb4d69b8b44433f0b564ec35a1e71371f25844088084b47402c90d52fee7237167b58a60a28c234af9123e104773136e8446d799541c8566882787caee7cd1fa8628aba63aa9e9d7cca0ddee92f96dd881535b19a131a1f487a1909e42d62945fd0ba08dacd7dc09a22ffe47e0410b8b85df92e4a8bbf9b46f0062da02e3ae94144a00bae917acc1246d8d1a4dca105708f55379caefef9d4c152f56b65ab4bd7b48f60233f57ba6d705387c79aeaa2a279e3314004bf16fcd7e7d2adef34b0ab3c22bc5461f2c09dce69065605e4fb96958c55984391712b3547e3914ad4ecca2c088be280dfcfe374a112515674aeca57b885e81dbef6a353ca387f4514db3158eb69f0d2725d42ad8102c05c26ad501d48b889c624035ead4</pre>
-
-====ROUND 2====
-* Coordinator
-** <tt>my_multisig_wallet.bsms</tt>:
-<pre>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</pre>
-
-* Send to Signer 1:
-** HMAC_KEY (hex): 1162cdace4ac9fcde1f96924b93714143d057a701de83ebaed248d1c9154f9fd
-** MAC (hex): 01bf557b6d44b3fbf07f8ec155cbdec42d85d856e174342563dd83b40ad7c025
-** IV (hex) : 01bf557b6d44b3fbf07f8ec155cbdec4
-** CIPHERTEXT (hex): 617ed25b4b8fd88b806cbebcc1731b071465514a805f7ba2de60e291bc9493f31aa0f9b0665ba822cf9a2e21c02649b5c3f7dbad317ae898292cb6fe992520f68c0ebe9d1434b348af10453f1be0a392a616d43ba21e5e7fa3c995dce54db947fe5dbad4a9a77f37b3aef58c54ee3e496c8312d3033359aed0de8cf28b82035ee7a38c9b23c9d95682fb15936bf2247546d2ba9b3ada605f5c89f0a3bbaa86cb4b5dded9a65004912c0afbbfd01f0115447f5625e8523f9de16165d32c4b21103d8ac965e2f7e17641ee1a8c5902e8dbb461c6c7d05141f7bba66b8b3608037fb251b55fa461c9441c6427921545a34a1798127d5bf9cc92423f7e62c769e232c65db8cc5124577012d49941143c3b4758212a8afa0475c9b3597da2e99d585039339b7d73611aa277878d212875051683053db9c630391e0b32356523e9fa8a58a334e16fe6650472f336ddaa8c587992b6c0c0e480b680261579a11cf9d036614abc113dde53653273f5ce82ea0bc10e38ca52ac66838aa49ff46c3a7d5096db439c15d3c2e8de55e4ac7315a57eb9997f219c378af86c858867ce583ed84e4d9c68aecfbca9ebff16b0ac91531125e273b215db688ffe52c8033eb78914b87c0fa2001c52e90c92765712e50384ddcf4d0953ac3cc8137abcb2a85d603a6cc207472677
-** <tt>my_multisig_wallet_for_signer_1.dat</tt>: <pre>01bf557b6d44b3fbf07f8ec155cbdec42d85d856e174342563dd83b40ad7c025617ed25b4b8fd88b806cbebcc1731b071465514a805f7ba2de60e291bc9493f31aa0f9b0665ba822cf9a2e21c02649b5c3f7dbad317ae898292cb6fe992520f68c0ebe9d1434b348af10453f1be0a392a616d43ba21e5e7fa3c995dce54db947fe5dbad4a9a77f37b3aef58c54ee3e496c8312d3033359aed0de8cf28b82035ee7a38c9b23c9d95682fb15936bf2247546d2ba9b3ada605f5c89f0a3bbaa86cb4b5dded9a65004912c0afbbfd01f0115447f5625e8523f9de16165d32c4b21103d8ac965e2f7e17641ee1a8c5902e8dbb461c6c7d05141f7bba66b8b3608037fb251b55fa461c9441c6427921545a34a1798127d5bf9cc92423f7e62c769e232c65db8cc5124577012d49941143c3b4758212a8afa0475c9b3597da2e99d585039339b7d73611aa277878d212875051683053db9c630391e0b32356523e9fa8a58a334e16fe6650472f336ddaa8c587992b6c0c0e480b680261579a11cf9d036614abc113dde53653273f5ce82ea0bc10e38ca52ac66838aa49ff46c3a7d5096db439c15d3c2e8de55e4ac7315a57eb9997f219c378af86c858867ce583ed84e4d9c68aecfbca9ebff16b0ac91531125e273b215db688ffe52c8033eb78914b87c0fa2001c52e90c92765712e50384ddcf4d0953ac3cc8137abcb2a85d603a6cc207472677</pre>
-
-* Send to Signer 2:
-** HMAC_KEY (hex): 43a4e704bd1bade703023004b00290f1a7b005474a581d869a217068eedf3f57
-** MAC (hex): 974ba77900c43c463dadaa6eaf24aaeb1b25b443cf155229b719bcbf8b343092
-** IV (hex) : 974ba77900c43c463dadaa6eaf24aaeb
-** CIPHERTEXT (hex): 86288c97a6341974a35015f97fbbc8db7655639c839fc438706f82fce36a82dd17e2d4d4a674516c4fc5c3a33d6097dd8fc5c6605018946741ed9f58d8fe530a808f16f0dd705cacfd273e34a158bd7566774dd31506b8280e448fabb72d0e7dfc05cee1142b61921dfaf0b0039d885cc0aa76c429025efc2ba49a8af15b58e75a5a83ba4838a9a4c9f13725f5aecefd8511513d93797f37b93150b9dca725685883188e39142dd8d3cf4b617c7936bdb3875415bbf6dfb2fe1a39ae2aed9fd2909aebd0355a5cc9a55bcb84048c851a1873948e495180f336edeb63f54bcf83feaa4d2453251260e24293e49815c2369c1c045083c412c973987fd7c9296a71cda424823ed32380ba442394500b7d2d2335818099090aaf08ca4e180869c546f58da4cb4ff0f95b796a35c40ea455e2ddd3e08bc494ffddc706aaf4d479f4f359e6a89a90df7c9b8f23cab355855a72b90795a0db83a96bce0dd4f77e3f58c0957b4ffe9663251565098e6c31fd4bbf3e1295faaff05e29912d9c37cb944da379a9b2193b466910d05a681e53a2dbe5aa18a2b4874153fe36d8a1aa4cc6e612bd6dbc9abb8e1e61b927fc5458d8e1be9536cd462e4c37672af7928c39e94bdc124a2da7b1bd3cad2cfe559adc33e62eb45bff89db8a47a72dda4f49f21c01a9432f4802a1
-** <tt>my_multisig_wallet_for_signer_2.dat</tt>: <pre>974ba77900c43c463dadaa6eaf24aaeb1b25b443cf155229b719bcbf8b34309286288c97a6341974a35015f97fbbc8db7655639c839fc438706f82fce36a82dd17e2d4d4a674516c4fc5c3a33d6097dd8fc5c6605018946741ed9f58d8fe530a808f16f0dd705cacfd273e34a158bd7566774dd31506b8280e448fabb72d0e7dfc05cee1142b61921dfaf0b0039d885cc0aa76c429025efc2ba49a8af15b58e75a5a83ba4838a9a4c9f13725f5aecefd8511513d93797f37b93150b9dca725685883188e39142dd8d3cf4b617c7936bdb3875415bbf6dfb2fe1a39ae2aed9fd2909aebd0355a5cc9a55bcb84048c851a1873948e495180f336edeb63f54bcf83feaa4d2453251260e24293e49815c2369c1c045083c412c973987fd7c9296a71cda424823ed32380ba442394500b7d2d2335818099090aaf08ca4e180869c546f58da4cb4ff0f95b796a35c40ea455e2ddd3e08bc494ffddc706aaf4d479f4f359e6a89a90df7c9b8f23cab355855a72b90795a0db83a96bce0dd4f77e3f58c0957b4ffe9663251565098e6c31fd4bbf3e1295faaff05e29912d9c37cb944da379a9b2193b466910d05a681e53a2dbe5aa18a2b4874153fe36d8a1aa4cc6e612bd6dbc9abb8e1e61b927fc5458d8e1be9536cd462e4c37672af7928c39e94bdc124a2da7b1bd3cad2cfe559adc33e62eb45bff89db8a47a72dda4f49f21c01a9432f4802a1</pre>
-
-* Send to Signer 3:
-** HMAC_KEY (hex): ab93ce7bf0f91c62a66d00ea9bf5e5c00b854ee2cfc2fb06f6eeff738abcdc26
-** MAC (hex): bb3c93b67d758f244de7ee73e5e61261cea6dff5b3852df8faf265cdf1c73dae
-** IV (hex) : bb3c93b67d758f244de7ee73e5e61261
-** CIPHERTEXT (hex): 7ac33bd9719a3cef6c68e09b3c9677565418933f188bbe50dc70f46329706732fe28ab230468e2a8798d3fbf641867d5b3322113204a372e7650ed06cf94d6df5cc7425b1b3a07690a32e12fd9cdad2c9f42d496c1b02215a7d8d63565aa4935bb2b087af39eebc02d4a2d30a4dbf1e72b9a0dab11473c7254ecf9065eb4f9d80a164c489d5fdae0d15d97b6100b79c3999b91341dfb4f599f738d4d631ae413c17b55daa09a67cb34b40d89c26f0e95ddfbf416033f869da32e502815d720bb342ec1c0e5c6910c598f32162016229cd37ea030b4d3b60f560105abb75531dc960ddf6830c26604c67c2da05b8adc45297dda58b2da4671104969b819cdf1c362bc20d7bdfe4a2fbdb79b4a69e285434d991c269e3d23ce3d95675a0acbec2cae04a310581148d3422c1c0a621fb6d79ecac1743b0e76837389b67cd4734ec5ab560c43a183de35fa98834e1f347a0c0c9b14273b76233f55f04553efcde873de92d766f3cdc5e56bc649bf0cc4951f051619ee9b931cd3872044b0e62ea2c2dacad978dbb8df3afa0b9386535278c295c6a30a56950e57f805770568e937ffafbadb226120991d5ec10effa9f4334800010d141a2ddddc00ac743efa821af37f69840487e4db48036c1e0730788cddbca2f68b3769ec6989d76161e6605af50651b6e86e
-** <tt>my_multisig_wallet_for_signer_3.dat</tt>: <pre>bb3c93b67d758f244de7ee73e5e61261cea6dff5b3852df8faf265cdf1c73dae7ac33bd9719a3cef6c68e09b3c9677565418933f188bbe50dc70f46329706732fe28ab230468e2a8798d3fbf641867d5b3322113204a372e7650ed06cf94d6df5cc7425b1b3a07690a32e12fd9cdad2c9f42d496c1b02215a7d8d63565aa4935bb2b087af39eebc02d4a2d30a4dbf1e72b9a0dab11473c7254ecf9065eb4f9d80a164c489d5fdae0d15d97b6100b79c3999b91341dfb4f599f738d4d631ae413c17b55daa09a67cb34b40d89c26f0e95ddfbf416033f869da32e502815d720bb342ec1c0e5c6910c598f32162016229cd37ea030b4d3b60f560105abb75531dc960ddf6830c26604c67c2da05b8adc45297dda58b2da4671104969b819cdf1c362bc20d7bdfe4a2fbdb79b4a69e285434d991c269e3d23ce3d95675a0acbec2cae04a310581148d3422c1c0a621fb6d79ecac1743b0e76837389b67cd4734ec5ab560c43a183de35fa98834e1f347a0c0c9b14273b76233f55f04553efcde873de92d766f3cdc5e56bc649bf0cc4951f051619ee9b931cd3872044b0e62ea2c2dacad978dbb8df3afa0b9386535278c295c6a30a56950e57f805770568e937ffafbadb226120991d5ec10effa9f4334800010d141a2ddddc00ac743efa821af37f69840487e4db48036c1e0730788cddbca2f68b3769ec6989d76161e6605af50651b6e86e</pre>
-
-==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
-
-- 
cgit v1.2.3


From 73e581ca06b28afb4419a4dc3e52dbf384090759 Mon Sep 17 00:00:00 2001
From: Hugo Nguyen <hugh.hn@gmail.com>
Date: Fri, 14 May 2021 18:29:58 -0700
Subject: BIP 129: Bitcoin Secure Multisig Setup (BSMS)

---
 README.mediawiki | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/README.mediawiki b/README.mediawiki
index 83120ab..1350639 100644
--- a/README.mediawiki
+++ b/README.mediawiki
@@ -645,6 +645,13 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Standard
 | Draft
 |- style="background-color: #ffffcf"
+| [[bip-0129.mediawiki|129]]
+| Applications
+| Bitcoin Secure Multisig Setup (BSMS)
+| Hugo Nguyen, Peter Gray, Marko Bencun, Aaron Chen, Rodolfo Novak
+| Standard
+| Proposed
+|- style="background-color: #ffffcf"
 | [[bip-0130.mediawiki|130]]
 | Peer Services
 | sendheaders message
-- 
cgit v1.2.3


From 0e9aef5d9ed64db29f4fa74ef22e1974e1987496 Mon Sep 17 00:00:00 2001
From: Hugo Nguyen <hugh.hn@gmail.com>
Date: Fri, 14 May 2021 18:37:07 -0700
Subject: Correct BIP number

---
 bip-0129.mediawiki | 462 +++++++++++++++++++++++++++++++++++++++++++++++++++++
 bip-0139.mediawiki | 462 -----------------------------------------------------
 2 files changed, 462 insertions(+), 462 deletions(-)
 create mode 100644 bip-0129.mediawiki
 delete mode 100644 bip-0139.mediawiki

diff --git a/bip-0129.mediawiki b/bip-0129.mediawiki
new file mode 100644
index 0000000..a5cf62a
--- /dev/null
+++ b/bip-0129.mediawiki
@@ -0,0 +1,462 @@
+<pre>
+  BIP: 129
+  Layer: Applications
+  Title: Bitcoin Secure Multisig Setup (BSMS)
+  Author: Hugo Nguyen <hugo at nunchuk.io>
+          Peter Gray <peter at coinkite.com>
+          Marko Bencun <marko at shiftcrypto.ch>
+          Aaron Chen <aarondongchen at gmail.com>
+          Rodolfo Novak <rodolfo at coinkite.com>
+  Comments-Summary: No comments yet.
+  Comments-URI:
+  Status: Proposed
+  Type: Standards Track
+  Created: 2020-11-10
+  License: BSD-2-Clause
+</pre>
+
+==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 <tt>.bsms</tt> file extension. Encrypted data should have a <tt>.dat</tt> 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 <tt>KEY</tt> 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 (<tt>M</tt> and <tt>N</tt>).
+* 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 <tt>TOKEN</tt> to each Signer over a secure channel. The Signer can use the <tt>TOKEN</tt> to derive an <tt>ENCRYPTION_KEY</tt>. Refer to the [[#Encryption]] section below for details on the <tt>TOKEN</tt>, the key derivation function and the encryption scheme. Depending on the use case, the Coordinator can decide whether to share one common <tt>TOKEN</tt> for all Signers, or to have one per Signer.
+* If encryption is disabled, the <tt>TOKEN</tt> is set to <tt>0x00</tt>, and all the encryption/decryption steps below can be skipped.
+
+=====Signer=====
+
+* The Signer initiates the multisig wallet creation session by setting the <tt>TOKEN</tt>. The Signer derives an <tt>ENCRYPTION_KEY</tt> from the <tt>TOKEN</tt>. The Signer can keep the session open until a different value for the <tt>TOKEN</tt> is set.
+* The Signer generates a key record by prompting the user for a multisig derivation path and retrieves the <tt>KEY</tt> 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 <tt>KEY</tt>s for different wallets.
+* The first line in the record must be the specification version (<tt>BSMS 1.0</tt> as of this writing). The second line must be the hex-encoded <tt>TOKEN</tt>. The third line must be the <tt>KEY</tt>. The <tt>KEY</tt> is a public key or an XPUB plus the key origin information, written in the descriptor-defined format, i.e.: <tt>[{master key fingerprint}/{derivation path}]{KEY}</tt>. The fourth line is a text description of the key, 80 characters maximum. The fifth line must be a <tt>SIG</tt>, whereas <tt>SIG</tt> 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 (<tt>MAC</tt>) for the record. The first 16 bytes of the <tt>MAC</tt> serves as the Initialization Vector (<tt>IV</tt>) for the encryption.
+* The Signer encrypts the key record with the <tt>ENCRYPTION_KEY</tt> and <tt>IV</tt>.
+* The Signer encodes the <tt>MAC</tt> and the ciphertext into hexadecimal format, then concatenates the results: <tt>(MAC || ciphertext)</tt>.
+
+====Round 2====
+
+=====Coordinator=====
+
+* The Coordinator gathers key records from all participating Signers. The Coordinator verifies that there are exactly <tt>N</tt> unique key records before the wallet setup session expires.
+* For each key record, the Coordinator extracts the <tt>MAC</tt> from the data, sets <tt>IV</tt> to the first 16 bytes of the <tt>MAC</tt>, then decrypts the ciphertext using the <tt>ENCRYPTION_KEY</tt> and <tt>IV</tt>.
+* The Coordinator verifies that the included <tt>MAC</tt> is valid given the plaintext.
+* The Coordinator verifies that the key records have compatible specification versions.
+* The Coordinator verifies that the included <tt>SIG</tt> is valid given the <tt>KEY</tt>.
+* 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 (<tt>BSMS 1.0</tt> 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 <tt>/</tt> and use non-hardened derivation. If there are no template or restrictions, it must say <tt>No path restrictions</tt>. 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 <tt>MAC</tt> for the record. The first 16 bytes of the <tt>MAC</tt> serves as the <tt>IV</tt> for the encryption.. 
+* The Coordinator encrypts the descriptor record with the <tt>ENCRYPTION_KEY</tt> and <tt>IV</tt>.
+* The Coordinator encodes the <tt>MAC</tt> and the ciphertext into hexadecimal format, then concatenates the results: <tt>(MAC || ciphertext)</tt>.
+* The Coordinator sends the encrypted descriptor record to all participating Signers.
+
+=====Signer=====
+
+* The Signer imports the descriptor record.
+* The Signer extracts the <tt>MAC</tt> from the data, sets <tt>IV</tt> to the first 16 bytes of the <tt>MAC</tt>, then decrypts the ciphertext using the <tt>ENCRYPTION_KEY</tt> (derived from the open session) and <tt>IV</tt>.
+* The Signer verifies that the included <tt>MAC</tt> 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 <tt>KEY</tt> is included in the descriptor or descriptor template, using path and fingerprint information provided. The check must perform an exact match on the <tt>KEY</tt>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, <tt>M</tt>, <tt>N</tt>, and the position(s) of the Signer's own <tt>KEY</tt> in the policy script. The total number of Signers, <tt>N</tt>, is important to prevent a <tt>KEY</tt> insertion attack. The position is important for scripts where <tt>KEY</tt> order matters. When applicable, all positions of the <tt>KEY</tt> 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 <tt>KEY</tt> 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.
+
+# <tt>NO_ENCRYPTION</tt> : the <tt>TOKEN</tt> is set to <tt>0x00</tt>. Encryption is disabled.
+# <tt>STANDARD</tt> : the <tt>TOKEN</tt> is a 64-bit nonce.
+# <tt>EXTENDED</tt> : the <tt>TOKEN</tt> is a 128-bit nonce.
+
+The <tt>TOKEN</tt> 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 <tt>STANDARD</tt> mode. This encoding is not recommended in <tt>EXTENDED</tt> mode as it can result in potential confusion between seed mnemonics and <tt>TOKEN</tt> 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:
+
+<tt>DKey = PBKDF2(PRF, Password, Salt, c, dkLen)</tt>
+
+Whereas:
+
+* PRF = SHA512
+* Password = "No SPOF"
+* Salt = <tt>TOKEN</tt>
+* c = 2048
+* dkLen = 256
+* DKey = Derived <tt>ENCRYPTION_KEY</tt>
+
+====Encryption Scheme====
+The encryption scheme is [https://tools.ietf.org/html/rfc3686 AES-256-CTR].
+
+<tt>MAC = HMAC-SHA256(HMAC_Key, hex-encoded TOKEN || Data)</tt>
+
+<tt>IV = First 16 bytes of MAC</tt>
+
+<tt>Ciphertext = AES-256-CTR-Encrypt(Plaintext, DKey, IV)</tt>
+
+<tt>Plaintext = AES-256-CTR-Decrypt(Ciphertext, DKey, IV)</tt>
+
+Whereas:
+* DKey = <tt>ENCRYPTION_KEY</tt>
+* HMAC_Key = SHA256(<tt>ENCRYPTION_KEY</tt>)
+* Data = the plaintext, e.g. the entire key record in round 1 and the entire descriptor record in round 2
+
+The <tt>MAC</tt> is to be sent along with the key and descriptor record, as specified above. Because it is a <tt>MAC</tt> 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:
+
+<tt>XPUB/**</tt>
+
+Whereas <tt>/**</tt> 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 <tt>/**</tt> with the restrictions.
+
+For example, the following template and derivation path restrictions:
+* <tt>wsh(sortedmulti(2,XPUB1/**,XPUB2/**))</tt>
+* <tt>/0/*,/1/*</tt>
+
+Should translate to two concrete descriptors:
+* <tt>wsh(sortedmulti(2,XPUB1/0/*,XPUB2/0/*))</tt>
+* <tt>wsh(sortedmulti(2,XPUB1/1/*,XPUB2/1/*))</tt>
+
+==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 <tt>TOKEN</tt>. The second one is the confirmation of the wallet's first address.
+
+The <tt>TOKEN</tt> is used to encrypt the two rounds of communication between the Signer and the Coordinator. A <tt>MAC</tt> is also generated from the <tt>TOKEN</tt> and plaintext to authenticate the data being exchanged. The <tt>TOKEN</tt> is only needed during the setup phase, and can be safely discarded afterwards. It is not recommended to use the same <tt>TOKEN</tt> 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 <tt>TOKEN</tt>, and to completely erase knowledge of the <tt>TOKEN</tt> after the multisig wallet has been set up.
+
+==Test Vectors==
+
+===Mode: <tt>NO_ENCRYPTION</tt> 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
+** <tt>signer_1_key.bsms</tt>:
+<pre>BSMS 1.0
+00
+[59865f44/48'/0'/0'/2']026d15412460ba0d881c21837bb999233896085a9ed4e5445bd637c10e579768ba
+Signer 1 key
+H6DXgqkCb353BDPkzppMFpOcdJZlpur0WRetQhIBqSn6DFzoQWBtm+ibP5wERDRNi0bxxev9B+FIvyQWq0s6im4=</pre>
+
+* Signer 2
+** MASTER_KEY_FINGERPRINT: b7044ca6
+** PRIVATE_KEY (m/48'/0'/0'/2'): KwT7BZDWjos4JAdfKi8NqF46Kj3rppTwN8KGhPbzmmugiZioFW3r
+** Public Key (m/48'/0'/0'/2'): 030baf0497ab406ff50cb48b4013abac8a0338758d2fd54cd934927afa57cc2062
+** Legacy signature
+** <tt>signer_2_key.bsms</tt>:
+<pre>BSMS 1.0
+00
+[b7044ca6/48'/0'/0'/2']030baf0497ab406ff50cb48b4013abac8a0338758d2fd54cd934927afa57cc2062
+Signer 2 key
+H08mGNGN+NxX/snt+6eX2Q1HjjfDkOtotglshHi7xdsBdIrTVMCQbgQ5SdACNZ0B2AJcifK11nJj43SvaitSemI=</pre>
+
+====ROUND 2====
+* Coordinator
+** <tt>my_multisig_wallet.bsms</tt>:
+<pre>BSMS 1.0
+wsh(sortedmulti(1,[59865f44/48'/0'/0'/2']026d15412460ba0d881c21837bb999233896085a9ed4e5445bd637c10e579768ba,[b7044ca6/48'/0'/0'/2']030baf0497ab406ff50cb48b4013abac8a0338758d2fd54cd934927afa57cc2062))#rzx9dffd
+No path restrictions
+bc1quqy523xu3l8che3s8vja8n33qtg0uyugr9l5z092s3wa50p8t7rqy6zumf</pre>
+
+===Mode: <tt>NO_ENCRYPTION</tt>===
+====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
+** <tt>signer_1_key.bsms</tt>:
+<pre>BSMS 1.0
+00
+[1cf0bf7e/48'/0'/0'/2']xpub6FL8FhxNNUVnG64YurPd16AfGyvFLhh7S2uSsDqR3Qfcm6o9jtcMYwh6DvmcBF9qozxNQmTCVvWtxLpKTnhVLN3Pgnu2D3pAoXYFgVyd8Yz
+Signer 1 key
+IB7v+qi1b+Xrwm/3bF+Rjl8QbIJ/FMQ40kUsOOQo1SqUWn5QlFWbBD8BKPRetfo1L1N7DmYjVscZNsmMrqRJGWw=</pre>
+
+* Signer 2
+** MASTER_KEY_FINGERPRINT: 4fc1dd4a
+** PRIVATE_KEY (m/48'/0'/0'/2'): L4JNkJfLBDyWfTLbKJ1H3w56GUMsvdfjCkzRo5RHXfJ6bdHqm6cN
+** XPUB (m/48'/0'/0'/2'): xpub6EebMbEps7ZcV3FYEnddRsvrFWDrt2tiPmCeM7pPXQEmphvq9ZfJ1LWFUDjf3vxCeBuPrfyGrMazWUsYsetrnHatQZVLJH7LsgCjtMqdzgj
+** Legacy signature
+** <tt>signer_2_key.bsms</tt>:
+<pre>BSMS 1.0
+00
+[4fc1dd4a/48'/0'/0'/2']xpub6EebMbEps7ZcV3FYEnddRsvrFWDrt2tiPmCeM7pPXQEmphvq9ZfJ1LWFUDjf3vxCeBuPrfyGrMazWUsYsetrnHatQZVLJH7LsgCjtMqdzgj
+Signer 2 key
+HzUa4Z76PFHMl54flIIF3XKiHZ+KbWjjxCEG5G3ZqZSqTd6OgTiFFLqq9PXJXdfYm6/cnL8IVWQgjFF9DQhIqQs=</pre>
+
+====ROUND 2====
+* Coordinator
+** <tt>my_multisig_wallet.bsms</tt>:
+<pre>BSMS 1.0
+wsh(sortedmulti(2,[1cf0bf7e/48'/0'/0'/2']xpub6FL8FhxNNUVnG64YurPd16AfGyvFLhh7S2uSsDqR3Qfcm6o9jtcMYwh6DvmcBF9qozxNQmTCVvWtxLpKTnhVLN3Pgnu2D3pAoXYFgVyd8Yz/**,[4fc1dd4a/48'/0'/0'/2']xpub6EebMbEps7ZcV3FYEnddRsvrFWDrt2tiPmCeM7pPXQEmphvq9ZfJ1LWFUDjf3vxCeBuPrfyGrMazWUsYsetrnHatQZVLJH7LsgCjtMqdzgj/**))
+/0/*,/1/*
+bc1qrgc6p3kylfztu06ysl752gwwuekhvtfh9vr7zg43jvu60mutamcsv948ej</pre>
+
+===Mode: <tt>STANDARD</tt> 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
+** <tt>signer_1_key.bsms</tt>:
+<pre>BSMS 1.0
+a54044308ceac9b7
+[b7868815/48'/0'/0'/2']xpub6FA5rfxJc94K1kNtxRby1hoHwi7YDyTWwx1KUR3FwskaF6HzCbZMz3zQwGnCqdiFeMTPV3YneTGS2YQPiuNYsSvtggWWMQpEJD4jXU7ZzEh
+Signer 1 key
+H8DYht5P6ko0bQqDV6MtUxpzBSK+aVHxbvMavA5byvLrOlCEGmO1WFR7k2wu42J6dxXD8vrmDQSnGq5MTMMbZ98=</pre>
+
+* Signer 1 encryption
+** HMAC_KEY (hex): 3d4c422806ba8964c9ee45070cd675c024d96648a0ddb4001325818c84951de2
+** MAC (hex): fbdbdb64e6a8231c342131d9f13dcd5a954b4c5021658fa5afcb3fc74dc82706
+** IV (hex) : fbdbdb64e6a8231c342131d9f13dcd5a
+** CIPHERTEXT (hex): 53f491cfd1431c292d922ea5a5dec3eb8ddaa6ed38ae109e7b040f0f23013e89a89b4d27476761a01197a3277850b2bc1621ae626efe65f2081eec6eb571c4f787bf1c49d061b43f70fd73cb3f37fa591d2400973ac0644c8941a83f1d4155e98f01fa2fdeb9f86c2e2413154fd18566a28fb0d9d8bd6172efabcfa6dab09ee7029bf3dd43376df52c118a6d291ec168f4ec7f7df951dfc6135fd8cb4b234da62eaea6017dfe5ca418f083e02e3aba2962ba313ba17b6468c7672fb218329a9f3fe4e4887fb87dac57c63ebff0e715a44498d18de8afc10e1cfeb46a1fc65ce871fef8a43b289305433a90c342d025aa4c19454fcfbcf911e9e2f928d5affd0536a6ddc2e816
+** <tt>signer_1_key.dat</tt>: <pre>fbdbdb64e6a8231c342131d9f13dcd5a954b4c5021658fa5afcb3fc74dc8270653f491cfd1431c292d922ea5a5dec3eb8ddaa6ed38ae109e7b040f0f23013e89a89b4d27476761a01197a3277850b2bc1621ae626efe65f2081eec6eb571c4f787bf1c49d061b43f70fd73cb3f37fa591d2400973ac0644c8941a83f1d4155e98f01fa2fdeb9f86c2e2413154fd18566a28fb0d9d8bd6172efabcfa6dab09ee7029bf3dd43376df52c118a6d291ec168f4ec7f7df951dfc6135fd8cb4b234da62eaea6017dfe5ca418f083e02e3aba2962ba313ba17b6468c7672fb218329a9f3fe4e4887fb87dac57c63ebff0e715a44498d18de8afc10e1cfeb46a1fc65ce871fef8a43b289305433a90c342d025aa4c19454fcfbcf911e9e2f928d5affd0536a6ddc2e816</pre>
+
+* Signer 2
+** MASTER_KEY_FINGERPRINT: eedff89a
+** PRIVATE_KEY (m/48'/0'/0'/2'): Kz1ijnkDXmc65NWTYdg47DDaQgSGJAPfhJG9Unm36oqZPpPXuNR6
+** XPUB (m/48'/0'/0'/2'): xpub6EhJvMneoLWAf8cuyLBLQiKiwh89RAmqXEqYeFuaCEHdHwxSRfzLrUxKXEBap7nZSHAYP7Jfq6gZmucotNzpMQ9Sb1nTqerqW8hrtmx6Y6o
+** Legacy signature
+** <tt>signer_2_key.bsms</tt>:
+<pre>BSMS 1.0
+a54044308ceac9b7
+[eedff89a/48'/0'/0'/2']xpub6EhJvMneoLWAf8cuyLBLQiKiwh89RAmqXEqYeFuaCEHdHwxSRfzLrUxKXEBap7nZSHAYP7Jfq6gZmucotNzpMQ9Sb1nTqerqW8hrtmx6Y6o
+Signer 2 key
+H/IHW5dMGYsrRdYEz3ux+kKnkWBtxHzfYkREpnYbco38VnMvIxCbDuf7iu6960qDhBLR/RLjlb9UPtLmCMbczDE=</pre>
+
+* Signer 2 encryption
+** HMAC_KEY (hex): 3d4c422806ba8964c9ee45070cd675c024d96648a0ddb4001325818c84951de2
+** MAC (hex): 383d05b7351a2cef7cca2850450f5efbbc4a3f8ea35707dda87a3692f0f2ebae
+** IV (hex) : 383d05b7351a2cef7cca2850450f5efb
+** CIPHERTEXT (hex): 71860b7c69f3a7665c3c3e85c45735bff78535a37ec6610b724627c73696820d519a9251703b17626b63898580233bebbb310aedbc370224b044ee19600bfe583445a6f26fb9bb5790bae516892655adb0e5dfc12be4609c2e0818d4f1f3bfccc4cd1a36f419d6cd842c913ae81eef4865ad473c32c3ee69cd98d6d0a088e2abdd01fe68b5c0503bb9183f9a912506204e5a9c6bd5a1626ff7eac30312a0b85004307c525e52fa3ad45a0b02eabc8cfaea0215bb6e60ee5f32d6673955290e008fbaef362977a21fd9830e3a604f9bb318cdcde456eae91dbedaa069bcd1efb0f981d5b0e502bd4dada903205458a00914887226a8dde317c02a8be4342acb97a8fee79fbe23
+** <tt>signer_2_key.dat</tt>: <pre>383d05b7351a2cef7cca2850450f5efbbc4a3f8ea35707dda87a3692f0f2ebae71860b7c69f3a7665c3c3e85c45735bff78535a37ec6610b724627c73696820d519a9251703b17626b63898580233bebbb310aedbc370224b044ee19600bfe583445a6f26fb9bb5790bae516892655adb0e5dfc12be4609c2e0818d4f1f3bfccc4cd1a36f419d6cd842c913ae81eef4865ad473c32c3ee69cd98d6d0a088e2abdd01fe68b5c0503bb9183f9a912506204e5a9c6bd5a1626ff7eac30312a0b85004307c525e52fa3ad45a0b02eabc8cfaea0215bb6e60ee5f32d6673955290e008fbaef362977a21fd9830e3a604f9bb318cdcde456eae91dbedaa069bcd1efb0f981d5b0e502bd4dada903205458a00914887226a8dde317c02a8be4342acb97a8fee79fbe23</pre>
+
+====ROUND 2====
+*Coordinator
+** <tt>my_multisig_wallet.bsms</tt>:
+<pre>BSMS 1.0
+wsh(sortedmulti(2,[b7868815/48'/0'/0'/2']xpub6FA5rfxJc94K1kNtxRby1hoHwi7YDyTWwx1KUR3FwskaF6HzCbZMz3zQwGnCqdiFeMTPV3YneTGS2YQPiuNYsSvtggWWMQpEJD4jXU7ZzEh/**,[eedff89a/48'/0'/0'/2']xpub6EhJvMneoLWAf8cuyLBLQiKiwh89RAmqXEqYeFuaCEHdHwxSRfzLrUxKXEBap7nZSHAYP7Jfq6gZmucotNzpMQ9Sb1nTqerqW8hrtmx6Y6o/**))
+/0/*,/1/*
+bc1qhs4u273g4azq7kqqpe6vh5wfhasfmrq7nheyzsnq77humd7rwtkqagvakf</pre>
+
+*Coordinator encryption
+** HMAC_KEY (hex): 3d4c422806ba8964c9ee45070cd675c024d96648a0ddb4001325818c84951de2
+** MAC (hex): 734ce791b466861945e1ef6f74c63faec590793de54831f0036b28d08714b71a
+** IV (hex) : 734ce791b466861945e1ef6f74c63fae
+** CIPHERTEXT (hex): 273cad18a5e1eff37dba6d850749594c9a3fd32b2069e8c69983ea269c5044b6bcaea26d9dbc8ad5d28bb8abfa02e3bfc7632fcc5c2b76e9abb1982ff11295858cfe44a8b97110ae970f58fff3fb6477f38ca9609eec78eedb1d640eaba489fd5e41e787b8d0bde48f1fa99cca641cabbee0f513fb1040cb73df10a57c9a34e4efcb069cd4c75467442c15d878ed9f40e3dffb98294931a6da4f444ae46f739b7fe002ce19fcfe71b05b9783d797ba45d568febbc8a2b0850da67f349d8567342352e1712c3d2a7ea1b2721df5efdb844431f0e5dcfa4acacb194c20785c9bb6dde90d64352fc913e9073b3b416be713bcc7632c821bbfddafa6199d471c54fb899f347f5fc706787ccaa82332dc8b93aeb3de3497d8e5c75f0f5d718c74bc6f8194fe999948e517f1c98398d9cb907d200f1d045394704b074dfb10e587f54fd78e95ef4bcbe77bf1376b390c3f47c91c12b2ed14073ea56bceab41f924302e62183c456b06d96b3da30439cb4320c764a0d6d1b3dabc06fc
+** <tt>my_multisig_wallet.dat</tt>: <pre>734ce791b466861945e1ef6f74c63faec590793de54831f0036b28d08714b71a273cad18a5e1eff37dba6d850749594c9a3fd32b2069e8c69983ea269c5044b6bcaea26d9dbc8ad5d28bb8abfa02e3bfc7632fcc5c2b76e9abb1982ff11295858cfe44a8b97110ae970f58fff3fb6477f38ca9609eec78eedb1d640eaba489fd5e41e787b8d0bde48f1fa99cca641cabbee0f513fb1040cb73df10a57c9a34e4efcb069cd4c75467442c15d878ed9f40e3dffb98294931a6da4f444ae46f739b7fe002ce19fcfe71b05b9783d797ba45d568febbc8a2b0850da67f349d8567342352e1712c3d2a7ea1b2721df5efdb844431f0e5dcfa4acacb194c20785c9bb6dde90d64352fc913e9073b3b416be713bcc7632c821bbfddafa6199d471c54fb899f347f5fc706787ccaa82332dc8b93aeb3de3497d8e5c75f0f5d718c74bc6f8194fe999948e517f1c98398d9cb907d200f1d045394704b074dfb10e587f54fd78e95ef4bcbe77bf1376b390c3f47c91c12b2ed14073ea56bceab41f924302e62183c456b06d96b3da30439cb4320c764a0d6d1b3dabc06fc</pre>
+
+===Mode: <tt>EXTENDED</tt> 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
+** <tt>signer_1_key.bsms</tt>:
+<pre>BSMS 1.0
+108a2360adb302774eb521daebbeda5e
+[793cc70b/48'/0'/0'/1']xpub6ErVmcYYHmavsMgxEcTZyzN5sqth1ZyRpFNJC26ij1wYGC2SBKYrgt9yariSbn7HLRoZUvhUhmPfsRTPrdhhGFscpPZzmch6UTdmRP1aZUj
+Signer 1 key
+ILG47LpCtjoD9UxL87jo5QFqA90t8g9fDQp/KBojdKgPPGB1pMx2bf9hPdORNZIOdCc/2+Gs6AOs3BEK9ubIuBw=</pre>
+
+* Signer 1 encryption
+** HMAC_KEY (hex): 1162cdace4ac9fcde1f96924b93714143d057a701de83ebaed248d1c9154f9fd
+** MAC (hex): ea12776c73de4bd5ea57c2d19eb8e0be856ac0d7f5651f7b74be4563d61ba5b1
+** IV (hex) : ea12776c73de4bd5ea57c2d19eb8e0be
+** CIPHERTEXT (hex): a36f34232bff47a853092654a718fea4f5f57d6a1f3d38fede04e2414da12c90cefc24ef662f736886d9a7fd6e7db636ca47217803c86b7fbcebe4ad6b71cffc261069c135bd2b2430fb2b446ff0203df34fbbc6801243e8a930b9d0cd3a9b160b8dcdc9131ce6e97641e6314b3285ff341013f302e308c1b2eba7ced0103a8999fe2bd86f844392938e7926cd26d023b764d0b8ff92b2fbdf995884c738414b83563ef2a0050279bf46d0e8271ea5d6af8154847c5736129a7a83a35a3cc747b2be4b389886cb57456678353b60473ebc4ab85d9c9131a17a1e288717343d9008825b16c48d7e93927f37b530033192c67b70dec0411a3e5952d2525c7eb80721676e1a6299248c17f8078202f3bb0932e9f263b0ab
+** <tt>signer_1_key.dat</tt>: <pre>ea12776c73de4bd5ea57c2d19eb8e0be856ac0d7f5651f7b74be4563d61ba5b1a36f34232bff47a853092654a718fea4f5f57d6a1f3d38fede04e2414da12c90cefc24ef662f736886d9a7fd6e7db636ca47217803c86b7fbcebe4ad6b71cffc261069c135bd2b2430fb2b446ff0203df34fbbc6801243e8a930b9d0cd3a9b160b8dcdc9131ce6e97641e6314b3285ff341013f302e308c1b2eba7ced0103a8999fe2bd86f844392938e7926cd26d023b764d0b8ff92b2fbdf995884c738414b83563ef2a0050279bf46d0e8271ea5d6af8154847c5736129a7a83a35a3cc747b2be4b389886cb57456678353b60473ebc4ab85d9c9131a17a1e288717343d9008825b16c48d7e93927f37b530033192c67b70dec0411a3e5952d2525c7eb80721676e1a6299248c17f8078202f3bb0932e9f263b0ab</pre>
+
+* Signer 2
+** MASTER_KEY_FINGERPRINT: b3118e52
+** PRIVATE_KEY (m/48'/0'/0'/1'): L4SnPjcHszMg3Wi2YYxEYnzM2zFeFkFr5NcLZ18YQeyJwaSFbTud
+** XPUB (m/48'/0'/0'/1'): xpub6Du5Jn6eYZE96ccmAc1ZTFPzdnzrvqfG4mpamDun2qZYKywoiQJMCbS3kWWMr6U3XW6s125RLsaPABWgv2yA749ieaMe67FxkTjMsbcxCch
+** Legacy signature
+** <tt>signer_2_key.bsms</tt>:
+<pre>BSMS 1.0
+d3fabc873b98165254fe18a71b5335b0
+[b3118e52/48'/0'/0'/1']xpub6Du5Jn6eYZE96ccmAc1ZTFPzdnzrvqfG4mpamDun2qZYKywoiQJMCbS3kWWMr6U3XW6s125RLsaPABWgv2yA749ieaMe67FxkTjMsbcxCch
+Signer 2 key
+IDK4d/oO0pgfrwRu4Zb8vqlPEmJb9aKT1K2CCnI3RKepVAKs3fZsBrypcCdQfUy1TG/3O5vAR3gjldxcCA1Wzg8=</pre>
+
+* Signer 2 encryption
+** HMAC_KEY (hex): 43a4e704bd1bade703023004b00290f1a7b005474a581d869a217068eedf3f57
+** MAC (hex): 4a3ff970d027010e83b4fbf2845a23907a301b3df692a9265e2ca679697ac718
+** IV (hex) : 4a3ff970d027010e83b4fbf2845a2390
+** CIPHERTEXT (hex): c8f4a6a6714eff90aa48cbefe6750c2ee3cc72182eb455e964f0ba59ada3ecd758c29f0fab7e33aaa82a340a18d9c793ddab09dc7e714864faac1ecea370d4f102533b739da38aa0491433f35eadec08f203685f04d1f6ec35d397d99e4f8096a5691075e3f54fd9ff58faf947f276bbe1031f827b274bd2f60fcb526add7058889104b189d7da22ac7be1f7ddd380bbebd5c6983a8a3c5fa86913e3d23c40935072ce03d9bdeb07791dc836d44b4d4c62f364d0e4f3580369ea8f6ebb774b7fda4a7ac6f5ae6b2f52b10cd71bdf3cdb5889e77d5eb1f2f647b798cdd6b3e5b964c9265daea3668d7e4cb53f724151923da1a87bbcd2abd8b164de474d865c51af69885431d26f88a5c8eea7d0dfdb52ca622017808a
+** <tt>signer_2_key.dat</tt>: <pre>4a3ff970d027010e83b4fbf2845a23907a301b3df692a9265e2ca679697ac718c8f4a6a6714eff90aa48cbefe6750c2ee3cc72182eb455e964f0ba59ada3ecd758c29f0fab7e33aaa82a340a18d9c793ddab09dc7e714864faac1ecea370d4f102533b739da38aa0491433f35eadec08f203685f04d1f6ec35d397d99e4f8096a5691075e3f54fd9ff58faf947f276bbe1031f827b274bd2f60fcb526add7058889104b189d7da22ac7be1f7ddd380bbebd5c6983a8a3c5fa86913e3d23c40935072ce03d9bdeb07791dc836d44b4d4c62f364d0e4f3580369ea8f6ebb774b7fda4a7ac6f5ae6b2f52b10cd71bdf3cdb5889e77d5eb1f2f647b798cdd6b3e5b964c9265daea3668d7e4cb53f724151923da1a87bbcd2abd8b164de474d865c51af69885431d26f88a5c8eea7d0dfdb52ca622017808a</pre>
+
+* Signer 3
+** MASTER_KEY_FINGERPRINT: 842bd2ed
+** PRIVATE_KEY (m/48'/0'/0'/1'): L1ehZHpo2UFHc1yaBWDU4bKVycUwcU2TESm92wbfq6xK6qpZZJP6
+** XPUB (m/48'/0'/0'/1'): xpub6Ex81KopPkEt9hJiWHabYy8LNsSR4A7sUQoFBk9dR8XxHrr4p9HrYWN3NCf5uwfopHnQkCG7FYnZMztKbtRtbh6tzZC4xtHPbmVVxRSN7ic
+** Legacy signature
+** <tt>signer_3_key.bsms</tt>:
+<pre>BSMS 1.0
+78a7d5e7549453d719150de5459c9ce5
+[842bd2ed/48'/0'/0'/1']xpub6Ex81KopPkEt9hJiWHabYy8LNsSR4A7sUQoFBk9dR8XxHrr4p9HrYWN3NCf5uwfopHnQkCG7FYnZMztKbtRtbh6tzZC4xtHPbmVVxRSN7ic
+Signer 3 key
+IL77mML0xo/O9dJn0T5EpQLuyRPPrdpgVJbtsdAugW5iX0MQ3Ci0f8jVnXu68Xm07CYjYGKX8af72jmkQKhNud0=</pre>
+
+* Signer 3 encryption
+** HMAC_KEY (hex): ab93ce7bf0f91c62a66d00ea9bf5e5c00b854ee2cfc2fb06f6eeff738abcdc26
+** MAC (hex): e82cfcccbd4bd4d3b76e28133eecd13f7362f4a8b4c4baa3e5f6ba2dfb4d69b8
+** IV (hex) : e82cfcccbd4bd4d3b76e28133eecd13f
+** CIPHERTEXT (hex): b44433f0b564ec35a1e71371f25844088084b47402c90d52fee7237167b58a60a28c234af9123e104773136e8446d799541c8566882787caee7cd1fa8628aba63aa9e9d7cca0ddee92f96dd881535b19a131a1f487a1909e42d62945fd0ba08dacd7dc09a22ffe47e0410b8b85df92e4a8bbf9b46f0062da02e3ae94144a00bae917acc1246d8d1a4dca105708f55379caefef9d4c152f56b65ab4bd7b48f60233f57ba6d705387c79aeaa2a279e3314004bf16fcd7e7d2adef34b0ab3c22bc5461f2c09dce69065605e4fb96958c55984391712b3547e3914ad4ecca2c088be280dfcfe374a112515674aeca57b885e81dbef6a353ca387f4514db3158eb69f0d2725d42ad8102c05c26ad501d48b889c624035ead4
+** <tt>signer_3_key.dat</tt>: <pre>e82cfcccbd4bd4d3b76e28133eecd13f7362f4a8b4c4baa3e5f6ba2dfb4d69b8b44433f0b564ec35a1e71371f25844088084b47402c90d52fee7237167b58a60a28c234af9123e104773136e8446d799541c8566882787caee7cd1fa8628aba63aa9e9d7cca0ddee92f96dd881535b19a131a1f487a1909e42d62945fd0ba08dacd7dc09a22ffe47e0410b8b85df92e4a8bbf9b46f0062da02e3ae94144a00bae917acc1246d8d1a4dca105708f55379caefef9d4c152f56b65ab4bd7b48f60233f57ba6d705387c79aeaa2a279e3314004bf16fcd7e7d2adef34b0ab3c22bc5461f2c09dce69065605e4fb96958c55984391712b3547e3914ad4ecca2c088be280dfcfe374a112515674aeca57b885e81dbef6a353ca387f4514db3158eb69f0d2725d42ad8102c05c26ad501d48b889c624035ead4</pre>
+
+====ROUND 2====
+* Coordinator
+** <tt>my_multisig_wallet.bsms</tt>:
+<pre>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</pre>
+
+* Send to Signer 1:
+** HMAC_KEY (hex): 1162cdace4ac9fcde1f96924b93714143d057a701de83ebaed248d1c9154f9fd
+** MAC (hex): 01bf557b6d44b3fbf07f8ec155cbdec42d85d856e174342563dd83b40ad7c025
+** IV (hex) : 01bf557b6d44b3fbf07f8ec155cbdec4
+** CIPHERTEXT (hex): 617ed25b4b8fd88b806cbebcc1731b071465514a805f7ba2de60e291bc9493f31aa0f9b0665ba822cf9a2e21c02649b5c3f7dbad317ae898292cb6fe992520f68c0ebe9d1434b348af10453f1be0a392a616d43ba21e5e7fa3c995dce54db947fe5dbad4a9a77f37b3aef58c54ee3e496c8312d3033359aed0de8cf28b82035ee7a38c9b23c9d95682fb15936bf2247546d2ba9b3ada605f5c89f0a3bbaa86cb4b5dded9a65004912c0afbbfd01f0115447f5625e8523f9de16165d32c4b21103d8ac965e2f7e17641ee1a8c5902e8dbb461c6c7d05141f7bba66b8b3608037fb251b55fa461c9441c6427921545a34a1798127d5bf9cc92423f7e62c769e232c65db8cc5124577012d49941143c3b4758212a8afa0475c9b3597da2e99d585039339b7d73611aa277878d212875051683053db9c630391e0b32356523e9fa8a58a334e16fe6650472f336ddaa8c587992b6c0c0e480b680261579a11cf9d036614abc113dde53653273f5ce82ea0bc10e38ca52ac66838aa49ff46c3a7d5096db439c15d3c2e8de55e4ac7315a57eb9997f219c378af86c858867ce583ed84e4d9c68aecfbca9ebff16b0ac91531125e273b215db688ffe52c8033eb78914b87c0fa2001c52e90c92765712e50384ddcf4d0953ac3cc8137abcb2a85d603a6cc207472677
+** <tt>my_multisig_wallet_for_signer_1.dat</tt>: <pre>01bf557b6d44b3fbf07f8ec155cbdec42d85d856e174342563dd83b40ad7c025617ed25b4b8fd88b806cbebcc1731b071465514a805f7ba2de60e291bc9493f31aa0f9b0665ba822cf9a2e21c02649b5c3f7dbad317ae898292cb6fe992520f68c0ebe9d1434b348af10453f1be0a392a616d43ba21e5e7fa3c995dce54db947fe5dbad4a9a77f37b3aef58c54ee3e496c8312d3033359aed0de8cf28b82035ee7a38c9b23c9d95682fb15936bf2247546d2ba9b3ada605f5c89f0a3bbaa86cb4b5dded9a65004912c0afbbfd01f0115447f5625e8523f9de16165d32c4b21103d8ac965e2f7e17641ee1a8c5902e8dbb461c6c7d05141f7bba66b8b3608037fb251b55fa461c9441c6427921545a34a1798127d5bf9cc92423f7e62c769e232c65db8cc5124577012d49941143c3b4758212a8afa0475c9b3597da2e99d585039339b7d73611aa277878d212875051683053db9c630391e0b32356523e9fa8a58a334e16fe6650472f336ddaa8c587992b6c0c0e480b680261579a11cf9d036614abc113dde53653273f5ce82ea0bc10e38ca52ac66838aa49ff46c3a7d5096db439c15d3c2e8de55e4ac7315a57eb9997f219c378af86c858867ce583ed84e4d9c68aecfbca9ebff16b0ac91531125e273b215db688ffe52c8033eb78914b87c0fa2001c52e90c92765712e50384ddcf4d0953ac3cc8137abcb2a85d603a6cc207472677</pre>
+
+* Send to Signer 2:
+** HMAC_KEY (hex): 43a4e704bd1bade703023004b00290f1a7b005474a581d869a217068eedf3f57
+** MAC (hex): 974ba77900c43c463dadaa6eaf24aaeb1b25b443cf155229b719bcbf8b343092
+** IV (hex) : 974ba77900c43c463dadaa6eaf24aaeb
+** CIPHERTEXT (hex): 86288c97a6341974a35015f97fbbc8db7655639c839fc438706f82fce36a82dd17e2d4d4a674516c4fc5c3a33d6097dd8fc5c6605018946741ed9f58d8fe530a808f16f0dd705cacfd273e34a158bd7566774dd31506b8280e448fabb72d0e7dfc05cee1142b61921dfaf0b0039d885cc0aa76c429025efc2ba49a8af15b58e75a5a83ba4838a9a4c9f13725f5aecefd8511513d93797f37b93150b9dca725685883188e39142dd8d3cf4b617c7936bdb3875415bbf6dfb2fe1a39ae2aed9fd2909aebd0355a5cc9a55bcb84048c851a1873948e495180f336edeb63f54bcf83feaa4d2453251260e24293e49815c2369c1c045083c412c973987fd7c9296a71cda424823ed32380ba442394500b7d2d2335818099090aaf08ca4e180869c546f58da4cb4ff0f95b796a35c40ea455e2ddd3e08bc494ffddc706aaf4d479f4f359e6a89a90df7c9b8f23cab355855a72b90795a0db83a96bce0dd4f77e3f58c0957b4ffe9663251565098e6c31fd4bbf3e1295faaff05e29912d9c37cb944da379a9b2193b466910d05a681e53a2dbe5aa18a2b4874153fe36d8a1aa4cc6e612bd6dbc9abb8e1e61b927fc5458d8e1be9536cd462e4c37672af7928c39e94bdc124a2da7b1bd3cad2cfe559adc33e62eb45bff89db8a47a72dda4f49f21c01a9432f4802a1
+** <tt>my_multisig_wallet_for_signer_2.dat</tt>: <pre>974ba77900c43c463dadaa6eaf24aaeb1b25b443cf155229b719bcbf8b34309286288c97a6341974a35015f97fbbc8db7655639c839fc438706f82fce36a82dd17e2d4d4a674516c4fc5c3a33d6097dd8fc5c6605018946741ed9f58d8fe530a808f16f0dd705cacfd273e34a158bd7566774dd31506b8280e448fabb72d0e7dfc05cee1142b61921dfaf0b0039d885cc0aa76c429025efc2ba49a8af15b58e75a5a83ba4838a9a4c9f13725f5aecefd8511513d93797f37b93150b9dca725685883188e39142dd8d3cf4b617c7936bdb3875415bbf6dfb2fe1a39ae2aed9fd2909aebd0355a5cc9a55bcb84048c851a1873948e495180f336edeb63f54bcf83feaa4d2453251260e24293e49815c2369c1c045083c412c973987fd7c9296a71cda424823ed32380ba442394500b7d2d2335818099090aaf08ca4e180869c546f58da4cb4ff0f95b796a35c40ea455e2ddd3e08bc494ffddc706aaf4d479f4f359e6a89a90df7c9b8f23cab355855a72b90795a0db83a96bce0dd4f77e3f58c0957b4ffe9663251565098e6c31fd4bbf3e1295faaff05e29912d9c37cb944da379a9b2193b466910d05a681e53a2dbe5aa18a2b4874153fe36d8a1aa4cc6e612bd6dbc9abb8e1e61b927fc5458d8e1be9536cd462e4c37672af7928c39e94bdc124a2da7b1bd3cad2cfe559adc33e62eb45bff89db8a47a72dda4f49f21c01a9432f4802a1</pre>
+
+* Send to Signer 3:
+** HMAC_KEY (hex): ab93ce7bf0f91c62a66d00ea9bf5e5c00b854ee2cfc2fb06f6eeff738abcdc26
+** MAC (hex): bb3c93b67d758f244de7ee73e5e61261cea6dff5b3852df8faf265cdf1c73dae
+** IV (hex) : bb3c93b67d758f244de7ee73e5e61261
+** CIPHERTEXT (hex): 7ac33bd9719a3cef6c68e09b3c9677565418933f188bbe50dc70f46329706732fe28ab230468e2a8798d3fbf641867d5b3322113204a372e7650ed06cf94d6df5cc7425b1b3a07690a32e12fd9cdad2c9f42d496c1b02215a7d8d63565aa4935bb2b087af39eebc02d4a2d30a4dbf1e72b9a0dab11473c7254ecf9065eb4f9d80a164c489d5fdae0d15d97b6100b79c3999b91341dfb4f599f738d4d631ae413c17b55daa09a67cb34b40d89c26f0e95ddfbf416033f869da32e502815d720bb342ec1c0e5c6910c598f32162016229cd37ea030b4d3b60f560105abb75531dc960ddf6830c26604c67c2da05b8adc45297dda58b2da4671104969b819cdf1c362bc20d7bdfe4a2fbdb79b4a69e285434d991c269e3d23ce3d95675a0acbec2cae04a310581148d3422c1c0a621fb6d79ecac1743b0e76837389b67cd4734ec5ab560c43a183de35fa98834e1f347a0c0c9b14273b76233f55f04553efcde873de92d766f3cdc5e56bc649bf0cc4951f051619ee9b931cd3872044b0e62ea2c2dacad978dbb8df3afa0b9386535278c295c6a30a56950e57f805770568e937ffafbadb226120991d5ec10effa9f4334800010d141a2ddddc00ac743efa821af37f69840487e4db48036c1e0730788cddbca2f68b3769ec6989d76161e6605af50651b6e86e
+** <tt>my_multisig_wallet_for_signer_3.dat</tt>: <pre>bb3c93b67d758f244de7ee73e5e61261cea6dff5b3852df8faf265cdf1c73dae7ac33bd9719a3cef6c68e09b3c9677565418933f188bbe50dc70f46329706732fe28ab230468e2a8798d3fbf641867d5b3322113204a372e7650ed06cf94d6df5cc7425b1b3a07690a32e12fd9cdad2c9f42d496c1b02215a7d8d63565aa4935bb2b087af39eebc02d4a2d30a4dbf1e72b9a0dab11473c7254ecf9065eb4f9d80a164c489d5fdae0d15d97b6100b79c3999b91341dfb4f599f738d4d631ae413c17b55daa09a67cb34b40d89c26f0e95ddfbf416033f869da32e502815d720bb342ec1c0e5c6910c598f32162016229cd37ea030b4d3b60f560105abb75531dc960ddf6830c26604c67c2da05b8adc45297dda58b2da4671104969b819cdf1c362bc20d7bdfe4a2fbdb79b4a69e285434d991c269e3d23ce3d95675a0acbec2cae04a310581148d3422c1c0a621fb6d79ecac1743b0e76837389b67cd4734ec5ab560c43a183de35fa98834e1f347a0c0c9b14273b76233f55f04553efcde873de92d766f3cdc5e56bc649bf0cc4951f051619ee9b931cd3872044b0e62ea2c2dacad978dbb8df3afa0b9386535278c295c6a30a56950e57f805770568e937ffafbadb226120991d5ec10effa9f4334800010d141a2ddddc00ac743efa821af37f69840487e4db48036c1e0730788cddbca2f68b3769ec6989d76161e6605af50651b6e86e</pre>
+
+==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-0139.mediawiki b/bip-0139.mediawiki
deleted file mode 100644
index 3d4e601..0000000
--- a/bip-0139.mediawiki
+++ /dev/null
@@ -1,462 +0,0 @@
-<pre>
-  BIP: 139
-  Layer: Applications
-  Title: Bitcoin Secure Multisig Setup (BSMS)
-  Author: Hugo Nguyen <hugo at nunchuk.io>
-          Peter Gray <peter at coinkite.com>
-          Marko Bencun <marko at shiftcrypto.ch>
-          Aaron Chen <aarondongchen at gmail.com>
-          Rodolfo Novak <rodolfo at coinkite.com>
-  Comments-Summary: No comments yet.
-  Comments-URI:
-  Status: Proposed
-  Type: Standards Track
-  Created: 2020-11-10
-  License: BSD-2-Clause
-</pre>
-
-==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 <tt>.bsms</tt> file extension. Encrypted data should have a <tt>.dat</tt> 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 <tt>KEY</tt> 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 (<tt>M</tt> and <tt>N</tt>).
-* 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 <tt>TOKEN</tt> to each Signer over a secure channel. The Signer can use the <tt>TOKEN</tt> to derive an <tt>ENCRYPTION_KEY</tt>. Refer to the [[#Encryption]] section below for details on the <tt>TOKEN</tt>, the key derivation function and the encryption scheme. Depending on the use case, the Coordinator can decide whether to share one common <tt>TOKEN</tt> for all Signers, or to have one per Signer.
-* If encryption is disabled, the <tt>TOKEN</tt> is set to <tt>0x00</tt>, and all the encryption/decryption steps below can be skipped.
-
-=====Signer=====
-
-* The Signer initiates the multisig wallet creation session by setting the <tt>TOKEN</tt>. The Signer derives an <tt>ENCRYPTION_KEY</tt> from the <tt>TOKEN</tt>. The Signer can keep the session open until a different value for the <tt>TOKEN</tt> is set.
-* The Signer generates a key record by prompting the user for a multisig derivation path and retrieves the <tt>KEY</tt> 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 <tt>KEY</tt>s for different wallets.
-* The first line in the record must be the specification version (<tt>BSMS 1.0</tt> as of this writing). The second line must be the hex-encoded <tt>TOKEN</tt>. The third line must be the <tt>KEY</tt>. The <tt>KEY</tt> is a public key or an XPUB plus the key origin information, written in the descriptor-defined format, i.e.: <tt>[{master key fingerprint}/{derivation path}]{KEY}</tt>. The fourth line is a text description of the key, 80 characters maximum. The fifth line must be a <tt>SIG</tt>, whereas <tt>SIG</tt> 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 (<tt>MAC</tt>) for the record. The first 16 bytes of the <tt>MAC</tt> serves as the Initialization Vector (<tt>IV</tt>) for the encryption.
-* The Signer encrypts the key record with the <tt>ENCRYPTION_KEY</tt> and <tt>IV</tt>.
-* The Signer encodes the <tt>MAC</tt> and the ciphertext into hexadecimal format, then concatenates the results: <tt>(MAC || ciphertext)</tt>.
-
-====Round 2====
-
-=====Coordinator=====
-
-* The Coordinator gathers key records from all participating Signers. The Coordinator verifies that there are exactly <tt>N</tt> unique key records before the wallet setup session expires.
-* For each key record, the Coordinator extracts the <tt>MAC</tt> from the data, sets <tt>IV</tt> to the first 16 bytes of the <tt>MAC</tt>, then decrypts the ciphertext using the <tt>ENCRYPTION_KEY</tt> and <tt>IV</tt>.
-* The Coordinator verifies that the included <tt>MAC</tt> is valid given the plaintext.
-* The Coordinator verifies that the key records have compatible specification versions.
-* The Coordinator verifies that the included <tt>SIG</tt> is valid given the <tt>KEY</tt>.
-* 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 (<tt>BSMS 1.0</tt> 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 <tt>/</tt> and use non-hardened derivation. If there are no template or restrictions, it must say <tt>No path restrictions</tt>. 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 <tt>MAC</tt> for the record. The first 16 bytes of the <tt>MAC</tt> serves as the <tt>IV</tt> for the encryption.. 
-* The Coordinator encrypts the descriptor record with the <tt>ENCRYPTION_KEY</tt> and <tt>IV</tt>.
-* The Coordinator encodes the <tt>MAC</tt> and the ciphertext into hexadecimal format, then concatenates the results: <tt>(MAC || ciphertext)</tt>.
-* The Coordinator sends the encrypted descriptor record to all participating Signers.
-
-=====Signer=====
-
-* The Signer imports the descriptor record.
-* The Signer extracts the <tt>MAC</tt> from the data, sets <tt>IV</tt> to the first 16 bytes of the <tt>MAC</tt>, then decrypts the ciphertext using the <tt>ENCRYPTION_KEY</tt> (derived from the open session) and <tt>IV</tt>.
-* The Signer verifies that the included <tt>MAC</tt> 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 <tt>KEY</tt> is included in the descriptor or descriptor template, using path and fingerprint information provided. The check must perform an exact match on the <tt>KEY</tt>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, <tt>M</tt>, <tt>N</tt>, and the position(s) of the Signer's own <tt>KEY</tt> in the policy script. The total number of Signers, <tt>N</tt>, is important to prevent a <tt>KEY</tt> insertion attack. The position is important for scripts where <tt>KEY</tt> order matters. When applicable, all positions of the <tt>KEY</tt> 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 <tt>KEY</tt> 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.
-
-# <tt>NO_ENCRYPTION</tt> : the <tt>TOKEN</tt> is set to <tt>0x00</tt>. Encryption is disabled.
-# <tt>STANDARD</tt> : the <tt>TOKEN</tt> is a 64-bit nonce.
-# <tt>EXTENDED</tt> : the <tt>TOKEN</tt> is a 128-bit nonce.
-
-The <tt>TOKEN</tt> 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 <tt>STANDARD</tt> mode. This encoding is not recommended in <tt>EXTENDED</tt> mode as it can result in potential confusion between seed mnemonics and <tt>TOKEN</tt> 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:
-
-<tt>DKey = PBKDF2(PRF, Password, Salt, c, dkLen)</tt>
-
-Whereas:
-
-* PRF = SHA512
-* Password = "No SPOF"
-* Salt = <tt>TOKEN</tt>
-* c = 2048
-* dkLen = 256
-* DKey = Derived <tt>ENCRYPTION_KEY</tt>
-
-====Encryption Scheme====
-The encryption scheme is [https://tools.ietf.org/html/rfc3686 AES-256-CTR].
-
-<tt>MAC = HMAC-SHA256(HMAC_Key, hex-encoded TOKEN || Data)</tt>
-
-<tt>IV = First 16 bytes of MAC</tt>
-
-<tt>Ciphertext = AES-256-CTR-Encrypt(Plaintext, DKey, IV)</tt>
-
-<tt>Plaintext = AES-256-CTR-Decrypt(Ciphertext, DKey, IV)</tt>
-
-Whereas:
-* DKey = <tt>ENCRYPTION_KEY</tt>
-* HMAC_Key = SHA256(<tt>ENCRYPTION_KEY</tt>)
-* Data = the plaintext, e.g. the entire key record in round 1 and the entire descriptor record in round 2
-
-The <tt>MAC</tt> is to be sent along with the key and descriptor record, as specified above. Because it is a <tt>MAC</tt> 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:
-
-<tt>XPUB/**</tt>
-
-Whereas <tt>/**</tt> 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 <tt>/**</tt> with the restrictions.
-
-For example, the following template and derivation path restrictions:
-* <tt>wsh(sortedmulti(2,XPUB1/**,XPUB2/**))</tt>
-* <tt>/0/*,/1/*</tt>
-
-Should translate to two concrete descriptors:
-* <tt>wsh(sortedmulti(2,XPUB1/0/*,XPUB2/0/*))</tt>
-* <tt>wsh(sortedmulti(2,XPUB1/1/*,XPUB2/1/*))</tt>
-
-==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 <tt>TOKEN</tt>. The second one is the confirmation of the wallet's first address.
-
-The <tt>TOKEN</tt> is used to encrypt the two rounds of communication between the Signer and the Coordinator. A <tt>MAC</tt> is also generated from the <tt>TOKEN</tt> and plaintext to authenticate the data being exchanged. The <tt>TOKEN</tt> is only needed during the setup phase, and can be safely discarded afterwards. It is not recommended to use the same <tt>TOKEN</tt> 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 <tt>TOKEN</tt>, and to completely erase knowledge of the <tt>TOKEN</tt> after the multisig wallet has been set up.
-
-==Test Vectors==
-
-===Mode: <tt>NO_ENCRYPTION</tt> 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
-** <tt>signer_1_key.bsms</tt>:
-<pre>BSMS 1.0
-00
-[59865f44/48'/0'/0'/2']026d15412460ba0d881c21837bb999233896085a9ed4e5445bd637c10e579768ba
-Signer 1 key
-H6DXgqkCb353BDPkzppMFpOcdJZlpur0WRetQhIBqSn6DFzoQWBtm+ibP5wERDRNi0bxxev9B+FIvyQWq0s6im4=</pre>
-
-* Signer 2
-** MASTER_KEY_FINGERPRINT: b7044ca6
-** PRIVATE_KEY (m/48'/0'/0'/2'): KwT7BZDWjos4JAdfKi8NqF46Kj3rppTwN8KGhPbzmmugiZioFW3r
-** Public Key (m/48'/0'/0'/2'): 030baf0497ab406ff50cb48b4013abac8a0338758d2fd54cd934927afa57cc2062
-** Legacy signature
-** <tt>signer_2_key.bsms</tt>:
-<pre>BSMS 1.0
-00
-[b7044ca6/48'/0'/0'/2']030baf0497ab406ff50cb48b4013abac8a0338758d2fd54cd934927afa57cc2062
-Signer 2 key
-H08mGNGN+NxX/snt+6eX2Q1HjjfDkOtotglshHi7xdsBdIrTVMCQbgQ5SdACNZ0B2AJcifK11nJj43SvaitSemI=</pre>
-
-====ROUND 2====
-* Coordinator
-** <tt>my_multisig_wallet.bsms</tt>:
-<pre>BSMS 1.0
-wsh(sortedmulti(1,[59865f44/48'/0'/0'/2']026d15412460ba0d881c21837bb999233896085a9ed4e5445bd637c10e579768ba,[b7044ca6/48'/0'/0'/2']030baf0497ab406ff50cb48b4013abac8a0338758d2fd54cd934927afa57cc2062))#rzx9dffd
-No path restrictions
-bc1quqy523xu3l8che3s8vja8n33qtg0uyugr9l5z092s3wa50p8t7rqy6zumf</pre>
-
-===Mode: <tt>NO_ENCRYPTION</tt>===
-====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
-** <tt>signer_1_key.bsms</tt>:
-<pre>BSMS 1.0
-00
-[1cf0bf7e/48'/0'/0'/2']xpub6FL8FhxNNUVnG64YurPd16AfGyvFLhh7S2uSsDqR3Qfcm6o9jtcMYwh6DvmcBF9qozxNQmTCVvWtxLpKTnhVLN3Pgnu2D3pAoXYFgVyd8Yz
-Signer 1 key
-IB7v+qi1b+Xrwm/3bF+Rjl8QbIJ/FMQ40kUsOOQo1SqUWn5QlFWbBD8BKPRetfo1L1N7DmYjVscZNsmMrqRJGWw=</pre>
-
-* Signer 2
-** MASTER_KEY_FINGERPRINT: 4fc1dd4a
-** PRIVATE_KEY (m/48'/0'/0'/2'): L4JNkJfLBDyWfTLbKJ1H3w56GUMsvdfjCkzRo5RHXfJ6bdHqm6cN
-** XPUB (m/48'/0'/0'/2'): xpub6EebMbEps7ZcV3FYEnddRsvrFWDrt2tiPmCeM7pPXQEmphvq9ZfJ1LWFUDjf3vxCeBuPrfyGrMazWUsYsetrnHatQZVLJH7LsgCjtMqdzgj
-** Legacy signature
-** <tt>signer_2_key.bsms</tt>:
-<pre>BSMS 1.0
-00
-[4fc1dd4a/48'/0'/0'/2']xpub6EebMbEps7ZcV3FYEnddRsvrFWDrt2tiPmCeM7pPXQEmphvq9ZfJ1LWFUDjf3vxCeBuPrfyGrMazWUsYsetrnHatQZVLJH7LsgCjtMqdzgj
-Signer 2 key
-HzUa4Z76PFHMl54flIIF3XKiHZ+KbWjjxCEG5G3ZqZSqTd6OgTiFFLqq9PXJXdfYm6/cnL8IVWQgjFF9DQhIqQs=</pre>
-
-====ROUND 2====
-* Coordinator
-** <tt>my_multisig_wallet.bsms</tt>:
-<pre>BSMS 1.0
-wsh(sortedmulti(2,[1cf0bf7e/48'/0'/0'/2']xpub6FL8FhxNNUVnG64YurPd16AfGyvFLhh7S2uSsDqR3Qfcm6o9jtcMYwh6DvmcBF9qozxNQmTCVvWtxLpKTnhVLN3Pgnu2D3pAoXYFgVyd8Yz/**,[4fc1dd4a/48'/0'/0'/2']xpub6EebMbEps7ZcV3FYEnddRsvrFWDrt2tiPmCeM7pPXQEmphvq9ZfJ1LWFUDjf3vxCeBuPrfyGrMazWUsYsetrnHatQZVLJH7LsgCjtMqdzgj/**))
-/0/*,/1/*
-bc1qrgc6p3kylfztu06ysl752gwwuekhvtfh9vr7zg43jvu60mutamcsv948ej</pre>
-
-===Mode: <tt>STANDARD</tt> 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
-** <tt>signer_1_key.bsms</tt>:
-<pre>BSMS 1.0
-a54044308ceac9b7
-[b7868815/48'/0'/0'/2']xpub6FA5rfxJc94K1kNtxRby1hoHwi7YDyTWwx1KUR3FwskaF6HzCbZMz3zQwGnCqdiFeMTPV3YneTGS2YQPiuNYsSvtggWWMQpEJD4jXU7ZzEh
-Signer 1 key
-H8DYht5P6ko0bQqDV6MtUxpzBSK+aVHxbvMavA5byvLrOlCEGmO1WFR7k2wu42J6dxXD8vrmDQSnGq5MTMMbZ98=</pre>
-
-* Signer 1 encryption
-** HMAC_KEY (hex): 3d4c422806ba8964c9ee45070cd675c024d96648a0ddb4001325818c84951de2
-** MAC (hex): fbdbdb64e6a8231c342131d9f13dcd5a954b4c5021658fa5afcb3fc74dc82706
-** IV (hex) : fbdbdb64e6a8231c342131d9f13dcd5a
-** CIPHERTEXT (hex): 53f491cfd1431c292d922ea5a5dec3eb8ddaa6ed38ae109e7b040f0f23013e89a89b4d27476761a01197a3277850b2bc1621ae626efe65f2081eec6eb571c4f787bf1c49d061b43f70fd73cb3f37fa591d2400973ac0644c8941a83f1d4155e98f01fa2fdeb9f86c2e2413154fd18566a28fb0d9d8bd6172efabcfa6dab09ee7029bf3dd43376df52c118a6d291ec168f4ec7f7df951dfc6135fd8cb4b234da62eaea6017dfe5ca418f083e02e3aba2962ba313ba17b6468c7672fb218329a9f3fe4e4887fb87dac57c63ebff0e715a44498d18de8afc10e1cfeb46a1fc65ce871fef8a43b289305433a90c342d025aa4c19454fcfbcf911e9e2f928d5affd0536a6ddc2e816
-** <tt>signer_1_key.dat</tt>: <pre>fbdbdb64e6a8231c342131d9f13dcd5a954b4c5021658fa5afcb3fc74dc8270653f491cfd1431c292d922ea5a5dec3eb8ddaa6ed38ae109e7b040f0f23013e89a89b4d27476761a01197a3277850b2bc1621ae626efe65f2081eec6eb571c4f787bf1c49d061b43f70fd73cb3f37fa591d2400973ac0644c8941a83f1d4155e98f01fa2fdeb9f86c2e2413154fd18566a28fb0d9d8bd6172efabcfa6dab09ee7029bf3dd43376df52c118a6d291ec168f4ec7f7df951dfc6135fd8cb4b234da62eaea6017dfe5ca418f083e02e3aba2962ba313ba17b6468c7672fb218329a9f3fe4e4887fb87dac57c63ebff0e715a44498d18de8afc10e1cfeb46a1fc65ce871fef8a43b289305433a90c342d025aa4c19454fcfbcf911e9e2f928d5affd0536a6ddc2e816</pre>
-
-* Signer 2
-** MASTER_KEY_FINGERPRINT: eedff89a
-** PRIVATE_KEY (m/48'/0'/0'/2'): Kz1ijnkDXmc65NWTYdg47DDaQgSGJAPfhJG9Unm36oqZPpPXuNR6
-** XPUB (m/48'/0'/0'/2'): xpub6EhJvMneoLWAf8cuyLBLQiKiwh89RAmqXEqYeFuaCEHdHwxSRfzLrUxKXEBap7nZSHAYP7Jfq6gZmucotNzpMQ9Sb1nTqerqW8hrtmx6Y6o
-** Legacy signature
-** <tt>signer_2_key.bsms</tt>:
-<pre>BSMS 1.0
-a54044308ceac9b7
-[eedff89a/48'/0'/0'/2']xpub6EhJvMneoLWAf8cuyLBLQiKiwh89RAmqXEqYeFuaCEHdHwxSRfzLrUxKXEBap7nZSHAYP7Jfq6gZmucotNzpMQ9Sb1nTqerqW8hrtmx6Y6o
-Signer 2 key
-H/IHW5dMGYsrRdYEz3ux+kKnkWBtxHzfYkREpnYbco38VnMvIxCbDuf7iu6960qDhBLR/RLjlb9UPtLmCMbczDE=</pre>
-
-* Signer 2 encryption
-** HMAC_KEY (hex): 3d4c422806ba8964c9ee45070cd675c024d96648a0ddb4001325818c84951de2
-** MAC (hex): 383d05b7351a2cef7cca2850450f5efbbc4a3f8ea35707dda87a3692f0f2ebae
-** IV (hex) : 383d05b7351a2cef7cca2850450f5efb
-** CIPHERTEXT (hex): 71860b7c69f3a7665c3c3e85c45735bff78535a37ec6610b724627c73696820d519a9251703b17626b63898580233bebbb310aedbc370224b044ee19600bfe583445a6f26fb9bb5790bae516892655adb0e5dfc12be4609c2e0818d4f1f3bfccc4cd1a36f419d6cd842c913ae81eef4865ad473c32c3ee69cd98d6d0a088e2abdd01fe68b5c0503bb9183f9a912506204e5a9c6bd5a1626ff7eac30312a0b85004307c525e52fa3ad45a0b02eabc8cfaea0215bb6e60ee5f32d6673955290e008fbaef362977a21fd9830e3a604f9bb318cdcde456eae91dbedaa069bcd1efb0f981d5b0e502bd4dada903205458a00914887226a8dde317c02a8be4342acb97a8fee79fbe23
-** <tt>signer_2_key.dat</tt>: <pre>383d05b7351a2cef7cca2850450f5efbbc4a3f8ea35707dda87a3692f0f2ebae71860b7c69f3a7665c3c3e85c45735bff78535a37ec6610b724627c73696820d519a9251703b17626b63898580233bebbb310aedbc370224b044ee19600bfe583445a6f26fb9bb5790bae516892655adb0e5dfc12be4609c2e0818d4f1f3bfccc4cd1a36f419d6cd842c913ae81eef4865ad473c32c3ee69cd98d6d0a088e2abdd01fe68b5c0503bb9183f9a912506204e5a9c6bd5a1626ff7eac30312a0b85004307c525e52fa3ad45a0b02eabc8cfaea0215bb6e60ee5f32d6673955290e008fbaef362977a21fd9830e3a604f9bb318cdcde456eae91dbedaa069bcd1efb0f981d5b0e502bd4dada903205458a00914887226a8dde317c02a8be4342acb97a8fee79fbe23</pre>
-
-====ROUND 2====
-*Coordinator
-** <tt>my_multisig_wallet.bsms</tt>:
-<pre>BSMS 1.0
-wsh(sortedmulti(2,[b7868815/48'/0'/0'/2']xpub6FA5rfxJc94K1kNtxRby1hoHwi7YDyTWwx1KUR3FwskaF6HzCbZMz3zQwGnCqdiFeMTPV3YneTGS2YQPiuNYsSvtggWWMQpEJD4jXU7ZzEh/**,[eedff89a/48'/0'/0'/2']xpub6EhJvMneoLWAf8cuyLBLQiKiwh89RAmqXEqYeFuaCEHdHwxSRfzLrUxKXEBap7nZSHAYP7Jfq6gZmucotNzpMQ9Sb1nTqerqW8hrtmx6Y6o/**))
-/0/*,/1/*
-bc1qhs4u273g4azq7kqqpe6vh5wfhasfmrq7nheyzsnq77humd7rwtkqagvakf</pre>
-
-*Coordinator encryption
-** HMAC_KEY (hex): 3d4c422806ba8964c9ee45070cd675c024d96648a0ddb4001325818c84951de2
-** MAC (hex): 734ce791b466861945e1ef6f74c63faec590793de54831f0036b28d08714b71a
-** IV (hex) : 734ce791b466861945e1ef6f74c63fae
-** CIPHERTEXT (hex): 273cad18a5e1eff37dba6d850749594c9a3fd32b2069e8c69983ea269c5044b6bcaea26d9dbc8ad5d28bb8abfa02e3bfc7632fcc5c2b76e9abb1982ff11295858cfe44a8b97110ae970f58fff3fb6477f38ca9609eec78eedb1d640eaba489fd5e41e787b8d0bde48f1fa99cca641cabbee0f513fb1040cb73df10a57c9a34e4efcb069cd4c75467442c15d878ed9f40e3dffb98294931a6da4f444ae46f739b7fe002ce19fcfe71b05b9783d797ba45d568febbc8a2b0850da67f349d8567342352e1712c3d2a7ea1b2721df5efdb844431f0e5dcfa4acacb194c20785c9bb6dde90d64352fc913e9073b3b416be713bcc7632c821bbfddafa6199d471c54fb899f347f5fc706787ccaa82332dc8b93aeb3de3497d8e5c75f0f5d718c74bc6f8194fe999948e517f1c98398d9cb907d200f1d045394704b074dfb10e587f54fd78e95ef4bcbe77bf1376b390c3f47c91c12b2ed14073ea56bceab41f924302e62183c456b06d96b3da30439cb4320c764a0d6d1b3dabc06fc
-** <tt>my_multisig_wallet.dat</tt>: <pre>734ce791b466861945e1ef6f74c63faec590793de54831f0036b28d08714b71a273cad18a5e1eff37dba6d850749594c9a3fd32b2069e8c69983ea269c5044b6bcaea26d9dbc8ad5d28bb8abfa02e3bfc7632fcc5c2b76e9abb1982ff11295858cfe44a8b97110ae970f58fff3fb6477f38ca9609eec78eedb1d640eaba489fd5e41e787b8d0bde48f1fa99cca641cabbee0f513fb1040cb73df10a57c9a34e4efcb069cd4c75467442c15d878ed9f40e3dffb98294931a6da4f444ae46f739b7fe002ce19fcfe71b05b9783d797ba45d568febbc8a2b0850da67f349d8567342352e1712c3d2a7ea1b2721df5efdb844431f0e5dcfa4acacb194c20785c9bb6dde90d64352fc913e9073b3b416be713bcc7632c821bbfddafa6199d471c54fb899f347f5fc706787ccaa82332dc8b93aeb3de3497d8e5c75f0f5d718c74bc6f8194fe999948e517f1c98398d9cb907d200f1d045394704b074dfb10e587f54fd78e95ef4bcbe77bf1376b390c3f47c91c12b2ed14073ea56bceab41f924302e62183c456b06d96b3da30439cb4320c764a0d6d1b3dabc06fc</pre>
-
-===Mode: <tt>EXTENDED</tt> 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
-** <tt>signer_1_key.bsms</tt>:
-<pre>BSMS 1.0
-108a2360adb302774eb521daebbeda5e
-[793cc70b/48'/0'/0'/1']xpub6ErVmcYYHmavsMgxEcTZyzN5sqth1ZyRpFNJC26ij1wYGC2SBKYrgt9yariSbn7HLRoZUvhUhmPfsRTPrdhhGFscpPZzmch6UTdmRP1aZUj
-Signer 1 key
-ILG47LpCtjoD9UxL87jo5QFqA90t8g9fDQp/KBojdKgPPGB1pMx2bf9hPdORNZIOdCc/2+Gs6AOs3BEK9ubIuBw=</pre>
-
-* Signer 1 encryption
-** HMAC_KEY (hex): 1162cdace4ac9fcde1f96924b93714143d057a701de83ebaed248d1c9154f9fd
-** MAC (hex): ea12776c73de4bd5ea57c2d19eb8e0be856ac0d7f5651f7b74be4563d61ba5b1
-** IV (hex) : ea12776c73de4bd5ea57c2d19eb8e0be
-** CIPHERTEXT (hex): a36f34232bff47a853092654a718fea4f5f57d6a1f3d38fede04e2414da12c90cefc24ef662f736886d9a7fd6e7db636ca47217803c86b7fbcebe4ad6b71cffc261069c135bd2b2430fb2b446ff0203df34fbbc6801243e8a930b9d0cd3a9b160b8dcdc9131ce6e97641e6314b3285ff341013f302e308c1b2eba7ced0103a8999fe2bd86f844392938e7926cd26d023b764d0b8ff92b2fbdf995884c738414b83563ef2a0050279bf46d0e8271ea5d6af8154847c5736129a7a83a35a3cc747b2be4b389886cb57456678353b60473ebc4ab85d9c9131a17a1e288717343d9008825b16c48d7e93927f37b530033192c67b70dec0411a3e5952d2525c7eb80721676e1a6299248c17f8078202f3bb0932e9f263b0ab
-** <tt>signer_1_key.dat</tt>: <pre>ea12776c73de4bd5ea57c2d19eb8e0be856ac0d7f5651f7b74be4563d61ba5b1a36f34232bff47a853092654a718fea4f5f57d6a1f3d38fede04e2414da12c90cefc24ef662f736886d9a7fd6e7db636ca47217803c86b7fbcebe4ad6b71cffc261069c135bd2b2430fb2b446ff0203df34fbbc6801243e8a930b9d0cd3a9b160b8dcdc9131ce6e97641e6314b3285ff341013f302e308c1b2eba7ced0103a8999fe2bd86f844392938e7926cd26d023b764d0b8ff92b2fbdf995884c738414b83563ef2a0050279bf46d0e8271ea5d6af8154847c5736129a7a83a35a3cc747b2be4b389886cb57456678353b60473ebc4ab85d9c9131a17a1e288717343d9008825b16c48d7e93927f37b530033192c67b70dec0411a3e5952d2525c7eb80721676e1a6299248c17f8078202f3bb0932e9f263b0ab</pre>
-
-* Signer 2
-** MASTER_KEY_FINGERPRINT: b3118e52
-** PRIVATE_KEY (m/48'/0'/0'/1'): L4SnPjcHszMg3Wi2YYxEYnzM2zFeFkFr5NcLZ18YQeyJwaSFbTud
-** XPUB (m/48'/0'/0'/1'): xpub6Du5Jn6eYZE96ccmAc1ZTFPzdnzrvqfG4mpamDun2qZYKywoiQJMCbS3kWWMr6U3XW6s125RLsaPABWgv2yA749ieaMe67FxkTjMsbcxCch
-** Legacy signature
-** <tt>signer_2_key.bsms</tt>:
-<pre>BSMS 1.0
-d3fabc873b98165254fe18a71b5335b0
-[b3118e52/48'/0'/0'/1']xpub6Du5Jn6eYZE96ccmAc1ZTFPzdnzrvqfG4mpamDun2qZYKywoiQJMCbS3kWWMr6U3XW6s125RLsaPABWgv2yA749ieaMe67FxkTjMsbcxCch
-Signer 2 key
-IDK4d/oO0pgfrwRu4Zb8vqlPEmJb9aKT1K2CCnI3RKepVAKs3fZsBrypcCdQfUy1TG/3O5vAR3gjldxcCA1Wzg8=</pre>
-
-* Signer 2 encryption
-** HMAC_KEY (hex): 43a4e704bd1bade703023004b00290f1a7b005474a581d869a217068eedf3f57
-** MAC (hex): 4a3ff970d027010e83b4fbf2845a23907a301b3df692a9265e2ca679697ac718
-** IV (hex) : 4a3ff970d027010e83b4fbf2845a2390
-** CIPHERTEXT (hex): c8f4a6a6714eff90aa48cbefe6750c2ee3cc72182eb455e964f0ba59ada3ecd758c29f0fab7e33aaa82a340a18d9c793ddab09dc7e714864faac1ecea370d4f102533b739da38aa0491433f35eadec08f203685f04d1f6ec35d397d99e4f8096a5691075e3f54fd9ff58faf947f276bbe1031f827b274bd2f60fcb526add7058889104b189d7da22ac7be1f7ddd380bbebd5c6983a8a3c5fa86913e3d23c40935072ce03d9bdeb07791dc836d44b4d4c62f364d0e4f3580369ea8f6ebb774b7fda4a7ac6f5ae6b2f52b10cd71bdf3cdb5889e77d5eb1f2f647b798cdd6b3e5b964c9265daea3668d7e4cb53f724151923da1a87bbcd2abd8b164de474d865c51af69885431d26f88a5c8eea7d0dfdb52ca622017808a
-** <tt>signer_2_key.dat</tt>: <pre>4a3ff970d027010e83b4fbf2845a23907a301b3df692a9265e2ca679697ac718c8f4a6a6714eff90aa48cbefe6750c2ee3cc72182eb455e964f0ba59ada3ecd758c29f0fab7e33aaa82a340a18d9c793ddab09dc7e714864faac1ecea370d4f102533b739da38aa0491433f35eadec08f203685f04d1f6ec35d397d99e4f8096a5691075e3f54fd9ff58faf947f276bbe1031f827b274bd2f60fcb526add7058889104b189d7da22ac7be1f7ddd380bbebd5c6983a8a3c5fa86913e3d23c40935072ce03d9bdeb07791dc836d44b4d4c62f364d0e4f3580369ea8f6ebb774b7fda4a7ac6f5ae6b2f52b10cd71bdf3cdb5889e77d5eb1f2f647b798cdd6b3e5b964c9265daea3668d7e4cb53f724151923da1a87bbcd2abd8b164de474d865c51af69885431d26f88a5c8eea7d0dfdb52ca622017808a</pre>
-
-* Signer 3
-** MASTER_KEY_FINGERPRINT: 842bd2ed
-** PRIVATE_KEY (m/48'/0'/0'/1'): L1ehZHpo2UFHc1yaBWDU4bKVycUwcU2TESm92wbfq6xK6qpZZJP6
-** XPUB (m/48'/0'/0'/1'): xpub6Ex81KopPkEt9hJiWHabYy8LNsSR4A7sUQoFBk9dR8XxHrr4p9HrYWN3NCf5uwfopHnQkCG7FYnZMztKbtRtbh6tzZC4xtHPbmVVxRSN7ic
-** Legacy signature
-** <tt>signer_3_key.bsms</tt>:
-<pre>BSMS 1.0
-78a7d5e7549453d719150de5459c9ce5
-[842bd2ed/48'/0'/0'/1']xpub6Ex81KopPkEt9hJiWHabYy8LNsSR4A7sUQoFBk9dR8XxHrr4p9HrYWN3NCf5uwfopHnQkCG7FYnZMztKbtRtbh6tzZC4xtHPbmVVxRSN7ic
-Signer 3 key
-IL77mML0xo/O9dJn0T5EpQLuyRPPrdpgVJbtsdAugW5iX0MQ3Ci0f8jVnXu68Xm07CYjYGKX8af72jmkQKhNud0=</pre>
-
-* Signer 3 encryption
-** HMAC_KEY (hex): ab93ce7bf0f91c62a66d00ea9bf5e5c00b854ee2cfc2fb06f6eeff738abcdc26
-** MAC (hex): e82cfcccbd4bd4d3b76e28133eecd13f7362f4a8b4c4baa3e5f6ba2dfb4d69b8
-** IV (hex) : e82cfcccbd4bd4d3b76e28133eecd13f
-** CIPHERTEXT (hex): b44433f0b564ec35a1e71371f25844088084b47402c90d52fee7237167b58a60a28c234af9123e104773136e8446d799541c8566882787caee7cd1fa8628aba63aa9e9d7cca0ddee92f96dd881535b19a131a1f487a1909e42d62945fd0ba08dacd7dc09a22ffe47e0410b8b85df92e4a8bbf9b46f0062da02e3ae94144a00bae917acc1246d8d1a4dca105708f55379caefef9d4c152f56b65ab4bd7b48f60233f57ba6d705387c79aeaa2a279e3314004bf16fcd7e7d2adef34b0ab3c22bc5461f2c09dce69065605e4fb96958c55984391712b3547e3914ad4ecca2c088be280dfcfe374a112515674aeca57b885e81dbef6a353ca387f4514db3158eb69f0d2725d42ad8102c05c26ad501d48b889c624035ead4
-** <tt>signer_3_key.dat</tt>: <pre>e82cfcccbd4bd4d3b76e28133eecd13f7362f4a8b4c4baa3e5f6ba2dfb4d69b8b44433f0b564ec35a1e71371f25844088084b47402c90d52fee7237167b58a60a28c234af9123e104773136e8446d799541c8566882787caee7cd1fa8628aba63aa9e9d7cca0ddee92f96dd881535b19a131a1f487a1909e42d62945fd0ba08dacd7dc09a22ffe47e0410b8b85df92e4a8bbf9b46f0062da02e3ae94144a00bae917acc1246d8d1a4dca105708f55379caefef9d4c152f56b65ab4bd7b48f60233f57ba6d705387c79aeaa2a279e3314004bf16fcd7e7d2adef34b0ab3c22bc5461f2c09dce69065605e4fb96958c55984391712b3547e3914ad4ecca2c088be280dfcfe374a112515674aeca57b885e81dbef6a353ca387f4514db3158eb69f0d2725d42ad8102c05c26ad501d48b889c624035ead4</pre>
-
-====ROUND 2====
-* Coordinator
-** <tt>my_multisig_wallet.bsms</tt>:
-<pre>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</pre>
-
-* Send to Signer 1:
-** HMAC_KEY (hex): 1162cdace4ac9fcde1f96924b93714143d057a701de83ebaed248d1c9154f9fd
-** MAC (hex): 01bf557b6d44b3fbf07f8ec155cbdec42d85d856e174342563dd83b40ad7c025
-** IV (hex) : 01bf557b6d44b3fbf07f8ec155cbdec4
-** CIPHERTEXT (hex): 617ed25b4b8fd88b806cbebcc1731b071465514a805f7ba2de60e291bc9493f31aa0f9b0665ba822cf9a2e21c02649b5c3f7dbad317ae898292cb6fe992520f68c0ebe9d1434b348af10453f1be0a392a616d43ba21e5e7fa3c995dce54db947fe5dbad4a9a77f37b3aef58c54ee3e496c8312d3033359aed0de8cf28b82035ee7a38c9b23c9d95682fb15936bf2247546d2ba9b3ada605f5c89f0a3bbaa86cb4b5dded9a65004912c0afbbfd01f0115447f5625e8523f9de16165d32c4b21103d8ac965e2f7e17641ee1a8c5902e8dbb461c6c7d05141f7bba66b8b3608037fb251b55fa461c9441c6427921545a34a1798127d5bf9cc92423f7e62c769e232c65db8cc5124577012d49941143c3b4758212a8afa0475c9b3597da2e99d585039339b7d73611aa277878d212875051683053db9c630391e0b32356523e9fa8a58a334e16fe6650472f336ddaa8c587992b6c0c0e480b680261579a11cf9d036614abc113dde53653273f5ce82ea0bc10e38ca52ac66838aa49ff46c3a7d5096db439c15d3c2e8de55e4ac7315a57eb9997f219c378af86c858867ce583ed84e4d9c68aecfbca9ebff16b0ac91531125e273b215db688ffe52c8033eb78914b87c0fa2001c52e90c92765712e50384ddcf4d0953ac3cc8137abcb2a85d603a6cc207472677
-** <tt>my_multisig_wallet_for_signer_1.dat</tt>: <pre>01bf557b6d44b3fbf07f8ec155cbdec42d85d856e174342563dd83b40ad7c025617ed25b4b8fd88b806cbebcc1731b071465514a805f7ba2de60e291bc9493f31aa0f9b0665ba822cf9a2e21c02649b5c3f7dbad317ae898292cb6fe992520f68c0ebe9d1434b348af10453f1be0a392a616d43ba21e5e7fa3c995dce54db947fe5dbad4a9a77f37b3aef58c54ee3e496c8312d3033359aed0de8cf28b82035ee7a38c9b23c9d95682fb15936bf2247546d2ba9b3ada605f5c89f0a3bbaa86cb4b5dded9a65004912c0afbbfd01f0115447f5625e8523f9de16165d32c4b21103d8ac965e2f7e17641ee1a8c5902e8dbb461c6c7d05141f7bba66b8b3608037fb251b55fa461c9441c6427921545a34a1798127d5bf9cc92423f7e62c769e232c65db8cc5124577012d49941143c3b4758212a8afa0475c9b3597da2e99d585039339b7d73611aa277878d212875051683053db9c630391e0b32356523e9fa8a58a334e16fe6650472f336ddaa8c587992b6c0c0e480b680261579a11cf9d036614abc113dde53653273f5ce82ea0bc10e38ca52ac66838aa49ff46c3a7d5096db439c15d3c2e8de55e4ac7315a57eb9997f219c378af86c858867ce583ed84e4d9c68aecfbca9ebff16b0ac91531125e273b215db688ffe52c8033eb78914b87c0fa2001c52e90c92765712e50384ddcf4d0953ac3cc8137abcb2a85d603a6cc207472677</pre>
-
-* Send to Signer 2:
-** HMAC_KEY (hex): 43a4e704bd1bade703023004b00290f1a7b005474a581d869a217068eedf3f57
-** MAC (hex): 974ba77900c43c463dadaa6eaf24aaeb1b25b443cf155229b719bcbf8b343092
-** IV (hex) : 974ba77900c43c463dadaa6eaf24aaeb
-** CIPHERTEXT (hex): 86288c97a6341974a35015f97fbbc8db7655639c839fc438706f82fce36a82dd17e2d4d4a674516c4fc5c3a33d6097dd8fc5c6605018946741ed9f58d8fe530a808f16f0dd705cacfd273e34a158bd7566774dd31506b8280e448fabb72d0e7dfc05cee1142b61921dfaf0b0039d885cc0aa76c429025efc2ba49a8af15b58e75a5a83ba4838a9a4c9f13725f5aecefd8511513d93797f37b93150b9dca725685883188e39142dd8d3cf4b617c7936bdb3875415bbf6dfb2fe1a39ae2aed9fd2909aebd0355a5cc9a55bcb84048c851a1873948e495180f336edeb63f54bcf83feaa4d2453251260e24293e49815c2369c1c045083c412c973987fd7c9296a71cda424823ed32380ba442394500b7d2d2335818099090aaf08ca4e180869c546f58da4cb4ff0f95b796a35c40ea455e2ddd3e08bc494ffddc706aaf4d479f4f359e6a89a90df7c9b8f23cab355855a72b90795a0db83a96bce0dd4f77e3f58c0957b4ffe9663251565098e6c31fd4bbf3e1295faaff05e29912d9c37cb944da379a9b2193b466910d05a681e53a2dbe5aa18a2b4874153fe36d8a1aa4cc6e612bd6dbc9abb8e1e61b927fc5458d8e1be9536cd462e4c37672af7928c39e94bdc124a2da7b1bd3cad2cfe559adc33e62eb45bff89db8a47a72dda4f49f21c01a9432f4802a1
-** <tt>my_multisig_wallet_for_signer_2.dat</tt>: <pre>974ba77900c43c463dadaa6eaf24aaeb1b25b443cf155229b719bcbf8b34309286288c97a6341974a35015f97fbbc8db7655639c839fc438706f82fce36a82dd17e2d4d4a674516c4fc5c3a33d6097dd8fc5c6605018946741ed9f58d8fe530a808f16f0dd705cacfd273e34a158bd7566774dd31506b8280e448fabb72d0e7dfc05cee1142b61921dfaf0b0039d885cc0aa76c429025efc2ba49a8af15b58e75a5a83ba4838a9a4c9f13725f5aecefd8511513d93797f37b93150b9dca725685883188e39142dd8d3cf4b617c7936bdb3875415bbf6dfb2fe1a39ae2aed9fd2909aebd0355a5cc9a55bcb84048c851a1873948e495180f336edeb63f54bcf83feaa4d2453251260e24293e49815c2369c1c045083c412c973987fd7c9296a71cda424823ed32380ba442394500b7d2d2335818099090aaf08ca4e180869c546f58da4cb4ff0f95b796a35c40ea455e2ddd3e08bc494ffddc706aaf4d479f4f359e6a89a90df7c9b8f23cab355855a72b90795a0db83a96bce0dd4f77e3f58c0957b4ffe9663251565098e6c31fd4bbf3e1295faaff05e29912d9c37cb944da379a9b2193b466910d05a681e53a2dbe5aa18a2b4874153fe36d8a1aa4cc6e612bd6dbc9abb8e1e61b927fc5458d8e1be9536cd462e4c37672af7928c39e94bdc124a2da7b1bd3cad2cfe559adc33e62eb45bff89db8a47a72dda4f49f21c01a9432f4802a1</pre>
-
-* Send to Signer 3:
-** HMAC_KEY (hex): ab93ce7bf0f91c62a66d00ea9bf5e5c00b854ee2cfc2fb06f6eeff738abcdc26
-** MAC (hex): bb3c93b67d758f244de7ee73e5e61261cea6dff5b3852df8faf265cdf1c73dae
-** IV (hex) : bb3c93b67d758f244de7ee73e5e61261
-** CIPHERTEXT (hex): 7ac33bd9719a3cef6c68e09b3c9677565418933f188bbe50dc70f46329706732fe28ab230468e2a8798d3fbf641867d5b3322113204a372e7650ed06cf94d6df5cc7425b1b3a07690a32e12fd9cdad2c9f42d496c1b02215a7d8d63565aa4935bb2b087af39eebc02d4a2d30a4dbf1e72b9a0dab11473c7254ecf9065eb4f9d80a164c489d5fdae0d15d97b6100b79c3999b91341dfb4f599f738d4d631ae413c17b55daa09a67cb34b40d89c26f0e95ddfbf416033f869da32e502815d720bb342ec1c0e5c6910c598f32162016229cd37ea030b4d3b60f560105abb75531dc960ddf6830c26604c67c2da05b8adc45297dda58b2da4671104969b819cdf1c362bc20d7bdfe4a2fbdb79b4a69e285434d991c269e3d23ce3d95675a0acbec2cae04a310581148d3422c1c0a621fb6d79ecac1743b0e76837389b67cd4734ec5ab560c43a183de35fa98834e1f347a0c0c9b14273b76233f55f04553efcde873de92d766f3cdc5e56bc649bf0cc4951f051619ee9b931cd3872044b0e62ea2c2dacad978dbb8df3afa0b9386535278c295c6a30a56950e57f805770568e937ffafbadb226120991d5ec10effa9f4334800010d141a2ddddc00ac743efa821af37f69840487e4db48036c1e0730788cddbca2f68b3769ec6989d76161e6605af50651b6e86e
-** <tt>my_multisig_wallet_for_signer_3.dat</tt>: <pre>bb3c93b67d758f244de7ee73e5e61261cea6dff5b3852df8faf265cdf1c73dae7ac33bd9719a3cef6c68e09b3c9677565418933f188bbe50dc70f46329706732fe28ab230468e2a8798d3fbf641867d5b3322113204a372e7650ed06cf94d6df5cc7425b1b3a07690a32e12fd9cdad2c9f42d496c1b02215a7d8d63565aa4935bb2b087af39eebc02d4a2d30a4dbf1e72b9a0dab11473c7254ecf9065eb4f9d80a164c489d5fdae0d15d97b6100b79c3999b91341dfb4f599f738d4d631ae413c17b55daa09a67cb34b40d89c26f0e95ddfbf416033f869da32e502815d720bb342ec1c0e5c6910c598f32162016229cd37ea030b4d3b60f560105abb75531dc960ddf6830c26604c67c2da05b8adc45297dda58b2da4671104969b819cdf1c362bc20d7bdfe4a2fbdb79b4a69e285434d991c269e3d23ce3d95675a0acbec2cae04a310581148d3422c1c0a621fb6d79ecac1743b0e76837389b67cd4734ec5ab560c43a183de35fa98834e1f347a0c0c9b14273b76233f55f04553efcde873de92d766f3cdc5e56bc649bf0cc4951f051619ee9b931cd3872044b0e62ea2c2dacad978dbb8df3afa0b9386535278c295c6a30a56950e57f805770568e937ffafbadb226120991d5ec10effa9f4334800010d141a2ddddc00ac743efa821af37f69840487e4db48036c1e0730788cddbca2f68b3769ec6989d76161e6605af50651b6e86e</pre>
-
-==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
-
-- 
cgit v1.2.3


From 76c103a0effd73a0cbe2f35debb6f5501328af1b Mon Sep 17 00:00:00 2001
From: Hugo Nguyen <hugh.hn@gmail.com>
Date: Fri, 14 May 2021 18:38:11 -0700
Subject: Fix email format

---
 bip-0129.mediawiki | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/bip-0129.mediawiki b/bip-0129.mediawiki
index a5cf62a..60b8dc7 100644
--- a/bip-0129.mediawiki
+++ b/bip-0129.mediawiki
@@ -2,11 +2,11 @@
   BIP: 129
   Layer: Applications
   Title: Bitcoin Secure Multisig Setup (BSMS)
-  Author: Hugo Nguyen <hugo at nunchuk.io>
-          Peter Gray <peter at coinkite.com>
-          Marko Bencun <marko at shiftcrypto.ch>
-          Aaron Chen <aarondongchen at gmail.com>
-          Rodolfo Novak <rodolfo at coinkite.com>
+  Author: Hugo Nguyen <hugo@nunchuk.io>
+          Peter Gray <peter@coinkite.com>
+          Marko Bencun <marko@shiftcrypto.ch>
+          Aaron Chen <aarondongchen@gmail.com>
+          Rodolfo Novak <rodolfo@coinkite.com>
   Comments-Summary: No comments yet.
   Comments-URI:
   Status: Proposed
-- 
cgit v1.2.3


From c9249b230b43e572dd29a29c43216ef805f6943e Mon Sep 17 00:00:00 2001
From: Hugo Nguyen <hugh.hn@gmail.com>
Date: Fri, 14 May 2021 18:43:50 -0700
Subject: update URI

---
 bip-0129.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-0129.mediawiki b/bip-0129.mediawiki
index 60b8dc7..8719fe4 100644
--- a/bip-0129.mediawiki
+++ b/bip-0129.mediawiki
@@ -8,7 +8,7 @@
           Aaron Chen <aarondongchen@gmail.com>
           Rodolfo Novak <rodolfo@coinkite.com>
   Comments-Summary: No comments yet.
-  Comments-URI:
+  Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0129
   Status: Proposed
   Type: Standards Track
   Created: 2020-11-10
-- 
cgit v1.2.3


From cd223ea64aa9305e5cca214a71e3972813b70de6 Mon Sep 17 00:00:00 2001
From: Robert Spigler <RobertSpigler@ProtonMail.ch>
Date: Fri, 14 May 2021 23:36:00 -0400
Subject: BIP 87 assigned

---
 ... Deterministic Multisignature Wallets.mediawiki | 273 +++++++++++++++++++++
 ... Deterministic Multisignature Wallets.mediawiki | 273 ---------------------
 2 files changed, 273 insertions(+), 273 deletions(-)
 create mode 100644 BIP 87: Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki
 delete mode 100644 Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki

diff --git a/BIP 87: Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki b/BIP 87: Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki
new file mode 100644
index 0000000..f9be499
--- /dev/null
+++ b/BIP 87: Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki	
@@ -0,0 +1,273 @@
+<pre>
+  BIP: 87
+  Layer: Applications
+  Title: Modern Hierarchy for Deterministic Multisignature Wallets
+  Author: Robert Spigler <RobertSpigler@ProtonMail.ch>
+  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
+</pre>
+
+==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:
+
+<pre>
+m / purpose' / coin_type' / account' / change / address_index
+</pre>
+
+where the BIP43 <code>purpose'</code> 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:
+
+<pre>
+m / purpose' / cosigner_index / change / address_index
+</pre>
+
+BIP45 unecessarily demands a single script type (here, P2SH).  In addition, BIP45 sets <code>cosigner_index</code> in order to sort the <code>purpose'</code> public keys of each cosigner.  This too is redundant, as descriptors can set the order of the public keys with <code>multi</code> or have them sorted lexicographically (as described in [https://github.com/bitcoin/bips/blob/master/bip-0067.mediawiki BIP67]) with <code>sortedmulti</code>.  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:
+
+<pre>
+m / purpose' / coin_type' / account' / script_type' / change / address_index
+</pre>
+
+Rather than following in BIP 44/49/84's path and having a separate BIP per script after P2SH (BIP45), vendors decided to insert <code>script_type'</code> 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, <code>script_type</code> 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 <ref>'''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.</ref>.
+
+This paper was inspired from BIP44.
+
+==Specification==
+
+===Key sorting===
+
+Any wallet that supports descriptors inherently supports deterministic key sorting as per BIP67 (through the <code>sortedmulti</code> 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:
+
+<pre>
+m / purpose' / coin_type' / account' / change / address_index
+</pre>
+
+<code>h</code> or <code>'</code> 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 XY' 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 <code>0</code> for mainnet and <code>1</code> 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 <code>0</code> 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 <code>account'</code> level.
+This prevents key reuse - across ECDSA and Schnorr signatures, across different script types, and inbetween the same wallet types.
+
+===Change===
+
+Constant <code>0</code> is used for external chain and constant <code>1</code> 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 <code>0</code> 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 BIP__ (Bitcoin Secure Multisig Setup) for an introduction on descriptor templates.  [Waiting for merge of BSMS to link here].  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:
+
+<code>wsh(sortedmulti(2,[xfpForA/XY'/0'/0']XpubA/**,[xfpForB/XY'/0'/0']XpubB/**))</code>
+
+<code>/0/*,/1/*</code>
+
+Expands to the two concrete descriptors:
+
+<code>wsh(sortedmulti(2,[xfpForA/XY'/0'/0']XpubA/0/*,[xfpForB/XY'/0'/0']XpubB/0/*))</code>
+
+<code>wsh(sortedmulti(2,[xfpForA/XY'/0'/0']XpubA/1/*,[xfpForB/XY'/0'/0']XpubB/1/*))</code>
+
+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 <code>M</code> seeds in any <code>M</code> of <code>N</code> multisig restore operation. The descriptor provides this information in a standardized format, with key origin information and error detection.
+
+==Rationale==
+
+<references/>
+
+==Examples==
+
+{|
+|network
+|account
+|chain
+|address
+|path
+|-
+|mainnet
+|first
+|external
+|first
+|m / XY' / 0' / 0' / 0 / 0
+|-
+|mainnet
+|first
+|external
+|second
+|m / XY' / 0' / 0' / 0 / 1
+|-
+|mainnet
+|first
+|change
+|first
+|m / XY' / 0' / 0' / 1 / 0
+|-
+|mainnet
+|first
+|change
+|second
+|m / XY' / 0' / 0' / 1 / 1
+|-
+|mainnet
+|second
+|external
+|first
+|m / XY' / 0' / 1' / 0 / 0
+|-
+|mainnet
+|second
+|external
+|second
+|m / XY' / 0' / 1' / 0 / 1
+|-
+|testnet
+|first
+|external
+|first
+|m / XY' / 1' / 0' / 0 / 0
+|-
+|testnet
+|first
+|external
+|second
+|m / XY' / 1' / 0' / 0 / 1
+|-
+|testnet
+|first
+|change
+|first
+|m / XY' / 1' / 0' / 1 / 0
+|-
+|testnet
+|first
+|change
+|second
+|m / XY' / 1' / 0' / 1 / 1
+|-
+|testnet
+|second
+|external
+|first
+|m / XY' / 1' / 1' / 0 / 0
+|-
+|testnet
+|second
+|external
+|second
+|m / XY' / 1' / 1' / 0 / 1
+|-
+|testnet
+|second
+|change
+|first
+|m / XY' / 1' / 1' / 1 / 0
+|-
+|testnet
+|second
+|change
+|second
+|m / XY' / 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
+
+* [[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]]
+* [https://github.com/bitcoin/bitcoin/blob/master/doc/descriptors.md Output Descriptors]
+* [[bip-0174.mediawiki|BIP174 - Partially Signed Bitcoin Transaction Format]]
+* [[bip-0067.mediawiki|BIP67 - Deterministic Pay-to-script-hash multi-signature addresses through public key sorting]]
+* Bitcoin Secure Multisig Setup [Waiting For Merge]
diff --git a/Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki b/Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki
deleted file mode 100644
index 88dd46f..0000000
--- a/Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki	
+++ /dev/null
@@ -1,273 +0,0 @@
-<pre>
-  BIP: Number not assigned
-  Layer: Applications
-  Title: Modern Hierarchy for Deterministic Multisignature Wallets
-  Author: Robert Spigler <RobertSpigler@ProtonMail.ch>
-  Comments-Summary: No comments
-  Comments-URI:
-  Status: Proposed
-  Type: Standards Track
-  Created: 2020-03-11
-  License: BSD-2-Clause
-</pre>
-
-==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:
-
-<pre>
-m / purpose' / coin_type' / account' / change / address_index
-</pre>
-
-where the BIP43 <code>purpose'</code> 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:
-
-<pre>
-m / purpose' / cosigner_index / change / address_index
-</pre>
-
-BIP45 unecessarily demands a single script type (here, P2SH).  In addition, BIP45 sets <code>cosigner_index</code> in order to sort the <code>purpose'</code> public keys of each cosigner.  This too is redundant, as descriptors can set the order of the public keys with <code>multi</code> or have them sorted lexicographically (as described in [https://github.com/bitcoin/bips/blob/master/bip-0067.mediawiki BIP67]) with <code>sortedmulti</code>.  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:
-
-<pre>
-m / purpose' / coin_type' / account' / script_type' / change / address_index
-</pre>
-
-Rather than following in BIP 44/49/84's path and having a separate BIP per script after P2SH (BIP45), vendors decided to insert <code>script_type'</code> 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, <code>script_type</code> 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 <ref>'''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.</ref>.
-
-This paper was inspired from BIP44.
-
-==Specification==
-
-===Key sorting===
-
-Any wallet that supports descriptors inherently supports deterministic key sorting as per BIP67 (through the <code>sortedmulti</code> 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:
-
-<pre>
-m / purpose' / coin_type' / account' / change / address_index
-</pre>
-
-<code>h</code> or <code>'</code> 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 XY' 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 <code>0</code> for mainnet and <code>1</code> 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 <code>0</code> 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 <code>account'</code> level.
-This prevents key reuse - across ECDSA and Schnorr signatures, across different script types, and inbetween the same wallet types.
-
-===Change===
-
-Constant <code>0</code> is used for external chain and constant <code>1</code> 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 <code>0</code> 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 BIP__ (Bitcoin Secure Multisig Setup) for an introduction on descriptor templates.  [Waiting for merge of BSMS to link here].  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:
-
-<code>wsh(sortedmulti(2,[xfpForA/XY'/0'/0']XpubA/**,[xfpForB/XY'/0'/0']XpubB/**))</code>
-
-<code>/0/*,/1/*</code>
-
-Expands to the two concrete descriptors:
-
-<code>wsh(sortedmulti(2,[xfpForA/XY'/0'/0']XpubA/0/*,[xfpForB/XY'/0'/0']XpubB/0/*))</code>
-
-<code>wsh(sortedmulti(2,[xfpForA/XY'/0'/0']XpubA/1/*,[xfpForB/XY'/0'/0']XpubB/1/*))</code>
-
-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 <code>M</code> seeds in any <code>M</code> of <code>N</code> multisig restore operation. The descriptor provides this information in a standardized format, with key origin information and error detection.
-
-==Rationale==
-
-<references/>
-
-==Examples==
-
-{|
-|network
-|account
-|chain
-|address
-|path
-|-
-|mainnet
-|first
-|external
-|first
-|m / XY' / 0' / 0' / 0 / 0
-|-
-|mainnet
-|first
-|external
-|second
-|m / XY' / 0' / 0' / 0 / 1
-|-
-|mainnet
-|first
-|change
-|first
-|m / XY' / 0' / 0' / 1 / 0
-|-
-|mainnet
-|first
-|change
-|second
-|m / XY' / 0' / 0' / 1 / 1
-|-
-|mainnet
-|second
-|external
-|first
-|m / XY' / 0' / 1' / 0 / 0
-|-
-|mainnet
-|second
-|external
-|second
-|m / XY' / 0' / 1' / 0 / 1
-|-
-|testnet
-|first
-|external
-|first
-|m / XY' / 1' / 0' / 0 / 0
-|-
-|testnet
-|first
-|external
-|second
-|m / XY' / 1' / 0' / 0 / 1
-|-
-|testnet
-|first
-|change
-|first
-|m / XY' / 1' / 0' / 1 / 0
-|-
-|testnet
-|first
-|change
-|second
-|m / XY' / 1' / 0' / 1 / 1
-|-
-|testnet
-|second
-|external
-|first
-|m / XY' / 1' / 1' / 0 / 0
-|-
-|testnet
-|second
-|external
-|second
-|m / XY' / 1' / 1' / 0 / 1
-|-
-|testnet
-|second
-|change
-|first
-|m / XY' / 1' / 1' / 1 / 0
-|-
-|testnet
-|second
-|change
-|second
-|m / XY' / 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
-
-* [[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]]
-* [https://github.com/bitcoin/bitcoin/blob/master/doc/descriptors.md Output Descriptors]
-* [[bip-0174.mediawiki|BIP174 - Partially Signed Bitcoin Transaction Format]]
-* [[bip-0067.mediawiki|BIP67 - Deterministic Pay-to-script-hash multi-signature addresses through public key sorting]]
-* Bitcoin Secure Multisig Setup [Waiting For Merge]
-- 
cgit v1.2.3


From 10e4bc6668ec4fdc0e6959da043b0f8e354c4da7 Mon Sep 17 00:00:00 2001
From: Robert Spigler <RobertSpigler@ProtonMail.ch>
Date: Fri, 14 May 2021 23:49:08 -0400
Subject: Update README.mediawiki

---
 README.mediawiki | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/README.mediawiki b/README.mediawiki
index 5ab7499..34cf740 100644
--- a/README.mediawiki
+++ b/README.mediawiki
@@ -435,6 +435,13 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Informational
 | Draft
 |- style="background-color: #cfffcf"
+| [[bip-0087.mediawiki|87]]
+| Applications
+| Modern Hierarchy for Deterministic Multisignature Wallets
+| Robert Spigler
+| Standard
+| Proposed
+|-
 | [[bip-0090.mediawiki|90]]
 |
 | Buried Deployments
-- 
cgit v1.2.3


From 7e10290920a8e609f1fed52b1c953a8fe7e6ad41 Mon Sep 17 00:00:00 2001
From: Robert Spigler <RobertSpigler@ProtonMail.ch>
Date: Fri, 14 May 2021 23:55:43 -0400
Subject: Rename BIP 87: Modern Hierarchy for Deterministic Multisignature
 Wallets.mediawiki to bip-0087.mediawiki

---
 ... Deterministic Multisignature Wallets.mediawiki | 273 ---------------------
 bip-0087.mediawiki                                 | 273 +++++++++++++++++++++
 2 files changed, 273 insertions(+), 273 deletions(-)
 delete mode 100644 BIP 87: Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki
 create mode 100644 bip-0087.mediawiki

diff --git a/BIP 87: Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki b/BIP 87: Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki
deleted file mode 100644
index f9be499..0000000
--- a/BIP 87: Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki	
+++ /dev/null
@@ -1,273 +0,0 @@
-<pre>
-  BIP: 87
-  Layer: Applications
-  Title: Modern Hierarchy for Deterministic Multisignature Wallets
-  Author: Robert Spigler <RobertSpigler@ProtonMail.ch>
-  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
-</pre>
-
-==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:
-
-<pre>
-m / purpose' / coin_type' / account' / change / address_index
-</pre>
-
-where the BIP43 <code>purpose'</code> 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:
-
-<pre>
-m / purpose' / cosigner_index / change / address_index
-</pre>
-
-BIP45 unecessarily demands a single script type (here, P2SH).  In addition, BIP45 sets <code>cosigner_index</code> in order to sort the <code>purpose'</code> public keys of each cosigner.  This too is redundant, as descriptors can set the order of the public keys with <code>multi</code> or have them sorted lexicographically (as described in [https://github.com/bitcoin/bips/blob/master/bip-0067.mediawiki BIP67]) with <code>sortedmulti</code>.  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:
-
-<pre>
-m / purpose' / coin_type' / account' / script_type' / change / address_index
-</pre>
-
-Rather than following in BIP 44/49/84's path and having a separate BIP per script after P2SH (BIP45), vendors decided to insert <code>script_type'</code> 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, <code>script_type</code> 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 <ref>'''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.</ref>.
-
-This paper was inspired from BIP44.
-
-==Specification==
-
-===Key sorting===
-
-Any wallet that supports descriptors inherently supports deterministic key sorting as per BIP67 (through the <code>sortedmulti</code> 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:
-
-<pre>
-m / purpose' / coin_type' / account' / change / address_index
-</pre>
-
-<code>h</code> or <code>'</code> 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 XY' 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 <code>0</code> for mainnet and <code>1</code> 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 <code>0</code> 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 <code>account'</code> level.
-This prevents key reuse - across ECDSA and Schnorr signatures, across different script types, and inbetween the same wallet types.
-
-===Change===
-
-Constant <code>0</code> is used for external chain and constant <code>1</code> 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 <code>0</code> 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 BIP__ (Bitcoin Secure Multisig Setup) for an introduction on descriptor templates.  [Waiting for merge of BSMS to link here].  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:
-
-<code>wsh(sortedmulti(2,[xfpForA/XY'/0'/0']XpubA/**,[xfpForB/XY'/0'/0']XpubB/**))</code>
-
-<code>/0/*,/1/*</code>
-
-Expands to the two concrete descriptors:
-
-<code>wsh(sortedmulti(2,[xfpForA/XY'/0'/0']XpubA/0/*,[xfpForB/XY'/0'/0']XpubB/0/*))</code>
-
-<code>wsh(sortedmulti(2,[xfpForA/XY'/0'/0']XpubA/1/*,[xfpForB/XY'/0'/0']XpubB/1/*))</code>
-
-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 <code>M</code> seeds in any <code>M</code> of <code>N</code> multisig restore operation. The descriptor provides this information in a standardized format, with key origin information and error detection.
-
-==Rationale==
-
-<references/>
-
-==Examples==
-
-{|
-|network
-|account
-|chain
-|address
-|path
-|-
-|mainnet
-|first
-|external
-|first
-|m / XY' / 0' / 0' / 0 / 0
-|-
-|mainnet
-|first
-|external
-|second
-|m / XY' / 0' / 0' / 0 / 1
-|-
-|mainnet
-|first
-|change
-|first
-|m / XY' / 0' / 0' / 1 / 0
-|-
-|mainnet
-|first
-|change
-|second
-|m / XY' / 0' / 0' / 1 / 1
-|-
-|mainnet
-|second
-|external
-|first
-|m / XY' / 0' / 1' / 0 / 0
-|-
-|mainnet
-|second
-|external
-|second
-|m / XY' / 0' / 1' / 0 / 1
-|-
-|testnet
-|first
-|external
-|first
-|m / XY' / 1' / 0' / 0 / 0
-|-
-|testnet
-|first
-|external
-|second
-|m / XY' / 1' / 0' / 0 / 1
-|-
-|testnet
-|first
-|change
-|first
-|m / XY' / 1' / 0' / 1 / 0
-|-
-|testnet
-|first
-|change
-|second
-|m / XY' / 1' / 0' / 1 / 1
-|-
-|testnet
-|second
-|external
-|first
-|m / XY' / 1' / 1' / 0 / 0
-|-
-|testnet
-|second
-|external
-|second
-|m / XY' / 1' / 1' / 0 / 1
-|-
-|testnet
-|second
-|change
-|first
-|m / XY' / 1' / 1' / 1 / 0
-|-
-|testnet
-|second
-|change
-|second
-|m / XY' / 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
-
-* [[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]]
-* [https://github.com/bitcoin/bitcoin/blob/master/doc/descriptors.md Output Descriptors]
-* [[bip-0174.mediawiki|BIP174 - Partially Signed Bitcoin Transaction Format]]
-* [[bip-0067.mediawiki|BIP67 - Deterministic Pay-to-script-hash multi-signature addresses through public key sorting]]
-* Bitcoin Secure Multisig Setup [Waiting For Merge]
diff --git a/bip-0087.mediawiki b/bip-0087.mediawiki
new file mode 100644
index 0000000..f9be499
--- /dev/null
+++ b/bip-0087.mediawiki
@@ -0,0 +1,273 @@
+<pre>
+  BIP: 87
+  Layer: Applications
+  Title: Modern Hierarchy for Deterministic Multisignature Wallets
+  Author: Robert Spigler <RobertSpigler@ProtonMail.ch>
+  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
+</pre>
+
+==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:
+
+<pre>
+m / purpose' / coin_type' / account' / change / address_index
+</pre>
+
+where the BIP43 <code>purpose'</code> 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:
+
+<pre>
+m / purpose' / cosigner_index / change / address_index
+</pre>
+
+BIP45 unecessarily demands a single script type (here, P2SH).  In addition, BIP45 sets <code>cosigner_index</code> in order to sort the <code>purpose'</code> public keys of each cosigner.  This too is redundant, as descriptors can set the order of the public keys with <code>multi</code> or have them sorted lexicographically (as described in [https://github.com/bitcoin/bips/blob/master/bip-0067.mediawiki BIP67]) with <code>sortedmulti</code>.  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:
+
+<pre>
+m / purpose' / coin_type' / account' / script_type' / change / address_index
+</pre>
+
+Rather than following in BIP 44/49/84's path and having a separate BIP per script after P2SH (BIP45), vendors decided to insert <code>script_type'</code> 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, <code>script_type</code> 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 <ref>'''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.</ref>.
+
+This paper was inspired from BIP44.
+
+==Specification==
+
+===Key sorting===
+
+Any wallet that supports descriptors inherently supports deterministic key sorting as per BIP67 (through the <code>sortedmulti</code> 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:
+
+<pre>
+m / purpose' / coin_type' / account' / change / address_index
+</pre>
+
+<code>h</code> or <code>'</code> 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 XY' 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 <code>0</code> for mainnet and <code>1</code> 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 <code>0</code> 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 <code>account'</code> level.
+This prevents key reuse - across ECDSA and Schnorr signatures, across different script types, and inbetween the same wallet types.
+
+===Change===
+
+Constant <code>0</code> is used for external chain and constant <code>1</code> 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 <code>0</code> 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 BIP__ (Bitcoin Secure Multisig Setup) for an introduction on descriptor templates.  [Waiting for merge of BSMS to link here].  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:
+
+<code>wsh(sortedmulti(2,[xfpForA/XY'/0'/0']XpubA/**,[xfpForB/XY'/0'/0']XpubB/**))</code>
+
+<code>/0/*,/1/*</code>
+
+Expands to the two concrete descriptors:
+
+<code>wsh(sortedmulti(2,[xfpForA/XY'/0'/0']XpubA/0/*,[xfpForB/XY'/0'/0']XpubB/0/*))</code>
+
+<code>wsh(sortedmulti(2,[xfpForA/XY'/0'/0']XpubA/1/*,[xfpForB/XY'/0'/0']XpubB/1/*))</code>
+
+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 <code>M</code> seeds in any <code>M</code> of <code>N</code> multisig restore operation. The descriptor provides this information in a standardized format, with key origin information and error detection.
+
+==Rationale==
+
+<references/>
+
+==Examples==
+
+{|
+|network
+|account
+|chain
+|address
+|path
+|-
+|mainnet
+|first
+|external
+|first
+|m / XY' / 0' / 0' / 0 / 0
+|-
+|mainnet
+|first
+|external
+|second
+|m / XY' / 0' / 0' / 0 / 1
+|-
+|mainnet
+|first
+|change
+|first
+|m / XY' / 0' / 0' / 1 / 0
+|-
+|mainnet
+|first
+|change
+|second
+|m / XY' / 0' / 0' / 1 / 1
+|-
+|mainnet
+|second
+|external
+|first
+|m / XY' / 0' / 1' / 0 / 0
+|-
+|mainnet
+|second
+|external
+|second
+|m / XY' / 0' / 1' / 0 / 1
+|-
+|testnet
+|first
+|external
+|first
+|m / XY' / 1' / 0' / 0 / 0
+|-
+|testnet
+|first
+|external
+|second
+|m / XY' / 1' / 0' / 0 / 1
+|-
+|testnet
+|first
+|change
+|first
+|m / XY' / 1' / 0' / 1 / 0
+|-
+|testnet
+|first
+|change
+|second
+|m / XY' / 1' / 0' / 1 / 1
+|-
+|testnet
+|second
+|external
+|first
+|m / XY' / 1' / 1' / 0 / 0
+|-
+|testnet
+|second
+|external
+|second
+|m / XY' / 1' / 1' / 0 / 1
+|-
+|testnet
+|second
+|change
+|first
+|m / XY' / 1' / 1' / 1 / 0
+|-
+|testnet
+|second
+|change
+|second
+|m / XY' / 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
+
+* [[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]]
+* [https://github.com/bitcoin/bitcoin/blob/master/doc/descriptors.md Output Descriptors]
+* [[bip-0174.mediawiki|BIP174 - Partially Signed Bitcoin Transaction Format]]
+* [[bip-0067.mediawiki|BIP67 - Deterministic Pay-to-script-hash multi-signature addresses through public key sorting]]
+* Bitcoin Secure Multisig Setup [Waiting For Merge]
-- 
cgit v1.2.3


From 9c40c18dbe8e01da8a9f1786fe845f5aed70fa06 Mon Sep 17 00:00:00 2001
From: Robert Spigler <RobertSpigler@ProtonMail.ch>
Date: Sat, 15 May 2021 00:55:41 -0400
Subject: Link to merged BSMS, update examples

---
 bip-0087.mediawiki | 33 +++++++++++++++++----------------
 1 file changed, 17 insertions(+), 16 deletions(-)

diff --git a/bip-0087.mediawiki b/bip-0087.mediawiki
index f9be499..53f2849 100644
--- a/bip-0087.mediawiki
+++ b/bip-0087.mediawiki
@@ -1,7 +1,7 @@
 <pre>
   BIP: 87
   Layer: Applications
-  Title: Modern Hierarchy for Deterministic Multisignature Wallets
+  Title: Hierarchy for Deterministic Multisig Wallets
   Author: Robert Spigler <RobertSpigler@ProtonMail.ch>
   Comments-Summary: No comments yet.
   Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0087
@@ -124,7 +124,8 @@ Public derivation is used at this level.
 
 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 BIP__ (Bitcoin Secure Multisig Setup) for an introduction on descriptor templates.  [Waiting for merge of BSMS to link here].  The descriptor or descriptor template should contain the key origin information for maximum compatibility with BIP-0174.
+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:
 
@@ -171,43 +172,43 @@ As wallets complying with this BIP are descriptor wallets, this therefore necess
 |first
 |external
 |first
-|m / XY' / 0' / 0' / 0 / 0
+|m / 87' / 0' / 0' / 0 / 0
 |-
 |mainnet
 |first
 |external
 |second
-|m / XY' / 0' / 0' / 0 / 1
+|m / 87' / 0' / 0' / 0 / 1
 |-
 |mainnet
 |first
 |change
 |first
-|m / XY' / 0' / 0' / 1 / 0
+|m / 87' / 0' / 0' / 1 / 0
 |-
 |mainnet
 |first
 |change
 |second
-|m / XY' / 0' / 0' / 1 / 1
+|m / 87' / 0' / 0' / 1 / 1
 |-
 |mainnet
 |second
 |external
 |first
-|m / XY' / 0' / 1' / 0 / 0
+|m / 87' / 0' / 1' / 0 / 0
 |-
 |mainnet
 |second
 |external
 |second
-|m / XY' / 0' / 1' / 0 / 1
+|m / 87' / 0' / 1' / 0 / 1
 |-
 |testnet
 |first
 |external
 |first
-|m / XY' / 1' / 0' / 0 / 0
+|m / 87' / 1' / 0' / 0 / 0
 |-
 |testnet
 |first
@@ -219,37 +220,37 @@ As wallets complying with this BIP are descriptor wallets, this therefore necess
 |first
 |change
 |first
-|m / XY' / 1' / 0' / 1 / 0
+|m / 87' / 1' / 0' / 1 / 0
 |-
 |testnet
 |first
 |change
 |second
-|m / XY' / 1' / 0' / 1 / 1
+|m / 87' / 1' / 0' / 1 / 1
 |-
 |testnet
 |second
 |external
 |first
-|m / XY' / 1' / 1' / 0 / 0
+|m / 87' / 1' / 1' / 0 / 0
 |-
 |testnet
 |second
 |external
 |second
-|m / XY' / 1' / 1' / 0 / 1
+|m / 87' / 1' / 1' / 0 / 1
 |-
 |testnet
 |second
 |change
 |first
-|m / XY' / 1' / 1' / 1 / 0
+|m / 87' / 1' / 1' / 1 / 0
 |-
 |testnet
 |second
 |change
 |second
-|m / XY' / 1' / 1' / 1 / 1
+|m / 87' / 1' / 1' / 1 / 1
 |}
 
 ==Reference Implementation==
@@ -270,4 +271,4 @@ Original mailing list thread: https://lists.linuxfoundation.org/pipermail/bitcoi
 * [https://github.com/bitcoin/bitcoin/blob/master/doc/descriptors.md Output Descriptors]
 * [[bip-0174.mediawiki|BIP174 - Partially Signed Bitcoin Transaction Format]]
 * [[bip-0067.mediawiki|BIP67 - Deterministic Pay-to-script-hash multi-signature addresses through public key sorting]]
-* Bitcoin Secure Multisig Setup [Waiting For Merge]
+* [[bip-0129.mediawiki|BIP129 - Bitcoin Secure Multisig Setup (BSMS)]]
-- 
cgit v1.2.3


From 7663693310cc3a42aacc8e8406480ab47cd35a62 Mon Sep 17 00:00:00 2001
From: Robert Spigler <RobertSpigler@ProtonMail.ch>
Date: Sat, 15 May 2021 00:57:54 -0400
Subject: Change name for CI

---
 README.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/README.mediawiki b/README.mediawiki
index 3d4abfe..dba93f3 100644
--- a/README.mediawiki
+++ b/README.mediawiki
@@ -437,7 +437,7 @@ Those proposing changes should consider that ultimately consent may rest with th
 |- style="background-color: #cfffcf"
 | [[bip-0087.mediawiki|87]]
 | Applications
-| Modern Hierarchy for Deterministic Multisignature Wallets
+| Hierarchy for Deterministic Multisig Wallets
 | Robert Spigler
 | Standard
 | Proposed
-- 
cgit v1.2.3


From d502f681b8f796c7c9e5523be16f855aa58797ab Mon Sep 17 00:00:00 2001
From: Robert Spigler <RobertSpigler@ProtonMail.ch>
Date: Sat, 15 May 2021 01:15:09 -0400
Subject: Minor edits and links

---
 bip-0087.mediawiki | 22 +++++++++++-----------
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/bip-0087.mediawiki b/bip-0087.mediawiki
index 53f2849..57d5efe 100644
--- a/bip-0087.mediawiki
+++ b/bip-0087.mediawiki
@@ -76,7 +76,7 @@ Each level has a special meaning, described in the chapters below.
 
 ===Purpose===
 
-Purpose is a constant set to XY' following the BIP43 recommendation.
+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.
@@ -131,15 +131,15 @@ For example:
 
 The following descriptor template and derivation path restrictions:
 
-<code>wsh(sortedmulti(2,[xfpForA/XY'/0'/0']XpubA/**,[xfpForB/XY'/0'/0']XpubB/**))</code>
+<code>wsh(sortedmulti(2,[xfpForA/87'/0'/0']XpubA/**,[xfpForB/87'/0'/0']XpubB/**))</code>
 
 <code>/0/*,/1/*</code>
 
 Expands to the two concrete descriptors:
 
-<code>wsh(sortedmulti(2,[xfpForA/XY'/0'/0']XpubA/0/*,[xfpForB/XY'/0'/0']XpubB/0/*))</code>
+<code>wsh(sortedmulti(2,[xfpForA/87'/0'/0']XpubA/0/*,[xfpForB/87'/0'/0']XpubB/0/*))</code>
 
-<code>wsh(sortedmulti(2,[xfpForA/XY'/0'/0']XpubA/1/*,[xfpForB/XY'/0'/0']XpubB/1/*))</code>
+<code>wsh(sortedmulti(2,[xfpForA/87'/0'/0']XpubA/1/*,[xfpForB/87'/0'/0']XpubB/1/*))</code>
 
 To discover addresses, import both the receiving and change descriptors; respect the gap limit described below.
 
@@ -214,7 +214,7 @@ As wallets complying with this BIP are descriptor wallets, this therefore necess
 |first
 |external
 |second
-|m / XY' / 1' / 0' / 0 / 1
+|m / 87' / 1' / 0' / 0 / 1
 |-
 |testnet
 |first
@@ -265,10 +265,10 @@ Special thanks to SomberNight, Craig Raw, David Harding, Jochen Hoenicke, Sjors
 
 Original mailing list thread: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-March/018630.html
 
-* [[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]]
+* [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]
-* [[bip-0174.mediawiki|BIP174 - Partially Signed Bitcoin Transaction Format]]
-* [[bip-0067.mediawiki|BIP67 - Deterministic Pay-to-script-hash multi-signature addresses through public key sorting]]
-* [[bip-0129.mediawiki|BIP129 - Bitcoin Secure Multisig Setup (BSMS)]]
+* [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)]
-- 
cgit v1.2.3


From 2371906f0268c4edfc9859d2204a8d2bbf1351dc Mon Sep 17 00:00:00 2001
From: Robert Spigler <RobertSpigler@ProtonMail.ch>
Date: Sat, 15 May 2021 01:22:45 -0400
Subject: Minor edit

---
 bip-0087.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-0087.mediawiki b/bip-0087.mediawiki
index 57d5efe..d270027 100644
--- a/bip-0087.mediawiki
+++ b/bip-0087.mediawiki
@@ -76,7 +76,7 @@ Each level has a special meaning, described in the chapters below.
 
 ===Purpose===
 
-Purpose is a constant set to 87' following the BIP43 recommendation.
+Purpose is a constant set to <code>87'</code> 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.
-- 
cgit v1.2.3


From 2305c5bda6a2a7cbcb948eb6c5838f39db4fe4fc Mon Sep 17 00:00:00 2001
From: Dmitry Petukhov <dp@simplexum.com>
Date: Mon, 26 Oct 2020 17:30:32 +0500
Subject: Add BIP draft for BIP32 path templates

---
 bip-path-templates.mediawiki | 213 +++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 213 insertions(+)
 create mode 100644 bip-path-templates.mediawiki

diff --git a/bip-path-templates.mediawiki b/bip-path-templates.mediawiki
new file mode 100644
index 0000000..143186e
--- /dev/null
+++ b/bip-path-templates.mediawiki
@@ -0,0 +1,213 @@
+<pre>
+  BIP: ?
+  Layer: Applications
+  Title: Templates for Hierarchical Deterministic derivation paths
+  Author: Dmitry Petukhov <dp@simplexum.com>
+  Status: Draft
+  Type: Informational
+  Created: 2020-06-23
+  License: BSD-2-Clause
+</pre>
+
+==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 <code>|</code> to denote alternative derivation indexes
+(example: <code>m/|44'|49'|84'/0'/0'</code>) or whole alternative paths (<code>m/44'/0'/0'|m/44'/1'/0'</code>).
+
+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 <code>|</code> 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")
+* The <nowiki>"["</nowiki> character, followed by a number of ''index ranges'' delimited by commas (","), followed by <nowiki>"]"</nowiki> 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.
+
+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.
+# 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, <nowiki>"[1,2,3-5]"</nowiki> is not allowed, and should be specified as <nowiki>"[1-5]"</nowiki> 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).
+
+==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).
+
+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 apporach 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)
+
+==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 any non-hardened index
+
+Its representation after parsing can be:
+    [[(2147483648, 4294967295)], [(0, 0)]]
-- 
cgit v1.2.3


From 6ffc3542f8b8a36b3452f77f67bd8e289b86772a Mon Sep 17 00:00:00 2001
From: Dmitry Petukhov <dp@simplexum.com>
Date: Tue, 11 May 2021 13:55:09 +0500
Subject: bip-path-templates: Change chars for ranges from "[]" to "{}"

---
 bip-path-templates.mediawiki | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/bip-path-templates.mediawiki b/bip-path-templates.mediawiki
index 143186e..b828a2e 100644
--- a/bip-path-templates.mediawiki
+++ b/bip-path-templates.mediawiki
@@ -98,7 +98,7 @@ Each section consists of ''index template'', optionally followed by the hardened
 Index template can be:
 
 * An integer value from 0 to 2147483647 ("Unit index template")
-* The <nowiki>"["</nowiki> character, followed by a number of ''index ranges'' delimited by commas (","), followed by <nowiki>"]"</nowiki> character ("Ranged index template")
+* The <nowiki>"{"</nowiki> character, followed by a number of ''index ranges'' delimited by commas (","), followed by <nowiki>"}"</nowiki> character ("Ranged index template")
 
 Implementations MAY limit the maximum number of index ranges within the Ranged index template.
 
@@ -129,7 +129,7 @@ It may be desireable to have fully unambiguous encoding, where for each valid pa
 
 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, <nowiki>"[1,2,3-5]"</nowiki> is not allowed, and should be specified as <nowiki>"[1-5]"</nowiki> instead. This rule might make templates less convenient for frequent edits, though.
+* 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, <nowiki>"{1,2,3-5}"</nowiki> is not allowed, and should be specified as <nowiki>"{1-5}"</nowiki> instead. This rule might make templates less convenient for frequent edits, though.
 
 * Only one type of hardened marker should be allowed (either "h" or "'").
 
@@ -193,7 +193,7 @@ At the moment, three implementations exist:
 
 ==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
+'''"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)),
@@ -202,7 +202,7 @@ Its representation after parsing can be (using Python syntax, ignoring full/part
      [(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
+'''"{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)]]
-- 
cgit v1.2.3


From c90c76bc1bd13501c2e61ece0aba5f0c904225ed Mon Sep 17 00:00:00 2001
From: Dmitry Petukhov <dp@simplexum.com>
Date: Tue, 11 May 2021 17:10:09 +0500
Subject: bip-path-templates: describe Wildcard index range

---
 bip-path-templates.mediawiki | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/bip-path-templates.mediawiki b/bip-path-templates.mediawiki
index b828a2e..9888c16 100644
--- a/bip-path-templates.mediawiki
+++ b/bip-path-templates.mediawiki
@@ -98,6 +98,7 @@ Each section consists of ''index template'', optionally followed by the hardened
 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 <nowiki>"{"</nowiki> character, followed by a number of ''index ranges'' delimited by commas (","), followed by <nowiki>"}"</nowiki> character ("Ranged index template")
 
 Implementations MAY limit the maximum number of index ranges within the Ranged index template.
@@ -113,11 +114,16 @@ For Non-unit range, value on the left side of the "-" character is the range_sta
 
 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 template that matches any value from 0 to 2147483647 MUST be specified as Wildcard index template
 # 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).
-- 
cgit v1.2.3


From 25f8c3e69477bd330e5ed01a3bfa9ce29abef4b7 Mon Sep 17 00:00:00 2001
From: Dmitry Petukhov <dp@simplexum.com>
Date: Tue, 11 May 2021 17:51:24 +0500
Subject: bip-path-templates: Add Compatibility section

---
 bip-path-templates.mediawiki | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/bip-path-templates.mediawiki b/bip-path-templates.mediawiki
index 9888c16..82a7e6a 100644
--- a/bip-path-templates.mediawiki
+++ b/bip-path-templates.mediawiki
@@ -197,6 +197,14 @@ At the moment, three implementations exist:
 * 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
-- 
cgit v1.2.3


From 3d9a359d1de6232975042f0a5a5c99f2fc112a6b Mon Sep 17 00:00:00 2001
From: Dmitry Petukhov <dp@simplexum.com>
Date: Sat, 15 May 2021 11:18:16 +0500
Subject: BIP88: number assigned, rename file and update README

---
 README.mediawiki             |   7 ++
 bip-0088.mediawiki           | 229 +++++++++++++++++++++++++++++++++++++++++++
 bip-path-templates.mediawiki | 227 ------------------------------------------
 3 files changed, 236 insertions(+), 227 deletions(-)
 create mode 100644 bip-0088.mediawiki
 delete mode 100644 bip-path-templates.mediawiki

diff --git a/README.mediawiki b/README.mediawiki
index 182db6a..9f5cc58 100644
--- a/README.mediawiki
+++ b/README.mediawiki
@@ -434,6 +434,13 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Ethan Kosakovsky
 | Informational
 | Draft
+|- style="background-color: #ffffcf"
+| [[bip-0088.mediawiki|88]]
+| Applications
+| Hierarchical Deterministic Path Templates
+| Dmitry Petukhov
+| Informational
+| Proposed
 |- style="background-color: #cfffcf"
 | [[bip-0090.mediawiki|90]]
 |
diff --git a/bip-0088.mediawiki b/bip-0088.mediawiki
new file mode 100644
index 0000000..2ddd7e2
--- /dev/null
+++ b/bip-0088.mediawiki
@@ -0,0 +1,229 @@
+<pre>
+  BIP: 88
+  Layer: Applications
+  Title: Hierarchical Deterministic Path Templates
+  Author: Dmitry Petukhov <dp@simplexum.com>
+  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
+</pre>
+
+==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 <code>|</code> to denote alternative derivation indexes
+(example: <code>m/|44'|49'|84'/0'/0'</code>) or whole alternative paths (<code>m/44'/0'/0'|m/44'/1'/0'</code>).
+
+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 <code>|</code> 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 <nowiki>"{"</nowiki> character, followed by a number of ''index ranges'' delimited by commas (","), followed by <nowiki>"}"</nowiki> 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 template that matches any value from 0 to 2147483647 MUST be specified as Wildcard index template
+# 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, <nowiki>"{1,2,3-5}"</nowiki> is not allowed, and should be specified as <nowiki>"{1-5}"</nowiki> 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).
+
+==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).
+
+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 apporach 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 any non-hardened index
+
+Its representation after parsing can be:
+    [[(2147483648, 4294967295)], [(0, 0)]]
diff --git a/bip-path-templates.mediawiki b/bip-path-templates.mediawiki
deleted file mode 100644
index 82a7e6a..0000000
--- a/bip-path-templates.mediawiki
+++ /dev/null
@@ -1,227 +0,0 @@
-<pre>
-  BIP: ?
-  Layer: Applications
-  Title: Templates for Hierarchical Deterministic derivation paths
-  Author: Dmitry Petukhov <dp@simplexum.com>
-  Status: Draft
-  Type: Informational
-  Created: 2020-06-23
-  License: BSD-2-Clause
-</pre>
-
-==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 <code>|</code> to denote alternative derivation indexes
-(example: <code>m/|44'|49'|84'/0'/0'</code>) or whole alternative paths (<code>m/44'/0'/0'|m/44'/1'/0'</code>).
-
-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 <code>|</code> 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 <nowiki>"{"</nowiki> character, followed by a number of ''index ranges'' delimited by commas (","), followed by <nowiki>"}"</nowiki> 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 template that matches any value from 0 to 2147483647 MUST be specified as Wildcard index template
-# 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, <nowiki>"{1,2,3-5}"</nowiki> is not allowed, and should be specified as <nowiki>"{1-5}"</nowiki> 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).
-
-==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).
-
-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 apporach 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 any non-hardened index
-
-Its representation after parsing can be:
-    [[(2147483648, 4294967295)], [(0, 0)]]
-- 
cgit v1.2.3


From 01679c8f29d0454d7003805d30031623f194a93b Mon Sep 17 00:00:00 2001
From: Dmitry Petukhov <dp@simplexum.com>
Date: Sun, 16 May 2021 12:33:38 +0500
Subject: BIP88: clarifications, mistype fixes

---
 bip-0088.mediawiki | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/bip-0088.mediawiki b/bip-0088.mediawiki
index 2ddd7e2..048f2a7 100644
--- a/bip-0088.mediawiki
+++ b/bip-0088.mediawiki
@@ -91,17 +91,17 @@ installation of malicious or incorrect profiles, though.
 
 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 ("/").
+Template starts with optional prefix "m/", and then one or more sections delimited by the slash character (<code>/</code>).
 
 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".
+Each section consists of ''index template'', optionally followed by the hardened marker: either an apostrophe (<code>'</code>) 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 <nowiki>"{"</nowiki> character, followed by a number of ''index ranges'' delimited by commas (","), followed by <nowiki>"}"</nowiki> character ("Ranged index template")
+* The <nowiki>"{"</nowiki> character, followed by a number of ''index ranges'' delimited by commas (<code>,</code>), followed by <nowiki>"}"</nowiki> character ("Ranged index template")
 
 Implementations MAY limit the maximum number of index ranges within the Ranged index template.
 
@@ -125,12 +125,12 @@ 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 template that matches any value from 0 to 2147483647 MUST be specified as Wildcard index template
+# To avoid ambiguity, an index range <code>0-2147483647</code> 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, if a hardened marker appears within any section in the path template, all preceding sections MUST also use the same hardened marker (either <code>h</code> or <code>'</code>).
 # 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.
@@ -139,7 +139,7 @@ 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, <nowiki>"{1,2,3-5}"</nowiki> is not allowed, and should be specified as <nowiki>"{1-5}"</nowiki> instead. This rule might make templates less convenient for frequent edits, though.
 
-* Only one type of hardened marker should be allowed (either "h" or "'").
+* Only one type of hardened marker should be allowed (either <code>h</code> or <code>'</code>).
 
 Instead of requiring the second extra rule, implementations can simply replace one type of marker with another in the template strings before comparing them.
 
@@ -191,7 +191,7 @@ The specification can be used with TLC checker and accompanying script to genera
 
 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 apporach might detect some of these errors earlier than FSM-based implementation, and vise versa.
+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:
 
-- 
cgit v1.2.3


From b628a13e2124c7f927c033f5fed81671cb559ae5 Mon Sep 17 00:00:00 2001
From: Dmitry Petukhov <dp@simplexum.com>
Date: Sun, 16 May 2021 12:41:40 +0500
Subject: BIP88: use <code> tags more, instead of double quotes

---
 bip-0088.mediawiki | 30 +++++++++++++++---------------
 1 file changed, 15 insertions(+), 15 deletions(-)

diff --git a/bip-0088.mediawiki b/bip-0088.mediawiki
index 048f2a7..ce081cc 100644
--- a/bip-0088.mediawiki
+++ b/bip-0088.mediawiki
@@ -91,17 +91,17 @@ installation of malicious or incorrect profiles, though.
 
 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 (<code>/</code>).
+Template starts with optional prefix <code>m/</code>, and then one or more sections delimited by the slash character (<code>/</code>).
 
 Implementations MAY limit the maximum number of sections.
 
-Each section consists of ''index template'', optionally followed by the hardened marker: either an apostrophe (<code>'</code>) or letter "h".
+Each section consists of ''index template'', optionally followed by the hardened marker: either an apostrophe (<code>'</code>) or letter <code>h</code>.
 
 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 <nowiki>"{"</nowiki> character, followed by a number of ''index ranges'' delimited by commas (<code>,</code>), followed by <nowiki>"}"</nowiki> character ("Ranged index template")
+* A single <code>*</code> character, which denotes any value from 0 to 2147483647 ("Wildcard index template")
+* The <code>{</code> character, followed by a number of ''index ranges'' delimited by commas (<code>,</code>), followed by <code>}</code> character ("Ranged index template")
 
 Implementations MAY limit the maximum number of index ranges within the Ranged index template.
 
@@ -110,9 +110,9 @@ If an index template is immediately followed by hardened marker, this means that
 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")
+* An integer value from 0 to 2147483647, followed by the <code>-</code> 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 Non-unit range, value on the left side of the <code>-</code> character is the range_start, and the value on the right side of the <code>-</code> 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.
 
@@ -128,16 +128,16 @@ Constraints:
 # To avoid ambiguity, an index range <code>0-2147483647</code> 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).
+# To avoid ambiguity, all representations of integer values larger than 0 MUST NOT start with character <code>0</code> (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 <code>h</code> or <code>'</code>).
-# To avoid ambiguity, trailing slashes (for example, "1/2/") and duplicate slashes (for example, "0//1") MUST NOT appear in the template.
+# To avoid ambiguity, trailing slashes (for example, <code>1/2/</code>) and duplicate slashes (for example, <code>0//1</code>) 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, <nowiki>"{1,2,3-5}"</nowiki> is not allowed, and should be specified as <nowiki>"{1-5}"</nowiki> instead. This rule might make templates less convenient for frequent edits, though.
+* 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, <code>{1,2,3-5}</code> is not allowed, and should be specified as <code>{1-5}</code> instead. This rule might make templates less convenient for frequent edits, though.
 
 * Only one type of hardened marker should be allowed (either <code>h</code> or <code>'</code>).
 
@@ -145,9 +145,9 @@ Instead of requiring the second extra rule, implementations can simply replace o
 
 ==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 starts with <code>m/</code>, 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).
+If the template does not start with <code>m/</code>, 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.
@@ -205,11 +205,11 @@ The full path template that only contains Unit index templates represents a full
 
 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.
+There is a discussion on path templating for bitcoin script descriptors at https://github.com/bitcoin/bitcoin/issues/17190, which proposes the format <code>xpub...{0,1}/*</code>, of which the <code>{0,1}/*</code> 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
+<code>m/{44,49,84}'/0'/0'/{0-1}/{0-50000}</code> 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)),
@@ -218,12 +218,12 @@ Its representation after parsing can be (using Python syntax, ignoring full/part
      [(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
+<code>{0-2,33,123}/*</code> 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 any non-hardened index
+<code>*h/0</code> specifies a partial template that matches any hardened index followed by any non-hardened index
 
 Its representation after parsing can be:
     [[(2147483648, 4294967295)], [(0, 0)]]
-- 
cgit v1.2.3


From 14f731e3d2c87cc221505750ae63cab49f293ad5 Mon Sep 17 00:00:00 2001
From: Michael Folkson <michaelfolkson@gmail.com>
Date: Mon, 17 May 2021 10:09:34 +0100
Subject: BIP 343 assigned

---
 bip-0343.mediawiki                 | 62 ++++++++++++++++++++++++++++++++++++++
 bip-mandatory-activation.mediawiki | 62 --------------------------------------
 2 files changed, 62 insertions(+), 62 deletions(-)
 create mode 100644 bip-0343.mediawiki
 delete mode 100644 bip-mandatory-activation.mediawiki

diff --git a/bip-0343.mediawiki b/bip-0343.mediawiki
new file mode 100644
index 0000000..0a9de32
--- /dev/null
+++ b/bip-0343.mediawiki
@@ -0,0 +1,62 @@
+<pre>
+BIP: 343
+Layer: Consensus (soft fork)
+Title: Mandatory activation of taproot deployment
+Author: Shinobius <quantumedusa@gmail.com> 
+        Michael Folkson <michaelfolkson@gmail.com>
+Comments-Summary: No comments yet.
+Comments-URI:
+Status: Proposed
+Type: Standards Track
+Created: 2021-04-25
+License: BSD-3-Clause
+         CC0-1.0
+</pre>
+
+==Abstract==
+
+This document specifies a BIP8 (LOT=true) deployment to activate taproot.
+
+==Motivation==
+
+The Taproot soft fork upgrade has been assessed to have overwhelming community consensus and hence should attempt to be activated. Lessons have been learned from the BIP148 and BIP91 deployments in 2017 with regards to giving many months of advance warning before the mandatory signaling is attempted. The mandatory signaling is only required if miners have failed to meet the signaling threshold during the BIP8 deployment. It is important that mandatory signaling is included as without it miners would effectively have the ability to indefinitely block the activation of a soft fork with overwhelming consensus. 
+
+==Specification==
+
+This BIP will begin an activation signaling period using bit 2 at blockheight 681408 with a minimum activation height of 709632 and an activation threshold of 90%. The signaling period will timeout at blockheight 760032 with a latest activation height of 762048. Lockinontimeout (LOT) is set to true so mandatory signaling will be enforced in the last signaling period before the timeout height. Blocks without the signaling bit 2 set run the risk of being rejected during this period if taproot is not locked in prior. This BIP will cease to be active when taproot is locked in.
+
+==Reference implementation==
+
+*[[https://github.com/BitcoinActivation/bitcoin]]
+
+==Backward Compatibility==
+
+As a soft fork, older software will continue to operate without modification. Non-upgraded nodes, however, will consider all SegWit version 1 witness programs as anyone-can-spend scripts. They are strongly encouraged to upgrade in order to fully validate the new programs.
+
+==Compatibility with later alternative activations==
+
+The activation mechanism “Speedy Trial” as proposed by Russell O’Connor and outlined in this bitcoin-dev mailing list [https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-March/018583.html post] by David Harding was released in Bitcoin Core. It is effectively a BIP8 activation mechanism with one exception: start height and timeout height were defined using median time past (MTP) rather than block heights. It uses signaling bit 2, was deployed between midnight April 24th 2021 and midnight August 11th 2021, has a minimum activation height of 709632 and intends to activate BIPs 340, 341, and 342. The BIP8(LOT=true) deployment is compatible with the “Speedy Trial” deployment in Bitcoin Core as there was not a discrepancy between MTP and block height for the defined start heights.
+
+The BIP8 (LOT=true) deployment has also been deliberately designed to be compatible with a future BIP8(LOT=false) or BIP8(LOT=true) deployment in Bitcoin Core assuming Bitcoin Core releases one of these activation mechanisms in the event of the Speedy Trial deployment failing to activate.
+
+==Rationale==
+
+The deployment of BIP148 demonstrated that multiple implementations with different activation mechanisms can incentivize the necessary actors to act so that the different deployments activate in sync. A BIP8 LOT=true deployment can run in parallel with other BIP8 activation mechanisms that have eventual mandatory signaling or no mandatory signaling. Eventual mandatory signaling ensures that miners cannot prevent the activation of a desired feature with community consensus indefinitely.
+
+==Acknowledgements==
+
+Thanks to Shaolin Fry and Luke Dashjr for their work on BIP148 and BIP8 which were important prerequisites for this proposal.
+
+==References==
+
+*[[bip-0008.mediawiki|BIP8 Version bits with lock-in by height]]
+*[[bip-0148.mediawiki|BIP148 Mandatory activation of segwit deployment]]
+*[[bip-0340.mediawiki|BIP340 Schnorr Signatures for secp256k1]]
+*[[bip-0341.mediawiki|BIP341 Taproot: SegWit version 1 spending rules]]
+*[[bip-0342.mediawiki|BIP342 Validation of Taproot Scripts]]
+*[https://taproot.works/taproot-faq/ Taproot benefits]
+
+==Copyright==
+
+This document is dual licensed as BSD 3-clause, and Creative Commons CC0 1.0 Universal.
+
diff --git a/bip-mandatory-activation.mediawiki b/bip-mandatory-activation.mediawiki
deleted file mode 100644
index 1c03159..0000000
--- a/bip-mandatory-activation.mediawiki
+++ /dev/null
@@ -1,62 +0,0 @@
-<pre>
-BIP: ???
-Layer: Consensus (soft fork)
-Title: Mandatory activation of taproot deployment
-Author: Shinobius <quantumedusa@gmail.com> 
-        Michael Folkson <michaelfolkson@gmail.com>
-Comments-Summary: No comments yet.
-Comments-URI:
-Status: Proposed
-Type: Standards Track
-Created: 2021-04-25
-License: BSD-3-Clause
-         CC0-1.0
-</pre>
-
-==Abstract==
-
-This document specifies a BIP8 (LOT=true) deployment to activate taproot.
-
-==Motivation==
-
-The Taproot soft fork upgrade has been assessed to have overwhelming community consensus and hence should attempt to be activated. Lessons have been learned from the BIP148 and BIP91 deployments in 2017 with regards to giving many months of advance warning before the mandatory signaling is attempted. The mandatory signaling is only required if miners have failed to meet the signaling threshold during the BIP8 deployment. It is important that mandatory signaling is included as without it miners would effectively have the ability to indefinitely block the activation of a soft fork with overwhelming consensus. 
-
-==Specification==
-
-This BIP will begin an activation signaling period using bit 2 at blockheight 681408 with a minimum activation height of 709632 and an activation threshold of 90%. The signaling period will timeout at blockheight 760032 with a latest activation height of 762048. Lockinontimeout (LOT) is set to true so mandatory signaling will be enforced in the last signaling period before the timeout height. Blocks without the signaling bit 2 set run the risk of being rejected during this period if taproot is not locked in prior. This BIP will cease to be active when taproot is locked in.
-
-==Reference implementation==
-
-*[[https://github.com/BitcoinActivation/bitcoin]]
-
-==Backward Compatibility==
-
-As a soft fork, older software will continue to operate without modification. Non-upgraded nodes, however, will consider all SegWit version 1 witness programs as anyone-can-spend scripts. They are strongly encouraged to upgrade in order to fully validate the new programs.
-
-==Compatibility with later alternative activations==
-
-The activation mechanism “Speedy Trial” as proposed by Russell O’Connor and outlined in this bitcoin-dev mailing list [https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-March/018583.html post] by David Harding was released in Bitcoin Core. It is effectively a BIP8 activation mechanism with one exception: start height and timeout height were defined using median time past (MTP) rather than block heights. It uses signaling bit 2, was deployed between midnight April 24th 2021 and midnight August 11th 2021, has a minimum activation height of 709632 and intends to activate BIPs 340, 341, and 342. The BIP8(LOT=true) deployment is compatible with the “Speedy Trial” deployment in Bitcoin Core as there was not a discrepancy between MTP and block height for the defined start heights.
-
-The BIP8 (LOT=true) deployment has also been deliberately designed to be compatible with a future BIP8(LOT=false) or BIP8(LOT=true) deployment in Bitcoin Core assuming Bitcoin Core releases one of these activation mechanisms in the event of the Speedy Trial deployment failing to activate.
-
-==Rationale==
-
-The deployment of BIP148 demonstrated that multiple implementations with different activation mechanisms can incentivize the necessary actors to act so that the different deployments activate in sync. A BIP8 LOT=true deployment can run in parallel with other BIP8 activation mechanisms that have eventual mandatory signaling or no mandatory signaling. Eventual mandatory signaling ensures that miners cannot prevent the activation of a desired feature with community consensus indefinitely.
-
-==Acknowledgements==
-
-Thanks to Shaolin Fry and Luke Dashjr for their work on BIP148 and BIP8 which were important prerequisites for this proposal.
-
-==References==
-
-*[[bip-0008.mediawiki|BIP8 Version bits with lock-in by height]]
-*[[bip-0148.mediawiki|BIP148 Mandatory activation of segwit deployment]]
-*[[bip-0340.mediawiki|BIP340 Schnorr Signatures for secp256k1]]
-*[[bip-0341.mediawiki|BIP341 Taproot: SegWit version 1 spending rules]]
-*[[bip-0342.mediawiki|BIP342 Validation of Taproot Scripts]]
-*[https://taproot.works/taproot-faq/ Taproot benefits]
-
-==Copyright==
-
-This document is dual licensed as BSD 3-clause, and Creative Commons CC0 1.0 Universal.
-
-- 
cgit v1.2.3


From 7bf9c1b84d2a80388b4d27a0e33e9a34184c1964 Mon Sep 17 00:00:00 2001
From: Michael Folkson <michaelfolkson@gmail.com>
Date: Mon, 17 May 2021 10:18:40 +0100
Subject: Update README

---
 README.mediawiki | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/README.mediawiki b/README.mediawiki
index 5ab7499..621d08d 100644
--- a/README.mediawiki
+++ b/README.mediawiki
@@ -988,6 +988,13 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Standard
 | Draft
 |-
+| [[bip-0343.mediawiki|343]]
+| Consensus (soft fork)
+| Mandatory activation of taproot deployment
+| Shinobius, Michael Folkson
+| Standard
+| Draft
+|-
 | [[bip-0350.mediawiki|350]]
 | Applications
 | Bech32m format for v1+ witness addresses
-- 
cgit v1.2.3


From abc113edd4bc2339c6b64689c0b33635615c297e Mon Sep 17 00:00:00 2001
From: Dmitry Petukhov <dp@simplexum.com>
Date: Mon, 17 May 2021 15:03:02 +0500
Subject: BIP88: Add definition for "length of the template", "length of the
 path"

---
 bip-0088.mediawiki | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/bip-0088.mediawiki b/bip-0088.mediawiki
index ce081cc..1f77c8e 100644
--- a/bip-0088.mediawiki
+++ b/bip-0088.mediawiki
@@ -162,11 +162,11 @@ Implementations MAY support parsing partial templates and matching portions of t
 
 ==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 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 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.
 
-- 
cgit v1.2.3


From 255b5b67c09879eb9d3e731ce45493ded9be87c9 Mon Sep 17 00:00:00 2001
From: Jonas Nick <jonasd.nick@gmail.com>
Date: Mon, 17 May 2021 14:37:12 +0000
Subject: BIP340: remove batch speedup graph and link to it instead

This avoids having to update the BIP with a fresh graph every time there's a
change to libsecp and suggests that the expected speedup depends on the specific
implementation.
---
 bip-0340.mediawiki         |   4 +---
 bip-0340/speedup-batch.png | Bin 11914 -> 0 bytes
 2 files changed, 1 insertion(+), 3 deletions(-)
 delete mode 100644 bip-0340/speedup-batch.png

diff --git a/bip-0340.mediawiki b/bip-0340.mediawiki
index 1de7faa..b5a47d3 100644
--- a/bip-0340.mediawiki
+++ b/bip-0340.mediawiki
@@ -56,9 +56,7 @@ encodings and operations.
 
 '''Schnorr signature variant''' Elliptic Curve Schnorr signatures for message ''m'' and public key ''P'' generally involve a point ''R'', integers ''e'' and ''s'' picked by the signer, and the base point ''G'' which satisfy ''e = hash(R || m)'' and ''s⋅G = R + e⋅P''. Two formulations exist, depending on whether the signer reveals ''e'' or ''R'':
 # Signatures are pairs ''(e, s)'' that satisfy ''e = hash(s⋅G - e⋅P || m)''. This variant avoids minor complexity introduced by the encoding of the point ''R'' in the signature (see paragraphs "Encoding R and public key point P" and "Implicit Y coordinates" further below in this subsection). Moreover, revealing ''e'' instead of ''R'' allows for potentially shorter signatures: Whereas an encoding of ''R'' inherently needs about 32 bytes, the hash ''e'' can be tuned to be shorter than 32 bytes, and [http://www.neven.org/papers/schnorr.pdf a short hash of only 16 bytes suffices to provide SUF-CMA security at the target security level of 128 bits]. However, a major drawback of this optimization is that finding collisions in a short hash function is easy. This complicates the implementation of secure signing protocols in scenarios in which a group of mutually distrusting signers work together to produce a single joint signature (see Applications below). In these scenarios, which are not captured by the SUF-CMA model due its assumption of a single honest signer, a promising attack strategy for malicious co-signers is to find a collision in the hash function in order to obtain a valid signature on a message that an honest co-signer did not intend to sign.
-# Signatures are pairs ''(R, s)'' that satisfy ''s⋅G = R + hash(R || m)⋅P''. This supports batch verification, as there are no elliptic curve operations inside the hashes. Batch verification enables significant speedups.
-
-[[File:bip-0340/speedup-batch.png|center|frame|This graph shows the ratio between the time it takes to verify ''n'' signatures individually and to verify a batch of ''n'' signatures. This ratio goes up logarithmically with the number of signatures, or in other words: the total time to verify ''n'' signatures grows with ''O(n / log n)''.]]
+# Signatures are pairs ''(R, s)'' that satisfy ''s⋅G = R + hash(R || m)⋅P''. This supports batch verification, as there are no elliptic curve operations inside the hashes. Batch verification enables significant speedups.<ref>The speedup that results from batch verification can be demonstrated with the cryptography library [https://github.com/jonasnick/secp256k1/blob/schnorrsig-batch-verify/doc/speedup-batch.md libsecp256k1].</ref>
 
 Since we would like to avoid the fragility that comes with short hashes, the ''e'' variant does not provide significant advantages. We choose the ''R''-option, which supports batch verification. 
 
diff --git a/bip-0340/speedup-batch.png b/bip-0340/speedup-batch.png
deleted file mode 100644
index fe672d4..0000000
Binary files a/bip-0340/speedup-batch.png and /dev/null differ
-- 
cgit v1.2.3


From eb7ab7ab414710bb8a57c78deca69cdaa51839db Mon Sep 17 00:00:00 2001
From: Luke Dashjr <luke-jr+git@utopios.org>
Date: Mon, 17 May 2021 23:28:17 +0000
Subject: README: Fix colours for BIPs 87 & 90

---
 README.mediawiki | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/README.mediawiki b/README.mediawiki
index dba93f3..a3956c0 100644
--- a/README.mediawiki
+++ b/README.mediawiki
@@ -434,14 +434,14 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Ethan Kosakovsky
 | Informational
 | Draft
-|- style="background-color: #cfffcf"
+|- style="background-color: #ffffcf"
 | [[bip-0087.mediawiki|87]]
 | Applications
 | Hierarchy for Deterministic Multisig Wallets
 | Robert Spigler
 | Standard
 | Proposed
-|-
+|- style="background-color: #cfffcf"
 | [[bip-0090.mediawiki|90]]
 |
 | Buried Deployments
-- 
cgit v1.2.3


From e7ee4fe6d51727c37e3435815b693ca5e78a42bb Mon Sep 17 00:00:00 2001
From: Luke Dashjr <luke-jr+git@utopios.org>
Date: Mon, 17 May 2021 23:33:22 +0000
Subject: Fix formatting for BIP 343

---
 README.mediawiki   |  4 ++--
 bip-0343.mediawiki | 24 ++++++++++++------------
 2 files changed, 14 insertions(+), 14 deletions(-)

diff --git a/README.mediawiki b/README.mediawiki
index 621d08d..298425e 100644
--- a/README.mediawiki
+++ b/README.mediawiki
@@ -987,13 +987,13 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Pieter Wuille, Jonas Nick, Anthony Towns
 | Standard
 | Draft
-|-
+|- style="background-color: #ffffcf"
 | [[bip-0343.mediawiki|343]]
 | Consensus (soft fork)
 | Mandatory activation of taproot deployment
 | Shinobius, Michael Folkson
 | Standard
-| Draft
+| Proposed
 |-
 | [[bip-0350.mediawiki|350]]
 | Applications
diff --git a/bip-0343.mediawiki b/bip-0343.mediawiki
index 0a9de32..3d2f392 100644
--- a/bip-0343.mediawiki
+++ b/bip-0343.mediawiki
@@ -1,16 +1,16 @@
 <pre>
-BIP: 343
-Layer: Consensus (soft fork)
-Title: Mandatory activation of taproot deployment
-Author: Shinobius <quantumedusa@gmail.com> 
-        Michael Folkson <michaelfolkson@gmail.com>
-Comments-Summary: No comments yet.
-Comments-URI:
-Status: Proposed
-Type: Standards Track
-Created: 2021-04-25
-License: BSD-3-Clause
-         CC0-1.0
+  BIP: 343
+  Layer: Consensus (soft fork)
+  Title: Mandatory activation of taproot deployment
+  Author: Shinobius <quantumedusa@gmail.com>
+          Michael Folkson <michaelfolkson@gmail.com>
+  Comments-Summary: No comments yet.
+  Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0343
+  Status: Proposed
+  Type: Standards Track
+  Created: 2021-04-25
+  License: BSD-3-Clause
+           CC0-1.0
 </pre>
 
 ==Abstract==
-- 
cgit v1.2.3


From de829ac445b21453ead0f4aadbe9c1a9148ff0eb Mon Sep 17 00:00:00 2001
From: Dmitry Petukhov <dp@simplexum.com>
Date: Tue, 18 May 2021 12:52:21 +0500
Subject: BIP88: add Acknowledgements section

---
 bip-0088.mediawiki | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/bip-0088.mediawiki b/bip-0088.mediawiki
index 1f77c8e..1e6efce 100644
--- a/bip-0088.mediawiki
+++ b/bip-0088.mediawiki
@@ -227,3 +227,7 @@ Its representation after parsing can be:
 
 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.
-- 
cgit v1.2.3


From 240de39b236e83e9e142b56847e4b00461a75d14 Mon Sep 17 00:00:00 2001
From: Dmitry Petukhov <dp@simplexum.com>
Date: Wed, 26 May 2021 17:45:01 +0500
Subject: BIP88: fix description of the "*h/0" example

---
 bip-0088.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-0088.mediawiki b/bip-0088.mediawiki
index 1f77c8e..146a22c 100644
--- a/bip-0088.mediawiki
+++ b/bip-0088.mediawiki
@@ -223,7 +223,7 @@ Its representation after parsing can be (using Python syntax, ignoring full/part
 Its representation after parsing can be:
     [[(0, 2), (33, 33), (123, 123)], [(0, 2147483647)]]
 
-<code>*h/0</code> specifies a partial template that matches any hardened index followed by any non-hardened index
+<code>*h/0</code> 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)]]
-- 
cgit v1.2.3


From 135f95ffb706855582b7293384cfbd843825ea3d Mon Sep 17 00:00:00 2001
From: "Esteban A. Maringolo" <emaringolo@gmail.com>
Date: Fri, 28 May 2021 20:20:47 -0300
Subject: Update bip-0039.mediawiki

Fixes syntax error.

Co-authored-by: Pavol Rusnak <pavol@rusnak.io>
---
 bip-0039.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-0039.mediawiki b/bip-0039.mediawiki
index 2093454..b077269 100644
--- a/bip-0039.mediawiki
+++ b/bip-0039.mediawiki
@@ -176,7 +176,7 @@ Rust:
 * https://github.com/maciejhirsz/tiny-bip39/
 * https://github.com/koushiro/bip0039-rs
 
-* Smalltalk:
+Smalltalk:
 * https://github.com/eMaringolo/pharo-bip39mnemonic
 
 Swift:
-- 
cgit v1.2.3


From cdbe675223d2324321836fa9fe9f8c6e1e0c734f Mon Sep 17 00:00:00 2001
From: Chirag Bhatia <chirag64@users.noreply.github.com>
Date: Sun, 6 Jun 2021 17:34:30 +0530
Subject: Updated URL of the JavaScript reference implementation

Old repo is archived and links to the new repo are found in the old one's README file. This change updates the old repo's link to the new one.
---
 bip-0039.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-0039.mediawiki b/bip-0039.mediawiki
index 9d38248..40288dd 100644
--- a/bip-0039.mediawiki
+++ b/bip-0039.mediawiki
@@ -163,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:
-- 
cgit v1.2.3


From 9ee97173106dfb0886e335a00df1359f6d4279c7 Mon Sep 17 00:00:00 2001
From: Tobin Harding <me@tobin.cc>
Date: Wed, 9 Jun 2021 10:15:53 +1000
Subject: Use hyperlinks when mentioning bips

When mentioning a bip we use a hyperlink to the bip file to assist
readers. There are two mentions of bips in BIP-0009 that do not use
links, probably because links where provided above in the text, however,
its a bit easier on the reader if we provide links again to save
scrolling through the document.

Use hyperlinks when mentioning BIP 34 and 141 in isolation.
---
 bip-0009.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-0009.mediawiki b/bip-0009.mediawiki
index c9fcd6f..ad11678 100644
--- a/bip-0009.mediawiki
+++ b/bip-0009.mediawiki
@@ -197,7 +197,7 @@ Miners MAY clear or set bits in the block version WITHOUT any special "mutable"
 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 [[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==
-- 
cgit v1.2.3


From f59b209b913b2b45c99436ac3bce7cd86d623000 Mon Sep 17 00:00:00 2001
From: Tobin Harding <me@tobin.cc>
Date: Wed, 9 Jun 2021 10:33:59 +1000
Subject: Fix typo, remove 'in'

Phrase 'based on in BIP 43' should probably read 'based on BIP 34'.
---
 bip-0009.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-0009.mediawiki b/bip-0009.mediawiki
index ad11678..f7fbad1 100644
--- a/bip-0009.mediawiki
+++ b/bip-0009.mediawiki
@@ -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.
-- 
cgit v1.2.3


From 4e53b6e6c4b279e76ccf107a5a315911466bda4b Mon Sep 17 00:00:00 2001
From: John Newbery <john@johnnewbery.com>
Date: Thu, 6 May 2021 21:15:19 +0100
Subject: Add Kalle Alm as BIP editor

Update language to clarify that there are multiple editors.
---
 bip-0002.mediawiki | 19 +++++++++++--------
 1 file changed, 11 insertions(+), 8 deletions(-)

diff --git a/bip-0002.mediawiki b/bip-0002.mediawiki
index 35d38c2..c6eb950 100644
--- a/bip-0002.mediawiki
+++ b/bip-0002.mediawiki
@@ -41,14 +41,14 @@ It also helps to make sure the idea is applicable to the entire community and no
 Once the champion has asked the Bitcoin community as to whether an idea has any chance of acceptance, a draft BIP should be presented to the [https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev Bitcoin development mailing list].
 This gives the author a chance to flesh out the draft BIP to make it properly formatted, of high quality, and to address additional concerns about the proposal.
 Following a discussion, the proposal should be submitted to the [https://github.com/bitcoin/bips BIPs git repository] as a pull request.
-This draft must be written in BIP style as described below, and named with an alias such as "bip-johndoe-infinitebitcoins" until the editor has assigned it a BIP number (authors MUST NOT self-assign BIP numbers).
+This draft must be written in BIP style as described below, and named with an alias such as "bip-johndoe-infinitebitcoins" until an editor has assigned it a BIP number (authors MUST NOT self-assign BIP numbers).
 
 BIP authors are responsible for collecting community feedback on both the initial idea and the BIP before submitting it for review. However, wherever possible, long open-ended discussions on public mailing lists should be avoided. Strategies to keep the discussions efficient include: setting up a separate SIG mailing list for the topic, having the BIP author accept private comments in the early design phases, setting up a wiki page or git repository, etc. BIP authors should use their discretion here.
 
 It is highly recommended that a single BIP contain a single key proposal or new idea. The more focused the BIP, the more successful it tends to be. If in doubt, split your BIP into several well-focused ones.
 
-When the BIP draft is complete, the BIP editor will assign the BIP a number, label it as Standards Track, Informational, or Process, and merge the pull request to the BIPs git repository.
-The BIP editor will not unreasonably reject a BIP.
+When the BIP draft is complete, a BIP editor will assign the BIP a number, label it as Standards Track, Informational, or Process, and merge the pull request to the BIPs git repository.
+The BIP editors will not unreasonably reject a BIP.
 Reasons for rejecting BIPs include duplication of effort, disregard for formatting rules, being too unfocused or too broad, being technically unsound, not providing proper motivation or addressing backwards compatibility, or not in keeping with the Bitcoin philosophy.
 For a BIP to be accepted it must meet certain minimum criteria.
 It must be a clear and complete description of the proposed enhancement.
@@ -61,16 +61,19 @@ The BIP author may update the draft as necessary in the git repository. Updates
 
 It occasionally becomes necessary to transfer ownership of BIPs to a new champion. In general, we'd like to retain the original author as a co-author of the transferred BIP, but that's really up to the original author. A good reason to transfer ownership is because the original author no longer has the time or interest in updating it or following through with the BIP process, or has fallen off the face of the 'net (i.e. is unreachable or not responding to email). A bad reason to transfer ownership is because you don't agree with the direction of the BIP. We try to build consensus around a BIP, but if that's not possible, you can always submit a competing BIP.
 
-If you are interested in assuming ownership of a BIP, send a message asking to take over, addressed to both the original author and the BIP editor. If the original author doesn't respond to email in a timely manner, the BIP editor will make a unilateral decision (it's not like such decisions can't be reversed :).
+If you are interested in assuming ownership of a BIP, send a message asking to take over, addressed to both the original author and the BIP editors. If the original author doesn't respond to email in a timely manner, the BIP editors will make a unilateral decision (it's not like such decisions can't be reversed :).
 
 ===BIP Editors===
 
-The current BIP editor is Luke Dashjr who can be contacted at [[mailto:luke_bipeditor@dashjr.org|luke_bipeditor@dashjr.org]].
+The current BIP editors are:
+
+* Luke Dashjr ([[mailto:luke_bipeditor@dashjr.org|luke_bipeditor@dashjr.org]])
+* Kalle Alm ([[mailto:karljohan-alm@garage.co.jp|karljohan-alm@garage.co.jp]])
 
 ===BIP Editor Responsibilities & Workflow===
 
-The BIP editor subscribes to the Bitcoin development mailing list.
-Off-list BIP-related correspondence should be sent (or CC'd) to luke_bipeditor@dashjr.org.
+The BIP editors subscribe to the Bitcoin development mailing list.
+Off-list BIP-related correspondence should be sent (or CC'd) to the BIP editors.
 
 For each new BIP that comes in an editor does the following:
 
@@ -186,7 +189,7 @@ The typical paths of the status of BIPs are as follows:
 <img src="bip-0002/process.png"></img>
 
 Champions of a BIP may decide on their own to change the status between Draft, Deferred, or Withdrawn.
-The BIP editor may also change the status to Deferred when no progress is being made on the BIP.
+A BIP editor may also change the status to Deferred when no progress is being made on the BIP.
 
 A BIP may only change status from Draft (or Rejected) to Proposed, when the author deems it is complete, has a working implementation (where applicable), and has community plans to progress it to the Final status.
 
-- 
cgit v1.2.3


From 88e1514f088e060b9b452b9368a6ff3736ee7794 Mon Sep 17 00:00:00 2001
From: Andreas Gassmann <andreas@andreasgassmann.ch>
Date: Mon, 14 Jun 2021 03:16:46 +0200
Subject: BIP85: Add AirGap Vault implementation

---
 bip-0085.mediawiki | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/bip-0085.mediawiki b/bip-0085.mediawiki
index b0131c3..6e7dd0e 100644
--- a/bip-0085.mediawiki
+++ b/bip-0085.mediawiki
@@ -104,6 +104,8 @@ OUTPUT
 
 * 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==
-- 
cgit v1.2.3


From 5919ade31c1f55b97c438024b6250aed614514bc Mon Sep 17 00:00:00 2001
From: Raulo <630679+Raulo@users.noreply.github.com>
Date: Mon, 14 Jun 2021 09:27:50 +0000
Subject: Replaces Bech32 by Bech32m in BIP341

Segwit version 1 is encoded by Bech32m given by BIP350
---
 bip-0341.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-0341.mediawiki b/bip-0341.mediawiki
index fb6e222..5e47bfc 100644
--- a/bip-0341.mediawiki
+++ b/bip-0341.mediawiki
@@ -336,7 +336,7 @@ Non-upgraded nodes, however, will consider all SegWit version 1 witness programs
 They are strongly encouraged to upgrade in order to fully validate the new programs.
 
 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-0173.mediawiki|BIP173]] Bech32 addresses.
+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.
 
 == Acknowledgements ==
 
-- 
cgit v1.2.3


From 337114b06eee649b5b2fe75dcbdcd7e5b984bbde Mon Sep 17 00:00:00 2001
From: Vasil Dimov <vd@FreeBSD.org>
Date: Wed, 16 Jun 2021 13:24:55 +0200
Subject: BIP155: extra-clarify the semantic of sendaddrv2

---
 bip-0155.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-0155.mediawiki b/bip-0155.mediawiki
index 19f92f2..3e7b0d8 100644
--- a/bip-0155.mediawiki
+++ b/bip-0155.mediawiki
@@ -131,7 +131,7 @@ See the appendices for the address encodings to be used for the various networks
 
 ==Signaling support and compatibility==
 
-Introduce a new message type <code>sendaddrv2</code>. Sending such a message indicates that a node can understand and prefers to receive <code>addrv2</code> messages instead of <code>addr</code> messages. I.e. "Send me addrv2".
+Introduce a new message type <code>sendaddrv2</code>. Sending such a message indicates that a node can understand and prefers to receive <code>addrv2</code> messages instead of <code>addr</code> messages. I.e. "Send me addrv2". Sending or not sending this message does not imply any preference with respect to receiving unrequested address messages.
 
 The <code>sendaddrv2</code> message MUST only be sent in response to the <code>version</code> message from a peer and prior to sending the <code>verack</code> message.
 
-- 
cgit v1.2.3


From 70e37e025daa21bb2287efa7dd5c17fe80b003d3 Mon Sep 17 00:00:00 2001
From: Andrew Chow <achow101-github@achow101.com>
Date: Mon, 21 Jun 2021 17:09:14 -0400
Subject: psbt2: Fix field number counting

PSBT_OUT_SCRIPT should be 0x04, not 0x03.
---
 bip-0174.mediawiki | 2 +-
 bip-0370.mediawiki | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/bip-0174.mediawiki b/bip-0174.mediawiki
index b211434..f3de964 100644
--- a/bip-0174.mediawiki
+++ b/bip-0174.mediawiki
@@ -501,7 +501,7 @@ determine which outputs are change outputs and verify that the change is returni
 | [[bip-psb2.mediawiki|psbt2]]
 |-
 | Output Script
-| <tt>PSBT_OUT_SCRIPT = 0x03</tt>
+| <tt>PSBT_OUT_SCRIPT = 0x04</tt>
 | None
 | No key data
 | <tt><script></tt>
diff --git a/bip-0370.mediawiki b/bip-0370.mediawiki
index 8dd557a..d906a40 100644
--- a/bip-0370.mediawiki
+++ b/bip-0370.mediawiki
@@ -197,7 +197,7 @@ The new per-output types for PSBT Version 2 are defined as follows:
 | 2
 |-
 | Output Script
-| <tt>PSBT_OUT_SCRIPT = 0x03</tt>
+| <tt>PSBT_OUT_SCRIPT = 0x04</tt>
 | None
 | No key data
 | <tt><script></tt>
-- 
cgit v1.2.3


From c8d0e63feea4a32853c57f4b57985988b00b43c5 Mon Sep 17 00:00:00 2001
From: Tobin Harding <me@tobin.cc>
Date: Tue, 22 Jun 2021 10:52:18 +1000
Subject: Remove typo: plural

This sentence should use a singular 'key' instead of 'keys'. Change
'knowing an extended public keys allows' to be 'knowing an extended
public key allows'
---
 bip-0032.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-0032.mediawiki b/bip-0032.mediawiki
index b8152e7..88c2dbb 100644
--- a/bip-0032.mediawiki
+++ b/bip-0032.mediawiki
@@ -119,7 +119,7 @@ To shorten notation, we will write CKDpriv(CKDpriv(CKDpriv(m,3<sub>H</sub>),2),5
 * N(m/a<sub>H</sub>/b/c) = N(m/a<sub>H</sub>/b)/c = N(m/a<sub>H</sub>)/b/c.
 However, N(m/a<sub>H</sub>) cannot be rewritten as N(m)/a<sub>H</sub>, 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===
 
-- 
cgit v1.2.3


From 5e052176efef4d54f5b6d02e86501e4417af2575 Mon Sep 17 00:00:00 2001
From: Anthony Towns <aj@erisian.com.au>
Date: Thu, 10 Jun 2021 08:06:46 +1000
Subject: Update BIP 118 for taproot, rename to ANYPREVOUT

---
 bip-0118.mediawiki | 311 ++++++++++++++++++++++++++++++++---------------------
 1 file changed, 190 insertions(+), 121 deletions(-)

diff --git a/bip-0118.mediawiki b/bip-0118.mediawiki
index afbfde6..9596b95 100644
--- a/bip-0118.mediawiki
+++ b/bip-0118.mediawiki
@@ -1,144 +1,213 @@
 <pre>
   BIP: 118
   Layer: Consensus (soft fork)
-  Title: SIGHASH_NOINPUT
+  Title: SIGHASH_ANYPREVOUT for Taproot Scripts
   Author: Christian Decker <decker.christian@gmail.com>
+          Anthony Towns <aj@erisian.com.au>
   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
 </pre>
 
-== Abstract ==
-This BIP describes a new signature hash flag (<tt>sighash</tt>-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.
-
-== 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.
-
-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 <tt>witnessProgram</tt> and value match the ones
-in the <tt>witness</tt> of the spending transaction.
-
-The dynamic binding is opt-in and can further be restricted by using
-unique <tt>witnessProgram</tt> scripts that are specific to the application
-instance, e.g., using public keys that are specific to the off-chain
-protocol instance.
+== Introduction ==
+
+=== Abstract ===
+
+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.
+
+=== 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<ref>'''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]]).</ref>
+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<ref>'''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 <code>nLockTime</code> 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.
+</ref> and value <ref>'''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].</ref>).
+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 ==
-<tt>SIGHASH_NOINPUT</tt> is a flag with value <tt>0x40</tt> 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 <tt>SIGHASH_NOINPUT</tt> 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.
-
-The transaction digest algorithm from BIP 143 is used when verifying a
-<tt>SIGHASH_NOINPUT</tt> signature, with the following modifications:
-
-    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 <tt>value</tt> of the previous output remains part of the transaction
-digest and is therefore also committed to in the signature.
-
-The <tt>NOINPUT</tt> flag MAY be combined with the <tt>SINGLE</tt> flag in which
-case the <tt>hashOutputs</tt> is modified as per BIP
-143<ref>https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki</ref>: it
-only commits to the output with the matching index, if such output exists, and
-is a <tt>uint256</tt> <tt>0x0000......0000</tt> otherwise.
-
-Being a change in the digest algorithm, the <tt>NOINPUT</tt> flag applies to
-all segwit signature verification opcodes, specifically it applies to:
-
-* <tt>OP_CHECKSIG</tt>
-
-* <tt>OP_CHECKSIGVERIFY</tt>
-
-* <tt>OP_CHECKMULTISIG</tt>
-
-* <tt>OP_CHECKMULTISIGVERIFY</tt>
-
-== Binding through scripts ==
-Using <tt>NOINPUT</tt> 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 signature and whose <tt>witnessProgram</tt>,
-combined with the spending transaction's <tt>witness</tt> returns <tt>true</tt>.
-
-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 <tt>witnessProgram</tt> and the <tt>witness</tt>.
-
-This also means that particular care has to be taken in order to avoid
-unintentionally enabling this rebinding mechanism. <tt>NOINPUT</tt> 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 <tt>NOINPUT</tt> 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 <tt>NOINPUT</tt>
-signatures and MUST NOT reuse them afterwards.
+
+This BIP modifies the behaviour of the [[bip-0342.mediawiki|BIP 342]] signature opcodes<ref>'''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.
+</ref> (<code>CHECKSIG</code>, <code>CHECKSIGVERIFY</code>, and <code>CHECKSIGADD</code>) for public keys that have a length of 33 bytes and a first byte of <code>0x01</code> or the public key which is precisely the single byte vector <code>0x01</code><ref>'''Use of 0x01 public key type'''
+Because <code>OP_0</code> 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 <code>OP_1..OP_16</code> or <code>OP_1NEGATE</code> as a way to reference the taproot internal key.
+To keep things as simple as possible, we simply use the first of these, and add the same byte as a prefix to allow ANYPREVOUT signatures for explicitly specified keys.
+</ref>.
+These keys are termed '''BIP 118 public keys'''.
+
+==== Rules for signature opcodes ====
+
+The [[bip-0342.mediawiki|BIP 342]] rules for signature opcodes are modified by removing keys with the first byte <code>0x01</code> and length of 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:
+
+* If the public key is the single byte <code>0x01</code>, or if the public key is 33 bytes and the first byte of the public key is <code>0x01</code>, 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 <code>hash_type</code> values, and transaction digest modified as defined below.
+
+==== Public key ====
+
+To convert a 1-byte BIP 118 public key for use with [[bip-0340.mediawiki|BIP 340]], simply use the 32-byte taproot internal key, <code>p</code>, as defined in [[bip-0341.mediawiki|BIP 341]].
+
+To convert a 33-byte BIP 118 public key for use with [[bip-0340.mediawiki|BIP 340]], simply remove the <code>0x01</code> prefix and use the remaining 32 bytes.
+
+==== Signature message ====
+
+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]].
+
+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 <code>0x41</code>, <code>0x42</code>, <code>0x43</code>, <code>0xc1</code>, <code>0xc2</code>, and <code>0xc3</code> are also valid for BIP 118 public keys.
+
+We define the following constants using bits 6 and 7 of <code>hash_type</code>:
+
+* <code>SIGHASH_ANYPREVOUT = 0x40</code>
+* <code>SIGHASH_ANYPREVOUTANYSCRIPT = 0xc0</code>
+
+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 <code>SIGHASH_SINGLE</code> 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 <code>SIGHASH_NONE</code> or <code>SIGHASH_SINGLE</code>:
+*** ''sha_outputs'' (32): the SHA256 of the serialization of all outputs in <code>CTxOut</code> 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 <code>SIGHASH_ANYONECANPAY</code>:
+**** ''outpoint'' (36): the <code>COutPoint</code> of this input (32-byte hash + 4-byte little-endian).
+*** If ''hash_type & 0xc0'' is <code>SIGHASH_ANYONECANPAY</code> or <code>SIGHASH_ANYPREVOUT</code>:
+**** ''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 <code>CTxOut</code>. 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 <code>SIGHASH_SINGLE</code>:
+*** ''sha_single_output'' (32): the SHA256 of the corresponding output in <code>CTxOut</code> format.
+
+Similarly, ''SigExt118(hash_type,key_version)'' evaluates to the concatenation of:
+
+* Extension:
+** If ''hash_type & 0xc0'' is not <code>SIGHASH_ANYPREVOUTANYSCRIPT</codE>:
+*** ''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 <code>OP_CODESEPARATOR</code> 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, hash<sub>TapSigHash</sub>(0x00 || SigMsg118(0x00, 1) || SigExt118(0x00, 0x02), sig)'', where ''Verify'' is defined in [[bip-0340.mediawiki|BIP 340]].
+* If the ''sig'' is 65 bytes long, return ''sig[64] &ne; 0x00 and Verify(p, hash<sub>TapSighash</sub>(0x00 || SigMsg118(sig[64], 1) || SigExt118(sig[64], 0x02), sig[0:64])''.
+* Otherwise, fail.
+
+The key differences from [[bip-0342.mediawiki|BIP 342]] signature verification are:
+
+* In all cases, <code>key_version</code> is set to the constant value <code>0x01</code> instead of <code>0x00</code>.<ref>'''Why change key_version?''' Changing <code>key_version</code> 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).</ref>
+* If <code>SIGHASH_ANYPREVOUT</code> is set, the digest is calculated as if <code>SIGHASH_ANYONECANPAY</code> was set, except <code>outpoint</code> is not included in the digest.
+* If <code>SIGHASH_ANYPREVOUTANYSCRIPT</code> is set, the digest is calculated as if <code>SIGHASH_ANYONECANPAY</code> was set, except <code>outpoint</code>, <code>scriptPubKey</code> and <code>tapleaf_hash</code> are not included in the digest.
+
+== Security ==
+
+==== Signature replay ====
+
+By design, <code>SIGHASH_ANYPREVOUT</code> and <code>SIGHASH_ANYPREVOUTANYSCRIPT</code> introduce additional potential for signature replay (that is they allow the same signature to be reused on a different transaction) when compared to <code>SIGHASH_ALL</code> and <code>SIGHASH_ANYONECANPAY</code> signatures.
+
+Both <code>SIGHASH_ALL</code> and <code>SIGHASH_ANYONECANPAY</code> 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 <code>SIGHASH_ANYPREVOUT</code> signature replay is possible for different UTXOs with the same <code>scriptPubKey</code> and the same value, while with <code>SIGHASH_ANYPREVOUTANYSCRIPT</code> 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 <code>SIGHASH_ANYPREVOUT</code> or <code>SIGHASH_ANYPREVOUTANYSCRIPT</code> 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 <code>scriptPubKey</code> 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 simply be adjusted to reference the new txid as the input and the ANYPREVOUT signatures remain valid.
+
+However child transactions that are authorised by a <code>SIGHASH_ALL</code> or <code>SIGHASH_ANYONECANPAY</code> 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 <code>SIGHASH_ALL</code> or <code>SIGHASH_ANYONECANPAY</code>: 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 ==
+
+<references />
 
 == Deployment ==
-The <tt>NOINPUT</tt> 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
+
+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]].
+
+== Backwards compatibility ==
+
+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-0173.mediawiki|BIP173]] Bech32 addresses and do not consider the outputs non-standard, and therefore prevent transaction broadcast.
 
-== Acknowledgments ==
+== Revisions ==
 
-The <tt>NOINPUT</tt> sighash flag was first proposed by Joseph Poon in
-February 2016<ref>https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-February/012460.html</ref>, after being mentioned in the original
-Lightning paper<ref>http://lightning.network/lightning-network.pdf</ref>. 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 <tt>NOINPUT</tt> sighash flag, and its uses in off-chain protocols.
+Apart from being based on Taproot rather than SegWit v0, the main differences to prior revisions of this BIP are:
 
-== References ==
+* 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 <code>SIGHASH_ANYPREVOUT</code> or <code>SIGHASH_ANYPREVOUTANYSCRIPT</code> 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 <code>scriptPubKey</code> or the redeem/witness script. This behaviour is preserved when <code>SIGHASH_ANYPREVOUTANYSCRIPT</code> is used, but when <code>SIGHASH_ANYPREVOUT</code> is used, the signature now commits to <code>scriptPubKey</code> and the tapscript.
+* NOINPUT signatures did commit to the input's amount. This behaviour is preserved when <code>SIGHASH_ANYPREVOUT</code> is used, but not when <code>SIGHASH_ANYPREVOUTANYSCRIPT</code> is used.
+* <code>OP_CODESEPARATOR</code> in script will affect both <code>SIGHASH_ANYPREVOUT</code> and <code>SIGHASH_ANYPREVOUTANYSCRIPT</code> signatures, whereas it would not have in the previous draft.
 
-<references/>
+== Acknowledgements ==
 
-== Copyright ==
+The <code>SIGHASH_NOINPUT</code> 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.
-- 
cgit v1.2.3


From a8787c51ff7835d35de930d54aa8045aac19c129 Mon Sep 17 00:00:00 2001
From: Anthony Towns <aj@erisian.com.au>
Date: Mon, 20 Jul 2020 13:21:07 +1000
Subject: Update README

---
 README.mediawiki | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/README.mediawiki b/README.mediawiki
index d8bcae6..aca35e9 100644
--- a/README.mediawiki
+++ b/README.mediawiki
@@ -591,8 +591,8 @@ Those proposing changes should consider that ultimately consent may rest with th
 |-
 | [[bip-0118.mediawiki|118]]
 | Consensus (soft fork)
-| SIGHASH_NOINPUT
-| Christian Decker
+| SIGHASH_ANYPREVOUT for Taproot Scripts
+| Christian Decker, Anthony Towns
 | Standard
 | Draft
 |-
-- 
cgit v1.2.3


From 0cbc8674dd642702fca2037fb105d3277381b784 Mon Sep 17 00:00:00 2001
From: Anthony Towns <aj@erisian.com.au>
Date: Sat, 12 Jun 2021 19:15:29 +1000
Subject: BIP118: refer to bech32m instead of bech32 for segwit v1 outputs

Thanks to Ben Carman for spotting.
---
 bip-0118.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-0118.mediawiki b/bip-0118.mediawiki
index 9596b95..bb66349 100644
--- a/bip-0118.mediawiki
+++ b/bip-0118.mediawiki
@@ -194,7 +194,7 @@ Nodes that have not upgraded to support [[bip-0341.mediawiki|BIP 341]] will see
 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-0173.mediawiki|BIP173]] Bech32 addresses and do not consider the outputs non-standard, and therefore prevent transaction broadcast.
+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.
 
 == Revisions ==
 
-- 
cgit v1.2.3


From 420dc42f0e771b1ee131b4fff9c50530e140b463 Mon Sep 17 00:00:00 2001
From: Anthony Towns <aj@erisian.com.au>
Date: Sun, 13 Jun 2021 09:18:06 +1000
Subject: BIP118: remove subliminal advertising of Simplicity

---
 bip-0118.mediawiki | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/bip-0118.mediawiki b/bip-0118.mediawiki
index bb66349..df3e42b 100644
--- a/bip-0118.mediawiki
+++ b/bip-0118.mediawiki
@@ -54,7 +54,7 @@ This proposal only supports ANYPREVOUT signatures via script path spends, and do
 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.
 </ref> (<code>CHECKSIG</code>, <code>CHECKSIGVERIFY</code>, and <code>CHECKSIGADD</code>) for public keys that have a length of 33 bytes and a first byte of <code>0x01</code> or the public key which is precisely the single byte vector <code>0x01</code><ref>'''Use of 0x01 public key type'''
 Because <code>OP_0</code> 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 <code>OP_1..OP_16</code> or <code>OP_1NEGATE</code> as a way to reference the taproot internal key.
-To keep things as simple as possible, we simply use the first of these, and add the same byte as a prefix to allow ANYPREVOUT signatures for explicitly specified keys.
+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.
 </ref>.
 These keys are termed '''BIP 118 public keys'''.
 
@@ -67,9 +67,9 @@ The [[bip-0342.mediawiki|BIP 342]] rules for signature opcodes are modified by r
 
 ==== Public key ====
 
-To convert a 1-byte BIP 118 public key for use with [[bip-0340.mediawiki|BIP 340]], simply use the 32-byte taproot internal key, <code>p</code>, as defined in [[bip-0341.mediawiki|BIP 341]].
+To convert a 1-byte BIP 118 public key for use with [[bip-0340.mediawiki|BIP 340]], use the 32-byte taproot internal key, <code>p</code>, as defined in [[bip-0341.mediawiki|BIP 341]].
 
-To convert a 33-byte BIP 118 public key for use with [[bip-0340.mediawiki|BIP 340]], simply remove the <code>0x01</code> prefix and use the remaining 32 bytes.
+To convert a 33-byte BIP 118 public key for use with [[bip-0340.mediawiki|BIP 340]], remove the <code>0x01</code> prefix and use the remaining 32 bytes.
 
 ==== Signature message ====
 
@@ -161,7 +161,7 @@ Depending on the changes to the inputs, this might conflict with the original tr
 
 Further, for a chain of transactions using the same <code>scriptPubKey</code> 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 simply be adjusted to reference the new txid as the input and the ANYPREVOUT signatures remain valid.
+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 <code>SIGHASH_ALL</code> or <code>SIGHASH_ANYONECANPAY</code> 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 <code>SIGHASH_ALL</code> or <code>SIGHASH_ANYONECANPAY</code>: 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.
-- 
cgit v1.2.3


From d616d5492bc6e6566af1b9f9e43b660bcd48ca29 Mon Sep 17 00:00:00 2001
From: Anthony Towns <aj@erisian.com.au>
Date: Sun, 13 Jun 2021 09:24:07 +1000
Subject: BIP118: tweak wording around 1-byte pubkey

---
 bip-0118.mediawiki | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/bip-0118.mediawiki b/bip-0118.mediawiki
index df3e42b..8fa3d52 100644
--- a/bip-0118.mediawiki
+++ b/bip-0118.mediawiki
@@ -60,14 +60,14 @@ These keys are termed '''BIP 118 public keys'''.
 
 ==== Rules for signature opcodes ====
 
-The [[bip-0342.mediawiki|BIP 342]] rules for signature opcodes are modified by removing keys with the first byte <code>0x01</code> and length of 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 [[bip-0342.mediawiki|BIP 342]] rules for signature opcodes are modified by removing keys with the first byte <code>0x01</code> 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:
 
 * If the public key is the single byte <code>0x01</code>, or if the public key is 33 bytes and the first byte of the public key is <code>0x01</code>, 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 <code>hash_type</code> values, and transaction digest modified as defined below.
 
 ==== Public key ====
 
-To convert a 1-byte BIP 118 public key for use with [[bip-0340.mediawiki|BIP 340]], use the 32-byte taproot internal key, <code>p</code>, as defined in [[bip-0341.mediawiki|BIP 341]].
+To convert the 1-byte BIP 118 public key for use with [[bip-0340.mediawiki|BIP 340]], use the 32-byte taproot internal key, <code>p</code>, as defined in [[bip-0341.mediawiki|BIP 341]].
 
 To convert a 33-byte BIP 118 public key for use with [[bip-0340.mediawiki|BIP 340]], remove the <code>0x01</code> prefix and use the remaining 32 bytes.
 
-- 
cgit v1.2.3


From 330b56b35867fa403634bf8d0ede0d2cb235aab5 Mon Sep 17 00:00:00 2001
From: Andrew Chow <achow101-github@achow101.com>
Date: Tue, 22 Jun 2021 20:59:29 -0400
Subject: Specify BIP 86: Key Derivation for Single Key P2TR Outputs

---
 README.mediawiki   |   7 +++
 bip-0086.mediawiki | 128 +++++++++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 135 insertions(+)
 create mode 100644 bip-0086.mediawiki

diff --git a/README.mediawiki b/README.mediawiki
index d8bcae6..eaafbef 100644
--- a/README.mediawiki
+++ b/README.mediawiki
@@ -434,6 +434,13 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Ethan Kosakovsky
 | Informational
 | Draft
+|-
+| [[bip-0086.mediawiki|86]]
+| Applications
+| Key Derivation for Single Key P2TR Outputs
+| Andrew Chow
+| Standard
+| Draft
 |- style="background-color: #ffffcf"
 | [[bip-0087.mediawiki|87]]
 | Applications
diff --git a/bip-0086.mediawiki b/bip-0086.mediawiki
new file mode 100644
index 0000000..f724884
--- /dev/null
+++ b/bip-0086.mediawiki
@@ -0,0 +1,128 @@
+<pre>
+  BIP: 86
+  Layer: Applications
+  Title: Key Derivation for Single Key P2TR Outputs
+  Author: Andrew Chow <andrew@achow101.com>
+  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
+</pre>
+
+==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.
+
+<pre>
+m / purpose' / coin_type' / account' / change / address_index
+</pre>
+
+For the <tt>purpose</tt>-path level it uses <tt>86'</tt>.
+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 <tt>derived_key</tt> 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(hash<sub>TapTweak</sub>(bytes(P)))G''." Thus:
+
+<pre>
+internal_key:       lift_x(derived_key)
+32_byte_output_key: internal_key + int(HashTapTweak(bytes(internal_key)))G
+</pre>
+
+In a transaction, the scripts and witnesses are as defined in
+[[bip-0341.mediawiki#specification|BIP 341]]:
+
+<pre>
+witness:      <signature>
+scriptSig:    (empty)
+scriptPubKey: 1 <32_byte_output_key>
+              (0x5120{32_byte_output_key})
+</pre>
+
+==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==
+
+<pre>
+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
+</pre>
+
+==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]]
-- 
cgit v1.2.3


From f62639ab52794fe3b99d4a1c10e8ec4daff938d4 Mon Sep 17 00:00:00 2001
From: Sanket Kanjalkar <sanket1729@gmail.com>
Date: Fri, 9 Jul 2021 01:28:07 -0700
Subject: BIP118: key version should be 0x01

---
 bip-0118.mediawiki | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/bip-0118.mediawiki b/bip-0118.mediawiki
index 8fa3d52..a3a690b 100644
--- a/bip-0118.mediawiki
+++ b/bip-0118.mediawiki
@@ -131,8 +131,8 @@ Note that if ''hash_type & 0x40'' is zero, ''SigMsg118(hash_type,ext_flag) == Si
 
 To verify a signature ''sig'' for a BIP 118 public key ''p'':
 
-* If the ''sig'' is 64 bytes long, return ''Verify(p, hash<sub>TapSigHash</sub>(0x00 || SigMsg118(0x00, 1) || SigExt118(0x00, 0x02), sig)'', where ''Verify'' is defined in [[bip-0340.mediawiki|BIP 340]].
-* If the ''sig'' is 65 bytes long, return ''sig[64] &ne; 0x00 and Verify(p, hash<sub>TapSighash</sub>(0x00 || SigMsg118(sig[64], 1) || SigExt118(sig[64], 0x02), sig[0:64])''.
+* If the ''sig'' is 64 bytes long, return ''Verify(p, hash<sub>TapSigHash</sub>(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] &ne; 0x00 and Verify(p, hash<sub>TapSighash</sub>(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:
-- 
cgit v1.2.3


From 9cf5c72b569e321c0fc680b2a1ce0c3dd03c75af Mon Sep 17 00:00:00 2001
From: Riccardo Casatta <riccardo@casatta.it>
Date: Wed, 14 Jul 2021 16:42:39 +0200
Subject: remove int_from_bytes in lift_x call since it is done internally

---
 bip-0341.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-0341.mediawiki b/bip-0341.mediawiki
index 5e47bfc..ba3310f 100644
--- a/bip-0341.mediawiki
+++ b/bip-0341.mediawiki
@@ -180,7 +180,7 @@ def taproot_tweak_pubkey(pubkey, h):
     t = int_from_bytes(tagged_hash("TapTweak", pubkey + h))
     if t >= SECP256K1_ORDER:
         raise ValueError
-    Q = point_add(lift_x(int_from_bytes(pubkey)), point_mul(G, t))
+    Q = point_add(lift_x(pubkey), point_mul(G, t))
     return 0 if has_even_y(Q) else 1, bytes_from_int(x(Q))
 
 def taproot_tweak_seckey(seckey0, h):
-- 
cgit v1.2.3


From 1eb8a3ca4d8ab6d6aab2fd947ef9e613026df1f0 Mon Sep 17 00:00:00 2001
From: Fonta1n3 <fontainedenton@googlemail.com>
Date: Tue, 20 Jul 2021 09:43:55 +0800
Subject: Update bip-0048.mediawiki

- Replace BIP number with ?
- Reduce title to less then 44 characters
- Add MIT Licence and copyright section
- Add specification section
- Add backwards compatibility section
---
 bip-0048.mediawiki | 24 +++++++++++++++++++-----
 1 file changed, 19 insertions(+), 5 deletions(-)

diff --git a/bip-0048.mediawiki b/bip-0048.mediawiki
index 68c0190..313bfcf 100644
--- a/bip-0048.mediawiki
+++ b/bip-0048.mediawiki
@@ -1,13 +1,14 @@
 <pre>
-  BIP: Number not assigned
+  BIP: ?
   Layer: Applications
-  Title: Multi-Account/Multi-Script Hierarchy for Deterministic Multi Signature Wallets
+  Title: Multi-Script Hierarchy for Multi-Sig Wallets
   Author: Peter Denton <dentondevelopment@protonmail.com>
   Comments-Summary: No comments
-  Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0048
+  Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-?
   Status: Proposed
   Type: Standards Track
   Created: 2020-12-16
+  License: MIT License
 </pre>
 
 ==Abstract==
@@ -19,6 +20,9 @@ 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'
@@ -32,12 +36,22 @@ millions of addresses per chain.
 
 This paper was inspired from BIP44.
 
-==Key sorting==
+==Backwards compatibility==
+
+Currently a number of wallets already utilize this derivation scheme for HD multi-sig accounts.
+This BIP is intended to maintain the *existing* real world use of the `48'` derivation.
+No breaking changes are made so as to avoid "loss of funds" to existing users.
+Wallet's which currently support the `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==
+===Path levels===
 
 We define the following 6 levels in BIP32 path:
 
-- 
cgit v1.2.3


From c3c0abd44d79124e418f245de2d960ca123c46dc Mon Sep 17 00:00:00 2001
From: Fonta1n3 <fontainedenton@googlemail.com>
Date: Tue, 20 Jul 2021 09:45:59 +0800
Subject: Update bip-0048.mediawiki

---
 bip-0048.mediawiki | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/bip-0048.mediawiki b/bip-0048.mediawiki
index 313bfcf..20f8b29 100644
--- a/bip-0048.mediawiki
+++ b/bip-0048.mediawiki
@@ -21,6 +21,7 @@ BIP-0044 (BIP44 from now on).
 This BIP is a particular application of BIP43.
 
 ==Copyright==
+
 This BIP falls under the MIT License.
 
 ==Motivation==
@@ -38,7 +39,7 @@ This paper was inspired from BIP44.
 
 ==Backwards compatibility==
 
-Currently a number of wallets already utilize this derivation scheme for HD multi-sig accounts.
+Currently a number of wallets utilize the `48'` derivation scheme for HD multi-sig accounts.
 This BIP is intended to maintain the *existing* real world use of the `48'` derivation.
 No breaking changes are made so as to avoid "loss of funds" to existing users.
 Wallet's which currently support the `48'` derivation will not need to make any changes
-- 
cgit v1.2.3


From bc0593133273f62dbd0c7beeee7c875e14c438cd Mon Sep 17 00:00:00 2001
From: Fonta1n3 <fontainedenton@googlemail.com>
Date: Tue, 20 Jul 2021 09:58:04 +0800
Subject: Delete .DS_Store

---
 .DS_Store | Bin 18436 -> 0 bytes
 1 file changed, 0 insertions(+), 0 deletions(-)
 delete mode 100644 .DS_Store

diff --git a/.DS_Store b/.DS_Store
deleted file mode 100644
index 6f80a1e..0000000
Binary files a/.DS_Store and /dev/null differ
-- 
cgit v1.2.3


From 20c5af58f16da0ba0f7c909d85c4813a7222cfe0 Mon Sep 17 00:00:00 2001
From: Fontan3 <fontainedenton@googlemail.com>
Date: Tue, 20 Jul 2021 10:00:59 +0800
Subject: Update bip-0048.mediawiki

---
 bip-0048.mediawiki | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/bip-0048.mediawiki b/bip-0048.mediawiki
index 20f8b29..6004ad2 100644
--- a/bip-0048.mediawiki
+++ b/bip-0048.mediawiki
@@ -39,10 +39,10 @@ This paper was inspired from BIP44.
 
 ==Backwards compatibility==
 
-Currently a number of wallets utilize the `48'` derivation scheme for HD multi-sig accounts.
-This BIP is intended to maintain the *existing* real world use of the `48'` derivation.
+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 `48'` derivation will not need to make any changes
+Wallet's which currently support the `m/48'` derivation will not need to make any changes
 to comply with this BIP.
 
 ==Specification==
-- 
cgit v1.2.3


From 90cb1c89065207c59847d6259db23f0507fd30c6 Mon Sep 17 00:00:00 2001
From: Fontan3 <fontainedenton@googlemail.com>
Date: Tue, 20 Jul 2021 12:23:59 +0800
Subject: Update bip-0048.mediawiki

---
 bip-0048.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-0048.mediawiki b/bip-0048.mediawiki
index 6004ad2..c63e736 100644
--- a/bip-0048.mediawiki
+++ b/bip-0048.mediawiki
@@ -2,7 +2,7 @@
   BIP: ?
   Layer: Applications
   Title: Multi-Script Hierarchy for Multi-Sig Wallets
-  Author: Peter Denton <dentondevelopment@protonmail.com>
+  Author: Fontaine <dentondevelopment@protonmail.com>
   Comments-Summary: No comments
   Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-?
   Status: Proposed
-- 
cgit v1.2.3


From 84e14b68a62d82ab330a847f63f871494df94962 Mon Sep 17 00:00:00 2001
From: Fontan3 <fontainedenton@googlemail.com>
Date: Tue, 20 Jul 2021 12:30:54 +0800
Subject: Update bip-0048.mediawiki

Add code snippets.
---
 bip-0048.mediawiki | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/bip-0048.mediawiki b/bip-0048.mediawiki
index c63e736..cba896a 100644
--- a/bip-0048.mediawiki
+++ b/bip-0048.mediawiki
@@ -39,10 +39,10 @@ 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.
+Currently a number of wallets utilize the ‎<code>m/48'</code> derivation scheme for HD multi-sig accounts.
+This BIP is intended to maintain the *existing* real world use of the ‎<code>m/48'</code> 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
+Wallet's which currently support the ‎<code>m/48'</code> derivation will not need to make any changes
 to comply with this BIP.
 
 ==Specification==
-- 
cgit v1.2.3


From c583f4dcbe78c2520be20067203ae2737bbca369 Mon Sep 17 00:00:00 2001
From: Andrew Chow <achow101-github@achow101.com>
Date: Mon, 21 Jun 2021 16:58:45 -0400
Subject: Specify BIP 371 Taproot Fields for PSBT

Add bip-0371.mediawiki, update readme, and update BIP 174 with
new field types.
---
 README.mediawiki   |   7 +++
 bip-0174.mediawiki | 110 ++++++++++++++++++++++++++++++++
 bip-0371.mediawiki | 179 +++++++++++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 296 insertions(+)
 create mode 100644 bip-0371.mediawiki

diff --git a/README.mediawiki b/README.mediawiki
index eaafbef..50826db 100644
--- a/README.mediawiki
+++ b/README.mediawiki
@@ -1036,6 +1036,13 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Andrew Chow
 | Standard
 | Draft
+|-
+| [[bip-0371.mediawiki|371]]
+| Applications
+| Taproot Fields for PSBT
+| Andrew Chow
+| Standard
+| Draft
 |}
 
 <!-- IMPORTANT!  See the instructions at the top of this page, do NOT JUST add BIPs here! -->
diff --git a/bip-0174.mediawiki b/bip-0174.mediawiki
index f3de964..5317b4f 100644
--- a/bip-0174.mediawiki
+++ b/bip-0174.mediawiki
@@ -428,6 +428,72 @@ The currently defined per-input types are defined as follows:
 | 2
 | [[bip-psb2.mediawiki|psbt2]]
 |-
+| Taproot Key Spend Signature
+| <tt>PSBT_IN_TAP_KEY_SIG = 0x13</tt>
+| None
+| No key data 
+| <tt><signature></tt>
+| The 64 or 65 byte Schnorr signature for key path spending a Taproot output. Finalizers should remove this field after <tt>PSBT_IN_FINAL_SCRIPTWITNESS</tt> is constructed.
+|
+|
+| 0, 2
+| [[bip-0371.mediawiki|371]]
+|-
+| Taproot Script Spend Signature
+| <tt>PSBT_IN_TAP_SCRIPT_SIG = 0x14</tt>
+| <tt><xonlypubkey> <leafhash></tt>
+| 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.
+| <tt><signature></tt>
+| The 64 or 65 byte Schnorr signature for this pubkey and leaf combination. Finalizers should remove this field after <tt>PSBT_IN_FINAL_SCRIPTWITNESS</tt> is constructed.
+|
+|
+| 0, 2
+| [[bip-0371.mediawiki|371]]
+|-
+| Taproot Leaf Script
+| <tt>PSBT_IN_TAP_LEAF_SCRIPT = 0x15</tt>
+| <tt><control block></tt>
+| The control block for this leaf as specified in BIP 341. The control block contains the merkle tree path to this leaf.
+| <tt><script> <8-bit uint></tt>
+| The script for this leaf as would be provided in the witness stack followed by the single byte leaf version. Note that the leaves included in this field should be those that the signers of this input are expected to be able to sign for. Finalizers should remove this field after <tt>PSBT_IN_FINAL_SCRIPTWITNESS</tt> is constructed. Finalizers should remove this field after <tt>PSBT_IN_FINAL_SCRIPTWITNESS</tt> is constructed.
+|
+|
+| 0, 2
+| [[bip-0371.mediawiki|371]]
+|-
+| Taproot Key BIP 32 Derivation Path
+| <tt>PSBT_IN_TAP_BIP32_DERIVATION = 0x16</tt>
+| <tt><xonlypubkey></tt>
+| A 32 byte X-only public key involved in this input. It may be the internal key, or a key present in a leaf script.
+| <tt><hashes len> <leaf hash>* <4 byte fingerprint> <32-bit uint>*</tt>
+| A compact size unsigned integer representing the number of leaf hashes, followed by a list of leaf hashes, followed by the 4 byte master key fingerprint 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. Public keys are those needed to spend this output. The leaf hashes are of the leaves which involve this public key. The internal key does not have leaf hashes, so can be indicated with a <tt>hashes len</tt> of 0. Finalizers should remove this field after <tt>PSBT_IN_FINAL_SCRIPTWITNESS</tt> is constructed.
+|
+|
+| 0, 2
+| [[bip-0371.mediawiki|371]]
+|-
+| Taproot Internal Key
+| <tt>PSBT_IN_TAP_INTERNAL_KEY = 0x17</tt>
+| None
+| No key data
+| <tt><pubkey></tt>
+| The X-only pubkey used as the internal key in this output. Finalizers should remove this field after <tt>PSBT_IN_FINAL_SCRIPTWITNESS</tt> is constructed.
+|
+|
+| 0, 2
+| [[bip-0371.mediawiki|371]]
+|-
+| Taproot Merkle Root
+| <tt>PSBT_IN_TAP_MERKLE_ROOT = 0x18</tt>
+| None
+| No key data
+| <tt><pubkey></tt>
+| The 32 byte Merkle root hash. Finalizers should remove this field after <tt>PSBT_IN_FINAL_SCRIPTWITNESS</tt> is constructed.
+|
+|
+| 0, 2
+| [[bip-0371.mediawiki|371]]
+|-
 | Proprietary Use Type
 | <tt>PSBT_IN_PROPRIETARY = 0xFC</tt>
 | <tt><identifierlen> <identifier> <subtype> <subkeydata></tt>
@@ -511,6 +577,50 @@ determine which outputs are change outputs and verify that the change is returni
 | 2
 | [[bip-psb2.mediawiki|psbt2]]
 |-
+| Taproot Internal Key
+| <tt>PSBT_OUT_TAP_INTERNAL_KEY = 0x05</tt>
+| None
+| No key data
+| <tt><pubkey></tt>
+| The X-only pubkey used as the internal key in this output.
+|
+|
+| 0, 2
+| [[bip-0371.mediawiki|371]]
+|-
+| Taproot Tree
+| <tt>PSBT_OUT_TAP_TREE = 0x06</tt>
+| None
+| No key data
+| <tt>{<8-bit uint depth> <8-bit uint leaf version> <scriptlen> <script>}*</tt>
+| One or more tuples representing the depth, leaf version, and script for a leaf in the Taproot tree, allowing the entire tree to be reconstructed. The tuples must be in depth first search order so that the tree is correctly reconstructed. Each tuple is an 8-bit unsigned integer representing the depth in the Taproot tree for this script, an 8-bit unsigned integer representing the leaf version, the length of the script as a compact size unsigned integer, and the script itself.
+|
+|
+| 0, 2
+| [[bip-0371.mediawiki|371]]
+|-
+| Taproot Leaf Script
+| <tt>PSBT_OUT_TAP_LEAF_SCRIPT = 0x06</tt>
+| <tt><control block></tt>
+| The control block for this leaf as specified in BIP 341. The control block contains the merkle tree path to this leaf.
+| <tt><script></tt>
+| The script for this leaf as would be provided in the witness stack.
+|
+|
+| 0, 2
+| [[bip-0371.mediawiki|371]]
+|-
+| Taproot Key BIP 32 Derivation Path
+| <tt>PSBT_OUT_TAP_BIP32_DERIVATION = 0x07</tt>
+| <tt><xonlypubkey></tt>
+| A 32 byte X-only public key involved in this output. It may be the internal key, or a key present in a leaf script.
+| <tt><hashes len> <leaf hash>* <4 byte fingerprint> <32-bit uint>*</tt>
+| A compact size unsigned integer representing the number of leaf hashes, followed by a list of leaf hashes, followed by the 4 byte master key fingerprint 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. Public keys are those needed to spend this output. The leaf hashes are of the leaves which involve this public key. The internal key does not have leaf hashes, so can be indicated with a <tt>hashes len</tt> of 0. Finalizers should remove this field after <tt>PSBT_IN_FINAL_SCRIPTWITNESS</tt> is constructed.
+|
+|
+| 0, 2
+| [[bip-0371.mediawiki|371]]
+|-
 | Proprietary Use Type
 | <tt>PSBT_OUT_PROPRIETARY = 0xFC</tt>
 | <tt><identifierlen> <identifier> <subtype> <subkeydata></tt>
diff --git a/bip-0371.mediawiki b/bip-0371.mediawiki
new file mode 100644
index 0000000..ab52ea4
--- /dev/null
+++ b/bip-0371.mediawiki
@@ -0,0 +1,179 @@
+<pre>
+  BIP: 371
+  Layer: Applications
+  Title: Taproot Fields for PSBT
+  Author: Andrew Chow <andrew@achow101.com>
+  Comments-Summary: No comments yet.
+  Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0371
+  Status: Draft
+  Type: Standards Track
+  Created: 2021-06-21
+  License: BSD-2-Clause
+</pre>
+
+==Introduction==
+
+===Abstract===
+
+This document proposes additional fields for BIP 174 PSBTv0 and BIP 370 PSBTv2 that allow for
+BIP 340/341/342 Taproot data to be included in a PSBT of any version. These will be fields for
+signatures and scripts that are relevant to the creation of Taproot inputs.
+
+===Copyright===
+
+This BIP is licensed under the 2-clause BSD license.
+
+===Motivation===
+
+BIPs 340, 341, and 342 specify Taproot which provides a wholly new way to create and spend Bitcoin outputs.
+The existing PSBT fields are unable to support Taproot due to the new signature algorithm and the method
+by which scripts are embedded inside of a Taproot output. Therefore new fields must be defined to allow
+PSBTs to carry the information necessary for signing Taproot inputs.
+
+==Specification==
+
+The new per-input types are defined as follows:
+
+{|
+! Name
+! <tt><keytype></tt>
+! <tt><keydata></tt>
+! <tt><keydata></tt> Description
+! <tt><valuedata></tt>
+! <tt><valuedata></tt> Description
+! Versions Requiring Inclusion
+! Versions Requiring Exclusion
+! Versions Allowing Inclusion
+|-
+| Taproot Key Spend Signature
+| <tt>PSBT_IN_TAP_KEY_SIG = 0x13</tt>
+| None
+| No key data <ref>'''Why is there no key data for <tt>PSBT_IN_TAP_KEY_SIG</tt>'''The signature in a key path spend corresponds directly with the pubkey provided in the output script. Thus it is not necessary to provide any metadata that attaches the key path spend signature to a particular pubkey.</ref>
+| <tt><signature></tt>
+| The 64 or 65 byte Schnorr signature for key path spending a Taproot output. Finalizers should remove this field after <tt>PSBT_IN_FINAL_SCRIPTWITNESS</tt> is constructed.
+|
+|
+| 0, 2
+|-
+| Taproot Script Spend Signature
+| <tt>PSBT_IN_TAP_SCRIPT_SIG = 0x14</tt>
+| <tt><xonlypubkey> <leafhash></tt>
+| 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.
+| <tt><signature></tt>
+| The 64 or 65 byte Schnorr signature for this pubkey and leaf combination. Finalizers should remove this field after <tt>PSBT_IN_FINAL_SCRIPTWITNESS</tt> is constructed.
+|
+|
+| 0, 2
+|-
+| Taproot Leaf Script
+| <tt>PSBT_IN_TAP_LEAF_SCRIPT = 0x15</tt>
+| <tt><control block></tt>
+| The control block for this leaf as specified in BIP 341. The control block contains the merkle tree path to this leaf.
+| <tt><script> <8-bit uint></tt>
+| The script for this leaf as would be provided in the witness stack followed by the single byte leaf version. Note that the leaves included in this field should be those that the signers of this input are expected to be able to sign for. Finalizers should remove this field after <tt>PSBT_IN_FINAL_SCRIPTWITNESS</tt> is constructed. Finalizers should remove this field after <tt>PSBT_IN_FINAL_SCRIPTWITNESS</tt> is constructed.
+|
+|
+| 0, 2
+|-
+| Taproot Key BIP 32 Derivation Path
+| <tt>PSBT_IN_TAP_BIP32_DERIVATION = 0x16</tt>
+| <tt><xonlypubkey></tt>
+| A 32 byte X-only public key involved in this input. It may be the internal key, or a key present in a leaf script.
+| <tt><hashes len> <leaf hash>* <4 byte fingerprint> <32-bit uint>*</tt>
+| A compact size unsigned integer representing the number of leaf hashes, followed by a list of leaf hashes, followed by the 4 byte master key fingerprint 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. Public keys are those needed to spend this output. The leaf hashes are of the leaves which involve this public key. The internal key does not have leaf hashes, so can be indicated with a <tt>hashes len</tt> of 0. Finalizers should remove this field after <tt>PSBT_IN_FINAL_SCRIPTWITNESS</tt> is constructed.
+|
+|
+| 0, 2
+|-
+| Taproot Internal Key
+| <tt>PSBT_IN_TAP_INTERNAL_KEY = 0x17</tt>
+| None
+| No key data
+| <tt><pubkey></tt>
+| The X-only pubkey used as the internal key in this output.<ref>'''Why is the internal key provided?'''The internal key is not necessarily the same key as in the Taproot output script. BIP 341 recommends tweaking the key with the hash of itself. It may be necessary for signers to know what the internal key actually is so that they are able to determine whether an input can be signed by it.</ref> Finalizers should remove this field after <tt>PSBT_IN_FINAL_SCRIPTWITNESS</tt> is constructed.
+|
+|
+| 0, 2
+|-
+| Taproot Merkle Root
+| <tt>PSBT_IN_TAP_MERKLE_ROOT = 0x18</tt>
+| None
+| No key data
+| <tt><pubkey></tt>
+| The 32 byte Merkle root hash. Finalizers should remove this field after <tt>PSBT_IN_FINAL_SCRIPTWITNESS</tt> is constructed.
+|
+|
+| 0, 2
+|}
+
+The new per-output types are defined as follows:
+
+{|
+! Name
+! <tt><keytype></tt>
+! <tt><keydata></tt>
+! <tt><keydata></tt> Description
+! <tt><valuedata></tt>
+! <tt><valuedata></tt> Description
+! Versions Requiring Inclusion
+! Versions Requiring Exclusion
+! Versions Allowing Inclusion
+|-
+| Taproot Internal Key
+| <tt>PSBT_OUT_TAP_INTERNAL_KEY = 0x05</tt>
+| None
+| No key data
+| <tt><pubkey></tt>
+| The X-only pubkey used as the internal key in this output.
+|
+|
+| 0, 2
+|-
+| Taproot Tree
+| <tt>PSBT_OUT_TAP_TREE = 0x06</tt>
+| None
+| No key data
+| <tt>{<8-bit uint depth> <8-bit uint leaf version> <scriptlen> <script>}*</tt>
+| One or more tuples representing the depth, leaf version, and script for a leaf in the Taproot tree, allowing the entire tree to be reconstructed. The tuples must be in depth first search order so that the tree is correctly reconstructed. Each tuple is an 8-bit unsigned integer representing the depth in the Taproot tree for this script, an 8-bit unsigned integer representing the leaf version, the length of the script as a compact size unsigned integer, and the script itself.
+|
+|
+| 0, 2
+|-
+| Taproot Key BIP 32 Derivation Path
+| <tt>PSBT_OUT_TAP_BIP32_DERIVATION = 0x07</tt>
+| <tt><xonlypubkey></tt>
+| A 32 byte X-only public key involved in this output. It may be the internal key, or a key present in a leaf script.
+| <tt><hashes len> <leaf hash>* <4 byte fingerprint> <32-bit uint>*</tt>
+| A compact size unsigned integer representing the number of leaf hashes, followed by a list of leaf hashes, followed by the 4 byte master key fingerprint 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. Public keys are those needed to spend this output. The leaf hashes are of the leaves which involve this public key. The internal key does not have leaf hashes, so can be indicated with a <tt>hashes len</tt> of 0. Finalizers should remove this field after <tt>PSBT_IN_FINAL_SCRIPTWITNESS</tt> is constructed.
+|
+|
+| 0, 2
+|}
+
+===UTXO Types===
+
+BIP 174 recommends using <tt>PSBT_IN_NON_WITNESS_UTXO</tt> for all inputs because of potential attacks involving
+an updater lying about the amounts in an output. Because a Taproot signature will commit to all of the amounts
+and output scripts spent by the inputs of the transaction, such attacks are prevented as any such lying would
+result in an invalid signature. Thus Taproot inputs can use just <tt>PSBT_IN_WITNESS_UTXO</tt>.
+
+==Compatibility==
+
+These are simply new fields added to the existing PSBT format. Because PSBT is designed to be extensible, old
+software will ignore the new fields.
+
+==Test Vectors==
+
+TBD
+
+==Rationale==
+
+<references/>
+
+==Reference implementation==
+
+The reference implementation of the PSBT format is available at TBD.
+
+==Acknowledgements==
+
+TBD
-- 
cgit v1.2.3


From 03f2d744d345500bb30b2d0e52d3ecfa69fdc21e Mon Sep 17 00:00:00 2001
From: Luke Dashjr <luke-jr+git@utopios.org>
Date: Tue, 20 Jul 2021 19:31:25 +0000
Subject: Fix BIP 48 headers and add to README

---
 README.mediawiki   | 7 +++++++
 bip-0048.mediawiki | 6 +++---
 2 files changed, 10 insertions(+), 3 deletions(-)

diff --git a/README.mediawiki b/README.mediawiki
index 106c455..252c006 100644
--- a/README.mediawiki
+++ b/README.mediawiki
@@ -258,6 +258,13 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Justus Ranvier
 | Informational
 | Draft
+|- style="background-color: #ffffcf"
+| [[bip-0048.mediawiki|48]]
+| Applications
+| Multi-Script Hierarchy for Multi-Sig Wallets
+| Fontaine
+| Standard
+| Proposed
 |- style="background-color: #cfffcf"
 | [[bip-0049.mediawiki|49]]
 | Applications
diff --git a/bip-0048.mediawiki b/bip-0048.mediawiki
index cba896a..0b099b3 100644
--- a/bip-0048.mediawiki
+++ b/bip-0048.mediawiki
@@ -1,14 +1,14 @@
 <pre>
-  BIP: ?
+  BIP: 48
   Layer: Applications
   Title: Multi-Script Hierarchy for Multi-Sig Wallets
   Author: Fontaine <dentondevelopment@protonmail.com>
   Comments-Summary: No comments
-  Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-?
+  Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0048
   Status: Proposed
   Type: Standards Track
   Created: 2020-12-16
-  License: MIT License
+  License: MIT
 </pre>
 
 ==Abstract==
-- 
cgit v1.2.3


From 5943de4fa40e808f776374b916205d2932eff3ea Mon Sep 17 00:00:00 2001
From: azuchi <azuchi@chaintope.com>
Date: Sun, 15 Aug 2021 15:49:43 +0900
Subject: [BIP174] Fix broken link to psbt2

---
 bip-0174.mediawiki | 26 +++++++++++++-------------
 1 file changed, 13 insertions(+), 13 deletions(-)

diff --git a/bip-0174.mediawiki b/bip-0174.mediawiki
index 5317b4f..d70a7f1 100644
--- a/bip-0174.mediawiki
+++ b/bip-0174.mediawiki
@@ -125,7 +125,7 @@ The currently defined global types are as follows:
 | 2
 | 0
 | 2
-| [[bip-psb2.mediawiki|psbt2]]
+| [[bip-0370.mediawiki|370]]
 |-
 | Fallback Locktime
 | <tt>PSBT_GLOBAL_FALLBACK_LOCKTIME = 0x03</tt>
@@ -136,7 +136,7 @@ The currently defined global types are as follows:
 |
 | 0
 | 2
-| [[bip-psb2.mediawiki|psbt2]]
+| [[bip-0370.mediawiki|370]]
 |-
 | Input Count
 | <tt>PSBT_GLOBAL_INPUT_COUNT = 0x04</tt>
@@ -147,7 +147,7 @@ The currently defined global types are as follows:
 | 2
 | 0
 | 2
-| [[bip-psb2.mediawiki|psbt2]]
+| [[bip-0370.mediawiki|370]]
 |-
 | Output Count
 | <tt>PSBT_GLOBAL_OUTPUT_COUNT = 0x05</tt>
@@ -158,7 +158,7 @@ The currently defined global types are as follows:
 | 2
 | 0
 | 2
-| [[bip-psb2.mediawiki|psbt2]]
+| [[bip-0370.mediawiki|370]]
 |-
 | Transaction Modifiable Flags
 | <tt>PSBT_GLOBAL_TX_MODIFIABLE = 0x06</tt>
@@ -169,7 +169,7 @@ The currently defined global types are as follows:
 |
 | 0
 | 2
-| [[bip-psb2.mediawiki|psbt2]]
+| [[bip-0370.mediawiki|370]]
 |-
 | SIGHASH_SINGLE Inputs
 | <tt>PSBT_GLOBAL_SIGHASH_SINGLE_INPUTS = 0x07</tt>
@@ -180,7 +180,7 @@ The currently defined global types are as follows:
 |
 | 0
 | 2
-| [[bip-psb2.mediawiki|psbt2]]
+| [[bip-0370.mediawiki|370]]
 |-
 | PSBT Version Number
 | <tt>PSBT_GLOBAL_VERSION = 0xFB</tt>
@@ -382,7 +382,7 @@ The currently defined per-input types are defined as follows:
 | 2
 | 0
 | 2
-| [[bip-psb2.mediawiki|psbt2]]
+| [[bip-0370.mediawiki|370]]
 |-
 | Spent Output Index
 | <tt>PSBT_IN_OUTPUT_INDEX = 0x0f</tt>
@@ -393,7 +393,7 @@ The currently defined per-input types are defined as follows:
 | 2
 | 0
 | 2
-| [[bip-psb2.mediawiki|psbt2]]
+| [[bip-0370.mediawiki|370]]
 |-
 | Sequence Number
 | <tt>PSBT_IN_SEQUENCE = 0x10</tt>
@@ -404,7 +404,7 @@ The currently defined per-input types are defined as follows:
 |
 | 0
 | 2
-| [[bip-psb2.mediawiki|psbt2]]
+| [[bip-0370.mediawiki|370]]
 |-
 | Required Time-based Locktime
 | <tt>PSBT_IN_REQUIRED_TIME_LOCKTIME = 0x11</tt>
@@ -415,7 +415,7 @@ The currently defined per-input types are defined as follows:
 |
 | 0
 | 2
-| [[bip-psb2.mediawiki|psbt2]]
+| [[bip-0370.mediawiki|370]]
 |-
 | Required Height-based Locktime
 | <tt>PSBT_IN_REQUIRED_HEIGHT_LOCKTIME = 0x12</tt>
@@ -426,7 +426,7 @@ The currently defined per-input types are defined as follows:
 |
 | 0
 | 2
-| [[bip-psb2.mediawiki|psbt2]]
+| [[bip-0370.mediawiki|370]]
 |-
 | Taproot Key Spend Signature
 | <tt>PSBT_IN_TAP_KEY_SIG = 0x13</tt>
@@ -564,7 +564,7 @@ determine which outputs are change outputs and verify that the change is returni
 | 2
 | 0
 | 2
-| [[bip-psb2.mediawiki|psbt2]]
+| [[bip-0370.mediawiki|370]]
 |-
 | Output Script
 | <tt>PSBT_OUT_SCRIPT = 0x04</tt>
@@ -575,7 +575,7 @@ determine which outputs are change outputs and verify that the change is returni
 | 2
 | 0
 | 2
-| [[bip-psb2.mediawiki|psbt2]]
+| [[bip-0370.mediawiki|370]]
 |-
 | Taproot Internal Key
 | <tt>PSBT_OUT_TAP_INTERNAL_KEY = 0x05</tt>
-- 
cgit v1.2.3