Hi,

This is an issue that is plaguing me since months, and I'd like to ask if there is any solution to it.

Often, when I try to send a large amount of BTC, I get the following message:
error: {"code":-4,"message":"Error: Transaction creation failed  "}

If this error happens, I try sending a smaller amount.  Eventually this succeeds.  There is always a treshold below which the transaction can be created successfully.  However the treshold is not a static value, but rather depends on some internal details of my wallet.  Sometimes the treshold is lower than 1 BTC, sometimes it is near 200 BTC.  After each successful send, the treshold jumps a different value (higher or lower).  I cannot send more than 200 BTC ever anymore since the problem started to appear, and it becomes worse and worse with time.

After googling this forum and other sites, my understanding is that the error occurs because the transaction becomes too complex.  The source of it seems to be "wallet pollution" where many small inputs exist and bitcoind wants to combine too many of them into the transaction.

My wallet file is 2.3 MB, and certainly there may be many small items in it.  However there are also plenty of large items that could be used to form the desired transaction (without reaching the excessive complexity).  Bitcoind seems to use a poor strategy in choosing the inputs from the available ones.

The problem appears accross many versions of bitcoin, including v0.3.x and v0.6.3, and on several machines.  It never appears on a fresh install, only starts to appear after the wallet has grown a lot, and then becomes worse with time.

My questions:

1. Do I have some way to influence which inputs are chosen?  For example, can I choose 10 "virgin" coins for a 500 BTC transaction, instead of thousands of 0.01xxx inputs?

2. Can I somehow view the details of my wallet?  I imagine that I could send the offending small inputs away to a different wallet, if I only knew their exact face value and the order in which they appear in the wallet.

3. Is there any other way to "clean" my wallet, or reorder the items in it so that the offending items will be selected last instead of first?

I am living with the problem, but it gets worse and worse every week.  I cannot ignore it much longer.  Right now I am thinking about this resolution strategy:  Fresh install on a new box.  Try to send 99.9 BTC to the new box.  If fails, decrease the amount by 0.1 BTC and retry (until success). Start over with 99.9.  Continue until the wallet is empty or near empty.  Delete the remaining wallet file.  Obviously this method is costly because of the TX fees involved.

Again I'm looking for a reliable partner who can turn BTC into wire transfers (EUR or USD) on a regular basis.  Specifically I'm interested in a solid, honest, long-term business relationship.

If you are interested, please send me a private message here on the forum.

Hi,

after stumbling upon and reading about this P2SH thing, I can't seem to find the answers to my two principal questions.

1) Will the implementation break compatibility with old solo mining clients?  I assume that when someone is solo mining and producing blocks with an old client, he will just not include the new transactions but everything else works as before.  Or, to the contrary, will his blocks be rejected by the rest of the network as invalid because he didn't update his client?

2) If, as a solo miner with an old client, compiled from source, wanted to vote in favor or against the P2SH, what changes exactly would I have to do to the source?  Note that I couldn't pull the latest source because of dependency hell.  I'd insert lets say 20 lines of code into one place that exists unchanged in the last two years of the source.  But I wouldn't make 20 different changes in 20 places that can't be located in my copy because they exists only in recent code anyway.  Note that I'm not interested in adding experimental P2SH functionality or anything.  This question is strictly about adding the vote cast, nothing else.  What change(s) are necessary for that?

Thanks for taking your time to answer!

After an investment I'm about to produce a considerable amount of BTC.  I want to sell them off on a daily or weekly basis.

However I am not interested in setting up a trading shop myself, and I'd like to hand this off to someone else.  I'm looking for a business partner with good reputation (company papers banks etc).  Specifically I'm not interested in paypal creditcards transfers from dubious origins etc, but rather a solid and long-term business relation.

We'll freeze prices based on public exchange rates, with a margin for your service.

If you are interested, please send me a private message here on the forum.

[1 kw of electricity is turned into 1 kw of heat.]

One thing I wanted to correct since quite a while:  Many people here on the forum say that electricity is expensive in summer, but free in winter.  Why?  Because it can be used for heating, which is necessary in winter anyway, and thus mining is free.

This is not universally true.

If your computer / kitchen / etc is working anyway, and produces surplus heat which you use to heat your home in winter, then this is free heat.  But when the equipment is run only for the purpose of producing heat, then it must be compared to (better) alternatives.  A computer turns electricity into heat similar to an electric resistor. 1 kw of electricity is turned into 1 kw of heat.

(Note that I'm intentionally disregarding the health aspects of the contamination with particles due to air circulation through a computer)

The myth is based on the assumption that this is the best efficieny one can achieve.  1 kw for 1 kw.  However, this is not true.  A modern household air conditioner with heat pump, can achieve an efficiency of 3 to 4.

In other words: With just 1kw of electricity, you get 3-4 kw of heat!

How does this work?  It works in the opposite way than a fridge works.  Air/gas is decompressed (making it very cold) and then warmed by the winter days' outside temperature.  Afterwards it's re-compressed (making it hot) and heats your home.  See http://en.wikipedia.org/wiki/Heat_pump#Efficiency for details.

If your home is in the mid to south area, where air-conditioners are common, and you bought yours in the last few years, then your home can probably already use this technique!

Using your computer to heat your home with electricity is 3 - 4 times LESS EFFICIENT than using such a dedicated electrical equipment.  Even if you don't already possess such an equipment, the cost of it is a fraction compared to a mining rig.

Back to the original argument, winter miners can still claim that the first 25% - 33% of their electricity bill helps heating their house.  But the remaining 66% - 75% is just "for the funs" of mining and nothing else.  Because they wouldn't spend them if they really were after the heating (and not the mining).

Conclusion:  Electricity in winter cheaper, not free.

Today I've learned how the transactions are encoded, which are actually scripts in a forth-like language.  The scripts are "executed" to validate the transactions.  The lack of tight regulation of how a "standard" transaction is to be encoded, allows for many different possible encodings (or forms of expressing) one and the same transaction.

The language is described here: https://en.bitcoin.it/wiki/Script and in fact near the bottom of the page is an interesting example of how to take advantage of the language to achieve a "non-standard" transaction (to a hidden receiver address).  The universal encoding by scripts potentially allows for many other cool features to be implemented.

However, I've also stumbled across a description of past incidents that required addressing by modifications to the client software. It's at https://en.bitcoin.it/wiki/Incidents and most notable is the last paragraph talking about LSHIFT and RETURN bugs.  Apparently, some script commands have been abused to induce errors into the clients.  As reaction, the commands have been disabled (instead of merely been fixed).  Moreso, many other "currently unused" commands have been disabled as well, "for security reasons".

I understand that script engines pose a security risk.

But there are two fundamental questions that immediately form in my mind.

1) If script engines are a security risk, then why is the majority of it still enabled even after reacting to the incident?  Wouldn't it be "safer" to enforce a fixed straight-forward encoding for every single desired form of transaction and do away with the scripts alltogether?  A smooth transition can be achieved easily (I can elaborate if desired).  It would make future incidents impossible, improving security of the software.

2) If on the other hand, scripting is desireable for the purpose of enabling non-standard ways of transacting to be supported by all clients, then it is already broken!  After all, a once "legal" scripting command like OP_XOR is "forbidden" today.  If I had implemented earlier something like "send to hidden receiver address" using OP_XOR, the transaction would not verify anymore in todays client.  It would stop at the illegal instruction, and ignore all further history of the coin (although previos versions of the same software would have accepted it!).

As a programmer, I cannot rely on using ANY scripting command, because I cannot know which may become disabled tomorrow.  Except maybe those which are generated by the majority of the clients in everyday transactions.  And even those could become invalid in the future (for example if scripts are being done away with).  The precedent is here already.

Therefore I ask:  How much can I rely on scripting?  Can I trust that any command that I use in a confirmed transaction, will not be blacklisted in the future?

I also ask:  Can the receiver of my bits rely on my cleverly scripted transaction to be un-revokable?  There's a spin on this, beware!  Let me give you an example.  Bitcoin buries transactions in the blockchain, making it harder to doublespend as time passes.  If I were malicious, I could find a new bug in a script command.  I could use the command to form a harmless transaction (not triggering the bug).  It would work fine in the existing clients and make it into the blockchain.  It would give ownership of my money to somebody else, and it would be confirmed after a certain time.  The receiver of the coin would believe that I cannot undo the transaction.  But possibly I can?   I could publish an evil exploit based on the command that I used in my transaction, and encourage the developpers to disable the command just like they disabled OP_XOR.  The new (fixed) clients would not be able to parse the transaction anymore.  The coin would fall back to me RETROACTIVELY, as I am the last legitimate owner (by the now changed rules).  The validity of the chain of transactions would break at my special script, and I could start a new valid branch by spending the coin again (using valid script commands).

I am aware that this is an example taken to the extreme, but it serves to show how either decisions about scripting security can have unexpected sideeffects.

Opinions on this post?  Or maybe even comments from those involved in the decision of disabling commands?