How are transactions propagated through the bitcoin network? (In-depth) I know the general gossip protocol that occurs i.e transactions are sent to neighboring nodes who then send it to their peers etc. but I was trying to find a more in-depth answer on how transactions are sent across the bitcoin network.

I read briefly in a paper that there is some sort of transaction queue that the node keeps for each neighbor and that they will only select a random (?) amount of those transactions and send in an INV message to those nodes.

Why don't they send them all the transactions in the queue and why does it wait a random amount of time to send the transactions in the queue?

Any help would be great, thanks!

I read briefly in a paper that there is some sort of transaction queue that the node keeps for each neighbor and that they will only select a random (?) amount of those transactions and send in an INV message to those nodes.

Note that this is specific to Bitcoin Core. Other full node software may not exhibit this behavior.

When Bitcoin Core receives a transaction, it adds the transaction to lists that it maintains for every other node it is connected to. Each node has its own list and that list contains all of the transactions that your node has received but may not have been received by the other node. After a certain random time delay, your node will then send messages to the other node. Among the messages it sends is an INV for transactions in the list for that node.

However not all transactions in the list are sent. Only some of them are sent. To select which transactions are sent, your node will sort the transaction list by the number of ancestors it has (so that parent transactions are relayed before child transactions) and by its feerate. Those transactions with the fewest ancestors and highest feerate will be at the top. Transactions are selected from this sorted list until either the INV message reaches its limit (which happens rarely) or there are no transactions remaining. Once transactions are selected, the INV is sent.

  Why don't they send them all the transactions in the queue and why does it wait a random amount of time to send the transactions in the queue?

The random delay between sends is done for privacy reasons. The sorting of transactions is done to prioritize the transactions that will be selected first by miners. It also helps with privacy.

The reason these help with privacy is because a spy node that has connected to your node will not be able to always know what transactions your node has received and what your mempool looks like. It won't be able to know which transactions you have received first. Furthermore, due to the random delays, if a transaction originates from your node, it is possible that a node connected directly to yours receives your transaction from someone else first, thereby reducing the certainty of such analyses.


Is CheckSequenceVerify only a stop-gap measure? The Lightning Paper v0.5.9.2 says that CSV "would permit further
abilities, including allowing a stop-gap solution before a more permanent
solution for resolving transaction malleability. A future version of this
paper will include proposed solutions."

This means that Thunder is still vulnerable to malleability attacks since it relies on CSV as a solution.

Since the Thunder readme does not mention malleability fixes as a TODO point, I guess the Thunder authors considers it fixed.

The cited Lightning draft is from January.

CSV is not a stop-gap solution. Before you can say that, you first need to define what the problem is.

CSV solves the problem that you can't use CLTV in contracts that need a spending delay where the output itself will not be broadcast for an unknown amount of time. This is a very abstract problem, but it does occur as a primitive inside more complex constructions.

However, the current Thunder implementation uses a stop-gap solution to transaction malleability, which just happens to rely on CSV.


What challenges will bitcoin face in space? What would the challenges of transacting in outerspace be for bitcoin? What improvements need to be implemented to address these challenges? I'm particularly curious about low-earth orbit.

Biggest problem facing spaceborne bitcoin is communications latency.  Consider possible Mars colony.

Light speed imposes delay, 4 to 24 minutes.  Bad enough this is.  If miners on both Earth and Mars, each comes up with new block, possibly extends blockchain twice more, before signal from other crosses distance.  Means very long transaction confirmation time, for colonists (assuming on Earth most mining power).  Transactions fine going into local blockchains, but those blockchains not continuing.  Only when individual transaction records reach Earth (meaning lightspeed delay at minimum) does it get into chain that will more likely  continue.  Then must wait while more blocks close at ten minutes approx. each.

Now further problem appears.  High latency causing deeper depth of chains which abort.  Colonists wanting to be sure of transaction commitment. To be as sure  as six blocks deep in earth-only chain, must being nine or more blocks deep in interplanetary chain.  So now delay is lightspeed delay, plus maybe 90 minutes.  Then lightspeed delay again before news reaches Mars.

When Mars 24 light minutes from Earth, expect delay confirming Martian transactions minimum around 140 minutes.  Plus whatever network propagation delay on planet, not usually very significant.  Effect much less pronounced when 4 Minutes mars is from Earth;  Need only 7 blocks to be as sure, lightspeed delay much less.  Expect delay around 80 minutes confirming Martian transactions.

Earth mostly unaffected as long as Mars have not significant mining power.  But when real possibility is scenario of Martian blockchain accepted and extended, Earth-only transactions also take ten to thirty minutes extra for confirm.  Problem here is not knowing when Martian miner extends chain, so needs more chain depth before sure of confirmation.  Still, extra delay only about ten minutes.

Propagation delay problem goes deeper when additional colonies on Ceres, Juno, Pallas, Vesta, Jupiter Moons, &c.  Extra time taken for confirm transactions proportional to approximate diameter of sphere containing vast majority of mining power.  Adding twice lightspeed delay at least from center of mining power to location for confirmation times at location.

Extra bandwidth too.  Extra bandwidth required because of aborted blockchains.  Not significant too much in reasonable scenarios, but in extreme case scales badly, with square of distance.

Next, bitcoin client need accurate network time. Establish accurate network time require many iterations of light speed delay.  Bitcoin client not worry about.   Will be provided by operating system.  Must be provided, because MOST network clients want accurate network time.

However, if too picky about accurate, is not really possible (or at least very interesting) due to Relativity.  Time passing at slightly different rates closer and further from sun, different orbital speeds, different relative vectors, etc.  Einstein is a Meanie.

Now we have meta-problem.  Mining not really possible unless mining power on site comparable to mining power at largest other single site.  No point mining bitcoin on Martian colony, for example;  Due to lightspeed delay your work will arrive 4 to 24 minutes after you do it, and you'll be working with blockchain 4 to 24 minutes older than miners on earth.  You must work so hard that you get 8 to 50 minutes ahead of Earth's miners.  Very very hard to do.

Interesting though, that if this ever happens, then when Martian extend blockchain, suddenly it is Earth miners who are 8 to 50 minutes behind.  All considerations of delay previously working against Mars colony now work against Earth; roles reversed as long as nobody Earth get 8 to 50 minutes ahead of Martian miner.  Suddenly Earth transactions face 80 to 140 minute delays, Martian transactions clear in only 70.

Finally, effects of different mining speed various locations on hash rate.  Consider where Martian miners have 1/4 power of Earth Miners.  Due to high variability of block closures, chance of mining "center" switching to Mars and unfairly favoring Martians as above very real is.  So is chance of switching back to Earth and unfairly favoring Earthlings later. When a 2016 block mined, possible that hash difficulty could change suddenly.  Possible for hash difficulty swing back and forth unpredictably, one week to next.  Miners have maybe very prosperous week, then very dry month when no coins at all, and all go broke.  Meanwhile Miners in other location reap huge reward in bitcoin.  Depending on value of bitcoin, sudden swings in direction of money movement affect local economies, destabilize things.

But in general, value movement caused by mining would be unfair directed away from smaller locations toward major centers of mining, probably bad for development of frontiers.

Edward.


Are there any _true_ anonymous cryptocurrencies? I've been looking into Bitcoin recently and stumbled upon numerous notes how Bitcoin is not anonymous at all, or how it's only partially anonymous and you can easily trace your funds.

So, this brings us to my question: is there any true anonymous cryptocurrencies which I can use and there will be no trace left.

I am a fairly new member to the cryptoworld, so please, keep it simple. :)

The short answer is no. The long answer is split into three parts, each headed by a bold word.

