13

Background P2TR addresses will be encoded using Bech32, although likely an amended version. In anticipation of Taproot getting merged, some proponents tested the behavior of various wallets and services regarding segwit v1 outputs. BIP173 prescribes that known restrictions should be enforced for Bech32 addresses, but that "implementations MUST allow the ...


11

TL;DR: Native segwit refers to segwit outputs without P2SH-wrapper. Bech32 is the address format used to represent native segwit-v0 locking scripts. Wrapped segwit vs native segwit When segwit activated, it introduced the zeroth generation of segwit, segwit-v0. The corresponding locking scripts came in two flavors: The forward-compatible "wrapped ...


9

Segwit addresses like the one you posted are case insensitive. Assuming your wallet is up to the spec, it should be able to send the BTC just fine. If you have a transaction ID, look it up on an explorer to see if it has been confirmed. If you don't have a transaction ID, and you have the private keys for the wallet, you should simply be able to make another ...


6

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. bc is representing Bitcoin (mainnet) and is human readable. Testnet bech32 addresses start tb Signet (both default Signet and custom Signets) bech32 addresses ...


5

Adopting any deposit change at all is not as simple as "just change regex". There are a few considerations: Addresses must be generated, and generated properly. All generated addresses that are passed to the frontend must be valid otherwise you have now black-holed future user deposits. Can your signing process sign for those new address types? ...


4

Because P2SH addresses are too short to provide typically desirable levels of security security level we expect from Bitcoin, against certain attacks. On top of that, they use bech32 encoding rather than base58, which means they're slightly longer for the same amount of data, but are case insensitive instead. For any kind of "multi party" address (...


3

is it possible to send transactions back and forth between all 3 address types (legacy, segwit, native segwit-bech32)? Yes, of course. It's totally normal at protocol level. Just like what Murch had said: There are no restrictions on sending from any type of outputs to any address type in the Bitcoin protocol The ability to limit where the "unlocked&...


3

Yes. The format used for encoding native version 0 SegWit scriptPubKeys (P2WPKH and P2WSH) is bech32, defined by bip-0173. Unfortunately, at the time of writing, a weakness has been discovered regarding the usage of this encoding for the proposed version 1 SegWit scriptPubKeys (Taproot). There are ongoing discussions for how to modify this encoding for ...


3

If you look closely, you'll notice that BIP 32 and BIP 44 actually have the same root key and it begins with xprv. Then BIP 49 and BIP 141 also have the same root key and it begins with yprv. BIP 84 has a root key that's different from the others that begins with zprv. Now if you were to take all of those root keys and Base 58 decode them, you'll find that ...


2

You differentiate a Taproot scriptPubKey and a P2WSH scriptPubKey by their witness version. 1 for Taproot, 0 for P2WSH. A "P2WSH with version 1" doesn't exist, it would just be treated as a Taproot scriptPubKey by upgraded nodes and as an anyone-can-spend by legacy ones. P2WSH: <0> <32-bytes push> Taproot: <1> <32-bytes push>...


2

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 ...


2

As far as I can tell "length extension mutation weakness" is the sole problem that needed to be resolved and is resolved by bech32m. But "length extension mutation weakness" includes both insertion and deletion. Insertion: if a valid Bech32 string has the suffix p, inserting a single q character immediately before the p will produce ...


2

The encoding is bech32 not base58, which is slightly longer but vastly easier to type due to a lack of capital letters, and the inclusion of error correction rather than error detection. SegWit scripts use SHA256 not RIPEMD160 for the hash function, which is longer and stronger.


2

I assume that you're referring to withdrawals, and I think that you're probably right if the company's backend relies on bitcoind to fully process transactions. If the company's backend manually builds transactions, then that code needs to be updated. Even if you use a stateless bitcoind's RPC interface to build and sign transactions, you still need to ...


1

It is not as simple as checking the address format. Different address formats represent different output types. An address that starts with a "1" is a legacy pay-to-public-key-hash output. When writing wallet software signing transactions for this type of output requires a different order of operations to spend than let's say a pay-to-script-hash ...


1

BIP173 specifies the conversion from Bech32 segwit addresses to scriptPubKey. You probably want to use some reference software to do the decoding (there are several links in the BIP). If you need the details, it is approximately: Split the address in a "human readable part" and a "data part"; the last '1' character in the address ...


1

Is it possible to remove unnecessary addresses? Many wallets can show you a list of all the receiving addresses they have generated. Some wallets do allow you to view a list of only those addresses with a non-zero balance. Wallet developers probably don't want to allow deletion of addresses because of the customer support issues that would be raised if ...


1

var bitcoinPrivateKey = new BitcoinSecret("cPof7e5g6xfgB6AZrc6XVTVwA4efLJurh9kVxa6FRChbr8Jyqaon", Network.TestNet); var legacy_address = bitcoinPrivateKey.GetAddress(ScriptPubKeyType.Legacy); var segwitp2sh_address = bitcoinPrivateKey.GetAddress(ScriptPubKeyType.SegwitP2SH); var nativesegwit_address = ...


1

Can a single wallet generate (and use) both SegWit and non-SegWit addresses? Yes. Example: In Bitcoin Core you can can run getnewaddress with address_type in the argument I intend to migrate their wallets to native Segwit, but they will also need legacy addresses so that they can receive coins from anywhere. Most of the apps, websites, services etc. now ...


1

I am not familiar with the wallets generated by BitPay's Bitcore specifically, but there is no general issue preventing a wallet from generating addresses of various output formats. If BitPay's wallets can only either do one or the other that would be a local implementation quirk. While it is possible to maintain separate wallets for each user, it is rather ...


1

As an answer didn't appear to be forthcoming, I did my own research in order to address this question. Based on the information provided by the Bitcoin Wiki on Bech32 adoption, I surmised the following information. All mainstream software wallets support sending to Bech32. All mainstream hardware wallets support sending to Bech32 (either directly or via ...


Only top voted, non community-wiki answers of a minimum length are eligible