Large Bitcoin Collider (Collision Finders Pool)

[rico666]

Well, this result demonstrates that only the outputs of that puzzle transaction were searched by whoever did that, which only mildly surprises me.

I agree with the surprise-level. As I wrote further above in the thread (soemewhere discussing the days until the #51 puzzle) I already suspected this, which is why I kept the pool forefront where it is.

If someone posts in this thread a different private key that also works out to 1PVwqUXrD5phy6gWrqJUrhpsPiBkTnftGg, I'll pay them 5BTC.

Now that's an incentive. I wonder if there would be a better place to announce that than here.
As nrg1zer wrote here: https://bitcointalk.org/index.php?topic=1573035.msg16523769#msg16523769
even if the owner of 1PVwqUXrD5phy6gWrqJUrhpsPiBkTnftGg sees (and cares about) that drain, how should he know where to look?


Rico

[1713455152]

1713455152

[ginky]

@rico

https://i.imgur.com/eyO9zBO.png

[rico666]

@rico

ls -al would have been more enlightening, but my guess is:

LBC directory belongs to root, you are user "ginky", therefore have no write permission in LBC, therefore no generator and no blf file can be downloaded.


Rico

[ginky]

ls -al would have been more enlightening, but my guess is:

LBC directory belongs to root, you are user "ginky", therefore have no write permission in LBC, therefore no generator and no blf file can be downloaded.


Rico

The LBC folder have drwxrwxrwx permissions. LBC script same

[rico666]

Second guess would be you have no internet connection, or port 20/21 (FTP) is filtered.
Other than that, I have no idea.

You can beat it manually to do your bidding. Also known as "Clubbed to death" method:

Download


ftp://ftp.cryptoguru.org/LBC/generators/161008-1d02144cdfbf81767255c040e0b7861c.gen-hrdcore-sse42-linux64.bz2

bunzip2, rename to gen-hrdcore-sse42-linux64

download


ftp://ftp.cryptoguru.org/LBC/blf/161011-4a9d2c4412e667d864bbfdfa5927bc79.blf.bz2

bunzip2, rename to funds_h160.blf

Try again.

Hope, that helps..


Rico

[ginky]

@rico

That works

Intel i5 4690 @ 3.5 - 441 799 keys/s per CPU core

WSL Win10 https://i.imgur.com/bxCnm6g.png

[ryanc]

If someone posts in this thread a different private key that also works out to 1PVwqUXrD5phy6gWrqJUrhpsPiBkTnftGg, I'll pay them 5BTC.

Now that's an incentive. I wonder if there would be a better place to announce that than here.
As nrg1zer wrote here: https://bitcointalk.org/index.php?topic=1573035.msg16523769#msg16523769
even if the owner of 1PVwqUXrD5phy6gWrqJUrhpsPiBkTnftGg sees (and cares about) that drain, how should he know where to look?


Rico

Actually, let's make that 5BTC or $3000 worth of BTC based on CoinDesk's bitcoin price index at the time of claim, whichever is more. I'm sure otherwise, someone will claim I'm assuming that me having to pay would crash the price.

If blockchain.info still has the feature that allows a "public message" to be added to a transaction, that would be a good option for signaling. A message could also be encoded in a series of vanity addresses.

For the fellow who figured "how much wood could a woodchuck chuck if a woodchuck could chuck wood" would make for a good brainwallet password, I was able to track him down via his transactions, but luck was a major factor in my ability to do that.

This problem was actually discussed somewhat by a fellow who went by "btcrobinhood" on reddit, see here: https://github.com/btcrobinhood/bips/blob/master/bip-1337.mediawiki (note that I have no opinion on that proposal at this time).

[rico666]

I will be updating the LBC manual, so make sure you have a look from time to time.

Intel i5 4690 @ 3.5 - 441 799 keys/s per CPU core

duly noted

WSL Win10

Good to see, that the VM solution under Windows has superb performance. I do not feel great pressure to push a native Win-version right now and will probably focus more on a GPU client.


Rico

[ginky]

I will be updating the LBC manual, so make sure you have a look from time to time.

Intel i5 4690 @ 3.5 - 441 799 keys/s per CPU core

duly noted

WSL Win10

Good to see, that the VM solution under Windows has superb performance. I do not feel great pressure to push a native Win-version right now and will probably focus more on a GPU client.

Rico

Change "gen-hrdcore-avx2-linux64" to "gen-hrdcore-sse42-linux64".
Agree with you about gpu client

[rico666]

Maybe I am being super duper optimistic but on the Statistics page of your website there should be a column for "Collisions" next to "Blocks done" for the client ID.

"Super duper optimism" is relative. What ~2981793 seconds ago sounded "super duper", may today seem common.

http://lbc.cryptoguru.org:5000/trophies


Rico

[rico666]

After giving it some more thought, I would like to revisit this:

Well, this result demonstrates that only the outputs of that puzzle transaction were searched by whoever did that, which only mildly surprises me.

The alleged mode of search of whoever did the search for the PKs in the puzzle transaction was discussed
in https://bitcointalk.org/index.php?topic=1573035.msg16348760#msg16348760 ff.
between you and donGeilo

We have found #45 (https://bitcointalk.org/index.php?topic=1573035.msg16430637#msg16430637), but have not yet found #46 (https://blockchain.info/address/1F3JRMWudBaj48EhwcHDdpeuy2jwACNxjP).

The fact, that we have found 1PVwqUXrD5phy6gWrqJUrhpsPiBkTnftGg in-between, which a) pre-dates the puzzle transaction, b) seems to be there before (in terms of key value) 1F3JRMWudBaj48EhwcHDdpeuy2jwACNxjP indicates, that whoever searched for the puzzle funds, did not perform a search such as both you and donGeilo assumed. Which - honestly - should take the mildness from your surprise.

