text:
Why is the block size is not filled with transactions?
Since a miner can acquire the fees from the transactions in a block, the miner should package as many transactions as possible in a block.
However, I recently found a block (blocknum: 602297) with a relatively smaller size, whose size is only 134 kB.
More details about the block can be found in block: 602297.
Why does it not contain more transactions to earn more fees?

Miners pick transactions from the mempool which is the queue of unconfirmed transactions. When there are fewer transactions waiting than would fit into a block, the block will not be full. The miner could create more transactions themselves, but that would be only useful if they wanted to send one themselves already in the first place, otherwise they'd just be paying themselves to include useless data.
So, why are so few transactions waiting to be confirmed sometimes? The traffic in the Bitcoin network appears to have both a daily and a weekly cycle. It tends to start picking up when Europe's business day starts, and slows down a bit when the US West Coast goes home from work. Weekends tend to have less traffic altogether. Of course that is overlaid by greater trends in Bitcoin, so demand will surge during price rallies for example.

Mempool Visualization of last seven days via jochen-hoenicke.de
Additionally, the block production is probabilistic. Blocks come in random intervals roughly ten minutes in average, but that'll mean that sometimes there may be three blocks in one minute and the queue gets flushed, or no block for an hour and the queue builds.

UTXO Set Size over past year via statoshi.info
In the end, network participants should ensure that the queue doesn't flush completely. When there is little demand for blockspace, users could be consolidating their tiny pieces of Bitcoin: the unspent transaction output set grew from 50M to 64M in the past year. In a perfect world, we'd always have a backlog of consolidation transactions that we could chew through when no other transactions are waiting.

While miners do try to maximize transaction space, they can't always fill a block.
Miners usually start with a block template that contains just the coinbase transaction - that alone will net them the block reward, currently 12.5 BTC. Any transaction fees over and above that are "free" money.
When blocks are mined in quick succession, it may take miners a few seconds to a few minutes to build another maximal block with several transaction in it. While miners perform that calculation, they continue mining on a smaller block template, and update it as they find a better transaction list. If they happen to find a valid block in that timespan, they will still broadcast it so that they receive the primary block reward.


