text:
How to invest bitcoins?
Are there any websites where bitcoin holders can invest their money? Such as by buying shares or giving out loans. For example there is a ShareHolder service for WebMoney. Is there something similar for Bitcoin?

A great answer to this question would be a link to a website that actively maintain a list of such websites, otherwise the answer here will likely get out of date.

When a venture raises capital in bitcoins it spends those on assets and contracts tied to fiat money.  As a result if the exchange rate rises, the venture's earnings are at a lower rate (in terms of bitcoins).  As a result, the lower dividends cause the valuation for the venture to drop.  So it is very difficult for a business to either be capitalized using bitcoins without the investor losing if the exchange rate rises.  Simply holding bitcoins as an asset has provided better returns than "putting the funds to work" has returned.

A list of Bitcoin-related financial investment services:

http://en.bitcoin.it/wiki/Trade#Financial

The link is broken.

Beware, making use of the following could be dangerous, risky, or even illegal:

http://btcjam.com p2p loans
http://polimedia.us/mpex stock exchange and options contracts
https://coinbr.com an mpex broker (makes it easier to use mpex)
https://icbit.se futures, mostly
https://cryptostocks.com stock exchange

The "dangerous and risky" label is accurate, but "illegal" remains to be seen. European Central Bank considers bitcoin market to be existing outside its regulation (only normal trade laws apply), US/UK authorities did not issue clear assessment yet afaik. But it's reasonable to assume there isn't bigger legal threat, than for example, accessing unlicensed online casinos.

I did leave a little wiggle room in that statement just for that concern, essentially saying that it 'could be illegal'

I have been using btcjam and it is pretty simple. However people aren't really offering competitive rates, the highest reasonable return i have seen is 5%. There are higher ones, but only for untrustworthy people.

@PeterMichealLacey-Bordeaux, it may have improved since your comment. I've successfully invested in several high interest ones. You should do due diligence as with  anything and don't only go by the ratings the site shows. Also look at number of trades and even ask the borrower to chat offline and send more verification if you have doubts of their ability or motivations to repay.

A new exchange just opened at http://btct.co operated by the same person running http://litecoinglobal.com

I've had some pretty good luck with Cryptostocks.com. Not all of the things on that site are things I would condone. There's a lot of stock for groups that do orchestrated pump and dumps. But they also have miners and companies that are building economies for cryptocurrencies, which I approve of. It takes all kinds, I guess.

You could invest IN bitcoins or you could invest your bitcoins.. Slight difference. There are several companies that offer cash gold silver etc investments that now allow you to invest your bitcoins too. Google finds few results as yet but they are out there. I use a non-profit investment company at www.bitcointrustgroup.org as they seem to offer good returns but on the downside they only offer long term investments if you dont want to suffer penalties for early withdrawal.

-1 never trust someone who wants to anonymously hold your money


text:
How much ASIC power has been, or is being, shipped in 2013?
Where can I verify how much ASIC mining power has been shipped, how much has been pre-ordered, when it will be shipped, and at what rates and time frames more units will be shipped?

And a related question: is there any info on how much of the ASIC supply is being bought up by mining contract companies rather than individuals?

This question needs a timeframe, or it will soon be out of date. If you don't like my edit, feel free to update it...

Let's analyze ButterflyLabs alone.
From the Butterfly Labs Wait list, here are the current numbers, along with the number of chips:
Orders Tracked: 325

Unit             Number tracked     Chips/unit     Chips tracked
Jalapeno SC      216                  1              216
Mini Single SC    41                  7              287
Single SC        348                 14             4872
Mini Rig SC       25                334             8350
------------------------------------------------------------------
Total                                              13725

Thus, our average chips per order is 13725/325 = 42.2 chips/order from what we know.  Next, let's look at the number of orders and assume that average stays consistent.  Let's say there were 18,500 ASIC orders under the first ordering system (Order numbers 1500-20000), and are currently 12,000 in the second order system (Order numbers 100014000-100026000).  That brings the total orders to be filled to 30,500.  Multiply that by our average number of chips per order and we have 1,287,100 4.5GHz chips on order.  Thus, if these numbers hold true (and I really hope they are VERY high), we are looking at 5.8 Million GH/s added to the network from Butterfly Labs alone once they fill the orders to this point.  This is about 100 times the current global hash rate of 50000GH/s.
Also note that this is based off a lot of assumptions, and they haven't shipped their first unit yet, so who really knows.  When I contacted them in February, they said orders placed then would be fulfilled in May-June, but they also said they were shipping the first units by the end of February and they haven't shipped those yet.
UPDATE (4/22/2013):
The last order I see posted is 100036087, on April 8, up from 100026000 on March 22 (2 months ago to the day!), so we have an increase in order numbers of about 5,000 per month at the moment.  Also, they just shipped their first developer units, and they had to up the case sizes to accomodate the extra power modules.  Thus my best guess is that BFL will begin shipping to customers late May/early June.
Speaking of order numbers, I had assumed above that they increased every time an order was actually made.  However, According to Sgt Spike on the wait list forum about BFL order numbers,
"It generates an order number every time someone goes to checkout, whether they actually
 pay for it or not."

Which, if true, means that the above numbers are a definite worst-case scenario (unless of course there are a bunch of missing orders from the list for 100 mini-rigs or something crazy like that, which is very doubtful).  Thus, multiply the above numbers by the percentage you think that people actually followed through to a purchase after proceeding to checkout to get a better estimate.
Also, it looks like the earlier orders were much more heavily weighted than the later orders, where the info is also much more sparse, so the estimate still may be high even after you figure the correct buy percentage in.
Last, note that going forward the mini-rig is out of stock and they have upped the price and they have lowered the hash rates available from 60GH/s and 30GH/s to 50GH/s and 25GH/s respectively, so going forward the GH/order will probably be much less on average.  Even before they did that.  Thus, that should lower the expected addition to the global hash rate as well going forward.
With the above considered, I'd say a reasonable upper limit is about 2 Million GH/s added, which assumes about half the people that go to checkout actually place an order and the average order is slightly smaller than the average of the orders submitted.

If that's is correct even if no more orders are placed that's 7200 bitcoins per day / 1,287,000 = 0.0056 bitcoins per chip per day or around 71.76 USD * 0.0056 = 0.4 USD per day per chip.  So not profitable unless you ordered early.

@ChristopherEdwards: Unfortunately, it's even worse at 3600 bitcoins per day (25 per block instead of 50). For the 30/60GHz, let's say it's about $100/chip after fees. Thus, you'd get your money back at current projected rates and that hash rate in 500 days if you bought today and Butterfly Labs was the only one in the market, but that number could get MUCH higher very quickly once the ASIC companies streamline their production process.  Honestly, BFL dragging their feet is the best thing they can do, as once people see the updated Global Hash Rates, the orders are going to stop flying in.

...but again, I hope I'm wrong!

Nobody has that information but some supposed ASIC companies published how many preorders they had received (BFL). This would be a good indicator of the demand or amount of machines that will saturate the market.

Fine, but either link to these publications or this is not an answer.

@Lohoris I'm sorry you feel that way, the OP asked "where" he can go to get the information, and I told him who would have it, assuming that OP would then pursue knowledge in that direction. And my answer is also in line with the other answers. So I respectfully disagree with your ultimatum

I still disagree with you, but I'm sorry if my comment was harsher than intended!

source: Stack Exchange

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

sort: votes


text:
Bitcoin: transaction completed, bitcoins never arrived
I'm currently mining some bitcoins during normal computer use. I am using windows. The wallet is Bitcoin, as a miner I am using GUIMiner and pooled mining.
I am happy with the way everything works, however, I wanted to move my wallet to another location, so that I had access to it everywhere. I rented a virtual linux machine running Ubuntu 12.04, then installed bitcoind. I created an account and a new address.
For testing purposes, I transferred 1 BCCent to the new address. I was watching the sending wallet waiting for transfer confirmations, that never came. However, I remembered that the first time starting a wallet it takes quite a lot of time to synch to the network completely, so I went to sleep.
In the morning, the transaction was done and was affirmed by a lot of sources. I confidently checked my target wallet, and found that there were no bitcoins on the address and the account.
Checking the wallet for the transaction using
bitcoind gettransaction <the used txid>

gives the message
error: {"code":-5,"message":"Invalid or non-wallet transaction id"}

I am not sure how this could happen. I've double-checked the target address, and it matches.
Does anyone have an idea how such a thing can happen?

Check to make sure that your blockchain is fully up to date. I can't remember the command offhand, but you want to make sure of that. Maybe it's still syncing or got stuck somehow.

Have you tried restarting bitcoind with the -rescan option?

@ColinDean You were and are right. Somehow, not all blocks have been synchronized. If you formulate it as an answer (the option is, as Nick ODell said, -rescan), I'll accept it.

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


text:
How do I get started mining bitcoin with a GPU?
I'm totally new to this, but love this idea!
I want to help, (and generate coin), and have only installed Bitcoin-Qt version 0.8.1
It ran, synchronized; I encrypted my wallet.
But now what?  Will it use my 2 NVIDIA gtx580 GPU's on its own? Do I need to do anything else, other than just let it run?
Got the green checkmark; up to date
I have 8 active connections and my wallet is both locked(?) and encrypted.

I just did this today...
I found a mining pool (I picked Eligius) from here https://en.bitcoin.it/wiki/Comparison_of_mining_pools
The pools website had further instructions. In my case, I installed a mining client "bfgminer" and followed the instructions to add my ID. It sounds like for a windows OS, GUIMiner might be a good start too.
gui miner thread https://bitcointalk.org/?topic=3878.0
The key thing to realize is that there is a difference being a BitCoin "client", which is what you setup above, and a BitCoin "miner" which requires the steps I in this response.

bfgminer thread  https://bitcointalk.org/?topic=78192 (could only post 2 links above)

The official bitcoin-qt bitcoin client was the first bitcoin miner as well, but it only supports solo-mining. Unless you have some powerful equipment you're much better off mining with a pool, which requires the separate application like gui-miner.

i think its a pretty strong rig, so i just keep on waiting?

bitcoin-qt won't mine on your GPUs. It's not a miner, think of it as a wallet. You can send and receive coins with it. I created a miner that is dead simple to use. You'll find it at bitminter.com


