Re: [Bitcoin-development] Floating fees and SPV clients

2013-12-04 Thread Peter Todd
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mike Hearn m...@plan99.net wrote: I think this US/other cultural issue is complicating things more than we appreciate. I am trying to imagine in my head how all this will work and what it will look like with allow_fee, and I just can't see it.

Re: [Bitcoin-development] Floating fees and SPV clients

2013-12-04 Thread Peter Todd
On Wed, Dec 04, 2013 at 12:09:42PM +0100, Mike Hearn wrote: Please don't try and drag this thread off topic. What I said is factually correct. If you want to (again) try and convince people things should work differently, start another thread for that. replace-by-fee is no less speculative

Re: [Bitcoin-development] Floating fees and SPV clients

2013-12-04 Thread Mike Hearn
On Wed, Dec 4, 2013 at 2:06 PM, Peter Todd p...@petertodd.org wrote: replace-by-fee is no less speculative than your original proposals; you're also trying to convince people that things should work differently re: fees The original proposal I started this thread with hasn't even received

Re: [Bitcoin-development] Floating fees and SPV clients

2013-12-04 Thread Peter Todd
On Wed, Dec 04, 2013 at 02:48:08PM +0100, Mike Hearn wrote: On Wed, Dec 4, 2013 at 2:06 PM, Peter Todd p...@petertodd.org wrote: replace-by-fee is no less speculative than your original proposals; you're also trying to convince people that things should work differently re: fees The

Re: [Bitcoin-development] Floating fees and SPV clients

2013-12-03 Thread Mike Hearn
On Tue, Dec 3, 2013 at 2:40 AM, Gavin Andresen gavinandre...@gmail.comwrote: optional uint64 allowfeetag number=1000 Let's just use a normal/low tag number. The extensions mechanism is great for people who want to extend the protocol outside the core development process. It'd be weird

Re: [Bitcoin-development] Floating fees and SPV clients

2013-12-03 Thread Drak
I dont like the idea of putting the min fee in the hands of the receiver. Seems like that will work against the best interests of senders in the long run. Why not try a different path of calculating the min fee like difficulty retarget. You can analyse the last 2016 blocks to find the average fee

Re: [Bitcoin-development] Floating fees and SPV clients

2013-12-03 Thread Mike Hearn
On Tue, Dec 3, 2013 at 11:36 AM, Drak d...@zikula.org wrote: I dont like the idea of putting the min fee in the hands of the receiver. Seems like that will work against the best interests of senders in the long run. Senders have no interest in ever attaching any kind of fee, which is one

Re: [Bitcoin-development] Floating fees and SPV clients

2013-12-03 Thread Peter Todd
On Tue, Dec 03, 2013 at 11:40:35AM +1000, Gavin Andresen wrote: On Tue, Dec 3, 2013 at 12:44 AM, Mike Hearn m...@plan99.net wrote: PPv1 doesn't have any notion of fee unfortunately. I suppose it could be added easily, but we also need to launch the existing feature set. Lets bang out a

Re: [Bitcoin-development] Floating fees and SPV clients

2013-12-03 Thread Peter Todd
On Tue, Dec 03, 2013 at 11:09:51AM +, Drak wrote: On 3 December 2013 11:03, Peter Todd p...@petertodd.org wrote: UI once both are implemented is to not show anything in the default case, and explain to the user why they have to pay extra in the unusual case where they are spending a

Re: [Bitcoin-development] Floating fees and SPV clients

2013-12-03 Thread Peter Todd
On Tue, Dec 03, 2013 at 12:29:03PM +0100, Mike Hearn wrote: On Tue, Dec 3, 2013 at 12:07 PM, Gavin Andresen gavinandre...@gmail.comwrote: Making it fee-per-kilobyte is a bad idea, in my opinion; users don't care how many kilobytes their transactions are, and they will just be confused

Re: [Bitcoin-development] Floating fees and SPV clients

2013-12-03 Thread Gavin Andresen
Wouldn't the idea be that the user always sees 10mBTC no matter what, but the receiver may receive less if the user decides to pay with a huge transaction? If users want to pay with a huge transaction then it seems to me the user should cover that cost. Allowing users to pay merchants with