text:
How can I measure cost savings from consolidation transactions?
One of the techniques to save fees is doing consolidations. According to https://en.bitcoin.it/wiki/Techniques_to_reduce_transaction_fees: "if your usual target feerate during normal-priced fee periods is 100 nanobitcoins per vbyte and the current feerate is 10 nanobitcoins per vbyte, you could save up to almost 90% on fees by consolidating now before you next need to spend some of those inputs."
However, this is under the assumption that your coin selection strategy will only spend low value UTXO at a high fee rate (which isn't optimal to begin with).
It seems hard to measure the the cost savings because it's hard to predict when the UTXO would have been spent in the future. One way to measure the "savings" is by comparing spending the UTXOs at the time of consolidation vs at the time of spending the consolidation transaction. One can measure if the consolidation transaction was profitable. However, this metric seems misleading because those same UTXO's could have been spent sometime later under a different fee rate.
Is it impossible to have an accurate measurement of fee savings from doing consolidation transactions?

Ideally if the fee rate is always 1 sat/vB then that would be the optimal solution.

Well, unfortunately, that’s not something we can expect lately

You could simulate a wallet that did not perform the consolidations but kept the original UTXOs and see what you would have spent on fees sending and receiving the same payments at the same feerates that your actual wallet performed. Since there is an element of randomness to some wallet’s coin selection methods, you may want to repeat this random walk multiple times.
I think it would be difficult to more accurately measure the “what-if” otherwise, since the consolidation transactions inherently change the outcome of the subsequent wallet history.

However, this is under the assumption that your coin selection strategy will only spend low value UTXO at a high fee rate (which isn't optimal to begin with).

More precisely the benefit of consolidating is based on the expectation that you will need to spend multiple instead of a single UTXO at a high feerate, and consolidating them will provide you with sufficient funds in a single UTXO so you can spend the many UTXOs at low feerates and a single UTXO at high feerates which overall costs less than the multiple UTXOs at high feerates.
If you actually end up being able to create transactions at a low feerate over a longer period of time, you can save fees by just spending the UTXOs directly and leveraging the variety of amounts to create changeless transactions.
One problem that some users looking into consolidation overlook is that excessive consolidation can actually increase your cost. When I have previously implemented consolidation strategies for enterprise wallets, I recommended that they only consolidate UTXOs when they had accumulated more than e.g. 200 that were older than 2 weeks that were below their usual spending amounts. I wrote about some of our experiences in this blog post.

source: Stack Exchange

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/

sort: votes


text:
How to process refunds and ensure that after a crash you don't resend to someone?
I want to have a server running that will be processing payments and refunds.  However, I also want to ensure that should my server die, that after a restart I will continue sending out any applicable refunds without sending a refund to someone I have already sent one too. I plan on using a WAL to achieve this, but I need to know what to store in the WAL. Is it possible to know your transaction ID before submitting the transaction?
That way I could just log the ID before submitting, and if I crash, I can just check the blockchain to see if that transaction already exists or not.
This seems like it would be a common problem for payment processors, but looking at the JSON-RPC documentation it appears that you only ever get the transaction ID after submitting the sendfrom/sendtoaddress.

I suspect this can be achieved by creating a raw tx, then storing that in the WAL before attempting to send the tx.  Then, after a crash, I can verify which transactions are in the blockchain and which aren't, but I dont know if this is the best way or not.

You can check blockchain for the latest transactions of the address you are using for refunds.
Get the latest transactions of the address from the blockchain and compare those to the refunds in your system to see which ones you were able to send and which ones you weren't before the crash.

But I need a way to uniquely identify a refund.  Address+amount isn't necessarily unique, so I have no way of knowing which transactions from the blockchain match to which transactions in my outgoing queue.  Am I missing something?

No you're right. Note that this is a really extreme case. You need to have sent the coins and before you can save the transaction on your db the machine needs to crash. Checking the address works but you need to use a unique address for each refund.

Using a unique address is an interesting idea, however, how long do you wait after a crash to determine if a transaction ends up on the blockchain or not?  You could very easily end up retransmitting due to a hiccup in the transactions processing (or my network connection).  As I said above, I suspect the only safe way to do this is to store the signed raw tx in the WAL before sending and then replay it after a crash.  That way the bitcoin network prevents the double spend for me.  However, I'm not convinced there isnt an easier/cleaner way to do it.

@senecaso The transaction id is always unique, you could use that.

You could do this by chaining the refund and the transaction that you received. This way you could issue the refund as often as your system crashes without incurring the risk of returning more than you need. This is a bit tricky and you need to use the API from bitcoind but SatoshiDice has been using it successfully  to return winnings. What you do is take the output that was sent to you and spend it in a transaction that refunds the sender. Since an output can be claimed at most once, the refund will be sent only once.

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/3.0/


text:
Can't I create milions of Bitcoin addresses and wait if someone will have same one?
If Bitcoin addresses can be generated offline, then the Bitcoin network doesn't check for duplicate addresses while generating a new one. Can't I just make a script and generate milions of Bitcoin addresses and then make a profit when someone will have one of those addresses and sends bitcoins there?
How does the Bitcoin network prevent this?

Probability prevents this from happening as the bitcoin address space is 2^160 or
1,461,501,600,000,000,000,000,000,000,000,000,000,000,000,000,000 (apx)

here is a picture to put it into perspective. Ok so now you are thinking well it is quick to generate them so I will just make more. Looking at this thread How to pre-generate 100M bitcoin addresses? you can generate 770k addresses in 15 minutes so lets do the math. that is
54,168,210,000,000,000,000,000,000,000,000,000,000 (apx)

years to generate all the bitcoin addresses. get cracking.

all_licenses: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/3.0/


text:
Bitcoin-Qt is shutting down my laptop
I am running Bitcoin-Qt, and it is shutting down my laptop while trying to synchronize. I even tried on a different laptop with the same result of shutting itself down.
This situation happens while synchronizing, the CPU usage and the CPU temperature raises dramatically and the computer doesn't have any other option than shutting itself down before becoming permanently damaged. How can I fix this problem?
Here are some of the system details:
Samsung R730 laptop with

4 GB RAM
Intel Core i3 dual core processor
Arch Linux system

It's normal for the cpu usage to increase, the client has a lot of work to do when synchronizing and verifying the block chain. The temperature should increase some but not dramatically, so you may have a cooling problem with your hardware. See if the same thing happens with other cpu intensive applications. If so, this is a hardware problem and nothing to do with Bitcoin.

I had something similar happen on a cheapie vps, bitcoin-qt is a demanding program, it crashes for you because it's verifying all the transactions that ever happened with bitcoin. To lessen the load, just find a torrent/download of the block chain. Also try out a thin-client (like electrum) if you only need basic wallet functionality.

Just use the Multibit client. It doesn't download the blockchain, and is very fast.


text:
Miner seems to be stuck at receiving new blocks
I have two laptops cranking hashes for pooled mining. My Mac is set up correctly, and I see the (yay!!!) messages pretty often from the minerd.exe output.
However, the PC I have cranking never seems to get the (yay!!!) message. It keeps on doing hashes and then receiving the "Longpoll detected new block" message. I even downloaded the Litecoin-Qt wallet, let it synchronize with the system, and placed the Minerd and mining_proxy EXE files next to the Litecoin-Qt in hopes that it would be able to access the longest chain due to the effort of the Litecoin wallet's synching.
I followed the steps for a PC in Litecoin LTC mining guide, CPU.
How can I make it work?

is it because my PC is too slow that it doesnt solve the block before a new one is sent to it by the mining proxy? why is my MAC able to get the yay message every second/half a second?

Try instead GPU mining with Cgminer 3.7.2 it has always worked well for me. Using CPU on a machine only, is really not worth it.


text:
Best way for anonymous purchases (for small amounts only) with credit card or Paypal if you have Bitcoins to spend? Bitcoin-OTC? No name credit card?
Obviously if you are American or you live somewhere where you have the opportunity to just buy a Visa (or Mastercard) gift card in a store for cash: you can't go better than that. But I don't have that opportunity around my country.
So how would you pay someone (not a big amount) with credit card or Paypal if these are the only payments accepted by the merchant and you simply want to stay anonymous?
If I understand correctly, the hefty fees are if you want to exchange credit card or Paypal to bitcoin because they are reversible payments but for the other way around (bitcoin to credit card or Paypal) there shouldn't be extra fees, correct?
Is Bitcoin-OTC the place to go? What are best practices for this procedure? Is there a newbie-friendly non-techie guide to Bitcoin-OTC?
Is there such a thing as a truly legitimate no-name reloadable Visa/Mastercard or only the once-loadable gift cards are available?

Taking a quick look here: https://en.bitcoin.it/wiki/Selling_bitcoins reveals that BTC-E is capable of doing PayPal withdrawals.
I'm not sure how closely it meets your requirements, and PayPal clearly requires you to provide personally identifiable information, but it could be helpful.

There are prepaid credit card that exists you just buy them at a convenience store for cash and you can go make transaction with bitcoin-otc.
To get started on bitoin-otc try out this, it explains you how to setup your bitcoin-otc with a bitcoin address, which is simpler than Gnupg (but I like gnupg more).

OP has indicated that the prepaid credit cards are an obvious solution for Americans (and few other countries that make them so readily available) - most of the world is a tad more complicated.


text:
In case of physical wallet theft, quickest way to offload funds in wallet backup?
Assume one makes a secure online backup of their wallet and then their laptop or device that has it is stolen. For the sake of argument assume that the thief watched the user type their wallet password in somehow, or the owner kept the password in a text file or something... what is the fastest way to transfer the funds from the online backup into a new wallet?
I would imagine this would be something like a easy online service that imports a wallet so that user is not forced to use the slower default of: find computer, download client, wait forever for the blockchain sync, then transfer.

You do not need to send coin to another wallet, but you surely need them to be sent to another address (since the compromised wallet has compromised addres). What I would is go to http://blockchain.info and open a new wallet. Copy paste the first address you see, it'll be your new secure address since you just genereted it. Then import your old compromised wallet.dat to blockchain.info and then send all your coins to the address you copied (in the bitcoin client it would show as sending to self). Then you are safe if the transaction confirm since you are the only one able to use this address. You can then send those bitcoin to a new wallet.

this still depends a lot of getting a full block chain up somewhere so that you can transfer the funds. this is the delay i think someone in this situation would want to avoid

blockchain.info does not need to download blockchain it already has it.

I thought you were suggesting "import" of the wallet into a new bitcoin-qt instance, which would require resyncing. i didnt understand that you meant that blockchain.info supports importing the wallet.dat. got it now. thanks!

The debug window of the Bitcoin-Qt client provides the ability to export private keys.  Those keys can then be imported to another client, either another Bitcoin-Qt wallet or to something like Blockchain.info/wallet.

thanks. if this is the only way it would mean people concerned should go to the command line and export the wallet. I guess most wont so it might still be useful if there was a service that could input a wallet.

If this were to happen today, for instance, there are trusted individuals that can be found who would perform this service, for a fee.

finding trusted individuals would add a delay that might make such an option unusefull


text:
If I buy a bitcoin in USD who gets the cash?
Question if I buy a bitcoin @$103.89 USD as of today’s prices where does the USD payment go?  Do the funds paid in any world currency go into a pool to back the bitcoin or into the developers of bitcoin clients?  What are the IRS requirements as to the value of ones account?  The Norfed dollars where backed or made of precious metals and taken down by the federal coinage act.  The $20.00 coin is now worth about 30% more than face value, go figure.  Thanks any info would be appreciated.

Just like any other currency exchange, then you find a person/company, agree on a rate, and you get bitcoins and the exchanger get dollars/euro/whatever you have.

So... lets say someone buys a lighter from me, it cost B2, how do i cash the money in order to buy more lighters? And i don't mean only in the USA i mean in more complicate economies, with hardcore money regulations, as Venezuela or Argentina?

When you buy an ounce of silver bullion at the coin store, who gets the money?
The person who held the coin before you did.
All bitcoins are first issued to miners. From there, miners use those coins for trade or exchange.  So when you buy a bitcoin with cash, you are buying it from someone who owned it but initially it was obtained from a miner.

When I buy a gold or silver coin I have the coin with value, as silver and gold are needed to build computers and other things.  I only see the bitcoin as another fiat currency?  I still do not quite comprehend the miner aspect, what does a miner do to add value to the bitcoins?  The I.R.S. question still not answered.  Can bitcoins be held in a ROTH or IRA account?  The overall concept sounds ok however a barter system would be value for value, I trade you some food you fix my roof.  What am I missing?

Hi Stephen I can see this is a fraud as my first post has been edited by you? post as I sent here it is again

Again here was my post before it was changed by Stephen"Question if I buy a bitcoin @$103.89 USD as of today’s prices where does the USD payment go?  Do the funds paid in any world currency go into a pool to back the bitcoin or into the developers of bitcoins pockets?  What are the IRS requirements as to the value of ones account?  The Norfed dollars where backed or made of precious metals and taken down by the federal coinage act.  The $20.00 coin is now worth about 30% more than face value, go figure.  Thanks any info would be appreciated

Gold is gold, silver is silver and food is food.  I still can not see where the value in bitcoins are?  What happens if your computer is hacked?

Bitcoin is neither a commodity or a fiat currency, but has characters of both. The value is derived from the scarcity (since there will only ever be a finite amount of bitcoins, and before then there can only be so many at any given time, with no possibility of finding a new resource of them). The value is also derived from the liquidity perks that commodities and currencies have failed to offer, especially person to person, and over the internet.
If you bought a bitcoin with usd, the person you bought it from no longer has a bitcoin and would have usd instead.
For the IRS you would most likely have to report your cost basis in US Dollars, and at reporting time report a gain or a loss if you sold them for cash. In the absence of specific regulations (recognized foreign currency trading profits have a max tax rate subject to the 60/40 rule), you will use the short-term or long-term capital gains tax code. Short-term capital gains are treated as normal income and taxed in whatever bracket you are in. Long-Term Capital gains are treated in a lower max different tax bracket. Unless explicitly prohibited you can hold anything in an IRA or Roth account.......

Still the question has not been answered how was or is the bitcoin monetized ?  I have a real cool cat that I have trained to give me a high five on command.  If I brush him everyday there will be a finite amount of RARE,,,scarce cat hairs from this cat.  Are these hairs worth the same as gold, silver or bitcoins? When I dig a hole in my backyard and say goodbye to my beloved kitty are the hairs worth anything?  There are a limited amount of these hairs on the market,  $1.00 each, any takers?

what answer do you want to hear? bitcoin is currently very liquid and allows people to transfer large amounts with zero reporting requirements. There are liquidity crisis around the world and people are using bitcoins for liquidity instead of a reserve currency like gold and precious metals. People find value in that.

If you are asking about trading on an exchange, then the exchange software matches up buyers and sellers.  Since you are a buyer, it matches you up with someone that wants to sell (or potentially several sellers that add up to what you want to buy).  The sellers get the money (and usually a small part of it goes to the exchange itself)


text:
Whats the easiest way to go from BTC to GBP? Paypal solution?
Is there anyway of being able to transfer bitcoins to pound sterling to a paypal account at all? I struggle to find any solutions in this area so that I can make regular conversions. Even just to a UK bankaccount is ok, but Paypal is prefered? even if it means getting small fees as one would expect.

In the end I was able to do this by XMLgold, http://www.xmlgold.eu/, I had to do the payment as Bitcoin to USD (directly to Paypal) and PayPal then offered to convert that to GBP, it cost me $20 of my reward to PayPal, not totally sure if it was truly a great value but it saved juggling some of the money around.

I assume you are asking about how to convert your BTC into GBP.
For small quantity, you can do a direct sales at one of the many bitcoin community forum, such as bitcointalk.org (particularly, the Currency Exchange sub-forum).  There is currently an active thread on the forum, where someone is buying large quantity of bitcoin and payment via cash deposit into your UK bank account.
For large quantity, you should check out major exchanges, such as MTGOX, and receive your money via Bank Wire.
Accepting payment via Paypal and other reversible transfer services should be avoided, as the buyer can take your bitcoin and reversed the payment at a later date.

I bought bitcoin on https://bitbargain.co.uk/, not sure what it's like to sell there.

Sellers are only accepted if they are dedicated and not just once-offs.


text:
How does the getblocktemplate request rate correlate with a miner's hashrate?
What is the relationship between a miner's hashrate and the getblocktemplate (GBT) request rate?
(The question here, "How does the rate of getwork requests correlate with the hashrate of a miner?," discusses getwork, but that's outdated.)

There's no relationship. With a single block template mining software can create a limitless amount of work by modifying the extranonce, the only reason they would need to update to a new one is to include transactions that have just arrived, or when someone else has found a block. The reason GetWork rates varied was that each request was only valid for a single 2**32 nonce range, which a modern ASIC miner can exhaust in milliseconds.


text:
Does Bitcoin + mixers = Monero?
Moneropedia defines "ring signatures" as:

Ring signatures make sure individual transaction outputs on the blockchain can’t be traced. A ring signature is a group of cryptographic signatures with at least one real participant, but there is no way to tell which in the group is the real one as they all appear valid, while the key image prevents double spends. When sending a transaction, you select some random transaction outputs on the blockchain and mix those with your own “real coins”. Mixing of coins is enforced across the network, making all coins “equal”. Because every transaction output has plausible deniability on their state (spent or unspent), there are no fungibility issues with monero
To read how Monero gives you a privacy by default (unlinkability), see stealth addresses.
A group of cryptographic signatures with at least one real participant, but no way to tell which in the group is the real one as they all appear valid.

It sounds like Moreo's ring signatures are basically a way of building mixing right in. So, is Monero effectively the same as Bitcoin+mixers?

No. Monero's ring signatures draw on Monero's complete TXO set to create a larger anonymity set.
Monero's method has the disadvantage that since it is unclear which TXO were actually spent, they can never be marked as spent and therefore spent TXO  hardly ever leave the TXO set.
In Bitcoin mixers, you're actually dependent on other users also using the same mixer.

hey @Murch , could you pls elaborate on why that is a disadvantage? Blockchain bloat?

@kumarz: In Bitcoin the UTXO set has been about doubling each year for the past three years. This is with UTXO leaving the UTXO set when they are spent. In Monero, I'd expect this growth to be more pronounced for the TXO set (at similar levels of transactions), because transaction inputs don't shrink the TXO set. Other than the blockchain, the TXO set needs to be kept completely on each node to check whether inputs are valid.


text:
What is Mt. Gox's YubiKeys' "configuration protection access code"?
Does anyone know if Mt. Gox, now that they're bankrupt, has released their YubiKey's "configuration protection access code" (cf. this)? If so, we could reprogram the free YubiKeys they sent us and use them for other purposes.
Does anyone know their contact information?
thanks

This appears to be a duplicate of http://crypto.stackexchange.com/q/14809/6733

the unlock codes were leaked:
https://bitcointalk.org/index.php?topic=631044

(source)


text:
Creating my own bootstrap.dat?
Since I have been tearing down and setting up bitcoin clients a lot for some experiments lately, I was wondering whether there is a simple way to speed up the synchronization with the network. One method that comes to mind is the bootstrap.dat file distributed by some people. The problem is that the last 40'000 blocks, which are the most expensive to get and verify, are not included.
Now I was wondering how to create such a bootstrap.dat myself, from a good copy I have on another machine. Any idea?

The block files are in the same format as the bootstrap file. Their format is really simple: just concatenate all blocks after prefixing them by the network number (to avoid mixing the testnets) and the block length.
[network number] [length] [block header] [block transactions]
[network number] [length] [block header] [block transactions]
[network number] [length] [block header] [block transactions]
... repeat for all blocks

To create a bootstrap file, all you need to do is to just grab the data from blk00001.dat up to your last block file (here that's blk000054.dat) and put all of it in the bootstrap.dat file, preferably sorted so that it can just import them all in one go without having to swap blocks.
I think you might even be able to just concatenate the block files themselves, as they are already in the right format, and the format supports concatenation.

Didn't know of this functionality, makes me wonder what's the point of these files since you can always download an archive with all blkXXX.dat files and uncompress it at the appropriate directory, getting exactly the same results except without the renaming to ".old" at the end :-S

Note: this is no longer a preferred method. Concatenating the files together will cause issues with orphan branches. See Peter Josling's answer below.

Bitcoin Core contains a tool to do this properly (filtering out any orphan blocks, putting everything in the correct order — which will work a lot better than just concatenating the block files. It's documented in its own README, here: https://github.com/bitcoin/bitcoin/tree/master/contrib/linearize
In short:

Launch Bitcoin with an rpcuser and rpcpassword set in your config file, with the correct location as per https://en.bitcoin.it/wiki/Running_Bitcoin#Bitcoin.conf_Configuration_File
Checkout the Bitcoin source from Github and cd to contrib/linearize.
Copy example-linearize.cfg to linearize.cfg and update it with your rpcuser/rpcpassword values, along with the maximum block height you want to output (max_height), and the path to your data directory (input), as well as the path to your desired output file (output_file).
Run ./linearize-hashes.py linearize.cfg > hashlist.txt followed by ./linearize-data.py linearize.cfg.

After spending a HUGE amount of time on this issue, Peter Josling's answer needs upvoting more. Concatenating the files from a node without sanitizing them leads to unexpected results, such as the syncing client jumping to network download after an orphan branch is detected. My rep will not allow me to comment or upvote, but anyone building a bootstrap file really needs to be aware of the pitfalls of simply concatenating the blk*.dat files

in 2019 this should be the right answer. Thank you

 From Mac

Open terminal
Go to the folder where the blocks are. In this
case Bitcoin's folder (it's the same for other bitcoin forks)
cd "Library/Application Support/Bitcoin/blocks/"

Run this code that will concatenate all the blk files. Make sure to include all the numbered
blocks you find on your Bitcoin's folder. In this case there are 4
cat blk000*.dat > bootstrap.dat

Done.

Making your own bootstrap.dat is fairly simple. In windows, drop to your command prompt and use the following command.
Copy /b blk00000.dat+blk00001.dat+blk00002.dat bootstrap.dat

You'll want to keep going with the + blk*.dat files until you reach the last one. To make things easier for you, just run a batch file which can take care of adding them all without having to input each blk*.dat file. Simply copy and paste the code below into a text file and name it something like Create_Bootstrap.cmd and run it from your /blocks folder.
@echo off
setlocal enableDelayedExpansion

set BITCOINDIR=%APPDATA%\bitcoin\blocks
for /F %%x in ('dir /B/D/ON %BITCOINDIR%\blk*.*') do (
  IF NOT [!B!] == [] set B=!B!+
  set FILENAME=%BITCOINDIR%\%%x
  set B=!B!"!FILENAME!"
)
copy /b %B% bootstrap.dat

or just use "copy /b blk*.dat bootstrap.dat"

It is somewhat intuitive what files need to be copy and where once you have a full node built.  What is not so intuitive is how to bootstrap a full node before you have built your first full node. You first need to know where the files need to be placed for the various 'OSes'. I'm not sure if there are little or big endian issues with copying the raw Blockchain node files between different OSes.
Another approach is to let the protocol handle the problem. Secondary and tertiary nodes build very quickly if they a on your own high bandwidth LAN.  Just point a secondary node (by tweaking its bitcoind.conf file) to the primary node that is already built using the "connect=Your_IPv4_LAN_Address". Such builds move very quickly... You might find it to be faster than writing the ledger to a thumb drive and copying it to another computer.

authors: แจ็ค' คนเลี้ยงไก่

all_licenses: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/


text:
Which full node implementation(s) supports SegWit2x?
I'm running a full node, because I want to support the Bitcoin network, and because I'm interested in the backend mechanisms in Bitcoin.
Now, SegWit2x is approaching. I believe it's important for Bitcoin to increase the block size, so I would like to somehow support the doubling of the block size. Can I somehow support SegWit2x through my choice of full node software? If I can choose between Bitcoin Core, Bitcoin ABC, Bitcoin XT, and Bitcoin Classic: Are there any feature differences that would make those more or less supportive of the block size doubling?

As it stands, asking which one is "best" is primarily opinion based, it would be better to reword your question to ask which software is available to run

If I can choose between Bitcoin Core, Bitcoin ABC, Bitcoin XT, and Bitcoin Classic

None of these software support Segwit2x. Currently your only choice of Full node software for Segwit2x is btc1.

Thanks! A follow-up question: Am I correct in thinking that plain Bitcoin Core currently does not support SegWit2x?

Yes, Bitcoin Core does not support segwit2x.

But it says here that BTC1, Bitcoin Unlimited & Bitcoin Classic are compatible.... https://segwit2x.github.io/segwit2x-announce.html

And this is alert on the main unlimited site pointing to this statement : https://medium.com/@peter_r/bitcoin-network-upgrade-at-block-494-784-f5ca19829529 - where it says for example that: "What this means for Bitcoin Unlimited node operators: [...] No action is required from Bitcoin Unlimited node operators."

Bitcoin Core will not follow the B2x blockchain tip, as B2x requires a block exceeding Bitcoin's blockweight limit at fork height which Bitcoin Core will reject as invalid.
BTC1 is the reference implementation of the New York Agreement and thus will follow the B2x blockchain.
Bitcoin Unlimited is an implementation of the Bitcoin protocol that doesn't enforce the current blockweight limit and thus will follow the B2x blockchain.
BitcoinABC is an implementations of the Bitcoin Cash protocol and will thusly not follow the B2x chain.
I've not kept up to date on Bitcoin XT and Bitcoin Classic. It seems that today the former is an implementation of the Bitcoin Cash protocol and the latter may be following Bitcoin but allowing a higher blockweight.


text:
Sent Bitcoin Cash to a Bitcoin segwit address by accident on my Ledger Nano S
Stupid but I sent bitcoin cash to a bitcoin segwit address I own on my Ledger Nano S. They are not shown in either wallet. Did I lose them or is there a way to get them back?

It is in principal possible to get them back, but the danger lies in the fact that as soon as you broadcast your new transaction to get them back anyone can change the receiving address, hence steal your Bitcoin Cash coins.
Bitcoin Cash interprets the outpoint which contains your coins as a P2SH. To spend from it you must provide a redeemscript that hashes to image in the P2SH after which the script itself is interpreted and must also validate.
In your case though the redeemscript is a Segwit redeemscript of the form 0014{20-byte-key-hash} (https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#P2WPKH_nested_in_BIP16_P2SH). Since Bitcoin Cash does not understand Segwit, it will evaluate it as a script that simply contains a push of 0 followed by your public-key-hash and therefore is immediately considered valid.
One solution may be to create the transaction that spends this outpoint by simply providing this redeemscript, but instead of broadcasting it to the whole bitcoin cash network somehow give it to a miner directly that does not broadcast the transaction but only includes it in its block...


text:
Why is it safer to keep your bitcoins offline than online on Coinbase?
I'm trying to think of a good way to store my bitcoins somewhere but I can't really think of a way to do it without
1) having something physical (eg. USB key) that can get lost or destroyed
2) having some sort of password (that I can forget)
The problems with either of those things is I'm planning on leaving my bitcoins to sit for a long time so by the time I need to sell them, I may not be able to remember all the details.
I was thinking maybe I should just leave my coins on Coinbase. At first that sounds more risky giving my coins for somebody else to manage, especially given what happened to Mt Gox.
However, whilst cryptocurrency is kind of like the wild west, Coinbase is a legitimate company. They're also fully insured so if they do get hacked, it doesn't sound like I would be on the hook for any loss. In addition, accessing the coins requires two factor authentication and furthermore, they have my identification details. So these features protect me against me losing access to my own coins.
So please explain why it is safer to keep my own coins offline where I would have to manage and implement my own security instead of just keeping it on CoinBase where they have professionally implemented security, contingencies for if I lose my credentials and where my coins are fully insured?

Let's assume you keep your bitcoins on the exchange for 5 years. If the company behind the online wallet goes bankrupt, is hacked, or is malicious, you lose your bitcoins. If you kept them on a hardware wallet and kept the mnemonics in another, safe location, you can still recover them in case of fire, disaster, turmoil.
Mt.Gox taught us that trusting in another's private keys for your holdings is not a good idea. Many of the people who lost hard in that episode are still waiting for a reimbursement.

An answer over here https://bitcoin.stackexchange.com/questions/53108/is-it-safe-to-store-all-my-coins-on-coinbase says "Coinbase has insurance that protects every customer against the loss of digital currencies. If digital currencies are stolen, Coinbase's insurance company will make you whole. Also, if you are a U.S. Citizen, your U.S. Dollar wallet (USD) is protected up to $250,000.00 by F.D.I.C insurance"

it also states that "This insurance policy does not cover any losses resulting from the compromise of your individual Coinbase account." So if you get hacked, you get nothing. Also, many people are not in the us. I'm pretty sure my country will insure nothing.

fair enough.  As a computer professional my concern is much greater that Coinbase will get hacked than me personally. (they are obviously a much bigger target with a lot more surface).  And what you have advocated "trusting in another's private keys for your holdings is not a good idea" puts you at the same risk regardless whether you use coinbase or any other wallet.  If you are holding the keys yourself and get hacked, kiss your money goodbye.

I guess a hardware wallet addresses this?  But compared to any other software based wallet, I don't see any disadvantage for Coinbase in this regard.

Centralization risks include:

Government shutdown/freezing of assets (would not be covered by insurance)
Hacking/insider stealing in excess of insurance coverage
Mistake moving of cold storage resulting in accidental catastrophic loss
Network/backend issue preventing withdrawals

Additional loss of value:

Nonpayment/delayed payment of forked tokens or loss of airdropped coins (either bitcoin forks not supported, or airdrop of less popular ethereum-based tokens such as the OmiseGo airdrop which was not credited)


text:
How to get history trades of last 10 days from Bittrex using Bittrex API?
I want to know how to programmatically get history of trades for period - last 10 days from Bittrex? I saw bittrex API, but using function getmarkethistory I can get only last 200 trades items. But I need to calculate volume buy and volume sell separately for last 10 days and I can't find functions in bittrex API that can help me do this. I saw coinmarketcap.com and bitcoinwisdom API, but I didn't find any solution for this task. Can anybody help me? Thanks.

Do you mean your own trade history, or trade history for a specific cryptocurrency?

I have tried to do the same, and as far as I know it is not possible. The best solution may be to start today, and in 10 days you will have 10 days worth of trades :)

You can't do it directly from the Bittrex API. You can get raw trades from an API like Cluedex. They also offer OHLCV data if you don't want to calculate that yourself.

You can get the market history using "GetTicks" from the v2 API (warning: v2 is still in development so the only documentation that exists is unofficial).
import requests
import time
nonce = time.time()
r = requests.get("https://bittrex.com/Api/v2.0/pub/market/GetTicks?marketName="BTC-ETH&tickInterval="day")
print(r.json()["result"][0]) # data for 2015-08-14
print(r.json()["result"][-1]) # gives today's data


text:
Attack vectors for difficulty retargeting with BCH and BTC?
Since the existence of BCH, miners can now switch chains to mine on. Assuming they mine greedily based on price and difficulty. Can the following attack happen and how could it be mitigated:
Assuming BCH has a high market cap, in parity with BTC.
Since it take two weeks to adjust for difficulty most miners would mine BCH when bitcoin difficulty is unprofitable. Then lets say 20% of miners keep mining BTC such that the difficulty adjustment is triggered 1.5 months later and re sets to 1/5 difficulty. Then, miners would jump from BCH to BTC and mine 2 weeks worth of supply in 4 days, leave when difficulty readjusts, and BTC basically dies (because most of the time blocks are solved on average every 50mins rather than the usual 10mins, causing slow confirmation times).
How can this attack be mitigated?

Great question :-)

Short answer: You can protect with money.
It is an economic problem. First, if the marketcap changes slowly, the difficulty can adopt. Now suppose the marketcap changes suddenly and miners behave rationally for the short term profit.
Since total_reward = block_reward + fee, a sufficient higher fee can attract miners. For example, if the marketcap on one side is double, then the compensation fee should be more than 12.5 BTC. This total fee may seem high, but it had actually happened. During the time lacking miners, there is 13.4 BTC in block #494045, and many other blocks with 11+ BTC. This is around $30 per transaction and people are willing to pay it! Hence, for the "protection", rich people can pay high fee, poor people can make donation transaction, and "irrational" miners can stay by losing profit.
Anyway, you cannot use the blockchain if you cannot pay a high fee. Note that the above strategy is true in both directions: A "protection" on one side is an "attack" on the other side. So the fee on both side may rise exponentially together.


text:
is bitcoind reliable when depending on it for web services?
What I mean by the title is, say If I create a service with bitcoind being used to create and store large numbers of accounts and address, is it likely to take the strain? Can I setup multiple instances of bitcoind to access information about the network or would I need to one large instance of a bitcoin daemon to handle everything?
If not is there an alternative to be used that can keep up with an expanding web service?

I think bitcoind is perfectly suitable for it, if you can securely access it via RPC.
You can easily create a separate bitcoind instance when you experience that only one instance cannot handle the load, but keep in mind that a bitcoind instance can only send coins it has the private key from, so you will have to separate all your queries into two parts, one for every instance.


text:
How can I limit bandwidth usage in Bitcoin-qt client?
I've just finished the intial blockchain download/verify in my BitcoinQt client (17 hours..) and I now see that BitcoinQt is happily eating all of my upstream bandwidth. (About 110kByte/sec on my ADSL line.)
I'm going to be applying bandwidth limits to the app using Waterroof, which should probably work --
But shouldn't there be a built-in method for BitcoinQt to be more polite about its bandwidth consumption?

If your goal is just to get a stable Bitcoin node running, and not to contribute to the network, you can add listen=0 to your bitcoin.conf file. This generally (though not always) keeps your upload bandwidth in check.
If you want to contribute to the Bitcoin network without using up too much of your own bandwidth, however, there are ways of limiting your upload speed for Bitcoin Core (Bitcoin-qt) only. Instructions depend on your OS, so what follows is a breakdown on what to do with each OS.
IMPORTANT NOTE: If you limit the bandwidth of Bitcoin Core far below your actual upload speed, it can actually harm the Bitcoin network instead of helping it. To be a responsible maintainer of the Bitcoin network, you should test your upload speed and then set your outgoing bandwidth limit to be as close to your actual speed as possible (e.g. 90%). This guide is intended solely for people whose internet connections go unresponsive due to Bitcoin Core completely saturating their upload bandwidth.
The following instructions are abridged from this article I wrote recently:
https://www.maxlaumeister.com/blog/how-to-limit-bandwidth-of-bitcoin-core-on-windows-mac-os-and-linux/

Limiting Bitcoin Bandwidth on Windows

Download and Install NetBalancer.
Start Bitcoin Core if it isn’t already running.
Run NetBalancer.
Find “bitcoin-qt.exe” in the list of running applications in the NetBalancer dialog and double-click it to change its bandwidth rules.
Under “Upload Priority” choose “Limited”, set the maximum amount of bandwidth for Bitcoin Core to use, and confirm.

You’re done! NetBalancer will now sit in the background and make sure Bitcoin Core doesn’t use more bandwidth than you want it to.

Limiting Bandwidth on Mac OS X
OS X 10.10 Yosemite and later
For OS X 10.10 Yosemite and later, there is no easy way to limit the bandwidth of a particular application, but the overall system bandwidth can be limited as follows:

Visit Apple Developer Downloads and log in with your Apple ID.
Search for “Hardware IO Tools for Xcode” and download the latest stable (non-beta) version.
Open the .dmg and double-click “Network Link Conditioner.prefpane” to install the prefpane. From now on, you can enable/disable Network Link Conditioner from System Preferences.
From the Network Link Conditioner pane in System Preferences, click “Manage Profiles”, then click the “+” button to add a new profile.
Edit the profile and add your desired maximum upload speed.
Save your edit, exit the profile manager, choose your new profile, and flip the big switch to enable the limiter.

Mac OS will place an icon in your notification tray so you remember that it’s on. Unlike the Windows/Linux solutions, this will limit the bandwidth for your entire system, so be sure to turn it off you’re not running Bitcoin Core.
OS X 10.9 Mavericks and earlier
For OS X 10.9 Mavericks you can use IceFloor to configure bandwidth rules. For 10.8 Mountain Lion and earlier, use Waterroof. Alternatively, if you want a simple way to control the overall system bandwidth limit instead of just Bitcoin Core, follow the instructions above for OS X 10.10 Yosemite and later.

Limiting Bandwidth on Linux

Make sure you have tc installed by typing tc at the command line. If you get “command not found”, install tc using your favorite package manager. If you're on a Debian-based distribution, the easiest way to install tc is by using apt-get:
sudo apt-get update
sudo apt-get install iproute2
Download the tc.sh script from the official Bitcoin Core repository using wget:
wget https://raw.githubusercontent.com/bitcoin/bitcoin/master/contrib/qos/tc.sh
Open the script in a text editor. Find the line that says IF="eth0" and change eth0 to reflect the network interface that your internet connection runs through. To get a list of your computer's network interfaces, use ifconfig on the command line. My computer is connected wirelessly through wlan1, so the IF line of my tc.sh looks like this:
IF="wlan1"
LINKCEIL should reflect the limit of the network interface, and most likely does not need to be changed.
LINKCEIL="1gbit"
Change LIMIT to be the maximum bandwidth you want Bitcoin Core to use (I chose 1mbit). If you don’t have any other Bitcoin Core nodes in your local network, you can delete the line that says LOCALNET. This line is there to make a bandwidth exception for port 8333 communications within your local network (i.e. not out to the internet).
LIMIT="1mbit"
Leave the rest of the commands in tc.sh alone unless you know what you're doing. The final top section of my tc.sh ended up looking like this:
#network interface on which to limit traffic
IF="wlan1"

#limit of the network interface in question
LINKCEIL="1gbit"

#limit outbound Bitcoin protocol traffic to this rate
LIMIT="1mbit"

Exit your editor and make the script executable with the following command:
chmod +x ./tc.sh
Run the script as superuser:
sudo ./tc.sh
Your Bitcoin Core bandwidth will be throttled until you reboot your computer!

Optionally, you can set the script to run every time you start your computer. Instructions for running scripts on boot will vary depending on your Linux distribution. On Ubuntu, one of the ways to run a script on boot is by adding the script to your /etc/rc.local file.
Conclusion
Hopefully this post was helpful in showing you how to limit the bandwidth of Bitcoin Core! For the full version, including images and extra information, check out the original article here.

I'm on a debian distribution and the tc package is not found. :( Halp.

@SpencerRuport Actually I did more research and I would try apt-get install iproute2 instead. I'm going to update my answer.

@MaximillianLaumeister - Awesome thanks :)

