Bitcoin Forum
February 18, 2019, 09:10:30 AM *
News: Latest Bitcoin Core release: 0.17.1 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 2 3 4 5 6 7 8 9 [10] 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 ... 551 »
181  Bitcoin / Development & Technical Discussion / Re: just for you to know on: September 04, 2018, 03:47:13 AM
http://botbot.me/freenode/bitcoin-core-dev/msg/104049316/
and the one below.
one of them got a sinking feeling haha
Quote
Have you noticed ...
no it's not the case

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.
182  Bitcoin / Bitcoin Technical Support / Re: How to:Running a hybrid full node = Broadcasting to clearnet and TOR hidden net on: September 04, 2018, 01:32:09 AM
Right click the file and ‘Extract all’. Open the new directory, then the one named ‘Tor’. Double click on Tor.exe.

Sounds suspicious, there's no need to do that at all.

My advice: Do not do this. Follow the guide in the docs at the Bitcoin github.com page.
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.
183  Bitcoin / Bitcoin Technical Support / Re: Access funds on legacy address related to segwit addr to which I got access to on: August 30, 2018, 03:52:12 PM
1. scriptPubKey for both addresses contains 09763cb05dcea0f98f53b0f08651f92c5d2d2f38 part, which is, afaik, actuall public key. First byte differs, which makes sense, since it's prefix, 00 for legacy and 05 for segwit respectively.
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.

regarding output for 1s2iywx94HudryMHsU2g1K9x8DB1cahGc :

2. pubkey property is missing, which is weird, because usually its included for legacy addresses
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.

3. isMine property equals false, wich means that wallet does not recognize this address relation to wallet PK.
The address is unrelated to the pubkey.

So, can anyone please provide some insight and tell us if (and how?) we can access those funds, or we've lost them for good? Thanks in advance.
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.


Which means your ScriptPubKey is if you use P2WPKH (bc1q9mn8mp.... address):
Code:
00 14 2ee67d879ccf17daec87b4ed4a6cecdd9b3f64a0

Or it is the following if you use P2WPKH nested in P2SH
Code:
a9 14 2ee67d879ccf17daec87b4ed4a6cecdd9b3f64a0 87

But what your program was doing to create your address (32Z3eXSPgxcHj2fnQy8d6dg66eVtZfxrBM) is the following:
Code:
a9 14 09763cb05dcea0f98f53b0f08651f92c5d2d2f38 87
0976... is your ScriptHash which means it was a "redeem script" that got hashed not a public key. Possibly means more than 1 key was used but I may be mistaken about that.
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.
184  Bitcoin / Development & Technical Discussion / Re: Is it possible to know the date I changed my wallet.dat password? on: August 28, 2018, 03:31:45 PM
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.

Thanks, I already tried dumpwallet however it ask me to enter the wallet passphrase first which I have forgotten. If you know how to bypass this hurdle please let us know.
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:
Code:
076b65796d6574612103ffc5d227b2e27f2e1253eb44c359eed1af38ec6028da2ec62205f479f533c6d7
0b0000005c147e5b000000000c6d2f30272f30272f35373727eaa6033dd5740c71a55efd9e7e6c8d102974535f0000000000000000000000000000000000000000
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
Code:
db_dump wallet.dat
185  Bitcoin / Development & Technical Discussion / Re: Is it possible to know the date I changed my wallet.dat password? on: August 28, 2018, 02:13:47 AM
I don't believe that data is stored within the wallet for older, non-HD wallets.

With the newer HD wallets, whenever you change the password, it will modify the seed and the master key and then generate new keys/addresses... I have two old dumpwallet outputs from a testnet wallet, one before a password change, and one after. The timestamps in these files show the original creation date for the keys (ie. when the keys were generated to fill the keypool)...

So, by looking at the current "hdmaster" key timestamp, I can tell when the password was changed. Unfortunately, given that your wallet was created in 2013, that would predate Bitcoin Core HD Wallets Undecided
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.
186  Bitcoin / Bitcoin Technical Support / Re: Bitcoin Core Multi-wallet HTTP RPC request problem in v16 on: August 26, 2018, 09:34:22 PM
I believe you are just using EasyBitcoin incorrectly.

