On Wed, Dec 04, 2013 at 02:48:08PM +0100, Mike Hearn wrote:
> On Wed, Dec 4, 2013 at 2:06 PM, Peter Todd 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
On Wed, Dec 4, 2013 at 2:06 PM, Peter Todd 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
comments - presuma
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 t
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.
--
Sponsored by Intel(R) XDK
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Mike Hearn 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. Merchants w
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. Merchants want customers
to pay the sticker price, deviance from that social norm is ext
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 t
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 redu
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. T
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 fo
On Dec 3, 2013, at 2:20 PM, Mike Hearn wrote:
> On Tue, Dec 3, 2013 at 12:57 PM, Taylor Gerring
> 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
> same regardless of who is on
Hi all, first post so go easy on me!
Background/Intro: I'm a C/C++ software engineer with a keen interest in
Bitcoin working for everyone. I've spent the last couple of months pitching
Bitcoin to merchants & end users (previously I mined),
While I agree as Peter said, transparency with fees is go
On Tue, Dec 3, 2013 at 12:57 PM, Taylor Gerring 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 same regardless of who is on the receiving end.
>
Lots and lots of people are psycho
On Tue, Dec 03, 2013 at 12:57:23PM +0100, Taylor Gerring wrote:
>
> On Dec 3, 2013, at 12:29 PM, Mike Hearn 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 transaction
On 3 December 2013 11:46, Mike Hearn wrote:
> On Tue, Dec 3, 2013 at 12:41 PM, Gavin Andresen
> wrote:
>>
>> 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 t
On Dec 3, 2013, at 12:29 PM, Mike Hearn 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 transactions of course any fee at all is confusing because
> you intuitively expect th
>
> 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.
A
On Tue, Dec 3, 2013 at 12:41 PM, Gavin Andresen wrote:
>
> 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
> great way to enable
>
> 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 wi
On Tue, Dec 03, 2013 at 12:29:03PM +0100, Mike Hearn wrote:
> On Tue, Dec 3, 2013 at 12:07 PM, Gavin Andresen
> wrote:
>
> > 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
> > if they're payin
On Tue, Dec 03, 2013 at 11:09:51AM +, Drak wrote:
> On 3 December 2013 11:03, Peter Todd 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 whole bunch
On Sun, Dec 01, 2013 at 12:51:46PM +0100, Mike Hearn wrote:
> 4) Finally, when we next hard fork, we make v2 transactions include the
> output value in the signature, same as the output script (this proposal has
> been on the forums for a while now). That allows the fee data added in step
> 2 to be
On Tue, Dec 3, 2013 at 12:07 PM, Gavin Andresen wrote:
> 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
> if they're paying for a 10mBTC burger and are asked to pay 10.00011 or
> 9.9994 because t
On 3 December 2013 11:03, Peter Todd 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 whole bunch of dust.
Yes, that's the other problem with a merchant setting
Ok, revised spec:
SPEC:
message PaymentDeatils {
...
optional uint64 minfeetag number=8
Pay at least minfee satoshis in transaction fees. Wallet software should
add minfee to the amount the user authorizes and pays, and include at least
minfee in the transaction created to pay miner'
On 3 December 2013 10:45, Mike Hearn wrote:
> On Tue, Dec 3, 2013 at 11:36 AM, Drak 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
On Tue, Dec 03, 2013 at 11:40:35AM +1000, Gavin Andresen wrote:
> On Tue, Dec 3, 2013 at 12:44 AM, Mike Hearn 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 merch
On Tue, Dec 3, 2013 at 11:36 AM, Drak 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
reason we explo
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 2:40 AM, Gavin Andresen wrote:
> 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 if nobody ever used th
On Tue, Dec 3, 2013 at 12:44 AM, Mike Hearn 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 allowfeeta
Current rough timeline proposed for 0.9 was end-of-January, IIRC.
On Mon, Dec 2, 2013 at 9:44 AM, Mike Hearn 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.
>
> There's code pending review to im
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.
There's code pending review to implement PPv1 in bitcoinj, unfortunately
it's currently not passing unit tests and the author can't figure out why.
I didn't h
Right, as I said earlier:
"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."
Having thought about it a bit more, I think it's better to just have a fee
field that lets the receiver reques
On Mon, Dec 2, 2013 at 9:33 AM, Mike Hearn 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."
BitPay noticed this detail last week. We were noticing that some
transactions
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 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 cares about dou
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 wall
> 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 thems
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 m
> "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
>
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
> 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
(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
> 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
On 12/01/2013 12:51 PM, Mike Hearn wrote:
> I propose the following plan:
Thanks taking the initiative and writing this up!
> If a wallet gets a reject message for a tx that has a fee that are by
> its own estimates acceptable, what should it do? What if only some nodes
> report that and others
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 n
46 matches
Mail list logo
