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?Is 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?Checking the Merkle Root for Block #100000How to model randomness in validators selection in PoS?

Why use [FormalN]?

Dicht antonym - what is it?

Is current (November 2019) polling about Democrats lead over Trump trustworthy?

Can I request a credit item be removed from my report as soon as it is paid in full?

Hole in PCB due to corrosive reaction?

Spanning tree of a rectangular grid

Translation Golf XLIX - An Accurate Shot

How to use FDE without needing to share the encryption password

What type of logical fallacy is the offering of a source which is really long and not specifying what part of the source is relevant?

What would make the internet go away?

What spells can be countered?

Dissecting the exotic bulbfish

How to get the address of a C++ lambda function within the lambda itself

Short story/novella about old-school Biblical angels wrecking the world

On a naked chicken (no coating,batter) is there any benefit of double frying?

Passport expiration requirement for Jordan Visa

Basic Accidental Question

What's an "add" chord?

Very high precision zero crossing detection

What is the meaning of Text inside of AMS logo

Does single-stepping on the 8086 behave as described in the user manual?

How do I find the unknown program enabled during Start-Up?

What is the "opposite" of a random variable?

Creating vector (with lines/polygons) from raster based on paper map in QGIS



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?Is 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?Checking 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;









4

















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?










share|improve this question


































    4

















    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?










    share|improve this question






























      4












      4








      4


      1






      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?










      share|improve this question

















      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






      share|improve this question
















      share|improve this question













      share|improve this question




      share|improve this question








      edited Jul 22 at 2:20









      Pieter Wuille

      53.3k4 gold badges109 silver badges179 bronze badges




      53.3k4 gold badges109 silver badges179 bronze badges










      asked Jul 21 at 4:35









      ascendzorascendzor

      302 bronze badges




      302 bronze badges























          1 Answer
          1






          active

          oldest

          votes


















          8


















          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.






          share|improve this answer























          • 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
            Jul 21 at 11:04







          • 4





            @ascendzor Changing the header format like that requires a hard-fork.

            – CodesInChaos
            Jul 21 at 14:30






          • 5





            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
            Jul 21 at 16:55












          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/4.0/"u003ecc by-sa 4.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
          );



          );














          draft saved

          draft discarded
















          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









          8


















          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.






          share|improve this answer























          • 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
            Jul 21 at 11:04







          • 4





            @ascendzor Changing the header format like that requires a hard-fork.

            – CodesInChaos
            Jul 21 at 14:30






          • 5





            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
            Jul 21 at 16:55















          8


















          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.






          share|improve this answer























          • 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
            Jul 21 at 11:04







          • 4





            @ascendzor Changing the header format like that requires a hard-fork.

            – CodesInChaos
            Jul 21 at 14:30






          • 5





            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
            Jul 21 at 16:55













          8














          8










          8









          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.






          share|improve this answer
















          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.







          share|improve this answer















          share|improve this answer




          share|improve this answer








          edited Jul 22 at 2:21

























          answered Jul 21 at 6:10









          Pieter WuillePieter Wuille

          53.3k4 gold badges109 silver badges179 bronze badges




          53.3k4 gold badges109 silver badges179 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
            Jul 21 at 11:04







          • 4





            @ascendzor Changing the header format like that requires a hard-fork.

            – CodesInChaos
            Jul 21 at 14:30






          • 5





            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
            Jul 21 at 16:55












          • 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
            Jul 21 at 11:04







          • 4





            @ascendzor Changing the header format like that requires a hard-fork.

            – CodesInChaos
            Jul 21 at 14:30






          • 5





            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
            Jul 21 at 16:55







          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
          Jul 21 at 11:04






          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
          Jul 21 at 11:04





          4




          4





          @ascendzor Changing the header format like that requires a hard-fork.

          – CodesInChaos
          Jul 21 at 14:30





          @ascendzor Changing the header format like that requires a hard-fork.

          – CodesInChaos
          Jul 21 at 14:30




          5




          5





          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
          Jul 21 at 16:55





          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
          Jul 21 at 16:55


















          draft saved

          draft discarded















































          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.




          draft saved


          draft discarded














          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





















































          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









          Popular posts from this blog

          Tamil (spriik) Luke uk diar | Nawigatjuun

          Align equal signs while including text over equalitiesAMS align: left aligned text/math plus multicolumn alignmentMultiple alignmentsAligning equations in multiple placesNumbering and aligning an equation with multiple columnsHow to align one equation with another multline equationUsing \ in environments inside the begintabularxNumber equations and preserving alignment of equal signsHow can I align equations to the left and to the right?Double equation alignment problem within align enviromentAligned within align: Why are they right-aligned?

          Training a classifier when some of the features are unknownWhy does Gradient Boosting regression predict negative values when there are no negative y-values in my training set?How to improve an existing (trained) classifier?What is effect when I set up some self defined predisctor variables?Why Matlab neural network classification returns decimal values on prediction dataset?Fitting and transforming text data in training, testing, and validation setsHow to quantify the performance of the classifier (multi-class SVM) using the test data?How do I control for some patients providing multiple samples in my training data?Training and Test setTraining a convolutional neural network for image denoising in MatlabShouldn't an autoencoder with #(neurons in hidden layer) = #(neurons in input layer) be “perfect”?