Blockchain.info wallet unusable for almost 36 hours now

[v3miner]

I have a balance in a blockchain.info wallet and it simply will not let me send BTC out no matter what I do.
I figured I just needed to wait it out for something to get caught up somewhere, but it's not budging
I even tried importing the wallet into a new blockchain.info wallet, and to my desktop client, no dice.

I keep getting an insufficient funds message after "Getting Unspent Outputs", it says I only have .0000005
in my account, although the balance shows 3.58 for more than 36 hours. It's completely jacked.

I sent .01 BTC to myself from the desktop client and the transaction went through but it's freaking gigantic
with tons of extra hashes.

I'm really confused about this.

Has anyone else had this problem?

[1714143186]

1714143186

[DannyHamilton]

I sent .01 BTC to myself from the desktop client and the transaction went through but it's freaking gigantic
with tons of extra hashes.

That happens from playing lots of SatoshiDice (or any other situation where you might receive lots of small transfers to your address).  Each transfer that you receive has to be spent individually.  There is no way to "combine" them into a single input without spending them each individually.

Most of the bitcoin wallets require a transaction fee on any transaction that is larger than 10 kilobytes.  I'm not sure (you haven't provided enough details to tell), but I suspect that the necessary transaction fee is what is getting in the way of you sending the bitcoins.

When you sent that "freaking gigantic with tons of extra hashes" transaction from the desktop client, it looks like you sent 0.01 BTC (or possibly 0.02 BTC) and paid a 0.0345 BTC transaction fee.

[coqui33]

That happens from ... playing lots of SatoshiDice (or any other situation where you might receive lots of small transfers to your address).  Each transfer that you receive has to be spent individually.  There is no way to "combine" them into a single input without spending them each individually.

Could you please suggest a source where I could learn more about this limitation? I was thinking about accepting BTC on my book-sales website. But this will result in my receiving "lots of small transfers" as people buy books. The proposed change to accepting BTC on my sales website will be pointless if I cannot combine the BTC revenue into a single BTC balance,

[DannyHamilton]

That happens from ... playing lots of SatoshiDice (or any other situation where you might receive lots of small transfers to your address).  Each transfer that you receive has to be spent individually.  There is no way to "combine" them into a single input without spending them each individually.

Could you please suggest a source where I could learn more about this limitation? I was thinking about accepting BTC on my book-sales website. But this will result in my receiving "lots of small transfers" as people buy books. The proposed change to accepting BTC on my sales website will be pointless if I cannot combine the BTC revenue into a single BTC balance,

Bitcointalk.org is a great place to learn about it.  I'll explain a bit below.  Post any further questions you have about it and I'm sure that someone (maybe even me) will answer.

Lets assume for the moment that you are collecting at least the equivalent of 1 USD for each book.
Furthermore, lets assume every input in your wallet is one of these book sale transactions.

At today's exchange rate, each output that you receive will be approximately 0.05 BTC.

Now lets assume that you want to spend 50 BTC (1000 USD) from this book sales wallet to a single output address.

Each input is approximately 180 bytes and you will need 1000 of them, so your transaction will be 180,000 bytes in size.
The current transaction fee is 0.0005 BTC per kilobyte.  So you will pay about 0.09 BTC (1.80 USD) in fees to send the 50 BTC (1000 USD) transaction. This works out to approximately a 0.18% fee.

Now imagine that you are playing Satoshi Dice, where every losing bet sends 0.00000001 BTC to your wallet.
Imagine that you've played a lot of Satoshi Dice and all you have left in your wallet is 0.00005 BTC (0.001 USD) of these 0.00000001 BTC outputs.
You decide to spend this 0.00005 BTC.  This is 5,000 inputs at 180 bytes each, so your transaction will be 900,000 bytes in size.  At 0.0005 BTC per kilobyes you'll need approximately 0.45 BTC in fees to send the 0.00005 BTC.

If you are really concerned about the extremely small fees that business transactions larger than 0.01 USD will eventually incur, you can make an effort to combine your outputs on a regular basis. Create a second wallet with an address you'll use as a "consolidation address".  After every 50 transactions (or something less if you prefer), send the total balance (or most of it) from the business wallet to the "consolidation address".  This will create a transaction with 50 inputs (or less if you do it more often).  50 inputs at 180 bytes per input is 9,000 bytes, leaving 1000 bytes for your output and any overhead/headers I may not have considered.  Since transactions less than 10,000 bytes in size don't automatically require a fee, this should consolidate the entire balance into a single output in the "consolidation address".  I suppose that every 2,500 transactions you'll want to send the balance from the "consolidation address" to a "re-consolidation address", since at that time you'll have 50 outputs at the .consolidation address". (and after 125,000 transactions you may want to consolidate the outputs at that address?)

