path: root/80/dbca5fe83c184ca5440e7681e1cd72f158ae1d

Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
	helo=mx.sourceforge.net)
	by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <nathan@leastauthority.com>) id 1Z2mAv-0003gz-K8
	for bitcoin-development@lists.sourceforge.net;
	Wed, 10 Jun 2015 20:00:37 +0000
X-ACL-Warn: 
Received: from mail-ob0-f176.google.com ([209.85.214.176])
	by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1Z2mAr-0004FH-0p
	for bitcoin-development@lists.sourceforge.net;
	Wed, 10 Jun 2015 20:00:37 +0000
Received: by obbgp2 with SMTP id gp2so42570896obb.2
	for <bitcoin-development@lists.sourceforge.net>;
	Wed, 10 Jun 2015 13:00:27 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type;
	bh=SuciBltJpgfVxiUIavA7S8Gcadz+m/KZR35Qls2RbhU=;
	b=jjUgciLl7Vwjna59yAgZJiDWd8RhX/+856EUD5nIw3HQ113r6aOwwvKhZSCrd84GYX
	nCHerSiJYuyWnYq39IBGuJcs7bNtpibZeGO3Q4hXIPArBm+YqAOpPVhRcOHvOZAyIPVd
	SaMqJoQqBZwSrCHCH2gnzFf3/SKJqgGij9f2qLJ0tTFS0qtjLrUlbYYtoNA/QGQ7ZG9D
	uvUg5VnRvrWhsrF52Xwt3TrslGXk5PZSJlGNi/xsAY0V+TZ4CEN3ItsVYGWafidX2cNZ
	bXYQI2nP9RJX06qfMrBUcrMejIIDQ7yboMIHK2asDFHcCMM0Lneny6x3EWxcqxd4iVZp
	UE9g==
X-Gm-Message-State: ALoCoQm02CNlcBYJL0ir3hAJgyl4wFOL8WtseWDeNpDZluZ1eRfwIwh21+CdlObuH/2XINQpvmvV
MIME-Version: 1.0
X-Received: by 10.182.247.102 with SMTP id yd6mr4302559obc.39.1433966427562;
	Wed, 10 Jun 2015 13:00:27 -0700 (PDT)
Received: by 10.182.47.229 with HTTP; Wed, 10 Jun 2015 13:00:27 -0700 (PDT)
In-Reply-To: <CACq0ZD5=EunMZJJMKfFUGkR=Ye_8nmV0qLkJJ997gbWk1MTC9w@mail.gmail.com>
References: <CAFdHNGgtgWGu8gnnJfM0EcVn2m_Wff5HPwAe-9FBvjR++q0Q-Q@mail.gmail.com>
	<CACq0ZD5=EunMZJJMKfFUGkR=Ye_8nmV0qLkJJ997gbWk1MTC9w@mail.gmail.com>
Date: Wed, 10 Jun 2015 14:00:27 -0600
Message-ID: <CAFdHNGh=eGCwoMF36Siup-h6aSQtE0mvxCfk+OQRJb-37pds9w@mail.gmail.com>
From: Nathan Wilcox <nathan@leastauthority.com>
To: Aaron Voisine <voisine@gmail.com>
Content-Type: multipart/alternative; boundary=089e01537dea88fc0b05182f5328
X-Spam-Score: 1.0 (+)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	1.0 HTML_MESSAGE           BODY: HTML included in message
X-Headers-End: 1Z2mAr-0004FH-0p
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: Wed, 10 Jun 2015 20:00:37 -0000

--089e01537dea88fc0b05182f5328
Content-Type: text/plain; charset=UTF-8

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.)


> For real up-to-the-minute fee calculations you're also going to want to
> look at the current mempool, how many transactions are waiting, what fees
> they're paying, etc, but of course that information is susceptible to sybil
> attack.
>

Hm, when you mention Sybil attack, I don't quite follow.

When a client relies on any report of a mempool [*], this is already
outside the realm of locally-verifiable SPV information, so they are
already susceptible to the service making false claims. If that's
acceptable (and in many cases it may be) then this whole mechanism is moot,
because the client can ask the service for fee statistics for past blocks.


> In practice what we're doing for now is using services like blockcypher
> who's business is improving reliability of zero-conf to tell us what
> fee-per-kb is needed, and then putting a hard coded range around it to
> protect against the service being compromised.
>

This is interesting for me, because I had previously believed fees were
fairly static presently, and also because I like hearing about real life
wallet implementations.

