address – Can a single wallet generate (and use) both SegWit and non-SegWit addresses?

Is a Segwit wallet able to generate and use non-Segwit addresses?

I’m using Bitpay’s Bitcore to create wallets and generate new addresses for the users of my platform. I’m also using Bitcore-wallet-client to sign transactions.

My users have legacy wallets right now. I intend to migrate their wallets to native Segwit, but they will also need legacy addresses so that they can receive coins from anywhere. (right?)

Is it possible to have only one wallet per user, generating both types of addresses, or will I have to manage two wallets per user?

And if I have to manage two wallets per user, utxos from one wallet won’t be available to the other, obviously. What’s the best way to deal with their ‘split balance’? Should I orient users to send all their coins to the bc1 address of the new Segwit wallet? But then, whenever they receive funds in their legacy addresses, they’d have to transfer again to the bc1 address in order to make Segwit transactions. It makes no sense – or does it? What am I missing?

bitcoin core – Is it possible to query a node for all addresses containing value?

Bitcoin-core (the full node implementation that makes up the majority of the network) does not keep an index of all addresses and balances, so without writing additional code to do the job, it is not possible. Bitcoin-core keeps track of coins via the UTXO model– the idea of ‘an address with a balance’ is just an abstraction of this that makes for a more user-friendly interface.

Of course, you could write some code to create an index of addresses and their respective balances, or perhaps find an already-existing open-source block explorer project that accomplishes this.

Is it possible to query a node for all addresses?

For instance, can I run a query on a bitcoin node, that returns all addresses with more than 1 bitcoin on them?

address – What are Green Addresses?

The green address is a third party trust trick and can help resolve most problems related to the need to wait for confirmations (slow transactions).

To make it very simple :

Service A publishes its green address, service B decides to trust service A.

When someone send bitcoins from service A to service B, he will send from the service A green address.

The service B knows he can trust the service A, he knows A won’t double spend, so B can credit the sent bitcoins immediately, without waiting for confirmations ( or waiting for just one confirmation, which is probably wiser ).

This is mostly useful for transferring bitcoins b2b (business to business), typically it would help making arbitrage easier and faster between 2 bitcoin exchanges, if both decide to trust each other’s green address.

This can also be useful to allow for POS (Point of sales) with instant transactions if the POS can trust the green address of your bitcoin bank (or online wallet)

As an individual, I could also negotiate with my local supermarket to trust my green address (providing them my IRL address, ID number and more if needed). Once they decide to trust my green address, I can pay immediately with bitcoins at my local supermarket (they trust me and won’t need to wait for confirmations).

The green address is just a bitcoin address, but it’s a “from” address people decide to trust and accept transactions from this address without waiting for confirmations.

Possible drawbacks are :

  • Less anonymity, or even no anonimity at all ( always using the same public from address), which is not a problem for a business, and its even great for public accounting/auditing ( yes bitcoin can also help fighting corruption ! )

  • Blockchain spam (more transactions for the bitcoin network), which is a good thing if the blockchain can scale.

  • Encourages people to use trusted wallet providers (some kind of bitcoin banks). Here too, this have good and bad sides.

  • It’s not enough to create a green address, you still need to be trusted so that your green address is useful

  • For now, afaik, only, and support the idea. To be useful, green address system needs to be widely adopted by bitcoin pools, exchanges, online wallets, businesses, etc.

    See also
    ( edit 11 years ago, october 2020 , this reference is no more very relevant, some people completely rewrote the wiki page years later,for obscure reasons . . . they even replaced the first line with a blockstream ad . . . but you can still go and check the earliest versions of this page, around 2011-2012 , by clicking the “history” tab of the wiki page )

address – Compatibility questions regarding Native Segwit addresses

Sending bitcoins means to lock funds to a specific output script. The output script determines how the funds can later be spent. E.g. if funds were sent to a P2WPKH (Pay to Witness Public Key Hash) address, they can later be spent using a P2WPKH input script. If funds were sent to a P2PKH (Pay to Public Key Hash) address, they have to be spent using a P2PKH input script instead.

The (native segwit) P2WPKH input script has less weight than the P2PKH input script, so receiving funds to P2WPKH addresses will save you fees when you later spend those funds. The output scripts for both are similar in size.

enter image description here

Funds of any type of input can be assigned to outputs of any type in a transaction. You can even mix: spending a native segwit and a non-segwit input, and sending to a non-segwit and a native segwit output in one transaction works fine.
However, as you say, some wallets may not support sending to native segwit addresses. In that case, the receiver should fall back to providing a backwards compatible P2SH-wrapped segwit address which is still cheaper than non-segwit but can be sent to by almost all wallets. You can track native segwit adoption on Bitcoin Optech’s Compatibility Matrix or

My understanding is that such wallets cannot properly validate Native Segwit addresses and cannot create Native Segwit outputs. Does it also mean that such wallets cannot properly spend the outputs generated by Native Segwit addresses?

Correct. A wallet that does not know how to interpret native segwit addresses would not be able to spend funds received from a native segwit address. This is not a problem in practice, because the receiver provides the spender with the invoice address they want to receive the funds to. The receivers wallet will not generate a native segwit address, when it is unaware of native segwit.

8 – What is the acceptable method for importing addresses via feeds?

I have a list of businesses that I need to import and naturally they all have addresses. However the field address on my content type is not targetable during mapping, but all the other fields are. I did some google searching and because address field is not a core feature and part of a contrib module, I cannot do this?

Is there a way around this? I can’t manually input all these businesses, it would take far too long! What is the appropriate way to tackle this?

address – How is it possible that the same WIF Private Key generates two different addresses?

I am wondering if you can explain this.

I went here:

Created the SegWit Address below:




Public key


Private key (WIF key)


Then I opened Electrum v3.1.3 and Imported WIF Pkey above.

And I got this address instead:


So now there are two addresses, one SegWit (or I think P2SH) starting with 3… and the legacy address from Electrum starting with 1…

Appreciate an explanation of this.

Thank you.

bitcoin core – Version prefix used for Bech32 addresses

Those bytes (x03x03x00x02x03 or better shown as 0x0303000203) are the expanded human readable part. You can find the code on BIP-173.

def bech32_hrp_expand(s):
  return (ord(x) >> 5 for x in s) + (0) + (ord(x) & 31 for x in s)

The problem however is that unlike Base58 encoding, those bytes are only used in calculation of checksum not as the starting bytes. Which makes the picture misleading in my opinion.

Bech32 encoding is very different from Base58 encoding as there is no “version prefix”. There is an Hrp, a witness version, a data (hash) and a checksum. Witness version | hash are the data being encoded and expanded_hrp | data is used in checksum calculation (| is concatination).

Why you should generate new bitcoin addresses

Many of the times bitcoin transactions can happen with the same address which can be a bit risky. Your activity can easily be tracked and can even give access to hackers. Therefore, the next time you make a bitcoin transaction, make sure to change the address…

address – list of addresses for major bitcoin exchanges

I use this website.

You can filter bitcoin addresses by business organizations. You can also see updated list of transactions by each business organization. This site has exchange, pool, and other addresses.

Definitely never take information like this at face value, but it does provide some interesting insight.