From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1VoA9b-0001qT-Jr for bitcoin-development@lists.sourceforge.net; Wed, 04 Dec 2013 10:58:03 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of petertodd.org designates 62.13.149.56 as permitted sender) client-ip=62.13.149.56; envelope-from=pete@petertodd.org; helo=outmail149056.authsmtp.com; Received: from outmail149056.authsmtp.com ([62.13.149.56]) by sog-mx-2.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1VoA9a-0000ie-2u for bitcoin-development@lists.sourceforge.net; Wed, 04 Dec 2013 10:58:03 +0000 Received: from mail-c237.authsmtp.com (mail-c237.authsmtp.com [62.13.128.237]) by punt10.authsmtp.com (8.14.2/8.14.2) with ESMTP id rB4AvtKw076676; Wed, 4 Dec 2013 10:57:55 GMT Received: from [10.28.39.245] (pa-18-178-222.service.infuturo.it [151.18.178.222]) (authenticated bits=0) by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id rB4AvpGY083443; Wed, 4 Dec 2013 10:57:52 GMT User-Agent: K-9 Mail for Android In-Reply-To: References: <5E4597E4-C1C7-4536-8CF0-82EDD7715DAB@plan99.net> <39921E12-B411-4430-9D56-04F53906B109@plan99.net> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 From: Peter Todd Date: Wed, 04 Dec 2013 11:57:48 +0100 To: Mike Hearn , Jeremy Spilman Message-ID: X-Server-Quench: ecfc2f02-5cd2-11e3-94fa-002590a135d3 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aQdMdgYUHFAXAgsB AmUbWlReVVp7XGc7 ag9QcwRVfEtJVxto UkpWR1pVCwUmQ24F d1heJXByfwZCfH0+ ZENkW3cVCRcsJkQr QkxJED5SZ3phaTUc TUlcIVJJcANIexZF O1F8UScOLwdSbGoL NQ4vNDcwO3BTJTpY RgYVKF8UXXNDMDo7 TgwDGzpnE0AIXG06 KRBuEWYiVE0VM0g0 LUBJ X-Authentic-SMTP: 61633532353630.1024:706 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 151.18.178.222/587 X-AuthVirus-Status: No virus detected - but ensure you scan with your own anti-virus system. X-Spam-Score: -1.5 (-) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain -0.0 SPF_PASS SPF: sender matches SPF record 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: plan99.net] X-Headers-End: 1VoA9a-0000ie-2u Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Floating fees and SPV clients X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 10:58:03 -0000 -----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 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-----