Bitcoin Forum
September 20, 2018, 01:55:41 AM *
News: ♦♦ Bitcoin Core users must update to 0.16.3 [Torrent]. More info.
  Home Help Search Donate Login Register  
  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 ... 543 »
1  Bitcoin / Bitcoin Discussion / Re: Bitcoin Core 0.16.3 Released on: September 19, 2018, 04:36:51 AM
If the node is crashed, then is it possible that the blockchain/chainstate corrupted? It would be suck for those who use older version and use HDD if someone decide to use the exploit.
It is unlikely as those issues were identified as bugs a while ago (around 0.10 or 0.11 IIRC) and fixed. If the process dies or is killed, starting it again should have it pick up where it stopped (or very near it) and not require a reindex. For several major versions now, I have been able to kill bitcoind (using sudo kill -9 so it actually kills it with SIGKILL) and have it be fine when it starts back up again.
2  Bitcoin / Bitcoin Discussion / Re: Bitcoin Core 0.16.3 Released on: September 18, 2018, 10:42:49 PM
Can anyone explain in an Eli5 exactly what this means?
If a node running Bitcoin Core from versions 0.14.0 to 0.16.2, receives a block that contains a transaction that has a duplicate input, that node will crash.

Does "exploitable" mean that this possibility existed or was exploited?
It means that the vulnerability currently exists and Bitcoin Core versions 0.14.0 to 0.16.2 and could be exploited by anyone who has enough hashrate to mine a block. There are no known instances of it actually being exploited.

And that leaves the various forks of this last year at risk, doesn't it? I doubt they have the ability to fix it so fast until someone can exploit it.
The person who reported this reported it to other projects as well, including BCH node software Bitcoin ABC. They have fixed this bug, however I do not know if other fork coins have as well.
3  Bitcoin / Bitcoin Discussion / Re: Bitcoin Core 0.16.2 Released on: September 18, 2018, 09:13:35 PM
Bitcoin Core 0.16.3 has been released.
4  Bitcoin / Bitcoin Discussion / Bitcoin Core 0.16.3 Released on: September 18, 2018, 09:12:02 PM
Bitcoin Core version 0.16.3 is now available from:


This is a new minor version release, with various bugfixes.

Please report bugs using the issue tracker at GitHub:


To receive security and update notifications, please subscribe to:


How to Upgrade

If you are running an older version, shut it down. Wait until it has completely
shut down (which might take a few minutes for older versions), then run the
installer (on Windows) or just copy over `/Applications/Bitcoin-Qt` (on Mac)
or `bitcoind`/`bitcoin-qt` (on Linux).

The first time you run version 0.15.0 or newer, your chainstate database will be converted to a
new format, which will take anywhere from a few minutes to half an hour,
depending on the speed of your machine.

Note that the block database format also changed in version 0.8.0 and there is no
automatic upgrade code from before version 0.8 to version 0.15.0 or higher. Upgrading
directly from 0.7.x and earlier without re-downloading the blockchain is not supported.
However, as usual, old wallet versions are still supported.

Downgrading warning

Wallets created in 0.16 and later are not compatible with versions prior to 0.16
and will not work if you try to use newly created wallets in older versions. Existing
wallets that were created with older versions are not affected by this.


Bitcoin Core is extensively tested on multiple operating systems using
the Linux kernel, macOS 10.8+, and Windows Vista and later. Windows XP is not supported.

Bitcoin Core should also work on most other Unix-like systems but is not
frequently tested on them.

Notable changes

Denial-of-Service vulnerability

A denial-of-service vulnerability (CVE-2018-17144) exploitable by miners has
been discovered in Bitcoin Core versions 0.14.0 up to 0.16.2. It is recommended
to upgrade any of the vulnerable versions to 0.16.3 as soon as possible.

0.16.3 change log

### Consensus
- #14249 `696b936` Fix crash bug with duplicate inputs within a transaction (TheBlueMatt, sdaftuar)

### RPC and other APIs
- #13547 `212ef1f` Make `signrawtransaction*` give an error when amount is needed but missing (ajtowns)

### Miscellaneous
- #13655 `1cdbea7` bitcoinconsensus: invalid flags error should be set to `bitcoinconsensus_err` (afk11)

### Documentation
- #13844 `11b9dbb` correct the help output for -prune (hebasto)


Thanks to everyone who directly contributed to this release:

- Anthony Towns
- Hennadii Stepanov
- Matt Corallo
- Suhas Daftuar
- Thomas Kerin
- Wladimir J. van der Laan

And to those that reported security issues:

- (anonymous reporter)