So if this "SPV Fee Stats" feature were added, a wallet might rely on an
API for timely stats (aka "block height < 1") then verify that the API
isn't lying after doing SPV verification of fee stats for confirmed blocks.


This is also the kind of thing being done for exchange rate data which is
> probably the bigger security risk until bitcoin becomes the standard unit
> of account for the planet.
>
>
That makes sense, although there's no SPV equivalent for exchange data.


Aaron Voisine
> co-founder and CEO
> breadwallet.com
>
> On Wed, Jun 10, 2015 at 10:37 AM, Nathan Wilcox <nathan@leastauthority.com
> > wrote:
>
>> [I'm currently wading through bitcoin-development. I'm still about a
>> month behind, so I apologize in advance for any noisy redundancy in this
>> post.]
>>
>> While reading about blocksize, I've just finished Mike Hearn's blog post
>> describing expected systemic behavior as actual blocks approach the current
>> limit (with or without non-protocol-changing implementation improvements):
>>
>> https://medium.com/@octskyward/crash-landing-f5cc19908e32
>>
>>
>> One detail Mike uses to argue against the "fee's will save us" line of
>> reasoning is that wallets have no good way to learn fee information.
>>
>> So, here's a proposal to fix that: put fee and (and perhaps block size,
>> UTXO, etc...) statistics into the locally-verifiable data available to SPV
>> clients (ie: block headers).
>>
>>
>> It's easy to imagine a hard fork that places details like per-block total
>> fees, transaction count, fee variance, UTXO delta, etc... in a each block
>> header. This would allow SPV clients to rely on this data with the same
>> PoW-backed assurances as all other header data.
>>
>> This mechanism seems valuable regardless of the outcome of blocksize
>> debate. So long as fees are interesting or important, SPV clients should
>> know about them. (Same for other stats such as UTXO count.)
>>
>> Upgrading the protocol without a hard-fork may be possible and is left as
>> an exercise for the reader. ;-)
>>
>> --
>> Nathan Wilcox
>> Least Authoritarian
>>
>> email: nathan@leastauthority.com
>> twitter: @least_nathan
>> PGP: 11169993 / AAAC 5675 E3F7 514C 67ED  E9C9 3BFE 5263 1116 9993
>>
>>
>> ------------------------------------------------------------------------------
>>
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>


-- 
Nathan Wilcox
Least Authoritarian

email: nathan@leastauthority.com
twitter: @least_nathan
PGP: 11169993 / AAAC 5675 E3F7 514C 67ED  E9C9 3BFE 5263 1116 9993

--089e01537dea88fc0b05182f5328
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Wed, Jun 10, 2015 at 1:19 PM, Aaron Voisine <span dir=
=3D"ltr">&lt;<a href=3D"mailto:voisine@gmail.com" target=3D"_blank">voisine=
@gmail.com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=
=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">It could b=
e 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 wi=
th a soft fork.<div><br></div></div></blockquote><div><br></div><div>Sounds=
 plausible, except SPV protocols would need to include this coinbase txn if=
 it&#39;s going to help SPV clients. (Until a softfork is activated, SPV cl=
ients should not rely on this encoding, since until that time the results c=
an be fabricated by individual miners.)<br></div><div>=C2=A0</div><blockquo=
te class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc so=
lid;padding-left:1ex"><div dir=3D"ltr"><div></div><div>For real up-to-the-m=
inute fee calculations you&#39;re also going to want to look at the current=
 mempool, how many transactions are waiting, what fees they&#39;re paying, =
etc, but of course that information is susceptible to sybil attack.</div></=
div></blockquote><div><br></div><div>Hm, when you mention Sybil attack, I d=
on&#39;t quite follow.<br></div><div><br></div><div>When a client relies on=
 any report of a mempool [*], this is already outside the realm of locally-=
verifiable SPV information, so they are already susceptible to the service =
making false claims. If that&#39;s acceptable (and in many cases it may be)=
 then this whole mechanism is moot, because the client can ask the service =
for fee statistics for past blocks.<br><br></div><blockquote class=3D"gmail=
_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:=
1ex"><div dir=3D"ltr"><div><br></div><div>In practice what we&#39;re doing =
for now is using services like blockcypher who&#39;s business is improving =
reliability of zero-conf to tell us what fee-per-kb is needed, and then put=
ting a hard coded range around it to protect against the service being comp=
romised.</div></div></blockquote><div><br></div><div>This is interesting fo=
r me, because I had previously believed fees were fairly static presently, =
and also because I like hearing about real life wallet implementations. <br=
><br>So if this &quot;SPV Fee Stats&quot; feature were added, a wallet migh=
t rely on an API for timely stats (aka &quot;block height &lt; 1&quot;) the=
n verify that the API isn&#39;t lying after doing SPV verification of fee s=
tats for confirmed blocks.<br></div><div>=C2=A0<br><br></div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p=
adding-left:1ex"><div dir=3D"ltr"><div>This is also the kind of thing being=
 done for exchange rate data which is probably the bigger security risk unt=
