Well that’s disappointing
. So private key generation is the same. Is there a getbech32address command in bitcoin core?
I believe you'll need to use
Code:
getnewaddress "" "bech32"
If that doesn't work, you'll need to set
Code:
addresstype=bech32
Topic: Bitcoin address inflation (Read 205 times)
Well that’s disappointing
. So private key generation is the same. Is there a getbech32address command in bitcoin core?
I believe you'll need to use
If that doesn't work, you'll need to set
As I understand it last year (or possibly this year) we got a new set of public key/private key pairs for the bech 32/ native segwit addresses.
nothing has changed about number of key pairs or how they work. there is still the same number of private keys (0< key
Quote
As I understand, the native segwit addresses have added to the pool of Bitcoin addresses, but by how much?
Normal segwit addresses (the non native ones beginning with a 3) share the same private keys as the legacy addresses so there's a theoretical no change in the number of private keys for that.
Normal segwit addresses (the non native ones beginning with a 3) share the same private keys as the legacy addresses so there's a theoretical no change in the number of private keys for that.
what has changed is the new type of output that you can create which belongs to segwit so the addresses are also different. otherwise every step until creation of an address is the same:
private key --EC multiplication--> public key --SHA256 of RIPEMD160--> hash160
then if you encode that result with base58check you get address starting with 1. if you encode it with bech32 you get an address starting with bc1.
Well that’s disappointing
. So private key generation is the same. Is there a getbech32address command in bitcoin core?
As I understand it last year (or possibly this year) we got a new set of public key/private key pairs for the bech 32/ native segwit addresses.
nothing has changed about number of key pairs or how they work. there is still the same number of private keys (0< key
Quote
As I understand, the native segwit addresses have added to the pool of Bitcoin addresses, but by how much?
Normal segwit addresses (the non native ones beginning with a 3) share the same private keys as the legacy addresses so there's a theoretical no change in the number of private keys for that.
Normal segwit addresses (the non native ones beginning with a 3) share the same private keys as the legacy addresses so there's a theoretical no change in the number of private keys for that.
what has changed is the new type of output that you can create which belongs to segwit so the addresses are also different. otherwise every step until creation of an address is the same:
private key --EC multiplication--> public key --SHA256 of RIPEMD160--> hash160
then if you encode that result with base58check you get address starting with 1. if you encode it with bech32 you get an address starting with bc1.
Actually hard question not that beginner one 
.
I think address "pool" is same. Its extremely huge, to the point almost endless. If you can add to that with different address format?
That is real question, probably not, its just address "conversion" to another format. Correct me someone if im wrong.
.I think address "pool" is same. Its extremely huge, to the point almost endless. If you can add to that with different address format?
That is real question, probably not, its just address "conversion" to another format. Correct me someone if im wrong.
As I understand it last year (or possibly this year) we got a new set of public key/private key pairs for the bech 32/ native segwit addresses.
As I understand, the native segwit addresses have added to the pool of Bitcoin addresses, but by how much?
Normal segwit addresses (the non native ones beginning with a 3) share the same private keys as the legacy addresses so there's a theoretical no change in the number of private keys for that.
As I understand, the native segwit addresses have added to the pool of Bitcoin addresses, but by how much?
Normal segwit addresses (the non native ones beginning with a 3) share the same private keys as the legacy addresses so there's a theoretical no change in the number of private keys for that.
Jump to: