Thanks for your answer @DannyHamilton. And you are right, my description is rather confusing. So let me express it with an example:

For a given tx the amount to be sent is X btc. The (suggested) tx fee for this tx is Y. However, X = Y, so there's no point in sending out this tx. So my question is, does the above occur for any given value of X?

My arbitrary assumption is also that amounts smaller than X will need more fees to be sent than the actual value, I might be wrong on this one.

What is the absolute minimum amount which, when transferred over a tx, its value equals the tx's suggested fee? Is it the dust amount of 0.00005430 BTC? How is this value affected when that amount is the only unspent output spent in the tx and when there are more unspent outputs than just this one?

Thanks for the tips, guys. gmaxwell you are right: I though it would be rather convenient if the hex-encoded reply of signrawtransactions wouldn't contain any malleable data (which is not true, as kjj explained) so my program would use this internally as a transaction identifier (as tx id can change) so now I will follow your advice and create a hash based on the tx's outputs' address/amount information for that purpose. I will then use this hash to compare it against the one I create for all txs in a block when one of my outgoing txs gets mutated until I track it down and re-associate it internally with its new tx id.

How can I tell if an incoming payment is redeemable by my receiving address's private key through the RPC API?

My concern is receiving a multi-sig tx which I will process in my program but then won't be able to redeem, so for now I call gettxout for every single unspent output not generated by my program and check that the "reqSigs" return parameter equals to 1. Is this the right way to do it?

Great answer, kjj.

So I suppose I have to create a custom hash over my tx's inputs which will never change no matter how my tx gets mutated.

Let's say I've sent out a tx, it got mutated and my program tries to see the original tx's progress (confirmations etc), it sees the original tx orphaned so it should start looking for its mutated version, how do I do this? Scan all txs in the recent blocks and compare their inputs with my original tx's inputs until I get a perfect match? What is the most efficient way to handle this case?

What is the best way (in terms of security and/or resources) to track my outgoing transactions through the RPC API?

I would like to be able to track them down using their tx id and also to have a fallback mechanism for when my outgoing transaction's id changes as a result of a malleability attack.

I seriously don't get why you even bothered to reply to my question since you don't really know the answer and just wanna fool around with semantics and waste your time and ours.

The signrawtransaction command returns two variables:
- "hex", which is a hex-encoded string
- "complete", which is a numeric

The hex-encoded string is essentially a snapshot of the raw transaction at the moment when its inputs are being signed, so my question is, will this hex-encoded string change if the transaction gets modified by a malleability attack?

When calling RPC signrawtransaction it returns a hex-encoded string that contains the raw tx request with its signatures.

Is this string:

• malleable?
• unique?

It is a bit weird that nobody has replied to this very critical question, could somebody please shed some light on this one?

listsinceblock help returns:


I sent a coin to my wallet and a few seconds later I executed listsinceblock 1. My transaction was just broadcasted so it had 0 confirmations, as expected. Note the target-confirmations parameter above which must be greater than 0 no matter what.

So for my test I executed bitcoin-cli listsinceblock 0000000008eb5d53efbb39d2cb9f595e5bd567c295936de5c2282bbb8ef46cf0 1 which returned:


Note that the above transaction has 0 confirmations, however listsinceblock is supposed to operate beyond 1 confirmations (which is weird, as I am polling listsinceblock to get new transactions that are always unconfirmed, after Gavin's tip: http://bitcoin.stackexchange.com/a/2171/11221).

What am I missing here?

That sounds like a good approach, I'll have to check it out ASAP, thank you for bringing it up.

I thought there were some miners who don't follow the rules and can include them in their blocks. Nice..

Yes, the service rolled out only a couple of months ago but this is the way it currently works so we need to readjust its revenue model ASAP! Thanks for your suggestions!

Reading about spending own generated unconfirmed change some time ago I stumbled upon this reddit thread that convinced me that doing so is a really bad idea and could prove catastrophic for any business that allows it.

Now in the bitcoin core 0.9.0 release notes there are some fixes regarding the infamous malleability issue (search for text: "Transaction malleability-related fixes").

My question is:

Is it now safe to spend unconfirmed change generated by my own txs, after the 0.9.0 upgrades?
If not, what is considered to be a safe number of confirmations for this change before I can use it as an input for another tx?

So my service is skimming a tiny 0,001% (1/1,000) fee off every payment that gets through it. Most of the transactions are actually micro-payments so there are thousands of tiny unspent outputs accumulating in the service's wallet. I'm worried now that I will not be able to spent these outputs without having to pay a load of transaction fees and wait for eternity for this payment to clear.

The average btc value of my unspent outputs that come out of the commissions is 100 satoshis (0,000001 btc). That means that if I want to cash out 100 btc, I need to spend on average 100,000,000 of these outputs.

According to: How to calculate transaction size before sending the transaction size is: in*148 + out*34 + 10 plus or minus 'in', which makes my withdrawal equal to: 100,000,000*148 + 2*34 + 10 + 100,000,000 = 14,900,000,078 bytes = 14,9 GB ?! (am I missing something here?)

The maximum block size is 1 MB so I will need to split this transaction in more than 14,900 transactions ?!

A transaction fee of 0.0001 btc per kB is required, so I will need to spend 0,0001 * 1,000 = 0,1 btc for each of these 14,900 transactions which means I will need at least 1,490 btc (to send 100 btc), which is roughly 15 times the amount I'm trying to send!

All these 14,900 transactions will need to be included on different blocks (since they would exceed the maximum block size otherwise) and since one block is found every 10 minutes on average, I will need to wait 14,900 * 10 minutes = 149,000 minutes = 2,483 hours = 103 days = 3 months and a half ?!

Please tell me I got this all wrong. I've really freaked out.