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?
asked Jan 28, 2020 at 21:40
Add a comment
|
4 Answers
Absolutely!
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.
Legacy 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.
P2SH Address
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.
SegWit & Bech32
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.
Fully Benefiting from SegWit
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.
Mixed Script Transactions
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:
- Alice receives 0.5 BTC to her SegWit wallet from Bob's legacy address.
- Alice receives 0.5 BTC from Charlie that were sent using SegWit.
- Alice sends a 1 BTC transaction which uses both legacy and native SegWit transactions to a Bech32 address.
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.
Taproot - 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!
-
1The first paragraph seems to imply that it's not possible to send from some address types to others, but funds from any address type can be sent to any other address type. I'm also confused what "a legacy address doesn't know about […] segwit code" or "the transaction can't support information coming from the legacy address to implement it into any segwit functions" are supposed to mean. It's not possible to chose which format to use to spend a UTXO. The required input script is defined by the address type the funds were previously sent to.– Murch ♦Feb 3, 2020 at 2:54
-
I've added another answer that addresses the question more broadly than Pieter's and revisits some of the points hinted at in this answer.– Murch ♦Feb 3, 2020 at 3:21
-
Updated to clarify, thank you for pointing this out. I mean that older transaction types cannot benefit from later protocols, as they are unaware of the new code. While it's not possible to chose which format you use to spend a UTXO, it is possible to send a transaction with mixed scripts. Dec 17, 2020 at 6:58
-
Thank you for addressing the comment about being able to send between address formats. I would still recommend that the phrasing of "addresses knowing things" would be updated. The segwit-awareness is a feature of wallet software, not of an address. Likewise, "[…] will take advantage of the transaction fee updates" is a bit circuitous—the input script for segwit UTXOs simply has less weight, thus it costs less fees to spent such UTXOs in a transaction.– Murch ♦Dec 18, 2020 at 0:48
-
@Murch Good point on phrasing of "transaction fee updates"—I meant "benefits" (SE forum check is usually an end-of-day activity for me). I've updated to make the example more concise. Feel free to suggest edits to the answer; since it is the accepted answer and many users stop there, I want to make sure it is as correct and helpful as possible! Dec 18, 2020 at 20:48
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:
- The recipient picks an address they would like to receive funds to. This will be an address format their wallet knows how to spend funds from. It is in the recipient's interest to pick a more efficient address format to save cost on spending the funds they will be receiving later.
- The sender picks the inputs they want to spend. The input scripts are set in stone by the address type these outputs were received to before. The sender is incentivized to pick an efficient address type for their change output to save future costs, though.
- Older wallet software may not be able to send to newer address types. Specifically, native segwit addresses only got an address standard in March 2017 (BIP-173), and not all wallets support sending to these addresses yet. In that case, the sender should ask the receiver to instead provide a wrapped segwit address. All wallets should be able to send to wrapped segwit addresses as that uses the Pay to Script Hash (P2SH, BIP-16) address standard which was introduced in 2012.
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.
answered Jan 28, 2020 at 22:10
-
There're privacy-related implications that different address types can possibly reveal the true change address, therefore some wallet may provide the option to avoid this. I saw reminds about this on Mycelium wallet. Jul 16, 2020 at 5:41
-
The privacy implication is not so much about change addresses specifically, but being able to determine what type of wallet client was used to send the transaction (potentially helping to narrow down the true owner). Change address privacy has to do with the difference in value between the two outputs. If a transaction sends the following values to two addresses: 0.524 and 0.489, it is more difficult to guess which is the change address vs. outputs like 0.5 and 0.00021 (the exact value is probably not change). Dec 18, 2020 at 21:03
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.
To summarize:
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.