I will talk about the existing privacy tools in Bitcoin.
I will talk about some pie-in-the-sky theoretical crypto which would achieve full anonymity (but which can't be done feasibly today).
I will talk about CryptoNote, its limitations, and feasible ways around it that could be implemented today, specifically those that have already been implemented by Monero.

Today, you can do a lot relative to stock Bitcoin in the direction of privacy. Two strategies I should mention are CoinJoin and CoinSwap.

CoinJoin works by effectively pasting together transactions. In Bitcoin, each transaction is a list of inputs tied (by digital signature) to a list of outputs. The transaction is valid if the total output value is less than or equal to the total input value (any difference is a "transaction fee" claimed by miners), and if every input is a valid (not already spent) output of an old transaction. CoinJoin takes transactions from two or more users, combines the input and output lists, and has both users sign the resulting transaction. The result is that the standard flow analysis idiom of "all inputs are owned by the same person" and "all outputs are owned by the same person, except maybe for a change output" is broken. CoinJoin is tricky to implement well: output values should be as uniform as possible to avoid grouping them and matching them to input values; the resulting outputs should not be spent at the same time, since this also groups them; the join should involve two distinct parties, neither of whom is some central server participating in every join. Currently there are no good tools out there which satisfy all these requirements, but there are several in development (such as DarkWallet). Keep an eye open.
CoinSwap does trustless mixing, even across different blockchains (as long as each has a sufficiently rich scripting system). It is too complex to summarize here, but the result is the same as if two parties switched private keys in person, except that there is no room for cheating. That is, coins are moved between parties but the blockchain does not see this and therefore chain analysis cannot link them — except to the extent that they look funny, so if there are almost no users doing this, their transactions can be linked on this fact alone. To the best of my knowledge, there are no tools which support this. I am developing a Bitcoin wallet for experimental features such as this that will support it, but it may be several months or years away.

Total anonymity, in the sense that when you spend money there is no trace of where it came from or where it's going, is theoretically possible by using the cryptographic technique of zero-knowledge proofs. As an extreme example, you could imagine that rather than publishing blocks mapping old outputs to new ones (which is what transactions are in Bitcoin), miners published zero-knowledge proofs that they had a valid set of transactions which, in aggregate, mapped the old set of all outputs to the new set of all outputs. You could further obscure this by having the recipient choose the destination address(es) and pass different ones to every miner. That way, only the miner who gets the block (who is probably different for every block) and the recipient knows where money is going.

In what I've described, the values of all coins would still be visible, and perhaps tracking could be done by linking similarly-valued coins. We can fix this with homomorphically-encrypted values, say.

The point of this musing is that there are no strong theoretical reasons that what you want is impossible. But I'm going to burst the bubble I just created and talk about practical problems: firstly, to do this kind of general computation is zero-knowledge even remotely feasibly, you need to use a system which has a trusted setup (in cryptographic terms, the scheme is secure only in the CRS (common reference string) model). This means that some party, the scheme's creator probably, has access to secret data which will allow them to produce false proofs, effectively allowing them to undetectably print money for all time. A recent example of such a thing is the paper SNARKs for C by Eli Ben-Sasson et. al., which provides a lot of historical context.

Secondly, even with this fatal flaw, these schemes are not all that computationally feasible. Zerocoin, now superceded by Zerocash, took this approach and needed to create serious restrictions: all coins have the same value, there is no scripting (even for multisignature transactions, I believe), and even so some serious work went into special optimizations to do whatever was left (such as hashing) in zero knowledge. For ZeroCash research is going into doing the initial setup in a multi-party computation so that no individual has the secret material needed to print coins; there would be several, and as long as even one securely destroyed their data, the currency would be safe from forgery.

However, ZeroCash's trusted setup is orders of magnitude more complex than any other MPC that has ever been done. And the most efficient MPC schemes known depend on a trusted-setup as well, so we haven't gained anything.

Having said that, we can get something weaker than total anonymity, and it looks like we can do it in a feasible way. As has been mentioned, CryptoNote-based currencies use ring signatures (contrast group signatures, which involve a trusted party) rather than plain old ECDSA signatures in the proof-of-ownership part of their transaction signature scheme. Arguably the most well-known cryptocurrency that was originally based on CryptoNote is Monero. Whilst Monero has subsequently deviated substantially from its CryptoNote origins, it still implements many of the key concepts below, and additionally improves a lot of the problem areas originally highlighted in this answer.

To understand how CryptoNote works we must first recap how Bitcoin transactions work. Essentially, in Bitcoin each transaction output has a public key associated to it (identified, though not revealed, by the Bitcoin address on the output), and to spend that output you need to produce a small script including a digital signature using this key. When everyone sees that transaction, they see that the old output(s) are spent (so they can forget about it, except as far as keeping historical blockchain data for new users) and that new unspent output(s) have been created. Ring signatures, on the other hand, are associated to an arbitrary set of public keys, and knowledge of only one is required to make a signature. CryptoNote uses this by having each transaction input be a set of potential unspent outputs of the same value, signed by a ring signature using all those outputs' associated keys. It is impossible to determine which one is the "real" one that the signer is actually spending.

You might ask, if it's impossible to determine which outputs are being spent, how can double-spending by prevented? CryptoNote solves this using a special ring signature algorithm (which is a modified version of existing signatures, so this is original cryptography and their security proof should be scrutinized — fortunately it is not too complicated) in which the real signing key has a key image associated to it, which must be published alongside the signature. This key image cannot be reversed to get the original key and deanonymize the sender, but if a double-spend is attempted, users will see that the same key image is used twice and reject the second attempt.

This provides good anonymity, but even with the improvements listed presently, this is not a zero-knowledge scheme. This means that linkability is confounded but an adversary with good analysis tools will certainly be able to glean a non-zero (literally, infinity times as much as zero) amount of information.

This is a very promising direction, and these signatures are feasible to verify by ordinary computers (though they are more difficult, so scaling will be worse than Bitcoin's), but there are some serious limitations. Fortunately, all are fixable. The following list is the result of conversations between myself, Greg Maxwell, Peter Todd, Mark Friedenbach, Adam Back and several others (who I'm sure will contact me to be listed :)), and to the best of my knowledge hasn't been published anywhere. So aspiring anonymous altcoins developers, here is a wishlist:

In Bitcoin, because transaction outputs are incontrovertibly spent, the total list of unspent outputs grows only very slowly. Nodes with limited storage are able to store this, and basically nothing else: when they see a new block, they verify it then update their list of unspent outputs accordingly. In CryptoNote this is impossible since transaction outputs are never definitely spent: there is a giant list of potentially spendable outputs, and a giant list of spent key images, and both of these grow very quickly and never shrink. Current CryptoNote implementations, except for Monero, store this all in RAM, which puts a pretty serious cap on their scalability today. One of Monero's scalability improvements is to store this set on disk in a very fast LMDB database, but the set of mixable outputs is still unbounded and is expected to grow faster than Bitcoin's comparable utxoset.

However, this can be further be improved by having users store only the outputs whose keys they own (plus some extras for anonymity) and only a subset of spent key images, which I will describe. The set of outputs would be stored in an insertion-ordered Merkle tree (so a user storing almost none of the tree can easily verifiably append new outputs, but can't detect duplicates, which is fine). The set of images would be stored in a image-ordered Merkle tree (so a user storing almost none of the tree can easily add a new key image and verify that it didn't exist before, given a proof of insertion, which is basically a path from the new node to the root of the tree, along with the siblings of each node along the way). To spend an output, the user provides a ring signature including the output, with appropriate key image and proof-of-new-insertion.

Note that to produce a proof of insertion for the new key image, the user needs to store all its neighbors in the key image tree. Since key images are random-looking, how can this be done without storing the whole thing? The answer is prefix-filtering. When a user creates a new key, he creates one whose first 10 bits (say) are a specific ten-bit sequence that all his key images will have. He stores every key image that starts these ten bits so that he can produce proof-of-insertion of such images. The result is a reduction in anonymity (by a factor of $2^{10}$) since everyone will know that nearby key images are more likely to be owned by the same person than are far-away ones, but a corresponding reduction in storage requirements (by a factor of $2^{10}$) and an increase in key generation time (since on average $2^{10}$ keys will need to be generated before one with the right prefix comes along). This is a tradeoff that every user will have to make.

Peter Todd has suggested choosing a new prefix every few months or years, and retiring those in which every known key image has been used. This gets more privacy for the storage hit than simply decreasing the prefix length, since two key images in different prefix sets don't reveal their common owner.

With ring signatures, the anonymity set is only as large as you make it, probably just two or three potential keys per signature.

We can improve this to effectively CoinJoin all transactions in each block (with the caveats that (a) miners can deanonymize the CoinJoin, reducing anonymity to the smaller set provided by the ring signatures, and (b) it is possible to miners to detectably cheat, so there is a small window after mining in which block content might be invalidated by revealing its cheating, which increases complexity) (the complexity hit is because it is important that the block content, not the block itself, be invalidated, since otherwise miners could deliberately cheat then reveal the cheating later, giving them a large window in which everyone else is mining a bad chain). The exact scheme is described at the very top of this IRC log.

(The same security can be provided with fancy cryptography, specifically one-way aggregatable signatures ("just the math" by Greg Maxwell), which depends on pairing-based cryptography, which is slow and requires new security assumptions that make some people uncomfortable. The exact way these would be used is described from 21:24:58 onward in these IRC logs. It is very cool that we can get the same security with no new crypto.)

With ring signatures, your anonymity can be compromised after the fact by others in your anonymity set. For example, if you spend an output using a ring signature along with two other outputs, then those other outputs' owners spend them with a single-signature ring signature (so they are incontrovertibly spent), it is now clear which of the three you used is yours, since each can be spent only once. This can be done long after the fact, which complicates analysis.

This can be fixed by requiring a minimum size of anonymity set, as Monero has done on a protocol level since March, 2016. But then we have a new problem — there are only so many outputs of any given size, and since all outputs in an anonymity set must be the same size (so the network knows how much you are spending), this might not be possible. This can be fixed by allowing outputs of any size in the anonymity set, and taking the minimum size to be the spend amount. But then given a ring signature across several outputs' keys, people will know that the output with smallest size will be the "real" one. This is because each output can only be spent once, so if you mix it with smaller outputs, you are basically shrinking it to the size of those outputs since the network will only recognize the smaller value.

All these problems are addressed in the next point.

With ring signatures, you need all potential inputs to have same (or similar) value, which greatly restricts your anonymity set.

In fact, Greg Maxwell and I found a way such that every single output can be read as any uniform distribution of outputs (so 1BTC might be spendable as a single 1BTC output, or two 0.5 BTC outputs, or three 0.33 BTC outputs, etc.) There is a single "real" distribution, but only the creator of the output knows this, and it is not revealed except in the case of leaked keys. Therefore, literally every single output size can plausibly be claimed to be created by every output, and therefore all outputs can participate in each anonymity set. This scheme is described in this writeup.

With this is place, it is feasible to set a minimum anonymity set size, preventing people from using keys with no anonymity set and compromising their own and others' anonymity. They can still do this compromise by revealing their secret key, but it's not clear to me that this is even possible to prevent.

Monero has addressed this issue in a similarly powerful manner, by implementing a scheme based on Greg Maxwell's Confidential Transactions. This novel scheme and implementation is called Ring Confidential Transactions. Because the value of outputs is no longer known under this RingCT scheme, you are no longer forced to only mix with a small subset of outputs (ie. those of the same denomination, which in CryptoNote and pre-RingCT Monero are all ^10 denominated outputs). This massively increases the potential anonymity set, and ensures that even large outputs are not "stuck" with only a handful of matching, mixable outputs.

And by the way, Dash (formerly Darkcoin) does not provide anonymity. They attached a (broken) implementation of CoinJoin to the ordinary Bitcoin client, and at least initially released it as a closed-source software. I haven't looked into Anoncoin, but the best advice I have for folks looking into altcoins is to assume they are uninteresting (and probably dangerously broken) until someone has demonstrated a concrete technical innovation.


Is extranonce sometimes necessary for blocking? Is extranonce ever necessary to find a block, e.g., in cases where exhausting the regular nonce range fails to block? Is this the rationale behind extranonce?

Yes, it's almost always necessary.  The current Bitcoin difficulty is 48,807,487,245, which means (approximately) that if you go through all possible values for the regular 32-bit nonce, your probability of finding a valid proof of work is only 1 in 48,807,487,245.  So the vast majority of times, you will exhaust all possibilities for the regular nonce, at which point you can increment the extraNonce and continue.