text:
Is it possible to use a P2PKH output with a schnorr signature?
I know that Bitcoin has many different transaction output types (P2SH, P2WPKH, P2WSH, P2TR, etc).
And I know that P2PKH is an old transaction output type that has existed since before Segwit and before Taproot.
Is it still possible to create a P2PKH output that works with Schnorr signatures?

No, it is not possible to use Schnorr signatures with old output types.
Current node software evaluating transactions expects an ECDSA signature for an input spending a P2PKH output. Putting a Schnorr signature there would be invalid per the accepted rules. Even if the rules were updated to allow using Schnorr signatures, old node software would always reject a transaction that uses the updated understanding, and this would therefore classify as a hardfork.

No, Schnorr signatures are only used in taproot spends (v1 segwit with 32 byte witness program) as specified in BIP-342. This cannot be P2SH wrapped, and are encoded only with Bech32m.
Script path spending of Taproot modifies OP_CHECKSIG(VERIFY) to use Schnorr signatures instead of ECDSA. A new opcode is also made available for batch verification, OP_CHECKSIGADD. This means it is no longer possible to use ECDSA in taproot scripts.

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


text:
How do I prevent Bitcoin from synchronizing?
I have a script that uses Bitcoin's RPC interface and takes a lot of CPU to run, and I don't want Bitcoin to be verifying blocks while I do it. Is there a config setting or an RPC call I can use to stop it from syncing?

bitcoin-cli invalidateblock `bitcoin-cli getbestblockhash`

or
bitcoind -maxconnections=0

Thanks for your answer! Can you tell me, how can I "undo" the invalidateblock command so the sync will be continued?

reconsiderblock <hash>

Is invalidateblock still working? How much of a hack is this? Is there a less hacky way to do this already? Like a config entry?

It still works.

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


text:
What was the design decision behind that the coinbase field can have arbitrary data?
From what I learned, the coinbase field in the block reward transaction can carry any data (As long as smaller than 100b).
Why that actually? Was it easier to implement in the beginning? I would just have defined that the coinbase transaction may have no input. I know it is useful now to carry more information (see BIP34). I'm just not sure what was Satoshi's intention here, although he included himself the famous

The Times 03/Jan/2009 Chancellor on brink of second bailout for banks

Further it seems that this is missing in the transaction db and is unspendable, but I may confuse things here.

They wanted to rule out possibility that the same transaction ID would appear in different block, as a different coinbase.
There have been such in the history, but only twice, and it complicates the unspent DB application, so they just decided one day that same ID would not be distinguishable as a different transaction anymore. Thus added a protection against it, in block format version 2, so no miner can accidentally end up anymore with a non-unique ID for his coinbase transaction.

Ok, I see, that's the reason: the transaction ID is calculated from the data of the transaction, and if there would be just a normal bitcoin address as 'out' but nothing as 'in', collisions would be likely.

are you referring to bip 0034?

This answer explains how it is used now (as of BIP 34), not the original reason for having the coinbase field.

agreed with @PieterWuille . This doesn't answer the motivation of having the coinbase field in the first place. If unique transaction ID was required a sequence field would have been added instead of allowing arbitrary data


text:
Bitcoin Client - How do I find the destination address of an incoming transaction?
I'm mining Bitcoins and have multiple incoming addresses in my bitcoin-qt wallet.
When I get a payout for mining in the "Transactions" tab it shows the amount of BTC I received and the type is set to "Mined".
Now I see a lot of transactions, but I have no clue for which incoming wallet address these payments were originally made for.
How can I figure out the destination address in the wallet for incoming transactions? And if I can't; why?

Settings > Options > Display > Display addresses in transaction list

Nick, that's an answer not a comment.  Please post it below so this question can get marked with the proper answer.

@NickODell - Thanks, but that still doesn't show the incoming address for mined transactions. It does show the address for normal payments: http://i.imgur.com/QphomGx.png

@Casper I don't understand what you're trying to do. Are you trying to find the addresses of transactions inside blocks you mine? Are you trying to find the input addresses of coinbase (mining reward) transactions?

@NickODell - I'm mining with p2pool. When I connect to the p2pool network with my p2pool client I have to provide a payment address for mined blocks. My miner then connects to the p2pool client and starts mining. The pool then pays me to the address I provided for the blocks I mine. And I was wondering how come the incoming payments do not show this address I gave earlier. It's just n/a (and somehow the wallet knows those payments come from mined blocks, because the type is "Mined").

@Casper Ah, ok. I was confused by how many there were. It's not giving an input address, because p2pool pays you directly from the coinbase. Remember, coinbase transactions don't have a source address - their security is guaranteed entirely by how hard it is to change the block.

@NickODell "..payments don't have a source address..". But each payment must have a destination, right? And the destination is the address I gave p2pool? And that's what should show up in the transaction list? Sorry, I'm still a bit confused..there's probably something basic I'm missing here on how mining works.

In Bitcoin Core v0.15.1 you go to the transaction tab in bitcoin-qt and double-click on a transaction. It shows you the transaction details including the To: address.

Maybe this will help. Do a getrawtransaction  1
For example, getrawtransaction e12766de3b8b9532c0cca09a146c8a87e176ef39ec3823f1ea263401c77c465e 1 is this
"result":[{
        "hex":"01000000010000000000000000000000000000000000000000000000000000000000000000ffffffff2a0313ad051d4d696e656420627920416e74506f6f6c20626a38186bcefb2055e11be1d60c000000153904ffffffff015af73695000000001976a9149524440a5b54cca9c46ef277c34739e9b521856d88ac00000000",
        "txid":"e12766de3b8b9532c0cca09a146c8a87e176ef39ec3823f1ea263401c77c465e",
        "version":1,
        "locktime":0,
        "vin":[{
            "coinbase":"0313ad051d4d696e656420627920416e74506f6f6c20626a38186bcefb2055e11be1d60c000000153904",
            "sequence":4294967295
        }],
        "vout":[{
            "value":25.0340745,
            "n":0,
            "scriptPubKey":{
                "asm":"OP_DUP OP_HASH160 9524440a5b54cca9c46ef277c34739e9b521856d OP_EQUALVERIFY OP_CHECKSIG",
                "hex":"76a9149524440a5b54cca9c46ef277c34739e9b521856d88ac",
                "reqSigs":1,
                "type":"pubkeyhash",
                "addresses":["1Ebb8NfVmKMoGuMJCAEbVMv2dX8GnzgxSa"]
            }
        }],
        "blockhash":"00000000000000000f312f367314d9c9880ac990d3e759092407a088a104cadd",
        "confirmations":1,
        "time":1440816100,
        "blocktime":1440816100
    }]

