Bitcoin Forum
December 10, 2016, 07:11:42 AM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: Bounty? for "re-fees" allowing the receiver to add a fee to a transaction  (Read 921 times)
Luke-Jr
Legendary
*
Offline Offline

Activity: 2100



View Profile
May 10, 2012, 03:46:46 PM
 #1

I seem to recall people offering bounties for this functionality. I've implemented the miner side, so if you offered a bounty for this, please post and/or send here when satisfied: 123R1562U9BNAjh7h2QHNiJ44YTSx1oa8P

Note this is mostly untested still, and I don't recommend mining with it until I've given it more sanity checking and had some peer review.

I don't intend to implement the receiver-wants-to-explicitly-add-a-fee side, at this time. If people start offering bounties for that, I might change my mind. Wink

"The nature of Bitcoin is such that once version 0.1 was released, the core design was set in stone for the rest of its lifetime." -- Satoshi
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481353902
Hero Member
*
Offline Offline

Posts: 1481353902

View Profile Personal Message (Offline)

Ignore
1481353902
Reply with quote  #2

1481353902
Report to moderator
Stephen Gornick
Legendary
*
Offline Offline

Activity: 2002



View Profile
May 10, 2012, 11:13:00 PM
 #2

Would you describe how this would be implemented for the user?

i.e., I presume this would allow me to create a 0 BTC spend transaction for the address that is an output in a transaction that I'm waiting on it to confirm.  Is it voluntary up to the miner to take this transaction and then include the earlier transaction, or could the miner just take this "re-fee" transaction and still ignore the earler transaction?


Luke-Jr
Legendary
*
Offline Offline

Activity: 2100



View Profile
May 10, 2012, 11:31:40 PM
 #3

Would you describe how this would be implemented for the user?

i.e., I presume this would allow me to create a 0 BTC spend transaction for the address that is an output in a transaction that I'm waiting on it to confirm.  Is it voluntary up to the miner to take this transaction and then include the earlier transaction, or could the miner just take this "re-fee" transaction and still ignore the earler transaction?
Miners can't include transactions without first making sure their inputs are confirmed. Therefore, consuming an output of a transaction you want to confirm, in a new "change only" transaction (and including a fee on that) can be used as an incentive to include the original transaction. This code will treat the dependent transaction the same as it would by itself, but with a larger data size including the one it depends on. So if your new transaction is 500 bytes, and the one it depends on is 2000 bytes, the new transaction is treated as if it were 2500 bytes until the first one is confirmed - so your new transaction should include a fee assuming it is 2500 bytes, and its parent will get pulled in with it.

randomproof
Member
**
Offline Offline

Activity: 61


View Profile
May 12, 2012, 11:57:30 PM
 #4

Doesn't this eliminate some of the anonymity of the system by advertising who the receiver of a transaction is?

Donations to me:   19599Y3PTRF1mNdzVjQzePr67ttMiBG5LS
Sukrim
Legendary
*
Offline Offline

Activity: 1848


View Profile
May 13, 2012, 12:04:16 AM
 #5

It could expose another address of the receiver, yes.

It could be also be done by a (paid?) 3rd party service or out of charity though, so I believe it's not conclusive proof, unlike linking inputs together where you need to control both of them.

https://bitfinex.com <-- leveraged trading of BTCUSD, LTCUSD and LTCBTC (long and short) - 10% discount on fees for the first 30 days with this refcode: x5K9YtL3Zb
Mail me at Bitmessage: BM-BbiHiVv5qh858ULsyRDtpRrG9WjXN3xf
Luke-Jr
Legendary
*
Offline Offline

Activity: 2100



View Profile
May 13, 2012, 12:10:12 AM
 #6

Doesn't this eliminate some of the anonymity of the system by advertising who the receiver of a transaction is?
No.

Input: 5 BTC to 1someaddress
Output: 4.99 BTC to 1someaddress
Net fee: 0.01 BTC to miner

Sukrim
Legendary
*
Offline Offline

Activity: 1848


View Profile
May 13, 2012, 12:24:25 AM
 #7

Doesn't this eliminate some of the anonymity of the system by advertising who the receiver of a transaction is?
No.

Input: 5 BTC to 1someaddress
Output: 4.99 BTC to 1someaddress
Net fee: 0.01 BTC to miner
Maybe:

