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.

This topic has been moved to Trashcan.

Duplicate

This topic has been moved to Trashcan.

Duplicate

There is no maximum on the time between blocks, so there is no maximum at 10 minutes. The distribution time between blocks is not a normal distribution. Rather it is poisson with the true mean at ~9.7 minutes. The difficulty adjusts to make it 10 minutes, but new hardware coming online pulls the time down. Since it is poisson, the time can vary a lot, from 0 minutes to several hours, there is no maximum at 10 minutes.

That error means that bitcoind started, ran into a problem (usually in the configuration) and then shut down.

Please post the contents of your debug.log file.

It doesn't matter where the software is installed to. What matters is the data directory it is configured to use. There is no need to install the software twice, you can run multiple instances of the same binary. Just start each one with -datadir=<path> where <path> is the path to the folder you want that instance to store its data.

This topic has been moved to Trashcan.

Duplicate

This topic has been moved to Trashcan.

Duplicate

This topic has been moved to Trashcan.

Duplicate

Not with today's technology. A public key is supposed to be public. It helps in the future if quantum computers have enough qubits, but that's a long ways off. The main benefit of not reusing addresses is privacy.

You must not be looking very hard because there are clear explanations of this. It is one of the most commonly asked questions. https://en.bitcoin.it/wiki/Address_reuse explains this.

16^64 is 2^256 which is the number of possible SHA256 hashes. With P2PKH and P2WPKH, the number of possible hashes in those types of outputs is 2^160. This means that yes, in theory there are multiple public keys which have the same hash160 but different SHA256 hashes. However, we cannot say if all hash160's have collisions, nor can we say how many collisions there might be. This is because SHA256 may not actually produce all possible 256 bit values. It is possible that there are some values that do not have any data that hash to them, but we do not and cannot know this for sure with today's technology (or likely any technology for that matter).

However, even though the probability of a collision is high when you consider the sets of all possible values, the probability of finding a collision is still extremely low as the set of all possible values is extremely large.

Offline address generation means exactly what it sounds like: generating an address on a machine that is offline, i.e. not connected to the internet. If you don't even know what offline address generation is, then you reply to that question saying either you don't know what they mean or you have not tried generating an address offline.

Offline transaction generation means exactly what it sounds like: creating and signing a transaction on a machine that is offline. Since signing transactions requires data from the blockchain (which thus implies that you had to be online at some point), offline transaction generation usually refers to signing where the signing is done on an offline machine.

Being able to find a collision of any hash function used in Bitcoin can completely mess with Bitcoin. It would result in, at best, lost funds. Or we will have a consensus failure.

Let's suppose you found a collision in the hash160 algorithm (RIPEMD160 of the SHA256 of data) used for P2PKH, P2SH, and P2WPKH outputs. Say you are able to find a collision of a hash in a P2WPKH or P2PKH output. That means that you have found a piece of data that has the same hash of a public key owned by someone else. If this piece of data also happens to be a valid public key and you know it's private key, you can spend an output that isn't really yours. Thus you can steal funds from someone.

Now suppose that you can find a collision for a hash in a P2SH output. That means that you have found a piece of data that has the same hash as the redeemScript for that output. If this piece of data is also a script and is a script which does nothing or involves public keys for which you know the private keys for, then you can spend that P2SH output even though it isn't really yours.

Let's now suppose you found a collision in SHA256. SHA256 by itself is only used for P2WSH outputs. But if you had a SHA256 collision algorithm, you could do the exact same things with P2WSH outputs as you could with P2SH outputs, i.e. spend an output that is not yours.

Let's suppose you found a collision in SHA256 Double (SHA256 of SHA256 of data) which is used in block hashing and transaction hashing. With this, you can cause a consensus failure. If you find a valid block whose hash collides with another block's, you would be able to force nodes to have different views of the blockchain from each other. This is because one node would have one block that has one set of transactions in it, and another node would have a different block (but with the same hash) that has a different set of transactions in it. If transactions in one block are not in the other, but they are referenced in a later transaction, then the transaction would fail to validate. In general, this would be very bad for the network as it would be possible for nodes to have a different view of the blockchain and thus not be in consensus. This would not really be detectable automatically as both blocks would have the same hash.

With a SHA256d collision, you can also collide transactions. If you can create two transactions that spend different inputs or create different outputs and have the same txid, then you can also cause a consensus failure in the same way that colliding blocks would. You can have some nodes believe a chain of transactions is invalid because their values or output scripts don't match.


In conclusion, hash collisions are bad for Bitcoin and can cause lost money or consensus failures. If any of the hash functions in use in Bitcoin every have a practical collision attack, then we should move to different hash functions ASAP.

Yes. The TXID is the nversion, txin, txout, and nlocktime fields. The wtxid is everything. Just concatenate everything together from the part where each field is broken down. The lengths are still there so you can just stick them all together.

Because the genesis block actually has to be mined. It must have a valid proof of work, you cannot just make a genesis block that fails the consensus rules (except for the prevblock rule).

No major online wallet uses Bitcoin Core's account system. In fact, no major service uses Bitcoin Core for their wallet. So no, they won't shutdown because they have their own systems for handling wallets and user accounts. Bitcoin Core is typically used solely for block and transaction validation as an edge node in all major services.

Those addresses are not invalid, they are segwit addresses. Native segwit uses a different address format from non-segwit ("normal" 1 and 3 addresses).

The address within an address that you see is a P2SH address. This is an address that contains within it a script, which itself can map to another address.

It is important to note that Bitcoin does not use addresses at a low level. Rather addresses are turned into scripts, and vice versa, for those scripts. So P2SH addresses contain scripts, and those scripts may map to an address, thus you will see an address within an address.