Recipient paid tx fee

[Steve]

In thinking about p2sh and about the whole topic of the recipient of a transaction being the one who has the incentive to see that a transaction makes it into the blockchain, I've arrive at this potential solution.  Note, for bit-pay (as well as other processors), having the recipient set the transaction fee could be quite beneficial.  We occasionally get very low priority transactions that, while being perfectly valid, take forever to get into the block chain.  It would be nice if we had a mechanism where we could ensure it will get the appropriate priority with miners.

What if instead of transactions being included directly in the block chain, they were instead put into a container that could hold multiple transactions.  A sender could deliver a transaction to the recipient who could then add another transaction that pays a fee.  Loose transaction could move about the network as always, but until they get put into a container, they are ignored by miners (at least for the purposes of inclusion in a block).  There might be other uses for transaction containers.

I realize that this would be a radical change for bitcoin and not likely to happen anytime soon, but I'm curious if anyone has thought of alternative ways of doing this (ideally that preserve the simplicity of the sender just paying to an address without requiring the recipient to communicate anything else up front)?

[Maged]

As long as the sender pays enough to get their transaction relayed (in the long-term, transactions should be sent to the receiver directly), the easiest short-term solution is to update the priority code to consider all transactions dependent on an unconfirmed transaction to be part of the same transaction. Thus, the receiver just has to send the transaction to themselves, but including a good fee this time, and the first transaction would benefit from this.

Long-term, it needs to be possible to pay for another transaction's transaction fee without using the dependency (either through the Bitcoin network itself, or through some out-of-band system). This is why Mike is against P2SH (BIP 12,16,17): the benefits of P2SH are completely null and void if you need to create a dependency on the first transaction. It's a protocol change that's just going to require another protocol change.

[Revalin]

Instead of creating a transaction container and then sending it to the receiver COD, you could simply create a "pay another transaction's fee" transaction type.  There's no need to cryptographically guarantee that the postage is only paid by the recipient, so let anyone throw in some extra tx fee.

On the sending side this would make it simpler - you just send the transaction the same as any other.

On the receiving end you're not forced to pay the extra tx fee until you decide you're tired of waiting and want the transaction mined ASAP, instead of with the "container" method where you'd have to make that decision at the time you send the tx to the network.

[Maged]

Instead of creating a transaction container and then sending it to the receiver COD, you could simply create a "pay another transaction's fee" transaction type.  There's no need to cryptographically guarantee that the postage is only paid by the recipient, so let anyone throw in some extra tx fee.

Like I said, that would be the long term goal. However, that requires the same work we have to go through for P2SH, and you know how well that's turning out. The short-term solution I detailed could be added to all of the miners today, if the code existed.