public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Mike Hearn <mike@plan99.net>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: [Bitcoin-development] Floating fees and SPV clients
Date: Sun, 1 Dec 2013 12:51:46 +0100	[thread overview]
Message-ID: <CANEZrP3tGdFh6oG5fbX9JbU6sYbbex1cq=0tQB-0A4aDrdbXrQ@mail.gmail.com> (raw)

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

Lately I was pondering how to make floating fees and SPV wallets work well
together.

I propose the following plan:

1) 0.9 ships with something dead simple, like a command to query what a
node estimates and then clients just take the average, or cross-check a
centralised estimate against the P2P network. It's fast to implement and
simple, but not very secure or decentralised. However it will allow the
feature to launch on some kind of reasonable timeframe.

2) We bump the protocol version and the tx message now gets an optional
protobuf buffer stuck on the end. The first thing put in this protobuf is a
list of the values of the inputs. Using this data, the fee paid by a
transaction can be calculated. In step 2 the data is unauthenticated.

3) Some SPV wallets already set themselves up so that they sync with the
network in the background, e.g. the Android wallet syncs at least every 24
hours. This should become more common, using scheduler capabilities built
into most operating systems. When the wallet syncs with the network, it
sets a deliberately very noisy Bloom filter on its peers and waits around
for 30-60 seconds or so. The wallet observes some of the broadcasts taking
place and records the hashes and associated fees that were paid to disk.
Next time it syncs, it includes the observed hashes into the Bloom filter
used to download the chain, and thus learns how quickly they confirmed. It
can calculate its own fee estimate from that.

4) Finally, when we next hard fork, we make v2 transactions include the
output value in the signature, same as the output script (this proposal has
been on the forums for a while now). That allows the fee data added in step
2 to be cross-checked against the signatures on the inputs, thus
authenticating it.


I think this is a small and easy set of steps that would make it quite hard
to attack - malicious nodes could make it appear that some transactions
never confirmed thus seeming to force the price up, but it's easy to simply
exclude transactions which never confirm at all from the calculations. Plus
of course you can cross-check nodes against each other to try and catch
nodes that are failing to match transactions properly.

One obvious concern is what to do if nodes don't converge on very similar
estimates. Wallets will always want to pay the lowest fee possible, so that
means they'll always be riding the very edge of what's acceptable, opening
up tx propagation to random flaky failures if fee estimates change whilst a
transaction is in progress, or if some nodes don't calculate the same
estimates as others.

If a wallet gets a reject message for a tx that has a fee that are by its
own estimates acceptable, what should it do? What if only some nodes report
that and others don't?

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

             reply	other threads:[~2013-12-01 11:51 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-12-01 11:51 Mike Hearn [this message]
2013-12-01 12:15 ` [Bitcoin-development] Floating fees and SPV clients Andreas Schildbach
2013-12-01 13:41   ` Mike Hearn
2013-12-01 16:50     ` Andreas Schildbach
2013-12-01 17:19       ` Mike Hearn
2013-12-01 17:40         ` Andreas Schildbach
2013-12-01 17:52           ` Mike Hearn
2013-12-01 18:12         ` Peter Todd
2013-12-01 18:18           ` Mike Hearn
2013-12-01 18:37             ` Peter Todd
2013-12-02 13:54         ` Patrick Mead
2013-12-02 14:33           ` Mike Hearn
2013-12-02 14:37             ` Jeff Garzik
2013-12-02 14:44               ` Mike Hearn
2013-12-02 14:47                 ` Jeff Garzik
2013-12-03  1:40                 ` Gavin Andresen
2013-12-03 10:06                   ` Mike Hearn
2013-12-03 10:36                     ` Drak
2013-12-03 10:45                       ` Mike Hearn
2013-12-03 11:04                         ` Drak
2013-12-03 11:07                     ` Gavin Andresen
2013-12-03 11:29                       ` Mike Hearn
2013-12-03 11:37                         ` Peter Todd
2013-12-03 11:41                         ` Gavin Andresen
2013-12-03 11:46                           ` Mike Hearn
2013-12-03 11:54                             ` Gavin Andresen
2013-12-03 12:05                             ` Drak
2013-12-03 11:57                         ` Taylor Gerring
2013-12-03 12:07                           ` Peter Todd
2013-12-03 13:20                             ` Jamie McNaught
2013-12-03 13:20                           ` Mike Hearn
2013-12-03 13:48                             ` Taylor Gerring
2013-12-03 13:54                               ` Mike Hearn
2013-12-03 14:42                             ` Quinn Harris
2013-12-04  1:45                       ` Jeremy Spilman
2013-12-04 10:40                         ` Mike Hearn
2013-12-04 10:57                           ` Peter Todd
2013-12-04 11:09                             ` Mike Hearn
2013-12-04 13:06                               ` Peter Todd
2013-12-04 13:48                                 ` Mike Hearn
2013-12-04 21:51                                   ` Peter Todd
2013-12-03 11:03                   ` Peter Todd
2013-12-03 11:09                     ` Drak
2013-12-03 11:33                       ` Peter Todd
2013-12-04  5:50                   ` kjj
2013-12-03 11:31 ` Peter Todd

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='CANEZrP3tGdFh6oG5fbX9JbU6sYbbex1cq=0tQB-0A4aDrdbXrQ@mail.gmail.com' \
    --to=mike@plan99.net \
    --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