Re: [Bitcoin-development] Proposal: SPV Fee Discovery mechanism
On Thu, Jun 11, 2015 at 12:55 PM, Aaron Voisine vois...@gmail.com wrote: A Header-PoW-verifying client could still be given all transactions in a recent block, from which it can see the in-band fees directly. You don't know the fees paid by any given transaction unless you also have all it's inputs. Transaction inputs do not include an amount. You could however get the average fee-per-kb paid by all transactions in a block by looking at the coinbase transaction, subtracting the block reward, and dividing by the size of block minus the header. Excellent point and alternative proposal. You're right: to get the specifi fees, you'd need all transactions in a block, and all TxOuts with membership proofs. Your alternative seems like a much leaner trade-off for similar data. Aaron Voisine co-founder and CEO breadwallet.com On Thu, Jun 11, 2015 at 11:30 AM, Nathan Wilcox nat...@leastauthority.com wrote: On Wed, Jun 10, 2015 at 2:03 PM, Peter Todd p...@petertodd.org wrote: On Wed, Jun 10, 2015 at 02:00:27PM -0600, Nathan Wilcox 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.) Fee stats can always be fabricated by individual miners because fees can be paid out-of-band. This is a point I hadn't considered carefully before. I don't understand the marketplace here or why miners would want to move fees outside of explicit inband fees. Implicit in this proposal is that the statistics only cover in-band data, because that's the scope of consensus rules, and thus the proposal is only as useful as the information of in-band fees is useful. I've also noticed a detracting technical argument given a particular tradeoff: A Header-PoW-verifying client could still be given all transactions in a recent block, from which it can see the in-band fees directly. The trade-off is the size of those transactions versus the need to alter any consensus rules or do soft forks. Notice how this trade-off's costs change with maximum block size. -- 'peter'[:-1]@petertodd.org 1245bd2f5c99379ee76836227ded9c08324894faabc0d27f -- Nathan Wilcox Least Authoritarian email: nat...@leastauthority.com twitter: @least_nathan PGP: 11169993 / AAAC 5675 E3F7 514C 67ED E9C9 3BFE 5263 1116 9993 -- 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
Re: [Bitcoin-development] Proposal: SPV Fee Discovery mechanism
On Wed, Jun 10, 2015 at 2:03 PM, Peter Todd p...@petertodd.org wrote: On Wed, Jun 10, 2015 at 02:00:27PM -0600, Nathan Wilcox 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.) Fee stats can always be fabricated by individual miners because fees can be paid out-of-band. This is a point I hadn't considered carefully before. I don't understand the marketplace here or why miners would want to move fees outside of explicit inband fees. Implicit in this proposal is that the statistics only cover in-band data, because that's the scope of consensus rules, and thus the proposal is only as useful as the information of in-band fees is useful. I've also noticed a detracting technical argument given a particular tradeoff: A Header-PoW-verifying client could still be given all transactions in a recent block, from which it can see the in-band fees directly. The trade-off is the size of those transactions versus the need to alter any consensus rules or do soft forks. Notice how this trade-off's costs change with maximum block size. -- 'peter'[:-1]@petertodd.org 1245bd2f5c99379ee76836227ded9c08324894faabc0d27f -- 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
Re: [Bitcoin-development] Proposal: SPV Fee Discovery mechanism
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
