📅 Original date posted:2016-02-09
📝 Original message:On 02/09/16 22:10, Luke Dashjr wrote:
> On Tuesday, February 09, 2016 10:00:44 PM Matt Corallo via bitcoin-dev wrote:
>> Indeed, we could push for more place by just always having one 0-byte,
>> but I'm not sure the added complexity helps anything? ASICs can never be
>> designed which use more extra-nonce-space than what they can reasonably
>> assume will always be available, so we might as well just set the
>> maximum number of bytes and let ASIC designers know exactly what they
>> have available. Currently blocks start with at least 8 0-bytes. We could
>> just say minimum difficulty is now 6 0-bytes (2**16x harder) and reserve
>> those?
>
> The extranonce rolling doesn't necessarily need to happen in the ASIC itself.
> With the current extranonce-in-gentx, an old RasPi 1 can only handle creating
> work for up to 5 Gh/s with a 500k gentx.
Did you read the footnote on my original email? There is some potential
for optimization if you can brute-force the midstate, which today
requires using the nVersion space as nonce. In order to fix this we need
to add nonce space in the first compression function, so this is an
ideal place. Even ignoring that reducing complexity of mining control
stuff is really nice. If we could go back to just providing block
headers to miners instead of having to provide the entire
transaction-hash-list we could move a ton of complexity back into
Bitcoin Core from mining setups, which have historically been pretty
poorly-reviewed codebases.
> Furthermore, there is a direct correlation between ASIC speeds and difficulty,
> so increasing the extranonce space dynamically makes a lot of sense.
>
> I don't see any reason *not* to increase the minimum difficulty at the same
> time, though.
Meh, my point was less that its a really bad idea and more that it adds
compexity that I dont see much need for.
Matt Corallo [ARCHIVE] /
npub1e4…jxmcu
2023-06-07 17:48:58
in reply to nevent1q…n497
Author Public Key
npub1e46n428mcyfwznl7nlsf6d3s7rhlwm9x3cmkuqzt3emmdpadmkaqqjxmcuSeen on
wss://relay.nostr.bandPublished at
2023-06-07 17:48:58Event JSON
{
"id": "605ef57e4b3ddf32f84de7fbcd4aee67c756ed2c8f6430688491d4067655d04b",
"pubkey": "cd753aa8fbc112e14ffe9fe09d3630f0eff76ca68e376e004b8e77b687adddba",
"created_at": 1686160138,
"kind": 1,
"tags": [
[
"e",
"8c25de74ae7131786de7d5ab012e48bad7eff95963972248b7442bdb60a9ffb5",
"",
"root"
],
[
"e",
"c4b4ef9add852ce5d291e9be3222ea58a12f44a80eb80417a61146c767750c82",
"",
"reply"
],
[
"p",
"5a6d1f44482b67b5b0d30cc1e829b66a251f0dc99448377dbe3c5e0faf6c3803"
]
],
"content": "📅 Original date posted:2016-02-09\n📝 Original message:On 02/09/16 22:10, Luke Dashjr wrote:\n\u003e On Tuesday, February 09, 2016 10:00:44 PM Matt Corallo via bitcoin-dev wrote:\n\u003e\u003e Indeed, we could push for more place by just always having one 0-byte,\n\u003e\u003e but I'm not sure the added complexity helps anything? ASICs can never be\n\u003e\u003e designed which use more extra-nonce-space than what they can reasonably\n\u003e\u003e assume will always be available, so we might as well just set the\n\u003e\u003e maximum number of bytes and let ASIC designers know exactly what they\n\u003e\u003e have available. Currently blocks start with at least 8 0-bytes. We could\n\u003e\u003e just say minimum difficulty is now 6 0-bytes (2**16x harder) and reserve\n\u003e\u003e those?\n\u003e \n\u003e The extranonce rolling doesn't necessarily need to happen in the ASIC itself. \n\u003e With the current extranonce-in-gentx, an old RasPi 1 can only handle creating \n\u003e work for up to 5 Gh/s with a 500k gentx.\n\n\nDid you read the footnote on my original email? There is some potential\nfor optimization if you can brute-force the midstate, which today\nrequires using the nVersion space as nonce. In order to fix this we need\nto add nonce space in the first compression function, so this is an\nideal place. Even ignoring that reducing complexity of mining control\nstuff is really nice. If we could go back to just providing block\nheaders to miners instead of having to provide the entire\ntransaction-hash-list we could move a ton of complexity back into\nBitcoin Core from mining setups, which have historically been pretty\npoorly-reviewed codebases.\n\n\n\u003e Furthermore, there is a direct correlation between ASIC speeds and difficulty, \n\u003e so increasing the extranonce space dynamically makes a lot of sense.\n\u003e \n\u003e I don't see any reason *not* to increase the minimum difficulty at the same \n\u003e time, though.\n\nMeh, my point was less that its a really bad idea and more that it adds\ncompexity that I dont see much need for.",
"sig": "bbe3375a9057bb231af493d21a452bc2c294ab2e66d8447cc8cac8265e64ae66428fbcbc96dfe64b659ae096aae8e4b6bae2984af9c257b66c97829d34a83573"
}