We’re rewarding the question askers & reputations are being recalculated! Read more.
20

I'm sorry to be the bearer of bad news: It looks like your funds are gone and the security of your computer is compromised. A quick google suggests that is one of the electrum phishing destination addresses. You can find more information on the attacks against electrum here: http://electrum-malware.surge.sh/


14

They will be distinguishable, but they will still be bech32 addresses. The introduction of Schnorr signatures requires a new type of output. Segwit was designed with such extensibility in mind, and it defines 17 version numbers. Currently, only version 0 is used. Segwit v0 outputs with a 20-byte hash are known as P2WPKH outputs, and v0 outputs with a 32-...


9

bech32 produces smaller transactions than P2SH segwit transactions. one extra byte per output to create P2SH outputs than to create bech32 utxos (P2SH uses OP_HASH160 and OP_EQUAL in addition to a 20 byte hash in its script, whereas bech32 just uses a fixed 00 byte in addition to a 20 byte hash), and 23 extra bytes per input to spend from P2SH utxos than ...


9

Is it safe to receive funds at this 1FJJd... address? Kind of. Your wallet knows the private key that corresponds to that address as it is the same private key for the bech32 address. However it does not necessarily know that it should be looking for coins sent to this address, so any transactions that send coins to that address may not appear in your ...


8

Transfer from Legacy ⟶ SegWit: pay full fee (doesn't benefit from SegWit discount) Transfer from SegWit ⟶ Legacy or SegWit: discounted. Note: SegWit addresses can be Bech32 bc1... or they can be nested in a legacy P2SH 3... address which are backwards-compatible (although less efficient). Many exchanges, wallets support the legacy "nested" form only.


8

Is it acceptable to mix P2PKH and P2WPKH inputs in the same transaction as described above? Yes, absolutely. In the same way that you can mix multisig and P2SH and P2PK inputs in the same transaction. When would I encounter a situation where "all txins in a transaction are not associated with any witness data" When you're not spending any SegWit outputs....


8

Blockchair announced support for Bech32 addresses last month. This page about Bech32 adoption on bitcoin.it wiki page is tracking blockexplorers that support Bech32 addresses.


8

Is there a way to get to the hash160 address from bc1q34aq5drpuwy3wgl9lhup9892qp6svr8ldzyy7c Yes, you could use the reference implementations in various languages to encode and decode a bech32 address. For example, I have decoded the sample address you mentioned in the question, bc1q34aq5drpuwy3wgl9lhup9892qp6svr8ldzyy7c, using python below. The decode ...


7

The difference lies in the encoding and the underlying representation in the transaction data stored on the blockchain. The 3-segwit addresses are known as P2SH-P2WPKH or P2SH-P2WSH. This stands for Pay-to-witness-pubkey-hash wrapped in pay-to-script-hash and pay-to-witness-script-hash wrapped in pay-to-script-hash respectively. This was done to provide ...


7

An algorithm called Public Key Recovery exists for ECDSA, which lets you construct the public keys for which a given pair of message and signature would be valid. To explain the algorithm, remember that ECDSA signatures are pairs (r,s) for which sR = mG + rP. In this equation m is the message hash (which must be a hash of a known message), P is the public ...


7

The HRP is part of the bech32 encoded string, and in the bech32 decoding API, it is returned along with the payload by the decoder, after checking the checksum. We still want to compare it with the expected HRP in BIP173, which encodes the chain the software is operating on. Otherwise you could have a testnet node that accepts mainnet BIP173 addresses or ...


6

how to interprete script handling? What you're missing is that BIP173 is not a way to encode public keys or scripts. It is a way to encode segwit transaction outputs. What those outputs are and mean is currently in BIP141 and BIP143 - but may change over time, without BIP173 changing. All segwit transaction outputs (current and future) have the following ...


6

q is the Bech32 encoding of the number 0. For a segwit address, as defined in BIP 173, the number immediately following the separator is the witness version. In this case, bc1q, the q means it is a witness v0 address, which is the only type currently used but allows for easy future addition of new versions


6

There's no big difference for users between the two. The fee is lower while using native Segwit address (bech32), and the address format differs. Let's look at the motivations of bech32 address authors: Old addresses (base58) need a lot of space in QR codes, as it cannot use the alphanumeric mode. The mixed case in (old addresses) base58 makes it ...


6

All current addresses are cross compatible. At a technical level, the chain has no concept of an address, only of locking scripts, which are fragments of a bitcoin script program. You send coins by specifying the locking script, and spend them by providing the unlocking script (also called the script sig), which completes the program by providing the ...


6

The NATO phonetic alphabet is designed for this purpose and is very widely recognized by a number of people in communication critical industries. The words are clearly recognizable even to the unfamiliar and is intended to not be able to be mistaken. Due to bech32 encoding there’s no need for communication of capital letters as you would need for p2pkh ...


6

I'm going to provide a more algebraic explanation of the issue. Every valid (and invalid) Bech32 string can be seen as a polynomial in the variable x, where the coefficients are elements of GF(32). I'm going to ignore the GF(32) part in what follows, so it suffices to say that they're simply numbers from 0 to 31 inclusive, with weird addition and ...


5

AFAIK there are 5 different standard non-SegWit transaction types, and 4 SegWit ones. Non-SegWit: Pay to public key (P2PK) PUSH (1 byte) + <compressed/uncompressed_pk> (33/65 bytes) + OP_CHECKSIG (1 byte) Pay to public key hash (P2PKH) OP_DUP (1 byte) + OP_HASH160 (1 byte) + PUSH (1 byte) + <hash_160(PK)> (20 bytes) + OP_EQUALVERIFY (1 byte) ...


4

I'm assuming that the "dec.data[0] > 16" check is to make sure that the byte at index zero doesn't exceed a value of 16, which would be invalid hex. Is this correct? No, it's because only versions 0 - 16 are specified. Other versions might behave entirely differently. (As an aside, if it were a comparison for the sake of clamping to the range of a single ...


3

Immediately following the human readable part and separator of a bech32 address is the witness version number. For current bech32 addresses, that version number is 0. According to the encoding table here, the value for a 0 byte is q. Thus addresses will begin with bc1q.


3

I've found this project: https://github.com/oskyk/cashaddress , checked the accounts generated by it using validateaddress of my wallet, seems working fine!


3

Yes, they are. Bech32 addresses allow for native Segwit outputs, which offer higher efficiency and security than the legacy P2SH nested Segwit outputs. https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki#Reference_implementations has reference implementations in C, C++, JS, Go, Python, Haskell, Ruby, and Rust along with tests courteous of Pieter ...


3

You can’t assume that any given software will be know to go searching for arbitrary encodings of the public key you’re “converting” to. Depending on the wallet software on the other end, your payment will likely to be missed or at worst lost entirely in the case of a hardware security module that can’t be altered. There's no situation in which you should ...


3

To generate a P2WSH address, you need to have some script. The most easiest one you can use is a multisig script. You can do this with the addmultisigaddress. If you do something like addmultisigaddress 1 '["37Ju7oTbPfe5qNAHYiAKfdTtVvCSP3TTdL"]' "" "bech32" you should get a P2WSH address.


3

1) Native P2WPKH Unspent outputs save 22 bytes as their ScriptSigs are empty instead of 0x0014{20-byte-key-hash}. So, the amount of saving is insignificant. 2) Yes, there's already a checksum of the same length. The newer checksum algorithm is Faster. Very high probability of detection guaranteed.. Can find where the errors are: http://bitcoin.sipa.be/...