Note that transactions that exceed 10,000 bytes are not the only type of transaction that incurs a fee.  The bitcoin protocol as currently implemented in the reference client and several other wallets also demands a 0.0005 BTC fee if any output is less than 0.01 BTC.  It also requires a fee if the inputs are not sufficiently aged.  I'm not sure, but there may be another fee trigger as well.

[coqui33]

Thank you very much, DannyHamilton! Let me see if I understand.

When address XYZ sends out its balance, the outgoing transaction is of a size such as to contain data about each of the incoming transactions that created the balance in the XYZ address.

100 xfers --> [addy1] --> 1 xfer w/ 100 inputs --> [addy2] --> 1 xfer w/ 1 input --> [addy3]

And so, for example: One hundred 1-BTC transactions come into addy1. When addy1 sends one 100-BTC transaction (its balance) to addy2, that addy1-to-addy2 transaction's size includes info about each of the 100 inputs that came into addy1. But when addy2 sends its 100-BTC balance to addy3, the addy2-to-addy3 transaction includes only one input. Is that the way it works?

If so, this brings up another hypothetical question. To make sure that I understood. Say that I invest in BTC with dollar-cost averaging. I buy a fixed USD value of BTC every Wednesday and put each batch of newly purchased BTC into the same address. If I spend it all after one year, the outgoing transaction will contain 52 inputs. But if I wait 10 years to spend it, the outgoing transaction will contain 520 inputs. Right?

[DannyHamilton]

. . .When address XYZ sends out its balance, the outgoing transaction is of a size such as to contain data about each of the incoming transactions that created the balance in the XYZ address.

100 xfers --> [addy1] --> 1 xfer w/ 100 inputs --> [addy2] --> 1 xfer w/ 1 input --> [addy3]

And so, for example: One hundred 1-BTC transactions come into addy1. When addy1 sends one 100-BTC transaction (its balance) to addy2, that addy1-to-addy2 transaction's size includes info about each of the 100 inputs that came into addy1. But when addy2 sends its 100-BTC balance to addy3, the addy2-to-addy3 transaction includes only one input. Is that the way it works? . . .

You are starting to catch on.  Note however, that while it is always necessary to spend any previous output in it's entirety (there is no way to only partially spend a previous output), it is not necessary to spend all the outputs associated with an address at once.

As an example:
100 xfers --> [addy1]

1 xfer w/ 40 inputs from [addy1] --> [addy2]
1 xfer w/ 40 inputs from [addy1] --> [addy3]
(at this time [addy1] still has 20 unspent outputs)

Also note that a transaction can use inputs from multiple addresses.  So given the example I've just provided above, if all 3 addresses were in the same wallet, the wallet could create the following transaction:

1 xfer to [addy4] using:
10 inputs from [addy1]
1 input from [addy2]
1 input from [addy3]
(at this time [addy1] would still have ten unspent outputs, all outputs at [addy2] and [addy3] will have been fully spent, and [addy4] will have one new output)

If so, this brings up another hypothetical question. To make sure that I understood. Say that I invest in BTC with dollar-cost averaging. I buy a fixed USD value of BTC every Wednesday and put each batch of newly purchased BTC into the same address. If I spend it all after one year, the outgoing transaction will contain 52 inputs. But if I wait 10 years to spend it, the outgoing transaction will contain 520 inputs. Right?

If you spend the entire balance in a single transaction, and that address was the only address in the wallet, and no other transactions were received to or sent from that wallet during that time, then yes you are correct. (actually, since 365 is not evenly divisable by 7 and there will be at least one and maybe two leap years, there should be a year with an extra Wednesday so after 10 years you should have as many as 521 inputs).

[coqui33]

Ahhh.

You wrote, "...it is always necessary to spend any previous output in its entirety (there is no way to only partially spend a previous output)..."

This is why "change" comes back, isn't it? The light is starting to dawn!

The reason that I asked about addresses, rather than about wallets, is that looking only at addresses makes things easier to understand, for me at least.

Also, I do not understand by what criteria or logic bitcoin clients choose from which address in the wallet to spend, and into which address to receive change. Until I do, I prefer to control this myself. This is not a question, simply an expression of discomfort that many wallets hide too much beneath the cowling.

Again, thank you so much for your patient explanations.

[DannyHamilton]

Ahhh.

You wrote, "...it is always necessary to spend any previous output in its entirety (there is no way to only partially spend a previous output)..."

This is why "change" comes back, isn't it? The light is starting to dawn!