The constructor for a Bitcoin object is

Code:
__construct($username, $password, $host = 'localhost', $port = 8332, $url = null)
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
Code:
$bitcoin = new Bitcoin("userhidden","passhiddden", '127.0.0.1', '8332', 'wallet/wallet1.dat/');

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.
187  Bitcoin / Development & Technical Discussion / MOVED: Bitcoin Core Multi-wallet HTTP RPC request problem in v16 on: August 26, 2018, 09:25:03 PM
This topic has been moved to Trashcan.

Duplicate
188  Bitcoin / Development & Technical Discussion / MOVED: BIP 171 - Specs, Mock server, template project and client librairies on: August 23, 2018, 02:38:40 PM
This topic has been moved to Trashcan.

Duplicate
189  Bitcoin / Development & Technical Discussion / Re: Bitcoin Block time on: August 22, 2018, 09:34:03 PM
Someone with good statics knowlege could calculate how average the block time is really. So normally it should be a Gauss normal distribution with the maximum at 10 mins. But it is not, cause e.g. miners are activated or deactivated and difficulty can not react. Look how many blocks are found exactly 10 mins after the last one or even 11 or 9 min.
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.
190  Bitcoin / Development & Technical Discussion / Re: Seem like bitcoin -daemon not run on: August 21, 2018, 04:38:33 PM
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.
191  Bitcoin / Development & Technical Discussion / Re: Bitcoin Core and bitcoind running on: August 20, 2018, 01:24:31 AM
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.
192  Bitcoin / Bitcoin Technical Support / MOVED: ban links on: August 16, 2018, 05:35:34 PM
This topic has been moved to Trashcan.

Duplicate
193  Bitcoin / Development & Technical Discussion / MOVED: Server wont sync 3.1.2 on: August 15, 2018, 05:18:13 PM
This topic has been moved to Trashcan.

Duplicate
194  Bitcoin / Development & Technical Discussion / MOVED: false to verify ECDSA sinature in golang on: August 14, 2018, 04:32:26 AM
This topic has been moved to Trashcan.

Duplicate
195  Bitcoin / Development & Technical Discussion / Re: Random or user-specified ports on: August 13, 2018, 04:14:44 AM
There is no need to modify the source code. Just start Bitcoin Core with the -port=<port> option where <port> is the port that you want to use. Also, in order to run multiple instances of Bitcoin Core, you will need to have one of them use a different data directory. You can set this by starting Bitcoin Core with -datadir=<path> where <path> is the path to the data directory that you want to use.
196  Bitcoin / Bitcoin Technical Support / Re: Must I always generate a new public address/key every time for both sending and on: August 10, 2018, 08:48:39 PM
Is it really possible for someone to deduce your private key if you use the same public key more than once?
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 would think this would be the first thing someone would explain to people new to crypto. It took awhile before I even new I should have these Qs. I wonder why there isn't more clear explanations of this on the internet.
You must not be looking very hard because there are clear explanations of this. It is one of the most commonly asked questions. http://en.bitcoin.it/wiki/Address_reuse explains this.
197  Bitcoin / Development & Technical Discussion / Re: If I could find a collision... on: August 10, 2018, 02:20:58 AM
If there's only 16^64 possible outputs, wouldn't the hash of every possible sha256 output result in a collision, even if you don't know what it's colliding with?
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.
198  Bitcoin / Development & Technical Discussion / Re: What this means? offline address/tx generation on: August 10, 2018, 01:59:09 AM
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.
199  Bitcoin / Development & Technical Discussion / Re: If I could find a collision... on: August 10, 2018, 01:55:57 AM
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.
200  Bitcoin / Development & Technical Discussion / Re: In need of TxID and WTxID of BIP143 transactions for UnitTesting on: August 07, 2018, 06:29:31 AM
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.
Pages: « 1 2 3 4 5 6 7 8 9 [10] 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 ... 551 »
Bitcointalk.org is not available or authorized for sale. Do not believe any fake listings.
Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!