Feed for tag: bech32
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.
Summary for December 2018
We’ve been taking a break for the past two months while working on a website upgrade. Since we did not cover news in that time, we decided to make a series of recap articles covering the last two months, starting with news related Bitcoin Core and going through Lightning Network and its related updates.
Bip 39 Seeds Using Random Words
There was a discussion on BIP39 seeds and the probability of getting a valid BIP39 using randomly chosen words, otherwise known as brute forcing. The probability is about 1:256 for 24 words and 1:16 for 12 words. This is meant to change drastically with SLIP 39, proposed last year, SLIP 39 describes a standard implementation of Shamir’s secret-sharing, which splits a secret into unique parts which can be distributed among participants.
URI scheme with optional bech32 address

Bitcoin’s URI scheme is a way to encode addresses, amount of Bitcoin to send, label and message, it is used to make handling wallets easier for the user as all you need to know is a URI that you’ll input into a wallet and just hit the send button!

A new suggestion came to light on the Bitcoin-dev mailing list about optional bech32 address support in the Bitcoin URI scheme, bech32 is a segwit address format that starts with “bc” and was recently supported by Bitcoin’s network, the suggestion is still early but may lead to a single URI scheme that works both on legacy and segwit wallets. We’ll keep an eye on it!

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.

Bech32 and P2SH^2

Luke Dashjr opened a discussion regarding why Bech32 was omitted from previous P2SH2 improvements.

For those unfamiliar with the concept, the idea is to have the address include the single SHA256 hash of the public key or script, rather than RIPEMD160(SHA256(pubkey)) or SHA256(SHA256(script)). The sender would then perform the second hash to produce the output. Doing this would in the future enable relaying the “middle-hash” as a way to prove the final hash is in fact a hash itself, thereby proving it is not embedded data spam.

Bech32 seems like a huge missed opportunity to add this, since everyone will probably be upgrading to it at some point.