Skip to content
Merged
Changes from 20 commits
Commits
Show all changes
27 commits
Select commit Hold shift + click to select a range
09e8645
clear more TBDs and merge Andrea's 0.9.4 spec
gcolvin Aug 21, 2020
fcc12ee
fix broken links
gcolvin Aug 21, 2020
0bfefd5
fix another broken link
gcolvin Aug 21, 2020
cb16871
fix yet another broken link
gcolvin Aug 21, 2020
8beb62e
hope for the last broken link
gcolvin Aug 21, 2020
38ee7ad
force bot
gcolvin Aug 21, 2020
85a7c14
please be the last broken links
gcolvin Aug 21, 2020
cebea08
broken test vector label
gcolvin Aug 21, 2020
36d2762
another broken link and test vector label
gcolvin Aug 21, 2020
8806a7b
all links now work in browser
gcolvin Aug 21, 2020
768ea1c
?
gcolvin Aug 21, 2020
82ec1ca
??
gcolvin Aug 21, 2020
9efd5fc
ready for review
gcolvin Aug 22, 2020
2d9550a
stop bot
gcolvin Aug 23, 2020
109679d
ready for review
gcolvin Aug 23, 2020
ea96242
Michah's review
gcolvin Aug 24, 2020
f92ab22
Merge branch 'master' into progPowReview
gcolvin Aug 24, 2020
a32eee3
more of Michah's review
gcolvin Aug 24, 2020
9bec864
Merge branch 'progPowReview' of https://github.com/ethereum/EIPs into…
gcolvin Aug 24, 2020
6514473
a little more of Michah's review
gcolvin Aug 24, 2020
102b215
move Kik fix from Specification to Security Considerations
gcolvin Sep 12, 2020
9b5d08e
move Kik fix from Specification to Security Considerations
gcolvin Sep 12, 2020
3baf429
incorporate Andreas Kik changes
gcolvin Sep 12, 2020
41361d1
fix up tables
gcolvin Sep 12, 2020
32d1f54
security section
gcolvin Sep 16, 2020
3f87e57
security section 2
gcolvin Sep 16, 2020
f1add18
reflect decisions in ACD 96
gcolvin Sep 18, 2020
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
86 changes: 26 additions & 60 deletions EIPS/eip-1057.md
Original file line number Diff line number Diff line change
Expand Up @@ -13,12 +13,12 @@ created: 2018-05-02

A new Proof-of-Work algorithm to replace Ethash that utilizes almost all parts of commodity GPUs.

