Is Bitcoin PoW actually SHA256 + Merkle generation? Or have I misunderstood coinbase/append?How does a miner perform hashing?What determines SHA256 performance on different types of hardware?Bitcoin block hashing algorithm. nonceIs it possible to make PoW ASIC-resistant through dynamically generated hash chains?How often do miners recalculate the merkle root they're working on?When do miners stop waiting for new transactions?Proof of work: optimal number of transactions?General Bitcoin questionsChecking the Merkle Root for Block #100000How to model randomness in validators selection in PoS?
Does the Bracer of Flying Daggers really let a thief make 4 attacks per round?
Quickest way to move a line in a text file before another line in a text file?
Why is the forgetful functor representable?
What is the intuition for higher homotopy groups not vanishing?
Three phase systems - are there any single phase devices that are connected between two phases instead of between one phase and neutral?
Counting multiples of 3 up to a given number
You have no, but can try for yes
What is the difference between uniform velocity and constant velocity?
What does a Nintendo Game Boy do when turned on without a game cartridge inserted?
"move up the school" meaning
Aren't all schwa sounds literally /ø/?
Satellite in orbit in front of and behind the Moon
What is this light passenger prop airplane which crash landed in East Kalimantan, Borneo in 1983?
How to declare an array without specifying its size, but with an initializer inside a class in C++?
When we are talking about black hole evaporation - what exactly happens?
Linux ext4 restore file and directory access rights after bad backup/restore
Manager is asking me to eat breakfast from now on
Linearize or approximate a square root constraint
TCP connections hang during handshake
Do you need to have the original move to take a "Replaces:" move?
Can two waves interfere head on?
Is there an English word to describe when a sound "protrudes"?
Alignment problem with a mathematical equation in a presentation in beamer
Do gauntlets count as armor?
Is Bitcoin PoW actually SHA256 + Merkle generation? Or have I misunderstood coinbase/append?
How does a miner perform hashing?What determines SHA256 performance on different types of hardware?Bitcoin block hashing algorithm. nonceIs it possible to make PoW ASIC-resistant through dynamically generated hash chains?How often do miners recalculate the merkle root they're working on?When do miners stop waiting for new transactions?Proof of work: optimal number of transactions?General Bitcoin questionsChecking the Merkle Root for Block #100000How to model randomness in validators selection in PoS?
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty margin-bottom:0;
Miners can mutate nonce (32 bits) + time (mutates once a second). This allows for 232 (~4 billion) hashes per second. That's not enough anymore for our ASICs as they perform in the TH/s now rather than GH/s. So we allowed miners to mutate the coinbase transaction, but this requires us to generate a new Merkle tree. This means that a miner needs to generate a new Merkle tree every 232 hashes. at 1 TH/s The miner must generate a new Merkle tree 250 times per second.
TLDR: Is Bitcoin PoW actually SHA256 + Merkle tree generation? And not pure SHA256?
If I'm correct in asserting that Bitcoin PoW is SHA256 + Merkle tree, does this slow the commoditization of ASICs and therefore slow decentralization, as ASICs now must be more complex than if they did with just SHA256 + nonce mutations?
proof-of-work merkle-tree sha256 bip
edited 50 mins ago
Pieter Wuille
50.6k4 gold badges103 silver badges173 bronze badges
asked 22 hours ago
ascendzorascendzor
182 bronze badges
New contributor
ascendzor is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
add a comment |
Miners can mutate nonce (32 bits) + time (mutates once a second). This allows for 232 (~4 billion) hashes per second. That's not enough anymore for our ASICs as they perform in the TH/s now rather than GH/s. So we allowed miners to mutate the coinbase transaction, but this requires us to generate a new Merkle tree. This means that a miner needs to generate a new Merkle tree every 232 hashes. at 1 TH/s The miner must generate a new Merkle tree 250 times per second.
TLDR: Is Bitcoin PoW actually SHA256 + Merkle tree generation? And not pure SHA256?
If I'm correct in asserting that Bitcoin PoW is SHA256 + Merkle tree, does this slow the commoditization of ASICs and therefore slow decentralization, as ASICs now must be more complex than if they did with just SHA256 + nonce mutations?
proof-of-work merkle-tree sha256 bip
edited 50 mins ago
Pieter Wuille
50.6k4 gold badges103 silver badges173 bronze badges
asked 22 hours ago
ascendzorascendzor
182 bronze badges
New contributor
ascendzor is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
add a comment |
Miners can mutate nonce (32 bits) + time (mutates once a second). This allows for 232 (~4 billion) hashes per second. That's not enough anymore for our ASICs as they perform in the TH/s now rather than GH/s. So we allowed miners to mutate the coinbase transaction, but this requires us to generate a new Merkle tree. This means that a miner needs to generate a new Merkle tree every 232 hashes. at 1 TH/s The miner must generate a new Merkle tree 250 times per second.
TLDR: Is Bitcoin PoW actually SHA256 + Merkle tree generation? And not pure SHA256?
If I'm correct in asserting that Bitcoin PoW is SHA256 + Merkle tree, does this slow the commoditization of ASICs and therefore slow decentralization, as ASICs now must be more complex than if they did with just SHA256 + nonce mutations?
proof-of-work merkle-tree sha256 bip
edited 50 mins ago
Pieter Wuille
50.6k4 gold badges103 silver badges173 bronze badges
asked 22 hours ago
ascendzorascendzor
182 bronze badges
New contributor
ascendzor is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
Miners can mutate nonce (32 bits) + time (mutates once a second). This allows for 232 (~4 billion) hashes per second. That's not enough anymore for our ASICs as they perform in the TH/s now rather than GH/s. So we allowed miners to mutate the coinbase transaction, but this requires us to generate a new Merkle tree. This means that a miner needs to generate a new Merkle tree every 232 hashes. at 1 TH/s The miner must generate a new Merkle tree 250 times per second.
TLDR: Is Bitcoin PoW actually SHA256 + Merkle tree generation? And not pure SHA256?
If I'm correct in asserting that Bitcoin PoW is SHA256 + Merkle tree, does this slow the commoditization of ASICs and therefore slow decentralization, as ASICs now must be more complex than if they did with just SHA256 + nonce mutations?
proof-of-work merkle-tree sha256 bip
proof-of-work merkle-tree sha256 bip
edited 50 mins ago
Pieter Wuille
50.6k4 gold badges103 silver badges173 bronze badges
asked 22 hours ago
ascendzorascendzor
182 bronze badges
New contributor
ascendzor is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
edited 50 mins ago
Pieter Wuille
50.6k4 gold badges103 silver badges173 bronze badges
asked 22 hours ago
ascendzorascendzor
182 bronze badges
New contributor
ascendzor is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
edited 50 mins ago
Pieter Wuille
50.6k4 gold badges103 silver badges173 bronze badges
edited 50 mins ago
Pieter Wuille
50.6k4 gold badges103 silver badges173 bronze badges
edited 50 mins ago
Pieter Wuille
50.6k4 gold badges103 silver badges173 bronze badges
50.6k4 gold badges103 silver badges173 bronze badges
asked 22 hours ago
ascendzorascendzor
182 bronze badges
New contributor
ascendzor is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
asked 22 hours ago
ascendzorascendzor
182 bronze badges
asked 22 hours ago
ascendzorascendzor
182 bronze badges
182 bronze badges
New contributor
ascendzor is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
New contributor
ascendzor is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
You are correct that effectively Bitcoin PoW involves computing the Merkle root every now and then in addition to the hash grinding.
However, this is negligable. Even ignoring nTime rolling, the Merkke root computation is just a dozen or so hashes every 232. It's so little because not the entire Merkle tree needs recomputation; just the coinbase transaction is modified, along with n Merkle nodes above it (assuming up to 2n transactions).
As far as I know, the burden of Merkle root computation is so low that it is generally done in the miner controller rather than in the ASIC itself.
answered 21 hours ago
Pieter WuillePieter Wuille
50.6k4 gold badges103 silver badges173 bronze badges
2
Thank you for your answer Pieter, I understand that it does not require much compute. But my criticism is towards the added complexity of doing two things to get a new hash, as opposed to one, just using the nonce (and extending it to 64bits). It seems to me that there is accidental complexity we can shave off here. We can reduce the complexity of the miners, pool operators, RPC interface, stratum. Why have we chosen to increase the complexity of the software, rather than increase the nonce to 64bits? Thank you for your contributions to bitcoin, I'm a huge fan of yours.
– ascendzor
16 hours ago
4
@ascendzor Changing the header format like that requires a hard-fork.
– CodesInChaos
12 hours ago
4
Yes, things would have been slightly simpler if the nonce field was 64 bits in size. As @CodesInChaos points out, this would require a hard fork, and because of that it'll probably never happen. All infrastructure relies on 32-bit nonces, and already includes the complexity of grinding Merkle trees. Convincing the whole world to change that, and the risks for forks while doing so, just isn't worth the gain.
– Pieter Wuille
10 hours ago
add a comment |
Your Answer
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "308"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
noCode: true, onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
ascendzor is a new contributor. Be nice, and check out our Code of Conduct.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fbitcoin.stackexchange.com%2fquestions%2f89296%2fis-bitcoin-pow-actually-sha256-merkle-generation-or-have-i-misunderstood-coin%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
You are correct that effectively Bitcoin PoW involves computing the Merkle root every now and then in addition to the hash grinding.
However, this is negligable. Even ignoring nTime rolling, the Merkke root computation is just a dozen or so hashes every 232. It's so little because not the entire Merkle tree needs recomputation; just the coinbase transaction is modified, along with n Merkle nodes above it (assuming up to 2n transactions).
As far as I know, the burden of Merkle root computation is so low that it is generally done in the miner controller rather than in the ASIC itself.
answered 21 hours ago
Pieter WuillePieter Wuille
50.6k4 gold badges103 silver badges173 bronze badges
2
Thank you for your answer Pieter, I understand that it does not require much compute. But my criticism is towards the added complexity of doing two things to get a new hash, as opposed to one, just using the nonce (and extending it to 64bits). It seems to me that there is accidental complexity we can shave off here. We can reduce the complexity of the miners, pool operators, RPC interface, stratum. Why have we chosen to increase the complexity of the software, rather than increase the nonce to 64bits? Thank you for your contributions to bitcoin, I'm a huge fan of yours.
– ascendzor
16 hours ago
4
@ascendzor Changing the header format like that requires a hard-fork.
– CodesInChaos
12 hours ago
4
Yes, things would have been slightly simpler if the nonce field was 64 bits in size. As @CodesInChaos points out, this would require a hard fork, and because of that it'll probably never happen. All infrastructure relies on 32-bit nonces, and already includes the complexity of grinding Merkle trees. Convincing the whole world to change that, and the risks for forks while doing so, just isn't worth the gain.
– Pieter Wuille
10 hours ago
add a comment |
You are correct that effectively Bitcoin PoW involves computing the Merkle root every now and then in addition to the hash grinding.
However, this is negligable. Even ignoring nTime rolling, the Merkke root computation is just a dozen or so hashes every 232. It's so little because not the entire Merkle tree needs recomputation; just the coinbase transaction is modified, along with n Merkle nodes above it (assuming up to 2n transactions).
As far as I know, the burden of Merkle root computation is so low that it is generally done in the miner controller rather than in the ASIC itself.
answered 21 hours ago
Pieter WuillePieter Wuille
50.6k4 gold badges103 silver badges173 bronze badges
2
Thank you for your answer Pieter, I understand that it does not require much compute. But my criticism is towards the added complexity of doing two things to get a new hash, as opposed to one, just using the nonce (and extending it to 64bits). It seems to me that there is accidental complexity we can shave off here. We can reduce the complexity of the miners, pool operators, RPC interface, stratum. Why have we chosen to increase the complexity of the software, rather than increase the nonce to 64bits? Thank you for your contributions to bitcoin, I'm a huge fan of yours.
– ascendzor
16 hours ago
4
@ascendzor Changing the header format like that requires a hard-fork.
– CodesInChaos
12 hours ago
4
Yes, things would have been slightly simpler if the nonce field was 64 bits in size. As @CodesInChaos points out, this would require a hard fork, and because of that it'll probably never happen. All infrastructure relies on 32-bit nonces, and already includes the complexity of grinding Merkle trees. Convincing the whole world to change that, and the risks for forks while doing so, just isn't worth the gain.
– Pieter Wuille
10 hours ago
add a comment |
You are correct that effectively Bitcoin PoW involves computing the Merkle root every now and then in addition to the hash grinding.
However, this is negligable. Even ignoring nTime rolling, the Merkke root computation is just a dozen or so hashes every 232. It's so little because not the entire Merkle tree needs recomputation; just the coinbase transaction is modified, along with n Merkle nodes above it (assuming up to 2n transactions).
As far as I know, the burden of Merkle root computation is so low that it is generally done in the miner controller rather than in the ASIC itself.
answered 21 hours ago
Pieter WuillePieter Wuille
50.6k4 gold badges103 silver badges173 bronze badges
You are correct that effectively Bitcoin PoW involves computing the Merkle root every now and then in addition to the hash grinding.
However, this is negligable. Even ignoring nTime rolling, the Merkke root computation is just a dozen or so hashes every 232. It's so little because not the entire Merkle tree needs recomputation; just the coinbase transaction is modified, along with n Merkle nodes above it (assuming up to 2n transactions).
As far as I know, the burden of Merkle root computation is so low that it is generally done in the miner controller rather than in the ASIC itself.
answered 21 hours ago
Pieter WuillePieter Wuille
50.6k4 gold badges103 silver badges173 bronze badges
edited 50 mins ago
answered 21 hours ago
Pieter WuillePieter Wuille
50.6k4 gold badges103 silver badges173 bronze badges
answered 21 hours ago
Pieter WuillePieter Wuille
50.6k4 gold badges103 silver badges173 bronze badges
answered 21 hours ago
Pieter WuillePieter Wuille
50.6k4 gold badges103 silver badges173 bronze badges
50.6k4 gold badges103 silver badges173 bronze badges
2
Thank you for your answer Pieter, I understand that it does not require much compute. But my criticism is towards the added complexity of doing two things to get a new hash, as opposed to one, just using the nonce (and extending it to 64bits). It seems to me that there is accidental complexity we can shave off here. We can reduce the complexity of the miners, pool operators, RPC interface, stratum. Why have we chosen to increase the complexity of the software, rather than increase the nonce to 64bits? Thank you for your contributions to bitcoin, I'm a huge fan of yours.
– ascendzor
16 hours ago
4
@ascendzor Changing the header format like that requires a hard-fork.
– CodesInChaos
12 hours ago
4
Yes, things would have been slightly simpler if the nonce field was 64 bits in size. As @CodesInChaos points out, this would require a hard fork, and because of that it'll probably never happen. All infrastructure relies on 32-bit nonces, and already includes the complexity of grinding Merkle trees. Convincing the whole world to change that, and the risks for forks while doing so, just isn't worth the gain.
– Pieter Wuille
10 hours ago
add a comment |
2
Thank you for your answer Pieter, I understand that it does not require much compute. But my criticism is towards the added complexity of doing two things to get a new hash, as opposed to one, just using the nonce (and extending it to 64bits). It seems to me that there is accidental complexity we can shave off here. We can reduce the complexity of the miners, pool operators, RPC interface, stratum. Why have we chosen to increase the complexity of the software, rather than increase the nonce to 64bits? Thank you for your contributions to bitcoin, I'm a huge fan of yours.
– ascendzor
16 hours ago
4
@ascendzor Changing the header format like that requires a hard-fork.
– CodesInChaos
12 hours ago
4
Yes, things would have been slightly simpler if the nonce field was 64 bits in size. As @CodesInChaos points out, this would require a hard fork, and because of that it'll probably never happen. All infrastructure relies on 32-bit nonces, and already includes the complexity of grinding Merkle trees. Convincing the whole world to change that, and the risks for forks while doing so, just isn't worth the gain.
– Pieter Wuille
10 hours ago
2
2
Thank you for your answer Pieter, I understand that it does not require much compute. But my criticism is towards the added complexity of doing two things to get a new hash, as opposed to one, just using the nonce (and extending it to 64bits). It seems to me that there is accidental complexity we can shave off here. We can reduce the complexity of the miners, pool operators, RPC interface, stratum. Why have we chosen to increase the complexity of the software, rather than increase the nonce to 64bits? Thank you for your contributions to bitcoin, I'm a huge fan of yours.
– ascendzor
16 hours ago
Thank you for your answer Pieter, I understand that it does not require much compute. But my criticism is towards the added complexity of doing two things to get a new hash, as opposed to one, just using the nonce (and extending it to 64bits). It seems to me that there is accidental complexity we can shave off here. We can reduce the complexity of the miners, pool operators, RPC interface, stratum. Why have we chosen to increase the complexity of the software, rather than increase the nonce to 64bits? Thank you for your contributions to bitcoin, I'm a huge fan of yours.
– ascendzor
16 hours ago
4
4
@ascendzor Changing the header format like that requires a hard-fork.
– CodesInChaos
12 hours ago
@ascendzor Changing the header format like that requires a hard-fork.
– CodesInChaos
12 hours ago
4
4
Yes, things would have been slightly simpler if the nonce field was 64 bits in size. As @CodesInChaos points out, this would require a hard fork, and because of that it'll probably never happen. All infrastructure relies on 32-bit nonces, and already includes the complexity of grinding Merkle trees. Convincing the whole world to change that, and the risks for forks while doing so, just isn't worth the gain.
– Pieter Wuille
10 hours ago
Yes, things would have been slightly simpler if the nonce field was 64 bits in size. As @CodesInChaos points out, this would require a hard fork, and because of that it'll probably never happen. All infrastructure relies on 32-bit nonces, and already includes the complexity of grinding Merkle trees. Convincing the whole world to change that, and the risks for forks while doing so, just isn't worth the gain.
– Pieter Wuille
10 hours ago
add a comment |
ascendzor is a new contributor. Be nice, and check out our Code of Conduct.
ascendzor is a new contributor. Be nice, and check out our Code of Conduct.
ascendzor is a new contributor. Be nice, and check out our Code of Conduct.
ascendzor is a new contributor. Be nice, and check out our Code of Conduct.
Thanks for contributing an answer to Bitcoin Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fbitcoin.stackexchange.com%2fquestions%2f89296%2fis-bitcoin-pow-actually-sha256-merkle-generation-or-have-i-misunderstood-coin%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
