public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: mike@powx.org
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Cc: Bitcoin Protocol Discussion
	<bitcoin-dev@lists.linuxfoundation.org>,
	marshall ball <marshallball@gmail.com>
Subject: Re: [bitcoin-dev] Proposal: Low Energy Bitcoin PoW
Date: Tue, 18 May 2021 08:17:46 -0400	[thread overview]
Message-ID: <864F983C-841D-4334-94F4-5A9F7D617B70@powx.org> (raw)
In-Reply-To: <vTGmO3qpvd7XawxARg2vvWmeP2LOCLAIBgMRWmNNmf7mok0DRhIes5JsBnooflSNk4DX2vQCuOB7hBmSjcUT_RvtF6l8gJ9Tt69TWEeowmg=@protonmail.com>

[-- Attachment #1: Type: text/plain, Size: 2486 bytes --]

Nothing in a dynamic system like PoW mining can be 100% anticipated, for example there might be advanced in manufacturing of chips which are patented and so on. 

It sounds like your take is that this means no improvements can ever be made by any mechanism, however conservative.

We do go into a fair amount of detail about Minimum Effective Hardness in our paper https://assets.pubpub.org/xi9h9rps/01581688887859.pdf , which is actually a special case of hardness that we invented for the context of adding an operation to a PoW, and how it applies to random matrix mults.   

Sent from my iPhone

> On May 18, 2021, at 7:58 AM, ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:
> 
> Good morning Michael,
> 
>> That’s interesting. I didn’t know the history of ASICBOOST.
> 
> History is immaterial, what is important is the technical description of ASICBOOST.
> Basically, by fixing the partial computation of the second block of SHA256, we could selectively vary bits in the first block of SHA256, while reusing the computation of the second block.
> This allows a grinder to grind more candidate blocks without recomputing the second block output, reducing the needed power consumption for the same number of hashes attempted.
> 
> Here is an important writeup: https://www.mit.edu/~jlrubin/public/pdfs/Asicboost.pdf
> It should really be required reading for anyone who dreams of changing PoW algorithms to read and understand this document.
> 
> There may be similar layer-crossings in any combined construction --- or even just a simple hash function --- when it is applied to a specific Bitcoin block format.
> 
>> 
>> Our proposal (see Implementation) is to phase in oPoW slowly starting at a very low % of the rewards (say 1%). That should give a long testing period where there is real financial incentive for things like ASICBOOST
>> 
>> Does that resolve or partially resolve the issue in your eyes?
> 
> It does mitigate this somewhat.
> 
> However, such a mechanism is an additional complication and there may be further layer-crossing violations possible --- there may be an optimization to have a circuit that occasionally uses SHA256d and occasionally uses oPoW, that is not possible with a pure SHA256d or pure oPoW circuit.
> So this mitigation is not as strong as it might appear at first glance; additional layers means additional possibility of layer-crossing violations like ASICBOOST.
> 
> 
> 
> 
> Regards,
> ZmnSCPxj
> 

[-- Attachment #2: Type: text/html, Size: 3451 bytes --]

  reply	other threads:[~2021-05-18 12:17 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-17 19:32 [bitcoin-dev] Proposal: Low Energy Bitcoin PoW Bogdan Penkovsky
2021-05-17 21:13 ` Keagan McClelland
2021-05-18  6:46   ` ZmnSCPxj
2021-05-18  9:18     ` Devrandom
2021-05-18 10:58       ` ZmnSCPxj
2021-05-18 11:05         ` mike
2021-05-18 11:36           ` ZmnSCPxj
2021-05-18 11:43             ` mike
2021-05-18 11:58               ` ZmnSCPxj
2021-05-18 12:17                 ` mike [this message]
2021-05-18 12:22                   ` ZmnSCPxj
2021-05-18 12:58                     ` ZmnSCPxj
2021-05-18 10:59       ` mike
2021-05-18 12:46     ` Claus Ehrenberg
2021-05-18 16:47       ` Keagan McClelland

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=864F983C-841D-4334-94F4-5A9F7D617B70@powx.org \
    --to=mike@powx.org \
    --cc=ZmnSCPxj@protonmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=marshallball@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox