📅 Original date posted:2015-06-10
📝 Original message: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.
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.
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 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.
Aaron Voisine
co-founder and CEO
breadwallet.com
On Wed, Jun 10, 2015 at 10:37 AM, Nathan Wilcox <nathan at 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 at leastauthority.com
> twitter: @least_nathan
> PGP: 11169993 / AAAC 5675 E3F7 514C 67ED E9C9 3BFE 5263 1116 9993
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150610/21988162/attachment.html>;
Aaron Voisine [ARCHIVE] /
npub18g…knkzl
2023-06-07 15:37:16
in reply to nevent1q…c98s
Author Public Key
npub18gjvug29c4yg46lmplq38e75gg6wn5mn8taytckcsr4jt8p74h3s5knkzlPublished at
2023-06-07 15:37:16Event JSON
{
"id": "2314a663c49ab26f05d3de652b44e3b34bcec26226e59580f4520cd08d5d8a9e",
"pubkey": "3a24ce2145c5488aebfb0fc113e7d44234e9d3733afa45e2d880eb259c3eade3",
"created_at": 1686152236,
"kind": 1,
"tags": [
[
"e",
"e5c5b327043fce5d06c04d5d47b9e1bc42816638599cdc94c838afd2a20dc49c",
"",
"root"
],
[
"e",
"6ddcb1af794ddaab2b0c7563d6704206c2cf73f078997428e772223e67a64aec",
"",
"reply"
],
[
"p",
"523c0d5379d2d258d92dab5f63a52d60a8a6d34ce6d11f9c60c3f64b24727aaf"
]
],
"content": "📅 Original date posted:2015-06-10\n📝 Original message:It could be done by agreeing on a data format and encoding it in an\nop_return output in the coinbase transaction. If it catches on it could\nlater be enforced with a soft fork.\n\nFor real up-to-the-minute fee calculations you're also going to want to\nlook at the current mempool, how many transactions are waiting, what fees\nthey're paying, etc, but of course that information is susceptible to sybil\nattack.\n\nIn practice what we're doing for now is using services like blockcypher\nwho's business is improving reliability of zero-conf to tell us what\nfee-per-kb is needed, and then putting a hard coded range around it to\nprotect against the service being compromised. This is also the kind of\nthing being done for exchange rate data which is probably the bigger\nsecurity risk until bitcoin becomes the standard unit of account for the\nplanet.\n\nAaron Voisine\nco-founder and CEO\nbreadwallet.com\n\nOn Wed, Jun 10, 2015 at 10:37 AM, Nathan Wilcox \u003cnathan at leastauthority.com\u003e\nwrote:\n\n\u003e [I'm currently wading through bitcoin-development. I'm still about a month\n\u003e behind, so I apologize in advance for any noisy redundancy in this post.]\n\u003e\n\u003e While reading about blocksize, I've just finished Mike Hearn's blog post\n\u003e describing expected systemic behavior as actual blocks approach the current\n\u003e limit (with or without non-protocol-changing implementation improvements):\n\u003e\n\u003e https://medium.com/@octskyward/crash-landing-f5cc19908e32\n\u003e\n\u003e\n\u003e One detail Mike uses to argue against the \"fee's will save us\" line of\n\u003e reasoning is that wallets have no good way to learn fee information.\n\u003e\n\u003e So, here's a proposal to fix that: put fee and (and perhaps block size,\n\u003e UTXO, etc...) statistics into the locally-verifiable data available to SPV\n\u003e clients (ie: block headers).\n\u003e\n\u003e\n\u003e It's easy to imagine a hard fork that places details like per-block total\n\u003e fees, transaction count, fee variance, UTXO delta, etc... in a each block\n\u003e header. This would allow SPV clients to rely on this data with the same\n\u003e PoW-backed assurances as all other header data.\n\u003e\n\u003e This mechanism seems valuable regardless of the outcome of blocksize\n\u003e debate. So long as fees are interesting or important, SPV clients should\n\u003e know about them. (Same for other stats such as UTXO count.)\n\u003e\n\u003e Upgrading the protocol without a hard-fork may be possible and is left as\n\u003e an exercise for the reader. ;-)\n\u003e\n\u003e --\n\u003e Nathan Wilcox\n\u003e Least Authoritarian\n\u003e\n\u003e email: nathan at leastauthority.com\n\u003e twitter: @least_nathan\n\u003e PGP: 11169993 / AAAC 5675 E3F7 514C 67ED E9C9 3BFE 5263 1116 9993\n\u003e\n\u003e\n\u003e ------------------------------------------------------------------------------\n\u003e\n\u003e _______________________________________________\n\u003e Bitcoin-development mailing list\n\u003e Bitcoin-development at lists.sourceforge.net\n\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150610/21988162/attachment.html\u003e",
"sig": "dbe24b9bfe8a5b556377f4b4413fee03c8d52764d2d1af2e226fb9f32293f56e40d53a0b69c4a967e2b558577c9859e18a21166fc312b992b2520ef783007c79"
}