There are multiple mathematical formulas and algorithms involved in both the calculation of a public key from a private key, and from a public key to a bech32 address.

I would estimate that it would take you a few decades to do either of these algorithms. With a computer to do some precomputation, you can probably do it in a few years.

---

For public key from a private key, Andrew Poelstra has a pretty good post describing it here: https://bitcointalk.org/index.php?topic=1534028.msg15594185#msg15594185 along with a precomputed table for you.

---

For the Bech32 calculation, you will need to be able to do two different hash functions: SHA256 and RIPEMD160. Then you also need to calculate the checksum which uses a BCH error correcting code.

For SHA256, Ken Shirriff has a pretty good blog post about how to do SHA256 by hand for mining. It's the same operations, just on different data. Also, you are doing only 1 SHA256 computation, not 2 as mining requires. You perform the SHA256 on your serialized public key in compressed form.

For RIPEMD160, I don't think anyone has really explained how to do by hand (and I don't really want to be cause it is long and takes a lot of time which I don't have). The algorithm is described in this paper with pseudocode given in Appendix A. It is similar to SHA256 in that the message is broken up into chunks which are XOR'd initially with some initial values and then later with the previous chunk.. You would like use a similar method as described in the SHA256 blog post but with the modifications to be able to do RIPEMD160. You perform RIPEMD160 on the above SHA256.

For calculating the checksum, you use the algorithm described under the Checksum section in the BIP. The gist of it is that, given a list of numbers, you apply multiple polynomials on all of the numbers and the "sum" of the results is the checksum (it's a lot more complicated than that and I don't remember all of the details). The python code given in the bech32_polymod() function describes how to do this. Note that ^= in python means XOR, not exponentiation.

To calculate the final bech32 string, you first need to convert the hash160 into a list of numbers usable for bech32's checksum calculation. You do this by splitting up the 160 bit hash into 5 bit chunks. Each 5 bit chunk is then a number so you now have a list of 5 bit numbers. You prepend to that the witness version, which is 0, so the list now starts with the number 0. Then you prepend to that an expansion of the human readable part of a bech32 string, bc. This is expanded by using the bech32_hrp_expand() function in the python code given in the BIP. You will get a list of numbers like so: [3, 3, 0, 2, 3]. So the resulting list of numbers will be 39 numbers in length and begin with [3, 3, 0, 2, 3, 0, .... Lastly you append six 0's to the end of the list which represent the positions that the checksum will go in. Now you do the bech32_polymod() function on this list of numbers and the resulting value you get back is the checksum.

Now you must convert all of these numbers to characters. You do this by breaking the checksum into 5 bit chunks to get a list of 6 numbers. Then, given the list of numbers containing the witness version number, the hash160, and the checksum, convert each number to the corresponding character using the lookup table described in the BIP. Note that you do not need to do this to the expanded human readable part. The resulting bech32 address is the human readable part concatenated to the character '1' concatenated to the characters for the witness version number, the hash160, and the checksum. So it will begin with bc1....

Regarding the human readable part expansion, that is done because the human readable part can be any ascii character and the numbers in the list of numbers need to be in the interval [0, 32). However ASCII can have numbers outside of that interval, so the expansion is done to have the higher bits, then the lower bits so it all fits in the interval.

Bech32 would probably only really take a few days / weeks. You just need to be careful to not make a mistake. The thing that takes a while would be privkey to pubkey.

getblockchaininformation is not a RPC command. You are probably looking for getblockchaininfo.

It doesn't it exist in Bitcoin yet. SIGHASH_NOINPUT requires a soft fork.

This question doesn't make any sense.

You can't. Lightning Network funding transactions look identical to any other transaction paying to a P2WSH output.

It can't do anything to mainnet since testnet is a completely separate network with almost 0 hashrate. The only reason this can happen on testnet is because someone has the majority hashrate.

Is your node fully synced? What do you get from the getblockchaininfo command?

No, because those things are not used in Bitcoin. Also, the library is heavily reviewed by cryptographers.

Even experimental things are generally safe to use as their cryptography is reviewed before it is implemented into libsecp256k1. The experimental mostly refers to the fact that APIs may change for those experimental things. Also, the experimental stuff is not enabled by default and must be explicitly enabled when compiling the library.

Yes, and no. Yes, a miner started from 0 and incremented the nonce until they found a hash that met the proof of work requirements. No, the difficulty does not require them to find a hash with 18 leading zeroes.

The leading zeroes thing is just a simplification of how the proof of work check actually works. What actually happens is that there is some target value that is a 256 bit integer. Block hashes are interpreted as a 256 bit integer. So all that happens is that the block hash (interpreted as a 256 bit integer) is compared to the target value. The block hash must then be less than or equal to the target value. Because the target value is "small" (small in terms of the 256 bit number space), it will have many leading zeroes. But the zeroes themselves do not actually matter, all that matters is the value.

There is only one parameter that matters: the target value. The difficulty is just the inverse of the target divided by the maximum target value.

The difficulty readjustment is really a target readjustment. The target changes every 2016 blocks, which is approximately two weeks. It does not actually change every two weeks since it may take shorter or longer than 2 weeks to find 2016 blocks. The target is just scaled proportionally to the amount of time it took to mine 2016 blocks and the amount of time it should take to mine 2016 blocks (2 weeks). Of course there must have been a starting point for the target, and that is the maximum target value (so difficulty is the lowest) which is defined in the consensus rules. The maximum target value was used in the genesis block so that is the starting point for target adjustment.

That is close. Miners don't usually re-select transactions after every set of nonces is exhausted. Usually they will change something within the block they already have. Specifically, they will set some value in their coinbase transaction that is known as the extra nonce. This extra nonce is then incremented every time the nonce runs out so that the merkle root is different and thus the nonces can be tried again. Furthermore, miners may change things like the block timestamp and block version number in order to get different candidate blocks.

Transactions are just transactions. There are no transaction headers. The block contains the transactions themselves and then the hash of all of the transactions is included in the merkle root which is in the block header.

No, the nonce is a 32 bit integer. It can only have the 32 bit integer values. It does not change with the difficulty.

A block hash is valid so long as it is less than or equal to the current target. So one with more leading zeroes is inherently less than, thus it will still be accepted.

Yes, but it is somewhat annoying to setup and it doesn't really work in the way that you would want it to.

On your offline wallet, get a bunch of addresses by using getnewaddress. Import these addresses into your online wallet using importmulti. Your online wallet will now track those addresses and your balance will update when those addresses receive coins.

Because those addresses are imported and are watching only, any time you do any wallet command, you must set whatever watching only option for that command to true, otherwise it will pull things from the online wallet itself and not the things you are watching.

HOWEVER, you cannot use getnewaddress or the GUI equivalent on the online wallet as that will actually give you keys generated in the online wallet. Furthermore, in order to have your offline wallet sign the transactions, you will need to provide additional information from the online wallet besides the transaction being signed. You will need to provide the scriptPubKey's of the outputs being spent, the amounts, and some other stuff I can't remember right now.

---

Note that the above HOWEVER only applies to versions prior to 0.17. The upcoming 0.17.0 release fixes these problems. You can create a wallet that has no private keys thus eliminating the need to be careful about getnewaddress as getnewaddress will not work when private keys are disabled for a wallet. Furthermore, 0.17 introduces BIP 174 Partially Signed Bitcoin Transactions which solves the issue of having to provide additional information as part of the command arguments. Instead that information will be packed into a PSBT which you can create and send to the offline wallet.

Because there isn't really a risk to using libsecp256k1. That's just there as a disclaimer since some parts of the library are experimental, but those are also labeled clearly.

libsecp256k1 is what Bitcoin Core uses for all of its ECDSA operations for several years now. The library was created by some Bitcoin Core developers.

BIP 174 and the Lightning Network are two completely separate and independent things. They are designed to achieve complete separate and independent goals. That article is wrong.

The Lightning Network is a scaling solution for doing transactions off chain.

