segregated witness – createPaymentTransactionNew with Bech32 address

How to properly call createPaymentTransactionNew using @ledgerhq/hw-app-bt to spend utxos from a bech32 transaction?

This is the code I’m using to call it, having previously defined inputs and purpose, coinPath, accountNumber:

tx = await appBtc.createPaymentTransactionNew({
                    inputs: inputs,
                    associatedKeysets: `${purpose}'/${coinPath}'/${accountNumber}'/0/0`,
                    outputScriptHex: outputScriptHex,
                    segwit:true,
                    additionals: ("bech32")
                });

segregated witness – Can you break down what data is encoded into a bech32 address?

bech32 addresses are defined in BIP 173. A list of address prefixes on the Bitcoin wiki is here.

This slide is taken from Pieter Wuille’s presentation on bech32 at SF Bitcoin Devs in March 2017.

bech32 structure slide

  • bc is representing Bitcoin (mainnet) and is human readable.

  • Testnet bech32 addresses start tb

  • Signet (both default Signet and custom Signets) bech32 addresses also start tb (although an earlier iteration of Signet used sb).

  • Regtest bech32 addresses start with bcrt. This is defined in chainparams.cpp here.

  • 1 is just a separator and doesn’t represent any particular data

  • q is the witness version. This represents zero as the first SegWit witness version introduced was SegWit v0. Taproot introduces SegWit v1.

  • w508d6qejxtdg4y5r3zarvary0c5xw7k is the hash of the witness program.

  • v8f3t4 is the checksum

As the slide says, mainnet P2WPKH addresses are 42 characters and mainnet P2WSH addressses are 62 characters under SegWit v0. Future witness versions can be up to 74 characters although SegWit v1 addresses (Taproot) will be the same length as v0 P2WSH addresses (62 characters). Witness programs as defined under SegWit v1 are 32 bytes.

There is a bech32 demo decoder site here.

segregated witness – Why did bech32 define a new base32 encoding scheme rather than use an existing one?

There are multiple aspects to the design of bech32. There is the choice of character set (i.e. which characters are included in the 32 options and which characters are excluded because they visually look like other characters e.g. 1 because it looks like l), the mapping of specific bits to this character set, the type of checksum to use and the final address structure.

BIP 173 explains the choice of character set.

The character set is chosen to minimize ambiguity according to this visual similarity data, and the ordering is chosen to minimize the number of pairs of similar characters (according to the same data) that differ in more than 1 bit. As the checksum is chosen to maximize detection capabilities for low numbers of bit errors, this choice improves its performance under some error models.

The mapping of bits to bech32 characters is also included in the BIP.

e.g. 11 maps to t (3 on x axis and +8 on y axis) and 30 maps to 7 (6 on x axis and +24 on y axis)

bech32 mapping

Note that although 1 is included in bech32 addresses as a separator (see here) the character 1 is not included in the permitted character set of bech32. Nothing maps to 1 in this mapping.

Pieter Wuille explained the rationale for this bit to character mapping at SF Bitcoin Devs in March 2017:

The reason for this is we were able to select our code to optimize for low bit error rates. Wouldn’t it be great if we could choose the character set in such a way that 1 bit errors are more likely than non 1 bit errors. This character set is the result of another year of CPU time to optimize for this. We found a bunch of information on tables for similarity between various characters. What you can see on this slide, the z and the 2 are considered similar in some fonts or writing. As you can see they are 8 apart. One is 2 and the other is 10 so they are 1 bit apart. And r and t are 1 bit apart. And y and v are 1 bit apart. And x and k are 1 bit apart. And e and a are 1 bit apart. And s and 5 are 1 bit apart. And 4 and h are 1 bit apart. There are way more similar errors overlaid in this data that you can look for. It’s pretty cool. We made a character set that optimizes for 1 bit errors. As a result our code is distance 6 for 1 bit errors. If you just look at these 1 bit errors we guarantee 5 errors. If you only make errors like this you can detect 5.

segregated witness – What is the difference between “native segwit” and “bech32”?

TL;DR: Native segwit refers to segwit-v0 output types without P2SH-wrapper, Bech32 is the address format used to represent their locking script.