As you can see, it's a coinbase transaction, with a vout of the address it's paid to. The Bitcoin-Qt interface may not show it (because it doesn't really matter), but if you run that command on your mining tx you will see where it went :)

getrawtransaction (txid) => gives you raw transaction X
take that and calc
decoderawtransaction (X) , after that look at "vout" and find the address the transaction send the bitcoin to .
All in Bitcoin-qt console


text:
How can I create and setup an litcoin mining pool?
I am researching if it is viable to create a mining pool on some closed networks outside of normal operating hours.
Is there a system which can be customise which shows accountability of running such a mining pool?  I want to make sure we can prove the electricity usage and offer a fair reward for all concerned obviously.
We have some participants who have supercomputers handy too, would that cause any complication due to skewing the performance too heavily?
How can we calculate the power needed to mine a single LTC coin (on average)?

"How can we calculate the power needed to mine a single LTC coin (on average)?" would be best asked as a separate question.

there is an answer how to install a mining pool
http://bitcoin.stackexchange.com/questions/4303/how-to-setup-pushpool/5995#5995?newreg=6410e50683ed49f0bf829d0c865c4ca4


text:
Why is my transaction not getting confirmed and what can I do about it?
I sent a transaction

without (or with an exceptionally small) transaction fee
using extremely small or unconfirmed inputs
while the stars were not standing right.

For whatever reason, I have been waiting forever for my transaction to confirm.
Why is it taking so long for my transaction to confirm? What can I do to speed-up the transaction’s confirmation?

This is a canonical question serving as a lightning rod for the flood of "unconfirmed transaction" questions we are experiencing lately. Please provide a detailed and broad answer to serve a wide range of these questions.

Also see these related questions: • How to unstuck a low-fee transaction with Electrum?, • How do miners select which transactions to include in a block?, • Do unconfirmed transactions expire?, • What happens if my transaction is not accepted because I did not pay fees?, • How to unstuck a low-fee transaction with blockchain.info?

How Bitcoin Mining Works
Bitcoin transactions are mined (processed) by Miners, and Miners want to benefit from their work. By mining transactions with higher fees, they make more money. Some miners can decide to mine all transactions no matter the fee but they still must compete with every other financially motivated miner.
Why is it taking so long for my transaction to confirm?
If you have sent a transaction

without (or with an exceptionally small) transaction fee

expect it to be ignored for an unknown amount of time until a miner decides to process it and solves the block; this could be several days to several weeks, possibly never. Your wallet and any Bitcoin node will show it as unconfirmed, your transaction is stuck in limbo.
Block sizes are limited, which means that only a limited number of transactions can be processed in a certain timeframe. In the beginning of bitcoin, there was lots of free space in each block because there were not many transactions. However, now that Bitcoin is quite popular there are more transactions than can be processed into the current block. This is why transaction fees have increased, and as long as someone is still willing to pay more they will keep increasing.
What can I do to speed-up the transaction’s confirmation?
Nothing. The next best thing is to cancel and resend the transaction.

Make a note of the individual bitcoin address(es) that the unconfirmed transaction was sent from.
Run Bitcoin Core with the -zapwallettxes option (or wait a few days until your wallet stops broadcasting the transaction and it falls out of the global transaction mempool). (Issue with mempool.dat resolved by #10330 in 0.15.0).
Send all your bitcoins from the addresses recorded in step 1 to a new address with the recommended or higher than recommended fee.
Make original transaction again using the recommended fee.

What to watch out for

Sites that claim to "speed up your unconfirmed bitcoin transaction". From personal experience, these sites are either scams or just don't work.
DOUBLE PAYMENTS. If the addresses used in the original transaction have sufficient bitcoin in them to cover the transaction, it can always be completed at a later date. To avoid this, follow step 3 to empty the associated addresses and do not reuse them.

What is the recommended fee?
Transaction fees vary by the size of your transaction, and not all transactions are the same size. The fee for same sized transactions also depends on how busy the bitcoin network is at the moment.
An estimate (at the time of original post) was between 11-20 satoshi/byte (0.00011-0.00020BTC/kB) but now can be much higher.
Most wallets have a feature which dynamically calculates the rate based on network congestion.
See https://bitcoinfees.earn.com/ for a live chart of suggested transaction fees

Very good! Thank you. Perhaps you could add a sentence please where you explain that blocks have gotten fuller and that’s why fewer miners pick up low-fee transactions.

Yes, there is a way to save a borked transmission. A restart of the wallet and some patience typically fixes the issue.
How to stop/reverse a Bitcoin transaction without confirmations:

Run bitcoind and with -zapwallettxes.
This makes the wallet "forget" any unconfirmed transactions, thus enabling you to reuse their inputs.
Create a new transaction to make your payment and add an appropriate fee this time.
The unconfirmed transaction is still valid and may still be floating around in the network, so be sure to spend its inputs to yourself, or the transaction may be confirmed at a later time and you'll end up double-paying.
The simplest way is to send all your bitcoins to yourself. Don't forget an appropriate fee. ;)

here is a very interesting thread on reddit about canceling a transaction and double spending, I never knew the protocol actually allowed it  http://www.reddit.com/r/Bitcoin/comments/1s4zdn/it_currently_costs_around_5_to_send_someone/?utm_medium=twitter&utm_source=Fancy+Show+Tech

Here is a guide for as many wallets as I could figure out how to perform an RBF with. This is adapted from my bitcointalk post: https://bitcointalk.org/index.php?topic=1802212.0
What is a "Stuck" transaction? How are they caused?
A "stuck" transaction is a transaction which has remained unconfirmed for period of time which either the receiver or the sender is uncomfortable with. Stuck transactions can be annoying as it means that recipients often consider the senders to not have paid yet, or the recipient needs the money as soon as possible.
Stuck transactions are typically caused by low transaction fee rates. However other things can cause stuck transactions such as spending from an unconfirmed transaction, having dust outputs in the transaction, or being a double spend of another transaction. If a transaction has a double spending transaction and the double spend confirms, then the transaction will be "stuck" forever as it can never confirm.
What can I do to make my stuck transaction confirm?
There are several options for confirming stuck transactions:
For both the recipient and the sender of the transaction, you can:

Wait for the transaction to confirm
Wait for the network to "forget" about the transaction
Ask a miner to confirm it for you

For the sender of a transaction, you can also:

Attempt an Replace-By-Fee double spend transaction
If you have a change output, you can attempt a Child-Pays-For-Parent transaction

For the recipient of a transaction, you can also:

Attempt a Child-Pays-For-Parent transaction

Waiting for a confirmation
If you are incapable of performing any of the other options or are too afraid to do so, you can simply wait and hope that the transaction will eventually confirm. To ensure the network is constantly being reminded of the transaction, you can rebroadcast the transaction periodically. Most wallets will rebroadcast automatically, so simply leaving your wallet open will allow rebroadcasting to happen.
Waiting for the network to "forget" about the transaction
If a transaction remains unconfirmed for too long, it can be eventually "forgotten" by most nodes on the Bitcoin network if no one rebroadcasts the transaction. This happens due to node restarts, mempool expiry times, or mempool eviction because the minimum mempool fee has increased. This process typically takes a few days (usually 3). Once a transaction has been "forgotten", you may not see it in your wallet and you probably will not see the transaction in most block explorers. Once the transaction has been "forgotten", you can simply send the Bitcoin again but include a higher transaction fee. If you still see the transaction in your wallet but don't find it on any block explorers, you will need to follow the instructions in the next Replace-By-Fee Section.
Note that some wallets will continuously rebroadcast the transaction while the wallet is on, so you either have to remove the transaction from the wallet using the instructions in the RBF section, or shut down the wallet and keep it off for several days.
Ask a miner for help
Some mining pools and miners offer services to allow you to prioritize your transaction in their mempool so that it is chosen sooner for inclusion in a block. One such service is https://pool.viabtc.com/tools/txaccelerator/. Note that ViaBTC does have a limit the accelerator to 100 transactions every hour and requires that it pays a minimum fee rate of 10 satoshis/byte, so their accelerator may not necessarily work. Another such service is https://pushtx.btc.com/#/. Not that BTC.com does require another form of payment in order to "accelerate" your transaction.
Also note that if you attempt a Replace-By-Fee transaction, both the original transaction and the RBF transaction will be considered double spends.  Miners will likely not help with any transactions marked as double spends.
Attempting a Replace-By-Fee (RBF) double spend transaction
What is an RBF transaction
A Replace-By-Fee transaction is a transaction that is nearly identical to your stuck transaction but pays a higher transaction fee. Since the original transaction most likely does not use Opt-in RBF, the RBF transaction that we will be creating will be considered a double spend and marked as such. The transaction uses Full-RBF and thus may still take a little bit longer to confirm as it is technically a double spend.
The difference between the types of RBF transactions
Replace-By-Fee transactions have 3 different types, First-Seen-Safe(FSS) RBF, Full RBF, and Opt-in RBF. FSS RBF requires that the RBF transaction include the same outputs as the transaction it replaces and consumes the same inputs. Full RBF means that the transaction is simply a double spend of another transaction but pays a higher transaction fee than the one(s) it replaces. Opt-in RBF means that the RBF transaction can only replace a transaction that has Opted-in to allowing itself to be replaced. Opt-in RBF follows BIP 125.
The instructions given in this section will be for making Full RBF transactions. Opt-in RBF transactions will be described in the "Avoiding Stuck Transactions In The Future" section.
How to make a Full RBF transaction
Making a Full RBF transaction depends entirely on the wallet that you are using. Some wallets support the advanced functionality required to make a Full RBF transaction, others do not. The following will be guides for each wallet on how to make a Full RBF transaction with that wallet. In general the procedure is to remove the unconfirmed transaction from the wallet and then resend the Bitcoin but with a higher transaction fee.
When making a Full RBF transaction, the transaction should include the recommended fee rate effective at the time of creating the transaction. See the "Avoiding this issue in the future" section for help with that.
Bitcoin Core
Bitcoin Core makes making Full RBF transactions very easy. Simply go to the transactions list, right click the transaction that is stuck, and choose the Abandon Transaction option.
If that option is greyed out, go to the Bitcoin Core datadir and delete the mempool.dat file. Then restart Bitcoin Core with the -walletbroadcast=0 option and then you should be able to use Abandon Transaction.
If the above two options fail for some reason, start Bitcoin Core with the -zapwallettxes option to clear all unconfirmed transactions from your wallet.
Once the transaction is either Abandoned or cleared from the wallet, you can simply go to the Send tab and send the Bitcoin again but make sure that you include a sufficient transaction fee.
Bitcoin Armory
Bitcoin Armory also makes making Full RBF transactions very easy. Go to Help > Clear All Unconfirmed Transactions and restart Armory. This will clear all of the unconfirmed transactions from the wallet and thus allow you to create the Full RBF transaction. Once Armory has restarted, simply send the Bitcoin again as you normally would but be sure to include a sufficient transaction fee.
MultiBit HD
MultiBit HD allows for making Full RBF transactions fairly easy as well. Go to Manage Wallet and click on Repair Wallet and follow the wizard. This process will clear all of the unconfirmed transactions from your wallet much like Bitcoin Core and Armory do. Once repair wallet has completed, simply send the Bitcoin again as you normally would. Note that some users have had trouble with this method in the past and it may not always work. You may need to wait for the transaction to be "forgotten" in order for this method to work.
Wallets that do not allow you to or ones that I don't know how to make Full RBF transactions
Not all wallets support the creation of Full RBF transactions. Many wallets do not allow clearing all unconfirmed transactions to allow for making Full RBF transactions. The following is a list of wallet software which do not support Full RBF transactions. If a wallet on this list does support FullRBF transactions, please let me know and provide instructions for that so I can add it above.

Blockchain.info and web wallets in general
Electrum (supports Opt-in RBF, but not Full RBF)
Mycelium
MultiBit Classic
Bitcoin Wallet for Android
Breadwallet
Copay

Attempting a Child-Pays-For-Parent transaction
What is a Child-Pays-For-Parent transaction?
A Child-Pays-For-Parent (CPFP) transaction is exactly as the name implies, a child transaction spends from an unconfirmed parent transaction and includes a transaction fee which covers both the fee of the child and the parent. However creating CPFP transactions are much more difficult as it requires spending from an unconfirmed transaction, something that many wallets do not allow.
How can I avoid making Stuck transactions in the future?
Using Dynamic Fees
The best way to avoid having stuck transactions is to make sure that you are not spending from an unconfirmed transaction, and include a sufficient transaction fee. If your wallet supports dynamic transaction fees, you should use those. If you want very fast confirmations, set the dynamic fees to choose the fastest fee possible. Dynamic fees are calculated by the wallet by analyzing the current state of the network and determining an optimal transaction fee from there. Since the state of the network constantly changes, the optimal transaction fee calculated one day may not necessarily be the best fee for the next day.
If your wallet does not support dynamic fees but does support setting a custom transaction fee rate for each transaction, you can look up the optimal fee rate on sites like http://bitcoinfees.21.co/ and https://bitcoinfees.github.io/ and set the fee rate for each transaction based on those sites. You must do this for each transaction you make otherwise you may end up paying a sub-optimal fee.
If your wallet does not support any sort of fee rate or does not allow setting custom transaction fees, you should upgrade to a new wallet. Using a fixed fee or fixed fee rate is no longer a good idea as the network constantly changes. You can use this formula: <in>*148 + <out>*34 + 10 where <in> is the number of inputs and <out> is the number of outputs to estimate the size of your transaction and determine the optimal fee for it.
Note that some wallets (e.g. blockchain.info), even though they use dynamic fees, set an upper limit to the transaction fee. If you notice that your transactions are constantly being stuck even though you are using dynamic fees, you should check the settings of your wallet and perhaps even switch to a new wallet which has no limit to the transaction fee.
Use Opt-In RBF
Opt-In RBF is a feature that allows for an RBF transaction to be more easily created as these transactions will not be rejected by nodes supporting Opt-In RBF.
Currently few wallets support creating Opt-In RBF transactions
Electrum
To create a transaction that can be replaceable, go to Tools > Preferences and check the box "Enable Replace-By-Fee". Then when you want to send some Bitcoin, next to the Fee slider is a box labeled "Replaceable". Check that box so that while the transaction is still unconfirmed you can replace the transaction with one that pays a higher fee.
To increase the fee of a transaction that uses Opt-In RBF, right click the transaction in the history list and choose the "Increase Fee" option.
Armory
Armory also allows for the creation of RBF transactions. When sending a transaction, choose the checkbox "Enable RBF".
To increase the fee of a transaction that uses Opt-In RBF, right click the transaction in the transactions list and choose the "Bump Fee" option. Transactions whose fee can be increased are labeled clearly in the transactions list.

I just experienced a "gotcha" in Bitcoin Core 0.15 for an opt-in RBC transaction.  The transaction required no "change" address since it was spending exactly the amount of the input.  When attempting an RBF to speed up the transaction, bitcoin-qt complains that there is no change address present in the transaction, so RBF cannot be used.

Regarding a transaction with no change output, see my question about exactly this issue: https://bitcoin.stackexchange.com/questions/64814/increase-transaction-fee-with-bitcoin-core-client-fails-because-of-no-change-out

In the case that your fee is too low: Now that child-pays-for-parent has been merged, you(or any of the recipients of your unconfirmed transaction) could spend the Bitcoin received and the fee associated with that second transaction will help prioritize the confirmation of the original transaction.
This does require more fine grained control of which outputs you spend, which not all wallets provide.
The behavior from miners prioritizing this way has existed in some pools for a while, but now it is the default.

This is a far better option than the accepted answer. Helped me a lot. A bit more detailed explanation can be found here: https://www.reddit.com/r/Bitcoin/comments/5uzgvu/how_to_issue_a_cpfp/

The other answers cover most useful information already, I'd like to add one point though:
The fee estimation of most wallets has significantly improved since blocks have gotten full.
If you're running an outdated version, it's likely that it is doing a bad job of guessing the fee. That may cause you to either overpay or your transactions not getting confirmed in a timely fashion.
To avoid fee-related delays in the future, it is advantageous to run a current version of your wallet software.

If you are using Electrum, there is no equivalent to -zapwallettxes. The closest thing you can do is to restore your wallet from a seed. This will wipe your client of any unconfirmed transactions.
Then, you can resend the transaction with a higher fee.

Is this also the answer to http://bitcoin.stackexchange.com/q/50064/5406?

There's many ways to get your transaction confirmed.

push your transaction

https://insight.bitpay.com/tx/send
https://blockchain.info/pushtx
https://blockexplorer.com/tx/send
https://btc.com/tools/tx/publish
https://coinb.in/#broadcast
https://chain.localbitcoins.com/tx/send
http://webbtc.com/relay_tx
https://www.smartbit.com.au/txs/pushtx
https://live.blockcypher.com/btc/pushtx/
https://www.f2pool.com/pushtx (Needs referral code from pool operator.)
https://pool.viabtc.com/tools/BTC/broadcast/
https://chainquery.com/bitcoin-api/sendrawtransaction

Pay to mining pools to confirm your transaction

https://pushtx.btc.com/

Some websites ask for hex format transaction ID, You could convert it like that:
https://blockchain.info/tx/TransactionID Here?format=hex

No, pushtx websites only broadcast transactions, they don't convince miners to include theirs in their blocks.

If I had seen Andrew's great reply earlier, I would probably spared myself from writing an explainer on Reddit, but now that I did I'll post it here as well, hoping that it might complement this thread, as it is targeted more at beginner level folks.
In the last days we have been experiencing a sharp rise in price, which is historically correlated with many people transacting over the Bitcoin network. Many people transacting over the Bitcoin network implies that the blockspace is in popular demand, meaning that when you send a transaction, it has to compete with other transactions for the inclusion in one of the blocks in the future. Miners are motivated by profits and transactions that pay more than other transactions are preferred when mining a new block. Although the network is working as intended (blockspace is a scarce good, subject to supply/demand dynamics, regulated purely by fees), people who are unfamiliar with it might feel worried that their transaction is “stuck” or otherwise somehow lost or “in limbo”. This post attempts to explain how the mempool works, how to optimize fees and that one does not need to worry about their funds.
TL;DR: Your funds are safe. Just be patient* and it'll be confirmed at some point. A transaction either will be confirmed or it never leaves your wallet, so there is nothing to worry about in regards to the safety of your coins.
You can see how the mempool "ebbs and flows", and lower fee transactions get confirmed in the "ebb" times (weekends, nights): https://jochen-hoenicke.de/queue/#0,30d
Here’s how Andreas Antonopoulos describes it:

In bitcoin there is no "in transit". Transactions are atomic meaning they either happen all at once or don't happen at all. There is no situation where they "leave" one wallet and are not simultaneously and instantaneously in the destination address. Either the transaction happened or it didn't. The only time you can't see the funds is if your wallet is hiding them because it is tracking a pending transaction and doesn't want you to try and spend funds that are already being spent in another transaction. It doesn't mean the money is in limbo, it's just your wallet waiting to see the outcome. If that is the case, you just wait. Eventually the transaction will either happen or will be deleted by the network.
tl;dr: your funds are safe

*  If you are in hurry there are things like RBF (Replace By Fee) and CPFC (Child Pays For Parent), which you can use to boost your transaction fees; you will need an advanced wallet like Bitcoin Core or Electrum for that though. Keep also in mind that this is not possible with any transaction (RBF requires opt in before sending, f.ex). If nothing else works and your transaction really needs a soon confirmation, you can try and contact a mining pool to ask them if they would include your transaction. Some mining pools even offer a web-interface for this: 1, 2.
If you are interested in trying out those options, here is a very helpful post that goes more into it: What can I do to make my stuck transaction confirm?
How is the speed of confirmations determined in bitcoin?
Open this site: https://jochen-hoenicke.de/queue/#0,2w
Here you see how many transactions are currently (and were historically) waiting to be confirmed, i.e how many transactions are currently competing with your transaction for blockspace (=confirmation).
You can see two important things: the differently coloured layers, each layer representing a different fee (higher layer = higher fees). You can point at a layer and see which fees (expressed in sat/byte) are represented in this layer. You can then deduct which layer your own transaction is currently at, and how far away from the top your position is (miners work through the mempool always from the top, simply because the transactions on top pay them more). You can estimate that each newly mined block removes 1MB from the top (see the third graph which shows the mempool size in MB). On average, a new block is produced every ten minutes. But keep in mind that over time more transactions come into the mempool, so there can be periods where transactions are coming faster than transactions being “processed” by miners.
The second important observation is that the mempool "ebbs and flows", so even the lower paid transactions are periodically being confirmed at some point.
In short: what determines the speed of a confirmation is A) how high you set the fee rate (in sat/vbyte), B) how many other transactions with same or higher fees are currently competing with yours and C) how many transactions with higher paid fees will be broadcast after yours.
A) you can influence directly, B) you can observe in real time, but C) is difficult to predict. So it's always a little tricky to tell when the first confirmation happens if you set your fees low. But it's quite certain that at some point even the cheap transactions will come through.
Good to know: "fee" means the absolute amount of satoshis a transaction pays, and "fee rate" is the fee per weight of a transaction. Miners prioritize by the latter, because even if a "lighter" transaction pays less in absolute satoshis, it might be more profitable to include it into a block if it has higher fee rate, because it also takes up less space. This means, fees expressed in sat/vbyte is what interests us in this context.
So what happens if my transaction stays unconfirmed for days or even weeks?
Transactions are being broadcast by the full nodes on the network. Each node can adjust their settings for how long they keep unconfirmed transactions in their mempool. That’s why there is not a fixed amount of time after which a transaction is dropped from the mempool, but most nodes drop unconfirmed transactions after two weeks. This means that in the absolute worst case the unconfirmed transaction will simply disappear from the network, as if it never happened. Keep in mind that in those two weeks the coins never actually leave your wallet. It’s just that your wallet doesn’t show them as “available”, but you still have options like RBF and CPFP to get  your transaction confirmed with higher fees, or to “cancel” your transaction by spending the same coins onto another address with a higher fee.
A transaction with very low fee rate might also disappear from the network if the mempool goes over 300MB in size, because by default a Bitcoin Core node will purge transactions from its internal mempool, starting with the lowest fee rates first, while increasing its minimum acceptable fee rates that it will broadcast further. You can read more about it here. Spikes this large have been very rare in bitcoin's history so far though, I think there was only one, briefly in January 2018.
Important to know: even if the transaction has been forgotten by most nodes and doesn't appear anymore on blockexplorers, it is still a valid transaction and might have stayed in the mempool of a node somewhere. So it's better to use one of the inputs in another transaction to invalidate the original, "stuck" transaction (otherwise you risk it to be re-broadcast and be confirmed when you already forgot about it).
Helpful tools to estimate fees for future transactions:
Here are some resources that can help you estimate fees when sending a bitcoin transaction, so you don't end up overpaying (or underpaying) unnecessarily. Keep in mind that in order to take advantage of this, you need a proper bitcoin wallet which allows for custom fee setting. A selection of such wallets you can find here or here.
The order here is roughly from advanced to easy.

