diff options
| author | Taylor Gerring <taylor.gerring@gmail.com> | 2013-12-03 12:57:23 +0100 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2013-12-03 11:59:17 +0000 |
| commit | abc9ef83e72b66501ad9238d3258e0c4873a2e4f (patch) | |
| tree | 66ef1083ae04be4637cce055d3c43625ec7d3698 /6d | |
| parent | 46ad5eb7ae3be05702f241a6b22c5eed8e495a5e (diff) | |
| download | pi-bitcoindev-abc9ef83e72b66501ad9238d3258e0c4873a2e4f.tar.gz pi-bitcoindev-abc9ef83e72b66501ad9238d3258e0c4873a2e4f.zip | |
Re: [Bitcoin-development] Floating fees and SPV clients
Diffstat (limited to '6d')
| -rw-r--r-- | 6d/fe23c5c4a95050f1eaae68da817740685103a0 | 175 |
1 files changed, 175 insertions, 0 deletions
diff --git a/6d/fe23c5c4a95050f1eaae68da817740685103a0 b/6d/fe23c5c4a95050f1eaae68da817740685103a0 new file mode 100644 index 000000000..d9f22f177 --- /dev/null +++ b/6d/fe23c5c4a95050f1eaae68da817740685103a0 @@ -0,0 +1,175 @@ +Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] + helo=mx.sourceforge.net) + by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) + (envelope-from <taylor.gerring@gmail.com>) id 1VnodJ-0001SP-KC + for bitcoin-development@lists.sourceforge.net; + Tue, 03 Dec 2013 11:59:17 +0000 +Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com + designates 209.85.215.176 as permitted sender) + client-ip=209.85.215.176; envelope-from=taylor.gerring@gmail.com; + helo=mail-ea0-f176.google.com; +Received: from mail-ea0-f176.google.com ([209.85.215.176]) + by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) + (Exim 4.76) id 1VnodH-0007H9-CU + for bitcoin-development@lists.sourceforge.net; + Tue, 03 Dec 2013 11:59:17 +0000 +Received: by mail-ea0-f176.google.com with SMTP id h14so9727179eaj.7 + for <bitcoin-development@lists.sourceforge.net>; + Tue, 03 Dec 2013 03:59:09 -0800 (PST) +X-Received: by 10.14.174.71 with SMTP id w47mr26923eel.113.1386071949080; + Tue, 03 Dec 2013 03:59:09 -0800 (PST) +Received: from [192.168.1.157] ([82.84.138.236]) + by mx.google.com with ESMTPSA id a45sm81611710eem.6.2013.12.03.03.59.07 + for <multiple recipients> + (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); + Tue, 03 Dec 2013 03:59:08 -0800 (PST) +Content-Type: multipart/alternative; + boundary="Apple-Mail=_90B85D20-1FD8-4B03-A7A1-33B4072408B7" +Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) +From: Taylor Gerring <taylor.gerring@gmail.com> +In-Reply-To: <CANEZrP0P9NTJXs22K8-4hnLkxV7Uo+tjvWKJ8msgxiFgJW6xvg@mail.gmail.com> +Date: Tue, 3 Dec 2013 12:57:23 +0100 +Message-Id: <05CEDEB4-BA29-4ED3-8CFC-D3504727DB4D@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> + <CANEZrP0P9NTJXs22K8-4hnLkxV7Uo+tjvWKJ8msgxiFgJW6xvg@mail.gmail.com> +To: Mike Hearn <mike@plan99.net> +X-Mailer: Apple Mail (2.1822) +X-Spam-Score: -0.6 (/) +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 FREEMAIL_FROM Sender email is commonly abused enduser mail provider + (taylor.gerring[at]gmail.com) + -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] + 1.0 HTML_MESSAGE BODY: HTML included in message + -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from + author's domain + 0.1 DKIM_SIGNED Message has a DKIM or DK signature, + not necessarily valid + -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature +X-Headers-End: 1VnodH-0007H9-CU +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: Tue, 03 Dec 2013 11:59:17 -0000 + + +--Apple-Mail=_90B85D20-1FD8-4B03-A7A1-33B4072408B7 +Content-Transfer-Encoding: quoted-printable +Content-Type: text/plain; + charset=windows-1252 + + +On Dec 3, 2013, at 12:29 PM, Mike Hearn <mike@plan99.net> wrote: + +> It may be acceptable that receivers don't always receive exactly what = +they requested, at least for person-to-business transactions. For = +person-to-person transactions of course any fee at all is confusing = +because you intuitively expect that if you send 1 mBTC, then 1 mBTC will = +arrive the other end. I wonder if we'll end up in a world where buying = +things from shops involves paying fees, and (more occasional?) = +person-to-person transactions tend to be free and people just understand = +that the money isn't going to be spendable for a while. + + +> person-to-business transactions. For person-to-person transactions +Why should there be two classes of transactions? Where does paying a = +local business at a farmer=92s stand lie in that realm? Transactions = +should work the same regardless of who is on the receiving end. + +> any fee at all is confusing because you intuitively expect that if you = +send 1 mBTC, then 1 mBTC will arrive the other end +The paradigm of sending money has an explicit cost is not new... I think = +people are used to Western Union/PayPal and associated fees, no? It=92s = +okay to have a fee if it=92s reasonable, so let=92s inform the user what = +the estimated cost is to send a transaction in a reasonable amount of = +time. + +> wonder if we'll end up in a world where buying things from shops = +involves paying fees +I stayed in a hotel for the first night here here in Milan, and there = +was an (anticipated) surcharge for the use of credit over cash. Again, = +nothing new here. + + +Fees are only confusing because existing clients do a terrible job of = +presenting the information to the user. In Hive Wallet, I=92m of the = +opinion that we should inform the user in an intuitive way to let them = +make an informed decision.= + +--Apple-Mail=_90B85D20-1FD8-4B03-A7A1-33B4072408B7 +Content-Transfer-Encoding: quoted-printable +Content-Type: text/html; + charset=windows-1252 + +<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html = +charset=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; = +-webkit-nbsp-mode: space; -webkit-line-break: = +after-white-space;"><div><br></div><div><div>On Dec 3, 2013, at 12:29 = +PM, Mike Hearn <<a = +href=3D"mailto:mike@plan99.net">mike@plan99.net</a>> wrote:</div><br = +class=3D"Apple-interchange-newline"><blockquote type=3D"cite"><span = +style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; = +font-variant: normal; font-weight: normal; letter-spacing: normal; = +line-height: normal; orphans: auto; text-align: start; text-indent: 0px; = +text-transform: none; white-space: normal; widows: auto; word-spacing: = +0px; -webkit-text-stroke-width: 0px; float: none; display: inline = +!important;">It may be acceptable that receivers don't always receive = +exactly what they requested, at least for person-to-business = +transactions. For person-to-person transactions of course any fee = +at all is confusing because you intuitively expect that if you send 1 = +mBTC, then 1 mBTC will arrive the other end. I wonder if we'll end up in = +a world where buying things from shops involves paying fees, and (more = +occasional?) person-to-person transactions tend to be free and people = +just understand that the money isn't going to be spendable for a = +while.</span></blockquote></div><br><div><br></div><div>> = +person-to-business transactions. For person-to-person = +transactions</div><div>Why should there be two classes of transactions? = +Where does paying a local business at a farmer=92s stand lie in that = +realm? Transactions should work the same regardless of who is on the = +receiving end.</div><div><br></div><div>> any fee at all is = +confusing because you intuitively expect that if you send 1 mBTC, then 1 = +mBTC will arrive the other end</div><div>The paradigm of sending money = +has an explicit cost is not new... I think people are used to Western = +Union/PayPal and associated fees, no? It=92s okay to have a fee if = +it=92s reasonable, so let=92s inform the user what the estimated cost is = +to send a transaction in a reasonable amount of = +time.</div><div><br></div><div>> wonder if we'll end up in a = +world where buying things from shops involves paying fees</div><div>I = +stayed in a hotel for the first night here here in Milan, and there was = +an (anticipated) surcharge for the use of credit over cash. Again, = +nothing new here.</div><div><br></div><div><br></div><div>Fees are only = +confusing because existing clients do a terrible job of presenting the = +information to the user. In Hive Wallet, I=92m of the opinion that we = +should inform the user in an intuitive way to let them make an informed = +decision.</div></body></html>= + +--Apple-Mail=_90B85D20-1FD8-4B03-A7A1-33B4072408B7-- + + |