How do you generate a Ripple address and secret using the ripple-lib javascript library? The ripple client application can generate new accounts using the elliptic curve algorithm. Is there a high-level function to perform this task?

Yes, there's a nice script written by you.
https://github.com/stevenzeiler/ripple-wallet


What exactly did `Bitcoin-Qt -rescan -reindex` do? I spent a ton of time today trying to get Bitcoin-Qt to sync using the bootstrap.dat file and could not get it to work.  I found an answer on this forum saying to use:
/Applications/Bitcoin-Qt.app/Contents/MacOS/Bitcoin-Qt -rescan -reindex

Which seems to have worked perfectly.  Now I'm just wondering what exactly that command did to fix the problem?

-rescan likely did nothing at all. It goes through the blockchain to find transactions that are missing from your wallet. It is only very rarely needed (like when you manually changed things in wallet.dat).

-reindex throws away the block chain index and chain state (the database of all unspent transaction outputs), and rebuilds those from scratch. It is exactly like downloading the block chain again from peers, except the blocks already on disk are used.


If newly generated coin disappear, will that affect the total supply? When coins are generated they need to go down certain number of blocks to be mature and spendable, if for some reason they disapear, will that reduce the total supply of the currency, since the generation of new coins is the solving of some math and new block has uncovered some coins?

To make my question more clear, I've added this additional explanation:

