Bitcoin Forum
November 17, 2018, 07:58:46 PM *
News: Latest Bitcoin Core release: 0.17.0 [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 ... 547 »
61  Bitcoin / Development & Technical Discussion / Re: The duplicate input vulnerability shouldn't be forgotten on: September 22, 2018, 03:15:32 PM
I know this is probably the last argument most people want to hear, but is this not a case where more independent implementations would result in less risk?  If you maintain that one particular client should form the "backbone of the network", you have to consider what happens if that backbone breaks.  If there were a wider variety of clients being run, there may have been less of a threat to the network overall?

Core have done exceptional work, but at the end of the day, they're still only human.  Assigning more people to keep an eye on one codebase might help mitigate faults, but if there's only one main codebase, there's still going to be an issue if an error slips through the net.  Hence my belief that more codebases would create a stronger safeguard.
What many people do not realize is that having people run different implementations makes it easier for attackers to partition the network and thus harder to resolve situations where vulnerabilities are exploited. Network partitioning can cause multiple blockchain forks which is a much harder situation to resolve than a single fork or an entire network shutdown.  It is not just that some nodes will go down and the rest are up and the network is still running. If the attack is directed in a certain way, miners will be separated and no longer connected to each other which then causes forks. Network partitioning is a serious issue, and running different implementations makes it easier for attackers to partition the network. So having multiple implementations and recommending that people run alternative software is really not a good thing.

That being said, having multiple implementations is good for the individual who runs multiple nodes with different implementations. With multiple nodes each with different software, attacks exploiting critical bugs lets them know if an attack is going on. If everyone ran multiple nodes with different implementations, then multiple implementations are fine. The network would not shutdown and there wouldn't be any network partitioning. But not everyone is going to do that.
62  Bitcoin / Bitcoin Discussion / Re: Bitcoin Core 0.16.3 Released on: September 21, 2018, 01:33:21 PM
Sorry I don't understand, I'm having trouble updating to bitcoin core version 0.16.3. what if I don't update to that version?
Then you are at risk of being attacked and could possibly accept an invalid block. You could be made to believe that some coins exist which do not actually exist. You are at risk of being defrauded if you perform any transactions. You are at risk of being forked onto a different blockchain than the rest of the Bitcoin network.

does it affect my comments?
This question does not make sense.
63  Bitcoin / Bitcoin Discussion / Re: Bitcoin Core 0.16.3 Released on: September 21, 2018, 01:41:41 AM
This ?

There appears to be a workaround to bypass the assert check in Bitcoin Core 0.16 that allows one to mint new coins by using an input multiple times and it be accepted by the network without crashing. Probably will be waiting until the dust settles on this before publishing that test case though, since it's clearly much more severe than a DoS
64  Bitcoin / Bitcoin Discussion / Re: Bitcoin Core 0.16.3 Released on: September 21, 2018, 12:28:46 AM
There was actually more to the bug than just a DoS vulnerability. It allowed for inflation. Users MUST upgrade now.

Full disclosure is available here:

The reason this has been disclosed after such a short notice is because someone has independently discovered these vulnerabilities and posted about them publicly on Hacker News.
65  Bitcoin / Bitcoin Discussion / Re: Bitcoin Core 0.16.3 Released on: September 20, 2018, 01:58:26 PM
Virustotal says:



Dr.Web on my Windows PC swears too on this file...

So as 360 Total Security does not like "bitcoin-0.16.3-win64-setup.exe" file. It found 2 viruses after installation of this new version.

SHA-256 checksums are OK in both cases.
It's a false positive. Antivirus software frequently false positive on Bitcoin Core because it contains code that is found in malware. Namely, it looks for and opens a wallet.dat file (because it is the thing that makes it in the first place and uses it for your wallet), and it contains bitcoin mining code (it does, but that can only be used on regtest). However, many coin stealing malware look for a wallet.dat file. And other malware will mine cryptocurrencies without you knowing. Since Bitcoin Core can do both of those things, it is usually flagged as being malware when it really is not.
66  Bitcoin / Development & Technical Discussion / Re: When Schnorr will be added? on: September 20, 2018, 03:46:46 AM
It was thought that BIP9 would be a faster and safer way of doing softforks than the Satoshi-style method, but boy did that turn out to be wrong. It was definitely not intended to be a way of letting miners "vote"; miners are not and should not be a decision-making body for Bitcoin.
TBF, BIP 9 is very similar to the method used in previous soft forks, namely that miners signal readiness via a different version number and that the rules activate when the signalling passes a certain threshold. This had worked for several soft forks in the past, so it didn't seem like that bad of an idea. BIP 9 just made this method more sane by not having to burn version numbers and to allow for simultaneous soft forks.
67  Bitcoin / Bitcoin Discussion / Re: Bitcoin Core 0.16.3 Released on: September 20, 2018, 03:16:32 AM
Theymos, what i was referring to is seeing you keep the sig and the file in the same location, what is keeping a hacker for rehashing the key after he hacks the client and reposting his version of the sha256 sig file?

Seeing we are verifying the sig from the same site as the file. Its like locking your house and placing the house key under your welcome mat.  The file and sig are too close together.

The sig indicates who signed it though. The attacker can only do this successfully if he is able to compromise Wladimir and get the signing key from him. Otherwise, replacing the sums file and the sig with his own versions will either result in an invalid sig, or a sig from the wrong key. When users verify the download, they should be checking that the downloaded binary's sha256 matches, that the signature for the sums file is valid, and that the key that made the signature is Wladimir's release signing key.
68  Bitcoin / Development & Technical Discussion / Re: When Schnorr will be added? on: September 20, 2018, 02:40:10 AM
AFAIK Schnorr don't use similar method for backward compability.
Schnorr will be added via a new segwit version number. It will not require a transaction format change, there just be a witness version 1 in addition to the current witness version 0.
69  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.
70  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.
71  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.
72  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)

Hash: SHA256

0768c6c15caffbaca6524824c9563b42c24f70633c681c2744649158aa3fd484  bitcoin-0.16.3-aarch64-linux-gnu.tar.gz
fb2818069854a6ad20ea03b28b55dbd35d8b1f7d453e90b83eace5d0098a2a87  bitcoin-0.16.3-arm-linux-gnueabihf.tar.gz
75a537844313b0a84bdb61ffcdc5c4ce19a738f7ddf71007cd2edf664efd7c37  bitcoin-0.16.3-i686-pc-linux-gnu.tar.gz
78c3bff3b619a19aed575961ea43cc9e142959218835cf51aede7f0b764fc25d  bitcoin-0.16.3-osx64.tar.gz
c67e382b05c26640d95d8dddd9f5203f7c5344f1e1bb1b0ce629e93882dbb416  bitcoin-0.16.3-osx.dmg
836eed97dfc79cff09f356e8fbd6a6ef2de840fb9ff20ebffb51ccffdb100218  bitcoin-0.16.3.tar.gz
1fe280a78b8796ca02824c6e49d7873ec71886722021871bdd489cbddc37b1f3  bitcoin-0.16.3-win32-setup.exe
bd48ec4b7e701b19f993098db70d69f2bdc03473d403db2438aca5e67a86e446  bitcoin-0.16.3-win64-setup.exe
5d422a9d544742bc0df12427383f9c2517433ce7b58cf672b9a9b17c2ef51e4f  bitcoin-0.16.3-x86_64-linux-gnu.tar.gz
Version: GnuPG v1.4.11 (GNU/Linux)

73  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.
74  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.
75  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.
76  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.
77  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?
78  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.
79  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.
80  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.
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 ... 547 »
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!