📅 Original date posted:2015-12-08
📝 Original message:On Tue, Dec 8, 2015 at 4:58 AM, Anthony Towns via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> Having a cost function rather than separate limits does make it easier to
> build blocks (approximately) optimally, though (ie, just divide the fee by
> (base_bytes+witness_bytes/4) and sort). Are there any other benefits?
Actually being able to compute fees for your transaction: If there are
multiple limits that are "at play" then how you need to pay would
depend on the entire set of other candidate transactions, which is
unknown to you. Avoiding the need for a fancy solver in the miner is
also virtuous, because requiring software complexity there can make
for centralization advantages or divert development/maintenance cycles
in open source software off to other ends... The multidimensional
optimization is harder to accommodate for improved relay schemes, this
is the same as the "build blocks" but much more critical both because
of the need for consistency and the frequency in which you do it.
These don't, however, apply all that strongly if only one limit is
likely to be the limiting limit... though I am unsure about counting
on that; after all if the other limits wouldn't be limiting, why have
them?
> That seems kinda backwards.
It can seem that way, but all limiting schemes have pathological cases
where someone runs up against the limit in the most costly way. Keep
in mind that casual pathological behavior can be suppressed via
IsStandard like rules without baking them into consensus; so long as
the candidate attacker isn't miners themselves. Doing so where
possible can help avoid cases like the current sigops limiting which
is just ... pretty broken.
Gregory Maxwell [ARCHIVE] /
npub1f2…crwet
2023-06-07 17:45:36
in reply to nevent1q…gele
Author Public Key
npub1f2nvlx49er5c7sqa43src6ssyp6snd4qwvtkwm5avc2l84cs84esecrwetPublished at
2023-06-07 17:45:36Event JSON
{
"id": "300e2a839c212b710a65ce72a60217566875c8573486d91ba2b2c3829426c3b9",
"pubkey": "4aa6cf9aa5c8e98f401dac603c6a10207509b6a07317676e9d6615f3d7103d73",
"created_at": 1686159936,
"kind": 1,
"tags": [
[
"e",
"558b0da1f3869961bbef0556878e1dd6b9ae37e86128bc130bab17f5332c918d",
"",
"root"
],
[
"e",
"db1ce6175b31a15f1ed613ae2e10a79485581ce9695e27c331f12e4f61dd08d7",
"",
"reply"
],
[
"p",
"f0feda6ad58ea9f486e469f87b3b9996494363a26982b864667c5d8acb0542ab"
]
],
"content": "📅 Original date posted:2015-12-08\n📝 Original message:On Tue, Dec 8, 2015 at 4:58 AM, Anthony Towns via bitcoin-dev\n\u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e Having a cost function rather than separate limits does make it easier to\n\u003e build blocks (approximately) optimally, though (ie, just divide the fee by\n\u003e (base_bytes+witness_bytes/4) and sort). Are there any other benefits?\n\nActually being able to compute fees for your transaction: If there are\nmultiple limits that are \"at play\" then how you need to pay would\ndepend on the entire set of other candidate transactions, which is\nunknown to you. Avoiding the need for a fancy solver in the miner is\nalso virtuous, because requiring software complexity there can make\nfor centralization advantages or divert development/maintenance cycles\nin open source software off to other ends... The multidimensional\noptimization is harder to accommodate for improved relay schemes, this\nis the same as the \"build blocks\" but much more critical both because\nof the need for consistency and the frequency in which you do it.\n\nThese don't, however, apply all that strongly if only one limit is\nlikely to be the limiting limit... though I am unsure about counting\non that; after all if the other limits wouldn't be limiting, why have\nthem?\n\n\u003e That seems kinda backwards.\n\nIt can seem that way, but all limiting schemes have pathological cases\nwhere someone runs up against the limit in the most costly way. Keep\nin mind that casual pathological behavior can be suppressed via\nIsStandard like rules without baking them into consensus; so long as\nthe candidate attacker isn't miners themselves. Doing so where\npossible can help avoid cases like the current sigops limiting which\nis just ... pretty broken.",
"sig": "f73771a8d276991a96dbe05062c54442ae07d9445b8f69ad610313cd340623ee0164bebb832f4e2b8bb6a802a7fa3c5a617281d1a1895b416a643ee80ab817f3"
}