|
Title: Large Bitcoin Collider Thread 2.0 Post by: rico666 on April 20, 2017, 06:54:26 AM About the Collider
The Large Bitcoin Collider (https://lbc.cryptoguru.org/stats) (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
The last ones we are interested in. This pool is not searching for brainwallets and our mode of search (http://) 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:
About this Thread Contrary to the 1st a.k.a v1-Thread (https://bitcointalk.org/index.php?topic=1573035.0), 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:
What may get your post kicked with delay:
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 "When I grow up, I want to be like https://bitcointalk.org/index.php?topic=973843.0" Title: LBC News Post by: rico666 on April 20, 2017, 06:55:03 AM 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 (https://lbc.cryptoguru.org/stats/GiveMeCoin) delivered over 3000 Gkeys. Your gpuauth has been enabled. 2017-07-25: User Tearinitup537 (https://lbc.cryptoguru.org/stats/Tearinitup537) delivered over 3000 Gkeys. Your gpuauth has been enabled. 2017-07-25: User Rexikonn (https://lbc.cryptoguru.org/stats/Rexikonn) delivered over 3000 Gkeys. Your gpuauth has been enabled. 2017-07-21: User likizjucdordvd (https://lbc.cryptoguru.org/stats/likizjucdordvd) delivered over 3000 Gkeys. Your gpuauth has been enabled. 2017-06-26: User fujimonster (https://lbc.cryptoguru.org/stats/fujimonster) delivered over 3000 Gkeys. Your gpuauth has been enabled. 2017-06-23: User 91248576198523 (https://lbc.cryptoguru.org/stats/91248576198523) delivered over 3000 Gkeys. Your gpuauth has been enabled. 2017-06-09: User ___vh___ (https://lbc.cryptoguru.org/stats/___vh___) delivered over 3000 Gkeys. Your gpuauth has been enabled. 2017-05-31: User ROYAL247 (https://lbc.cryptoguru.org/stats/ROYAL247) delivered over 3000 Gkeys. Your gpuauth has been enabled. 2017-05-16: User mrgiacalone (https://lbc.cryptoguru.org/stats/mrgiacalone) delivered over 3000 Gkeys. Your gpuauth has been enabled. 2017-05-11: User RoboCreeper (https://lbc.cryptoguru.org/stats/RoboCreeper) delivered over 3000 Gkeys. Your gpuauth has been enabled. 2017-05-05: User DarkMann1200 (https://lbc.cryptoguru.org/stats/DarkMann1200) delivered over 3000 Gkeys. Your gpuauth has been enabled. 2017-05-03: User bingobits (https://lbc.cryptoguru.org/stats/bingobits) delivered over 3000 Gkeys. Your gpuauth has been enabled. 2017-04-29: User ffchampmt (https://lbc.cryptoguru.org/stats/ffchampmt) delivered over 3000 Gkeys. Your gpuauth has been enabled. 2017-04-25: User MetaLynx (https://lbc.cryptoguru.org/stats/MetaLynx) delivered over 3000 Gkeys. Your gpuauth has been enabled. 2017-04-24: User gonzocarmen2 (https://lbc.cryptoguru.org/stats/gonzocarmen2) delivered over 3000 Gkeys. Your gpuauth has been enabled. 2017-04-21: User PeterPC_Bitcoin (https://lbc.cryptoguru.org/stats/PeterPC_Bitcoin) delivered over 3000 Gkeys. Your gpuauth has been enabled. 2017-04-21: User shaolinfry (https://lbc.cryptoguru.org/stats/shaolinfry) delivered over 3000 Gkeys. Your gpuauth has been enabled. 2017-04-19: Welcome josh5_8264 (https://lbc.cryptoguru.org/stats/josh5_8264) in the top30. Your gpuauth has been enabled. 2017-04-19: Welcome surfdawg (https://lbc.cryptoguru.org/stats/surfdawg) in the top30. Your gpuauth has been enabled. 2017-04-17: Welcome Nitrado_ (https://lbc.cryptoguru.org/stats/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 (https://blockchain.info/address/1PVwqUXrD5phy6gWrqJUrhpsPiBkTnftGg)) has been 6 months in custody (16cFBcM27DGriyvz5i8SLmd8n5ai8hCTEE (https://blockchain.info/address/16cFBcM27DGriyvz5i8SLmd8n5ai8hCTEE) without having been claimed and will go to the LBC Pot past this date. Title: On LBC Security Post by: rico666 on April 20, 2017, 06:55:42 AM 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- Quote 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:
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 (https://www.microsoft.com/en-us/research/wp-content/uploads/2016/12/The-Byzantine-Generals-Problem.pdf) - 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 (https://bitcointalk.org/index.php?topic=1581701.msg18630527#msg18630527) (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:
Be the collision with you. Title: The SlarkBoy a.k.a __KULME__ Bounties Post by: rico666 on April 20, 2017, 03:20:44 PM 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 (https://blockchain.info/de/address/1L1TjHQQM75mLYVn9QoFuBvWN7rPPTaio) n/a n/a Unknownhostname n/a undetected (old BLF) 1wazCmCo4TGz2kV7b3Gz7996EUQNZ7crt (https://blockchain.info/de/address/1wazCmCo4TGz2kV7b3Gz7996EUQNZ7crt) 2017-04-10 07:34:42 2017-04-09 19:29:19 Unknownhostname 0x830c199efffc2(c) 1CuK5hSe6H8xrT4o71AbZxiavpqLbjMnmi (https://blockchain.info/de/address/1CuK5hSe6H8xrT4o71AbZxiavpqLbjMnmi) 2017-04-10 07:36:02 2017-04-10 04:07:02 Unknownhostname 0x86109578ffff6(u) 1BFXCzSXxt7qJdFsh2HtfTqjiXUn2x1ibc (https://blockchain.info/de/address/1BFXCzSXxt7qJdFsh2HtfTqjiXUn2x1ibc) 2017-04-10 13:32:54 2017-04-10 13:05:33 Unknownhostname 0x891b476cfffbb(c) 1FEi7STCXEELzJ4KnkGJKJChGUUt8BzsFB (https://blockchain.info/de/address/1FEi7STCXEELzJ4KnkGJKJChGUUt8BzsFB) 2017-04-10 21:40:12 2017-04-10 20:21:39 Unknownhostname 0x8c184912fff9f(c) 1Ah9NaXnABomH6ENnie3qMa4hF7DGGrBoY (https://blockchain.info/de/address/1Ah9NaXnABomH6ENnie3qMa4hF7DGGrBoY) 2017-04-11 18:59:03 2017-04-11 03:58:41 Real-Duke 0x8f1ce137fffea(c) 17VAHtuREREixUm1ZqextyEt4VWNv86E5Z (https://blockchain.info/de/address/17VAHtuREREixUm1ZqextyEt4VWNv86E5Z) n/a n/a Unknownhostname n/a undetected (old BLF) 137L9goS9xfjvBWTNkWBb2a3jYveJrAWoH (https://blockchain.info/de/address/137L9goS9xfjvBWTNkWBb2a3jYveJrAWoH) n/a n/a Unknownhostname n/a undetected (old BLF) 15EGV79KNYUPMN5qTXjJ1TjjmmrGFFg2CS (https://blockchain.info/de/address/15EGV79KNYUPMN5qTXjJ1TjjmmrGFFg2CS) 2017-04-12 06:49:08 2017-04-12 00:28:46 Unknownhostname 0x98434c83fffec(c) 1HPDraakUXm4cYuEpJWDbfwc8NDvLXTNfu (https://blockchain.info/de/address/1HPDraakUXm4cYuEpJWDbfwc8NDvLXTNfu) 2017-04-12 07:55:03 2017-04-12 06:45:36 Unknownhostname 0x9b4b6a3bfffbe(c) 1MoMZuj3kLZdmRU7PdXpLPE3PRe8ZHQuUY (https://blockchain.info/de/address/1MoMZuj3kLZdmRU7PdXpLPE3PRe8ZHQuUY) 2017-04-14 16:04:51 2017-04-12 14:35:00 PeterPC_Bitcoin 0x9e86f8ddfffd4(c) very lucky find with low keyrate 1PeWuAVdPw11PZcfynb9e2fwvSKPjGKPFe (https://blockchain.info/de/address/1PeWuAVdPw11PZcfynb9e2fwvSKPjGKPFe) 2017-04-12 22:30:04 2017-04-12 21:15:47 Unknownhostname 0xa1835db9fff88(c) 1AmaNGEcnkU2dYoYt4Whorcnp4HpWmVso5 (https://blockchain.info/de/address/1AmaNGEcnkU2dYoYt4Whorcnp4HpWmVso5) 2017-04-13 07:06:34 2017-04-13 03:22:07 Unknownhostname 0xa489a332fffc0(c) 1NzzyXcv4mLeDFVdLGpQCfMhDjwAjH5ngo (https://blockchain.info/de/address/1NzzyXcv4mLeDFVdLGpQCfMhDjwAjH5ngo) 2017-04-13 10:27:21 2017-04-13 10:15:28 Unknownhostname 0xa78990f8fffbb(u) 1PiiAeBcUZdRRSvk8kUhyKJYWt1eFaV8ci (https://blockchain.info/de/address/1PiiAeBcUZdRRSvk8kUhyKJYWt1eFaV8ci) 2017-04-13 18:46:18 2017-04-13 17:52:32 Unknownhostname 0xaaa676be00000(u) 1LFWLLMHqXRip7ahemVDJiovcaRA77Gfzx (https://blockchain.info/de/address/1LFWLLMHqXRip7ahemVDJiovcaRA77Gfzx) 2017-04-14 07:37:46 2017-04-14 01:31:24 Unknownhostname 0xadbedc72fffb3(u) 1686wj26RVXJhWraqHhTgd64pfBhURaiRK (https://blockchain.info/de/address/1686wj26RVXJhWraqHhTgd64pfBhURaiRK) n/a n/a Unknownhostname n/a undetected (old BLF) 13PWvi4ij9zDSwK3NrBrcmiYfrLXiWAUBz (https://blockchain.info/de/address/13PWvi4ij9zDSwK3NrBrcmiYfrLXiWAUBz) n/a n/a Unknownhostname n/a promised, but undelivered 17oxeCzLxHXTLcrhmHTXUeyjCuem6RkzCg (https://blockchain.info/de/address/17oxeCzLxHXTLcrhmHTXUeyjCuem6RkzCg) 2017-04-15 18:06:37 2017-04-15 00:37:21 Unknownhostname 0xb6c06182fffc0(c) 1AiF5WwCF3joPdn6SeJCtRnCbonbgetYCi (https://blockchain.info/de/address/1AiF5WwCF3joPdn6SeJCtRnCbonbgetYCi) 2017-04-15 18:07:30 2017-04-15 08:04:13 Unknownhostname 0xb9ca85dcfffa0(u) 1HjshPgHCEguQTtttkvvYohd6ztuF51yjB (https://blockchain.info/de/address/1HjshPgHCEguQTtttkvvYohd6ztuF51yjB) 2017-04-15 18:08:26 2017-04-15 15:19:08 Unknownhostname 0xbccd2b36fffaa(u) 1DaxM5xTFQZEAzKi2k8vuhwZ5fHWiMB7h7 (https://blockchain.info/de/address/1DaxM5xTFQZEAzKi2k8vuhwZ5fHWiMB7h7) n/a n/a Unknownhostname n/a undetected (old BLF) 18JAkWVP5QHCx4RTWuADQD8qTbGa6nL3ZM (https://blockchain.info/de/address/18JAkWVP5QHCx4RTWuADQD8qTbGa6nL3ZM) 2017-04-17 08:26:07 2017-04-16 11:20:44 Unknownhostname 0xc3df5b92fffe8(c) 1E77NXwnHdE37iZFHEsCiunHt53p6trq8w (https://blockchain.info/de/address/1E77NXwnHdE37iZFHEsCiunHt53p6trq8w) 2017-04-17 08:27:07 2017-04-16 20:52:25 Unknownhostname 0xc741e356fffdc(c) 1D66Eb4eXWB6zjvXfFZT84eSTipm8cfwbV (https://blockchain.info/de/address/1D66Eb4eXWB6zjvXfFZT84eSTipm8cfwbV) 2017-04-17 08:27:37 2017-04-17 05:41:08 Unknownhostname 0xca4faa5dffff7(u) 1D7QDSfYP5BpxxCXXBNGtYGCb3uuYwTWo5 (https://blockchain.info/de/address/1D7QDSfYP5BpxxCXXBNGtYGCb3uuYwTWo5) 2017-04-17 15:55:38 2017-04-17 14:52:09 Unknownhostname 0xcdb05487fffc2(c) 1FwwbW27fhTrNZT1UggPTXa8c4GtYECwt9 (https://blockchain.info/de/address/1FwwbW27fhTrNZT1UggPTXa8c4GtYECwt9) 2017-04-18 08:47:39 2017-04-17 23:44:39 Unknownhostname 0xd0ac3413fffc9(u) 1CvDDQJJVsdaeztZxFwx4uF6wqCtoYQ8TT (https://blockchain.info/de/address/1CvDDQJJVsdaeztZxFwx4uF6wqCtoYQ8TT) 2017-04-18 10:02:47 2017-04-18 09:31:25 Unknownhostname 0xd4247c99fffd1(u) 1NttcmSrn5QKdExyuMFD57GuiXg2H1xKd9 (https://blockchain.info/de/address/1NttcmSrn5QKdExyuMFD57GuiXg2H1xKd9) 2017-04-18 19:17:25 2017-04-18 18:43:51 Unknownhostname 0xd757dd51fffe5(u) 1PHAAxfSNmVZMUCTiQk4ksWLkcpMM2SLmE (https://blockchain.info/de/address/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 (https://blockchain.info/de/address/1LBCPotwPzBvBcTtd7ADGzCWPXXsZE19j6) after April, 25th for pool members disbursement. Title: Some infos about the GPU generator Post by: rico666 on April 20, 2017, 09:32:20 PM
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. Title: Re: Large Bitcoin Collider Thread 2.0 Post by: SopaXT on April 21, 2017, 08:18:04 AM 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. Title: Re: Large Bitcoin Collider Thread 2.0 Post by: josh5 on April 21, 2017, 03:12:25 PM 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? Title: Re: Large Bitcoin Collider Thread 2.0 Post by: rico666 on April 21, 2017, 05:53:39 PM ...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. Title: >3000 Gkeys = gpuauth Post by: rico666 on April 21, 2017, 09:11:23 PM 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" :D - if you delivered 3000 valid Gkeys (or more) via CPU, we know you're committed. You deserve GPU authorization. Title: Re: Large Bitcoin Collider Thread 2.0 Post by: josh5 on April 22, 2017, 02:59:39 PM 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. Title: Re: Large Bitcoin Collider Thread 2.0 Post by: digaran on April 24, 2017, 02:07:58 AM 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 (https://bitcointalk.org/index.php?topic=1883978.0) you can find more info on the matter. Title: Re: Large Bitcoin Collider Thread 2.0 Post by: DNN on April 24, 2017, 03:57:46 AM I heard about this project in the news:
http://fortune.com/2017/04/15/bitcoin-collider/ Not bad to appear on Fortune :) Title: Re: Large Bitcoin Collider Thread 2.0 Post by: rico666 on April 24, 2017, 05:56:48 AM 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 Title: Project Characteristics and Mode of Operation Post by: rico666 on April 24, 2017, 08:39:51 PM 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. Title: R&D contribution - How you could help the pool Post by: rico666 on April 25, 2017, 08:14:04 AM 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 (https://github.com/znort987/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 (https://blockchain.info/address/1LBCPotwPzBvBcTtd7ADGzCWPXXsZE19j6) (see also stats (https://lbc.cryptoguru.org/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 Quote 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". Title: Re: Large Bitcoin Collider Thread 2.0 Post by: Victor_sueca on April 25, 2017, 01:14:49 PM 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 Title: Re: Large Bitcoin Collider Thread 2.0 Post by: rico666 on April 25, 2017, 02:16:38 PM 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: https://i.imgur.com/Qa0OwLb.png There is no "fixing it" for Christ's rice wine, therefore it remains. Show me an alternative working concept or end of discussion. Title: Re: Large Bitcoin Collider Thread 2.0 Post by: Azelphur on April 25, 2017, 04:45:04 PM 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. Title: Re: Large Bitcoin Collider Thread 2.0 Post by: rico666 on April 25, 2017, 04:55:54 PM Heh, this whole thing is getting silly. Yes, it is. Very. Quote 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. Quote 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. Quote 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 (https://lbc.cryptoguru.org/download) page, the On LBC Security (https://bitcointalk.org/index.php?topic=1877935.msg18665927#msg18665927) page and many other pages say. Title: Re: Large Bitcoin Collider Thread 2.0 Post by: donGeilo on April 25, 2017, 07:21:29 PM Rico,
could you please add OpenBSD to the supported Os's? Thx Title: Re: Large Bitcoin Collider Thread 2.0 Post by: rico666 on April 26, 2017, 01:47:32 PM could you please add OpenBSD to the supported Os's? When there is time - should not be too much effort. Biggest obstacle is to get some OpenBSD VM - so if you have a pointer to a suitable OpenBSD vmdk, it would speed things up. What I can do for now, is to add Win10 to the list of supported operating systems. :) It's true - the "bash for Windows" a.k.a. Canonical/Microsoft Ubuntu in the newest Win10 Creators Update can run the LBC with a CPU generator (not sure if GPU will be possible with this edit: nope - not possible as of now). After user "Coinpiet" got it running, I tried myself and it works! Title: Re: Large Bitcoin Collider Thread 2.0 Post by: GoldTiger69 on April 26, 2017, 04:07:17 PM Now that the bounties have been moved , can you please show the remaining keys?
Thanks in advance. Title: Re: Large Bitcoin Collider Thread 2.0 Post by: rico666 on April 26, 2017, 06:32:18 PM Now that the bounties have been moved , can you please show the remaining keys? Well - technically they have not been moved yet. https://blockchain.info/address/1LBCPotwPzBvBcTtd7ADGzCWPXXsZE19j6 Still unconfirmed transaction, I have been - again - fooled by the core client when I adjusted a transaction fee for confirmation within 15 blocks. This fee estimate in the core client is seriously broken, or miners too greedy. :-\ As soon as this goes through, I'll publish the keys. Title: Re: Large Bitcoin Collider Thread 2.0 Post by: GoldTiger69 on April 26, 2017, 06:39:21 PM Now that the bounties have been moved , can you please show the remaining keys? Well - technically they have not been moved yet. https://blockchain.info/address/1LBCPotwPzBvBcTtd7ADGzCWPXXsZE19j6 Still unconfirmed transaction, I have been - again - fooled by the core client when I adjusted a transaction fee for confirmation within 15 blocks. This fee estimate in the core client is seriously broken, or miners too greedy. :-\ As soon as this goes through, I'll publish the keys. Thanks man, I appreciate it. Title: Re: Large Bitcoin Collider Thread 2.0 Post by: SopaXT on April 27, 2017, 03:21:27 PM While thinking about a proof-of-work method, I remembered about BOINC (think Folding@Home, etc). How do they verify work? This can be applicable to LBC.
Title: Re: Large Bitcoin Collider Thread 2.0 Post by: BurtW on April 27, 2017, 03:32:43 PM I think this deserves a spot in this thread. If not then it will get deleted:
This puzzle is very strange. If it's for measuring the world's brute forcing capacity, 161-256 are just a waste (RIPEMD160 entropy is filled by 160, and by all of P2PKH Bitcoin). The puzzle creator could improve the puzzle's utility without bringing in any extra funds from outside - just spend 161-256 across to the unsolved portion 51-160, and roughly treble the puzzle's content density. If on the other hand there's a pattern to find... well... that's awfully open-ended... can we have a hint or two? :D I am the creator. You are quite right, 161-256 are silly. I honestly just did not think of this. What is especially embarrassing, is this did not occur to me once, in two years. By way of excuse, I was not really thinking much about the puzzle at all. I will make up for two years of stupidity. I will spend from 161-256 to the unsolved parts, as you suggest. In addition, I intend to add further funds. My aim is to boost the density by a factor of 10, from 0.001*length(key) to 0.01*length(key). Probably in the next few weeks. At any rate, when I next have an extended period of quiet and calm, to construct the new transaction carefully. A few words about the puzzle. There is no pattern. It is just consecutive keys from a deterministic wallet (masked with leading 000...0001 to set difficulty). It is simply a crude measuring instrument, of the cracking strength of the community. Finally, I wish to express appreciation of the efforts of all developers of new cracking tools and technology. The "large bitcoin collider" is especially innovative and interesting! Title: Re: Large Bitcoin Collider Thread 2.0 Post by: rico666 on April 27, 2017, 04:10:43 PM While thinking about a proof-of-work method, I remembered about BOINC (think Folding@Home, etc). How do they verify work? This can be applicable to LBC. We talked about BOINC in the german thread (here (https://bitcointalk.org/index.php?topic=1581701.msg18481061#msg18481061) and my answer (https://bitcointalk.org/index.php?topic=1581701.msg18481160#msg18481160)), but mainly because of its "ease of deployment" - compared to the effort to deploy LBC. BOINC is a framework for distributed computing. It enables applications - mostly for scientific numeric computations - to be distributed as "payload" to BOINC clients. Now your question should be: Does BOINC enable arbitrary code execution on my client? Of course it does. It's the nature of the thing. Does it prevent "data poisoning" from the clients? Unfortunately no. (See below the Milburn presentation) http://boinc.berkeley.edu/wiki/Usage_rules Quote Is it safe to run BOINC? Any time you download a program through the Internet you are taking a chance: the program might have dangerous errors, or the download server might have been hacked. Liability The BOINC project and the University of California assume no liability for damage to your computer, loss of data, or any other event or condition that may occur as a result of participating in BOINC-based projects. It's exactly the same. Do not run it if you do not trust the project. I know, BOINC is a quite famous project and 99,9% used for good scientific reasons, but would rico666 - the computer scientist - trust it more than LBC? http://crowdcomputing.eu/documents/10508/844563/Milburn.pdf https://security-tracker.debian.org/tracker/CVE-2013-2018 (SQL Injection http://www.securityfocus.com/bid/59568/discuss) https://nvd.nist.gov/vuln/detail/CVE-2013-7386 https://www.cvedetails.com/bugtraq-bid/59565/BOINC-CVE-2013-2019-Stack-Based-Buffer-Overflow-Vulerability.html https://boinc.berkeley.edu/dev/forum_thread.php?id=9141 Let's cut it down: http://www.cvedetails.com/product/27779/Rom-Walton-Boinc.html?vendor_id=13367 I know LBC cannot (and probably never will) compare to BOINC in terms of R&D manpower behind it as well as "fame". But at the moment I do not feel like BOINC would security-wise do things better than LBC. Rico Title: Re: Large Bitcoin Collider Thread 2.0 Post by: rico666 on April 27, 2017, 04:21:48 PM I think this deserves a spot in this thread. If not then it will get deleted: If true, then wow. Of course up to now we do not have more than the claim of a newly created bitcointalk-account. I am the creator. ... I will make up for two years of stupidity. I will spend from 161-256 to the unsolved parts, as you suggest. In addition, I intend to add further funds. My aim is to boost the density by a factor of 10, from 0.001*length(key) to 0.01*length(key). Probably in the next few weeks. At any rate, when I next have an extended period of quiet and calm, to construct the new transaction carefully. I guess we will have to wait if deeds follow words. If so, we can assume his claim is true and then - see my "wow" above. I wouldn't have expected the creator to appear. Quote Finally, I wish to express appreciation of the efforts of all developers of new cracking tools and technology. The "large bitcoin collider" is especially innovative and interesting! Accolade time! :) (if he is indeed the creator of the puzzle transaction) Title: Re: Large Bitcoin Collider Thread 2.0 Post by: SopaXT on April 27, 2017, 04:53:55 PM I honestly don't understand your efforts to prevent client tampering, as I said before. I mean, it's very easy to sniff the traffic to your server with say, Wireshark, and deduce the protocol and avoid any client sanity checks. Maybe we could move the LBC on a platform that already exists and is trusted? Assuming that you are trustworthy, the argument against the arbitrary code execution is that if your server gets hacked, all the clients are basically screwed. Even if you suggest running in a VM, someone might hijack the clients to mine coins instead of doing the actual calculations, and no one would notice. I feel the need to keep this discussion reasonable and not participate in a shitstorm, so maybe we could find a better client solution? If you want to keep executing code, maybe we can ask the user, like stopping the program and asking:
Code: LBC paused: server wants to execute the following command, allow? [Y/N] This would actually be a good protection against a hijacked server. Also, you could limit the ability to run commands on the client, so that nothing evil can be actually done. e.g. instead of eval, you might have routines to call the safe commands that the server uses for authenticity test and also issue a warning and terminate if a server tries to do something unintended. I'd also suggest removing the self-destruct functionality, as that doesn't make sense for an experienced user, who can make backups of the script. Title: Re: Large Bitcoin Collider Thread 2.0 Post by: rico666 on April 27, 2017, 06:13:44 PM I honestly don't understand your efforts to prevent client tampering, as I said before. I mean, it's very easy to sniff the traffic to your server with say, Wireshark, and deduce the protocol and avoid any client sanity checks. You said it yourself: You honestly do not understand. I believe you. Yet we have a problem, as you consider me incompetent. ;) I do not mind, but I can imagine it must be hard for you to learn something from me ... then so maybe I am not the right discussion partner? You can sniff the traffic (and please do so). What you will see are various code snippets such as this: Code: {Actually this is v1 - some 4 months old - the new validation schemes are different, and there are quite some of them. The newest ones actually do check if they were executed on a genuine Perl-eval, send a nonce to prevent some "preimage" fakery etc. So the protocol is easy, you can sniff the code, but you will not be able to fake the code. Please try. The strategy on the client side cannot be to simply not execute the code, because that will put your client id and IP on blacklist, or even gets it deleted from the DB and all Gkeys delivered so far are forfeited and redistributed to other clients. Game over. Quote Assuming that you are trustworthy, the argument against the arbitrary code execution is that if your server gets hacked, all the clients are basically screwed. This is moving the goalposts, but ok. Let's be precise though: If the server gets hacked and if that goes undetected and if the clients do not run in some sandboxed environment and if the clients do contain precious data and if the clients are unmonitored by their owners. => Yes, then these and only these clients are basically screwed. You are also welcome to try to hack the server. Quote Even if you suggest running in a VM, someone might hijack the clients to mine coins instead of doing the actual calculations, and no one would notice. See above. No one can hijack a LBC client but the LBC server itself. Running the LBC client makes the machine the LBC client runs on not susceptible to hacks/attacks from anywhere else than the LBC server. So if someone hijacked that VM (or a dedicated machine or whatever), it would be because of something else (open SSH, bug in another program, some browser exploit, whatever...), but not the LBC client. How might someone hijack the client? There is no way to perform a REC from someone else than the LBC server. You seem to permanently forget that. There is ONE security-issue left that Ryan Castellucci brought up - and that is the MiTM attack of the update mechanism from the FTP. And that will be fixed. Actually it might get fixed the sooner the less I am busy explaining the LBC validation concept. ;) When this is fixed, then There is no way to hijack a machine by the means of the LBC client if you are not the LBC server. Quote I feel the need to keep this discussion reasonable and not participate in a shitstorm, so maybe we could find a better client solution? If you want to keep executing code, maybe we can ask the user, like stopping the program and asking: Code: LBC paused: server wants to execute the following command, allow? [Y/N] Unfortunately no, because time is of the essence when validating. If validation would allow for arbitrary execution time, a client operator could of course make coffee, light up a cigarette, analyze the code, and then write his own code that would fake the validation code just sent. Sure - even here the server would have the longer staying power, but potentially you could get invalid data into the server that way. What I thought, was to have a logging facility in LBC, which would log with a timestamp when a server-client validation occured. But then again - you could not trust that either, because potentially, the REC could undo this. => Back to START. As for your example: A simple chroot-jail and of course no sudo rights for the user running the LBC. Quote This would actually be a good protection against a hijacked server. Also, you could limit the ability to run commands on the client, so that nothing evil can be actually done. e.g. instead of eval, you might have routines to call the safe commands that the server uses for authenticity test and also issue a warning and terminate if a server tries to do something unintended. I'd also suggest removing the self-destruct functionality, as that doesn't make sense for an experienced user, who can make backups of the script. Again: There is no way to hijack a LBC client if you are not the LBC server. Please embed that into your considerations. Even IF someone hijacked a machine where the LBC client runs on, he still has no way to use that eval unless he IS the LBC server. And then he probably already got a shell anyway, so why bother with that eval that listens only to a specific SSL connection? Also: You are again striding away from the turing-complete validation, which would actually leave the validation prone to countermeasures as you have suggested in your 1st paragraph. I can exactly see how you are thinking and why you have concerns. Please excuse me, if I say it's still because you are lacking insight - but I really do appreciate the factual tone. We'll eventually get there. As for hacking the LBC server: I am not going to say it is NSA/CIA proof, because it probably isn't. But it's secured state-of-the-art, monitored 24/7 and as I have written above enterprise-class. This is no "cheap VPS running somewhere in da cloud". So while not saying "never", I can say that the server is not going to be hacked AND that goes undetected. Worst case scenario: Server gets hacked and we shut down the VM for analysis. So if we boil down to "So my LBC client security depends on the LBC server security?", the answer is YES. Title: Re: Large Bitcoin Collider Thread 2.0 Post by: onemanatatime on April 28, 2017, 06:10:43 AM Are you planning any kind of crowdfunding or seed funding in the near future to expand your project?
Title: Re: Large Bitcoin Collider Thread 2.0 Post by: rico666 on April 28, 2017, 06:22:13 AM Are you planning any kind of crowdfunding or seed funding in the near future to expand your project? No. I must say, that a crowdfunding project for an ASIC did cross my mind, but down that path is probably more pain than fun, so ... no. At least not within the next 2-3 years? ;) Title: Re: Large Bitcoin Collider Thread 2.0 Post by: Razzoel on April 28, 2017, 07:40:37 AM It would be interesting if you guys could try to recover "burned" coins somehow. That way, the lost coins in the ecosystem won't go to waste.
Title: Re: Large Bitcoin Collider Thread 2.0 Post by: onemanatatime on April 28, 2017, 08:08:02 AM Are you planning any kind of crowdfunding or seed funding in the near future to expand your project? No. I must say, that a crowdfunding project for an ASIC did cross my mind, but down that path is probably more pain than fun, so ... no. At least not within the next 2-3 years? ;) Cool.. will keep an eye on the progress of this project. All the best rico666 ! Title: Re: Large Bitcoin Collider Thread 2.0 Post by: rico666 on April 28, 2017, 09:03:17 AM It would be interesting if you guys could try to recover "burned" coins somehow. That way, the lost coins in the ecosystem won't go to waste. That is the plan. Acually these lost coins are those that will remain unclaimed and these will go sooner or later to the LBC Pot for client disbursement. When Satoshi said Quote Lost coins only make everyone else’s coins worth slightly more. Think of it as a donation to everyone. he forgot to mention the donation being involuntary. So might as well go to Pool members instead of "everyone". Title: Re: Large Bitcoin Collider Thread 2.0 Post by: SopaXT on April 28, 2017, 09:34:32 AM I don't remember if I suggested the below challenge-based proof-of-work system already:
The challenge could be faked if the client stops the calculations after finding the challenge key, but the current client can also be tweaked to send invalid work too. There is a possibility of using multiple challenge keys to make the forging of the work as computationally hard as doing the actual computations. Again, please feel free to correct me and criticize this idea appropriately! Title: New version and other News Post by: rico666 on April 30, 2017, 07:23:19 PM There is a new LBC client version (1.138) available
You can fetch it either manually from https://lbc.cryptoguru.org/static/client/LBC or your 1.067 client will get it - for the last time - from ftp://ftp.cryptoguru.org/LBC/client/1.138-LBC.bz2 (ftp://ftp.cryptoguru.org/LBC/client/1.138-LBC.bz2) All subsequent LBC client and generator updates will be from https://lbc.cryptoguru.org/static/ Moving the source of updates for executables from FTP to HTTPS is also the main change 1.067->1.138 Other changes:
LBC in the News: Another VICE Motherboard 2nd guessing copy: http://forklog.com/bolshoj-bitkoin-kollajder-ugrozhaet-polzovatelyam-vzlomom-koshelkov/ I found only out after the server log started to mention this URL as origin of some accesses. Of course Google Translate suggests, that the usual "never in a billion years" talk is going on in Cyrillic script too. ;) As you can see in the stats (https://lbc.cryptoguru.org/stats) The pool is slowing down, which is because our top-contributor https://lbc.cryptoguru.org/stats/Unknownhostname is shutting down capacities. Without him, the pool has around 200-250 Mkeys/s. (Maybe 400 if _KULME_ starts his monster machine ;)) Therefore my next focus and priority will be again on the generator to squeeze some more speed out of it and also to make it available on more machines. For the time being, I consider all security-related issues resolved and am as of now not willing to participate in any discussion regarding "LBC security", novel proof-of-work suggestions and the like. If you must stretch this topic, please do so in v1 thread or show me some code. Else: 404 Title: Re: Large Bitcoin Collider Thread 2.0 Post by: mrgiacalone on April 30, 2017, 11:27:26 PM Hello rico,
While trying to set up LBC on a Ubuntu VM I ran into the "Benchmark info not found - benchmarking... 'gen-hrdcore-sse42-linux64' not found/executable." issue mentioned in the first thread (https://bitcointalk.org/index.php?topic=1573035.msg16539529#msg16539529 (https://bitcointalk.org/index.php?topic=1573035.msg16539529#msg16539529)). In my case this was probably because of a poor connection on the desktop hosting the VM. The links in the first thread don't seem to work as they are. However, I was able to download the files from the FTP folders using an alternate connection and follow your instructions for the "Clubbed to Death" method.
(i.e. 1170422-433ed5196898900563a5d6dcf7f6a87d.blf.bz2. Extract and rename to funds_h160.blf) After that it was simple enough to get it working. While I wait for the GPU threshold to be reached, I have a question about the GPU process (http://lbc.cryptoguru.org:5000/man/user#gpu (http://lbc.cryptoguru.org:5000/man/user#gpu)). Quote The CPU computes 4096 uncompressed public keys and moves them to GPU The GPU computes 4096 hash160 of this and 4096 hash160 of the compressed equivalents The 8192 hashes are moved back to the CPU which performs a bloom filter search on them. This process is repeated 4096 times before you see a 'o' on your screen, which takes around 8 seconds on modern CPU/GPU combinations. Depending on the speed of the GPU, its load may be low - e.g. just 10% per CPU core. As I understand it, the use of GPU processing capacity may be unused depending on the number of cores the CPU has. Does this mean that running LBC on a multi-GPU rig with only an Intel Celeron Dual Core would not necessarily use all the GPUs capacity? Cheers, MRG Title: Re: Large Bitcoin Collider Thread 2.0 Post by: BurtW on May 01, 2017, 03:01:55 AM I am currently writing a thread related to the the Bitcoin address space and need to know something about your project:
What is the maximum key generation rate you have every recorded, even for a short period of time? Thanks! Please see my related thread here: https://bitcointalk.org/index.php?topic=1895455.0 Title: Re: Large Bitcoin Collider Thread 2.0 Post by: SopaXT on May 01, 2017, 05:02:28 AM Rico, did you see my suggestion above? Please reply, I really want to know if it's applicable.
Title: Re: Large Bitcoin Collider Thread 2.0 Post by: rico666 on May 01, 2017, 07:57:55 AM Rico, did you see my suggestion above? Please reply, I really want to know if it's applicable. No, it's not. It's a variation of what arulbero has suggested further above. To all the problems of your previous suggestion, this adds the problem of scalability to the server (We have - in principle - a 1:many relation between server and clients, and we cannot afford to let the server perform key generation computations). Moreover: Quote For the time being, I consider all security-related issues resolved and am as of now not willing to participate in any discussion regarding "LBC security", novel proof-of-work suggestions and the like. If you must stretch this topic, please do so in v1 thread or show me some code. Else: 404 I have addressed every valid security concern in the LBC client. So far, you have brought nothing to the table of value. No working code, no proof of concept. You have no projects of your own, no track of record , no nothing. You only brought stir to the LBC project. But you consider it somehow (I honestly do not know where you take that self-confidence) legit to demand my attention and even answers. You are in no position for that. Am I being clear? You are this close ----> <------ to my ignore list. Please read and understand in the 1st post of this thread what that means (key phrase is: retro-active). The only thing keeping you from there is, that it could be perceived as martyrdom if I simply kicked you there. But the time nears where I do not care. Your constant gnat buzzing is like a developer DoS and I will not let you swamp me with that. More than anyone else, your contribution to the LBC meritocracy is negative so far. Before I even consider looking at any of your output ever again, you will have to provide some Gods own code or concept of value for the LBC. Including a prototype implementation. Until then: Try to learn as much as you can and should your fingers tickle and urge you to do a writeup: DON'T. Title: Re: Large Bitcoin Collider Thread 2.0 Post by: rico666 on May 01, 2017, 08:14:23 AM alternate connection and follow your instructions for the "Clubbed to Death" method. Yep - that "clubbed to death" method works always - because actually a human is doing what the computer should do. :) Now that I will have more time to spend on usability and infrastructure, I certainly hope to get that automated install more robust and user-friendly. (e.g. biggest problem of FTP updates was, that the LBC client on some installations just sees an empty directory and I have no idea why.) With moving the updates of client and generator to HTTPS, I also am using JSON output from the Nginx server for directory listings (see e.g. https://lbc.cryptoguru.org/static/generators/) which should also help to get the update/install more robust as no brittle output parsing is necessary anymore. This is actually the authoritative source. FTP will be phased out as soon as the last sub-1.138 client is in use. Quote The CPU computes 4096 uncompressed public keys and moves them to GPU The GPU computes 4096 hash160 of this and 4096 hash160 of the compressed equivalents The 8192 hashes are moved back to the CPU which performs a bloom filter search on them. This process is repeated 4096 times before you see a 'o' on your screen, which takes around 8 seconds on modern CPU/GPU combinations. Depending on the speed of the GPU, its load may be low - e.g. just 10% per CPU core. This is not entirely true anymore. The 8192 hashes moving back is not done anymore, the GPU does the bloom filter search now. Also, using a faster ECC (done by arulbero) than what libsecp256k1 provided, allowed the CPU to feed the GPU faster. All in all, the load one CPU core does on GPU is about twice what it was when the quoted text above was written. Quote As I understand it, the use of GPU processing capacity may be unused depending on the number of cores the CPU has. Does this mean that running LBC on a multi-GPU rig with only an Intel Celeron Dual Core would not necessarily use all the GPUs capacity? As of now, this is exactly what it means. I am thrilled to say, that this is actually something I will be working on next and GPU usage/saturation will raise at least by a factor of 2 again in the next couple of ??? (days/few weeks). Title: Re: Large Bitcoin Collider Thread 2.0 Post by: SopaXT on May 01, 2017, 08:52:40 AM Rico, did you see my suggestion above? Please reply, I really want to know if it's applicable. No, it's not. It's a variation of what arulbero has suggested further above. To all the problems of your previous suggestion, this adds the problem of scalability to the server (We have - in principle - a 1:many relation between server and clients, and we cannot afford to let the server perform key generation computations). Moreover: Quote For the time being, I consider all security-related issues resolved and am as of now not willing to participate in any discussion regarding "LBC security", novel proof-of-work suggestions and the like. If you must stretch this topic, please do so in v1 thread or show me some code. Else: 404 I have addressed every valid security concern in the LBC client. So far, you have brought nothing to the table of value. No working code, no proof of concept. You have no projects of your own, no track of record , no nothing. You only brought stir to the LBC project. But you consider it somehow (I honestly do not know where you take that self-confidence) legit to demand my attention and even answers. You are in no position for that. Am I being clear? You are this close ----> <------ to my ignore list. Please read and understand in the 1st post of this thread what that means (key phrase is: retro-active). The only thing keeping you from there is, that it could be perceived as martyrdom if I simply kicked you there. But the time nears where I do not care. Your constant gnat buzzing is like a developer DoS and I will not let you swamp me with that. More than anyone else, your contribution to the LBC meritocracy is negative so far. Before I even consider looking at any of your output ever again, you will have to provide some Gods own code or concept of value for the LBC. Including a prototype implementation. Until then: Try to learn as much as you can and should your fingers tickle and urge you to do a writeup: DON'T. I *do* have projects of my own - SopaXorzTaker on GitHub. If you find it appropriate to take this post to your attention, I should argue with you on the above. Key generation for the challenge is not that expensive. Assuming that your server has ~200 regular clients, and you get a work requests from all of them (which is exaggerated) every second and there's 16 challenge keys per work request, you'd only need 200*16 = 3200 keys per second to be generated, while my machine does ~800 kkey/sec. I feel it necessary to argue, as I think some of your claims are incorrect, such as this one. I'd love to hear your feedback and arguments on that. EDIT: that's not possible as every client has a different work from the server, so the challenge has to be different too. Am I wrong? Title: Re: Large Bitcoin Collider Thread 2.0 Post by: rico666 on May 01, 2017, 09:39:38 AM I *do* have projects of my own - SopaXorzTaker on GitHub. Hm. I see. This is really my final take on it. All subsequent writeups of you in this thread will be deleted unseen. You may as well copy them to /dev/null I'm answering under the theoretical premises your proposed PoW would actually be an unfakeable PoW - which it isn't. Which renders all of this discussion moot. But hey - why not: Quote you'd only need 200*16 = 3200 keys per second to be generated, while my machine does ~800 kkey/sec. You are comparing peas to apples. 800 Kkeys/s incremental key generation compared to 3200 starting keys. For an incremental key, you simply have to do 1/2 of a G addition. For a starting key, you have to do n G multiplications (or additions if you have a precomputed table) where n is the number of 1-bits in your privkey. "your 800k-machine" can therefore do about 6666 starting keys/s in our current entropy range. Nice number, but too low. Also, the LBC server is a VM and there is no chance to get a GPU in there. As of now, the server would be able to cope with around 50 Tkeys/s key generation capacity with no code changes whatsoever. Please build YOUR OWN "LBC Server" project. SHOW me, how it's done by doing it, not by babbling about it. Quote I feel it necessary to argue, as I think some of your claims are incorrect, such as this one. I'd love to hear your feedback and arguments on that. Again, your feeling is based on your ignorance (in this case about the key generation process). I did way more than I should to nurture your attention needs. Now begone. Title: Re: Large Bitcoin Collider Thread 2.0 Post by: Real-Duke on May 01, 2017, 10:37:01 AM Hi rico,
have done the update to the new generator yesterday evening and all went fine over night. Just now I have shutdown the LBC and make the following run: Code: real-duke@C1-Ubuntu:~/gcollider$ ./LBC -u The file "gen-hrdcore-avx2+gpu-linux64" is of course in the LBC directory with rights 777 but now you can see Im unable to start the collider again ( Have a working backup somewhere ;) ) Title: Re: Large Bitcoin Collider Thread 2.0 Post by: rico666 on May 01, 2017, 11:05:52 AM have done the update to the new generator yesterday evening and all went fine over night. Just now I have shutdown the LBC and make the following run: Code: real-duke@C1-Ubuntu:~/gcollider$ ./LBC -u The file "gen-hrdcore-avx2+gpu-linux64" is of course in the LBC directory with rights 777 but now you can see Im unable to start the collider again ( Have a working backup somewhere ;) ) Hm. Nevertheless: Code: > ls -al so I can see what is there and what not. Title: Re: Large Bitcoin Collider Thread 2.0 Post by: mrgiacalone on May 01, 2017, 01:58:42 PM Quote Quote As I understand it, the use of GPU processing capacity may be unused depending on the number of cores the CPU has. Does this mean that running LBC on a multi-GPU rig with only an Intel Celeron Dual Core would not necessarily use all the GPUs capacity? As of now, this is exactly what it means. I am thrilled to say, that this is actually something I will be working on next and GPU usage/saturation will raise at least by a factor of 2 again in the next couple of ??? (days/few weeks).Thanks for the reply. At the moment I have a 6xGPU rig with a dead mobo/cpu that I will be splitting into two 3xGPU rigs. I intend on using one of them for new mining projects (of the like of LBC), so I'll be checking your updates (for the next days/few weeks) to do some testing on multi-GPU rigs. (Hopefully I'll get my GPU auth flag ready as well with my CPU). My main interest is on the performance with this low CPU high GPU combination, which are very common in GPU rigs at the moment. Quote As you can see in the stats The pool is slowing down, which is because our top-contributor https://lbc.cryptoguru.org/stats/Unknownhostname is shutting down capacities. Without him, the pool has around 200-250 Mkeys/s. (Maybe 400 if _KULME_ starts his monster machine Wink) Therefore my next focus and priority will be again on the generator to squeeze some more speed out of it and also to make it available on more machines. Perhaps this will also be a good time to increase incentives to a broader range of contributors to reduce dependence on fewer of them. MRG Title: Re: Large Bitcoin Collider Thread 2.0 Post by: shortcircuit on May 01, 2017, 02:06:33 PM have done the update to the new generator yesterday evening and all went fine over night. Just now I have shutdown the LBC and make the following run: Code: real-duke@C1-Ubuntu:~/gcollider$ ./LBC -u The file "gen-hrdcore-avx2+gpu-linux64" is of course in the LBC directory with rights 777 but now you can see Im unable to start the collider again ( Have a working backup somewhere ;) ) Hm. Nevertheless: Code: > ls -al so I can see what is there and what not. Already posted in the german section. Here's the ouput of ls -al Quote drwxr-xr-x 2 bert bert 4096 May 1 14:40 . drwxr-xr-x 4 bert bert 4096 May 1 12:25 .. -rw-r--r-- 1 root root 48076 May 1 14:40 diagnostics-LBC.txt -rw-r--r-- 1 root root 536870912 May 1 14:23 funds_h160.blf -r-xr-xr-- 1 root root 199200 May 1 14:19 gen-hrdcore-generic-linux64 -rwxr-xr-x 1 root root 63819 May 1 13:50 LBC Title: Re: Large Bitcoin Collider Thread 2.0 Post by: rico666 on May 01, 2017, 02:37:42 PM Can't exec "gen-hrdcore-avx2+gpu-linux64": File not found yadda Temporary fix: Code: export PATH=$PATH:. edit: Version 1.140 on Server which does not need this workaround. Problem was only in "LBC -x" - not in normal operation. Title: Re: Large Bitcoin Collider Thread 2.0 Post by: SopaXT on May 01, 2017, 04:26:00 PM Rico, he's running it on a machine named "Ubuntu-C2", which suggests of it being an ODROID-C2. That's an ARM single board computer and LBC is not going to run on it.
Title: Re: Large Bitcoin Collider Thread 2.0 Post by: rico666 on May 01, 2017, 04:39:35 PM Rico, he's running it on a machine named "Ubuntu-C2", which suggests of it being an ODROID-C2. That's an ARM single board computer and LBC is not going to run on it. I see "C1-Ubuntu", which I would now intuitively translate to "Collider1-Ubuntu". Given the fact that he is running a GTX1060, I seriously doubt he has an ARM board below that. Given another fact, that the LBC client has recognized AVX2, I would be very interested to see an ARM with avx2 features. As mentioned, the problem was that "LBC -x" did not start the generator explicitely with the "./" current path prefix. It's fixed in 1.140 Title: Re: Large Bitcoin Collider Thread 2.0 Post by: Real-Duke on May 01, 2017, 06:16:43 PM LOL nice rumours about my hardware ;D
C1 is my Intel Standalone PC and C2 is my little AMD Notebook...both are no ARM Systems as far as I know ;) "C" means nothing more than "Computer" in this case. Title: Re: Large Bitcoin Collider Thread 2.0 Post by: Real-Duke on May 01, 2017, 07:40:55 PM edit: Version 1.140 on Server which does not need this workaround. Problem was only in "LBC -x" - not in normal operation. Hmm but ./LBC -x still gives an error here! Starting with ./LBC seems to work...but correct way? Code: real-duke@C1-Ubuntu:~/gcollider$ ./LBC -u Title: User MetaLynx -> please PM me Post by: rico666 on May 01, 2017, 08:29:09 PM or mail: bots@cryptoguru.org
There's something weird going on with your 1.067 client edit: server put your client in blacklist, contact me for clarification. Title: Re: User MetaLynx -> please PM me Post by: MetaLynx on May 02, 2017, 03:29:20 PM or mail: bots@cryptoguru.org There's something weird going on with your 1.067 client edit: server put your client in blacklist, contact me for clarification. Yeah, I noticed I was blacklisted, but was heading out the door on the way to work and didn't have a forum account or time to start playing fiddlesticks trying to figure out why, also I was hoping it would just fix itself by the time I got home. So what happened? I was a mere few hundred G/Keys from top 30 and then bam rico shells into my computer and sabotages me so that I have to start all over! I knew it! lol. But in all fairness it could have possibly also been several other factors. I have it running in the background on an arch antergos box. At the time I was doing an update that affected like 300+ items, while also finding random new programs, and while the LBC was running in the background. So maybe a dependency was updated while it was running, I think some nvdia things got changed, maybe those? idk. Title: Re: Large Bitcoin Collider Thread 2.0 Post by: Real-Duke on May 02, 2017, 04:56:57 PM All sorted out, tonight Im back ON ;)
Time = 7 for testing... Code: real-duke@C1-Ubuntu:~/gcollider$ ./LBC -x Title: Re: User MetaLynx -> please PM me Post by: rico666 on May 02, 2017, 07:52:55 PM Yeah, I noticed I was blacklisted, but was heading out the door on the way to work and didn't have a forum account or time to start playing fiddlesticks trying to figure out why, also I was hoping it would just fix itself by the time I got home. So what happened? I was a mere few hundred G/Keys from top 30 and then bam rico shells into my computer and sabotages me so that I have to start all over! I knew it! lol. I have no interest in sabotaging you. Why should I? Your client is in blacklist, because there were some weird things going on. I would like to find out what. Blacklist doesn't necessarily mean you would have to start all over. But I would like to discuss what went on in private 1st - for analysis. I have never seen a client behave like that before, so naturally I'd like to find out what happened. PLEASE -> bots@cryptoguru.org It may very well be that it's all my fault and the program just misbehaved because of some unforeseen hardware error or whatever. I just don't know yet. Quote But in all fairness it could have possibly also been several other factors. I have it running in the background on an arch antergos box. At the time I was doing an update that affected like 300+ items, while also finding random new programs, and while the LBC was running in the background. So maybe a dependency was updated while it was running, I think some nvdia things got changed, maybe those? idk. Ah! Please let's discuss this via mail, I'll put in a summary here for the interested - of course. edit: So with the little information you provided (and no further discussion), I solved this on my own... After your client got the interval 4942213231-4942216430 to work on - and while it ran - you started a system update, probably including update of the drivers for the GPU, system libraries and what not. This is a plausible explanation for what I saw on my end: This made the client go haywire and it answered to validation challenges with a bunch of errors (namely tampered BLF file, execution time, etc.) I removed the last two intervals your client worked on from your delivered valid Gkeys (6400 Mkeys = 6.4Gkeys) and janitored (= recomputed) them with my client. I will move your Id from blacklist now, but please and that is @ALL: Do not perform extensive system upgrades while the client is running. I mean if you exchange the GPU-driver while the GPU is computing - what do you expect to happen? Title: News Post by: rico666 on May 10, 2017, 08:34:58 AM So for those who do not monitor the News (https://bitcointalk.org/index.php?topic=1877935.msg18665920#msg18665920) link in my signature, here the "more important" news.
Claiming Finds: Tomorrow it will be 6 months since our 1st find (https://lbc.cryptoguru.org/trophies) went into custody. Quote 2016-10-11 03:00:34 GMT The pool found a private key to f6cc30532dba44efe592733887f4f74c589c9602 (1PVwqUXrD5phy6gWrqJUrhpsPiBkTnftGg) as 0x22306e3f1a72. At the time of the find, there were 0.007899 BTC on that address.The funds were transferred to custody at 16cFBcM27DGriyvz5i8SLmd8n5ai8hCTEE. See the announcement and the modalities of the return of the funds to their rightful owner here. As no one came along to reclaim these funds, they will be moved to the LBC Pot (https://blockchain.info/address/1LBCPotwPzBvBcTtd7ADGzCWPXXsZE19j6) adding some $13 to the currently present ~$195. *crowd cheers* New generators: Kardashev In the next few days, I will roll out our next generation of generators (sounds nice - eh?) called "Kardashev". The predecessor "HRD (https://en.wikipedia.org/wiki/Hertzsprung%E2%80%93Russell_diagram)-core" served us well, but in order to break new ground, we needed to make extensive changes which made the resulting generator not just a newer version of HRD-core: Unified binary Mainly, the new generators will already have support for GPU computing, it will be on the client to evaluate "GPU-Auth" and start the generator with the appropriate options. This will reduce the number of binaries we have to maintain/juggle (no +gpu versions anymore). You can see the generators already appearing on our update URL (https://lbc.cryptoguru.org/static/generators/). In order to have a seamless upgrade, please make sure you run at least LBC client version 1.140. Because the new generators are all linked against libOpenCL, you have to make sure you do install OpenCL on your machine - even if you use only the CPU version or have a VM. If you were already running a GPU client, you do not need to do anything. If you are on a VM or even intend to run only CPU clients, you still have to install OpenCL. Luckily, you can install some dummy OpenCL package like https://apps.ubuntu.com/cat/applications/ocl-icd-libopencl1/ or the Mesa OpenCL or whatever (feel free to install the Nvidia, AMD ones if you intend to use that Hardware later on) - just make sure a libOpenCL.so is on your system. HW support: Reducing the number of binaries we have to juggle while improving the release cycle (testing & automation), allows us to extend the support for various other nice devices out there. Take for example Intel Goldmont (https://en.wikipedia.org/wiki/Goldmont) a.k.a. Apollo Lake a.k.a. Pentium/Celeron WTF. These nifty little CPUs do have hardware support for SHA256! And some even niftier ARM CPUs do also (https://github.com/noloader/SHA-Intrinsics)! So yeah - we intend to support that. Your little settop box may actually perform a formidable search for BTC keys while you are watching a movie (of course without disturbing the movie). Speed: As of now, Kardashev generators are only slightly faster than HRD-core. While there is nothing spectacular as of now, make no mistake: We just left a local optimum (http://www.lindo.com/doc/online_help/lingo15_0/local_optima_vs__global_optima.htm), went through some performance valley and are releasing the new generators while climbing up the next performance mountain, just about the height of the last peak. Understood? In terms of efficiency, already the current versions of HRD-core are the best key generation (and checking) software out there. With Kardashev, we intend to take the game to a whole new level. Doubling the speed seems realistic now. We do already have faster prototypes running here... About: Oh - and about the name (https://en.wikipedia.org/wiki/Kardashev_scale). Kardashev is of course some tribute to our anglo-saxonian friends. I wouldn't mind to call the binary Kardašov, or Kardaschow or Кapдaшёв, but some people might have trouble with their keyboard. As for why this name has been chosen: It was an idea sketched out by Ryan Castellucci some months (~10) ago, in reference to the nice but pathetic picture of the sun (https://miguelmoreno.net/wp-content/uploads/2013/05/fYFBsqp.jpg). Other than that, it should be self-explanatory why the name has been chosen. ;) Title: Kardashev rollout Post by: rico666 on May 12, 2017, 05:04:03 PM Your client may update to version 1.165 on the next startup
Code: GPU authorized: yes and then fetch a "kardashev-xxx" generator, where xxx stands for a CPU architecture which can be seen in ascending order of new instruction support: 'generic' < 'nehalem' < 'westmere' < 'sandybridge' < 'haswell' < 'skylake' these correlate somewhat with specific instruction sets the compiler has optimized to. (Like AVX is supported by sandybridge, AVX2 by haswell etc.) Don't worry if you have an AMD CPU: the right binary for your CPU should be chosen and in case it shouldn't, the 1.165 client has a new option: --override <gentype>|? Override the LBC generator choice. You get a list of valid generators when giving '?' as argument. So just do a --override generic if you get a "illegal instruction" error or just try the "next lower" binary. As for speed, the kardashev-generators should be about 5% faster than the old HRD-core generators. While that's not spectacular, it can be 1 Mkey/s (or more) if you had 20 Mkeys/s (or more) - which is pleasant nevertheless. Title: Re: Large Bitcoin Collider Thread 2.0 Post by: Real-Duke on May 12, 2017, 07:01:03 PM Thanks for your effort, going to give it a try now! 8)
Title: Re: Large Bitcoin Collider Thread 2.0 Post by: rico666 on May 12, 2017, 09:34:50 PM Thanks for your effort, going to give it a try now! 8) Looks like it's working ;) https://lbc.cryptoguru.org/stats/RealDuke Title: Re: Large Bitcoin Collider Thread 2.0 Post by: Real-Duke on May 12, 2017, 10:09:16 PM Thanks for your effort, going to give it a try now! 8) Looks like it's working ;) https://lbc.cryptoguru.org/stats/RealDuke Yep and even a little faster now like announced ;) Code: ./LBC Compared to ~20.51 MKeys/s before 8) Title: Re: Large Bitcoin Collider Thread 2.0 Post by: SlarkBoy on May 13, 2017, 06:58:05 AM Can't run 2nd GPU.
Code: root@......:~/LBC# ./LBC .................. --gpu --cpus 10 --time 20 --delay 600 -gdev 1 PC specs i7-6950X 2x GTX 1080 Ti Title: Re: Large Bitcoin Collider Thread 2.0 Post by: rico666 on May 13, 2017, 08:25:25 AM Can't run 2nd GPU. I'll have a look. Meanwhile I can confirm that the new kardashev generators also run well on WSL (a.k.a. Ubuntu Bash on Windows) as long as you simply install a default OpenCL: http://packages.ubuntu.com/xenial/ocl-icd-libopencl1 (The Ubuntu on WIndows is Xenial). To be clear: It will still only allow you to run the CPU-only generator, but as the binary wants an OpenCL library to be present, the ocl-icd-libopencl1 installation satisfies that requirement. Title: Re: Large Bitcoin Collider Thread 2.0 Post by: Hamukione on May 13, 2017, 02:02:32 PM Nice to see this is still going on.
Finally back after a long break and busy times. Might be time to start up the server again and see what a nVidia Quadro card can do. I know I did around a million keys pr sec with the cpu alone. Title: Re: Large Bitcoin Collider Thread 2.0 Post by: SlarkBoy on May 13, 2017, 02:37:08 PM I'll have a look. Meanwhile I can confirm that the new kardashev generators also run well on WSL (a.k.a. Ubuntu Bash on Windows) as long as you simply install a default OpenCL: http://packages.ubuntu.com/xenial/ocl-icd-libopencl1 (The Ubuntu on WIndows is Xenial). To be clear: It will still only allow you to run the CPU-only generator, but as the binary wants an OpenCL library to be present, the ocl-icd-libopencl1 installation satisfies that requirement. Ok good. Now both GPU working. Title: Re: Large Bitcoin Collider Thread 2.0 Post by: rico666 on May 13, 2017, 03:26:43 PM Nice to see this is still going on. Finally back after a long break and busy times. Might be time to start up the server again and see what a nVidia Quadro card can do. I know I did around a million keys pr sec with the cpu alone. Ah! My most devotee minion is back. ;) You will be pleased to hear, that the CPU should be able to do about twice as much now and with the GPU acceleration a x6 or x7 speedup on top of that. Meanwhile there are people with 150+ Mkeys/s machines. If they only kept them running. 8) Title: Re: Large Bitcoin Collider Thread 2.0 Post by: Hamukione on May 13, 2017, 03:39:06 PM Hehe, its good to be back Master.
I am currently fixing my friends PC, but will be done with that later tonight.. I hope your GPU version supports my Quadro. Could be fun to see what its able to do. Will spin the server up later. Title: On LBC Feasibility Post by: rico666 on May 15, 2017, 10:20:21 AM Recently I read another masterpiece on LBC feasibility:
https://breadwallet.com/blog/large-bitcoin-collider/. As tweets are not the right medium to transport all the information about what's wrong with this, let's look at it here: First, I would like to state that I agree with the headline "LBC poses no threat to Bitcoin". Of course I agree for a completely different reason than the usual - wrong - grade school arithmetic exercises also presented in the breadwallet blog. You must know, there are already quite some of these texts and they all fall into the same template category
There are many examples: https://bitcoin.stackexchange.com/questions/22/is-it-possible-to-brute-force-bitcoin-address-creation-in-order-to-steal-money Quote Supposing you could generate a billion (230) per second plus like 100 threads on bitcointalk.It has been fun watching these pamphlets, but it's getting boring. Moreover, it's getting sad that such texts still seem to meet the appreciation of a nodding flock. So - sorry Aaron Lasher, please don't take it personally - I feel I have to start beating up these pamphlet-generators. By argument ofc. The author of the article is CMO (I guess that's Chief Marketing Officer), and claims to have studied Math and Psychology at least to the BA-level. I take that as a given and send my compliments for the nice share of psychology in the text. I also do not take his text personally, because his aim certainly wasn't to badmouth LBC, rather than to calm down worried users. The Mishaps If you are Chief Marketing Officer for a Bitcoin Business, you should have your numbers right. Especially those numbers that are important if you want to act as a proponent to Bitcoin. Such as the number of addresses with funds on them. You know - this number says something about the adoption of Bitcoin and naturally you want to make the adoption rate look good. If you - as a CMO - claim there are 5M addresses at a time when there are 16.1M addresses with funds on them, you're not doing a good CMO job. Of course marketing people get the benefit of the doubt as being tech-unsavvy so I take all the occasions where Aaron didn't get the numbers right as non-intentional. He simply didn't know better rather than tuning them for a purposeful deception. E.g. when claiming that the address 1G1W1DbeUeH2AKKicqMNuhEuaoqPDNuXDF represents the number 4,036,794,190,046,444,310,490,975,774,115,813,708,619,807,673,368,708,224,110 Or when mixing up keys and addresses. Or when mixing up the BTC-network hashrate (SHA256d) with the key-generation (ECC+hash160). Or ... you get the idea The Spaceship Before I dissect his calculations, let's take a step back and look at his premises. Representing the search space, there is a chess board with an edge length of quite some light years. Arbitrary squared. He also uses inches instead of a metric norm. :) There is a "Spaceship" - capable of travelling with the speed of light and still not being able to cover any significant part of the chess board. This is the outrageous part. We all know mankind is still unable to reach anything near the speed of light and except for some hardcore sci-fi fans (probably even these), most take that as a given. To make things even more plain, this spaceship is left in the dust by some super-spaceship (equivalent to the Bitcoin network) which is about 312 million times faster than the speed of light. Even this super-spaceship will need 2.25 quadrillion years (2,250,000,000,000,000) to find - allegedly - an address with funds on it. Phew. Impossibru! Yep! LBC poses no threat to Bitcoin. q.e.d ... Or does it? The Fallacies Before I even go into the details, let's take a look at the most evident craftmanship error Aaron made: The number of addresses with funds on them. 16.1M compared to his 5M. Let's be generous and assume only a factor of 3 (when it's 3.22, and we'll see that decimal places do matter) he was off. Let alone this folds his 2.25 quadrillion years to 0.75 qn. We saved a whopping 1.5 quadrillion years! MAGIC! Now if you are not taking the same drugs as creationists do, you will assume our universe is a mere 13.8 bn years old. So you consider 0.75 qn years equally irrelevant. Well, the message should have been the 1.5 qn years off, but now that we found such a big ... hmmm ... rounding error, let's look at the calculations in more detail: Aaron got it right that we do not need to have a look at all 2256 bits, but a mere 2160, he divided the latter with his 5M addresses (should have been 16.1) to get the space "until 1st hit". Hm. Is the search space even right? Aaron unfortunately is constantly mixing up "private keys" and "addresses", even more so that he sees a 1:1 relation between these. Now if the LBC had it's own CMO pet, it would present the pool rate in MAddrs/s instead of Mkeys/s, because that number would be twice as big. You remember: the LBC is looking at both uncompressed and compressed addresses. What does that mean? Well (if we leave the advanced math discussion aside), it means we should be able to look only at 2159 private keys in the 1st place. "Bah! 1bit", I hear you say. Yep - 1bit. This 1bit means halving of the search space. So 2159/16.1M and we are at almost 362 tn years search time instead of our 2.25 quadrillion years. Holy sh*t that's some difference. But wait - that's still the search time for our super-spaceship. Nothing will ever go with 312 million times the speed of light! Well - the bitcoin network does evidently - at least in this crude comparison. "Going with the speed of light" - in the text above would translate to a key generation rate of 5.9 Gkeys/s for the LBC. So far, we had a peak of 2.5 Gkeys/s, so something above 0.4c, so we're at least doing better than NASA. Oh - and this keyrate was 90% contributed by a single man. With CPUs. LBC - as is, i.e. with no code change - could handle about 50 Tkeys/s, so 8474 times the speed of light according to Aarons magnificent universe. So it's important to know, that the "speed of light" in the breadwallet-text is a mere psychological trick. If you convert it into some real-world keyrate (5.9Gkeys/s) it certainly loses some of it's mystical aura. Moreover, the constant (not even linear) nature of the comparison becomes apparent. As if the LBC was to remain at a certain keyrate for "quadrillions of years". Gimme a break! What's really going on? For now, LBC is mainly an engineering task and a little bit of a mathematical task. The math will become more and more important should we hit some engineering barriers. There are no barriers in sight for the near future. LBC is still a baby project both in terms of code maturity as well as in terms of size. There are like 20 clients contributing. Twenty! Judging LBCs impact on Bitcoin based on it's current state is like judging Bitcoins impact on global economy based on its current state. You have to do a lot of extrapolation and you should know that you are bad at it. Let me be more specific: All the calculations in texts like the one I'm answering to are bullshit. The "super-spaceship" with its 4 Exahash/s is a mere 8 years old. You cannot possibly make a calculation showing this instance will take xxx quadrillion years to search. How fast will the hashrate be in another 8 years? No one knows. Neither do I, nor does Aaron. Except I don't claim I do know. How fast will the key generation rate of LBC be in 8 years? No one knows. Neither do I, nor does Aaron. It may be 0, it may be way more than 4EKeys/s or it may be something in between. If 8 months ago someone told me, that the LBC would cover 1 million pages on http://directory.io/ per second, checking every single address listed there against 15+M addresses with funds on them and that this speed would be considered really slow (it's what we currently have), I would think of him being a crackpot. If I was to make such claims when LBC started (with its 150 Kkeys/s), I would probably have had earned the "crackpot" title myself. Our software is meanwhile more than 400 times faster than it was 8 months ago. The hardware available today is on average 50% faster than it was 8 months ago. In 8 years? Well, you will get a high-end Volta GPU on eBay for $50 (probably less), so I assume 1Gkeys/s per user will be the low average. When my notebook delivered about 1.5Mkeys MORE with the new kardashev generator a couple days ago, it was not even thrilling anymore. "1.5Mkeys/s. Hm. So what?" 8 months ago, this would have been 10 times the total pool capacity. But ... but .... But exponential! Yes, Bitcoin uses exponential functions for its protection. It can throw up to 2224 difficulty at the miners, or up to 2160 search space at the searchers (Yes: LBC pool participants are "searchers"). But that's it. The 160 and 224 as you can see are finite numbers. That's no infinite exponential function. And our spaceships are also getting exponentially faster. Don't forget that - should you once again feel the urge to write up a text like the one I'm answering. Do not fall prey to the "I think of some outrageous premise and then perform various equivalence calculations on it". Because if you do, you may end up with a nice picture of the sun, or a space-ship, or digging the Mount Everest, or any other mathematical vomit. Your only achievement will be the generation of a text containing not even a linear extrapolation, but a constant extrapolation based on seemingly outrageous premises. If you must, just assume the speed of key generation gets doubled every year and see with how many quintillion years search time you'll end up with. Doubling? Every year? Impossible? I would not be surprised if the superposition-units in regular off-the-shelf PQCs in 25 years will be able to perform a search of 264 keys per second. Of course by then - if BTC still exists - it will have migrated to novel post-quantum standards. The question remains what will happen to all the lost and forgotten BTCs until then. On Profitability LBC is not a commercial project and it does not promise any gains. Still, there may be a profitability aspect to it. At the current difficulty, your CPU would have to search for 10653936 years to find a block (12.5 BTC+fees) 11645110 years for the estimated next difficulty, due in 8 days. You see the difficulty is rising way faster than you can cover with time. => You will never find a block solo-mining with your CPU anymore. When searching addresses, there is no rise in difficulty, quite the contrary, the more addresses there are in use, the easier it becomes to find one. Is there a specific BTC difficulty when searching becomes more "profitable" than mining? Of course. Also, the mining-difficulty cannot be looked at without a block reward. If LBC would not evolve any further - i.e. software to remain at same speed - by 2036 it would be theoretically more profitable to search for BTC addresses with your CPU than to mine blocks (with your CPU). (For this calculation, you have to extrapolate the difficulty, the number of addresses in use and take the BTC/block reward into account and we're talking trillions of years) https://en.bitcoin.it/wiki/Controlled_supply Should BTC value continue to rise, I assume that long before this date - not later than 2030 - it may become financially interesting to search for "old forgotten BTCs on P2PKH addresses" (because by the time we certainly will have other types) than to mine new ones. This is the latest date when Chinese ASIC manufacturers will start to provide Keygen-ASICs. There may be a 1 million BTC search incentive. It remains to be seen, if the BTC community agrees to "invalidate" these old BTC addresses before anyone can find them or how much these will be worth by 2030. If you think 2030 is a long way to go, you should stop talking about "quadrillions of years" because it does not suit your event horizon. Title: Re: Large Bitcoin Collider Thread 2.0 Post by: Hamukione on May 15, 2017, 01:28:03 PM That... Was an interesting read.
Only made me want to know more about this than before. If you can make a list of hardware that could be "fun" to play with then I can scavenge and maybe find most of it to you. I want to learn more master... xD Title: Re: Large Bitcoin Collider Thread 2.0 Post by: SopaXT on May 15, 2017, 02:34:11 PM Hey, I think I have an idea for a pool search project (but it would require rewriting the client a bit): Searching for P2SH puzzles.
There have been multiple P2SH scripts which consisted of only one opcode (byte), likely made as a challenge. I think that with the pool speed, we'd easily find some longer scripts which can be spent (if they were created, of course). What do you think? Title: Re: Large Bitcoin Collider Thread 2.0 Post by: rico666 on May 15, 2017, 02:45:17 PM Searching for P2SH puzzles. There have been multiple P2SH scripts which consisted of only one opcode (byte), likely made as a challenge. I think that with the pool speed, we'd easily find some longer scripts which can be spent (if they were created, of course). What do you think? It's in the pipeline. We currently have the "problem" of not being able to put enough load on GPUs. There are some tweaks to the generator we'll have to do 1st, but a GPU-only P2SH search for filling idle GPU capacity is in the mental incubator already. I have been made aware, that P2SH addresses actually are probably even more susceptible to collision attacks than P2PKH - and very GPU friendly, with basically zero ECC requirements. I am not sure if that is considered a collision also, but if we end up with a P2PKH hash160 from a P2SH process and vice versa - it could be considered a collision IMHO. So yes - it will be done eventually. Title: Re: Large Bitcoin Collider Thread 2.0 Post by: rico666 on May 15, 2017, 03:01:13 PM If you can make a list of hardware that could be "fun" to play with then I can scavenge and maybe find most of it to you. I want to learn more master... xD For now, I also want to learn more. E.g. about GPU programming, especially OpenCL. While the OpenCL code in LBC is actually faster than the one in OpenCL-vanitygen, it seems it is still far below it's potential. If hashcat (https://hashcat.net/hashcat/) benchmarks are to be believed, my low-mid-range GPU should be able to perform at least 270 Mega-hash160 per second!!! (compared to the current LBC implementation: 46 Mega-hash160 that put around 85% load on it) And we're talking regular hash160 = RMD160(SHA256(x)), not the tuned Bitcoin-hash160 (where you have fixed input sizes for SHA256 and a very restricted input size for RMD160, both resulting in significant speedup of the code - which we use.) In short: Although we have problems to put load on GPUs, it looks like the GPU would be able - with the correct programming - take 10times more load than we currently expect. We're not using the GPU vectorization capabilities at all :-( I thought about asking some professionals for help https://streamhpc.com/development/making-the-release-version-of-prototype-code/ but I'm afraid of the cost... Title: AWS GPU Instances Post by: rico666 on May 15, 2017, 09:21:51 PM Uh ::) - finally commanding AWS GPU hardware:
Code: ubuntu@ip-172-31-42-141:~/collider$ ./LBC -x -gpu As with everything Amazon: Assume just the half of what they promise. They say you have 32 vCPUs? Assume you have only 16. Their GPU hardware says max worksize 1024? Guess what... I'll make a new kardashev-haswell capable of running on AWS. Please don't tell Unknownhostname or we're screwed. ;D edit: p2.8xlarge ~90 Mkeys/s - the sharp spike you can see in the stats from 2017-05-16 - 2017-05-23 edit2: more convenience - no separate LBC startup for multi-GPU operation Code: root@ip-172-31-39-222:~/collider# ./LBC -c 32 -gopt dev=1-8:lws=512 Title: Re: Large Bitcoin Collider Thread 2.0 Post by: SopaXT on May 17, 2017, 11:50:26 AM I am not sure if that is considered a collision also, but if we end up with a P2PKH hash160 from a P2SH process and vice versa - it could be considered a collision IMHO. So yes - it will be done eventually. That still means the same RIPEMD-160 hash, so yes. Title: Re: Large Bitcoin Collider Thread 2.0 Post by: Hamukione on May 17, 2017, 08:20:31 PM Anyone that got some spare time that wants to fiddle with my machine?
I am a retard to Linux and cant get this thing going on my "server" with an i7 920 on. Will run 24/7, with a quadro 4000 when I earn my GPU auth xD Title: 1.174 is out Post by: rico666 on May 18, 2017, 06:59:07 AM New version of the client is available. Generators have also been updated to accept "GPU worksize" parameter.
Biggest changes:
This is only of interest for people with multi-GPU setups or those who want to run LBC on Amazon GPU Instances, almost everyone else (*) will not need the new features. LBC will now distribute the workload to all given CPUs and GPUs in a balanced way. In previous versions, you had to start up a separate LBC client with -gdev X parameter for every GPU you had. No more. Assume you have 4 GPUs and 32 CPUs. LBC will assign 8 CPUs to each GPU: ./LBC -c 32 -gpu -gopt dev=1-4 Or you have 32CPUs and 8 GPUs and are on Amazon: ./LBC -c 32 -gpu -gopt dev=1-8:lws=512 Assume you would like to distribute the work of your 16 CPUs only to GPUs 1,3,5,7 ./LBC -c 16 -gpu -gopt dev=1,3,5,7 So the old -gdev X parameter is gone and replaced by the more generic (and more complex) gopt parameter. If you have just one GPU, you do not need to care about all this. (-gopt dev=1 is default) BTW: dev=1-4 isthe same as dev=1,2,3,4 or dev=1,2,3-4 etc. just shorter. dev=1-2 and dev=1,2 are also equivalent (*) there may be one exception, if you have old GPUs and get a "CL_OUT_OF_RESOURCES" error. In this case, you could try -gopt with lws=X where X is 512 or 256 or 128 or 64 Title: Fun with gopt Post by: rico666 on May 19, 2017, 04:11:49 PM Originally, I intended to make sure in -gopt dev=x,y,z (see above) each device is given just once. I was enthusiastic about AWS support so I pushed the release out sooner than I had implemented that filtering.
Turns out, its a feature! :D Normally gopt dev=x,y,z distributes CPU processes evenly on the given GPU devices. But what if you had two GPUs in your system where one was faster than the other? You would not want both to get the same share of work. Or you have two same GPUs on your system, but one is for your Desktop and you want to put a lower load on this. Normally you would have to start - again - a separate LBC process for each GPU to achieve non-symmetric workload. Not with our feature. ;) Assume GPU 1 has only 2GB VRAM and GPU 2 has 4GB VRAM. Naturally this limits the number of processes that can run on 1, but why should we constraint GPU 2 because of this? Assume you have 10 cores to fire on the GPUs and you want to have 3 on GPU1 and 7 on GPU2. Solution: -c 10 -gopt dev=1,1,1,2,2,2,2,2,2,2 Now that's an extreme example where we basically had to enumerate all CPU processes explicitely for their GPU assignment. What if we simply have two 1080 (plenty of vram) and would like to assign 12 of our cores in a 1:2 ratio to both these GPUs? Solution: -c 12 -gopt dev=1,2,2 Now GPU1 gets 4 processes, GPU2 gets 8 processes. 1:3 ratio? Simple: -c 12 -gopt dev=1,2,2,2 GPU1: 3 processes, GPU2: 9 processes So I like that feature very much and will keep it as is. I intend to develop -gopt further. As is, it accepts dev and lws "subparameters". Each subparameter is delimited by ":". Another sub-parameter in future may be: Nope. nobloom=<devs> with the possibility to declare a set of devices which shall not use on-GPU bloom filter check. I have not yet decided about implementing other GPU features to be optional. Title: Brittle, unoptimized, in short: shitty code ... Post by: rico666 on May 25, 2017, 11:00:45 AM and still: 30.958 seconds on 1 CPU core for 2 x 10 x 224 keys.
(10.8 Mkeys/s per core) GPU load about 40% higher than before. That's nearly a doubling of the speed! :) The hashes 0c96c911f51bee4250b3d2a2b86b8853fb8c5830 and 82bf3725df95cd4260b003d21063a1b85a66ab21 from the test below (are the symmetric siblings of what we compute now) are fromhttp://www.directory.io/904625697166532776746648320380374280100293470930272690489102837043110636675 where I use 1CvKupTzRqsDi5Zf4QdbVYhmaQUkF667hM (82bf3725df95cd4260b003d21063a1b85a66ab21) and 129Zk4KrdjCtTkPDKDA9yKEoyQMKg7nnY4 (0c96c911f51bee4250b3d2a2b86b8853fb8c5830) for testing. Privkey shown is still wrong, should be e.g. 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364140-0x35 instead of 0000000000000000000000000000000000000000000000000000000000000001+0x35 but that's cosmetics. Code: $ make test So why is it brittle, unoptimized and still shitty? The symmetry computation is still done @ CPU and while it's no big deal (256bit subtraction), we want to get load from CPU to GPU - right? So I'll do that before I release it. Also, there are still lots of optimizations missing, so I am quite confident to be able to achieve a per-core rate more like 5.8 Mkeys/s * 2 (~11.6 Mkeys/s per core) -> 23.2 Maddrs/s per core with around 25% GPU load per CPU core on my machine. So watch out, next release will give you GPU users a nice speed bump. edit: 11.9 Mkeys/s per core now (shittyness levels bearable - symmetry computation on GPU already) ... time to make a release. Title: Re: Large Bitcoin Collider Thread 2.0 Post by: BitcoinUKmedia on May 27, 2017, 11:02:20 PM Such an interesting project. Could the collider be applied to alts with smaller market caps and fewer address?
Title: Re: Large Bitcoin Collider Thread 2.0 Post by: rico666 on May 28, 2017, 07:42:30 AM Such an interesting project. Could the collider be applied to alts with smaller market caps and fewer address? In principle yes, but fewer addresses = less hit probability (I assume with "fewer addresses" you mean those in use/with funds) Also, the size of the codomain (https://en.wikipedia.org/wiki/Codomain) (the number of possible addresses) of the address generation process is an important parameter. The only reason why I started this in the 1st place, are Bitcoins' 160bit (for both P2PKH and P2SH) which I believe will show being insufficient within a couple of years (contrary to what "educated" guesses may say). An almost 1:1 Litecoin-collider could be done, obviously, because Litecoin is an almost 1:1 Bitcoin clone. ;) I have not looked into the other alts too much, but from what I have seen e.g. at Monero, a collider would be really futile there. Title: Re: Large Bitcoin Collider Thread 2.0 Post by: SopaXT on May 28, 2017, 03:45:49 PM Ethereum seems to be held together with band-aids. I am sure that there must be some bad private keys as it's an emerging technology with lots of bad implementations, and actually an Ethereum address is just hex(Keccak256(pubkey)[12:]), where pubkey is an ECDSA public key, which is represented as 32-bytes for x and 32 bytes for y (just the good old uncompressed public key with the first byte removed) - also easy to calculate and to make a bloom filter for.
Title: Re: Large Bitcoin Collider Thread 2.0 Post by: killyou007 on May 30, 2017, 07:53:19 AM hi @rico666
i am trying to run LBC client on amazon ec2 p2.16xlarge (64CPUs with GPU) but getting an error like GPU authorize: no it's working only on cpus i installed all compatible drivers and there is no issue from hardware. what would be the issue? thanks in advance... regards, Killer King Title: Re: Large Bitcoin Collider Thread 2.0 Post by: rico666 on May 30, 2017, 08:42:12 AM i am trying to run LBC client on amazon ec2 p2.16xlarge (64CPUs with GPU) The p2.16xlarge is supported and would give you around 170 Mkeys/s (at the moment this would be equivalent to the total of the current pool capacity...). In order to get GPU authorize, you have to submit 3000 Gkeys. With CPU. That's our "Proof of discipline". Also it's a little gesture of fairness for the early adopters. You have now around 680 Gkeys. You should - by the way - refrain from doing things like Code: 1496064624 50.19.147.36 PUT-NIL: tampered (K1LL3RK1NG-65f2) ;) Ok? So maybe you are cheaper off using a m4.16xlarge (64 vCPUs) and as soon as you have 3000 Gkeys, move to the p2.xxx Title: Re: Large Bitcoin Collider Thread 2.0 Post by: killyou007 on May 30, 2017, 06:35:58 PM actually i have 6 instances with p2.16xlarge and 6 with f1.8xlarge (fpga) instances.
i have these instances for another project since last year. but if you would give an opportunity i will use them for LBC. hope you can understand the issue and let me know your opinion. thanks in advance and waiting for your response asap....... Title: Re: Large Bitcoin Collider Thread 2.0 Post by: killyou007 on May 30, 2017, 06:50:06 PM it's the issue because i simply modified the client with GPU authorize 0 to 1
then i got blacklisted. but i am paying for amazon ec2 more than 28K per annum, so i would like to use it at least per LBC. that's the only thing i modified in LBC client. and i already submitted more than 3000 G keys with royal360 user id. hope you can understand and authorize for gpu. thanks in advance... Title: Re: Large Bitcoin Collider Thread 2.0 Post by: rico666 on May 30, 2017, 07:34:16 PM it's the issue because i simply modified the client with GPU authorize 0 to 1 then i got blacklisted. but i am paying for amazon ec2 more than 28K per annum, so i would like to use it at least per LBC. that's the only thing i modified in LBC client. and i already submitted more than 3000 G keys with royal360 user id. hope you can understand and authorize for gpu. thanks in advance... The client is made so even adding a whitespace is considered tampering: please don't. ROYAL247 has submitted 1410 Gkeys to date... so that's not sufficient. (You can find out with ./LBC -q command) But the nick is rising fast https://lbc.cryptoguru.org/stats/ROYAL247, Let it work overnight and you have your GPU auth. HOWEVER, I could enable GPU auth immediately for you (because honestly that's quite some punch hardware access you have there) if you let me play with an F1 instance for - say - 3x8 hours then. Gentlemen agreement ;) 6 instances p2.16xlarge could reach the 1 Gkeys/s on their own ... intriguing. Title: @nikovnikov & @challenger Post by: rico666 on May 31, 2017, 07:08:51 AM Hey guys,
you're the only 2 left with clients older than 1.140 (you have 1.067 in case you didn't know). Please see https://bitcointalk.org/index.php?topic=1877935.msg18665920#msg18665920 ("News" link from my sig) As of tomorrow, the server will require client 1.140 as minimum version. Shortly thereafter I would like to phase out the FTP updates. The new versions accept updates of the client and the generator only via a HTTPS connection (with name validation on ;)) so they address and fix some of the valid security concerns raised about a month ago. You guys are bravely fighting your way to 3000 Gkeys, so please don't let the server pull the plug on you. edit: If these are some "fire and forget" clients, I recommend the "eternal run" setup, see here https://lbc.cryptoguru.org/man/user#eternal-run (scroll down the "Get Work" section) This will keep your clients, generators and BLF file up to date with minimum overead (check once a day). Also, it's even more robust against transient network errors or even errors of the update process itself. Title: Re: Large Bitcoin Collider Thread 2.0 Post by: rico666 on May 31, 2017, 02:00:52 PM ROYAL247 has submitted 1410 Gkeys to date... so that's not sufficient. (You can find out with ./LBC -q command) But the nick is rising fast https://lbc.cryptoguru.org/stats/ROYAL247, Let it work overnight and you have your GPU auth. Looks like you did it! Congrats. For better GPU performance, Amazon recommends you do nvidia-smi -pm 1 nvidia-smi --auto-boost-default=0 nvidia-smi -ac 2505,875 (with sudo if you are not root already), then ./LBX -gpu -x in order to get a good/updated speed benchmark for your GPU client. And after that, the p2.16xlarge are to be started with LBC -c 64 -gpu -gopt dev=1-16:lws=512 be prepared that upon 1st invocation, it takes quite a while until the machine has started up all 64 processes. In my experience, the AWS IO subsystem is laggy like hell. After that all should be well. AWS systems differ slightly in their performance even in the same machine class. The bigger the system, the bigger the performance variance. You can expect p2.xlarge ~11 Mkeys/s p2.8xlarge ~80 - 88 Mkeys/s p2.16xlarge ~155 - 170 Mkeys/s Title: Re: Large Bitcoin Collider Thread 2.0 Post by: killyou007 on May 31, 2017, 03:14:14 PM hi
thanks for your support. how can i use fpga instances? what is the command? thanks in advance... regards, killer king Title: Re: Large Bitcoin Collider Thread 2.0 Post by: rico666 on May 31, 2017, 03:51:38 PM how can i use fpga instances? what is the command? thanks in advance... FPGA support has not been developed yet. I wish, but we're not there yet. Oh and before I forget it: Of course when testing AWS instances you have to use ./LBC -gpu -x -gopt lws=512 (the lws=512 is important, else you get a CL_OUT_OF_RESSOURCES or similar) Title: Re: Large Bitcoin Collider Thread 2.0 Post by: gizmoh on June 01, 2017, 05:30:53 AM Hey Rico,
Apparently someone stumbled on an Eth collision... https://twitter.com/RNR_0/status/869950371141177344 https://etherscan.io/address/0x2e7542eC36df6429D8C397F88C4Cf0c925948f44 Pub key: 0x2e7542eC36df6429D8C397F88C4Cf0c925948f44 Would be interesting to hash investigate ETH... Title: 5555.55 tn Post by: rico666 on June 01, 2017, 07:49:27 AM Apparently someone stumbled on an Eth collision... https://twitter.com/RNR_0/status/869950371141177344 I don't feel qualified enough to comment on these ETH things. From the tweet it looks like he claims to have found eth by simply generating a privkey with NodeJS. So to me, it looks more like the RNG in NodeJS would be #rekt. @killyou007 I see you're rising quite fast in the top30. At ~ 140 Mkeys/s no wonder, but somehow it doesn't fit the expected performance of a p2.16xlarge (let alone 6 of them). Care to let me in on your rig specs? Feel free via PM or to bots@cryptoguru.org if you don't want to discuss that officially. @oldclients The minimum client version accepted by the server is 1.140 as of now. Sorry. Also, as of this writing, the pool has searched the magnificent number of 5555.55 trillion private keys (11111.1 trillion addresses). I managed to snapshot it almost at the right moment: https://i.imgur.com/w4LldMV.png Title: Re: Large Bitcoin Collider Thread 2.0 Post by: vh on June 02, 2017, 03:06:58 AM Project looks interesting.
The server I was planning to allocate to contribute has no GPU @ Ubuntu 16.04. I made it trough ./LBC -h and got stuck at ./LBC -x Code: # ./LBC -x no gpu = no opencl *edit: Googling lead me to your original thread. Seems like OpenCL is required. More reading to do. Title: Re: Large Bitcoin Collider Thread 2.0 Post by: vh on June 02, 2017, 04:06:37 AM Got past that and the odd missing blf error. Looks like I'm good to continue.
Code: #./LBC -x Title: Re: Large Bitcoin Collider Thread 2.0 Post by: rico666 on June 02, 2017, 05:12:55 AM Got past that and the odd missing blf error. Looks like I'm good to continue. Code: Your speed is roughly 401519 keys/s per CPU core. I see a user "___vh___" successfully asking for and delivering blocks. May appear within a hour or two here: https://lbc.cryptoguru.org/stats/___vh___ As you probably found out already, the kardashev generators are unified binaries (CPU and GPU support) and they need a libOpenCL present - even if it is just a dummy/fake lib (for CPU only clients). Title: Re: Large Bitcoin Collider Thread 2.0 Post by: Jude Austin on June 06, 2017, 10:42:17 PM Hi,
What does this mean: GPU authorized: yes Benchmark info not found - benchmarking... done. Your speed is roughly 3245154 keys/s per CPU core. Ask for work... got blocks [5393996735-5394007934] (11744 Mkeys) oooooooooo0 just got out of the pool with exit code: 255 and data: 3 just got out of the pool with exit code: 255 and data: oooooooooooooooooo Thanks, Jude Title: Re: Large Bitcoin Collider Thread 2.0 Post by: rico666 on June 07, 2017, 05:36:11 AM What does this mean: GPU authorized: yes Benchmark info not found - benchmarking... done. Your speed is roughly 3245154 keys/s per CPU core. Ask for work... got blocks [5393996735-5394007934] (11744 Mkeys) oooooooooo0 just got out of the pool with exit code: 255 and data: 3 just got out of the pool with exit code: 255 and data: oooooooooooooooooo Any other errors on screen? Most of the time this means the OpenCL failed to start * no GPU found (probably not your case) * worksize too big (not your case if you are not on Amazon) * no memory left on GPU In your case, it looks like OCL error: CL_MEM_OBJECT_ALLOCATION_FAILURE (clEnqueueNDRangeKernel failed.) edit: you sure you have up-to-date client/generators? I see you were last active 24 days ago, minimum client version is now 1.140, hopefully you have also a kardashev-generator too. Title: Re: Large Bitcoin Collider Thread 2.0 Post by: Jude Austin on June 07, 2017, 12:12:30 PM What does this mean: GPU authorized: yes Benchmark info not found - benchmarking... done. Your speed is roughly 3245154 keys/s per CPU core. Ask for work... got blocks [5393996735-5394007934] (11744 Mkeys) oooooooooo0 just got out of the pool with exit code: 255 and data: 3 just got out of the pool with exit code: 255 and data: oooooooooooooooooo Any other errors on screen? Most of the time this means the OpenCL failed to start * no GPU found (probably not your case) * worksize too big (not your case if you are not on Amazon) * no memory left on GPU In your case, it looks like OCL error: CL_MEM_OBJECT_ALLOCATION_FAILURE (clEnqueueNDRangeKernel failed.) edit: you sure you have up-to-date client/generators? I see you were last active 24 days ago, minimum client version is now 1.140, hopefully you have also a kardashev-generator too. I installed everything new in a new directory. It could be my distro install, I messed some shit up trying to install Boost. Let me do a reinstall and try again. Thanks, Jude Title: Re: Large Bitcoin Collider Thread 2.0 Post by: rico666 on August 01, 2017, 09:28:52 AM I made a small modification to the server source:
Code: my $logtxt = "Query $id"; # text to be logged Title: Re: Large Bitcoin Collider Thread 2.0 Post by: anomaly31415 on August 04, 2017, 04:02:40 AM I like this project and I would love to help...
Someone mentioned pointing the pool to a different cryptocurrency, but what about something more like merged-mining? Could the saved work be re-used on a different blockchain, like Bitcoin Cash for example? Why not generate more complete search sequences (without the zeros at the begining)? It might seem like it's taking longer, but it would be searching in a less obscure area of the search space. And you wouldn't necessarily need to count by one's in a linear method, you may be able to write an subroutine to space it out without overlapping. The odds of discovery might be about the same but it wouldn't be limited to the lower number space. And I don't suppose the server side is open-source, but at least will the saved work be public domain? Title: Re: Large Bitcoin Collider Thread 2.0 Post by: OctoRostov2 on August 10, 2017, 04:51:02 PM For all time was found 32 bts? This is for what time interval?
How is the production divided between the participants? Title: Re: Large Bitcoin Collider Thread 2.0 Post by: kknd on August 28, 2017, 02:34:46 PM I am trying , but some problems and bugs in process
JSON not found - installing it :/ and download link ftp is broken ;/ Parcial solution: sudo apt install perl bzip2 xdelta3 libgmp-dev libssl-dev gcc make cpan force install JSON cpan force install LWP cpan force install Net::SSLeay sudo apt-get install libnet-ssleay-perl sudo apt-get install libcrypt-ssleay-perl sudo apt-get install LWP::Protocol::https sudo apt-get install Parallel::ForkManager sudo apt-get install Term::ReadKey sudo apt install ocl-icd-opencl-dev BUT , the problem now ubuntu@ip:~/$ ./LBC Will use 0 CPUs. Benchmark info not found - benchmarking... failed to open bloom filter 'funds_h160.blf': No such file or directory Generator validity check failed. Expected: 5, Got: 0 With output: -- ubuntu@ip-:~/$ Title: Re: Large Bitcoin Collider Thread 2.0 Post by: charlie-barkin on August 29, 2017, 01:26:26 AM Same problem with ftp:
Code: ./LBC -x Title: Re: Large Bitcoin Collider Thread 2.0 Post by: arulbero on August 30, 2017, 03:25:03 PM Ubuntu 17.04, this works for me:
Code: # $ is shell/bash Title: Re: Large Bitcoin Collider Thread 2.0 Post by: charlie-barkin on August 30, 2017, 10:29:58 PM Oh, looks like ftp.cryptoguru.org does not support passive ftp connections, so computers behind nat can not connect to it.
Title: Re: Large Bitcoin Collider Thread 2.0 Post by: unknownhostname on August 31, 2017, 02:38:44 PM Ubuntu 17.04, this works for me: Code: # $ is shell/bash How do I install it for a p2.x16 amazon machine ? Rico doenst answer to me ... he is busy now Title: Re: Large Bitcoin Collider Thread 2.0 Post by: arulbero on August 31, 2017, 03:22:57 PM How do I install it for a p2.x16 amazon machine ? Rico doenst answer to me ... he is busy now I don't know, I never installed LBC in a p2.x16 amazon machine. Title: Re: Large Bitcoin Collider Thread 2.0 Post by: fusepay on September 01, 2017, 11:31:26 AM What a super interesting project, I was quite a big contributor to BOIN, and I love playing with VanityGen, and now this, very exciting stuff, will get this installed and see how it goes, then report if I get any findings!
Title: Re: Large Bitcoin Collider Thread 2.0 Post by: kknd on September 04, 2017, 04:14:45 PM Ubuntu 17.04, this works for me: Code: # $ is shell/bash How do I install it for a p2.x16 amazon machine ? Rico doenst answer to me ... he is busy now sudo apt install perl bzip2 xdelta3 libgmp-dev libssl-dev gcc make cpan force install JSON cpan force install LWP cpan force install Net::SSLeay sudo apt-get install libnet-ssleay-perl sudo apt-get install libcrypt-ssleay-perl sudo apt-get install LWP::Protocol::https sudo apt-get install Parallel::ForkManager sudo apt-get install Term::ReadKey sudo apt install ocl-icd-opencl-dev run for me Title: Re: Large Bitcoin Collider Thread 2.0 Post by: rico666 on September 04, 2017, 05:18:39 PM Holy Sh!t - what happened to the puzzle transaction: https://blockchain.info/de/address/15K1YKJMiJ4fpesTVUcByoz334rHmknxmT
So whoever finds the next puzzle will be over half a bitcoin richer. edit: The birthday party is over - gpuauth=1 again only for those who delivered over 3000 Gkeys. Title: Re: Large Bitcoin Collider Thread 2.0 Post by: arulbero on September 04, 2017, 05:37:08 PM Holy Sh!t - what happened to the puzzle transaction: https://blockchain.info/de/address/15K1YKJMiJ4fpesTVUcByoz334rHmknxmT So whoever finds the next puzzle will be over half a bitcoin richer. https://bitcointalk.org/index.php?topic=1306983.msg18765941#msg18765941 Title: Re: Large Bitcoin Collider Thread 2.0 Post by: rico666 on September 04, 2017, 08:17:19 PM Holy Sh!t - what happened to the puzzle transaction: https://blockchain.info/de/address/15K1YKJMiJ4fpesTVUcByoz334rHmknxmT So whoever finds the next puzzle will be over half a bitcoin richer. https://bitcointalk.org/index.php?topic=1306983.msg18765941#msg18765941 Hm. So it was the creator and indeed all rewards up to 160bit are now 10 times the BTC! Wow. I think I will have to start some engines myself. ;) Title: Re: Large Bitcoin Collider Thread 2.0 Post by: arulbero on September 04, 2017, 08:32:05 PM Found #53!!!
Title: Re: Large Bitcoin Collider Thread 2.0 Post by: Real-Duke on September 04, 2017, 08:54:29 PM Found #53!!! was it you?Title: Re: Large Bitcoin Collider Thread 2.0 Post by: arulbero on September 04, 2017, 08:58:10 PM Yes ;D Title: Re: Large Bitcoin Collider Thread 2.0 Post by: Real-Duke on September 04, 2017, 09:11:29 PM Yes ;D Wooow congrats :o! That was the biggest bounty till now in the race...tell rico to shut down his extra power-machines ;D Title: Re: Large Bitcoin Collider Thread 2.0 Post by: GoldTiger69 on September 04, 2017, 09:38:40 PM Yes ;D Congrats! I'm curious, are you guys gonna publish the priv key? Title: Re: Large Bitcoin Collider Thread 2.0 Post by: arulbero on September 04, 2017, 09:46:16 PM Congrats! I'm curious, are you guys gonna publish the priv key? Yes, you will see the key here (https://lbc.cryptoguru.org/trophies). Title: Re: Large Bitcoin Collider Thread 2.0 Post by: balskiy on September 04, 2017, 09:47:27 PM edit: The birthday party is over - gpuauth=1 again only for those who delivered over 3000 Gkeys. Hello Rico!I delivered more than 10,000 Gkeys, but gpu stopped working for me. my id 46a1be18c42d87b7f927c01796c80c30. How can I view the contents of the funds_h160.blf file? Title: Re: Large Bitcoin Collider Thread 2.0 Post by: rico666 on September 05, 2017, 05:19:23 AM I delivered more than 10,000 Gkeys, but gpu stopped working for me. my id 46a1be18c42d87b7f927c01796c80c30. restored. Quote How can I view the contents of the funds_h160.blf file? That file is the bloom filter. It's basically a binary blob. Title: Re: Large Bitcoin Collider Thread 2.0 Post by: rico666 on September 06, 2017, 12:45:14 PM Private key for #53: https://lbc.cryptoguru.org/trophies
Stats updated to show ETA for #54 Title: Re: Large Bitcoin Collider Thread 2.0 Post by: prakbit on September 07, 2017, 08:48:18 PM the link to the LBC Appliance is not working. can you pls post a new link so i can start contributing ?
Title: Re: Large Bitcoin Collider Thread 2.0 Post by: kknd on September 09, 2017, 08:55:53 PM Best hardware teste for LBC !
AMAZON vs GOOGLE CLOUD vs MICROSOFT AZURE Code: ######################################################### Title: Re: Large Bitcoin Collider Thread 2.0 Post by: fanou1989 on September 09, 2017, 09:23:08 PM Where did you get this calculation from? Basically investing is actually risking a whole lot
Title: Re: Large Bitcoin Collider Thread 2.0 Post by: kknd on September 09, 2017, 10:19:04 PM Where did you get this calculation from? Basically investing is actually risking a whole lot I paid for a few hours in each service to make a test https://i.imgur.com/tGNYYw2.png Title: Re: Large Bitcoin Collider Thread 2.0 Post by: arulbero on September 10, 2017, 06:59:07 AM Best hardware teste for LBC ! AMAZON vs GOOGLE CLOUD vs MICROSOFT AZURE Amazon m4.x16large (cpu only) ./LBC -c 64 24Mkeys/s $0.53 / hour It takes about $62 to perform 10000 Gkeys. Title: Re: Large Bitcoin Collider Thread 2.0 Post by: arulbero on September 10, 2017, 08:40:00 AM the link to the LBC Appliance is not working. can you pls post a new link so i can start contributing ? Try this: ftp 92.43.104.60 username: anonymous password: (press ENTER, no password) cd LBC/appliance get archlinux-64bit.7z quit Code: $ ftp 92.43.104.60 Title: Re: Large Bitcoin Collider Thread 2.0 Post by: lookingforcoins on September 29, 2017, 04:05:24 PM So, I managed to get it more or less running on Bash on Ubuntu on Windows 10, but I'm missing the bloom filter (failed to open bloom filter "funds_h160.blf"). So, I thought I should try the appliance instead, but the ftp server refuses my connection, although I'm successful in navigating to LBC\Appliance, it will kick me off if I ls or try to get the VMware image. Anyone willing to share either the bloom filter or the appliance?
Title: Re: Large Bitcoin Collider Thread 2.0 Post by: arulbero on October 01, 2017, 12:13:18 PM Anyone willing to share the bloom filter ? https://www.dropbox.com/s/vlh1c6ammvgyw50/funds_h160.blf?dl=0 Title: Re: Large Bitcoin Collider Thread 2.0 Post by: lookingforcoins on October 02, 2017, 05:26:49 PM https://www.dropbox.com/s/vlh1c6ammvgyw50/funds_h160.blf?dl=0 Thanks, works now! Only thing not working is the --email option. Anyone got that working? Title: Re: Large Bitcoin Collider Thread 2.0 Post by: icanteven on October 03, 2017, 09:46:04 AM Hi guys,
I installed the LBC appliance, ran it with VMWare Player, did ./LBC -x and I get the following error: "Testing mode. Using page 0, turning off looping. Benchmark info not found - benchmarking.... "gen-hrdcore-sse42-linux62" not found/executable" I also got a "wrong: minversion 1.140" error. How do I fix this? Thanks, Title: Re: Large Bitcoin Collider Thread 2.0 Post by: dcw312 on October 08, 2017, 10:02:43 PM First of all, thank you for this project. Mostly because I suspected that bitcoin was vulnerable to key collision but when I shared these suspicions, I was told that the earth was more likely to explode than for that to happen. So your work will has done me the great service of seeming smarter than I am.
I tried yesterday to get the client running on my local machine yesterday. I tried using Docker to provide the safe sandbox discussed in the documentation. I've put my Dockerfile on Github at https://github.com/dcw312/lbc-client-docker I'm new to Arch Linux and Perl so I don't expect to make significant contributions. As an aside, I'm a little surprised that the dependency management of Perl seems to be such a challenge. In my work yesterday, I'd keep seeing messages like "LWP::UserAgent not found - installing it." I'm most recently using Java and Maven so I expected the dependency management to be a bit more straightforward. Would someone be willing to reply with the list of Arch Linux packages that are installed on the VM image? I ask so I can add them to the Dockerfile. This can be done with: Code: pacman -Q Please also supply installed cpan modules: Code: cpan -l Also, if something special was required to install cpan, please let me know so I can close this https://github.com/dcw312/lbc-client-docker/issues Thanks!! p.s. My motivation is mostly to continue to see how Docker can be used for sandboxed work like this. Title: Re: Large Bitcoin Collider Thread 2.0 Post by: arulbero on October 09, 2017, 12:33:34 PM Please also supply installed cpan modules: Code: cpan -l I have Ubuntu 17.04. With your command I get over 800 modules, these are related to LBC (if I remember properly) Code: $ cpan -l EDIT: Looking in to the Perl script these are modules you need for sure: Code: JSON Title: Re: Large Bitcoin Collider Thread 2.0 Post by: dcw312 on October 10, 2017, 01:46:30 AM I have Ubuntu 17.04. Looking into the Perl script these are modules you need for sure: Code: JSON Thank you! My Dockerfile now works: https://github.com/dcw312/lbc-client-docker You need to manually add the funds_h160 file. I'll try to post instructions for that. Title: Re: Large Bitcoin Collider Thread 2.0 Post by: daserpent on October 10, 2017, 05:15:44 AM I don' think I understand completely what you mean by bitcoin collider. Could you please explain it is simple laymen words?
Title: Re: Large Bitcoin Collider Thread 2.0 Post by: BurtW on October 10, 2017, 11:19:46 AM I don' think I understand completely what you mean by bitcoin collider. Could you please explain it is simple laymen words? My guess is you are new to forums, new to reading threads, new to computers and not technically savy.The very first post in a thread is called the "original post" or OP for sort. This is where you will find out what the thread is all about. So, before you ask any questions in a thread you should read the OP, the first post in the thread. Then if you do not understand what the thread is about it then, and only then, you post a very specific question that is not answered in the OP. In order to get to the OP you click on the 1 below where it says "Pages:" to get to the first page. Or you can click here: https://bitcointalk.org/index.php?topic=1877935.msg18665912#msg18665912 Title: Re: Large Bitcoin Collider Thread 2.0 Post by: daserpent on October 10, 2017, 04:03:38 PM I don' think I understand completely what you mean by bitcoin collider. Could you please explain it is simple laymen words? My guess is you are new to forums, new to reading threads, new to computers and not technically savy.The very first post in a thread is called the "original post" or OP for sort. This is where you will find out what the thread is all about. So, before you ask any questions in a thread you should read the OP, the first post in the thread. Then if you do not understand what the thread is about it then, and only then, you post a very specific question that is not answered in the OP. In order to get to the OP you click on the 1 below where it says "Pages:" to get to the first page. Or you can click here: https://bitcointalk.org/index.php?topic=1877935.msg18665912#msg18665912 I read the OP but it was too complicated.. like what are brain wallets? And what does he mean by trying to find private keys to addresses that have bitcoins in them? Is this some collective hacking attempt or something? Title: Re: Large Bitcoin Collider Thread 2.0 Post by: GoldTiger69 on October 10, 2017, 05:30:31 PM I don' think I understand completely what you mean by bitcoin collider. Could you please explain it is simple laymen words? My guess is you are new to forums, new to reading threads, new to computers and not technically savy.The very first post in a thread is called the "original post" or OP for sort. This is where you will find out what the thread is all about. So, before you ask any questions in a thread you should read the OP, the first post in the thread. Then if you do not understand what the thread is about it then, and only then, you post a very specific question that is not answered in the OP. In order to get to the OP you click on the 1 below where it says "Pages:" to get to the first page. Or you can click here: https://bitcointalk.org/index.php?topic=1877935.msg18665912#msg18665912 I read the OP but it was too complicated.. like what are brain wallets? And what does he mean by trying to find private keys to addresses that have bitcoins in them? Is this some collective hacking attempt or something? Just remember: Google is your friend ;) Title: Re: Large Bitcoin Collider Thread 2.0 Post by: arulbero on October 11, 2017, 10:31:03 AM I have Ubuntu 17.04. Looking into the Perl script these are modules you need for sure: Code: JSON Thank you! My Dockerfile now works: https://github.com/dcw312/lbc-client-docker You need to manually add the funds_h160 file. I'll try to post instructions for that. GPU version of LBC usually works only on Linux, not on Windows. With your Dockerfile is it possibile to exploit GPU on Win? Title: Re: Large Bitcoin Collider Thread 2.0 Post by: daserpent on October 11, 2017, 04:44:54 PM Can I participate from Windows?? Does it require GPU power or CPU power?
Title: Re: Large Bitcoin Collider Thread 2.0 Post by: dcw312 on October 13, 2017, 03:25:55 AM GPU version of LBC usually works only on Linux, not on Windows. With your Dockerfile is it possibile to exploit GPU on Win? A quick Google search indicates that Nvidia/Docker does not support Windows. For Linux, see this project here for Nvidia+Docker https://github.com/NVIDIA/nvidia-docker/tree/2.0 Title: Re: Large Bitcoin Collider Thread 2.0 Post by: KeepingScore on October 13, 2017, 09:50:53 AM No downloads available on site?
Title: Re: Large Bitcoin Collider Thread 2.0 Post by: rico666 on October 13, 2017, 11:34:07 AM Just to make it clear for everybody:
Yes, the project is still on, I haven't abandoned it. I just happen to spend my energy currently on the BURST cryptocurrency, so there is not much time left for the LBC project at the moment. I feel the need to make that clarification here, as there are 1st "stalkers" who use Burst discussions on Reddit to ask me about LBC https://www.reddit.com/r/burstcoin/comments/75urgi/i_want_to_set_another_node_but_this_time_on_a_vps/dob21xk/ Please don't do that. There is a nice Discord Channel at https://discord.gg/AyEfZrY Where you can get more interactive support from the great LBC community. Also, there are at the moment some showstoppers that would need too much of my time to look into (like a broken blockparser, see https://github.com/znort987/blockparser/issues/65) if someone wants to give me a real nudge to update some things LBC (and I do have some pretty nice updates pending), fix that blockparser issue or find an alternative. Arulbero has sent me a new version of his ECC lib which may be (I haven't tested it yet, but I believe his tests/claims) 20% faster. I would want to include that too. So someone please look into the blockexplorer. Title: Re: Large Bitcoin Collider Thread 2.0 Post by: arulbero on October 13, 2017, 06:30:54 PM Arulbero has sent me a new version of his ECC lib which may be (I haven't tested it yet, but I believe his tests/claims) 20% faster. A little explanation (and update) for the LBC users: LBC generator has 3 components: 1) ECC generator --> 2) sha256 + ripemd160 --> 3) bloom search 1) this component computes the generation from the private key of the corresponding public key. We have only a CPU version of this library. 2) each single public key produces 2 160-bit strings (addresses = hash of the public key), uncompressed and compressed addresses; Rico developed 2 optimized versions of this component, one for CPU and one for GPU. In the GPU case the output of the CPU is sent to the GPU. 3) check if the addresses generated in the step 2) are or not in the bloom filter (CPU version and GPU version). For the systems GPU limited (GPU used at 90% or more) it is crucial to improve the component 2). For the systems CPU limited (example: CPU used at 100% and GPU at 50%) it is important instead to improve the speed of the ECC generator, i.e. the rate at which the CPU feeds the GPU. ECC generator is the component I have been working on in the past months. I'm improving the ECC library as much as I can. At this moment the library is almost 30% faster than the current one. On my CPU Kabylake, it takes only 1,16 s to generate 16,7 M public keys against the 1,64 s of the latest release. For a system cpu limited, the new library could take a +30% speedup (exploiting completely the GPU's speed). In that case I think that the LBC generator will be faster than oclvanitygen on all GPUs (for now the LBC generator is faster only on middle/slow gpu, but not on fast gpu). For a system gpu limited, the only advantage is that you could use 3 cores to get (almost) the same performance as 4 cores now. For a system without GPU there is a small speedup, because in the CPU generator only a 10% of the cpu work is about the ECC arithmetic, about 65% is for the sha256/ripemd160 task and about 25% for the bloom search. Title: Re: Large Bitcoin Collider Thread 2.0 Post by: arulbero on October 13, 2017, 06:54:43 PM Also, there are at the moment some showstoppers that would need too much of my time to look into (like a broken blockparser, see https://github.com/znort987/blockparser/issues/65) if someone wants to give me a real nudge to update some things LBC (and I do have some pretty nice updates pending), fix that blockparser issue or find an alternative. I would want to include that too. So someone please look into the blockexplorer. This is a Python version to extract data from utxo: https://bitcoin.stackexchange.com/questions/56655/getting-a-crypto-proof-utxo-set https://github.com/sr-gi/bitcoin_tools Like Wuille noted, Bitcoin Core 0.15 has changed db format of the Utxo set. Maybe you could try with a old version of Core. Title: Re: Large Bitcoin Collider Thread 2.0 Post by: kknd on October 14, 2017, 12:09:22 AM tks arulbero for work ;D ;D ;D ;D
I was thinking that the project was abandoned Title: Re: Large Bitcoin Collider Thread 2.0 Post by: rico666 on October 14, 2017, 09:00:50 AM For a system without GPU there is a small speedup, because in the CPU generator only a 10% of the cpu work is about the ECC arithmetic, about 65% is for the sha256/ripemed160 task and about 25% for the bloom search. No, the bloom search (more precisely: bloom check) accounts for about 1% of the total work. Title: Re: Large Bitcoin Collider Thread 2.0 Post by: arulbero on October 14, 2017, 12:03:19 PM For a system without GPU there is a small speedup, because in the CPU generator only a 10% of the cpu work is about the ECC arithmetic, about 65% is for the sha256/ripemd160 task and about 25% for the bloom search. No, the bloom search (more precisely: bloom check) accounts for about 1% of the total work. On the CPU generator the bloom check is only 1%? I made a little program with: 1) my aecc 2) sha256 and ripemd160 from supervanitygen 3) bloom check from brainflayer and I got: 1,16s for aecc, 12,4s for sha256+ripemd160, 4s for bloom check => total: 17,55s for 16,7 Mkeys Then: 6,6% for aecc, 70,6% for sha256 and 22,8% for bloom check. Maybe I'm not using the bloom check in the best way, but 23% against 1% is too much. Title: Re: Large Bitcoin Collider Thread 2.0 Post by: rico666 on October 14, 2017, 03:25:54 PM On the CPU generator the bloom check is only 1%? I made a little program with: 1) my aecc 2) sha256 and ripemd160 from supervanitygen 3) bloom check from brainflayer and I got: 1,16s for aecc, 12,4s for sha256+ripemd160, 4s for bloom check => total: 17,55s for 16,7 Mkeys Then: 6,6% for aecc, 70,6% for sha256 and 22,8% for bloom check. Maybe I'm not using the bloom check in the best way, but 23% against 1% is too much. Hard to say when I do not see the little program. On my machine the LBC generator takes like 0.2 s for both compressed and uncompressed checks of 16.7M keys. No - I do not use the code from brainflayer anymore, but I believe even the original code didn't take so long on my CPU (more like 0.4s instead of 4s) On a different topic: I updated the views. The download link to the LBC Appliance is updated. Careful, it's a 1.8GB download. It has an updated Arch Linux, newest available BLF, client and a haswell generator. You will now see also a Crowdfunding page, which is merely there to stipulate a discussion about improving GPU performance (see what arulbero wrote above about GPU limited issues). By using an improved ECC lib and symmetries, we may run sooner into a GPU limited situation in the future. Title: Re: Large Bitcoin Collider Thread 2.0 Post by: rico666 on October 16, 2017, 12:22:48 PM Success!
(25.99 Mkeys/s) on a machine (Skylake + M2000M) that gave me 22.7 Mkeys/s max with the previous generator. Thanks to the new Arulbero ECC library. A nice side effect of arulbero completely ditching the libgmp requirement (by providing his own tailored bignum math) is, that the generator binaries are now only half the size of the previous ones. 243184 Oct 16 14:20 kardashev-skylake 237KiB - we may cast that soon into a FPGA ;D - just kidding... Or am I? Still, please do have patience before I push the new binaries on the server, I would like to get rid of the FTP server first and move all to a HTTPS communication. edit: with some newer versions I was able to squeeze 27.26 Mkeys/s out of my machine with around 95/96% GPU usage. Certainly more will be possible in the future. kardashev-skylake is now available in the new versions, those of you who have skylake machines with GPU, please test. (client should auto-update the generator upon restart). Generators for the other instruction sets will follow soon. Title: Re: Large Bitcoin Collider Thread 2.0 Post by: gizmoh on October 18, 2017, 09:31:15 AM Hurrah! over 30% jump from ~31.5 Mkeys to ~41.6 Mkeys on a 7700k with 1080Ti
Gpu usage from ~83% now to ~98% Thanks Arulbero for the optimizations and Rico for quick implementation :) Title: Re: Large Bitcoin Collider Thread 2.0 Post by: rico666 on October 18, 2017, 11:29:20 AM Hurrah! over 30% jump from ~31.5 Mkeys to ~41.6 Mkeys on a 7700k with 1080Ti Gpu usage from ~83% now to ~98% Thanks Arulbero for the optimizations and Rico for quick implementation :) 28% for GPU clients that were not GPU limited - to be precise. ;) Your observation is consistent with what is seen on these machines. i7-6700 CPU @ 3.40GHz + 1080 : 32.47 Mkeys/s -> 42.36 Mkeys/s That makes the overall collider speed an equivalent of 6 such machines. If we had 600 of these colliders, the next puzzle transaction privkey would be here in less than 24 hours - worst case. Title: Re: Large Bitcoin Collider Thread 2.0 Post by: arulbero on October 18, 2017, 05:07:38 PM Hurrah! over 30% jump from ~31.5 Mkeys to ~41.6 Mkeys on a 7700k with 1080Ti If your system is more or less like this: https://bitcointalk.org/index.php?topic=1573035.msg18373053#msg18373053 or like this https://bitcointalk.org/index.php?topic=1573035.msg18446472#msg18446472 then we are now faster than oclvanitygen on fast GPUs too. Remember that 41.6 Mkeys/s means 41.6 M compressed keys + 41.6 M uncompressed keys per second, over 83 Maddresses/s!. Could you test oclvanitygen on your machine? Gpu usage from ~83% now to ~98% I'm afraid that almost all systems are now GPU limited. Only multi GPU systems can take advantage from other ecc improvements (if there will be) and from n-k symmetry. I think that a GPU version of ECC library would be not very useful at the moment. We need above all to speedup sha256/ripemd160 on GPU. Title: Re: Large Bitcoin Collider Thread 2.0 Post by: rico666 on October 18, 2017, 05:26:47 PM I'm afraid that almost all systems are now GPU limited. Only multi GPU systems can take advantage from other ecc improvements (if there will be) and from n-k symmetry. I think that a GPU version of ECC library is not very useful at the moment. We need overall to speedup sha256/ripemd160 on GPU. You are right: Multi-GPU systems are not GPU limited and the client has been tested already on Systems with as many as 16 GPUs. (currently the Amazon p16.xlarge delivers 175 Mkeys/s) I have already a n-k symmetry prototype running - in fact had this already May, 25th: https://twitter.com/LBC_collider/status/867657663987015680 The single showstopper to enable n-k symmetry is accounting work that has to be done on the server. In theory, with n-k symmetry and better hash160 OpenCL code (which I believe is possible - see also https://lbc.cryptoguru.org/crowdfunding), we may see 2x speedups on the same hardware. Title: Re: Large Bitcoin Collider Thread 2.0 Post by: KeepingScore on October 19, 2017, 07:33:14 PM Solution to the VM's "loadable library and perl binaries are mismatched" bug when you run "./collider/LBC -x" is to run "cpan -r" and let it update everything.
Title: Re: Large Bitcoin Collider Thread 2.0 Post by: CrytpSig on October 20, 2017, 03:35:12 AM I'm afraid that almost all systems are now GPU limited. Only multi GPU systems can take advantage from other ecc improvements (if there will be) and from n-k symmetry. I think that a GPU version of ECC library is not very useful at the moment. We need overall to speedup sha256/ripemd160 on GPU. You are right: Multi-GPU systems are not GPU limited and the client has been tested already on Systems with as many as 16 GPUs. (currently the Amazon p16.xlarge delivers 175 Mkeys/s) I have already a n-k symmetry prototype running - in fact had this already May, 25th: https://twitter.com/LBC_collider/status/867657663987015680 The single showstopper to enable n-k symmetry is accounting work that has to be done on the server. In theory, with n-k symmetry and better hash160 OpenCL code (which I believe is possible - see also https://lbc.cryptoguru.org/crowdfunding), we may see 2x speedups on the same hardware. Hi I am having issues with the Arch Linux virtual machine on windows Problem connecting to server https://lbc.cryptoguru.org/static/client(status: 500 Can't connect to lbc.cryptoguru.org:443 (certificate verify failed). retries left 29 Title: Re: Large Bitcoin Collider Thread 2.0 Post by: rico666 on October 21, 2017, 09:12:57 AM I'm having issues with the Arch Linux virtual machine on windows Problem connecting to server https://lbc.cryptoguru.org/static/client(status: 500 Can't connect to lbc.cryptoguru.org:443 (certificate verify failed). retries left 29 maybe a > pacman -S ca-certificates will help. I remember (faintly) that the ca-certificates package said something like "valid until 20.10" or something like that "next check 20.10" - not sure. Or you do a > pacman -Syu Which is the Arch Linux way of "apt-get update & apt-get upgrade" edit: Or you have a simple networking problem. Try a > ping 8.8.8.8 if that works. If yes, update as said above. If no, you have to get your VM networking right first. But that is a matter of the VM configuration, not of the OS running inside the VM. Title: Re: Large Bitcoin Collider Thread 2.0 Post by: CrytpSig on October 22, 2017, 09:54:50 PM I'm having issues with the Arch Linux virtual machine on windows Problem connecting to server https://lbc.cryptoguru.org/static/client(status: 500 Can't connect to lbc.cryptoguru.org:443 (certificate verify failed). retries left 29 maybe a > pacman -S ca-certificates will help. I remember (faintly) that the ca-certificates package said something like "valid until 20.10" or something like that "next check 20.10" - not sure. Or you do a > pacman -Syu Which is the Arch Linux way of "apt-get update & apt-get upgrade" edit: Or you have a simple networking problem. Try a > ping 8.8.8.8 if that works. If yes, update as said above. If no, you have to get your VM networking right first. But that is a matter of the VM configuration, not of the OS running inside the VM. Ping came back fine updated on those commands previously still not working. I think this is an issue with the Perl certificate implementation. I had a similar issue running a perl script on windows with he same error that i could not fix. Title: Re: Large Bitcoin Collider Thread 2.0 Post by: Suzobo on October 23, 2017, 01:29:14 AM Might be time to start up the server again and see what a nVidia Quadro card can do.
I know I did around a million keys pr sec with the cpu alone. :D :D Title: Re: Large Bitcoin Collider Thread 2.0 Post by: rico666 on October 23, 2017, 08:15:05 AM Ping came back fine updated on those commands previously still not working. I think this is an issue with the Perl certificate implementation. I had a similar issue running a perl script on windows with he same error that i could not fix. LBC uses https://metacpan.org/pod/LWP::Protocol::https for HTTPS validation. Worksforme. So maybe $ sudo cpan cpan> install LWP::Protocol::https Other than that: ¯\_(ツ)_/¯ Title: Re: Large Bitcoin Collider Thread 2.0 Post by: CrytpSig on October 23, 2017, 08:28:02 AM Ping came back fine updated on those commands previously still not working. I think this is an issue with the Perl certificate implementation. I had a similar issue running a perl script on windows with he same error that i could not fix. LBC uses https://metacpan.org/pod/LWP::Protocol::https for HTTPS validation. Worksforme. So maybe $ sudo cpan cpan> install LWP::Protocol::https Other than that: ¯\_(ツ)_/¯ Still no luck anyway I can bypass https? https://stackoverflow.com/questions/74358/how-can-i-get-lwp-to-validate-ssl-server-certificates#5329129 Title: Re: Large Bitcoin Collider Thread 2.0 Post by: kknd on October 26, 2017, 10:36:47 PM All comands:
sudo apt-get update sudo apt-get upgrade sudo apt-get update && sudo apt-get -y upgrade sudo apt-get install -y linux-image-extra-`uname -r` sudo apt install perl bzip2 xdelta3 libgmp-dev libssl-dev gcc make sudo apt-get install gcc make tmux libssl-dev xdelta3 nvidia-367 nvidia-cuda-toolkit sudo cpan install OpenCL sudo cpan force install JSON sudo cpan force install LWP sudo cpan force install Parallel::ForkManager sudo cpan force install Net::SSLeay sudo cpan force install LWP::Protocol::https sudo cpan force install Parallel::ForkManager sudo cpan force install Term::ReadKey sudo apt-get install libnet-ssleay-perl sudo apt-get install libcrypt-ssleay-perl sudo apt-get install LWP::Protocol::https sudo apt-get install Parallel::ForkManager sudo apt-get install Term::ReadKey sudo apt install ocl-icd-opencl-dev sudo apt-get install nvidia-375 sudo apt-get dist-upgrade -y sudo reboot sudo ./LBC -h sudo ./LBC -x Title: Re: Large Bitcoin Collider Thread 2.0 Post by: dcw312 on October 28, 2017, 05:06:38 PM sudo ./LBC -x RUNNING LBC AS ROOT IS NOT REQUIRED OR A GOOD PRACTICE The LBC app contains a remote code execution vulnerability. Rico assures us that he as taken many steps to avoid a malicious attacker from leveraging the vulnerability. But since root privilege is not required, there is no reason to run LBC as root. For extra protection, you might consider running LBC inside a Docker container. I provide a base image (dcw312/lbc-base:latest) as well as code to create it and use it at: https://github.com/dcw312/lbc-client-docker p.s. Thanks for providing the nvidia libraries. My Docker image does not use that and some extra Docker foo is required to leverage the GPU. Title: Re: Large Bitcoin Collider Thread 2.0 Post by: rico666 on October 28, 2017, 07:28:54 PM RUNNING LBC AS ROOT IS NOT REQUIRED OR A GOOD PRACTICE The LBC app contains a remote code execution vulnerability. It seems impossible for people to remember things that have been said once, so I repeat it again. Hopefully it will last for a couple of months: a) Running LBC as root is not required, but if you run LBC in a VM, or Docker container, or on a dedicated machine, it's as good as any other command running as root. I do it all the time. b) The LBC is not an App - go to your sweepy wheepy Android/iOS device for that. c) The Remote Code Execution is there by design and not a vulnerability. Same as you do not consider the JavaScript remote code execution in your faggy browser a vulnerability. Or do you? Quote p.s. Thanks for providing the nvidia libraries. My Docker image does not use that and some extra Docker foo is required to leverage the GPU. I have some reports of people successfully doing a PCI passthrough to VMware and KVM virtual machines, so that's definitely an option for a GPU enabled client. Title: Re: Large Bitcoin Collider Thread 2.0 Post by: dcw312 on October 29, 2017, 05:19:02 PM The Remote Code Execution is there by design and not a vulnerability. My apologies for implying that the RCE was a bug. I was using the word "vulnerability" to refer to the "state of being exposed to the possibility of being attacked" without judgement of it being a "bug" or a "feature". Your analogy to Javascript is a good one. Browsers provide an execution sandbox so to manage the risks of RCE. Users of LBC should, as you say, take appropriate steps to provide an appropriate sandbox.To avoid repeating yourself further, you might consider having the client print a message on startup, like: "The LBC client contains a feature update itself. In the unlikely event that the LBC server were compromised by an attacker, the attacker would be able to execute arbitrary code on your machine as the user that executes LBC. Please execute LBC accordingly." This is just a well intended suggestion. Apologies again for any insult. Title: 16000 trillion addresses, LBC Pot payout and Gkeys forfeiture Post by: rico666 on October 30, 2017, 07:28:19 AM Greetings Colliders!
A few hours ago, the LBC computed it's 16000 trillionth address (8000 trillion keys, each key compressed & uncompressed pubkey -> 2 addresses per key). At the current rate of 25-30 tn keys per day, this means 36 days for 1000 tn keys on average. In other words, the LBC checked the equivalent of over 62500 billion pages on http://www.directory.io/ and at the moment is doing so at a rate of 2.5 million of these pages per second. I have thought a long time how and when to distribute the funds that ended up in the LBC Pot (currently 0.12274528 BTC) and here's how the LBC Pot will be distributed among the participating colliders: Every time the LBC reaches a bit boundary in the search space (53 bits, 54 bits, ...) the current LBC pot will be distributed proportionally according to the Gkeys delivered among those who were active in the week before the LBC hits this boundary. This means, if you look at your Per-User statistics (e.g. https://lbc.cryptoguru.org/stats/__rico666__) at the time the LBC crosses this boundary, there can be no single 2h average point with 0 Mkeys/s or else you are not eligible - no matter how many Gkeys you have submitted so far. On the other hand, the speed in there (as long as it is above 0 Mkeys/s) does not have any influence on the payout - only your Gkeys delivered so far do. There are a lot of dead/dormant accounts, who seem to just have tested LBC and then stopped colliding. And this is perfectly ok. On the other hand, I don't think it makes sense to keep these accounts around indefinitely as most of them have some single-digit Gkeys, but everyone started out small, so an automated cleanup mechanism should not immediately reap small accounts. This is what will happen: Starting with 53bit search space (which is due in about a month given current speed), accounts that have been inactive for (7 + Gkeys_delivered) days will be reaped and their Gkeys will be added proportionally to the other active accounts. Consider it a kind of Proof of Stake. ;) e.g. Account has delivered 5 Gkeys and is inactive. This account can be inactive for 12 days before it is reaped. Account has delivered 1000 Gkeys and is inactive. This account can be inactive for 1007 days before it is reaped. It's clear that accounts that did some serious colliding in the past with several thousand Gkeys do not have to fear to be reaped anytime soon. But I should point out that as speed of colliding rates changes over time, we may change this rule at some point in the future. (Imagine if the hardware/software in 5 years can give you 1Gkey/s then probably 1 Gkey will buy you 1 hour idle time. Or something like that) For now, 7 days idle time is ok for everyone, above that: 1Gkey = 1 day. Title: Re: Large Bitcoin Collider Thread 2.0 Post by: arulbero on October 30, 2017, 03:10:43 PM Just my opinion:
when you delete an account, why its Gkeys are added to the other active accounts? Personally I like to know exactly how many keys I have delivered. I don't need the Gkeys from other accounts. I prefer to see an accurate record. You could gather all the Gkeys from the account deleted in a single generic account "other" that doesn't appear in the top 30. A few hours ago, the LBC computed it's 16000 trillionth address (8000 trillion keys, each key compressed & uncompressed pubkey -> 2 addresses per key). Then the Unknownhostname's share has fallen below 50% of the total amount. Title: Re: Large Bitcoin Collider Thread 2.0 Post by: Hereticalsauce on October 30, 2017, 11:21:11 PM arulbero,
I think this is rico's way to incentivize M/hash to the pool, and reward those who stick with him in his experiment. Perhaps the re-distributed Gkeys can be assigned to a dead-pool IP of 0.0.0.0 to keep them separate from your work. I found Google's cloud computing to be quite nice, they are offering a $300 trial of their services, at least for me. Without asking for more vCPUs, a 24 core skylake preemptible VM per region will cost $0.20/hour and net ~10 Mkey/s. A 96 core will cost $0.84/hr. There are GPU options as well, up to eight K80s or four P100. An eight core Broadwell with four P100s will cost $9.399/hr or $5.799/hr on eight K80s. Id like to try these once my GPU is authed. Title: Re: Large Bitcoin Collider Thread 2.0 Post by: gizmoh on October 31, 2017, 05:29:37 AM Quote there can be no single 2h average point with 0 Mkeys/s or else you are not eligible - no matter how many Gkeys you have submitted so far IMO a 2h timeframe is too short. Probability of power outage/ network downtime lasting over 2hr is quite high. A number between 6hr to 12hr average point would be more reasonable. Title: Re: Large Bitcoin Collider Thread 2.0 Post by: rico666 on October 31, 2017, 06:28:11 AM IMO a 2h timeframe is too short. Probability of power outage/ network downtime lasting over 2hr is quite high. A number between 6hr to 12hr average point would be more reasonable. 2h is fine. You can have multiple colliders, even geographically distributed, working for the same id. Also, I need to be efficient about any functional changes I make to the LBC because of time constraints taking the individual stats as validation dataset is such an efficiency. And therefore as announced. It may be a problem if your collider infrastructure is not reliable: https://lbc.cryptoguru.org/stats/Unknownhostname But that is - intentionally - your problem you either solve or not. @arulbero I may re-think the assignment of forfeited Gkeys. Either assign them to some "Dummy account", or into a separate value of the clients, because I agree that the information what were your Gkeys and what were foreign Gkeys should not be dilluted. Title: Re: Large Bitcoin Collider Thread 2.0 Post by: rico666 on October 31, 2017, 04:36:23 PM Id like to try these once my GPU is authed. 5b8f5562ac3873408d26852d74434040 is over 3000 Gkeys and has no gpuauth. GPUAuth set now. 6fdafb1d737ef98bcbdceaaff16b2a9c is over 3000 Gkeys and has no gpuauth. GPUAuth set now. Hereticalsauce is over 3000 Gkeys and has no gpuauth. GPUAuth set now. QWERTYUIOP555 is over 3000 Gkeys and has no gpuauth. GPUAuth set now. YorikBlin is over 3000 Gkeys and has no gpuauth. GPUAuth set now. ___vh___ is over 3000 Gkeys and has no gpuauth. GPUAuth set now. cyberguard is over 3000 Gkeys and has no gpuauth. GPUAuth set now. ddosddos is over 3000 Gkeys and has no gpuauth. GPUAuth set now. ffchampmt is over 3000 Gkeys and has no gpuauth. GPUAuth set now. Title: Re: Large Bitcoin Collider Thread 2.0 Post by: Hereticalsauce on November 01, 2017, 05:21:21 AM Hereticalsauce is over 3000 Gkeys and has no gpuauth. GPUAuth set now. Thank you, sir. So, Google wants $140 before they auth me GPU use. ::) Might just as well buy a video card and run this locally; time to dust off the ol' 5970. Title: Re: Large Bitcoin Collider Thread 2.0 Post by: arulbero on November 01, 2017, 10:10:03 AM I want to make some comments on how LBC works. I take inspiration from this Wuille's comment: https://bitcoin.stackexchange.com/questions/54841/birthday-attack-on-p2sh/54844
The aim of the following considerations is to help bitcointalkforum's users to understand better what (and why) LBC is doing. For this reason, I will make some simplifications, like 20M = 2^24 instead of 20M = 2^24.2535 and so on. In this context above all I care about the concepts. ************************************************************************************************************************************************************************************************* THE THEORY The theory: 1) Preimage search: given a hash H, find X such that Hash(X) = H. 2) Collision search: find an X and a Y, such that X != Y and Hash(X) = Hash(Y). These 2 problems look similar, but they are actually very different. In our context, X is a public key, H = hash160(X) is a bitcoin address: 1) Preimage search: given a particular address H, find a public key X such that hash160(X) = H. 2) Collision search: find two public keys X and Y, such that X != Y and hash160(X) = hash160(Y) . A preimage search for a 160-bit hash function needs 2^160 steps. A collision search however only needs 2^80 steps. Example of a preimage search: You choose a particular address H. Then you generate: 2^160 public keys Xi and store the corresponding addresses Hi = hash160(Xi) in a list L= {H1, H2, H3, .....H2^160} If they are all different, you will get surely a match between an Hi and the H you chose (Hi = H). So we say that there are needed 2^160 steps to find an Xi (a pre-image) of H=Hi. Note: Xi is only one preimage, since we don't know how H was generated, we can't say we have found a collision (we don't have two different public keys but only one that produces for sure H) Example of a collision search: Your purpose here is to find a couple ("collision" implies always at least two) of public keys X and Y that generate the same address H, any address H, you can't choose it. You generate: a list L1 of 2^80 random addresses Hi => L1= {H1, H2, H3, .....H2^80} where Hi = Hash160(Xi) and a list L2 of other 2^80 random addresses Aj => L2= {A1, A2, A3, .....A2^80} where Aj = hash160(Yj) "You sort both lists. Then you go through both lists, and find a hash that exists in both in a single iteration. This is the critical point. It is likely that such a collision exists, because even though there are only 2^80 entries in each list, there are 2^160 combinations of entries. Each of those has a 2^(-160) chance to be a collision. This is also the explanation of the Birthday Paradox, and such an attack is therefore called a birthday attack." (Wuille) So we say that there are needed 2^80 steps to find an Xi and Yj (a collision) such that Hi=Aj. If you noted, the difference between the first case (preimage) and the second one (collision) is that in the first case we are looking for something we chose, a particular address (in LBC we have the UTXO data set, we are assuming now for the sake of simplicity it is always the same during the research) and we get only one preimage (one public key), in the second case we find two public keys that correspond to a random address. To sum up, we can think at these 2 problems using 2 lists: preimage search: L1 = {H1, H2, H3, .....H2^160} --> you have to generate randomly 2^160 addresses -> 2^160 steps L2 = {H} --> H is the particular prefixed address you chose collision search: L1 = {H1, H2, H3, .....H2^80} --> you have to generate randomly 2^80 addresses L2= {A1, A2, A3, ..... A2^80} --> you have to generate randomly 2^80 addresses -> 2^80 steps (2^81 at the most) The fact that the number of the elements of the 2 lists in the second case is the same (this number is equal - more or less - to the square root of the number of the elements in L1 in the first case) makes less expensive to perform a collision search. This point is very important. A metaphor to visualize the difference between a preimage search (looking for a prefixed target using randomly generated elements) and a collision (a chance "encounter" between two elements of two random sequences): imagine you are in a room. 1) In that room there is a fixed target (a single point). If a fly moves randomly, what are the chances that it hit the target? Very low (this is a preimage, to hit a specific target using randomly generated addresses). 2) Now imagine that the target turns into another fly. Then we have two flies that move randomly in the room. What are the chances that one hit the other one? Much more. This is a collision. *************************************************************************************************************************************************************************************************+ ************************************************************************************************************************************************************************************************* THE CURRENT LBC APPROACH Ok, now how is the LBC's approach in relation to these two problems? To start, LBC performs a preimage search, where L2 contains not only 1 but 20M = (about) 2^24 addresses taken from the UTXO data set: preimage search: L1 = {H1, H2, H3, .....H2^160} --> we can think that it is randomly generated L2 = {A1, A2, ......, A2^24} --> UTXO data set, it is not randomly generated!!! in this case you can note that there are 2^160 * 2^24 combinations of entries, then we can reduce L1 from 2^160 to 2^136 addresses: L1 = {H1, H2, H3, .....H2^136} --> the addresses we have to generate to get a single preimage L2 = {A1, A2, ......, A2^24} --> the UTXO data set, these are "data", we don't have to compute these I repeat: we are taking care of a preimage search problem. In LBC project we call "collision" what actually is a "preimage". Infact our difficulty is nearer to 160 bit than 80 bit. We want to find preimages (public keys) only of some particular hashes (addresses from UTXO). Now imagine we find a preimage, i.e. we find a public key Xi such that Hi = Aj for some Aj in L2 (remember: Hi = hash160(Xi)) Then, only if we can prove that the public key Xi is different from the public key Yj that produces Aj, we can claim to have found a real collision too (usually we don't have Yj, how to get this information is a real problem) Only in this case we can go from a single preimage to two preimages and then get a real collision. ************************************************************************************************************************************************************************************************* ************************************************************************************************************************************************************************************************* SOME IDEA FOR THE FUTURE Can we improve the odds to find a preimage/collision? My guess: we should extend the L2 list (and extend the corresponding bloom filter to not rise the false positive rate, but this is a technical issue) Remember: if L2 becomes bigger, then L1 becomes smaller, and L1's size is the difficulty of our task (because: size_of_L1 = 2^160 / size_of_L2). L2's elements can be collected and stored easily, those of L1 don't, L1 is too big. To extend L2, we have these possibilities: 1) we wait for bitcoin's net grows up naturally 2) we generate a few random millions of addresses (but in this way we shift from a preimage search to a purely random collision search task) 3) we use addresses already generated and stored in blockchain even if they have no more bitcoin (always interesting for me; besides, if we find a preimage of one of these addresses, then we will know for sure if we have a collision too, because all the addresses with at least an output transaction have already exposed their public key) Narrow down the list L1 is a way to speedup our search, on the other hand we need to rise the speed at which we generate the list L1. Any idea is welcome. To speedup my ECC library I need to realize a couple of assembly functions. I don't know so much about assembly. If someone is able to help me, I will be happy. :) ************************************************************************************************************************************************************************************************* Title: Re: Large Bitcoin Collider Thread 2.0 Post by: dcw312 on November 01, 2017, 06:42:12 PM I like where you are going with expanding the search space because it puts the focus on proving the likelihood of collision. I think this is the interesting question.
Looking at all used addresses seems the simplest way to expand the search space because those addresses are publicly available. Has anyone seen a calculation on how many attempts it should take to have a high chance of finding a collision? (The binomial probably) I tried calculating it but the library I used wasn’t able to handle the large numbers. Title: Re: Large Bitcoin Collider Thread 2.0 Post by: arulbero on November 02, 2017, 09:39:47 AM Has anyone seen a calculation on how many attempts it should take to have a high chance of finding a collision? (The binomial probably) I tried calculating it but the library I used wasn’t able to handle the large numbers. This is a very interesting question, in the next days I will add a section called "Probability & LBC". Title: Re: Large Bitcoin Collider Thread 2.0 Post by: dcw312 on November 02, 2017, 10:29:15 PM From the LBC website: In the rare event of a collision, the funds on the address in question would become accessible to the collision finder.
I was confused about this earlier but I found my point of confusion. I'll add here in the hope it saves others some time. The public key is exposed when the sender (Alice) lists it as an input to a transaction. I thought that the public key could be compared to the previous transaction or another transaction. While there may be another transaction from Alice that identifies the full public key from her address, there is no verification that the same public key is being used for all transactions from her address. So if we find a key pair X2 that hash160(X1) == hash160(X2), the finder could transfer the money . Code: Input: Title: Re: Large Bitcoin Collider Thread 2.0 Post by: dcw312 on November 03, 2017, 03:08:08 AM in the next days I will add a section called "Probability & LBC". I was able to find this formula: p(different) ~ e^(n^2 / -2 * T) https://betterexplained.com/articles/understanding-the-birthday-paradox/ Which calculates the probability of avoiding a collision for a given search size (2^x) as: Code: search_range p_different with the following python code Code: import numpy as np Title: Re: 16000 trillion addresses, LBC Pot payout and Gkeys forfeiture Post by: arulbero on November 06, 2017, 02:39:50 PM Every time the LBC reaches a bit boundary in the search space (53 bits, 54 bits, ...) the current LBC pot will be distributed proportionally according to the Gkeys delivered among those who were active in the week before the LBC hits this boundary. This means, if you look at your Per-User statistics (e.g. https://lbc.cryptoguru.org/stats/__rico666__) at the time the LBC crosses this boundary, there can be no single 2h average point with 0 Mkeys/s or else you are not eligible - no matter how many Gkeys you have submitted so far. On the other hand, the speed in there (as long as it is above 0 Mkeys/s) does not have any influence on the payout - only your Gkeys delivered so far do. I feel like we are going to reach the next bit boundary of the search space. Maybe we are already in the week before the end of the 53 bits. Thanks to Unknownhostname. Title: Re: 16000 trillion addresses, LBC Pot payout and Gkeys forfeiture Post by: rico666 on November 06, 2017, 02:50:34 PM I feel like we are going to reach the next bit boundary of the search space. Maybe we are already in the week before the end of the 53 bits. Thanks to Unknownhostname. It's very well possible. Last time he managed to push pool performance to 2.5 Gkeys/s with CPUs only. This time he's back and has weapons of mass collision at his hands. Pool has 1.2 Gkeys/s already. The "one week before bit boundary" was exactly this. You can never know when you are "just one week before the bit boundary". Interestingly, if Unknownhostname overdoes it, he will not be eligible for LBC Pot distribution himself. Title: Re: 16000 trillion addresses, LBC Pot payout and Gkeys forfeiture Post by: arulbero on November 06, 2017, 03:09:48 PM Pool has 1.2 Gkeys/s already. The "one week before bit boundary" was exactly this. You can never know when you are "just one week before the bit boundary". Interestingly, if Unknownhostname overdoes it, he will not be eligible for LBC Pot distribution himself. If it were so, at the moment there would be only a few people currently active that could get the LBC Pot (at least in the top 30, from what I can see). And besides, If we could mantain a 1.5 Gkeys/s speed for 1 year, we would find #54, #55 and #56 by the end of 2018. EDIT: now we are almost at 2 Gkeys/s, #54 by the end of this year! :o And we will hit the next bit boundary in less than 4 days! At this speed, in the next 50 days we will generate as many addresses as we have been generating from the beginning of this project so far. Title: Re: Large Bitcoin Collider Thread 2.0 Post by: Hereticalsauce on November 07, 2017, 05:00:26 AM Unknown, what the heck are you running this project on?!
Title: Re: Large Bitcoin Collider Thread 2.0 Post by: rico666 on November 07, 2017, 07:44:01 AM Unknown, what the heck are you running this project on?! Join our Discord Chat and find out. (Mostly cloud services, pretty big iron machines with 80 - 220 Mkeys/s) Title: If LBC Pot payout was now Post by: rico666 on November 07, 2017, 09:16:45 AM If it were so, at the moment there would be only a few people currently active that could get the LBC Pot (at least in the top 30, from what I can see). it is so, and at the moment would look something like that: Eligible users: 5b8f5562ac3873408d26852d74434040 b8a357e43e373ac086bed2c374085298 kknd2017 __rico666__ likizjucdordvd UnimatrixONE _maxairz_ cagrund_ __ac0v__ 5dcb3e5d07a8ccdbc00912773ca806dd amthenia Rexikonn 735912756 Total blocks of eligible users: 2677768070 Satoshi in LBC Pot: 12274528 Distribution as follows: userid (share in total eligible blocks) -> share in LBC Pot in Satoshi Code: 5b8f5562ac3873408d26852d74434040 (0.003923506340114063724719818621184769000551) -> 48159.188429907598382857705820653840270795264928 Satoshi Now, this is only to demonstrate the Sub-Satoshi accuracy of the distribution script and which/how many users currently actually are eligible. The numbers may change, because I see users who still can make it into the list of eligible users as e.g. https://lbc.cryptoguru.org/stats/testing123 and also, I will let run the "Gkeys forfeiture reaper" script before the distribution script. While the Gkeys gained by the forfeiture of others will be recorded in a separate place, they will count for share computation. edit: And of course you need to have a BTC address set for payout, else cry (holy crap): UnimatrixONE would be eligible by activity, but has no BTC address set! __ac0v__ would be eligible by activity, but has no BTC address set! __rico666__ would be eligible by activity, but has no BTC address set! amthenia would be eligible by activity, but has no BTC address set! kknd2017 would be eligible by activity, but has no BTC address set! Total blocks of eligible users: 562942816 Satoshi in LBC Pot: 12274528 Distribution as follows: Code: 5b8f5562ac3873408d26852d74434040 (0.01869944815140868588684503258675566791495) -> 229526.8999190141543612841841470448749807553936 Satoshi Title: Re: Large Bitcoin Collider Thread 2.0 Post by: dcw312 on November 07, 2017, 03:20:44 PM On Rico's advise just now, I added a hook-find file because I am running in the cloud.
https://github.com/dcw312/lbc-client-docker/commit/15874d4dc14fdb48e92b3288ff98bd9645172c26 Rico suggested: Code: #!/bin/bash Mine sends to a queue that I would prefer not to share. Title: Re: 16000 trillion addresses, LBC Pot payout and Gkeys forfeiture Post by: rico666 on November 09, 2017, 07:21:44 AM There are a lot of dead/dormant accounts, who seem to just have tested LBC and then stopped colliding. And this is perfectly ok. On the other hand, I don't think it makes sense to keep these accounts around indefinitely as most of them have some single-digit Gkeys, but everyone started out small, so an automated cleanup mechanism should not immediately reap small accounts. This is what will happen: Starting with 53bit search space (which is due in about a month given current speed), accounts that have been inactive for (7 + Gkeys_delivered) days will be reaped and their Gkeys will be added proportionally to the other active accounts. Consider it a kind of Proof of Stake. ;) e.g. Account has delivered 5 Gkeys and is inactive. This account can be inactive for 12 days before it is reaped. Account has delivered 1000 Gkeys and is inactive. This account can be inactive for 1007 days before it is reaped. It's clear that accounts that did some serious colliding in the past with several thousand Gkeys do not have to fear to be reaped anytime soon. But I should point out that as speed of colliding rates changes over time, we may change this rule at some point in the future. (Imagine if the hardware/software in 5 years can give you 1Gkey/s then probably 1 Gkey will buy you 1 hour idle time. Or something like that) For now, 7 days idle time is ok for everyone, above that: 1Gkey = 1 day. The 53bit search space is nearing completion, and see below for the current forfeiture list. So in probably less than 24 hours accounts worth ~1300 Gkeys are going to be reaped and redistributed. If anyone sees an old account of his and wants it to be merged, ping me (Discord). Code: 07012014 - merits (13) < inactive days (61) Title: Re: Large Bitcoin Collider Thread 2.0 Post by: dcw312 on November 10, 2017, 01:09:11 AM At 10:48 PM Thursday (UTC), Rico announced on Discord that we crossed into the 54 bit search space.
Title: Some News Post by: rico666 on November 10, 2017, 09:43:37 AM New client 1.192 (see News in my sig for changes);
User 735912756 blacklisted for insane spamming. Note from the author: "If you start using AWS for your LBC efforts, please make sure your config is right or bear the consequences." also, the block forfeiture script ran, result can be inspected here: https://lbc.cryptoguru.org/static/logs/171110-forfeiture_run.log The acquired blocks are kept separate from the blocks you delivered (done by your work). You can see them in the "acquired"-field when doing ./LBC -q Code: {LBC Pot payout Code: # lbcadmin payout Title: Re: Large Bitcoin Collider Thread 2.0 Post by: David Rabahy on November 10, 2017, 02:39:34 PM How would I be able to tell if one of my addresses was collided?
Title: Re: Large Bitcoin Collider Thread 2.0 Post by: BurtW on November 10, 2017, 05:48:52 PM How would I be able to tell if one of my addresses was collided? I believe they will move your Bitcoins for you. Correct?Title: Re: Large Bitcoin Collider Thread 2.0 Post by: David Rabahy on November 10, 2017, 05:52:48 PM Ok, so, if I see some coins move then come here to reclaim them?
Title: Re: Large Bitcoin Collider Thread 2.0 Post by: rico666 on November 10, 2017, 08:51:05 PM Ok, so, if I see some coins move then come here to reclaim them? Yes. Or better yet - directly to our LBC Discord Chat: https://discord.gg/YjD2Sx where we can solve things more interactively. Title: Re: Some News Post by: dcw312 on November 11, 2017, 05:25:10 AM New client 1.192 (see News in my sig for changes); I found the cause of the spam. I was using Amazon EC2 Container Service. With the service you configure how many containers you want running at a time. I think I had it set for 8 "desired tasks". The service will deploy 8 containers, execute their entrypoint file, when a container/task stops running, it will start a new one in its place. I just ran the container locally by supplying "bash" as an override entrypoint. Code: Mac$ sh secret/run-local.sh At this point the container thinks it is done with it's task and stops. The service will replace it with a new container. This is also how Open Shift, Kubernetes, etc work. So there was just a "groundhog day" (Bill Murray movie) scenario. A fresh container would be made from the image. It would get the update, but think it was finished. I just reviewed the LBC -h help and see there already is a flag for update. I think I fixed in: https://github.com/dcw312/lbc-client-docker/issues/7 The entrypoint is now like this: Code: ./LBC --update Title: Re: Some News Post by: rico666 on November 11, 2017, 12:22:06 PM At this point the container thinks it is done with it's task and stops. The service will replace it with a new container. This is also how Open Shift, Kubernetes, etc work. So there was just a "groundhog day" (Bill Murray movie) scenario. A fresh container would be made from the image. It would get the update, but think it was finished. This explanation makes perfect sense, and yes, a preceding ./LBC -u solves that particular problem. On other topics. We did test yesterday the first AVX512-enabled generator, seems to bring a slight speedup compared with avx2 binaries (Haswell, Syklake) I'm looking into some other issues of the client and will make one more update to offer a skylake-avx512 generator "soon(tm)". Title: LBC website issue Post by: dcw312 on November 11, 2017, 03:30:35 PM Rico gave me a link to show the hooks documentation. It opened up a "secret manual" that I had never seen before!
Here is the problem with the website I am seeing. Steps to reproduce: 1. Click https://lbc.cryptoguru.org/man/user#hooks 2. Verify that you see the hooks information 3. Click trophies from the left bar 4. Click Manual from the left bar Expected behavior: The hooks documentation is visible Actual behavior: The hooks documentation is not visible on the page I am using Chrome on Mac. Can anyone else verify the problem? Title: Re: LBC website issue Post by: rico666 on November 11, 2017, 03:35:09 PM Rico gave me a link to show the hooks documentation. It opened up a "secret manual" that I had never seen before! ... Can anyone else verify the problem? To quote my answer: I seem to be old school When books were a thing Big technical books. Consisting of several "Parts" Clicking on manual reveals Parts I to IV Hooks are documented in Part II - User Manual Title: Re: Large Bitcoin Collider Thread 2.0 Post by: Pustul on November 12, 2017, 03:38:43 AM Hi, I stumbled across this project while researching math behind the process of generating BTC addresses. Very interesting project!
I was wondering if this will run on ARM cpus, I tried to set it up on a Raspberry Pi and I have an error during benchmarking: Code: Benchmark info not found - benchmarking... ./kardashev-generic: 1: ./kardashev-generic: Syntax error: ")" unexpected I have also tried to set it up on a mining rig I have and it works but I have this warning message when launching the script: Code: ./kardashev-sandybridge: /usr/local/cuda-8.0/targets/x86_64-linux/lib/libOpenCL.so.1: no version information available (required by ./kardashev-sandybridge) Still it is able to compute keys at 0.79 Mkeys/s (it's a AMD Athlon X2 340 ultra cheap cpu) but I guess it's complaining because the cpu is AMD? Title: Re: Large Bitcoin Collider Thread 2.0 Post by: rico666 on November 12, 2017, 09:05:55 AM I was wondering if this will run on ARM cpus, I tried to set it up on a Raspberry Pi and I have an error during benchmarking: ARM is not supported, only 64bit x86 compatible (x86_64 a.k.a. AMD64) Quote Code: ./kardashev-sandybridge: /usr/local/cuda-8.0/targets/x86_64-linux/lib/libOpenCL.so.1: no version information available (required by ./kardashev-sandybridge) Still it is able to compute keys at 0.79 Mkeys/s (it's a AMD Athlon X2 340 ultra cheap cpu) but I guess it's complaining because the cpu is AMD? No, it's complaining because your OpenCL installation is slightly broken. Reinstalling OpenCL helps. clinfo should work, if you have a Nvidia GPU, nvidia-smi should work, then you are probably good to go. The performance you see is because you run a CPU-only generator. In this project, you have to earn your merits and perks. One of them being to be allowed to use a GPU. Which comes after you delivered 3000 Gkeys CPU-only. Title: Re: Large Bitcoin Collider Thread 2.0 Post by: Pustul on November 13, 2017, 01:03:39 PM Quote Code: ./kardashev-sandybridge: /usr/local/cuda-8.0/targets/x86_64-linux/lib/libOpenCL.so.1: no version information available (required by ./kardashev-sandybridge) Still it is able to compute keys at 0.79 Mkeys/s (it's a AMD Athlon X2 340 ultra cheap cpu) but I guess it's complaining because the cpu is AMD? No, it's complaining because your OpenCL installation is slightly broken. Reinstalling OpenCL helps. clinfo should work, if you have a Nvidia GPU, nvidia-smi should work, then you are probably good to go. The performance you see is because you run a CPU-only generator. In this project, you have to earn your merits and perks. One of them being to be allowed to use a GPU. Which comes after you delivered 3000 Gkeys CPU-only. Oh ok I didn't realize it was complaining about OpenCL since it was running on CPU only mode. I will fix it when I get to enable the GPU. For the 3000 Gkeys I am working on it ;) Title: Re: Large Bitcoin Collider Thread 2.0 Post by: rico666 on November 13, 2017, 09:06:43 PM Oh ok I didn't realize it was complaining about OpenCL since it was running on CPU only mode. I will fix it when I get to enable the GPU. For the 3000 Gkeys I am working on it ;) It's a tribute to the unified generators (earlier we had different generators for CPU and GPU, now the binary supports both), it needs to dynamically link against a OpenCL library - but you can install a dummy one: https://github.com/OCL-dev/ocl-icd Most linux distributions have that as a package. Title: 20000 trillion addresses, new client, AVX512 generator later today Post by: rico666 on November 15, 2017, 07:38:24 AM The collider generated (and checked) over 10000 trillion keys, which is double the addresses.
I released a new version of the LBC client (1.195) - this fixes one or two bugs in Skylake and Skylake-avx512 detection. Everyone who has either a Skylake CPU or a Skylake-avx512 CPU should update to this version, because later today I plan to put the Skylake-avx512 generator binaries for download. If you do have a Skylake CPU and an older version than 1.195, your LBC will break by downloading a skylake-avx512 binary although you only have a skylake. Same applies if you have a Kaby Lake (as these are virtually the same as Skylakes and therefore want to use the same binary) Code: $ LBC -u Title: Re: Large Bitcoin Collider Thread 2.0 Post by: croxNN on November 15, 2017, 07:48:46 AM Guys, can you advice what is the best speed/price ratio from Core i5-i7 CPU family for launch LBC soft? Im going to participate and luckly it's time to upgrade my HW. Thanks.
Title: Re: Large Bitcoin Collider Thread 2.0 Post by: rico666 on November 15, 2017, 09:10:49 AM Guys, can you advice what is the best speed/price ratio from Core i5-i7 CPU family for launch LBC soft? Im going to participate and luckly it's time to upgrade my HW. Thanks. Depends on your budget. The https://ark.intel.com/products/123767/Intel-Core-i7-7820X-X-series-Processor-11M-Cache-up-to-4_30-GHz is a nice CPU with lots of potential. Seems a 1950X Threadripper is even better. Don't go for Vega{56,64} yet - lot's of trouble - AMD guys seem to need more time to provide sane drivers. If I was to choose some MAX configuration, still in reasonable reach for the well funded individual, I'd probably go for a 1950X system with two 1080Ti GPUs - should give me 90-100 Mkeys/s now and XXXXX in the future. If you want better price/performance ratio now, at the expense of less future potential, replace the 1080Ti with 1050Ti. Title: Re: Large Bitcoin Collider Thread 2.0 Post by: croxNN on November 15, 2017, 09:44:12 AM Guys, can you advice what is the best speed/price ratio from Core i5-i7 CPU family for launch LBC soft? Im going to participate and luckly it's time to upgrade my HW. Thanks. Depends on your budget. The https://ark.intel.com/products/123767/Intel-Core-i7-7820X-X-series-Processor-11M-Cache-up-to-4_30-GHz is a nice CPU with lots of potential. Seems a 1950X Threadripper is even better. Don't go for Vega{56,64} yet - lot's of trouble - AMD guys seem to need more time to provide sane drivers. If I was to choose some MAX configuration, still in reasonable reach for the well funded individual, I'd probably go for a 1950X system with two 1080Ti GPUs - should give me 90-100 Mkeys/s now and XXXXX in the future. If you want better price/performance ratio now, at the expense of less future potential, replace the 1080Ti with 1050Ti. Rico thanks for answer. Now I'm slecting MB and CPU only. Not GPUs. But I limited myself only with 1151 socket as 2066 CPUs/MBs overload my budget and also I don't like AMD. The second step will be GPUs but it's a little later. What you say about https://ark.intel.com/ru/products/126686/Intel-Core-i7-8700-Processor-12M-Cache-up-to-4_60-GHz with MB https://www.msi.com/Motherboard/B250-KRAIT-GAMING.html ? I'm not very familiar with modern HW so maybe there are better options. Any more advices ? Thanks. Title: Re: Large Bitcoin Collider Thread 2.0 Post by: rico666 on November 15, 2017, 11:32:04 AM Now I'm slecting MB and CPU only. Not GPUs. But I limited myself only with 1151 socket as 2066 CPUs/MBs overload my budget and also I don't like AMD. The second step will be GPUs but it's a little later. What you say about https://ark.intel.com/ru/products/126686/Intel-Core-i7-8700-Processor-12M-Cache-up-to-4_60-GHz with MB https://www.msi.com/Motherboard/B250-KRAIT-GAMING.html ? I'm not very familiar with modern HW so maybe there are better options. Any more advices ? Thanks. So you're from Russia - or so? ;-) Cannot speak for the mainboard - didn't even look it up. The CPU is ok, my guesstimate would be 5.5 Mkeys/s. Title: Re: Large Bitcoin Collider Thread 2.0 Post by: rico666 on November 15, 2017, 12:55:53 PM For everyone else to estimate speed:
A 4GHz Kaby Lake core does about 1 Mkeys/s A GPU client gives you a 7x speedup compared to a CPU-only client. (Now - soon this may be 14x) So let's say you have a quad-core Kaby Lake 4GHz and a GPU -> 28 Mkeys/s It's only a rough estimate, but should help you to assess what to expect from your hardware. Title: Re: Large Bitcoin Collider Thread 2.0 Post by: rico666 on November 15, 2017, 03:57:58 PM Rico, what about 2 or evern 3 GPUs and how it depend on GPU speed (how it's better to have 1080ti compared to some medium GPUs? does it have sence) ? Arulbero wrote already something about this topic in this thread (scroll back for "CPU limited", "GPU limited" situation). At the moment a 1080Ti maxes out with some 45 Mkeys/s a 1050Ti maxes out at some 37 Mkeys/s "maxes out" = GPU limited situation. The GPU can't deliver more. In this case - if your CPU is stronger - a 2nd GPU will help. Let's say you have a 14 core Haswell ~2GHz and two 1050Ti, then you will get around 70 - 74 Mkeys/s Theoretically, if you have a mainboard with two such Haswells and 4 x 1050Ti, you will get double that keyrate. Same with other GPU/CPU combinations. 7820X + 2 x 1080Ti gives you at the moment 85/86 Mkeys, because each 1080Ti maxes out at some 43 Mkeys/ with that CPU. I'm trying to find both time and funds to improve the generators (https://lbc.cryptoguru.org/crowdfunding), but interest is low, so for the time being we have to cope with these CPU/GPU limitations. Title: #54 Post by: rico666 on November 16, 2017, 11:11:26 AM LBC found the #54 of the puzzle transaction yesterday.
https://lbc.cryptoguru.org/trophies Title: Re: #54 Post by: BurtW on November 16, 2017, 01:13:13 PM LBC found the #54 of the puzzle transaction yesterday. Congrats! 0.54 BTC so about $4000 right now. I see your are estimating 40 to 135 days for the next one. Happy hunting!https://lbc.cryptoguru.org/trophies Title: Re: #54 Post by: adaseb on November 16, 2017, 08:09:03 PM LBC found the #54 of the puzzle transaction yesterday. https://lbc.cryptoguru.org/trophies Congrats on finding the private key. I don't think you know but you can also claim BitCore and Bitcoin GOLD with that private key. I see you or somebody already claimed Bitcoin Cash. I sweeped both your BitCore and BitcoinGold funds before somebody else got to it. Post a BitCore and BitcoinGold address in this thread and I will send them back to you. Here are those transaction ids https://chainz.cryptoid.info/btx/tx.dws?172551.htm http://btgexp.com/tx/f78617a5e6bf438c7a310639f6d8fe10c194a74be6ac98b2c329024a4d1df745 EDIT: Please post your addresses where you want the coins sent in the 32btc contest thread since its unmoderated. https://bitcointalk.org/index.php?topic=1306983 Thanks Title: Re: Large Bitcoin Collider Thread 2.0 Post by: croxNN on November 18, 2017, 07:06:27 PM Im trying to run LBC on my new 7820X:
$ ./LBC -x Will use 8 CPUs. Testing mode. Using page 0, turning off looping. Benchmark info not found - benchmarking... 'kardashev-skylake-avx512' not found/executable. LBC just downloaded .blf file but not kardashev-skylake-avx512. LBC version 1.195 Any suggestions what's wrong ? Title: Re: Large Bitcoin Collider Thread 2.0 Post by: rico666 on November 19, 2017, 08:19:11 AM Im trying to run LBC on my new 7820X: $ ./LBC -x Will use 8 CPUs. Testing mode. Using page 0, turning off looping. Benchmark info not found - benchmarking... 'kardashev-skylake-avx512' not found/executable. LBC just downloaded .blf file but not kardashev-skylake-avx512. LBC version 1.195 Any suggestions what's wrong ? Sure, 171110-beafd74c1e70cb254a6b3cfcc6e1f8d0.kardashev-skylake-avx512.bz2 was missing on the download server, because that would break all clients who do have a Skylake (sans the avx512) and still run a client < 1.195. I have uploaded the binary now, so it should run for you, and whoever does have a skylake and client < 1.195 might want to update now. Title: Re: #54 Post by: dlorah111 on November 19, 2017, 06:56:20 PM LBC found the #54 of the puzzle transaction yesterday. https://lbc.cryptoguru.org/trophies Congrats on finding the private key. I don't think you know but you can also claim BitCore and Bitcoin GOLD with that private key. I see you or somebody already claimed Bitcoin Cash. I sweeped both your BitCore and BitcoinGold funds before somebody else got to it. Post a BitCore and BitcoinGold address in this thread and I will send them back to you. Here are those transaction ids https://chainz.cryptoid.info/btx/tx.dws?172551.htm http://btgexp.com/tx/f78617a5e6bf438c7a310639f6d8fe10c194a74be6ac98b2c329024a4d1df745 EDIT: Please post your addresses where you want the coins sent in the 32btc contest thread since its unmoderated. https://bitcointalk.org/index.php?topic=1306983 Thanks I don't really get the trophy page of the LBC site. I can't see what the private key is they found. So what is the private key of the last address they found. #54?? Title: Re: #54 Post by: arulbero on November 19, 2017, 07:25:15 PM LBC found the #54 of the puzzle transaction yesterday. https://lbc.cryptoguru.org/trophies I don't really get the trophy page of the LBC site. I can't see what the private key is they found. So what is the private key of the last address they found. #54?? This sentence Quote The pool found a private key to cb66763cf7fde659869ae7f06884d9a0f879a092 (1KYUv7nSvXx4642TKeuC2SNdTk326uUpFy) as 0x236fb6d5ad1f43. At the time of the find, there were 0.54 BTC on that address. This is #54 of the puzzle transaction. means: private key: 0x236fb6d5ad1f43 (hex format) or KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjhHvuTMSDchRp5hktc (WIF format) address: cb66763cf7fde659869ae7f06884d9a0f879a092 (1KYUv7nSvXx4642TKeuC2SNdTk326uUpFy in base58) from private key to address: private key: 00000000000000000000000000000000000000000000000000236fb6d5ad1f43 public key: X = 4af4b81f8c450c2c870ce1df184aff1297e5fcd54944d98d81e1a545ffb22596 Y = 5f8151d32bd6771ea637e2c8328097d49d2498c3ddd4c76a81f2bad58944cd public key: 034af4b81f8c450c2c870ce1df184aff1297e5fcd54944d98d81e1a545ffb22596 (compressed format) ripemd160(sha256(public key)) = address = cb66763cf7fde659869ae7f06884d9a0f879a092 Title: Re: Large Bitcoin Collider Thread 2.0 Post by: rico666 on November 20, 2017, 07:20:10 AM When I run LBC on 8 physical cores - I got 8+Mkey/s, temp 60C and everything is stable. When I run on 16 hyper-threading cores I got 10+Mkey/s, temp 72C and server reboots in few hours without any notes in log file. Why can it happen and is it possible to avoid ? Thanks. I don't want this thread to become a heap of individual pseudo-interactive support. If you have problems with your LBC setup, or stability, or whatever that could require interactive support come to our Discord: https://discord.gg/AyEfZrY I will delete further utterances like "my speed is..." You can give that info on the Discord channel too, and I can use it and update https://lbc.cryptoguru.org/man/admin#references at some point. Title: Re: #54 Post by: ZeusLight on November 20, 2017, 01:38:51 PM LBC found the #54 of the puzzle transaction yesterday. https://lbc.cryptoguru.org/trophies I don't really get the trophy page of the LBC site. I can't see what the private key is they found. So what is the private key of the last address they found. #54?? This sentence Quote The pool found a private key to cb66763cf7fde659869ae7f06884d9a0f879a092 (1KYUv7nSvXx4642TKeuC2SNdTk326uUpFy) as 0x236fb6d5ad1f43. At the time of the find, there were 0.54 BTC on that address. This is #54 of the puzzle transaction. means: private key: 0x236fb6d5ad1f43 (hex format) or KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjhHvuTMSDchRp5hktc (WIF format) address: cb66763cf7fde659869ae7f06884d9a0f879a092 (1KYUv7nSvXx4642TKeuC2SNdTk326uUpFy in base58) from private key to address: private key: 00000000000000000000000000000000000000000000000000236fb6d5ad1f43 public key: X = 4af4b81f8c450c2c870ce1df184aff1297e5fcd54944d98d81e1a545ffb22596 Y = 5f8151d32bd6771ea637e2c8328097d49d2498c3ddd4c76a81f2bad58944cd public key: 034af4b81f8c450c2c870ce1df184aff1297e5fcd54944d98d81e1a545ffb22596 (compressed format) ripemd160(sha256(public key)) = address = cb66763cf7fde659869ae7f06884d9a0f879a092 Congrats!! is there any place where i can see other founded privkeys before this by LBC ? How many trophys are they ? Title: Re: Large Bitcoin Collider Thread 2.0 Post by: directoryio on November 20, 2017, 01:46:25 PM Hello would it be possible to have the source of the project to use offline (for personal purposes)?
Title: Re: Large Bitcoin Collider Thread 2.0 Post by: rico666 on November 20, 2017, 07:51:52 PM Hello would it be possible to have the source of the project to use offline (for personal purposes)? No. Title: Re: Large Bitcoin Collider Thread 2.0 Post by: jhdscript on November 20, 2017, 11:36:21 PM Great job boys. Congratulation ! #55 on the road :-)
Title: Re: Large Bitcoin Collider Thread 2.0 Post by: SanderM2 on November 21, 2017, 07:31:10 AM I have an "old" computer with a i7-3930K CPU.
Running LBC with the "--cpu 12" command gives me about 4.8MKeys/sec now. What kind of GPU would you recommend to speed things up and how much Mkeys/sec do you think I'll be able to get with it? Would it be worth using an NVIDIA GTX 1080TI or won't this one be faster compared to, let's say a GTX 1050 ? Title: Re: Large Bitcoin Collider Thread 2.0 Post by: directoryio on November 21, 2017, 08:32:01 AM LBC IS FAKE ATTENTION Can you tell us more about why you think that? Proof? my ip was banned because I manipulated the source code Do not run the client executable on any important computers, it might contain a rootkit. Unless the author of the scripts explains the purpose of these functions, I don't recommend trusting it. EDIT: corrected the username: rico666 -> therico666. REMOTE CODE EXECUTION BACKDOOR Code: if This is arbitrary code execution of whatever the server tells it to execute. EDIT4: The de-tamperproofing I initially posted is not sufficient. Although I obviously do not recommend running the script, you also need to change inside the h160_inject function: Code: eval This eval's an alternative piece of code that computes the md5 of the file. Probably just replace those lines with $quine. There might be more places it tries to calculate its own md5 hash as well. I don't like how user-hostile this program is, and I certainly don't like the blatant, deliberate, arbitrary remote code execution. I agree with OP: this program is malicious. EDIT5: There's more! Line ~157: Code: LWP::UserAgent So, in addition to executing whatever it gets told to execute, it doesn't even verify that it's talking to the right server? Anybody can MITM this program and inject their own arbitrary code to execute. Title: Re: Large Bitcoin Collider Thread 2.0 Post by: SanderM2 on November 21, 2017, 09:25:34 AM Right from the FAQ:
Quote 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. So your IP got blocked because you violated the rules. I do understand that the author needed to implement a way to make sure the data sent to the server is always valid. If not, the whole project is failing... You shouldn't be running this as root and you're still allowed to block all outgoing connections (except the server connection) in order to improve security on your side and prevent the author from abusing your client... Having this said I still think you're right about the fact that an MITM attack is possible. The client does indeed not seem to verify the SSL cert. I assume this is something he can add in a next release? I'm more concerned about the binaries that are actually doing the work which seem to be closed source. When I find the time I'll load them up in a disassembler in order to roughly find out what the hell they are up to .. Also the fact that we can't use GPU acceleration from the beginning is kind of strange. We're not allowed to use GPU acceleration unless we pay 0.1BTC (=$819 !!!) or get our first 3000GKeys done with a CPU, which takes a long time.... While this project stinks at many places I still believe it's not a fake one... Title: Re: Large Bitcoin Collider Thread 2.0 Post by: rico666 on November 21, 2017, 09:26:01 AM LBC IS FAKE ATTENTION Can you tell us more about why you think that? Proof? my ip was banned because I manipulated the source code Do not run the client executable on any important computers, it might contain a rootkit. Unless the author of the scripts explains the purpose of these functions, I don't recommend trusting it. EDIT: corrected the username: rico666 -> therico666. REMOTE CODE EXECUTION BACKDOOR ... So, in addition to executing whatever it gets told to execute, it doesn't even verify that it's talking to the right server? Anybody can MITM this program and inject their own arbitrary code to execute. @directoryio noob: You're beating a dead story to even more death. How is that even possible? Yes, modifying the code will get you banned. Yes, there is a RCE, but it's not more or less a "backdoor" than is the fucking javaScript in your fucking browser - which is also a RCE. (you have no problem with JavaScript in your browser, because you think it is sandboxed) It is explained - in detail and length - here: https://bitcointalk.org/index.php?topic=1877935.msg18665927#msg18665927 It is mentioned on the download page: https://lbc.cryptoguru.org/download And in the FAQ and and and I suggest you read and understand (a.k.a. "educate yourself") before you open up your yapper again. And also Code: verify_hostname => 0 is a code like 7 months ago, currently of course the verification is set to 1 The reason why it was at 0 in the 1st place, was simply the migration from HTTP to HTTPS and a time when there were both ports open and the client had to accept a non-SSL connection too. Pure hysteria, pure apeshit. I am really tired of these low-lifes who think they found a scandal, because they read some text of other low-lifes. edit: To elaborate on the "low-lifes". There are differences between a remote code execution, a backdoor, a rootkit. Mixing all these up while you go apeshit about a remote-code execution is just proving how clouded your brain must be. There is no single proof in the history of the LBC, that there was any root-kit in place. Rootkit means a remote attacker (in this case the LBC server - or me), would try to get access to your computer AND in addition elevate permissions to root/admin level. Backdoor means a way to gain access to the machine. This is also not happening. There is no shell opened, no login happens, there is not even any executable on the client machine - by definition - used to perform any operation. Remote Code Execution is exactly that - executing code on a remote machine. This is absolut neutral technology. As mentioned above, if you haven't disabled JavaScript in your browser - which I have 99,99% confidence you haven't - SAME STORY! If you of course visit some shady website that uses the javaScript to malevolently - say - abuse your browser to perform some mining or whatever without your consent, then THAT is a problem/attack. Nothing like that is happening with the LBC, has never happened and will not happen. Otherwise prove or shut up if you can't. Title: Re: Large Bitcoin Collider Thread 2.0 Post by: SanderM2 on November 21, 2017, 09:32:35 AM I agree with rico666 ...
verify_hostname is set to 1 already in my client. I didn't check myself before I posted my previous reply as I was just assuming directoryio was copy/pasting sources of the latest client version. So there's no risk for an MITM attack. Title: Re: Large Bitcoin Collider Thread 2.0 Post by: SanderM2 on November 21, 2017, 09:38:55 AM Now, can anyone tell me what to expect from GPU acceleration with an i7-3930K CPU?
Without a GPU I've got about 4.8MKeys/sec but I'm planning on adding a GPU. I can't do benchmarks myself yet because it doesn't allow doing benchmarks for the period I'm not gpu authorized. I need to wait until I get my 3000Gkeys (because I don't want to pay 0.1BTC or $810 for this permission...) I can have a GTX 1050 for this or a GTX 1080TI but if the 1080TI isn't going to be a lot faster compared to the 1050 I prefer to keep the 1080TI for other purposes... Title: Re: Large Bitcoin Collider Thread 2.0 Post by: rico666 on November 21, 2017, 09:44:25 AM Now, can anyone tell me what to expect from GPU acceleration with an i7-3930K CPU? Without a GPU I've got about 4.8MKeys/sec but I'm planning on adding a GPU. I can't do benchmarks myself yet because it doesn't allow doing benchmarks for the period I'm not gpu authorized. I need to wait until I get my 3000Gkeys (because I don't want to pay 0.1BTC or $810 for this permission...) I can have a GTX 1050 for this or a GTX 1080TI but if the 1080TI isn't going to be a lot faster compared to the 1050 I prefer to keep the 1080TI for other purposes... It's in the docs. Expect a 7x speedup from GPU. At the moment a 1080 will be only marginally faster than a 1050, but this will most likely change in the future when the generators become more "GPU-heavy". Title: Re: Large Bitcoin Collider Thread 2.0 Post by: SanderM2 on November 21, 2017, 09:50:10 AM Okay.
Is there a good reason why the benchmark code isn't allowed to use the GPU when not reached the 3000GKeys yet? It's only for benchmarking, right? It would allow me to know which video card to allocate for this purpose without having to wait and start using it as soon as my 3000GKeys are there... Are there any real plans already related to GPU acceleration? I've read about it that you want StreamHPC to do this work but that you need money in order to get this done. But according to blockchain nobody has helped funding this (yet) ? If GPU acceleration improvements aren't going to happen in a year or so I better use a 1050 I guess :) Title: Re: Large Bitcoin Collider Thread 2.0 Post by: rico666 on November 21, 2017, 09:54:39 AM Is there a good reason why the benchmark code isn't allowed to use the GPU when not reached the 3000GKeys yet? It's only for benchmarking, right? The very good reason - actually the best, definitive and divine reason is always time. This is a non-commercial, spare-time hobby project. You get what you paid for. There are 1000 things I am aware of, that could be improved. Title: Re: Large Bitcoin Collider Thread 2.0 Post by: SanderM2 on November 21, 2017, 10:14:36 AM I understand ;-) So I'll just have to wait....
One more question: I have currently installed it on an old linux installation that was already on this computer, but I want a new / clean install with a chroot environment etc... Can I just move LBC and all related files to the new disk without losing my current count of GKeys? Title: Re: Large Bitcoin Collider Thread 2.0 Post by: rico666 on November 21, 2017, 10:26:23 AM Can I just move LBC and all related files to the new disk without losing my current count of GKeys? The Gkeys are bound to id (and that is protected by secret) and stored on server. So yes, you can move the LBC client files, copy them to several machines, execute LBCs in parallel on several machines... Your current Gkeys remain. As long as you know your id and secret, you do not lose them. (except forfeiture if inactive, but that is a different story) Title: Re: Large Bitcoin Collider Thread 2.0 Post by: SanderM2 on November 22, 2017, 07:51:38 PM I have just copied over bench.pst, FOUND.txt, fund_h160.blf, kardashev-* and LBC to a different server and ran "./LBC -q --secret mysecret" but I get this back:
Server answer to 'query' is: { "nil" : "wrong secret" } What files am I missing? Title: Re: Large Bitcoin Collider Thread 2.0 Post by: SanderM2 on November 22, 2017, 08:07:18 PM Never mind. Figured it out :-)
But I just noticed our pool performance dropped from over 2000Mkeys/sec to only 600MKeys/sec... Title: Re: Large Bitcoin Collider Thread 2.0 Post by: rico666 on November 22, 2017, 10:09:07 PM Never mind. Figured it out :-) But I just noticed our pool performance dropped from over 2000Mkeys/sec to only 600MKeys/sec... From 2200 to 550 actually. One man who turns his machines on/off. ;-) Title: Re: Large Bitcoin Collider Thread 2.0 Post by: SanderM2 on November 23, 2017, 07:00:27 AM I said we lost 3/4 of the pool speed and that message got deleted.
What did I do wrong by writing that? Title: Re: Large Bitcoin Collider Thread 2.0 Post by: rico666 on November 23, 2017, 09:22:54 AM I said we lost 3/4 of the pool speed and that message got deleted. What did I do wrong by writing that? I reserve the right to remove Cpt. Obvious, low quality, low information content messages. Obviously I am still very benevolent, so do not push it. Title: Re: Large Bitcoin Collider Thread 2.0 Post by: hisslyness on November 24, 2017, 06:05:01 PM Hi, Is there anyway i can test too see if LBC client is working and reporting properly...
I have tried running the following to find the last puzzle address #54.. but it doesn't report a find ./LBC -c 3 -p '#x236fb6d5ad1040-#x236fb6d5ad1f49' and i have tried ./LBC -c 3 -p '1-2' Still no FOUND.txt file produced... Thanks Title: Re: Large Bitcoin Collider Thread 2.0 Post by: rico666 on November 24, 2017, 08:52:29 PM Hi, Is there anyway i can test too see if LBC client is working and reporting properly... ./LBC -x Quote I have tried running the following to find the last puzzle address #54.. but it doesn't report a find ./LBC -c 3 -p '#x236fb6d5ad1040-#x236fb6d5ad1f49' and i have tried ./LBC -c 3 -p '1-2' Still no FOUND.txt file produced... The range you're giving is way too small. I'm not sure LBC works correctly if you give it a range of some few dozens of individual keys. This ant shit is probably getting borked by rounding errors. LBC is made to check billions of keys, so don't try to navigate the USS Nimitz in your bath tub. Code: LBC -c 1 -p 9512381750-9512381800 is only 53 Mkeys and should work for #54. At least it does on my computer: Code: $ LBC -c 1 -p 9512381750-9512381800 Title: Re: Large Bitcoin Collider Thread 2.0 Post by: hisslyness on November 25, 2017, 10:34:31 AM ./LBC -x does display the 4 planted priv keys
We have tried it with 1 page and 1000 pages still no hit!... Loop off! Work on blocks [9512381750-9512381800] (53 Mkeys) Will use 2 CPUs. Estimated duration: 35.013005625s oo (2.02 Mkeys/s) [root@osboxes collider]# Another person on "discord" also tried and wasn't about to find anything. I am currently using the LBC appliance with VMware 14... Also wasn't able to run LBC as user: osboxes [osboxes@osboxes collider]$ ./LBC -x XS.c: loadable library and perl binaries are mismatched (got handshake key 0xdb80080, needed 0xde00080) However, executing as root user will work... Title: Re: Large Bitcoin Collider Thread 2.0 Post by: arulbero on November 25, 2017, 01:41:07 PM We have tried it with 1 page and 1000 pages still no hit!... Loop off! Work on blocks [9512381750-9512381800] (53 Mkeys) Will use 2 CPUs. Estimated duration: 35.013005625s oo (2.02 Mkeys/s) Try with a wider interval: Example: Code: $ ./LBC -c 1 -p 9512381750-9512381800 As you can see, in the first case the program computes 3 'o' (3*2^24 keys, about 50.3 Mkeys) instead of 53 Mkeys. In the second case it computes only 2 'o' (2*2^24 keys, about 33.4 Mkeys) instead of 53 Mkeys. In the third case it computes 8 'o' (8*2^24 keys, about 134 Mkeys) instead of 158 Mkeys. Maybe the rounding error is < number of cpus * 2^24 keys (I'm not sure). EDIT: if you try directly with the generator: Code: $ ./kardashev-skylake -I 00000000000000000000000000000000000000000000000000236fb6d5ad1f40 -c 10000 there are no problems. Title: Re: Large Bitcoin Collider Thread 2.0 Post by: hisslyness on November 25, 2017, 02:25:28 PM I have installed a fresh copy of CentOS instead of the ArchLinux LBC Appliance, and can confirm it is now working as expected!... Also, Min 2^24 per CPU according to rico666
Title: Re: Large Bitcoin Collider Thread 2.0 Post by: Hereticalsauce on November 27, 2017, 02:19:06 AM Please update the LBC performance spreadsheet with your keys/sec instead of this thread:
https://docs.google.com/spreadsheets/d/1n6rh-0fMVYPEd69cD-3YPcFlgJaxBNh_bZr94kQSvIs/edit?usp=sharing Title: Re: Large Bitcoin Collider Thread 2.0 Post by: adaseb on November 27, 2017, 09:43:19 PM Ok, I finally sold those Bitcore AND Bitcoin Gold coins from the 54th key.
I think I sold the BTG for around ~0.038 and the Bitcore was like $8 or so. So I will send over half as promised. However little did I know that Hitbtc sends BTC from Segwit addresses and my Electrum isn't upgraded yet. So I need to upgrade first before I can send over the BTC to you. So give me a few days to do so. Title: Re: Large Bitcoin Collider Thread 2.0 Post by: adaseb on December 03, 2017, 06:07:47 AM Ok done. Here is the transaction ID
https://blockchain.info/tx/1ec00c68cf375cec164271086cae7e8897302da299c7a6de5038f586c4b95823 Lets find the 55th number now! Title: Re: Large Bitcoin Collider Thread 2.0 Post by: itod on December 03, 2017, 07:40:36 PM Excuse me for not reading everything about LBC, but who found the keys corresponding to 0.161 - 0.256 BTC outputs range in the Puzzle transaction (https://blockchain.info/tx/08389f34c98c606322740c0be6a7125d9860bb8d5cb182c02f98461e5fa6cd15)? There are somehow derived from 0.001 to 0.054 private keys?
Title: Re: Large Bitcoin Collider Thread 2.0 Post by: BurtW on December 03, 2017, 07:46:10 PM Excuse me for not reading everything about LBC, but who found the keys corresponding to 0.161 - 0.256 BTC outputs range in the Puzzle transaction (https://blockchain.info/tx/08389f34c98c606322740c0be6a7125d9860bb8d5cb182c02f98461e5fa6cd15)? There are somehow derived from 0.001 to 0.054 private keys? Those were moved by the creator (of the puzzle) because they were redundant.Title: Re: Large Bitcoin Collider Thread 2.0 Post by: arulbero on December 03, 2017, 07:49:14 PM Excuse me for not reading everything about LBC, but who found the keys corresponding to 0.161 - 0.256 BTC outputs range in the Puzzle transaction (https://blockchain.info/tx/08389f34c98c606322740c0be6a7125d9860bb8d5cb182c02f98461e5fa6cd15)? There are somehow derived from 0.001 to 0.054 private keys? https://bitcointalk.org/index.php?topic=1306983.msg18765941#msg18765941 Title: Re: Large Bitcoin Collider Thread 2.0 Post by: itod on December 03, 2017, 07:55:14 PM Ah, thanks for clarification. It's obvious when you see the answer ;)
Title: Re: Large Bitcoin Collider Thread 2.0 Post by: holy_ship on December 06, 2017, 06:23:02 AM I do understand that the author needed to implement a way to make sure the data sent to the server is always valid. If not, the whole project is failing... Hello, guys! Just joined my modest 10Mkps to your great project. But I still have a couple of questions... 1. What perl program does when the collision is found? Only writes to file FOUND.txt? If I someone overlook/delete this file, nobody will even know that we found the key and the worst thing - this range should be marked as empty? :-\ 2. Is there any validation of results? Or just checking checksums of the program itself? Why not to compute each block's checksum (even simplest in couple of bytes) and send to server? Then make 10% of work-units overlap. If checksums do not match, sending to third client and marking ALL work from client with wrong checksum as undone and ban him if there were several badly processed blocks. For now it seems like we are sifting with too large sieve? ::) Title: Re: Large Bitcoin Collider Thread 2.0 Post by: rico666 on December 06, 2017, 01:10:54 PM 1. What perl program does when the collision is found? Only writes to file FOUND.txt? If I someone overlook/delete this file, nobody will even know that we found the key and the worst thing - this range should be marked as empty? :-\ See https://lbc.cryptoguru.org/man/user#hooks Quote 2. Is there any validation of results? Or just checking checksums of the program itself? Why not to compute each block's checksum (even simplest in couple of bytes) and send to server? Then make 10% of work-units overlap. If checksums do not match, sending to third client and marking ALL work from client with wrong checksum as undone and ban him if there were several badly processed blocks. For now it seems like we are sifting with too large sieve? ::) Some overlap happens already, although it's less than 2% Work is also being re-issued. Not sure what you mean by the "too large sieve". Rest assured, validation is working fine. Title: Re: Large Bitcoin Collider Thread 2.0 Post by: timisis on December 06, 2017, 01:22:55 PM Joining up!
Title: Re: Large Bitcoin Collider Thread 2.0 Post by: arulbero on December 06, 2017, 01:52:00 PM A number of people have raised this matter: how to read properly the FOUND.txt file?
I decided to share a little python script. First we generate a FOUND.txt file to make a test: Code: $ ./LBC -x Then you can use this python script, called "lbc_output.py": https://www.dropbox.com/s/q1sgc4gbb26vc99/lbc_output.py?dl=0 Copy the line of FOUND.TXT you are interested of and you get the result: Code: $ ./lbc_output.py 2d17543d32448acc7a1c43c5f72cd5be459ab302:u:priv:0000000000000000000000000000000000000000000000000000000000000001+0x5e What does the script? First it reads and parses the line. Then it computes the private key (it does the addition, in our example: 0000000000000000000000000000000000000000000000000000000000000001 + 0x5e) and using the ecc arithmetic it generates the public key. Then it generates the address (compressed or uncompressed) and checks if it matches with the address in FOUND.txt (in this case 2d17543d32448acc7a1c43c5f72cd5be459ab302). Finally it provides the private key in WIF format and the address b58 encoded. Title: Re: Large Bitcoin Collider Thread 2.0 Post by: holy_ship on December 07, 2017, 03:54:38 AM By the way, don't you think that starting from very beginning is a bad idea?
I guess most of us are hoping to discover abandoned wallets from early 2010-s. At that times harsh cryptofreaks didn't have fancy bitcoin-core software and generated private keys themselves. So, they at least have seen the result of RNG. And the secret key with 40 leading zeros looks very stupid. Yeah, I understand that any value from RNG has the same probability to occur, but still... Why not to move to middle of 256-bit range (or 2^160 - I'm not sure what exactly we are bruteforcing)? Title: Re: Large Bitcoin Collider Thread 2.0 Post by: holy_ship on December 07, 2017, 04:32:59 AM See https://lbc.cryptoguru.org/man/user#hooks Not sure what you mean by the "too large sieve". Thanks for the answer, rico666! English is not my native language. It seems to me that LBC now has rather weak control of clients (correctness of their checks and return of results). So the effect is: in list of Trophies we see far less records than it should be. Also the main sense and benefit of pool is sharing award between all members (proportionally to contribution). But now the single member takes everything (and can even not report the find!). Actually, I do not see any advantages of being member of LBC versus solo mode. Yeah, I've read the FAQ, but I totally disagree with the answer. The range of LBC is known (and I think it is not best). Solo "miner" can easily use another range without being a member of LBC. The point of this message is not "hey, everyone, run from LBC", but to make LBC better and possibly more popular. Title: Re: Large Bitcoin Collider Thread 2.0 Post by: rico666 on December 07, 2017, 04:51:42 AM See https://lbc.cryptoguru.org/man/user#hooks Not sure what you mean by the "too large sieve". Thanks for the answer, rico666! English is not my native language. It seems to me that LBC now has rather weak control of clients (correctness of their checks and return of results). So the effect is: in list of Trophies we see far less records than it should be. Also the main sense and benefit of pool is sharing award between all members (proportionally to contribution). But now the single member takes everything (and can even not report the find!). Actually, I do not see any advantages of being member of LBC versus solo mode. Yeah, I've read the FAQ, but I totally disagree with the answer. The range of LBC is known (and I think it is not best). Solo "miner" can easily use another range without being a member of LBC. The point of this message is not "hey, everyone, run from LBC", but to make LBC better and possibly more popular. No hard feelings, but I think you have still a lot to read and learn about the project and the concept and tech behind it. Most of your "suggestions" are result of being badly informed - really. Title: Re: Large Bitcoin Collider Thread 2.0 Post by: holy_ship on December 09, 2017, 10:43:48 AM rico666 thanks for not sending me to GTFO ;D Tried to read "What We Do" more attentive.
One question still remains: did you estimate required funds to make FPGA or ASIC clients for LBC? I guess ordinary bitcoin mining ASICs wouldn't be effective (or suitable at all)? Title: Re: Large Bitcoin Collider Thread 2.0 Post by: rico666 on December 09, 2017, 11:11:52 AM rico666 thanks for not sending me to GTFO ;D Tried to read "What We Do" more attentive. One question still remains: did you estimate required funds to make FPGA or ASIC clients for LBC? I guess ordinary bitcoin mining ASICs wouldn't be effective (or suitable at all)? ASICs - as the "Application-Specific" part suggests - are of use only for a very narrow usage case. Bitcoin miners have scrapyard value beyond BTC* mining. I asked http://www.orsoc.se/ what the cost of ASIC development might be about 2 months after launching the pool. ORSoC is/was the technology development company behind KnC and I thought it would be a good address to ask. Unfortunately never got any answer. I might try again. Bitcoin miners do a SHA256d essentially. The LBC does ECC, followed by hash160, followed by bloom filter lookup Now the hash160 is actually less demanding than SHA256d and if it was only for that, I'm pretty sure that hash160 ASICs could deliver more performance than SHA256d ASICs. The ECC however, requires 256bit multiplications and that is serious stuff taking up whole FPGA circuits. (at least until a few years ago) At the moment we do these ECC things on CPU and hash160 on GPU An ASIC doing hash160 and Bloom-filter lookup (512MB chips containing the BLF connected directly to the ASIC) I can imagine, but I can't imagine how to feed it with ECC data. ECC on ASIC I can't imagine, but then again, I am a VHDL, Verilog, FPGA, ASIC noob. It would certainly be good if we managed to establish at least some informal smalltalk with ORSoC (or similar) engineers about this. Title: Re: Large Bitcoin Collider Thread 2.0 Post by: rico666 on December 10, 2017, 02:07:53 PM We have now our own directory.io, clone as the original site seems to have gone.
Clicking on the directory.io in https://lbc.cryptoguru.org/stats leads to https://lbc.cryptoguru.org/dio/101091723026432 (or whatever the page at the time of the click is) I've enabled a rate limiter for all my beloved leechers out there, who still haven't understood how the page works. Then you can use this python script, called "lbc_output.py": https://www.dropbox.com/s/q1sgc4gbb26vc99/lbc_output.py?dl=0 Copy the line of FOUND.TXT you are interested of and you get the result: Code: $ ./lbc_output.py 2d17543d32448acc7a1c43c5f72cd5be459ab302:u:priv:0000000000000000000000000000000000000000000000000000000000000001+0x5e With the above, the reverse way is possible too: https://lbc.cryptoguru.org/dio/priv/5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEsreMQiR4w7 will take you to the page containing that privkey and the address. Title: Re: Large Bitcoin Collider Thread 2.0 Post by: andreyyv on December 17, 2017, 10:53:33 AM Hi! what is the -c in process? why they are diferent? ???
http://c2n.me/3Qpu2Gr Title: Re: Large Bitcoin Collider Thread 2.0 Post by: rico666 on December 17, 2017, 01:35:04 PM Client -> Generator challenge. To make sure the client is talking to a legit generator. Title: Re: Large Bitcoin Collider Thread 2.0 Post by: smmintl on December 17, 2017, 09:15:19 PM Total newb here when it comes to linux but please take a look at the attached image and let me know if I actually started the collider
https://i.imgur.com/BLSDMjc.png If it's started how can I see the FOUND.txt file in case something is found? Any suggestion is much appreciated. edit: also, does 1,8 Mkeys/s mean that I'm searching through 1,800,000 keys per second? Title: Re: Large Bitcoin Collider Thread 2.0 Post by: rico666 on December 18, 2017, 06:06:22 AM Total newb here when it comes to linux but please take a look at the attached image and let me know if I actually started the collider https://i.imgur.com/BLSDMjc.png If it's started how can I see the FOUND.txt file in case something is found? Any suggestion is much appreciated. edit: also, does 1,8 Mkeys/s mean that I'm searching through 1,800,000 keys per second? You started the collider and you are searching with 1 800 000 keys/second. you can see the file FOUND.txt in the same directory as the LBC client and look at is in a text editor, by doing Code: cat FOUND.txt Code: less FOUND.txt Title: Re: Large Bitcoin Collider Thread 2.0 Post by: smmintl on December 18, 2017, 08:21:25 AM Total newb here when it comes to linux but please take a look at the attached image and let me know if I actually started the collider https://i.imgur.com/BLSDMjc.png If it's started how can I see the FOUND.txt file in case something is found? Any suggestion is much appreciated. edit: also, does 1,8 Mkeys/s mean that I'm searching through 1,800,000 keys per second? You started the collider and you are searching with 1 800 000 keys/second. you can see the file FOUND.txt in the same directory as the LBC client and look at is in a text editor, by doing Code: cat FOUND.txt Code: less FOUND.txt Thank you very much! I'm currently looking for a vps to run this 24/7 with a better speed and should be around $50/month. Any suggestions? Title: Re: Large Bitcoin Collider Thread 2.0 Post by: SatoshíNackamoto on December 18, 2017, 07:09:39 PM There is always someone who has to try and break the stuff you make..
But, respect.. This is a very interesting project. Title: Re: Large Bitcoin Collider Thread 2.0 Post by: holy_ship on December 19, 2017, 02:40:36 AM Thank you very much! I'm currently looking for a vps to run this 24/7 with a better speed and should be around $50/month. Any suggestions? Google offers $300 "credit" for newcomers to their cloud services. The most efficient hardware is 8core/7.2GB will make 3.0-3.3 megakeys a second. One server costs $150 a month. So you'll have a free server for 2 months. I guess, buying a videocard to your own PC is much more funds-efficient. Actually, this project lacks a reasonable comparison of different cards. I'm not ready to buy a $1000 card like nvidia 2000, but it's totally unclear how would cheaper aftermarket cards behave. Also, ATI cards were always much stronger for mining, is it the same for LBC? ??? Title: Re: Large Bitcoin Collider Thread 2.0 Post by: smmintl on December 19, 2017, 06:59:59 AM Thank you very much! I'm currently looking for a vps to run this 24/7 with a better speed and should be around $50/month. Any suggestions? Google offers $300 "credit" for newcomers to their cloud services. The most efficient hardware is 8core/7.2GB will make 3.0-3.3 megakeys a second. One server costs $150 a month. So you'll have a free server for 2 months. I guess, buying a videocard to your own PC is much more funds-efficient. Actually, this project lacks a reasonable comparison of different cards. I'm not ready to buy a $1000 card like nvidia 2000, but it's totally unclear how would cheaper aftermarket cards behave. Also, ATI cards were always much stronger for mining, is it the same for LBC? ??? Thanks for the advice! I actually have a decent GPU but I can't use it as I'm not auth yet I think since I only started a couple days ago and my average speed is 1,8 Mkeys/s. I'll take a look at what Google has to offer, thanks again! Title: Re: Large Bitcoin Collider Thread 2.0 Post by: rico666 on December 19, 2017, 11:12:08 AM Actually, this project lacks a reasonable comparison of different cards. I'm not ready to buy a $1000 card like nvidia 2000, but it's totally unclear how would cheaper aftermarket cards behave. If you were on the Discord, you'd know by now, that the best cost-efficient GPU is a 1050Ti, where you can get for 150 bucks (or less) as much as 40 Mkeys/s with the right CPU. user glatzer44 is also doing some work to get more out of the higher-end cards which behave not as good in price/performance category. A small WX4100 also tops somewhere at 30 Mkeys/s, but costs double the 1050Ti. New ATI Vega64 ... are at the moment a monumental drama of misery. But there it's the software, the hardware should be great, so we wait. Title: Re: Large Bitcoin Collider Thread 2.0 Post by: andreyyv on December 20, 2017, 09:37:48 AM Hm... tested my RIG Cel G1840 and GTX 1060 3g and got from 1 core about 600k and 1 core with gpu about 2M.... :-\ with GPU load about 50%...... what is wrong? slow CPU? ???
and got 4.5M from 1 core laptop CPU i7-7500 with GTX 940m .... Title: Re: Large Bitcoin Collider Thread 2.0 Post by: bcoinmanager on December 20, 2017, 11:41:17 PM Could you make a software or other transformer to allow the use of bitcoin mining ASIC for the LBC? Things would really speed up with couple of antminers.
On the other hand, could one search for wallets by brute forcing the 12 phrase keywords? Title: Re: Large Bitcoin Collider Thread 2.0 Post by: bigvito19 on December 21, 2017, 11:06:13 PM Could you make a software or other transformer to allow the use of bitcoin mining ASIC for the LBC? Things would really speed up with couple of antminers. On the other hand, could one search for wallets by brute forcing the 12 phrase keywords? ASIC miners are only used for mining bitcoins and that's it, not cracking private keys. Title: Re: Large Bitcoin Collider Thread 2.0 Post by: BurtW on December 21, 2017, 11:41:03 PM On the other hand, could one search for wallets by brute forcing the 12 phrase keywords? The number of possible words for each of the 12 words is 2048 so the total number of 12 word combinations is: 204812 = 5.44452 x 1039 That is for the weaker 12 word seeds. I use the Trezor wallet which uses a 24 word seed so for my wallet the number of possible ways to select the 24 words is: 204824 = 2.96428 x 1079 Compare these numbers to the total number of Bitcoin addresses: 2160 = 1.46150 x 1048 and the total number of private/public key pairs: 2256 = 1.15792 x 1077 First, you see that you should really be using a 24 word seed and not a 12 word seed. Next, I believe the amount of work to go from the seed words to the xPriv then to the xPub then to the generated Bitcoin addresses is more than the amount of work LBC does to calculate the next private key [just a simple increment], the next public key [just add G to the previous public key], then to the Bitcoin address. So, going through all the possible 12 word seeds is "harder" than going through all the Bitcoin addresses on a Bitcoin addresses / second basis. Plus, after going through all the possible 12 word seeds you will only hit about 204812 / 2160 = 0.00000037253 % of all Bitcoin addresses. Title: Re: Large Bitcoin Collider Thread 2.0 Post by: BenitoM on December 25, 2017, 09:19:01 AM Salve! Do you have instructions for new setting GPU? On i7-4820K 3.7GHz I had 3.9 million keys. Plugged gf 1050ti and now have speed 22 million.
nvidia-smi shows 6 processes with 561MiB and 4 with 49MiB. Changing --cpus from 6 to 20 doesn't matter, speed is around 21-22 millions keys. Shouldn't be 35? nvidia-smi -pm 1 did nothing. With --cpus 6 I have GPU-Utilization 60% and CPU utilization 80%. So what is bottleneck? Temp is low (40C). Title: Re: Large Bitcoin Collider Thread 2.0 Post by: aurigae on December 27, 2017, 05:40:27 AM Interesting project. Any wallet miner asics work in progress yet?
Once this attracts real size io/hashpower, could get interesting rather quick lol One way to make it happen, how about a bounty pot bitcoiners/donors can donate to - would maybe motivate to mine it Title: Re: Large Bitcoin Collider Thread 2.0 Post by: holy_ship on December 27, 2017, 08:23:15 AM wallet miner asics work in progress yet? a bounty pot bitcoiners/donors can donate to The donation pot cannot collect couple of BTC for GPU development ::) ASIC development costs around $10-100MLN. The worst thing is - even if you get an investor with 100 megabucks, the chinese will steal your tech and start flooding the market with cheap clones. I guess, LBC (or it's clone projects) should go the BTC way - CPU-GPU-FPGA-ASIC... GPU is still immature, no FPGA. You want too much. Title: Re: Large Bitcoin Collider Thread 2.0 Post by: aurigae on December 27, 2017, 08:56:17 AM wallet miner asics work in progress yet? a bounty pot bitcoiners/donors can donate to The donation pot cannot collect couple of BTC for GPU development ::) ASIC development costs around $10-100MLN. The worst thing is - even if you get an investor with 100 megabucks, the chinese will steal your tech and start flooding the market with cheap clones. I guess, LBC (or it's clone projects) should go the BTC way - CPU-GPU-FPGA-ASIC... GPU is still immature, no FPGA. You want too much. 10-100m? well - whats that compared to the loot :) i guess its not about computation power anyways but IO. Dont have the means to test on a decent cluster - would love to do some benchmarking xD looking for a donor lol https://www.ebay.de/itm/HP-BladeSystem-C7000-16x-BL460c-Gen8-4096GB-RAM-32x-Xeon-E5-2660v2-10-Core/222609616134?hash=item33d4912d06:g:HtsAAOSw6VRaJlHk Title: Re: Large Bitcoin Collider Thread 2.0 Post by: pablito1989 on December 29, 2017, 11:13:16 PM I have a Intel(R) Xeon(R) CPU E3-1270 v6 @ 3.80GHz server and I want to do some tests with it..
Can anyone give me a step by step guide for install lbc on centos? I tried but I'm pretty noob with Linux OS. Thanks in advance P.S. Is that server good for this? Title: Re: Large Bitcoin Collider Thread 2.0 Post by: holy_ship on December 30, 2017, 05:54:33 AM 10-100m? well - whats that compared to the loot :) If you recover wallet with 79k BTC, the loot is more than 10-100m. But it is not abandoned. p.s. the "loot" is actually, not what you get from wallets, but what hunters are willing to pay for ASICs. It might be a larger sum, than actual finding. By the way, I've read that there was a lot of fraud with crowdfunding of ASICs. People payed and had to wait forever... Title: Re: Large Bitcoin Collider Thread 2.0 Post by: holy_ship on December 30, 2017, 06:41:33 AM I have a Intel(R) Xeon(R) CPU E3-1270 v6 @ 3.80GHz server and I want to do some tests with it.. Can anyone give me a step by step guide for install lbc on centos? I tried but I'm pretty noob with Linux OS. On 6core (12ht) server you'll get around 3-4 million keys a second. It is 0.1% of pools speed. For CentOS7 (if you are NOT root, but privileged user) If root remove sudo sudo rpm -vi http://dl.fedoraproject.org/pub/epel/7/x86_64/Packages/o/ocl-icd-2.2.11-2.el7.x86_64.rpm sudo yum -y install cpan perl openssl-devel wget make gcc bzip2 sudo cpan Log::Log4perl LWP::UserAgent Net::SSLeay LWP::Protocol::https Parallel::ForkManager Term::ReadKey JSON wget https://lbc.cryptoguru.org/static/client/LBC chmod 755 LBC ./LBC --cpus 12 -x nohup ./LBC --cpus 12 > logg & tailf logg answer yes on all questions of third line Title: Re: Large Bitcoin Collider Thread 2.0 Post by: peter_d on December 30, 2017, 01:49:21 PM Hi Rico,
I started being involved in LBC pool a few days ago, I got over 3000 Gkeys, and would like to try with GPU on a local machine and on AWS. If I do: Code: ./LBC -q --gpu I got: Code: OpenCL diganotics written. Is the threshold of 3000 Gkeys still used? My id is : peter_doe Regards, Title: Re: Large Bitcoin Collider Thread 2.0 Post by: peter_d on December 30, 2017, 06:45:14 PM Hi Rico, I started being involved in LBC pool a few days ago, I got over 3000 Gkeys, and would like to try with GPU on a local machine and on AWS. If I do: Code: ./LBC -q --gpu I got: Code: OpenCL diganotics written. Is the threshold of 3000 Gkeys still used? My id is : peter_doe Regards, Got a reply on discord, GPU is enabled now. Thanks Rico Title: Re: Large Bitcoin Collider Thread 2.0 Post by: ZafotheNinja on January 01, 2018, 01:43:05 PM The other thread is depreciated?
So, being new here in general as well as this thread I may just be ignorant but I have to ask. If the goal of this project is to find collisions and the best way to find one is if an "owner" comes forward claiming their wallet was stolen by LBC, then why is the LBC only searching addresses that have balances "up to 1 Satoshi"? Especially given that the average bitcoin holder has a balance of 2 bits (0.0002 btc)? I get the whole "we are searching for collisions, not trying to crack wallets" but it seems to me that you get just as many abandoned wallets with small balances as you do with large balances and that the ideal search space should be in the average balance range of 2 bits. (For that matter I would crank the number up to the 20-150 bit range considering that a guy with $20 or more in it is a lot more likely to seek out why his btc have gone missing) I have read the entire thread as well as have used the search box and Google, however I have yet to come to an answer for this seemingly obvious question. Edit: According to the "trophies" page the balances are 0.1 to 79 bits (0.00001 to 0.0079 btc) not 1 Satoshi? Regardless the question remains the same. Title: Re: Large Bitcoin Collider Thread 2.0 Post by: pablito1989 on January 04, 2018, 02:14:04 AM which company offer the best vps for lbc? (cost/effort)
What do you think about digitalocean high cpu droplets? Title: Re: Large Bitcoin Collider Thread 2.0 Post by: holy_ship on January 04, 2018, 05:18:01 PM DigiOcean highCPU seems to be ordinary dedicated CPUs, price is $160 for 8core.
Probably google's "preemptible instance" for $40/month is the winner (8core). Speed differs from 3.1 to 3.4 megakeys. Title: Re: Large Bitcoin Collider Thread 2.0 Post by: jhdscript on January 05, 2018, 12:31:38 AM Google cloud is the best but preemptive machines are killed when CPU rate is high :-(
Title: Re: Large Bitcoin Collider Thread 2.0 Post by: holy_ship on January 05, 2018, 03:42:09 AM That's a wrong statement. They are killed (with 30 seconds timeout) when there's demand from google itself.
So they live from several minutes to 24 hours. Title: Re: Large Bitcoin Collider Thread 2.0 Post by: BurtW on January 07, 2018, 04:20:51 PM The other thread is depreciated? You are confused. The bits mentioned on the trophies page refer to the search space, not Bitcoin value.So, being new here in general as well as this thread I may just be ignorant but I have to ask. If the goal of this project is to find collisions and the best way to find one is if an "owner" comes forward claiming their wallet was stolen by LBC, then why is the LBC only searching addresses that have balances "up to 1 Satoshi"? Especially given that the average bitcoin holder has a balance of 2 bits (0.0002 btc)? I get the whole "we are searching for collisions, not trying to crack wallets" but it seems to me that you get just as many abandoned wallets with small balances as you do with large balances and that the ideal search space should be in the average balance range of 2 bits. (For that matter I would crank the number up to the 20-150 bit range considering that a guy with $20 or more in it is a lot more likely to seek out why his btc have gone missing) I have read the entire thread as well as have used the search box and Google, however I have yet to come to an answer for this seemingly obvious question. Edit: According to the "trophies" page the balances are 0.1 to 79 bits (0.00001 to 0.0079 btc) not 1 Satoshi? Regardless the question remains the same. Here is what you need to know: 1 Bitcoin = 1 BTC 1 Satoshi = 0.00000001 BTC 1 BTC = 100,000,000 Satoshi On the statistics page here: https://lbc.cryptoguru.org/stats Quote keys per day: 282.21 tn total keys generated: 19498.14 tn pages on directory.io 152329.19 bn search space covered: 54.11 of 160 bits search space in 1y: 56.77 bits Means: tn = trillion bn = billion search space covered of 54.11 bits means LBC has tried 254.11 private keys (about 19,441,647,535,076,223) search space in 1y: 56.77 bits means at the current rate they will cover 256.77 private keys in the next year. On the trophies page you mentioned that "bit" was used. I only see one reference to the word "bit" and it is: Quote A manual revisit of the 38-42 bit search space revealed these private keys Which simply means they were searching private keys with values from 238 through 242 Where are you getting your very confusing definition of "bit", trying to make it equal to 0.0001 BTC ? I have never seen that in all my years. There was a push to call one millionth of a BTC a "bit" in the distant past. But that really is not what you are talking about here. Are you trying to use the antiquated definition of 1 bit = $0.125 ? That would be really strange. Title: Re: Large Bitcoin Collider Thread 2.0 Post by: Jude Austin on January 07, 2018, 06:37:21 PM Just curious, can this https://github.com/basil00/pairgen contribute to LBC in a way?
Thanks, Jude Title: Re: Large Bitcoin Collider Thread 2.0 Post by: arulbero on January 07, 2018, 08:36:45 PM Just curious, can this https://github.com/basil00/pairgen contribute to LBC in a way? That program uses the Pollard rho algorithm (a probabilistic algorithm) to find a collision between any 2 addresses. LBC checks all the private keys from 1 to 2^134 to find a collision with an address with bitcoin. The 2 ways are very different. Title: Re: Large Bitcoin Collider Thread 2.0 Post by: 18fdmtTHAS on January 08, 2018, 03:42:13 AM Guys, sorry for being noob, but what does this mean:
Code: Ask for work... got blocks [18607002461-18607006172] (3892 Mkeys) Does this mean my client will search in this range [18607002461-18607006172]? I believe this range is < 2^35; while LBC is already done with 2^54? I'm searching on the already searched space? I run LBC with this command: Code: sudo ./LBC --address xxx --id xxx --secret xxx --cpus 8 Is there anything wrong? Thank you so much. Title: Re: Large Bitcoin Collider Thread 2.0 Post by: holy_ship on January 08, 2018, 06:21:14 AM >Is there anything wrong
Megakeys means millions of keys. 18607006172-18607002461=3711 Title: Re: Large Bitcoin Collider Thread 2.0 Post by: 18fdmtTHAS on January 08, 2018, 08:44:45 AM >Is there anything wrong Megakeys means millions of keys. 18607006172-18607002461=3711 Thanks, but what is the relation between 3892 Mkeys and 3711 Mkeys? Did you mean the LBC client is searching in the range [18607002461x10^6-18607006172x10^6]? Sorry for being ignorant :( --- Edit: Okay I got this: https://lbc.cryptoguru.org/man/user Quote pages/blocks The parameter is called "pages", for historic reasons. A page (sometimes also called a "block") contains 2^20 (1048576) private keys. The history of LBC dates back to directory.io, where 128 private keys are listed on one page. As our "pages" do have 1048576 keys and therefore each represents "8192 directory.io pages", we started to call pages blocks. You remember: pages=blocks 3711 block, each contains 2^20 key (the output has oooooo.. but I don't understand why they are not fat block) -> 3892M keys Title: Re: Large Bitcoin Collider Thread 2.0 Post by: bxmath on January 11, 2018, 08:45:15 PM It's easy, the difference is because you're assuming 1 Block = 1,000,000 but it's actually 1,048,576.
So 3711 blocks * 1,048,576 = 3,891,265,536 Basically 3892 MKeys. Hope that helps. Title: Re: Large Bitcoin Collider Thread 2.0 Post by: ZafotheNinja on January 16, 2018, 04:28:35 AM -Snip- https://bitcointalk.org/index.php?topic=406312.0 Yes, I was referring to the value of the wallets in btc, not the difficulty of finding a working key for them. This is why I mentioned "balances" several times and specified 0.0001 btc whenever I used the somewhat uncommon term "bit" or "bits". None of your rant actually answered my question? Title: Re: Large Bitcoin Collider Thread 2.0 Post by: rud3boy on January 17, 2018, 07:37:56 PM Hey Rico,
could you pls enable --gpu auth for my ID 785872e03932a91cb17634861c6b6c31 THX in advance Title: Re: Large Bitcoin Collider Thread 2.0 Post by: BurtW on January 17, 2018, 08:04:57 PM So, being new here in general as well as this thread I may just be ignorant but I have to ask. If the goal of this project is to find collisions and the best way to find one is if an "owner" comes forward claiming their wallet was stolen by LBC, then why is the LBC only searching addresses that have balances "up to 1 Satoshi"? Especially given that the average bitcoin holder has a balance of 2 bits (0.0002 btc)? I get the whole "we are searching for collisions, not trying to crack wallets" but it seems to me that you get just as many abandoned wallets with small balances as you do with large balances and that the ideal search space should be in the average balance range of 2 bits. (For that matter I would crank the number up to the 20-150 bit range considering that a guy with $20 or more in it is a lot more likely to seek out why his btc have gone missing) I have read the entire thread as well as have used the search box and Google, however I have yet to come to an answer for this seemingly obvious question. Edit: According to the "trophies" page the balances are 0.1 to 79 bits (0.00001 to 0.0079 btc) not 1 Satoshi? Regardless the question remains the same. OK, so now that I know you are using the archaic term "bit" to mean $0.125 I can answer your question. You are saying why not look at addresses that have a least a "bit" (at least $0.125) of money in them. But LBC is searching for addresses that have "up to 1 Satoshi" (should be "at least 1 Satoshi") in them. Since by definition 1 Satoshi is 0.00000001 BTC, at today's price of about $10,000 USD/BTC 1 Satoshi is worth about $0.0001. So there you have it. LBC is searching for addresses that contain at least $0.0001, you want to look for addresses with at least $0.125, therefore LBC is doing more than you are asking for. Did I answer your question? Title: Re: Large Bitcoin Collider Thread 2.0 Post by: Greko81 on January 28, 2018, 03:29:39 PM A number of people have raised this matter: how to read properly the FOUND.txt file? I decided to share a little python script. First we generate a FOUND.txt file to make a test: Code: $ ./LBC -x Then you can use this python script, called "lbc_output.py": https://www.dropbox.com/s/q1sgc4gbb26vc99/lbc_output.py?dl=0 Copy the line of FOUND.TXT you are interested of and you get the result: Code: $ ./lbc_output.py 2d17543d32448acc7a1c43c5f72cd5be459ab302:u:priv:0000000000000000000000000000000000000000000000000000000000000001+0x5e What does the script? First it reads and parses the line. Then it computes the private key (it does the addition, in our example: 0000000000000000000000000000000000000000000000000000000000000001 + 0x5e) and using the ecc arithmetic it generates the public key. Then it generates the address (compressed or uncompressed) and checks if it matches with the address in FOUND.txt (in this case 2d17543d32448acc7a1c43c5f72cd5be459ab302). Finally it provides the private key in WIF format and the address b58 encoded. hi please specify after running the scrypt in phyton window where exactly to @Copy the line of FOUND.TXT you are interested of and you get the result@ ??? :) :) please can you post more details photos on process? ps I am running phyton app under mac Title: Re: Large Bitcoin Collider Thread 2.0 Post by: kranium5 on January 29, 2018, 08:21:24 AM Title: Re: Large Bitcoin Collider Thread 2.0 Post by: arulbero on February 09, 2018, 04:40:04 PM Curious though if the LBC lets you search for the private key of a specific address, namely, the one to which my coins were inadvertently sent. They are just sitting there. If I know that the first 4 characters are the same as the address for which I have the privkey, does that do anything to narrow the scope or increase my chances? No. Searching for a specific address is quite equivalent to search against all addresses with bitcoin. If you know the first 4 characters, again you cannot take advantage from this fact. You could use vanitygen and store all addresses that match with the first 4 characters. But your chances to find a private key for that specific address will remain always 1 over 2^160. LBC software could be useful only if you would know a (consistent) part of a private key of a specific address. Informations only about the address are useless. Title: Re: Large Bitcoin Collider Thread 2.0 Post by: therealbtcdave on February 09, 2018, 06:53:55 PM Is this code open source and how could I get access? In the first post you have a link to https://svn.cryptoguru.org/ which looks like an SVN server but it requires credentials as you mentioned.
Thanks Title: Re: Large Bitcoin Collider Thread 2.0 Post by: ViperGuyMike on March 04, 2018, 05:59:00 AM Hey everyone, I have been following and studying the project for a couple weeks and finally finished my new Linux rig tonight and joined the pool. Although I am a long way from it, I had a question or two about the payout system. It seems as though I read somewhere that only members in the top30 would be included in the payouts, but I cant find anything about that now that I am searching for it? Is everyone included in the payout provided they haven't had a 2 hour window with 0 k/s in the previous week, and all their info is correct and updated? If anyone has a link or clarification, I would appreciate it. Working towards my 3000 keys now so I can point my mining rig at it for a while and see how much the CPU can handle with 6 cards behind it ;D
Title: Re: Large Bitcoin Collider Thread 2.0 Post by: rosengold on April 06, 2018, 06:42:56 PM The Bitcoin Colider it's a great ideia. this is why i made my own: http://youtube.com/watch?v=VAo7qgrbAqw
I found some addresses with balance but the privkey ins't the real one :P I think it's because I'm using an old colision curve algo, I'll keep it updated. Long Life this New "pool" way ;D Title: Re: Large Bitcoin Collider Thread 2.0 Post by: Marcel555 on April 07, 2018, 10:13:08 AM By the way, don't you think that starting from the beginning is not a good idea?
I guess most of us are hoping to discover abandoned wallets from early 2010-s. At that times harsh cryptofreaks didn't have fancy bitcoin-core software and generated private keys themselves. So, they at least have seen the result of RNG. And the secret key with 40 leading zeros looks very stupid. Yeah, I understand that any value from RNG has the same probability to occur, but still... Why not to move to middle of 256-bit range (or 2^160 - I'm not sure what exactly we are bruteforcing)? Title: Re: Large Bitcoin Collider Thread 2.0 Post by: HappyS on May 06, 2018, 09:09:17 AM Rico, can i ask you to enable a GPU script for my worker? i want to kompare 1080 w5100 and grid k2 :D
Title: Re: Large Bitcoin Collider Thread 2.0 Post by: anunnaki1202 on August 30, 2018, 06:08:58 PM Am trying to run the LBC and got stuck on see below please
$ wget http://ftp://ftp.cryptoguru.org/LBC/client/LBC --2018-08-30 17:30:44-- http://ftp://ftp.cryptoguru.org/LBC/client/LBC => ‘LBC.1’ Resolving ftp.cryptoguru.org (ftp.cryptoguru.org)... 92.43.104.60 Connecting to ftp.cryptoguru.org (ftp.cryptoguru.org)|92.43.104.60|:21... connected. Logging in as anonymous ... Logged in! ==> SYST ... done. ==> PWD ... done. ==> TYPE I ... done. ==> CWD (1) /LBC/client ... done. ==> SIZE LBC ... 63819 ==> PASV ... couldn't connect to 192.168.1.200 port 59530: No route to host And I want to set it to search alone as random And I want settings for pool as well please And the keys conversion to WIF how we do ? Title: Re: Large Bitcoin Collider Thread 2.0 Post by: anunnaki1202 on September 01, 2018, 10:04:39 AM I think I got it open with the command ./LCB -h but not accepting any more commands
Code: anunnaki1202@Anunnaki:~$ ./LBC -h then any of commands i give to register my username with this ./LBC -id annunaki1202 then reply with Code: anunnaki1202@Anunnaki:~$ ./LBC -id anunnaki1202 or any other command will give different error please help if anyone knows what is going on actually I got a test going on fine look below on ./LBC -x command Code: anunnaki1202@Anunnaki:~$ ./LBC -x now when i give the command perl LBC -x I get reply as another error see below please Code: anunnaki1202@Anunnaki:~$ perl LBC -x any suggestions what options I got left to try ? Title: Re: Large Bitcoin Collider Thread 2.0 Post by: snosj on September 06, 2018, 11:42:50 AM Please expplain to me:
- I run LBC on approx 150 nvidia 1050 cards, at work - I have custom way of selecting the range to scan using lbc parameters - I am running for over a year now - Today my equippement found key for 1CuSHEw7nerhLSwc4guXXdEvwLim58QnZ3. Big address! - I checked but everything moved half hour after my LBC found it??? Is LBC a scam? How is this possible. So much coinsidence. Half an hour later it is emptied!! Title: Re: Large Bitcoin Collider Thread 2.0 Post by: arulbero on September 06, 2018, 04:38:32 PM Please expplain to me: - I run LBC on approx 150 nvidia 1050 cards, at work - I have custom way of selecting the range to scan using lbc parameters - I am running for over a year now - Today my equippement found key for 1CuSHEw7nerhLSwc4guXXdEvwLim58QnZ3. Big address! - I checked but everything moved half hour after my LBC found it??? From the blockchain I see that the address 1CuSHEw7nerhLSwc4guXXdEvwLim58QnZ3 has the public key Code: compress format: 02b009e153bd0df7fd2856ffbcbb71020bd69fbea49b20f7cd0b40e0ae98ff2486 Did you find the private key relative to the public key "02b009e153bd0df7fd2856ffbcbb71020bd69fbea49b20f7cd0b40e0ae98ff2486"? Or did you find just a collision (different public key <--> same address) ? To check this fact, you can run my script https://www.dropbox.com/s/q1sgc4gbb26vc99/lbc_output.py?dl=0 (see here (https://bitcointalk.org/index.php?topic=1877935.msg25852487#msg25852487) how to run it ) Title: Re: Large Bitcoin Collider Thread 2.0 Post by: rico666 on September 07, 2018, 06:41:24 AM Please expplain to me: - I run LBC on approx 150 nvidia 1050 cards, at work - I have custom way of selecting the range to scan using lbc parameters - I am running for over a year now - Today my equippement found key for 1CuSHEw7nerhLSwc4guXXdEvwLim58QnZ3. Big address! - I checked but everything moved half hour after my LBC found it??? Is LBC a scam? How is this possible. So much coinsidence. Half an hour later it is emptied!! If you use LBC on 150 nvidia 1050 cards, you should have a keyrate of at least 3.75 GKeys/s which is more than 10 times what the whole LBC pool has now (~ 300Mkeys/s): https://lbc.cryptoguru.org/stats Given the fact that the LBC sees nothing of your keyrate, your clients - however you may operate them - do not even communicate with the server. So as far as I am concerned, whatever it is you do it is completely unrelated to LBC. On a personal note, I find it slightly asocial to take the software and not to contribute to the pool, so feel free to think of LBC being a scam and stop using the software. Title: Re: Large Bitcoin Collider Thread 2.0 Post by: snosj on September 07, 2018, 07:10:49 AM From the blockchain I see that the address 1CuSHEw7nerhLSwc4guXXdEvwLim58QnZ3 has the public key Code: compress format: 02b009e153bd0df7fd2856ffbcbb71020bd69fbea49b20f7cd0b40e0ae98ff2486 Did you find the private key relative to the public key "02b009e153bd0df7fd2856ffbcbb71020bd69fbea49b20f7cd0b40e0ae98ff2486"? Or did you find just a collision (different public key <--> same address) ? To check this fact, you can run my script https://www.dropbox.com/s/q1sgc4gbb26vc99/lbc_output.py?dl=0 (see here (https://bitcointalk.org/index.php?topic=1877935.msg25852487#msg25852487) how to run it ) It is different public key. Is this first real collision? Title: Re: Large Bitcoin Collider Thread 2.0 Post by: arulbero on September 07, 2018, 07:39:05 AM From the blockchain I see that the address 1CuSHEw7nerhLSwc4guXXdEvwLim58QnZ3 has the public key Code: compress format: 02b009e153bd0df7fd2856ffbcbb71020bd69fbea49b20f7cd0b40e0ae98ff2486 Did you find the private key relative to the public key "02b009e153bd0df7fd2856ffbcbb71020bd69fbea49b20f7cd0b40e0ae98ff2486"? Or did you find just a collision (different public key <--> same address) ? To check this fact, you can run my script https://www.dropbox.com/s/q1sgc4gbb26vc99/lbc_output.py?dl=0 (see here (https://bitcointalk.org/index.php?topic=1877935.msg25852487#msg25852487) how to run it ) It is different public key. Is this first real collision? Same address and different public key? Yes. Could you post only your public key? Title: Re: Large Bitcoin Collider Thread 2.0 Post by: itod on September 07, 2018, 11:03:16 AM ... Or did you find just a collision (different public key <--> same address) ? ... It is different public key. Is this first real collision? Same address and different public key? Yes. Could you post only your public key? ... Guys, there are no collisions. There never was, if there were Bitcoin would go to the ground. How long do you need to understand this fact? Never assume a collision, always assume you are doing something wrong without understanding what you are talking about. The point of this whole thing is to prove this fact, and it has been proven over and over again. Until you have any kind of proof please do not use the "collision" word, you just make yourself look bad. Title: Re: Large Bitcoin Collider Thread 2.0 Post by: arulbero on September 07, 2018, 11:56:46 AM Guys, there are no collisions. There never was, if there were Bitcoin would go to the ground. How long do you need to understand this fact? There are about 2^96 different public keys for each address. 2^160 addresses times 2^96 public keys = 2^256 public keys. Title: Re: Large Bitcoin Collider Thread 2.0 Post by: rico666 on September 07, 2018, 12:06:21 PM Guys, there are no collisions. ... Until you have any kind of proof please do not use the "collision" word, you just make yourself look bad. I believe the use of the word collision with a question mark after it is allowed - if you're kind enough to allow it sir. Of course there are collisions we just have no definitive proof (2 different privkeys resulting in 1 pubkey). Mathematically there must be collisions because you are not able to map a 2^256 bit space onto a 2^160bit space collision-free. That is impossible and in this light your skepticism makes you look bad. Because there must be - in fact - for every single public key around 2^96 private keys resolving in that public key. All this results in 2^256 - 2^160 "superfluous" private keys and we "just" need to find one colliding pair. Summary: There are collisions and everyone claiming otherwise simply doesn't understand the math behind this. The legit question may be if/how to find these efficiently or if that is possible at all, but doesn't change the fact about their existence. Title: Re: Large Bitcoin Collider Thread 2.0 Post by: arulbero on September 07, 2018, 12:06:53 PM It is different public key. Is this first real collision? If you look here (https://www.blockchain.com/btc/tx/05b580a46410bd373a8408dd3775abde66ce9833f753af28cdeeabaec6de028f?show_adv=true) you can see that who signed that transaction has used the public key 02b009e153bd0df7fd2856ffbcbb71020bd69fbea49b20f7cd0b40e0ae98ff2486. You claim that you found a different public key, that means nobody has stolen your private key. Title: Re: Large Bitcoin Collider Thread 2.0 Post by: rico666 on September 07, 2018, 12:09:03 PM If you look here (https://www.blockchain.com/btc/tx/05b580a46410bd373a8408dd3775abde66ce9833f753af28cdeeabaec6de028f?show_adv=true) you can see that who signed that transaction has used the public key 02b009e153bd0df7fd2856ffbcbb71020bd69fbea49b20f7cd0b40e0ae98ff2486. You claim that you found a different public key, that means nobody has stolen your private key. If all this proves to be true - we would look at a hash160 collision - yes? Title: Re: Large Bitcoin Collider Thread 2.0 Post by: arulbero on September 07, 2018, 12:13:03 PM If you look here (https://www.blockchain.com/btc/tx/05b580a46410bd373a8408dd3775abde66ce9833f753af28cdeeabaec6de028f?show_adv=true) you can see that who signed that transaction has used the public key 02b009e153bd0df7fd2856ffbcbb71020bd69fbea49b20f7cd0b40e0ae98ff2486. You claim that you found a different public key, that means nobody has stolen your private key. If all this proves to be true - we would look at a hash160 collision - yes? Yes, we would have a (sha256 + ripemd160) collision. That's why I hope he will post his public key. Title: Re: Large Bitcoin Collider Thread 2.0 Post by: rico666 on September 07, 2018, 12:14:02 PM By the way: the private key for https://www.blockchain.com/btc/address/1LzhS3k3e9Ub8i2W1V8xQFdB8n2MYCHPCa
is 000000000000000000000000000000000000000000000000006abe1f9b67e114 Title: Re: Large Bitcoin Collider Thread 2.0 Post by: anunnaki1202 on September 07, 2018, 06:05:43 PM Now that's a clever move rico666 :) who can decode that key :) only you
snosj do not have any privkey for that address he says he has .. because he needs to decompress the key what LBC find and he doesn't run LBC Title: Re: Large Bitcoin Collider Thread 2.0 Post by: anunnaki1202 on September 07, 2018, 06:52:37 PM False alarm that address snosj posted is zero balance useless even if he has the key maybe watch only address wait trillions of trillions years to happen a transaction again
Title: Re: Large Bitcoin Collider Thread 2.0 Post by: anunnaki1202 on September 07, 2018, 08:03:44 PM I think I have an idea what snosj is trying to do he maybe have them cards or even maybe is mining for bitcoin at the moment and is not so profitable for and wanting to switch to LBC
Title: Re: Large Bitcoin Collider Thread 2.0 Post by: rico666 on September 08, 2018, 04:12:58 AM Now that's a clever move rico666 :) who can decode that key :) only you Excuse me? Don't be so ignorant - read the manual: https://lbc.cryptoguru.org/man/user#found- I also believe there are ready-made scripts to show you the private key in any format you are used to. Title: Re: Large Bitcoin Collider Thread 2.0 Post by: Poloned on October 19, 2018, 01:24:42 AM Does this still work? and is this program a private key sweeper?
Can anyone give me a video of it working? Title: Re: Large Bitcoin Collider Thread 2.0 Post by: fucilator_3000 on October 19, 2018, 12:56:14 PM I can't undestrand if this project is still alive or not...
Title: Re: Large Bitcoin Collider Thread 2.0 Post by: BurtW on October 20, 2018, 05:19:58 AM Go here:
https://lbc.cryptoguru.org/stats As of the time I posted this they are generating and checking about 290 Mkeys/second for Bitcoins, or about 25.07 trillion keys per day. So, yes, it is still up and operating. Title: Re: Large Bitcoin Collider Thread 2.0 Post by: Thirdspace on October 20, 2018, 12:14:38 PM So, yes, it is still up and operating. yes... but why still working on #55 of the puzzle? both #55 (may 29) and #56 (sept 8 ) has been solved/found already shouldn't the pool working on #57 now? 15c9mPGLku1HuW9LRtBf4jcHVpBUt8txKz (https://www.blockchain.com/btc/address/15c9mPGLku1HuW9LRtBf4jcHVpBUt8txKz) - (Unspent) 0.057 BTC is the project also targeting other public addresses (used or with balance) as well? Title: Re: Large Bitcoin Collider Thread 2.0 Post by: Severos on October 22, 2018, 01:09:33 AM Is it possible to run LBC on an offline machine and update it manually every week for example?? I know there would be some useless work will be done due to other clients searching the same space before my offline machine does it.
If so, how would I do that?? Title: Re: Large Bitcoin Collider Thread 2.0 Post by: Elliptic23 on October 22, 2018, 01:42:38 PM Is it possible to run LBC on an offline machine and update it manually every week for example?? I know there would be some useless work will be done due to other clients searching the same space before my offline machine does it. If so, how would I do that?? There's a project where someone made an independent offline client. You can search any key range and address you want: https://github.com/brichard19/BitCrack (https://github.com/brichard19/BitCrack) Title: Re: Large Bitcoin Collider Thread 2.0 Post by: bartekjagoda on October 22, 2018, 04:55:29 PM So, yes, it is still up and operating. yes... but why still working on #55 of the puzzle? both #55 (may 29) and #56 (sept 8 ) has been solved/found already shouldn't the pool working on #57 now? 15c9mPGLku1HuW9LRtBf4jcHVpBUt8txKz (https://www.blockchain.com/btc/address/15c9mPGLku1HuW9LRtBf4jcHVpBUt8txKz) - (Unspent) 0.057 BTC is the project also targeting other public addresses (used or with balance) as well? Is there a list of all found puzzles with keys? Title: Re: Large Bitcoin Collider Thread 2.0 Post by: BurtW on October 22, 2018, 10:26:55 PM So, yes, it is still up and operating. yes... but why still working on #55 of the puzzle? both #55 (may 29) and #56 (sept 8 ) has been solved/found already shouldn't the pool working on #57 now? 15c9mPGLku1HuW9LRtBf4jcHVpBUt8txKz (https://www.blockchain.com/btc/address/15c9mPGLku1HuW9LRtBf4jcHVpBUt8txKz) - (Unspent) 0.057 BTC is the project also targeting other public addresses (used or with balance) as well? Is there a list of all found puzzles with keys? See here: https://lbc.cryptoguru.org/trophies and here: https://bitcointalk.org/index.php?topic=1306983.msg13381244#msg13381244 Title: Re: Large Bitcoin Collider Thread 2.0 Post by: anunnaki1202 on November 11, 2018, 09:11:35 PM - Today my equippement found key for 1CuSHEw7nerhLSwc4guXXdEvwLim58QnZ3. Big address! - I checked but everything moved half hour after my LBC found it??? So is a find or not a find? How moved out after half an hour? Title: Re: Large Bitcoin Collider Thread 2.0 Post by: Thirdspace on November 12, 2018, 05:06:57 AM - Today my equippement found key for 1CuSHEw7nerhLSwc4guXXdEvwLim58QnZ3. Big address! How moved out after half an hour? - I checked but everything moved half hour after my LBC found it??? https://www.blockchain.com/btc/tx/05b580a46410bd373a8408dd3775abde66ce9833f753af28cdeeabaec6de028f https://chainz.cryptoid.info/btx/tx.dws?faaa97a275106c3e5857918a6c6babc6113b6044bad14151ab4b93c333fe0a7d.htm https://btgexplorer.com/tx/58eb9f616650a26f0ed319062e4b61140ec155fde9f3722f6d7ce8947e36b475 https://btgexplorer.com/tx/883ed31fb5ca352059d2caf87653d76f34832702197dd3dba8414203b43a27ff 1CuSHEw7... = 2QvFEZpy... on BTX chain (airdropped 0.5 BTX for 1 BTC) It is different public key. if he found a private key of the same bitcoin address (P2PKH) but different public key, Is this first real collision? would this private key work? as in to sign transaction of that utxo with different public key Title: Re: Large Bitcoin Collider Thread 2.0 Post by: arulbero on November 12, 2018, 12:55:41 PM interesting... because the corresponding address on BTX and BTG was moved the next day https://www.blockchain.com/btc/tx/05b580a46410bd373a8408dd3775abde66ce9833f753af28cdeeabaec6de028f https://chainz.cryptoid.info/btx/tx.dws?faaa97a275106c3e5857918a6c6babc6113b6044bad14151ab4b93c333fe0a7d.htm https://btgexplorer.com/tx/58eb9f616650a26f0ed319062e4b61140ec155fde9f3722f6d7ce8947e36b475 https://btgexplorer.com/tx/883ed31fb5ca352059d2caf87653d76f34832702197dd3dba8414203b43a27ff 1CuSHEw7... = 2QvFEZpy... on BTX chain (airdropped 0.5 BTX for 1 BTC) if he found a private key of the same bitcoin address (P2PKH) but different public key, would this private key work? as in to sign transaction of that utxo with different public key Yes, it would work. But in this case I see always the same public key (then the same private key): https://www.blockchain.com/btc/tx/05b580a46410bd373a8408dd3775abde66ce9833f753af28cdeeabaec6de028f 02b009e153bd0df7fd2856ffbcbb71020bd69fbea49b20f7cd0b40e0ae98ff2486 https://chainz.cryptoid.info/btx/tx.dws?faaa97a275106c3e5857918a6c6babc6113b6044bad14151ab4b93c333fe0a7d.htm 02b009e153bd0df7fd2856ffbcbb71020bd69fbea49b20f7cd0b40e0ae98ff2486 Title: Re: Large Bitcoin Collider Thread 2.0 Post by: anunnaki1202 on November 12, 2018, 07:14:50 PM http://i67.tinypic.com/zjgmf8
I think you can run LBC on any version of Linux and even on Windows Microsoft VM environment Title: Re: Large Bitcoin Collider Thread 2.0 Post by: digitalcitizen on November 25, 2018, 03:08:31 AM Does anyone know how to set LBC to use GPUs?
james@research:~$ ./LBC --gpu --id x --secret y GPU authorized: yes Whenever I try to use -gopt dev=1 for example, it seems to use only CPUs. I'm reading the manual and looking at the help, but I can't find anything that will let me make use of the GPUs. It always says, "Will use 16 CPUs." Thanks, Title: Re: Large Bitcoin Collider Thread 2.0 Post by: arulbero on November 25, 2018, 06:41:26 AM Does anyone know how to set LBC to use GPUs? james@research:~$ ./LBC --gpu --id x --secret y GPU authorized: yes Whenever I try to use -gopt dev=1 for example, it seems to use only CPUs. I'm reading the manual and looking at the help, but I can't find anything that will let me make use of the GPUs. It always says, "Will use 16 CPUs." Thanks, If you have only 1 GPU, then Code: ./LBC --gpu -c 4 --id x --secret y If you have more gpus, then you have to specify which you want to use ( from the manual: https://lbc.cryptoguru.org/man/user ) Code: Distribute your 16 CPUs only on the cards 1,3,5,7: Title: Re: Large Bitcoin Collider Thread 2.0 Post by: digitalcitizen on November 26, 2018, 04:37:29 PM Does anyone know how to set LBC to use GPUs? james@research:~$ ./LBC --gpu --id x --secret y GPU authorized: yes Whenever I try to use -gopt dev=1 for example, it seems to use only CPUs. I'm reading the manual and looking at the help, but I can't find anything that will let me make use of the GPUs. It always says, "Will use 16 CPUs." Thanks, If you have only 1 GPU, then Code: ./LBC --gpu -c 4 --id x --secret y If you have more gpus, then you have to specify which you want to use ( from the manual: https://lbc.cryptoguru.org/man/user ) Code: Distribute your 16 CPUs only on the cards 1,3,5,7: Thank you for that. The results seem disappointing with only one GPU though. I can't get more than one GPU to work at once. Poop. Title: Re: Large Bitcoin Collider Thread 2.0 Post by: sic_null on December 02, 2018, 10:28:48 PM LBC servers down?
The website doesn't seem to work either. Title: Re: Large Bitcoin Collider Thread 2.0 Post by: 88nE6w2xfri6izL1Xx239ELXb on December 04, 2018, 03:38:09 PM LBC servers down? The website doesn't seem to work either. Works fine for me. Title: Re: Large Bitcoin Collider Thread 2.0 Post by: crypticj on January 14, 2019, 06:36:48 PM Hey guys I have ubuntu 18.04 installed and i am trying to get LBC to work but i am getting error. LWP::Protocol::https not found.
i try to install it using sudo install and cpan force install i get package not found. Please help Title: Re: Large Bitcoin Collider Thread 2.0 Post by: Jude Austin on January 15, 2019, 05:14:21 PM Hey guys I have ubuntu 18.04 installed and i am trying to get LBC to work but i am getting error. LWP::Protocol::https not found. i try to install it using sudo install and cpan force install i get package not found. Please help Did you try: sudo cpan install LWP::Protocol::https ? Or: sudo cpan install LWP::Protocol Title: Re: Large Bitcoin Collider Thread 2.0 Post by: crypticj on January 15, 2019, 05:50:34 PM https://i.imgur.com/Ak89efL.png
I installed sudo cpan install LWP::Protocol::https already and sudo cpan install LWP::Protocol but still getting the same error. Title: Re: Large Bitcoin Collider Thread 2.0 Post by: Jude Austin on January 15, 2019, 05:54:57 PM https://i.imgur.com/Ak89efL.png I installed sudo cpan install LWP::Protocol::https already and sudo cpan install LWP::Protocol but still getting the same error. Try sudo apt-get liblwp-protocol-https-perl Title: Re: Large Bitcoin Collider Thread 2.0 Post by: crypticj on January 15, 2019, 09:26:05 PM https://i.imgur.com/Ak89efL.png I installed sudo cpan install LWP::Protocol::https already and sudo cpan install LWP::Protocol but still getting the same error. Try sudo apt-get liblwp-protocol-https-perl Thank you that didn't work but it put me in right track. i install aptitude (package manager) and than Code: sudo aptitude install liblwp-protocol-https-perl fixed the issue with ./LBC ty ty Title: Re: Large Bitcoin Collider Thread 2.0 Post by: crypticj on January 16, 2019, 05:29:56 PM New problem using -gpu for LBC i have Ubuntu 18.04 and have Open cl installed
previous post i found a solution https://bitcointalk.org/index.php?topic=1877935.msg18999315#msg18999315 install ocl-icd-libopencl1 unfortunately it doesn't work for me. still getting exit code: 255 https://i.imgur.com/QywzpoR.png Title: Re: Large Bitcoin Collider Thread 2.0 Post by: hunghcm on January 23, 2019, 04:37:38 AM if sucess, the crypto currency is not safe :(
Title: Re: Large Bitcoin Collider Thread 2.0 Post by: andrejmi on January 30, 2019, 05:19:07 PM Hi guys,
I've been thinking a lot about old, forgotten and abandoned BTC wallets and the way they can be accessed. In that research, I saw this project that inspired me and I want to join the project. Could you give me a PC configuration recommendation, to pay attention to whether is more important CPU or GPU , whether one GPU is enough or more, how much RAM, and more. What is minimum configuration for good participation in this project. Give me some recommendation, some advice about hardware, what should I pay attention to. Thanks a lot for every one. p.s. Who knows, maybe we sometimes get into Satoshi's wallet, it's never known... Title: Re: Large Bitcoin Collider Thread 2.0 Post by: Jude Austin on January 30, 2019, 05:19:59 PM Hi guys, I've been thinking a lot about old, forgotten and abandoned BTC wallets and the way they can be accessed. In that research, I saw this project that inspired me and I want to join the project. Could you give me a PC configuration recommendation, to pay attention to whether is more important CPU or GPU , whether one GPU is enough or more, how much RAM, and more. What is minimum configuration for good participation in this project. Give me some recommendation, some advice about hardware, what should I pay attention to. Thanks a lot for every one. p.s. Who knows, maybe we sometimes get into Satoshi's wallet, it's never known... Would be better off using: https://github.com/brichard19/BitCrack Title: Re: Large Bitcoin Collider Thread 2.0 Post by: andrejmi on February 01, 2019, 09:43:44 PM Maybe my question is nooby,
But, why LBC is randomly collide addresses with private keys, why LBC don't target group of large btc addresses (which are a long time inactive and have large number of BTC) and try to collide-pair brute force public keys (auto generated) with exactly choosen addresses. If we saw list of trophies, there are addresses about 0.5BTC or less, I hope that is not target. If someone can explain me, I repeat, I am noob and only think "why we not go directly big addresses" such as: https://bitinfocharts.com/top-100-richest-bitcoin-addresses.html I am planning to invest in hardware and join in LBC, but I not know where is calculation to invest thousands of dollars in hardware, spent months and years for 0.5btc. Title: Re: Large Bitcoin Collider Thread 2.0 Post by: crypticj on February 18, 2019, 06:22:19 PM Maybe my question is nooby, But, why LBC is randomly collide addresses with private keys, why LBC don't target group of large btc addresses (which are a long time inactive and have large number of BTC) and try to collide-pair brute force public keys (auto generated) with exactly choosen addresses. If we saw list of trophies, there are addresses about 0.5BTC or less, I hope that is not target. If someone can explain me, I repeat, I am noob and only think "why we not go directly big addresses" such as: https://bitinfocharts.com/top-100-richest-bitcoin-addresses.html I am planning to invest in hardware and join in LBC, but I not know where is calculation to invest thousands of dollars in hardware, spent months and years for 0.5btc. if you read the details about the project it checks the top 9 million address for collision so every key it generates checks against 9 million addresses with BTC. https://lbc.cryptoguru.org/man/theory read the whole page.. to get an idea. edit: its 15 million addresses now. Title: Re: Large Bitcoin Collider Thread 2.0 Post by: BurtW on March 16, 2019, 11:23:17 PM I am planning to invest in hardware and join in LBC, but I not know where is calculation to invest thousands of dollars in hardware, spent months and years for 0.5btc. You will never make enough money to pay for the computer. Never.If you are doing it for fun and to learn more about how Bitcoin works then fine. Doing this to make a profit is a very very bad idea. Title: Re: Large Bitcoin Collider Thread 2.0 Post by: qwer111 on March 21, 2019, 12:38:38 PM found.txt created only when finding a wallet?
https://prnt.sc/n0yj7e Title: Re: Large Bitcoin Collider Thread 2.0 Post by: crypticj on March 21, 2019, 07:02:16 PM yes after you benchmark it creates found.txt to make sure its working
and after you should delete found.tx and once it finds a collision it will create found.txt with private key that it found collision with balance. Title: Re: Large Bitcoin Collider Thread 2.0 Post by: Raj Lassi on March 22, 2019, 06:09:01 PM Hello,
I have a few questions that may have been answered already, but I can't wait 90 seconds between searches, or find by RTFM. First of all, I love the private key database at https://lbc.cryptoguru.org/dio Now, we just need Google to index it. Haha :) Why so many warnings on download page? https://lbc.cryptoguru.org/download I want to try LBC, but GPU lives in my main box. Is it really putting my data at risk, or is this just standard disclaimer? So, nothing found since 2017-11-15 01:25:58 UTC ? https://lbc.cryptoguru.org/trophies Does client automatically report collision details to LBC server? Thanks, Raj Title: Re: Large Bitcoin Collider Thread 2.0 Post by: Crazyhead90 on March 22, 2019, 08:33:01 PM Does client automatically report collision details to LBC server? Of course, do you think they let it to chance that when a 85000 btc account gets found it goes to the finder?! There is no thing such as charity Title: Re: Large Bitcoin Collider Thread 2.0 Post by: Raj Lassi on April 16, 2019, 03:11:13 AM So, no action here at all, huh?
I am looking for a "lost" privkey. Hahaha. Good luck to me! I wrote something in C to do it, urandom style. It's pretty cute when it finds the first 4 bytes of a hash.... But matching 5 bytes? Nothing for weeks on 16 CPU cores. (maybe some weren't running). I don't expect oclvanitygen on one GPU to spit out any results, either. I don't check the hashtable of "addresses with balances" anymore. It takes too long. and eats too much memory. what is the point, anyway? just burning up CPU's here for nothing. thanks for listening. Title: Re: Large Bitcoin Collider Thread 2.0 Post by: mrxtraf on May 16, 2019, 05:14:30 PM Wauuuu! In this year spent 59, 60 and 61!!!!
And at LBC currently "Time to hit #56 of the puzzle transaction (17aPYR1m6pVAacXg1PTDDU7XafvK1dxvhi) 0 to 1545 days at current speed in sub-56bit search space." ;D ;D ;D ;D ;D Title: Re: Large Bitcoin Collider Thread 2.0 Post by: bigvito19 on May 21, 2019, 01:08:50 AM Its on #57 now, somebody hitting those keys or already got them....
Title: Re: Large Bitcoin Collider Thread 2.0 Post by: TrumenPack on May 30, 2019, 08:03:27 AM Greetings to all friends. I have such a problem. I am writing a term paper on cryptography analysis. I need to find at least one private key out of 10 million Bitcoin Addresses. All these Bitcoin addresses have a zero balance. My goal is not to make money. That is, do not enrich themselves at the expense of other people's money. This is a course and research work on cryptography. Now I can not explain everything in more detail. But to continue my research I need to know one or two private keys of 10 million Bitcoin addresses. For your help I will thank you with a certain amount of money. I uploaded these 10,000,000 bitcoin addresses to the Google Drive cloud service. Help me please.
Google Drive: Bitcoin Address: https://drive.google.com/file/d/1KFTPpH8fmw_44Ns0F3mEOFXXjzOQecVG (https://drive.google.com/file/d/1KFTPpH8fmw_44Ns0F3mEOFXXjzOQecVG) Public keys: https://drive.google.com/drive/folders/1HByDJR9Ck5CdIwTl-v_IzcaVhsG8aKaA (https://drive.google.com/drive/folders/1HByDJR9Ck5CdIwTl-v_IzcaVhsG8aKaA) Screenshot: https://pp.userapi.com/c846524/v846524528/11f8f2/3xaG5fkuKaA.jpg (https://pp.userapi.com/c846524/v846524528/11f8f2/3xaG5fkuKaA.jpg) Contacts: EMAIL: pokgoip@gmail.com VK: https://vk.com/mistercooper (https://vk.com/mistercooper) FB: https://www.facebook.com/dmitry.bazhenovsky (https://www.facebook.com/dmitry.bazhenovsky) Title: Re: Large Bitcoin Collider Thread 2.0 Post by: BurtW on May 30, 2019, 04:16:35 PM Greetings to all friends. I have such a problem. I am writing a term paper on cryptography analysis. I need to find at least one private key out of 10 million Bitcoin Addresses. All these Bitcoin addresses have a zero balance. My goal is not to make money. That is, do not enrich themselves at the expense of other people's money. This is a course and research work on cryptography. Now I can not explain everything in more detail. But to continue my research I need to know one or two private keys of 10 million Bitcoin addresses. For your help I will thank you with a certain amount of money. I uploaded these 10,000,000 bitcoin addresses to the Google Drive cloud service. Help me please. Here is some information for your research project:Google Drive: Bitcoin Address: https://drive.google.com/file/d/1KFTPpH8fmw_44Ns0F3mEOFXXjzOQecVG (https://drive.google.com/file/d/1KFTPpH8fmw_44Ns0F3mEOFXXjzOQecVG) Public keys: https://drive.google.com/drive/folders/1HByDJR9Ck5CdIwTl-v_IzcaVhsG8aKaA (https://drive.google.com/drive/folders/1HByDJR9Ck5CdIwTl-v_IzcaVhsG8aKaA) Screenshot: https://pp.userapi.com/c846524/v846524528/11f8f2/3xaG5fkuKaA.jpg (https://pp.userapi.com/c846524/v846524528/11f8f2/3xaG5fkuKaA.jpg) Contacts: EMAIL: pokgoip@gmail.com VK: https://vk.com/mistercooper (https://vk.com/mistercooper) FB: https://www.facebook.com/dmitry.bazhenovsky (https://www.facebook.com/dmitry.bazhenovsky) It is easy to calculate the public key from the private key. The formula is PublicKey = PrivateKey * G where G is a specific point on the specified elliptic curve and * is the scalar multiplication defined over the finite group of the elliptic curve. For all practical purposes it is impossible to calculate or even estimate the private key from the public key because there is no "division operation" defined for the group. That is what makes Bitcoin work. If you could calculate or even estimate the private key from the public key then anyone could calculate anyone's private key from their public key and anyone could steal anyone's Bitcoins. If anyone ever figures out how to calculate or estimate the private key from the public key then Bitcoin and a plethora of other system worldwide would all be catastrophically broken. In other words it is impossible to do what you ask even when you give us 10,000,000 Bitcoin addresses. Title: Re: Large Bitcoin Collider Thread 2.0 Post by: bigvito19 on June 02, 2019, 10:38:54 PM 01 0000000000000000000000000000000000000000000000000000000000000001 1BgGZ9tcN4rm9KBzDn7KprQz87SZ26SAMH
02 0000000000000000000000000000000000000000000000000000000000000003 1CUNEBjYrCn2y1SdiUMohaKUi4wpP326Lb 03 0000000000000000000000000000000000000000000000000000000000000007 19ZewH8Kk1PDbSNdJ97FP4EiCjTRaZMZQA 04 0000000000000000000000000000000000000000000000000000000000000008 1EhqbyUMvvs7BfL8goY6qcPbD6YKfPqb7e 05 0000000000000000000000000000000000000000000000000000000000000015 1E6NuFjCi27W5zoXg8TRdcSRq84zJeBW3k 06 0000000000000000000000000000000000000000000000000000000000000031 1PitScNLyp2HCygzadCh7FveTnfmpPbfp8 07 000000000000000000000000000000000000000000000000000000000000004c 1McVt1vMtCC7yn5b9wgX1833yCcLXzueeC 08 00000000000000000000000000000000000000000000000000000000000000e0 1M92tSqNmQLYw33fuBvjmeadirh1ysMBxK 09 00000000000000000000000000000000000000000000000000000000000001d3 1CQFwcjw1dwhtkVWBttNLDtqL7ivBonGPV 10 0000000000000000000000000000000000000000000000000000000000000202 1LeBZP5QCwwgXRtmVUvTVrraqPUokyLHqe 11 0000000000000000000000000000000000000000000000000000000000000483 1PgQVLmst3Z314JrQn5TNiys8Hc38TcXJu 12 0000000000000000000000000000000000000000000000000000000000000a7b 1DBaumZxUkM4qMQRt2LVWyFJq5kDtSZQot 13 0000000000000000000000000000000000000000000000000000000000001460 1Pie8JkxBT6MGPz9Nvi3fsPkr2D8q3GBc1 14 0000000000000000000000000000000000000000000000000000000000002930 1ErZWg5cFCe4Vw5BzgfzB74VNLaXEiEkhk 15 00000000000000000000000000000000000000000000000000000000000068f3 1QCbW9HWnwQWiQqVo5exhAnmfqKRrCRsvW 16 000000000000000000000000000000000000000000000000000000000000c936 1BDyrQ6WoF8VN3g9SAS1iKZcPzFfnDVieY 17 000000000000000000000000000000000000000000000000000000000001764f 1HduPEXZRdG26SUT5Yk83mLkPyjnZuJ7Bm 18 000000000000000000000000000000000000000000000000000000000003080d 1GnNTmTVLZiqQfLbAdp9DVdicEnB5GoERE 19 000000000000000000000000000000000000000000000000000000000005749f 1NWmZRpHH4XSPwsW6dsS3nrNWfL1yrJj4w 20 00000000000000000000000000000000000000000000000000000000000d2c55 1HsMJxNiV7TLxmoF6uJNkydxPFDog4NQum 21 00000000000000000000000000000000000000000000000000000000001ba534 14oFNXucftsHiUMY8uctg6N487riuyXs4h 22 00000000000000000000000000000000000000000000000000000000002de40f 1CfZWK1QTQE3eS9qn61dQjV89KDjZzfNcv 23 0000000000000000000000000000000000000000000000000000000000556e52 1L2GM8eE7mJWLdo3HZS6su1832NX2txaac 24 0000000000000000000000000000000000000000000000000000000000dc2a04 1rSnXMr63jdCuegJFuidJqWxUPV7AtUf7 25 0000000000000000000000000000000000000000000000000000000001fa5ee5 15JhYXn6Mx3oF4Y7PcTAv2wVVAuCFFQNiP 26 000000000000000000000000000000000000000000000000000000000340326e 1JVnST957hGztonaWK6FougdtjxzHzRMMg 27 0000000000000000000000000000000000000000000000000000000006ac3875 128z5d7nN7PkCuX5qoA4Ys6pmxUYnEy86k 28 000000000000000000000000000000000000000000000000000000000d916ce8 12jbtzBb54r97TCwW3G1gCFoumpckRAPdY 29 0000000000000000000000000000000000000000000000000000000017e2551e 19EEC52krRUK1RkUAEZmQdjTyHT7Gp1TYT 30 000000000000000000000000000000000000000000000000000000003d94cd64 1LHtnpd8nU5VHEMkG2TMYYNUjjLc992bps 31 000000000000000000000000000000000000000000000000000000007d4fe747 1LhE6sCTuGae42Axu1L1ZB7L96yi9irEBE 32 00000000000000000000000000000000000000000000000000000000b862a62e 1FRoHA9xewq7DjrZ1psWJVeTer8gHRqEvR 33 00000000000000000000000000000000000000000000000000000001a96ca8d8 187swFMjz1G54ycVU56B7jZFHFTNVQFDiu 34 000000000000000000000000000000000000000000000000000000034a65911d 1PWABE7oUahG2AFFQhhvViQovnCr4rEv7Q 35 00000000000000000000000000000000000000000000000000000004aed21170 1PWCx5fovoEaoBowAvF5k91m2Xat9bMgwb 36 00000000000000000000000000000000000000000000000000000009de820a7c 1Be2UF9NLfyLFbtm3TCbmuocc9N1Kduci1 37 0000000000000000000000000000000000000000000000000000001757756a93 14iXhn8bGajVWegZHJ18vJLHhntcpL4dex 38 00000000000000000000000000000000000000000000000000000022382facd0 1HBtApAFA9B2YZw3G2YKSMCtb3dVnjuNe2 39 0000000000000000000000000000000000000000000000000000004b5f8303e9 122AJhKLEfkFBaGAd84pLp1kfE7xK3GdT8 40 000000000000000000000000000000000000000000000000000000e9ae4933d6 1EeAxcprB2PpCnr34VfZdFrkUWuxyiNEFv 41 00000000000000000000000000000000000000000000000000000153869acc5b 1L5sU9qvJeuwQUdt4y1eiLmquFxKjtHr3E 42 000000000000000000000000000000000000000000000000000002a221c58d8f 1E32GPWgDyeyQac4aJxm9HVoLrrEYPnM4N 43 000000000000000000000000000000000000000000000000000006bd3b27c591 1PiFuqGpG8yGM5v6rNHWS3TjsG6awgEGA1 44 00000000000000000000000000000000000000000000000000000e02b35a358f 1CkR2uS7LmFwc3T2jV8C1BhWb5mQaoxedF 45 0000000000000000000000000000000000000000000000000000122fca143c05 1NtiLNGegHWE3Mp9g2JPkgx6wUg4TW7bbk 46 00000000000000000000000000000000000000000000000000002ec18388d544 1F3JRMWudBaj48EhwcHDdpeuy2jwACNxjP 47 00000000000000000000000000000000000000000000000000006cd610b53cba 1Pd8VvT49sHKsmqrQiP61RsVwmXCZ6ay7Z 48 0000000000000000000000000000000000000000000000000000ade6d7ce3b9b 1DFYhaB2J9q1LLZJWKTnscPWos9VBqDHzv 49 000000000000000000000000000000000000000000000000000174176b015f4d 12CiUhYVTTH33w3SPUBqcpMoqnApAV4WCF 50 00000000000000000000000000000000000000000000000000022bd43c2e9354 1MEzite4ReNuWaL5Ds17ePKt2dCxWEofwk 51 00000000000000000000000000000000000000000000000000075070a1a009d4 1NpnQyZ7x24ud82b7WiRNvPm6N8bqGQnaS 52 000000000000000000000000000000000000000000000000000efae164cb9e3c 15z9c9sVpu6fwNiK7dMAFgMYSK4GqsGZim 53 00000000000000000000000000000000000000000000000000180788e47e326c 15K1YKJMiJ4fpesTVUcByoz334rHmknxmT 54 00000000000000000000000000000000000000000000000000236fb6d5ad1f43 1KYUv7nSvXx4642TKeuC2SNdTk326uUpFy 55 000000000000000000000000000000000000000000000000006abe1f9b67e114 1LzhS3k3e9Ub8i2W1V8xQFdB8n2MYCHPCa 56 000000000000000000000000000000000000000000000000009d18b63ac4ffdf 17aPYR1m6pVAacXg1PTDDU7XafvK1dxvhi 57 00000000000000000000000000000000000000000000000001eb25c90795d61c 15c9mPGLku1HuW9LRtBf4jcHVpBUt8txKz 58 00000000000000000000000000000000000000000000000002c675b852189a21 1Dn8NF8qDyyfHMktmuoQLGyjWmZXgvosXf 59 00000000000000000000000000000000000000000000000007496cbb87cab44f 1HAX2n9Uruu9YDt4cqRgYcvtGvZj1rbUyt 60 0000000000000000000000000000000000000000000000000fc07a1825367bbe 1Kn5h2qpgw9mWE5jKpk8PP4qvvJ1QVy8su 61 00000000000000000000000000000000000000000000000013C96A3742F64906 1AVJKwzs9AskraJLGHAZPiaZcrpDr1U6AB Title: Re: Large Bitcoin Collider Thread 2.0 Post by: omfg-4yi on June 13, 2019, 06:09:04 PM Please, remind me how to bring the key to WIF see (eg. 5Jde*******************************************Qnsw)?
Title: Re: Large Bitcoin Collider Thread 2.0 Post by: BurtW on June 13, 2019, 07:52:15 PM 01 0000000000000000000000000000000000000000000000000000000000000001 1BgGZ9tcN4rm9KBzDn7KprQz87SZ26SAMH 65 000000000000000000000000000000000000000000000001A838B13505B26867 18ZMbwUFLMHoZBbfpCjUJQTCMCbktshgpe02 0000000000000000000000000000000000000000000000000000000000000003 1CUNEBjYrCn2y1SdiUMohaKUi4wpP326Lb 03 0000000000000000000000000000000000000000000000000000000000000007 19ZewH8Kk1PDbSNdJ97FP4EiCjTRaZMZQA 04 0000000000000000000000000000000000000000000000000000000000000008 1EhqbyUMvvs7BfL8goY6qcPbD6YKfPqb7e 05 0000000000000000000000000000000000000000000000000000000000000015 1E6NuFjCi27W5zoXg8TRdcSRq84zJeBW3k 06 0000000000000000000000000000000000000000000000000000000000000031 1PitScNLyp2HCygzadCh7FveTnfmpPbfp8 07 000000000000000000000000000000000000000000000000000000000000004c 1McVt1vMtCC7yn5b9wgX1833yCcLXzueeC 08 00000000000000000000000000000000000000000000000000000000000000e0 1M92tSqNmQLYw33fuBvjmeadirh1ysMBxK 09 00000000000000000000000000000000000000000000000000000000000001d3 1CQFwcjw1dwhtkVWBttNLDtqL7ivBonGPV 10 0000000000000000000000000000000000000000000000000000000000000202 1LeBZP5QCwwgXRtmVUvTVrraqPUokyLHqe 11 0000000000000000000000000000000000000000000000000000000000000483 1PgQVLmst3Z314JrQn5TNiys8Hc38TcXJu 12 0000000000000000000000000000000000000000000000000000000000000a7b 1DBaumZxUkM4qMQRt2LVWyFJq5kDtSZQot 13 0000000000000000000000000000000000000000000000000000000000001460 1Pie8JkxBT6MGPz9Nvi3fsPkr2D8q3GBc1 14 0000000000000000000000000000000000000000000000000000000000002930 1ErZWg5cFCe4Vw5BzgfzB74VNLaXEiEkhk 15 00000000000000000000000000000000000000000000000000000000000068f3 1QCbW9HWnwQWiQqVo5exhAnmfqKRrCRsvW 16 000000000000000000000000000000000000000000000000000000000000c936 1BDyrQ6WoF8VN3g9SAS1iKZcPzFfnDVieY 17 000000000000000000000000000000000000000000000000000000000001764f 1HduPEXZRdG26SUT5Yk83mLkPyjnZuJ7Bm 18 000000000000000000000000000000000000000000000000000000000003080d 1GnNTmTVLZiqQfLbAdp9DVdicEnB5GoERE 19 000000000000000000000000000000000000000000000000000000000005749f 1NWmZRpHH4XSPwsW6dsS3nrNWfL1yrJj4w 20 00000000000000000000000000000000000000000000000000000000000d2c55 1HsMJxNiV7TLxmoF6uJNkydxPFDog4NQum 21 00000000000000000000000000000000000000000000000000000000001ba534 14oFNXucftsHiUMY8uctg6N487riuyXs4h 22 00000000000000000000000000000000000000000000000000000000002de40f 1CfZWK1QTQE3eS9qn61dQjV89KDjZzfNcv 23 0000000000000000000000000000000000000000000000000000000000556e52 1L2GM8eE7mJWLdo3HZS6su1832NX2txaac 24 0000000000000000000000000000000000000000000000000000000000dc2a04 1rSnXMr63jdCuegJFuidJqWxUPV7AtUf7 25 0000000000000000000000000000000000000000000000000000000001fa5ee5 15JhYXn6Mx3oF4Y7PcTAv2wVVAuCFFQNiP 26 000000000000000000000000000000000000000000000000000000000340326e 1JVnST957hGztonaWK6FougdtjxzHzRMMg 27 0000000000000000000000000000000000000000000000000000000006ac3875 128z5d7nN7PkCuX5qoA4Ys6pmxUYnEy86k 28 000000000000000000000000000000000000000000000000000000000d916ce8 12jbtzBb54r97TCwW3G1gCFoumpckRAPdY 29 0000000000000000000000000000000000000000000000000000000017e2551e 19EEC52krRUK1RkUAEZmQdjTyHT7Gp1TYT 30 000000000000000000000000000000000000000000000000000000003d94cd64 1LHtnpd8nU5VHEMkG2TMYYNUjjLc992bps 31 000000000000000000000000000000000000000000000000000000007d4fe747 1LhE6sCTuGae42Axu1L1ZB7L96yi9irEBE 32 00000000000000000000000000000000000000000000000000000000b862a62e 1FRoHA9xewq7DjrZ1psWJVeTer8gHRqEvR 33 00000000000000000000000000000000000000000000000000000001a96ca8d8 187swFMjz1G54ycVU56B7jZFHFTNVQFDiu 34 000000000000000000000000000000000000000000000000000000034a65911d 1PWABE7oUahG2AFFQhhvViQovnCr4rEv7Q 35 00000000000000000000000000000000000000000000000000000004aed21170 1PWCx5fovoEaoBowAvF5k91m2Xat9bMgwb 36 00000000000000000000000000000000000000000000000000000009de820a7c 1Be2UF9NLfyLFbtm3TCbmuocc9N1Kduci1 37 0000000000000000000000000000000000000000000000000000001757756a93 14iXhn8bGajVWegZHJ18vJLHhntcpL4dex 38 00000000000000000000000000000000000000000000000000000022382facd0 1HBtApAFA9B2YZw3G2YKSMCtb3dVnjuNe2 39 0000000000000000000000000000000000000000000000000000004b5f8303e9 122AJhKLEfkFBaGAd84pLp1kfE7xK3GdT8 40 000000000000000000000000000000000000000000000000000000e9ae4933d6 1EeAxcprB2PpCnr34VfZdFrkUWuxyiNEFv 41 00000000000000000000000000000000000000000000000000000153869acc5b 1L5sU9qvJeuwQUdt4y1eiLmquFxKjtHr3E 42 000000000000000000000000000000000000000000000000000002a221c58d8f 1E32GPWgDyeyQac4aJxm9HVoLrrEYPnM4N 43 000000000000000000000000000000000000000000000000000006bd3b27c591 1PiFuqGpG8yGM5v6rNHWS3TjsG6awgEGA1 44 00000000000000000000000000000000000000000000000000000e02b35a358f 1CkR2uS7LmFwc3T2jV8C1BhWb5mQaoxedF 45 0000000000000000000000000000000000000000000000000000122fca143c05 1NtiLNGegHWE3Mp9g2JPkgx6wUg4TW7bbk 46 00000000000000000000000000000000000000000000000000002ec18388d544 1F3JRMWudBaj48EhwcHDdpeuy2jwACNxjP 47 00000000000000000000000000000000000000000000000000006cd610b53cba 1Pd8VvT49sHKsmqrQiP61RsVwmXCZ6ay7Z 48 0000000000000000000000000000000000000000000000000000ade6d7ce3b9b 1DFYhaB2J9q1LLZJWKTnscPWos9VBqDHzv 49 000000000000000000000000000000000000000000000000000174176b015f4d 12CiUhYVTTH33w3SPUBqcpMoqnApAV4WCF 50 00000000000000000000000000000000000000000000000000022bd43c2e9354 1MEzite4ReNuWaL5Ds17ePKt2dCxWEofwk 51 00000000000000000000000000000000000000000000000000075070a1a009d4 1NpnQyZ7x24ud82b7WiRNvPm6N8bqGQnaS 52 000000000000000000000000000000000000000000000000000efae164cb9e3c 15z9c9sVpu6fwNiK7dMAFgMYSK4GqsGZim 53 00000000000000000000000000000000000000000000000000180788e47e326c 15K1YKJMiJ4fpesTVUcByoz334rHmknxmT 54 00000000000000000000000000000000000000000000000000236fb6d5ad1f43 1KYUv7nSvXx4642TKeuC2SNdTk326uUpFy 55 000000000000000000000000000000000000000000000000006abe1f9b67e114 1LzhS3k3e9Ub8i2W1V8xQFdB8n2MYCHPCa 56 000000000000000000000000000000000000000000000000009d18b63ac4ffdf 17aPYR1m6pVAacXg1PTDDU7XafvK1dxvhi 57 00000000000000000000000000000000000000000000000001eb25c90795d61c 15c9mPGLku1HuW9LRtBf4jcHVpBUt8txKz 58 00000000000000000000000000000000000000000000000002c675b852189a21 1Dn8NF8qDyyfHMktmuoQLGyjWmZXgvosXf 59 00000000000000000000000000000000000000000000000007496cbb87cab44f 1HAX2n9Uruu9YDt4cqRgYcvtGvZj1rbUyt 60 0000000000000000000000000000000000000000000000000fc07a1825367bbe 1Kn5h2qpgw9mWE5jKpk8PP4qvvJ1QVy8su 61 00000000000000000000000000000000000000000000000013C96A3742F64906 1AVJKwzs9AskraJLGHAZPiaZcrpDr1U6AB 70 0000000000000000000000000000000000000000000000349B84B6431A6C4EF1 19YZECXj3SxEZMoUeJ1yiPsw8xANe7M7QR 75 0000000000000000000000000000000000000000000004C5CE114686A1336E07 1J36UjUByGroXcCvmj13U6uwaVv9caEeAt 80 FOUND 85 FOUND 90 (next one to be found) Title: Re: Large Bitcoin Collider Thread 2.0 Post by: rico666 on June 14, 2019, 05:31:02 AM Meanwhile, the LBC has found a few in between. ;)
Title: Re: Large Bitcoin Collider Thread 2.0 Post by: omfg-4yi on June 14, 2019, 05:43:47 AM Dear Guru's. How to set your e-mail address in the arguments of the ./LBC command?
Title: Re: Large Bitcoin Collider Thread 2.0 Post by: rico666 on June 14, 2019, 08:06:59 AM Dear Guru's. How to set your e-mail address in the arguments of the ./LBC command? Code: --email <email address> You know what NYI means? If you want email notification when your client finds something, use the hooks: https://lbc.cryptoguru.org/man/user#hooks Title: Re: Large Bitcoin Collider Thread 2.0 Post by: omfg-4yi on June 15, 2019, 07:21:26 AM All the same, how to convert the found key into WIF format?
Title: Re: Large Bitcoin Collider Thread 2.0 Post by: Raj Lassi on June 16, 2019, 10:17:35 PM All the same, how to convert the found key into WIF format? there is an explanation here https://en.bitcoin.it/wiki/Wallet_import_format and some online thing here https://gobittest.appspot.com/PrivateKey but you don't paste real keys into online things. maybe run javascript offline. or find some python that does it. here is something: https://bitcoin.stackexchange.com/questions/58114/convert-wif-to-private-key Title: Re: Large Bitcoin Collider Thread 2.0 Post by: Raj Lassi on June 18, 2019, 02:37:52 AM Greetings to all friends. I have such a problem. I am writing a term paper on cryptography analysis. I need to find at least one private key out of 10 million Bitcoin Addresses. All these Bitcoin addresses have a zero balance. My goal is not to make money. That is, do not enrich themselves at the expense of other people's money. This is a course and research work on cryptography. Now I can not explain everything in more detail. But to continue my research I need to know one or two private keys of 10 million Bitcoin addresses. For your help I will thank you with a certain amount of money. I uploaded these 10,000,000 bitcoin addresses to the Google Drive cloud service. Help me please. How is your research and term paper coming along? Title: Re: Large Bitcoin Collider Thread 2.0 Post by: bigvito19 on July 08, 2019, 12:16:35 PM 01 0000000000000000000000000000000000000000000000000000000000000001 1BgGZ9tcN4rm9KBzDn7KprQz87SZ26SAMH
02 0000000000000000000000000000000000000000000000000000000000000003 1CUNEBjYrCn2y1SdiUMohaKUi4wpP326Lb 03 0000000000000000000000000000000000000000000000000000000000000007 19ZewH8Kk1PDbSNdJ97FP4EiCjTRaZMZQA 04 0000000000000000000000000000000000000000000000000000000000000008 1EhqbyUMvvs7BfL8goY6qcPbD6YKfPqb7e 05 0000000000000000000000000000000000000000000000000000000000000015 1E6NuFjCi27W5zoXg8TRdcSRq84zJeBW3k 06 0000000000000000000000000000000000000000000000000000000000000031 1PitScNLyp2HCygzadCh7FveTnfmpPbfp8 07 000000000000000000000000000000000000000000000000000000000000004c 1McVt1vMtCC7yn5b9wgX1833yCcLXzueeC 08 00000000000000000000000000000000000000000000000000000000000000e0 1M92tSqNmQLYw33fuBvjmeadirh1ysMBxK 09 00000000000000000000000000000000000000000000000000000000000001d3 1CQFwcjw1dwhtkVWBttNLDtqL7ivBonGPV 10 0000000000000000000000000000000000000000000000000000000000000202 1LeBZP5QCwwgXRtmVUvTVrraqPUokyLHqe 11 0000000000000000000000000000000000000000000000000000000000000483 1PgQVLmst3Z314JrQn5TNiys8Hc38TcXJu 12 0000000000000000000000000000000000000000000000000000000000000a7b 1DBaumZxUkM4qMQRt2LVWyFJq5kDtSZQot 13 0000000000000000000000000000000000000000000000000000000000001460 1Pie8JkxBT6MGPz9Nvi3fsPkr2D8q3GBc1 14 0000000000000000000000000000000000000000000000000000000000002930 1ErZWg5cFCe4Vw5BzgfzB74VNLaXEiEkhk 15 00000000000000000000000000000000000000000000000000000000000068f3 1QCbW9HWnwQWiQqVo5exhAnmfqKRrCRsvW 16 000000000000000000000000000000000000000000000000000000000000c936 1BDyrQ6WoF8VN3g9SAS1iKZcPzFfnDVieY 17 000000000000000000000000000000000000000000000000000000000001764f 1HduPEXZRdG26SUT5Yk83mLkPyjnZuJ7Bm 18 000000000000000000000000000000000000000000000000000000000003080d 1GnNTmTVLZiqQfLbAdp9DVdicEnB5GoERE 19 000000000000000000000000000000000000000000000000000000000005749f 1NWmZRpHH4XSPwsW6dsS3nrNWfL1yrJj4w 20 00000000000000000000000000000000000000000000000000000000000d2c55 1HsMJxNiV7TLxmoF6uJNkydxPFDog4NQum 21 00000000000000000000000000000000000000000000000000000000001ba534 14oFNXucftsHiUMY8uctg6N487riuyXs4h 22 00000000000000000000000000000000000000000000000000000000002de40f 1CfZWK1QTQE3eS9qn61dQjV89KDjZzfNcv 23 0000000000000000000000000000000000000000000000000000000000556e52 1L2GM8eE7mJWLdo3HZS6su1832NX2txaac 24 0000000000000000000000000000000000000000000000000000000000dc2a04 1rSnXMr63jdCuegJFuidJqWxUPV7AtUf7 25 0000000000000000000000000000000000000000000000000000000001fa5ee5 15JhYXn6Mx3oF4Y7PcTAv2wVVAuCFFQNiP 26 000000000000000000000000000000000000000000000000000000000340326e 1JVnST957hGztonaWK6FougdtjxzHzRMMg 27 0000000000000000000000000000000000000000000000000000000006ac3875 128z5d7nN7PkCuX5qoA4Ys6pmxUYnEy86k 28 000000000000000000000000000000000000000000000000000000000d916ce8 12jbtzBb54r97TCwW3G1gCFoumpckRAPdY 29 0000000000000000000000000000000000000000000000000000000017e2551e 19EEC52krRUK1RkUAEZmQdjTyHT7Gp1TYT 30 000000000000000000000000000000000000000000000000000000003d94cd64 1LHtnpd8nU5VHEMkG2TMYYNUjjLc992bps 31 000000000000000000000000000000000000000000000000000000007d4fe747 1LhE6sCTuGae42Axu1L1ZB7L96yi9irEBE 32 00000000000000000000000000000000000000000000000000000000b862a62e 1FRoHA9xewq7DjrZ1psWJVeTer8gHRqEvR 33 00000000000000000000000000000000000000000000000000000001a96ca8d8 187swFMjz1G54ycVU56B7jZFHFTNVQFDiu 34 000000000000000000000000000000000000000000000000000000034a65911d 1PWABE7oUahG2AFFQhhvViQovnCr4rEv7Q 35 00000000000000000000000000000000000000000000000000000004aed21170 1PWCx5fovoEaoBowAvF5k91m2Xat9bMgwb 36 00000000000000000000000000000000000000000000000000000009de820a7c 1Be2UF9NLfyLFbtm3TCbmuocc9N1Kduci1 37 0000000000000000000000000000000000000000000000000000001757756a93 14iXhn8bGajVWegZHJ18vJLHhntcpL4dex 38 00000000000000000000000000000000000000000000000000000022382facd0 1HBtApAFA9B2YZw3G2YKSMCtb3dVnjuNe2 39 0000000000000000000000000000000000000000000000000000004b5f8303e9 122AJhKLEfkFBaGAd84pLp1kfE7xK3GdT8 40 000000000000000000000000000000000000000000000000000000e9ae4933d6 1EeAxcprB2PpCnr34VfZdFrkUWuxyiNEFv 41 00000000000000000000000000000000000000000000000000000153869acc5b 1L5sU9qvJeuwQUdt4y1eiLmquFxKjtHr3E 42 000000000000000000000000000000000000000000000000000002a221c58d8f 1E32GPWgDyeyQac4aJxm9HVoLrrEYPnM4N 43 000000000000000000000000000000000000000000000000000006bd3b27c591 1PiFuqGpG8yGM5v6rNHWS3TjsG6awgEGA1 44 00000000000000000000000000000000000000000000000000000e02b35a358f 1CkR2uS7LmFwc3T2jV8C1BhWb5mQaoxedF 45 0000000000000000000000000000000000000000000000000000122fca143c05 1NtiLNGegHWE3Mp9g2JPkgx6wUg4TW7bbk 46 00000000000000000000000000000000000000000000000000002ec18388d544 1F3JRMWudBaj48EhwcHDdpeuy2jwACNxjP 47 00000000000000000000000000000000000000000000000000006cd610b53cba 1Pd8VvT49sHKsmqrQiP61RsVwmXCZ6ay7Z 48 0000000000000000000000000000000000000000000000000000ade6d7ce3b9b 1DFYhaB2J9q1LLZJWKTnscPWos9VBqDHzv 49 000000000000000000000000000000000000000000000000000174176b015f4d 12CiUhYVTTH33w3SPUBqcpMoqnApAV4WCF 50 00000000000000000000000000000000000000000000000000022bd43c2e9354 1MEzite4ReNuWaL5Ds17ePKt2dCxWEofwk 51 00000000000000000000000000000000000000000000000000075070a1a009d4 1NpnQyZ7x24ud82b7WiRNvPm6N8bqGQnaS 52 000000000000000000000000000000000000000000000000000efae164cb9e3c 15z9c9sVpu6fwNiK7dMAFgMYSK4GqsGZim 53 00000000000000000000000000000000000000000000000000180788e47e326c 15K1YKJMiJ4fpesTVUcByoz334rHmknxmT 54 00000000000000000000000000000000000000000000000000236fb6d5ad1f43 1KYUv7nSvXx4642TKeuC2SNdTk326uUpFy 55 000000000000000000000000000000000000000000000000006abe1f9b67e114 1LzhS3k3e9Ub8i2W1V8xQFdB8n2MYCHPCa 56 000000000000000000000000000000000000000000000000009d18b63ac4ffdf 17aPYR1m6pVAacXg1PTDDU7XafvK1dxvhi 57 00000000000000000000000000000000000000000000000001eb25c90795d61c 15c9mPGLku1HuW9LRtBf4jcHVpBUt8txKz 58 00000000000000000000000000000000000000000000000002c675b852189a21 1Dn8NF8qDyyfHMktmuoQLGyjWmZXgvosXf 59 00000000000000000000000000000000000000000000000007496cbb87cab44f 1HAX2n9Uruu9YDt4cqRgYcvtGvZj1rbUyt 60 0000000000000000000000000000000000000000000000000fc07a1825367bbe 1Kn5h2qpgw9mWE5jKpk8PP4qvvJ1QVy8su 61 00000000000000000000000000000000000000000000000013C96A3742F64906 1AVJKwzs9AskraJLGHAZPiaZcrpDr1U6AB 65 000000000000000000000000000000000000000000000001A838B13505B26867 18ZMbwUFLMHoZBbfpCjUJQTCMCbktshgpe 70 0000000000000000000000000000000000000000000000349B84B6431A6C4EF1 19YZECXj3SxEZMoUeJ1yiPsw8xANe7M7QR 75 0000000000000000000000000000000000000000000004C5CE114686A1336E07 1J36UjUByGroXcCvmj13U6uwaVv9caEeAt 80 00000000000000000000000000000000000000000000ea1a5c66dcc11b5ad180 1BCf6rHUW6m3iH2ptsvnjgLruAiPQQepLe 85 00000000000000000000000000000000000000000011720c4f018d51b8cebba8 1Kh22PvXERd2xpTQk3ur6pPEqFeckCJfAr 90 000000000000000000000000000000000000000002ce00bb2136a445c71e85bf 1L12FHH2FHjvTviyanuiFVfmzCy46RRATU Title: Re: Large Bitcoin Collider Thread 2.0 Post by: Raj Lassi on July 08, 2019, 01:36:28 PM Meanwhile, the LBC has found a few in between. ;) Just wondering if https://lbc.cryptoguru.org/trophies will be updated with finds. Or does that not matter, or am i missing something? Title: Re: Large Bitcoin Collider Thread 2.0 Post by: mrxtraf on July 13, 2019, 11:08:09 AM Why speed at pool is to slow "24h Pool Performance: 233.52 Mkeys/s"?
This in one GPU GeForce GTX 1080 TI. Info from here https://bitcointalk.org/index.php?topic=4453897.msg49793258#msg49793258 Quote GeForce GT 640 = 9.11 MKeys/s GeForce GTX 1060 3GB = compressed = 60.61 MKeys/s GeForce GTX 1060 3GB = both = 46.93 MKeys/s GeForce GTX 1070 = compressed = 109 MKeys/s GeForce GTX 1070 = compressed = 85 MKeys/s (with 40k targets) GeForce GTX 1070 TI = compressed = 80 MKeys/s (with 87k targets) GeForce GTX 1080 TI = compressed = 1030 MKeys/s (with 40k targets) GeForce GTX 1080 TI = compressed = 350.28 MKeys/s (-b 224 -t 128 -p 1024) GeForce GTX 1080 TI = compressed = 350.28 MKeys/s GeForce GTX 2070 TI = compressed = 805 MKeys/s (with 200 targets) GeForce RXT 2080 TI = both = 631.57 MKeys/s GeForce GTX 1050 TI = 64 MKeys/s (with 81 targets) Tesla K80 = compressed = 39.76 MKeys/s Tesla K80 = compressed = 68.21 MKeys/s (config) Tesla P100 = compressed = 76 MKeys/s Tesla P100 = compressed = 251 MKeys/s (config) Tesla V100 = compressed = 174 MKeys/s Tesla V100 = compressed = 603 MKeys/s (with 40k targets) (config) Tesla V100 = compressed = 715 MKeys/s (with 40k targets) (config = -b 72 -t 512 -p 1024) = Title: Re: Large Bitcoin Collider Thread 2.0 Post by: rico666 on July 13, 2019, 12:18:04 PM Why speed at pool is to slow "24h Pool Performance: 233.52 Mkeys/s"? This in one GPU GeForce GTX 1080 TI. Info from here https://bitcointalk.org/index.php?topic=4453897.msg49793258#msg49793258 Quote GeForce GTX 1080 TI = compressed = 1030 MKeys/s (with 40k targets) GeForce GTX 1080 TI = compressed = 350.28 MKeys/s (-b 224 -t 128 -p 1024) GeForce GTX 1080 TI = compressed = 350.28 MKeys/s Because in Russia, Large Bitcoin Collider collides you! Different software, different use case, comparing apples and steaks. => Stop making fun of blondies mrxtraf. Title: Re: Large Bitcoin Collider Thread 2.0 Post by: retardedinhead on July 13, 2019, 08:30:11 PM Why speed at pool is to slow "24h Pool Performance: 233.52 Mkeys/s"? This in one GPU GeForce GTX 1080 TI. Info from here https://bitcointalk.org/index.php?topic=4453897.msg49793258#msg49793258 Quote GeForce GTX 1080 TI = compressed = 1030 MKeys/s (with 40k targets) GeForce GTX 1080 TI = compressed = 350.28 MKeys/s (-b 224 -t 128 -p 1024) GeForce GTX 1080 TI = compressed = 350.28 MKeys/s Because in Russia, Large Bitcoin Collider collides you! Different software, different use case, comparing apples and steaks. => Stop making fun of blondies mrxtraf. English is not my native language and sorry for mistakes. Rico666 i watch you work long time ago and its so good, but what about bitcrack adoption to your pool ? Why not ? It will have moar power and we can solve puzzel really fast ? I think this is the next stage of bitcoin soon or later pepople will start to brute keys, also im wondering is it possible to adopt fpga cluster to mine keys what do u think ? Title: Re: Large Bitcoin Collider Thread 2.0 Post by: rico666 on July 13, 2019, 08:45:47 PM English is not my native language and sorry for mistakes. Rico666 i watch you work long time ago and its so good, but what about bitcrack adoption to your pool ? Why not ? It will have moar power and we can solve puzzel really fast ? I think this is the next stage of bitcoin soon or later pepople will start to brute keys, also im wondering is it possible to adopt fpga cluster to mine keys what do u think ? Well, first off - if bitcrack did all the work LBC is doing (watching all 16M addresses AND computing compressed and uncompressed addresses), the speed difference would not be that big anymore. The reason people use bitcrack is just because of the usual little greedy minds of the common crypto crowd: quick buck from the puzzle transaction bitcoins. As I mentioned before, with that approach something falls through the cracks and LBC finds what bitcrack misses. Second, I believe I could write (with the help of certain 1-2 people I know) something much faster than bitcrack. Essentially a LBCv2 doing as usual a complete search (all addresses, all privkeys sequentially) - way faster than bitcrack, but I'm working now on bigger things, so LBC has not the priority. Title: Re: Large Bitcoin Collider Thread 2.0 Post by: mrxtraf on July 14, 2019, 01:55:34 PM English is not my native language and sorry for mistakes. Rico666 i watch you work long time ago and its so good, but what about bitcrack adoption to your pool ? Why not ? It will have moar power and we can solve puzzel really fast ? I think this is the next stage of bitcoin soon or later pepople will start to brute keys, also im wondering is it possible to adopt fpga cluster to mine keys what do u think ? Well, first off - if bitcrack did all the work LBC is doing (watching all 16M addresses AND computing compressed and uncompressed addresses), the speed difference would not be that big anymore. The reason people use bitcrack is just because of the usual little greedy minds of the common crypto crowd: quick buck from the puzzle transaction bitcoins. As I mentioned before, with that approach something falls through the cracks and LBC finds what bitcrack misses. Second, I believe I could write (with the help of certain 1-2 people I know) something much faster than bitcrack. Essentially a LBCv2 doing as usual a complete search (all addresses, all privkeys sequentially) - way faster than bitcrack, but I'm working now on bigger things, so LBC has not the priority. Currently runnnig at my one RX 560 (4GB), checked all addrees compressed and uncmpressed, with step 1 key, and list searched address about 7K. An so spead 48-50Mkeys/sec! For that matter already, the LBS also does not find everything, but only from the list given to him. And how much is there given to him? 100K addresses? 200? 300? Well, well, you can even specify a couple of millions through the bloom filter. But there are currently about 400 million known addresses! And to check every address on the block, even if your ABD is raised, then the speed will be completely different, much less. Title: Re: Large Bitcoin Collider Thread 2.0 Post by: rico666 on July 14, 2019, 02:31:56 PM Is it real? Yes, spellchecking is real. ... In some parts of this planet at least. Quote An so spead 48-50Mkeys/sec! For that matter already, the LBS also does not find everything, but only from the list given to him. And how much is there given to him? 100K addresses? 200? 300? I thought I mentioned beyond reasonable doubt: 16M addresses - those that have at least 1 Satoshi on them. Quote Well, well, you can even specify a couple of millions through the bloom filter. But there are currently about 400 million known addresses! And to check every address on the block, even if your ABD is raised, then the speed will be completely different, much less. Last time I checked there were 270M known addresses, but maybe that is bigger now. So? People usually don't want to search for empty addresses. For the topic of finding collisions, it would actually be preferable to look up all of them (and an instant speedup factor of ~20) and these proposals have been made. Maybe in the next version of LBC. I don't know what ABD is, sorry. Title: Re: Large Bitcoin Collider Thread 2.0 Post by: mrxtraf on July 14, 2019, 02:54:11 PM Is it real? Yes, spellchecking is real. ... In some parts of this planet at least. Quote An so spead 48-50Mkeys/sec! For that matter already, the LBS also does not find everything, but only from the list given to him. And how much is there given to him? 100K addresses? 200? 300? I thought I mentioned beyond reasonable doubt: 16M addresses - those that have at least 1 Satoshi on them. Quote Well, well, you can even specify a couple of millions through the bloom filter. But there are currently about 400 million known addresses! And to check every address on the block, even if your ABD is raised, then the speed will be completely different, much less. Last time I checked there were 270M known addresses, but maybe that is bigger now. So? People usually don't want to search for empty addresses. For the topic of finding collisions, it would actually be preferable to look up all of them (and an instant speedup factor of ~20) and these proposals have been made. Maybe in the next version of LBC. I don't know what ABD is, sorry. After all, even those 16 million which are now incorporated in the LBC, in a month are not entirely relevant. That is, to talk about 100 percent coverage is not entirely correct. But the conversation is not about that. Just where was the conclusion that the bitcrake checked not all the addresses? In may 2019 i calculate address. Found 496 millions. But this and simple 1, and multi 3 addresses. Title: Re: Large Bitcoin Collider Thread 2.0 Post by: retardedinhead on July 14, 2019, 05:53:13 PM English is not my native language and sorry for mistakes. Rico666 i watch you work long time ago and its so good, but what about bitcrack adoption to your pool ? Why not ? It will have moar power and we can solve puzzel really fast ? I think this is the next stage of bitcoin soon or later pepople will start to brute keys, also im wondering is it possible to adopt fpga cluster to mine keys what do u think ? Well, first off - if bitcrack did all the work LBC is doing (watching all 16M addresses AND computing compressed and uncompressed addresses), the speed difference would not be that big anymore. The reason people use bitcrack is just because of the usual little greedy minds of the common crypto crowd: quick buck from the puzzle transaction bitcoins. As I mentioned before, with that approach something falls through the cracks and LBC finds what bitcrack misses. Second, I believe I could write (with the help of certain 1-2 people I know) something much faster than bitcrack. Essentially a LBCv2 doing as usual a complete search (all addresses, all privkeys sequentially) - way faster than bitcrack, but I'm working now on bigger things, so LBC has not the priority. So LBC also watch all generated keys and check 4 funds ? Are u find some other puzzels like this or this is the only one ? Anyway you do great work with lbc i watch the project since 2018 summer and always thinking for fpga priv8 key mining but still think is useless. I hope u big project to be 160bit key bruteforce :) Are u think its possible to bruteforce 160 bit key for example first adresses where satoshi mine blocks with current hardware tehcnology ? Title: Re: Large Bitcoin Collider Thread 2.0 Post by: bareknuckle1983 on July 16, 2019, 07:11:12 PM Hey everyone longtime crypto enthusiast new to using LBC i have read the FAQ on the cryptoguru site and i know we have to report/claim finds my question is this because i didnt quite understand the claim process or how i would get funds (not like a dick just 10%) how would i go about that and how long would it take?
Regards from Las Vegas Bareknuckle1983 Title: Re: Large Bitcoin Collider Thread 2.0 Post by: bigvito19 on September 19, 2019, 07:50:41 PM 01 0000000000000000000000000000000000000000000000000000000000000001 1BgGZ9tcN4rm9KBzDn7KprQz87SZ26SAMH
02 0000000000000000000000000000000000000000000000000000000000000003 1CUNEBjYrCn2y1SdiUMohaKUi4wpP326Lb 03 0000000000000000000000000000000000000000000000000000000000000007 19ZewH8Kk1PDbSNdJ97FP4EiCjTRaZMZQA 04 0000000000000000000000000000000000000000000000000000000000000008 1EhqbyUMvvs7BfL8goY6qcPbD6YKfPqb7e 05 0000000000000000000000000000000000000000000000000000000000000015 1E6NuFjCi27W5zoXg8TRdcSRq84zJeBW3k 06 0000000000000000000000000000000000000000000000000000000000000031 1PitScNLyp2HCygzadCh7FveTnfmpPbfp8 07 000000000000000000000000000000000000000000000000000000000000004c 1McVt1vMtCC7yn5b9wgX1833yCcLXzueeC 08 00000000000000000000000000000000000000000000000000000000000000e0 1M92tSqNmQLYw33fuBvjmeadirh1ysMBxK 09 00000000000000000000000000000000000000000000000000000000000001d3 1CQFwcjw1dwhtkVWBttNLDtqL7ivBonGPV 10 0000000000000000000000000000000000000000000000000000000000000202 1LeBZP5QCwwgXRtmVUvTVrraqPUokyLHqe 11 0000000000000000000000000000000000000000000000000000000000000483 1PgQVLmst3Z314JrQn5TNiys8Hc38TcXJu 12 0000000000000000000000000000000000000000000000000000000000000a7b 1DBaumZxUkM4qMQRt2LVWyFJq5kDtSZQot 13 0000000000000000000000000000000000000000000000000000000000001460 1Pie8JkxBT6MGPz9Nvi3fsPkr2D8q3GBc1 14 0000000000000000000000000000000000000000000000000000000000002930 1ErZWg5cFCe4Vw5BzgfzB74VNLaXEiEkhk 15 00000000000000000000000000000000000000000000000000000000000068f3 1QCbW9HWnwQWiQqVo5exhAnmfqKRrCRsvW 16 000000000000000000000000000000000000000000000000000000000000c936 1BDyrQ6WoF8VN3g9SAS1iKZcPzFfnDVieY 17 000000000000000000000000000000000000000000000000000000000001764f 1HduPEXZRdG26SUT5Yk83mLkPyjnZuJ7Bm 18 000000000000000000000000000000000000000000000000000000000003080d 1GnNTmTVLZiqQfLbAdp9DVdicEnB5GoERE 19 000000000000000000000000000000000000000000000000000000000005749f 1NWmZRpHH4XSPwsW6dsS3nrNWfL1yrJj4w 20 00000000000000000000000000000000000000000000000000000000000d2c55 1HsMJxNiV7TLxmoF6uJNkydxPFDog4NQum 21 00000000000000000000000000000000000000000000000000000000001ba534 14oFNXucftsHiUMY8uctg6N487riuyXs4h 22 00000000000000000000000000000000000000000000000000000000002de40f 1CfZWK1QTQE3eS9qn61dQjV89KDjZzfNcv 23 0000000000000000000000000000000000000000000000000000000000556e52 1L2GM8eE7mJWLdo3HZS6su1832NX2txaac 24 0000000000000000000000000000000000000000000000000000000000dc2a04 1rSnXMr63jdCuegJFuidJqWxUPV7AtUf7 25 0000000000000000000000000000000000000000000000000000000001fa5ee5 15JhYXn6Mx3oF4Y7PcTAv2wVVAuCFFQNiP 26 000000000000000000000000000000000000000000000000000000000340326e 1JVnST957hGztonaWK6FougdtjxzHzRMMg 27 0000000000000000000000000000000000000000000000000000000006ac3875 128z5d7nN7PkCuX5qoA4Ys6pmxUYnEy86k 28 000000000000000000000000000000000000000000000000000000000d916ce8 12jbtzBb54r97TCwW3G1gCFoumpckRAPdY 29 0000000000000000000000000000000000000000000000000000000017e2551e 19EEC52krRUK1RkUAEZmQdjTyHT7Gp1TYT 30 000000000000000000000000000000000000000000000000000000003d94cd64 1LHtnpd8nU5VHEMkG2TMYYNUjjLc992bps 31 000000000000000000000000000000000000000000000000000000007d4fe747 1LhE6sCTuGae42Axu1L1ZB7L96yi9irEBE 32 00000000000000000000000000000000000000000000000000000000b862a62e 1FRoHA9xewq7DjrZ1psWJVeTer8gHRqEvR 33 00000000000000000000000000000000000000000000000000000001a96ca8d8 187swFMjz1G54ycVU56B7jZFHFTNVQFDiu 34 000000000000000000000000000000000000000000000000000000034a65911d 1PWABE7oUahG2AFFQhhvViQovnCr4rEv7Q 35 00000000000000000000000000000000000000000000000000000004aed21170 1PWCx5fovoEaoBowAvF5k91m2Xat9bMgwb 36 00000000000000000000000000000000000000000000000000000009de820a7c 1Be2UF9NLfyLFbtm3TCbmuocc9N1Kduci1 37 0000000000000000000000000000000000000000000000000000001757756a93 14iXhn8bGajVWegZHJ18vJLHhntcpL4dex 38 00000000000000000000000000000000000000000000000000000022382facd0 1HBtApAFA9B2YZw3G2YKSMCtb3dVnjuNe2 39 0000000000000000000000000000000000000000000000000000004b5f8303e9 122AJhKLEfkFBaGAd84pLp1kfE7xK3GdT8 40 000000000000000000000000000000000000000000000000000000e9ae4933d6 1EeAxcprB2PpCnr34VfZdFrkUWuxyiNEFv 41 00000000000000000000000000000000000000000000000000000153869acc5b 1L5sU9qvJeuwQUdt4y1eiLmquFxKjtHr3E 42 000000000000000000000000000000000000000000000000000002a221c58d8f 1E32GPWgDyeyQac4aJxm9HVoLrrEYPnM4N 43 000000000000000000000000000000000000000000000000000006bd3b27c591 1PiFuqGpG8yGM5v6rNHWS3TjsG6awgEGA1 44 00000000000000000000000000000000000000000000000000000e02b35a358f 1CkR2uS7LmFwc3T2jV8C1BhWb5mQaoxedF 45 0000000000000000000000000000000000000000000000000000122fca143c05 1NtiLNGegHWE3Mp9g2JPkgx6wUg4TW7bbk 46 00000000000000000000000000000000000000000000000000002ec18388d544 1F3JRMWudBaj48EhwcHDdpeuy2jwACNxjP 47 00000000000000000000000000000000000000000000000000006cd610b53cba 1Pd8VvT49sHKsmqrQiP61RsVwmXCZ6ay7Z 48 0000000000000000000000000000000000000000000000000000ade6d7ce3b9b 1DFYhaB2J9q1LLZJWKTnscPWos9VBqDHzv 49 000000000000000000000000000000000000000000000000000174176b015f4d 12CiUhYVTTH33w3SPUBqcpMoqnApAV4WCF 50 00000000000000000000000000000000000000000000000000022bd43c2e9354 1MEzite4ReNuWaL5Ds17ePKt2dCxWEofwk 51 00000000000000000000000000000000000000000000000000075070a1a009d4 1NpnQyZ7x24ud82b7WiRNvPm6N8bqGQnaS 52 000000000000000000000000000000000000000000000000000efae164cb9e3c 15z9c9sVpu6fwNiK7dMAFgMYSK4GqsGZim 53 00000000000000000000000000000000000000000000000000180788e47e326c 15K1YKJMiJ4fpesTVUcByoz334rHmknxmT 54 00000000000000000000000000000000000000000000000000236fb6d5ad1f43 1KYUv7nSvXx4642TKeuC2SNdTk326uUpFy 55 000000000000000000000000000000000000000000000000006abe1f9b67e114 1LzhS3k3e9Ub8i2W1V8xQFdB8n2MYCHPCa 56 000000000000000000000000000000000000000000000000009d18b63ac4ffdf 17aPYR1m6pVAacXg1PTDDU7XafvK1dxvhi 57 00000000000000000000000000000000000000000000000001eb25c90795d61c 15c9mPGLku1HuW9LRtBf4jcHVpBUt8txKz 58 00000000000000000000000000000000000000000000000002c675b852189a21 1Dn8NF8qDyyfHMktmuoQLGyjWmZXgvosXf 59 00000000000000000000000000000000000000000000000007496cbb87cab44f 1HAX2n9Uruu9YDt4cqRgYcvtGvZj1rbUyt 60 0000000000000000000000000000000000000000000000000fc07a1825367bbe 1Kn5h2qpgw9mWE5jKpk8PP4qvvJ1QVy8su 61 00000000000000000000000000000000000000000000000013C96A3742F64906 1AVJKwzs9AskraJLGHAZPiaZcrpDr1U6AB 62 000000000000000000000000000000000000000000000000363D541EB611ABEE 1Me6EfpwZK5kQziBwBfvLiHjaPGxCKLoJi 63 0000000000000000000000000000000000000000000000007CCE5EFDACCF6808 1NpYjtLira16LfGbGwZJ5JbDPh3ai9bjf4 65 000000000000000000000000000000000000000000000001A838B13505B26867 18ZMbwUFLMHoZBbfpCjUJQTCMCbktshgpe 70 0000000000000000000000000000000000000000000000349B84B6431A6C4EF1 19YZECXj3SxEZMoUeJ1yiPsw8xANe7M7QR 75 0000000000000000000000000000000000000000000004C5CE114686A1336E07 1J36UjUByGroXcCvmj13U6uwaVv9caEeAt 80 00000000000000000000000000000000000000000000ea1a5c66dcc11b5ad180 1BCf6rHUW6m3iH2ptsvnjgLruAiPQQepLe 85 00000000000000000000000000000000000000000011720c4f018d51b8cebba8 1Kh22PvXERd2xpTQk3ur6pPEqFeckCJfAr 90 000000000000000000000000000000000000000002ce00bb2136a445c71e85bf 1L12FHH2FHjvTviyanuiFVfmzCy46RRATU 95 0000000000000000000000000000000000000000527a792b183c7f64a0e8b1f4 19eVSDuizydXxhohGh8Ki9WY9KsHdSwoQC 100 000000000000000000000000000000000000000af55fc59c335c8ec67ed24826 1KCgMv8fo2TPBpddVi9jqmMmcne9uSNJ5F 105 000000000000000000000000000000000000016f14fc2054cd87ee6396b33df3 1CMjscKB3QW7SDyQ4c3C3DEUHiHRhiZVib Title: Re: Large Bitcoin Collider Thread 2.0 Post by: mrxtraf on September 20, 2019, 10:40:30 AM And what is it?
Title: Re: Some infos about the GPU generator Post by: omfg-4yi on October 13, 2019, 09:22:06 AM Hello dear gurus!
My id in LBC statistics: mishanya79. My performance in the LBC server: ~ 280 Mkeys/s, this is about half the computing power of the entire pool. In this regard, I have a few questions. I hope for your answers. 1. Does the address option in the LBC script command begin to seem like the wallet to which the reward will be transferred, or is it the one to which I want to pick up a private key? 2. I launched my data center in mid-July, but for all the time there have never been a single award. Should I double the power of the data center for calculations in the LBC, when to expect a result (even a small one)? 3. Creating the calculated capacity in the data center (buying and setting up iron) costs me 1-1.2 BTC for 250-280 Mkeys/s. I have my own wallets with lost keys for large amounts. Can I somehow look for priority keys specifically for my wallets? I am ready to share when finding keys in any reasonable proportion. I am ready to develop and support your project with hardware, software, time and my own enthusiasm. But I really hope for your help and support. My contact: +7-904-401-0391 (WhatsApp & Telegram), omfg.4yi@gmail.com, mishanya79@yandex.ru Best regards: Mikhail Title: Re: Large Bitcoin Collider Thread 2.0 Post by: balskiy on October 14, 2019, 11:39:42 AM Correctly, I understand that in theory for any bitcoin address in the theory there are both compressed and uncompressed keys?
Title: Re: Large Bitcoin Collider Thread 2.0 Post by: bartovski on February 02, 2020, 06:28:47 PM does it work now?
Title: Re: Large Bitcoin Collider Thread 2.0 Post by: omfg-4yi on February 05, 2020, 10:16:11 AM Hello Guru.
Please tell me, periodically, every 1-2 weeks on my 10 computers connected to the LBC under the nickname Mishanya79 this error pops up: "2 just got out of the pool with exit code: 255" On all computers costs Ubuntu 19.10 and CUDA 10.1. What does this mean, maybe some LBC element is missing, so I have not found a single key in 7 months? Title: Re: Large Bitcoin Collider Thread 2.0 Post by: yytbch on February 05, 2020, 02:08:02 PM Hello Guru. Please tell me, periodically, every 1-2 weeks on my 10 computers connected to the LBC under the nickname Mishanya79 this error pops up: "2 just got out of the pool with exit code: 255" On all computers costs Ubuntu 19.10 and CUDA 10.1. What does this mean, maybe some LBC element is missing, so I have not found a single key in 7 months? Finding the private key is very difficult, and can take days or years. FOUND.TXT will be saved if found, observe it Title: Re: Large Bitcoin Collider Thread 2.0 Post by: yytbch on February 05, 2020, 02:21:05 PM English is not my native language and sorry for mistakes. Rico666 i watch you work long time ago and its so good, but what about bitcrack adoption to your pool ? Why not ? It will have moar power and we can solve puzzel really fast ? I think this is the next stage of bitcoin soon or later pepople will start to brute keys, also im wondering is it possible to adopt fpga cluster to mine keys what do u think ? Well, first off - if bitcrack did all the work LBC is doing (watching all 16M addresses AND computing compressed and uncompressed addresses), the speed difference would not be that big anymore. The reason people use bitcrack is just because of the usual little greedy minds of the common crypto crowd: quick buck from the puzzle transaction bitcoins. As I mentioned before, with that approach something falls through the cracks and LBC finds what bitcrack misses. Second, I believe I could write (with the help of certain 1-2 people I know) something much faster than bitcrack. Essentially a LBCv2 doing as usual a complete search (all addresses, all privkeys sequentially) - way faster than bitcrack, but I'm working now on bigger things, so LBC has not the priority. 171125-2642d3b0bdf4ff2fb6828801a39da3d3.blf.bz2 When to update the latest data？ Title: Re: Large Bitcoin Collider Thread 2.0 Post by: omfg-4yi on March 09, 2020, 06:04:21 AM Hello Guru.
For 9 hours, my computers can not connect to the LBS server. Error "Problem connecting to server https://lbc.cryptoguru.org/static/client(status: 500 Can't connect to lbc.cryptoguru.org:443 (certificate verify failed)). Retries left: 25" Please tell me how fix it. Or can someone from the respected Guru renew the ca certificates on the server? Best regards, Mikhail P.S. OS Xubuntu 19.10 Title: Re: Large Bitcoin Collider Thread 2.0 Post by: meligo on March 09, 2020, 07:50:56 AM Hello Guru. For 9 hours, my computers can not connect to the LBS server. Error "Problem connecting to server https://lbc.cryptoguru.org/static/client(status: 500 Can't connect to lbc.cryptoguru.org:443 (certificate verify failed)). Retries left: 25" Please tell me how fix it. Or can someone from the respected Guru renew the ca certificates on the server? Best regards, Mikhail P.S. OS Xubuntu 19.10 Same for me all servers dropped connections Title: Re: Large Bitcoin Collider Thread 2.0 Post by: omfg-4yi on March 12, 2020, 02:27:31 PM Today it worked. I checked that all 10 of my computers connected to the LBC server.
Title: Re: Large Bitcoin Collider Thread 2.0 Post by: omfg-4yi on June 08, 2020, 04:34:54 AM Hello Guru.
For 9 hours, my computers can not connect to the LBS server. Error "Problem connecting to server https://lbc.cryptoguru.org/static/client(status: 500 Can't connect to lbc.cryptoguru.org:443 (certificate verify failed)). Retries left: 25" Please tell me how fix it. Or can someone from the respected Guru renew the ca certificates on the server? Best regards, Mikhail P.S. OS Xubuntu 20.04 Title: Re: Large Bitcoin Collider Thread 2.0 Post by: DaveF on June 08, 2020, 12:06:33 PM They are using letsencrypt. There should be a cron job running on the server that checks and renews.
For some reason it didn't. So it's just a server side thing that you have to wait for them to take care of. That is one of the issues with automated SSL renewals, if it fails you might not know about it. -Dave Title: Re: Large Bitcoin Collider Thread 2.0 Post by: Atrax on August 14, 2020, 04:39:21 PM Hi all,
is the project death by now or not? If not: If a "player" would have the capacity of some 100'000 CPUs or GPUs: What would this mean for the project? Title: Re: Large Bitcoin Collider Thread 2.0 Post by: LewyMistrz on August 16, 2020, 11:26:38 AM Looking at the daily statistics the project is almost dead, but I'm still hoping for luck and looking for the keys. 100,000 cpu / gpu is a lot and it would probably push the project forward, but even with such a data center you are not sure if you will find any bitcoins in a reasonable time.
Title: Re: Large Bitcoin Collider Thread 2.0 Post by: Atrax on August 23, 2020, 06:45:46 PM The question is what can be found regarding collisions, right? Is there any estimate?
Title: Re: Large Bitcoin Collider Thread 2.0 Post by: LewyMistrz on September 11, 2020, 04:54:01 PM Can anyone repair certificate?
Title: Re: Large Bitcoin Collider Thread 2.0 Post by: btc_hell on February 27, 2021, 03:15:00 AM Hi guys!
I am trying to set the LBC clinte up, but I am a bit new to ubuntu and cannot figure out what to do next? I am currently stuck at stage (2): Code: 1)Make sure the following packages are installed: I just cannot understand what should I do next? what should I do here "2)You want to perform the installation as root or with "sudo". After install, "chown" all files to the user you want LBC to run as. Sissy." and how can I actually run the app, it does not seem to react when I click on it, nor when I try accessing it via terminal =( Can someone help me please? ;D thank you in advance!!! Title: Re: Large Bitcoin Collider Thread 2.0 Post by: crypto-dev on June 18, 2021, 02:48:02 PM Is there any status update about till which bit have you reached rico666?
Also, is it possible for you to share the database of private keys and their corresponding public keys? Title: Re: Large Bitcoin Collider Thread 2.0 Post by: bigvito19 on June 18, 2021, 05:25:55 PM Is there any status update about till which bit have you reached rico666? Also, is it possible for you to share the database of private keys and their corresponding public keys? The public keys that are exposed and left to solve: #120 ( 17s2b9ksz5y7abUm92cHwG8jEPCzK3dLnT ) 800000000000000000000000000000 FFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 02CEB6CBBCDBDF5EF7150682150F4CE2C6F4807B349827DCDBDD1F2EFA885A2630 #125 ( 1PXAyUB8ZoH3WD8n5zoAthYjN15yN5CVq5 ) 10000000000000000000000000000000 1FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 0233709EB11E0D4439A729F21C2C443DEDB727528229713F0065721BA8FA46F00E #130 ( 1Fo65aKq8s8iquMt6weF1rku1moWVEd5Ua ) 200000000000000000000000000000000 3FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 03633CBE3EC02B9401C5EFFA144C5B4D22F87940259634858FC7E59B1C09937852 #135 ( 16RGFo6hjq9ym6Pj7N5H7L1NR1rVPJyw2v ) 4000000000000000000000000000000000 7FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 02145D2611C823A396EF6712CE0F712F09B9B4F3135E3E0AA3230FB9B6D08D1E16 #140 ( 1QKBaU6WAeycb3DbKbLBkX7vJiaS8r42Xo ) 80000000000000000000000000000000000 FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 031F6A332D3C5C4F2DE2378C012F429CD109BA07D69690C6C701B6BB87860D6640 #145 ( 19GpszRNUej5yYqxXoLnbZWKew3KdVLkXg ) 1000000000000000000000000000000000000 1FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 03AFDDA497369E219A2C1C369954A930E4D3740968E5E4352475BCFFCE3140DAE5 #150 ( 1MUJSJYtGPVGkBCTqGspnxyHahpt5Te8jy ) 20000000000000000000000000000000000000 3FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 03137807790EA7DC6E97901C2BC87411F45ED74A5629315C4E4B03A0A102250C49 #155 ( 1AoeP37TmHdFh8uN72fu9AqgtLrUwcv2wJ ) 400000000000000000000000000000000000000 7FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 035CD1854CAE45391CA4EC428CC7E6C7D9984424B954209A8EEA197B9E364C05F6 #160 ( 1NBC8uXJy1GiJ6drkiZa1WuKn51ps7EPTv ) 8000000000000000000000000000000000000000 FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 02E0A8B039282FAF6FE0FD769CFBC4B6B4CF8758BA68220EAC420E32B91DDFA673 Title: Re: Large Bitcoin Collider Thread 2.0 Post by: crypto-dev on June 20, 2021, 07:31:16 AM Is there any status update about till which bit have you reached rico666? Also, is it possible for you to share the database of private keys and their corresponding public keys? The public keys that are exposed and left to solve: #120 ( 17s2b9ksz5y7abUm92cHwG8jEPCzK3dLnT ) 800000000000000000000000000000 FFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 02CEB6CBBCDBDF5EF7150682150F4CE2C6F4807B349827DCDBDD1F2EFA885A2630 #125 ( 1PXAyUB8ZoH3WD8n5zoAthYjN15yN5CVq5 ) 10000000000000000000000000000000 1FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 0233709EB11E0D4439A729F21C2C443DEDB727528229713F0065721BA8FA46F00E #130 ( 1Fo65aKq8s8iquMt6weF1rku1moWVEd5Ua ) 200000000000000000000000000000000 3FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 03633CBE3EC02B9401C5EFFA144C5B4D22F87940259634858FC7E59B1C09937852 #135 ( 16RGFo6hjq9ym6Pj7N5H7L1NR1rVPJyw2v ) 4000000000000000000000000000000000 7FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 02145D2611C823A396EF6712CE0F712F09B9B4F3135E3E0AA3230FB9B6D08D1E16 #140 ( 1QKBaU6WAeycb3DbKbLBkX7vJiaS8r42Xo ) 80000000000000000000000000000000000 FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 031F6A332D3C5C4F2DE2378C012F429CD109BA07D69690C6C701B6BB87860D6640 #145 ( 19GpszRNUej5yYqxXoLnbZWKew3KdVLkXg ) 1000000000000000000000000000000000000 1FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 03AFDDA497369E219A2C1C369954A930E4D3740968E5E4352475BCFFCE3140DAE5 #150 ( 1MUJSJYtGPVGkBCTqGspnxyHahpt5Te8jy ) 20000000000000000000000000000000000000 3FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 03137807790EA7DC6E97901C2BC87411F45ED74A5629315C4E4B03A0A102250C49 #155 ( 1AoeP37TmHdFh8uN72fu9AqgtLrUwcv2wJ ) 400000000000000000000000000000000000000 7FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 035CD1854CAE45391CA4EC428CC7E6C7D9984424B954209A8EEA197B9E364C05F6 #160 ( 1NBC8uXJy1GiJ6drkiZa1WuKn51ps7EPTv ) 8000000000000000000000000000000000000000 FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 02E0A8B039282FAF6FE0FD769CFBC4B6B4CF8758BA68220EAC420E32B91DDFA673 Thank You. But I was asking for the database that has been built by the LBC till now. The pool stats show that already 55.19 bits have been tried. It would be better to store this huge data and make it public if possible. Title: Re: Large Bitcoin Collider Thread 2.0 Post by: WanderingPhilospher on June 22, 2021, 06:41:47 AM Quote Thank You. But I was asking for the database that has been built by the LBC till now. The pool stats show that already 55.19 bits have been tried. It would be better to store this huge data and make it public if possible. Not sure there are enough hard drives to store all of that information. They have basically searched 2^54.19 private keys and looked at both compressed and uncompressed h160s (or addresses, I'm not sure which). 2^54.19 x 2 = 2^55.19That's a lot of data to store. Title: Re: Large Bitcoin Collider Thread 2.0 Post by: securus on November 25, 2022, 03:33:48 PM Is this project still alive and is the software still under development?
If not, can the source code be released? Title: Re: Large Bitcoin Collider Thread 2.0 Post by: digaran on February 03, 2023, 10:32:49 PM OP is inactive, this topic is not active anymore, did they get to rico? Anyone know if he is still alive or not?
Title: Re: Large Bitcoin Collider Thread 2.0 Post by: happa on May 05, 2023, 09:12:39 PM OP is inactive, this topic is not active anymore, did they get to rico? Anyone know if he is still alive or not? You can find Rico on Discord https://discord.gg/AyEfZrY Title: Re: Large Bitcoin Collider Thread 2.0 Post by: digaran on May 06, 2023, 03:05:26 AM OP is inactive, this topic is not active anymore, did they get to rico? Anyone know if he is still alive or not? You can find Rico on Discord https://discord.gg/AyEfZrY Well, when you see him tell him we are still waiting for #120 private key, it's not cool to keep so many people waiting for so long, just dropping the key would be great!😉 Title: Re: Large Bitcoin Collider Thread 2.0 Post by: Z1pp4 on June 28, 2023, 08:26:51 AM I might sound stupid, but can some1 explain me how this "0x236fb6d5ad1f43" is a private key if in normal life the priv key is 51 characters (or 52) long?
Title: Re: Large Bitcoin Collider Thread 2.0 Post by: digaran on June 28, 2023, 01:49:26 PM I might sound stupid, but can some1 explain me how this "0x236fb6d5ad1f43" is a private key if in normal life the priv key is 51 characters (or 52) long? This is the WIF private key for key 0x1 5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEsreAnchuDf If you decode it, you will see this 800000000000000000000000000000000000000000000000000000000000000001a85aa87e If you remove the last 8 characters and the first 2 characters, you will be left with 63 zeros and a 1. What you have posted is the hexadecimal format, what I posted is wallet import format, wallets convert the hex key to WIF, or WIF to hex depending on what you are doing. 😉 Title: Re: Large Bitcoin Collider Thread 2.0 Post by: joseperal on April 07, 2024, 11:41:45 PM Hi guys,
Nice work! I also did develop my tool, "Colisionador" (collider in spanish), as I do not trust the founds are being sent to the cloud. I did program it on C, trying to make if super efficient and fast. I keep the source code closed at the moment, but just ask if you would like to collaborate. You can run the binaries released it if you want: https://github.com/japeral/colisionador_releases I like to run it in Debian on WSL, running on Windows 10. There is also binaries for ARMv7 and Windows X86. It collides against a sorted list of ripemd160 from public addresses with balance. On 2024-03-22 when I scrapped a fully synced BTC node database with 53994718 addresses (53.9 Million addresses). The list include the 256 pieces of the puzzle also, those with balance 0 and still not 0. You can download the full sorted list of r160's updated up to 2024-03-22 here: https://drive.usercontent.google.com/download?id=1mAX4kdXaYSBYYGtgQf30Sw_Zkhl2GC3r&export=download&confirm=yes The tool, loads the list into RAM, and with a binary search on the sorted list, search each key ripedmd160 against the list in RAM. You can edit the list to target different public addresses with the "-list" parameter. Speed improvements are marginal if the list size is reduced, so I always load the entire list. The search speed is between 15-25K keys/s per CPU thread, depending on the CPU clock. On a AMD Ryzen 7 7730U CPU with 16th threads, the tool searches at 15K keys/s per thread, making a total of ~215K keys/s On a Raspberry pi4, @4 threads, it makes a total of ~31K keys/s. It currently supports CPU only. It spreads the load across all the threads available in the system. I use OpenMP for the parallelization. It computes the: compressed_02, compressed_03, uncompressed_04, compressed_06 and compressed_07 Id's. I am targeting the search space of puzzle 66 (that is all zeros from the left, bit 66 to 1, and the random bits down to bit 0). For that just run the tool with the parameter "-puzzle 66". The lower bits are randomized every 16777215 Keys (000000 - FFFFFF) ~ 15mins of work. Each thread is independent and jumps into a different location inside the puzzle search space. You can run as many instances of the tool, in as many machines you want. Because the random nature of the jumps, the probability of covering the entire search space is even. You could also target all the addresses with balance, just with the parameter "-puzzle 255", against the probability of finding anything. You could use it as a lottery cracker. If a finding happens, the tool saves the result in a found.txt file. It also converts the private key into WIF format for convenience to easily import it into the wallet with importprivkey command. I have a question: How the hell are you finding puzzle pieces 70, 75, 80, 85, etc before puzzle 66, if the search space of those puzzles are much bigger that the puzzle 66 search space? It is also interesting, puzzle pieces: 161-256 are also spent. Is it any other clue to delimit the search space of every puzzle piece? As far as I know: For puzzle 66, search space is: Code: from: That is: 36893488147419103231 keys to check! Thanks! Title: Re: Large Bitcoin Collider Thread 2.0 Post by: WanderingPhilospher on April 08, 2024, 02:05:27 AM Hi guys, I'm pretty sure this program is dead.Nice work! I also did develop my tool, "Colisionador" (collider in spanish), as I do not trust the founds are being sent to the cloud. I did program it on C, trying to make if super efficient and fast. I keep the source code closed at the moment, but just ask if you would like to collaborate. You can run the binaries released it if you want: https://github.com/japeral/colisionador_releases I like to run it in Debian on WSL, running on Windows 10. There is also binaries for ARMv7 and Windows X86. It collides against a sorted list of ripemd160 from public addresses with balance. On 2024-03-22 when I scrapped a fully synced BTC node database with 53994718 addresses (53.9 Million addresses). The list include the 256 pieces of the puzzle also, those with balance 0 and still not 0. You can download the full sorted list of r160's updated up to 2024-03-22 here: https://drive.usercontent.google.com/download?id=1mAX4kdXaYSBYYGtgQf30Sw_Zkhl2GC3r&export=download&confirm=yes The tool, loads the list into RAM, and with a binary search on the sorted list, search each key ripedmd160 against the list in RAM. You can edit the list to target different public addresses with the "-list" parameter. Speed improvements are marginal if the list size is reduced, so I always load the entire list. The search speed is between 15-25K keys/s per CPU thread, depending on the CPU clock. On a AMD Ryzen 7 7730U CPU with 16th threads, the tool searches at 15K keys/s per thread, making a total of ~215K keys/s On a Raspberry pi4, @4 threads, it makes a total of ~31K keys/s. It currently supports CPU only. It spreads the load across all the threads available in the system. I use OpenMP for the parallelization. It computes the: compressed_02, compressed_03, uncompressed_04, compressed_06 and compressed_07 Id's. I am targeting the search space of puzzle 66 (that is all zeros from the left, bit 66 to 1, and the random bits down to bit 0). For that just run the tool with the parameter "-puzzle 66". The lower bits are randomized every 16777215 Keys (000000 - FFFFFF) ~ 15mins of work. Each thread is independent and jumps into a different location inside the puzzle search space. You can run as many instances of the tool, in as many machines you want. Because the random nature of the jumps, the probability of covering the entire search space is even. You could also target all the addresses with balance, just with the parameter "-puzzle 255", against the probability of finding anything. You could use it as a lottery cracker. If a finding happens, the tool saves the result in a found.txt file. It also converts the private key into WIF format for convenience to easily import it into the wallet with importprivkey command. I have a question: How the hell are you finding puzzle pieces 70, 75, 80, 85, etc before puzzle 66, if the search space of those puzzles are much bigger that the puzzle 66 search space? It is also interesting, puzzle pieces: 161-256 are also spent. Is it any other clue to delimit the search space of every puzzle piece? As far as I know: For puzzle 66, search space is: Code: from: That is: 36893488147419103231 keys to check! Thanks! Every 5th key has its public key exposed so one can find the keys within minutes using kangaroo or BSGS. You may want to read up more on the puzzles to answer your questions, get a better understanding at what people are using these days to search for keys such as #66. A 4090 is getting at least 5,000 MKey/s with GPU programs. Title: Re: Large Bitcoin Collider Thread 2.0 Post by: holy_ship on April 08, 2024, 05:24:45 AM 1. it is stupid to search for 66 and other lower puzzles, because when you begin to spend them, guys with kangaroo stuff will steal you key and likely overwrite your transaction.
2. The speed is ridiculous. keyhunt on ryzen7 is searching at speed of 4040394398072471407 keys per second (puzzle 130) no GPU Title: Re: Large Bitcoin Collider Thread 2.0 Post by: citb0in on April 08, 2024, 11:07:21 AM I also did develop my tool, "Colisionador" (collider in spanish), as I do not trust the founds are being sent to the cloud. I did program it on C, trying to make if super efficient and fast. I keep the source code closed at the moment, but just ask if you would like to collaborate. You can run the binaries released it if you want: ... I can only expressly warn everyone not to download ready-made binaries from unknown sources and run them on their computer. As long as the source code is not open, you never know what the program is doing in the background. Someone with malicious intentions could use the executed program, for example, to spy on and extract data from your own PC, i.e. it could, for example, read your existing hard disk or RAM data and copy passwords or wallet files out to the INternet on some server. Never ever download programs in .dll or .exe form from unknown sources and never run them. Whether and whom you trust is of course up to you, this is only a well-intentioned warning. The shown program (test.bat) calls a binary executable: Quote colisionador_x86_64.exe -list puzzle_r160list_sorted.csv -puzzle 0 -threads 1 -start_pk_bin 0000000000000000000000000000000000000000000000000000000000000001 as well as all other start scripts listed here. Stay away ! Read and continue here: https://bitcointalk.org/index.php?topic=1306983.msg63917514#msg63917514 |
