Feed for category: bips
BIP Proposal For New Opcode OP_SECURETHEBAG
OP_SECURETHEBAG is a new proposed opcode that uses a simple covenant to enable a set of valuable use cases like congestion controlled transactions, wallet vaults, CoinJoin and channel factories.
Self Balancing Between Excessively Low/High Fees and Block Size
A new BIP being discussed on the Bitcoin-dev mailing list is aiming at making variable Bitcoin block size depending on the fee the sender is willing to pay, the BIP is aiming at making the block space small, decrease the impact of spam transactions, balancing fees with smaller fees increasing in a higher percentage than higher fees, allow larger block size if the sender is willing to pay for it, allow wallets to display the amount, and price, of free block space left and allow senders to have more control on their fee/priority structure.
[BIP Proposal] Peer to Peer Message Transport Protocol V2

Peer to Peer messaging is already applied in Bitcoin courtesy of BIP 151, but the current way it is applied is inefficient and insecure, currently messages transported are non-encrypted so message tampering, block delay attacks and BGP hijacks are all valid threats using man in the middle attacks. A new BIP is aiming at adding opportunistic encryption using ChaCha20 as a cipher and Poly1305 as a message authentication code, which has been lately getting adopted in many state of the art protocol encryption schemes such as Wireguad and tinyssh.

The computation power required for encrypting and authenticating a message using these algorithms would be almost as much the current double-SHA256 checksum.

The Great Consensus Cleanup
The great consensus cleanup is a new BIP suggested by developer Matt Corallo to address different issues in the current Bitcoin consensus, the new set of consensus changes aim at reducing complexity of Bitcoin implementations, improving worst-case validation times and fixing vulnerabilities like timewarp.
Signatures of Messages Using Bitcoin Private Keys
The processing of signing messages with Bitcoin private keys with P2PKH addresses is a fairly known one but with the introduction of segwit, with its bech32 and P2SH forms, it is unclear how to distinguish these three addresses, a new BIP was proposed by developer Christopher Gilliard intending to set a standard for messages to be signed and verified by different clients.
Simple Proof of Reserves Transactions

Proof-of-reserve transactions are transactions provided by a certain custodian to prove ownership for an amount of funds. For example, lets say an Exchange currently holds 30 thousand Bitcoins on behalf of its users, if anything happens to the exchange, say a hack, the exchange might need to prove to its customers that their Bitcoin is in safe hands, currently any company that wants to perform a proof-of-reserve must do it in its own way and accordingly, their users have to understand the construction to be able to verify it, this makes the process not very common among custodian companies as it’s both tiresome and would require educating their users on technical terms.

A new BIP was proposed as a way to formalize a standard format for constructing these proofs, making it easier for custodians and users with existing wallet infrastructures to understand these proofs. Proofs are formatted as a regular Bitcoin transaction with small differences. This transaction must be unspendable as its sole purpose is to demonstrate the availability of the funds, not spending them. The proof must be linked to the issuer, preventing custodians from just copying other custodians’ proofs.

BIP 322: Generic Signed Message Format

Message signing and verification is one of the quirks included in Bitcoin clients, although it isn’t used as much, this quirk can help you in different situations like proving the ownership of an address, proving a payment to a real world vendor or like a simple proof of an anonymous identity and avoiding fraud.

Currently this only works with P2PKH addresses (legacy addresses starting with a 1), leaving out a standard way to do it with P2SH or any different type of segwit addresses. Note that there exist some non-standard implementations with limited functionnality.

Bustapay: a practical sender/receiver coinjoin protocol

One of the main features intended for Bitcoin in the future is a native support for multisig payments and coinjoins, they are currently supported by the Blockchain but not in a native way and as such they do not have as much efficiency and privacy as desired. This is going to be the main focus of the next major update in Bitcoin, changing the signature scheme to Schnorr Signatures.

As a simplified alternative to Pay-to-Endpoint (P2EP - Pay-to-Endpoint), developer Ryan Havar proposed a BIP for a new coinjoins protocol that does not need changes to the current Bitcoin consensus and provides a simple, practical way to make coinjoin transactions that are indistinguishable from normal ones.

A BIP proposal for 'cancellable' transactions

Alejandro Ranchal Pedrosa and Tucci-Piergiovanni proposed a new BIP to extend OP_CSV1 and/or OP_CLTV2 to allow and interpret negative values.

The discussion that followed concluded that the BIP would be breaking a fundamental rule which is that valid transactions remain valid. This could lead to loss of funds when several transactions are made invalid.