diff options
| author | Luke Dashjr <luke-jr+git@utopios.org> | 2020-01-23 23:59:10 +0000 |
|---|---|---|
| committer | Luke Dashjr <luke-jr+git@utopios.org> | 2020-01-23 23:59:10 +0000 |
| commit | d81cf9da5ee18c9af8f57a63bdb8adc80d80156b (patch) | |
| tree | 438801e16254da7b60c2c73035f129b7142bc255 | |
| parent | ffa91573d2cb349d9322c4d6f775ece23f99027e (diff) | |
| parent | 24eddbb48a1d686f70bf33172de602d865a244b4 (diff) | |
| download | bips-d81cf9da5ee18c9af8f57a63bdb8adc80d80156b.tar.xz | |
Merge branch 'master' into HEAD
44 files changed, 4270 insertions, 113 deletions
diff --git a/.travis.yml b/.travis.yml index ed99de0..70d339a 100644 --- a/.travis.yml +++ b/.travis.yml @@ -1,7 +1,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 2e28c5f..46cc389 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 @@ -449,26 +449,33 @@ Those proposing changes should consider that ultimately consent may rest with th | Informational | Draft |- style="background-color: #ffcfcf" +| [[bip-0100.mediawiki|100]] +| Consensus (hard fork) +| Dynamic maximum block size by miner vote +| Jeff Garzik, Tom Harding, Dagur Valberg Johannsson +| Standard +| Rejected +|- style="background-color: #ffcfcf" | [[bip-0101.mediawiki|101]] | Consensus (hard fork) | Increase maximum block size | 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 +|- style="background-color: #ffcfcf" | [[bip-0103.mediawiki|103]] | Consensus (hard fork) | Block size following technological growth | Pieter Wuille | Standard -| Draft +| Withdrawn |- | [[bip-0104.mediawiki|104]] | Consensus (hard fork) @@ -658,6 +665,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 @@ -756,12 +770,19 @@ Those proposing changes should consider that ultimately consent may rest with th | Matt Corallo | Standard | Draft -|- +|- style="background-color: #ffcfcf" | [[bip-0154.mediawiki|154]] | Peer Services | Rate Limiting via peer specified challenges | Karl-Johan Alm | Standard +| Withdrawn +|- +| [[bip-0155.mediawiki|155]] +| Peer Services +| addrv2 message +| Wladimir J. van der Laan +| Standard | Draft |- | [[bip-0156.mediawiki|156]] @@ -834,6 +855,13 @@ Those proposing changes should consider that ultimately consent may rest with th | Standard | Draft |- +| [[bip-0179.mediawiki|179]] +| +| Name for payment recipient identifiers +| Emil Engler, MarcoFalke, Luke Dashjr +| Informational +| Draft +|- | [[bip-0180.mediawiki|180]] | Peer Services | Block size/weight fraud proof @@ -855,6 +883,20 @@ Those proposing changes should consider that ultimately consent may rest with th | Standard | Draft |- +| [[bip-0300.mediawiki|300]] +| Consensus (soft fork) +| Hashrate Escrows (Consensus layer) +| Paul Sztorc, CryptAxe +| 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 @@ -875,6 +917,20 @@ Those proposing changes should consider that ultimately consent may rest with th | Karl-Johan Alm | Standard | Draft +|- +| [[bip-0325.mediawiki|325]] +| Applications +| Signet +| Karl-Johan Alm +| Standard +| Draft +|- +| [[bip-0330.mediawiki|330]] +| Peer Services +| Transaction announcements reconciliation +| Gleb Naumenko, Pieter Wuille +| Standard +| Draft |} <!-- IMPORTANT! See the instructions at the top of this page, do NOT JUST add BIPs here! --> 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-0032.mediawiki b/bip-0032.mediawiki index 18b3b0c..9339307 100644 --- a/bip-0032.mediawiki +++ b/bip-0032.mediawiki @@ -294,7 +294,7 @@ Two JavaScript implementations exist: available at https://github.com/sarchar/br A PHP implementation is available at https://github.com/Bit-Wasp/bitcoin-lib-php -A C# implementation is available at https://github.com/NicolasDorier/NBitcoin (ExtKey, ExtPubKey) +A C# implementation is available at https://github.com/MetacoSA/NBitcoin (ExtKey, ExtPubKey) A Haskell implementation is available at https://github.com/haskoin/haskoin together with a CLI interface at https://github.com/np/hx 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-0045.mediawiki b/bip-0045.mediawiki index f4d200c..d721582 100644 --- a/bip-0045.mediawiki +++ b/bip-0045.mediawiki @@ -16,7 +16,7 @@ This BIP defines a structure for hierarchical deterministic P2SH multi-party multi-signature wallets (HDPM wallets from now on) based on the algorithm -described in BIP-0032 (BIP32 from now on) and purpose scheme described in +described in BIP-0032 (BIP32 from now on) and purpose scheme described in BIP-0043 (BIP43 from now on). This BIP is a particular application of BIP43. @@ -63,7 +63,7 @@ Hardened derivation is used at this level. The index of the party creating a P2SH multisig address. The indices can be determined independently by lexicographically sorting the purpose public keys of each cosigner. Each cosigner creates addresses on its own branch, -even though they have independent extended master public key, as explained +even though they have independent extended master public key, as explained in the "Address generation" section. Note that the master public key is not shared amongst the cosigners. Only the @@ -79,12 +79,12 @@ purpose public keys: 03f76588e06c0d688617ef365d1e58a7f1aa84daa3801380b1e7f12acc9a69cd13 </pre> -it should use `m / 45 ' / 0 / *` for -`039863fb5f07b667d9b1ca68773c6e6cdbcac0088ffba9af46f6f6acd153d44463`, -`m / 45 ' / 1 / *` for -`03a473275a750a20b7b71ebeadfec83130c014da4b53f1c4743fcf342af6589a38`, -and `m / 45 ' / 2 / *` for -`03f76588e06c0d688617ef365d1e58a7f1aa84daa3801380b1e7f12acc9a69cd13`, +it should use <code>m / 45 ' / 0 / *</code> for +<code>039863fb5f07b667d9b1ca68773c6e6cdbcac0088ffba9af46f6f6acd153d44463</code>, +<code>m / 45 ' / 1 / *</code> for +<code>03a473275a750a20b7b71ebeadfec83130c014da4b53f1c4743fcf342af6589a38</code>, +and <code>m / 45 ' / 2 / *</code> for +<code>03f76588e06c0d688617ef365d1e58a7f1aa84daa3801380b1e7f12acc9a69cd13</code>, as dictated by their lexicographical order. @@ -102,7 +102,7 @@ chain is used for addresses which are not meant to be visible outside of the wallet and is used for return transaction change. For example, if cosigner 2 wants to generate a change address, he would use -`m / 45 ' / 2 / 1 / *`, and `m / 45 ' / 2 / 0 / *` for a receive +<code>m / 45 ' / 2 / 1 / *</code>, and <code>m / 45 ' / 2 / 0 / *</code> for a receive address. Non-hardened derivation is used at this level. @@ -118,7 +118,7 @@ Non-hardened derivation is used at this level. Each party generates their own extended master keypair and shares the extended purpose' public key with the others, which is stored encrypted. Each party can generate any of the other's derived public keys, but only -his own private keys. +his own private keys. ===Address Generation Procedure=== When generating an address, each party can independently generate the N needed @@ -137,18 +137,18 @@ others using the next index, and calculate the needed script for the address. Example: Cosigner #2 wants to receive a payment to the shared wallet. His last used index on his own branch is 4. Then, the path for the next receive -address is `m/45'/2/0/5`. He uses this same path in all of the cosigners +address is <code>m/45'/2/0/5</code>. He uses this same path in all of the cosigners trees to generate a public key for each one, and from that he gets the new p2sh address. ====Change address case==== Again, each cosigner generates addresses only on his own branch. One of the n cosigners wants to create an outgoing payment, for which he'll need a change address. He generates a new address using the same procedure as above, but -using a separate index to track the used change addresses. +using a separate index to track the used change addresses. Example: Cosigner #5 wants to send a payment from the shared wallet, for which he'll need a change address. His last used change index on his own branch is -11. Then, the path for the next change address is `m/45'/5/1/12`. He uses +11. Then, the path for the next change address is <code>m/45'/5/1/12</code>. He uses this same path in all of the cosigners trees to generate a public key for each one, and from that he gets the new p2sh address. @@ -163,7 +163,7 @@ that specific address (using the same path that generated the public key in that address, but deriving the private key instead), and sign it. Once the proposal reaches m signatures, any cosigner can broadcast it to the network, becoming final. The specifics of how this proposal is structured, and the -protocol to accept or reject it, belong to another BIP, in my opinion. +protocol to accept or reject it, belong to another BIP, in my opinion. ===Address discovery=== @@ -171,8 +171,8 @@ When the master seed is imported from an external source the software should start to discover the addresses in the following manner: # for each cosigner: -# derive the cosigner's node (`m / 45' / cosigner_index`) -# for both the external and internal chains on this node (`m / 45' / cosigner_index / 0` and `m / 45' / cosigner_index / 1`): +# derive the cosigner's node (<code>m / 45' / cosigner_index</code>) +# for both the external and internal chains on this node (<code>m / 45' / cosigner_index / 0</code> and <code>m / 45' / cosigner_index / 1</code>): # scan addresses of the chain; respect the gap limit described below Please note that the algorithm uses the transaction history, not address @@ -182,7 +182,7 @@ even if the earlier ones don't have transactions ===Address gap limit=== -Address gap limit is currently set to 20. If the software hits 20 unused +Address gap limit is currently set to 20. If the software hits 20 unused addresses (no transactions associated with that address) in a row, it expects there are no used addresses beyond this point and stops searching the address chain. @@ -198,7 +198,7 @@ parties. Here are some explanations about the design decisions made. The reason for using separate branches for each cosigner is we don't want two of them generating the same address and receiving simultaneous payments to it. The ideal case is that each address receives at most one payment, -requested by the corresponding cosigner. +requested by the corresponding cosigner. ==Examples== 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-0100.mediawiki b/bip-0100.mediawiki new file mode 100644 index 0000000..aaf6beb --- /dev/null +++ b/bip-0100.mediawiki @@ -0,0 +1,77 @@ +<pre> + BIP: 100 + Layer: Consensus (hard fork) + Title: Dynamic maximum block size by miner vote + Author: Jeff Garzik <jgarzik@gmail.com> + Tom Harding <tomh@thinlink.com> + Dagur Valberg Johannsson <dagurval@pvv.ntnu.no> + Comments-Summary: No comments yet. + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0100 + Status: Rejected + Type: Standards Track + Created: 2015-06-11 + License: BSD-2-Clause +</pre> + +==Abstract== + +Replace the static 1M block size hard limit with a hard limit set by coinbase vote, conducted on the same schedule as difficulty retargeting. + +==Motivation== + +Miners directly feel the effects, both positive and negative, of any maximum block size change imposed by their peers. Larger blocks allow more growth in the on-chain ecosystem, while smaller blocks reduce resource requirements network-wide. Miners also act as an efficient proxy for the rest of the ecosystem, since they are paid in the tokens collected for the blocks they create. + +A simple deterministic system is specified, whereby a 75% mining supermajority may activate a change to the maximum block size each 2016 blocks. Each change is limited to a 5% increase from the previous block size hard limit, or a decrease of similar magnitude. Among adopting nodes, there will be no disagreement on the evolution of the maximum block size. + +The system is compatible with emergent consensus, but whereas under that system a miner may choose to accept any size block, a miner following BIP100 observes the 75% supermajority rule, and the 5% change limit rule. Excessive-block values signaled by emergent consensus blocks are considered in the calculation of the BIP100 block size hard limit, and the BIP100 calculated maximum block size is signaled as an excessive-block value for the benefit of all observers. + +==Specification== + +===Dynamic Maximum Block Size=== +# Initial value of <code>hardLimit</code> is 1000000 bytes, preserving current system. +# Changing <code>hardLimit</code> is accomplished by encoding a proposed value, a vote, within a block's coinbase scriptSig, and by processing the votes contained in the previous retargeting period.<br /><br /> +## Vote encoding +### A vote is represented as a megabyte value using the BIP100 pattern<br /><br /><code>/BIP100/B[0-9]+/</code><br /><br />Example: <code>/BIP100/B8/</code> is a vote for a 8000000-byte <code>hardLimit</code>.<br /><br /> +### If the block height is encoded at the start of the coinbase scriptSig, as per BIP34, it is ignored. +### Only the first BIP100 pattern match is processed in "Maximum block size recalculation" below. +### A megabyte value is represented by consecutive base-ten digits. +### If no BIP100 pattern is matched, the first matching emergent consensus pattern <code>/EB[0-9]+/</code>, if any, is accepted as the megabyte vote.<br /><br /> +## Maximum block size recalculation +### A <code>new hardLimit</code> is calculated after each difficulty adjustment period of 2016 blocks, and applies to the next 2016 blocks. +### Absent/zero-valued votes are counted as votes for the <code>current hardLimit</code>. +### The votes of the previous 2016 blocks are sorted by megabyte vote. +### Raising <code>hardLimit</code><br /><br /> +#### The <code>raise value</code> is defined as the vote of the 1512th highest block, converted to bytes. +#### If the resultant <code>raise value</code> is greater than (<code>current hardLimit</code> * 1.05) rounded down, it is set to that value. +#### If the resultant <code>raise value</code> is greater than <code>current hardLimit</code>, the <code>raise value</code> becomes the <code>new hardLimit</code> and the recalculation is complete.<br /><br /> +### Lowering <code>hardLimit</code><br /><br /> +#### The <code>lower value</code> is defined as the vote of the 1512th lowest block, converted to bytes. +#### If the resultant <code>lower value</code> is less than (<code>current hardLimit</code> / 1.05) rounded down, it is set to that value. +#### If the resultant <code>lower value</code> is less than <code>current hardLimit</code>, the <code>lower value</code> becomes the <code>new hardLimit</code> and the recalculation is complete.<br /><br /> +### Otherwise, <code>new hardLimit</code> remains the same as <code>current hardLimit</code>. + +===Signature Hashing Operations Limits=== +# The per-block signature hashing operations limit is scaled to (actual block size, fractional megabyte rounded to next higher megabyte) / 50. +# A maximum serialized transaction size of 1000000 bytes is imposed. + +==Recommendations== + +===Publication of <code>hardLimit</code>=== +# For the benefit of all observers, it is recommended that <code>hardLimit</code> be published. Example: a complete coinbase string might read <br /><br /><code>/BIP100/B8/EB2.123456/</code><br /><br /> which indicates a vote for 8M maximum block size, and an enforced <code>hardLimit</code> of 2.123456 megabytes for the block containing the coinbase string. + +==Deployment== + +This BIP is presumed deployed and activated as of block height 449568 by implementing nodes on the bitcoin mainnet. It has no effect until a raise value different from 1M is observed, which requires at least 1512 of 2016 blocks to vote differently from 1M. + +==Backward compatibility== + +The first block larger than 1M will create a network partition, as nodes with a fixed 1M hard limit reject that block. + +==Implementations== +https://github.com/bitcoinxt/bitcoinxt/pull/188</br> +https://github.com/bitcoinxt/bitcoin/pull/1</br> +https://github.com/BitcoinUnlimited/BitcoinUnlimited/pull/398</br> + +==Copyright== +This document is licensed under the BSD 2-clause license. + 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-0103.mediawiki b/bip-0103.mediawiki index bc06000..3a8bab5 100644 --- a/bip-0103.mediawiki +++ b/bip-0103.mediawiki @@ -5,7 +5,7 @@ Author: Pieter Wuille <pieter.wuille@gmail.com> Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0103 - Status: Draft + Status: Withdrawn Type: Standards Track Created: 2015-07-21 License: BSD-2-Clause 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-0154.mediawiki b/bip-0154.mediawiki index a0bf387..c1e4cdb 100644 --- a/bip-0154.mediawiki +++ b/bip-0154.mediawiki @@ -5,7 +5,7 @@ Author: Karl-Johan Alm <karljohan-alm@garage.co.jp> Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0154 - Status: Draft + Status: Withdrawn Type: Standards Track Created: 2017-04-12 License: BSD-2-Clause 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-0157.mediawiki b/bip-0157.mediawiki index 4a47706..bb864aa 100644 --- a/bip-0157.mediawiki +++ b/bip-0157.mediawiki @@ -168,7 +168,7 @@ fields: # Nodes SHOULD NOT send <code>getcfilters</code> unless the peer has signaled support for this filter type. Nodes receiving <code>getcfilters</code> with an unsupported filter type SHOULD NOT respond. # StopHash MUST be known to belong to a block accepted by the receiving peer. This is the case if the peer had previously sent a <code>headers</code> or <code>inv</code> message with that block or any descendents. A node that receives <code>getcfilters</code> with an unknown StopHash SHOULD NOT respond. -# The height of the block with hash StopHash MUST be greater than or equal to StartHeight, and the difference MUST be strictly less than 100. +# The height of the block with hash StopHash MUST be greater than or equal to StartHeight, and the difference MUST be strictly less than 1000. # The receiving node MUST respond to valid requests by sending one <code>cfilter</code> message for each block in the requested range, sequentially in order by block height. ==== cfilter ==== diff --git a/bip-0158.mediawiki b/bip-0158.mediawiki index 6c3202b..ce4a4af 100644 --- a/bip-0158.mediawiki +++ b/bip-0158.mediawiki @@ -19,7 +19,7 @@ This BIP describes a structure for compact filters on block data, for use in the BIP 157 light client protocol<ref>bip-0157.mediawiki</ref>. The filter construction proposed is an alternative to Bloom filters, as used in BIP 37, that minimizes filter size by using Golomb-Rice coding for compression. This -document specifies two initial types of filters based on this construction that +document specifies one initial filter type based on this construction that enables basic wallets and applications with more advanced smart contracts. == Motivation == @@ -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 == @@ -285,7 +284,7 @@ We exclude all outputs that start with <code>OP_RETURN</code> in order to allow filters to easily be committed to in the future via a soft-fork. A likely area for future commitments is an additional <code>OP_RETURN</code> output in the coinbase transaction similar to the current witness commitment -<ref>https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki</rev>. By +<ref>https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki</ref>. By excluding all <code>OP_RETURN</code> outputs we avoid a circular dependency between the commitment, and the item being committed to. @@ -323,7 +322,7 @@ This BIP allocates a new service bit: |- | NODE_COMPACT_FILTERS | style="white-space: nowrap;" | <code>1 << 6</code> -| If enabled, the node MUST respond to all BIP 157 messages for filter types <code>0x00</code> and <code>0x01</code> +| If enabled, the node MUST respond to all BIP 157 messages for filter type <code>0x00</code> |} == Compatibility == @@ -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 f197728..df7d658 100644 --- a/bip-0174.mediawiki +++ b/bip-0174.mediawiki @@ -69,7 +69,7 @@ the length of that data. <tt>{..}</tt> indicates the raw data itself. |- | Key | byte[] -| The key itself with the first byte being the type of the key-value pair +| The Key itself |- | Value Length | Compact Size Unsigned Integer @@ -103,11 +103,13 @@ The format of each key-value map is as follows: | separator | char | <tt>0x00</tt> -| Must be <tt>0x00</tt>. +| Must be <tt>0x00</tt> at the end of the map. |} -The first byte of each key specifies the type of the key-value pair. There are global types, -per-input types, and per-output types. +At the beginning of each key is a compact size unsigned integer representing the type. +This compact size unsigned integer must be minimally encoded, i.e. if the value can be represented using one byte, it must be represented as one byte. +For convenience, this BIP will specify types using their full serialization, so a multi-byte type will have it's full prefix and zero padding as necessary. +There are global types, per-input types, and per-output types. The currently defined global types are as follows: @@ -118,6 +120,24 @@ 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 little endian unsigned integer indexes concatenated with each other. The number of 32 bit unsigned integer indexes must match the depth provided in the extended public key. +*** <tt>{master key fingerprint}|{32-bit uint}|...|{32-bit uint}</tt> + +* Type: Version Number <tt>PSBT_GLOBAL_VERSION = 0xFB</tt> +** Key: None. The key must only contain the 1 byte type. +*** <tt>{0xFB}</tt> +** Value: The 32-bit little endian unsigned integer representing the version number of this PSBT. If ommitted, the version number is 0. +*** <tt>{32-bit uint}</tt> + +* Type: Proprietary Use Type <tt>PSBT_GLOBAL_PROPRIETARY = 0xFC</tt> +** Key: Variable length identifier prefix, followed by a subtype, followed by the key data itself. +*** <tt>{0xFC}|<prefix>|{subtype}|{key data}</tt> +** Value: Any value data as defined by the proprietary type user. +*** <tt><data></tt> + The currently defined per-input types are defined as follows: * Type: Non-Witness UTXO <tt>PSBT_IN_NON_WITNESS_UTXO = 0x00</tt> @@ -160,7 +180,7 @@ The currently defined per-input types are defined as follows: ** Key: The public key *** <tt>{0x06}|{public key}</tt> ** Value: The master key fingerprint as defined by BIP 32 concatenated with the derivation path of the public key. The derivation path is represented as 32 bit unsigned integer indexes concatenated with each other. Public keys are those that will be needed to sign this input. -*** <tt>{master key fingerprint}|{32-bit int}|...|{32-bit int}</tt> +*** <tt>{master key fingerprint}|{32-bit uint}|...|{32-bit uint}</tt> * Type: Finalized scriptSig <tt>PSBT_IN_FINAL_SCRIPTSIG = 0x07</tt> ** Key: None. The key must only contain the 1 byte type. @@ -180,6 +200,12 @@ The currently defined per-input types are defined as follows: ** Value: The UTF-8 encoded commitment message string for the proof-of-reserves. See [[bip-0127.mediawiki|BIP 127]] for more information. *** <tt>{porCommitment}</tt> +* Type: Proprietary Use Type <tt>PSBT_IN_PROPRIETARY = 0xFC</tt> +** Key: Variable length identifier prefix, followed by a subtype, followed by the key data itself. +*** <tt>{0xFC}|<prefix>|{subtype}|{key data}</tt> +** Value: Any value data as defined by the proprietary type user. +*** <tt><data></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: @@ -199,8 +225,14 @@ determine which outputs are change outputs and verify that the change is returni * Type: BIP 32 Derivation Path <tt>PSBT_OUT_BIP32_DERIVATION = 0x02</tt> ** Key: The public key *** <tt>{0x02}|{public key}</tt> -** Value: The master key fingerprint concatenated with the derivation path of the public key. The derivation path is represented as 32 bit unsigned integer indexes concatenated with each other. This must omit the index of the master key. Public keys are those needed to spend this output. -*** <tt>{master key fingerprint}|{32-bit int}|...|{32-bit int}</tt> +** Value: The master key fingerprint concatenated with the derivation path of the public key. The derivation path is represented as 32-bit little endian unsigned integer indexes concatenated with each other. Public keys are those needed to spend this output. +*** <tt>{master key fingerprint}|{32-bit uint}|...|{32-bit uint}</tt> + +* Type: Proprietary Use Type <tt>PSBT_OUT_PROPRIETARY = 0xFC</tt> +** Key: Variable length identifier prefix, followed by a subtype, followed by the key data itself. +*** <tt>{0xFC}|<prefix>|{subtype}|{key data}</tt> +** Value: Any value data as defined by the proprietary type user. +*** <tt><data></tt> The transaction format is specified as follows: @@ -277,6 +309,23 @@ whichever value it wishes.<ref>'''Why can the values be arbitrarily chosen?''' W valid or invalid. If the values are invalid, a signer would simply produce an invalid signature and the final transaction itself would be invalid. If the values are valid, then it does not matter which is chosen as either way the transaction is still valid.</ref> +===Proprietary Use Type=== + +For all global, per-input, and per-output maps, the types <tt>0xFC</tt> is reserved for proprietary use. +The proprietary use type requires keys that follow the type with a variable length string identifer, then a subtype. + +The identifier can be any variable length string that software can use to identify whether the particular data in the proprietary type can be used by it. +It can also be the empty string and just be a single <tt>0x00</tt> byte although this is not recommended. + +The subtype is defined by the proprietary type user and can mean whatever they want it to mean. +The subtype must also be a compact size unsigned integer in the same form as the normal types. +The key data and value data are defined by the proprietary type user. + +The proprietary use types is for private use by individuals and organizations who wish to use PSBT in their processes. +It is useful when there are additional data that they need attached to a PSBT but such data are not useful or available for the general public. +The proprietary use type is not to be used by any public specification and there is no expectation that any publicly available software be able to understand any specific meanings of it and the subtypes. +This type must be used for internal processes only. + ==Responsibilities== Using the transaction format involves many different responsibilities. Multiple responsibilities can be handled by a single entity, but each responsibility is specialized in what it should be capable of doing. @@ -307,7 +356,7 @@ If a Signer cannot sign a transaction, it must not add a Partial Signature. The Signer can additionally compute the addresses and values being sent, and the transaction fee, optionally showing this data to the user as a confirmation of intent and the consequences of signing the PSBT. -Signers do not need to sign for all possible input types. For example, a signer may choose to only sign only Segwit inputs. +Signers do not need to sign for all possible input types. For example, a signer may choose to only sign Segwit inputs. A single entity is likely to be both a Signer and an Updater as it can update a PSBT with necessary information prior to signing it. @@ -319,6 +368,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===== @@ -326,18 +377,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) @@ -358,6 +413,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. @@ -401,7 +473,16 @@ The Partially Signed Transaction format can be extended in the future by adding new types for key-value pairs. Backwards compatibilty will still be maintained as those new types will be ignored and passed-through by signers which do not know about them. -If one byte type fields were to ever run out, new extensions can still be added by defining multi-byte types where the first byte signals that the next byte indicates the type and so on. +===Version Numbers=== + +The Version number field exists only as a safeguard in the event that a backwards incompatible change is introduced to PSBT. +If a parser encounters a version number it does not recognize, it should exit immediately as this indicates that the PSBT will contain types that it does not know about and cannot be ignored. +Current PSBTs are Version 0. Any PSBT that does not have the version field is version 0. +It is not expected that any backwards incompatible change will be introduced to PSBT, so it is not expected that the version field will ever actually be seen. + +Updaters and combiners that need to add a version number to a PSBT should use the highest version number required. +For example, if a combiner sees two PSBTs for the same transaction, one with version 0, and the other with version 1, then it should combine them and produce a PSBT with version 1. +If an updater is updating a PSBT and needs to add a field that is only available in version 1, then it should set the PSBT version number to 1 unless a version higher than that is already specified. ==Compatibility== @@ -492,8 +573,8 @@ The following are invalid PSBTs: ** Base64 String: <pre>cHNidP8BAHMCAAAAATAa6YblFqHsisW0vGVz0y+DtGXiOtdhZ9aLOOcwtNvbAAAAAAD/////AnR7AQAAAAAAF6kUA6oXrogrXQ1Usl1jEE5P/s57nqKHYEOZOwAAAAAXqRS5IbG6b3IuS/qDtlV6MTmYakLsg4cAAAAAAAEBHwDKmjsAAAAAFgAU0tlLZK4IWH7vyO6xh8YB6Tn5A3wAAgAAFgAUYunpgv/zTdgjlhAxawkM0qO3R8sAAQAiACCHa62DLx0WgBXtQSMqnqZaGBXZ7xPA74dZ9ktbKyeKZQEBJVEhA7fOI6AcW0vwCmQlN836uzFbZoMyhnR471EwnSvVf4qHUa4A</pre> * Case: PSBT With invalid output witnessScript typed key -** Bytes in Hex: <pre>70736274ff0100730200000001301ae986e516a1ec8ac5b4bc6573d32f83b465e23ad76167d68b38e730b4dbdb0000000000ffffffff02747b01000000000017a91403aa17ae882b5d0d54b25d63104e4ffece7b9ea2876043993b0000000017a914b921b1ba6f722e4bfa83b6557a3139986a42ec8387000000000001011f00ca9a3b00000000160014d2d94b64ae08587eefc8eeb187c601e939f9037c00010016001462e9e982fff34dd8239610316b090cd2a3b747cb000100220020876bad832f1d168015ed41232a9ea65a1815d9ef13c0ef8759f64b5b2b278a6521010025512103b7ce23a01c5b4bf00a642537cdfabb315b668332867478ef51309d2bd57f8a8751ae00</pre> -** Base64 String: <pre>cHNidP8BAHMCAAAAATAa6YblFqHsisW0vGVz0y+DtGXiOtdhZ9aLOOcwtNvbAAAAAAD/////AnR7AQAAAAAAF6kUA6oXrogrXQ1Usl1jEE5P/s57nqKHYEOZOwAAAAAXqRS5IbG6b3IuS/qDtlV6MTmYakLsg4cAAAAAAAEBHwDKmjsAAAAAFgAU0tlLZK4IWH7vyO6xh8YB6Tn5A3wAAQAWABRi6emC//NN2COWEDFrCQzSo7dHywABACIAIIdrrYMvHRaAFe1BIyqeploYFdnvE8Dvh1n2S1srJ4plIQEAJVEhA7fOI6AcW0vwCmQlN836uzFbZoMyhnR471EwnSvVf4qHUa4A</pre> +** Bytes in Hex: <pre>70736274ff0100730200000001301ae986e516a1ec8ac5b4bc6573d32f83b465e23ad76167d68b38e730b4dbdb0000000000ffffffff02747b01000000000017a91403aa17ae882b5d0d54b25d63104e4ffece7b9ea2876043993b0000000017a914b921b1ba6f722e4bfa83b6557a3139986a42ec8387000000000001011f00ca9a3b00000000160014d2d94b64ae08587eefc8eeb187c601e939f9037c00010016001462e9e982fff34dd8239610316b090cd2a3b747cb000100220020876bad832f1d168015ed41232a9ea65a1815d9ef13c0ef8759f64b5b2b278a6521010025512103b7ce23a01c5b4bf00a642537cdfabb315b668332867478ef51309d06d57f8a8751ae00</pre> +** Base64 String: <pre>cHNidP8BAHMCAAAAATAa6YblFqHsisW0vGVz0y+DtGXiOtdhZ9aLOOcwtNvbAAAAAAD/////AnR7AQAAAAAAF6kUA6oXrogrXQ1Usl1jEE5P/s57nqKHYEOZOwAAAAAXqRS5IbG6b3IuS/qDtlV6MTmYakLsg4cAAAAAAAEBHwDKmjsAAAAAFgAU0tlLZK4IWH7vyO6xh8YB6Tn5A3wAAQAWABRi6emC//NN2COWEDFrCQzSo7dHywABACIAIIdrrYMvHRaAFe1BIyqeploYFdnvE8Dvh1n2S1srJ4plIQEAJVEhA7fOI6AcW0vwCmQlN836uzFbZoMyhnR471EwnQbVf4qHUa4A</pre> The following are valid PSBTs: @@ -517,10 +598,18 @@ 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> +* Case: PSBT with `PSBT_GLOBAL_XPUB`. +** Bytes in Hex: <pre>70736274ff01009d0100000002710ea76ab45c5cb6438e607e59cc037626981805ae9e0dfd9089012abb0be5350100000000ffffffff190994d6a8b3c8c82ccbcfb2fba4106aa06639b872a8d447465c0d42588d6d670000000000ffffffff0200e1f505000000001976a914b6bc2c0ee5655a843d79afedd0ccc3f7dd64340988ac605af405000000001600141188ef8e4ce0449eaac8fb141cbf5a1176e6a088000000004f010488b21e039e530cac800000003dbc8a5c9769f031b17e77fea1518603221a18fd18f2b9a54c6c8c1ac75cbc3502f230584b155d1c7f1cd45120a653c48d650b431b67c5b2c13f27d7142037c1691027569c503100008000000080000000800001011f00e1f5050000000016001433b982f91b28f160c920b4ab95e58ce50dda3a4a220203309680f33c7de38ea6a47cd4ecd66f1f5a49747c6ffb8808ed09039243e3ad5c47304402202d704ced830c56a909344bd742b6852dccd103e963bae92d38e75254d2bb424502202d86c437195df46c0ceda084f2a291c3da2d64070f76bf9b90b195e7ef28f77201220603309680f33c7de38ea6a47cd4ecd66f1f5a49747c6ffb8808ed09039243e3ad5c1827569c5031000080000000800000008000000000010000000001011f00e1f50500000000160014388fb944307eb77ef45197d0b0b245e079f011de220202c777161f73d0b7c72b9ee7bde650293d13f095bc7656ad1f525da5fd2e10b11047304402204cb1fb5f869c942e0e26100576125439179ae88dca8a9dc3ba08f7953988faa60220521f49ca791c27d70e273c9b14616985909361e25be274ea200d7e08827e514d01220602c777161f73d0b7c72b9ee7bde650293d13f095bc7656ad1f525da5fd2e10b1101827569c5031000080000000800000008000000000000000000000220202d20ca502ee289686d21815bd43a80637b0698e1fbcdbe4caed445f6c1a0a90ef1827569c50310000800000008000000080000000000400000000</pre> +** Base64 String: <pre>cHNidP8BAJ0BAAAAAnEOp2q0XFy2Q45gflnMA3YmmBgFrp4N/ZCJASq7C+U1AQAAAAD/////GQmU1qizyMgsy8+y+6QQaqBmObhyqNRHRlwNQliNbWcAAAAAAP////8CAOH1BQAAAAAZdqkUtrwsDuVlWoQ9ea/t0MzD991kNAmIrGBa9AUAAAAAFgAUEYjvjkzgRJ6qyPsUHL9aEXbmoIgAAAAATwEEiLIeA55TDKyAAAAAPbyKXJdp8DGxfnf+oVGGAyIaGP0Y8rmlTGyMGsdcvDUC8jBYSxVdHH8c1FEgplPEjWULQxtnxbLBPyfXFCA3wWkQJ1acUDEAAIAAAACAAAAAgAABAR8A4fUFAAAAABYAFDO5gvkbKPFgySC0q5XljOUN2jpKIgIDMJaA8zx9446mpHzU7NZvH1pJdHxv+4gI7QkDkkPjrVxHMEQCIC1wTO2DDFapCTRL10K2hS3M0QPpY7rpLTjnUlTSu0JFAiAthsQ3GV30bAztoITyopHD2i1kBw92v5uQsZXn7yj3cgEiBgMwloDzPH3jjqakfNTs1m8fWkl0fG/7iAjtCQOSQ+OtXBgnVpxQMQAAgAAAAIAAAACAAAAAAAEAAAAAAQEfAOH1BQAAAAAWABQ4j7lEMH63fvRRl9CwskXgefAR3iICAsd3Fh9z0LfHK57nveZQKT0T8JW8dlatH1Jdpf0uELEQRzBEAiBMsftfhpyULg4mEAV2ElQ5F5rojcqKncO6CPeVOYj6pgIgUh9JynkcJ9cOJzybFGFphZCTYeJb4nTqIA1+CIJ+UU0BIgYCx3cWH3PQt8crnue95lApPRPwlbx2Vq0fUl2l/S4QsRAYJ1acUDEAAIAAAACAAAAAgAAAAAAAAAAAAAAiAgLSDKUC7iiWhtIYFb1DqAY3sGmOH7zb5MrtRF9sGgqQ7xgnVpxQMQAAgAAAAIAAAACAAAAAAAQAAAAA</pre> + Fails Signer checks * Case: A Witness UTXO is provided for a non-witness input @@ -659,6 +748,21 @@ Any data types, their associated scope and BIP number must be defined here | PSBT_GLOBAL_UNSIGNED_TX | BIP 174 |- +| Global +| 1 +| PSBT_GLOBAL_XPUB +| BIP 174 +|- +| Global +| 251 +| PSBT_GLOBAL_VERSION +| BIP 174 +|- +| Global +| 252 +| PSBT_GLOBAL_PROPRIETARY +| BIP 174 +|- | Input | 0 | PSBT_IN_NON_WITNESS_UTXO @@ -709,6 +813,11 @@ Any data types, their associated scope and BIP number must be defined here | PSBT_IN_POR_COMMITMENT | [[bip-0127.mediawiki|BIP 127]] |- +| Input +| 252 +| PSBT_IN_PROPRIETARY +| BIP 174 +|- | Output | 0 | PSBT_OUT_REDEEM_SCRIPT @@ -723,4 +832,9 @@ Any data types, their associated scope and BIP number must be defined here | 2 | PSBT_OUT_BIP32_DERIVATION | BIP 174 +|- +| Output +| 252 +| PSBT_OUT_PROPRIETARY +| BIP 174 |} 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-0179.mediawiki b/bip-0179.mediawiki new file mode 100644 index 0000000..7894f2d --- /dev/null +++ b/bip-0179.mediawiki @@ -0,0 +1,58 @@ +<pre> + BIP: 179 + Title: Name for payment recipient identifiers + Author: Emil Engler <me@emilengler.com> + MarcoFalke <falke.marco@gmail.com> + Luke Dashjr <luke+bip@dashjr.org> + Comments-Summary: No comments yet. + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0179 + Status: Draft + Type: Informational + Created: 2019-10-17 + License: CC0-1.0 +</pre> + +==Abstract== +This BIP proposes a new term for 'address' + +==Specification== +The new term is: +''Bitcoin'' '''Invoice''' ''Address'' + +The ''Bitcoin'' and ''Address'' parts are optional. +The address suffix should only be used as a transitional step. + +A ''Bitcoin'' Invoice ''Address'' is a string of characters that can be used to indicate the intended recipient and purpose of a transaction. + +==Motivation== +Bitcoin addresses are intended to be only used '''once''' and you should generate a new one for every new incoming payment. +The term 'address' however indicates consistency because nearly everything on the internet or the offline world with the term 'address' +is something that rarely or even never changes (postal address, email address, IP addresses (depends heavily on the provider), etc.) +The motivation for this BIP is to change the term address to something that indicates that the address is connected to a single transaction. + +==Rationale== +The reason why we use ''Bitcoin Invoice Address'' or just ''Invoice'' is to emphasize that it is single-use. +The terms ''Bitcoin'' and ''Address'' are optional for the following reasons: +For ''Bitcoin'': +* Useful for multicoin wallets to indicate that it belongs to Bitcoin +* Indicates a difference between a lightning and an on-chain invoice +For ''Address'': +* To not confuse users with a completely new term +* To show that it is where you send something to +* To not break backwards compatibility + +This gives us the four following possibilities: +* Bitcoin Invoice Address +* Bitcoin Invoice +* Invoice Address +* Invoice + +==Backwards Compatibility== +To avoid issues, the 'Address' suffix is permitted, but not recommended. +The suffix 'Address' remains so users should be immediately able to recognize it until the new term is widely known. + +==Acknowledgements== +Thanks to Chris Belcher for the suggestion of the term 'Bitcoin Invoice Address' + +==Copyright== +This BIP is released under CC0-1.0 and therefore Public Domain. diff --git a/bip-0197.mediawiki b/bip-0197.mediawiki index 8a34b04..427ff22 100644 --- a/bip-0197.mediawiki +++ b/bip-0197.mediawiki @@ -130,7 +130,7 @@ In the case of a default or the lender not accepting the borrower repayment, the In the case that either the lender or borrower don’t accept the bid, the lender can seize a percentage of the collateral. The amount is dependent on the amount of collateral locked in the Seizable Collateral and Refundable Collateral script as described in this BIP. During this period, the borrower can also refund the funds locked in the Refundable Collateral script. ===Refund Period=== -In the case that the lender does not seize the collateral locked in the Seizable Collateral script, then the borrower can refund the funds locked in the Refundable Collateral script. +In the case that the lender does not seize the collateral locked in the Seizable Collateral script, then the borrower can refund the funds locked in the Seizable Collateral script. ==Rationale== diff --git a/bip-0300.mediawiki b/bip-0300.mediawiki new file mode 100644 index 0000000..08f8994 --- /dev/null +++ b/bip-0300.mediawiki @@ -0,0 +1,308 @@ +<pre> + BIP: 300 + Layer: Consensus (soft fork) + Title: Hashrate Escrows (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-0300 + Status: Draft + Type: Standards Track + Created: 2017-08-14 + License: BSD-2-Clause + Post-History: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014364.html +</pre> + +==Abstract== + +A "Hashrate Escrow" is a clearer term for the concept of "locked to an SPV Proof", which is itself a restatement of the phrase "within a sidechain" as described in [https://blockstream.com/sidechains.pdf the 2014 Blockstream whitepaper]. + +A Hashrate Escrow resembles a 2-of-3 multisig escrow, where the 3rd party (who will arbitrate any disputes) is a decentralized group of people: the dynamic-membership set of Bitcoin Miners. However, the 3rd party does not sign escrow-withdrawal transactions with a private key. Instead, these are "signed" by the accumulation of hashpower over time. + +This project has [http://www.drivechain.info/ a website] which includes [http://www.drivechain.info/faq/index.html an FAQ]. + + +==Motivation== + +In practice these escrows are likely to be "asymmetric sidechains" of Bitcoin (such as [http://www.rsk.co/ Rootstock]) or "virtual chains" within Bitcoin (such as [https://github.com/blockstack/virtualchain proposed by Blockstack] in mid-2016). + +Sidechains have many potential benefits, including: + +# Protect Bitcoin from competition from altcoins and spinoffs. +# Protect Bitcoin from hard fork campaigns. (Such campaigns represent an existential threat to Bitcoin, as well as an avenue for developer corruption.) +# Help with review, by making it much easier for reviewers to ignore bad ideas. +# Provide an avenue for good-but-confusing ideas to prove their value safely. + + + +==Specification== + +==== Components ==== + +Hashrate Escrows are built of two types of component: [1] new databases, and [2] new message-interpretations. + +===== 1. New Databases ===== + +* D1. "Escrow_DB" -- a database of "accounts" and their attributes. +* D2. "Withdrawal_DB" -- a database of pending withdrawals from these accounts, and their statuses. + +Please note that these structures (D1 and D2) will not literally exist anywhere in the blockchain. Instead they are constructed from messages...these messages, in contrast, *will* exist in the blockchain (with the exception of M4). + +===== 2. New Messages ===== + +* M1. "Propose New Escrow" +* M2. "ACK Escrow Proposal" +* M3. "Propose Withdrawal" +* M4. (implied) "ACK Withdrawal" +* M5. "Execute Deposit" -- a transfer of BTC from-main-to-side +* M6. "Execute Withdrawal" -- a transfer of BTC from-side-to-main + + + + +=== Adding Sidechains (D1, M1, M2) === + +==== D1 -- "Escrow_DB" ==== + +The table below enumerates the new database fields, their size in bytes, and their purpose. In general, an escrow designer (for example, a sidechain-designer), is free to choose any value for these. + + + +{| class="wikitable" +! Field No. +! Label +! Type +! Description / Purpose +|- +| 1 +| Escrow Number +| uint8_t +| A number assigned to the entire escrow. Used to make it easy to refer to each escrow. +|- +| 2 +| Sidechain Deposit Script Hex +| string +| The script that will be deposited to, and update the CTIP of the sidechain. +|- +| 3 +| Sidechain Private Key +| string +| The private key of the sidechain deposit script. +|- +| 4 +| Escrow Name +| string +| A human-readable name of the sidechain. +|- +| 5 +| Escrow Description +| string +| A human-readable name description of the sidechain. More than enough space to hold a 32 byte hash. +|- +| 6 +| Hash ID 1 +| uint256 +| A field of 32 bytes, which could be any bytes such as a sha256 hash. +|- +| 7 +| Hash ID 2 +| uint256 +| A field of 32 bytes, which could be any bytes such as a sha256 hash. +|- +| 8 +| "CTIP" -- Part 1 "TxID" +| uint256 +| The CTIP, or "Critical (TxID, Index) Pair" is a variable for keeping track of where the escrow's money is (ie, which member of the UTXO set). +|- +| 9 +| "CTIP" -- Part 2 "Index" +| int32_t +| Of the CTIP, this is second element of the pair: the Index. See #9 above. +|- +|} + +D1 is updated via M1 and M2. + +( The following messages were modeled on SegWit -- see [https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#commitment-structure here] and [https://github.com/DriveNetTESTDRIVE/DriveNet/blob/564516653c1d876429382971a011f5f6119f7eb4/src/validation.cpp#L3348-L3375 here]. ) + + +==== M1 -- "Propose New Sidechain" ==== + + 1-byte - OP_RETURN (0x6a) + 4-byte - Commitment header (0xD5E0C4AF) + N-byte - The serialization of the sidechain. + + +==== M2 -- "ACK Sidechain Proposal" ==== + + 1-byte - OP_RETURN (0x6a) + 4-byte - Commitment header (0xD6E1C5BF) + 32-byte - Commitment hash: sha256D hash of sidechain's serialization + +==== New Block Validation Rules ==== + + +# Escrows are added in a procedure that resembles BIP 9 soft fork activation: the network must see a properly-formatted M1, followed by "acknowledgment" of the sidechain in 95% of the following 2016 blocks. +# It is possible to "overwrite" an escrow. This requires 6 months (26298 blocks) of M2s, instead of 2 weeks (XXXX). This possibility does not change the security assumptions (because we already assume that users perform extra-protocolic validation at a rate of 1 bit per 26298 blocks). + + + +=== Withdrawing from Escrows (D2, M3, M4) === + +==== D2 -- "Withdrawal_DB" ==== + +D2 changes deterministically with respect to M3, M4, M5, and M6. + +{| class="wikitable" +! Field No. +! Label +! Type +! Description / Purpose +|- +| 1 +| Escrow Number +| uint8_t +| Links the withdrawal-request to a specific escrow. +|- +| 2 +| WT^ Hash +| uint256 +| This is a "blinded transaction id" (ie, the double-Sha256 of a txn that has had two fields zeroed out, see M6) of a withdrawal-attempt. +|- +| 3 +| ACKs (Work Score) +| uint16_t +| The current total number of ACKs (PoW) +|- +| 4 +| Blocks Remaining (Age) +| uint16_t +| The number of blocks which this WT^ has remaining to accumulate ACKs +|} + + +==== New Block Validation Rules for D2 ==== + +# A hash commitment to D2 exists in each block (even if D2 is blank). +# Withdrawals in D2 are sorted first by field #1 (Escrow Number) and second by field #4 (Age). This imposes a unique sort. +# From one block to the next, "Age" fields must increase by exactly 1. +# Withdrawals are stored in D2 until they fail ("Age" = "MaxAge"), or they succeed (the blockchain contains a txn whose blinded txID matches "WT^"). + +In addition, there are special rules for the "ACKs" field (see M4 below). + +==== M3 -- "Propose Withdrawal" ==== + + 1-byte - OP_RETURN (0x6a) + 1-byte - Push the following 36 bytes (0x24) + 4-byte - Commitment header (0xD45AA943) + 32-byte - The WT^ hash to populate a new D2 entry + + +==== New Block Validation Rules for M3 ==== + +# If the network detects a properly-formatted M3, it must add an entry to D2 in the very next block. The starting values of fields #3 and #4 are zero, and #5 is pulled over by extracting the relevant value from D1. +# Each block can only contain one M3 per sidechain. + + +==== M4 -- "ACK Withdrawal" ==== + +M4 is a way of describing changes to the "ACKs" column of D2. + +From one block to the next, "ACKs" can only change as follows: + +* The ACK-counter of any withdrawal can only change by (-1,0,+1). +* Within a sidechain-group, upvoting one withdrawal ("+1") requires you to downvote all other withdrawals in that group. However, the minimum ACK-value is zero (and, therefore, downvotes cannot reduce it below zero). +* While only one withdrawal can be upvoted at once, they can all be unchanged at once ("abstain") and they can all be downvoted at once ("alarm"). + +One option for explicit transmission of M4 is: + + 4-byte - Message identifier (0x????????) + 1-byte - Version of this message + 1-byte - Length (in bytes) of this message; total number of withdrawal attempts; y = ceiling( sum_i(m_i +2)/8 ). Nodes should already know what length to expect, because they know the sequence of M3s and therefore the vector of WT^s. + N-byte - stream of bits (not bytes), with a 1 indicating the position of the chosen action [downvote all, abstain, upvote1, upvote2, ...] + +But sometimes M4 does not need to be transmitted at all! If there are n Escrows and m Withdrawals-per-escrow, then there are (m+2)^n total candidates for the next D2. So, when m and n are low, all of the possible D2s can be trivially computed in advance. + +Miners can impose a "soft limit" on m, blocking new withdrawal-attempts until previous ones expire. For a worst-case scenario of n=200 and m=1,000, honest nodes can communicate M4 with ~25 KB per block [4+1+1+(200\*(1000+1+1)/8)]. + + +=== Depositing and Withdrawing (M5, M6) === + +Both M5 and M6 are regular Bitcoin txns. They are identified by meeting an important criteria: they select a one of the Critical TxID-index Pairs (a "CTIP") as one of their inputs. + +Just as these txns must select a CTIP input, they must create a new CTIP output. D1 is then updated to match only the latest CTIP output. The purpose of this is to have all of the escrow's money (ie all of the sidechain's money) in one TxID, so that depositors immediately undo any UTXO bloat they may cause. + +Deposits ("M5") are distinguished from withdrawals ("M6") by simply checking to see if money is "going in", or "out". + +https://github.com/DriveNetTESTDRIVE/DriveNet/blob/564516653c1d876429382971a011f5f6119f7eb4/src/validation.cpp#L647-L742 + + +==== M5. "Make a Deposit" -- a transfer of BTC from-main-to-side ==== + +As far as mainchain consensus is concerned, deposits to the escrow are always valid. + +However, in practice there will be additional requirements. The escrow account (ie the "sidechain") needs to know how to credit depositors. One well-known method, is for mainchain depositors to append a zero-value OP Return to a Deposit txn, so that the sidechain knows how to credit funds. Mainchain users must upgrade their wallet software, of course, (on an individual basis) in order to become aware of and take advantage of new deposit-methods. + + + +==== M6. "Execute Withdrawal" -- a transfer of BTC from-side-to-main ==== + +We come, finally, to the critical matter: where users can take their money *out* of the escrow account, and return it to the "regular" UTXO set. As previously mentioned, this txn is one which (a) spends from a CTIP and (b) reduces the quantity of BTC in an account's CTIP. Most of the work has already been done by D1, M3, M4, and D2. Furthermore, existing Bitcoin tx-rules prevent the sidechain from ever withdrawing more money than has been placed into it. + +In each block, a withdrawal in D2 is considered "approved" if its "ACKs" value meets the threshold (13,150). + +Approved withdrawals give the green light to their respective "WT^". A "WT^" is 32-bytes which aspire to represent the withdrawing transaction (the txn that actually withdraws funds from the escrow). The two cannot match exactly, because "WT^" is defined at onset, and the withdrawing TxID depends on the its CTIP input (which is constantly changing). + +To solve this, we define a "blinded TxID" as a way of hashing a txn, in which some bytes are first overwritten with zeros. Specifically, these bytes are the first input and the first output. + +So, withdrawals must meet the following three criteria: + +# "Be ACKed" -- The "blinded TxID" of this txn must be member of the "approved candidate" set in the D2 of this block. +# "Return Change to Account" -- TxOut0 must pay to the "critical account" (see D1) that corresponds to the CTIP that was selected as a TxIn. +# "Return *all* Change to Account" -- Sum of inputs must equal the sum of outputs. No traditional tx fee is possible. + + + + + +==Backward compatibility== + + +As a soft fork, older software will continue to operate without modification. Non-upgraded nodes will see a number of phenomena that they don't understand -- coinbase txns with non-txn data, value accumulating in anyone-can-spend UTXOs for months at a time, and then random amounts leaving the UTXO in single, infrequent bursts. However, these phenomena don't affect them, or the validity of the money that they receive. + +( As a nice bonus, note that the sidechains themselves inherit a resistance to hard forks. The only way to guarantee that the WT^s reported by different clients will continue to match identically, is to upgrade sidechains via soft forks of themselves. ) + + +==Deployment== + + +This BIP will be deployed by "version bits" BIP9 with the name "hrescrow" 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== + +See http://www.drivechain.info/literature/index.html + + +==Credits== + +Thanks to everyone who contributed to the discussion, especially: ZmnSCPxj, Adam Back, Peter Todd, Dan Anderson, Sergio Demian Lerner, Chris Stewart, Matt Corallo, Sjors Provoost, Tier Nolan, Erik Aronesty, Jason Dreyzehner, Joe Miyamoto, Ben Goldhaber. + + +==Copyright== + +This BIP is licensed under the BSD 2-clause license. diff --git a/bip-0300/appendix-1.txt b/bip-0300/appendix-1.txt new file mode 100644 index 0000000..736a6c4 --- /dev/null +++ b/bip-0300/appendix-1.txt @@ -0,0 +1,45 @@ + +==== Two Withdrawals at Once ==== + +Currently, the documentation and code describe a situation where only one withdrawal can proceed at a time. As a result, one "train" (carrying everyone's withdrawals) leaves the station every 3 months, and takes 3-6 months to reach its destination. + +Thus, if a withdrawing-user is very unlucky, and "just misses" the train, this user must wait double-long. First, (s)he must wait for the missed-train to reach its destination. Second, (s)he must board the new train, and wait for *it* to reach its destination. Each of these steps takes 3-6 months. + +So, even when withdrawals always go as quickly as possible (3 months each), the total time varies, from 3 months (0 months waiting + 3 months travel) to 6 months (3 months waiting + 3 months travel). The average is 4.5 months. + +To improve this, we allow for slightly different behavior if the highest-ACK-withdrawal [1st] has an ACK score >= 6575; and [2nd] is not tied with any other withdrawal. + +Basically: a second train can leave, if the furthest train is 50+% of the way to its destination. + +So, previously, for m trains, M4 could be any of the following: + + abstain + alarm (move all trains backwards) + move train #1 forward (and others backwards) + move train #2 forward (and others backwards) + ... + move train #3 forward (and others backwards) + +If our new special conditions apply, we now double the (m-1) elements, to accommodate a second train: + + |abstain + |alarm (move all trains backwards) + + |advance furthest train + advance train #1 (regress all others) + |advance furthest train + advance train #2 (regress all others) + |... + |advance furthest train + advance train #(m-1) (regress all others) + + |regress furthest train + advance train #1 (regress all others) + |regress furthest train + advance train #2 (regress all others) + |... + |regress furthest train + advance train #(m-1) (regress all others) + + +It is theoretically possible (but in practice probably impossible) to troll this rule, by getting two (or even three) withdrawals to have >6575 ACK scores, and then getting these to *tie* for first place. Then they'd both be furthest. Hence the second condition prohibiting this new behavior, if the furthest trains have any ACK-score ties. + +This simple change, which has almost zero impact on the security assumptions, improves the monthly total wait times drastically: + + Worst-case: 6 --> 4.5 + Average: 4.5 --> 3.75 + Std Dev: ~.91 --> ~.45 diff --git a/bip-0300/images.txt b/bip-0300/images.txt new file mode 100644 index 0000000..2fbbf63 --- /dev/null +++ b/bip-0300/images.txt @@ -0,0 +1 @@ +Images used as reference in the documentation. diff --git a/bip-0300/two-groups.png b/bip-0300/two-groups.png Binary files differnew file mode 100644 index 0000000..c8a3ffa --- /dev/null +++ b/bip-0300/two-groups.png 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/bip-0325.mediawiki b/bip-0325.mediawiki new file mode 100644 index 0000000..51ec634 --- /dev/null +++ b/bip-0325.mediawiki @@ -0,0 +1,85 @@ +<pre> + BIP: 325 + Layer: Applications + Title: Signet + Author: Karl-Johan Alm <karljohan-alm@garage.co.jp> + Comments-Summary: No comments yet. + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0325 + Status: Draft + Type: Standards Track + Created: 2019-03-20 + License: CC0-1.0 +</pre> + +== Abstract == + +A new type of test network where signatures are used in addition to proof of work for block progress, enabling much better coordination and robustness (be reliably unreliable), for persistent, longer-term testing scenarios involving multiple independent parties. + +== Motivation == + +Testnet is a great place to try out new things without risking real money, but it is notoriously unreliable. Huge block reorgs, long gaps in between blocks being mined or sudden bursts of blocks in rapid succession mean that realistic testing of software, especially involving multiple independent parties running software over an extended period of time, becomes infeasible in practice. + +A new type of test network would be more suitable for integration testing by organizations such as exchanges, or testing of next generation Layer-2 protocols like Eltoo or sidechain pegs. The goal is not to be perfectly reliable but rather to have a predictable amount of unreliability. You want a test network to behave like mainnet (i.e. no thousands of block reorgs) while also making it easier to trigger expected but rare events like a 6-block reorg. Regtest is not suitable for longer-term scenarios involving multiple independent parties because creating blocks costs nothing, so any party can completely control the test network. + + +== Specification == + +A new type of network ("signet"), which takes an additional consensus parameter called the challenge (scriptPubKey). The challenge can be a simple pubkey (P2PKH style), or a k-of-n multisig, or any other script you would want. + +The witness commitment of the coinbase transaction is extended to include a secondary commitment (the signature/solution): + + 1-4 bytes - Push the following (x + 4) bytes + 4 bytes - Signet header (0xecc7daa2) + x bytes - Solution (sigScript) + +Any push operations that do not start with the 4 byte signet header are ignored. Multiple push operations with the 4 byte signet header are ignored except for the first entry. + +Any signature operations contained within the challenge use SHA256d(modifiedBlockHash), i.e. the double-SHA256 digest of the following data as the sighash: + +{|class="wikitable" style="text-align: center;" +|- +!Type +!Size +!Name +|- +|Int32||4||nVersion +|- +|Uint256||32||hashPrevBlock +|- +|Uint256||32||modifiedMerkleRoot +|- +|Uint32||4||nTime +|- +|Uint32||4||nBits +|} + +The <code>modifiedMerkleRoot</code> hash is obtained by generating the merkle root of the block transactions, with the coinbase witness commitment as is, without the signet extension. This means the merkle root of the block is different from the merkle root in the signet commitment. This is needed, because the signature can never be included in the very message (in this case, a block) that is being signed. Apart from the signature, to facilitate block generation (mining), the block nonce value is the only other component of the block that the signet signature does not commit to. When grinding proof of work, the extended nonce cannot be used as it would invalidate the signature. Instead, simply resigning the same (or an updated) block will give a new search space. + +A block is considered fully validated if the above commitment is found, and its solution is valid. It is recommended that this verification is done directly before or after the witness commitment verification, as the data required to do both is approximately the same. + +== Compatibility == + +This specification is backwards compatible in the sense that existing software can use Signet out of the box. + +Simply by adding the network parameters for signet (magic number, etc), a client can connect to and use any signet network without further modifications. The block headers have valid proof of work, so clients can trivially check that blocks are "probably" valid. + +However, anyone can mine blocks that are accepted by the client for any given signet network. These blocks do not contain the required signatures, however, so any fully validating node will promptly reject them. As such, clients need to either validate the block signature inside the coinbase transaction, or connect to trusted peers. + +Other software need not add block signature validation code that they will not use in production. This is adequate for non-production test purposes where the goal is to have a network behave as much like mainnet as possible. + +== Reference implementation == + +Pull request at https://github.com/bitcoin/bitcoin/pull/16411 + +== Acknowledgements == + +TODO + +== References == + +# Original mailing list thread: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-March/016734.html +# Bitcoin Wiki entry: https://en.bitcoin.it/wiki/Signet + +== Copyright == + +This document is licensed under the Creative Commons CC0 1.0 Universal license. diff --git a/bip-0330.mediawiki b/bip-0330.mediawiki new file mode 100644 index 0000000..581b6ae --- /dev/null +++ b/bip-0330.mediawiki @@ -0,0 +1,299 @@ +<pre> + BIP: 330 + Layer: Peer Services + Title: Transaction announcements reconciliation + Author: Gleb Naumenko <naumenko.gs@gmail.com> + Pieter Wuille <pieter.wuille@gmail.com> + Comments-Summary: No comments yet. + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0330 + Status: Draft + Type: Standards Track + Created: 2019-09-25 + License: CC0-1.0 + License-Code: MIT +</pre> + +==Abstract== + +This document specifies a P2P protocol extension for reconciliation of transaction announcements <b>between 2 nodes</b>, which is a building block for efficient transaction relay protocols (e.g., [https://arxiv.org/pdf/1905.10518.pdf Erlay]). This is a step towards increasing the connectivity of the network for almost no bandwidth cost. + +==Motivation== + +Currently in the Bitcoin network, every 32-byte transaction ID is announced in at least one direction between every pair of connected peers, via INV messages. This results in high cost of announcing transactions: ''O(nodes * connections_per_node)''. + +A <b>reconciliation-based protocol</b> which uses the technique suggested in this document can have better scaling properties than INV-based flooding. + +Increasing the connectivity of the network makes the network more robust to partitioning attacks; thus, improving the bandwidth scaling of transaction relay to ''O(nodes)'' (and without a high constant overhead) would allow us to improve the security of the network by increasing connectivity. It would also reduce the bandwidth required to run a Bitcoin node and potentially enable more users to run full nodes. + +===Erlay=== + +[https://arxiv.org/pdf/1905.10518.pdf Erlay] is an example of a high-level transaction relay protocol which employs set reconciliation for bandwidth efficiency. + +Erlay uses both flooding (announcing using INV messages to all peers) and reconciliation to announce transactions. +Flooding is expensive, so Erlay seeks to use it sparingly and in strategic locations - only well-connected publicly reachable nodes flood transactions to other publicly reachable nodes via outbound connections. +Since every unreachable node is directly connected to several reachable nodes, this policy ensures that a transaction is quickly propagated to be within one hop from most of the nodes in the network. + +All transactions not propagated through flooding are propagated through efficient set reconciliation. +To do this, every node keeps a reconciliation set for each peer, in which transactions are placed which would have been announced using INV messages absent this protocol. Every 2 seconds every node chooses a peer from its outbound connections in a predetermined order to reconcile with, resulting in both sides learning the transactions known to the other side. After every reconciliation round, the corresponding reconciliation set is cleared. +A more detailed description of a set reconciliation round and other implementation details can be found in the paper. + +Erlay allows us to: +* save 40% of the bandwidth consumed by a node, given typical network connectivity as of July 2019. +* achieve similar latency +* increase network connectivity for almost no bandwidth or latency cost +* improves privacy as a side-effect + +This document proposes a P2P-layer extension which is required to enable efficient reconciliation-based protocols (like Erlay) for transaction relay. + +==Specification== + +===New data structures=== + +Several new data structures are introduced to the P2P protocol first, to aid with efficient transaction relay. + +====32-bit short transaction IDs==== + +During reconciliation, significantly abbreviated transaction IDs are used of just 32 bits in size. To prevent attackers from constructing sets of transactions that cause network-wide collisions, the short ID computation is salted on a per-link basis using 64 bits of entropy contributed by both communication partners. + +Short IDs are computed as follows: +* Let ''salt<sub>1</sub>'' and ''salt<sub>2</sub>'' be the entropy contributed by both sides; see the "sendrecon" message further for details how they are exchanged. +* Sort the two salts such that ''salt<sub>1</sub> ≤ salt<sub>2</sub>'' (which side sent what doesn't matter). +* Compute ''h = SHA256("Tx Relay Salting" || salt<sub>1</sub> || salt<sub>2</sub>)'', where the two salts are encoded in 64-bit little-endian byte order. +* Let ''k<sub>0</sub>'' be the 64-bit integer obtained by interpreting the first 8 bytes of ''h'' in little-endian byte order. +* Let ''k<sub>1</sub>'' be the 64-bit integer obtained by interpreting the second 8 bytes of ''h'' in little-endian byte order. +* Let ''s = SipHash-2-4((k<sub>0</sub>,k<sub>1</sub>),wtxid)'', where ''wtxid'' is the transaction hash including witness data as defined by BIP141. +* The short ID is equal to ''1 + (s mod 0xFFFFFFFF)''. + +This results in approximately uniformly distributed IDs in the range ''[1..0xFFFFFFFF]'', which is a requirement for using them as elements in 32-bit sketches. See the next paragraph for details. + +====Short transaction ID sketches==== + +Reconciliation-based relay uses [https://www.cs.bu.edu/~reyzin/code/fuzzy.html PinSketch] BCH-based secure sketches as introduced by the [https://www.cs.bu.edu/~reyzin/fuzzy.html Fuzzy Extractors paper]. They are a form of set checksums with the following properties: +* Sketches have a predetermined capacity, and when the number of elements in the set does not exceed the capacity, it is always possible to recover the entire set from the sketch by decoding the sketch. A sketch of nonzero b-bit elements with capacity c can be stored in bc bits. +* A sketch of the [https://en.wikipedia.org/wiki/Symmetric_difference symmetric difference] between the two sets (i.e., all elements that occur in one but not both input sets), can be obtained by combining the sketches of those sets. + +The sketches used here consists of elements of the [https://en.wikipedia.org/wiki/Finite_field finite field] ''GF(2<sup>32</sup>)''. Specifically, we represent finite field elements as polynomials in ''x'' over ''GF(2)'' modulo ''x<sup>32</sup + x<sup>7</sup> + x<sup>3</sup> + x<sup>2</sup> + 1''. To map integers to finite field elements, simply treat each bit ''i'' (with value ''2<sup>i</sup>'') in the integer as the coefficient of ''x<sup>i</sup>'' in the polynomial representation. For example the integer ''101 = 2<sup>6</sup> + 2<sup>5</sup> + 2<sup>2</sup> + 1'' is mapped to field element ''x<sup>6</sup> + x<sup>5</sup> + x<sup>2</sup> + 1''. These field elements can be added and multiplied together, but the specifics of that are out of scope for this document. + +A short ID sketch with capacity ''c'' consists of a sequence of ''c'' field elements. The first is the sum of all short IDs in the set, the second is the sum of the 3rd powers of all short IDs, the third is the sum of the 5th powers etc., up to the last element with is the sum of the ''(2c-1)''th powers. These elements are then encoded as 32-bit integers in little endian byte order, resulting in a ''4c''-byte serialization. + +The following Python 3.2+ code implements the creation of sketches: <pre> +FIELD_BITS = 32 +FIELD_MODULUS = (1 << FIELD_BITS) + 0b10001101 + +def mul2(x): + """Compute 2*x in GF(2^FIELD_BITS)""" + return (x << 1) ^ (FIELD_MODULUS if x.bit_length() >= FIELD_BITS else 0) + +def mul(x, y): + """Compute x*y in GF(2^FIELD_BITS)""" + ret = 0 + for bit in [(x >> i) & 1 for i in range(x.bit_length())]: + ret, y = ret ^ bit * y, mul2(y) + return ret + +def create_sketch(shortids, capacity): + """Compute the bytes of a sketch for given shortids and given capacity.""" + odd_sums = [0 for _ in range(capacity)] + for shortid in shortids: + squared = mul(shortid, shortid) + for i in range(capacity): + odd_sums[i] ^= shortid + shortid = mul(shortid, squared) + return b''.join(elem.to_bytes(4, 'little') for elem in odd_sums) +</pre> + +The [https://github.com/sipa/minisketch/ minisketch] library implements the construction, merging, and decoding of these sketches efficiently. + +====Truncated transaction IDs==== + +For announcing and relaying transaction outside of reconciliation, we need an unambiguous, unsalted way to refer to transactions to deduplicate transaction requests. As we're introducing a new scheme anyway, this is a good opportunity to switch to wtxid-based requests rather than txid-based ones. While using full 256-bit wtxids is possible, this is overkill as they contribute significantly to the total bandwidth as well. Instead, we truncate the wtxid to just their first 128 bits. These are referred to as truncated IDs. + +===Intended Protocol Flow=== + +Set reconciliation primarily consists of the transmission and decoding of a reconciliation set sketch upon request. + +[[File:bip-0330/recon_scheme_merged.png|framed|center|Set reconciliation protocol flow]] + +====Bisection==== + +If a node is unable to reconstruct the set difference from the received sketch, the node then makes an additional reconciliation request, similar to the initial one, but this request is applied to only a fraction of possible transactions (e.g., in the range 0x0–0x8). Because of the linearity of sketches, a sketch of a subset of transactions would allow the node to compute a sketch for the remainder, which saves bandwidth. + +[[File:bip-0330/bisection.png|framed|300px|center|Bisection]] + +===New messages=== +Several new protocol messages are added: sendrecon, reqreconcil, sketch, reqbisec, reconcildiff, invtx, gettx. This section describes their serialization, contents, and semantics. + +In what follows, all integers are serialized in little-endian byte order. Boolean values are encoded as a single byte that must be 0 or 1 exactly. Arrays are serialized with the CompactSize prefix that encodes their length, as is common in other P2P messages. + +====sendrecon==== +The sendrecon message announces support for the reconciliation protocol. It is expected to be only sent once, and ignored by nodes that don't support it. + +Its payload consists of: +{|class="wikitable" +! Data type !! Name !! Description +|- +| bool || sender || Indicates whether the sender will send "reqreconcil" message +|- +| bool || responder || Indicates whether the sender will respond to "reqreconcil" messages. +|- +| uint32 || version || Sender must set this to 1 currently, otherwise receiver should ignore the message. +|- +| uint64 || salt || The salt used in the short transaction ID computation. +|} + +"reqreconcil" messages can only be sent if the sender has sent a "sendrecon" message with sender=true, and the receiver has sent a "sendrecon" message with responder=true. + +====reqreconcil==== +The reqreconcil message initiates a reconciliation round. + +{|class="wikitable" +! Data type !! Name !! Description +|- +| uint16 || set_size || Size of the sender's reconciliation set, used to estimate set difference. +|- +| uint8 || q || Coefficient used to estimate set difference. Multiplied by PRECISION=2^6 and rounded up by the sender and divided by PRECISION by the receiver. +|} + +Upon receipt of a "reqreconcil" message, the receiver: +* Constructs and sends a "sketch" message (see below), with a sketch of capacity computed as ''|set_size - local_set_size| + q * (set_size + local_set_size) + c'', where ''local_set_size'' represents size of the receiver's reconciliation set. +* Makes a snapshot of their current reconciliation set, and clears the set itself. The snapshot is kept until a "reconcildiff" message is received by the node. + +It is suggested to use ''c=1'' to avoid sending empty sketches and reduce the overhead caused by under-estimations. + +Intuitively, ''q'' represents the discrepancy in sets: the closer the sets are, the lower optimal ''q'' is. +As suggested by Erlay, ''q'' should be derived as an optimal ''q'' value for the previous reconciliation with a given peer, once the actual set sizes and set difference are known. Alternatively, ''q=0.1'' should be used as a default value. +For example, if in previous round ''set_size=30'' and ''local_set_size=20'', and the *actual* difference was ''4'', then a node should compute ''q'' as following: +''q=(|30-20| - 1) / (30+20)=0.18'' +The derivation of ''q'' can be changed according to the version of the protocol. + +No new "reqreconcil" message can be sent until a "reconcildiff" message is sent. + +====sketch==== +The sketch message is used to communicate a sketch required to perform set reconciliation. + +{|class="wikitable" +! Data type !! Name !! Description +|- +| byte[] || skdata || The sketch of the sender's reconciliation snapshot +|} + +Upon receipt of a "sketch" message, a node computes the set difference by combining the receiver sketch with a sketch computed locally for a corresponding reconciliation set. If this is the 2nd time for this round a "sketch" message was received, the bisection approach is used, and by combining the new sketch with the previous one, two difference sketches are obtained, one for the first half and one for the second half of the short id range. The receiving node then tries to decode this sketch (or sketches), and based on the result: +* If decoding fails, a "reconcildiff" message is sent with the failure flag set (success=false). If this was the first "sketch" in the round, a "reqbisec" message may be sent instead. +* If decoding succeeds, a "reconcildiff" message is sent with the truncated IDs of all locally known transactions that appear in the decode result, and the short IDs of the unrecognized ones. + +The receiver also makes snapshot of their current reconciliation set, and clears the set itself. The snapshot is kept until a "reconcildiff" message is sent by the node. + +====reqbisec==== +The reqbisec message is used to signal that set reconciliation has failed and an extra sketch is needed to find set difference. + +It has an empty payload. + +Upon receipt of a "reqbisec" message, a node responds to it with a "sketch" message, which contains a sketch of a subset of corresponding reconciliation set <b>snapshot</b> (stored when "reqreconcil" message for the current round was processed) (values in range ''[0..(2^31)]''). + +====reconcildiff==== +The reconcildiff message is used to announce transactions which are found to be missing during set reconciliation on the sender's side. + +{|class="wikitable" +! Data type !! Name !! Description +|- +| uint8 || success || Indicates whether sender of the message succeeded at set difference decoding. +|- +| uint32[] || ask_shortids || The short IDs that the sender did not have. +|} + +Upon receipt a "reconcildiff" message with ''success=1'', a node sends a "invtx" message for the transactions requested by 32-bit IDs (first vector) containing their 128-bit truncated IDs (with parent transactions occuring before their dependencies), and can request announced transactions (second vector) it does not have via a "gettx" message. +Otherwise if ''success=0'', receiver should request bisection via ''reqbisec'' (if failure happened for the first time). +If failure happened for the second time, receiver should announce the transactions from the reconciliation set via an "invtx" message, excluding the transactions announced from the sender. + +The <b>snapshot</b> of the corresponding reconciliation set is cleared by the sender and the receiver of the message. + +The sender should also send their own "invtx" message along with the reconcildiff message to announce transactions which are missing on the receiver's side. + +====invtx==== +The invtx message is used to announce transactions (both along with reconcildiff message and as a response to the reconcildiff message). It is the truncated ID analogue of "inv" (which cannot be used because it has 256-bit elements). + +{|class="wikitable" +! Data type !! Name !! Description +|- +| uint128[] || inv_truncids || The truncated IDs of transactions the sender believes the receiver does not have. +|} + +Upon receipt a "invtx" message, a node requests announced transactions it does not have. +The <b>snapshot</b> of the corresponding reconciliation set is cleared by the sender of the message. + +====gettx==== +The gettx message is used to request transactions by 128-bit truncated IDs. It is the truncated ID analogue of "getdata". + +{|class="wikitable" +! Data type !! Name !! Description +|- +| uint128[] || ask_truncids || The truncated IDs of transactions the sender wants the full transaction data for. +|} + +Upon receipt a "gettx" message, a node sends "tx" messages for the requested transactions. + +==Local state== + +This BIP suggests a stateful protocol and it requires storing several variables at every node to operate properly. + +====Reconciliation sets==== +Every node stores a set of 128-bit truncated IDs for every peer which supports transaction reconciliation, representing the transactions which would have been sent according to the regular flooding protocol. +Incoming transactions are added to sets when those transactions are received (if they satisfy the policies such as minimum fee set by a peer). +A reconciliation set is moved to the corresponding set snapshot after the transmission of the initial sketch. + +====Reconciliation set snapshot==== +After the transmitting of the initial sketch (either sending or receiving of reconcildiff message), every node should store the snapshot of the current reconciliation set, and clear the set. +This is important to make bisection more stable during the reconciliation round (bisection should be applied to the snapshot). +The snapshot is also used to efficiently lookup the transactions requested by short ID. +The snapshot is cleared after the end of the reconciliation round (sending or receiving of the reconcildiff message). + +====q-coefficient==== +The q value should be stored to make efficient difference estimation. It is shared across peers and changed after every reconciliation. +q-coefficient represents the discrepancy in sets: the closer the sets are, the lower optimal ''q'' is. +In future implementations, q could vary across different peers or become static. + + +==Backward compatibility== + +Older clients remain fully compatible and interoperable after this change. + +Clients which do not implement this protocol remain fully compatible after this change using existing protocols, because transaction announcement reconciliation is used only for peers that negotiate support for it. + +==Rationale== + +====Why using PinSketch for set reconciliation?==== + +PinSketch is more bandwidth efficient than IBLT, especially for the small differences in sets we expect to operate over. +PinSketch is as bandwidth efficient as CPISync, but PinSketch has quadratic decoding complexity, while CPISync have cubic decoding complexity. This makes PinSketch significantly faster. + +====Why using 32-bit short transaction IDs?==== + +To use Minisketch in practice, transaction IDs should be shortened (ideally, not more than 64 bits per element). +Small number of bits per transaction also allows to save extra bandwidth and make operations over sketches faster. +According to our estimates, 32 bits provides low collision rate in a non-adversarial model (which is enabled by using independent salts per-link). + +====Why using 128-bit short IDs?==== + +To avoid problems caused by the delays in the network, our protocol requires extra round of announcing unsalted transaction IDs. [https://arxiv.org/pdf/1905.10518.pdf Erlay] protocol on top of this work also requires announcing unsalted transaction IDs for flooding. +Both of these measures allow to deduplicate transaction announcements across the peers. +However, using full 256-bit IDs to uniquely identify transactions seems to be an overkill. +128 is the highest power of 2 which provides good enough collision-resistance in an adversarial model, and trivially saves a significant portion of the bandwidth related to these announcements. + +====Why using bisection instead of extending the sketch?==== + +Unlike extended sketches, bisection does not require operating over sketches of higher order. +This allows to avoid the high computational cost caused by quadratic decoding complexity. + +==Implementation== + +TODO + +==Acknowledgments== + +A large fraction of this proposal was done during designing Erlay with Gregory Maxwell, Sasha Fedorova and Ivan Beschastnikh. +We would like to thank Suhas Daftuar for contributions to the design and BIP structure. +We would like to thank Ben Woosley for contributions to the high-level description of the idea. + +==Copyright== + +This document is licensed under the Creative Commons CC0 1.0 Universal license. diff --git a/bip-0330/bisection.png b/bip-0330/bisection.png Binary files differnew file mode 100644 index 0000000..70f37e8 --- /dev/null +++ b/bip-0330/bisection.png diff --git a/bip-0330/minisketch.py b/bip-0330/minisketch.py new file mode 100755 index 0000000..f64286f --- /dev/null +++ b/bip-0330/minisketch.py @@ -0,0 +1,157 @@ +#!/usr/bin/env python3 + +######## ENCODING and DECODING ######## + +FIELD_BITS = 32 +FIELD_MODULUS = (1 << FIELD_BITS) + 0b10001101 + +def mul2(x): + """Compute 2*x in GF(2^FIELD_BITS)""" + return (x << 1) ^ (FIELD_MODULUS if x.bit_length() >= FIELD_BITS else 0) + +def mul(x, y): + """Compute x*y in GF(2^FIELD_BITS)""" + ret = 0 + for bit in [(x >> i) & 1 for i in range(x.bit_length())]: + ret ^= bit * y + y = mul2(y) + return ret + +######## ENCODING only ######## + +def sketch(shortids, capacity): + """Compute the bytes of a sketch for given shortids and given capacity.""" + odd_sums = [0 for _ in range(capacity)] + for shortid in shortids: + squared = mul(shortid, shortid) + for i in range(capacity): + odd_sums[i] ^= shortid + shortid = mul(shortid, squared) + return b''.join(elem.to_bytes(4, 'little') for elem in odd_sums) + +######## DECODING only ######## + +import random + +def inv(x): + """Compute 1/x in GF(2^FIELD_BITS)""" + t = x + for i in range(FIELD_BITS - 2): + t = mul(mul(t, t), x) + return mul(t, t) + + +def berlekamp_massey(s): + """Given a sequence of LFSR outputs, find the coefficients of the LFSR.""" + C, B, L, m, b = [1], [1], 0, 1, 1 + for n in range(len(s)): + d = s[n] + for i in range(1, L + 1): + d ^= mul(C[i], s[n - i]) + if d == 0: + m += 1 + else: + T = list(C) + while len(C) <= len(B) + m: + C += [0] + t = mul(d, inv(b)) + for i in range(len(B)): + C[i + m] ^= mul(t, B[i]) + if 2 * L <= n: + L, B, b, m = n + 1 - L, T, d, 1 + else: + m += 1 + return C[0:L + 1] + +def poly_monic(p): + """Return the monic multiple of p, or 0 if the input is 0.""" + if len(p) == 0: + return [] + i = inv(p[-1]) + return [mul(v, i) for v in p] + +def poly_divmod(m, p): + """Compute the polynomial quotient p/m, and replace p with p mod m.""" + assert(len(m) > 0 and m[-1] == 1) + div = [0 for _ in range(len(p) - len(m) + 1)] + while len(p) >= len(m): + div[len(p) - len(m)] = p[-1] + for i in range(len(m)): + p[len(p) - len(m) + i] ^= mul(p[-1], m[i]) + assert(p[-1] == 0) + p.pop() + while (len(p) > 0 and p[-1] == 0): + p.pop() + return div + +def poly_gcd(a, b): + """Compute the GCD of a and b (destroys the inputs).""" + if len(a) < len(b): + a, b = b, a + while len(b): + if len(b) == 1: + return [1] + b = poly_monic(b) + poly_divmod(b, a) + a, b = b, a + return a + +def poly_sqr(p): + """Compute the coefficients of the square of polynomial with coefficients p.""" + return [0 if i & 1 else mul(p[i // 2], p[i // 2]) for i in range(2 * len(p))] + +def poly_trace(m, a): + """Compute the coefficients of the trace polynomial of (a*x) mod m.""" + out = [0, a] + for i in range(FIELD_BITS - 1): + out = poly_sqr(out) + while len(out) < 2: + out += [0] + out[1] = a + poly_divmod(m, out) + return out + +def find_roots_inner(p, a): + """Recursive helper function for find_roots (destroys p). a is randomizer.""" + # p must be monic + assert(len(p) > 0 and p[-1] == 1) + # Deal with degree 0 and degree 1 inputs + if len(p) == 1: + return [] + elif len(p) == 2: + return [p[0]] + # Otherwise, split p in left*right using paramater a_vals[0]. + t = poly_monic(poly_trace(p, a)) + left = poly_gcd(list(p), t) + right = poly_divmod(list(left), p) + # Invoke recursion with the remaining a_vals. + ret_right = find_roots_inner(right, mul2(a)) + ret_left = find_roots_inner(left, mul2(a)) + # Concatenate roots + return ret_left + ret_right + +def find_roots(p): + """Find the roots of polynomial with coefficients p.""" + # Compute x^(2^FIELD_BITS)+x mod p in a roundabout way. + t = poly_trace(p, 1) + t2 = poly_sqr(t) + for i in range(len(t)): + t2[i] ^= t[i] + poly_divmod(p, t2) + # If distinct from 0, p is not fully factorizable into non-repeating roots. + if len(t2): + return None + # Invoke the recursive splitting algorithm + return find_roots_inner(list(p), random.randrange(1, 2**32-1)) + +def decode(sketch): + """Recover the shortids from a sketch.""" + odd_sums = [int.from_bytes(sketch[i*4:(i+1)*4], 'little') for i in range(len(sketch) // 4)] + sums = [] + for i in range(len(odd_sums) * 2): + if i & 1: + sums.append(mul(sums[(i-1)//2], sums[(i-1)//2])) + else: + sums.append(odd_sums[(i+1)//2]) + return find_roots(list(reversed(berlekamp_massey(sums)))) + diff --git a/bip-0330/recon_scheme_merged.png b/bip-0330/recon_scheme_merged.png Binary files differnew file mode 100644 index 0000000..11d1559 --- /dev/null +++ b/bip-0330/recon_scheme_merged.png 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 |