When segwit activated, it introduced the zeroth generation of segwit, segwit-v0. The corresponding locking scripts came in multiple flavors:

  1. The forward-compatible “wrapped segwit” or “nested segwit” packages the witness program inside of a Pay to Script Hash (P2SH) output type. The single-sig variant is P2SH-P2WPKH, while P2SH-P2WSH allows arbitrary scripts and thus is used for multisig.
    Wrapped segwit outputs get encoded using Base58Check as other P2SH addresses do. This allowed any P2SH-enabled wallets to send to wrapped segwit addresses.
  2. The compatibility-breaking “native segwit” which can only be paid to by segwit-enabled wallets. Native segwit outputs are more blockspace efficient because they avoid the P2SH-wrapper by resolving the witness program directly. Native segwit locking scripts get represented using the newly introduced bech32 address format (BIP-173).

Bech32 is also used for other purposes such as e.g. encoding Lightning invoices. Originally, it was planned to use bech32 for later segwit output versions as well. However, after a mutability was discovered, and surveys found that many wallets did not properly handle sending to higher segwit versions, an amended version of bech32 is in discussion. This amended version of bech32 would use a different checksum constant to explicitly break forward-compatibility. Breaking forward-compatibility protects against wallets which burn the funds by incorrectly downgrading segwit-v1 addresses to segwit-v0 addresses, and allows the mutability to be fixed.

The proposed Taproot softfork introduces the segwit-v1 output type called Pay to Taproot (P2TR) which would be the first output type to use the amended bech32 address format, possibly called “bech32m”.

What is needed to generate a bech32 address?

So I wrote a vanity address generator in c# with the NBitcoin lib. When I use the private key used to generate the address and input it in Mycelium it outputs a different address. This does not occur when working with legacy addresses, so I’m guessing I need something more than just a private key in order to generate a segwit address. Was it a redeem script or something? How can I make sure I get the same address in a wallet when I input the privkey?

bitcoin core – Version prefix used for Bech32 addresses

Those bytes (x03x03x00x02x03 or better shown as 0x0303000203) are the expanded human readable part. You can find the code on BIP-173.

def bech32_hrp_expand(s):
  return (ord(x) >> 5 for x in s) + (0) + (ord(x) & 31 for x in s)

The problem however is that unlike Base58 encoding, those bytes are only used in calculation of checksum not as the starting bytes. Which makes the picture misleading in my opinion.

Bech32 encoding is very different from Base58 encoding as there is no “version prefix”. There is an Hrp, a witness version, a data (hash) and a checksum. Witness version | hash are the data being encoded and expanded_hrp | data is used in checksum calculation (| is concatination).

buy bitcoins – BTC received in BECH32 (P2WPKH) format address not exist in Electrum

I sent some BTC to a BECH32 (P2WPKH) format address. (details of the transaction)

I imported the private key(wif) in Electrum, but I can’t find the income?

I am sure I sent to the right address and imported the right wif. How can I get the incomes?

Thanks a lot!

address – How Many Clients Could Not Send to Bech32 Addresses?

For my client, I have set up a custom BTC payment solution using BTCPay Server. The wallets I have configured in BTCPay Server produce only bech32 (bc1xxx) addresses for payments (cheapest transaction fees).

My client (who ordered the solution) has asked me how many of his customers would be unable to send a payment to a bech32 address?

His concern is that his clients will be unable to pay their invoices in BTC because their wallets will be unable to send payments to the bech32 addresses.

As I can see it, I can go back to my client with one of the following two answers:

  1. Nearly all (??%) of wallets can send to bech32 including allmost commercial wallet providers so you don’t need to worry, or
  2. This is a problem and instead of bech32 addresses I need to set up a payment wallet that supports legacy addresses (either 1xxx or 3xxx).

Could someone please tell me whether I can reassure him that the solution is fine as is, or whether I need to add legacy address support into it?

bitcoin core – Speed of decoding Bech32 addresses

I am trying to understand if Bech32 can be a bottleneck in some specific cases (only Bech32, not Bitcoin itself).
What is the hypothetical speed decoding the address back to the streamable format in the client?
How many transactions per second you can do in Bech32 when you have not in scope the Bitcoin client itself?

I found out that vanity Bech32 can be tested with this tool: https://github.com/lispczz/bech32-vanity-address-generator

Any advice, how I can do the raw estimation? Do you have some formula in mind?

Generate p2sh-segwit and bech32 address

When i use bitcoin-cli getnewaddress "" "p2sh-segwit" What kind of script is inside? Can I convert it to bech32?