From: Mike Hearn <mike@plan99•net>
To: Jeremy Spilman <jeremy@taplink•co>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Floating fees and SPV clients
Date: Wed, 4 Dec 2013 11:40:00 +0100 [thread overview]
Message-ID: <CANEZrP3D4WhXTdMAT7B=DaXEOSdXESc+bU0n7enu7hSaGtns8A@mail.gmail.com> (raw)
In-Reply-To: <op.w7jnreqwyldrnw@laptop-air.hsd1.ca.comcast.net>
[-- Attachment #1: Type: text/plain, Size: 2237 bytes --]
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 extremely rare
even after the credit card company contracts that required it have been
invalidated. The only time it happens to me is when buying flight tickets
with credit cards: but it's only for that method, other payment methods are
still treated as "free" a.k.a interior fees.
If you walk into a physical shop and try to pay a large bill with bags of
pennies, the merchant won't enter into a complicated agreement where they
agree to split the cost of processing with you. They will just reject the
payment out of hand and tell you to get real. It has to be that way because
otherwise the shop would carry the cost of counting all the pennies and
hauling them around, not the buyer (who "knows" he put the right number of
pennies in the bags).
As a buyer, I do not care about whether my transaction will confirm. If I
try to pay with dust, there is no incentive for me to attach a higher fee
than allow_fee to make that confirm, especially if the merchant has no way
to reject the payment. What's more, as Jeremy points out, no clean fail
mechanism means large piles of manual work and lots of disputes due to
payments not clearing before the exchange rate shifts and other things like
that.
Trying to make the success of payment confirmation a two-person dance seems
to have so many edge cases it makes my head hurt. For most pay-to-merchant
cases, it has to be the receivers job to get a transaction confirmed, and
if the sender doesn't follow the instructions a payment should hard fail
and require trying again. If Bitcoin-Qt can't handle that today, that does
seem like a problem.
In the case of a transaction with too-low fee, either the payer can
> double-spend with a higher fee
You can't do that. When a tx doesn't have the right fee attached you're out
of luck today, except for the fact that some pools run with a custom child
pays for parent patch. So respending it would bump priority for some miners
and not others.
[-- Attachment #2: Type: text/html, Size: 2708 bytes --]
next prev parent reply other threads:[~2013-12-04 10:40 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-01 11:51 Mike Hearn
2013-12-01 12:15 ` Andreas Schildbach
2013-12-01 13:41 ` Mike Hearn
2013-12-01 16:50 ` Andreas Schildbach
2013-12-01 17:19 ` Mike Hearn
2013-12-01 17:40 ` Andreas Schildbach
2013-12-01 17:52 ` Mike Hearn
2013-12-01 18:12 ` Peter Todd
2013-12-01 18:18 ` Mike Hearn
2013-12-01 18:37 ` Peter Todd
2013-12-02 13:54 ` Patrick Mead
2013-12-02 14:33 ` Mike Hearn
2013-12-02 14:37 ` Jeff Garzik
2013-12-02 14:44 ` Mike Hearn
2013-12-02 14:47 ` Jeff Garzik
2013-12-03 1:40 ` Gavin Andresen
2013-12-03 10:06 ` Mike Hearn
2013-12-03 10:36 ` Drak
2013-12-03 10:45 ` Mike Hearn
2013-12-03 11:04 ` Drak
2013-12-03 11:07 ` Gavin Andresen
2013-12-03 11:29 ` Mike Hearn
2013-12-03 11:37 ` Peter Todd
2013-12-03 11:41 ` Gavin Andresen
2013-12-03 11:46 ` Mike Hearn
2013-12-03 11:54 ` Gavin Andresen
2013-12-03 12:05 ` Drak
2013-12-03 11:57 ` Taylor Gerring
2013-12-03 12:07 ` Peter Todd
2013-12-03 13:20 ` Jamie McNaught
2013-12-03 13:20 ` Mike Hearn
2013-12-03 13:48 ` Taylor Gerring
2013-12-03 13:54 ` Mike Hearn
2013-12-03 14:42 ` Quinn Harris
2013-12-04 1:45 ` Jeremy Spilman
2013-12-04 10:40 ` Mike Hearn [this message]
2013-12-04 10:57 ` Peter Todd
2013-12-04 11:09 ` Mike Hearn
2013-12-04 13:06 ` Peter Todd
2013-12-04 13:48 ` Mike Hearn
2013-12-04 21:51 ` Peter Todd
2013-12-03 11:03 ` Peter Todd
2013-12-03 11:09 ` Drak
2013-12-03 11:33 ` Peter Todd
2013-12-04 5:50 ` kjj
2013-12-03 11:31 ` Peter Todd
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CANEZrP3D4WhXTdMAT7B=DaXEOSdXESc+bU0n7enu7hSaGtns8A@mail.gmail.com' \
--to=mike@plan99$(echo .)net \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=jeremy@taplink$(echo .)co \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox