BIPs bitcoin improvement proposals

178 - Version Extended WIF

<pre> BIP: 178 Layer: Applications Title: Version Extended WIF Author: Karl-Johan Alm <karljohan-alm@garage.co.jp> Comments-Summary: Discouraged for implementation (one person) Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0178 Status: Draft Type: Standards Track Created: 2018-04-04 License: CC0-1.0 </pre> == Abstract == An extension to the Wallet Import Format (WIF) to specify what kind of bitcoin address the private key corresponds to. == Motivation == There are several types of bitcoin addresses which can all be associated with a given private key: P2PKH (legacy <code>1...</code> format), P2SH-P2WPKH (SegWit public key inside P2SH), P2WPKH (bech32), etc. While private keys have a 1-byte suffix indicating whether the corresponding public key is compressed (<code>0x01</code>) or not (through suffix absence), there is no way of knowing what kind of bitcoin address were associated with the private key. As a result, when importing a private key,...

322 - Generic Signed Message Format

<pre> BIP: 322 Layer: Applications Title: Generic Signed Message Format Author: Karl-Johan Alm <karljohan-alm@garage.co.jp> Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0322 Status: Draft Type: Standards Track Created: 2018-09-10 License: CC0-1.0 </pre> == Abstract == A standard for interoperable signed messages based on the Bitcoin Script format, either for proving fund availability, or committing to a message as the intended recipient of funds sent to the invoice address. == Motivation == The current message signing standard only works for P2PKH (1...) invoice addresses. We propose to extend and generalize the standard by using a Bitcoin Script based approach. This ensures that any coins, no matter what script they are controlled by, can in-principle be signed for. For easy interoperability with existing signing hardware, we also define a signature message format which resembles a Bitcoin transaction (excep...

154 - Rate Limiting via peer specified challenges

<pre> BIP: 154 Layer: Peer Services Title: Rate Limiting via peer specified challenges 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: Withdrawn Type: Standards Track Created: 2017-04-12 License: BSD-2-Clause </pre> ==Abstract== An anti-DoS system which provides additional service for peers which perform proof of work. ==Definitions== * '''POW''' : a proof of work using some arbitrary algorithm, such as SHA256 * '''challenge''' : a problem in the form of a POW specification and other data * '''solution''' : a set of inputs which solve a given challenge * '''free connection slot''' : an inbound connection slot that does not require POW * '''POW connection slot''' : an inbound connection slot that requires POW * '''SPH''' : Special Purpose Hardware, such as an ASIC chip * '''GPH''' : General Purpose Hardware, such as a desktop computer * '''Work''' :...

325 - Signet

<pre> BIP: 325 Layer: Applications Title: Signet Author: Karl-Johan Alm <karljohan-alm@garage.co.jp> Anthony Towns <aj@erisian.com.au> Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0325 Status: Proposed 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...