Large Bitcoin Collider Thread 2.0

[rico666]

About the Collider

The Large Bitcoin Collider (LBC - a.k.a. Collision Finders Pool) is a distributed effort to find private keys to BTC addresses that have funds on them.
Because it searches in a very specific (low-entropy) area of the private key space, any working private keys to be found are either

• result of bad RNG
• placed there intentionally
• collisions to "original" a.k.a. "right" a.k.a. "regular" private keys

The last ones we are interested in. This pool is not searching for brainwallets and our mode of search makes it very unlikely we would find a "brainwallet" private key sooner than a "collision to a regular" private key. Even if we did, we would probably not recognize it as such.

Project homepage: https://lbc.cryptoguru.org
Downloads: https://lbc.cryptoguru.org/download
Statistics: https://lbc.cryptoguru.org/stats
Twitter: https://twitter.com/LBC_collider
Discord: https://discord.gg/AyEfZrY

Development Server: https://svn.cryptoguru.org/ (requires auth)

What this pool does is - at the moment - in its form unique and thus requires novel and often unorthodox approaches. We are aware not everybody will like these, but that's life. What we can assert, is that the pool is no malicious project to discredit or "kill" Bitcoin. This pool also is not a commercial endeavor. Before we continue to enumerate what this pool is not, let's give some examples what this pool is or what it can be:

• The pool is fun! While deploying the software may be hard - or even frustrating to some, people who manage it and maybe even learn something about Linux along the way, do show signs of of euphoria when talking about it. It's the ultimate hide and seek game!
• The pool is thrilling! After all, it is similar to a treasure hunt and no one knows if he's going to be successful or not. Finding something - especially after you have been told numerous times you won't - can give you quite some adrenaline rush. As can discussions with the uninitiated.
• The pool is social! Pool participants do compete, but not like miners do. Sure - the more search power you throw at the problem, the more chances you have to find something (and proportionally so), but we are all standing in front of only one huge mountain together. Some have bigger and some have smaller pickaxes - some have excavators, but all are eroding the same damn rock. And sometimes the excavators take the people with small pickaxes to the rich veins...
• The pool can be rewarding! People do compare this pools "commercial viability" to mining and we are aware of all the arguments. We think these arguments are wrong - mostly - or at least obsolete. Comparison to mining cannot be done without looking at the mining difficulty, our speed and lots of other parameters. Using your CPU for mining versus using it for collision search is a different story today, than it was 2009.

About this Thread

Contrary to the 1st a.k.a v1-Thread, this one is self-moderated. So everything the forum says about self-moderated threads does apply here (if you don't like it, open your own thread etc.). Main reason is, we would like to keep this thread clean and informative - thus useful.

Keeping the thread "clean and useful" does not mean your post will be kicked if you disagree with us or the pool purpose. If you do so with sound arguments and in a certain form (see below), there is no reason for censorship. If you feel you need more freedom, go and discuss in the v1 Thread, but we will shift our focus - thus presence - to this v2 thread. Also all announcements/news from the devs will be done here from now on.

What will get your post kicked unconditionally:

• You are on the moderators' ignore list (*). Sorry, there is a reason you got there and the moderator of this thread cannot have replies here he does not see. Let's take the ignore-function by it's name: it does not make sense un-ignoring you just to see if you wrote a "marvel" this time. Being on the ignore-list has retro-active effect ... I'm sure you'll figure out what that means.
• You post low-quality content. This may seem like a very elastic definition, so let's be more precise here:
  
  • You posted a "one-liner".
  • Your contribution is smaller than what you actually quoted. Keep the quote/own text ratio at least 51% in favor of own/original text.
  • Your contribution has no relation to the LBC topic at all (thread hijacking) or to the current flow of discussion without bringing up a new and relevant topic of interest.
  • You posted something that was being posted before (redundancy) or as a question that was answered before (RTFM).

What may get your post kicked with delay:

• Something that looked like a good contribution turns out to be a bad contribution
• I was on vacation.
• Your text is ok, but in a bad context. (I.e. if you got sucked in an argument with an idiot and I had to delete the idiots posts). In these cases I will try to preserve your text for you to repost - if still applicable.

Before you post, please consider that your posting may have a 99% chance to get deleted and ask yourself if it's worth the effort. If - on the other hand - you are convinced that your posting is quality-wise above 99% of the usual bitcointalk.org postings, you have probably nothing to "fear" (which you shouldn't in any case). These rules, which may or may not be complete, are intended to make this a low-volume high-quality thread. Useful for both newbies and versed colliders. See this as "censorship of crap" if you must.

Hints to not have your scribe efforts squashed and a little Q&A:

Contrary to usual practice you can and should edit your post if you feel there is some better or clearer formulation. Grammar, typos (except the intentional ones) should be corrected, you do not need to "edit:" your post because of that all over the place.

"What if I have only a simple one-liner question?"

If it's something you think is of relevance to a broader public, ask yourself 1st: "Why hasn't this come up already?" If you think you are the 1st one to see the problem (and you have our compassion there) elaborate on it! Make others understand what they haven't considered up to now. Then ask. If, however, you come to the conclusion the question may be of interest only for you - that's what PM's are for.

"I have Tourette's - will you kill my posts?"