BIP 174 is a transaction format for transactions that are not ready to be broadcast to the Bitcoin network yet. It is not a protocol nor is it a layer 2 solution for off chain transactions.

BIP 174 only helps for creating and signing on chain transactions. It is designed for inter-client compatibility and to allow easier hardware wallet and offline wallet setups.

Yeah, those docs tend to lag a few versions. The most up to date versions exist in the code itself. You can get those docs by doing
It will give you the help for the command.

Indeed, that probably would help. The heuristic currently is actually rather dumb. IIRC it decodes as non-witness first and then checks for whether there are invalid opcodes in the scripts of any inputs. We could certainly have it check the output amounts to see if they are sane (between 0 and 21 million).

There's nothing illegal about it. There is just no real benefit to the network if many or all nodes are running on VPS services like AWS. All of those nodes are using the same block of IP addresses. They are likely hosted in the same data centers, so they are centralized in both the same digital region (IP address blocks) and the same physical region (datacenter location). Furthermore, if Amazon or DIgitalOcean decided that they didn't want people running Bitcoin nodes on their VPSes, they could shut down those VPSes and take off a large portion of the network. Thus having many nodes on VPSes with the same VPS providers does not really contribute to the decentralization of the network and is similar to just one node being run.

This is a known issue and unfortunately it cannot be fixed without a fork. The issue lies with the format of a segwit transaction itself. A segwit transaction, under some circumstances, can be interpreted as either a 0 input, 1 output transaction, or as a witness transaction. Since getrawtransaction fetches transactions from blocks themselves or from the mempool, the transaction must be a valid network transaction and thus witness serialization can be attempted safely as a first step and only deserializing as non-witness if the witness deserialization fails.

However, decoderawtransaction behaves differently as it is intended to be used during the transaction creation steps. This means that it must be able to handle 0-input, 1 output transactions (which are inherently non-witness) as users may create a 0-input, 1 output transaction, decode it, and then pass it to fundrawtransaction to get inputs. But because some 0-input, 1 output transactions can be interpreted as witness transactions, and some witness transactions can be interpreted as 0-input, 1 output transactions, decoderawtransaction does not always succeed to decoding a transaction correctly. It uses some heuristics in order to decrease the number of false decodings, but sometimes, as you can clearly see, it's wrong.

Fortunately, if you know that a transaction is witness you can set the iswitness argument (added in 0.16) to true to tell it explicitly to decode the transaction as witness. You can set it to false for non-witness decoding. Not setting it uses the heuristics.

So your command will be something like:

First of all, double the current hashrate would be nearly impossible for someone to get. They would have to acquire ALL of the mining equipment in the world, and then do it again, all without taking away the existing equipment. This would be exorbitantly expensive, both in resources and in time. Manufacturers can't just magically produce machines that they don't have. It takes time, money, and raw materials. Such an operation would be very obvious.

Second, people running nodes, and nodes themselves, are not stupid. They would definitely notice a 500,000+ block blockchain reorganization. That is extremely obvious and there would be warnings put up all over place. Such an attack would likely result in some form of human intervention which prevents people's nodes from switching to using the attacker's blockchain.

It's a good thing that the code is completely different from what you did.

Also, this isn't "stealing your idea". You created a pull request for a particular feature. People did not like how you implemented it (and they also did not like how you rude you were in the thread and on IRC). The existence of your pull request has been taken as a feature request (you put out a request for us to implement this feature). Someone is implementing the feature you requested.

There's a link in the linked article that goes directly to the TOR Project's website. That's what it is telling people to download and extract. Furthermore, the link is to the download page, not a directly download link itself.

No, this is wrong.

First of all, 0x05 does not mean segwit, it means P2SH. Bitcoin Core by default creates addresses that are P2WPKH nested inside of a P2SH address. That is why you see embedded in the getaddressinfo output.