Now you're really starting to catch on.

The reason that I asked about addresses, rather than about wallets, is that looking only at addresses makes things easier to understand, for me at least.

Certainly, but it is important to remember that a wallet has multiple addresses, and unless you are using a wallet that has "coin control", you don't get to choose which addresses the wallet pulls its inputs from when generating a transaction.  It is quite likely that the wallet will pull inputs from multiple addresses (including change addresses)

Also, I do not understand by what criteria or logic bitcoin clients choose from which address in the wallet to spend,

I'm not certain exactly how the decision is coded.  I'm not happy with the current implementation in most wallets, but I'm not frustrated enough with it yet to attempt to create my own algorithm.

and into which address to receive change.

This is very dependent on the wallet.  The reference client (Bitcoin-Qt) always gets a brand new address every time it needs a "change" address, and it doesn't tell the user what that address is.  It keeps it hidden in the wallet.dat file. I believe there are other clients that allow you to specify a "change" address.

Until I do, I prefer to control this myself. This is not a question, simply an expression of discomfort that many wallets hide too much beneath the cowling.

Which requires a wallet with "coin control"  I'm not sure if Armory, Electrum, or MultiBit allow this level of control.

Again, thank you so much for your patient explanations.

No problem.  Let me know if there is anything else that you need explained.

[CurbsideProphet]

Sorry to interject, very interesting conversation.  If this is the case, how does sites like SatoshiDice continue to function?  Wouldn't the transaction expense be completely eating away at their profits due to the sheer volume of input/outputs?

[DannyHamilton]

Sorry to interject, very interesting conversation.  If this is the case, how does sites like SatoshiDice continue to function?  Wouldn't the transaction expense be completely eating away at their profits due to the sheer volume of input/outputs?

I've never looked too closely at how Satoshi Dice is running their business.  I would assume that they have custom created software that generates transactions to combine the outputs from multiple bets that they win into ever larger single outputs.  I would assume that they do this often enough to ensure that the "combining" transactions that they create are never larger than 10,000 bytes.  I believe that Satoshi Dice also reduces the winning payouts by 0.0005 BTC to pay the 0.0005 BTC fee on the transactions that they send to winning players:

On a win or a lose a transaction fee of 0.0005 is subtracted from the payment amount. If this makes the payment amount zero or less the payment is set to 0.00000001. In the event that the transaction costs us more to send back to you, we pay the fee over 0.0005.

Note that Satoshi Dice doesn't have any 0.00000001 BTC inputs, only 0.00000001 outputs.  The minimum bet on any of their games is 0.01 BTC, which ensures that all of their inputs are at least 0.01 BTC.  You can combine 55 inputs of 0.01 BTC (for a total of 0.55 BTC) in a single transaction without exceeding 10 kilobytes and triggering a fee as long as the inputs are sufficiently aged and all outputs are at least 0.01.

[v3miner]

Hey guys,

I can't even send .01 out to any address FROM the blockchain.info wallet. I'm not trying to move the entire balance.

Are you implying that the required fee to send out .01 would be greater than the entire balance of over 3.5btc?

I can send to it, but then it is stuck in there, so I don't necessarily want to try adding BTC in to transfer out
with a change address.

[DannyHamilton]

. . . Are you implying that the required fee to send out .01 would be greater than the entire balance of over 3.5btc? . . .

I was just commenting on where you said:

. . . I sent .01 BTC to myself from the desktop client and the transaction went through but it's freaking gigantic
with tons of extra hashes.

I'm really confused about this . . .

Explaining why your transaction was "freaking gigantic with tons of extra hashes" and pointing out that you paid a 0.0345 BTC fee to send that 0.01 BTC.

I'm not sure if transaction fees are the reason that you can't send from blockchain.info.  I don't know enough about the contents of your wallet to determine that.

You can try sending a Personal Message to piuk.  He's the local blockchain.info expert.

https://bitcointalk.org/index.php?action=pm;sa=send;u=17928

[v3miner]

Yeah I PM'ed him on Friday but haven't heard back yet.

And I can see why there were a large amount of hashes there, but they would be related to my desktop client wallet, not the blockchain.info wallet receiving them, so I guess that is irrelevant.

Thanks for your input.

[v3miner]

I got this sorted out after experimentation. Just in case anyone else ever gets themself in this situation here's how you fix it:

We'll call the locked up wallet: Wallet-X
Completely different wallet: Wallet-Y
We'll assume Wallet-X has only one address for sending/receiving.

1. Create 1-2 new addresses in Wallet-X

2. Send some BTC from Wallet-Y to one of the new Wallet-X addresses, wait for the transaction to confirm.