https://jochen-hoenicke.de/queue/#0,24h

Here you can see a visualization of how many unconfirmed transactions are currently on the network, as well as how many were there in the past. Each coloured layer represents a different fee amount. F.ex the deep blue (lowest layer) are the 1sat/byte transactions, slightly brighter level above are the 2sat/byte transactions and so on.
The most interesting graph is the third one, which shows you the size of the current mempool in MB and the amount of transactions with different fee levels, which would compete with your transaction if you were to send it right now. This should help you estimating how high you need to set the fee (in sat/byte) in order to have it confirmed "soon". But this also should help you to see that even the low fee transactions get confirmed very regularly, especially on weekends and in the night periods, and that the spikes in the mempool so far have always been temporary. For that you can switch to higher timeframes in the upper right corner, f.ex here is a 30 days view: https://jochen-hoenicke.de/queue/#0,30d. Try higher timerframes as well.
You clearly can see that the mempool is cyclical and you can set a very low fee if you are not in hurry.

https://mempool.space

This is also an overview of the current mempool status, although less visual than the previous one. It shows you some important stats, like the mempool size, some basic stats of the recent blocks (tx fees, size etc). Most importantly, it makes a projection of how large you need to set your fees in sat/byte if you want your transaction to be included in the next block, or within the next two/three/four blocks. You can see this projection in the left upper corner (the blocks coloured in brown).