5  Other / Meta / Re: My Account banned on: September 18, 2018, 04:04:18 PM
Plagiarism is an automatic permanent ban. It does not matter how many posts are copied from others nor does it matter if the posts are deleted by a moderator. The mere fact that there were copied posts means that you will be permanently banned from the forum. A permanent ban applies to you the user, not to your account. Just because one account is permanently banned does not mean that you can use another account to make posts. You are not allowed to create a new account or use another account to post; you as a person are banned from this forum.
6  Other / Meta / Re: How NEWBIES are treated on: September 18, 2018, 04:02:07 PM
If mods delete the bad posts, then the spammers won't make their quotas, and they wont get paid. It a simple solutiion, and could lead to the emigration of the parasites.
This is better than the one implemented, maybe some mods are so lazy relying on the reports of the users, what if mods seek for bad posts and ask for a help from active high members to do delete bad posts
Most mods _do_ delete posts without relying on reports, but we still do rely on reports. However the quantity of posts that get made per minute is so high that it would be a more-than-full time job (i.e. probably 12-16 hours per day) to read every post and make a decision whether to delete them. The moderators do not have time for that. More moderators would be helpful, but we cannot rely on just the moderators. The community needs to help police itself, and people need to understand the rules.
7  Bitcoin / Development & Technical Discussion / Re: wallet.dat hash reset on: September 18, 2018, 01:13:17 PM
I think OP has a wallet.dat he can't access, because he doesn't have the password to unlock it. He probably thinks, he can simply replace the hash in this wallet.dat with his own version to access the funds of this wallet. Since he doesn't mention the reason for his question, I guess this is a matter of a stolen wallet and a brilliant idea...
I suspected that was the case..

I think OP has a wallet.dat he can't access, because he doesn't have the password to unlock it. He probably thinks, he can simply replace the hash in this wallet.dat with his own version to access the funds of this wallet. Since he doesn't mention the reason for his question, I guess this is a matter of a stolen wallet and a brilliant idea...
Yes, I want to do this
You can't.

First of all, the password is not stored as a hash. Secondly, changing the way the password is stored will not change how the keys in the wallet are encrypted. It will simply make it impossible to decrypt the wallet. It is not the software that is preventing you from opening the wallet, it is the fact that the private keys are encrypted and you do not know the password.

Bitcoin Core's encrypted wallet format is roughly like this: a secure encryption key is generated and used to encrypt every single private key in the wallet. That secure encryption key is itself encrypted with the password which is stretched with several rounds of PBKDF2 (a hash function designed to generate encryption keys from passwords) and salted (the salt is included when hashing). The result is that the encryption key itself is encrypted with the password, and the private keys in the wallet are encrypted with the encryption key. The only things that are stored are the encryption key in its encrypted form, the parameters to the key stretching process (number of iterations of PBKDF2 and the salt), and the encrypted private keys themselves.

As you can see, there are no hashes stored whatsoever. What matters is the encrypted encryption key. If you were to replace that encrypted encryption key with your own encrypted encryption key (i.e. a different encryption key encrypted with a different password), the key would be unable to actually decrypt the encrypted private keys. You cannot change the password without knowing the current password as it is needed to decrypt the encryption key and to re-encrypt it with the new password.
8  Bitcoin / Development & Technical Discussion / Re: Manually convert a Binary or HEX private key to WIF, then find the Public Key on: September 18, 2018, 12:12:42 AM
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: 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.
9  Bitcoin / Development & Technical Discussion / Re: wallet.dat hash reset on: September 18, 2018, 12:08:43 AM
I know how to extract a hash, I need a program to replace it, then I ground on my hash
What do you mean by "ground on my hash"?

What are you trying to do? Changing that hash isn't going to change anything in the wallet except making it un-openable. What exactly do you think this is going to accomplish?
10  Bitcoin / Development & Technical Discussion / Re: Bitcoin-core. Unhandled rejection RpcError: 404 Not Found when calling getBlockc on: September 15, 2018, 07:53:25 PM
getblockchaininformation is not a RPC command. You are probably looking for getblockchaininfo.
11  Bitcoin / Development & Technical Discussion / Re: wallet.dat hash reset on: September 15, 2018, 07:52:43 PM
Hash of what? What hash are you trying to replace?

What exactly are you trying to do? Please ask a question about the goal that you are trying to accomplish, not what you think is a way to accomplish that goal. Asking about how to replace some hash in the wallet.dat file sounds like you think you can solve a problem by replacing a hash. Instead of asking how to replace that hash, you should ask about the problem that caused you to think to replace a hash.
12  Bitcoin / Development & Technical Discussion / Re: SIGHASH_NOINPUT and Lightning Network on: September 13, 2018, 01:30:46 PM
    const bool fAnyoneCanPay;  //! whether the hashtype has the SIGHASH_ANYONECANPAY flag set
    const bool fNoInput;       //! whether the hashtype has the SIGHASH_NOINPUT flag set
    const bool fHashSingle;    //! whether the hashtype is SIGHASH_SINGLE
But I can't find "SIGHASH_NOINPUT" in bitcoin master source.
This is only in branch?
It doesn't it exist in Bitcoin yet. SIGHASH_NOINPUT requires a soft fork.

2.In Bitcoin blockchain are transactions which opens bidirectional LN channel?
If not, these are in testnet?
This question doesn't make any sense.

