đź“… Original date posted:2015-07-02
đź“ť Original message:Hi folks,
I’m a game developer. I write time critical code for a living and have to deal with memory, CPU, GPU and I/O budgets on a daily basis. These budgets are based on what we call a minimum specification (of hardware); min spec for short. In most cases the min spec is based on entry model machines that are available during launch, and will give the user an enjoyable experience when playing our games. Obviously, we can turn on a number of bells and whistles for people with faster machines, but that’s not the point of this mail.
The point is, can we define a min spec for Bitcoin Core? The number one reason for this is: if you know how your changes affect your available budgets, then the risk of breaking something due to capacity problems is reduced to practically zero.
One way of doing so is to work backwards from what we have right now: Block size (network / disk I/O), SigOps/block (CPU), UTXO size (memory), etc. Then there’s Pieter’s analysis of network bottlenecks and how it affects orphan rates that could be used to set some form of cap on what transfer time + verification time should be to keep the orphan rate at an acceptable level.
So taking all of the above (and more) into account, what configuration would be the bare minimum to comfortably run Bitcoin Core at maximum load and can it be reasonably expected to still be out there in the field running Bitcoin Core? Also, can the parameters that were used to determine this min spec be codified in some way so that they can later be used if Bitcoin Core is optimized (or extended with new functionality) and see how it affects the min spec? Basically, with any reasonably big change, one of the first questions could be: “How does this change affect min spec?"
For example, currently OpenSSL is used to verify the signatures in the transactions. The new secp256k1 implementation is several times faster than (depending on CPU architecture, I’m sure) OpenSSL’s implementation. So it would result in faster verification time. This can then result in the following things; either network I/O and CPU requirements are adjusted downward in the min spec (you can run the new Bitcoin Core on a cheaper configuration), or other parameters can be adjusted upwards (number of SigOps / transaction, block size?), through proper rollout obviously. Since we know how min spec is affected by these changes, they should be non-controversial by default. Nobody running min spec is going to be affected by it, etc.
Every change that has a positive effect on min spec (do more on the same hardware) basically pushes the need to start following any of the curve laws (Nielsen, Moore) forward. No need for miners / node operators to upgrade.
Once we hit what we call SOL (Speed Of Light, the fastest something can go on a specific platform) it’s time to start looking at periodically adjusting min spec upwards, or by that time maybe it’s possible to use conservative plots of the curve laws as a basis.
Lastly, a benchmark test could be developed that can tell everyone running Bitcoin Core how their setup compares to the min spec and how long they can expect to run on this setup.
What do you guys think?
jp
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150701/172ef784/attachment.sig>;
Jean-Paul Kogelman [ARCHIVE] /
npub1sa…8y304
2023-06-07 15:41:27
in reply to nevent1q…d68m
Author Public Key
npub1sa86gng3pvs3jgyt5majwcrhn8ck5qxgy9pjqxkh79u638cd7dys28y304Published at
2023-06-07 15:41:27Event JSON
{
"id": "5d74d4f77f514e0232e3d6509af3ae11e331a93505d53aed483a42ea8d28b1f1",
"pubkey": "874fa44d110b2119208ba6fb27607799f16a00c82143201ad7f179a89f0df349",
"created_at": 1686152487,
"kind": 1,
"tags": [
[
"e",
"cbeb59b6768e318715a77120e4857024067bd925936ab9abad26dc3d4a343b49",
"",
"reply"
],
[
"p",
"a23dbf6c6cc83e14cc3df4e56cc71845f611908084cfe620e83e40c06ccdd3d0"
]
],
"content": "📅 Original date posted:2015-07-02\n📝 Original message:Hi folks,\n\nI’m a game developer. I write time critical code for a living and have to deal with memory, CPU, GPU and I/O budgets on a daily basis. These budgets are based on what we call a minimum specification (of hardware); min spec for short. In most cases the min spec is based on entry model machines that are available during launch, and will give the user an enjoyable experience when playing our games. Obviously, we can turn on a number of bells and whistles for people with faster machines, but that’s not the point of this mail.\n\nThe point is, can we define a min spec for Bitcoin Core? The number one reason for this is: if you know how your changes affect your available budgets, then the risk of breaking something due to capacity problems is reduced to practically zero.\n\nOne way of doing so is to work backwards from what we have right now: Block size (network / disk I/O), SigOps/block (CPU), UTXO size (memory), etc. Then there’s Pieter’s analysis of network bottlenecks and how it affects orphan rates that could be used to set some form of cap on what transfer time + verification time should be to keep the orphan rate at an acceptable level.\n\nSo taking all of the above (and more) into account, what configuration would be the bare minimum to comfortably run Bitcoin Core at maximum load and can it be reasonably expected to still be out there in the field running Bitcoin Core? Also, can the parameters that were used to determine this min spec be codified in some way so that they can later be used if Bitcoin Core is optimized (or extended with new functionality) and see how it affects the min spec? Basically, with any reasonably big change, one of the first questions could be: “How does this change affect min spec?\"\n\nFor example, currently OpenSSL is used to verify the signatures in the transactions. The new secp256k1 implementation is several times faster than (depending on CPU architecture, I’m sure) OpenSSL’s implementation. So it would result in faster verification time. This can then result in the following things; either network I/O and CPU requirements are adjusted downward in the min spec (you can run the new Bitcoin Core on a cheaper configuration), or other parameters can be adjusted upwards (number of SigOps / transaction, block size?), through proper rollout obviously. Since we know how min spec is affected by these changes, they should be non-controversial by default. Nobody running min spec is going to be affected by it, etc.\n\nEvery change that has a positive effect on min spec (do more on the same hardware) basically pushes the need to start following any of the curve laws (Nielsen, Moore) forward. No need for miners / node operators to upgrade.\n\nOnce we hit what we call SOL (Speed Of Light, the fastest something can go on a specific platform) it’s time to start looking at periodically adjusting min spec upwards, or by that time maybe it’s possible to use conservative plots of the curve laws as a basis.\n\nLastly, a benchmark test could be developed that can tell everyone running Bitcoin Core how their setup compares to the min spec and how long they can expect to run on this setup.\n\nWhat do you guys think?\n\n\njp\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 842 bytes\nDesc: Message signed with OpenPGP using GPGMail\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150701/172ef784/attachment.sig\u003e",
"sig": "81cb70bf0b954de0356d21c9c7fa23872d9a749de6fde987f5c9218f6fc822f0929aca9f2d837efd3c84e47bb0249ad2c3fe641d5ff64ffc21c1aee85bbc07a7"
}