3

Okay so I think I've figured it out for anyone else wondering what exactly you have to do to derive an address from this type. In the case of the already mentioned transaction, (coinbase of block 542748) we first start by looking at the full decoded output script. 0 PUSHDATA(20) 97cfc76442fe717f2a3f0cc9c175f7561b661997 The very first OP_0 in the decoded ...


3

First of all, what are you trying to do? Why do you need a P2WSH address? A P2WSH address (and P2SH addresses earlier) send coins to a script, which requires satisfying that script to decode. A script of the form <key> CHECKSIG is wasteful - you should be using P2WPKH instead. In general, you use P2WSH when you have more complex spending requirements ...


3

P2WPKH - This stands for "Pay To Witness Public Key Hash" and the scriptPubkey is OP_0 0x14 {20-byte-hash}, where OP_0 is the version, byte 0x14 is the size of the data, and the {20-byte-hash} is a HASH160(PubKey). P2WSH - This stands for "Pay To Witness Script Hash" and the scriptPubkey is OP_0 0x20 {32-byte-hash}, where OP_0 is the version, byte 0x20 is ...


3

It sounds like you are using the wrong address type for the network that you are on. Regtest bech32 addresses begin with "bcrt".


3

Pieter Wuille's comment gives a nice summary: basically: take a bech32 string, xor a 1 into the last character, then push or pop as many 'q's as you like, and then xor a 1 into the last character again... should always give you a valid new bech32 string Checksum code taken from Bitcoin Core is: uint32_t PolyMod(const data& v) { uint32_t c = 1; ...


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