summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorPeter Todd <pete@petertodd.org>2013-12-04 11:57:48 +0100
committerbitcoindev <bitcoindev@gnusha.org>2013-12-04 10:58:03 +0000
commitdb8c04982f323b2c125c715c2f5d646883559c99 (patch)
treeb6adc2c8ebac25ffaa7f406be0db38fffb5c78a1
parentc4feef1b3de24dedda9c7f038b90d809ce6b3d80 (diff)
downloadpi-bitcoindev-db8c04982f323b2c125c715c2f5d646883559c99.tar.gz
pi-bitcoindev-db8c04982f323b2c125c715c2f5d646883559c99.zip
Re: [Bitcoin-development] Floating fees and SPV clients
-rw-r--r--ce/c4c675f06ea16a882cac319a9e59f469e1b789180
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-----
+
+
+