il bitcoin becomes the standard unit of account for the planet.</div><div c=
lass=3D"gmail_extra"><div><div><div dir=3D"ltr"><div><div dir=3D"ltr"><div>=
<br></div></div></div></div></div></div></div></div></blockquote><div><br><=
/div><div>That makes sense, although there&#39;s no SPV equivalent for exch=
ange data.<br><br><br></div><blockquote class=3D"gmail_quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"=
><div class=3D"gmail_extra"><div><div><div dir=3D"ltr"><div><div dir=3D"ltr=
"><div>Aaron Voisine</div><div>co-founder and CEO<br><a href=3D"http://brea=
dwallet.com" target=3D"_blank">breadwallet.com</a></div></div></div></div><=
/div></div>
<br><div class=3D"gmail_quote"><div><div class=3D"h5">On Wed, Jun 10, 2015 =
at 10:37 AM, Nathan Wilcox <span dir=3D"ltr">&lt;<a href=3D"mailto:nathan@l=
eastauthority.com" target=3D"_blank">nathan@leastauthority.com</a>&gt;</spa=
n> wrote:<br></div></div><blockquote class=3D"gmail_quote" style=3D"margin:=
0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class=3D"=
h5"><div dir=3D"ltr"><div>[I&#39;m currently wading through bitcoin-develop=
ment. I&#39;m still about a month behind, so I apologize in advance for any=
 noisy redundancy in this post.]<br><br></div>While reading about blocksize=
, I&#39;ve just finished Mike Hearn&#39;s blog post describing expected sys=
temic behavior as actual blocks approach the current limit (with or without=
 non-protocol-changing implementation improvements):<br><div><br><a href=3D=
"https://medium.com/@octskyward/crash-landing-f5cc19908e32" target=3D"_blan=
k">https://medium.com/@octskyward/crash-landing-f5cc19908e32</a><br><br><br=
></div><div>One detail Mike uses to argue against the &quot;fee&#39;s will =
save us&quot; line of reasoning is that wallets have no good way to learn f=
ee information.<br><br></div><div>So, here&#39;s a proposal to fix that: pu=
t fee and (and perhaps block size, UTXO, etc...) statistics into the locall=
y-verifiable data available to SPV clients (ie: block headers).<br><br></di=
v><br><div>It&#39;s easy to imagine a hard fork that places details like pe=
r-block total fees, transaction count, fee variance, UTXO delta, etc... in =
a each block header. This would allow SPV clients to rely on this data with=
 the same PoW-backed assurances as all other header data.<br><br></div><div=
><div>This mechanism seems valuable regardless of the outcome of=20
blocksize debate. So long as fees are interesting or important, SPV=20
clients should know about them. (Same for other stats such as UTXO=20
count.)<br><br></div><div>Upgrading the protocol without a hard-fork may be=
 possible and is left as an exercise for the reader. ;-)<span><font color=
=3D"#888888"><br></font></span></div><span><font color=3D"#888888"><br>-- <=
br><div>Nathan Wilcox<br>Least Authoritarian<br><br>email: <a href=3D"mailt=
o:nathan@leastauthority.com" target=3D"_blank">nathan@leastauthority.com</a=
><br>twitter: @least_nathan<br>PGP: 11169993 / AAAC 5675 E3F7 514C 67ED =C2=
=A0E9C9 3BFE 5263 1116 9993<br></div>
</font></span></div></div>
<br></div></div>-----------------------------------------------------------=
-------------------<br>
<br>_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net" target=3D"_bla=
nk">Bitcoin-development@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
<br></blockquote></div><br></div></div>
</blockquote></div><br><br clear=3D"all"><br>-- <br><div class=3D"gmail_sig=
nature">Nathan Wilcox<br>Least Authoritarian<br><br>email: <a href=3D"mailt=
o:nathan@leastauthority.com" target=3D"_blank">nathan@leastauthority.com</a=
><br>twitter: @least_nathan<br>PGP: 11169993 / AAAC 5675 E3F7 514C 67ED =C2=
=A0E9C9 3BFE 5263 1116 9993<br></div>
</div></div>

--089e01537dea88fc0b05182f5328--