What happend is that a month ago I found a block with new coins while mineing (in my case I wasn't mineing bitcoin but I think the concept applies also to other cryptocurrencies). I had problem with my internet connection and after a while I lost connection. When I solved the internet connection problem the newly generated coins that poped up were no longer there. If the coin supply is limited to 21M, then those coins should vanish forever as they were generated from the solving of the math problem that allows the creation of new coins. If that is the case then these coins should be lost forever, otherwise it means that every time a block containing coins is lost then another one is generated to keep the "total supply" 21M.In order to say that the total supply is limited there should be a limited number of blocks containig coins totaling the announced supply, in case of bitcoin 21M.

The way for newly generated coins to "disappear" is if the corresponding block is orphaned, i.e. a different branch of the block chain becomes the longest (in terms of work) which does not contain that block.  The total money supply could be affected slightly in the short term, if the new dominant branch is longer or shorter (in terms of blocks) than the previous one, and thus contains more or fewer block rewards.  It's not affected in the long run, since the money supply limit is in terms of total coins on the dominant branch.

In other words, if the orphaned block was at height 503567, then the new chain will (eventually) contain a different block at height 503567, and this block will have the same reward as the original orphaned block.  So the economy still contains the coins that correspond to the block reward at height 503567, they have just been paid to a different miner.


How to estimate the optimal fee for transaction(Segwit addresses)? I am using Segwit addresses to create transactions. As per my knowledge usage of segwit addresses allows the transactions to process fast with fewer fees as it occupies less space in the block. Could anyone explain how to calculate the fee for transactions using segwit transactions?

Legacy input size: 148 bytes (compressed)
Legacy output size: 34 bytes (compressed)
Segwit input size: 104 bytes
Segwit output size: 32 bytes

so if your transaction has two inputs and one output total size is ~ 246 Bytes, Don't forget about some more additional bytes for transaction header.


Bitcoin deposit stuck 0 confirmations high confidence/low priority hi i have a deposit stuck in the blockchain im not understanding why, its been stuck for 7 hours now without any confirmations, what is the explanation behind why the transaction is stuck?

https://live.blockcypher.com/btc/tx/e83922d98fc5f4a882e1ae04c3d1d56b1eee092a5e1caa2788f8a8fd5553460b/

Miners naturally select the  highest fee transactions to include in the blocks they create.  At 300 sat/byte, the fee you paid is too low for the transaction to be immediately included in a block.

See https://core.jochen-hoenicke.de/queue/#8h to visualize the current set of transactions waiting to clear.  As you can see, transactions at your fee level have not been reliably clearing since ~7h ago.


What is the origin of the data that the bitcoin algorithm operates on? According to the bitcoin wiki, the data used comes from calling getwork.

  getwork is a JSON-RPC defined at https://en.bitcoin.it/wiki/Getwork as "An RPC method used by a miner to get hashing work to try to solve."

After reviewing the source here: https://github.com/bitcoin/bitcoin/blob/142e604184e3ab6dcbe02cebcbe08e5623182b81/src/main.cpp#L3352 I was unable to determine the code for the GetWork method. I am mostly curious about the source of the data though. Although the bitcoin system is said to be entirely transparent, it seems to skimp on information regarding the data used.

Where/what is the origin of the data that is being worked on by the bitcoin hashing algorithm?

The proof of work that miners do is a double sha256 hash on 80 bytes of data.

Where do the 80 bytes come from?

They are build from enough data to describe the current block (and the transactions it contains) and a pointer to the previous block.

To wit:

4 bytes version number
32 bytes hash of the previous block
32 bytes Merkle root of all the transactions contained in this block
4 bytes timestamp
4 bytes current difficulty target
4 bytes nonce

These 80 bytes are concatenated and have the shit sha'd out of them until the required difficult is reached.

More info


Sync with bitcoin-qt very slow (0,01%) I have the issue that my node's synchronisation is very slow. I am 14 weeks behind and it estimates to take 12 weeks to get synced. The synchronisation rate per hour is only 0,01%.
I have a fast broadband connection and no other issues with this PC. It should be able to download the whole blockchain in a few hours. However, the average transfer rate is about 0,5 KB/s.
Any idea what the issue might be?
I am running v0.14.2 and the number of outgoing connections is 3.
I have already changed cache memory to 800 MB but that didn't change anything.

Bitcoin Core sync very slow

Bitcoin Core is capable of full sync in a relatively short period of time depending mainly on the hardware.

Most of the work done is not actually downloading the blocks, it is validating them and every transaction that they contain. It not only depends on downloading the blocks but also on the quantity and complexity of every transaction. The downloading of the blocks themselves is usually not an issue if you are connected (outbound) to several nodes. I am able to download blocks generally in forty-five seconds each (which includes the request time etc. and validation as well as the transfer) when I have been offline and am catching up on my restricted local 256Kbps link. My upload speed is low, and latency is high. At the rate of one block per forty-five seconds, it would currently take over two-hundred-and-sixty-three days to complete the whole blockchain as there are more than 506822 blocks as of writing.

From my personal experience, the initial sync actually took over five days to complete on a 2.5GHz Core i5 notebook with 4GB of RAM running Fedora with Bitcoin Core v0.15.1. For that, I used ADSL2+ and never perceived the actual downloading of the blocks to be the issue.

Performance of initial sync

Performance of initial sync largely comes down to the individual performance of your computer, provided your internet is fine.

Always use the latest release version of Bitcoin Core (includes bitcoin-qt and bitcoind) downloaded from the official site at www.bitcoin.org. An upgrade is safe and easy, just safely exit Bitcoin Core first and make a new secure backup of your wallet.dat before you upgrade.

Adjusting parameters

There are some parameters that you can look at and consider depending on your system. Always make a backup of your wallet before making any changes. The parameters can be entered at the command line or generally in your bitcoin.conf file, which you would need to exit and restart Bitcoin Core in that case to see the effect. Some things to consider that could make a difference:

I am presuming here that you are running bitcoin-qt which is the GUI version and not bitcoind.

If parameters are used in the bitcoin.conf file, omit the leading -.

-datadir= You could have your datadir on a fast drive. If you move your whole .bitcoin folder you will need to specify this parameter on the command line. Note that if you change your datadir and do not copy the .bitcoin folder over to the new location first, it will create a new wallet and begin downloading the blockchain again from the start.
-dbcache= The default for this is 450. If you have 8GB of RAM, you could easily set this to 4096
par= The default for this setting is auto, but I do not know what the automatic setting does. You could try setting this to -1 which leaves one core free.
-banscore= You could try setting this to 10 to kick off misbehaving nodes sooner.
-listen= You could temporarily set this to 0 to disable incoming connections while you get the initial sync done. Your busy node does not need the additional work.

After the initial sync, you can revert these settings to their defaults but probably leave your datadir wherever you put it.

Some of these parameters are available as options in the bitcoin-qt Settings > Options menu.

TLDR; The short answer if you want it fast is, get a fast computer, loads of RAM, a fast HDD and, fast internet. The same as anytime you want anything fast on a computer.

In the real world, and from personal experience, using an SSD increased sync speed more than 10x on my example system from the performance noted above.

Anecdotes

Real life example of varying system performance: I know someone personally who had to work on a quite large, but not extraordinarily large, Illustrator file. He opened it on his ~12-month-old upper spec Mac which usually performs great and, it was virtually unusable (slow to respond). Just for kicks he thought he would try the same file on a bog standard PC, opened it in Illustrator and it was completely normal. Some hardware/software builds have bottlenecks for some processes. The opposite result is probably true for some operations.

Also note, I have observed that exiting and restarting Bitcoin Core during initial sync seems to speed it up a bit for a while once it connects to nodes again.

Referencing again personal experience, syncing on Windows 10 64-bit seems to be orders of magnitude faster than syncing on Linux on the same hardware - even if Windows is running in Gnome-Boxes, it easily churns through 100 blocks per second during the initial stages of download.

Alternatives

If you are in serious trouble waiting to sync Bitcoin Core (a full node client) and you do not need the additional features that Bitcoin Core provides then, you may consider trying Electrum (not a full node client) which does not need to do the initial sync. On Fedora 27, getting Electrum is as simple as sudo dnf install electrum.


Bitcoin ETF - Press releases On 11th of March 2017 the U.S. Securities and Exchange Commision will decide whether the Bitcoin Exchange Traded Fund (ETF) will be approved or not.

The decision will almost certainly have massive influence on the market as soon as the first press release gets published. So the question is where the first official and reliable statement on the outcome of the decision will be published. The SEC homepage has a RSS feed for press releases. However it is not certain that the outcome will be published there first. Are there any other reliable services / official news pages where news like this may be released first?

I have a news feed from https://news.bitcoin.com/ . It sends me news articles in a pop-up window similar to Facebook. I'm assuming that they'll know as soon as the decision occurrs.
For the moment I'm in a watch and see, I'd like to buy more but at what price. The BTCs I now own were bought much lower. If the ETF decision is positive we may never see lower again, if negative or ambiguous who knows where the price will go. Down I suppose, in which case I'll buy more when it settles.


Bitcoin Core keeps crashing I have Bitcoin Core v0.11.0 installed on a machine that's running Windows XP.  After waiting several days to completely synchronize, I decided to update the bincoin.conf file.  I didn't see one where it was supposed to be, so I created a new file that had nothing but the following line it it.

txindex = 1

I saved the file in the appropriate directory and restarted Bitcoin.  Upon starting, it basically said that I had to start synchronizing from scratch (it said I was over 6 years behind).  It then crashed.

Finally, I decided to get things back to the way they were before.  I simply deleted the bitcoin.conf file that I had created, thinking that everything would go back to normal.  It didn't.  Now the program crashes every time I try to start it.  A window pops up that says

"Bitcoin Core (GUI node for Bitcoin) has encountered a problem and needs to close.  We are sorry for the inconvenience."

So what do I do now?  How do I get Bitcoin Core to stop crashing?

Thanks for your time.

%%%% UPDATE %%%%%%%%%%

As for the debug log, the first line to show an error is the following:

2015-10-30 02:56:56 Error: Couldn't open socket for incoming connections (socket returned error An address incompatible with the requested protocol was used.  (10047))

I've tried saving the bitcoin folder (the one that has the huge blockchain) as a backup and then re-installing The entire program.  After re-installation, if I let it create its own new "Bitcoin" folder, everything is fine.  Then when I try to put the blockchain folders inside the bitcoin folder, that it created, I get the error message.

I hope re-installation wasn't a mistake.  I have the blockchain.  I'd hate to have to re-acquire the whole thing again.

Either way, I really appreciate your speedy responses.  That's excellent!

I used to work at Microsoft - testing code - good luck with that - you will likely NEVER get it stable as to the machine you described - it is just too CPU and swap intensive because the XP platform cannot handle the memory the program will actually need and the hard drive - assuming you are NOT running SSD hardware - will never hold up for long


Bitcoinjs module missing issue I am trying to run this code with node and bitcoinjs-lib but I keep getting missing lib.

Any idea what am I missing?

I am on a Windows Server 2016. I try to create a P2SH address by hashing a redeemScript.

// OP_HASH160 {scriptHash} OP_EQUAL
var bitcoin = require('bitcoinjs-lib')
var bscript = require('../../script')
var types = require('../../types')
var typeforce = require('typeforce')
var OPS = require('bitcoin-ops')

function check (script) {
  var buffer = bscript.compile(script)

  return buffer.length === 23 &&
    buffer[0] === OPS.OP_HASH160 &&
    buffer[1] === 0x14 &&
    buffer[22] === OPS.OP_EQUAL
}
check.toJSON = function () { return 'scriptHash output' }

function encode (scriptHash) {
  typeforce(types.Hash160bit, scriptHash)

  return bscript.compile([OPS.OP_HASH160, e216c9ev2d0drec3xxxxxxxxxxxxxxa3b5576d9176, OPS.OP_EQUAL])
}

function decode (buffer) {
  typeforce(check, buffer)

  return buffer.slice(2, 22)
}

module.exports = {
  check: check,
  decode: decode,
  encode: encode
}

Error is this below, but couldn't find this lib 'script'.

Error: Cannot find module '../../script'
    at Function.Module._resolveFilename (module.js:547:15)
    at Function.Module._load (module.js:474:25)
    at Module.require (module.js:596:17)
    at require (internal/module.js:11:18)
    at Object.<anonymous> (C:\Program Files\Bitcoin\rob\hash2.js:3:15)
    at Module._compile (module.js:652:30)
    at Object.Module._extensions..js (module.js:663:10)
    at Module.load (module.js:565:32)
    at tryModuleLoad (module.js:505:12)
    at Function.Module._load (module.js:497:3)

Thanks!

Your file is in the directory:

…/hash2.js

while the script module is in

…/src/script.js

The relative path between these two would be ./src/script while your file is prescribing to find it in ../../script.
Once you correct the relative path, your program should be able to find the module.


Bitcoin transaction with dust output stuck I made this transaction more than 24 hours ago, and it still has no confirmations at all.

What should I do? This transaction was created by the mobile Blockchain.info wallet. At the time, it didn't warn me that transaction was problematic. However, I later noticed that one of the outputs of transaction is dust, using Blockchain.info's block explorer.

Any suggestions how to solve this issue?

In case you are interested as to the cause of this problem, I believe this is due to a 'bug' (of sorts) in the wallet you were using, in which the wallet software doesn't check to make sure it's not generating dust outputs.

Let's say you have a single 1.0 BTC UTXO (unspent transaction output) which is available for spending, and you want to send 0.99989999 BTC (slightly less than 1.0 BTC - default fee 0.0001 BTC). Then in this case, if that is the only UTXO that you have, then you cannot actually send the exact amount you requested and expect it to get confirmed in time.

      0.99989999  (Amount sent)
    /
1.0 - 0.00000001  (Change)
    \
      0.0001      (Miner fee)

You should be able to do this, since you have enough to fund the amount and pay for the fee, but the problem is that the transaction will also usually make a dust output (an output of less than 5460 satoshis). One solution is to just automatically give the extra dust to the person you are sending to. Another is to give it to the miners (by not claiming it in any of the outputs). A better solution is to use another UTXO that you own and be able to make a refund UTXO which is not dust, but this is not always possible.

In all of these solutions, no dust outputs are created. But if the wallet software just makes the transaction the usual way and give the leftover change back to yourself without checking to make sure that it's not dust, then what you saw happens and your transaction is not mined and then is eventually thrown out when it becomes old enough.

It's pretty unlikely that this bug would even be apparent in a particular transaction (about a 1 in 18,315 chance), but obviously not impossible, since you had this problem! Probably blockchain.info will apply the fix if enough people complain about it.


how does a node searches a transaction among various blocks in blockchain? Let me express what I have got to know about blockchain and where am I stuck.

Transactions are stored in the form of merkel trees inside a block. (I know how a merkel tree is made). A merkel root is calculated and stored in the block header. An SPV can ask a full node about the balance of an address (which is an encryption of public key).

Now a full node is supposed to give merkel root hash of all the blocks which contain the transactions( which contains the UTXOs which can be spent by the private key holder by unlocking its output script using its digital signature).

I want to know how does the full node get to know which blocks exactly contains those UTXOs? Does it the traverse merkel tree of each block till genesis block? or is there any way to know if the block contains those transaction or not just by utilising its merkel root.

Transactions are stored in the form of merkel trees inside a block. (I know how a merkel tree is made). A merkel root is calculated and stored in the block header.

All correct.

  An SPV can ask a full node about the balance of an address

No, it can only ask for a proof that a particular transaction was included in the blockchain. The Merkle tree has transactions as leaves, not addresses

At the protocol level there are no balances, only UTXOs. UTXOs (or "coins") are things with a value and an address, and every transaction simply "reforges" coins. It explicitly lists certain input coins which are melted down fully (destroying those coins in the process), and then constructs new coins whose value does not exceed the value of the consumed coins. Nowhere in this system does a balance appear.

  (which is an encryption of public key).

A hash, not an encryption. There is no encryption anywhere in Bitcoin (except locally to password protocol your wallet file).

  I want to know how does the full node get to know which blocks exactly contains those UTXOs?

This is unrelated. Blocks contain Merkle roots of transactions. They don't contain UTXOs.

One way to look at it is that there is an implicitly-defined set of UTXOs for each block. This set is empty for the genesis block. Every transaction processed deletes the UTXOs it consumes from that set, and adds new UTXOs to it for each output it has. As blocks are groups of transactions, they too are just aggregations of groups of UTXOs being deleted from and added to the UTXO set.

In fact, that is how full nodes work. They just maintain a database with all unspent outputs. Every block is just an authenticated "patch" of changes to make to the UTXO set.

  Does it the traverse merkel tree of each block till genesis block? or is there any way to know if the block contains those transaction or not just by utilising its merkel root.

I assume you're talking about BIP37 Bloom Filters? There is no searching involved at all. A light client tells a full node "hey I am interested in transactions to address X". Then it asks for a range of blocks. The full node reads through those blocks, and if a matching transaction is found, sends it to the light client along with a Merkle branch that proves the transaction was indeed in that block.

This approach has various downsides. First of all, it is inefficient, as it requires the full node involved to read and scan through all transactions in all blocks. Secondly, it is terrible for privacy. Even while the set of addresses the light client is interested in is hidden inside a Bloom filter, it is very hard to not make it leak what transactions a node cares about.

BIP157/BIP158 specify a more efficient and more private protocol called Neutrino to accomplish the same.


Low fee Electrum wallet transaction disappeared, now when I increase the fee it seems to be rejected as a double spend Can anyone tell me what is happening with my transactions ...

First I move some small amount and didn't see that fee was set up to low so it was "low fee" after that I've made another one and It get status "parent ....". I've read about fees and all that stuff so only thing I could do is wait, after 24h those two transactions disappeared and my balance went back to what it was before those two transactions.

I thought that they where cancelled so I made another one with higher fee. After that when I've check it at blockchain it had "double spender" tag and in electrum was "unconfirmed". After another 24h once again that transaction disappeared and my balance went back. Today I've tried to move my btc to another wallet .. made transaction with high fee and is still unconfirmed and I'm unable to see it in blockchain. Can anyone tell me what I'm doing wrong? My previous 15 transactions went without any problems ...

I faced a similar issue and found this reddit post quite helpful. I'm not a bitcoin expert but I will write an answer describing what I think is happening, since there are no other answers yet.

When you sent the first low-fee tx, it got propagated fine to the network but remained unconfirmed. When you opened the Electrum wallet a few hours later, this unconfirmed tx disappeared because your electrum wallet connected to a node which removed your tx from the mempool for being below its minimum relay fee.

So you created a second transaction, but while most nodes (including block explorers, miners) saw your transaction, they immediately ejected it out of the mempool for being an attempted double spend.

Only your first tx has any chance of going through. But if it has very low fees it might not be mined and be removed from all mempools after some time (3+ days?). So, you have to wait for the first transaction to be removed from all mempools and then create a new transaction with higher fees.

Any confirmation or correction for the above from an expert would be appreciated..

Here is what electrum documentation proposes for cases of unconfirmed transactions:
If you have made a transaction that is unconfirmed, you can:

Wait for a long time. Eventually, your transaction will either be
confirmed or cancelled. This might take several days.
Increase the    transaction fee. This is only possible for
‘replaceable’    transactions. To create this type of transaction,
you must have    enabled ‘Replace by Fee’ in your preferences, before
sending the    transaction.
Create a ‘Child Pays For Parent’ transaction. A CPFP is    a new
transaction, that pays a high fee in order to compensate for    the
small fee of its parent transaction. It can be done by the
recipient of the funds, or by the sender, if the transaction has a
change output. (Here is a step by step guide for this option: link)


What is Steem and Steemit? I recently came across Steemit, a Reddit-esque platform which seems to be running on the Steem blockchain. It looks like it is paying its users to post and curate content. However, it looks rather leery that essentially a lengthy blog post could have a pending payout of over $3900. Even taking into account the exchange rate of about 0.25 USD/Steem, that is a good pay for writing articles.

So I wonder - what's the catch? What is Steem and Steemit all about? Is the platform really paying people hundreds of dollars to post articles, or is there something fishy going on?

Steem content is rewarded based on a voting system, described well here:

https://steemit.com/steem/@smooth/voting-is-a-popularity-contest

Not that payment is made in Steem not fiat and Steem value will fluctuate over time.

The developers were able to mine a huge portion of the total Steem supply due to the relative complexity if the mining process at launch.  The fairness of the process has been a matter of debate:

"First, they did a typical instamine/flashmine/freemine scam (yes scam) where they released

(1) no compiled wallets
(2) no instructions to build
(3) incomplete and inaccurate instructions to mine

This wasn't bad enough. After the first 12 or so hours of mining, all their miners crashed, exposing that they were mining to 100 different witnesses to hide the fact that they (he) was one entity. The devs wouldn't have been caught except that their mining instructions were wrong, and no one else was mining because, even if they couldn't get the client to build, they entered mining commands that caused them to get no blocks. The devs will claim this isn't on purpose, but check the original thread. You'll see that no one mined a block when the dev's miners were down.

Then, as I have stated many times, when their miners crashed again, I mined a significant amount of steem that night in their absence. To prevent my vesting that and driving the price of vests up on them, they relaunched to ensure COMPLETE CONTROL AND CENTRALIZATION.

After the relaunch, no one would challenge them on mining because if they did, the devs would just relaunch this scamcoin again. So, no one who pays attention (and the people who have the means to procure whatever hashes they want are also the people who are paying attention), would challenge them on the hashes. As they hoped, no one did and they completely dominated the hashes for 1 week."

https://bitcointalk.org/index.php?topic=1427230.0

The "stealth" mining by developers raised a lot of Steem which are now being deployed in part to attract new users.

"At the conclusion of the pure-PoW mining phase, all of the coins from the developer mining accounts were merged into the transparent 'steemit' account, with a stated plan to sell them off to pay for development and distribute them for free to new users (each new account requires 10 STEEM funding). These actions have occurred and are transparent on the blockchain."

https://bitcointalk.org/index.php?topic=1513252.msg15232327#msg15232327


Is there a webpage showing some of the latest orphaned blocks? Blockchain.info has a couple pages about orphans, but the chart page does not agree with the list page.

My admittedly brief search for a page that shows orphans didn't turn up anything that was useful, so I'm hoping someone has one.  It seems a valuable resource for anyone involved in a trade where one side claims that the payment was confirmed and the other disagrees.

If you're looking for an absolute authoritative source that will show you latest orphaned blocks, its impossible and anyone that claims otherwise is scamming you.

Why?

The Bitcoin network is a fully decentralized peer-to-peer network, therefore in the event of a temporal split (i.e. two blocks of the same height racing in the network), a block-tip that was accepted to extend the canonical chain will not relayed to adjacent peers (though it it is stored locally for record-keeping purposes). In that sense, it is only natural that no one can tell with absolute certainty of the existence/or the non-existence of the latest orphaned blocks.

You can increase your likelihood of capturing all orphaned blocks by sampling across more nodes that you personally run. But the only way for you to get the them with absolute certainty is for you to own the entire network -- which is impossible.


Transaction in future Is there any plan to add a feature so that you can perform transactions that will be spent in the future and stored on the network? For example, I want to send some bitcoin to my kids after each N block so they will slowly receive a long time after I may already be dead. But I don’t want to send them the whole balance at once.

About the phrasing, there is really no "plan" on Bitcoin as there would be if a centralised authority governed the protocol. Instead, there are proposals and sometimes supermajority consensus for the network to deploy a proposal.
Regarding your question you can already do this today using the locktime features of Bitcoin transaction.
You can either:

Hand your child a transaction with a nLockTime set to block X (so that the transaction cannot be confirmed before the block number X).
Create a transaction which can be confirmed but cannot be spent before the block number X (CHECKLOCKTIMEVERIFY).
Create a transaction which can be confirmed but cannot be spent before N blocks are mined after your transaction (CHECKSEQUENCEVERIFY, relative locktime).

In either way (I omitted an even more involved one purposefully), you (and your child) definitely need a specific software to create and recognize this type of transaction.
Learn more (and get more links) on the Bitcoin wiki page about locktimes.


Problems with Off Line Armory I have an off line laptop that will not let me sign the transaction.  I am running Armory .92.3 and Bitcoin Core .9.2.1.
I know that I need to upgrade to a new computer.  Any thoughts how and the process would be very helpful.

Update the software first. Both Bitcoin Core and Armory. Most likely no need for new hardware.


Library for trading on major exchanges Is there a library which exposes order-book and trading functionality of major exchanges like BTC-e, Bitfinex, Cryptsy etc. ? I know these site have their own API but I wanted to re-use the code, if some sort of library is already available.

I am looking for a java library in particular.

Check out xchange on github::
https://github.com/timmolter/XChange

It works on multiple exchanges, and is written in Java.


Why did Satoshi design Bitcoin to be mineable only on specialized hardware, if the goal was decentralization? GPU-mineable cryptos are arguably more decentralized.

Did he simply miss this design aspect or does this sound fishy to you?

Bitcoin was not designed to only be mineable with specialized hardware. When Bitcoin was created in 2009, ASIC miners did not exist, SHA256d ASICs did not exist. Even GPU mining software did not exist because mining was a completely new thing. Bitcoin's difficulty was low enough for Bitcoin to be CPU mined on a laptop.

However over time, as more and more people began using and mining Bitcoin, the difficulty increased. Eventually someone figured out how to do GPU mining and wrote software for it, so Bitcoin moved on to GPU mining. Eventually someone figured out how to mine Bitcoin using FPGAs (Field Programmable Gate Arrays) so Bitcoin moved onto being mined with FPGAs. Eventually someone figured out how to build ASICs (Application Specific Integrated Circuits) for mining Bitcoin, so Bitcoin moved onto ASIC mining.

Satoshi did not intend for Bitcoin to be mined with ASICs (or even GPUs or FPGAs); it was meant to be mined on CPUs, but over time, as technology advanced, people figured out better ways to mine.


Can quantum computing improve Bitcoin mining? Would a D-Wave 2 with 512 qbits be faster than the fastest ASIC when mining bitcoins?

There are two different things here:

D-Wave machines ARE ASICs. They only solve certain particular problems. It is not really clear they take advantage of quantum effects or that they perform better than a classical ASIC working on the same problem would. In any case, they would be quantum ASICs, not general purpose quantum computers.
Mining can be improved using Grover's algorithm (http://en.wikipedia.org/wiki/Grover%27s_algorithm). When you mine, you basically have a black box that you feed with guesses and the box answers whether you have "won" the block or not. The number of possible answers is your difficulty. It is easy to produce by chance an even number, not so easy to produce a multiple of 5743.

Imagine you have a quantum computer and a classical computer each with a black box which takes the same time to check your guess. Each guess has a probability of being right equal to (#right answers)/(#total possible answers).

In a classical computer you just try one by one. On average you need about (#total possible answers)/(#right answers) tries to hit a block. In a quantum computer or a quantum ASIC implementing Grover's algorithm, you only need to use the black box (what they call the "oracle") the square root of (#right answers)/(#total possible answers) times. There are some other factors, but roughly you get a quadratic advantage.

Of course you never get this kind of fair comparison. I wouldn't really worry about quantum mining for a long time. Even if it were faster, it would probably be much more expensive. Think that you can always mine faster with more expensive equipment. You could mine faster with a supercomputer, but, at the cost they come, you better use it for something else.


Why are all redeem scripts standard, but only a few pubkey scripts? As I understand it, only transactions with pubkey scripts conforming to a certain pattern are considered "standard" and are relayed, however a script is also considered standard regardless of its redeem script.

If the limitation on standard transactions is to prevent abuse, wouldn't using it as a redeem script be equally bad?

Due to the nature of of how redeem scripts are used, there is never any reason for a redeem script to contain anything more than simple constant values.  When an output is redeemed, the redeem script is pre-pended to the encumbrance script, and run as a single script.  Consider a transaction output that is encumbered by a script that says (in pseudo code):

+ 3 == 5

This output could be redeemed by by any script that leaves a 2 on the stack after executing.  That means it could be redeemed by scripts like 3 - 1 or 8 / 4.  However, there is no reason for the additional calculation.  Since  a redeem script only need to leave 2 on the stack, we can simply use a script that just puts 2 on the stack.

This means that any redeem script that performs calculations rather than just placing constants on the stack serves no purpose, and was probably broadcast as an attempt at a denial of service.  These scripts can be disallowed without having any negative effect on the utility of the Bitcoin network.

By contrast, limiting the variability of encumbrance scripts limits what the Bitcoin network can be used for.  This is a topic that has been hotly debated, but in general, the community does not wish to limit Bitcoin's usefulness for future applications.


Bitcoin Core extremely high syncing time I'm running Bitcoin Core wallet on a gaming PC with a GTX 750ti, and 3.7ghz quadcore processor, and 16gb of ram. My internet download speed is 15 116mbps via hardwire.

But for some reason the syncing is stuck on 2 years and 33 weeks. I just ordered 100$ worth of bitcoin (which should come in 7 days) and I'm worried that it won't go through if it's still syncing.

Does anyone know what I could do to fix this? It's making me anxious.

The transaction will go through whether Bitcoin Core is done syncing or not, so don't worry about that.  You just won't see the transaction appear in the application until syncing is finished.

The Bitcoin Core GUI doesn't always give the most accurate updates on its progress.  But one way to check the progress is to open Help:Debug Window, click the Console tab, and type getinfo.  Look at the blocks number.  Then try getinfo again a minute or two later and see if the blocks number has increased.  If so, you are in fact syncing and just have to be patient.  Note that you are downloading about 60 GB of data and performing fairly intensive computations on all of it.

If you get tired of waiting, you might prefer a "thin" client that doesn't try to download and verify the entire block chain.  See Cannot access my bitcoins because my wallet is still synchronising. What can I do to spend them immediately? to learn about your options for switching.


HD wallet lost my private keys? I just had a computer crash, and when I restored the computer I upgraded from I think Bitcoin 0.17 to Bitcoin 0.19.1. The wallet was gone, so I restored an old copy of the wallet. It's an HD wallet.

When the blockchain was synced, I put in the wallet in the proper folder, but the latest incoming transaction was not displayed. I generated several new addresses, but none of them had the latest transaction. I am sure it's the same wallet because it's got all the same transactions except the last one.

I then downloaded Bitcoin 0.17, and started generating new addresses starting with 3. The addresses were completely different, and had no overlap to the addresses generated with 0.19.1 from the same wallet.dat file.

I thought the point of a HD wallet was that I only needed to back it up once?

Any help is appreciated. The HD wallet issue might affect many users, many might think they are backed up because they use HD wallets. Best of all is that someone proves me wrong.

You can try this, close core and temporarily add these to your config file in the data directory (create a bitcoin.conf file if you didn't have one).
Code:

addresstype=p2sh-segwit

changetype=p2sh-segwit

keypool=5000

(delete them later if this didn't worked)
That will force your wallet to create 4000 more "P2SH Wrapped SegWit" receiving and change addresses to your wallet's keypool.

Then open Bitcoin core, open console (Window->Console), and type getaddressinfo '3your-missing-addressxxxxxxxx'
If the value of "ismine" is "true", you've restored that address and it's beyond the default keypool (1000 receiving/change).

This worked. Solution found here:
https://bitcointalk.org/index.php?topic=5244862.msg54344316#msg54344316


If I have 51% of the capacity of the entire network, can I mine absolutely all the blocks faster than the network? I'm really wondering can I mine absolutely all the blocks in the network faster than rest miners with their 49% hashing power not for the purpose of conducting double-spend attack?

Can you mine absolutely? No. If you have 51% share of the network hash rate then the probability (not certainty) that you will mine the next block is 51%. It is theoretically possible that you may never find a solution to the block ever. However, if you continue to mine on the blocks that only you generate, then practically you can build a chain that consists entirely of the blocks that you mine after the forking point.


Is it possible to talk to bitcoin RPC API with Javascript and WITHOUT using a node server? I am planning on building a Wallet and want to know if I can hook something like an Electron native JavaScript app to Bitcoin RPC without running node.js for the server calls, so using something like AJAX or XMLhttprequest.

It is possible? Yes definitely!

Is it secure and smart to do? NO!

Anyone can see the password of your bitcoin node and thus steal your funds.

You will be hacked in no time.


verification of wallet to be verified To have btc transferred into a wallet does it need a certain amount of btc in the wallet for it to be verified. Does this amount depend on total btc to be transferred

No,
It is normal to be able to receive money into an empty wallet. Anyone who says otherwise is a thief trying to trick you and steal your money.
Wallets are not verified in any way by the Bitcoin network. Again, anyone who says otherwise is probably a confidence trickster trying to fool you into giving them your money.
Scammers like to use words that have some special meaning in the Bitcoin world and twist them to confuse their victims into doing what the scammer wants. In the Bitcoin world transactions are verified but not wallets. You can use Bitcoin without using any trusted third party such as a bank or exchange. If you do use a Bitcoin exchange they may ask questions as part of the Know-Your-Customer (KYC) laws, but this isn't verification of a wallet.
When you use Bitcoin to pay someone, your wallet creates a proposal for a transaction and sends this to a few other Bitcoin nodes (wallets etc). Those other nodes verify the transaction. The transaction has a transaction-fee included in it but the fee does not depend on the amount of money, only on the complexity of the transaction. The fee is usually very small (cents) but may need to be larger (a few dollars) when the Bitcoin network is very busy.

If you suspect someone might not be being completely honest with you, you can read some answers to questions here that will prepare you for some of the ways in which these kinds of thieves work:

fraud (Bitcoin)
scams (Personal Finance)


How can I import my XRP private key online to spend funds? How can I use my XRP paper wallet private key (or "private address") to send XRP to another address? I know that once a private key touches the internet, the wallet can't be used again (for security reasons). So, the only time when I'll be importing my key is when spending the funds. I have a simple XRP private key (it is not encrypted or anything) that starts with letter "s".

The phrase “paper wallet” is a slightly overblown name for a sheet of paper with one-or-more cryptographic private keys on it. At its simplest, a “paper wallet” could be handwritten on the back of an envelope. It may have optional extra information, such as a public address derived from the private key. For XRP, a public address begins with “r”. Ideally, for maximum security, the private keys would be generated on a computer that's not connected to the internet.

Your example has a string of letters & numbers beginning with “s”, commonly known as a ripple secret, but more properly called a family seed. For brevity, I will call it a seed.

A software wallet can convert this seed into a private key (and also a public address). If you enter the seed into a software wallet on an internet-connected computer, you will have a hot wallet. But you obviously care about security (since you're holding a paper wallet…), so perhaps you would prefer a cold wallet. Here are two examples of wallet software that works in both hot and cold modes (don't try them until you've read the rest of this answer):—

RippleRM's wallet (http://ripplerm.github.io/ripple-wallet/)
Bithomp tools (https://bithomp.com/tools/)

They may look like so-called ‘web wallets’, but they do all of their cryptography inside your browser. So, you can enhance your security by downloading the pages and running them directly on your computer. For true cold wallet functionality, transfer them to a computer that's not connected to the internet. The Bithomp wallet is newer & more intuitive, but RipplemRM's wallet has some interesting bells & whistles.

“But Wait!” I hear you exclaim. “How can I spend my XRPs from a cold wallet if it's cut off from the internet?” The answer is to pair it with a view-only wallet. Enter your ripple address (beginning with “r”) into either of the above wallets, but not your seed (beginning with “s”), and you will have a view-only wallet. With a view-only wallet, it's impossible to lose your funds by accident, but you can draw up an unsigned transaction. The wallet uses the internet to consult the XRP ledger and make sure your transaction is properly formed, but it's not valid without a signature. If you want the transaction to happen for real, you have to transfer it (as a file on a USB stick?) to your cold wallet. Your cold wallet is exactly the same software as your read-only wallet, except

It's running on a disconnected computer
You enter your seed into it (safe since there's no internet connection).

Your cold wallet can add a cryptographic signature to your unsigned transaction file. Then you can transfer it back (USB stick again?) to your view-only wallet and tell the view-only wallet to broadcast it over the internet. The XRP network will validate the signature against the originating address (thank to the magic of asymmetric cryptography, it does this without knowing your private key), and your transaction will be recorded forever on the XRP ledger.

Alternatively, if you like living dangerously, you can just use a hot wallet (enter your seed into wallet software on an internet-connected computer; but if using the Bithomp or RippleRM wallets it's still a good idea to run them from downloaded copies). The wallet itself will not leak your private keys if you downloaded the genuine wallet, but malware on your computer is still a risk.

You will find the BitHomp wallet easier to use (both hot and cold modes), but it's worth knowing that the RippleRM wallet starts up with a demo account (the seed is snoPBrXtMeMyMHUVTgbuqAfg1SUTb), which can be useful for learning. I guess you could try out the same demo account in both. Also, the RippleRM wallet is denominated in drops (1 XRP = 1 million drops). With either wallet, be careful not to accidentally unset your address's master private key unless you can live with the consequences.

If you had a hexadecimal private key rather than a seed, you could use it in RippleRM's wallet. If you had a mnemonic phrase rather than a seed, you could use it in the Bithomp wallet.

If you opt for cold signing, remember that malicious USB sticks are sometime planted in places where they get picked up & used by gullible people. Finally, you should not cut-&-paste the above links, because I'm a random stranger on the internet. Type them out by hand in case I'm a thief trying my luck with an IDN homograph attack.

EDIT: Here's another reason for using cold signing. Active XRP accounts hold a reserve of 20 XRPs, so if you abandon an account because you don't trust the private key, you're throwing away $6.54 at today's exchange-rate.


What's next after scrypt? I have been reading about the LiteCoin, and how it uses a hashing function (scrypt) that is not able to be mined by ASICs.  As a side-effect of this, it has been said that people with GPUs will move to Litecoin, as the ASICs take over bitcoin mining.  I'm wondering, are there any hashing functions that are resistant to GPUs as well as ASICs?  It would be nice to have a crypto-currency based on those, so I could use my CPU to do mining, without having to buy an expensive graphics card to keep up.

Let me describe when a hash function can (not) be calculated efficiently by using ASICs or GPUs:

ASICs: I'm speaking of simple in design, cheap ASICs, because in theory you can design an ASIC for every digital function. Simple ASICs are mostly designed for linear workflows. So they do not use loops (or loops with a hardcoded count), no recursion and a very limited memory requirements and local memory access (payload size is known). So the designer has to know the exact digital formulas. Imagine them as a calculator for mathematics terms (no jumps, every input/output as variable).

GPUs: They are good when it comes to small functions which are executed very often and having medium memory usage. Recursion doesn't work very well and complex, non-parallelized functions aren't handled in an efficient way.

So if you want to design a hash function that doesn't work well on either of them, use a complex function with high random memory access. Also make sure that the hash function does not contain parallel small parts (good for GPUs). Use data dependencies to ensure this. Please consider that it is always possible to build better more expensive ASICs for every function. So it's about cheap ASIC development VS complexity of the hash function.

Explanation of some used therms:

Complexity: doesn't mean theoretical complexity Here it's about the length of the description, the number of function calls / jumps and dynamic behavior (non hardcoded loop counts / memory requirements)
Recursion: a function calls itself one or multiple times, so a stack structure is required.
Data dependency: To calculate the next subresult (e.g. when using loops), you need the previous subresult (e.g. from the last loop body execution).


Why is the full blockchain required, effectively forever? I do understand that every block is validated in terms of the blocks before it by way of the previous block's hash, all the way back to the genesis block. However, could the protocol be modified such that the blockchain is a sliding window over the most recent N number of blocks? How likely is it that some block from 1 year ago later turns out to be invalid?

How likely is it that some block from 1 year ago later turns out to be invalid?

Very unlikely, but I think that isn't the problem.
The problem is, how does a new user find out the current state (UTXO set or equivalent) without having to trust other parties? Any community has dishonest people preying on it.

You cannot ignore, expire or invalidate unspent UTXO from much earlier blocks. That is someone's savings and the community wont throw their savings away or  arbitrarily take away their peers savings. To do so would undermine the credibility of the currency. Any such change would be ignored and not be adopted by the majority.


Not Getting shares but have decent Hashrate Just signed up and need help.kinda new to bit mining and am using slushes pool with guiminer and cannot get any accepted shares from my Radeon HD 6870  ,it has Hash rate of 200mh/s and 0 shares after it has ran for a day. I am also mining with my cpu and it is getting around 5mh/s and has gotten over 73 shares,Any help figuring this out would be highly appreciated.

specs:
Amd driver Catalyst Version 15.7.1
Windows 7 64 bit
Cpu Amd Phenom x6 1045T

What are you mining? If I'm still right old days 200mh/s was enough and 5ms/s also, but today should be already dead not?

It is still possible that pool didn't had luck in solving problem and you got no reward.

I just realised you wrote Slush's pool, which means you mine BTC, which means
pool has now 36.21Ph/s which is  36,210,000,000,000,000 hashes/sec
You have 205,000,000 hashes/sec  that means

(36,210,000,000,000,000/100=3,621×10¹⁴=1% ->205000000÷3,621×10¹⁴= 0,000000566%)

You got 0,000000566% of pool mine, if they will mine 100BTC, it will be 0,0000566BTC for you per day... It is still not enough per day to make transaction... Wait a month and let us know here...

With having pool not luck seems not possible since they have written:

Luck 1,7,30days : 128%, 121%, 89%


Can we leverage a popular website for mining? Is it possible to leverage a popular website and have users mine on their side for your own benefits?

Let's say you have a large website and you have an algorithm running on the front-end (Javascript for example) that uses users' browsers to mine blocks?

Is this possible?

That was possible a few years ago, when GPU's were what high end miners used. You could have a Javascript that harnessed the CPU's of your visitors for the duration of time that they were on your site.

Of course, Google noticed this theft of resources and (rightfully) marked those sites as being ridden with malware.

And to try to do it now? Even if you had Stackoverflows pageviews, I'm betting you'd end up with negligible income, and a lot of upset users.


Nxt / Ardor not downloading blockchain, it just stuck and hangs on startup at "known peers" I have a fresh install of nxt / ardor and it just hangs on "Known Peers:". I waited a few hours and nothing happens. How can one debug this issue?

Make sure your firewall allows outgoing connections on port 7874 or 6874 on testnet.

You can also try to invoke the getPeers API from the http://localhost:7876/test page with "active" set to "true". You should see a list of IPs your connected to, if you don't see anything, double check your 7874 port.


How can I download a single Bitcoin block? I just started studying bitcoin.
I would like to be able to download a single block from the Bitcoin network.
I referred to the following:
https://blockchain.info/rawblock/0000000000000000000212f7c098effbb7d814b481ead2b315f605371e47bae1?format=hex
But, it's not the size of the block I know (like 1MB).
How can I get one?

Yes, it's the whole block. The hex text is 2.5 MB. Hex has 50% efficiency, so the block is 1.25 MB.
Since SegWit, blocks can be larger than 1 MB. There's a 4 MB hard limit which is almost impossible to reach. (With the largest block to date being 2.4 MB, 4.8 MB in hex)


Deserializing merkleblock message I've been struggling the past couple of days to deserialize a merkleblock message. I'm writing a go app that uses the bitcoin rpc client to call gettxoutproof, but only need the merkle proof (array of required tx hashes needed to hash merkle root) of given transaction (want to verify the transaction in an ethereum smart contract).

So I've looked at how the serialization is defined in merkleblock.h which looks pretty straight forward. The problem i'm having is figuring out how CDataStream serializes the CMerkleBlock object, and finding the transaction hashes in the hex string.

Example:
This is the block im looking at: Testnet Block

it only contains one tx: 8148740e33df53073f55089f195c327f40e2a9c374dcc05643c60671243cc4a8

When I run the gettxoutproof command I get the following output:

0000002024ea1b7676f6ae9f2a3b639ec43e15c509a661d33d123deb3d00000000000000a8c43c247106c64356c0dc74c3a9e2407f325c199f08553f0753df330e744881f4d6715affff001d00cecafd0100000001a8c43c247106c64356c0dc74c3a9e2407f325c199f08553f0753df330e7448810101

Initially I expected to find the tx hash somewhere in that hex string, since its the only tx in the block and has to be included, but its no where to be found. Since the docs say that gettxoutproof returns a serialized, hex encoded string I thought maybe the tx hash has been hex encoded, but it isn't.
I've tried figuring this out with other blocks, that for example contain 2 transactions but have had no luck. I've looked at how CDataStream serializes the data but fail to understand it.

Would be very happy if someone could help me out!

It seems that the transaction hash and the merkle root are both serialized in the gettxoutproof, but byte-wise reverse.
As stated in the bitcoin developer reference,

  Bitcoin Core RPCs accept and return the byte-wise reverse of computed SHA-256 hash values.

So regarding your example, the hash (byte-wise)

81 48 74 0e ... 24 3c c4 a8

is contained twice in reverse in the gettxoutproof as:

a8 c4 3c 24 ... 0e 74 48 81

In this special case it is contained twice, of course, because with only one transaction the merkle root equals the according transaction hash.


How to get xpriv and xpub from keyPair with bitcoinjs-lib I have this code:

const bitcoin = require('bitcoinjs-lib');
const keyPair = bitcoin.ECPair.makeRandom({ });

Question: how do I get xpriv and xpub from keyPair

The short answer is: you probably shouldn't.

That is not a typical way to generate an xpriv/xpub. You are trying to convert a key pair to an extended key pair. The difference is the extended keys include the following (See BIP32 - Serialization Format):

4 byte: version bytes (mainnet: 0x0488B21E public, 0x0488ADE4 private; testnet: 0x043587CF public, 0x04358394 private)
1 byte: depth: 0x00 for master nodes, 0x01 for level-1 derived keys, ....
4 bytes: the fingerprint of the parent's key (0x00000000 if master key)
4 bytes: child number. This is ser32(i) for i in xi = xpar/i, with xi the key being serialized. (0x00000000 if master key)
32 bytes: the chain code
33 bytes: the public key or private key data (serP(K) for public keys, 0x00 || ser256(k) for private keys)

BIP32 standard Master Key generation goes like this:

Generate a seed byte sequence S of a chosen length (between 128 and 512 bits; 256 bits is advised) from a (P)RNG.
Calculate I = HMAC-SHA512(Key = "Bitcoin seed", Data = S)
Split I into two 32-byte sequences, IL and IR.
Use parse256(IL) as master secret key, and IR as master chain code.

With bitcoinjs-lib, a more standard approach would be:

const mnemonic = 'praise you muffin lion enable neck grocery crumble super myself license ghost'
const seed = bip39.mnemonicToSeed(mnemonic)
const node = bip32.fromSeed(seed)
console.log(node.toBase58())

'xprv9s21ZrQH143K3QTDL4LXw2F7HEK3wJUD2nW2nRk4stbPy6cq3jPPqjiChkTcaMEcjq1vG7XmEEW22S2UiSPbrzTkUeXfcwo7PzRZ4aDiRQu'

If you absolutely had to do it, technically you could (not recommended) replace the private key property of the node object with a buffer of your own private key, i.e. __d:

> const bip32 = require('bip32')
undefined
> let node = bip32.fromBase58('xprv9s21ZrQH143K3QTDL4LXw2F7HEK3wJUD2nW2nRk4stbPy6cq3jPPqjiChkVvvNKmPGJxWUtg6LnF5kejMRNNU3TGtRBeJgk33yuGBxrMPHi')
undefined
> node
BIP32 {
  __d: <Buffer e8 f3 2e 72 3d ec f4 05 1a ef ac 8e 2c 93 c9 c5 b2 14 31 38 17 cd b0 1a 14 94 b9 17 c8 43 6b 35>,
  __Q: null,
  chainCode: <Buffer 87 3d ff 81 c0 2f 52 56 23 fd 1f e5 16 7e ac 3a 55 a0 49 de 3d 31 4b b4 2e e2 27 ff ed 37 d5 08>,
  depth: 0,
  index: 0,
  network: { wif: 128, bip32: { public: 76067358, private: 76066276 } },
  parentFingerprint: 0 }
> node.__d = Buffer.from('e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855', 'hex')
<Buffer e3 b0 c4 42 98 fc 1c 14 9a fb f4 c8 99 6f b9 24 27 ae 41 e4 64 9b 93 4c a4 95 99 1b 78 52 b8 55>
> node
BIP32 {
  __d: <Buffer e3 b0 c4 42 98 fc 1c 14 9a fb f4 c8 99 6f b9 24 27 ae 41 e4 64 9b 93 4c a4 95 99 1b 78 52 b8 55>,
  __Q: null,
  chainCode: <Buffer 87 3d ff 81 c0 2f 52 56 23 fd 1f e5 16 7e ac 3a 55 a0 49 de 3d 31 4b b4 2e e2 27 ff ed 37 d5 08>,
  depth: 0,
  index: 0,
  network: { wif: 128, bip32: { public: 76067358, private: 76066276 } },
  parentFingerprint: 0 }


How do you set up Pushpool/Litecoin for windows? I am hoping someone can point me to a decent tutorial as to how to set up a Litecoin Pushpool server for windows. Im not trying to build anything big just so that my friends and I can mine together. I already have MySQL Community installed and working properly, downloaded the pushpool php files as well as the Mining Farm extras.

https://bitcointalk.org/index.php?topic=10617.0

Though the only tutorials I have seen to implements those files are for Ubuntu? Don't know how well that reflects Windows so I have been stuck.

Would be willing to donate a small amount of bitcoin, not litecoin, to anyone who can help me.

It can be done. There are windows equivalents for all of the programs you need to install.

Cron. Normally, I'd tell you to use the task scheduler, but it looks like the program you linked needs to run stuff every 5 - 8 minutes. This tool seems to do  what you need. You'll need Perl too.
PHP. Note that you need to use the command C:\PHP5\php.exe -f  instead of php.
MySQL.
Apache2.


Decrypting Bitcoin Core wallet with password that contains special characters I have come across a Bitcoin Core wallet that uses a special character for the passphrase. When attempting to decrypt, it accepts the password but does not decrypt part of the keys.
Is there a known bug where core fails to decrypt key pairs using special non-standard characters?
This happens for Bitcoin Core version 0.19.1 for Mac 0SX.

There have previously been issues with entering passphrases that contain non-ascii characters, however these all were related to how the terminal processes those characters before Bitcoin Core does.
If you are receiving an error message that says something along the lines of "Some keys decrypt but not all", then the wallet has been corrupted. There are no known issues that would cause that other than wallet corruption.


What is the ECC key length for OpenCoin's implementation of Ripple? http://www.reddit.com/r/Bitcoin/comments/1lubl1/wired_oped_worries_that_elliptic_curve/cc2vhos suggests that key lengths < 500 bits are no longer considered secure from the NSA.  What key length is Ripple using?

Ripple uses the same signature scheme as Bitcoin, 256-bit ECDSA keys and elliptic curve SECP256k1. It takes about 5 times more CPU effort to verify a 512-bit ECDSA signature than a 256-bit ECDSA signature and signature verification is a huge CPU load for both Bitcoin and Ripple. And, of course, keys and signatures are twice as long.


Review sites for the hardware wallets? As I understand it there are four (4) hardware wallets produced currently (2018).

Which businesses, web sites, or academic papers in the field review and compare the security of these devices?  Is there such a security review?

(Just TBC by "review" I don't mean, "this one is a nice color" etc. - security review.)

I've never heard of a site that has done an in depth review of the security of these devices. The common point of difference on the hardware security is this: 'The TREZOR is essentially a small computer while the Ledger Nano S uses two secure elements/chips."
Otherwise, a lot is the same for other hardware security such as no WiFi or Bluetooth.


Which of the open-source Bitcoin clients has the most thoroughly commented source code? Learning from a source code is very useful at times, but it is a pain if the code is not commented well. Which of the open source Bitcoin software have the most thoroughly and understandably commented source code? That is, if someone wanted to understand how the main client, miner, pool or other Bitcoin software works, which projects should one look at?

I remembered that I had seen answer to that question somewhere, after searching a bit I found it here.

Check out BitCoinJ (a from scratch bitcoin implementation in Java) and
BitCoinSharp (a C# port of BitCoinJ). They are not full
implementations yet, but they are very far along and can do most of
the tasks of a bitcoin client.
No matter what language you plan to create your implementation in,
looking at these is very valuable because they are very thoroughly
commented and much easier to understand than the official C++ client.

weird, because it's the answer to your other question.


Multi-currency wallet api I need a api or an application that can generate and handle (send/receive and so on...) multi currency wallet.
For an example: It can generate dogecoin address, bitcoin address, litecoin address, peercoin address and so on... and handle them. Like send/receive/check balance.

I am developing an open source wallet that handles multiple currencies and stores the keys in a deterministic key chain (BIP44).

It is currently on Android but it is written in am modular way so that the core library could be used in any java application. The library is based on a slightly modified Bitcoinj and for the blockchain queries it uses Electrum servers. It supports BTC, LTC, DOGE and in beta PPC, DRK, RDD and I am adding now NuBits.

Check out the repo from here: https://github.com/Coinomi/coinomi-android. At some point I will separate the core lib from the android app.

enjoy


I run alt19, which is a free site which offers historical trade data on a large number of altcoins in CSV format. We have data at 15 minute, 1 hour, and 1 day increments.

http://alt19.com


What are some of the proposed ideas to why the Bitcoin dropped to sub $400 in the end of summer 2014? Having seen that BTC was around $600 early summer of 2014 (May-July). It is currently almost 50% of that value. I read many varying reports of the cause of such a big drop.

Can someone give a list of the main proposed ideas of this big drop in price?

Some possible reasons I read:

Merchant adoption through payment processors

While merchant adoption is growing, it is currently mostly through payment processors, hardly any merchants keep a significant portion of their bitcoin earnings. With the broader selection of things to spend bitcoins on, more people are shopping with bitcoins, yet, not necessarily replenish their holdings. This creates a downward pressure on the markets.

Retailers first, suppliers lagging behind

And the retailers are right to immediately turn their bitcoin earnings into cash: With the current price downtrend, otherwise they would have lost significant value, more than they could have afforded on their margins. The problem is: Since retailers don't have Bitcoin holdings, I don't think there has been much request for suppliers to accept Bitcoin. – But without suppliers taking Bitcoin, there is no reason for retailers to keep them.

Stocks are doing very well

I've seen it suggested, that some early adopters with large amounts of bitcoins might be diversifying their holdings into other assets. The stock market is doing pretty well, and there were some interesting Initial Public Offerings recently.

Price is set by exchanges, yet, the big amounts are traded on Over-The-Counter markets

The Bitcoin exchanges are too small a market for the big payment processors to offload their earnings. So, instead, they sell huge amounts directly to interested parties. It has been suggested, that some of those interested parties might be using their freshly acquired bitcoins to push down the price on exchanges, in order to buy more bitcoins cheaply.

We are still in the correction after the Mt.Gox hype and crash

Some think that we are still in the correction phase after the Mt.Gox hype, seeking the fair price after it was massively overvalued.

Regulatory stance still unclear in many countries

Some suggest that the Bitlicense proposal in NY could be a precedent for other US states to follow suit. Quite a few followers of Bitcoin seem to think that it would be very inhibiting to the adoption of Bitcoin in the US if that were to happen.

Mining crash

A lot of people invested a lot of money into mining equipment that is now not earning what they expected, or which they didn't even get. There might be some financial pressure on them to market more of their Bitcoin holdings than they wished in order to pay for their upkeep.

Weak Hands and Impatient Enthusiasts

The falling price is shaking out weak hands. People that bought too high and want to cut their losses. Also, some are gambling to buy back in lower. Some (younger?) enthusiasts might be getting disillusioned, because Bitcoin isn't changing the world fast enough.

Volatility is down, damping speculators enthusiasm

Volatility had been decreasing for most of the year, making it less attractive for speculators to invest. Apparently, this has changed this week with new record trading volumes on the Chinese exchanges according to Daniel Mark Harrison on Coindesk.

Just some ideas, most is gossip and AFAIK, I'm sure there are plenty more.


RPi3 bitcoind and solo mining I am setting up a Raspberry Pi 3 to be a full node and miner. I know I will probably never win a mining block. I am doing this for fun and learning.

I do not want to do a pool. I want to just do solo mining to learn how it works.

I set up bitcoind from the official bitcoin 0.13.2 git repo.

I found a cpuminer (minerd) and am setting that up.

The question I have is about the wallet address that will receive any bitcoins that get generated as a reward for mining a block.

I know that when a miner wins the mining of a block it creates a transaction in the block to receive the bit coins that are rewarded.

What I don't understand is how that wallet address gets created.

I have created my own wallet on another computer and would just like any rewarded coins for mining to go into that wallet.

I also know that you can create a wallet on the mining computer (RPi) itself. Is that required?

Please give some instructions on how to set up that mining reward address wherever it needs to be set up.

Like I said I probably will never be lucky enough to mind a block, but if I happen to get lucky I want to have a proper address set up to receive that reward.

Based on the source cpuminer has a --coinbase-addr parameter which accepts a bitcoin address (for example: ./cpuminer --coinbase-addr=1abcdef..., I believe you only need to set this.

The program checks if you have provided an address and if not then switches to "getwork" mode, unless you disabled it by adding the --no-gbt command line switch.


What has the nonaggression principle to do with bitcoin trading? In the Introductory page of the book 'Attack of the 50 foot Blockchain', the author says (in reference to Ross Ulbricht) :

  A young physics student starts a revolutionary new marketplace based on
  the nonaggression principle, immune to State coercion.

What does the author actually mean by that please?

Book author here! It's because Ulbricht subscribed to the tenets of Anarcho-Capitalism, and founded his drug market as an exercise in ideology. As it happened, the FBI didn't find this a compelling excuse.