> 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 <nat...@leastauthority.com> wrote: > On Wed, Jun 10, 2015 at 1:19 PM, Aaron Voisine <vois...@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 < >> nat...@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: nat...@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: nat...@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