We **Do Not** recommend that this Proposal be deployed at this time. Rather it is being offered in the spirit of [Ben DiFrancesco's compromise](https://ethereum-magicians.org/t/a-progpow-compromise-pre-proposal/4057) which for our purposes we state simply as,
>***Note:*** We **Do Not** recommend that this Proposal be deployed at this time. Rather it is being offered in the spirit of [Ben DiFrancesco's compromise](https://ethereum-magicians.org/t/a-progpow-compromise-pre-proposal/4057) which for our purposes we state simply as:
* This Proposal **is not** being proposed for deployment in any planned hardfork.
* This Proposal should be fully implemented and tested across major clients.
* Clients implementing this Proposal should be deployed and maintained on a testnet.

This leaves open the possibility and threat of future deployment.
>
>This leaves open the possibility and threat of future deployment.

## Abstract

Expand Down Expand Up @@ -133,27 +133,6 @@ Ethash requires external memory due to the large size of the DAG. However that

## Specification

Up to release 0.9.3 the DAG is generated exactly as in Ethash. All the parameters (epoch length, DAG size, etc) are unchanged. See the original [Ethash](https://github.com/ethereum/wiki/wiki/Ethash) spec for details on generating the DAG.

Release 0.9.3 has been software and hardware audited:
* [Least Authority — ProgPoW Software Audit PDF](https://leastauthority.com/static/publications/Least%20Authority%20-%20ProgPow%20Algorithm%20Final%20Audit%20Report.pdf)
* [Bob Rao - ProgPoW Hardware Audit PDF](https://github.com/ethereum-cat-herders/progpow-audit/raw/master/Bob%20Rao%20-%20ProgPOW%20Hardware%20Audit%20Report%20Final.pdf)

Following the suggestion expressed by Least Authority in their findings, new proposed release 0.9.4 introduces a tweak in DAG generation in order to mitigate the possibility of a "Light Evaluation" attack.
This change implies the modification of `ETHASH_DATASET_PARENTS` from a value of 256 to the new value of 512. Due to this the DAG memory file used by ProgPoW is no longer compatible with the one used by Ethash (epoch length and size increase ratio remain the same though).

After the completion of the audits a clever finding by [Kik](https://github.com/kik/) disclosed an exploitable condition to [bypass ProgPoW memory hardness](https://github.com/kik/progpow-exploit). The condition is present in Ethash but near-impossible to exploit, and requires the availability of a customized node able to accept modified block headers by the miner. To prevent this exploit this release changes the condition modifying the input state of the last keccak pass from
* header (256 bits) +
* seed for mix initiator (64 bits) +
* mix from main loop (256 bits)
* no padding

to
* digest from initial keccak (256 bits) +
* mix from main loop (256 bits) +
* padding
thus widening the constraint to target in keccak [brute force keccak linear searches](https://github.com/kik/progpow-exploit) from 64 to 256 bits.

ProgPoW can be tuned using the following parameters. The proposed settings have been tuned for a range of existing, commodity GPUs:

* `PROGPOW_PERIOD`: Number of blocks before changing the random program
Expand Down Expand Up @@ -354,7 +333,6 @@ uint32_t math(uint32_t a, uint32_t b, uint32_t r)
}
```


The flow of the inner loop is:
* Lane `(loop % LANES)` is chosen as the leader for that loop iteration
* The leader's `mix[0]` value modulo the number of 256-byte DAG entries is is used to select where to read from the full DAG
Expand Down Expand Up @@ -455,7 +433,7 @@ The flow of the overall algorithm is:
* When mining this final value is compared against a `hash32_t` target

```cpp
hash32_t progPowHash(
ash32_t progPowHash(
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Definitely a backdoor sneaked in.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

good catch

const uint64_t prog_seed, // value is (block_number/PROGPOW_PERIOD)
const uint64_t nonce,
const hash32_t header,
Expand Down Expand Up @@ -547,42 +525,33 @@ hash32_t progPowHash(
}
```

## Example / Testcase
## Security Considerations

ProgPoW utilizes almost all parts of a commodity GPU, excluding:
Up to release 0.9.3 the DAG is generated exactly as in Ethash. All the parameters (epoch length, DAG size, etc) are unchanged. See the original [Ethash](https://github.com/ethereum/wiki/wiki/Ethash) spec for details on generating the DAG.

* The graphics pipeline (displays, geometry engines, texturing, etc);
* Floating point math.
Release 0.9.3 has been software and hardware audited:
* [Least Authority — ProgPoW Software Audit PDF](https://leastauthority.com/static/publications/LeastAuthority-ProgPow-Algorithm-Final-Audit-Report.pdf)
* [Bob Rao - ProgPoW Hardware Audit PDF](https://github.com/ethereum-cat-herders/progpow-audit/raw/master/Bob%20Rao%20-%20ProgPOW%20Hardware%20Audit%20Report%20Final.pdf)

Making use of either of these would have significant portability issues between commodity hardware vendors, and across programming languages.
Following the suggestion expressed by Least Authority in their findings, new proposed release 0.9.4 introduces a tweak in DAG generation in order to mitigate the possibility of a "Light Evaluation" attack.
This change implies the modification of `ETHASH_DATASET_PARENTS` from a value of 256 to the new value of 512. Due to this the DAG memory file used by ProgPoW is no longer compatible with the one used by Ethash (epoch length and size increase ratio remain the same though).

Since the GPU is almost fully utilized, there’s little opportunity for specialized ASICs to gain efficiency. Removing both the graphics pipeline and floating point math could provide up to 1.2x gains in efficiency, compared to the 2x gains possible in Ethash, and 50x gains possible for CryptoNight.
After the completion of the audits a clever finding by [Kik](https://github.com/kik/) disclosed an exploitable condition to [bypass ProgPoW memory hardness](https://github.com/kik/progpow-exploit). The condition is present in Ethash but near-impossible to exploit. In progPoW it is not currently practical; It wasn’t practically implementable. An attacker would need a customized nodes able to accept modified block headers by the miner, the exploit used extraNonce/extraData as entropy, which isn’t the standard today, and the required brute-force search would be difficult to accomplish in one blocktime.

## Backwards Compatibility
To more completely prevent this exploit this release changes the condition modifying the input state of the last keccak pass from
* header (256 bits) +
* seed for mix initiator (64 bits) +
* mix from main loop (256 bits)
* no padding

This algorithm is not backwards compatible with the existing Ethash, and will require a fork for adoption. Furthermore, the network hashrate will halve since twice as much memory is loaded per hash.
to
* digest from initial keccak (256 bits) +
* mix from main loop (256 bits) +
* padding
thus widening the constraint to target in keccak [brute force keccak linear searches](https://github.com/kik/progpow-exploit) from 64 to 256 bits.

## Test Cases

### progpow 0.9.2
The algorithm run on block 30,000 produces the following digest and result:
```
header ffeeddccbbaa9988776655443322110000112233445566778899aabbccddeeff
nonce 123456789abcdef0

digest: 11f19805c58ab46610ff9c719dcf0a5f18fa2f1605798eef770c47219274767d
result: 5b7ccd472dbefdd95b895cac8ece67ff0deb5a6bd2ecc6e162383d00c3728ece
```

Additional test vectors can be found [in the test vectors file](../assets/eip-1057/test-vectors.md#progpowhash).

### progpow 0.9.3
[Machine-readable test vectors](https://github.com/ethereum/EIPs/blob/ad4e73f239d53d72a21cfd8fdc89dc81eb9d2688/assets/eip-1057/test-vectors-0.9.3.json)

Additional test vectors can be found [in the test vectors file](../assets/eip-1057/test-vectors.md#progpowhash).

### progpow 0.9.4

The random sequence generated for block 30,000 (prog_seed 3,000) can been seen in [kernel.cu](https://github.com/ifdefelse/ProgPOW/blob/824cd791634204c4cc7e31f84bb76c0c84895bd3/test/kernel.cu).

The algorithm run on block 30,000 produces the following digest and result:
Expand All @@ -602,14 +571,11 @@ Machine-readable test vectors (T.B.D)

## Implementation

We **Do Not** recommend that this Proposal be deployed at this time. Rather it is being offered in the spirit of [Ben DiFrancesco's compromise](https://ethereum-magicians.org/t/a-progpow-compromise-pre-proposal/4057) which for our purposes we state simply as,
* This Proposal **is not** being proposed for deployment in any planned hardfork.
* This Proposal should be fully implemented and tested across major clients.
* Clients implementing this Proposal should be deployed and maintained on a testnet.
The reference ProgPoW mining implementation is located at [The @ifdefelse ProgPOW repository](https://github.com/ifdefelse/ProgPOW).

This leaves open the possibility and threat of future deployment.
## Deployment

Note that DAG-size growth will defeat the Antminer E3 (and some Innosilicon ASICs) in October or November of 2020 [at about block 11,400,000](https://blog.bitmain.com/en/bitmains-antminer-e3-firmware-update/).
We **Do Not** recommend that this Proposal be deployed at this time. Rather, we leave open the possibility and threat of future deployment. Note that [DAG-size growth](https://investoon.com/tools/dag_size) will defeat the [Antminer E3(https://blog.bitmain.com/en/bitmains-antminer-e3-firmware-update/) (and many Innosilicon ASICs) circa November of 2020, which will mark one good window to introduce progPoW.

### Clients

Expand Down Expand Up @@ -675,4 +641,4 @@ xnpopol | Yes | Ready |

The ProgPoW algorithm and this specification are a new work. Copyright and related rights are waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).

The reference ProgPoW mining implementation located at [ProgPOW](https://github.com/ifdefelse/ProgPOW) is a derivative of ethminer so retains the GPL license.
The reference ProgPoW mining implementation located at [The @ifdefelse ProgPOW repository](https://github.com/ifdefelse/ProgPOW) is a derivative of ethminer so retains the GPL license.