is it possible to send transactions back and forth between all 3 address types (legacy, segwit, native segwit-bech32)?
Or is one of them not able to send to another?
Bitcoin Stack Exchange is a question and answer site for Bitcoin crypto-currency enthusiasts. It only takes a minute to sign up.Sign up to join this community
Each address type handles transaction generation slightly differently but they all are interoperable with each other on the protocol level. If you run into an issue where one address type will not send to another, this is not a limitation of the bitcoin code, rather the client.
Still, you may hear something like:
"Legacy addresses are not SegWit compatible"
This simply means a legacy address cannot send a SegWit transaction. When it comes to receiving, everything is interoperable. The type of transaction and whether or not the receiving address can fully utilize all transaction benefits depends on the sending address.
Bitcoin's original address format—Pay-to-Pubkey Hash (P2PKH)—builds a transaction using a hash of the recipient's public key. If an address starts with
1, it's legacy. It is still in common use due to the simplicity and universal integration, and while P2PKH can send to a SegWit address, the fee is a little higher because legacy transactions are slightly larger.
These addresses begin with a
3 and are designed to pay to script hash adding basic scripting functionality to addresses. The transaction has extra logic that—in the case of multi-sig—states that multiple signatures are required to authorize the transaction. As long as all required signatures are in place, any address can receive a transaction from this address.
If you've heard the term "non-native SegWit", or wondered why SegWit is called "native SegWit" that is because of this address. Even though the sending address is not SegWit, a P2SH transaction is created which contains a "Pay-to-Witness-Pubkey Hash" inside of it. This mimics SegWit formatting, allowing a native SegWit address to interpret it, well... natively.
Bech32 is the native SegWit address format and is more efficient with block space. A Bech32 address can be identified by it's
bc1 prefix. SegWit is a transaction format that splits (Segregates) a transaction into two pieces: one containing the standard transaction ID data (to, from, amount, signatures, etc.), and a scripted piece of that data (Witness) that is 75% smaller on-chain among other benefits. Since the witness contains, among other things, a "minified version" of legacy data it allows a SegWit transaction to be sent to a legacy address (without cost benefit), or to a SegWit address (as a cheaper transaction relying on the witness only).
A legacy address however doesn't know how to generate the witness data, so it cannot include it in a SegWit transaction and reap the benefits. That's okay though, because a SegWit address doesn't need the witness data, so a legacy address will have no problem sending tokens to a SegWit address.
No matter what wallet you use, any UTXO may have come from any address type. For any coin in an address, the UTXO it arrived in either contains the legacy data, the witness data, or both, depending on what type of transaction was used to send the coins.
If you're using a Bech32 address to send a SegWit transaction, its full benefits are realized when a UTXO was sent to you as a SegWit transaction, but will always send regardless.
These are transactions where UTXOs that may have come from different address types are placed into a single transaction. It's also an illustration of what happens when coins are sent to different address types through their lifecycle. Example:
The result is a SegWit transaction, although it does not fully benefit from the privacy or transaction cost reduction had all UTXOs been SegWit. If it was sent to a legacy address, any further movement of the coins will be legacy transactions, until it reaches a Bech32 address which sends it as a SegWit transaction, at which point it becomes again a SegWit transaction.
NOTE: Some older wallet clients, or ones without SegWit support may not recognize newer versions of addresses as valid, and won't let you send to them: this is a precautionary measure (in the wallet code, not bitcoin code) to prevent users from sending to a non-bitcoin address.
Update (Nov 2021)
The recent Taproot upgrade added additional transaction changes by enabling Schnorr signing in addition to the traditional Elliptic Curve Digital Signature Algorithm (ECDSA). When bitcoin was originally released, the Schnorr algorithm was under patent protection. There are many benefits that come with using Schnorr, most importantly the ability to aggregate signing keys. While a P2SH multi-sig includes each parties public key and signature, Schnorr enables the keys to be aggregated, providing privacy and easier computation for nodes.
Since the aggregate key is still used to create a signed UTXO with the necessary inputs and outputs, even a new algorithm is compatible with all existing bitcoin clients!
There are no restrictions on sending from any type of outputs to any address type in the Bitcoin protocol, but some older wallets might not support sending to newer address types.
Let's take a better look at what happens for a Bitcoin transaction coming to pass:
In any case, issues with sending to any specific address type are caused by missing functionality in the sender's wallet and in no way related to the input types used.
At a protocol level, they are all compatible. Transactions can spend any of them, and send to any of them.
Wallet software may of course have restrictions, but these are usually not about combinations. E.g. some wallets may be unable to generate a p2sh-segwit address to receive on, or be unable to send to bech32. However, I have not heard about software that puts restrictions on where it can send to based on what is being spent, for example.
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" bitcoin (UTXO) could go is actually a missing feature of bitcoin, called "covenants". Currently people could only use tricks like presigned time-locked transactions to achieve similar goals. In the future maybe this could be done in a more intuitive and powerful way.
However, an old wallet (or a cryptocurrency exchange with lazy/conservative technical team) may not be able to recognise native bech32 addresses, so that you won't be able to send bitcoins from such an old wallet (or withdraw from such a lazy cryptocurrency exchange) to a native bech32 SegWit address - that's the only significant downside.
Miner fee: (Most expensive) 1-starting legacy address > 3-starting p2sh-segwit > bc1-starting bech32 (cheapest)
Compatibility: (Most compatible) 1-starting legacy address ≈ 3-starting p2sh-segwit (almostly as compatible as legacy) > bc1-starting bech32 (potential compatibility/interoperability issue)
Also, obviously you can't generate any SegWit address with an old wallet without any SegWit support, so that you can't receive bitcoins with any SegWit address using such a wallet - the solution to this problem is simple: just upgrade the wallet to SegWit-supporting version, or switch to another wallet with proper SegWit support.
If someone who is too stubborn to upgrade/switch his/her wallet, it doesn't matter, because (1) you can still give him/her a 3-starting SegWit address; (2) you can totally send transactions back and forth between all 3 address types using a wallet with proper SegWit support.
(A transaction sending bitcoins all from) 1-starting P2PKH legacy addresses doesn't enjoy discounts of SegWit, so that it has the most expensive miner fees among those three address types. Its virtual byte count is exactly the same with actual/on-wire byte count.
(A transaction sending bitcoins from) bc1-starting native Bech32 SegWit address has the least data size (byte count), either virtual (vByte) or actual/on-wire, so that it enjoys the cheapest miner fees.
In fact SegWit (v0) doesn't reduce transaction data size so much, its cheap miner fee is mainly an artificial discount. However SegWit transactions indeedly has technical advantage over legacy ones, like, avoiding the quadratic sighash problem.
(A transaction sending bitcoins from) 3-starting P2SH-wrapped "compatible" SegWit address actually consumes more bytes than a legacy 1-starting address (mainly because P2SH "script hash" itself consumes 20 bytes), however, it still has cheaper miner fee than 1-starting legacy address due to discounts.
A 3-starting address is P2SH, which was brought by Gavin Andresen at very early stage of the history of bitcoin (2012), so that it's now highly improbable to see a wallet which can't recognise 3-starting P2SH addresses.
SegWit utilize P2SH to "wrap" its special "anyone-can-spend" script.
P2SH can actually "wrap" anything. Its typical usage has been multi-sig for quite a long time, much earlier than SegWit.
When an old wallet sends bitcoins to a 3-starting address, it (the payer) doesn't care about what kind of stuff is "wrapped inside" that address at all. It can be either a legacy multi-sig, SegWit, or something other - whatever, it doesn't matter.
(It could even be a totally unspendable address!)
It's then the responsibility of the payee to ensure that (s)he can still spend the bitcoins on that 3-starting address.
Then what's "anyone-can-spend"?
Old versions (pre-0.13) of bitcoin full nodes don't know about SegWit at all of course, so that they obviously cannot validate SegWit transactions (or blocks containing SegWit transactions) according to the newly defined SegWit rules.
However they would still accept SegWit blocks as if those blocks were valid, despite they cannot fully validate them - the forward compatibility (usually called "backwards compatibility" by a lot of developers) is still retained, in the sense that old nodes which are not SegWit-aware can still work as normal.
As for SegWit transactions, those old nodes won't accept/forward/mine any SegWit transactions (except sending to a 3-starting P2SH-wrapped SegWit address). They would accept confirmed SegWit transactions only, in other words, SegWit blocks only. Therefore, if you want to break SegWit rules, you must at least become a (solo) miner yourself, an almostly cost-free attempt like sending invalid "robbing" transaction from some SegWit addresses won't work at all. (Here comes the minor downside of SegWit that old non-SegWit-aware full nodes can't see 0-confirmation SegWit transactions)
SegWit was carefully designed to achieve this. It's actually quite similar to what P2SH had done.
There's a concept called "standardness rules" in bitcoin, that such rules are just self-discipline, so that they only restrict the behavoir of a full node itself. "Standardness rules" don't apply to the blockchain, which contains blocks mined by various types of other nodes.
Only "validity rules" or "consensus rules" apply to the blockchain.
SegWit address actually means "anyone can spend bitcoins on this address" according to old validity rules, so that old nodes would still accept SegWit blocks. (Therefore, there's indeedly a theoretical, unavoidable risk that a chain split could happen, if some malicious miners would insist on mining/extending an invalid blockchain "robbing" SegWit addresses - however it would be still clearly distinguishable between the valid chain and the invalid chain. SegWit-aware new nodes would only accept the valid chain) It violates the old standardness rules, so that old nodes won't mine any SegWit transactions into their own blocks.
According to new validity rules, spending bitcoins from SegWit address (typically) must provide valid signatures, without all-valid signatures it would be an invalid transaction, so that new nodes would reject either such an invalid transaction, or a (thus invalid) block including any invalid transaction. New nodes won't mine any invalid transaction into their own blocks either, of course. However, according to the new standardness rules, (valid) SegWit transactions is also standard (not violating the new standardness rules), so that new nodes would happily mine valid SegWit transactions into their own blocks.