@MaximillianLaumeister - So I got it to work. Aptitude told me that iproute2 was already installed but the script was giving me an error: RTNETLINK answers: No such file or directory. I installed iproute and it worked. (Or at least, I didn't receive any errors.)

@SpencerRuport Oh thank you! I don't have an extra debian box to test on, so it's much appreciated that you're helping me correct my answer. iproute it is :)

@MaximillianLaumeister - No problem. Thanks for following up. Do you have any recommendations on how I could determine if the script is working?

@SpencerRuport I might try a command-line tool called nethogs. More info in this serverfault question.

Does limiting the bandwidth when being a full node actually hurt the network more than not being a full node at all?  Question asked here: https://bitcoin.stackexchange.com/questions/61629/as-a-full-node-does-limiting-bitcoind-bandwidth-hurt-the-network/61685#61685

You were right before. It's iproute2, not iproute on debian. The RTNETLINK error appears the first time you run the script but not on subsequent times. /sbin/tc is in the iproute2 package and not in the iproute package. The iproute package is actually empty, and simply depends on iproute2.

@ChrisMoore Thank you for that data point, I have updated the answer accordingly.

Why would the threshold under which the node hurts the network be relative to the node's network bandwith and what is meant with "far below"? Many have GiB/s fibre to the home these days but need to stay below a few hundred GiB transfer volume per month to not risk that the provider terminates the contract. This requires limiting bandwidth to a lower MBit/s range. How can this be hurtful when nodes behind an ADSL connection are ok?

You can use maxuploadtarget by adding a line like:
maxuploadtarget=5000

to the bitcoin.conf file in your .bitcoin directory.  The example above will set a daily soft upload limit of ~5GB/day.
Even better might be limiting the maxconnections with
maxconnections=25

Below is a Perl script I have written that will run on Linux, and will automatically limit the maximum number of connections (and thus bandwidth) during the day, and then once nighttime rolls around, it will remove the connection/bandwidth restrictions. This way, while you are asleep, your Bitcoin full node can be making the most of your bandwidth, and when you're awake, the full node won't interfere with your web browsing during the day.
 #!/usr/bin/perl
 use warnings;
 use strict;

 #############################################################################################################
 #Program purpose: To configure a Bitcoin full node so bandwidth use is restricted during the day.
 #
 #How it works: The bitcoin.conf file is periodically modified so that Bitcoin runs with fewer connections
 #during the day (using less bandwidth), and unlimited connections (higher bandwidth) at night.
 #
 #How to run: On Linux, run within the Bitcoin /bin directory (i.e. the directory holding 'bitcoind').
 #############################################################################################################

 #Set the path of Bitcoin's bitcoin.conf file here:
 my $path_of_bitcoin_conf_file = $ENV{"HOME"} . "/.bitcoin/bitcoin.conf";
 my $bitcoind_connection_max = 25; # The maximum number of connections for bitcoind to make during day hours.
 my $start_of_day_hour = 7; # 7 am.
 my $start_of_night_hour = 21; # 9 pm in 24 hour format.

 my $time_period_last = "hasn't been recorded yet"; #Records whether the last time check was "day" or "night".

 #Run indefinitely, configuring node bandwidth restrictions based on time of day.
 while (1) {
     my $time_period_current = night_or_day();
     #When the day becomes night or night becomes day, configure bitcoin bandwidth accordingly.
     if ( $time_period_last ne $time_period_current ) {
         modify_bitcoin_conf_file($time_period_current);
         restart_bitcoind();
     }
     else{} #Night/day hasn't changed, check again in another minute.
     $time_period_last = $time_period_current;
     sleep 60;
 }

 #Modify bitcoin.conf to limit bandwidth during the day, but unlimited during the night.
 sub modify_bitcoin_conf_file {
     my $night_or_day = shift;
     my $last_line_of_bitcoin_conf_file;
     if ($night_or_day eq "night"){
         $last_line_of_bitcoin_conf_file = ""; #No maxconnections limit at night.
     }
     elsif ($night_or_day eq "day"){
         $last_line_of_bitcoin_conf_file = "maxconnections=$bitcoind_connection_max\n";
     }
     else{die "Error, no night or day\n";}

     #Check that bitcoin.conf exists and then open it for editing.
     if (-e $path_of_bitcoin_conf_file){
         open (my $bitcoin_conf_fh, "<", $path_of_bitcoin_conf_file);
         my @bitcoin_conf = <$bitcoin_conf_fh>;
         close $bitcoin_conf_fh;
         open ($bitcoin_conf_fh, ">", $path_of_bitcoin_conf_file);
         foreach my $line (@bitcoin_conf){
             print $bitcoin_conf_fh $line unless $line =~ m/maxconnections/;
         }
         print $bitcoin_conf_fh $last_line_of_bitcoin_conf_file;
         close $bitcoin_conf_fh;
         print "The bitcoin.conf file has been changed to $night_or_day settings ", scalar localtime, "\n";
     }
     else {
         die "Could not locate the bitcoin.conf file: '$path_of_bitcoin_conf_file'\n";
     }
 }

 sub restart_bitcoind {
     shut_down_bitcoin_if_running();
     start_bitcoind();
 }

 sub shut_down_bitcoin_if_running {
     #Check if Bitcoin is running.
     if ( bitcoind_is_running() ){
         print "Bitcoin daemon is running, trying to shut down now. ", scalar localtime, "\n";
         shut_down_bitcoind();
     }
     else{
         print "Bitcoin daemon is not running at the moment. ", scalar localtime, "\n";
     }
 }

 sub shut_down_bitcoind {
     if ( program_running("./bitcoin-cli stop", "Bitcoin server stopping") ){
         sleep 10;
         #Verify bitcoind process has stopped.
         while ( bitcoind_is_running() ) {
             print "Still waiting for Bitcoin daemon to shut down. ", scalar localtime, "\n";
             sleep 10;
         }
         print "Bitcoin daemon successfully shut down. ", scalar localtime, "\n";
     }
     else{
         print "Having problems shutting down Bitcoin daemon. ", scalar localtime, "\n";
     }
 }

 sub bitcoind_is_running {
     if ( program_running("ps -e", "bitcoind") ){
         return 1;
     }
     else{
         return 0;
     }
 }

 sub start_bitcoind {
     unless ( system("./bitcoind -daemon") ){
         print "Bitcoin server booting up. ", scalar localtime, "\n";
         sleep 30;
         #Verify Bitcoin server has fully booted.
         until ( bitcoin_server_is_up() ) {
             print "Still waiting for Bitcoin server to fully load. ", scalar localtime, "\n";
             sleep 60;

         }
         print "Bitcoin server has successfully loaded. ", scalar localtime, "\n";
     }
     else{
         print "Having problems starting the Bitcoin daemon. ", scalar localtime, "\n";
     }
 }

 sub bitcoin_server_is_up {
     #If we can get a block count, then the server is booted.
     if ( program_running("./bitcoin-cli getblockcount", '^\d{6,}') ){
         return 1;
     }
     else{
         return 0;
     }
 }

 #Call a program with argument 1, and return true if its stdout matches argument 2.
 sub program_running {
     my ($shell_cmd, $stdout_match) = @_;
     open (my $prog_call, "-|", $shell_cmd);
     while (my $stdout = <$prog_call>){
         if ($stdout =~ m/$stdout_match/){
             return 1;
         }
         else{} #Keep searching for match.
     }
     return 0; #Match not found.
 }

 #Determine if it's nighttime or daytime.
 sub night_or_day {
     my @current_time = localtime();
     my $current_hour = $current_time[2];
     if ($current_hour >= $start_of_day_hour && $current_hour < $start_of_night_hour){
         return "day";
     }
     else {
         return "night";
     }
 }

One answer mentioned in the thread is to add
listen=0

to your bitcoin.conf (which is in {User}\AppData\Roaming\Bitcoin).
This stops other nodes connecting to you to download the blockchain, hence stopping the large upstream bandwidth consumption

Not really, since you still connect to a number of nodes in the network they might also ask for blocks and transactions that you saw, but they did not yet. You do however limit the number of connections. It's a really rough cap though.

But what if you want to run a full node?

If your bitcoin client is running on a dedicated linux machine you might want to try wondershaper. It allows you to limit the bandwith of your network adapter. For instance
sudo wondershaper eth0 1024 56

limits your bandwith to 1024 Kbps download and 56 Kbps upload rate.
sudo wondershaper -c eth0

clears interface limits and brings you back to full speed.

Is there a way to restrict wondershaper to a specific process (PID)?


text:
My bitcoin-qt client connection status and uptime at http://blockchain.info/connected-nodes does not show reliably - why?
I've been running a Bitcoin-qt client (v0.7.2 beta) on my Mac for over 24 hours, with blockchain fully sync'ed.
I checked http://blockchain.info/connected-nodes at various times for my IP address. In the first few hours my IP appeared in the list. Then it disappeared for maybe 10 or 15 hours. Currently, it's back in the list, but showing a connection time of only 62 minutes, despite my network connection and IP address being completely stable, and a steady stream of inbound & outbound network traffic to/from the Bitcoin-qt client during the entire >28 hour period since I started it up.
Why would my IP show up at http://blockchain.info/connected-nodes for a certain time, then disappear from the list, then re-appear?
(It also appears that, as of this writing (2013-02-19  18:02:30 UTC,) no client on the list has a connection time of more than about 340-360 minutes. I'd expect it to be in the thousands to tens of thousands of minutes for at least some clients.)

They're not connected to the entire bitcoin network. There are about 15k nodes at the moment.

The list on http://blockchain.info/connected-nodes is just a list of nodes currently connected to that specific business' bitcoind server. It has no connection to the list of all Bitcoin nodes connected to other nodes. This hypothetical list doesn't exist anywhere, for obvious reasons, and would be 10 to 20 times longer than blockchain.info's list.
Blockchain.info's server is not authoratative in any way and has no formal connection to the "official" Bitcoin client (bitcoin-qt), the Bitcoin project, or Bitcoin.org.
As for the 360 minutes thing, Blockchain.info's bitcoind server probably prunes clients connected for 6 hours for whatever reasons that business has decided to do that. Or perhaps their bitcoind server lost its internet connection momentarily around 6 hours before you checked their connected nodes list.


text:
Can transaction validation really be free?
If you don't validate a transaction, then you are at risk for relying on it, propagating it, or including it in a block you're mining.  For this reason, the default behavior is to validate every transaction (I think!).  Otherwise there is some reliance on free transaction validation, which turns out not to be free because of the risks.  There is currently no simple way to pay for transaction validation in order to mitigate those risks.  I think there should be.
Some guys at Microsoft did some research into the idea of incentivizing transaction propagation (which would necessarily require validation for those getting paid).
I am wondering if it is worth it to develop an idea I had and present it to the bitcoin dev list.  It's called "bonded proof" and consists of a proof message which is a valid block (except that it's hash isn't low enough) and the TXOut that is the bond.  It isn't actual proof, but tentative proof that can be verified and, if found to be wrong, redeemed.  The bonded proof is signed by the bitcoin address that holds the bond. I imagine the TxOut would have to hold at least 100X a standard Tx Fee, but since it's not expected to ever be redeemed, it could hold far more just as a show of good faith.
If the proof is wrong, the maker of such a bonded proof can expect the bonded proof to be redeemed in a block.  The "transaction" that redeems such a failed bonded proof would need to include the entire proof message, plus an index into the block to identify the invalid transaction, plus a btc ("disproof") address to receive some part of the bond (say 50%).  Block validation would then have to verify that the identified transaction was actually invalid, and this would cause (say 50% of) the TxOut holding the bond to be transferred in the coinbase transaction, while the rest would go to the disproof address.
Miners would be free to ignore any such bonded proof, or to use them if and when they appear to be valuable, but I propose the following mechanism as a default:  The maker of a bonded proof ("weak") block would request a fee by making it the coinbase transaction in the weak block.  Miners would add a transaction sending that fee to the address in the weak coinbase transaction if they want to encourage the block assembler.  By default, any time a node has a brand new transaction to broadcast, it would make a weak block with the new transaction in it as long as the operator has specified a TxOut for the bond.
Selfish miners could turn this off if they wish to cheat those who assemble these blocks, just as they are already doing (probably because it's difficult not to) to those who propagate transactions.  I suspect behavior would be better than that.  Thousands of people have run full nodes without compensation, and this just makes it easier to reward them, and offload to them the time-consuming validation step, which they are doing anyway (by default).
Furthermore, non-mining nodes would have an incentive to validate these weak blocks in order to find an invalid transaction (root out cheaters who don't bother validating) and redeem the proof block.
The idea of bonded proof appeals to me not just in the case of weak block validation, but as a general mechanism.  It isn't called that with regards to the Lightning Network, but the idea is very similar: motivate helpful behavior while requiring that the helper stake some bitcoin on the claim that he is helping.

the default behavior is to validate every transaction (I think!): with BitcoinCore, yes, but not "client-only" (SPV)

There is currently no simple way to pay for transaction validation in order to mitigate those risks. I think there should be.

This statement is incorrect. Transactions include a fee which the miner that finds the block will get. Therefore it's in the miner's interest to include transactions and thus validate them.
Once transactions are in blocks, it's in everyone else's interest to validate for themselves and they don't run any risk doing that. (They'd run a risk NOT doing that.)
There is currently no real problem of transactions getting stuck because "it's too risky to validate". There are a few miners that mine empty blocks, possibly for this reason, but more likely because of lazyness and misunderstanding. And that will become even less of a problem every time the block-rewards halve.

You're right, if we're talking about transactions that have been confirmed, or we're talking about miners.  But if we restrict the discussion to non-miners and unconfirmed transactions, the statement is true, right?

Those nodes provide a service to the network by spending a little cpu validating and bandwidth propagating transactions. There no risk though: if you find the transaction invalid you simply drop it and ban the user that sent it. If not you propagate. If it turns out that your upstream peer finds it invalid anyway then the worst it will do is disconnect and ban you. Maybe not pleasant but if it really is a problem on your end (outdated version maybe) then it's a good sign that some human intervention is needed. Better have such a warning than not noticing it at all.

Everything for me falls into one of three categories: benefit, cost, or neutral.  Unpleasantness is always cost.  But it isn't high, which I guess is your point.  It just seems like an opportunity for there to be a tragedy of the commons when the transaction rate is higher and people don't like their cpu constantly churning, so they shut down their node.

"upstream" in my previous comment should be "downstream". - You could say that by forwarding transactions, your node is probing for feedback about the health of the network as well as it's own health. If others start refusing those forwarded transactions (banning your node), you know something is wrong (either your own node or the network). Maybe not a convincing incentive to do a lot of work, but since it's so cheap, actually smart to do anyway.


text:
What if you wanted to decrease anonymity?
My idea is to be able to build "credit" for an individual. Lenders of BTC could just use a service to check the "credit score" of a certain address of a borrower. The borrower would have to spend a year(s) using one address like a checking account, and by meeting certain criteria over time, they'd earn a higher credit rating. But this doesn't limit them to one address, only to one public address.
You'd have to data mine transactions to and from known/published public addresses of public companies or employers/employees, etc. All of this data about an address could be pulled off of the blockchain and calculated with certain weights, which means no reliance on a P2P rating system. An applicant for a loan could even provide their daily use address (like a checking account) and their offline address (like a savings account). Lenders would rely on the ADDRESS's credit rating, not the individuals.
Is it possible? Am I oversimplifying?

Seems like you are off to a good start. Credit scores work through a history of transactions, so if you tracked and traced the transactions of a particular Bitcoin account, you should be able to build a reliable "credit" score, as you already pointed out.So that part seems on track.
What I like about your system is the reliance on an address, so you should be able to maintain a degree of confidentiality.
It could also be possible to develop software to track transactions if users signed up. A bitcoin wallet service, for example, should be able to use your software (or a similar software) to plug into their own program and provide a rating service.
The one downside I see to any of these tracking/rating services, is that they could create long-term pressure to reduce the anonymity of the Bitcoin Community as a whole. Relying on an address, instead of name, like your system does could reduce these pressures.
Anyways, to answer your question, it does seem possible. Obviously developing the program itself is easier said than done. Anyways, interesting idea!

I'm running on a generally voluntaryist track here, so I'm not convinced that people should make efforts to unmask "identities" (whatever those might be, whether they are given at birth or something else adopted thereafter).  In fact, there is some evidence that decentralization of identity is already well underway and that such decentralization has been expanding for some time.  However, to address your question which is, essentially, "What if you wanted to decrease anonymity?" ~ I submit that the simplest answer to that question is this:
Provide people with a means to disclose their identity (whatever they claim it to be), and people will do so - irrespective of whether or not the technology (client, wallet technology, bitcoin service, etc.) readily reveals an individual's identity (as established from birth record or subsequent legal name change).  (Note:  In the United States, at least, the legal system does not currently recognize an IP address as equivalent to personal identity.)
The progress of decentralization of systems of trust, example(s) of which can be found in proposals similar to the bitcoin-otc concept, I submit here that credit scores as we understand them today is increasingly irrelevant, and even if developed using data freely available off the blockchain, such "credit scoring" systems will be generally disregarded in favor of decentralized reputation systems.  Note that recent proposals from Gavin Andresen, Mike Hearn, and other core developers, in a recent CoinDesk article covering Merge Avoidance, Address Reuse, and other concepts, suggest that multiple addresses will be the norm, further complicating this issue. This does not preclude or eliminate the possibility that addresses could individually or collectively develop "reputations" (in whatever context one imagines the term) over time.  Hearn's recent statements indicate his aversion to CoinJoin, which has already been implemented by blockchain.info and is likely to grow in use.  It should be understood while examining these discussions that "privacy" in the bitcoin space is currently marginal at best and is in a dynamic process of development, with certain wallets and various proposals changing 'privacy potential' over time, depending on what is developed or adopted.  However, part of the power of bitcoin (and decentralization generally) is that a central authority will not be able to be relied upon for such determinations (whether these be privacy-oriented, credit-oriented, or focused on anything else at all relative to bitcoin).  The notion of "choice" (and the extent to which various systems enable the process of choice as we understand it in transactional contexts) is critical to an understanding of how to approach these issues.
The ABIS protocol contains, in part, a proposal that people should be able to decide whether or not they disclose an identity (indicating that people should be able to decide what, if any, identity they wish to disclose) in connection with any particular transaction.
You can link to the ABIS protocol (currently in a "pre-release" alpha stage here:
https://github.com/ABISprotocol/ABIS


text:
How much Bitcoin was lost in the Jul. 2011 MyBitcoin site shutdown incident?
https://en.bitcoin.it/wiki/MyBitcoin
How much money was lost when it shut down? (You can also edit the wiki page and add this info). Best estimates of course.

Did they run off with the money but claimed they were "hacked"?

According to this speculative thread at bitcointalk.org forums, a minimum of 27,000 BTC (worth $370,000 USD at that time), with a possible maximum of 75,000 BTC, estimated.
Here's a screen cap of the first post in the thread, in case the forum later disappears:


text:
Delegating the creation of a transaction
This question might seem quite strange. but I am wondering if its possible to delegate the creation of a transaction to a third party, without having to trust them with your private key?
In the same way that with credit cards you can preauthorise a transaction, i'm wondering if its mathematically possible to do the same with bit coins. What I'm thinking of is having the client create the transaction, from the private key, and then forward the transaction to, and only to the authorising body. That way they would then hold a cryptographically secure transaction which at a later time if appropriate they could distribute to the rest of the bitcoin network.
so specifically:

Does this leave open the risk of that person double spending the same bitcoin?
Is there a mathematical window between the point when the private key is no longer required, and when the distribution process has begun.  (e.g.  adding it the current block?)
Has anyone solved this already?

Edit for clarity:
The key aspect is the ability for someone other than the person sending the bitcoin to 'hold the transaction' and at a later date to either forget the transaction (so it never left the original wallet) or to distribute the transaction, so it is accepted by the bitchain as having been transferred.
It would be required that the only trust that the sender needs to have is that the transaction holding place is trusted to either distribute or drop the transaction fairly.  In particular that they do not obtain access to transfer additional money later, or different amounts etc..

Yes this is possible, and there are a couple of clients that let you do this out of the box. Electrum is popular for this.
The purpose of the private key is that you are able to "sign" the transaction. Once the transaction has been created and signed actually anybody can broadcast it to the network.
I understand that it is even technically feasible not to use the bitcoin client but recreate a transaction, sign it and broadcast it as a string.
Edit to answer third point also in an edit from the OP: If you are suggesting that you can possibly drop off signed transactions everywhere using the same bitcoins to create a double-spend, you would also have to prevent any one of the recipients from broadcasting. As soon as the transaction is broadcast you can consider that those coins are spent, because a later transaction would be rejected. It is not therefore in the interest of the recipient to hold a transaction for you. The answer is in another function of the original code which allows escrow payments.
Localbitcoins.com operate an escrow process, I couldn't say for sure if they use the original functionality in the bitcoin code or have written it themselves, but essentially it is the same idea. Coins from your unspent balance are set aside and only released when certain conditions are met. This prevents the double-spend because once the coins are in the escrow they cannot be used in another transaction.
I think you ought to have a look at how transactions are actually constructed, as it is not as simple as saying that "I have a balance of n bitcoins and I spend x bitcoins". There is the notion inputs and outputs, spent coins and unspent coins.

sofar, this is the more complete answer as it answers 2 out of 3 of the questions.  can anyone answer about the double spending?

thanks.  I was doing a kind of thought experiment about how to solve the transactional certainty issue for spending bitcoins thats needed in physical shops.
The idea was that by scanning a QR code at the till, your phone could then ask for authorisation to send the payment request to a central server in the form of a valid, but undistributed transaction.  Likewise, the merchant would also send their payment request (and payment for the immediate processing) to the central server.  If both are received then both transactions get distributed and the merchant has the transaction confirmed

The beauty of this is that it creates a non reversible payment, unlike all card payments, and could be viable at a very low transaction cost per transaction.

I think you are over-thinking the issue - these problems are already dealt with in the standard client. The merchant would only need to be online and check their own version of the block chain (which should be up to date) to confirm the transaction is not using spent coins.

This is actually built in to the system. One can have a third party create a transaction but before posting it to the blockchain, you would still have to sign it in order for it to be valid. (Not entirely on-topic, but there's information concerning rebroadcasting raw transactions here that might appeal to you.)
To answer your questions specifically

Yes, but only if you're blindly signing transactions before sending them out. Anyone can create any number of transactions that use your bitcoin, but only the ones you sign will be valid and accepted into the blockchain.
No, the source of the bitcoins and the destinations are defined at the same time. There is no period in which coins are freely floating around that can be accessed without a private key.
I don't know of any major commercial operations doing this, but you can create raw unsigned transactions as well as sign them with brainwallet.


text:
Claim Bitcoin cash from android bitcoin app
I have some bitcoin stored in the bitcoin wallet android app
I want to transfer my inherited Bitcoin Cash (BCC) to an exchange.
The android app doesn't care about BCC.
I tried to decode a backup of my wallet to use the private key in Bitcoin ABC desktop app.

openssl enc -d -aes-256-cbc -a -in wallet_backup_file

But gibberish comes out.
Update looks like the decryption worked because I see the first text as org.bitcoin.production. The problem is that it is encoded in a protobuf format: Problems decrypting my bitcoin-wallet on android
Importing the same backup file on the bitcoin app works , and after some time I can see my funds.
How can I claim my bitcoin cash and transfer them to an exchange ?

I managed to get my private keys by using the suggested tool  https://github.com/lloeki/bitcoinj-wallet-dump after the openssl decryption. I am currently still waiting for the blockchain syncing (with -prune=30000 option). I will update with the full answer after it's done syncing

Would you be able to make a mini tutorial for those of us not particularly technical?

@tbenz9 I will try
https://coinomi.freshdesk.com/support/solutions/articles/29000013719-how-to-get-bitcoin-cash-from-many-wallet-software-services-with-coinomi (because syncing the whole blokchain is painfully slow)

The Bitcoin Wallet project recently included detailed instructions on how to extract your key pairs for exactly this purpose. In the section Recovering from protobuf wallet format, skip to the paragraph beginning with

You can also get a list of the private keys...

(Here is a historic version of that guide*, should it ever disappear)
I have now completed the process myself. Here's a summary. Note this works for backups made after 2014 (newer protobuf format). See the article above if your backup is older than this.
# pre-reqs
sudo apt install openjdk-8-jdk openjfx android-tools-adb openssl git maven

# use known version of bitcoinj - HEAD of branch release-0.14 at time of writing
git clone https://github.com/bitcoinj/bitcoinj.git
(cd bitcoinj && git reset --hard 0e30a3011c42cedfd83f2109d54dd192730dcc45)

# decrypt the wallet backup (substitute for <BACKUP>)
openssl enc -d -aes-256-cbc -md md5 -a -in <BACKUP> > /tmp/dec

# reset & sync wallet (may take some time, but was necessary in my case)
(cd bitcoinj/tools && \
   ./wallet-tool reset --wallet=/tmp/dec && \
   ./wallet-tool sync --wallet=/tmp/dec --debuglog)

# dump keys You will need to add `--password=<PIN>` if your wallet is pin protected.
(cd bitcoinj/tools && ./wallet-tool dump --wallet=/tmp/dec --dump-privkeys)

# delete your decrypted wallet
rm /tmp/dec

Thank you ! it worked. I didn't need to wait for the whole ./wallet-tool sync , I interrupted it after 5 minutes , dumped the keys (./wallet-tool dump) and imported them in Electron BCH.

For getting the WIF's from text private key dump used regex: regex to delete all lines not containing WIF ^(?!.*WIF=).*$  , regex to extract WIF values  ^.*WIF=(\w+).*$

I have the same issue. I used OpenSSL to decrypt the file, gave the correct password and got org.bitcoin.production followed by a load of protobuf-serialized gibberish.
I then processed the output using the tool mentioned here : https://github.com/lloeki/bitcoinj-wallet-dump, which appears to have worked successfully.
It gave me 271 public keys that my wallet used, that looked like normal bitcoin public keys, and 271 private keys - that were all the same and 7 characters.
So in answer to your question this tool github.com/lloeki/bitcoinj-wallet-dump works - but I'm not sure how to make sense of the output.
The output looked something like this (all values have been changed):
0 Publ: 1V5h7k
0 Priv: FYhAv34
1 Publ: 16wZac2mEc9jEtbdyGsUBeGR8YCVnJMLk4r2SXZ5k6v2HoCaoKY
1 Priv: FYhAv34
2 Publ: 16PBXd5r563xSA8m5bgRQgDGmn7wJBUoA4mfsfike2a66jzdjZU
2 Priv: FYhAv34
3 Publ: 16faRCW3znVawJis7DFnFNZTJ32F4ry5y7HEtnzPF9dKlXt6gVr
3 Priv: FYhAv34
4 Publ: 18CmUT8CTfbwLzD9PmhDlukA5s1KqJK7PTP9NxYYP5wMkeP36PJ
4 Priv: FYhAv34
.....

Anyone know how to make sense of the output? Is that format expected? I was expecting full public and private key pairs.. unless the 7 character constant is a special wallet key? I'm not familiar with wallet details..

Please delete this answer, go to https://gist.github.com, paste this answer, choose "create public gist", copy the link of the gist and paste it as a comment.

I would have commented, but I need 50 reputation.. so I can't comment on someone else's question - unless you mean comment on my deleted answer, if that is possible?

Did you try verifying your addresses on https://blockchain.info/ to check if they are valid and have transactions which make sense to you?

I checked a few, but I couldn't find any that made sense.. I will have a more thorough look. I haven't done 270 transactions though.

I have a very similar output to 0lOl0.  Were you able to figure out why the private key is only 7 characters?  And how to import it into a Bitcoin Cash wallet?

isn't there is one longer private key in the list ? That may be the one.(I just returned from vacation)

To find which public keys have balances: for p in $(bin/bitcoinj-wallet-dump exported_dump | grep Publ | cut -c10- ); do echo $p; curl -s "https://blockchain.info/address/$p" | grep final_balance; done

see answer from @Synesso . Worked for me . I didn't need to wait for the whole ./wallet-tool sync  command . I interrupted it after 5 minutes. And still worked eventhoutgh list of transactions was 0 in the dump.

Knowing your private key you can transfer/sweep your Bitcoin Cash funds into a offline wallet like Coinomi and then transfer them to an exchange.
More on the process of sweeping your funds is at How to sweep private extended key from mycellium into coinomi for bitcoin cash coins?

authors: พลธโนทัย แซ่อึ้ง


text:
How does Segwit achieve backwards compatibility in terms of the block size?
If SegWit results in production of blocks that are larger than 1MB, how do old nodes see them as valid, instead of rejecting them due to exceeding the maximal allowed size of 1MB?

there are some very genius people (aka sipa), who designed the blocks, which contain transactions in a way that particular parts of this transaction goes into a separate (segregated) area. This does not violate the validity of a tx. With the given space in a block, one can "bring in" more transactions in a block, which is roughly 1.8 tx more on average (a specific block reached up to 4 times more). So effectivly blocksize remains the same, it can just hold more tx, than before.

@pebwindcraft Maybe I misunderstand you (comments are so short...), but Segwit absolutely increases the size of blocks - it's not just using the same space more efficiently. Old nodes however don't see part of the blocks, and as a result, it does not violate their consensus rules.

@pebwindkraft: Please do not answer questions in the comments. Instead post an answer. Comments are only meant to provide constructive feedback to the post, to request clarification, or to provide minor transient additional information.

Segwit changes the definition of a maximum block size to be something called block weight. The maximum block weight is 4000000 weight units. We use the following formula to calculate the block weight:
3 * (size of non-witness data) + (size of everything including witness data)

So we can do some math here to figure out if the size of non-witness data will ever be more than 1 MB.
Let x = size of non-witness data
Let y = size of just witnesses
4000000 >= 3x + (x + y)
4000000 >= 4x + y
4000000 - 4x >= y

Since this is just a downwards sloping line, the point at which y = 0 is where x will be the greatest. So setting y to 0:
4000000 - 4x >= 0
-4x >= -4000000
 x <= 1000000

Thus the largest the non-witness data can be is 1 MB, which is exactly the maximum block size for non-segwit nodes. Since non-segwit nodes will only see the non-witness data, segwit is backwards compatible as blocks would still be within the size limit.


text:
I sent Bitcoin to a Bitcoin Cash eWallet by mistake, what can I do?
By mistake, I sent some Bitcoin to a Bitcoin Cash eWallet. Is there anything that I can do to get it back?

I ve always wondered if transaction can be reversed

Do you hold private keys of that Bitcoin Cash eWallet?
If yes, you need to import private key of that Bitcoin Cash address into any Bitcoin wallet and you will be able to get your bitcoins back.


text:
Tracking the wallet owner of stolen bitcoins
Hello Recently my bitcoin wallet was hacked and the money was transferred out into another bitcoin wallet. Is it possible to track and find out the owner of this wallet

Every Bitcoin transaction is traceable, but... unfortunately, it is not possible to determine who owns the address. Unless somebody admit to having a particular address.


text:
How are eth transaction faster than btc?
If I'm not wrong miners are trying to find nonce that satisfies a rule.
Then why is btc so slow? I want a technical answer.
Can btc ever match eth speed, given no politics?

You have two answers that address different questions - one asked by the title, and one implied by the first sentence.  Are you talking overall transaction throughput - that would be Rutger Versteegden's answer - or individual transaction latency - that would be Max Vernon's answer.  Or something else.  Clarification would be useful.

Most simple and foreseen reason:
Bitcoin's blocktime is set at 10 minutes,
while Ethereum has a block every 10-20 seconds, making it much faster.

See Ghost protocol, https://www.cryptocompare.com/coins/guides/what-is-the-ghost-protocol-for-ethereum/

So no, bitcoin will probably never be able to match Ethereum's speed. ( In it's current state)
(Unless they would implement something like the lightning network.)

BTC transaction confirmation can be "slow" because of a combination of factors, including:

Maximum block size is limited (the NYA was an attempt to rectify that), thereby limiting the number of transactions that can be contained in each block.  Typically less than 3000 transactions are included in any given block.
There are a large number of transactions occurring every minute (over 300).
There is competition for confirmation in the form of user-configurable transaction fees.

If you want fast confirmation, you up the fee, thereby ensuring you get prioritized by miners for inclusion in the next block.
See https://www.cryptocompare.com/coins/guides/what-is-the-block-size-limit/ for an interesting discussion about the pros and cons of the block size limit, and the effect that has on transaction processing.


text:
Attacking Bitcoin with a supercomputer
The difficulty in Bitcoin is recalculated every 14 days. What if immediately after this difficulty adjustment someone targets Bitcoin nodes with a supercomputer and start creating new blocks?
Such attack can create some many bitcoin to complete the series to the 21 million bitcoins before the 14 days pass by. Then the difficulty will be recalculated and it is going to result sky high, because of so many blocks were generated in the previous cycle.
But after that the super computer is disconnected, and the Bitcoin network (all nodes that were mining prior the attack) will have no power to create another block. The network will stall. The interest in mining Bitcoin will disappear and nobody would be able to withdraw anything, since you would need a supercomputer to create the next block, or wait for hundreds of years for the next block to come.
Is there any error in my reasoning? Is this scenario possible?

Related: Why can't they use super computers to mine all the bitcoins?

"TL;DR: Bitcoin mining is virtually immune to someone attacking it with a supercomputer, because the mining market is already flooded with supercomputers custom tailored to the job at the hardware level."
(via Cort Ammon in comments)

First of all, the difficulty reset happens after 2016 blocks. That's only after about 14 days if the hashrate is stable. When there is a steep increase in mining power the difficulty will therefore adjust much more quickly. The difficulty change is limited to a factor of four, so e.g. if the hashrate increased by a factor ten (at the start of a difficulty period), the difficulty would increase by a factor four after 1.4 days, and then again by a factor of 2.5 after 5.6 days, so that it would have adjusted a factor of 10 after only one week. Since the adjustment is an exponential function, the network can similarly adjust to even bigger jumps. You are correct however, that if the hashpower left at that point, the network could get stuck.
Luckily, supercomputers are not effective at producing Bitcoin blocks. For Bitcoin blocks, the only operation that needs to be churned endlessly is a double SHA-256 hash. And that's exactly what Bitcoin ASIC miner hardware does, their chips have the necessary algorithm implemented in hardware and are therefore exclusively designed to calculate Bitcoin blocks. This is what makes even a single contemporary ASIC faster than thousands of computers.
The window for supercomputers to take over Bitcoin mining closed some time in 2012 or 2013. Today, the Bitcoin network produces about 10 exahashes/s. To my knowledge, the most cost effective miners come at about $100 per TH/s which translates to a magnitude of one billion USD invested in Bitcoin mining hardware alone.

there are GPU supercomputers. or, you could also make your own ASICs to attack bitcoin, how much would you need? around 100k USD, that is not much, considering that all discovered blocks would pay for the ASICs during the period you would be attacking it.

You severely underestimate the mining power of the Bitcoin network. ;) I've amended my answer to address your comment.

Does that cost factor in the amount of power consumed by those miners?

No just a guesstimate for the hardware acquisition cost. Although, miners producing for themselves probably would have lower costs.

Wrong answer - it does not address the main poiint (getting all Bitcoin before the 14 day pass) which is false to start with.

@TomTom: Thanks, I've added a paragraph to address that part of the question.

Tl/Dr: Bitcoin mining is virtually immune to someone attacking it with a supercomputer, because the mining market is already flooded with supercomputers custom tailored to the job at the hardware level.  (similar argument: what prevents someone with a gun from going onto an airforce base and taking a modern F-22 fight?  Answer: the Airforce base has more guns than he does)

@CortAmmon: Thanks, I've added your summary to my answer.

@Shadur Power is indeed a significant issue. That is why Iceland is a particularly good location for Bitcoin mining. It has cheap power, and plenty of cold air. See We got a look inside a vast Icelandic bitcoin mine.

It's not done every 14 days - it's done every 2016 blocks, which will happen in 14 days if hashpower stays the same. If hashpower goes up, then the retarget happens sooner.

Also supercomputers wouldn't make a dent compared to today's hashrate. Likely, even the top 1000 most powerful general purpose computers together wouldn't even.

well, then a supercomputer can take advantage once in while. it can make 2015 blocks and then wait for the hashrate to stabilize.

@Nulik It would take 8 weeks for the hashrate to stabilize from that. That raises the question: why not turn on the supercomputer and mine continuously? Hardware isn't free.

@NickODell , I am exploring the possibility for the governments to attack bitcoin. They can use supercomputers to drive the difficulty so high, that the currency will be unusable, nobody would be able to withdraw or deposit because there will be no new block. Creating new block would take months, which means, bitcoin has failed its purpose.

so, mining is not the goal

@Nulik The difficulty algorithm would be adjusted. There are enough people who want bitcoin to keep working that, while it would be a bit inconvenient, they would be able to work out a change in the rules to keep things going.

You also need a LOT of power to do that. If that happens you can rather destroy bitcoin by reverting transactions. See, in order to "stop transactions for hours" you need to run like 20 or 50 times the current hashpower - otherwise you are just "inconveniently" slowing down the network, not disrupting it. That is a surreal amount of specialized hardware. You really need something that can hammer down like 2015 blocks in - half a day or so ;)

@TomTom: I did some reasoning on this. To break bitcoin permanently start from some weeks-old block and find the next block in the chain with the all-zeros hash if you can. All of the nodes will think your block is the next block and roll back a few weeks worth of transactions. It's not that they can't clean this up it's that they will be very worried about somebody doing that a second time with the intent to double-spend.

@Joshua That wouldn't work. Your chain (the one with the block you just found) is way shorter than the chain they were on previously (because it has a few weeks of additional blocks in it). The longest valid chain wins and your chain would be way shorter. (It's slightly more complicated than that, but that's the basic idea.)

@DavidSchwartz: It's total difficulty, and the difficulty of the all-zeros hash will be rated very high.

@Joshua No, it would not. You absolutely do NOT compute difficulty that way. It's only the difficulty required that you count.

The system is designed so that attempting attacks in simplistic ways like re mining an old block from a few weeks ago would not work.  If this was possible bitcoin would be effectively useless as a reliable store of value, and this form of attack would most likely have occurred by now.

@Nulik - if a government wanted to destroy bitcoin - or any cryptocurrency - all they need to do is pass a law, then enforce it.  It wouldn't be hard.  And IMO, it's going to be inevitable, because neither governments nor banks will want to deal with the loss of power.

@davidbak No single government can destroy bitcoin for the same reason they can't destroy the Internet. They could disconnect their own country from the system, to the extent their enforcement actually worked.

@DavidSchwartz. Why it wouldn't work? 2015 blocks are created every 2 weeks. Let's suppose I have super-puper computer at home, thousands of times faster that current bitcoin network of all the nodes within it. With my super-puper computer I could create 2015 blocks of last 2 weeks in a few minutes. Then I will create another 2015 blocks , my chain of blocks will be larger and it will accepted. And probably only after that my super-puper computer will have difficulties to calculate new blocks due to the difficulty. Why do you say it is not possible? Theoretically it is.

@DavidSchwartz and you would erase 2 weeks of transactions this way. What a horrible technology is this blockchain algorithm if you can lose transactions you made in the past

@Nulik There are a number of reasons that won't actually work. Ask your own question and I'll explain it.

@DavidSchwartz, okay, here it is: https://bitcoin.stackexchange.com/questions/60234/rewriting-past-transactions-in-bitcoin

It would take the power out put of a 30GW power plant for 3months and 49 qibits running of GPU to start from the gen block Jan 3rd 2009 up to date giving 2 months of mining the chain into oblivion. Thus collapsing the bitcoin.
"IBM has come up with a way to simulate quantum computers that have 56 quantum bits, or qubits, on a non-quantum supercomputer – a task previously thought to be impossible."
Set back and watch for a time and price a GOV backed attack takes place and evaporates the bitcoin barter business. In return causing a market dump of all blockchain and etherum platted trade.