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.
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.
Multisig transactions 1 have been a great use case of Bitcoin for the past few years, they require unsigned or partially signed transactions to be passed between multiple parties to “co-sign” them. However, there is currently no unified format for how multiple parties may share these transactions between multiple signers, it depends on the particular implementation for each wallet making it hard to do among parties using different Bitcoin wallets.
A draft BIP (174), which was proposed last year by Andrew Chow, was recently a subject of interest among Bitcoin developers. It aims to create a standard extensible format that different clients can implement making Partially Signed Bitcoin Transactions (PSBT) easier to pass around users to sign and combine their signatures.
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.
Decentralizing mining doesn’t always take the form of an algorithm change.
We propose two new mining protocols to rethink the way in which work is generated in the Bitcoin network, potentially drastically increasing effective mining decentralization.
Matt Corallo via Bitcoin-dev:
BIP 158 currently includes the following in the “basic” filter: 1) txids, 2) output scripts, 3) input prevouts.
I believe (1) could be skipped entirely - there is almost no reason why you’d not be able to filter for, eg, the set of output scripts in a transaction you know about and (2) and (3) may want to be split out - many wallets may wish to just find transactions paying to them, as transactions spending from their outputs should generally be things they’ve created.
BIP 158 is a protocol that extends BIP 157. It is a structure of “compact filters on block data” that replaces bloom filters. The purpose of such a system is to enable users who run light Bitcoin clients to verify transactions dealing specifically with their wallets. The issues at hand are juggling efficiency with security (ie. verifying honest nodes and detecting dishonest nodes).
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.
Jim Posen proposed the following BIP (Bitcoin Improvement Protocol) via Bitcoin developer mail:
I have been working on a P2P extension that will allow faster header sync mechanisms. The one-sentence summary is that by encoding headers more efficiently (eg. omitting prev_hash) and downloading evenly spaced checkpoints throughout history (say every 1,000th) from all peers first, we could speed up header sync, which would be a huge improvement for light clients.
According to Posen, the “proposed header download protocol reduces bandwidth usage by [approximately] 40%-50% and supports downloading… from multiple peers in parallel”. Currently parallel header synchronization is not supported. Such an improvement could be advantageous during periods of high technical adoption, which could occur as increasingly stable versions of Lighting Network daemons are released.