From: Aaron Voisine <voisine@gmail•com>
To: Mike Hearn <mike@plan99•net>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Proposal: SPV Fee Discovery mechanism
Date: Wed, 10 Jun 2015 14:18:30 -0700 [thread overview]
Message-ID: <CACq0ZD6Qr7F7_20Nfd0a8TTHEVMR0fxu-T5bO4FfN1Lp9PcGDQ@mail.gmail.com> (raw)
In-Reply-To: <CANEZrP3+jW3BO=Zv41CGubJL7bSZ==o=Wp83K6Q0xL4PP+0ZUQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1932 bytes --]
The other complication is that this will tend to be a lagging indicator
based on network congestion from the last time you connected. If we assume
that transactions are being dropped in an unpredictable way when blocks are
full, knowing the network congestion *right now* is critical, and even then
you just have to hope that someone who wants that space more than you do
doesn't show up after you disconnect.
Aaron Voisine
co-founder and CEO
breadwallet.com
On Wed, Jun 10, 2015 at 1:26 PM, Mike Hearn <mike@plan99•net> wrote:
> I described an alternative way for SPV wallets to learn about fees some
> time ago. It requires a new transaction version that embeds output values
> into the signed data. Then an upgrade to the P2P protocol to send UTXO data
> along with transactions when they are relayed.
>
> The idea is that the wallet sets a Bloom filter with an FP rate that
> ensures it will see some random subset of all transactions being broadcast
> on the network, and with the extra data, it can calculate the fee paid.
> Once a transaction broadcast is observed the wallet includes that tx hash
> in its next Bloom filter, thus it can see which block the tx confirmed in.
> By measuring the amount of time that passed between a broadcast and it
> appearing in a block, it can calculate its own tables of fee paid:time
> taken.
>
> This has the advantage that you don't have to trust miners to publish data
> accurately. However it requires some protocol upgrades and of course, a lot
> of new code in SPV wallets.
>
> The way Bitcoin Wallet for Android handles fees currently is to just
> update a hard coded value every so often.
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
[-- Attachment #2: Type: text/html, Size: 2657 bytes --]
next prev parent reply other threads:[~2015-06-10 21:18 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-10 17:37 Nathan Wilcox
2015-06-10 19:19 ` 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 [this message]
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=CACq0ZD6Qr7F7_20Nfd0a8TTHEVMR0fxu-T5bO4FfN1Lp9PcGDQ@mail.gmail.com \
--to=voisine@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=mike@plan99$(echo .)net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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