Bounty? for "re-fees" allowing the receiver to add a fee to a transaction

[Luke-Jr]

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.

[Stephen Gornick]

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]

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]

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

[Sukrim]

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.

[Luke-Jr]

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]

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

[Luke-Jr]

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]

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?

[Luke-Jr]

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.