novitski / bitcoinj

Automatically exported from code.google.com/p/bitcoinj
Apache License 2.0
0 stars 0 forks source link

SendRequest: receiver pays fee #427

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
This is a followup to the side discussion that started in
http://code.google.com/p/bitcoinj/issues/detail?id=425

I propose to add "receiver pays fee" to SendRequest. Two usecases come to mind:

- completely emptying one's own wallet
- services that don't want to pay the fee for their users, but still would like 
to prevent their payouts taking "forever"

The idea is that the fee is substracted from the amount rather than added. So 
the amount will be guaranteed the exact value that will be deducted from the 
wallet.

Note that since the fee is variable, the app cannot know it in advance and thus 
cannot adjust the amount itself. (Without duplicating all the fee resolver 
logic of course.)

Original issue reported on code.google.com by andreas....@gmail.com on 8 Jul 2013 at 11:06

GoogleCodeExporter commented 9 years ago
Just got today this user report:

  "I had a problem sending coins from my wallet, I was getting an error 'problem sending coins.' I was trying to send the full balance of my wallet. Eventually I tried sending an amount slightly less than the entire wallet, and it went through, probably because of transaction fees."

Original comment by andreas....@gmail.com on 8 Jul 2013 at 3:19

GoogleCodeExporter commented 9 years ago

Original comment by hearn@google.com on 11 Jul 2013 at 3:38

GoogleCodeExporter commented 9 years ago
I keep getting these reports. Here is another one:

  "Hi I'm having a small issue with the bitcoin wallet application. I sent some coins to it a few hours ago and when I try to send them to someone it gives the error 'There was a problem sending.'

It's said this everytime so far. I tried resetting the blockchain but it didn't 
fix the issue."

Original comment by andreas....@gmail.com on 16 Jul 2013 at 11:30

GoogleCodeExporter commented 9 years ago
  "Ich kann meine Bitcoins nicht verschicken ..?
Adresse ist eigentlich richtig.
Will den kompletten Betrag im Wallet überweisen."

(he added a screenshot of the 'problem sending' toast message)

Original comment by andreas....@gmail.com on 17 Jul 2013 at 4:21

GoogleCodeExporter commented 9 years ago
https://code.google.com/p/bitcoinj/source/detail?r=1e69d2b0dd42d72088dc1c52f2f07
91300daedc7

This isn't quite a full "receiver pays fee" option, which is more complicated, 
but it does solve the common case of needing to empty out a wallet whilst still 
paying a fee. How does it look?

Original comment by hearn@google.com on 22 Jul 2013 at 1:54

GoogleCodeExporter commented 9 years ago

Original comment by hearn@google.com on 23 Jul 2013 at 12:41

GoogleCodeExporter commented 9 years ago
Does the closing of this ticket mean we'll give up on a full "receiver pays 
fee" option?

Original comment by andreas....@gmail.com on 23 Jul 2013 at 6:57

GoogleCodeExporter commented 9 years ago
For now, yes. It's apparently quite hard. A better approach is to modify 
Bitcoin itself.

Original comment by hearn@google.com on 23 Jul 2013 at 7:03

GoogleCodeExporter commented 9 years ago
Just noticed that there is a bitcoind/-qt ticket for the original idea of this 
ticket:

https://github.com/bitcoin/bitcoin/issues/2724

Original comment by andreas....@gmail.com on 22 Oct 2013 at 8:07

GoogleCodeExporter commented 9 years ago
Note how the current discussion of "interior" vs. "exterior fees" is touching 
this. Maybe reconsider the receiver pays fee option in SendRequest?

Original comment by andreas....@gmail.com on 3 Dec 2013 at 1:47

GoogleCodeExporter commented 9 years ago
Yeah, I was just thinking the same thing.

I need to refresh my memory about why this is hard. It obviously works for the 
case of emptying the wallet. I need to ping Matt and ask him to (re)explain it 
to me. Or I could just try implementing it myself and see at what point things 
come unglued.

Original comment by hearn@google.com on 3 Dec 2013 at 2:09