📅 Original date posted:2015-06-11
📝 Original message:> 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.
Aaron Voisine
co-founder and CEO
breadwallet.com
On Thu, Jun 11, 2015 at 11:30 AM, Nathan Wilcox <nathan at leastauthority.com>
wrote:
> On Wed, Jun 10, 2015 at 2:03 PM, Peter Todd <pete at 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 <voisine at 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
>> 00000000000000001245bd2f5c99379ee76836227ded9c08324894faabc0d27f
>>
>
>
>
> --
> Nathan Wilcox
> Least Authoritarian
>
> email: nathan at leastauthority.com
> twitter: @least_nathan
> PGP: 11169993 / AAAC 5675 E3F7 514C 67ED E9C9 3BFE 5263 1116 9993
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150611/574993ab/attachment.html>;
Aaron Voisine [ARCHIVE] /
npub18g…knkzl
2023-06-07 15:37:18
in reply to nevent1q…r7uw
Author Public Key
npub18gjvug29c4yg46lmplq38e75gg6wn5mn8taytckcsr4jt8p74h3s5knkzlPublished at
2023-06-07 15:37:18Event JSON
{
"id": "9542049d90bf0ee7bc955469acd5594bf85779d9438fdd3b2da62e7b9f4d0d1c",
"pubkey": "3a24ce2145c5488aebfb0fc113e7d44234e9d3733afa45e2d880eb259c3eade3",
"created_at": 1686152238,
"kind": 1,
"tags": [
[
"e",
"e5c5b327043fce5d06c04d5d47b9e1bc42816638599cdc94c838afd2a20dc49c",
"",
"root"
],
[
"e",
"f513bfcdc57612162e436a803e35eb1ea60358838e3722b0a06e373685577ac5",
"",
"reply"
],
[
"p",
"523c0d5379d2d258d92dab5f63a52d60a8a6d34ce6d11f9c60c3f64b24727aaf"
]
],
"content": "📅 Original date posted:2015-06-11\n📝 Original message:\u003e A Header-PoW-verifying client could still be given all transactions in a\nrecent block, from which it can see the in-band fees directly.\n\nYou don't know the fees paid by any given transaction unless you also have\nall it's inputs. Transaction inputs do not include an amount. You could\nhowever get the average fee-per-kb paid by all transactions in a block by\nlooking at the coinbase transaction, subtracting the block reward, and\ndividing by the size of block minus the header.\n\n\nAaron Voisine\nco-founder and CEO\nbreadwallet.com\n\nOn Thu, Jun 11, 2015 at 11:30 AM, Nathan Wilcox \u003cnathan at leastauthority.com\u003e\nwrote:\n\n\u003e On Wed, Jun 10, 2015 at 2:03 PM, Peter Todd \u003cpete at petertodd.org\u003e wrote:\n\u003e\n\u003e\u003e On Wed, Jun 10, 2015 at 02:00:27PM -0600, Nathan Wilcox wrote:\n\u003e\u003e \u003e On Wed, Jun 10, 2015 at 1:19 PM, Aaron Voisine \u003cvoisine at gmail.com\u003e\n\u003e\u003e wrote:\n\u003e\u003e \u003e\n\u003e\u003e \u003e \u003e It could be done by agreeing on a data format and encoding it in an\n\u003e\u003e \u003e \u003e op_return output in the coinbase transaction. If it catches on it\n\u003e\u003e could\n\u003e\u003e \u003e \u003e later be enforced with a soft fork.\n\u003e\u003e \u003e \u003e\n\u003e\u003e \u003e \u003e\n\u003e\u003e \u003e Sounds plausible, except SPV protocols would need to include this\n\u003e\u003e coinbase\n\u003e\u003e \u003e txn if it's going to help SPV clients. (Until a softfork is activated,\n\u003e\u003e SPV\n\u003e\u003e \u003e clients should not rely on this encoding, since until that time the\n\u003e\u003e results\n\u003e\u003e \u003e can be fabricated by individual miners.)\n\u003e\u003e\n\u003e\u003e Fee stats can always be fabricated by individual miners because fees can\n\u003e\u003e be paid out-of-band.\n\u003e\u003e\n\u003e\u003e\n\u003e This is a point I hadn't considered carefully before. I don't understand\n\u003e the marketplace here or why miners would want to move fees outside of\n\u003e explicit inband fees. Implicit in this proposal is that the statistics only\n\u003e cover in-band data, because that's the scope of consensus rules, and thus\n\u003e the proposal is only as useful as the information of in-band fees is useful.\n\u003e\n\u003e I've also noticed a detracting technical argument given a particular\n\u003e tradeoff:\n\u003e\n\u003e A Header-PoW-verifying client could still be given all transactions in a\n\u003e recent block, from which it can see the in-band fees directly. The\n\u003e trade-off is the size of those transactions versus the need to alter any\n\u003e consensus rules or do soft forks.\n\u003e\n\u003e Notice how this trade-off's costs change with maximum block size.\n\u003e\n\u003e\n\u003e\n\u003e\n\u003e\u003e --\n\u003e\u003e 'peter'[:-1]@petertodd.org\n\u003e\u003e 00000000000000001245bd2f5c99379ee76836227ded9c08324894faabc0d27f\n\u003e\u003e\n\u003e\n\u003e\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-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150611/574993ab/attachment.html\u003e",
"sig": "21a94495eaa0ba9238a787a3a8875b65eb1acf18e1aa1ed32ee40f8d1f9abed42035e23b05215c656874e20088d2e8db5d4754fbffc5ba3b0061758af22b1dc6"
}