Original transaction:
Input: 4.99 BTC to 1someaddress from Alice
Output: 4.99 BTC to 1someaddress

Appended transaction
Input: 4.99 BTC to 1someaddress from Alice
appended Input: 0.01 BTC from someone who really wants to get these 4.99 BTC to 1someaddress, presumably the address owner
total new Input: 5.00 BTC to 1someaddress
Output: 4.99 BTC to 1someaddress
Net fee: 0.01 BTC to miner

https://bitfinex.com <-- leveraged trading of BTCUSD, LTCUSD and LTCBTC (long and short) - 10% discount on fees for the first 30 days with this refcode: x5K9YtL3Zb
Mail me at Bitmessage: BM-BbiHiVv5qh858ULsyRDtpRrG9WjXN3xf
Luke-Jr
Legendary
*
Offline Offline

Activity: 2100



View Profile
May 13, 2012, 12:28:47 AM
 #8

Doesn't this eliminate some of the anonymity of the system by advertising who the receiver of a transaction is?
No.

Input: 5 BTC to 1someaddress
Output: 4.99 BTC to 1someaddress
Net fee: 0.01 BTC to miner
Maybe:

Original transaction:
Input: 4.99 BTC to 1someaddress from Alice
Output: 4.99 BTC to 1someaddress

Appended transaction
Input: 4.99 BTC to 1someaddress from Alice
appended Input: 0.01 BTC from someone who really wants to get these 4.99 BTC to 1someaddress, presumably the address owner
total new Input: 5.00 BTC to 1someaddress
Output: 4.99 BTC to 1someaddress
Net fee: 0.01 BTC to miner
Only the person who controls 1someaddress can create such a transaction, so there's no reason for him to add an outside input - unless it's a regular transaction going to someone else (in which case the same privacy methods apply).

Sukrim
Legendary
*
Offline Offline

Activity: 1848


View Profile
May 13, 2012, 12:38:47 AM
 #9

So in reality it would look like this?

Original transaction:
Input: 4.99 BTC from Alice's address(es) to 1someaddress
Output: 4.99 BTC to 1someaddress (= Bob)

Stuck in limbo, would need 0.01 BTC fee likely.

New transaction:

Input: 4.99 BTC from 1someaddress and 0.01 from either 1someaddress (ideally) or another address under the control of Bob to 1someaddress or another of his addresses
Output: 4.99 BTC to 1someaddress (= Bob) or another of his addresses (he could also just output 4.98 BTC and spend the 0.01 on miner fees)
Net fee: 0.01 BTC to miner

The miner then includes both to get the fee on the second, which is only valid if the first one went through. It is either possible to let fewer BTC arrive at 1someaddress and paying the differnece to miners or to have the 4.99 BTC arrive at 1someaddress and pay the miners from existing other funds.

^^^
Is the above correct or did you only implement the case where fewer BTC than planned arrive at the address in the end?

https://bitfinex.com <-- leveraged trading of BTCUSD, LTCUSD and LTCBTC (long and short) - 10% discount on fees for the first 30 days with this refcode: x5K9YtL3Zb
Mail me at Bitmessage: BM-BbiHiVv5qh858ULsyRDtpRrG9WjXN3xf
Luke-Jr
Legendary
*
Offline Offline

Activity: 2100



View Profile
May 13, 2012, 01:12:19 AM
 #10

So in reality it would look like this?

Original transaction:
Input: 4.99 BTC from Alice's address(es) to 1someaddress
Output: 4.99 BTC to 1someaddress (= Bob)

Stuck in limbo, would need 0.01 BTC fee likely.

New transaction:

Input: 4.99 BTC from 1someaddress and 0.01 from either 1someaddress (ideally) or another address under the control of Bob to 1someaddress or another of his addresses
Output: 4.99 BTC to 1someaddress (= Bob) or another of his addresses (he could also just output 4.98 BTC and spend the 0.01 on miner fees)
Net fee: 0.01 BTC to miner

The miner then includes both to get the fee on the second, which is only valid if the first one went through. It is either possible to let fewer BTC arrive at 1someaddress and paying the differnece to miners or to have the 4.99 BTC arrive at 1someaddress and pay the miners from existing other funds.

^^^
Is the above correct or did you only implement the case where fewer BTC than planned arrive at the address in the end?
That would work, but there's not really any point to adding inputs IMO, except if you're sending to someone else at the same time.

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!