Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Z2nOL-0007Ul-Hf for bitcoin-development@lists.sourceforge.net; Wed, 10 Jun 2015 21:18:33 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.220.177 as permitted sender) client-ip=209.85.220.177; envelope-from=voisine@gmail.com; helo=mail-qk0-f177.google.com; Received: from mail-qk0-f177.google.com ([209.85.220.177]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Z2nOJ-00076F-VT for bitcoin-development@lists.sourceforge.net; Wed, 10 Jun 2015 21:18:33 +0000 Received: by qkhq76 with SMTP id q76so31594765qkh.2 for ; Wed, 10 Jun 2015 14:18:26 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.140.97.136 with SMTP id m8mr6787517qge.32.1433971106547; Wed, 10 Jun 2015 14:18:26 -0700 (PDT) Received: by 10.140.91.37 with HTTP; Wed, 10 Jun 2015 14:18:26 -0700 (PDT) In-Reply-To: References: Date: Wed, 10 Jun 2015 14:18:26 -0700 Message-ID: From: Aaron Voisine To: Nathan Wilcox Content-Type: multipart/alternative; boundary=001a113a5d526c8fe90518306a1e 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: 1Z2nOJ-00076F-VT Cc: Bitcoin Development 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2015 21:18:33 -0000 --001a113a5d526c8fe90518306a1e Content-Type: text/plain; charset=UTF-8 > Sounds plausible, except SPV protocols would need to include this coinbase txn if it's going to help SPV clients. Yes you'd either need a way to add those transactions to the bloom filter, or add/modify a p2p message to request it specifically. > when you mention Sybil attack, I don't quite follow. I just mean that someone could spin up a bunch of malicious p2p nodes that lied about mempool data. It's a bit worse for SPV clients since they can't verify that unconfirmed transactions are valid. > I had previously believed fees were fairly static presently, I actually just added it the other day after getting blockcypher to include it in their api. The current release is still using a hard coded fee rate. Aaron Voisine co-founder and CEO breadwallet.com On Wed, Jun 10, 2015 at 1:00 PM, Nathan Wilcox wrote: > On Wed, Jun 10, 2015 at 1:19 PM, Aaron Voisine 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 > --001a113a5d526c8fe90518306a1e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
>=C2=A0Sounds plaus= ible, except SPV protocols would need to include this coinbase txn if it= 9;s going to help SPV clients.

Yes you'd eith= er need a way to add those transactions to the bloom filter, or add/modify = a p2p message to request it specifically.

>= =C2=A0when you mention Sybil attack, I don&#= 39;t quite follow.

I just mean that someone could spin up a bunch of malicious p2p nod= es that lied about mempool data. It's a bit worse for SPV clients since= they can't verify that unconfirmed transactions are valid.
<= br>
>=C2=A0I had previously bel= ieved fees were fairly static presently,

I actual= ly just added it the other day after getting blockcypher to include it in t= heir api. The current release is still using a hard coded fee rate.<= /div>

Aaron Voisine
co-founder= and CEO
breadwalle= t.com

On Wed, Jun 10, 2015 at 1:00 PM, Nathan Wilc= ox <nathan@leastauthority.com> wrote:
On Wed, Jun 10, 2015 = at 1:19 PM, Aaron Voisine <voisine@gmail.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
It could be done by agreeing= on a data format and encoding it in an op_return output in the coinbase tr= ansaction. 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 g= oing to help SPV clients. (Until a softfork is activated, SPV clients shoul= d not rely on this encoding, since until that time the results can be fabri= cated by individual miners.)
=C2=A0
For real up-to= -the-minute fee calculations you're also going to want to look at the c= urrent mempool, how many transactions are waiting, what fees they're pa= ying, etc, but of course that information is susceptible to sybil attack.

Hm, when you mention Sybi= l attack, I don't quite follow.

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


I= n 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 fe= e-per-kb is needed, and then putting a hard coded range around it to protec= t against the service being compromised.

<= /div>
This is interesting for me, because I had previously belie= ved fees were fairly static presently, and also because I like hearing abou= t real life wallet implementations.

So if this "SPV Fee Stats&= quot; feature were added, a wallet might rely on an API for timely stats (a= ka "block height < 1") then verify that the API isn't lyin= g after doing SPV verification of fee stats for confirmed blocks.
=
=C2=A0

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.


Th= at 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 M= ike Hearn's blog post describing expected systemic behavior as actual b= locks approach the current limit (with or without non-protocol-changing imp= lementation improvements):
One detail Mik= e uses to argue against the "fee's will save us" line of reas= oning is that wallets have no good way to learn fee information.

So, here's a proposal to fix that: put fee and (and perhaps blo= ck size, UTXO, etc...) statistics into the locally-verifiable data availabl= e to SPV clients (ie: block headers).


It's easy t= o imagine a hard fork that places details like per-block total fees, transa= ction 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 assur= ances as all other header data.

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

Upgrading the protocol without a hard-fork may be= possible and is left as an exercise for the reader. ;-)

-- <= br>

-----------------------------------------------------------= -------------------

_______________________________________________
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment





--
Nathan Wilcox
Least Authoritarian

email: nathan@leastauthori= ty.com
twitter: @least_nathan
PGP: 11169993 / AAAC 5675 E3F7 514C= 67ED =C2=A0E9C9 3BFE 5263 1116 9993

--001a113a5d526c8fe90518306a1e--