Feed for tag: bip
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.

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.

BIP Proposal for 64-byte Elliptic Curve Schnorr Signatures

One of the core components of Bitcoin is the Digital signature algorithms, it is used in making public keys out of private keys, signing transactions and in multisig transactions. Bitcoin so far has been using Elliptic Curve Digital Signature Algorithm ECDSA, for the past few months developers in the Bitcoin community have been talking about changing this algorithm into another one called Schnorr Signatures.

Schnorr is another signing algorithm that bring multiple benefits to the table. A new BIP was recently submitted by Peter Wuille about the changes that should happen in the future to Bitcoin’s signing algorithm with all the bells and whistles it should bring. The security of Schnorr is easily provable given a certain assumption, this is not the case for ECDSA.

BIP Proposal: New Serialization Format for Key Material

Extended private keys are defined in BIP321 and are used to recover funds in case of a loss, but recovering a wallet using just the extended private keys is a tricky process and can sometimes fail to recover all the funds as some metadata can be missing. The current implemenation also has a weakness in which there is a limit to the incoming payment requests, handing out more than 20 incoming payment requests could lead to destruction of funds.

To remedy this issue, an early draft of a new serialization/encoding format for extended public and private keys was proposed on the Bitcoin-dev channel.

Updates to Dandelion Bip Proposal

A programmer and researcher, Brad Denby who’s team formerly proposed a BIP called Dandelion, published an update to the project.

We’re writing with an update on the Dandelion project. As a reminder, Dandelion is a practical, lightweight privacy solution that provides Bitcoin users formal anonymity guarantees. While other privacy solutions aim to protect individual users, Dandelion protects privacy by limiting the capability of adversaries to deanonymize the entire network.