From: Aaron Voisine <voisine@gmail•com>
To: Nathan Wilcox <nathan@leastauthority•com>
Cc: Bitcoin Development <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Proposal: SPV Fee Discovery mechanism
Date: Wed, 10 Jun 2015 14:18:26 -0700 [thread overview]
Message-ID: <CACq0ZD5O2Yt_XTzhTPm6tEEdA1OQinbeTfJi7cQE-=N=GWXTxQ@mail.gmail.com> (raw)
In-Reply-To: <CAFdHNGh=eGCwoMF36Siup-h6aSQtE0mvxCfk+OQRJb-37pds9w@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 5306 bytes --]
> 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 <nathan@leastauthority•com>
wrote:
> On Wed, Jun 10, 2015 at 1:19 PM, Aaron Voisine <voisine@gmail•com> 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
>
[-- Attachment #2: Type: text/html, Size: 8651 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 [this message]
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='CACq0ZD5O2Yt_XTzhTPm6tEEdA1OQinbeTfJi7cQE-=N=GWXTxQ@mail.gmail.com' \
--to=voisine@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=nathan@leastauthority$(echo .)com \
/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