Bitcoin Improvement Proposals

Related tags

Cryptography bips
Overview

People wishing to submit BIPs, first should propose their idea or document to the [email protected] mailing list (do not assign a number - read BIP 2 for the full process). After discussion, please open a PR. After copy-editing and acceptance, it will be published here.

We are fairly liberal with approving BIPs, and try not to be too involved in decision making on behalf of the community. The exception is in very rare cases of dispute resolution when a decision is contentious and cannot be agreed upon. In those cases, the conservative option will always be preferred.

Having a BIP here does not make it a formally accepted standard until its status becomes Final or Active.

Those proposing changes should consider that ultimately consent may rest with the consensus of the Bitcoin users (see also: economic majority).

Number Layer Title Owner Type Status
1 BIP Purpose and Guidelines Amir Taaki Process Replaced
2 BIP process, revised Luke Dashjr Process Active
8 Version bits with lock-in by height Shaolin Fry, Luke Dashjr Informational Draft
9 Version bits with timeout and delay Pieter Wuille, Peter Todd, Greg Maxwell, Rusty Russell Informational Final
10 Applications Multi-Sig Transaction Distribution Alan Reiner Informational Withdrawn
11 Applications M-of-N Standard Transactions Gavin Andresen Standard Final
12 Consensus (soft fork) OP_EVAL Gavin Andresen Standard Withdrawn
13 Applications Address Format for pay-to-script-hash Gavin Andresen Standard Final
14 Peer Services Protocol Version and User Agent Amir Taaki, Patrick Strateman Standard Final
15 Applications Aliases Amir Taaki Standard Deferred
16 Consensus (soft fork) Pay to Script Hash Gavin Andresen Standard Final
17 Consensus (soft fork) OP_CHECKHASHVERIFY (CHV) Luke Dashjr Standard Withdrawn
18 Consensus (soft fork) hashScriptCheck Luke Dashjr Standard Proposed
19 Applications M-of-N Standard Transactions (Low SigOp) Luke Dashjr Standard Rejected
20 Applications URI Scheme Luke Dashjr Standard Replaced
21 Applications URI Scheme Nils Schneider, Matt Corallo Standard Final
22 API/RPC getblocktemplate - Fundamentals Luke Dashjr Standard Final
23 API/RPC getblocktemplate - Pooled Mining Luke Dashjr Standard Final
30 Consensus (soft fork) Duplicate transactions Pieter Wuille Standard Final
31 Peer Services Pong message Mike Hearn Standard Final
32 Applications Hierarchical Deterministic Wallets Pieter Wuille Informational Final
33 Peer Services Stratized Nodes Amir Taaki Standard Rejected
34 Consensus (soft fork) Block v2, Height in Coinbase Gavin Andresen Standard Final
35 Peer Services mempool message Jeff Garzik Standard Final
36 Peer Services Custom Services Stefan Thomas Standard Rejected
37 Peer Services Connection Bloom filtering Mike Hearn, Matt Corallo Standard Final
38 Applications Passphrase-protected private key Mike Caldwell, Aaron Voisine Standard Draft
39 Applications Mnemonic code for generating deterministic keys Marek Palatinus, Pavol Rusnak, Aaron Voisine, Sean Bowe Standard Proposed
40 API/RPC Stratum wire protocol Marek Palatinus Standard BIP number allocated
41 API/RPC Stratum mining protocol Marek Palatinus Standard BIP number allocated
42 Consensus (soft fork) A finite monetary supply for Bitcoin Pieter Wuille Standard Final
43 Applications Purpose Field for Deterministic Wallets Marek Palatinus, Pavol Rusnak Informational Final
44 Applications Multi-Account Hierarchy for Deterministic Wallets Marek Palatinus, Pavol Rusnak Standard Proposed
45 Applications Structure for Deterministic P2SH Multisignature Wallets Manuel Araoz, Ryan X. Charles, Matias Alejo Garcia Standard Proposed
47 Applications Reusable Payment Codes for Hierarchical Deterministic Wallets Justus Ranvier Informational Draft
48 Applications Multi-Script Hierarchy for Multi-Sig Wallets Fontaine Standard Proposed
49 Applications Derivation scheme for P2WPKH-nested-in-P2SH based accounts Daniel Weigl Informational Final
50 March 2013 Chain Fork Post-Mortem Gavin Andresen Informational Final
52 Consensus (hard fork) Durable, Low Energy Bitcoin PoW Michael Dubrovsky, Bogdan Penkovsky Standard Draft
60 Peer Services Fixed Length "version" Message (Relay-Transactions Field) Amir Taaki Standard Draft
61 Peer Services Reject P2P message Gavin Andresen Standard Final
62 Consensus (soft fork) Dealing with malleability Pieter Wuille Standard Withdrawn
63 Applications Stealth Addresses Peter Todd Standard BIP number allocated
64 Peer Services getutxo message Mike Hearn Standard Obsolete
65 Consensus (soft fork) OP_CHECKLOCKTIMEVERIFY Peter Todd Standard Final
66 Consensus (soft fork) Strict DER signatures Pieter Wuille Standard Final
67 Applications Deterministic Pay-to-script-hash multi-signature addresses through public key sorting Thomas Kerin, Jean-Pierre Rupp, Ruben de Vries Standard Proposed
68 Consensus (soft fork) Relative lock-time using consensus-enforced sequence numbers Mark Friedenbach, BtcDrak, Nicolas Dorier, kinoshitajona Standard Final
69 Applications Lexicographical Indexing of Transaction Inputs and Outputs Kristov Atlas Informational Proposed
70 Applications Payment Protocol Gavin Andresen, Mike Hearn Standard Final
71 Applications Payment Protocol MIME types Gavin Andresen Standard Final
72 Applications bitcoin: uri extensions for Payment Protocol Gavin Andresen Standard Final
73 Applications Use "Accept" header for response type negotiation with Payment Request URLs Stephen Pair Standard Final
74 Applications Allow zero value OP_RETURN in Payment Protocol Toby Padilla Standard Rejected
75 Applications Out of Band Address Exchange using Payment Protocol Encryption Justin Newton, Matt David, Aaron Voisine, James MacWhyte Standard Final
78 Applications A Simple Payjoin Proposal Nicolas Dorier Standard Draft
79 Applications Bustapay :: a practical coinjoin protocol Ryan Havar Informational Replaced
80 Hierarchy for Non-Colored Voting Pool Deterministic Multisig Wallets Justus Ranvier, Jimmy Song Informational Deferred
81 Hierarchy for Colored Voting Pool Deterministic Multisig Wallets Justus Ranvier, Jimmy Song Informational Deferred
83 Applications Dynamic Hierarchical Deterministic Key Trees Eric Lombrozo Standard Rejected
84 Applications Derivation scheme for P2WPKH based accounts Pavol Rusnak Informational Draft
85 Applications Deterministic Entropy From BIP32 Keychains Ethan Kosakovsky Informational Draft
86 Applications Key Derivation for Single Key P2TR Outputs Andrew Chow Standard Draft
87 Applications Hierarchy for Deterministic Multisig Wallets Robert Spigler Standard Proposed
88 Applications Hierarchical Deterministic Path Templates Dmitry Petukhov Informational Proposed
90 Buried Deployments Suhas Daftuar Informational Final
91 Consensus (soft fork) Reduced threshold Segwit MASF James Hilliard Standard Final
98 Consensus (soft fork) Fast Merkle Trees Mark Friedenbach, Kalle Alm, BtcDrak Standard Draft
99 Motivation and deployment of consensus rule changes ([soft/hard]forks) Jorge Timón Informational Rejected
100 Consensus (hard fork) Dynamic maximum block size by miner vote Jeff Garzik, Tom Harding, Dagur Valberg Johannsson Standard Rejected
101 Consensus (hard fork) Increase maximum block size Gavin Andresen Standard Withdrawn
102 Consensus (hard fork) Block size increase to 2MB Jeff Garzik Standard Rejected
103 Consensus (hard fork) Block size following technological growth Pieter Wuille Standard Withdrawn
104 Consensus (hard fork) 'Block75' - Max block size like difficulty t.khan Standard Rejected
105 Consensus (hard fork) Consensus based block size retargeting algorithm BtcDrak Standard Rejected
106 Consensus (hard fork) Dynamically Controlled Bitcoin Block Size Max Cap Upal Chakraborty Standard Rejected
107 Consensus (hard fork) Dynamic limit on the block size Washington Y. Sanchez Standard Rejected
109 Consensus (hard fork) Two million byte size limit with sigop and sighash limits Gavin Andresen Standard Rejected
111 Peer Services NODE_BLOOM service bit Matt Corallo, Peter Todd Standard Proposed
112 Consensus (soft fork) CHECKSEQUENCEVERIFY BtcDrak, Mark Friedenbach, Eric Lombrozo Standard Final
113 Consensus (soft fork) Median time-past as endpoint for lock-time calculations Thomas Kerin, Mark Friedenbach Standard Final
114 Consensus (soft fork) Merkelized Abstract Syntax Tree Johnson Lau Standard Rejected
115 Consensus (soft fork) Generic anti-replay protection using Script Luke Dashjr Standard Rejected
116 Consensus (soft fork) MERKLEBRANCHVERIFY Mark Friedenbach, Kalle Alm, BtcDrak Standard Draft
117 Consensus (soft fork) Tail Call Execution Semantics Mark Friedenbach, Kalle Alm, BtcDrak Standard Draft
118 Consensus (soft fork) SIGHASH_ANYPREVOUT for Taproot Scripts Christian Decker, Anthony Towns Standard Draft
119 Consensus (soft fork) CHECKTEMPLATEVERIFY Jeremy Rubin Standard Draft
120 Applications Proof of Payment Kalle Rosenbaum Standard Withdrawn
121 Applications Proof of Payment URI scheme Kalle Rosenbaum Standard Withdrawn
122 Applications URI scheme for Blockchain references / exploration Marco Pontello Standard Draft
123 BIP Classification Eric Lombrozo Process Active
124 Applications Hierarchical Deterministic Script Templates Eric Lombrozo, William Swanson Informational Rejected
125 Applications Opt-in Full Replace-by-Fee Signaling David A. Harding, Peter Todd Standard Proposed
126 Best Practices for Heterogeneous Input Script Transactions Kristov Atlas Informational Draft
127 Applications Simple Proof-of-Reserves Transactions Steven Roose Standard Draft
129 Applications Bitcoin Secure Multisig Setup (BSMS) Hugo Nguyen, Peter Gray, Marko Bencun, Aaron Chen, Rodolfo Novak Standard Proposed
130 Peer Services sendheaders message Suhas Daftuar Standard Proposed
131 Consensus (hard fork) "Coalescing Transaction" Specification (wildcard inputs) Chris Priest Standard Rejected
132 Committee-based BIP Acceptance Process Andy Chase Process Withdrawn
133 Peer Services feefilter message Alex Morcos Standard Draft
134 Consensus (hard fork) Flexible Transactions Tom Zander Standard Rejected
135 Generalized version bits voting Sancho Panza Informational Rejected
136 Applications Bech32 Encoded Tx Position References Велеслав, Jonas Schnelli, Daniel Pape Informational Draft
137 Applications Signatures of Messages using Private Keys Christopher Gilliard Standard Final
140 Consensus (soft fork) Normalized TXID Christian Decker Standard Rejected
141 Consensus (soft fork) Segregated Witness (Consensus layer) Eric Lombrozo, Johnson Lau, Pieter Wuille Standard Final
142 Applications Address Format for Segregated Witness Johnson Lau Standard Withdrawn
143 Consensus (soft fork) Transaction Signature Verification for Version 0 Witness Program Johnson Lau, Pieter Wuille Standard Final
144 Peer Services Segregated Witness (Peer Services) Eric Lombrozo, Pieter Wuille Standard Final
145 API/RPC getblocktemplate Updates for Segregated Witness Luke Dashjr Standard Final
146 Consensus (soft fork) Dealing with signature encoding malleability Johnson Lau, Pieter Wuille Standard Withdrawn
147 Consensus (soft fork) Dealing with dummy stack element malleability Johnson Lau Standard Final
148 Consensus (soft fork) Mandatory activation of segwit deployment Shaolin Fry Standard Final
149 Consensus (soft fork) Segregated Witness (second deployment) Shaolin Fry Standard Withdrawn
150 Peer Services Peer Authentication Jonas Schnelli Standard Draft
151 Peer Services Peer-to-Peer Communication Encryption Jonas Schnelli Standard Withdrawn
152 Peer Services Compact Block Relay Matt Corallo Standard Final
154 Peer Services Rate Limiting via peer specified challenges Karl-Johan Alm Standard Withdrawn
155 Peer Services addrv2 message Wladimir J. van der Laan Standard Draft
156 Peer Services Dandelion - Privacy Enhancing Routing Brad Denby, Andrew Miller, Giulia Fanti, Surya Bakshi, Shaileshh Bojja Venkatakrishnan, Pramod Viswanath Standard Rejected
157 Peer Services Client Side Block Filtering Olaoluwa Osuntokun, Alex Akselrod, Jim Posen Standard Draft
158 Peer Services Compact Block Filters for Light Clients Olaoluwa Osuntokun, Alex Akselrod Standard Draft
159 Peer Services NODE_NETWORK_LIMITED service bit Jonas Schnelli Standard Draft
171 Applications Currency/exchange rate information API Luke Dashjr Standard Rejected
173 Applications Base32 address format for native v0-16 witness outputs Pieter Wuille, Greg Maxwell Informational Final
174 Applications Partially Signed Bitcoin Transaction Format Andrew Chow Standard Final
175 Applications Pay to Contract Protocol Omar Shibli, Nicholas Gregory Informational Rejected
176 Bits Denomination Jimmy Song Informational Draft
178 Applications Version Extended WIF Karl-Johan Alm Standard Draft
179 Name for payment recipient identifiers Emil Engler, MarcoFalke, Luke Dashjr Informational Draft
180 Peer Services Block size/weight fraud proof Luke Dashjr Standard Rejected
197 Applications Hashed Time-Locked Collateral Contract Matthew Black, Tony Cai Standard Draft
199 Applications Hashed Time-Locked Contract transactions Sean Bowe, Daira Hopwood Standard Draft
300 Consensus (soft fork) Hashrate Escrows (Consensus layer) Paul Sztorc, CryptAxe Standard Draft
301 Consensus (soft fork) Blind Merged Mining (Consensus layer) Paul Sztorc, CryptAxe Standard Draft
310 Applications Stratum protocol extensions Pavel Moravec, Jan Čapek Informational Draft
320 nVersion bits for general purpose use BtcDrak Standard Draft
322 Applications Generic Signed Message Format Karl-Johan Alm Standard Draft
325 Applications Signet Karl-Johan Alm, Anthony Towns Standard Proposed
330 Peer Services Transaction announcements reconciliation Gleb Naumenko, Pieter Wuille Standard Draft
338 Peer Services Disable transaction relay message Suhas Daftuar Standard Draft
339 Peer Services WTXID-based transaction relay Suhas Daftuar Standard Draft
340 Schnorr Signatures for secp256k1 Pieter Wuille, Jonas Nick, Tim Ruffing Standard Draft
341 Consensus (soft fork) Taproot: SegWit version 1 spending rules Pieter Wuille, Jonas Nick, Anthony Towns Standard Draft
342 Consensus (soft fork) Validation of Taproot Scripts Pieter Wuille, Jonas Nick, Anthony Towns Standard Draft
343 Consensus (soft fork) Mandatory activation of taproot deployment Shinobius, Michael Folkson Standard Proposed
350 Applications Bech32m format for v1+ witness addresses Pieter Wuille Standard Draft
370 Applications PSBT Version 2 Andrew Chow Standard Draft
371 Applications Taproot Fields for PSBT Andrew Chow Standard Draft
380 Applications Output Script Descriptors General Operation Pieter Wuille, Andrew Chow Informational Draft
381 Applications Non-Segwit Output Script Descriptors Pieter Wuille, Andrew Chow Informational Draft
382 Applications Segwit Output Script Descriptors Pieter Wuille, Andrew Chow Informational Draft
383 Applications Multisig Output Script Descriptors Pieter Wuille, Andrew Chow Informational Draft
384 Applications combo() Output Script Descriptors Pieter Wuille, Andrew Chow Informational Draft
385 Applications raw() and addr() Output Script Descriptors Pieter Wuille, Andrew Chow Informational Draft
386 Applications tr() Output Script Descriptors Pieter Wuille, Andrew Chow Informational Draft
Comments
  • BIP39 French Wordlist - My proposal

    BIP39 French Wordlist - My proposal

    @voisine

    Here are my restrictions:

    1. High priority on simple and common french words.
    2. Only words with 5-8 letters.
    3. A word is fully recognizable by typing the first 4 letters (special french characters "é-è" are considered equal to "e", for exemple "museau" and "musée" can not be together).
    4. Only infinitive verbs, adjectives and nouns.
    5. No pronouns, no adverbs, no prepositions, no conjunctions, no interjections (unless a noun/adjective is also popular than its interjection like "mince;chouette").
    6. No numeral adjectives.
    7. No words in the plural (except invariable words like "univers", or same spelling than singular like "heureux").
    8. No female adjectives (except words with same spelling for male and female adjectives like "magique").
    9. No words with several senses AND different spelling in speaking like "verre-vert", unless a word has a meaning much more popular than another like "perle" and "pairle".
    10. No very similar words with 1 letter of difference.
    11. No essentially reflexive verbs (unless a verb is also a noun like "souvenir").
    12. No words with "ô;â;ç;ê;œ;æ;î;ï;û;ù;à;ë;ÿ".
    13. No words ending by "é;ée;è;et;ai;ait".
    14. No demonyms.
    15. No words in conflict with the spelling corrections of 1990 (http://goo.gl/Y8DU4z).
    16. No embarrassing words (in a very, very large scope) or belonging to a particular religion.
    17. No identical words with the Spanish wordlist (as Y75QMO wants).

    4 wordlists used:

    • http://pastebin.com/Drs1HY0v (3726 words) from http://o.bacquet.free.fr/db2.htm
    • http://goo.gl/ymSBeY (336531 words) from http://www.pallier.org/ressources/dicofr/dicofr.html
    • http://dict.xmatiere.com/noms_communs_par_nombre_de_lettres.php
    • Thomas Voegtlin's wordlist

    Spelling verified with Hunspell French Dictionnary (1990 and Classique) in Notepad++, and meaning verified with https://fr.wiktionary.org and http://www.larousse.fr/ for hundreds words.

    Guys can review: @ecdsa @NicolasDorier @EricLarch @nicolasbigot @pollastri-pierre

    Thanks to Thomas Voegtlin for his wordlist!

    Please wait before merging.

    --- The following message is partially outdated because of the evolution of the wordlist. ---

    J'ai défini un maximum de restrictions "raisonnables" pour qu'un individu puisse deviner le plus facilement possible un de ses mots en cas d'oubli (ou s'en souvenir facilement).

    Pour les mots "embarrassants", il s'agit de mots qui peuvent être assimilés à une vilaine insulte, de certains mots relatifs à une maladie grave, à la mort, à la pauvreté, au crime, à la violence, au domaine médical, à des attitudes et bien d'autres.

    J'ai fait de mon mieux pour supprimer les mots qui présentaient une ressemblance avec un autre mot, à l'oral comme à l'écrit. Plusieurs centaines de mots qui avaient une différence de 1 lettre (ou 1 lettre différente) avec un autre mot ont été supprimés. Je considère que le résultat est plutôt satisfaisant, loin d'être parfait, mais tout à fait correct. Aussi, les restrictions n°6 et 10 sont complémentaires à ce problème.

    J'estime qu'il y a 1% de mots potentiellement inconnus du public (comme "quantum"), et 5% de mots avec des sens qui sont potentiellement incertains par le public (comme "fongible"). Je considère ces marges comme convenables.

    Notez que certains éléments chimiques du tableau périodique sont présents, les plus populaires.

    Pour une vérification plaisante, voici la version imprimable (5 pages PDF A4): https://www.dropbox.com/sh/xlq3x2anb706uw1/AADUYAqcBvkvUPdhwC2uLWmEa?dl=0

    Si vous voulez vérifier en 1 lecture, focalisez-vous sur les restrictions n°2,3,5,8 et 11. Étant donné l'homogénéité de la liste (et le bon sens qu'elle doit avoir), les mots contraires aux restrictions n°1,4 et 13 devront vous sauter aux yeux. Comptez 15 minutes de lecture par page. Je recommande quand même une deuxième lecture.

    J'espère que vous apprécierez cette wordlist, c'est un travail de plus de 70 heures que je n'envisageais pas de faire au début, étant donné l'ampleur et la responsabilité de la tâche.

    Si un mot vous semble inapproprié, ou si vous avez des remarques à faire par rapport aux restrictions, vous pouvez m'en faire part.

    Sachez aussi que si elle vous convient, elle sera intégrée dans une des prochaines versions de breadwallet avec les autres wordlists étrangères.

    opened by Kirvx 87
  • BIP341: speedy trial activation parameters

    BIP341: speedy trial activation parameters

    Adds mainnet and testnet3 activation parameters. This uses the "speedy trial" approach [0] with some refinements to the exact mechanism [1], as implemented in bitcoin/bitcoin#21377 . Parameters are selected based on previous discussions [2] [3] [4]. The parameters are:

    • starttime = 2021-04-24 00:00 UTC
    • timeout = 2021-08-11 00:00 UTC
    • min_activation_height = 709632 (est mid November 2021, mainnet only)
    • threshold = 1815 / 2016 blocks (90%, mainnet only)

    In terms of block heights, that will likely mean the first signalling period for mainnet should start at height 681408, approximately April 29th UTC, and will likely mean signalling will continue for 8 retarget periods until height 697536 (which if blocks arrived at 10 minute intervals, would be due around 2021-08-20).

    [0] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-March/018583.html [1] https://github.com/bitcoin/bitcoin/pull/21377#issuecomment-814494847 [2] (90%) https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018425.html [3] (May/August/Nov) https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-March/018715.html [4] (specific parameters) https://github.com/bitcoin/bips/pull/1081

    opened by ajtowns 66
  • bip174: add global xpub field

    bip174: add global xpub field

    Adds a global type for xpubs as discussed on the bitcoin-dev mailing list: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-April/016894.html

    opened by achow101 62
  • Remove 'hard fork' designation on BIP 90

    Remove 'hard fork' designation on BIP 90

    #478 added a label to BIP 90 that I disagree with. While the term "hard fork" is sometimes used in the way defined in BIP 123, it also is used by many -- including the BIP 123 author -- to refer to consensus changes that require network-wide coordination in deployment to avoid a chain split[1], which is untrue for BIP 90.

    As the whole purpose of this BIP is explain the type of consensus change that was made and point out that the network split risk is minimal, I don't accept the label "hard fork" as a useful or correct designation, and I think it does a disservice to our collective understanding of consensus changes to try to apply a label like this.

    --

    [1] From https://medium.com/@elombrozo/forks-signaling-and-activation-d60b6abda49a:

    Since hard forks loosen or eliminate existing rules, blocks which would have been rejected by the old rules are now accepted by nodes using the new rules. Examples include increasing the block reward, increasing the maximum base block size, changing the block header format, or changing the proof of work function. Nodes that do not update their rules will reject these blocks and will continue to follow only chains that enforce the old rules. This means that unless all nodes update, we will get a chain split.

    opened by sdaftuar 62
  • BIP39 changes

    BIP39 changes

    Hello,

    BIP39 is already implemented in Trezor, Multibit HD and bitcoinj 0.11. Other projects also agreed to eventually implement it (Electrum). Please merge the latest version of BIP39 and change status from Draft to Accepted.

    Thanks, Marek

    opened by slush0 61
  • BIP 136: Bech32 Encoded Tx Position References

    BIP 136: Bech32 Encoded Tx Position References

    This proposed BIP was posted to the mailing list just under two months ago. As there has been no serious objections, (unfortunately no mailing list feedback at all), I wish to formally ask for a BIP number to be assigned to our proposal.

    https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014396.html

    New BIP 
    opened by veleslavs 58
  • introduce BIP-0064: Hierarchy for Deterministic Wallets

    introduce BIP-0064: Hierarchy for Deterministic Wallets

    This BIP defines logical hierarchy for deterministic wallets based on algorithm described in BIP-0032. It is a particular application of the general idea described there.

    opened by prusnak 53
  • BIP39: Clarify necessity for ideographic spaces.

    BIP39: Clarify necessity for ideographic spaces.

    I left it unclear / open to interpretation on whether to use ideographic spaces, but realized that without being specific on its necessity, developers may implement something that would cause trouble with the Japanese user. (two words looking like one word, or phrase verification failing because it can't handle ideographic spaces, etc.)

    Hopefully, this will clear up any mis-understandings.

    opened by bip39JP 50
  • BIP155: include changes from followup discussions

    BIP155: include changes from followup discussions

    • Increase the maximum length of an address from 32 to 512 bytes and clarify that the entire message should be rejected if it contains a longer address. (from https://github.com/bitcoin/bips/pull/766#issuecomment-519248699)

    • Remove a contradiction about unknown address types - "MUST ignore" VS "MAY store and gossip".

    • Recommend gossiping addresses for unknown network ID and for networks to which the node is not currently connected to. (from https://github.com/bitcoin/bips/pull/766#issuecomment-545067608)

    • Clarify that the entire message should be rejected if it contains an address with unexpected size (e.g. IPv4 address with length 5).

    Proposed BIP modification 
    opened by vasild 43
  • Add German word list for BIP0039

    Add German word list for BIP0039

    This adds a German word list with the following properties:

    • Only ASCII letters (no äöüß, no dashs or apostrophes)
    • Only nouns in nominative case (no plurals, no genitives), i.e. all startig with an uppercase letter
    • At least 4, at most 6 letters
    • First 4 letters identify the word uniquely
    • No offensive words
    • Tried to avoid words with ambiguous spelling (Delphin, Delfin)
    Proposed BIP modification 
    opened by DavidMStraub 43
  • BIP0039 Added Japanese wordlist

    BIP0039 Added Japanese wordlist

    I have been testing with some colleagues to create a wordlist for BIP0039 for the Japanese language.

    We have decided on the current word list for the following reasons:

    1. Japanese borrowed Chinese symbol character set (Kanji) are filled with homonyms that are often only discernible via the Kanji used, we thought that would lower memorability (as the words are random, and context is not possible). This is why we chose to use only the hiragana phonetic character set.
    2. If the user inputs any character outside of the hiragana character set (such as katakana character set) the developer may automatically replace with the hiragana to check validity of the words.
    3. Hiragana is easier to write down by hand than Kanji and Katakana, and will be easy for all ages (both young and old)

    We are anxious for any comments or criticisms that you may have.

    opened by bip39JP 43
  • [New BIP] Wallet Policies

    [New BIP] Wallet Policies

    Initial version posted to bitcoin-dev in May.

    Wallet policies are implemented in the Ledger bitcoin app (in the upcoming version 2.1.0).

    The following PR experimenting with an HWI integration might provide more context and an end-to-end demo:

    • https://github.com/bitcoin-core/HWI/pull/647
    opened by bigspider 0
  • BIP 341: Fix taproot_tweak_pubkey

    BIP 341: Fix taproot_tweak_pubkey

    lift_x returns None if the input integer is not an X coordinate on the curve to indicate failure. point_add, on the other hand, interprets None as the point at infinity. Therefore, without this commit, if the internal pubkey is not a valid X coordinate, the function will not fail, which contradicts the specification in the "Script validation rules section". Instead, it sets Q to t*G.

    A test vector is being added here: https://github.com/bitcoin-core/qa-assets/pull/98

    CC @sipa @ajtowns

    opened by jonasnick 1
  • Wallet Labels Export Format

    Wallet Labels Export Format

    This was first proposed on the mailing list on Aug 24 as a common format for the export and import of wallet labels.

    Following discussion there, on this bitcointalk post and via private channels with other wallet developers, the original proposal was simplified, and changed to use JSON instead of CSV. The revised proposal has been well received, and I believe is ready for consideration as a BIP.

    Link: https://github.com/craigraw/bips/blob/master/bip-wallet-labels.mediawiki

    opened by craigraw 1
Owner
Bitcoin
Bitcoin
The Ethereum Improvement Proposal repository

Ethereum Improvement Proposals (EIPs) Ethereum Improvement Proposals (EIPs) describe standards for the Ethereum platform, including core protocol spec

null 10.8k Nov 28, 2022
A full node Bitcoin (BSV) implementation written in Go

bsvd bsvd is a full node Bitcoin (BSV) implementation written in Go (golang). This project is a port of the bchd codebase to Bitcoin (BSV). It provide

null 41 Feb 7, 2022
A db for bitcoin-sv & BTC

Welcome to go-svdb Project =========== Boquan Team The Boquan is a team dedicated to promoting and developing true bitcoin. The team has successfully

mempool.com team 31 Sep 3, 2021
Moeing chain is an EVM&Web3 compatible sidechain for Bitcoin Cash

Full node client of smartBCH This repository contains the code of the full node client of smartBCH, an EVM&Web3 compatible sidechain for Bitcoin Cash.

null 120 Oct 26, 2022
Store data on Bitcoin for 350 sats/KB up to 185 KB by using P2SH-P2WSH witness scripts

Bitcandle Store data on Bitcoin for 350 sats/KB up to 185 kB by using P2SH-P2WSH witness scripts. 225ed8bc432d37cf434f80717286fd5671f676f12b573294db72

Aurèle Oulès 11 Aug 12, 2022
A curated Golang toolkit for creating Bitcoin SV powered apps

bsv A curated Golang toolkit for creating Bitcoin SV powered apps Table of Contents Installation Maintainers License Installation bsv requires a suppo

null 21 May 10, 2022
A work-in-progress Bitcoin wallet based on Output Descriptors

go-wallet A work-in-progress Bitcoin wallet Descriptors go-wallet is designed around Bitcoin Descriptors. It implements a Output Script Descriptors la

Gustavo Chaín 5 May 4, 2022
The go-to Bitcoin Node (BN) Go library.

go-bitcoin Go wrapper for bitcoin RPC RPC services Start by creating a connection to a bitcoin node b, err := New("rcp host", rpc port, "rpc usernam

null 3 Feb 13, 2022
Bitcoin CPU miner written in Go.

CPU Miner Bitcoin CPU miner written in Go. Introduction This is a CPU miner written in Go. It is a proof of concept and is not intended for production

Yaroslav Gaponov 0 Jan 6, 2022
A fully validating Bitcoin node with Utreexo support

btcd btcd is an alternative full node bitcoin implementation written in Go (golang). This project is currently under active development and is in a Be

Utreexo 13 Sep 5, 2022
Bitcoin futures curve from Deribit as a JSON webservice

Curve Bitcoin futures curve from Deribit as a JSON webservice Building go build . Running ./curve Expiration date and annualised yield of each contr

Steven Wilkin 0 Dec 13, 2021
Bitcoin Core integration/staging tree

Bitcoin Core integration/staging tree https://bitcoincore.org For an immediately usable, binary version of the Bitcoin Core software, see https://bitc

Bitcoin 67k Nov 19, 2022
Mastering Bitcoin 2nd Edition - Programming the Open Blockchain

Code Examples: Mastering Bitcoin Mastering Bitcoin is a book for developers, although the first two chapters cover bitcoin at a level that is also app

Mastering Bitcoin 20.7k Nov 28, 2022
Full bitcoin solution written in Go (golang)

About Gocoin Gocoin is a full Bitcoin solution written in Go language (golang). The software architecture is focused on maximum performance of the nod

Piotr Narewski 899 Nov 19, 2022
A simple, concurrent bitcoin miner framework implemented in Go.

Bitcoin Miner A simple, concurrent bitcoin miner framework implemented in Go. Disclaimer: this is not a product intended to be used for real mining, s

null 4 May 30, 2022
Bitcoin address balance checker on steroids.

BTCSteroids Bitcoin address balance checker on steroids. Table of contents Quick start What's included Use Cases Thanks Copyright and license Quick st

null 9 Oct 27, 2022
Btc-globe - Visualize Bitcoin node locations using golang

btc-globe Visualize Bitcoin nodes by location using Golang

null 0 Jan 19, 2022
Bitcoin UTXO & xPub Management Suite

BUX Bitcoin UTXO & xPub Management Suite Table of Contents About Installation Documentation Examples & Tests Benchmarks Code Standards Usage Contribut

BUX 18 Nov 3, 2022
A proof-of-concept Bitcoin client that treats Bitcoin with the contempt it deserves

Democracy A proof-of-concept Bitcoin client that treats Bitcoin with the contempt it deserves. Bitcoin offers no inbuilt democracy. One can either vot

Josh Deprez 2 Jul 19, 2022
Go implementation of a vanity attempt to generate Bitcoin private keys and subsequently checking whether the corresponding Bitcoin address has a non-zero balance.

vanity-BTC-miner Go implementation of a vanity attempt to generate Bitcoin private keys and subsequently checking whether the corresponding Bitcoin ad

Lih Ingabo 1 Jun 3, 2022