Only explanation I have (which is consistent with the observations so far) , would be that the searches were performed backwards (i.e. for #46 starting at bit47, then decrementing PK values) and rest of the search space is skipped when puzzle transaction is found (starting again at bit48 for search of #47). IMHO this is the only way how 1PVwqUXrD5phy6gWrqJUrhpsPiBkTnftGg could have remained unseen in that search.

Alternative explanation could be that 1PVwqUXrD5phy6gWrqJUrhpsPiBkTnftGg was seen, but not bothered to touch. Not sure how probable that is.


Rico

[donGeilo]

After giving it some more thought, I would like to revisit this:

Well, this result demonstrates that only the outputs of that puzzle transaction were searched by whoever did that, which only mildly surprises me.

The alleged mode of search of whoever did the search for the PKs in the puzzle transaction was discussed
in https://bitcointalk.org/index.php?topic=1573035.msg16348760#msg16348760 ff.
between you and donGeilo

We have found #45 (https://bitcointalk.org/index.php?topic=1573035.msg16430637#msg16430637), but have not yet found #46 (https://blockchain.info/address/1F3JRMWudBaj48EhwcHDdpeuy2jwACNxjP).

The fact, that we have found 1PVwqUXrD5phy6gWrqJUrhpsPiBkTnftGg in-between, which a) pre-dates the puzzle transaction, b) seems to be there before (in terms of key value) 1F3JRMWudBaj48EhwcHDdpeuy2jwACNxjP indicates, that whoever searched for the puzzle funds, did not perform a search such as both you and donGeilo assumed. Which - honestly - should take the mildness from your surprise.

Only explanation I have (which is consistent with the observations so far) , would be that the searches were performed backwards (i.e. for #46 starting at bit47, then decrementing PK values) and rest of the search space is skipped when puzzle transaction is found (starting again at bit48 for search of #47). IMHO this is the only way how 1PVwqUXrD5phy6gWrqJUrhpsPiBkTnftGg could have remained unseen in that search.

Alternative explanation could be that 1PVwqUXrD5phy6gWrqJUrhpsPiBkTnftGg was seen, but not bothered to touch. Not sure how probable that is.


Rico

But I think the addresses higher than 35 were searched by a modded vanitygen, in other words he searched exactly for these addresses and not for funds.

[rico666]

I still see lots of Go-generators on Windows duly and diligently delivering blocks. I believe by now all Go-client operators are aware of the speed difference between the Go-client and HRD-core. One reasonable conclusion may be, that for a Windows user somehow installing Linux and on top of that LBC isn't just worth the effort.

I understand that and agree. Compared to executing some .msi, LBC installation was still PITA en large.

Good News Everyone! LBC installation on Windows just got a lot less PITA. You may even say it could be considered bearable now.
My definition of bearable:

You have to download about 1GB of data in 2-3 packages.
That and really only few clicks you have a completely installed "Jarvis" LBC (including blf file, xdelta3) ready to go.


Here's how:

• Make sure your computer is 64bit and supports virtualization (which is enabled in the BIOS)
• Download and install the VMware Player for Windows (~75MB): http://www.vmware.com/products/player/playerpro-evaluation.html
• Download the LBC Appliance (~960MB): ftp://ftp.cryptoguru.org/LBC/appliance (*)
  This appliance is - at the moment of this writing - an updated Arch-Linux 64bit, installed ready-to-run LBC Jarvis 0.886 - including a recent .blf, xdelta3, gcc
  
• Only if you need something to unpack a .7z archive: http://www.7-zip.org/a/7z1604-x64.exe

1) Unpack the archlinux.7z, it will need around 2GB on disk.
2) Start VMware Player, choose the Archlinux Image, Press "Play"
3) I took the Arch Linux base from: http://www.osboxes.org/arch-linux/
    so Linux should boot and in the login you enter
    username: osboxes
    password: osboxes.org
