📅 Original date posted:2012-07-24
📝 Original message:I think it would be great to have more nonce space with less merkle
calculation; keeping track of all possible versions of a block already
takes real RAM, real computation. Being able to change one bit in the
header and send out a new block for checking would ease our pool server
work by a real amount, somewhat on the work generation side, but also on
the checking old work side; we'll have a lot fewer unique transaction /
coinbase sets to hold on to for checking when we get back a solution.
Peter
On Tue, Jul 24, 2012 at 4:58 PM, Mike Hearn <mike at plan99.net> wrote:
> > That'd be 7 bytes of nonce in the block header, which is
> > 72,057,594,037,927,936 ~ 72 petahashes = 72,000 terahashes
> >
> > So: the changes for version 2 blocks would be "has height in the
> > coinbase, and has a 1-byte version number with a 3-byte extranonce."
>
> I don't understand why more nonce bits are necessary. Is it really
> impossible for a multi-core CPU to keep up with the merkle root
> re-calculation and keep an ASIC miner fed, or is this working around a
> performance bottleneck somewhere else?
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--
------------------------------
[image: CoinLab Logo]PETER VESSENES
CEO
*peter at coinlab.com * / 206.486.6856 / SKYPE: vessenes
811 FIRST AVENUE / SUITE 480 / SEATTLE, WA 98104
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20120724/e4232c5c/attachment.html>;
Peter Vessenes [ARCHIVE] /
npub1ez…6r8pt
2023-06-07 10:24:23
in reply to nevent1q…f8gd
Author Public Key
npub1ezg54d03a7unwu0fckmlugxulukrg06x7jzx4engngxfg79sfcqsn6r8ptPublished at
2023-06-07 10:24:23Event JSON
{
"id": "ada34804764ecf4f915e5cea38cb8f3b37720d5fbda5306ded4719580e71c2a6",
"pubkey": "c8914ab5f1efb93771e9c5b7fe20dcff2c343f46f4846ae6689a0c9478b04e01",
"created_at": 1686133463,
"kind": 1,
"tags": [
[
"e",
"46ab71b248824cbbc954163b8f073f93fecf03ba9fa9ff47dabf828a752960f7",
"",
"root"
],
[
"e",
"a5438d3236331a4e3775285b7cebabd028dede545e477e769b6630b65b1ba3e9",
"",
"reply"
],
[
"p",
"f2c95df3766562e3b96b79a0254881c59e8639f23987846961cf55412a77f6f2"
]
],
"content": "📅 Original date posted:2012-07-24\n📝 Original message:I think it would be great to have more nonce space with less merkle\ncalculation; keeping track of all possible versions of a block already\ntakes real RAM, real computation. Being able to change one bit in the\nheader and send out a new block for checking would ease our pool server\nwork by a real amount, somewhat on the work generation side, but also on\nthe checking old work side; we'll have a lot fewer unique transaction /\ncoinbase sets to hold on to for checking when we get back a solution.\n\nPeter\n\n\nOn Tue, Jul 24, 2012 at 4:58 PM, Mike Hearn \u003cmike at plan99.net\u003e wrote:\n\n\u003e \u003e That'd be 7 bytes of nonce in the block header, which is\n\u003e \u003e 72,057,594,037,927,936 ~ 72 petahashes = 72,000 terahashes\n\u003e \u003e\n\u003e \u003e So: the changes for version 2 blocks would be \"has height in the\n\u003e \u003e coinbase, and has a 1-byte version number with a 3-byte extranonce.\"\n\u003e\n\u003e I don't understand why more nonce bits are necessary. Is it really\n\u003e impossible for a multi-core CPU to keep up with the merkle root\n\u003e re-calculation and keep an ASIC miner fed, or is this working around a\n\u003e performance bottleneck somewhere else?\n\u003e\n\u003e\n\u003e ------------------------------------------------------------------------------\n\u003e Live Security Virtual Conference\n\u003e Exclusive live event will cover all the ways today's security and\n\u003e threat landscape has changed and how IT managers can respond. Discussions\n\u003e will include endpoint security, mobile security and the latest in malware\n\u003e threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/\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\n\n\n-- \n------------------------------\n\n[image: CoinLab Logo]PETER VESSENES\nCEO\n\n*peter at coinlab.com * / 206.486.6856 / SKYPE: vessenes\n811 FIRST AVENUE / SUITE 480 / SEATTLE, WA 98104\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20120724/e4232c5c/attachment.html\u003e",
"sig": "09342e30c7e5e2762b69eebddbd78235e34e5122af75c0aea9d8fa08aa615b3f9d544774f6efc4bc93a577b3877fa521176d7a512770433877a0e6eb992ff1d2"
}