3.I want search blocks are find all transactions which opens bidirectional LN channel.
How I can do it?
You can't. Lightning Network funding transactions look identical to any other transaction paying to a P2WSH output.
13  Bitcoin / Development & Technical Discussion / Re: What`s the deal with the testnet? on: September 11, 2018, 04:14:02 PM
Has anyone notice this? Today one miner has been mined almost all blocks on testnet. And he has not including any segwit transactions in the blocks! My test transactions have not been confirmed since 6 hours ago!

I am a bit worry of this type of attack could deal a great damage to Bitcoin Mainnet!
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.
14  Bitcoin / Bitcoin Technical Support / Re: strange bitcoind reindex and txindex on: September 09, 2018, 04:16:53 PM
Is your node fully synced? What do you get from the getblockchaininfo command?
15  Bitcoin / Electrum / Re: [Electrum 3.2.3] Why does it wish to use an at-risk package called libsecp256k1? on: September 08, 2018, 04:28:39 PM
Has there been any reported hacks that took advantage of the fact that some parts of libsecp256k1 are experimental?
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.
16  Bitcoin / Bitcoin Technical Support / Re: A TECHNICAL question about blockchain, btc mining on: September 08, 2018, 04:24:43 PM
1-) I'm looking at block 540494, its nonce is 2097181953 its hash is 00000000000000000024ada2........

so it starts with 18 leading zeros..

that means a miner starts from 0 calculates its hash with the nonce=0 IF no valid result, THEN increments nonce by 1. now nonce=1, and keep doing this until a hash is found with 18 leading zeros. Because current difficulty requires them to find a hash with 18 leading zeros, right?
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.

Sub-question: I know difficulty changes every 2 weeks, it is now 7,019,199,231,177 but who decides how many leading zeros should be in the valid hash? is it something to do with "target difficulty" rather than the "difficulty number" itself? Are these 2 different difficulty parameters that define the difficulty?
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.

So for this particular example (block 540494) the nonce is 2097181953

that means a miner tried every single nonce from 0 to 2,097,181,953, and calculated hash 2,097,181,953 (lets say 2 billions) times in total and found the valid result which is the hash starting with 18 zeros. (00000000000000000024ada2........)

Now what I dont understand is that an ASIC machine can hash 12 trillion times PER SECOND. and our nonce is 2,097,181,953. so that means winning miner spent only fraction of a second to calculate 2 billions hashes. But it cant be true because block time is 10 minutes, right? so what is wrong here?? What am I doing wrong with this calculation?

My understanding is like the following;

* Miner have a list of transactions and all the properties (headers I believe) to calculate the hash of the block.

* Miner calculates hashes for all the nonces between 0 and the current difficulty (it is now 7,019,199,231,177)

* IF miner finds a hash with at least 18 leading zeros (can be more than 18 zeros, right? since even if it has 20 leading zeros, it is still proof of the work.) that miner gets the reward.

* IF miner cant find a nonce between 0 - 7,019,199,231,177 then miner picks different set of transactions (since calculations with the current list of transactions wont be resulting valid hash.. So miner adds couple more transactions into the block and starts the whole process all over again with the new list of transactions.. hoping to find a valid hash with the nonce between 0 and 7,019,199,231,177 and with the new set of transactions.
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.

* Miner have a list of transactions and all the properties (headers I believe) to calculate the hash of the block.
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.

* Miner calculates hashes for all the nonces between 0 and the current difficulty (it is now 7,019,199,231,177)
No, the nonce is a 32 bit integer. It can only have the 32 bit integer values. It does not change with the difficulty.

* IF miner finds a hash with at least 18 leading zeros (can be more than 18 zeros, right? since even if it has 20 leading zeros, it is still proof of the work.) that miner gets the reward.
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.
17  Bitcoin / Bitcoin Technical Support / Re: Separate public and private key wallets on: September 08, 2018, 04:15:17 PM
Is it possible to setup bitcoind such that it only uses a wallet with public keys and have a separate local (does not talk to the world) bitcoind with a wallet that has the private keys ?
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.
18  Bitcoin / Electrum / Re: [Electrum 3.2.3] Why does it wish to use an at-risk package called libsecp256k1? on: September 08, 2018, 02:56:59 PM
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.
19  Bitcoin / Development & Technical Discussion / Re: BIP-174 vs Lightning network on: September 07, 2018, 05:17:35 PM
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.
20  Bitcoin / Bitcoin Technical Support / Re: Possible bug in decoderawtransaction in 16.02? on: September 06, 2018, 07:42:55 PM
Yes, this does indeed work! The documentation found at doesn't list the second parameter. According to the documentation decoderawtransaction only takes a single parameter. Guess the documentation isn't up to date here.
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
bitcoin-cli help <command>
It will give you the help for the command.

One last question about the heuristic in this specific case: It's pretty clear the assumption made this was a transaction without witness data is wrong based on the fact it's reporting a negative value as an amount. So shouldn't the "heuristic algoritm" reassess itself when the output generated was clearly wrong:

Input -> Trying as non witness -> Output is valid -> Done
Input -> Trying as non witness -> Output is invalid -> Trying as witness ->Output is valid -> Done

I might be oversimplifying things here but it seems to me this would lead to a lot less incorrect assumptions from heuristics.
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).
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 ... 543 »
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!