Re: [Bitcoin-development] Floating fees and SPV clients

2013-12-03 Thread Mike Hearn
On Tue, Dec 3, 2013 at 12:41 PM, Gavin Andresen gavinandre...@gmail.comwrote: If users want to pay with a huge transaction then it seems to me the user should cover that cost. Allowing users to pay merchants with 100K transactions full of dust and expecting them to eat the cost seems like a

Re: [Bitcoin-development] Floating fees and SPV clients

2013-12-03 Thread Gavin Andresen
A merchant can always refuse the payment and refund it if that's a practical problem. No, they can't, at least not in bitcoin-qt: when the user pokes the SEND button, the transaction is broadcast on the network, and then the merchant is also told with the Payment/PaymentACK round-trip.

Re: [Bitcoin-development] Floating fees and SPV clients

2013-12-03 Thread Drak
On 3 December 2013 11:46, Mike Hearn m...@plan99.net wrote: On Tue, Dec 3, 2013 at 12:41 PM, Gavin Andresen gavinandre...@gmail.comwrote: If users want to pay with a huge transaction then it seems to me the user should cover that cost. Allowing users to pay merchants with 100K transactions

Re: [Bitcoin-development] Floating fees and SPV clients

2013-12-03 Thread Peter Todd
On Tue, Dec 03, 2013 at 12:57:23PM +0100, Taylor Gerring wrote: On Dec 3, 2013, at 12:29 PM, Mike Hearn m...@plan99.net wrote: It may be acceptable that receivers don't always receive exactly what they requested, at least for person-to-business transactions. For person-to-person

Re: [Bitcoin-development] Floating fees and SPV clients

2013-12-03 Thread Mike Hearn
On Tue, Dec 3, 2013 at 12:57 PM, Taylor Gerring taylor.gerr...@gmail.comwrote: Why should there be two classes of transactions? Where does paying a local business at a farmer’s stand lie in that realm? Transactions should work the same regardless of who is on the receiving end. Lots and lots

Re: [Bitcoin-development] Floating fees and SPV clients

2013-12-03 Thread Taylor Gerring
On Dec 3, 2013, at 2:20 PM, Mike Hearn m...@plan99.net wrote: On Tue, Dec 3, 2013 at 12:57 PM, Taylor Gerring taylor.gerr...@gmail.com wrote: Why should there be two classes of transactions? Where does paying a local business at a farmer’s stand lie in that realm? Transactions should work

Re: [Bitcoin-development] Floating fees and SPV clients

2013-12-03 Thread Mike Hearn
Heh. People feel rises in sales tax elsewhere too. When VAT rises merchants all raise their prices, they don't normally swallow it (or if they do, they make a big fuss over how awesome they are). The US system is a complete pain in the ass. You never know how much money you actually need to pay

Re: [Bitcoin-development] Floating fees and SPV clients

2013-12-03 Thread Quinn Harris
The merchant wants to include a fee to ensure the transaction is confirmed which is dependent on the fee per kilobyte, but they don't want to pay unexpectedly high fees. So what about including a min_fee_per_kilobyte and a max_fee in PaymentDetails describing what fees the merchant will pay.

Re: [Bitcoin-development] Floating fees and SPV clients

2013-12-03 Thread Jeremy Spilman
allowfee: Allow up to allowfee satoshis to be deducted from the amount paid to be used to pay Bitcoin network transaction fees. A wallet implementation must not reduce the amount paid for fees more than allowfee, and transaction fees must be equal to or greater than the amount reduced.

Re: [Bitcoin-development] Floating fees and SPV clients

