Feed for category: bips
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.

Bitcoin Encrypted Communication (BIP151) Overhaul

On of the pros of Bitcoin since its birth is that it’s a public ledger, anyone is allowed to send and receive payments and data on the Blockchain. However, Bitcoin’s network does not provide a way of encrypting communication between nodes, which allows manipulation of data, mass surveillance and analysis of its users.

Although encrypted communication is currently a possibility with VPNs, TOR or other mechanisms, it is not easy for the average user to setup such a connection. There is BIP draft called BIP151 that aims to add encrypted communication to Bitcoin’s network and which currently seems implemented only by Armory.

Jonas Schnelli presented an overhauled version for BIP 151 with some major changes:

Extending BIP 174 for HTLCs

We’ve talked about BIP 174 before, this time we’re bringing a quick update and that is HTLC support.

HTLC stands for Hashed TimeLock Contracts, they are a type of payments that uses hashes and time locks to require the receiver to generate a cryptographic proof (preimage) that they did receive the payment, otherwise the payment is forfeited and sent back to the sender.

Alex Bosworth proposed adding HTLC support to PSBTs by adding an extra input.

Building a Bitcoin API and Query System

Currently, in order to get information on a Bitcoin block or transaction, one has to sync his node with other nodes in a P2P network to be able to query the block for the information required.

Sumit Lahiri presented a BIP proposal to build an API that enables users to “easily query Bitcoin blocks and transactions” without having to sync with other nodes on the network.

One of the issues with the proposal is that light clients like Electrum, Spruned and Bitcore offer most if not all of the functionalities because the “servers are designed to quickly answer the query of light client wallets”.

BIP Draft Sighash2

A new SIGHASH scheme is currently being discussed, called SIGHASH2, it is said to have more flexibility without introducing much complexity and it solves a few minor issues with BIP143.

Some of the new hashtype definitions are signing fees to make sure they are correct without signing some inputs, decoupling INPUT and SEQUENCE to have a NOINPUT option with a relative lock-time, signing INPUTINDEX, putting NOVERSION, for enforcing BIP68, and NOSCRIPTCODE, in case the public key is being reused, in the second byte some reserved bits for the future and lastly sigversion to avoid any conflict between past SIGHASH schemes and any future ones.