https://twitter.com/PhABCD/status/1265386127650885632?s=20

Well, for it to make a difference you need bytes that are zero, not just any zeroes. E.g.
0x0000000000100100100100100111111111111111
is about 150 cheaper than
0x1010101010101010101010101010101010101010
even though they have the same number of zeroes.

Would a --zero-bytes flag that searches like this this be difficult to add?

I'm trying to automate generating salts and I think one easy would be to have a flag to run ERADAICTE2 for a couple hours or until an address with sufficient 0 bytes is found. At the end it should write the best scoring address to a file (or stdout) and then exit. I could grab this output with my deploy script and then not have to do any copy/pasting.

I haven't written any C++ in a while, but if you point me to where this would best fit, I can try to write it.

ERADICATE2.x64 is crashing after 10 seconds when using more than one GPU

Error:

double free or corruption (fasttop)
Segmentation fault (core dumped)

This project looks really interesting! Thanks!

Do you have steps for compiling/installing this? What dependencies are there?

Background

CreateX is now live on 56 EVM chains (see also createx.rocks). TL;DR: CreateX is a factory smart contract to make easier and safer usage of the CREATE and CREATE2 EVM opcodes as well as of CREATE3-based (i.e. without an initcode factor) contract creations.

CreateX salt scheme

The full documentation can be viewed here.

CreateX implements some special features:

1. Permissioned Deploy Protection
2. Cross-Chain Redeploy Protection

The salt value implements these different safeguarding mechanisms depending on the encoded values in the salt (|| stands for byte-wise concatenation):

=> salt (32 bytes) = 0xbebebebebebebebebebebebebebebebebebebebe||ff||1212121212121212121212

• The first 20 bytes (i.e. bebebebebebebebebebebebebebebebebebebebe) may be used to implement a permissioned deploy protection by setting them equal to msg.sender,
• The 21st byte (i.e. ff) may be used to implement a cross-chain redeploy protection by setting it equal to 0x01,
• The last random 11 bytes (i.e. 1212121212121212121212) allow for $2^{88}$ bits of entropy for mining a salt.

Feature Request

Make ERADICATE2 compatible with CreateX's salt scheme. Cc: @mds1 @Vectorized

Great tool -thank you - one thing not clear about is lack of input flag for the sender expected - that is -

 ./ERADICATE2.x64 -A 0x0000000000000000000000000000000111111111 -I 0x00 --leading 0
Devices:
  GPU0: GeForce GTX 1650 Ti with Max-Q Design, 4101898240 bytes available, 16 compute units

Initializing OpenCL...
  Creating context...OK
  Compiling kernel...OK
  Building program...OK

Running...

  Time:     0s Score:  6 Salt: 0x511ed2354d1def73c740e47db67e709a417f1199f90494208fcc02f15723e4d4 Address: 0x0000001e6745ef4fa01beb82d5482c0e3740462b
  Time:     1s Score:  7 Salt: 0x511ed2354d1def230f70e39bb67e709a417f1199f90494208fcc02f15723e4d4 Address: 0x00000006f96775e3d865526653b20d9242eed2f1
  Time:    13s Score:  8 Salt: 0x511ed2354d1def691217e483b77e709a417f1199f90494208fcc02f15723e4d4 Address: 0x00000000171fc90e47be5170aa7c47cfb2730221

what sender address is being assumed here?

Compiling then running gives same empty output each time

$ ./ERADICATE2.x64 -A 0x00000000000000000000000000000000deadbeef -I 0x00 --leading 0
Devices:

If you use create2 to create a contract address, is there a factory address here? I don't understand the meaning of the - a parameter? I tried to set - A as the factory address. The generated contract address is incorrect

So it looks like having 5 leading zero bytes is helpful in reducing deployment costs.

Would it be possible to have a pattern that requires the first 5 bytes to be zero and then adds extra score for more zero bytes anywhere else in the address?

Metamorphic is a popular complementary tool, with factories for multiple contracts deployed on mainnet.

To avoid front-running / stealing of selfdestructed addresses (because the functions on the deployed factories are public), they enforce that the first 20bytes of the salt must match the msg.sender.

This is a request to include another input flag, that when non-empty, would be the prefix of the calculated salts.

After adding the dependencies and compiling on Ubuntu, nothing would work. I ran
./ERADICATE2.x64 --benchmark

and got:

Devices:
   GPU0: NVIDIA GeForce 1660 Ti, .....
   GPU1: Intel(R) UHD Graphics .....

Initializing OpenCL...
   Creating context...Segmentation fault (core dumped)

I lost money on profanti - it was hacked. Is this new fork safe? Can't they generate it?

With --zeros, I'm finding 15 really fast. Why is the max currently bound between 0 and 15 (f)?

./ERADICATE2.x64 -A 0x00000000000000000000000000000000deadbeef -I 0x00 --zeros
Devices:
  GPU0: Intel(R) Gen9 HD Graphics NEO, 26831261696 bytes available, 48 compute units

Initializing OpenCL...
  Creating context...OK
  Compiling kernel...OK
  Building program...OK

Running...

  Time:     1s Score: 14 Salt: 0xcd6ec5f93e88d1d34cb058f487ae3817e455667b9544d9e68c6408d3d89c39c2 Address: 0x7f7ba907683006c4010900093002e00eb503af0c
  Time:     1s Score: 15 Salt: 0xcd6ec5f93e88d17b9e3859f587ae3817e455667b9544d9e68c6408d3d89c39c2 Address: 0x0ed0700bcd0f0704b77480b20240c603030a00e8
Speed: 24.067 MH/s GPU0: 24.067 MH/s

I can't use this to generate a wallet can I?