diff options
| -rw-r--r-- | .travis.yml | 1 | ||||
| -rw-r--r-- | README.mediawiki | 50 | ||||
| -rw-r--r-- | bip-0002.mediawiki | 2 | ||||
| -rw-r--r-- | bip-0013.mediawiki | 2 | ||||
| -rw-r--r-- | bip-0016.mediawiki | 2 | ||||
| -rw-r--r-- | bip-0039/bip-0039-wordlists.md | 16 | ||||
| -rw-r--r-- | bip-0039/czech.txt | 2048 | ||||
| -rw-r--r-- | bip-0044.mediawiki | 13 | ||||
| -rw-r--r-- | bip-0049.mediawiki | 19 | ||||
| -rw-r--r-- | bip-0069.mediawiki | 4 | ||||
| -rw-r--r-- | bip-0074.mediawiki | 2 | ||||
| -rw-r--r-- | bip-0075.mediawiki | 2 | ||||
| -rw-r--r-- | bip-0079.mediawiki | 2 | ||||
| -rw-r--r-- | bip-0102.mediawiki | 2 | ||||
| -rw-r--r-- | bip-0127.mediawiki | 226 | ||||
| -rw-r--r-- | bip-0136.mediawiki | 328 | ||||
| -rw-r--r-- | bip-0143.mediawiki | 2 | ||||
| -rw-r--r-- | bip-0144.mediawiki | 2 | ||||
| -rw-r--r-- | bip-0151.mediawiki | 2 | ||||
| -rw-r--r-- | bip-0155.mediawiki | 189 | ||||
| -rw-r--r-- | bip-0158.mediawiki | 7 | ||||
| -rw-r--r-- | bip-0173.mediawiki | 2 | ||||
| -rw-r--r-- | bip-0174.mediawiki | 54 | ||||
| -rw-r--r-- | bip-0178.mediawiki | 2 | ||||
| -rw-r--r-- | bip-0301.mediawiki | 226 | ||||
| -rw-r--r-- | bip-0301/bmm-dots-examples.png | bin | 0 -> 41116 bytes | |||
| -rw-r--r-- | bip-0301/images.txt | 1 | ||||
| -rw-r--r-- | bip-0301/witness-vs-critical.png | bin | 0 -> 268309 bytes | |||
| -rw-r--r-- | bip-0322.mediawiki | 190 | ||||
| -rwxr-xr-x | scripts/link-format-chk.sh | 23 |
30 files changed, 3331 insertions, 88 deletions
diff --git a/.travis.yml b/.travis.yml index ed99de0..e463ab6 100644 --- a/.travis.yml +++ b/.travis.yml @@ -2,6 +2,7 @@ os: linux language: generic sudo: false script: + - scripts/link-format-chk.sh - scripts/buildtable.pl >/tmp/table.mediawiki || exit 1 - diff README.mediawiki /tmp/table.mediawiki | grep '^[<>] |' >/tmp/after.diff || true - if git checkout HEAD^ && scripts/buildtable.pl >/tmp/table.mediawiki 2>/dev/null; then diff README.mediawiki /tmp/table.mediawiki | grep '^[<>] |' >/tmp/before.diff || true; newdiff=$(diff -s /tmp/before.diff /tmp/after.diff -u | grep '^+'); if [ -n "$newdiff" ]; then echo "$newdiff"; exit 1; fi; else echo 'Cannot build previous commit table for comparison'; fi diff --git a/README.mediawiki b/README.mediawiki index 6a1aaa2..0f21815 100644 --- a/README.mediawiki +++ b/README.mediawiki @@ -223,7 +223,7 @@ Those proposing changes should consider that ultimately consent may rest with th | Marek Palatinus | Standard | BIP number allocated -|-style="background-color: #cfffcf" +|- style="background-color: #cfffcf" | [[bip-0042.mediawiki|42]] | Consensus (soft fork) | A finite monetary supply for Bitcoin @@ -258,13 +258,13 @@ Those proposing changes should consider that ultimately consent may rest with th | Justus Ranvier | Informational | Draft -|- +|- style="background-color: #cfffcf" | [[bip-0049.mediawiki|49]] | Applications | Derivation scheme for P2WPKH-nested-in-P2SH based accounts | Daniel Weigl | Informational -| Draft +| Final |- style="background-color: #cfffcf" | [[bip-0050.mediawiki|50]] | @@ -371,20 +371,20 @@ Those proposing changes should consider that ultimately consent may rest with th | Stephen Pair | Standard | Final -|- +|- style="background-color: #ffcfcf" | [[bip-0074.mediawiki|74]] | Applications | Allow zero value OP_RETURN in Payment Protocol | Toby Padilla | Standard -| Draft -|- +| Rejected +|- style="background-color: #cfffcf" | [[bip-0075.mediawiki|75]] | Applications | Out of Band Address Exchange using Payment Protocol Encryption | Justin Newton, Matt David, Aaron Voisine, James MacWhyte | Standard -| Draft +| Final |- style="background-color: #ffffcf" | [[bip-0079.mediawiki|79]] | Applications @@ -455,13 +455,13 @@ Those proposing changes should consider that ultimately consent may rest with th | Gavin Andresen | Standard | Withdrawn -|- +|- style="background-color: #ffcfcf" | [[bip-0102.mediawiki|102]] | Consensus (hard fork) | Block size increase to 2MB | Jeff Garzik | Standard -| Draft +| Rejected |- | [[bip-0103.mediawiki|103]] | Consensus (hard fork) @@ -609,6 +609,13 @@ Those proposing changes should consider that ultimately consent may rest with th | Kristov Atlas | Informational | Draft +|- +| [[bip-0127.mediawiki|127]] +| Applications +| Simple Proof-of-Reserves Transactions +| Steven Roose +| Standard +| Draft |- style="background-color: #ffffcf" | [[bip-0130.mediawiki|130]] | Peer Services @@ -651,6 +658,13 @@ Those proposing changes should consider that ultimately consent may rest with th | Sancho Panza | Informational | Draft +|- +| [[bip-0136.mediawiki|136]] +| Applications +| Bech32 Encoded Tx Position References +| Велеслав, Jonas Schnelli, Daniel Pape +| Informational +| Draft |- style="background-color: #cfffcf" | [[bip-0137.mediawiki|137]] | Applications @@ -735,13 +749,13 @@ Those proposing changes should consider that ultimately consent may rest with th | Jonas Schnelli | Standard | Draft -|- +|- style="background-color: #ffcfcf" | [[bip-0151.mediawiki|151]] | Peer Services | Peer-to-Peer Communication Encryption | Jonas Schnelli | Standard -| Draft +| Withdrawn |- | [[bip-0152.mediawiki|152]] | Peer Services @@ -757,6 +771,13 @@ Those proposing changes should consider that ultimately consent may rest with th | Standard | Draft |- +| [[bip-0155.mediawiki|155]] +| Peer Services +| addrv2 message +| Wladimir J. van der Laan +| Standard +| Draft +|- | [[bip-0156.mediawiki|156]] | Peer Services | Dandelion - Privacy Enhancing Routing @@ -848,6 +869,13 @@ Those proposing changes should consider that ultimately consent may rest with th | Standard | Draft |- +| [[bip-0301.mediawiki|301]] +| Consensus (soft fork) +| Blind Merged Mining (Consensus layer) +| Paul Sztorc, CryptAxe +| Standard +| Draft +|- | [[bip-0310.mediawiki|310]] | Applications | Stratum protocol extensions diff --git a/bip-0002.mediawiki b/bip-0002.mediawiki index b4567c4..3bf5aec 100644 --- a/bip-0002.mediawiki +++ b/bip-0002.mediawiki @@ -240,7 +240,7 @@ What if a single merchant wishes to block a hard-fork? How about a small number of merchants (maybe only two) who sell products to each other? -* In this scenario, it would seem the previous Bitcoin is alive any working, and that the hard-fork has failed. How to resolve such a split is outside the scope of this BIP. +* In this scenario, it would seem the previous Bitcoin is alive and working, and that the hard-fork has failed. How to resolve such a split is outside the scope of this BIP. How can economic agreement veto a soft-fork? diff --git a/bip-0013.mediawiki b/bip-0013.mediawiki index 081ea2a..70be90d 100644 --- a/bip-0013.mediawiki +++ b/bip-0013.mediawiki @@ -50,7 +50,7 @@ This proposal is not backwards compatible, but it fails gracefully-- if an older ==Reference Implementation== -See base58.cpp1/base58.h at https://github.com/bitcoin/bitcoin/src +See base58.cpp/base58.h at https://github.com/bitcoin/bitcoin/tree/master/src ==See Also== diff --git a/bip-0016.mediawiki b/bip-0016.mediawiki index ba828e1..0f4fb81 100644 --- a/bip-0016.mediawiki +++ b/bip-0016.mediawiki @@ -40,7 +40,7 @@ The rules for validating these outpoints when relaying transactions or consideri # Normal validation is done: an initial stack is created from the signatures and {serialized script}, and the hash of the script is computed and validation fails immediately if it does not match the hash in the outpoint. # {serialized script} is popped off the initial stack, and the transaction is validated again using the popped stack and the deserialized script as the scriptPubKey. -These new rules should only be applied when validating transactions in blocks with timestamps >= 1333238400 (Apr 1 2012) <ref>[https://github.com/bitcoin/bitcoin/commit/8f188ece3c82c4cf5d52a3363e7643c23169c0ff Remove -bip16 and -paytoscripthashtime command-line arguments]</ref>. There are transaction earlier than 1333238400 in the block chain that fail these new validation rules. <ref>[http://blockexplorer.com/tx/6a26d2ecb67f27d1fa5524763b49029d7106e91e3cc05743073461a719776192 Transaction 6a26d2ecb67f27d1fa5524763b49029d7106e91e3cc05743073461a719776192]</ref>. Older transactions must be validated under the old rules. (see the Backwards Compatibility section for details). +These new rules should only be applied when validating transactions in blocks with timestamps >= 1333238400 (Apr 1 2012) <ref>[https://github.com/bitcoin/bitcoin/commit/8f188ece3c82c4cf5d52a3363e7643c23169c0ff Remove -bip16 and -paytoscripthashtime command-line arguments]</ref>. There are transactions earlier than 1333238400 in the block chain that fail these new validation rules. <ref>[http://blockexplorer.com/tx/6a26d2ecb67f27d1fa5524763b49029d7106e91e3cc05743073461a719776192 Transaction 6a26d2ecb67f27d1fa5524763b49029d7106e91e3cc05743073461a719776192]</ref>. Older transactions must be validated under the old rules. (see the Backwards Compatibility section for details). For example, the scriptPubKey and corresponding scriptSig for a one-signature-required transaction is: diff --git a/bip-0039/bip-0039-wordlists.md b/bip-0039/bip-0039-wordlists.md index 635b901..0940f35 100644 --- a/bip-0039/bip-0039-wordlists.md +++ b/bip-0039/bip-0039-wordlists.md @@ -8,6 +8,7 @@ * [Chinese (Traditional)](chinese_traditional.txt) * [French](french.txt) * [Italian](italian.txt) +* [Czech](czech.txt) ## Wordlists (Special Considerations) @@ -82,3 +83,18 @@ Words chosen using the following rules: Rules 11 and 12 prevent the selection words that are not different enough. This makes each word more recognizable among others and less error prone. For example: the wordlist contains "atono", then "atomo" is rejected, but "atomico" is good. All the words have been manually selected and automatically checked against the rules. + +### Czech + +Credits: @zizelevak (Jan Lansky zizelevak@gmail.com) + +Words chosen using the following rules: + +1. Words are 4-8 letters long. +2. Words can be uniquely determined typing the first 4 letters. +3. Only words containing all letters without diacritical marks. (It was the hardest task, because in one third of all Czech letters has diacritical marks.) +4. Only nouns, werbs and adverbs, no other word types. All words are in basic form. +5. No personal names or geografical names. +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. diff --git a/bip-0039/czech.txt b/bip-0039/czech.txt new file mode 100644 index 0000000..fdab4a2 --- /dev/null +++ b/bip-0039/czech.txt @@ -0,0 +1,2048 @@ +abdikace +abeceda +adresa +agrese +akce +aktovka +alej +alkohol +amputace +ananas +andulka +anekdota +anketa +antika +anulovat +archa +arogance +asfalt +asistent +aspirace +astma +astronom +atlas +atletika +atol +autobus +azyl +babka +bachor +bacil +baculka +badatel +bageta +bagr +bahno +bakterie +balada +baletka +balkon +balonek +balvan +balza +bambus +bankomat +barbar +baret +barman +baroko +barva +baterka +batoh +bavlna +bazalka +bazilika +bazuka +bedna +beran +beseda +bestie +beton +bezinka +bezmoc +beztak +bicykl +bidlo +biftek +bikiny +bilance +biograf +biolog +bitva +bizon +blahobyt +blatouch +blecha +bledule +blesk +blikat +blizna +blokovat +bloudit +blud +bobek +bobr +bodlina +bodnout +bohatost +bojkot +bojovat +bokorys +bolest +borec +borovice +bota +boubel +bouchat +bouda +boule +bourat +boxer +bradavka +brambora +branka +bratr +brepta +briketa +brko +brloh +bronz +broskev +brunetka +brusinka +brzda +brzy +bublina +bubnovat +buchta +buditel +budka +budova +bufet +bujarost +bukvice +buldok +bulva +bunda +bunkr +burza +butik +buvol +buzola +bydlet +bylina +bytovka +bzukot +capart +carevna +cedr +cedule +cejch +cejn +cela +celer +celkem +celnice +cenina +cennost +cenovka +centrum +cenzor +cestopis +cetka +chalupa +chapadlo +charita +chata +chechtat +chemie +chichot +chirurg +chlad +chleba +chlubit +chmel +chmura +chobot +chochol +chodba +cholera +chomout +chopit +choroba +chov +chrapot +chrlit +chrt +chrup +chtivost +chudina +chutnat +chvat +chvilka +chvost +chyba +chystat +chytit +cibule +cigareta +cihelna +cihla +cinkot +cirkus +cisterna +citace +citrus +cizinec +cizost +clona +cokoliv +couvat +ctitel +ctnost +cudnost +cuketa +cukr +cupot +cvaknout +cval +cvik +cvrkot +cyklista +daleko +dareba +datel +datum +dcera +debata +dechovka +decibel +deficit +deflace +dekl +dekret +demokrat +deprese +derby +deska +detektiv +dikobraz +diktovat +dioda +diplom +disk +displej +divadlo +divoch +dlaha +dlouho +dluhopis +dnes +dobro +dobytek +docent +dochutit +dodnes +dohled +dohoda +dohra +dojem +dojnice +doklad +dokola +doktor +dokument +dolar +doleva +dolina +doma +dominant +domluvit +domov +donutit +dopad +dopis +doplnit +doposud +doprovod +dopustit +dorazit +dorost +dort +dosah +doslov +dostatek +dosud +dosyta +dotaz +dotek +dotknout +doufat +doutnat +dovozce +dozadu +doznat +dozorce +drahota +drak +dramatik +dravec +draze +drdol +drobnost +drogerie +drozd +drsnost +drtit +drzost +duben +duchovno +dudek +duha +duhovka +dusit +dusno +dutost +dvojice +dvorec +dynamit +ekolog +ekonomie +elektron +elipsa +email +emise +emoce +empatie +epizoda +epocha +epopej +epos +esej +esence +eskorta +eskymo +etiketa +euforie +evoluce +exekuce +exkurze +expedice +exploze +export +extrakt +facka +fajfka +fakulta +fanatik +fantazie +farmacie +favorit +fazole +federace +fejeton +fenka +fialka +figurant +filozof +filtr +finance +finta +fixace +fjord +flanel +flirt +flotila +fond +fosfor +fotbal +fotka +foton +frakce +freska +fronta +fukar +funkce +fyzika +galeje +garant +genetika +geolog +gilotina +glazura +glejt +golem +golfista +gotika +graf +gramofon +granule +grep +gril +grog +groteska +guma +hadice +hadr +hala +halenka +hanba +hanopis +harfa +harpuna +havran +hebkost +hejkal +hejno +hejtman +hektar +helma +hematom +herec +herna +heslo +hezky +historik +hladovka +hlasivky +hlava +hledat +hlen +hlodavec +hloh +hloupost +hltat +hlubina +hluchota +hmat +hmota +hmyz +hnis +hnojivo +hnout +hoblina +hoboj +hoch +hodiny +hodlat +hodnota +hodovat +hojnost +hokej +holinka +holka +holub +homole +honitba +honorace +horal +horda +horizont +horko +horlivec +hormon +hornina +horoskop +horstvo +hospoda +hostina +hotovost +houba +houf +houpat +houska +hovor +hradba +hranice +hravost +hrazda +hrbolek +hrdina +hrdlo +hrdost +hrnek +hrobka +hromada +hrot +hrouda +hrozen +hrstka +hrubost +hryzat +hubenost +hubnout +hudba +hukot +humr +husita +hustota +hvozd +hybnost +hydrant +hygiena +hymna +hysterik +idylka +ihned +ikona +iluze +imunita +infekce +inflace +inkaso +inovace +inspekce +internet +invalida +investor +inzerce +ironie +jablko +jachta +jahoda +jakmile +jakost +jalovec +jantar +jarmark +jaro +jasan +jasno +jatka +javor +jazyk +jedinec +jedle +jednatel +jehlan +jekot +jelen +jelito +jemnost +jenom +jepice +jeseter +jevit +jezdec +jezero +jinak +jindy +jinoch +jiskra +jistota +jitrnice +jizva +jmenovat +jogurt +jurta +kabaret +kabel +kabinet +kachna +kadet +kadidlo +kahan +kajak +kajuta +kakao +kaktus +kalamita +kalhoty +kalibr +kalnost +kamera +kamkoliv +kamna +kanibal +kanoe +kantor +kapalina +kapela +kapitola +kapka +kaple +kapota +kapr +kapusta +kapybara +karamel +karotka +karton +kasa +katalog +katedra +kauce +kauza +kavalec +kazajka +kazeta +kazivost +kdekoliv +kdesi +kedluben +kemp +keramika +kino +klacek +kladivo +klam +klapot +klasika +klaun +klec +klenba +klepat +klesnout +klid +klima +klisna +klobouk +klokan +klopa +kloub +klubovna +klusat +kluzkost +kmen +kmitat +kmotr +kniha +knot +koalice +koberec +kobka +kobliha +kobyla +kocour +kohout +kojenec +kokos +koktejl +kolaps +koleda +kolize +kolo +komando +kometa +komik +komnata +komora +kompas +komunita +konat +koncept +kondice +konec +konfese +kongres +konina +konkurs +kontakt +konzerva +kopanec +kopie +kopnout +koprovka +korbel +korektor +kormidlo +koroptev +korpus +koruna +koryto +korzet +kosatec +kostka +kotel +kotleta +kotoul +koukat +koupelna +kousek +kouzlo +kovboj +koza +kozoroh +krabice +krach +krajina +kralovat +krasopis +kravata +kredit +krejcar +kresba +kreveta +kriket +kritik +krize +krkavec +krmelec +krmivo +krocan +krok +kronika +kropit +kroupa +krovka +krtek +kruhadlo +krupice +krutost +krvinka +krychle +krypta +krystal +kryt +kudlanka +kufr +kujnost +kukla +kulajda +kulich +kulka +kulomet +kultura +kuna +kupodivu +kurt +kurzor +kutil +kvalita +kvasinka +kvestor +kynolog +kyselina +kytara +kytice +kytka +kytovec +kyvadlo +labrador +lachtan +ladnost +laik +lakomec +lamela +lampa +lanovka +lasice +laso +lastura +latinka +lavina +lebka +leckdy +leden +lednice +ledovka +ledvina +legenda +legie +legrace +lehce +lehkost +lehnout +lektvar +lenochod +lentilka +lepenka +lepidlo +letadlo +letec +letmo +letokruh +levhart +levitace +levobok +libra +lichotka +lidojed +lidskost +lihovina +lijavec +lilek +limetka +linie +linka +linoleum +listopad +litina +litovat +lobista +lodivod +logika +logoped +lokalita +loket +lomcovat +lopata +lopuch +lord +losos +lotr +loudal +louh +louka +louskat +lovec +lstivost +lucerna +lucifer +lump +lusk +lustrace +lvice +lyra +lyrika +lysina +madam +madlo +magistr +mahagon +majetek +majitel +majorita +makak +makovice +makrela +malba +malina +malovat +malvice +maminka +mandle +manko +marnost +masakr +maskot +masopust +matice +matrika +maturita +mazanec +mazivo +mazlit +mazurka +mdloba +mechanik +meditace +medovina +melasa +meloun +mentolka +metla +metoda +metr +mezera +migrace +mihnout +mihule +mikina +mikrofon +milenec +milimetr +milost +mimika +mincovna +minibar +minomet +minulost +miska +mistr +mixovat +mladost +mlha +mlhovina +mlok +mlsat +mluvit +mnich +mnohem +mobil +mocnost +modelka +modlitba +mohyla +mokro +molekula +momentka +monarcha +monokl +monstrum +montovat +monzun +mosaz +moskyt +most +motivace +motorka +motyka +moucha +moudrost +mozaika +mozek +mozol +mramor +mravenec +mrkev +mrtvola +mrzet +mrzutost +mstitel +mudrc +muflon +mulat +mumie +munice +muset +mutace +muzeum +muzikant +myslivec +mzda +nabourat +nachytat +nadace +nadbytek +nadhoz +nadobro +nadpis +nahlas +nahnat +nahodile +nahradit +naivita +najednou +najisto +najmout +naklonit +nakonec +nakrmit +nalevo +namazat +namluvit +nanometr +naoko +naopak +naostro +napadat +napevno +naplnit +napnout +naposled +naprosto +narodit +naruby +narychlo +nasadit +nasekat +naslepo +nastat +natolik +navenek +navrch +navzdory +nazvat +nebe +nechat +necky +nedaleko +nedbat +neduh +negace +nehet +nehoda +nejen +nejprve +neklid +nelibost +nemilost +nemoc +neochota +neonka +nepokoj +nerost +nerv +nesmysl +nesoulad +netvor +neuron +nevina +nezvykle +nicota +nijak +nikam +nikdy +nikl +nikterak +nitro +nocleh +nohavice +nominace +nora +norek +nositel +nosnost +nouze +noviny +novota +nozdra +nuda +nudle +nuget +nutit +nutnost +nutrie +nymfa +obal +obarvit +obava +obdiv +obec +obehnat +obejmout +obezita +obhajoba +obilnice +objasnit +objekt +obklopit +oblast +oblek +obliba +obloha +obluda +obnos +obohatit +obojek +obout +obrazec +obrna +obruba +obrys +obsah +obsluha +obstarat +obuv +obvaz +obvinit +obvod +obvykle +obyvatel +obzor +ocas +ocel +ocenit +ochladit +ochota +ochrana +ocitnout +odboj +odbyt +odchod +odcizit +odebrat +odeslat +odevzdat +odezva +odhadce +odhodit +odjet +odjinud +odkaz +odkoupit +odliv +odluka +odmlka +odolnost +odpad +odpis +odplout +odpor +odpustit +odpykat +odrazka +odsoudit +odstup +odsun +odtok +odtud +odvaha +odveta +odvolat +odvracet +odznak +ofina +ofsajd +ohlas +ohnisko +ohrada +ohrozit +ohryzek +okap +okenice +oklika +okno +okouzlit +okovy +okrasa +okres +okrsek +okruh +okupant +okurka +okusit +olejnina +olizovat +omak +omeleta +omezit +omladina +omlouvat +omluva +omyl +onehdy +opakovat +opasek +operace +opice +opilost +opisovat +opora +opozice +opravdu +oproti +orbital +orchestr +orgie +orlice +orloj +ortel +osada +oschnout +osika +osivo +oslava +oslepit +oslnit +oslovit +osnova +osoba +osolit +ospalec +osten +ostraha +ostuda +ostych +osvojit +oteplit +otisk +otop +otrhat +otrlost +otrok +otruby +otvor +ovanout +ovar +oves +ovlivnit +ovoce +oxid +ozdoba +pachatel +pacient +padouch +pahorek +pakt +palanda +palec +palivo +paluba +pamflet +pamlsek +panenka +panika +panna +panovat +panstvo +pantofle +paprika +parketa +parodie +parta +paruka +paryba +paseka +pasivita +pastelka +patent +patrona +pavouk +pazneht +pazourek +pecka +pedagog +pejsek +peklo +peloton +penalta +pendrek +penze +periskop +pero +pestrost +petarda +petice +petrolej +pevnina +pexeso +pianista +piha +pijavice +pikle +piknik +pilina +pilnost +pilulka +pinzeta +pipeta +pisatel +pistole +pitevna +pivnice +pivovar +placenta +plakat +plamen +planeta +plastika +platit +plavidlo +plaz +plech +plemeno +plenta +ples +pletivo +plevel +plivat +plnit +plno +plocha +plodina +plomba +plout +pluk +plyn +pobavit +pobyt +pochod +pocit +poctivec +podat +podcenit +podepsat +podhled +podivit +podklad +podmanit +podnik +podoba +podpora +podraz +podstata +podvod +podzim +poezie +pohanka +pohnutka +pohovor +pohroma +pohyb +pointa +pojistka +pojmout +pokazit +pokles +pokoj +pokrok +pokuta +pokyn +poledne +polibek +polknout +poloha +polynom +pomalu +pominout +pomlka +pomoc +pomsta +pomyslet +ponechat +ponorka +ponurost +popadat +popel +popisek +poplach +poprosit +popsat +popud +poradce +porce +porod +porucha +poryv +posadit +posed +posila +poskok +poslanec +posoudit +pospolu +postava +posudek +posyp +potah +potkan +potlesk +potomek +potrava +potupa +potvora +poukaz +pouto +pouzdro +povaha +povidla +povlak +povoz +povrch +povstat +povyk +povzdech +pozdrav +pozemek +poznatek +pozor +pozvat +pracovat +prahory +praktika +prales +praotec +praporek +prase +pravda +princip +prkno +probudit +procento +prodej +profese +prohra +projekt +prolomit +promile +pronikat +propad +prorok +prosba +proton +proutek +provaz +prskavka +prsten +prudkost +prut +prvek +prvohory +psanec +psovod +pstruh +ptactvo +puberta +puch +pudl +pukavec +puklina +pukrle +pult +pumpa +punc +pupen +pusa +pusinka +pustina +putovat +putyka +pyramida +pysk +pytel +racek +rachot +radiace +radnice +radon +raft +ragby +raketa +rakovina +rameno +rampouch +rande +rarach +rarita +rasovna +rastr +ratolest +razance +razidlo +reagovat +reakce +recept +redaktor +referent +reflex +rejnok +reklama +rekord +rekrut +rektor +reputace +revize +revma +revolver +rezerva +riskovat +riziko +robotika +rodokmen +rohovka +rokle +rokoko +romaneto +ropovod +ropucha +rorejs +rosol +rostlina +rotmistr +rotoped +rotunda +roubenka +roucho +roup +roura +rovina +rovnice +rozbor +rozchod +rozdat +rozeznat +rozhodce +rozinka +rozjezd +rozkaz +rozloha +rozmar +rozpad +rozruch +rozsah +roztok +rozum +rozvod +rubrika +ruchadlo +rukavice +rukopis +ryba +rybolov +rychlost +rydlo +rypadlo +rytina +ryzost +sadista +sahat +sako +samec +samizdat +samota +sanitka +sardinka +sasanka +satelit +sazba +sazenice +sbor +schovat +sebranka +secese +sedadlo +sediment +sedlo +sehnat +sejmout +sekera +sekta +sekunda +sekvoje +semeno +seno +servis +sesadit +seshora +seskok +seslat +sestra +sesuv +sesypat +setba +setina +setkat +setnout +setrvat +sever +seznam +shoda +shrnout +sifon +silnice +sirka +sirotek +sirup +situace +skafandr +skalisko +skanzen +skaut +skeptik +skica +skladba +sklenice +sklo +skluz +skoba +skokan +skoro +skripta +skrz +skupina +skvost +skvrna +slabika +sladidlo +slanina +slast +slavnost +sledovat +slepec +sleva +slezina +slib +slina +sliznice +slon +sloupek +slovo +sluch +sluha +slunce +slupka +slza +smaragd +smetana +smilstvo +smlouva +smog +smrad +smrk +smrtka +smutek +smysl +snad +snaha +snob +sobota +socha +sodovka +sokol +sopka +sotva +souboj +soucit +soudce +souhlas +soulad +soumrak +souprava +soused +soutok +souviset +spalovna +spasitel +spis +splav +spodek +spojenec +spolu +sponzor +spornost +spousta +sprcha +spustit +sranda +sraz +srdce +srna +srnec +srovnat +srpen +srst +srub +stanice +starosta +statika +stavba +stehno +stezka +stodola +stolek +stopa +storno +stoupat +strach +stres +strhnout +strom +struna +studna +stupnice +stvol +styk +subjekt +subtropy +suchar +sudost +sukno +sundat +sunout +surikata +surovina +svah +svalstvo +svetr +svatba +svazek +svisle +svitek +svoboda +svodidlo +svorka +svrab +sykavka +sykot +synek +synovec +sypat +sypkost +syrovost +sysel +sytost +tabletka +tabule +tahoun +tajemno +tajfun +tajga +tajit +tajnost +taktika +tamhle +tampon +tancovat +tanec +tanker +tapeta +tavenina +tazatel +technika +tehdy +tekutina +telefon +temnota +tendence +tenista +tenor +teplota +tepna +teprve +terapie +termoska +textil +ticho +tiskopis +titulek +tkadlec +tkanina +tlapka +tleskat +tlukot +tlupa +tmel +toaleta +topinka +topol +torzo +touha +toulec +tradice +traktor +tramp +trasa +traverza +trefit +trest +trezor +trhavina +trhlina +trochu +trojice +troska +trouba +trpce +trpitel +trpkost +trubec +truchlit +truhlice +trus +trvat +tudy +tuhnout +tuhost +tundra +turista +turnaj +tuzemsko +tvaroh +tvorba +tvrdost +tvrz +tygr +tykev +ubohost +uboze +ubrat +ubrousek +ubrus +ubytovna +ucho +uctivost +udivit +uhradit +ujednat +ujistit +ujmout +ukazatel +uklidnit +uklonit +ukotvit +ukrojit +ulice +ulita +ulovit +umyvadlo +unavit +uniforma +uniknout +upadnout +uplatnit +uplynout +upoutat +upravit +uran +urazit +usednout +usilovat +usmrtit +usnadnit +usnout +usoudit +ustlat +ustrnout +utahovat +utkat +utlumit +utonout +utopenec +utrousit +uvalit +uvolnit +uvozovka +uzdravit +uzel +uzenina +uzlina +uznat +vagon +valcha +valoun +vana +vandal +vanilka +varan +varhany +varovat +vcelku +vchod +vdova +vedro +vegetace +vejce +velbloud +veletrh +velitel +velmoc +velryba +venkov +veranda +verze +veselka +veskrze +vesnice +vespodu +vesta +veterina +veverka +vibrace +vichr +videohra +vidina +vidle +vila +vinice +viset +vitalita +vize +vizitka +vjezd +vklad +vkus +vlajka +vlak +vlasec +vlevo +vlhkost +vliv +vlnovka +vloupat +vnucovat +vnuk +voda +vodivost +vodoznak +vodstvo +vojensky +vojna +vojsko +volant +volba +volit +volno +voskovka +vozidlo +vozovna +vpravo +vrabec +vracet +vrah +vrata +vrba +vrcholek +vrhat +vrstva +vrtule +vsadit +vstoupit +vstup +vtip +vybavit +vybrat +vychovat +vydat +vydra +vyfotit +vyhledat +vyhnout +vyhodit +vyhradit +vyhubit +vyjasnit +vyjet +vyjmout +vyklopit +vykonat +vylekat +vymazat +vymezit +vymizet +vymyslet +vynechat +vynikat +vynutit +vypadat +vyplatit +vypravit +vypustit +vyrazit +vyrovnat +vyrvat +vyslovit +vysoko +vystavit +vysunout +vysypat +vytasit +vytesat +vytratit +vyvinout +vyvolat +vyvrhel +vyzdobit +vyznat +vzadu +vzbudit +vzchopit +vzdor +vzduch +vzdychat +vzestup +vzhledem +vzkaz +vzlykat +vznik +vzorek +vzpoura +vztah +vztek +xylofon +zabrat +zabydlet +zachovat +zadarmo +zadusit +zafoukat +zahltit +zahodit +zahrada +zahynout +zajatec +zajet +zajistit +zaklepat +zakoupit +zalepit +zamezit +zamotat +zamyslet +zanechat +zanikat +zaplatit +zapojit +zapsat +zarazit +zastavit +zasunout +zatajit +zatemnit +zatknout +zaujmout +zavalit +zavelet +zavinit +zavolat +zavrtat +zazvonit +zbavit +zbrusu +zbudovat +zbytek +zdaleka +zdarma +zdatnost +zdivo +zdobit +zdroj +zdvih +zdymadlo +zelenina +zeman +zemina +zeptat +zezadu +zezdola +zhatit +zhltnout +zhluboka +zhotovit +zhruba +zima +zimnice +zjemnit +zklamat +zkoumat +zkratka +zkumavka +zlato +zlehka +zloba +zlom +zlost +zlozvyk +zmapovat +zmar +zmatek +zmije +zmizet +zmocnit +zmodrat +zmrzlina +zmutovat +znak +znalost +znamenat +znovu +zobrazit +zotavit +zoubek +zoufale +zplodit +zpomalit +zprava +zprostit +zprudka +zprvu +zrada +zranit +zrcadlo +zrnitost +zrno +zrovna +zrychlit +zrzavost +zticha +ztratit +zubovina +zubr +zvednout +zvenku +zvesela +zvon +zvrat +zvukovod +zvyk diff --git a/bip-0044.mediawiki b/bip-0044.mediawiki index 9e5af1f..4ddd56b 100644 --- a/bip-0044.mediawiki +++ b/bip-0044.mediawiki @@ -263,19 +263,6 @@ is required and a pull request to the above file should be created. |m / 44' / 1' / 1' / 1 / 1 |} -==Compatible wallets== - -* [[https://play.google.com/store/apps/details?id=com.mycelium.wallet|Mycelium Bitcoin Wallet (Android)]] ([[https://github.com/mycelium-com/wallet|source]]) -* [[https://copay.io/|Copay]] ([[https://github.com/bitpay/copay|source]]) -* [[https://www.coinvault.io/|CoinVault]] ([[https://github.com/CoinVault/dotblock|source]]) -* [[https://samouraiwallet.com/|Samourai Wallet]] ([[https://github.com/Samourai-Wallet/samourai-wallet-android|source]]) -* [[https://coinomi.com/|Coinomi]] ([[https://github.com/Coinomi/coinomi-android|source]]) -* [[https://trezor.io/|TREZOR]] ([[https://github.com/trezor/|source]]) -* [[https://www.keepkey.com/|KeepKey]] ([[https://github.com/keepkey/|source]]) -* [[https://www.ledgerwallet.com/|Ledger Wallet]] ([[https://github.com/LedgerHQ|source]]) -* [[https://21.co/learn/21-lib-wallet/|21 Machine Wallet]] ([[https://github.com/21dotco|source]]) -* [[https://trustwalletapp.com/|Trust Wallet]] ([[http://github.com/trustWallet/|source]]) - ==Reference== * [[bip-0032.mediawiki|BIP32 - Hierarchical Deterministic Wallets]] diff --git a/bip-0049.mediawiki b/bip-0049.mediawiki index 74645a1..0029003 100644 --- a/bip-0049.mediawiki +++ b/bip-0049.mediawiki @@ -2,10 +2,10 @@ BIP: 49 Layer: Applications Title: Derivation scheme for P2WPKH-nested-in-P2SH based accounts - Author: Daniel Weigl <Daniel.Weigl@mycelium.com> + Author: Daniel Weigl <DanielWeigl@gmx.at> Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0049 - Status: Draft + Status: Final Type: Informational Created: 2016-05-19 License: PD @@ -66,19 +66,28 @@ To derive the P2SH address from the above calculated public key, we use the enca scriptPubKey: HASH160 <20-byte-script-hash> EQUAL (0xA914{20-byte-script-hash}87) + +===Extended Key Version=== + +When serializing extended keys, this scheme uses alternate version bytes. Extended public keys use <code>0x049d7cb2</code> to produce a "ypub" prefix, and private keys use <code>0x049d7878</code> to produce a "yprv" prefix. Testnet uses <code>0x044a5262</code> "upub" and <code>0x044a4e28</code> "uprv." + +Additional registered version bytes are listed in [[https://github.com/satoshilabs/slips/blob/master/slip-0132.md|SLIP-0132]]. + + ==Backwards Compatibility== -This BIP is not backwards compatible by design as described under [#considerations]. An incompatible wallet will not discover accounts at all and the user will notice that something is wrong. +This BIP is not backwards compatible by design as described under [[#considerations|considerations]]. An incompatible wallet will not discover accounts at all and the user will notice that something is wrong. ==Test vectors== <pre> masterseedWords = abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon about - masterseed = tprv8ZgxMBicQKsPe5YMU9gHen4Ez3ApihUfykaqUorj9t6FDqy3nP6eoXiAo2ssvpAjoLroQxHqr3R5nE3a5dU3DHTjTgJDd7zrbniJr6nrCzd (testnet) + masterseed = uprv8tXDerPXZ1QsVNjUJWTurs9kA1KGfKUAts74GCkcXtU8GwnH33GDRbNJpEqTvipfCyycARtQJhmdfWf8oKt41X9LL1zeD2pLsWmxEk3VAwd (testnet) // Account 0, root = m/49'/1'/0' - account0Xpriv = tprv8gRrNu65W2Msef2BdBSUgFdRTGzC8EwVXnV7UGS3faeXtuMVtGfEdidVeGbThs4ELEoayCAzZQ4uUji9DUiAs7erdVskqju7hrBcDvDsdbY (testnet) + account0Xpriv = uprv91G7gZkzehuMVxDJTYE6tLivdF8e4rvzSu1LFfKw3b2Qx1Aj8vpoFnHdfUZ3hmi9jsvPifmZ24RTN2KhwB8BfMLTVqaBReibyaFFcTP1s9n (testnet) + account0Xpub = upub5EFU65HtV5TeiSHmZZm7FUffBGy8UKeqp7vw43jYbvZPpoVsgU93oac7Wk3u6moKegAEWtGNF8DehrnHtv21XXEMYRUocHqguyjknFHYfgY (testnet) // Account 0, first receiving private key = m/49'/1'/0'/0/0 account0recvPrivateKey = cULrpoZGXiuC19Uhvykx7NugygA3k86b3hmdCeyvHYQZSxojGyXJ diff --git a/bip-0069.mediawiki b/bip-0069.mediawiki index e9f9245..3aa9463 100644 --- a/bip-0069.mediawiki +++ b/bip-0069.mediawiki @@ -78,7 +78,7 @@ N.B. All comparisons do not need to operate in constant time since they are not ===Transaction Inputs=== -Transaction inputs are defined by the hash of a previous transaction, the output index of of a UTXO from that previous transaction, the size of an unlocking script, the unlocking script, and a sequence number. [3] +Transaction inputs are defined by the hash of a previous transaction, the output index of a UTXO from that previous transaction, the size of an unlocking script, the unlocking script, and a sequence number. [3] For sorting inputs, the hash of the previous transaction and the output index within that transaction are sufficient for sorting purposes; each transaction hash has an extremely high probability of being unique in the blockchain — this is enforced for coinbase transactions by BIP30 — and output indices within a transaction are unique. For the sake of efficiency, transaction hashes should be compared first before output indices, since output indices from different transactions are often equivalent, while all bytes of the transaction hash are effectively random variables. @@ -87,7 +87,7 @@ In the event of two matching transaction hashes, the respective previous output If the previous output indices match, the inputs are considered equal. Transaction malleability will not negatively impact the correctness of this process. -Even if a wallet client follows this process using unconfirmed UTXOs as inputs and an attacker changes modifies the blockchain’s record of the hash of the previous transaction, the wallet client will include the invalidated previous transaction hash in its input data, and will still correctly sort with respect to that invalidated hash. +Even if a wallet client follows this process using unconfirmed UTXOs as inputs and an attacker modifies the blockchain’s record of the hash of the previous transaction, the wallet client will include the invalidated previous transaction hash in its input data, and will still correctly sort with respect to that invalidated hash. ===Transaction Outputs=== diff --git a/bip-0074.mediawiki b/bip-0074.mediawiki index 01fcf2c..b6e9b39 100644 --- a/bip-0074.mediawiki +++ b/bip-0074.mediawiki @@ -5,7 +5,7 @@ Author: Toby Padilla <tobypadilla@gmail.com> Comments-Summary: Unanimously Discourage for implementation Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0074 - Status: Draft + Status: Rejected Type: Standards Track Created: 2016-01-29 License: PD diff --git a/bip-0075.mediawiki b/bip-0075.mediawiki index a516916..8c49645 100644 --- a/bip-0075.mediawiki +++ b/bip-0075.mediawiki @@ -8,7 +8,7 @@ James MacWhyte <macwhyte@gmail.com> Comments-Summary: Recommended for implementation (one person) Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0075 - Status: Draft + Status: Final Type: Standards Track Created: 2015-11-20 License: CC-BY-4.0 diff --git a/bip-0079.mediawiki b/bip-0079.mediawiki index 15948ad..99430d9 100644 --- a/bip-0079.mediawiki +++ b/bip-0079.mediawiki @@ -26,7 +26,7 @@ This document is licensed under the Creative Commons CC0 1.0 Universal license. One of the most powerful blockchain analysis heuristics has been to assume all inputs of a transaction are controlled by a single party unless otherwise known (such as by the distinctive structure of a traditional coinjoin, or multisig spends that are validated onchain). Combined with other techniques (notably change-output guessing) this has lead to unexpectedly accurate tracking that has exposed bitcoin participants to unacceptable personal, business and financial risks -- undermining bitcoin's utility and fungibility -- and ultimately jeopardizing its ability to function as useful money. -We however can bust these assumption with a sender-receiver coinjoin. To prevent costless spy/DoS attacks, we require the sending party to provide a fully-valid ready-to-propagate transaction to initiate the process, that the receiver can broadcast if the sender never completes the coinjoin thus tying the cost to that of spending a utxo. Most promisingly, bustapay transactions do not have an identifiable structure so any network analysis will be not able to tell if a given transaction is a bustapay transaction or not which erodes the confidence of their entire models, providing positive externalities for the entire bitcoin ecosystem. +We however can bust these assumptions with a sender-receiver coinjoin. To prevent costless spy/DoS attacks, we require the sending party to provide a fully-valid ready-to-propagate transaction to initiate the process, that the receiver can broadcast if the sender never completes the coinjoin thus tying the cost to that of spending a utxo. Most promisingly, bustapay transactions do not have an identifiable structure so any network analysis will be not able to tell if a given transaction is a bustapay transaction or not which erodes the confidence of their entire models, providing positive externalities for the entire bitcoin ecosystem. Bustapay transactions also do not grow the receiver's count of unspent transaction outputs, and in fact gives the receiver an opportunity to better manage their utxo set, something normally only done when sending payments. Large utxo sets are often problematic and expensive, and frequently requiring privacy-destroying consolidation. Besides busting clustering assumptions, bustapay also provides a layer of obfuscation of send amounts. diff --git a/bip-0102.mediawiki b/bip-0102.mediawiki index ed6b4e3..5a2c91a 100644 --- a/bip-0102.mediawiki +++ b/bip-0102.mediawiki @@ -5,7 +5,7 @@ Author: Jeff Garzik <jgarzik@gmail.com> Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0102 - Status: Draft + Status: Rejected Type: Standards Track Created: 2015-06-23 </pre> diff --git a/bip-0127.mediawiki b/bip-0127.mediawiki new file mode 100644 index 0000000..15c7755 --- /dev/null +++ b/bip-0127.mediawiki @@ -0,0 +1,226 @@ + +<pre> + BIP: 127 + Layer: Applications + Title: Simple Proof-of-Reserves Transactions + Author: Steven Roose <steven@stevenroose.org> + Comments-Summary: No comments yet. + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0127 + Status: Draft + Type: Standards Track + Created: 2019-01-28 + License: CC0-1.0 +</pre> + + +==Abstract== + +This BIP describes a simple way to construct proof-of-reserves transactions. +This proposal formalizes a standard format for constructing such proofs, easing +their construction with existing wallet infrastructure and enabling general +proof-verification software. It relies on existing standards such as regular +Bitcoin transaction serialization/validation and the BIP 174 PSBT format. +The proposal also includes the description of a PSBT extension for a better +user experience. + +==Copyright== + +This BIP is licensed under the Creative Commons CC0 1.0 Universal license. + +==Motivation== + +From the very early days in the history of Bitcoin, there have been companies +managing bitcoins for their users. These users give up control over their coins +in return for a certain service. Inevitably, there have been many cases of +companies losing their users' bitcoins without timely disclosing such events to +the public. Proofs of Reserves are a way for companies managing large amounts +of bitcoins to prove ownership over a given amount of funds. The regular proof +of control helps to ensure that no significant loss has occurred. + +While the term proof-of-reserves is not new by any means, the procedure is not +very common among high-value custodian companies. One of the reasons for this +is that every company that wants to perform a proof-of-reserves has to construct +its own way to do so. Accordingly, their users have to understand the +construction of the proof in order to be able to verify it. This raises the bar +of entry both for custodians and for users. + + +===What this BIP is not doing=== + +The proof-of-reserve construction described in this document has some known +shortcomings, mostly with regards to its privacy properties. While there exists +research about improved proof-of-reserves mechanisms that have much better +privacy properties<ref>Dagher, Gaby G., Benedikt Bünz, Joseph Bonneau, Jeremy +Clark, and Dan Boneh. "Provisions: Privacy-preserving proofs of solvency for +Bitcoin exchanges." (2015).</ref>, this BIP intentionally only formalizes +the de-facto existing method. + + +==Specification== + +Our specification consists of two parts: +# the format for the actual proofs +# a file format used to package a set of proofs and relevant metadata + +The final construction should have the following properties: +* flexible proof construction to support complex wallet infrastructures +* easy integration with existing wallet solutions (both hardware and software wallets) +* support for verification via a standard procedure, regardless of publisher of the proof +* proof prevents reuse of proofs by other parties by committing to a message +* allow validating that the issuer had the funds under his control at a certain block, regardless of what happened after that block + +===Proof Format=== + +To allow for maximal compatibility with existing systems, proofs are formatted as regular Bitcoin +transactions. However, one small adaptation to the transaction is made that has two functions: +# make the transaction unspendable to avoid putting funds at risk +# link the proof to the issuer of the proof to prevent copying proofs from other custodians + +The resulting construction is a Bitcoin transaction with the following +characteristics: + +* The first input (the "commitment input") +** MUST have the txid part of the previous outpoint set to the SHA-256 hash of the commitment message prefixed with "Proof-of-Reserves: "<ref>If the message is "Some Message", the txid part should be <tt>SHA-256("Proof-of-Reserves: Some Message")</tt> with the string encoded as UTF-8.</ref> and index 0. +* The remaining inputs +** MUST have signatures that commit to the commitment input (e.g. using <tt>SIGHASH_ALL</tt>). +* The transaction MUST have a single output that is the exact sum of all the inputs, assuming the commitment input to have 0 value; this means the transaction has no miner fee. + +The existence of the first input (which is just a commitment hash) ensures +that this transaction is invalid and can never be confirmed. + + +===Proof File Format=== + +In theory, the first part of the specification would be sufficient as a minimum +viable standard. However, there are a number of motivations to extend the +standard with an extra layer of metadata: + +# constructing and combining multiple proofs +#:Having thousands of UTXOs spread across different offline and online wallets could make it difficult to construct a single proof transaction with all UTXOs. Allowing multiple proof transactions with the same commitment message and block number gives extra flexibility to custodians with complex wallet infrastructure without making the combined proof less secure. +# metadata for verification +#:Not all systems that will be used for verification have access to a full index of all transactions. However, proofs should be easily verifiable even after some of the UTXOs used in the proof are no longer unspent. Metadata present in the proof allows for relatively efficient verification of proofs even if no transaction index is available. +# potential future improvements +#:The extensible metadata format allows for amending the standard in the future. One potential improvement would be having UTXO set commitments. These would allow the proofs-of-reserves to come with accompanying proofs-of-inclusion of all used UTXOs in the UTXO set at the block of proof construction (making validation even more efficient). + +The proposed proof-file format provides a standard way of combining multiple +proofs and associated metadata. The specification of the format is in the +Protocol Buffers<ref>https://github.com/protocolbuffers/protobuf/</ref> format. + +<pre> +syntax = "proto3"; +import "google/protobuf/any.proto"; + +message OutputMeta { + // Identify the outpoint. + bytes txid = 1; + uint32 vout = 2; + + // The block hash of the block where this output was created. + bytes block_hash = 3; +} + +message FinalProof { + // The proof transaction. Should be able to be parsed like a regular + // Bitcoin transaction. + bytes proof_tx = 1; + + // The metadata of the ouputs used in the proof transaction. + repeated OutputMeta output_metadata = 2; +} + +message ProofOfReserves { + // A version number for this format to enable extending it with + // additional fields. + uint32 version = 1; + + // The network magic for the network in which the proofs are valid. + // 0xD9B4BEF9 for mainnet, 0x0709110B for testnet + //TODO consider BIP44 coin type ids instead: + // https://github.com/satoshilabs/slips/blob/master/slip-0044.md + uint32 network_magic = 2; + + // The commitment message for this proof-of-reserves. + // This message is global for all the proofs. + string message = 3; + + // The block at which this proof is supposed to be validated. + // Verification should take into account unspentness of outputs at this + // block height. + bytes block_hash = 4; + + // The set of final proof transactions with their output metadata. + repeated FinalProof final_proofs = 5; + + // Reserved field that can potentially be used by proof-construction tools. + // It can be ignored for verification. + repeated google.protobuf.Any pending_proofs = 6; +} +</pre> + +The last field, <tt>pending_proofs</tt>, leaves open some space in the same +file that can be used by proof-construction tools. This allows them to +construct different proofs incrementally without having to switch between file +formats. + + +===PSBT (BIP 174) extension=== + +The "commitment input" detailed in the proof format section does not spend an +existing UTXO and thus shouldn't be signed (empty <tt>scriptSig</tt> and +witness). This can cause some problems when signing this type of transactions. +For example, hardware wallets often require the signer to provide information +about all inputs of transactions they are signing, such as the previous output +or previous transaction; this data obviously doesn't exist for the commitment +inputs. + +For most existing devices, it's possible to circumvent these requirements by +providing dummy data or by instructing the device to ignore this specific +input. However, there is still a UX problem. Because the hardware wallet +device doesn't recognize the transaction as a proof-of-reserves transaction it +will think it is signing a regular transaction that is spending all the money +in the UTXOs. Most devices will ask for confirmation with a message along the +lines of "Are you sure you want to send XXX BTC to address [...]?". This is +not the best user experience. + +An addition to the BIP 174 PSBT format could help signing devices to recognize proof-of-reserve transactions. +The following field is added to the BIP 174 <tt>INPUT</tt> map: + +* 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. +*** <tt>{porCommitment}</tt> + +Wallets processing an input that has this field set +* MUST make sure the txid of the previous outpoint is set to the SHA-256 hash of the prefixed commitment message string, as detailed above; +* MUST assume the input value to be 0 (without requiring the previous output or transaction to be provided); +* SHOULD display the commitment message to ask the user for confirmation before signing any inputs; +* SHOULD only provide signatures with a signature hash that commits to this input; +* SHOULD accept an empty <tt>scriptSig</tt> for this input (as if the <tt>scriptPubKey</tt> was <tt>OP_TRUE</tt>). + + +==Compatibility== + +The proof transaction specification is based on the Bitcoin transaction +serialization protocol and will thus always be compatible with serializers +that can interpret Bitcoin transactions. The protobuf file format is custom +to this BIP and has a version byte to enable updates while attempting to remain +backwards compatible. + + +==Implementations== + +A proof-of-concept implementation of the PSBT extension in the +[https://github.com/rust-bitcoin/rust-bitcoin rust-bitcoin] project can be +found in the <tt>psbt-por</tt> branch here: +https://github.com/stevenroose/rust-bitcoin/tree/psbt-por + +A work-in-progress implementation of a tool that produces and verifies proofs +in the described format can be found here: +https://github.com/stevenroose/reserves + + +== Footnotes == + +<references /> + diff --git a/bip-0136.mediawiki b/bip-0136.mediawiki new file mode 100644 index 0000000..f94171d --- /dev/null +++ b/bip-0136.mediawiki @@ -0,0 +1,328 @@ +<pre> + BIP: 136 + Layer: Applications + Title: Bech32 Encoded Tx Position References + Author: Велеслав <veleslav.bips@protonmail.com> + Jonas Schnelli <dev@jonasschnelli.ch> + Daniel Pape <dpape@dpape.com> + Comments-Summary: No comments yet. + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0136 + Status: Draft + Type: Informational + Created: 2017-07-09 + License: BSD-2-Clause +</pre> + +== 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. + +''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.'' + +=== 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. + +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). + +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. + +=== 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> + +== 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. + +''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: + +* The specified block hasn't yet been mined. Or, +* 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: + +* 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. + +=== 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: + +* Human-readable Part, or "HRP", that provides namespacing. We have chosen to distinguish between Main and Test Networks: +** For Any Mainnet Network: '''"tx"'''. +** For Any Testnet Network: '''"txtest"'''. +** Please see [https://github.com/satoshilabs/slips/blob/master/slip-0173.md SLIP-0173 : Registered human-readable parts for BIP-0173] for a full list of HRP's including these two and others relating to other projects. +* Separator: '''"1"'''. +* Data Part. + +Please note: other specifications, such as [https://w3c-ccg.github.io/did-spec/ the Decentralized Identifiers spec], have implicitly encoded the information contained within the HRP elsewhere. In this case they may choose to not include the HRP as specified here. + +To increase portability and readability additional separators SHOULD be added: + +* A Colon<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. + +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 +|- +|Human Readable Part +| +|1 – 2 +|2 +|Bitcoin Mainnet: "'''tx'''", Bitcoin Testnet: "'''txtest'''" +|- +|Separator +| +|3 +|1 +|"'''1'''" +|- +|Colon +| +|4 +|1 +|"''':'''" +|- +|Data +|0 – 19 +|5 – 8 +|4 +| +|- +|Hyphen +| +|9 +|1 +|"'''-'''" +|} +The Data - Hyphen pattern is repeated for the entire length of data, ( a hyphen is inserted after every encoded 20 bits or 4 data characters). +=== Data === + +Depending on if an optional transaction outpoint is included, there can be 75 or 90 bits of data encoded in the string above. These bits are defined in this manner: + +{| class="wikitable" +|+TxRef Binary Format for Bitcoin Mainnet and Bitcoin Testnet: +! +!'''Bit''' +!'''Bit(s)''' +!'''Type''' +!'''Values''' +!'''Notes''' +|- +|Magic Code +|0 – 4 +|5 +|Chain Namespacing Code +|'''0x3''' for Bitcoin Mainnet. +'''0x4''' for Bitcoin Mainnet with Outpoint. +'''0x6''' for Bitcoin Testnet. +'''0x7''' for Bitcoin Testnet with Outpoint. +| +|- +|Version +|5 +|1 +|For Future Use +|Must be '''0x0''' +| +|- +|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 +|} +If the magic code is '''0x4''' or '''0x7''', an optional outpoint is included in the encoding: + +{| 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 +| +|} + +We include the 30-bit checksum last: +{| class="wikitable" +|+Bech32 Checksum Encoding: +! +!'''Bit''' +!'''Bit(s)''' +!'''Type''' +!'''Values''' +!'''Notes''' +|- +|Checksum +|45 – 74 or 60 – 89 +|30 +|Bech32 Checksum +| +| +|} + +==== 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. + +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.'' + +Other magic codes will be specified in SLIP-XXXX "TxRef for Non-Bitcoin Chains and Networks". + +=== Compatibility === +There are no known compatibility issues. + +== 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/ + +== Appendices == + +=== 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. + +==== 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.'' + +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 list gives invalid TxRef's and the reason for their invalidity. +* <tt>bc1qw508d6qejxtdg4y5r3zarvary0c5xw7kg3g4ty</tt>: Invalid human-readable part +* <tt>tx1qw508d6qejxtdg4y5r3zarvary0c5xw7kv8f3t5</tt>: Invalid checksum + +==== 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-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 Bitcoin testnet TxRef's and the values in hex. (block height, transaction index) + +* <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 (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 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. + +==== 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-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-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: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) + +* <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-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:8jk0-uqay-zrfq-xjhr-gq</tt>: <tt>(0x71F69, 0x89D, 0x123)</tt> +* <tt>txtest1:8jk0-uqay-zu4x-aw4h-zl</tt>: <tt>(0x71F69, 0x89D, 0x1ABC)</tt> + + +=== Bitcoin TxRef Payload Value Choice: === +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). + +*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). + +==== Tx Position Value: ==== +15-bit: between 0x0, and 0x7FFF. (32,768 transactions). + +*The ''realistic'' smallest Tx is 83 Bytes: Max 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. +**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 == +Special Thanks to Pieter Wuille and Greg Maxwell for Bech32, a wonderful user-facing data encoding. diff --git a/bip-0143.mediawiki b/bip-0143.mediawiki index ed07c82..81763a0 100644 --- a/bip-0143.mediawiki +++ b/bip-0143.mediawiki @@ -391,7 +391,7 @@ This example shows how unexecuted <code>OP_CODESEPARATOR</code> is processed, an 02 4730440220032521802a76ad7bf74d0e2c218b72cf0cbc867066e2e53db905ba37f130397e02207709e2188ed7f08f4c952d9d13986da504502b8c3be59617e043552f506c46ff83 275163ab68210392972e2eb617b2388771abe27235fd5ac44af8e61693261550447a4c3e39da98ac nLockTime: 00000000 - Since SINGLE|ANYONECANPAY does not commit to the input index, the signatures are still valid when the the input-output pairs are swapped: + Since SINGLE|ANYONECANPAY does not commit to the input index, the signatures are still valid when the input-output pairs are swapped: 0100000000010280e68831516392fcd100d186b3c2c7b95c80b53c77e77c35ba03a66b429a2a1b0000000000ffffffffe9b542c5176808107ff1df906f46bb1f2583b16112b95ee5380665ba7fcfc0010000000000ffffffff0280969800000000001976a9146648a8cd4531e1ec47f35916de8e259237294d1e88ac80969800000000001976a914de4b231626ef508c9a74a8517e6783c0546d6b2888ac024730440220032521802a76ad7bf74d0e2c218b72cf0cbc867066e2e53db905ba37f130397e02207709e2188ed7f08f4c952d9d13986da504502b8c3be59617e043552f506c46ff83275163ab68210392972e2eb617b2388771abe27235fd5ac44af8e61693261550447a4c3e39da98ac02483045022100f6a10b8604e6dc910194b79ccfc93e1bc0ec7c03453caaa8987f7d6c3413566002206216229ede9b4d6ec2d325be245c5b508ff0339bf1794078e20bfe0babc7ffe683270063ab68210392972e2eb617b2388771abe27235fd5ac44af8e61693261550447a4c3e39da98ac00000000 nVersion: 01000000 marker: 00 diff --git a/bip-0144.mediawiki b/bip-0144.mediawiki index 75d8a1b..8ec2191 100644 --- a/bip-0144.mediawiki +++ b/bip-0144.mediawiki @@ -79,7 +79,7 @@ The serialization has the following structure: Parsers supporting this BIP will be able to distinguish between the old serialization format (without the witness) and this one. The marker byte is set to zero so that this structure will never parse as a valid transaction in a parser that does not support this BIP. If parsing were to succeed, such a transaction would contain no inputs and a single output. -If the witness is empty, the old serialization format should be used. +If the witness is empty, the old serialization format must be used. Currently, the only witness objects type supported are script witnesses which consist of a stack of byte arrays. It is encoded as a var_int item count followed by each item encoded as a var_int length followed by a string of bytes. Each txin has its own script witness. The number of script witnesses is not explicitly encoded as it is implied by txin_count. Empty script witnesses are encoded as a zero byte. The order of the script witnesses follows the same order as the associated txins. diff --git a/bip-0151.mediawiki b/bip-0151.mediawiki index 2d29951..005c552 100644 --- a/bip-0151.mediawiki +++ b/bip-0151.mediawiki @@ -5,7 +5,7 @@ Author: Jonas Schnelli <dev@jonasschnelli.ch> Comments-Summary: Controversial; some recommendation, and some discouragement Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0151 - Status: Draft + Status: Withdrawn Type: Standards Track Created: 2016-03-23 License: PD diff --git a/bip-0155.mediawiki b/bip-0155.mediawiki new file mode 100644 index 0000000..5914241 --- /dev/null +++ b/bip-0155.mediawiki @@ -0,0 +1,189 @@ +<pre> + BIP: 155 + Layer: Peer Services + Title: addrv2 message + Author: Wladimir J. van der Laan <laanwj@gmail.com> + Comments-Summary: No comments yet. + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0155 + Status: Draft + Type: Standards Track + Created: 2019-02-27 + License: BSD-2-Clause +</pre> + +==Introduction== + +===Abstract=== + +This document proposes a new P2P message to gossip longer node addresses over the P2P network. +This is required to support new-generation Onion addresses, I2P, and potentially other networks +that have longer endpoint addresses than fit in the 128 bits of the current <code>addr</code> message. + +===Copyright=== + +This BIP is licensed under the 2-clause BSD license. + +===Motivation=== + +Tor v3 hidden services are part of the stable release of Tor since version 0.3.2.9. They have +various advantages compared to the old hidden services, among which better encryption and privacy +<ref>[https://gitweb.torproject.org/torspec.git/tree/rend-spec-v3.txt Tor Rendezvous Specification - Version 3]</ref>. +These services have 256 bit addresses and thus do not fit in the existing <code>addr</code> message, which encapsulates onion addresses in OnionCat IPv6 addresses. + +Other transport-layer protocols such as I2P have always used longer +addresses. This change would make it possible to gossip such addresses over the +P2P network, so that other peers can connect to them. + +==Specification== + +<blockquote> +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<ref>[https://tools.ietf.org/html/rfc2119 RFC 2119]</ref>. +</blockquote> + +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 +fixed 16-byte IP address is replaced by a network ID and a variable-length address, and the time and services format has been changed to VARINT. + +This means that the message contains a serialized <code>std::vector</code> of the following structure: + +{| class="wikitable" style="width: auto; text-align: center; font-size: smaller; table-layout: fixed;" +!Type +!Name +!Description +|- +| <code>VARINT</code> (unsigned) +| <code>time</code> +| Time that this node was last seen as connected to the network. A time in Unix epoch time format, up to 64 bits wide. +|- +| <code>VARINT</code> (unsigned) +| <code>services</code> +| Service bits. A 64-wide bit field. +|- +| <code>uint8_t</code> +| <code>networkID</code> +| Network identifier. An 8-bit value that specifies which network is addressed. +|- +| <code>std::vector<uint8_t></code> +| <code>addr</code> +| Network address. The interpretation depends on networkID. +|- +| <code>uint16_t</code> +| <code>port</code> +| Network port. If not relevant for the network this MUST be 0. +|} + +One message can contain up to 1,000 addresses. Clients SHOULD reject messages with more addresses. + +Field <code>addr</code> has a variable length, with a maximum of 32 bytes (256 bits). Clients SHOULD reject +longer addresses. + +The list of reserved network IDs is as follows: + +{| class="wikitable" style="width: auto; text-align: center; font-size: smaller; table-layout: fixed;" +!Network ID +!Enumeration +!Address length (bytes) +!Description +|- +| <code>0x01</code> +| <code>IPV4</code> +| 4 +| IPv4 address (globally routed internet) +|- +| <code>0x02</code> +| <code>IPV6</code> +| 16 +| IPv6 address (globally routed internet) +|- +| <code>0x03</code> +| <code>TORV2</code> +| 10 +| Tor v2 hidden service address +|- +| <code>0x04</code> +| <code>TORV3</code> +| 32 +| Tor v3 hidden service address +|- +| <code>0x05</code> +| <code>I2P</code> +| 32 +| I2P overlay network address +|- +| <code>0x06</code> +| <code>CJDNS</code> +| 16 +| Cjdns overlay network address +|} + +To allow for future extensibility, clients MUST ignore address types that they do not know about. +Client MAY store and gossip address formats that they do not know about. Further network ID numbers MUST be reserved in a new BIP document. + +Clients SHOULD reject addresses that have a different length than specified in this table for a specific address ID, as these are meaningless. + +See the appendices for the address encodings to be used for the various networks. + +==Compatibility== + +Send <code>addrv2</code> messages only, and exclusively, when the peer has a certain protocol version (or higher): +<source lang="c++"> +//! gossiping using `addrv2` messages starts with this version +static const int GOSSIP_ADDRV2_VERSION = 70016; +</source> +For older peers keep sending the legacy <code>addr</code> message, ignoring addresses with the newly introduced address types. + +==Reference implementation== + +The reference implementation is available at (to be done) + +==Acknowledgements== + +- Jonas Schnelli: change <code>services</code> field to VARINT, to make the message more compact in the likely case instead of always using 8 bytes. + +- Luke-Jr: change <code>time</code> field to VARINT, for post-2038 compatibility. + +- Gregory Maxwell: various suggestions regarding extensibility + +==Appendix A: Tor v2 address encoding== + +The new message introduces a separate network ID for <code>TORV2</code>. + +Clients MUST send Tor hidden service addresses with this network ID, with the 80-bit hidden service ID in the address field. This is the same as the representation in the legacy <code>addr</code> message, minus the 6 byte prefix of the OnionCat wrapping. + +Clients SHOULD ignore OnionCat (<code>fd87:d87e:eb43::/48</code>) addresses on receive if they come with the <code>IPV6</code> network ID. + +==Appendix B: Tor v3 address encoding== + +According to the spec <ref>[https://gitweb.torproject.org/torspec.git/tree/rend-spec-v3.txt Tor Rendezvous Specification - Version 3: Encoding onion addresses]</ref>, next-gen <code>.onion</code> addresses are encoded as follows: +<pre> +onion_address = base32(PUBKEY | CHECKSUM | VERSION) + ".onion" + CHECKSUM = H(".onion checksum" | PUBKEY | VERSION)[:2] + + where: + - PUBKEY is the 32 bytes ed25519 master pubkey of the hidden service. + - VERSION is an one byte version field (default value '\x03') + - ".onion checksum" is a constant string + - CHECKSUM is truncated to two bytes before inserting it in onion_address +</pre> + +Tor v3 addresses MUST be sent with the <code>TORV3</code> network ID, with the 32-byte PUBKEY part in the address field. As VERSION will always be '\x03' in the case of v3 addresses, this is enough to reconstruct the onion address. + +==Appendix C: I2P address encoding== + +Like Tor, I2P naming uses a base32-encoded address format<ref>[https://geti2p.net/en/docs/naming#base32 I2P: Naming and address book]</ref>. + +I2P uses 52 characters (256 bits) to represent the full SHA-256 hash, followed by <code>.b32.i2p</code>. + +I2P addresses MUST be sent with the <code>I2P</code> network ID, with the decoded SHA-256 hash as address field. + +==Appendix D: Cjdns address encoding== + +Cjdns addresses are simply IPv6 addresses in the <code>fc00::/8</code> range<ref>[https://github.com/cjdelisle/cjdns/blob/6e46fa41f5647d6b414612d9d63626b0b952746b/doc/Whitepaper.md#pulling-it-all-together Cjdns whitepaper: Pulling It All Together]</ref>. They MUST be sent with the <code>CJDNS</code> network ID. + +==References== + +<references/> diff --git a/bip-0158.mediawiki b/bip-0158.mediawiki index 6c3202b..ad46da6 100644 --- a/bip-0158.mediawiki +++ b/bip-0158.mediawiki @@ -27,9 +27,8 @@ enables basic wallets and applications with more advanced smart contracts. [[bip-0157.mediawiki|BIP 157]] defines a light client protocol based on deterministic filters of block content. The filters are designed to minimize the expected bandwidth consumed by light clients, downloading filters -and full blocks. This document defines two initial filter types, ''basic'' and -''extended'', to provide support for advanced applications while reducing the -filter size for regular wallets. +and full blocks. This document defines the initial filter type ''basic'' +that is designed to reduce the filter size for regular wallets. == Definitions == @@ -348,7 +347,7 @@ Light client: [https://github.com/lightninglabs/neutrino] Full-node indexing: https://github.com/Roasbeef/btcd/tree/segwit-cbf -Golomb-Rice Coded sets: https://github.com/Roasbeef/btcutil/tree/gcs/gcs +Golomb-Rice Coded sets: https://github.com/btcsuite/btcutil/blob/master/gcs == Appendix A: Alternatives == diff --git a/bip-0173.mediawiki b/bip-0173.mediawiki index ad6c58b..c3ee060 100644 --- a/bip-0173.mediawiki +++ b/bip-0173.mediawiki @@ -209,7 +209,7 @@ implementations' assumptions about lengths), but still be visually distinct.</ref> for testnet. * The data-part values: ** 1 byte: the witness version -** A conversion of the the 2-to-40-byte witness program (as defined by [https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki BIP141]) to base32: +** 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. *** Translate those bits to characters using the table above. diff --git a/bip-0174.mediawiki b/bip-0174.mediawiki index e6dd44f..deb3065 100644 --- a/bip-0174.mediawiki +++ b/bip-0174.mediawiki @@ -118,6 +118,12 @@ The currently defined global types are as follows: *** <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 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 int}|...|{32-bit int}</tt> + The currently defined per-input types are defined as follows: * Type: Non-Witness UTXO <tt>PSBT_IN_NON_WITNESS_UTXO = 0x00</tt> @@ -174,6 +180,12 @@ The currently defined per-input types are defined as follows: ** 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> + 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: @@ -313,6 +325,8 @@ For a Signer to only produce valid signatures for what it expects to sign, it mu * If a witness UTXO is provided, no non-witness signature may be created * If a redeemScript is provided, the scriptPubKey must be for that redeemScript * If a witnessScript is provided, the scriptPubKey or the redeemScript must be for that witnessScript +* If a sighash type is provided, the signer must check that the sighash is acceptable. If unacceptable, they must fail. +* If a sighash type is not provided, the signer should sign using SIGHASH_ALL, but may use any sighash type they wish. =====Simple Signer Algorithm===== @@ -320,18 +334,22 @@ A simple signer can use the following algorithm to determine what and how to sig <pre> sign_witness(script_code, i): - for key in psbt.inputs[i].keys: - if IsMine(key): + for key, sighash_type in psbt.inputs[i].items: + if sighash_type == None: + sighash_type = SIGHASH_ALL + if IsMine(key) and IsAcceptable(sighash_type): sign(witness_sighash(script_code, i, input)) sign_non_witness(script_code, i): - for key in psbt.inputs[i].keys: - if IsMine(key): + for key, sighash_type in psbt.inputs[i].items: + if sighash_type == None: + sighash_type = SIGHASH_ALL + if IsMine(key) and IsAcceptable(sighash_type): sign(non_witness_sighash(script_code, i, input)) for input,i in enumerate(psbt.inputs): if non_witness_utxo.exists: - assert(sha256d(non_witness_utxo) == psbt.tx.innput[i].prevout.hash) + 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) @@ -352,6 +370,23 @@ for input,i in enumerate(psbt.inputs): assert False </pre> +====Change Detection==== + +Signers may wish to display the inputs and outputs to users for extra verification. +In such displays, signers may wish to identify which outputs are change outputs in order to omit them to avoid additional user confusion. +In order to detect change, a signer can use the BIP 32 derivation paths provided in inputs and outputs as well as the extended public keys provided globally. + +For a single key output, a signer can observe whether the master fingerprint for the public key for that output belongs to itself. +If it does, it can then derive the public key at the specified derivation path and check whether that key is the one present in that output. + +For outputs involving multiple keys, a signer can first examine the inputs that it is signing. +It should determine the general pattern of the script and internally produce a representation of the policy that the script represents. +Such a policy can include things like how many keys are present, what order they are in, how many signers are necessary, which signers are required, etc. +The signer can then use the BIP 32 derivation paths for each of the pubkeys to find which global extended public key is the one that can derive that particular public key. +To do so, the signer would extract the derivation path to the highest hardened index and use that to lookup the public key with that index and master fingerprint. +The signer would construct this script policy with extended public keys for all of the inputs and outputs. +Change outputs would then be identified as being the outputs which have the same script policy as the inputs that are being signed. + ===Combiner=== The Combiner can accept 1 or many PSBTs. @@ -511,6 +546,10 @@ The following are valid PSBTs: ** Bytes in Hex: <pre>70736274ff0100550200000001279a2323a5dfb51fc45f220fa58b0fc13e1e3342792a85d7e36cd6333b5cbc390000000000ffffffff01a05aea0b000000001976a914ffe9c0061097cc3b636f2cb0460fa4fc427d2b4588ac0000000000010120955eea0b0000000017a9146345200f68d189e1adc0df1c4d16ea8f14c0dbeb87220203b1341ccba7683b6af4f1238cd6e97e7167d569fac47f1e48d47541844355bd4646304302200424b58effaaa694e1559ea5c93bbfd4a89064224055cdf070b6771469442d07021f5c8eb0fea6516d60b8acb33ad64ede60e8785bfb3aa94b99bdf86151db9a9a010104220020771fd18ad459666dd49f3d564e3dbc42f4c84774e360ada16816a8ed488d5681010547522103b1341ccba7683b6af4f1238cd6e97e7167d569fac47f1e48d47541844355bd462103de55d1e1dac805e3f8a58c1fbf9b94c02f3dbaafe127fefca4995f26f82083bd52ae220603b1341ccba7683b6af4f1238cd6e97e7167d569fac47f1e48d47541844355bd4610b4a6ba67000000800000008004000080220603de55d1e1dac805e3f8a58c1fbf9b94c02f3dbaafe127fefca4995f26f82083bd10b4a6ba670000008000000080050000800000</pre> ** Base64 String: <pre>cHNidP8BAFUCAAAAASeaIyOl37UfxF8iD6WLD8E+HjNCeSqF1+Ns1jM7XLw5AAAAAAD/////AaBa6gsAAAAAGXapFP/pwAYQl8w7Y28ssEYPpPxCfStFiKwAAAAAAAEBIJVe6gsAAAAAF6kUY0UgD2jRieGtwN8cTRbqjxTA2+uHIgIDsTQcy6doO2r08SOM1ul+cWfVafrEfx5I1HVBhENVvUZGMEMCIAQktY7/qqaU4VWepck7v9SokGQiQFXN8HC2dxRpRC0HAh9cjrD+plFtYLisszrWTt5g6Hhb+zqpS5m9+GFR25qaAQEEIgAgdx/RitRZZm3Unz1WTj28QvTIR3TjYK2haBao7UiNVoEBBUdSIQOxNBzLp2g7avTxI4zW6X5xZ9Vp+sR/HkjUdUGEQ1W9RiED3lXR4drIBeP4pYwfv5uUwC89uq/hJ/78pJlfJvggg71SriIGA7E0HMunaDtq9PEjjNbpfnFn1Wn6xH8eSNR1QYRDVb1GELSmumcAAACAAAAAgAQAAIAiBgPeVdHh2sgF4/iljB+/m5TALz26r+En/vykmV8m+CCDvRC0prpnAAAAgAAAAIAFAACAAAA=</pre> +* Case: PSBT with one P2WSH input of a 2-of-2 multisig. witnessScript, keypaths, and global xpubs are available. Contains no signatures. Outputs filled. +** Bytes in Hex: <pre>70736274ff01005202000000019dfc6628c26c5899fe1bd3dc338665bfd55d7ada10f6220973df2d386dec12760100000000ffffffff01f03dcd1d000000001600147b3a00bfdc14d27795c2b74901d09da6ef133579000000004f01043587cf02da3fd0088000000097048b1ad0445b1ec8275517727c87b4e4ebc18a203ffa0f94c01566bd38e9000351b743887ee1d40dc32a6043724f2d6459b3b5a4d73daec8fbae0472f3bc43e20cd90c6a4fae000080000000804f01043587cf02da3fd00880000001b90452427139cd78c2cff2444be353cd58605e3e513285e528b407fae3f6173503d30a5e97c8adbc557dac2ad9a7e39c1722ebac69e668b6f2667cc1d671c83cab0cd90c6a4fae000080010000800001012b0065cd1d000000002200202c5486126c4978079a814e13715d65f36459e4d6ccaded266d0508645bafa6320105475221029da12cdb5b235692b91536afefe5c91c3ab9473d8e43b533836ab456299c88712103372b34234ed7cf9c1fea5d05d441557927be9542b162eb02e1ab2ce80224c00b52ae2206029da12cdb5b235692b91536afefe5c91c3ab9473d8e43b533836ab456299c887110d90c6a4fae0000800000008000000000220603372b34234ed7cf9c1fea5d05d441557927be9542b162eb02e1ab2ce80224c00b10d90c6a4fae0000800100008000000000002202039eff1f547a1d5f92dfa2ba7af6ac971a4bd03ba4a734b03156a256b8ad3a1ef910ede45cc500000080000000800100008000</pre> +** 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> @@ -698,6 +737,11 @@ Any data types, their associated scope and BIP number must be defined here | PSBT_IN_FINAL_SCRIPTWITNESS | BIP 174 |- +| Input +| 9 +| PSBT_IN_POR_COMMITMENT +| [[bip-0127.mediawiki|BIP 127]] +|- | Output | 0 | PSBT_OUT_REDEEM_SCRIPT diff --git a/bip-0178.mediawiki b/bip-0178.mediawiki index 439774e..5522664 100644 --- a/bip-0178.mediawiki +++ b/bip-0178.mediawiki @@ -3,7 +3,7 @@ Layer: Applications Title: Version Extended WIF Author: Karl-Johan Alm <karljohan-alm@garage.co.jp> - Comments-Summary: No comments yet. + Comments-Summary: Discouraged for implementation (one person) Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0178 Status: Draft Type: Standards Track diff --git a/bip-0301.mediawiki b/bip-0301.mediawiki new file mode 100644 index 0000000..d6056f2 --- /dev/null +++ b/bip-0301.mediawiki @@ -0,0 +1,226 @@ +<pre> + BIP: 301 + Layer: Consensus (soft fork) + Title: Blind Merged Mining (Consensus layer) + Author: Paul Sztorc <truthcoin@gmail.com> + CryptAxe <cryptaxe@gmail.com> + Comments-Summary: No comments yet. + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0301 + Status: Draft + Type: Standards Track + Created: 2019-07-23 + License: BSD-2-Clause +</pre> + +==Abstract== + + +Blind Merged Mining (BMM) is a way of mining optional extension blocks (ie, "asymmetric sidechains"). BMM produces weak guarantees that the block is valid, for *any* arbitrary set of rules; and yet it does so without requiring miners to actually do any validation on the block whatsoever. + +BMM actually is a process that spans two or more chains. Here we focus on the modifications to mainchain Bitcoin. For an explanation of the "whole picture", please see [http://www.truthcoin.info/blog/blind-merged-mining/ this post]. + +Our goal here, is to allow mainchain miners to trustlessly "sell" the act of finding a sidechain block. + + +==Motivation== + +Regular "Merged-Mining" (MM) allows miners to reuse their hashing work to secure other chains (for example, as in Namecoin). However, traditional MM has two drawbacks: + +# Miners must run a full node of the other chain. (This is because [while miners can effortlessly create the block] miners will not create a valid payment to themselves, unless the block that they MM is a valid one. Therefore, miners must assemble a *valid* block first, then MM it.) +# Miners are paid on the other chain, not on the regular BTC mainchain. For example, miners who MM Namecoin will earn NMC (and they will need to sell the NMC for BTC, before selling the BTC in order to pay for electricity). + +BMM addresses both shortcomings. + + +==Specification== + +Note: This document uses the notation side:\* and main:\* in front of otherwise-ambiguous words (such as "block", "node", or "chain"), to distinguish the mainchain version from its sidechain counterpart. We also use "Simon" to refer to a Sidechain Full Node, and "Mary" to refer to a mainchain miner. + + +=== BMM Request === + +To buy the right to find a sidechain block, users broadcast BMM Requests. + +Here, these can take two forms. The first does not require the Lightning Network, but it does have new requirements for Immediate Expiration (see below). The second inherits Immediate Expiration from the Lightning Network itself, but requires extra preparation and a different/larger message. + +Both forms require that certain Critical Data will be committed to within the coinbase of the block that the transaction is included in (see BMM Accept). For the OnChain (non-Lightning) version, we have created a new extended serialization transaction type (very similar to how SegWit handles witness data (the witness stack)). + +==== Immediate Expiration ("Fill-or-Kill") ==== + +We would like to make special guarantees to the counterparties of this transaction. Specifically, instead of Simon making a "payment" to Mary, we prefer that Simon give Mary an "offer" (which she can either accept or decline). + +Crucially, we want Simon to safely make many offers to several different Mary's, in realtime (ie, quickly and off-chain). However, we ultimately want only one offer to be accepted, at most. In other words, we want Simon's offers to *immediately expire*. If only one offer can become a bona fide transaction, then Simon will feel comfortable making multiple offers all day long. Because all of the Simons are making many offers, the Marys collectively gain access to a large set of offers to choose from. + +==== OnChain BMM Request ==== + +OnChain BMMRs do not require the Lightning network, but they do have new requirements for validation. + +===== Structure ===== + +The following data is required: + +<pre> + 32-bytes - h* sideHeaderHash + ?~?-bytes - critical data extended serialization + 3-bytes - 0x00bf00 identifying bytes + 1-byte - nSidechain + 2-bytes - prevSideBlockRef + 4-bytes - prevMainHeaderBytes +</pre> + +sideHeaderHash comes from side:chain (side:nodes build side:blocks/headers). The identifying bytes are given here. nSidechain identifies which sidechain we are BMMing. By the time Blind Merged Mining can take place, it is known globally. + +prevBlockRef, is a little more complicated (next section). + +To qualify for inclusion in a block, BMM requests are subject to the following requirements: + +# Requests must match a corresponding "BMM Accept" (see last section of BIP). +# At most, only one Request is allowed in a main:block, per sidechain. In other words, if 700 users broadcast BMM Requests for sidechain #4, then the main:miner must choose one single Request to include. +# The 4-bytes of prevMainHeaderBytes must match the last four bytes of the previous main:blockheader. Thus, Simon's txns are only be valid for the current block, in the block history that he knows about (and therefore, the current sidechain history that he knows about). + +===== prevBlockRef ===== + +prevBlockRef is an integer that counts the number of "skips" one must take in the side:chain in order to find the current side:block's parent block. This value is zero unless the sidechain is reorganizing (or skipping over invalid sidechain blocks). If a side:node wants to orphan the most-recent N blocks, the value of the current block will be equal to N; in the block after that it will be back to zero. + +<img src="bip-0301/bmm-dots-examples.png?raw=true" align="middle"></img> + +Above: Three blockchains, with different max length (small number), reorganization histories, and prevBlockRef numbers (larger numbers beneath blocks). The ordering given via each side:block's "prevSideBlockRef" will be isomorphic to an ordering given by each side:block's "prevSideHeaderHash" ("prevSideHeaderHash is the sidechain's equivalent of the mainchain's "prevBlockHash"). One can freely convert from one to the other. + +===== Extended Serialization ===== + +To impose new requirements at the transaction level, we borrow the dummy vin & "flag" trick from SegWit style transactions. Unless all of the requirements for sidechain critical data transactions are met by the block it is included in, the transaction is invalid. With SegWit, this extra data is the SegWit signature stack, and the extra requirements are the signatures' locations and validity. In the sidechain BMM critical data transactions, the extra data is the (nSidechain, h\*) pair, which must meet the first two requirements (above) as well as the main:blocknumber, which must meet the third requirement (above). + +<img src="bip-0301/witness-vs-critical.png?raw=true" align="middle"></img> + +Above: A chart showing normal txns, SegWit txns, and CriticalData txns. The specific SegWit txn can be seen [http://srv1.yogh.io/#tx:id:D4A99AE93DF6EE3D4E42CE69338DFC1D06CCD9B198666E98FF0588057378D3D9 here]. + +These types of transactions have slightly different mempool behavior, and should probably be kept in a second mempool. These txns are received, checked immediately, and if valid they are evaluated for inclusion in a block. If they are not able to be included in the specific requested block (if the block height requested has been surpassed by the chain tip), they are discarded. In fact, after any main:block is found, everything in this "second mempool" can be discarded as new payments will be created immediately for the next block height. (This includes cases where the blockchain reorganizes.) There is no re-evaluation of the txns in this mempool ever -- they are evaluated once and then either included or discarded. They never need to be rescanned. + +Interestingly, these payments will *always* be directed to main:miners from non-main:miners. Therefore, non-mining full nodes do not need to keep them in any mempool at all. Non-miner nodes can just wait for a block to be found, and check the txn then. These transactions more resemble a stock market's pit trade-offers (in contrast, regular Bitcoin txns are more like paper checks). + +==== Lightning BMM Request ==== + +Lightning BMMRs require Simons to have a LN-channel pathways open with Marys. This may not always be practical (or even possible), especially today. + +LN txns cannot make use of prevSideBlockRef, as no one knows for sure when (or if) they will be broadcast on-chain. Instead, they must use prevSideBlockHash. But they otherwise require the same data: + +<pre> + 4-bytes - Message header (0xD0520C6E) + 1-byte - sidechain number + 32-bytes - h* side:block hash + 32-bytes - prevSideBlockHash +</pre> + +Notice that, in OnChain BMMRs, Simon could reuse the same h\* all he wanted, because only one OnChain BMMR could be included per main:block per sidechain. However, on the LN no such rule can be enforced, as the goal is to push everything off-chain and include *zero* txns. So, we will never know what the Requests were, or how many had an effect on anything. + +Therefore, Simon will need to ensure that he '''gives each Mary a different h\*'''. Simon can easily do this, as he controls the side:block's contents and can simply increment a side:nonce -- this changes the side:block, and changes its hash (ie, changes h\*). + +With a unique h\* per Mary (or, more precisely, per channel), and at most 1 h\* making it into a block (per sidechain), Simon can ensure that he is charged, at most, one time. + +That's probably confusing, so here is an example, in which: Simon starts with 13 BTC, Mary starts with 40 BTC, the side:block's tx-fees currently total 7.1 BTC, and Simon is keeping 0.1 BTC for himself and paying 7 BTC to Mary. + +We start with (I): + +<pre> + Simon 13 in, Mary 40 in ; 53 in total + Simon's version [signed by Mary] + 13 ; to Simon if TimeLock=over; OR to Mary if SimonSig + 40 ; to Mary + Mary's version [signed by Simon] + 40 ; to me if TimeLock=over; OR to Simon if MarySig + 13 ; to Simon +</pre> + + +And both parties move, from there to (II): + +<pre> + Simon 13 in, Mary 40 in ; 53 in total + Simon's version [signed by Mary] + 6 ; to Simon if TimeLock=over; OR to Mary if SimonSig + 40 ; to Mary + 7 ; to Mary if critical data requirements met; OR to Simon if LongTimeLock=over + Mary's version [signed by Simon] + 40 ; to Mary if TimeLock=over; OR to Simon if MarySig + 6 ; to Simon + 7 ; to Mary if critical data requirements met; OR to Simon if LongTimeLock=over +</pre> + + +From here, if the h\* side:block in question is BMMed, they can proceed to (III): + +<pre> + Simon 13 in, Mary 40 in ; 53 in total + Simon's version [signed by Mary] + 6 ; to Simon if TimeLock=over; OR to Mary if SimonSig + 47 ; to Mary + Mary's version [signed by Simon] + 47 ; to me if TimeLock=over; OR to Simon if MarySig + 6 ; to Simon +</pre> + +If Simon proceeds immediately, he removes Mary's incentive to care about blocks being built on this side:block. If Simon's side:block is orphaned, he loses his 7 BTC. Simon can either play it safe, and wait for (for example) 100 side:blocks before moving on (ie, before moving on to the third LN txn, above); or else Simon can take the risk if he feels comfortable with it. + +If the h\* side:block is not found, then (II) and (III) are basically equivalent to each other. Simon and Mary could jointly reconstruct (I) and go back there, or they could proceed to a new version of II (with a different h\*, trying again with new side:block in the next main:block). + +Now that we have described Requests, we can describe how they are accepted. + +=== BMM Accept === + +For each BMM Request that a main:miner "accepts", main:miners must place an OP Return output into their main:coinbase txn. (We've changed the tx-standardness policy to allow multiple OP_RETURNs.) + +The following data is required in the "accept" OP_RETURN output: + 1-byte - OP_RETURN (0x6a) + 1-byte - Push the following 36 bytes (0x24) + 4-bytes - Message header (0xD3407053) + 32-bytes - h* + ~5-bytes - BMM identifier bytes + + +[https://github.com/DriveNetTESTDRIVE/DriveNet/blob/564516653c1d876429382971a011f5f6119f7eb4/src/validation.cpp#L3377-L3470 Link to code]. + +If these OP_RETURN outputs are not present, then no BMM Requests have been accepted. (And, if they are not accepted, then they cannot be included in a main:block.) + + +==Backward compatibility== + +As a soft fork, older software will continue to operate without modification. As stated above, BMM asks nodes to track a set of ordered hashes, and to allow miners to "sell" the act of finding a sidechain block. Non-upgraded nodes will notice that this activity (specifically: data in coinbases, and new txns that have OP Returns and interesting message headers) is now taking place, but they will not understand any of it. Much like P2SH or a new OP Code, these old users will not be directly affected by the fork, as they will have no expectations of receiving payments of this kind. + +(As a matter of fact, the only people receiving money here all happen to be miners. So there is less reason than ever to expect compatibility problems.) + + +==Deployment== + +This BIP will be deployed by "version bits" BIP9 with the name "blindmm" and using bit 4. + +<pre> +// Deployment of Drivechains (BIPX, BIPY) +consensus.vDeployments[Consensus::DEPLOYMENT_DRIVECHAINS].bit = 4; +consensus.vDeployments[Consensus::DEPLOYMENT_DRIVECHAINS].nStartTime = 1579072881; // January 15th, 2020. +consensus.vDeployments[Consensus::DEPLOYMENT_DRIVECHAINS].nTimeout = 1610695281; // January 15th, 2021. +</pre> + + +==Reference Implementation== + +See: https://github.com/DriveNetTESTDRIVE/DriveNet + +Also, for interest, see an example sidechain here: https://github.com/drivechain-project/bitcoin/tree/sidechainBMM + + +==References== + +* http://www.drivechain.info/literature/index.html +* http://www.truthcoin.info/blog/blind-merged-mining/ +* https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-July/014789.html +* http://www.truthcoin.info/images/bmm-outline.txt + + +==Thanks== + +Thanks to everyone who contributed to the discussion, especially: ZmnSCPxj, Adam Back, Peter Todd, Dan Anderson, Sergio Demian Lerner, Matt Corallo, Sjors Provoost, Tier Nolan, Erik Aronesty, Jason Dreyzehner, Joe Miyamoto, Chris Stewart, Ben Goldhaber. + + +==Copyright== + +This BIP is licensed under the BSD 2-clause license. diff --git a/bip-0301/bmm-dots-examples.png b/bip-0301/bmm-dots-examples.png Binary files differnew file mode 100644 index 0000000..70f11f6 --- /dev/null +++ b/bip-0301/bmm-dots-examples.png diff --git a/bip-0301/images.txt b/bip-0301/images.txt new file mode 100644 index 0000000..2fbbf63 --- /dev/null +++ b/bip-0301/images.txt @@ -0,0 +1 @@ +Images used as reference in the documentation. diff --git a/bip-0301/witness-vs-critical.png b/bip-0301/witness-vs-critical.png Binary files differnew file mode 100644 index 0000000..79c84b1 --- /dev/null +++ b/bip-0301/witness-vs-critical.png diff --git a/bip-0322.mediawiki b/bip-0322.mediawiki index 5191143..aaf5496 100644 --- a/bip-0322.mediawiki +++ b/bip-0322.mediawiki @@ -15,6 +15,17 @@ A standard for interoperable generic signed messages based on the Bitcoin Script format. +== Background == + +* Assume two actors, a prover <code>P</code> and a verifier <code>V</code>. +* <code>P</code> wants to prove that they own the private key <code>k</code> associated with a given address <code>A</code> (which in turn is derived from the pubkey <code>kG</code>). +* Let <code>V</code> generate a message <code>M</code> and hand this to <code>P</code>. +* <code>P</code> generates a signature <code>S</code> by signing the message <code>M</code> using <code>k</code>. Given <code>S</code>, <code>V</code> can prove that <code>P</code> has the private key associated with <code>A</code>. + +The astute reader will notice that the above is missing a critical part, namely the pubkey <code>kG</code>, without which the verifier cannot actually verify the message. The current message signing standard solves this via a cryptographic trick, wherein the signature <code>S</code> above is a special "recoverable signature" type. Given the message <code>M</code> and the signature <code>S</code>, it is then possible to recover the pubkey <code>kG</code>. The system thus derives the address for the pubkey <code>kG</code>, and if it does not match <code>A</code>, the proof is deemed invalid. + +While this is a neat trick, it unnecessarily restricts and complicates the message signing mechanism; for instance, it is currently not possible to sign a message for a P2SH address, because there is no pubkey to recover from the resulting signature. + == Motivation == The current message signing standard only works for P2PKH (1...) addresses. By extending it to use a Bitcoin Script based approach, it could be made more generic without causing a too big burden on implementers, who most likely have access to Bitcoin Script interpreters already. @@ -23,7 +34,7 @@ The current message signing standard only works for P2PKH (1...) addresses. By e A new structure <code>SignatureProof</code> is added, which is a simple serializable scriptSig & witness container. -Two actions "Sign" and "Verify" are defined along with two *purposes* "SignMessage" and "ProveFunds". +Two actions "Sign" and "Verify" are defined along with one ''purpose'', "SignMessage", with the ability to expand in the future to add a potential "ProveFunds" purpose. === SignatureProof container === @@ -34,13 +45,9 @@ Two actions "Sign" and "Verify" are defined along with two *purposes* "SignMessa !Name !Comment |- -|Uint32||4||flags||standard flags (1-to-1 with standard flags in Bitcoin Core) +|Uint32||4||version||BIP322 version format; must be equal to 1; if > 1, verifier must abort the verification process |- -|VarInt||1-8||msglen||Number of bytes in message string, excluding NUL termination -|- -|Char*||[msglen]||msg||The message being signed for all subjects, excluding NUL termination -|- -|Uint8||1||entries||Number of proof entries<ref><strong>Why support multiple proofs?</strong> In particular with proof of funds, it is non-trivial to check a large number of individual proofs (one per UTXO) for duplicates. Software could be written to do so, but it seems more efficient to build this check into the specification itself.</ref> +|Uint8||1||entries||number of proof entries<ref><strong>Why support multiple proofs?</strong> It is non-trivial to check a large number of individual proofs for duplicates. Software could be written to do so, but it seems more efficient to build this check into the specification itself.</ref> |} The above is followed by [entries] number of signature entries: @@ -56,9 +63,9 @@ The above is followed by [entries] number of signature entries: |- |Uint8*||[scriptsiglen]||scriptsig||ScriptSig data |- -|VarInt||1-8||witlen||Number of bytes in witness data +|VarInt||1-8||witlen||Number of entries in witness stack |- -|Uint8*||[witlen]||wit||Witness +|Uint8[]*||[witlen]||wit||Witness stack, as [witlen] uint8* vectors, each one prepended with a varint of its size |} In some cases, the scriptsig or wit may be empty. If both are empty, the proof is incomplete. @@ -74,42 +81,30 @@ A verification call will return a result code according to the table below. |- |INCOMPLETE||One or several of the given challenges had an empty proof. The prover may need some other entity to complete the proof. |- -|INCONCLUSIVE||One or several of the given proofs used unknown opcodes or the scriptPubKey had an unknown witness version, perhaps due to the verifying node being outdated. +|INCONCLUSIVE||One or several of the given proofs was consensus-valid but policy-invalid. |- |VALID||All proofs were deemed valid. |- |INVALID||One or more of the given proofs were invalid |- -|SPENT||One or more of the claimed UTXO:s has been spent -|- |ERROR||An error was encountered |} == Signing and Verifying == -Let there be an empty set `inputs` which is populated and tested at each call to one of the actions below. +If the challenge consists of a single address and the address is in the P2PKH (legacy) format, sign using the legacy format (further information below). Otherwise continue as stated below. + +Let there be an empty set <code>inputs</code> which is populated and tested at each call to one of the actions below. === Purpose: SignMessage === The "SignMessage" purpose generates a sighash based on a scriptPubKey and a message. It emits a VALID verification result code unless otherwise stated. -# Return INVALID if scriptPubKey already exists in `inputs` set, otherwise insert it<ref><strong>Why track duplicates?</strong> Because a 3-entry proof is not proving 3 inputs unless they are all distinct</ref> -# Define the message pre-image as the sequence "Bitcoin Message:" concatenated with the message, encoded in UTF-8 using Normalization Form Compatibility Decomposition (NFKD) +# Return INVALID if scriptPubKey already exists in <code>inputs</code> set, otherwise insert it<ref><strong>Why track duplicates?</strong> Because a 3-entry proof is not proving 3 entries unless they are all distinct</ref> +# Define the message pre-image as the sequence "Bitcoin Signed Message:\n" concatenated with the message, encoded in UTF-8 using Normalization Form Compatibility Decomposition (NFKD) # Let sighash = sha256(sha256(scriptPubKey || pre-image)) -=== Purpose: ProveFunds === - -The "ProveFunds" purpose generates a sighash and a scriptPubKey from a transaction, an output index, and a message. For multiple simultaneous proofs, it also requires access to the ordered list of proofs. It emits a VALID verification result code unless otherwise stated. - -# Let txid be the transaction ID of the transaction, and vout be the output index corresponding to the index of the output being spent -# Return INVALID if the txid:vout pair already exists in `inputs` set, otherwise insert it -# Return SPENT if the txid/vout is not a valid UTXO according to a Bitcoin node<ref><strong>Synced up or not?</strong> A normal verifier would use a synced up node. An auditor checking records from a client that were submitted in the past want to use a node that is synced up to the block corresponding to the proof, or the proof will fail, even if it may have been valid at the time of creation.</ref> -# Extract scriptPubKey from transaction output -# Define the message pre-image as the concatenation of the following components:<ref><strong>Why not just the UTXO data?</strong> We want the verifier to be able to challenge the prover with a custom message to sign, or anyone can reuse the POF proof for a set of UTXO:s once they have seen it, and the funds have not yet been spent</ref> -#* the string "POF:" -#* the message, encoded in UTF-8 using Normalization Form Compatibility Decomposition (NFKD), including the null terminating character (i.e. write strlen(message) + 1 bytes, for a C string) -#* all transactions being proven for, as binary txid (little endian uint256) followed by index (little endian uint32), each separated by a single `0x00` byte -# Let sighash = sha256(sha256(scriptPubKey || pre-image)) +A private key may be used directly to sign a message. In this case, its P2WPKH bech32 address shall be derived, and used as the input. === Action: Sign === @@ -119,15 +114,20 @@ The "Sign" action takes as input a purpose. It returns a signature or fails. # Derive the private key privkey for the scriptPubKey; FAIL if not VALID # Generate and return a signature sig with privkey=privkey, sighash=sighash +The resulting signature proof should be encoded using base64 encoding. + === Action: Verify === The "Verify" action takes as input a standard flags value, a script sig, an optional witness, and a purpose. It emits one of INCONCLUSIVE, VALID, INVALID, or ERROR. +While omitted below, ERROR is returned if an unforeseen error occurs at any point in the process. A concrete example of this is if a legacy proof is given as input to a non-legacy address; the deserialization of the proof will fail in this case, and this should result in an ERROR result. + # Obtain the sighash and scriptPubKey from the purpose; pass on result code if not VALID -# If one or more of the standard flags are unknown, return INCONCLUSIVE -# Verify Script with flags=standard flags, scriptSig=script sig, scriptPubKey=scriptPubKey, witness=witness, and sighash=sighash -# Return VALID if verify succeeds, otherwise return INVALID +# Verify Script with flags=consensus flags (currently P2SH, DERSIG, NULLDUMMY, CLTV, CSV, WITNESS), scriptSig=script sig, scriptPubKey=scriptPubKey, witness=witness, and sighash=sighash +# Return INVALID if verification fails +# Verify Script with flags=standard flags (above plus STRICTENC, MINIMALDATA, etc.), scriptSig=script sig, scriptPubKey=scriptPubKey, witness=witness, and sighash=sighash +# Return VALID if verification succeeds, otherwise return INCONCLUSIVE === Multiple Proofs === @@ -139,13 +139,40 @@ Note that the order of the entries in the proof must match the order of the entr * If a verification call returns ERROR or INVALID, return ERROR or INVALID immediately, ignoring as yet unverified entries * After all verifications complete, ** return INCONCLUSIVE if any verification call returned INCONCLUSIVE -** return SPENT if any verification call returned SPENT ** return INCOMPLETE if the INCOMPLETE flag is set ** return VALID +== Legacy format == + +The legacy format is restricted to the legacy P2PKH address format, and restricted to one single challenge (address). + +Any other input (e.g. multiple addresses, or non-P2PKH address format(s)) must be signed using the new format described above. + +=== Signing === + +Given the P2PKH 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("Bitcoin Signed Message:\n"||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. + +=== Verifying === + +Given the P2PKH 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>: + +# 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("Bitcoin Signed Message:\n"||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 + == Compatibility == -This specification is not backwards compatible with the legacy signmessage/verifymessage specification. However, legacy addresses (1...) may be used in this implementation without any problems. +This specification is backwards compatible with the legacy signmessage/verifymessage specification through the special case as described above. == Rationale == @@ -153,17 +180,108 @@ This specification is not backwards compatible with the legacy signmessage/verif == Reference implementation == -To do. +# Pull request to Bitcoin Core: https://github.com/bitcoin/bitcoin/pull/16440 == Acknowledgements == -TODO +Thanks to David Harding, Jim Posen, Kalle Rosenbaum, Pieter Wuille, and many others for their feedback on the specification. == References == # Original mailing list thread: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-March/015818.html -# Pull request, with comments: https://github.com/bitcoin/bips/pull/725 == Copyright == 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 policy flags (which result in a transaction being accepted only if it is contained within an actual block, and rejected otherwise, if violated). The policy flags are a super-set of the consensus flags. + +BIP322 specifies that a proof that validates for both rulesets is valid, a proof that validates for consensus rules, but not for policy rules, is "inconclusive", and a proof that does not validate for consensus rules is "invalid" (regardless of policy 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]) + +=== Policy 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 == + +== Native segwit test vector == + +<pre> +address = bcrt1qe7nte4zk4ayly5tc53dtdjupgkz0lr8azx3rzz +scriptpubkey = 0014cfa6bcd456af49f25178a45ab6cb814584ff8cfd +message = hello +preimage = 0014cfa6bcd456af49f25178a45ab6cb814584ff8cfd426974636f696e205369 + 676e6564204d6573736167653a0a68656c6c6f + (scriptpubkey || "Bitcoin Signed Message:\nhello") +sighash = 790eef86c204f0bff969ff822121317aa34eff0215dbd30ccf031e7b2f3f0cc1 + (sha256d(preimage), displayed in big-endian) +</pre> + +The proof becomes: + +<pre> +HEX: 01000000010002473044022075b4fb40421d55c55462879cb352a85eeb3af2138d3f0290 + 2c9143f12870f5f70220119c2995c1661138142f3899c1fd6d1af7e790e0e081be72db9c + e7bf5b5b932901210290beccd02b73eca57467b2b6f1e47161a9b76a5e67586e7c1dee9e + a6e2dcd869 + +Base64: AQAAAAEAAkcwRAIgdbT7QEIdVcVUYoecs1KoXus68hONPwKQLJFD8Shw9fcCIBGcKZXBZhE4 + FC84mcH9bRr355Dg4IG+ctuc579bW5MpASECkL7M0Ctz7KV0Z7K28eRxYam3al5nWG58He6e + puLc2Gk= +</pre> + +Split into components: + +{|class="wikitable" style="text-align: center;" +|- +!Type +!Length +!Name +!Value +!Comment +|- +|Uint32||4||flags||<code>01000000</code>||proof format version +|- +|Uint8||1||entries||<code>01</code>||1 entry +|- +|VarInt||1-8||scriptsiglen||<code>00</code>||0 byte scriptsig +|- +|VarInt||1-8||wit entries||<code>02</code>||2 witness stack entries +|- +|VarInt||1-8||entry1len||<code>47</code>||71 byte entry +|- +|Uint8[71]||71||entry1||<code>3044022075b4fb40421d55c55462879cb352a85eeb3af213 +8d3f02902c9143f12870f5f70220119c2995c1661138142f +3899c1fd6d1af7e790e0e081be72db9ce7bf5b5b932901</code>||Witness stack item 1 +|- +|VarInt||1-8||entry2len||<code>21</code>||33 byte entry +|- +|Uint8[33]||33||entry2||<code>0290beccd02b73eca57467b2b6f1e47161a9b76a5e67586e +7c1dee9ea6e2dcd869</code>||Witness stack item 2 +|} + +The above test vector is for a bech32 P2WPKH (native segwit) address. (Once BIP solidifies, will add test vector for other types.) diff --git a/scripts/link-format-chk.sh b/scripts/link-format-chk.sh new file mode 100755 index 0000000..86f28be --- /dev/null +++ b/scripts/link-format-chk.sh @@ -0,0 +1,23 @@ +#!/usr/bin/env bash +# +# Copyright (c) 2019 The Bitcoin Core developers +# Distributed under the MIT software license, see the accompanying +# file COPYING or http://www.opensource.org/licenses/mit-license.php. +# +# Check wrong mediawiki link format + +ECODE=0 +FILES="" +for fname in $(git diff --name-only HEAD $(git merge-base HEAD master)); do + if [[ $fname == *.mediawiki ]]; then + GRES=$(grep -n '](' $fname) + if [ "$GRES" != "" ]; then + if [ $ECODE -eq 0 ]; then + >&2 echo "Github Mediawiki format writes link as [URL text], not as [text](url):" + fi + ECODE=1 + echo "- $fname:$GRES" + fi + fi +done +exit $ECODE |
