public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Nathan Wilcox <nathan@leastauthority.com>
To: bitcoin-development@lists.sourceforge.net
Subject: [Bitcoin-development] Proposal: SPV Fee Discovery mechanism
Date: Wed, 10 Jun 2015 11:37:59 -0600	[thread overview]
Message-ID: <CAFdHNGgtgWGu8gnnJfM0EcVn2m_Wff5HPwAe-9FBvjR++q0Q-Q@mail.gmail.com> (raw)

[-- Attachment #1: Type: text/plain, Size: 1495 bytes --]

[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

[-- Attachment #2: Type: text/html, Size: 1898 bytes --]

             reply	other threads:[~2015-06-10 18:42 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-10 17:37 Nathan Wilcox [this message]
2015-06-10 19:19 ` [Bitcoin-development] Proposal: SPV Fee Discovery mechanism Aaron Voisine
2015-06-10 20:00   ` Nathan Wilcox
2015-06-10 20:03     ` Peter Todd
2015-06-11 18:30       ` Nathan Wilcox
2015-06-11 18:55         ` Aaron Voisine
2015-06-13 15:38           ` Nathan Wilcox
2015-06-10 21:18     ` Aaron Voisine
2015-06-10 20:26 ` Mike Hearn
2015-06-10 21:18   ` Aaron Voisine
2015-06-11 10:19     ` Mike Hearn
2015-06-11 13:10     ` Peter Todd
2015-06-11 14:11       ` Martin Lie
2015-06-11 17:10       ` Tom Harding
2015-06-11 17:52         ` Mike Hearn
2015-06-12  6:44           ` Aaron Voisine
2015-06-11 18:18       ` Nathan Wilcox

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAFdHNGgtgWGu8gnnJfM0EcVn2m_Wff5HPwAe-9FBvjR++q0Q-Q@mail.gmail.com \
    --to=nathan@leastauthority.com \
    --cc=bitcoin-development@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox