diff options
| author | Aaron Voisine <voisine@gmail.com> | 2015-06-11 11:55:09 -0700 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2015-06-11 18:55:15 +0000 |
| commit | 4c73ea561cc1d821df1f1f22ca65735b7ca848cb (patch) | |
| tree | 153dbe913c5724e01072eb1392b6ef911997b821 | |
| parent | d75700f25c1ea861c24369605fd2e2155d3fe39e (diff) | |
| download | pi-bitcoindev-4c73ea561cc1d821df1f1f22ca65735b7ca848cb.tar.gz pi-bitcoindev-4c73ea561cc1d821df1f1f22ca65735b7ca848cb.zip | |
Re: [Bitcoin-development] Proposal: SPV Fee Discovery mechanism
| -rw-r--r-- | b0/b10b4c8fa285a7fa779bc4fd0b8e4adb6e9aed | 221 |
1 files changed, 221 insertions, 0 deletions
diff --git a/b0/b10b4c8fa285a7fa779bc4fd0b8e4adb6e9aed b/b0/b10b4c8fa285a7fa779bc4fd0b8e4adb6e9aed new file mode 100644 index 000000000..ab408bbc2 --- /dev/null +++ b/b0/b10b4c8fa285a7fa779bc4fd0b8e4adb6e9aed @@ -0,0 +1,221 @@ +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 <voisine@gmail.com>) id 1Z37dD-0006wW-QQ + for bitcoin-development@lists.sourceforge.net; + Thu, 11 Jun 2015 18:55:15 +0000 +Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com + designates 209.85.216.169 as permitted sender) + client-ip=209.85.216.169; envelope-from=voisine@gmail.com; + helo=mail-qc0-f169.google.com; +Received: from mail-qc0-f169.google.com ([209.85.216.169]) + by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) + (Exim 4.76) id 1Z37dC-0004yJ-Mj + for bitcoin-development@lists.sourceforge.net; + Thu, 11 Jun 2015 18:55:15 +0000 +Received: by qcjl8 with SMTP id l8so4637452qcj.3 + for <bitcoin-development@lists.sourceforge.net>; + Thu, 11 Jun 2015 11:55:09 -0700 (PDT) +MIME-Version: 1.0 +X-Received: by 10.140.107.228 with SMTP id h91mr13537038qgf.1.1434048909166; + Thu, 11 Jun 2015 11:55:09 -0700 (PDT) +Received: by 10.140.91.37 with HTTP; Thu, 11 Jun 2015 11:55:09 -0700 (PDT) +In-Reply-To: <CAFdHNGg-gJ99L4oartyMMX3PhykhekNbuLrs7Z8JN0zTpwgaZw@mail.gmail.com> +References: <CAFdHNGgtgWGu8gnnJfM0EcVn2m_Wff5HPwAe-9FBvjR++q0Q-Q@mail.gmail.com> + <CACq0ZD5=EunMZJJMKfFUGkR=Ye_8nmV0qLkJJ997gbWk1MTC9w@mail.gmail.com> + <CAFdHNGh=eGCwoMF36Siup-h6aSQtE0mvxCfk+OQRJb-37pds9w@mail.gmail.com> + <20150610200323.GA13724@savin.petertodd.org> + <CAFdHNGg-gJ99L4oartyMMX3PhykhekNbuLrs7Z8JN0zTpwgaZw@mail.gmail.com> +Date: Thu, 11 Jun 2015 11:55:09 -0700 +Message-ID: <CACq0ZD4LDTWXsk8Lk5Yf3D7FOwnrgY_oVjRHgH0PhRYmb3ZOdg@mail.gmail.com> +From: Aaron Voisine <voisine@gmail.com> +To: Nathan Wilcox <nathan@leastauthority.com> +Content-Type: multipart/alternative; boundary=001a113a360ed251a705184287b5 +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 + (voisine[at]gmail.com) + -0.0 SPF_PASS SPF: sender matches SPF record + 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: 1Z37dC-0004yJ-Mj +Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net> +Subject: Re: [Bitcoin-development] Proposal: SPV Fee Discovery mechanism +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: Thu, 11 Jun 2015 18:55:15 -0000 + +--001a113a360ed251a705184287b5 +Content-Type: text/plain; charset=UTF-8 + +> A Header-PoW-verifying client could still be given all transactions in a +recent block, from which it can see the in-band fees directly. + +You don't know the fees paid by any given transaction unless you also have +all it's inputs. Transaction inputs do not include an amount. You could +however get the average fee-per-kb paid by all transactions in a block by +looking at the coinbase transaction, subtracting the block reward, and +dividing by the size of block minus the header. + + +Aaron Voisine +co-founder and CEO +breadwallet.com + +On Thu, Jun 11, 2015 at 11:30 AM, Nathan Wilcox <nathan@leastauthority.com> +wrote: + +> On Wed, Jun 10, 2015 at 2:03 PM, Peter Todd <pete@petertodd.org> wrote: +> +>> On Wed, Jun 10, 2015 at 02:00:27PM -0600, Nathan Wilcox wrote: +>> > On Wed, Jun 10, 2015 at 1:19 PM, Aaron Voisine <voisine@gmail.com> +>> wrote: +>> > +>> > > It could be done by agreeing on a data format and encoding it in an +>> > > op_return output in the coinbase transaction. If it catches on it +>> could +>> > > later be enforced with a soft fork. +>> > > +>> > > +>> > Sounds plausible, except SPV protocols would need to include this +>> coinbase +>> > txn if it's going to help SPV clients. (Until a softfork is activated, +>> SPV +>> > clients should not rely on this encoding, since until that time the +>> results +>> > can be fabricated by individual miners.) +>> +>> Fee stats can always be fabricated by individual miners because fees can +>> be paid out-of-band. +>> +>> +> This is a point I hadn't considered carefully before. I don't understand +> the marketplace here or why miners would want to move fees outside of +> explicit inband fees. Implicit in this proposal is that the statistics only +> cover in-band data, because that's the scope of consensus rules, and thus +> the proposal is only as useful as the information of in-band fees is useful. +> +> I've also noticed a detracting technical argument given a particular +> tradeoff: +> +> A Header-PoW-verifying client could still be given all transactions in a +> recent block, from which it can see the in-band fees directly. The +> trade-off is the size of those transactions versus the need to alter any +> consensus rules or do soft forks. +> +> Notice how this trade-off's costs change with maximum block size. +> +> +> +> +>> -- +>> 'peter'[:-1]@petertodd.org +>> 00000000000000001245bd2f5c99379ee76836227ded9c08324894faabc0d27f +>> +> +> +> +> -- +> Nathan Wilcox +> Least Authoritarian +> +> email: nathan@leastauthority.com +> twitter: @least_nathan +> PGP: 11169993 / AAAC 5675 E3F7 514C 67ED E9C9 3BFE 5263 1116 9993 +> + +--001a113a360ed251a705184287b5 +Content-Type: text/html; charset=UTF-8 +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr">>=C2=A0<span style=3D"font-size:13px">A Header-PoW-veri= +fying client could still be given all transactions in a recent block, from = +which it can see the in-band fees directly.=C2=A0</span><div><span style=3D= +"font-size:13px"><br></span></div><div>You don't know the fees paid by = +any given transaction unless you also have all it's inputs. Transaction= + inputs do not include an amount. You could however get the average fee-per= +-kb paid by all transactions in a block by looking at the coinbase transact= +ion, subtracting the block reward, and dividing by the size of block minus = +the header.</div></div><div class=3D"gmail_extra"><br clear=3D"all"><div><d= +iv class=3D"gmail_signature"><div dir=3D"ltr"><div><div dir=3D"ltr"><div><b= +r>Aaron Voisine</div><div>co-founder and CEO<br><a href=3D"http://breadwall= +et.com" target=3D"_blank">breadwallet.com</a></div></div></div></div></div>= +</div> +<br><div class=3D"gmail_quote">On Thu, Jun 11, 2015 at 11:30 AM, Nathan Wil= +cox <span dir=3D"ltr"><<a href=3D"mailto:nathan@leastauthority.com" targ= +et=3D"_blank">nathan@leastauthority.com</a>></span> wrote:<br><blockquot= +e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol= +id;padding-left:1ex"><div dir=3D"ltr"><span class=3D"">On Wed, Jun 10, 2015= + at 2:03 PM, Peter Todd <span dir=3D"ltr"><<a href=3D"mailto:pete@petert= +odd.org" target=3D"_blank">pete@petertodd.org</a>></span> wrote:<br></sp= +an><div class=3D"gmail_extra"><div class=3D"gmail_quote"><span class=3D""><= +blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= + #ccc solid;padding-left:1ex"><span>On Wed, Jun 10, 2015 at 02:00:27PM -060= +0, Nathan Wilcox wrote:<br> +> On Wed, Jun 10, 2015 at 1:19 PM, Aaron Voisine <<a href=3D"mailto:v= +oisine@gmail.com" target=3D"_blank">voisine@gmail.com</a>> wrote:<br> +><br> +> > It could be done by agreeing on a data format and encoding it in = +an<br> +> > op_return output in the coinbase transaction. If it catches on it= + could<br> +> > later be enforced with a soft fork.<br> +> ><br> +> ><br> +> Sounds plausible, except SPV protocols would need to include this coin= +base<br> +> txn if it's going to help SPV clients. (Until a softfork is activa= +ted, SPV<br> +> clients should not rely on this encoding, since until that time the re= +sults<br> +> can be fabricated by individual miners.)<br> +<br> +</span>Fee stats can always be fabricated by individual miners because fees= + can<br> +be paid out-of-band.<br> +<span><font color=3D"#888888"><br></font></span></blockquote><div><br></div= +></span><div>This is a point I hadn't considered carefully before. I do= +n't understand the marketplace here or why miners would want to move fe= +es outside of explicit inband fees. Implicit in this proposal is that the s= +tatistics only cover in-band data, because that's the scope of consensu= +s rules, and thus the proposal is only as useful as the information of in-b= +and fees is useful.<br><br>I've also noticed a detracting technical arg= +ument given a particular tradeoff:<br><br>A Header-PoW-verifying client cou= +ld still be given all transactions in a recent block, from which it can see= + the in-band fees directly.=C2=A0 The trade-off is the size of those transa= +ctions versus the need to alter any consensus rules or do soft forks.<br><b= +r></div><div>Notice how this trade-off's costs change with maximum bloc= +k size.<br><br><br></div><span class=3D""><div>=C2=A0</div><blockquote clas= +s=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pad= +ding-left:1ex"><span><font color=3D"#888888"> +--<br> +'peter'[:-1]@<a href=3D"http://petertodd.org" target=3D"_blank">pet= +ertodd.org</a><br> +00000000000000001245bd2f5c99379ee76836227ded9c08324894faabc0d27f<br> +</font></span></blockquote></span></div><br><br clear=3D"all"><span class= +=3D""><br>-- <br><div>Nathan Wilcox<br>Least Authoritarian<br><br>email: <a= + href=3D"mailto:nathan@leastauthority.com" target=3D"_blank">nathan@leastau= +thority.com</a><br>twitter: @least_nathan<br>PGP: 11169993 / AAAC 5675 E3F7= + 514C 67ED =C2=A0E9C9 3BFE 5263 1116 9993<br></div> +</span></div></div> +</blockquote></div><br></div> + +--001a113a360ed251a705184287b5-- + + |