Tourette's's fine. Just make sure to provide some content around it. (In case you didn't understand: This was about form vs. content. Content is more important to us)

"I have Dunning-Kruger - will you kill my posts?"

Instantly.



Old v1 thread: https://bitcointalk.org/index.php?topic=1573035.0
German thread: https://bitcointalk.org/index.php?topic=1581701.0


(*) rico666's ignore list (no particular order, but Gleb Gamov takes the cake so far - by far):

Code:

becoin
candoo
Gyrsur
porc
deisik
KenR
Gleb Gamow

"When I grow up, I want to be like https://bitcointalk.org/index.php?topic=973843.0"

[1714050316]

1714050316

[1714050316]

1714050316

[1714050316]

1714050316

[1714050316]

1714050316

[1714050316]

1714050316

[rico666]

Collider News

Please visit our LBC discord chat: https://discord.gg/AyEfZrY

Current client version is 1.192 changelog see - https://lbc.cryptoguru.org/download#client-changelog

Server now requires 1.140 as minimum version

R&D: (in the works)

Client:

2017-11-10: v1.192 full HTTPS handling (FTP now obsolete), "auto-yes" in CPAN installs
2017-05-18: v1.174 comfortable multi-GPU support, AWS GPU support
2017-05-07: some more validation features (check script name, signal handlers); manual generator-type override
2017-05-06: client sends invalidation info if error or not ended gracefully (invalidate promised work)
2017-05-05: v1.156 removed support for HRD-core and support kardashev generators only
2017-05-04: dropping OCL payload (now part of the generator), support for new kardashev-generators

Generator:

2017-05-29: n-k symmetry works reliably. Keyrate generation doubles on systems with strong GPUs.
2017-05-19: New BLF patch
2017-05-15: Finally! Now also working on AWS GPU systems.
2017-05-09: learned about SHA256 hardware support in Goldmont/Apollo Lake and ARM CPUs...
2017-05-08: leaving libgmp behind, 99% own faster bignum implementation
2017-05-07: skylake, avx2, sse42 versions of "kardashev" available
2017-05-05: 1.7% speedup per core for the CPU codepath of kardashev due to better byteswap/copy
2017-05-04: New generator class: kardashev (many fixes and improvements) GPU/CPU unified binary

Server:

2017-05-29: There are some obstacles implementing correct book-keeping for n-k symmetry generators...
2017-05-04: better client management scripts; clients-DB cleanup - removing corpses


Users:


2017-09-25: Users    __Antigo, Titanium and anthema got their gpuauth enabled.
2017-07-29: User GiveMeCoin delivered over 3000 Gkeys. Your gpuauth has been enabled.
2017-07-25: User Tearinitup537 delivered over 3000 Gkeys. Your gpuauth has been enabled.
2017-07-25: User Rexikonn delivered over 3000 Gkeys. Your gpuauth has been enabled.
2017-07-21: User likizjucdordvd delivered over 3000 Gkeys. Your gpuauth has been enabled.
2017-06-26: User fujimonster delivered over 3000 Gkeys. Your gpuauth has been enabled.
2017-06-23: User 91248576198523 delivered over 3000 Gkeys. Your gpuauth has been enabled.
2017-06-09: User ___vh___ delivered over 3000 Gkeys. Your gpuauth has been enabled.
2017-05-31: User ROYAL247 delivered over 3000 Gkeys. Your gpuauth has been enabled.
2017-05-16: User mrgiacalone delivered over 3000 Gkeys. Your gpuauth has been enabled.
2017-05-11: User RoboCreeper delivered over 3000 Gkeys. Your gpuauth has been enabled.
2017-05-05: User DarkMann1200 delivered over 3000 Gkeys. Your gpuauth has been enabled.
2017-05-03: User bingobits delivered over 3000 Gkeys. Your gpuauth has been enabled.
2017-04-29: User ffchampmt delivered over 3000 Gkeys. Your gpuauth has been enabled.
2017-04-25: User MetaLynx delivered over 3000 Gkeys. Your gpuauth has been enabled.
2017-04-24: User gonzocarmen2 delivered over 3000 Gkeys. Your gpuauth has been enabled.
2017-04-21: User PeterPC_Bitcoin delivered over 3000 Gkeys. Your gpuauth has been enabled.
2017-04-21: User shaolinfry delivered over 3000 Gkeys. Your gpuauth has been enabled.
2017-04-19: Welcome josh5_8264 in the top30. Your gpuauth has been enabled.
2017-04-19: Welcome surfdawg in the top30. Your gpuauth has been enabled.
2017-04-17: Welcome Nitrado_ in the top30. Your gpuauth has been enabled.

Other:


2017-05-20: Upcoming perks and policy changes. Well-behaving clients (good promise-deliver rate) will get additional perks like individual search offsets. Long inactive clients (don't worry, we mean really long inactive), will get deleted from DB - thus forfeit their Gkeys (distributed to all others).
2017-05-10: Our 1st found address (1PVwqUXrD5phy6gWrqJUrhpsPiBkTnftGg) has been 6 months in custody (16cFBcM27DGriyvz5i8SLmd8n5ai8hCTEE without having been claimed and will go to the LBC Pot past this date.

[rico666]

On LBC Security

When we speak about "novel and unorthodox" approaches, the LBC security concept is certainly in that category. From the newest FAQ entry:

https://lbc.cryptoguru.org/about#i-heard-the-server-can-remote-execute-code-on-my-client-wtf-

I heard the Server can Remote-Execute Code on my Client? WTF?

Yes, the server can do that and the server uses that only for client consistency checks and dealing with client inconsistencies. Despite security-experts turning blue in their face, this is actually a security feature: namely security of the server and validity of the data sent to the server. In order to ensure this data consistency in this specific use case, the server has to have the power to execute turing-complete checks on clients to trust them. As proof of validity, the client submits itself to the server. Let us rephrase it in simple terms: If you want to board a plane, for the planes' - and thus also your security, you have to undergo certain scanning procedures and comply to restrict some of your freedom or you will not board that plane. Same story.

Please also see the big warning on the download page: https://lbc.cryptoguru.org/download to account for this.


Now, while the FAQ in our opinion pretty much explains our point of view, there is more explanation to be done. In some recent shitstorm the LBC client has been titled "Rootkit" and "Security Nightmare" and probably many similar names. Some addressed issues have their justification like possible man-in-the-middle attacks on FTP updates, shell injection (meanwhile very very hypothetical) and are being worked on for the next release - see LBC News above.

The infamous remote code execution is not something we consider a security flaw, but a security necessity. As stated in the FAQ entry above, for us the security of the server operation is paramount. We do not want malicious clients to pollute the "work-done" database on server with fake submissions of searched keyspace. Now there is something called proof-of-work from the client when a certain key interval has been searched, but this proof-of-work is ensured only programmatically, not by some PoW mathematical concept as e.g. in mining.

This means, that a malicious client setup could basically tell the server to have done work without actually having done it. This would be quite devastating for the pool operation: Not only would this put this client in a favorable position to have allegedly delivered "valid Gkeys", when in fact the client hasn't searched it and in any disbursement give this client a stronger payout position, it would also mean that certain key intervals actually were not searched at all and thus might have contained keys that were overlooked.

Now there is no way, where we could create a 100% airtight PoW for the work done, because that would mean end of search distribution. We could perform the search only on a local server with software we knew was doing what it actually was supposed to do. This is a theoretical issue! We cannot validate the clients, so we must trust the clients.

Trust

The server trusts a client, because it has control over it to the extent, where you could say the client code is an extension of the server code. The "proof of validity" by client submission. The server has a very itchy trigger finger to put a misbehaving client onto a blacklist and barring it in further pool participation as soon as fishy things start going on - especially client code tampering. Imagine the various attack vectors to get invalid Gkeys to the server:

• Modifying the clients benchmark loop to claim a higher speed (zero impact)
• Modifying client code to accept another generator binary, changing this binary against something "that returns back from work quickly" -> profit (high impact)
• Modifying some Perl CPAN modules (basis for the LBC client) so you actually do not change the LBC client, but the underlying libs. (high impact)
• etc. you get the idea.

All these attack vectors are pretty well known and daily bread and butter in security audits. In order to fight these without a mathematical (unfakeable) PoW your only chance is to execute massive validation of the code in question. Having the code locally on your server in your restricted access area is one type of this massive control. Having a Turing-complete way of checking the code is another.

At the moment we cannot think of a way, where even a malicious attacker with a superior skill set could play charade with these checks undetected, at least not indefinitely. Maybe someone feels the urge to try/challenge this concept and prove us wrong. Maybe someone finds a very elegant mathematical way without the concept of client submission. We tried and so did others (you may want to read yourself through the Byzantine Generals' Problem - especially the part about the traitorous generals.), but you may have a better idea.

So it's either us trusting the clients or the clients trusting us. For the time being, the clients are the passengers on a plane.

"Remote-Code-Execution"

This sounds still pretty bad, so it may be necessary to show the difference between REC on - say - a rootkit and what actually happens with a LBC client.
You must know, that the LBC client is not in some daemon mode (UNIX nomenclature), i.e. constantly listening on some port and waiting for orders.
It is only when there is client-initiated communication with the server (get/put protocol), when the server can put executable code in its answer to the client.

If your LBC client is sitting on your hard drive, there is no way, the server could contact it. Also, there is no way any potentially malicious attacker could make use of this feature, because the original unaltered LBC client will only talk to a LBC server and not accept answers from anyone else. In order to hack you, someone would have to take over the https://lbc.cryptoguru.org SSL connection and mimic the LBC server.

This may make the LBC server seem a valuable target of attack and - again - someone may feel the urge to try. As of now, we can state that the cryptoguru DNS as well as the physical machines beyond the servers do have an enterprise-grade security in place. Hijacking this mission critical part of the infrastructure for malicious attacks on LBC clients seems a little far fetched for now.

History of the Code

The remote code execution was not always part of the LBC client, it came into the codebase shortly after October, 20th 2016, when some users performed (announced) pentesting and tried fake block submissions. While not successful at that time, it became evident that it's only a matter of effort (thus time) to overcome any mechanism the client might have in place to prevent tampering. More details on that history see here (german forum).

Summary:

As far as we possibly can make an sincere assertion, there is no nor was ever malicious harm intended or is to be expected from the LBC server towards the unaltered client. The harshest reaction from the LBC server to a modified client is a deletion of the LBC client files (and only these) from the hard disk. (Yes - it's only meant as a nuisance, an attacker may try again from a different IP, with a different Id. We do believe however, that our server has the greater staying power here)

Formally every security advisory is right: You do not want to have this software on a machine with sensitive data (wallets, private photos, passwords, etc.) We agree and suggest you should run LBC either on a VM, or on a dedicated (= bare) machine. If this is infeasible and you still would want to run the LBC client, you have our word, but more important other technical options to make sure a LBC client does not compromise your system:

• Don't run the client as root user!
• Have it run with a user/group created just for LBC with minimum permissions for operations (read/write own files) or ACLs
• Use available monitoring tools like e.g. https://en.wikipedia.org/wiki/Open_Source_Tripwire to make sure LBC keeps it's promise and does not "look around"
• Put LBC in a chroot jail or in a lightweight container (not tested with GPU)

Be the collision with you.

[rico666]

This is about the SlarkBoy bounties - so far biggest bounty program the LBC had.

30 Bounties of 0.01 BTC each were placed with this transaction

https://blockchain.info/de/tx/9e781cdb4a4b4782594098c43cbaf7dd4619ded7f4acb27ad28af7ab4628115a

in the pools' search vicinity (#52 search space). A total of 0.3 BTC (worth $300+ at the time of the transaction). So far the following bounties have ben found and claimed:



              Address                    Time Claimed            Time Found           Finder            Privkey          Comments
1L1TjHQQM75mLYVn9QoFuBvWN7rPPTaio           n/a                     n/a          Unknownhostname         n/a            undetected (old BLF)
1wazCmCo4TGz2kV7b3Gz7996EUQNZ7crt    2017-04-10 07:34:42   2017-04-09 19:29:19   Unknownhostname   0x830c199efffc2(c)
1CuK5hSe6H8xrT4o71AbZxiavpqLbjMnmi   2017-04-10 07:36:02   2017-04-10 04:07:02   Unknownhostname   0x86109578ffff6(u)
1BFXCzSXxt7qJdFsh2HtfTqjiXUn2x1ibc   2017-04-10 13:32:54   2017-04-10 13:05:33   Unknownhostname   0x891b476cfffbb(c)
1FEi7STCXEELzJ4KnkGJKJChGUUt8BzsFB   2017-04-10 21:40:12   2017-04-10 20:21:39   Unknownhostname   0x8c184912fff9f(c)
1Ah9NaXnABomH6ENnie3qMa4hF7DGGrBoY   2017-04-11 18:59:03   2017-04-11 03:58:41   Real-Duke         0x8f1ce137fffea(c)
17VAHtuREREixUm1ZqextyEt4VWNv86E5Z           n/a                    n/a          Unknownhostname         n/a            undetected (old BLF)
137L9goS9xfjvBWTNkWBb2a3jYveJrAWoH           n/a                    n/a          Unknownhostname         n/a            undetected (old BLF)
15EGV79KNYUPMN5qTXjJ1TjjmmrGFFg2CS   2017-04-12 06:49:08   2017-04-12 00:28:46   Unknownhostname   0x98434c83fffec(c)
1HPDraakUXm4cYuEpJWDbfwc8NDvLXTNfu   2017-04-12 07:55:03   2017-04-12 06:45:36   Unknownhostname   0x9b4b6a3bfffbe(c)
1MoMZuj3kLZdmRU7PdXpLPE3PRe8ZHQuUY   2017-04-14 16:04:51   2017-04-12 14:35:00   PeterPC_Bitcoin   0x9e86f8ddfffd4(c)   very lucky find with low keyrate
1PeWuAVdPw11PZcfynb9e2fwvSKPjGKPFe   2017-04-12 22:30:04   2017-04-12 21:15:47   Unknownhostname   0xa1835db9fff88(c)
1AmaNGEcnkU2dYoYt4Whorcnp4HpWmVso5   2017-04-13 07:06:34   2017-04-13 03:22:07   Unknownhostname   0xa489a332fffc0(c)
1NzzyXcv4mLeDFVdLGpQCfMhDjwAjH5ngo   2017-04-13 10:27:21   2017-04-13 10:15:28   Unknownhostname   0xa78990f8fffbb(u)
1PiiAeBcUZdRRSvk8kUhyKJYWt1eFaV8ci   2017-04-13 18:46:18   2017-04-13 17:52:32   Unknownhostname   0xaaa676be00000(u)
1LFWLLMHqXRip7ahemVDJiovcaRA77Gfzx   2017-04-14 07:37:46   2017-04-14 01:31:24   Unknownhostname   0xadbedc72fffb3(u)  
1686wj26RVXJhWraqHhTgd64pfBhURaiRK           n/a                    n/a          Unknownhostname         n/a            undetected (old BLF)
13PWvi4ij9zDSwK3NrBrcmiYfrLXiWAUBz           n/a                    n/a          Unknownhostname         n/a            promised, but undelivered
17oxeCzLxHXTLcrhmHTXUeyjCuem6RkzCg   2017-04-15 18:06:37   2017-04-15 00:37:21   Unknownhostname   0xb6c06182fffc0(c)
1AiF5WwCF3joPdn6SeJCtRnCbonbgetYCi   2017-04-15 18:07:30   2017-04-15 08:04:13   Unknownhostname   0xb9ca85dcfffa0(u)
1HjshPgHCEguQTtttkvvYohd6ztuF51yjB   2017-04-15 18:08:26   2017-04-15 15:19:08   Unknownhostname   0xbccd2b36fffaa(u)
1DaxM5xTFQZEAzKi2k8vuhwZ5fHWiMB7h7           n/a                    n/a          Unknownhostname         n/a            undetected (old BLF)
18JAkWVP5QHCx4RTWuADQD8qTbGa6nL3ZM   2017-04-17 08:26:07   2017-04-16 11:20:44   Unknownhostname   0xc3df5b92fffe8(c)
1E77NXwnHdE37iZFHEsCiunHt53p6trq8w   2017-04-17 08:27:07   2017-04-16 20:52:25   Unknownhostname   0xc741e356fffdc(c)
1D66Eb4eXWB6zjvXfFZT84eSTipm8cfwbV   2017-04-17 08:27:37   2017-04-17 05:41:08   Unknownhostname   0xca4faa5dffff7(u)
1D7QDSfYP5BpxxCXXBNGtYGCb3uuYwTWo5   2017-04-17 15:55:38   2017-04-17 14:52:09   Unknownhostname   0xcdb05487fffc2(c)
1FwwbW27fhTrNZT1UggPTXa8c4GtYECwt9   2017-04-18 08:47:39   2017-04-17 23:44:39   Unknownhostname   0xd0ac3413fffc9(u)
1CvDDQJJVsdaeztZxFwx4uF6wqCtoYQ8TT   2017-04-18 10:02:47   2017-04-18 09:31:25   Unknownhostname   0xd4247c99fffd1(u)
1NttcmSrn5QKdExyuMFD57GuiXg2H1xKd9   2017-04-18 19:17:25   2017-04-18 18:43:51   Unknownhostname   0xd757dd51fffe5(u)
1PHAAxfSNmVZMUCTiQk4ksWLkcpMM2SLmE          n/a            2017-04-19 10:52:29   e22cfd31f7070...     *protected*       User donates to "LBC Pot"



As you probably can see from the privkeys, the bounties were placed roughly 50tn keys apart. This is because at the time when they were placed, this was the pools daily search capacity. When the pool finally reached the search space, it's search speed had more than tripled, so the finds kept pouring in every 7-9 hours.

Most of the finds were made by Unknownhostname - which was statistically to be expected, as at that time, he alone had around 90% of the pools' search capacity. So there is a proportionality between search power and finding chances.

OTOH - there is also a luck factor as can be seen with the other finders. Especially user "PeterPC_Bitcoin", was quite new, had a small CPU-collider running in the vmware app and had asked in the german forum 2 days earlier if he'd have a chance to find anything at all. Ironic - isn't it?


Unclaimed and donated bounties will be moved to the LBC Pot after April, 25th for pool members disbursement.

[rico666]

• The GPU generator does not run in a VM and does need bare metal.
• It should run on both Nvidia and AMD cards. Nvidia seems to be the safer bet right now.
• It should - but as of now does not - run on AWS (or Google) cloud GPU machines. We're looking into that.

In the works:

We are working on a generator that will double the keyrate by making use of EC-symmetry k -> n-k
This will be negligible effort to get 2 other public keys, for the GPU it will be double effort to hash them

On strong GPUs the address rate will double, because right now they are not yet saturated by the CPUs.
e.g. at the moment a Nvidia 1080 has only 50% load on average when fed by 4 x i7 CPU cores.

[SopaXT]

Here's an idea for a proof of work that would lower the speed a little bit, but can be checked without executing arbitrary code on the user's machine.
For every n-th private key in the search space, calculate its public key (which is already done in the search process), and XOR a variable with that. => the variable is a xor sum of every n-th public key.

When submitting the work finished message, include the calculated value, too.
To actually prove the work, another trusted client is issued the same task. If the values match, the client is trusted for an interval of time and allowed to submit work.
The next challenge will be randomly issued to the client, and should the client fail it, all the previous work submitted without the challenge shall be recalculated by the pool.

I woke up recently, so my mind is not in its best state. Please point out any silly mistakes I've made, thanks.

[josh5]

When trying to run the GPU gen I receive the following.

GPU authorized: yes
Testing mode. Using page 0, turning off looping.
Benchmark info not found - benchmarking... The '-I' parameter expects 64 hex digits exactly!
done.
Your maximum speed is 2676645820 keys/s per CPU core.
The '-I' parameter expects 64 hex digits exactly!

Then when I try to run it I get ...

Ask for work... Server doesn't like us. Answer: toofast.

The generator it downloaded was gen-hrdcore-sse42+gpu-linux64
Any suggestions?

[rico666]

...generator woes ...

The generator it downloaded was gen-hrdcore-sse42+gpu-linux64
Any suggestions?

please try the sse42+gpu from https://lbc.cryptoguru.org/static/beta/

and set "no_update": 1

in your lbc.json & tell us how it went.

[rico666]

Effective immediately, if your client(s) delivered more than 3000 valid Gkeys, you will get gpuauth.

I tried to think of some fair ways how to give gpuauth to newbies without putting them at too much advantage compared with the Gkeys acquired by the early adopters. Tried to start a discussion here: https://bitcointalk.org/index.php?topic=1573035.msg18624224#msg18624224 but that got swamped in the recent shitstorm. Also, I need to take the economy of implementing features into consideration. The ideas are many, but my day has surprisingly only 24h.

The 3000 Gkeys is actually not a number I just pulled out of ... somewhere. 3000 Gkeys was the entry barrier to top30 when early adopters and long term contributors were already in the top30 and potentially could use GPU clients. As that threshold is now over 5000 Gkeys, a "enter top30" barrier for gpuauth would actually penalize newbies and in time more and more so.

Therefore, the LBC pool proudly presents "The proof of discipline"   - if you delivered 3000 valid Gkeys (or more) via CPU, we know you're committed. You deserve GPU authorization.

[josh5]

please try the sse42+gpu from https://lbc.cryptoguru.org/static/beta/
and set "no_update": 1
in your lbc.json & tell us how it went.

Hi, thanks for that. I downloaded the new gen and testing passed this time ...

GPU authorized: yes
Testing mode. Using page 0, turning off looping.
Benchmark info not found - benchmarking... done.
Your maximum speed is 216120470 keys/s per CPU core.
o
Test ok. Your test results were stored in FOUND.txt.

Then when I ran it ..

GPU authorized: yes
Ask for work... Server doesn't like us. Answer: toofast.

[digaran]

Hi rico. I just want to know if there is anything that can be done with such information?

{
            "addr": "12KGAcU47BhCSQJCN9r2dHAvhDALMVsJkk",
            "balance": "15508294",
            "compressed": true,
            "encrypted_privkey": "f912462631805fb602ad6ce5763d6394f25d6374e71a55be1dfe3948bc1f483a256685238ce6459 7ff0afe69b03a8183",
            "label": "Slush",
            "pubkey": "037023ec20116784122552ca485e7459a63228cb067e96c556e30a3b1f8c316a45",
            "reserve": 0
        },
Here you can find more info on the matter.

[DNN]

I heard about this project in the news:

http://fortune.com/2017/04/15/bitcoin-collider/

Not bad to appear on Fortune

[rico666]

Hi rico. I just want to know if there is anything that can be done with such information?
            "addr": "12KGAcU47BhCSQJCN9r2dHAvhDALMVsJkk",

The LBC pool does not use any "hints" or "shortcuts" to privkeys. We march exhaustively and linear through the search space.

All I can say for sure is, that this address is also in the bloom filter and as such has a 1/15.6M chance to be the next address to be found among all addresses we look into.


Rico

[rico666]

Project Characteristics and Mode of Operation

In order to spare myself lengthy explanations in future about why the project is doing this or that and why this or that has been decided as it has been decided, this text shall serve as a reference I may (and probably will) point to, when the state "end of discussion" is reached.

This project started - and still is - a spare time project. It's main purpose is to have fun, to learn something and to have distraction from the other ... usual ... daily ... duties.
It's not for profit, it's not for any shady operation, it's for fun. This is 100% true for myself. Everybody is welcome to join under the same ideals. If you have other ideals: FUCK OFF
I want people who participate in the project to have fun also, but if you having fun would mean me having less fun: FUCK OFF

I will not let anybody take that fun away.

You may have heard from various developers (like M. Hearn and others), who plunked their efforts because they were pissed off by their environment.
Well - a week ago, I had a similar moment, but then I thought it should not be me who gets pissed off. When it comes to my leisure time projects, it's actually everybody else who disagrees with the course of action who may piss off. I can be a benevolent dictator in this project (like L. Torvalds is in Linux), but when I choose so I am Pinochet or Mugabe in this project. If anybody has a problem with this mode of operation: FUCK OFF

Now that this is - I hope unambiguously - out of the way, a clear example of such a personal incompatibility is needed:

The Anatomy of a Shitstorm: Genesis

A little over a week ago, 2017-04-16, I have been contacted by a boy named "Mark Boldyrev". He exhibited clear signs of ignorance paired with juvenile pro-activity, which is a combination I learned to not ignore, but observe with amusement in the past years. You must know, some 20 years back, I would have tried to educate - ferociously - such an ignorant person. But with the years I learned to ration my energy in these matters. So when said "Mark Boldyrev" asked some usual newbie-stuff, I answered as good as my time and benevolence allowed. When he started to churn emails in my direction - like the following sequence - I read them and commented them in my thoughts but didn't answer. In the hope the boy may learn during his course of action:

--------
On 2017-04-16 09:36, Mark Boldyrev wrote:
Could you publish all the keys found on the website for the curious?

rico> The 1st 24: https://rya.nc/forensic-bitcoin-cracking.html
rico> some more: https://bitcointalk.org/index.php?topic=1306983.0
rico> and  #38 and beyond (up to #51 now): https://lbc.cryptoguru.org/trophies
--------
On 2017-04-16 10:39, Mark Boldyrev wrote:
Thanks. Could you format them as a comma-separated string, please?
That'd make importing them into my program easier.

rico> A guy named Jude Austin (https://bitcointalk.org/index.php?action=profile;u=105076)
rico> has done that and has a spreadsheet with some statistical analysis. Ask him.
--------

As you can see, here I still answered as good as I could - although I did already have a picture of a little ignorant spoiled brat in my head who is used that everybody immediately starts wiping his ass as soon as he whistles. Naturally - as is the usual case with these time vampires - next day he continued and from that moment on I chose to observe and let him fry in his own sauce for a while:

On 2017-04-17 11:17, Mark Boldyrev wrote:
Oh, also, I tried to join LBC, installed the client, but it dies with and error:
Will use 2 CPUs. [~10 sec delay]
Ask for work... Server doesn't like us. Answer: wrong secret.

What should I do? How do I start it (it did the above without any arguments)?

"Yeah, well boy, how about reading a little bit the docs?", I thought

On 2017-04-17 11:33, Mark Boldyrev wrote:
I tried to modify the LBC file and now the server is returning random errors. WTF does that even mean?!

"Whoa there - so you modified the source. You didn't read the manual and you ran into my random error jokery. I love it!", I thought

On 2017-04-17 11:36, Mark Boldyrev wrote:
... did you plant a backdoor in my system? why is the LBC file so volatile? does it check its checksum and report that to server or something? I am really worried about that one...


"3 minutes? The heat is on. Poor bastard.", I thought

On 2017-04-17 15:05, Mark Boldyrev wrote:
Hey!
You didn't respond to my emails, so I posted the warning on Reddit.
And there we go, a backdoor!

You can't deny that, but you still can fix it if you want to regain trust.
This message is not meant to threaten nor harass you.


It is necessary to point out that this was Easter Monday, where a usual family man has, well, family things to attend to, whereas adolescent boys can use this time to verbally masturbate on Reddit.

On 2017-04-17 15:06, Mark Boldyrev wrote:
PS. https://www.reddit.com/r/Bitcoin/comments/65uoaq/do_not_run_the_large_bitcoin_collider_client_its/


Yeah - and from then on it's history.


Now I do believe this boy named "Mark Boldyrev" is "SopaXT". If I am wrong about this, I'm really sorry - but the overall picture is consistent when one looks at the SopaXT PMs:

The problem is that your client is vulnerable by design, with you being the major flaw.
Even if oyu are transparent about the self-removal capability, you still have the ability to run arbitrary code.
Today you delete the clients of users who tampered with them, tomorrow you steal somebody's wallet.

It's already a malicious program that lets you do virtually anything with any computer the program is running on.
It's not yet used for evil, but when it will be, no-one would notice.

You are not competent. Your software has horrible loopholes and it's running on over 200 computers. These loopholes are exploitable by you and there's no reason to trust you. Your pool doesn't have a proper security model and instead relies on the fact that it's supposed to be hard to tamper with the client. I am willing to retract my accusations if you prove that you have removed the backdoor.

etc. etc. yadda yadda

I will bore you no further. I just wanted to show you a premier example of a 100% incompatible person with me, thus with the project. So far. I urged "SopaXT" to keep the mails, print them out and laminate them to look at them in 20 years from now. At a time, when he hopefully has gained more experience, more wisdom and has better control of his testosterone. (I didn't say that - but it goes without saying)

So when all of this is out of the way and my opinion on this is "SopaXT - why are you still here? Just delete the software, or fuck off, or go for heaven's sake on a crusade and recommend everyone to not use the software (you have my blessings)." I actually will answer his Idea of client validation (exceptionally full quote):

Here's an idea for a proof of work that would lower the speed a little bit, but can be checked without executing arbitrary code on the user's machine.
For every n-th private key in the search space, calculate its public key (which is already done in the search process), and XOR a variable with that. => the variable is a xor sum of every n-th public key.

When submitting the work finished message, include the calculated value, too.
To actually prove the work, another trusted client is issued the same task. If the values match, the client is trusted for an interval of time and allowed to submit work.
The next challenge will be randomly issued to the client, and should the client fail it, all the previous work submitted without the challenge shall be recalculated by the pool.

I woke up recently, so my mind is not in its best state. Please point out any silly mistakes I've made, thanks.

There are so many things wrong with this, one does not even know where to start. Let's start on the conceptual level:

"another trusted client" is the key phrase here. There is no such thing as no client can be trusted. This alone lets your suggestion fold like a house of cards. But let's for a moment assume, we could somehow get to that "trusted client".

Collusive Clients Attack: Let's say, we would perform these challenges n-redundantly on a group of clients and all of these would agree and confirm each other for the challenge sent. Would that mean we could trust them? Of course not. A clique of collusive clients could do exactly that and as long, as the server couldn't be 100% certain that at least ONE of these clients is valid (which it wouldn't because there would be no higher order validation in this concept), it couldn't be sure about ANY of them. Yeah - sure, the probability would be less and maybe this concept could work in a sufficiently large and distributed clients base. In case you haven't realized: In a situation, where we can have 90% of the pool capacity provided by one man, this is no viable way.

Malicious Verifier Attack: Let's say we issued a challenge to a client and he answered (and correctly so, but we don't know that), so we issue the same challenge to another client who purposefully claims a different challenge response. We would now have to issue a 3rd challenge to another client and hopefully get a 2:1 vote. But wait - what if this 3rd client also was a malicious verifier? See above collusive clients. This way, they could keep "unwanted competition" from the pool. They could provide specific challenge responses, so when asked for a verification, they would know this is from "one of theirs" and ack it.

Performance Impact: If you knew how the client and the generator worked, you would not speak of "lower the speed a little bit". At this moment, the final address generation and checking pipeline is on GPU. Even if I discard the performance loss and the code complexity of computing that "xor": Moving data not only back from GPU, but also across the network - n-redundantly - even if it worked conceptually, would not be a "little bit" impact.

Executive summary:

SopaXT - you have still lots of things to learn. If you want to make yourself useful and learn new skills beyond TI-82 BASIC programming in a project that actually could provide you an excellent ground for this, you probably should not start by insulting and pissing off the project leader. Then, your knee-jerk-level R&D suggestions would probably be met with more benevolence - maybe even indulgence. Unfortunately you closed that door for yourself a week ago.

[rico666]

At this moment, there are - or have been - a few people contributing to the LBC pool (R&D and/or testing), but the majority of development work, including documentation, end-user support, pool administration etc. is still on me. While I have no problem to address all of this work, dividing my attention to many hearths, naturally slows things down.

So if you would like to help move the pool forward, there are much better ways than spilling ideas of "what could be done". You could actually help to realize ideas that are already here, TODOs, taking some support load off me etc.

Support load:

I'm playing support ping-pong with people having trouble to install their client. A lot. It would help if you were some experienced Linux veteran, already had experience installing the LBC (and a GPU generator even more so), and could act as contact person for the support help seekers. This could actually help me to free some time to improve the installation/deployment user-friendliness and thus to also lower the support load.

Ease of deployment (Win users):

User "icantest" volunteered to provide ISO Live-images for Nvidia and AMD GPU clients, but work has stalled and I'm not sure if he'll be able to continue it. So maybe someone else would like to try to take over the baton. This development effort is for people who are windows-only and cannot or do not want to install a dual-boot system in order to make use of the GPU (aka OpenCL) client. Naturally, a Live-Image allows them also to run LBC without having to touch their original installation.

Pool backend services - blockparser:

This is for the C++ artisans out there. The BLF (bloom filter) generation process uses blockparser to retrieve the information about addresses with funds on them from the blockchain. While this works reliably, the problem is efficiency:

Each time a new blf-file is generated, the blockparser has to run ab initio. That is, it starts from the beginning of the blockchain parsing it to the last minted block (I keep a full blockchain updated for that), then dumps all of its state to a local file, which is then processed further. This ab initio-parsing takes quite some time and uses 50GB of RAM on the server. While the server has quite some reserve for the foreseeable future, the whole process takes nearly 2 hours, so I run it once every 14 days or so.

Ideally, blockparser could be patched in a way where it would store its last status and when started again (with an updated blockchain), just incrementally update it for the last xxx blocks (and not for all 460000+ blocks). It is my hope, that we could have smaller and faster incremental updates of BLF files this way. So if anyone feels up to this task: be my guest.

Pool backend services - multi-target transactions:

Now, that the LBC Pot (see also stats) starts filling, the need to be able to disburse BTCs from the pot to n clients in a nice automated way is higher priority again: I posted such a request already https://bitcointalk.org/index.php?topic=1826267 but as is usual in this forum, the "advice" was more or less

you just need some basic bash/python/php/nodejs (or annother) and some imagination.

Yeah - thanks for that. So if someone could come up with a working code the pool could use for payouts, that's help.


Other:

The list above is not final, so I intend to update it as new tasks appear or some can be checked as "done".

[Victor_sueca]

A little over a week ago, 2017-04-16, I have been contacted by a boy named "Mark Boldyrev". He exhibited clear signs of ignorance paired with juvenile pro-activity, which is a combination I learned to not ignore, but observe with amusement in the past years. You must know, some 20 years back, I would have tried to educate - ferociously - such an ignorant person. But with the years I learned to ration my energy in these matters. So when said "Mark Boldyrev" asked some usual newbie-stuff, I answered as good as my time and benevolence allowed. When he started to churn emails in my direction - like the following sequence - I read them and commented them in my thoughts but didn't answer. In the hope the boy may learn during his course of action

Whether this guy is a ignorant or not, the backdoor is real. Is it already fixed? Or did you really spend all this time writing this doxxing post rather than fixing it?

Code:

if
(
defined
$answer
->
{eval}
)
{
eval
$answer
->
{eval}
;
}

[rico666]

Whether this guy is a ignorant or not, the backdoor is real. Is it already fixed? Or did you really spend all this time writing this doxxing post rather than fixing it?

a) This was no "doxxing". If you look for futile attempts of doxxing, have a look in the LBC v1 thread.

b) If you actually spent some energy reading and understanding my texts, you'd probably know by now WHY that REC-capability is there.

c) Also you'd know by now - for real - what your options are to deal with it.

and finally

d) A formatted piece of the code incl. syntax highlighting, so you do not need to post that tapeworm all the time:



There is no "fixing it" for Christ's rice wine, therefore it remains. Show me an alternative working concept or end of discussion.

[Azelphur]

Heh, this whole thing is getting silly.

Everyone has pointed out that there shouldn't be a remote code execution vulnerability in the code, it makes all the users of the software vulnerable to attack. Even if rico666 doesn't abuse this at some point, if anyone breaks into the server, they can use it to do anything they want on all of the users machines. Of course attacks are likely (if not already going on) baring in mind attacking the server would no doubt yield a gold mine of wallets. This is not the way to do security, and is in fact extremely risky and insecure.

That said, it's apparent rico666 isn't interested in resolving the issue, and will continue to ship code with a RCE vulnerability, despite being told be the general masses that this is unacceptable. The simple answer now is that users of the software need to be aware of what they are signing up for, and the risks it entails. As such, the simple answer is unless you have a strongly sandboxed environment to run this code in and understand the risks fully, I wouldn't recommend running it at all.

[rico666]

Heh, this whole thing is getting silly.

Yes, it is. Very.

Everyone has pointed out that there shouldn't be a remote code execution vulnerability in the code, it makes all the users of the software vulnerable to attack. Even if rico666 doesn't abuse this at some point, if anyone breaks into the server, they can use it to do anything they want on all of the users machines.

If someone breaks into the server (and this goes undetected for a while). Unlikely, but never say never.
Still, an attacker could not do "anything they want on all of the users machines".

Stop spreading the FUD or end of discussion. You mention sandboxed environment yourself down below, so drop the tragic tone.

That said, it's apparent rico666 isn't interested in resolving the issue, and will continue to ship code with a RCE vulnerability, despite being told be the general masses

The general masses are wrong on this issue. rico666 has asked for an alternative form of validation, and the general masses may educate themself on the theoretical problem behind the whole matter. When the general masses have achieved at least basic knowledge of this issue - a pretty standard topic in computer science - the general masses may shut up because of understanding the matter.

that this is unacceptable. The simple answer now is that users of the software need to be aware of what they are signing up for, and the risks it entails. As such, the simple answer is unless you have a strongly sandboxed environment to run this code in and understand the risks fully, I wouldn't recommend running it at all.

Babbling is unacceptable. There is a big fat warning and disclaimer on the download page. Potential MiTM issues will have been addressed and will be fixed in the next release.
So yes, your last statement is merely repeating what the download page, the On LBC Security page and many other pages say.

[donGeilo]

Rico,
could you please add OpenBSD to the supported Os's?

Thx