From: Peter Todd <pete@petertodd•org>
To: Mike Hearn <mike@plan99•net>, Jeremy Spilman <jeremy@taplink•co>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Floating fees and SPV clients
Date: Wed, 04 Dec 2013 11:57:48 +0100 [thread overview]
Message-ID: <e4515a76-b4c1-4a5f-a884-6d692b8d3466@email.android.com> (raw)
In-Reply-To: <CANEZrP3D4WhXTdMAT7B=DaXEOSdXESc+bU0n7enu7hSaGtns8A@mail.gmail.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Mike Hearn <mike@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. 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.
Here at the dark wallet conf there seems yo be rough consensus that replacement for fee bumping is a good thing and should be supported; I was talking to Taylor from hive specifically yesterday. The code is trivial on the node side of things and doesn't need consent of anymore than a small minority, and coinjoin forces wallets to handle double spends well anyway. I haven't heard anyone caring about zeroconf safety.
I'll be proposing it for "formal" inclusion in our wallet best practices guidelines.
Also fwiw apparently libbitcoin already implements a memory limited mempool and Amir is open to the idea of it using the satoshi consensus critical code for block validity. (therefor fairly safe mining) I wouldn't be surprised if libbitcoin based nodes start getting usage, and with a limited mempool it is very DoS attack safe for them to relay replacements regardless of miner support.
-----BEGIN PGP SIGNATURE-----
Version: APG v1.0.9
iQFQBAEBCAA6BQJSnwqsMxxQZXRlciBUb2RkIChsb3cgc2VjdXJpdHkga2V5KSA8
cGV0ZUBwZXRlcnRvZGQub3JnPgAKCRAZnIM7qOfwhR5yCAC3vaQQeoBrLdqn/rO5
Dzblqwl1B6AE1UjFj5+abQEZ2+uPy5P+7dZidpUn8Ms+tDDcCCge6HVOg+UeseaE
8pDP3+VIHZHH+9n6Y3+4facLNpQ3dP/+Zsg4pC+QSAjVV6408+yWPLtpbC6V0apK
T6K4qdq0Ct6V+54Ol0Thx+5cJlWLI+XbW2eXze3WjJzj3FgZUK0udBcVWa8JyWAV
WD1tv8DpPoUvDDzdmjEyf0EdjvcmamH9mcIvtxRdVwzyY/siZoizv9X8/gXNL+fg
JJ3Oxwrl1dOYSeENgp9VP8fU7GK7855bT1Wxd5zGNW7p/1gNxN4Lnx57XSMz2IHc
dHbg
=dcYz
-----END PGP SIGNATURE-----
next prev parent reply other threads:[~2013-12-04 10:58 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
2013-12-04 10:57 ` Peter Todd [this message]
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=e4515a76-b4c1-4a5f-a884-6d692b8d3466@email.android.com \
--to=pete@petertodd$(echo .)org \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=jeremy@taplink$(echo .)co \
--cc=mike@plan99$(echo .)net \
/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