9

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?

5

Yes. Each address type contains new features, but all are compatible with each other. SegWit is an improvement in the transaction protocol.

A SegWit transaction splits (segregates) a transaction into two pieces: one containing the standard legacy data (to, from, amount,...), plus a scripted piece of that data (witness) that is 75% smaller on-chain. 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, or to a SegWit address (as a cheaper transaction due to less data transferred). A legacy address however doesn't know about the witness, 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.

When you have UTXOs in your wallet, they may be from either one of the transaction types. For any address, that UTXO's data either contains the legacy data, or the witness data, depending on what type of transaction was used to send the coins.

Note on Mixed Script Transactions: These are transactions where UTXOs hat may have come from different script types are placed into a single transaction. It's also an illustration of what happens when a coins are sent to different address types.

  • You receive 0.5 BTC to your SegWit wallet from a legacy address.
  • You receive 0.5 BTC that were sent using SegWit.
  • You send a 1 BTC transaction, which uses both the legacy and SegWit UTXOs.
  • The result is a SegWit transaction. If it goes to a legacy address, any further movement of the coins will be legacy transactions, until it reaches an address that is SegWit enabled, at which point it can be sent as 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.

Wallet client aside, if you manually broadcast the transaction on the bitcoin network itself, everything is interoperable.

5
  • 1
    The 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 '20 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 '20 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. – SentientFlesh Dec 17 '20 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 '20 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! – SentientFlesh Dec 18 '20 at 20:48
6

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.

2
  • 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. – Chris Chen Jul 16 '20 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). – SentientFlesh Dec 18 '20 at 21:03
6

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.

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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.