Bitcoin Forum
November 17, 2018, 07:52:19 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 55 56 ... 547 »
101  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.
102  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.
103  Bitcoin / Bitcoin Technical Support / MOVED: ban links on: August 16, 2018, 05:35:34 PM
This topic has been moved to Trashcan.

Duplicate
104  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
105  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
106  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.
107  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.
108  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.
109  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.
110  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.
111  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.
112  Bitcoin / Development & Technical Discussion / Re: Change genesis block, regtest mining fail on: August 06, 2018, 04:33:44 AM
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).
113  Bitcoin / Development & Technical Discussion / Re: Which bitcoin core version is best for Merchant website on: August 05, 2018, 04:29:53 PM
In that case, what does this update mean for online wallets? they'll have to shutdown unless they don't upgrade their bitcoind?
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.
114  Bitcoin / Development & Technical Discussion / Re: What are these wallet addresses?? on: August 05, 2018, 05:14:37 AM
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.
115  Bitcoin / Bitcoin Technical Support / Re: assistance to repair corrupt wallet.dat ? on: August 01, 2018, 03:50:59 AM
Those characters are completely meaningless, the file is a binary, not human readable text. You should instead post the hex representing the bytes of the file.

The file is most certainly corrupted, either from the formatting or from the recovery itself. If the recovery software was expecting a jpg file, then what it recovered will most certainly not have the correct file headers to be a zip. Just because you change the extension of a file does not mean that its contents magically become that file type (in case you didn't know, the file type is determined by the contents, not the file extension).
116  Bitcoin / Development & Technical Discussion / Re: Which bitcoin core version is best for Merchant website on: July 30, 2018, 03:55:48 PM
First of all, you are not using Bitcoin Core 0.16.2 because that error is not in Bitcoin Core 0.16.2. It is in the current master branch which is the development branch. That error (along with many other changes), will be in 0.17.

Secondly, you should read the error message. It is telling you that the RPC will be removed in 0.18 and it tells you how to enable it in the version that you are using. That means that, going forward, you should not be using that RPC. This does not mean that every time you upgrade Bitcoin Core that you have to change your code. However, if you are using things that are being deprecated, then yes, you will. That is what deprecation means.

You should not be using the accounts system because it is being removed. That is explicitly being told to you in that error message. You should use something else that is not deprecated.
117  Bitcoin / Development & Technical Discussion / Re: different version have different SignatureHash? on: July 30, 2018, 07:33:08 AM
No, it is not. You are completely misunderstanding the logic. The signature hash is exactly the same, it just uses different logic to construct it. CTransactionSignatureSerializer does not just stick the arguments to it together, it actually has logic to place things in the correct places. If you actually followed the code for it, you would see that it has it is an object that has its own serialize method which makes use of the arguments passed to it. It is the same signature hash, but with the logic abstracted out to a different object.
118  Bitcoin / Bitcoin Technical Support / Re: bitcoin core slow sync today? on: July 29, 2018, 09:33:24 PM
The problem is that your node is rejecting block 533816 which means that any node which attempts to give it that block or any of its descendants will be disconnected from immediately.

Open the Debug Console (Help > Debug Window > Console) and then enter this command: reconsiderblock 0000000000000000001f642d24d3968eeef81460531346adbfb9882dd711ed45. If it returns with null, then the block was accepted and you should be able to connect to nodes and sync the rest of the blockchain.

Otherwise, start Bitcoin Core with the -reindex-chainstate option. That will reindex the chainstate (not quite as bad as a full reindex) and that should also fix the problem.

If all else fails, deleting the most recent blk*.dat and rev*.dat files and then starting Bitcoin Core should work too. That will trigger a full reindex as well as redownload the most recent blocks.
119  Bitcoin / Bitcoin Discussion / Bitcoin Core 0.16.2 Released on: July 29, 2018, 06:27:53 PM
Bitcoin Core version 0.16.2 is now available from:

  <http://bitcoincore.org/bin/bitcoin-core-0.16.2/>

This is a new minor version release, with various bugfixes
as well as updated translations.

Please report bugs using the issue tracker at GitHub:

  <http://github.com/bitcoin/bitcoin/issues>

To receive security and update notifications, please subscribe to:

  <http://bitcoincore.org/en/list/announcements/join/>

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.

Compatibility
==============

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.

0.16.2 change log
------------------

### Wallet
- #13622 `c04a4a5` Remove mapRequest tracking that just effects Qt display. (TheBlueMatt)
- #12905 `cfc6f74` [rpcwallet] Clamp walletpassphrase value at 100M seconds (sdaftuar)
- #13437 `ed82e71` wallet: Erase wtxOrderd wtx pointer on removeprunedfunds (MarcoFalke)

### RPC and other APIs
- #13451 `cbd2f70` rpc: expose CBlockIndex::nTx in getblock(header) (instagibbs)
- #13507 `f7401c8` RPC: Fix parameter count check for importpubkey (kristapsk)
- #13452 `6b9dc8c` rpc: have verifytxoutproof check the number of txns in proof structure (instagibbs)
- #12837 `bf1f150` rpc: fix type mistmatch in `listreceivedbyaddress` (joemphilips)
- #12743 `657dfc5` Fix csBestBlock/cvBlockChange waiting in rpc/mining (sipa)

### GUI
- #12432 `f78e7f6` [qt] send: Clear All also resets coin control options (Sjors)
- #12617 `21dd512` gui: Show messages as text not html (laanwj)
- #12793 `cf6feb7` qt: Avoid reseting on resetguisettigs=0 (MarcoFalke)

### Build system
- #13544 `9fd3e00` depends: Update Qt download url (fanquake)
- #12573 `88d1a64` Fix compilation when compiler do not support `__builtin_clz*` (532479301)

### Tests and QA
- #13061 `170b309` Make tests pass after 2020 (bmwiedemann)
- #13192 `79c4fff` [tests] Fixed intermittent failure in `p2p_sendheaders.py` (lmanners)
- #13300 `d9c5630` qa: Initialize lockstack to prevent null pointer deref (MarcoFalke)
- #13545 `e15e3a9` tests: Fix test case `streams_serializedata_xor` Remove Boost dependency. (practicalswift)
- #13304 `cbdabef` qa: Fix `wallet_listreceivedby` race (MarcoFalke)

### Miscellaneous
- #12887 `2291774` Add newlines to end of log messages (jnewbery)
- #12859 `18b0c69` Bugfix: Include <memory> for `std::unique_ptr` (luke-jr)
- #13131 `ce8aa54` Add Windows shutdown handler (ken2812221)
- #13652 `20461fc` rpc: Fix that CWallet::AbandonTransaction would leave the grandchildren, etc. active (Empact)

Credits
=======

Thanks to everyone who directly contributed to this release:

- 532479301
- Ben Woosley
- Bernhard M. Wiedemann
- Chun Kuan Lee
- Cory Fields
- fanquake
- Gregory Sanders
- joemphilips
- John Newbery
- Kristaps Kaupe
- lmanners
- Luke Dashjr
- MarcoFalke
- Matt Corallo
- Pieter Wuille
- practicalswift
- Sjors Provoost
- Suhas Daftuar
- Wladimir J. van der Laan

And to those that reported security issues:

- Braydon Fuller
- Himanshu Mehta

As well as everyone that helped translating on [Transifex](http://www.transifex.com/projects/p/bitcoin/).



Note this thread will be self-moderated to keep out the spam that usually appears in these release announcement threads. (I forgot to do this on the original thread)
120  Bitcoin / Bitcoin Discussion / Re: Bitcoin Core 0.16.1 Released on: July 29, 2018, 06:25:36 PM
Bitcoin Core 0.16.2 has been released
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 ... 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!