3. Send a little bit of the BTC back to Wallet-Y using the Custom transaction type in the following configuration:
    a.) Set FROM address to the NEW address that shows the BTC you just transferred
    b.) Set the TO address to your Wallet-Y
    c.) Set the CHANGE address to the original Wallet-X address that has the funds locked up.
    d.) Send the transaction and wait for it to confirm.

4. You should now be able to send the BTC that was previously locked up.

I don't know why it's neccesary to do it this way. You would assume that it would be the same as if you sent BTC directly to the original wallet address, but it only works if it comes back as CHANGE, not a direct transaction.

[Bit_Happy]

Thanks for the detailed info, too bad the system is so complex.

[bennett211085]

Done that still insufficient funds when theres enough there wtf

[Wekkel]

Thanks for the detailed info, too bad the system is so complex.

It will be addressed in the software at some point, no doubt about it. First, it needs to become a severe limitation. I learnt the hard way too with messing up a time critical payment due to hundreds of small receipts in my wallet from bitvisitor.com.

[bennett211085]

Thanks for the detailed info, too bad the system is so complex.

It will be addressed in the software at some point, no doubt about it. First, it needs to become a severe limitation. I learnt the hard way too with messing up a time critical payment due to hundreds of small receipts in my wallet from bitvisitor.com.

Is there anything I can do? I will get to use them at some point wont I :/

[BlackLilac Jordan]

That happens from ... playing lots of SatoshiDice (or any other situation where you might receive lots of small transfers to your address).  Each transfer that you receive has to be spent individually.  There is no way to "combine" them into a single input without spending them each individually.

Could you please suggest a source where I could learn more about this limitation? I was thinking about accepting BTC on my book-sales website. But this will result in my receiving "lots of small transfers" as people buy books. The proposed change to accepting BTC on my sales website will be pointless if I cannot combine the BTC revenue into a single BTC balance,

Bitcointalk.org is a great place to learn about it.  I'll explain a bit below.  Post any further questions you have about it and I'm sure that someone (maybe even me) will answer.

Lets assume for the moment that you are collecting at least the equivalent of 1 USD for each book.
Furthermore, lets assume every input in your wallet is one of these book sale transactions.

At today's exchange rate, each output that you receive will be approximately 0.05 BTC.

Now lets assume that you want to spend 50 BTC (1000 USD) from this book sales wallet to a single output address.

Each input is approximately 180 bytes and you will need 1000 of them, so your transaction will be 180,000 bytes in size.
The current transaction fee is 0.0005 BTC per kilobyte.  So you will pay about 0.09 BTC (1.80 USD) in fees to send the 50 BTC (1000 USD) transaction. This works out to approximately a 0.18% fee.

Now imagine that you are playing Satoshi Dice, where every losing bet sends 0.00000001 BTC to your wallet.
Imagine that you've played a lot of Satoshi Dice and all you have left in your wallet is 0.00005 BTC (0.001 USD) of these 0.00000001 BTC outputs.
You decide to spend this 0.00005 BTC.  This is 5,000 inputs at 180 bytes each, so your transaction will be 900,000 bytes in size.  At 0.0005 BTC per kilobyes you'll need approximately 0.45 BTC in fees to send the 0.00005 BTC.

If you are really concerned about the extremely small fees that business transactions larger than 0.01 USD will eventually incur, you can make an effort to combine your outputs on a regular basis. Create a second wallet with an address you'll use as a "consolidation address".  After every 50 transactions (or something less if you prefer), send the total balance (or most of it) from the business wallet to the "consolidation address".  This will create a transaction with 50 inputs (or less if you do it more often).  50 inputs at 180 bytes per input is 9,000 bytes, leaving 1000 bytes for your output and any overhead/headers I may not have considered.  Since transactions less than 10,000 bytes in size don't automatically require a fee, this should consolidate the entire balance into a single output in the "consolidation address".  I suppose that every 2,500 transactions you'll want to send the balance from the "consolidation address" to a "re-consolidation address", since at that time you'll have 50 outputs at the .consolidation address". (and after 125,000 transactions you may want to consolidate the outputs at that address?)

Note that transactions that exceed 10,000 bytes are not the only type of transaction that incurs a fee.  The bitcoin protocol as currently implemented in the reference client and several other wallets also demands a 0.0005 BTC fee if any output is less than 0.01 BTC.  It also requires a fee if the inputs are not sufficiently aged.  I'm not sure, but there may be another fee trigger as well.

Thanks for the information, very helpful.

[bennett211085]

What should I do then? Come on dumb it down a bit for me. How do I make my wallet work sgain??