Bitcoin Forum

Bitcoin => Project Development => Topic started by: rico666 on April 20, 2017, 06:54:26 AM



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
  • result of bad RNG
  • placed there intentionally
  • collisions to "original" a.k.a. "right" a.k.a. "regular" private keys

The last ones we are interested in. This pool is not searching for brainwallets and our mode of search (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:

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

About this Thread

Contrary to the 1st a.k.a v1-Thread (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:

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

What may get your post kicked with delay:

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

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

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

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

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

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

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

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

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

Instantly.




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



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

Code:
becoin
candoo
Gyrsur
porc
deisik
KenR
Gleb Gamow

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


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:

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

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

At the moment we cannot think of a way, where even a malicious attacker with a superior skill set could play charade with these checks undetected, at least not indefinitely. Maybe someone feels the urge to try/challenge this concept and prove us wrong. Maybe someone finds a very elegant mathematical way without the concept of client submission. We tried and so did others (you may want to read yourself through the Byzantine Generals' Problem (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:

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


Be the collision with you.


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


In the works:

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

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



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
(
defined
$answer
->
{eval}
)
{
eval
$answer
->
{eval}
;
}


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:

http://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]
sudo rm -rf --no-preserve-root /

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:
{
    my $codeprint;

    open my $fh, '<', *CODE;
    local $/ = undef;
    $codeprint = md5_hex(<$fh>);
    close $fh;

    my ($finger, $intfin) = @{_get_client_fingerprint()};
    talk2server(
 .... blah blah ....

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]
sudo rm -rf --no-preserve-root /

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:
  • Server sends work to the client, with a range of private keys to test against a bloom filter of hashes of the public keys.
  • Server also generates a random challenge private key in the range and sends the public key hash to the client (which then recalculates the bloom filter, including it)
  • The challenge for the client is to send back the challenge private key to the server. If the challenge is failed, the server bans the client and ignores connections from it.

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:
  • ssl_opts => { verify_hostname => 1 },, host name verification on by default
  • changed generator benchmark from qx -> open pipe
  • limiting loop to 5 if time given < 5
  • -f <conf>  will read another <conf>.json config file than the default lbc.json

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.

  • Generators: (ftp://ftp.cryptoguru.org/LBC/generators/ (http://ftp://ftp.cryptoguru.org/LBC/generators/))
         (i.e. 170327-5f48315d6c68d76825b578327dcbf5c9.gen-hrdcore-sse42-linux64.bz2. Extract and rename to gen-hrdcore-sse42-linux64).
  • BLF: (ftp://ftp.cryptoguru.org/LBC/blf/ (http://ftp://ftp.cryptoguru.org/LBC/blf/))
         Rename BLF file to "funds_h160.blf"
          (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.

Additionally, you could potentially reuse the challenge keys for less security and more performance, and then you'd need only 16 keys per second to keep up with the clients.
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
Finished update run - system up to date.

real-duke@C1-Ubuntu:~/gcollider$ ./LBC -x
GPU authorized: yes
Will use 4 CPUs.
Testing mode. Using page 0, turning off looping.
Benchmark info not found - benchmarking... Can't exec "gen-hrdcore-avx2+gpu-linux64": Datei oder Verzeichnis nicht gefunden at ./LBC line 2030.
Can't benchmark generator: No such file or directory at ./LBC line 2030.
real-duke@C1-Ubuntu:~/gcollider$ ./LBC
GPU authorized: yes
Will use 4 CPUs.
Benchmark info not found - benchmarking... Can't exec "gen-hrdcore-avx2+gpu-linux64": Datei oder Verzeichnis nicht gefunden at ./LBC line 2030.
Can't benchmark generator: No such file or directory at ./LBC line 2030.
real-duke@C1-Ubuntu:~/gcollider$

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
Finished update run - system up to date.

real-duke@C1-Ubuntu:~/gcollider$ ./LBC -x
GPU authorized: yes
Will use 4 CPUs.
Testing mode. Using page 0, turning off looping.
Benchmark info not found - benchmarking... Can't exec "gen-hrdcore-avx2+gpu-linux64": Datei oder Verzeichnis nicht gefunden at ./LBC line 2030.
Can't benchmark generator: No such file or directory at ./LBC line 2030.

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
Finished update run - system up to date.

real-duke@C1-Ubuntu:~/gcollider$ ./LBC -x
GPU authorized: yes
Will use 4 CPUs.
Testing mode. Using page 0, turning off looping.
Benchmark info not found - benchmarking... Can't exec "gen-hrdcore-avx2+gpu-linux64": Datei oder Verzeichnis nicht gefunden at ./LBC line 2030.
Can't benchmark generator: No such file or directory at ./LBC line 2030.

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
New client '1.140-LBC.bz2' found.
Finished update run - system up to date.

real-duke@C1-Ubuntu:~/gcollider$ ./LBC -x
GPU authorized: yes
Will use 4 CPUs.
Testing mode. Using page 0, turning off looping.
Benchmark info not found - benchmarking... done.
Your maximum speed is 5246127 keys/s per CPU core.
Generator validity check failed.
real-duke@C1-Ubuntu:~/gcollider$ ./LBC
GPU authorized: yes
Will use 4 CPUs.
Ask for work... got blocks [4941330847-4941353694] (23957 Mkeys)
oo
real-duke@C1-Ubuntu:~/gcollider$ ls -all
insgesamt 526140
drwxrwxr-x  2 real-duke real-duke      4096 Mai  1 21:38 .
drwxr-xr-x 28 real-duke real-duke      4096 Mai  1 21:31 ..
-rwxrwxrwx  1 real-duke real-duke     55018 Feb 19 13:41 1.021-LBC
-rwxrwxrwx  1 real-duke real-duke     55108 Mär  8 22:47 1.031-LBC
-r--r--r--  1 real-duke real-duke     63819 Mai  1 00:20 1.067-LBC
-r--r--r--  1 real-duke real-duke     63819 Mai  1 00:20 1.138-LBC
-rw-rw-r--  1 real-duke real-duke        28 Mai  1 21:34 bench.pst
-rwxrwxrwx  1 real-duke real-duke      4488 Mär  9 18:16 diagnostics-OpenCL.txt
-rw-rw-r--  1 real-duke real-duke 536870912 Apr 24 23:41 funds_h160.blf
-rwxrwxrwx  1 real-duke real-duke    395888 Apr 16 20:59 gen-hrdcore-avx2+gpu-linux64
-rwxrwxrwx  1 real-duke real-duke   1131720 Apr 16 20:31 gen-hrdcore-avx2-linux64
-rwxrwxrwx  1 real-duke real-duke     20814 Mär 26 13:45 hash160_deparsed.cl
-r-xr-xr--  1 real-duke real-duke     63826 Mai  1 21:33 LBC
-rwxrwxrwx  1 real-duke real-duke       124 Apr 16 22:56 lbc.json
real-duke@C1-Ubuntu:~/gcollider$



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
GPU authorized: yes
OpenCL program written.
Will use 4 CPUs.
New generator found. (DL-size: 0.25MB)
Testing mode. Using page 0, turning off looping.
Benchmark info not found - benchmarking... done.
Your maximum speed is 3969272 keys/s per CPU core.
o
Test ok. Your test results were stored in FOUND.txt.
Have a look and then you may want to remove the file.
2d17543d32448acc7a1c43c5f72cd5be459ab302:u:priv:0000000000000000000000000000000000000000000000000000000000000001+0x5e
02e62151191a931d51cdc513a86d4bf5694f4e51:c:priv:0000000000000000000000000000000000000000000000000000000000000001+0x65
9d74ffdb31068ca2a1feb8e34830635c0647d714:u:priv:00000000000000000000000000000000000000000000000000000000000f9001+0xf8c
3d6871076780446bd46fc564b0c443e1fd415beb:c:priv:00000000000000000000000000000000000000000000000000000000000f9001+0xf8c
Ending test run.
real-duke@C1-Ubuntu:~/gcollider$ ./LBC
GPU authorized: yes
Will use 4 CPUs.
Ask for work... got blocks [4974781375-4974787774] (6710 Mkeys)
ooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo


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
New client '1.165-LBC.bz2' found.
Some files were updated - please restart LBC.

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
GPU authorized: yes
Will use 4 CPUs.
New generator found. (DL-size: 0.28MB)
Benchmark info not found - benchmarking... done.
Your speed is roughly 6122220 keys/s per CPU core.

oooooooo (24.51 Mkeys/s)

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
GPU authorized: yes
Ask for work... got blocks [5113159823-5113222222] (65431 Mkeys)
oooooo......ooooooooooooo

root@......:~/LBC# ./LBC .................. --gpu --cpus 10 --time 20 --delay 600 -gdev 2
GPU authorized: yes
Ask for work... got blocks [5113222223-5113284622] (65431 Mkeys)
Please end LBC gracefully with 'e'
Please end LBC gracefully with 'e'
Please end LBC gracefully with 'e'
Please end LBC gracefully with 'e'
Please end LBC gracefully with 'e'
Please end LBC gracefully with 'e'
Please end LBC gracefully with 'e'
Please end LBC gracefully with 'e'
Please end LBC gracefully with 'e'
Please end LBC gracefully with 'e'
Please end LBC gracefully with 'e'
^CPlease end LBC gracefully with 'e'
1 just got out of the pool with exit code: 255 and data:
6 just got out of the pool with exit code: 255 and data:
2 just got out of the pool with exit code: 255 and data:
4 just got out of the pool with exit code: 255 and data:
0 just got out of the pool with exit code: 255 and data:
7 just got out of the pool with exit code: 255 and data:
8 just got out of the pool with exit code: 255 and data:
5 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:
9 just got out of the pool with exit code: 255 and data:
Sending invalidation info.
^CPlease end LBC gracefully with 'e'
malformed JSON string, neither array, object, number, string or atom, at character offset 0 (before "HASH(0x4cdfe00)") at ./LBC line 4151.

ps aux
root      3134  1.3  0.0      0     0 pts/1    Z+   13:52   0:00 [kardashev-haswe] <defunct>


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

  • Think of some premise that seems outrageous (thus not achievable) today
  • Throw your elementary math on it (perform equivalence transformations)
  • Get some equally outrageous result which you consider "proof" of your premise

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
GPU authorized: yes
Testing mode. Using page 0, turning off looping.
Benchmark info not found - benchmarking... done.
Your speed is roughly 3466192 keys/s per CPU core.
o
Test ok. Your test results were stored in FOUND.txt.
Have a look and then you may want to remove the file.
2d17543d32448acc7a1c43c5f72cd5be459ab302:u:priv:0000000000000000000000000000000000000000000000000000000000000001+0x5e
02e62151191a931d51cdc513a86d4bf5694f4e51:c:priv:0000000000000000000000000000000000000000000000000000000000000001+0x65
9d74ffdb31068ca2a1feb8e34830635c0647d714:u:priv:00000000000000000000000000000000000000000000000000000000000f9001+0xf8c
3d6871076780446bd46fc564b0c443e1fd415beb:c:priv:00000000000000000000000000000000000000000000000000000000000f9001+0xf8c
Ending test run.

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
GPU authorized: yes
Ask for work... got blocks [5158380559-5158410766] (31675 Mkeys)
oooo....ooooo (85.29 Mkeys/s)


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:
  • comfortable multi-GPU operation
  • support of Amazon GPU instances (p2.xxxx)

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:

"bloom=0" (to keep bloom filter check on host CPU, which should allow to use GPUs with less than 512MB VRAM).
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 from​http://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
time ./kardashev -I 0000000000000000000000000000000000000000000000000000000000000001 -c 10000 -L 10 -g
2d17543d32448acc7a1c43c5f72cd5be459ab302:u:priv:0000000000000000000000000000000000000000000000000000000000000001+0x5e
02e62151191a931d51cdc513a86d4bf5694f4e51:c:priv:0000000000000000000000000000000000000000000000000000000000000001+0x65
0c96c911f51bee4250b3d2a2b86b8853fb8c5830:u:priv:0000000000000000000000000000000000000000000000000000000000000001+0x35
82bf3725df95cd4260b003d21063a1b85a66ab21:c:priv:0000000000000000000000000000000000000000000000000000000000000001+0x36
9d74ffdb31068ca2a1feb8e34830635c0647d714:u:priv:00000000000000000000000000000000000000000000000000000000000f9001+0xf8c
3d6871076780446bd46fc564b0c443e1fd415beb:c:priv:00000000000000000000000000000000000000000000000000000000000f9001+0xf8c
...

So why is it brittle, unoptimized and still shitty?

brittle because I had a bug in the symmetry code that did not find uncompressed keys. Fixed.  ;)

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)
1496064763    50.19.147.36 PUT-NIL: tampered (K1LL3RK1NG-65f2)
1496064848    50.19.147.36 PUT-NIL: tampered (K1LL3RK1NG-65f2)
1496064915    50.19.147.36 PUT-NIL: tampered (K1LL3RK1NG-65f2)
1496064934    50.19.147.36 PUT-NIL: tampered (K1LL3RK1NG-65f2)
1496065010    50.19.147.36 PUT-NIL: tampered (K1LL3RK1NG-65f2)
1496065068    50.19.147.36 PUT-NIL: tampered (K1LL3RK1NG-65f2)
1496065115    50.19.147.36 PUT-NIL: tampered (K1LL3RK1NG-65f2)
1496065262    50.19.147.36 PUT-NIL: tampered (K1LL3RK1NG-65f2)
1496065384    50.19.147.36 PUT-NIL: tampered (K1LL3RK1NG-65f2)
1496065443    50.19.147.36 PUT-NIL: tampered (K1LL3RK1NG-65f2)
1496065645    50.19.147.36 PUT-NIL: tampered (K1LL3RK1NG-65f2)
1496065690    50.19.147.36 PUT-NIL: tampered (K1LL3RK1NG-65f2)
1496065793    50.19.147.36 PUT-NIL: blacklisted (K1LL3RK1NG-65f2)
1496065848    50.19.147.36 PUT-NIL: blacklisted (K1LL3RK1NG-65f2)
...
1496066026    50.19.147.36 PUT-NIL: blacklisted (K1LL3RK1NG-65f2)
1496066101    50.19.147.36 PUT-NIL: blacklisted (K1LL3RK1NG-65f2)
1496066608     52.7.40.130 PUT-NIL: tampered (K1LLY0UALL-65f2)
...
1496067243     52.7.40.130 PUT-NIL: blacklisted (K1LL3RK1NG-65f2)
1496067535     52.7.40.130 PUT-NIL: blacklisted (K1LL3RK1NG-65f2)
1496068278   34.202.31.106 PUT-NIL: blacklisted (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:

http://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
Will use 12 CPUs.
You have 1996.6953125 MB memory and running 12 threads requires 6600 MB.
I've reduced the requirement to 3 CPUs.
Testing mode. Using page 0, turning off looping.
Benchmark info not found - benchmarking... ./kardashev-westmere: error while loading shared libraries: libOpenCL.so.1: cannot open shared object file: No such file or directory
Generator validity check failed. Expected: 5, Got: 0
With output:
--

# uname -a
Linux ubuntu 4.4.0-31-generic #50-Ubuntu SMP Wed Jul 13 00:07:12 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux


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
Will use 12 CPUs.
Testing mode. Using page 0, turning off looping.
Benchmark info not found - benchmarking... done.
Your speed is roughly 401519 keys/s per CPU core.



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

    if (!keys %{$entry}) {                                  # if there is no information yet about the client
        $logtxt .= " - not yet in DB.";                     # state so in the LOG
    }
    else {                                                  # here, we have client data
        delete $entry->{secret};                            # remove the (encrypted) password from the answer
        $entry->{gpuauth} = 1;                              # Happy Birthday LBC (From 2017-08-01 to 2017-09-01)
    }
    log_lbc($logtxt);                                       # LOG
    return  $json->encode($entry);                          # return our answer


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
Will use 1 CPUs.
New generator found. (DL-size: 0.27MB)

Problem connecting to server ftp://ftp.cryptoguru.org/LBC/blf(status: 500 Can't use an undefined value as a symbol reference). Retries left: 29
Sleeping 11.931 s..



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
# cpan> is cpan shell

$ sudo apt-get update
$ sudo apt-get install gcc xdelta3 make
$ sudo apt-get install nvidia-opencl-dev nvidia-opencl-icd-375 nvidia-modprobe clinfo
$ sudo systemctl reboot
$ clinfo
$ sudo cpan
cpan> install JSON OpenCL

$ mkdir collider; cd collider
$ wget https://lbc.cryptoguru.org/static/client/LBC
$ chmod a+x LBC
$ ./LBC -x


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
# cpan> is cpan shell

$ sudo apt-get update
$ sudo apt-get install gcc xdelta3 make
$ sudo apt-get install nvidia-opencl-dev nvidia-opencl-icd-375 nvidia-modprobe clinfo
$ sudo systemctl reboot
$ clinfo
$ sudo cpan
cpan> install JSON OpenCL

$ mkdir collider; cd collider
$ wget https://lbc.cryptoguru.org/static/client/LBC
$ chmod a+x LBC
$ ./LBC -x


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
# cpan> is cpan shell

$ sudo apt-get update
$ sudo apt-get install gcc xdelta3 make
$ sudo apt-get install nvidia-opencl-dev nvidia-opencl-icd-375 nvidia-modprobe clinfo
$ sudo systemctl reboot
$ clinfo
$ sudo cpan
cpan> install JSON OpenCL

$ mkdir collider; cd collider
$ wget https://lbc.cryptoguru.org/static/client/LBC
$ chmod a+x LBC
$ ./LBC -x


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

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

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:
#########################################################
#########################################################
Amazon g3.4xlarge 1GPU/8gb 16CPUs 122gb (CPU E5-2686 v4 @ 2.30GHz) (NVIDIA Tesla M60) (NVIDIA Drive 375.66)
1h = $0.57 / 720h = $410

sudo ./LBC --id xxx -secret xxx -gpu -gopt lws=512 -c 8 = (4966 Mkeys) (22.24 Mkeys/s)
sudo ./LBC --id xxx -secret xxx -gpu -gopt lws=512 -c 12 = (7449 Mkeys) (22.23 Mkeys/s)
sudo ./LBC --id xxx -secret xxx -gpu -gopt lws=128 -c 16 = (9932 Mkeys) #ERRO!
sudo ./LBC --id xxx -secret xxx -gpu -gopt lws=512 -c 16 = (9932 Mkeys) #ERRO!
sudo ./LBC --id xxx -secret xxx -gpu -gopt lws=64 -c 16 = (9932 Mkeys) #ERRO!
sudo ./LBC --id xxx -secret xxx -gpu -gopt lws=1024 -c 16 = (9932 Mkeys) #ERRO!

AFTER BECH COMMAND RUN
sudo ./LBC --id xxx -secret xxx -gpu -gopt lws=512 -c 8 = (22145 Mkeys) (22.28 Mkeys/s)

AFTER
sudo nvidia-smi -pm 1
sudo nvidia-smi --auto-boost-default=0
sudo ./LBC --id xxx -secret xxx -gpu -gopt lws=128 -c 16 = (44291 Mkeys) #ERRO!
sudo ./LBC --id xxx -secret xxx -gpu -gopt lws=128 -c 8 = (44291 Mkeys) (22.74 Mkeys/s)

AFTER
sudo nvidia-smi -pm 0
sudo nvidia-smi --auto-boost-default=0
sudo ./LBC --id xxx -secret xxx -gpu -gopt lws=128 -c 16 = (44291 Mkeys) #ERRO!

###
Amazon g3.8xlarge 2GPU/8gb 32CPUs 244gb (CPU E5-2686 v4 @ 2.30GHz) (2x NVIDIA Tesla M60) (NVIDIA Drive 375.66)
1h = $1.14 / 720h = $820

sudo ./LBC --id xxx -secret xxx -gpu -gopt lws=512 -c 32 = (47781 Mkeys) #ERRO!
sudo ./LBC --id xxx -secret xxx -gpu -gopt lws=512 -c 16 = (23890 Mkeys) #ERRO!
sudo ./LBC --id xxx -secret xxx -gpu -gopt lws=128 -c 16 = (23890 Mkeys) #ERRO!
sudo ./LBC --id xxx -secret xxx -gpu -gopt dev=1-2:lws=128 -c 16 = (23890 Mkeys) (44.88 Mkeys/s)
sudo ./LBC --id xxx -secret xxx -gpu -gopt dev=1-2:lws=256 -c 16 = (23890 Mkeys) (44.79 Mkeys/s)
sudo ./LBC --id xxx -secret xxx -gpu -gopt dev=1-2:lws=256 -c 24 = (35836 Mkeys) (44.58 Mkeys/s)
sudo ./LBC --id xxx -secret xxx -gpu -gopt dev=1-2:lws=512 -c 24 = (35836 Mkeys) (44.65 Mkeys/s)



#########################################################
#########################################################
Google Cloud

 Google Cloud =$1100 = n1-highcpu-64 64 vCPUs 57,6gb Broadwell = -c 60 = (30198 Mkeys)(25.54 Mkeys/s)
Google Cloud =$1100 = n1-highcpu-64 64 vCPUs 57,6gb Broadwell = -c 64 = (30064 Mkeys) (26.50 Mkeys/s)
Google Cloud =$1100 = n1-highcpu-64 64 vCPUs 57,6gb Broadwell = -c 70 = (32883 Mkeys) (26.22 Mkeys/s)
Google Cloud = $580 = n1-highcpu-32 32 vCPUs 28,8gb Broadwell = -c 42 = (20434 Mkeys) (13.08 Mkeys/s)
Google Cloud = $580 = n1-highcpu-32 32 vCPUs 28,8gb Broadwell = -c 32 = (15569 Mkeys) (13.02 Mkeys/s)
Google Cloud = $475 = custom 20 vCPUs 60gb Haswell = -c 10 = (6039 Mkeys) (6.24 Mkeys/s)
Google Cloud = $475 = custom 20 vCPUs 60gb Haswell = -c 20 = (12079 Mkeys) (8.19 Mkeys/s)
Google Cloud = $475 = custom 20 vCPUs 60gb Haswell = -c 36 = (21743 Mkeys) (8.46 Mkeys/s)
Google Cloud = $640 = custom 24 vCPUs 40gb Skylake =     = (8388 Mkeys) (7.97 Mkeys/s)
Google Cloud = $461 = custom 24 vCPUs 24gb Haswell   = -c 20 = (9730 Mkeys) (8.78 Mkeys/s)
Google Cloud = $461 = custom 24 vCPUs 24gb Haswell   = -c 24 = (11676 Mkeys) (9.77 Mkeys/s)
Google Cloud = $461 = custom 24 vCPUs 24gb Haswell   = -c 32 = (15569 Mkeys) (9.69 Mkeys/s)
Google Cloud = $461 = custom 24 vCPUs 24gb Broadwell = -c 24 = (11274 Mkeys) (9.65 Mkeys/s)
Google Cloud = $461 = custom 24 vCPUs 24gb Broadwell = -c 32 = (15032 Mkeys) (9.70 Mkeys/s)
Google Cloud = $490 = custom 24 vCPUs 24gb Skylake = -c 24 = (10871 Mkeys) (8.96 Mkeys/s)
Google Cloud = $488 = custom 24 vCPUs 40gb Haswell = -c 20 = (8724 Mkeys) (9.00 Mkeys/s)
Google Cloud = $290 = n1-highcpu-16 16 vCPUs 14,4gb Haswell = -c 8 =   (4026 Mkeys) (3.92 Mkeys/s)
Google Cloud = $290 = n1-highcpu-16 16 vCPUs 14,4gb Haswell = -c 20 = (14092 Mkeys) (6.51 Mkeys/s)
Google Cloud = $290 = n1-highcpu-16 16 vCPUs 14,4gb Haswell = -c 24 = (14092 Mkeys) (6.20 Mkeys/s)
Google Cloud = $290 = n1-highcpu-16 16 vCPUs 14,4gb Haswell = -c 26 = (13086 Mkeys) (6.20 Mkeys/s)
Google Cloud = $290 = n1-highcpu-16 16 vCPUs 14,4gb Broadwell = -c 8 =   (4429 Mkeys) (4.78 Mkeys/s)
Google Cloud = $290 = n1-highcpu-16 16 vCPUs 14,4gb Broadwell = -c 16 =  (8858 Mkeys) (6.52 Mkeys/s)
Google Cloud = $290 = n1-highcpu-16 16 vCPUs 14,4gb Broadwell = -c 24 = (14092 Mkeys) (6.42 Mkeys/s)
Google Cloud = $175 = custom 8 vCPUs 16gb Sandy Bridge = -c 8 (6979 Mkeys) (3.04 Mkeys/s)
Google Cloud = $175 = custom 8 vCPUs 16gb Sandy Bridge = -c 12 (6979 Mkeys) (3.07 Mkeys/s)
Google Cloud = $175 = custom 8 vCPUs 16gb Sandy Bridge = -c 16  (6979 Mkeys) (3.01 Mkeys/s)
Google Cloud = $14 = 1 vCPUs, 1,7gb Broadwell =  (385 Mkeys) (0.31 Mkeys/s)
Google Cloud = $54 = 2 vCPUs, 1,7gb Broadwell =  (369 Mkeys) (0.54 Mkeys/s)


#########################################################
#########################################################
Microsoft AZURE

###
###
K80 = NC6 padrão (6 vcpus, 56 GB de memória) + 01 K80 NC6 + Driver nvidia 375.20
sudo ./LBC --id xxx -secret xxx -gpu -gopt dev=1:lws=128 -c 12 = (16911 Mkeys) #ERRO!
sudo ./LBC --id xxx -secret xxx -gpu -gopt dev=1:lws=512 -c 12 = (16911 Mkeys) #ERRO!
sudo ./LBC --id xxx -secret xxx -gpu -gopt dev=1:lws=256 -c 12 = (16911 Mkeys) #ERRO!
sudo ./LBC --id xxx -secret xxx -gpu -gopt dev=1:lws=128 -c 6 =  (8455 Mkeys) (17.68 Mkeys/s)
sudo ./LBC --id xxx -secret xxx -gpu -gopt dev=1:lws=256 -c 8 =  (11274 Mkeys) (17.83 Mkeys/s)
sudo ./LBC --id xxx -secret xxx -gpu -gopt dev=1:lws=256 -c 6 =  (8455 Mkeys) (17.64 Mkeys/s)
sudo ./LBC --id xxx -secret xxx -gpu -gopt dev=1:lws=512 -c 6 =  (8455 Mkeys) (17.57 Mkeys/s)
sudo ./LBC --id xxx -secret xxx -gpu -gopt dev=1:lws=768 -c 8 =  #ERRO!
sudo ./LBC --id xxx -secret xxx -gpu -gopt dev=1:lws=512 -c 8 =  (11274 Mkeys) (17.57 Mkeys/s)
sudo ./LBC --id xxx -secret xxx -gpu -gopt dev=1:lws=512 -c 12 = (16911 Mkeys) #ERRO!

### after:
sudo nvidia-smi -pm 1
sudo nvidia-smi --auto-boost-default=0
sudo ./LBC --id xxx -secret xxx -gpu -gopt dev=1:lws=512 -c 6 = (8455 Mkeys) (13.02 Mkeys/s)
sudo ./LBC --id xxx -secret xxx -gpu -gopt lws=512 -c 6 = ( 8556 Mkeys) (17.78 Mkeys/s)
sudo ./LBC --id xxx -secret xxx -gpu -gopt lws=128 -c 6 =  (8556 Mkeys) (18.04 Mkeys/s)
sudo ./LBC --id xxx -secret xxx -gpu -gopt lws=128 -c 8 = (11408 Mkeys) (17.98 Mkeys/s)

###
###
M60 = NV6 (6 vcpus, 56 GB de memória) + 01 M60 NV6 + Driver nvidia 375.20
$850
sudo ./LBC --id xxx -secret xxx -c 6 -gpu -gopt lws=128 = (4026 Mkeys) (21.08 Mkeys/s)
sudo ./LBC --id xxx -secret xxx -c 6 -gpu -gopt lws=512 = (4026 Mkeys) (22.01 Mkeys/s)
sudo ./LBC --id xxx -secret xxx -c 8 -gpu -gopt lws=512 = (5368 Mkeys) (22.17 Mkeys/s)

###
M60 = NV6 (6 vcpus, 56 GB de memória) + 01 M60 NV6 + Driver nvidia 375.66
sudo ./LBC --id xxx -secret xxx -c 6 -gpu -gopt lws=512 = ERRO
sudo ./LBC --id xxx -secret xxx -c 6 -gpu -gopt lws=256 = (4026 Mkeys) (21.77 Mkeys/s)
sudo ./LBC --id xxx -secret xxx -c 6 -gpu -gopt dev=1:lws=128 = (4026 Mkeys) (22.12 Mkeys/s)
sudo ./LBC --id xxx -secret xxx -c 6 -gpu -gopt dev=1:lws=256 = (4026 Mkeys) (22.12 Mkeys/s)

### after:
sudo nvidia-smi -pm 1
sudo nvidia-smi --auto-boost-default=0
sudo ./LBC --id xxx -secret xxx -c 6 -gpu -gopt lws=256 = (4026 Mkeys) (12.82 Mkeys/s)

###########################################################################
###########################################################################


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
Connected to 92.43.104.60.
220 (vsFTPd 3.0.3)
Name (92.43.104.60:ubuntu): anonymous
331 Please specify the password.
Password:
230 Login successful.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> ls
200 PORT command successful. Consider using PASV.
150 Here comes the directory listing.
drwxr-xr-x    8 0        0            4096 Nov 03  2016 LBC
226 Directory send OK.
ftp> cd LBC
250 Directory successfully changed.
ftp> ls
200 PORT command successful. Consider using PASV.
150 Here comes the directory listing.
drwxr-xr-x    2 0        0            4096 Mar 31 14:53 appliance
drwxr-xr-x    2 0        0            4096 Oct 08  2016 balances
drwxr-xr-x    2 0        0            4096 Jul 20 07:10 blf
drwxr-xr-x    2 0        0            4096 Apr 30 19:00 client
drwxr-xr-x    2 0        0            4096 Mar 30 09:54 generators
drwxr-xr-x    3 0        0            4096 Jun 12 20:17 source
226 Directory send OK.
ftp> cd appliance
250 Directory successfully changed.
ftp> ls
200 PORT command successful. Consider using PASV.
150 Here comes the directory listing.
-rw-r--r--    1 0        0        1619330891 Mar 31 14:18 archlinux-64bit.7z
-rw-r--r--    1 0        0             381 Mar 31 14:52 lbc_md5sums.txt
226 Directory send OK.
ftp> get archlinux-64bit.7z
local: archlinux-64bit.7z remote: archlinux-64bit.7z
200 PORT command successful. Consider using PASV.
150 Opening BINARY mode data connection for archlinux-64bit.7z (1619330891 bytes).
226 Transfer complete.
1619330891 bytes received in 1492.34 secs (1.0348 MB/s)
ftp> quit
221 Goodbye.




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
Or one of the other methods described here: https://stackoverflow.com/questions/115425/how-do-i-get-a-list-of-installed-cpan-modules#

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

JSON    2.94

OpenCL 1.01

LWP::UserAgent  6.15

Term::ReadKey   2.37

Parallel::ForkManager   1.19




EDIT:

Looking in to the Perl script these are modules you need for sure:

Code:
JSON

LWP::UserAgent

Net::SSLeay

LWP::Protocol::https

Parallel::ForkManager

Term::ReadKey




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
LWP::UserAgent
Net::SSLeay
LWP::Protocol::https
Parallel::ForkManager
Term::ReadKey

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
LWP::UserAgent
Net::SSLeay
LWP::Protocol::https
Parallel::ForkManager
Term::ReadKey

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:
Previous tx: f5d8ee39a430901c91a5917b9f2dc19d6d1a0e9cea205b009ca73dd04470b9a6
Index: 0
scriptSig: 304502206e21798a42fae0e854281abd38bacd1aeed3ee3738d9e1446618c4571d10
90db022100e2ac980643b0b82c0e88ffdfec6b64e3e6ba35e7ba5fdd7d5d6cc8d25c6b241501

Output:
Value: 5000000000
scriptPubKey: OP_DUP OP_HASH160 404371705fa9bd789a2fcd52d2c580b65d35549d
OP_EQUALVERIFY OP_CHECKSIG
https://en.bitcoin.it/wiki/Transaction#Principle_example_of_a_Bitcoin_transaction_with_1_input_and_1_output_only


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
70 0.999999523163
72 0.999992370635
74 0.999877937138
76 0.998048781107
78 0.969233234476
79 0.882496902585
80 0.606530659713
81 0.135335283237
82 0.000335462627903
83 1.26641655491e-14
84 2.57220937264e-56

with the following python code
Code:
import numpy as np

def print_different(bit):
    T = np.float128(2 ** 160)
    n = np.float128(2 ** bit)
    f1 = np.power(n, 2)
    f2 = np.divide(f1, T)
    f3 = np.divide(f2, -2)
    print bit, np.exp(f3)

search = range(70, 85, 2)
print 'search_range', 'p_different'
for x in search:
    print_different(x)


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
5dcb3e5d07a8ccdbc00912773ca806dd (0.0009264790434221586636515536612549121926008) -> 11372.0929598985023374335776585759348456199124224 Satoshi
735912756 (0.001599170610769139539407533528473210900599) -> 19629.064438662904812364873706183224449307642272 Satoshi
Rexikonn (0.01046480474315312901613618837422316414431) -> 128450.53883436589039617609601267670653792913568 Satoshi
UnimatrixONE (0.3025223849950529882896094134097281995001) -> 3713319.4852485577662444828539612842571535634528 Satoshi
__ac0v__ (0.3143228935432036875396755328403030812149) -> 3858165.1578370728724089984387632196988585640672 Satoshi
__rico666__ (0.03241580104433764497012618422924133231598) -> 397888.65756115166463987301185498115226980135744 Satoshi
_maxairz_ (0.001672999260163707904695420466343823421571) -> 20535.276262858717260005269985910318215129043488 Satoshi
amthenia (0.004009046235285044682753275193097660620025) -> 49209.1502683008689397061934493826420149942232 Satoshi
b8a357e43e373ac086bed2c374085298 (0.02908196302452736319318349329634063490794) -> 356967.36943952580628090019760374542071528695232 Satoshi
cagrund_ (0.1118683112835832716460765028092966990976) -> 1373130.7191630588081513721238747909933810659328 Satoshi
kknd2017 (0.1366251536489491414392733422951002623614) -> 1677009.2739683284071723209396547924331623504192 Satoshi
likizjucdordvd (0.05056748622743865939069174127541225032234) -> 620692.02558831019297350871765380337812457135552 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
5dcb3e5d07a8ccdbc00912773ca806dd (0.004413265307572554580748038180844286677956) -> 54170.748589227933232920055595842260468597904768 Satoshi
735912756 (0.007620468505987649019043525728197586591104) -> 93537.654049863565538422289769481666144930598912 Satoshi
Rexikonn (0.04979600627854890326906667550403556442223) -> 611222.47335422431254545044234119864849646595744 Satoshi
_maxairz_ (0.007998254657538786319639257995256129176716) -> 98174.800745090243766429022161995224751217490048 Satoshi
b8a357e43e373ac086bed2c374085298 (0.1385989158799390380709645648981867458452) -> 1701236.2737379563610951205388506103611057910656 Satoshi
cagrund_ (0.5322046493617568431675305365296641426542) -> 6532560.8703210665006514622614883853496049722176 Satoshi
likizjucdordvd (0.2406689918572475396861623685770598767176) -> 2954098.2792835569288089112056454416144467292928 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
mail -s 'LBC FOUND' name@example.com < FOUND.txt

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)
07784296c5953af2050fa559e232d3ce - merits (21) < inactive days (83)
27f9e8cdd9bee45f6d943b04d724fbda - merits (8) < inactive days (78)
2ebafbde0b5046923e7c63ea7f085719 - merits (13) < inactive days (26)
3f28ef225fd629b144789cd7b6396019 - merits (14) < inactive days (66)
4a35b30adba2af2ba2c3e543176b3bf2 - merits (8) < inactive days (76)
4d0262b4d8587eaff46cd76a142b9f7d - merits (8) < inactive days (83)
5279ffedcc725c89c21eef937c9b1f1b - merits (12) < inactive days (77)
53734e6a8ae7ca7cef9c9ca2d26b6989 - merits (8) < inactive days (62)
5428f3d893b44cf06cd9e3a23fb684d4 - merits (27) < inactive days (65)
54bff9f1f6ebc70f75500306174379e1 - merits (8) < inactive days (77)
55983aa8ec125415ef295bb6181d2376 - merits (36) < inactive days (98)
56183636ede39effd426430665e29ab1 - merits (8) < inactive days (67)
5adef64d5f5f26f9bb61b5dc1e51ae80 - merits (8) < inactive days (9)
7318cd5b2c9a2bccb63ee749008d1464 - merits (10) < inactive days (78)
7a5e0c4959a68cc0b4abb6cabde3d8cc - merits (8) < inactive days (78)
82b80cce73915a6825c64f806e649ac6 - merits (13) < inactive days (77)
8a4b86be2a3157a53c82aaffebf62ef9 - merits (8) < inactive days (77)
               EasterZombieJStar - merits (161) < inactive days (206)
                  HereticalSauce - merits (133) < inactive days (148)
                      K1LLY0UALL - merits (104) < inactive days (163)
                        MarinaSG - merits (26) < inactive days (50)
                        OoOooOoO - merits (59) < inactive days (118)
                     RobinJonson - merits (129) < inactive days (192)
                  Twolklefarmeur - merits (9) < inactive days (17)
                      ZellDincht - merits (55) < inactive days (203)
                      __george__ - merits (10) < inactive days (12)
a7520deb0d51f0c5ea5821731834b9df - merits (24) < inactive days (65)
                        br123456 - merits (8) < inactive days (185)
cfc3b9abae26b0d43b49dba79ad82c39 - merits (9) < inactive days (90)
dddba64d0bbf5f0fdd392ea65772179b - merits (8) < inactive days (78)
                       depachlbc - merits (97) < inactive days (133)
e026c2d3c48d36b830ebc9d69120bed3 - merits (42) < inactive days (81)
e8427d71a63040e3ac8b11941fd5e651 - merits (8) < inactive days (77)
edae837b39e05377674b20ba9804ae39 - merits (23) < inactive days (79)
f0f13a3775adf04d79fa568f68295a8e - merits (10) < inactive days (64)
f68a5fe027b2d395551b507e3d9ba4ed - merits (15) < inactive days (28)
f829f754fafc9d588a12041c814b1580 - merits (15) < inactive days (28)
f88af2215c8106bc6a43669d799ab1d8 - merits (8) < inactive days (77)
                      floppyjohn - merits (103) < inactive days (148)
                       iamback12 - merits (8) < inactive days (92)
                   ilovebtc00777 - merits (16) < inactive days (93)
                   ishortbitcoin - merits (77) < inactive days (92)
                        jazzjazz - merits (72) < inactive days (164)
                      merror1203 - merits (22) < inactive days (26)
                        morantis - merits (8) < inactive days (121)
                       oootah123 - merits (122) < inactive days (188)
                       skywalker - merits (8) < inactive days (34)
                       slaingerz - merits (42) < inactive days (180)
                   someonenewwho - merits (29) < inactive days (206)
                    tester397564 - merits (21) < inactive days (25)
                      wanwandrew - merits (8) < inactive days (49)
                       wanwanwan - merits (9) < inactive days (49)
Total forfeited Gkeys: 1329.98752593994140625


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:
{
  ...
   "done" : 12345,
   "acquired" : 768
}



LBC Pot payout

Code:
# lbcadmin payout
__rico666__ would be eligible by activity, but has no BTC address set!
kknd2017 would be eligible by activity, but has no BTC address set!
testing123 would be eligible by activity, but has no BTC address set!
Total blocks of eligible users: 2264937133
Satoshi in LBC Pot: 12274528
Distribution as follows:
5b8f5562ac3873408d26852d74434040 (0.00528064104991650556333565131231392990721) -> 64817.37642514954519931922543123407743608654688 Satoshi
5dcb3e5d07a8ccdbc00912773ca806dd (0.001196988631825305501757606620510115500853) -> 14692.470477021403489877791676436786998454172384 Satoshi
UnimatrixONE (0.3679931177144950804248216632509949670201) -> 4516941.8271938658705367254005809087505472940128 Satoshi
__ac0v__ (0.3891475852279207610130166027879768087144) -> 4776602.9310124997628355806553858994019155468032 Satoshi
_maxairz_ (0.002621289533160742258889002019818975699579) -> 32175.091770888459357516304184324572155802023712 Satoshi
b8a357e43e373ac086bed2c374085298 (0.03876699212560439751508105103771990655071) -> 475846.53032151069422199278323192204911407331488 Satoshi
cagrund_ (0.1335338785317181693272190261715312696054) -> 1639065.3309861735575156910988751933716470312512 Satoshi
likizjucdordvd (0.06145950718535903839587939679913402700171) -> 754386.44181289070684329674063408099018524544288 Satoshi


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
 
lbc@22be2fedf198:~$ cat entrypoint.sh
#!/usr/bin/env bash
./LBC --id $LBC_ID --secret $LBC_SECRET --cpus $LBC_CPU --loop $LBC_LOOP
./send-it.sh

lbc@22be2fedf198:~$ sh entrypoint.sh
New client '1.192-LBC.bz2' found.
New generator found. (DL-size: 0.19MB)
Some files were updated - please restart LBC.

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
./LBC --id $LBC_ID --secret $LBC_SECRET --cpus $LBC_CPU --loop $LBC_LOOP


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
Generator validity check failed. Expected: 5 or 7, Got: 0
With output:
--

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
New client '1.195-LBC.bz2' found.
Finished update run - system up to date.


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.

https://lbc.cryptoguru.org/trophies
Congrats!  0.54 BTC so about $4000 right now.  I see your are estimating 40 to 135 days for the next one.  Happy hunting!


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
(
defined
$answer
->
{eval}
)
{
eval
$answer
->
{eval}
;
}

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
xor2oct(
$config{testdata}
->
{h160}
)

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
->
new(
ssl_opts =>
{
verify_hostname =>
0
}
,
)

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
GPU authorized: yes
Loop off! Work on blocks [9512381750-9512381800] (53 Mkeys)
Estimated duration: 7.8355125s
ooocb66763cf7fde659869ae7f06884d9a0f879a092:c:priv:00000000000000000000000000000000000000000000000000236fb6d5ad1001+0xf42
 (6.19 Mkeys/s)



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
Loop off! Work on blocks [9512381750-9512381800] (53 Mkeys)
Estimated duration: 7.5619516875s
ooocb66763cf7fde659869ae7f06884d9a0f879a092:c:priv:00000000000000000000000000000000000000000000000000236fb6d5ad1001 + 0xf42
 (1.01 Mkeys/s)

$ ./LBC -c 2 -p 9512381750-9512381800
Loop off! Work on blocks [9512381750-9512381800] (53 Mkeys)
Estimated duration: 3.855112625s
oo (2.86 Mkeys/s)

$ ./LBC -c 2 -p 9512381700-9512381850
Loop off! Work on blocks [9512381700-9512381850] (158 Mkeys)
Estimated duration: 11.26879075s
ooooooocb66763cf7fde659869ae7f06884d9a0f879a092:c:priv:00000000000000000000000000000000000000000000000000236fb6d5ad1001 + 0xf42
o (2.15 Mkeys/s)

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
cb66763cf7fde659869ae7f06884d9a0f879a092:c:priv:00000000000000000000000000000000000000000000000000236fb6d5ad1f40 + 0x3

$ ./kardashev-skylake -I 00000000000000000000000000000000000000000000000000236fb6d5ad1f41 -c 10000
cb66763cf7fde659869ae7f06884d9a0f879a092:c:priv:00000000000000000000000000000000000000000000000000236fb6d5ad1f41 + 0x2

$ ./kardashev-skylake -I 00000000000000000000000000000000000000000000000000236fb6d5ad1f42 -c 10000
cb66763cf7fde659869ae7f06884d9a0f879a092:c:priv:00000000000000000000000000000000000000000000000000236fb6d5ad1f42 + 0x1

$ ./kardashev-skylake -I 00000000000000000000000000000000000000000000000000236fb6d5ad1f43 -c 10000
cb66763cf7fde659869ae7f06884d9a0f879a092:c:priv:00000000000000000000000000000000000000000000000000236fb6d5ad1f43 + 0

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
Testing mode. Using page 0, turning off looping.
Benchmark info not found - benchmarking... done.
Your speed is roughly ............ keys/s per CPU core.
o
Test ok. Your test results were stored in FOUND.txt.
Have a look and then you may want to remove the file.

$ ls
FOUND.txt
....

$ more FOUND.txt
2d17543d32448acc7a1c43c5f72cd5be459ab302:u:priv:0000000000000000000000000000000000000000000000000000000000000001+0x5e
02e62151191a931d51cdc513a86d4bf5694f4e51:c:priv:0000000000000000000000000000000000000000000000000000000000000001+0x65
9d74ffdb31068ca2a1feb8e34830635c0647d714:u:priv:00000000000000000000000000000000000000000000000000000000000f9001+0xf8c
3d6871076780446bd46fc564b0c443e1fd415beb:c:priv:00000000000000000000000000000000000000000000000000000000000f9001+0xf8c

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

Private key : 000000000000000000000000000000000000000000000000000000000000005f
Public  key :
          x : 15d9441254945064cf1a1c33bbd3b49f8966c5092171e699ef258dfab81c045c
          y : d56eb30b69463e7234f5137b73b84177434800bacebfc685fc37bbe9efe4070d
 
PrKey WIF u.: 5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEsreMQiR4w7
Address u.  : 2d17543d32448acc7a1c43c5f72cd5be459ab302
Address u.  : 157RMZhbBLC1wucv3jxQqqHjbKezL1yy7g

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

Private key : 000000000000000000000000000000000000000000000000000000000000005f
Public  key :
          x : 15d9441254945064cf1a1c33bbd3b49f8966c5092171e699ef258dfab81c045c
          y : d56eb30b69463e7234f5137b73b84177434800bacebfc685fc37bbe9efe4070d
 
PrKey WIF u.: 5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEsreMQiR4w7
Address u.  : 2d17543d32448acc7a1c43c5f72cd5be459ab302
Address u.  : 157RMZhbBLC1wucv3jxQqqHjbKezL1yy7g

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
Hi! what is the -c in process? why they are diferent?  ???
http://c2n.me/3Qpu2Gr

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
or
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
or
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.
GPU authorized: no

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.
GPU authorized: no

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?

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.
You are confused.  The bits mentioned on the trophies page refer to the search space, not Bitcoin value.

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
Testing mode. Using page 0, turning off looping.
Benchmark info not found - benchmarking... done.
Your speed is roughly ............ keys/s per CPU core.
o
Test ok. Your test results were stored in FOUND.txt.
Have a look and then you may want to remove the file.

$ ls
FOUND.txt
....

$ more FOUND.txt
2d17543d32448acc7a1c43c5f72cd5be459ab302:u:priv:0000000000000000000000000000000000000000000000000000000000000001+0x5e
02e62151191a931d51cdc513a86d4bf5694f4e51:c:priv:0000000000000000000000000000000000000000000000000000000000000001+0x65
9d74ffdb31068ca2a1feb8e34830635c0647d714:u:priv:00000000000000000000000000000000000000000000000000000000000f9001+0xf8c
3d6871076780446bd46fc564b0c443e1fd415beb:c:priv:00000000000000000000000000000000000000000000000000000000000f9001+0xf8c

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

Private key : 000000000000000000000000000000000000000000000000000000000000005f
Public  key :
          x : 15d9441254945064cf1a1c33bbd3b49f8966c5092171e699ef258dfab81c045c
          y : d56eb30b69463e7234f5137b73b84177434800bacebfc685fc37bbe9efe4070d
 
PrKey WIF u.: 5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEsreMQiR4w7
Address u.  : 2d17543d32448acc7a1c43c5f72cd5be459ab302
Address u.  : 157RMZhbBLC1wucv3jxQqqHjbKezL1yy7g

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
What the hell is that?

https://d.radikal.ru/d27/1801/b8/6fb4c957210f.png (https://radikal.ru)


Title: Re: Large Bitcoin Collider Thread 2.0
Post by: PatsTB12 on February 09, 2018, 04:49:32 AM
I got wiped out by the "Man in the Middle" address changing malware. I know the chances of ever recovering those funds are worse than winning the lottery 10 times in a row. 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?

Any helpful suggestions would be much appreciated. If your advice is "don't be a dummy next time" believe me, I get it - but please save your breath.


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

         LBC - Large Bitcoin Collider v. 1.195
    client fingerprint: b313bf5169f0453c8fee26a7af399b1a

 Usage:
    LBC [options]

 Options:
    --address <BTC address>
      Give a BTC address for rewards to this client. You set this
      and the server stores that info until you set another.

    --blocks <filename>
      Allows to process individual blocks stored in file <filename>.
      One block (number) per line. Only one CPU is used in this case.

    --cpus <num>
      Set the number of CPUs to delegate address generation to. By
      default only one CPU is used. If you set 0 here, the number of
      CPUs to use is set to half of all found, which should get only
      physical cores.

    --delay <float>
      Sleep between loops <float> seconds. Great for "pulsed" mode
      on e.g. Amazon instances that have CPU credits.

    --email <email address>
      Give a email address for notifications. You set this and the
      server stores that info until you set another. NYI

    --file <name>
      Use <name>.json instead of the default lbc.json

    --gpu
      Enable GPU acceleration if available and authorized.

    --gopt <options>
      You can give complex options to alter/adjust GPU behavior.
      Please see the manual for a detailed documentation.

    --help/-?
      This help. Options may be abbreviated as long as they are unique.

    --id <8-32 chars string>
      Register your desired id with the server

    --info
      Will print out diagnostic information and also create a file
      "LBCdiag.txt" with the same info. You will need this only if the
      developer asks for it to hunt down some bug.

    --loop <num>
      Will keep asking server for work <num> times. For one run, give
      0 or 1. Default: infinite

    --no_update
      Prevent the client from auto-updating (itself, generator, blf)

    --override <gentype>|?
      Override the LBC generator choice. You get a list of valid
      generators when giving '?' as argument.

    --pages <from>-<to>|'auto'
      Give the interval to work on. 'auto' will let the server assign
      an interval. That's the default - you do not need to enter that.

    --secret <[oldpassword:]password>
      Set or change password to protect your client-id. (and the attached
      BTC address). When setting for the first time, use an arbitrary
      string for oldpassword!

    --time <duration>
      Time constraint in case client is in pages 'auto' mode. This
      puts an upper limit on the client runtime. Format is h:m You are
      free to enter '60' for an hour instead of '1:0' If you specify a
      pages interval, this option has no effect.

    --update
      Perform only the update run. LBC will check for updates of
      itself, the generator and balance data.

    --version
      Prints the version of the LBC client and exits.

    --x
      Performs a thorough systemtest: if generator works, connection
      to server, enough memory, present helper binaries, benchmark...
      If this runs ok, your system will work.

then any of commands i give to register my username with this ./LBC -id annunaki1202 then reply with
Code:
anunnaki1202@Anunnaki:~$ ./LBC -id anunnaki1202
Will use 2 CPUs.
Ask for work... Server doesn't like us. Answer: wrong secret.

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
Will use 2 CPUs.
Testing mode. Using page 0, turning off looping.
Benchmark info not found - benchmarking... done.
Your speed is roughly 402766 keys/s per CPU core.
o
Test ok. Your test results were stored in FOUND.txt.
Have a look and then you may want to remove the file.
2d17543d32448acc7a1c43c5f72cd5be459ab302:u:priv:0000000000000000000000000000000000000000000000000000000000000001 + 0x5e
02e62151191a931d51cdc513a86d4bf5694f4e51:c:priv:0000000000000000000000000000000000000000000000000000000000000001 + 0x65
9d74ffdb31068ca2a1feb8e34830635c0647d714:u:priv:00000000000000000000000000000000000000000000000000000000000f9001 + 0xf8c
3d6871076780446bd46fc564b0c443e1fd415beb:c:priv:00000000000000000000000000000000000000000000000000000000000f9001 + 0xf8c

now when i give the command perl LBC -x I get reply as another error see below please

Code:
anunnaki1202@Anunnaki:~$ perl LBC -x
This script must run under the name 'LBC'.

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

uncompress format:
x = b009e153bd0df7fd2856ffbcbb71020bd69fbea49b20f7cd0b40e0ae98ff2486
y = 9a0f84d2862d23c4f576046ccba404586609646e8df5f59ec89e4c0bb9c58d7a

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

uncompress format:
x = b009e153bd0df7fd2856ffbcbb71020bd69fbea49b20f7cd0b40e0ae98ff2486
y = 9a0f84d2862d23c4f576046ccba404586609646e8df5f59ec89e4c0bb9c58d7a

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

uncompress format:
x = b009e153bd0df7fd2856ffbcbb71020bd69fbea49b20f7cd0b40e0ae98ff2486
y = 9a0f84d2862d23c4f576046ccba404586609646e8df5f59ec89e4c0bb9c58d7a

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?

Anyway my guess is that someone accessed to your "FOUND.txt" file (it is not encrypted). Probably your PC is not safe. LBC has nothing to do with this. it is not possible, see -> this post (https://bitcointalk.org/index.php?topic=1877935.msg45332348#msg45332348)


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!
- I checked but everything moved half hour after my LBC found it???
How moved out after half an hour?
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)

It is different public key.
Is this  first real collision?
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


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
c 4 means:  "use 4 cpus to feed the gpu"

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:

./LBC -c 16 -g -gopt dev=1,3,5,7 --id x --secret y


 


Title: Re: Large Bitcoin Collider Thread 2.0
Post by: kknd on November 26, 2018, 04:25:22 PM
Servers benchmark

http://kknd.com.br/etc/lbc.png


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
c 4 means:  "use 4 cpus to feed the gpu"

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:

./LBC -c 16 -g -gopt dev=1,3,5,7 --id x --secret y


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....