https://whatthefee.io

This is a simple estimation tool. It shows you the likelihood (in %) of a particular fee size (in sat/byte) to be confirmed within a particular timeframe (measured in hours). It is very simple to use, but the disadvantage is that it shows you estimates only for the next 24 hours. You probably will overpay by this method if your transaction is less time sensitive than that.

https://twitter.com/CoreFeeHelper

This is a very simple bot that tweets out fees projections every hour or so. It tells you how you need to set the fees in order to be confirmed within 1hour/6hours/12hours/1day/3days/1week. Very simple to use.
Hopefully one of these tools will help you save fees for your next bitcoin transaction. Or at least help you understand that even with a very low fee setting your transaction will be confirmed sooner or later. Furthermore, I hope it makes you understand how important it is to use a wallet that allows you to set your own fees.

Thank you to u/MrRGnome and u/fiatjaf for feedback and a special thank you to u/xekyo aka Murch on bitcoin.stackexchange for valuable help and proofreading.

Note: In the 2017 fee event, accelerators were widely used, but they seem to be rather expensive today in 2020. YMMV.

There are some services that take out-of-band requests to prioritize transactions that call themselves "transaction accelerators".
E.g. viabtc.com allocates part of their block to bumping stuck transactions:
https://pool.viabtc.com/tools/txaccelerator/
btc.com would be another transaction accelerator service. Try it if you want to pay by credit card :P
https://pushtx.btc.com/

ViaBTC recently stated that their allotment for an hour is used up in about 3 minutes. Really, it's more of a band-aid and political instrument than a solution.

There is currently a backlog of unconfirmed Bitcoin transactions and typically only the transactions with the highest fees will be confirmed until the backlog clears.

Any Help????

You have a few options:

Submit your transaction to the ViaBTC Transaction Accelerator
If you control either of the receiving addresses, send a new transaction from one of them with a much larger fee, encouraging a miner to pick up the whole chain of transactions (Child-Pays-For-Parent).
Wait. The transaction should be either confirmed or removed from the memory pool within about 72 hours.

Here is a good fee estimator for future transactions: https://bitcoinfees.earn.com/

I've merged the question this answer was posted on originally into this more canonical topic. Please check if you should edit your answer to adapt it to this topic.

If your Bitcoin transaction is not getting confirmed, it's likely due to one or more of the following reasons:
Network congestion: When the Bitcoin network experiences high transaction volumes, it can lead to longer confirmation times. For instance, in late 2017, during the peak of the cryptocurrency market, the network became heavily congested, causing significant delays in transaction confirmations. Miners prioritize transactions with higher fees, so during times of congestion, transactions with lower fees may take longer to be included in a block.
Insufficient transaction fee: If the transaction fee you've included is too low compared to the current market rate, miners might not prioritize your transaction, leading to a delay in confirmation. For example, if the average transaction fee is 100 satoshis per byte and your transaction fee is only 50 satoshis per byte, miners will likely prioritize other transactions with higher fees before yours.
Unconfirmed parent transaction: If your transaction is dependent on another unconfirmed transaction (for example, you're trying to spend coins received from an unconfirmed transaction), it won't be confirmed until the parent transaction is confirmed first. This situation can create a chain of unconfirmed transactions that need to be processed sequentially.
What can you do about it?
Wait: Often, the simplest solution is to wait for some time. Miners may eventually confirm your transaction when the network congestion subsides or when they have processed higher-fee transactions. This can take from a few hours to a few days, depending on the network conditions.
Replace-by-fee (RBF): If your wallet supports the RBF feature, you can try to increase the transaction fee to incentivize miners to prioritize your transaction. For example, if your original transaction fee was 50 satoshis per byte, you could create a new transaction with a fee of 120 satoshis per byte to make it more attractive to miners.
Child pays for parent (CPFP): If your wallet allows you to spend the unconfirmed transaction outputs, you can create a new transaction, known as a "child" transaction, with a higher fee. By doing so, you effectively increase the fee for the entire chain of unconfirmed transactions, encouraging miners to confirm both the original "parent" transaction and the new "child" transaction.
Use a transaction accelerator: Some services, like mining pools or third-party platforms, offer transaction acceleration services. For example, ViaBTC offers a transaction accelerator service that prioritizes your transaction for a fee, increasing the likelihood of a timely confirmation. Be cautious when using such services and only opt for reputable providers.
Wait for the transaction to drop from the mempool: If none of the above options work or are available, you can wait for the transaction to be dropped from the network's mempool (usually between 2 weeks and 30 days, depending on the network). Once the transaction is dropped, the funds will return to your wallet, and you can initiate a new transaction with a higher fee.
To avoid unconfirmed transactions in the future, ensure you're using a wallet that dynamically calculates the appropriate transaction fee based on current network conditions, such as the Electrum wallet or the Bitcoin Core wallet.


text:
How are vanity addresses generated?
The gambling site satoshi bones uses addresses that start with 1bones, such as
1bonesEeTcABPjLzAb1VkFgySY6Zqu3sX

How did they generate such a vanity address?

there are applications, which take the starting text and generates milions of new addresses until the generated address starts with the selected text. It's pretty fast for short strings (3 characters). you'll wait about few minutes for 5 characters (case insensitive).
one such application is vanitygen.

Are there problems importing the private key? Can these be imported into online services like Coinbase?

I use vanity adresses in bitcoind and blockchain.info (see this wiki) but I don't think, it is not possible to import your own addresses into Coinbase.

There used to be an address generator with prefix selection in inputs.io... Coinbase is similar type of service. You don't have any own addresses. You just have your account and they give you some their addresses bound to your account. Is that correct?

@V-X Yes, that's one reason why Coinbase.com isn't that secure.


text:
Can a miner refuse it's reward?
As of 2014, miners that successfully mine a block are entitled to 25 bitcoins.
Can miners refuse to receive those 25 bitcoins, thereby reducing the total number of bitcoins that will ever be mined?

It's not so different from simply never using the coins. They are effectively lost and thus out of circulation.

Pieter Wuille mentioned some blocks that took less than the full reward on Will there be 21 million bitcoins eventually?.

For the block to be valid there must be a coinbase transaction but it is only checked that it spends at much the reward and the fees generated in the transactions included in the block.
So it is possible to generate a valid block with a coinbase transaction spending less than the available coin and thus destroying coins forever.
But you can always send the reward to a random address in the hope that no one will ever be able to find it's private key and that it does not belongs to anyone.

Contradicts this answer which sources the Bitcoin code. You could set the script to OP_RETURN to make it provably unspendable or if I'm not mistaken you could just refuse to include a coinbase transaction (it's not enforced).

Yes it seems that the code does not check every posible situation, an unique coinbase as the first transaction of the block is enforced but there is no check if the value is less than what it should be, I will update accordingly.