Your pool software is incorrect here, and that is the source of the problems. The scriptPubKey that you should have used is a91409763cb05dcea0f98f53b0f08651f92c5d2d2f3887 which maps to the address 32Z3eXSPgxcHj2fnQy8d6dg66eVtZfxrBM. The 09763cb05dcea0f98f53b0f08651f92c5d2d2f38 part is the hash160 of the redeemScript. Since this is a P2WPKH nested in a P2SH, the redeemScript is 00142ee67d879ccf17daec87b4ed4a6cecdd9b3f64a0. However, what your pool software did was it ignored the version byte (the 0x05) which indicates that the hash160 encoded in the address should use a P2SH scriptPubKey. Instead, it made a P2PKH scriptPubKey using the provided hash160 which is why you see that the coins were sent to 1s2iywx94HudryMHsU2g1K9x8DB1cahGc.

It is missing because the pubkey does not exist in your wallet. What it is looking for is a pubkey that has a hash160 of 09763cb05dcea0f98f53b0f08651f92c5d2d2f38. But what you have is a redeemScript that has a hash160  of 09763cb05dcea0f98f53b0f08651f92c5d2d2f38. The pubkey that is in that redeemScript is unrelated to this address entirely.

The address is unrelated to the pubkey.

Your coins are lost, you cannot recover them. You would need a public key which hashes to 09763cb05dcea0f98f53b0f08651f92c5d2d2f38 and its associated private key. All you have is a redeemScript that has that hash. That redeemScript is not a public key. Thus you cannot get those coins as you cannot spend them.


No No No! You are horribly mistaken and completely wrong. That is not how P2WPKH is nested in P2SH. Doing this will cause your coins to be lost. P2WPKH nested in P2SH uses the scriptPubKey of the P2WPKH output as the redeemScript. It does not use the keyhash as the hash in the P2SH scriptPubKey. The P2SH address OP has is correct, his pool software is just broken.

Right, duh.

The way to get this information out without using dumpwallet is to use BDB's db_dump utility which will output all of the raw records from the wallet. What you want are the keymeta ones. When you use db_dump, you will get a bunch of hex output. What you want to do is look for the lines which begin with the hex 076b65796d65746121. The line immediately after contains the actual key metadata which has the timestamp for key creation. These timestamps are 8 byte, little endian integers. They begin at the 5th byte after the beginning of the line, so 8 characters after the beginning.

For example, here is a keymeta record from one of my wallets:
As you can see, the first line begins with 076b65796d65746121. Then on the second line, the timestamp is 5c147e5b00000000. Converting this to the unix timestamp results in 1534989404. This is a UNIX timestamp. As an actual date and time, it is Thursday, August 23, 2018 1:56:44 AM UTC.

This is a bit more manual, but it could probably be scripted.

Also, make sure you use the BDB 4.8 version of db_dump which can be downloaded from http://www.oracle.com/technetwork/database/database-technologies/berkeleydb/downloads/index-082944.html (scroll down to 4.8.30).

Note that you have to use the command line, i.e. the terminal (for unix systems) or the command prompt (windows). The command that you will use is

You don't need an HD wallet to observe this. With both HD and non-HD wallets, you should see a block of 100 (or 1000) keys created at one time, and then another block of 100 keys created at another time. That other time would be the time that the password was changed.

Just use dumpwallet and look at the dates in the resulting dump. The block of 100 keys with the most recent timestamp is the time the encryption was changed. Also, note that if you have used the wallet, you will see some keys that do not fit into these blocks of 100 keys. Those keys are generated after a key from the keypool is used.

I believe you are just using EasyBitcoin incorrectly.

The constructor for a Bitcoin object is

So you are setting $host to be the URL you want to use. However when EasyBitcoin sends the RPC call, it will use the URL of {$this->host}:{$this->port}/{$this->url}. So the real URL that you are using is 127.0.0.1:8332/wallet/wallet1.dat/:8333 which is not the wallet your bitcoind has loaded.

Rather you should be doing

You can check the endpoints that are actually being called by starting bitcoind with -debug=rpc and then looking at the debug log. The endpoints that are being called should be logged and you can see the difference between the URLs from bitcoin-cli and the URLs from EasyBitcoin.