diff options
author | Peter Todd <pete@petertodd.org> | 2013-12-04 11:57:48 +0100 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2013-12-04 10:58:03 +0000 |
commit | db8c04982f323b2c125c715c2f5d646883559c99 (patch) | |
tree | b6adc2c8ebac25ffaa7f406be0db38fffb5c78a1 | |
parent | c4feef1b3de24dedda9c7f038b90d809ce6b3d80 (diff) | |
download | pi-bitcoindev-db8c04982f323b2c125c715c2f5d646883559c99.tar.gz pi-bitcoindev-db8c04982f323b2c125c715c2f5d646883559c99.zip |
Re: [Bitcoin-development] Floating fees and SPV clients
-rw-r--r-- | ce/c4c675f06ea16a882cac319a9e59f469e1b789 | 180 |
1 files changed, 180 insertions, 0 deletions
diff --git a/ce/c4c675f06ea16a882cac319a9e59f469e1b789 b/ce/c4c675f06ea16a882cac319a9e59f469e1b789 new file mode 100644 index 000000000..e8b242f89 --- /dev/null +++ b/ce/c4c675f06ea16a882cac319a9e59f469e1b789 @@ -0,0 +1,180 @@ +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 <pete@petertodd.org>) 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: <CANEZrP3D4WhXTdMAT7B=DaXEOSdXESc+bU0n7enu7hSaGtns8A@mail.gmail.com> +References: <CANEZrP3tGdFh6oG5fbX9JbU6sYbbex1cq=0tQB-0A4aDrdbXrQ@mail.gmail.com> + <l7f97u$jdg$1@ger.gmane.org> + <5E4597E4-C1C7-4536-8CF0-82EDD7715DAB@plan99.net> + <l7fpbn$hf6$1@ger.gmane.org> + <39921E12-B411-4430-9D56-04F53906B109@plan99.net> + <CAGLkj4C9fyAX1CnB0oZH3BwLRQp6WOo9kLUqDhRUSA6y3LxYvg@mail.gmail.com> + <CANEZrP1C=Hc-3f-rqQ+wYrPn-eUj52HjN+qRQdJMWvnP+dkK=Q@mail.gmail.com> + <CAJHLa0P_uzEQ2OG2FTXyD2Zw4RzujNBxKbKD04CSS1sLNpLUUQ@mail.gmail.com> + <CANEZrP2hf2853w9f4__Ji9v3eRRU0u6pEzPxAmFN+iH067gtnA@mail.gmail.com> + <CABsx9T3NQDPL6=pz5BD5DsP0qh0x3LJOCj2H3yY5tzL2_DivGA@mail.gmail.com> + <CANEZrP1PLKemiUEgMJRGdiZXt7o=0_5fhLKYY0x3Ngb_iEm+2w@mail.gmail.com> + <CABsx9T322nCvynRCL6Mb9C0f5EuJSfMDTSGiU+_JsYoSCb=_kQ@mail.gmail.com> + <op.w7jnreqwyldrnw@laptop-air.hsd1.ca.comcast.net> + <CANEZrP3D4WhXTdMAT7B=DaXEOSdXESc+bU0n7enu7hSaGtns8A@mail.gmail.com> +MIME-Version: 1.0 +Content-Transfer-Encoding: 8bit +Content-Type: text/plain; + charset=UTF-8 +From: Peter Todd <pete@petertodd.org> +Date: Wed, 04 Dec 2013 11:57:48 +0100 +To: Mike Hearn <mike@plan99.net>, Jeremy Spilman <jeremy@taplink.co> +Message-ID: <e4515a76-b4c1-4a5f-a884-6d692b8d3466@email.android.com> +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 <bitcoin-development@lists.sourceforge.net> +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: <bitcoin-development.lists.sourceforge.net> +List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe> +List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development> +List-Post: <mailto:bitcoin-development@lists.sourceforge.net> +List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help> +List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe> +X-List-Received-Date: Wed, 04 Dec 2013 10:58:03 -0000 + +-----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----- + + + |