Bitcoin Forum
December 09, 2016, 11:41:28 AM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: Recipient paid tx fee  (Read 1003 times)
Steve
Hero Member
*****
Offline Offline

Activity: 868



View Profile WWW
January 31, 2012, 03:18:45 PM
 #1

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)?

(gasteve on IRC) Does your website accept cash? https://bitpay.com
1481283688
Hero Member
*
Offline Offline

Posts: 1481283688

View Profile Personal Message (Offline)

Ignore
1481283688
Reply with quote  #2

1481283688
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481283688
Hero Member
*
Offline Offline

Posts: 1481283688

View Profile Personal Message (Offline)

Ignore
1481283688
Reply with quote  #2

1481283688
Report to moderator
Maged
Legendary
*
Offline Offline

Activity: 1260


View Profile
January 31, 2012, 09:37:00 PM
 #2

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
Hero Member
*****
Offline Offline

Activity: 728


165YUuQUWhBz3d27iXKxRiazQnjEtJNG9g


View Profile
January 31, 2012, 10:59:13 PM
 #3

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.

      War is God's way of teaching Americans geography.  --Ambrose Bierce
Bitcoin is the Devil's way of teaching geeks economics.  --Revalin 165YUuQUWhBz3d27iXKxRiazQnjEtJNG9g
Maged
Legendary
*
Offline Offline

Activity: 1260


View Profile
February 01, 2012, 05:22:00 AM
 #4

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.

Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!