4) You type

cd collider
./LBC -x

from there on, you do whatever you want.  


Rico

edit:

(*) Thanks dArkjON

[ginky]

Hashrate increase wow. up to 23.29 mkeys/s

[rico666]

Hashrate increase wow. up to 23.29 mkeys/s

Yes, we have some new active clients. Also, the LBC Appliance I mentioned yesterday is being used, so some clients have now 13x the hashrate  keyrate.
Unfortunately the pool lost around 10 MKeys/s because of an accident of one of the clients...

Still people: remember these times. With GPU clients it will be like 3 digit MKeys/s at least.


Rico

[rico666]

I did some small updates which now allow LBC to run on a gossamer AWS EC2 t2.micro instance:

a) pulsed operation - see http://lbc.cryptoguru.org:5000/man/user#pulsedops
b) memory friendly hexdigests while updating (from version 0.893 on)

I got this t2.micro instance for free for a whole year. It's the most flimsy piece of computing power I ever saw, so I felt challenged to make use of it for LBC.
You can get like 2.8 GKeys per day out of something like that. So next challenge will be to run LBC on my toaster.  

Code:

[ec2-user@ip-1x2-xxx-20-xx ~]$ ./LBC -c 1 -t 10 -delay 5400
Best generator chosen: gen-hrdcore-sse42-linux64
Ask for work... got blocks [43436402-43436593] (201 Mkeys)
oooooooooooo
Sleeping 5400 seconds.
Ask for work... got blocks [43552882-43553073] (201 Mkeys)
oooooooooooo
Sleeping 5400 seconds.
Ask for work... got blocks [43691106-43691297] (201 Mkeys)
oooooooooooo
Sleeping 5400 seconds.
Ask for work... got blocks [43805874-43806065] (201 Mkeys)
oooooooooooo
Sleeping 5400 seconds.
etc.

Rico

[rico666]

How to get and AWS EC2 t2.micro istance for free?

I'm not entirely sure - one day I had this email from Amazon saying I could get one.
I think it goes somehow like this: https://aws.amazon.com/free/

Rico

[rico666]

I thought about setting that up in the stats, but you can make a good educated guess yourself quite easily.
In the block below, I added line numbers and the "Pool: xxx" (and removed the 'o' progress indicators)

If you look at the intervals your client gets and subtract the to-value in 1. from the from-value in 2., the to in 3. from "from" in 2. etc. etc.
and if you multiply these values with "1.048576" (which is 2^20/1000000) you get basically the MKeys the pool worked through on the forefront (i.e. auto-mode operation).

So you see in 1. the client represented a capacity of about 15.3% of the pool, in 2. about 11.9% and in 12. about 9.9%
This way you can also see - at least the tendency - if the pools performance accelerates or slows down.

Code:

 1. Ask for work... got blocks [44971058-44974897] (4026 Mkeys) Pool: 26341 MKeys
 2. Ask for work... got blocks [45000018-45003857] (4026 Mkeys) Pool: 33891 MKeys
 3. Ask for work... got blocks [45036178-45040017] (4026 Mkeys) Pool: 18439 MKeys
 4. Ask for work... got blocks [45057602-45061441] (4026 Mkeys) Pool: 21207 MKeys
 5. Ask for work... got blocks [45081666-45085505] (4026 Mkeys) etc.
 6. Ask for work... got blocks [45103938-45107777] (4026 Mkeys) etc.
 7. Ask for work... got blocks [45138754-45142593] (4026 Mkeys) yadda
 8. Ask for work... got blocks [45160242-45164081] (4026 Mkeys) yadda
 9. Ask for work... got blocks [45183346-45187185] (4026 Mkeys) won't
10. Ask for work... got blocks [45218930-45222769] (4026 Mkeys) compute
11. Ask for work... got blocks [45241266-45245105] (4026 Mkeys) all that
12. Ask for work... got blocks [45280866-45284705] (4026 Mkeys) Pool: 40568 MKeys
13. Ask for work... got blocks [45323394-45327233] (4026 Mkeys)

In case you are bored and wanted to know "how much" of the current pools capacity your client does.
It's not exact, because it doesn't take the manual searches into account which may be in completely different intervals, but it's more exact than the "Pool Performance" number in stats, which is a 24h moving average.

Therefore with this method you may see more variance in the pools performance, as there may be a spike if a big client delivered several hours of work in between your deliveries. I added also an "Activity" column to the Top30, which is a "last seen xxx ago" for the clients.

Oh and one more thing: Don't be surprised, if Pool speed will now slowly raise to ~ 40 MKeys/s  


Rico

[Hamukione]

Well, I see I am still nr 7 on the board

Ill throw an update with what CPU I have later.

[ginky]

Pool Performance: 34.34 MKeys/s