The mentioned 26-35 length is valid for addresses encoded using base58. These are the addresses starting with either a "1" or a "3". Native Segwit addresses use a base32 encoding, start with "bc" and they are case insensitive. These addresses have better error detection at a cost of being around 27% larger than the base58 equivalent. Version 0 witness addresses are always 42 or 62 characters afaik, If you would like more info on bech32 check out: https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki |
|
|
|
Q2: I would like to buy a book to understand these nuances. Can you recommend one?
This is an excellent book to get you covered: https://github.com/bitcoinbook/bitcoinbook. It's for free on github or if you want you can buy it in print. |
|
|
|
|
Transactions are stored on the blockchain. All currently unspent transactions for which you can produce a valid unlocking script are yours to spend. A wallet keeps a collection of the keys you need to unlock those unspent transactions, so no bitcoins themselves are stored in a wallet.
You are describing a wallet like it is a bank account, where one account holder has one account number. This is not the case in bitcoin. So one wallet is usually a collection of lot of "addresses".
|
|
|
|
Hello everyone! From which year the compressed pubkey become? 2015?
Bitcoin client 0.6.0 introduced compressed public keys and was released in March 2012. This is from the release notes: New wallets created with this version will use 33-byte ‘compressed’ public keys instead of 65-byte public keys, resulting in smaller transactions and less traffic on the bitcoin network. The shorter keys are already supported by the network but wallet.dat files containing short keys are not compatible with earlier versions of Bitcoin-Qt/bitcoind |
|
|
|
|
In order to implement smart-contracts you would probably need a scripting language that is Turing-complete. Bitcoin as of current uses a stack-based scripting language that is not Turing complete, for instance looping is not possible. Security wise this is a very good choice since it prevents infinite loops in a script that could lock up every single node when processing the script.
So in order to to fully support Smart contracts the scripting language of Bitcoin should be changed. But even then there's the difficulty of truly understanding what a script can do (see the DAO-fail on ETH) and a way of preventing infinite loops (like using Gas on ETH).
|
|
|
|
The bitcoin protocol adjust the mining reward each time 210,000 blocks have been mined since the last halving. Since the protocol aims for a block to be every 10 minutes on average this means the halving should occur every 4 years. We currently experienced three halvings. Please see this overview stating, as you can see in the last column, the mining reward will be at 1 satoshi starting from block 6720000: halving | block | year | reward
---------|---------|------|------------
0 | 0 | 2009 | 50.00000000
1 | 210000 | 2012 | 25.00000000
2 | 420000 | 2016 | 12.50000000
3 | 630000 | 2020 | 6.25000000
4 | 840000 | 2024 | 3.12500000
5 | 1050000 | 2028 | 1.56250000
6 | 1260000 | 2032 | 0.78125000
7 | 1470000 | 2036 | 0.39062500
8 | 1680000 | 2040 | 0.19531250
9 | 1890000 | 2044 | 0.09765625
10 | 2100000 | 2048 | 0.04882812
11 | 2310000 | 2052 | 0.02441406
12 | 2520000 | 2056 | 0.01220703
13 | 2730000 | 2060 | 0.00610352
14 | 2940000 | 2064 | 0.00305176
15 | 3150000 | 2068 | 0.00152588
16 | 3360000 | 2072 | 0.00076294
17 | 3570000 | 2076 | 0.00038147
18 | 3780000 | 2080 | 0.00019073
19 | 3990000 | 2084 | 0.00009537
20 | 4200000 | 2088 | 0.00004768
21 | 4410000 | 2092 | 0.00002384
22 | 4620000 | 2096 | 0.00001192
23 | 4830000 | 2100 | 0.00000596
24 | 5040000 | 2104 | 0.00000298
25 | 5250000 | 2108 | 0.00000149
26 | 5460000 | 2112 | 0.00000075
27 | 5670000 | 2116 | 0.00000037
28 | 5880000 | 2120 | 0.00000019
29 | 6090000 | 2124 | 0.00000009
30 | 6300000 | 2128 | 0.00000005
31 | 6510000 | 2132 | 0.00000002
32 | 6720000 | 2136 | 0.00000001
33 | 6930000 | 2140 | 0.00000001
lnx@tasman:~/dev/snippets$
lnx@tasman:~/dev/snippets$ python3 halving.py
halving | block | year | reward
---------|---------|------|------------
0 | 0 | 2009 | 50.00000000
1 | 210000 | 2012 | 25.00000000
2 | 420000 | 2016 | 12.50000000
3 | 630000 | 2020 | 6.25000000
4 | 840000 | 2024 | 3.12500000
5 | 1050000 | 2028 | 1.56250000
6 | 1260000 | 2032 | 0.78125000
7 | 1470000 | 2036 | 0.39062500
8 | 1680000 | 2040 | 0.19531250
9 | 1890000 | 2044 | 0.09765625
10 | 2100000 | 2048 | 0.04882812
11 | 2310000 | 2052 | 0.02441406
12 | 2520000 | 2056 | 0.01220703
13 | 2730000 | 2060 | 0.00610352
14 | 2940000 | 2064 | 0.00305176
15 | 3150000 | 2068 | 0.00152588
16 | 3360000 | 2072 | 0.00076294
17 | 3570000 | 2076 | 0.00038147
18 | 3780000 | 2080 | 0.00019073
19 | 3990000 | 2084 | 0.00009537
20 | 4200000 | 2088 | 0.00004768
21 | 4410000 | 2092 | 0.00002384
22 | 4620000 | 2096 | 0.00001192
23 | 4830000 | 2100 | 0.00000596
24 | 5040000 | 2104 | 0.00000298
25 | 5250000 | 2108 | 0.00000149
26 | 5460000 | 2112 | 0.00000075
27 | 5670000 | 2116 | 0.00000037
28 | 5880000 | 2120 | 0.00000019
29 | 6090000 | 2124 | 0.00000009
30 | 6300000 | 2128 | 0.00000005
31 | 6510000 | 2132 | 0.00000002
32 | 6720000 | 2136 | 0.00000001
|
|
|
|
That's based on bitcoin core 18.0 so it's just running an older version of bitcoin core than the current one or OP's one. Back then bitcoin-cli or rpc-calls would indeed do the translation to address based on public key. |
|
|
|
What do you mean by the page is out of date? The process of generating legacy addresses from private keys hasn't changed. How can it be out of date?
Although the page itself still works it gives a warning the public key is of an invalid length when entered in compressed format. So it is kind of out-of-date for not recognizing compressed public keys as valid. |
|
|
|
I wonder if these files are open source on github. I would like to check them. In what lang they are written for example.
This function is in python from my own software. It works with compressed/uncompressed keys: import binascii, base58, hashlib
def public_key_to_address(public_key):
bin = binascii.unhexlify(public_key)
#Step 1: Create hash of public key:
hash_of_public_key = hashlib.sha256(bin).digest()
#Step 2: Calculate RIPEMD-160 of the public key:
r = hashlib.new('ripemd160')
r.update(hash_of_public_key)
r.hexdigest()
#Step 3: Adding network bytes (00) to RIPEMD-160
networked = binascii.unhexlify('00'+r.hexdigest())
#Step 4: Double hash the networked RIPEMD-160
sha4a = hashlib.sha256(networked).digest()
sha4b = hashlib.sha256(sha4a).digest()
#Step 5: Get the first four bytes of sha4b:
four_bytes = str(binascii.hexlify(sha4b).decode('utf-8'))[:8]
#Step 6: Adding the four_bytes to the end the RIPEMD-160 from step 3:
address_hex = str(binascii.hexlify(networked).decode('utf-8')) + four_bytes
#Step 7: Convert the hex_address using base58 to bitcoin adres
address_base58 = base58.b58encode(binascii.unhexlify(address_hex))
return str(address_base58.decode())
|
|
|
|
Since you didn't describe what steps you took I can't comment on what you did wrong. What I can tell you is the following: You got your private key: c89856dd1b8f867fedfbefaa95c340a086aaaf1b086ffa3772b37540b45912f9
Based on this private key you can generate either a compressed or uncompressed public key: Public keys:
compressed: 039E8CFA0C5F56D61AA7ADC9CCE5963E9622C29AF2D61E82A2494B7051107B8720
uncompressed:049E8CFA0C5F56D61AA7ADC9CCE5963E9622C29AF2D61E82A2494B7051107B8720D2A18C74A3968A65860CCCAE2892A6A6B39001104B34D5E8D332598C06625A03
The public keys result in a different address but use the exact same algorithm and end up encoding a hash in base58 format. So both these addresses are "p2pkh", most newer ones are bases on a compressed public key: compressed: 1L1Z1V8WCQi5DEuQeF3GLR9LPWEUF2swtU
uncompressed: 15hw8MaTFjJsdkpwGNoBZRjGoCNzUy3D37
|
|
|
|
^^ That being said, most explorers translate the (uncompressed) pubkey which is in the script to an address. So what happens: txid = 4bec1175f9682fc10118bbb146d1def8fd82fdffdf27da8beea327469f79b2b0
pubkey from script = 04994b2548a865ad7e786c691bb9cac7d15afc60b8b4500e24e79ec1cd910830b7dd799defdfdc1a7136e4976d2086daa319a7923f633987905a86aaece612ab9b
pubkey to address = 19wBtLQYtLgriGWLjgAXWwedTBgPYbjE97
txid = 4caea993e7caa859840a8ebac457c31420bb4fb79b528d870556c5a2eec5da7a
pubkey from script =0405d71f20e493a0721e705944e7151a1d7c1b9a9cd546cc44c2f348fa6e27b588ddfdd7b3e52c9af208598f3b2ac519af9d7ee78cea4f237ee5028020e33633c9
pubkey to address = 12WSoZ84ZJAKDo4MbbgKQtw3qT8gTF2o4e
|
|
|
|
Ok Bro, help me fined privkey to this pubkey: 04eb838fb6782028a5adfc4082e52f30341ad2c0b3571ed8082062304a11eddeeb6d72b07bdf5c9 40efeeaa7f91e5a2552f632bb20e2744720973b26b4d16c61af I dont know exact range, but think what range is not to lage. PLEASE TRY SEARCH PRIVKEY, CAN YOU GET THIS PRIVKEY ? ? You are aware there are no funds in 1PymQyaT8eLb8e3vgkpjgcesNwpEgQ56CB right? |
|
|
|
To be honest, I missed an entire year :S My block height of 52,200 was based on april 2010 instead of 2011. When checking the raw file blk0000.dat I saw the last block in there was with height 119977. So I ran the numbers again: sum(total_incoming)|
-------------------|
1763310.7677514425|
These are all coins mined/deposited up till April 2011 (block 119977) which are untouched until today. This number ismore consistent with your 1.7M estimate. Please note that my own database hasn't synced fully yet so if coins have been spent recently they might still be in this number. In short: it's an educated estimate not an exact given  |
|
|
|
Big Thank All of You !!! You get me axact information what I search.
So now it's your turn, what is your ultimate goal with this/these public keys? I'm sure it's not just so you can fire up some software... |
|
|
|
My software input parametr only pubkey accepted. So, I need a pubkey for adress
So what software is that? Your 1337 pubkey to private key extractor? Privkey for bc1 and the pubkey will be the same or different ? I strongly suggest you try to learn a bit more on the internal workings of bitcoin, that way you might also realize you won't get rich by trying to "hack" private keys. That being said: An address is just a form of encoding a public key (or the hash of the public key). Bitcoin works with a combination of Private Key - Public Key pairs. So the same private key can be used to generate segwit addresses as well as legacy addresses. |
|
|
|
Bro how you get pubkey for bc1 ? I very need it. Explain please how to get pubkey for bc1 ?
Can you please read the answers already given? That's a very broken website IMO, it's full of dead links at my end. For your question, you wont be able to find the public key unless you own the address ( you have the priv key) or it was used to send bitcoins at least one time. If it was used before and it's a P2WPKH or a P2WPKH-in-P2SH, simply paste it in a blockexplorer: use blockstream.info to follow this: Click a transaction that used it as an input. Click " Details +" and Find " Witness" inside that particular input. The 33Byte string ( 66 characters) after the last space is that SegWit address' public key. To sum up: - The segwit address has to be used as an input in a transaction, if not then the public key is not known in the blockchain.
- So you need to find a transaction where the segwit address is used as an input. Any blockexplorer should be able to help you with this
- Once you have a transaction id either use @nc50lc description I linked above to get the pubkey
- Or you could use bitcoin cores bitcoin-cli to decode a transaction as described by @mocacinno
But the real question remains: why do you need these public keys??. I have an idea though... |
|
|
|
Thank you for your help - adress for ex. bc1qzgkzgavk6xveej7zpl9pwn2fw5l3lufwjyaze8
Pubkey for bc1qzgkzgavk6xveej7zpl9pwn2fw5l3lufwjyaze8:
03409f1b64a5c66599feafaf4cadfa84ab5c058aa3ef29e128582ae83717b19c57
|
|
|
|
address |total_incoming |total_outgoing|
----------------------------------|------------------|--------------|
12tkqA9xSoowkzoERHMWNKsTey55YEBqkv| 28150.05015902001| 0.0|
1HLvaTs3zR3oev9ya7Pzp3GB9Gqfg6XYJT| 9260.000364999998| 0.0|
198aMn6ZYAczwrE5NvNTUMyJ5qkfy4g3Hi| 8000.00033346| 0.0|
1PTYXwamXXgQoAhDbmUf98rY2Pg1pYXhin|3233.1703100000004| 0.0|
1HjdiADVHew97yM8z4Vqs4iPwMyQHkkuhj|2200.0002100000006| 0.0|
There are even a few addresses from that period with a lot more than 50BTC incoming and nothing ever spent. sum(total_incoming)|
-------------------|
1398416.2312229003|
When summing all balances from addresses funded in blocks below a height of 52200 and no outgoing transactions whatsoever I get a number quite a bit lower than your 1.7 million, about 1,398,416 BTC untouched. There is no way of telling how much of these coins were mined by Satoshi and/or which coins have their associated private keys lost forever. |
|
|
|
|
Show Posts