Oh, you're right! I thought coinbase wasn't enforced but apparently it is (don't know where I read it). Gotta fix my own code then :)


text:
Understanding speed vs. fees on various wallets, esp. Instawallet and original client
The Bitcoin Wiki don't say much about fees, more precisely if you have a choice between speed vs. fees (pay more, deliver faster).
In fact, I don't yet even have a clue how fast are bitcoin transactions. Sometimes instant, sometimes it is structured by the wallet provide for lower fees but takes up to 24 hours?

Related: http://bitcoin.stackexchange.com/q/4483/516 (If you feel this answers your question, let us know and we'll close it as a duplicate)

Thank you for letting me know. On that thread, there is not definitive answer as well and also they are examining the question from the point of view of vetted developers and I as a newbie user. Thank you.

A wallet provider might make it seem like the transaction is instant, but it will have to be included into a newly mined block (happens about every 10 minutes), for it to actually "go through". If you only pay a low transaction fee, it might take some time until a miner decides to include your transaction.
After that, it's up to the receiver of the transaction to decide how many blocks to wait until he books it as confirmed on his side.
The default client waits for six of these so-called confirmations to show the transaction with a checkmark.

"but with the high difficulty the network has grow to, it is sensible to accept a small payment already after the first confirmation without fearing for double spend attacks" this is totally wrong. The difficulty auto-adjusts with the total hashpower, so the % of the network which you need to perform an attack stays the same, hence difficulty going up doesn't make you less vulnerable to attacks.

You will always need a certain percentage of the total hashpower plus some amount of luck to pull of a double-spend. But the total hashpower went up by several magnitudes of GHash/sec over time. I don't get your point, are you saying double-spends are just as easy to pull of right now than they were 2 years ago?


text:
Non LuckyCoin descendant alt-coins with fair "lucky blocks"?
Dogecoin just dropped the "lucky block" stuff after it was found out the "luckiness" wasn't entirely random - multiminers were waiting for the lucky blocks to appear and dropping their hashing power onto Doge's network all of a sudden to ensure they won the extra-bonus, then jumping out to mine another more profitable (for the moment) coin.
I know 42coin has fully deterministic bonus blocks, so most probably the multipools are grabbing those as well - wouldn't be surprised if they're dropped soon for same reasons.
But after checking the graphs of altcoin ancestries, it seems to me all coins with lucky blocks descend ultimately from LuckyCoin, so almost certainly have the same deffect.
Is there an alt-coin with lucky blocks that doesn't descend from LuckyCoin? Another question: Have randomness tests ever been applied to these coins to verify both their appearance and the amount given are really random?


text:
Testing blockchain forks
I want to test if a service can manage a blockchain fork. However there is no way to get bitcoind to create test forks under the regtest mode. I've tried modifying it to generate blocks with arbitrary prevblock hashes but it is not easy due to the high code complexity. I've managed to get it to create forks on-top of earlier blocks, however, I can't get it to generate blocks for conflicting transactions (double-spends and malleability changes), largely due to all of the "pruning" code. Surely someone has already come up with a solution, as this is a vital thing to test? I can't find anything on-line to help with testing fork scenarios.
I'm thinking that perhaps I should have used another technique? That I should have run 3 bitcoind regtest nodes and isolate them so that I can create multiple blockchains. 2 of them generate competing chains, and the other interfaces with the application. I can generate a fork scenario with the first two nodes, sync one of the nodes to the 3rd node and then sync the other node to generate the fork? I'd need to use a combination of addnode and tcpkill (?) to sync and then re-isolate the nodes.
This seems a ridiculous thing to do to test something so simple, so is there a better way?

I managed to test forks by creating 3 reg test nodes. One node is used to interface with my software, and two other nodes are used to hold competing blockchains. The regtest mode starts each node with no connections to begin with, so they are completely isolated. I can use "sendrawtransaction" and "setgenerate" on these isolated nodes to create competing chains. However, the nodes need to sync to test fork scenarios.
It turned out to be easy to synchronise nodes. I sync the competing nodes with the interface node with help of the RPC command "disconnectpeer" which you can find here. My synchronisation code is as follows in pseudocode:
function sync (node1, node2)

    if node2.height < node1.height then
        sync(node2, node1)
        return

    node1.rpc("addnode", "localhost:" + node2.port, "onetry")

    wait while node1.rpc("get_info")["blocks"] is not node1.height

    node1.height = node2.height
    node1.rpc("disconnectpeer", node1.rpc("getpeerinfo")[0]["id"])

After the function is complete the nodes will remain isolated once again so that you can work on creating new competing chains.

You can also use the RPC commands invalidateblock and reconsiderblock to aid with testing in this scenario. They allow you to disconnect and reorganize back and forwards in otherwise static situations.

@MatthewMitchell: What is the rough idea of using an "interface node"? Isn't it sufficient to have 2 nodes only?

@AliakbarAhmadi: The idea is that you create two competing blockchains with to nodes and the "interface node" synchronises with either one. Once this interface node is synchronised, it can't make it's own fork (unless you used invalidateblock like Gavin suggested) so that's why you have the third node to keep isolated whilst the other two are synchronised. Then you use this third node to create another fork if desired for your test case.

Nowadays it seems disconnectpeer is replaced by either (i) addnode with command remove or (ii) disconnectnode.

You can use the invalidateblock RPC commands to create blockchain forks.
invalidateblock hash tells a node to consider hash invalid, so just generate a bunch of blocks, invalidate one somewhere down the chain on one of the regtest nodes, and have that node generate a bunch more to create a fork.
See qa/rpc-tests/mempool_resurrect_test.py in the Bitcoin Core tree for a python example.

Thanks. I did not know about these RPC commands as they are not listed in the help command. One issue however, is that when you make a block invalid, the transactions would renter the mempool. This wouldn't allow to test scenarios of conflicting transactions being confirmed into forks, unless there was also a command which would remove/replace transactions from the mempool.

@gavinandresen: is there a RPC other than reconsiderblock that considers a fork as valid without closing the fork? I have a scenario where I'd like to have 2 valid forks for 2 connected(!) nodes.

Any other commands that are hidden from the help? These seem fairly useful for development purposes.

It's worth noting that if you use this method, ZMQ's behavior will not be as described in the docs for proper reorgs (https://github.com/bitcoin/bitcoin/blob/master/doc/zmq.md). Say you have chain A -> B -> C, then invalidate C, then generate two new blocks, yielding A -> B -> C' -> D. ZMQ will notify A, B, C, C', and D, whereas the docs imply that in proper reorgs ZMQ would only notify A, B, C, and D.

Depending on your language and bitcoin library, you can simulate a fake bitcoin peer. This is what I do when I develop with NBitcoin. (C#)
Basically, I setup 2 peers, the "client" and the "server", I then setup the client to "trust" my server node in tests. (meaning it does not verify block correctness and proof of work)
Then I pilot the server's behavior as I want to test any fork scenario.

I thought about creating a simulated node, though instead I managed to create a fork by isolating regtest nodes, which I will describe in a separate answer. Thanks.


text:
Could Bitcoin dust spam be effectively combatted by actually including it in the block-chain?
After reading this question I got interested in these mysterious spammers who sent satoshis randomly. For what I read, here's been plenty of discussion about this, mainly at Bitcoin talk (discussions here, here and here - in Spanish also here,
here and here) but also somewhere else on the network (as in here).
I got sad when I saw I hadn't received such micro-payments, doubly sad when I read most of such transfers won't ever be included since most miner pools actively avoid collecting such "dust" - so spammer gets his message out for free, even though it may only last for a short while.
And I wondered - why not do include such dust, so that spammers are harmed economically and stop doing it? Plus, plenty of people would get tiny bits of money.
What would be the cons? Plus, if I've understood how Bitcoin operates correctly, spammers would end up paying much more in transaction fees than the amounts they actually send - which makes it doubly mysterious to me why not include them.

why not do include such dust, so that spammers are harmed economically
  and stop doing it?

I'm still not sure that would be enough to prevent this kind of spam activity. Even if these transactions were committed to the blockchain, 100,000,000 such broadcasts could be made from 1 BTC, that's a lot of reach for $700.

Good point! However, the downside of not including them is that after some days pass those transactions die - so from the network perspective it's as though they had never happened, in which case they can send yet another 100 million messages, and then some more... basically for free (since the cost of buying the initial Bitcoin is already a sunk cost)

@JoePineda If this actually becomes a problem then most likely what will happen is more and more clients will stop forwarding transactions with less than 5430 satoshis in outputs. Accepting them is completely up to the miners, and they have no incentive to accept something that doesn't pay the fee.

The transaction fees are optional, the sender can choose to include the fees and the miner can choose the include the transaction. Each transaction that is included increases the size of the block which affects how quickly it can propagate and the size of the entire block chain.
So one explanation of why not to include them is because it doesn't profit anyone but the one person that got the dust, and it only profits them a tiny amount. Another explanation is that these total amounts are less than 5430 satoshis, which is the currently accepted smallest possible transaction in the default implementation.

Thanks for your answer! But then, your last paragraph begs the question: Since sending a single satoshi is way below that 5,430 low limit: how come these dusty transactions get propagated at all, then?

Sorry I should have been more clear, the 5,430 'limit' is just a default in the standard wallet. Other implementations may allow it and repeat those transactions.


text:
How does a difficulty increase affect a miner's income?
At the time I write this, there are a lot of people getting into Bitcoin mining for the first time. Many buy ASIC hardware and are later surprised that their mining income suddenly drops due to a difficulty increase.
If I mine X bitcoins per day, then the difficulty goes up Y percent, how many coins do I get per day after this?
For instance, if my hashrate brings 1 BTC per day and the difficulty rises 30%, what is my average daily mining income with the same hashrate after this change in difficulty?

Your profit relates to the amount of hashing power you contribute to the network. Since your mining power is constant, your share of the total hashing power decreases relatively when the network's hashing power increases. I.e. we can deduce the following formula:
newProfit = currentProfit * currentDiff/newDiff.
At a currentProfit of 1BTC/d and a 30% increase in difficulty, you get:
(1BTC/d)*100/(100+30)= (1BTC/d)/1.3 = 0.76923077 BTC/d
i.e. your profit decreases by ~23%.

The target, which the difficulty is derived from, determines how hard hashing should be so that one block is found every 10 minutes, on average.
A 30% increase in difficulty means the network was finding blocks 30% too fast over the last 2015 blocks so as a result, your profits (assuming no other miners join or leave the network) will be about 23% (1 - 100/130) less.  For example, 1 GH/s nets about 0.00098431 a day at the current difficulty.  With an increase of 30%, this would mean about 0.00075716 per day,  0.00098431/0.00075716 is about 130%.
However, with all the mining equipment being added between blocks, it's likely you'll make a lot less.

With the increase in difficulty there is also a rise value of BTC that helps compensate for the decrease hash rate. Without miners Bitcoin would not see the completion of transactions therefore it seems unlikely for miners to go unpaid.

No, not necessarily. The price of Bitcoin constantly fluctuates and is usually unrelated to the difficulty. There may be a correlation, but there is no guarantee.


text:
Is pruning of the merkle tree implemented in the bitcoin android wallet?
I know that satoshi's client doesn't prune, because we need to store all the transactions so that we can send them to other nodes.  But does this android bitcoin wallet from de.schildbach prune?  Space on a smartphone is at a higher premium so it seems like a good place to prune.
And how much space would pruning save?  Has it ever been checked?

Which android bitcoin client?

https://play.google.com/store/apps/details?id=de.schildbach.wallet&hl=en

That wallet is using bitcoinj as its client which implements a "simplified payment verification" mode.
Here's what the client does in this implementation:

Connects to a trusted node.
Downloads only the block headers.
Validates the headers.

Do they chain back to genesis block?
Is difficulty high enough?
Do I trust this node enough?

Downloads only the transactions that yield ownership to your addresses.
Sufficiently deep block headers are thrown away.

Resource usage in this implementation just depends on your own sent/received transactions.

As of October 2012 (block 203258) there have been 7,979,231 transactions, however the size of the unspent output set is less than 100MiB, which is small enough to easily fit in RAM for even quite old computers.

In other words, almost 8 million txns in Oct2012 could be consolidated to 100MiB just by throwing out txns that had no spendable outputs.
So you can imagine how little space it takes just to store transactions relevant to your addresses.

https://code.google.com/p/bitcoin-wallet/
http://code.google.com/p/bitcoinj/source/browse/core/src/main/java/com/google/bitcoin/core/BlockChain.java#26
https://en.bitcoin.it/wiki/Scalability#Storage
https://en.bitcoin.it/wiki/Scalability#Simplified_payment_verification


text:
Bitcoin Mining ASICs used for cryptographic application? Rainbow tables?
What is the potential that the ASICs being developed for mining could be used for other cryptographic applications such as building rainbow tables? I know that for instance those that crack GSM with rainbow tables utilize systems similar to those for mining for building rainbow tables and decrypting GSM packets. Such systems are also used for building MD5, SHA, rainbow tables for traditional password/shadowfile cracking.

TLDR; forget about it.
The ASICs are optimized for bitcoin mining. Not just Sha256(Sha256(x)) hashing, but very specifically bitcoin mining. You can't even use them for the Sha256(Sha256(x)) hashing in the rest of the bitcoin system, like hashing transactions.
The ASICs are made for hashing 80 bytes, where you give them the midstate from hashing the first chunk (64 bytes), and 12 bytes from the second chunk. They then try all variations of the last 4 bytes to try and find a hash that starts with 4 zero-bytes. Only values that result in the 4 zero-bytes are reported at all. That's basically what mining is.
The ASIC could aid in password cracking if:

the hashes are generated with sha256(sha256(x))
salt + password = 80 bytes
the hash starts with 4 zero-bytes

I don't even think it would help there since password cracking requires that you find a password with the exact hash whereas an ASIC seeks only a hash with a value less than or equal to another one.

If the password hash starts with 4 zero-bytes like I wrote above, then it would find those candidates, which would be a great help. However you will likely never be in a situation where these prerequisites are present.

No you wouldn't. A hash that starts with 5 zero bytes, for instance, would meet the goals of the ASIC and it would stop. It never seeks an exact hash value, only one that starts a certain way which is why you can't recover passwords with it.

It doesn't stop but continues and reports more results. At least the ASICs at the time this answer was written. However since then there are now ASICs that don't scan the entire nonce-range, and ASICs work so quickly that they are not able to report all nonces that result in 4 zero bytes. These new ASICs are even more useless for password cracking.

ASICs for BTC mining are optimized for one calculation: SHA256(SHA256(x)). They can not be used to calculate MD5(x) or even SHA256(x), so unless you use double-SHA256 to hash your passwords, you should not be worried.

Assuming one does use double-SHA256 i'd be interested to know the effect of using a Bitcoin ASIC miner to attack such passwords. What I am trying to gauge is the side-effects of such innovations for other purposes.

If you use double-SHA256 for password hashes and someone is able to download your database, an ASIC miner chip would make bruteforce cracking these passwords a lot faster. The hashrate of the chip is the rate at which they can attempt to find the password for a hash.

The question though is how does this change current risk models for double-SHA256 based authentication designs? Should people avoid using it? Would double-SHA be more secure now than double-SHA256?

Right, using double-SHA256 as a hash function in security systems is a bad idea going forward. Applying a hash function twice usually does not make a lot of sense anyways, if you want a stronger hash just use SHA512. For more info on the SHA family of hash functions, see http://en.wikipedia.org/wiki/Secure_Hash_Algorithm

You probably shouldn't be worried about double-sha256 passwords either since for the purpose of password cracking you're looking for a collision in a 2^256 key space. The current gen ASICs make that much faster, but an exhaustive search of that large a key space with a 60GH/s ASIC would still take 6.1e+58 years

How would 6.1e+58 compare to a double-SHA1 hask cracking rig (non asic or fpga)?

@bananer: The hashrate is the rate at which they can attempt to find the password assuming they can load candidate passwords to the chip at that rate, which would be nearly impossible with an ASIC meant for mining. They just don't have high-bandwidth paths into their mining cores because they have no need for them and that would take up lots of space.

A potential use I can think of is for aiding mailing servers using a variant of HashCash to validate they're not spammers: should HashCash users start using SHA-2 instead of SHA-1 for the proof-of-work, then ASIC miners could be reused to aid mail severs send authenticated mails to large distribution lists, thus reducing the cost for honest corporate (or even personal, should the need arise!) massive mailing.
Of course, this also means spammers could simply get these machines to reduce the chance their mails get identified as the garbage they are - buying an ASIC would simply become another "investment" needed to start a spamming business. So here goes the egg and chicken problem...

Lets say you want to build a rainbow table of double-sha-256, you then want to calculate 2^256 hashes which is 1.579*10^77 hashes lets divived by on the average ASIC power we have (one at 30Ghash/s):

1.579*10^77 hash / 30,000,000,000 hash/s
  3.8596*10^66 seconds
  Or 1.2238*10^59 years

Which is, correct me, more than the time of the UNIVERSE!
And if we took the actual bitcoin network power (@ about 20 Thash/s), we would still wait 1.8358*10^56 YEARS. Which is not even really faster.
So well good luck trying to do a rainbow table, I guess.

Each of the 1.579e77 hashes would also need 32 bytes (256 bit) in your database. What is that, like a galaxy worth of microSDs?

Yeah I didn't thought of that or what would be the space needed in 1 TB harddrive?

It's still useful to build rainbow tables for passwords, even if you can't cover all cases, as most people use short passwords without special characters. I bet there are ASICs out there built to do it too...

Highly Irregular raises a valid point... How difficult would it be to create a rainbow table for all passwords with just English alphanumeric chars (including whitespace) of, at most, 15 characters long? Using an ASIC to do the hashing, this starts to look feasible, probably doable in some months - after which such rainbow tables could be used to scan the addresses, looking for weakly created private keys...

You would not need a rainbow table at all if you've got a very fast ASIC. In the end the computing power would simply be high enough that it could fill a very large table pretty fast. Especially if a sufficiently large & random salt is used, you'd need a rainbow table per password, which kind of defeats the purpose of such an expansive & expensive solution.

I guess the goal is to try to dictionary attack the password (or brute force over a short range, say 8 characters), which limits the number of tries you need to do.

TL;DR: Yes, bitcoin ASICs can serve cryptanalytic purposes.
They could be used to speed up a cryptanalytic attack that requires a lot of random bit-strings whose SHA256 begins with many zero bits. Bitcoin miners will report bitcoin header blocks M such that sha256(sha256(M)) begins with a prescribed number of zeros. In particular, this means that M'=sha256(M) is a random 256-bit blob whose hash begins with many zero bits.
One particular situation where this can be useful is the computation of a 3SUM on sha256. See this page for more details.


text:
Can a miner set the EXACT timestamp of a block?
I know that miners can adjust the timestamp of a block, but can they control the exact timestamp datetime (within the +-2h rule)?
For example:
A miner mines a block at 2013-08-08 08:01:34.
Can the miner change the block timestamp to 2013-08-08 08:08:08?

In theory this is certainly possible - but they have the decide what timestamp they want before starting to mine. Is your question about theory or practice?

So the answer is yes --- For my question this is theory only. This doesn't really affect bitcoin but the coins that are using a moving average to calculate the difficulty. If the moving average is short enough and a miner have majority of hash power the miner could create a chain of blocks with 0s timestamp apart and mess up the difficulty. --- very unlikely though.

And also this means that you can not use the block timestamp as a random time function. -- thank you Pieter for you answer.

Bitcoin miners can construct the block header, including the timestamp, however they want, as long as it adheres to the consensus rules. The shift you describe is well inside the 2 hour timerange, so it can be done when setting out to mine the block. It cannot however be done once the block is mined as the timestamp is part of the header, which is hashed into the PoW, hence changing the timestamp would invalidate the proof of work.
Most miners however prefer to increase/decrease the timestamp in order to have a simple way to alter the header, thus more hashes to compute. This is sometimes called time-rolling and is performed on top of the nonce-rolling.

Your answer might be confusing, as the asker seems to propose to change the timestamp after a block is found. You might want to clarify that this is not possible (although, I think I have been clear on that in my answer).

Thanks for the correction, I must have missed the fact that he is asking for a posteriori modifications of a block.

The timestamp is part of the input for the mining process.
So, the miner can set an arbitrary timestamp, but must decide before hashing what timestamp he wants a potential block to have.
He cannot change the timestamp after finding a block, because the timestamp is part of the block, and a different one wouldn't be valid. To change the timestamp, he would have to start over mining.


text:
In practice, are redeemScripts commonly reused?
In regards to P2SH-P2WSH transactions, are Txout-script values identical between transactions?  Is it reasonable to expect a business or vendor that accepts bitcoin to be using the same redeemScript for all transactions and use the same Txout-script value? Would users benefit from this value rotating?

Do you mean the same policy being reused, or the actual script being reused? (usually the keys will change, but all of them will be 2-of-3 or something like that)

@PieterWuille Both, but this is a technical question.

It is considered a bad practice to reuse addresses (which are representative of specific output scripts). Reused addresses reveal that a recipient in otherwise unrelated transactions is the same entity. Additionally, it is considered good practice to provide a fresh address for each payment attempt, as it allows the addresses to take the character of invoices and uniquely identify the context of the payment executed by the transaction output.
In practice, addresses unfortunately frequently get reused. In a blog post from February 2022, BitMEX Research details that at the time of writing about 50% of transaction outputs were being sent to previously used addresses. The blog post goes into additional statistics surrounding the topic.

Let's look at an example of this type of transaction:
The following example is the same 1-of-2 multi-signature P2WSH script, but nested in a BIP16 P2SH output.
witness:      0 <signature1> <1 <pubkey1> <pubkey2> 2 CHECKMULTISIG>
scriptSig:    <0 <32-byte-hash>>
              (0x220020{32-byte-hash})
scriptPubKey: HASH160 <20-byte-hash> EQUAL
              (0xA914{20-byte-hash}87)

So, let's say the user that created this script accepts multiple payments to this same script. In order to spend the Bitcoin received at the script, they must provide the same redeemScript, but one thing will change with each transaction, and that is the <signature1>. Since the transactions are not exactly the same each time, the data being signed will change, and even though it was signed with potentially the same key (could use key2), it will produce a different signature.
This isn't necessarily bad, but it is more common to see a business or vendor generate new script/addresses for each payment they receive so it can be easily tracked and verified.


text:
How to decode private key from Android Bitcoin Wallet?
I want to import my private key from the android's Bitcoin Wallet (the one created by Andreas Schildbach) but it can export it only in an encrypted way.
How do I decrypt the file so I can import the key to my Bitcoin Qt?

possible duplicate of Is there a known way to export my wallet private key from the "Bitcoin Android" app (com.bitcoinandroid)?

from: https://github.com/schildbach/bitcoin-wallet/tree/master/wallet
The backup file is encrypted using your chosen password. You can use OpenSSL to decrypt:

openssl enc -d -aes-256-cbc -a -in <filename>

The instructions have been moved to: https://github.com/bitcoin-wallet/bitcoin-wallet/blob/master/wallet/README.recover.md

If anyone is trying this in 2017, openssl has now defaulted to use SHA256 instead of the MD5 assumed in the older answers. Add "-md md5" (no quotes) to your openssl command line string.
https://superuser.com/questions/1245384/openssl-bad-decrypt-between-0-9-8o-and-1-1-0f
For example, originally without that MD5 option I was seeing:
$openssl enc -d -aes-256-cbc -a -in bitcoin-wallet-backup-2017-09-28 -out decrypted
enter aes-256-cbc decryption password: ******
bad decrypt
140031244338432:error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad decrypt:../crypto/evp/evp_enc.c:535:

But then with the MD5 option:
$openssl enc -d -aes-256-cbc -a -in bitcoin-wallet-backup-2017-09-28 -out decrypted -md md5
enter aes-256-cbc decryption password: ******

It runs successfully and creates a file called "decrypted" which is mostly binary data but starts with ^Vorg.bitcoin.production^R and contains your 12 word mnemonic as text near the top of the file.

In this case simply use the openssl-1.0 bindings which enforces the old encoding that changed when using recent version 2 binaries:
openssl-1.0 enc -d -aes-256-cbc -a -in bitcoin-wallet-backup-2017-09-28

I got a warning *** WARNING : deprecated key derivation used. Using -iter or -pbkdf2 would be better.  but the decryption of the secret keys worked fine, though!

This script seems to do the work
https://github.com/jleni/wallet-decrypt
You just need to create a backup and it will give you back a mnemonic that you can use in electrum or electrum cash.

This guide was the only one that worked for me. The mnemonic phrase didn't work on Electrum nor Electron Cash, but the exported private key as described here did:
https://bitcointalk.org/index.php?topic=2061691.0

I go a bit fancier:
set /p xin=
set xout="%xin%.txt"
openssl enc -d -aes-256-cbc -a -in "%XIN%" -out %XOUT%

But basically you want to name a file for the output and also the -k flag allows PASSWORD directly to be entered, like so:
openssl enc -d -aes-256-cbc -a -in "INFILE" -out "OUTFILE.txt" -k PASSWORD ,
where CAPS is the variable. Save above 3 lines or single openssl cmd into a *.bat (WinBatch file)

@SekeratKejunG See this gist. The 3 lines are a batch file. You can just skip straight to openssl enc -d -aes-256-cbc -a -in "encrypted" -out "decrypted.txt". encrypted is the base64 AES encrypted text file, decrypted.txt will be a Litecoin wallet in text. If the files in the gist decrypt but your wallet isn't decrypting, then something else is wrong


text:
Is it possible to speed up block chain syncing with a miner?
Syncing the client with the network can take some time. As I have to do this fairly often, it quite bothers me, especially when on slow devices. (A Pi can't do it in a week.)
I don't know exactly what the client does when syncing. Does it verify the block hashes? Transaction hashes as well? If it does hashing, a miner should be able to speed it up. I noticed periodic CPU bursts of the client, so that's probably when the hashing is done.
So, I happen to have one of those little Block Erupter USB Miners. Is it possible to setup one of these to speed up syncing?

Syncing means:

Downloading the blockchain.
For every transaction, check that its inputs actually reference earlier unspent outputs, and that the signatures match.

Hashing is a completely negligible part of the process and a mining device will not help you. Computationally the major work is verifying ECDSA signatures, and you also need disk access to find the past outputs. Using an SSD will make things faster.


text:
Are there numbers on how many pre-orders (or total GH/s) ButterflyLabs already received?
The whole Bitcoin world is waiting for ButterflyLabs' entree in the mining scene.
Their promised products are quite revolutionary and so they can cause great fluctuations in the BTC price when they finally arrive.
To know how the Bitcoin network would be affected, it would be very useful and interesting to have an idea on how much hashpower will enter for mining.
Calculations of the profits from their miners with the current difficulty are absurd (like a $ 1,299 miner being paid back in just 4 days) and make no sense.
When making estimates for your profit you need also to consider changes in the difficulty, which are predicted to be enormous when ButterflyLabs' hardware launches.
So, to come to my question, I know that Butterfly Labs is not the most transparent company and that they failed to keep most of their promises. But did they ever mentioned numbers or approximations of how many pre-orders they already received? Or how much hashpower they would account for?

I found this :
BFL SC Pre-Order Information
So. 6000 units ordered from june 2012 to june 2013. 100 were shipped, in june 2013. 5900 to go.

The link doesn't include shipped total, are we supposed to manually count the green lines? O_o

That's the best you're gonna find. Steven/user5560 did a good job... Yes you could count the green lines like everyone else, or make yourself a script... but BFL does not announce total orders and the likes. It is all hearsay beyond what they tell you(which is nothing)


text:
Trying to use Block Erupters with Ubuntu 13.04
I'm trying to Mine with ASICMiner's Block Erupters on Ubuntu 13.04. I've installed everything (bitcoin-qt, cgminer, bfgminer, I've got the block erupters in usb hubs hooked up to my ubuntu box).
But neither CGMiner, nor BFGMiner detect the block erupters...
When I go to /dev I see 18 ttyUSB[0-17] devices, I guess that's probably them, but I don't really know how to tell if my system can even see them.
I have the hubs they're plugged into hooked up to another usb hub so that you've got the first hub coming out of one usb port from the box and the ANKER hubs that hold the block erupters are both hooked up to that. I don't know if that's messing it up.

to determine if they're being detected properly, use the 'lsusb' command.
Here's what they should look like if your system is detecting them properly (I run mine in a VM running Ubuntu:
$ sudo lsusb
[sudo] password for majorminer:
Bus 002 Device 002: ID 0e0f:0003 VMware, Inc. Virtual Mouse
Bus 002 Device 003: ID 0e0f:0002 VMware, Inc. Virtual USB Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 004: ID 0e0f:0008 VMware, Inc.
Bus 002 Device 005: ID 10c4:ea60 Cygnal Integrated Products, Inc. CP210x UART Bridge / myAVR mySmartUSB light
Bus 002 Device 006: ID 10c4:ea60 Cygnal Integrated Products, Inc. CP210x UART Bridge / myAVR mySmartUSB light
Bus 002 Device 007: ID 10c4:ea60 Cygnal Integrated Products, Inc. CP210x UART Bridge / myAVR mySmartUSB light
Bus 002 Device 008: ID 10c4:ea60 Cygnal Integrated Products, Inc. CP210x UART Bridge / myAVR mySmartUSB light
Bus 002 Device 009: ID 10c4:ea60 Cygnal Integrated Products, Inc. CP210x UART Bridge / myAVR mySmartUSB light

Make sure they're detected by the miner by using sudo bfgminer -S all -d? -- I found this to be a lot better on linux than cgminer.
Then start your miner with sudo bfgminer -o $pool.goes.here -u $USER -p $PASSWORD -S all

Great, wow you saved my butt. Turns out the command I needed was sudo bfgminer -S all.


text:
Where do I get my username and password for solo mining?
I downloaded Bitcoin-Qt and synched.  I downloaded pyminer to help me understand the mining process.  But I need a username and password.  Where do I get them for solo mining?

Add a file named bitcoin.conf to your data directory with the following values:
 # server=1 tells Bitcoin-QT to accept JSON-RPC commands.
 server=1

 # You must set rpcuser and rpcpassword to secure the JSON-RPC api
 rpcuser=user
 rpcpassword=<a password you make up>

Tell pyminer to mine at localhost with the password/username combo you just used.

I'm on OSX.  Where does the bitcoin.conf file go so Bitcoin-QT will pick it up?

@dacracot In your data directory. See this page.

You just make them up. They just need to match on both ends (the bitcoin program and the mining program).

But the Bitcoin-Qt program never asked me to create one.  I looked for it, and found nothing.

It's in the documentation.

While I appreciate your response and that I should RTFM, so much documentation and terminology is rather obtuse for someone new to the process.  A more directed response, as given by Nick ODell, saved me from reading much that was not applicable and solved my problem.


text:
Blockchain long run issue
the last days I have thinking about the bitcoins and the technical issues that can have this currency, I am a computer science guy, with many interest in the global economy.
The first question that I want to ask is about the blockchain, the file that store all the transactions done in the network, the problem is that the current size of this file is about 7 GB, with only 100.000 bitcoin accounts, something insignificant to the global economy, still insignificant for a little country of third world.
What will happen when exists 10 , 100 or worse 1000 million of accounts, what will be the size of the blockchain file?.
If this file grow and grow this is not problem for the current tecnology, is more a problem againts the philosopy of bitcoin, because not all the people could be have the file in their own computers, then in the long run the system will tend to transform in something centralized, where only some organizations or very rich people would have a copy of the blockchain file, and the system will be more susceptible to be shut down if some power entity decides to do that.
What do you think about?, is like I am thinking? or am I missing some one about the design of bitcoin?.
Thank for your answers.

This is explained in Satoshi's original paper:

Basically, the block hash does not contain the hashes of the individual transactions, rather it contains the root of the Merkle tree of the hashes. Once all the bitcoin outputs of a transaction have been fully spent, then there is no need for the original transaction, and hence its branch is chopped off from the Merkle tree. As time passes, all the branches get chopped off and one is left with just the root.
So, let's say someone gives you 1 BTC in transaction A (which has no other outputs). You give it away in transaction B to someone else. After a few more blocks have been generated, I have no reason to doubt that transaction B is valid and since A cannot be referenced anywhere else (it is already spent), it is safe for me to remove A from my blockchain.
Of course, some entities may keep the entire chain but this is not strictly necessary for bitcoin to work.

Great info I will definitely going to read the paper before do more question, thanks

Sorry to unbury such an old question, but I really don't understand the concept of "fully spent" bitcoin ouputs. Could you please elaborate it in your answer?

@HenriqueBarcelos A bitcoin is just a portion of an output of a transaction (transactions can output to multiple addresses) . Subsequent transactions may refer to this transaction as an input. When they do, the original output was "fully spent". I suggest looking into how transactions work; this is a fundamental concept.