2013-12-03 Thread kjj
After reading all 99 messages in this thread, I think allowfee is just about perfect. It effectively lets merchants to give an allowance against the purchase price for network fees, if they choose. It is still up to the sender (and/or the sender's software) to get the fees right. Sometimes

Re: [Bitcoin-development] Floating fees and SPV clients

2013-12-02 Thread Patrick Mead
First time posting to this mailing list so feel free to ignore me if this is a stupid idea. On Mon, Dec 2, 2013 at 3:49 AM, Mike Hearn m...@plan99.net wrote: We need to get away from the notion of senders attaching fees anyway. This is the wrong way around because it’s the recipient who

Re: [Bitcoin-development] Floating fees and SPV clients

2013-12-02 Thread Jeff Garzik
On Mon, Dec 2, 2013 at 9:33 AM, Mike Hearn m...@plan99.net wrote: The payment protocol at least would need some notion of fee, or possibly (better?) the ability for a recipient to specify some inputs as well as some outputs. vendor hat: on BitPay noticed this detail last week. We were

Re: [Bitcoin-development] Floating fees and SPV clients

2013-12-02 Thread Gavin Andresen
On Tue, Dec 3, 2013 at 12:44 AM, Mike Hearn m...@plan99.net wrote: PPv1 doesn't have any notion of fee unfortunately. I suppose it could be added easily, but we also need to launch the existing feature set. Lets bang out a merchant-pays-fee extension. How about: SPEC: optional uint64

[Bitcoin-development] Floating fees and SPV clients

2013-12-01 Thread Mike Hearn
Lately I was pondering how to make floating fees and SPV wallets work well together. I propose the following plan: 1) 0.9 ships with something dead simple, like a command to query what a node estimates and then clients just take the average, or cross-check a centralised estimate against the P2P

Re: [Bitcoin-development] Floating fees and SPV clients

2013-12-01 Thread Mike Hearn
As long as the tx is not confirmed (by a broadcast), apps can offer to bump up the fee a little bit. Unfortunately there are risks to that approach. The most obvious one is that nodes could keep sending reject messages to get wallets to attach ridiculously high fees. If half a wallets peers

Re: [Bitcoin-development] Floating fees and SPV clients

2013-12-01 Thread Andreas Schildbach
(my post hasn't shown up for an hour, so I'm sending it again) On 12/01/2013 02:41 PM, Mike Hearn wrote: As long as the tx is not confirmed (by a broadcast), apps can offer to bump up the fee a little bit. Unfortunately there are risks to that approach. I assume you're right, since I do

Re: [Bitcoin-development] Floating fees and SPV clients

2013-12-01 Thread Mike Hearn
Both can be combined into adapting the current generic messages (This payment should become spendable shortly for incoming and This payment has not been transmitted yet for outgoing transactions). What would the new messages say? We need to get away from the notion of senders attaching fees

Re: [Bitcoin-development] Floating fees and SPV clients

2013-12-01 Thread Andreas Schildbach
On 12/01/2013 06:19 PM, Mike Hearn wrote: Both can be combined into adapting the current generic messages (This payment should become spendable shortly for incoming and This payment has not been transmitted yet for outgoing transactions). What would the new messages say? Well, for starters

Re: [Bitcoin-development] Floating fees and SPV clients

2013-12-01 Thread Mike Hearn
This payment did not become spendable since xxx minutes. Check with the sender if s/he paid the Bitcoin network fee. Check if your internet connection is working properly. (incoming) That seems reasonable. The other message should be implementable today, I think? If numBroadcastPeers 0

Re: [Bitcoin-development] Floating fees and SPV clients

2013-12-01 Thread Peter Todd
On Sun, Dec 01, 2013 at 06:19:14PM +0100, Mike Hearn wrote: Both can be combined into adapting the current generic messages (This payment should become spendable shortly for incoming and This payment has not been transmitted yet for outgoing transactions). What would the new messages

Re: [Bitcoin-development] Floating fees and SPV clients

2013-12-01 Thread Mike Hearn
Bitcoin is and always will be limited in capacity - transactions may not confirm in a reasonable about of time because of high-demand and/or DoS attacks. I agree in the general case, but I was talking about the mobile wallet case specifically (i.e. people who are sending money between

Re: [Bitcoin-development] Floating fees and SPV clients

2013-12-01 Thread Peter Todd
On Sun, Dec 01, 2013 at 07:18:07PM +0100, Mike Hearn wrote: Bitcoin is and always will be limited in capacity - transactions may not confirm in a reasonable about of time because of high-demand and/or DoS attacks. I agree in the general case, but I was talking about the mobile wallet case