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
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
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
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
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
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
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
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
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.
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
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
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
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
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.
I posted this on bitcoin-user, but nobody replied, so I'm
trying here.
Today, when a user uses bitcoin-qt client, it can make a backup
of wallet.dat easily through menu, but when he/she needs to restore
this backup, he/she must copy the file to the correct folder and
execute
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.
On Tue, Dec 3, 2013 at 11:59 AM, Dâniel Fraga frag...@gmail.com wrote:
Today, when a user uses bitcoin-qt client, it can make a backup
of wallet.dat easily through menu, but when he/she needs to restore
this backup, he/she must copy the file to the correct folder and
execute
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
18 matches
Mail list logo
