Topic: zero transaction fee payments (Read 1086 times)

No, the official view is how transactions are actually processed in the code. When a bitcoin node receives a block it doesn't know about it tries going through the transaction list from beginning to end, processing each transaction as it goes. Thus if you are at transaction #4, the block transaction processor simply does not know that the output of transaction #6 exists at all and will reject the whole block if #4 tries to spend the output of #6

In addition remember that an input to a transaction is specified by giving a cryptographic hash of a previous transaction and the hash of a transaction includes the part where the inputs to the transaction are specified. Cryptographic hashes are one way, so if you have the output of a hash function there is no way to find a sequence of bytes for the input that gives that output. Since you can't do that creating a transaction loop just isn't possible.

This property actually lead to an interesting bug. So, ask your self, where did the first input come from? Well, that's the special coinbase transaction, where coins are created in the first place, and the part of the transaction where the input would normally be specified is just a set of bytes that are ignored. Now normally part of the mining process puts some totally random bytes into that input, but it is possible, albeit very hard, for two transactions to have the same coinbase. Thus it's possible for two valid transactions to have the same hash, and what the Bitcoin software does in that case is simply overwrites the entry in the transaction database for the first transaction with the second.

However a fix is being deployed where a coinbase input is now required to always have the block number as the first few bytes, so this won't be possible even in theory for that much longer. Satoshi should have done this in the first place, but contrary to popular belief he wasn't omniscient.

FTFY 

It isn't that you can't, it's just that it isn't very easy to do and probably isn't worth the effort.

Yes, a transaction can have an input in the same block.  The reference client requires that the input come before the output, whether in a previous block, or in the same block.

Philosophically, I prefer to think of all of the transactions in a block as being simultaneous, but officially, they happen in the order they appear in the block.  The official view has a few advantages, such as avoiding loops.

As far as I'm aware, it only requires a reference back to a prior transaction.  It should still be able to reference that transaction if it is in the same block.  If I'm mistaken, hopefully someone with more knowledge of the matter will respond here.

Can a transaction be included into the same block that some of it's input transactions are included?  Doesn't the protocol require that an txin dependency reference back to a prior block?

Available developed, but does not yet exist in a released version:
 - https://github.com/bitcoin/bitcoin/pull/1647

If the transaction had change, the sender could similarly use that to send another transaction with a fee, and any miner with the look-for-parent-transaction-and-confirm-them-too-so-we-can-get-this-fee code (which is probably very few if any at this point) would try to include it.

Similarly, you could try to double-spend the input, and miners that resolved double-spend attempts by taking the one with the highest fee rather than the first transaction they see would attempt to include that one, and take the fee. Again, probably there are few to no miners that do that.

Plus, to do either would involve messing around with raw transactions, as I'm not aware of any UI on any software that makes it easy (though perhaps one of the alternative clients does support it better).

So, there are some theoretical approaches that could help with bitcoin in the future, but probably won't help you before your transaction gets confirmed anyway.

One thing which could be done but I don't think any miners look for this would be for the repient to include a fee in the tx which uses the no fee 0-confirm tx as an input.

Since inclusion of this tx in the block requires the 0-confirm tx to also be included it would be a protocol compatible way to "pay a fee after the fact".  However it requires the bitcoind or other software used by miners to be "smart" enough to notice that tx X has no fee but the output of tx X is the input for tx Y which does have a fee and thus there is value in including both in the memory pool for the next block.

No you can't add a fee after the fact. It depends on the miner and the block and what other transactions need to be added to the block. Some of my 0-fees take 10mins and some take an hour I never had any go over an hour.

If I make a payment with a 0-fee , and then decide it's taking too long, do I have any other option than paying again WITH a fee, and hoping that eventually I will be able to recover my first payment back the payee ?

What would be useful would be a rolling study of how long 0-fee payments are taking (eg how many blocks go past to get included) so I can make an informed decision ?