From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Z2kxh-0001XW-Bn for bitcoin-development@lists.sourceforge.net; Wed, 10 Jun 2015 18:42:53 +0000 X-ACL-Warn: Received: from mail-oi0-f42.google.com ([209.85.218.42]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Z2kxf-0004TL-Ld for bitcoin-development@lists.sourceforge.net; Wed, 10 Jun 2015 18:42:53 +0000 Received: by oiha141 with SMTP id a141so38185991oih.0 for ; Wed, 10 Jun 2015 11:42:46 -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:date:message-id:subject:from:to :content-type; bh=32+07YryTQCleNinhxqVlrL570Kkv62L+nzkGc9XDg8=; b=RjrPACjjcHSVPAVLZnYp/EbEAlpQon6IC6db0sVBuujFQRvQAhohxtSqg59ssnlJtP ssn0icdbVNPy97ijzb29isMHTZ5m6Zv0SvSw8HusFPoCPML/CROw7moadVy1JvZZT1mn NBOS1rVMfztc0oif1mLnUUVESu32DvMwyMzN9Yke79i87IKJIHfm58l7PWFwrzvnvrgB j7/FBHXzcOc7FqpMIwOQSyOwjsdSjWCu2OSNH0Rd1DvFJOwsuPUFKbXlqFuPZBL4M3R9 4mwD30zoheDsdThW1HTWTw9Rhi2Si/ih3TiT1d+YHhybxa4Or7C1DK73169qtru/A6oa HL0A== X-Gm-Message-State: ALoCoQl9kLbPG5oe5c9BH4dF5LvBOhhm+cH8QNY4a9Mg3T/NteE8dzOvOwC1trkbp4XT+LXega2h MIME-Version: 1.0 X-Received: by 10.60.35.42 with SMTP id e10mr3790804oej.26.1433957879378; Wed, 10 Jun 2015 10:37:59 -0700 (PDT) Received: by 10.182.47.229 with HTTP; Wed, 10 Jun 2015 10:37:59 -0700 (PDT) Date: Wed, 10 Jun 2015 11:37:59 -0600 Message-ID: From: Nathan Wilcox To: bitcoin-development@lists.sourceforge.net Content-Type: multipart/alternative; boundary=089e013d04ee060cd505182d56a6 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: 1Z2kxf-0004TL-Ld Subject: [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 18:42:53 -0000 --089e013d04ee060cd505182d56a6 Content-Type: text/plain; charset=UTF-8 [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 --089e013d04ee060cd505182d56a6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
[I'm currently wading through bitcoin-development= . I'm still about a month behind, so I apologize in advance for any noi= sy redundancy in this post.]

While reading about blocksize, I&= #39;ve just finished Mike Hearn's blog post describing expected systemi= c behavior as actual blocks approach the current limit (with or without non= -protocol-changing implementation improvements):
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 avai= lable to SPV clients (ie: block headers).


It's ea= sy to imagine a hard fork that places details like per-block total fees, tr= ansaction count, fee variance, UTXO delta, etc... in a each block header. T= his would allow SPV clients to rely on this data with the same PoW-backed a= ssurances as all other header data.

This mechanism s= eems 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. ;-)

--
Nathan Wilcox
Least Authoritarian
email: nat= han@leastauthority.com
twitter: @least_nathan
PGP: 11169993 / AAA= C 5675 E3F7 514C 67ED =C2=A0E9C9 3BFE 5263 1116 9993
--089e013d04ee060cd505182d56a6--