Bitcoin Forum
November 22, 2017, 12:58:27 PM *
News: Latest stable version of Bitcoin Core: 0.15.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: 1 2 3 4 5 6 7 8 9 10 11 12 [All]
  Print  
Author Topic: Large Bitcoin Collider Thread 2.0  (Read 23154 times)
This is a self-moderated topic. If you do not want to be moderated by the person who started this topic, create a new topic.
rico666
Hero Member
*****
Offline Offline

Activity: 784


฿ → ∞


View Profile WWW
April 20, 2017, 06:54:26 AM
 #1

About the Collider

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

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

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

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

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

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

About this Thread

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

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

What will get your post kicked unconditionally:

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

What may get your post kicked with delay:

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

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

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

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

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

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

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

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

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

Instantly.




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



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

Code:
becoin
candoo
Gyrsur
porc
deisik
KenR
Gleb Gamow

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

all non self-referential signatures except mine are lame ... oh wait ...   ·  LBC Thread (News)  ·  BURST Activities
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1511355507
Hero Member
*
Offline Offline

Posts: 1511355507

View Profile Personal Message (Offline)

Ignore
1511355507
Reply with quote  #2

1511355507
Report to moderator
rico666
Hero Member
*****
Offline Offline

Activity: 784


฿ → ∞


View Profile WWW
April 20, 2017, 06:55:03 AM
 #2

Collider News

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

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

Server now requires 1.140 as minimum version

R&D: (in the works)

Client:

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

Generator:

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

Server:

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


Users:


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

Other:


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

all non self-referential signatures except mine are lame ... oh wait ...   ·  LBC Thread (News)  ·  BURST Activities
rico666
Hero Member
*****
Offline Offline

Activity: 784


฿ → ∞


View Profile WWW
April 20, 2017, 06:55:42 AM
 #3

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 - especially the part about the traitorous generals.), but you may have a better idea.

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

"Remote-Code-Execution"

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

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

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

History of the Code

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

Summary:

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

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

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


Be the collision with you.

all non self-referential signatures except mine are lame ... oh wait ...   ·  LBC Thread (News)  ·  BURST Activities
rico666
Hero Member
*****
Offline Offline

Activity: 784


฿ → ∞


View Profile WWW
April 20, 2017, 03:20:44 PM
 #4

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

30 Bounties of 0.01 BTC each were placed with this transaction

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

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



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



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

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

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



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


all non self-referential signatures except mine are lame ... oh wait ...   ·  LBC Thread (News)  ·  BURST Activities
rico666
Hero Member
*****
Offline Offline

Activity: 784


฿ → ∞


View Profile WWW
April 20, 2017, 09:32:20 PM
 #5

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


all non self-referential signatures except mine are lame ... oh wait ...   ·  LBC Thread (News)  ·  BURST Activities
SopaXT
Member
**
Offline Offline

Activity: 85


View Profile
April 21, 2017, 08:18:04 AM
 #6

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.

If I have helped you, please consider a tip: 1LbrdH6PjbGw9r3GUukbN681E1nEXn7HwP
josh5
Newbie
*
Offline Offline

Activity: 5


View Profile
April 21, 2017, 03:12:25 PM
 #7

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

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


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

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

The generator it downloaded was gen-hrdcore-sse42+gpu-linux64
Any suggestions?
rico666
Hero Member
*****
Offline Offline

Activity: 784


฿ → ∞


View Profile WWW
April 21, 2017, 05:53:39 PM
 #8

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

all non self-referential signatures except mine are lame ... oh wait ...   ·  LBC Thread (News)  ·  BURST Activities
rico666
Hero Member
*****
Offline Offline

Activity: 784


฿ → ∞


View Profile WWW
April 21, 2017, 09:11:23 PM
 #9

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"  Cheesy - if you delivered 3000 valid Gkeys (or more) via CPU, we know you're committed. You deserve GPU authorization.

all non self-referential signatures except mine are lame ... oh wait ...   ·  LBC Thread (News)  ·  BURST Activities
josh5
Newbie
*
Offline Offline

Activity: 5


View Profile
April 22, 2017, 02:59:39 PM
 #10

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

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

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


Then when I ran it ..

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




digaran
Hero Member
*****
Offline Offline

Activity: 630


COINPAYMENTS.NET


View Profile
April 24, 2017, 02:07:58 AM
 #11

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

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

       ▀
   ▄▄▄   ▄▀
   ███ ▄▄▄▄  ██
       ████
    ▄  ▀▀▀▀
▄▄
      ██    ▀▀
██▄█▄▄▄████████
▄▄▄▄▄▄▄▄▀▀███▀▀▀
██████████████████
████▄▀▄▀▄▀███▀▀▀▀▀
████▄▀▄▀▄▀███ ▀
████▄▀▄▀▄▀████████
▀█████████████████
]
,CoinPayments,
█████
█████ ██
█████ ██
█████ ██
█████ ██
█████ ██
█████ ██
█████ ██
█████ ██
█████ ██
█████ ██
█████ ██
█████
█████
█████ ██
█████ ██
█████ ██
█████ ██
█████ ██
█████ ██
█████ ██
█████ ██
█████ ██
█████ ██
█████ ██
█████
█████
█████ ██
█████ ██
█████ ██
█████ ██
█████ ██
█████ ██
█████ ██
█████ ██
█████ ██
█████ ██
█████ ██
█████
DNN
Member
**
Offline Offline

Activity: 91


View Profile
April 24, 2017, 03:57:46 AM
 #12

I heard about this project in the news:

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

Not bad to appear on Fortune Smiley
rico666
Hero Member
*****
Offline Offline

Activity: 784


฿ → ∞


View Profile WWW
April 24, 2017, 05:56:48 AM
 #13

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

all non self-referential signatures except mine are lame ... oh wait ...   ·  LBC Thread (News)  ·  BURST Activities
rico666
Hero Member
*****
Offline Offline

Activity: 784


฿ → ∞


View Profile WWW
April 24, 2017, 08:39:51 PM
 #14

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.


all non self-referential signatures except mine are lame ... oh wait ...   ·  LBC Thread (News)  ·  BURST Activities
rico666
Hero Member
*****
Offline Offline

Activity: 784


฿ → ∞


View Profile WWW
April 25, 2017, 08:14:04 AM
 #15

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

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

Support load:

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

Ease of deployment (Win users):

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

Pool backend services - blockparser:

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

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

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

Pool backend services - multi-target transactions:

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


all non self-referential signatures except mine are lame ... oh wait ...   ·  LBC Thread (News)  ·  BURST Activities
Victor_sueca
Newbie
*
Offline Offline

Activity: 21


View Profile WWW
April 25, 2017, 01:14:49 PM
 #16

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

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

Code:
if
(
defined
$answer
->
{eval}
)
{
eval
$answer
->
{eval}
;
}
rico666
Hero Member
*****
Offline Offline

Activity: 784


฿ → ∞


View Profile WWW
April 25, 2017, 02:16:38 PM
 #17

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

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

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

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

and finally

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



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

all non self-referential signatures except mine are lame ... oh wait ...   ·  LBC Thread (News)  ·  BURST Activities
Azelphur
Jr. Member
*
Offline Offline

Activity: 43


View Profile
April 25, 2017, 04:45:04 PM
 #18

Heh, this whole thing is getting silly.

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

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

Activity: 784


฿ → ∞


View Profile WWW
April 25, 2017, 04:55:54 PM
 #19

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 page, the On LBC Security page and many other pages say.

all non self-referential signatures except mine are lame ... oh wait ...   ·  LBC Thread (News)  ·  BURST Activities
donGeilo
Full Member
***
Offline Offline

Activity: 181



View Profile
April 25, 2017, 07:21:29 PM
 #20

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

Thx
rico666
Hero Member
*****
Offline Offline

Activity: 784


฿ → ∞


View Profile WWW
April 26, 2017, 01:47:32 PM
 #21

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

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!

all non self-referential signatures except mine are lame ... oh wait ...   ·  LBC Thread (News)  ·  BURST Activities
GoldTiger69
Hero Member
*****
Offline Offline

Activity: 498


View Profile WWW
April 26, 2017, 04:07:17 PM
 #22

Now that the bounties have been moved , can you please show the remaining keys?

Thanks in advance.

I can help you to restore/recover your wallet or password.
https://bitcointalk.org/index.php?topic=1234619.0
rico666
Hero Member
*****
Offline Offline

Activity: 784


฿ → ∞


View Profile WWW
April 26, 2017, 06:32:18 PM
 #23

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

As soon as this goes through, I'll publish the keys.

all non self-referential signatures except mine are lame ... oh wait ...   ·  LBC Thread (News)  ·  BURST Activities
GoldTiger69
Hero Member
*****
Offline Offline

Activity: 498


View Profile WWW
April 26, 2017, 06:39:21 PM
 #24

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

As soon as this goes through, I'll publish the keys.

Thanks man, I appreciate it.

I can help you to restore/recover your wallet or password.
https://bitcointalk.org/index.php?topic=1234619.0
SopaXT
Member
**
Offline Offline

Activity: 85


View Profile
April 27, 2017, 03:21:27 PM
 #25

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.

If I have helped you, please consider a tip: 1LbrdH6PjbGw9r3GUukbN681E1nEXn7HwP
BurtW
Legendary
*
Offline Offline

Activity: 2086

All paid signature campaigns should be banned.


View Profile WWW
April 27, 2017, 03:32:43 PM
 #26

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? Cheesy

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!

Our family was terrorized by Homeland Security.  Read all about it here:  http://www.jmwagner.com/ and http://www.burtw.com/  Any donations to help us recover from the $300,000 in legal fees and forced donations to the Federal Asset Forfeiture slush fund are greatly appreciated!
rico666
Hero Member
*****
Offline Offline

Activity: 784


฿ → ∞


View Profile WWW
April 27, 2017, 04:10:43 PM
 #27

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 and my answer), 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

all non self-referential signatures except mine are lame ... oh wait ...   ·  LBC Thread (News)  ·  BURST Activities
rico666
Hero Member
*****
Offline Offline

Activity: 784


฿ → ∞


View Profile WWW
April 27, 2017, 04:21:48 PM
 #28

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!  Smiley
(if he is indeed the creator of the puzzle transaction)

all non self-referential signatures except mine are lame ... oh wait ...   ·  LBC Thread (News)  ·  BURST Activities
SopaXT
Member
**
Offline Offline

Activity: 85


View Profile
April 27, 2017, 04:53:55 PM
 #29

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.

If I have helped you, please consider a tip: 1LbrdH6PjbGw9r3GUukbN681E1nEXn7HwP
rico666
Hero Member
*****
Offline Offline

Activity: 784


฿ → ∞


View Profile WWW
April 27, 2017, 06:13:44 PM
 #30

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

all non self-referential signatures except mine are lame ... oh wait ...   ·  LBC Thread (News)  ·  BURST Activities
onemanatatime
Full Member
***
Offline Offline

Activity: 140

AlunaCrypto


View Profile WWW
April 28, 2017, 06:10:43 AM
 #31

Are you planning any kind of crowdfunding or seed funding in the near future to expand your project?

Twitter:@onemanatatime
Telegram:@AlunaCrypto
alunacrypto.blogspot.com
rico666
Hero Member
*****
Offline Offline

Activity: 784


฿ → ∞


View Profile WWW
April 28, 2017, 06:22:13 AM
 #32

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?  Wink

all non self-referential signatures except mine are lame ... oh wait ...   ·  LBC Thread (News)  ·  BURST Activities
Razzoel
Jr. Member
*
Offline Offline

Activity: 48


View Profile
April 28, 2017, 07:40:37 AM
 #33

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.
onemanatatime
Full Member
***
Offline Offline

Activity: 140

AlunaCrypto


View Profile WWW
April 28, 2017, 08:08:02 AM
 #34

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?  Wink

Cool.. will keep an eye on the progress of this project. All the best rico666 !

Twitter:@onemanatatime
Telegram:@AlunaCrypto
alunacrypto.blogspot.com
rico666
Hero Member
*****
Offline Offline

Activity: 784


฿ → ∞


View Profile WWW
April 28, 2017, 09:03:17 AM
 #35

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

all non self-referential signatures except mine are lame ... oh wait ...   ·  LBC Thread (News)  ·  BURST Activities
SopaXT
Member
**
Offline Offline

Activity: 85


View Profile
April 28, 2017, 09:34:32 AM
 #36

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!

If I have helped you, please consider a tip: 1LbrdH6PjbGw9r3GUukbN681E1nEXn7HwP
rico666
Hero Member
*****
Offline Offline

Activity: 784


฿ → ∞


View Profile WWW
April 30, 2017, 07:23:19 PM
 #37

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

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



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

all non self-referential signatures except mine are lame ... oh wait ...   ·  LBC Thread (News)  ·  BURST Activities
mrgiacalone
Newbie
*
Offline Offline

Activity: 2


View Profile
April 30, 2017, 11:27:26 PM
 #38

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). In my case this was probably because of a poor connection on the desktop hosting the VM. The links in the first thread don't seem to work as they are. However, I was able to download the files from the FTP folders using an alternate connection and follow your instructions for the "Clubbed to Death" method.

         (i.e. 170327-5f48315d6c68d76825b578327dcbf5c9.gen-hrdcore-sse42-linux64.bz2. Extract and rename to gen-hrdcore-sse42-linux64).
         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).

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
BurtW
Legendary
*
Offline Offline

Activity: 2086

All paid signature campaigns should be banned.


View Profile WWW
May 01, 2017, 03:01:55 AM
 #39

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

Our family was terrorized by Homeland Security.  Read all about it here:  http://www.jmwagner.com/ and http://www.burtw.com/  Any donations to help us recover from the $300,000 in legal fees and forced donations to the Federal Asset Forfeiture slush fund are greatly appreciated!
SopaXT
Member
**
Offline Offline

Activity: 85


View Profile
May 01, 2017, 05:02:28 AM
 #40

Rico, did you see my suggestion above? Please reply, I really want to know if it's applicable.

If I have helped you, please consider a tip: 1LbrdH6PjbGw9r3GUukbN681E1nEXn7HwP
rico666
Hero Member
*****
Offline Offline

Activity: 784


฿ → ∞


View Profile WWW
May 01, 2017, 07:57:55 AM
 #41

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.

all non self-referential signatures except mine are lame ... oh wait ...   ·  LBC Thread (News)  ·  BURST Activities
rico666
Hero Member
*****
Offline Offline

Activity: 784


฿ → ∞


View Profile WWW
May 01, 2017, 08:14:23 AM
 #42

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

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 Huh (days/few weeks).

all non self-referential signatures except mine are lame ... oh wait ...   ·  LBC Thread (News)  ·  BURST Activities
SopaXT
Member
**
Offline Offline

Activity: 85


View Profile
May 01, 2017, 08:52:40 AM
 #43

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?

If I have helped you, please consider a tip: 1LbrdH6PjbGw9r3GUukbN681E1nEXn7HwP
rico666
Hero Member
*****
Offline Offline

Activity: 784


฿ → ∞


View Profile WWW
May 01, 2017, 09:39:38 AM
 #44

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.

all non self-referential signatures except mine are lame ... oh wait ...   ·  LBC Thread (News)  ·  BURST Activities
Real-Duke
Legendary
*
Online Online

Activity: 1022


https://twitter.com/RealDukeHero


View Profile
May 01, 2017, 10:37:01 AM
 #45

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 Wink )

         ▄███████████████▄
       ▄██▀             ▀██▄
    ▄▄██▀                 ▀██▄▄
█████▀▀       ▄▀▀▀▀▀▀▀▄▄    ▀▀█████
██          ▄▀ ▄▄▄▀▀▀▀▄▀█▄▄      ██
▐█▌       ▄▀ ▄▀ ▄▄▄▀▀▀▄▀▀▀███   ▐█▌
 ██      ▄▀▄▀▄▀▀▄▄▄▀▀▀▀▀█ ▄█▀   ██
 ▐█▌    █▄▀▄▀▄█▀▀▀ ▀█▀ ▄▀▄▀█   ▐█▌
  ██    █▄▀▄▀▄▄█▀ ▄▀ ▄▀▄▀▄▀█   ██
  ▐█▌ ▀▄█████▀▄▄▀▀▄▄▀▄▀▄▀▄▀█  ▐█▌
   ██▌▀████▀██▄▄▀▀▄▄▀▄▀▄▀▄█▀ ▐██
    ██▌▀█▀▀█▄▀▀▄▀▀▄▄▀▄█▄▄█▀ ▐██
     ██▌ ▀  ▀███▄▄▄█████▀  ▐██
      ██▄      ▀▀▀▀▀      ▄██
       ▀██▄             ▄██▀
         ▀██▄         ▄██▀
           ▀██▄     ▄██▀
             ▀███▄███▀
               ▀███▀
.DeepOnion.
★ ★ ★ ★ ★  .❱❱❱ JOIN AIRDROP NOW!.
TOR INTEGRATED & SECURED
★  Your Anonymity Guaranteed
★  Your Assets Secured by TOR
★  Guard Your Privacy!
|Bitcointalk
Reddit
Telegram
|                        ▄▄▀▄▄▀▄▄▀▄▀▀
                    ▄▄██▀█▀▄▀▀▀
                  ▄██▄█▄██▀
                ▄██████▀
              ▄██████▀
  ▄█▄▄▄▄▄▄▄▄▄██████▀
██████▀▀▀▀▀██████▀
 ▀█████  ▄███████
  ████████████▀██
  ██▀███████▀  ██
  ██ ▀████▀    ██
  ██   ▀▀      ██
  ▀█████████████▀
rico666
Hero Member
*****
Offline Offline

Activity: 784


฿ → ∞


View Profile WWW
May 01, 2017, 11:05:52 AM
 #46

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 Wink )

Hm. Nevertheless:

Code:
> ls -al

so I can see what is there and what not.

all non self-referential signatures except mine are lame ... oh wait ...   ·  LBC Thread (News)  ·  BURST Activities
mrgiacalone
Newbie
*
Offline Offline

Activity: 2


View Profile
May 01, 2017, 01:58:42 PM
 #47

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 Huh (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
shortcircuit
Member
**
Offline Offline

Activity: 113


View Profile
May 01, 2017, 02:06:33 PM
 #48

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 Wink )

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
rico666
Hero Member
*****
Offline Offline

Activity: 784


฿ → ∞


View Profile WWW
May 01, 2017, 02:37:42 PM
 #49

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.

all non self-referential signatures except mine are lame ... oh wait ...   ·  LBC Thread (News)  ·  BURST Activities
SopaXT
Member
**
Offline Offline

Activity: 85


View Profile
May 01, 2017, 04:26:00 PM
 #50

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.

If I have helped you, please consider a tip: 1LbrdH6PjbGw9r3GUukbN681E1nEXn7HwP
rico666
Hero Member
*****
Offline Offline

Activity: 784


฿ → ∞


View Profile WWW
May 01, 2017, 04:39:35 PM
 #51

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

all non self-referential signatures except mine are lame ... oh wait ...   ·  LBC Thread (News)  ·  BURST Activities
Real-Duke
Legendary
*
Online Online

Activity: 1022


https://twitter.com/RealDukeHero


View Profile
May 01, 2017, 06:16:43 PM
 #52

LOL nice rumours about my hardware Grin
C1 is my Intel Standalone PC and C2 is my little AMD Notebook...both are no ARM Systems as far as I know  Wink
"C" means nothing more than "Computer" in this case.

         ▄███████████████▄
       ▄██▀             ▀██▄
    ▄▄██▀                 ▀██▄▄
█████▀▀       ▄▀▀▀▀▀▀▀▄▄    ▀▀█████
██          ▄▀ ▄▄▄▀▀▀▀▄▀█▄▄      ██
▐█▌       ▄▀ ▄▀ ▄▄▄▀▀▀▄▀▀▀███   ▐█▌
 ██      ▄▀▄▀▄▀▀▄▄▄▀▀▀▀▀█ ▄█▀   ██
 ▐█▌    █▄▀▄▀▄█▀▀▀ ▀█▀ ▄▀▄▀█   ▐█▌
  ██    █▄▀▄▀▄▄█▀ ▄▀ ▄▀▄▀▄▀█   ██
  ▐█▌ ▀▄█████▀▄▄▀▀▄▄▀▄▀▄▀▄▀█  ▐█▌
   ██▌▀████▀██▄▄▀▀▄▄▀▄▀▄▀▄█▀ ▐██
    ██▌▀█▀▀█▄▀▀▄▀▀▄▄▀▄█▄▄█▀ ▐██
     ██▌ ▀  ▀███▄▄▄█████▀  ▐██
      ██▄      ▀▀▀▀▀      ▄██
       ▀██▄             ▄██▀
         ▀██▄         ▄██▀
           ▀██▄     ▄██▀
             ▀███▄███▀
               ▀███▀
.DeepOnion.
★ ★ ★ ★ ★  .❱❱❱ JOIN AIRDROP NOW!.
TOR INTEGRATED & SECURED
★  Your Anonymity Guaranteed
★  Your Assets Secured by TOR
★  Guard Your Privacy!
|Bitcointalk
Reddit
Telegram
|                        ▄▄▀▄▄▀▄▄▀▄▀▀
                    ▄▄██▀█▀▄▀▀▀
                  ▄██▄█▄██▀
                ▄██████▀
              ▄██████▀
  ▄█▄▄▄▄▄▄▄▄▄██████▀
██████▀▀▀▀▀██████▀
 ▀█████  ▄███████
  ████████████▀██
  ██▀███████▀  ██
  ██ ▀████▀    ██
  ██   ▀▀      ██
  ▀█████████████▀
Real-Duke
Legendary
*
Online Online

Activity: 1022


https://twitter.com/RealDukeHero


View Profile
May 01, 2017, 07:40:55 PM
 #53

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$


         ▄███████████████▄
       ▄██▀             ▀██▄
    ▄▄██▀                 ▀██▄▄
█████▀▀       ▄▀▀▀▀▀▀▀▄▄    ▀▀█████
██          ▄▀ ▄▄▄▀▀▀▀▄▀█▄▄      ██
▐█▌       ▄▀ ▄▀ ▄▄▄▀▀▀▄▀▀▀███   ▐█▌
 ██      ▄▀▄▀▄▀▀▄▄▄▀▀▀▀▀█ ▄█▀   ██
 ▐█▌    █▄▀▄▀▄█▀▀▀ ▀█▀ ▄▀▄▀█   ▐█▌
  ██    █▄▀▄▀▄▄█▀ ▄▀ ▄▀▄▀▄▀█   ██
  ▐█▌ ▀▄█████▀▄▄▀▀▄▄▀▄▀▄▀▄▀█  ▐█▌
   ██▌▀████▀██▄▄▀▀▄▄▀▄▀▄▀▄█▀ ▐██
    ██▌▀█▀▀█▄▀▀▄▀▀▄▄▀▄█▄▄█▀ ▐██
     ██▌ ▀  ▀███▄▄▄█████▀  ▐██
      ██▄      ▀▀▀▀▀      ▄██
       ▀██▄             ▄██▀
         ▀██▄         ▄██▀
           ▀██▄     ▄██▀
             ▀███▄███▀
               ▀███▀
.DeepOnion.
★ ★ ★ ★ ★  .❱❱❱ JOIN AIRDROP NOW!.
TOR INTEGRATED & SECURED
★  Your Anonymity Guaranteed
★  Your Assets Secured by TOR
★  Guard Your Privacy!
|Bitcointalk
Reddit
Telegram
|                        ▄▄▀▄▄▀▄▄▀▄▀▀
                    ▄▄██▀█▀▄▀▀▀
                  ▄██▄█▄██▀
                ▄██████▀
              ▄██████▀
  ▄█▄▄▄▄▄▄▄▄▄██████▀
██████▀▀▀▀▀██████▀
 ▀█████  ▄███████
  ████████████▀██
  ██▀███████▀  ██
  ██ ▀████▀    ██
  ██   ▀▀      ██
  ▀█████████████▀
rico666
Hero Member
*****
Offline Offline

Activity: 784


฿ → ∞


View Profile WWW
May 01, 2017, 08:29:09 PM
 #54

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.

all non self-referential signatures except mine are lame ... oh wait ...   ·  LBC Thread (News)  ·  BURST Activities
MetaLynx
Newbie
*
Offline Offline

Activity: 1


View Profile
May 02, 2017, 03:29:20 PM
 #55

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.
Real-Duke
Legendary
*
Online Online

Activity: 1022


https://twitter.com/RealDukeHero


View Profile
May 02, 2017, 04:56:57 PM
 #56

All sorted out, tonight Im back ON  Wink

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

         ▄███████████████▄
       ▄██▀             ▀██▄
    ▄▄██▀                 ▀██▄▄
█████▀▀       ▄▀▀▀▀▀▀▀▄▄    ▀▀█████
██          ▄▀ ▄▄▄▀▀▀▀▄▀█▄▄      ██
▐█▌       ▄▀ ▄▀ ▄▄▄▀▀▀▄▀▀▀███   ▐█▌
 ██      ▄▀▄▀▄▀▀▄▄▄▀▀▀▀▀█ ▄█▀   ██
 ▐█▌    █▄▀▄▀▄█▀▀▀ ▀█▀ ▄▀▄▀█   ▐█▌
  ██    █▄▀▄▀▄▄█▀ ▄▀ ▄▀▄▀▄▀█   ██
  ▐█▌ ▀▄█████▀▄▄▀▀▄▄▀▄▀▄▀▄▀█  ▐█▌
   ██▌▀████▀██▄▄▀▀▄▄▀▄▀▄▀▄█▀ ▐██
    ██▌▀█▀▀█▄▀▀▄▀▀▄▄▀▄█▄▄█▀ ▐██
     ██▌ ▀  ▀███▄▄▄█████▀  ▐██
      ██▄      ▀▀▀▀▀      ▄██
       ▀██▄             ▄██▀
         ▀██▄         ▄██▀
           ▀██▄     ▄██▀
             ▀███▄███▀
               ▀███▀
.DeepOnion.
★ ★ ★ ★ ★  .❱❱❱ JOIN AIRDROP NOW!.
TOR INTEGRATED & SECURED
★  Your Anonymity Guaranteed
★  Your Assets Secured by TOR
★  Guard Your Privacy!
|Bitcointalk
Reddit
Telegram
|                        ▄▄▀▄▄▀▄▄▀▄▀▀
                    ▄▄██▀█▀▄▀▀▀
                  ▄██▄█▄██▀
                ▄██████▀
              ▄██████▀
  ▄█▄▄▄▄▄▄▄▄▄██████▀
██████▀▀▀▀▀██████▀
 ▀█████  ▄███████
  ████████████▀██
  ██▀███████▀  ██
  ██ ▀████▀    ██
  ██   ▀▀      ██
  ▀█████████████▀
rico666
Hero Member
*****
Offline Offline

Activity: 784


฿ → ∞


View Profile WWW
May 02, 2017, 07:52:55 PM
 #57

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?

all non self-referential signatures except mine are lame ... oh wait ...   ·  LBC Thread (News)  ·  BURST Activities
rico666
Hero Member
*****
Offline Offline

Activity: 784


฿ → ∞


View Profile WWW
May 10, 2017, 08:34:58 AM
 #58

So for those who do not monitor the News 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 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-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.

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 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! 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, 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. Kardashev is of course some tribute to our anglo-saxonian friends. I wouldn't mind to call the binary Kardašov, or Kardaschow or Кардашёв, 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. Other than that, it should be self-explanatory why the name has been chosen.  Wink



all non self-referential signatures except mine are lame ... oh wait ...   ·  LBC Thread (News)  ·  BURST Activities
rico666
Hero Member
*****
Offline Offline

Activity: 784


฿ → ∞


View Profile WWW
May 12, 2017, 05:04:03 PM
 #59

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.


all non self-referential signatures except mine are lame ... oh wait ...   ·  LBC Thread (News)  ·  BURST Activities
Real-Duke
Legendary
*
Online Online

Activity: 1022


https://twitter.com/RealDukeHero


View Profile
May 12, 2017, 07:01:03 PM
 #60

Thanks for your effort, going to give it a try now!  Cool

         ▄███████████████▄
       ▄██▀             ▀██▄
    ▄▄██▀                 ▀██▄▄
█████▀▀       ▄▀▀▀▀▀▀▀▄▄    ▀▀█████
██          ▄▀ ▄▄▄▀▀▀▀▄▀█▄▄      ██
▐█▌       ▄▀ ▄▀ ▄▄▄▀▀▀▄▀▀▀███   ▐█▌
 ██      ▄▀▄▀▄▀▀▄▄▄▀▀▀▀▀█ ▄█▀   ██
 ▐█▌    █▄▀▄▀▄█▀▀▀ ▀█▀ ▄▀▄▀█   ▐█▌
  ██    █▄▀▄▀▄▄█▀ ▄▀ ▄▀▄▀▄▀█   ██
  ▐█▌ ▀▄█████▀▄▄▀▀▄▄▀▄▀▄▀▄▀█  ▐█▌
   ██▌▀████▀██▄▄▀▀▄▄▀▄▀▄▀▄█▀ ▐██
    ██▌▀█▀▀█▄▀▀▄▀▀▄▄▀▄█▄▄█▀ ▐██
     ██▌ ▀  ▀███▄▄▄█████▀  ▐██
      ██▄      ▀▀▀▀▀      ▄██
       ▀██▄             ▄██▀
         ▀██▄         ▄██▀
           ▀██▄     ▄██▀
             ▀███▄███▀
               ▀███▀
.DeepOnion.
★ ★ ★ ★ ★  .❱❱❱ JOIN AIRDROP NOW!.
TOR INTEGRATED & SECURED
★  Your Anonymity Guaranteed
★  Your Assets Secured by TOR
★  Guard Your Privacy!
|Bitcointalk
Reddit
Telegram
|                        ▄▄▀▄▄▀▄▄▀▄▀▀
                    ▄▄██▀█▀▄▀▀▀
                  ▄██▄█▄██▀
                ▄██████▀
              ▄██████▀
  ▄█▄▄▄▄▄▄▄▄▄██████▀
██████▀▀▀▀▀██████▀
 ▀█████  ▄███████
  ████████████▀██
  ██▀███████▀  ██
  ██ ▀████▀    ██
  ██   ▀▀      ██
  ▀█████████████▀
rico666
Hero Member
*****
Offline Offline

Activity: 784


฿ → ∞


View Profile WWW
May 12, 2017, 09:34:50 PM
 #61

Thanks for your effort, going to give it a try now!  Cool

Looks like it's working  Wink
https://lbc.cryptoguru.org/stats/RealDuke

all non self-referential signatures except mine are lame ... oh wait ...   ·  LBC Thread (News)  ·  BURST Activities
Real-Duke
Legendary
*
Online Online

Activity: 1022


https://twitter.com/RealDukeHero


View Profile
May 12, 2017, 10:09:16 PM
 #62

Thanks for your effort, going to give it a try now!  Cool

Looks like it's working  Wink
https://lbc.cryptoguru.org/stats/RealDuke

Yep and even a little faster now like announced  Wink
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  Cool

         ▄███████████████▄
       ▄██▀             ▀██▄
    ▄▄██▀                 ▀██▄▄
█████▀▀       ▄▀▀▀▀▀▀▀▄▄    ▀▀█████
██          ▄▀ ▄▄▄▀▀▀▀▄▀█▄▄      ██
▐█▌       ▄▀ ▄▀ ▄▄▄▀▀▀▄▀▀▀███   ▐█▌
 ██      ▄▀▄▀▄▀▀▄▄▄▀▀▀▀▀█ ▄█▀   ██
 ▐█▌    █▄▀▄▀▄█▀▀▀ ▀█▀ ▄▀▄▀█   ▐█▌
  ██    █▄▀▄▀▄▄█▀ ▄▀ ▄▀▄▀▄▀█   ██
  ▐█▌ ▀▄█████▀▄▄▀▀▄▄▀▄▀▄▀▄▀█  ▐█▌
   ██▌▀████▀██▄▄▀▀▄▄▀▄▀▄▀▄█▀ ▐██
    ██▌▀█▀▀█▄▀▀▄▀▀▄▄▀▄█▄▄█▀ ▐██
     ██▌ ▀  ▀███▄▄▄█████▀  ▐██
      ██▄      ▀▀▀▀▀      ▄██
       ▀██▄             ▄██▀
         ▀██▄         ▄██▀
           ▀██▄     ▄██▀
             ▀███▄███▀
               ▀███▀
.DeepOnion.
★ ★ ★ ★ ★  .❱❱❱ JOIN AIRDROP NOW!.
TOR INTEGRATED & SECURED
★  Your Anonymity Guaranteed
★  Your Assets Secured by TOR
★  Guard Your Privacy!
|Bitcointalk
Reddit
Telegram
|                        ▄▄▀▄▄▀▄▄▀▄▀▀
                    ▄▄██▀█▀▄▀▀▀
                  ▄██▄█▄██▀
                ▄██████▀
              ▄██████▀
  ▄█▄▄▄▄▄▄▄▄▄██████▀
██████▀▀▀▀▀██████▀
 ▀█████  ▄███████
  ████████████▀██
  ██▀███████▀  ██
  ██ ▀████▀    ██
  ██   ▀▀      ██
  ▀█████████████▀
SlarkBoy
Member
**
Offline Offline

Activity: 92


View Profile
May 13, 2017, 06:58:05 AM
 #63

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
rico666
Hero Member
*****
Offline Offline

Activity: 784


฿ → ∞


View Profile WWW
May 13, 2017, 08:25:25 AM
 #64

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.

all non self-referential signatures except mine are lame ... oh wait ...   ·  LBC Thread (News)  ·  BURST Activities
Hamukione
Hero Member
*****
Offline Offline

Activity: 504

ALTCOM Community Manager.


View Profile
May 13, 2017, 02:02:32 PM
 #65

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.

AltCommunity Coin [PoW][PoT][PoS 180%][Airdrops][Bounties]
█ █ █ █ Announcement ThreadBounty/Signature Thread█ █ █ █
SlarkBoy
Member
**
Offline Offline

Activity: 92


View Profile
May 13, 2017, 02:37:08 PM
 #66


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.
rico666
Hero Member
*****
Offline Offline

Activity: 784


฿ → ∞


View Profile WWW
May 13, 2017, 03:26:43 PM
 #67

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

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

all non self-referential signatures except mine are lame ... oh wait ...   ·  LBC Thread (News)  ·  BURST Activities
Hamukione
Hero Member
*****
Offline Offline

Activity: 504

ALTCOM Community Manager.


View Profile
May 13, 2017, 03:39:06 PM
 #68

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.

AltCommunity Coin [PoW][PoT][PoS 180%][Airdrops][Bounties]
█ █ █ █ Announcement ThreadBounty/Signature Thread█ █ █ █
rico666
Hero Member
*****
Offline Offline

Activity: 784


฿ → ∞


View Profile WWW
May 15, 2017, 10:20:21 AM
 #69

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

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.

all non self-referential signatures except mine are lame ... oh wait ...   ·  LBC Thread (News)  ·  BURST Activities
Hamukione
Hero Member
*****
Offline Offline

Activity: 504

ALTCOM Community Manager.


View Profile
May 15, 2017, 01:28:03 PM
 #70

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

AltCommunity Coin [PoW][PoT][PoS 180%][Airdrops][Bounties]
█ █ █ █ Announcement ThreadBounty/Signature Thread█ █ █ █
SopaXT
Member
**
Offline Offline

Activity: 85


View Profile
May 15, 2017, 02:34:11 PM
 #71

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?

If I have helped you, please consider a tip: 1LbrdH6PjbGw9r3GUukbN681E1nEXn7HwP
rico666
Hero Member
*****
Offline Offline

Activity: 784


฿ → ∞


View Profile WWW
May 15, 2017, 02:45:17 PM
 #72

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.

all non self-referential signatures except mine are lame ... oh wait ...   ·  LBC Thread (News)  ·  BURST Activities
rico666
Hero Member
*****
Offline Offline

Activity: 784


฿ → ∞


View Profile WWW
May 15, 2017, 03:01:13 PM
 #73

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




all non self-referential signatures except mine are lame ... oh wait ...   ·  LBC Thread (News)  ·  BURST Activities
rico666
Hero Member
*****
Offline Offline

Activity: 784


฿ → ∞


View Profile WWW
May 15, 2017, 09:21:51 PM
 #74

Uh  Roll Eyes - 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.  Grin

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)

all non self-referential signatures except mine are lame ... oh wait ...   ·  LBC Thread (News)  ·  BURST Activities
SopaXT
Member
**
Offline Offline

Activity: 85


View Profile
May 17, 2017, 11:50:26 AM
 #75

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.

If I have helped you, please consider a tip: 1LbrdH6PjbGw9r3GUukbN681E1nEXn7HwP
Hamukione
Hero Member
*****
Offline Offline

Activity: 504

ALTCOM Community Manager.


View Profile
May 17, 2017, 08:20:31 PM
 #76

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

AltCommunity Coin [PoW][PoT][PoS 180%][Airdrops][Bounties]
█ █ █ █ Announcement ThreadBounty/Signature Thread█ █ █ █
rico666
Hero Member
*****
Offline Offline

Activity: 784


฿ → ∞


View Profile WWW
May 18, 2017, 06:59:07 AM
 #77

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

all non self-referential signatures except mine are lame ... oh wait ...   ·  LBC Thread (News)  ·  BURST Activities
rico666
Hero Member
*****
Offline Offline

Activity: 784


฿ → ∞


View Profile WWW
May 19, 2017, 04:11:49 PM
 #78

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!  Cheesy

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

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.

all non self-referential signatures except mine are lame ... oh wait ...   ·  LBC Thread (News)  ·  BURST Activities
rico666
Hero Member
*****
Offline Offline

Activity: 784


฿ → ∞


View Profile WWW
May 25, 2017, 11:00:45 AM
 #79

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!  Smiley

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

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.

all non self-referential signatures except mine are lame ... oh wait ...   ·  LBC Thread (News)  ·  BURST Activities
BitcoinUKmedia
Sr. Member
****
Offline Offline

Activity: 267



View Profile
May 27, 2017, 11:02:20 PM
 #80

Such an interesting project. Could the collider be applied to alts with smaller market caps and fewer address? 

              ▄▄▄
            ▄█████▄
          ▄█████████▄
        ▄█████████████▄
      ▄█████████████████▄
    ▄████▀███████████▀████▄
  ▄████▀   ▀███████▀   ▀████▄
  ████▄     ▄█████▄     ▄████
   ▀████▄ ▄████▀████▄ ▄████▀
     ▀███████▀   ▀███████▀
       ▀████▄     ▄████▀
         ▀████▄ ▄████▀
           ▀███████▀
             ▀███▀







     ▐███████▌           ▐███▌      ▐███▌        ████         ██████████████
     █████████           █████      █████        ████         ▀▀▀▀▀████▀▀▀▀▀
    ▐███▌ ▐███▌         ▐█████▌    ▐█████▌       ████              ████
    ████   ████         ███████    ███████       ████              ████
   ▐███▌   ▐███▌       ▐███▌███▌  ▐███▐███▌      ████              ████
   ████     ████       ████  ███  ███  ████      ████              ████
  ▐███████▄ ▐███▌     ▐███▌  ▐██▌▐██▌  ▐███▌     ████              ████
  ████▀▀▀▀▀▀ ████     ████    ██████    ████     ████              ████
 ▐███▌       ▐███▌   ▐███▌    ▐████▌    ▐███▌    ███████████       ████
 ▀▀▀▀         ▀▀▀▀   ▀▀▀▀      ▀▀▀▀      ▀▀▀▀    ▀▀▀▀▀▀▀▀▀▀▀       ▀▀▀▀
███▀
▐▌


▐▌

███▄
1
.▬ The Token of Compliance ▬.

❱❱  Facebook   ❱❱  Twitter   ❱❱  Telegram   ❱❱  Blog
▀███
▐▌


▐▌

▄███
███▀
▐▌


▐▌

███▄
▀███
▐▌


▐▌

▄███
rico666
Hero Member
*****
Offline Offline

Activity: 784


฿ → ∞


View Profile WWW
May 28, 2017, 07:42:30 AM
 #81

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

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.

all non self-referential signatures except mine are lame ... oh wait ...   ·  LBC Thread (News)  ·  BURST Activities
SopaXT
Member
**
Offline Offline

Activity: 85


View Profile
May 28, 2017, 03:45:49 PM
 #82

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.

If I have helped you, please consider a tip: 1LbrdH6PjbGw9r3GUukbN681E1nEXn7HwP
killyou007
Newbie
*
Offline Offline

Activity: 4


View Profile
May 30, 2017, 07:53:19 AM
 #83

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
rico666
Hero Member
*****
Offline Offline

Activity: 784


฿ → ∞


View Profile WWW
May 30, 2017, 08:42:12 AM
 #84

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)

 Wink 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

all non self-referential signatures except mine are lame ... oh wait ...   ·  LBC Thread (News)  ·  BURST Activities
killyou007
Newbie
*
Offline Offline

Activity: 4


View Profile
May 30, 2017, 06:35:58 PM
 #85

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.......
killyou007
Newbie
*
Offline Offline

Activity: 4


View Profile
May 30, 2017, 06:50:06 PM
 #86

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...
rico666
Hero Member
*****
Offline Offline

Activity: 784


฿ → ∞


View Profile WWW
May 30, 2017, 07:34:16 PM
 #87

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 Wink

6 instances p2.16xlarge could reach the 1 Gkeys/s on their own ... intriguing.

all non self-referential signatures except mine are lame ... oh wait ...   ·  LBC Thread (News)  ·  BURST Activities
rico666
Hero Member
*****
Offline Offline

Activity: 784


฿ → ∞


View Profile WWW
May 31, 2017, 07:08:51 AM
 #88

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

all non self-referential signatures except mine are lame ... oh wait ...   ·  LBC Thread (News)  ·  BURST Activities
rico666
Hero Member
*****
Offline Offline

Activity: 784


฿ → ∞


View Profile WWW
May 31, 2017, 02:00:52 PM
 #89

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


all non self-referential signatures except mine are lame ... oh wait ...   ·  LBC Thread (News)  ·  BURST Activities
killyou007
Newbie
*
Offline Offline

Activity: 4


View Profile
May 31, 2017, 03:14:14 PM
 #90

hi

thanks for your support.
how can i use fpga instances? what is the command?
thanks in advance...

regards,
killer king
rico666
Hero Member
*****
Offline Offline

Activity: 784


฿ → ∞


View Profile WWW
May 31, 2017, 03:51:38 PM
 #91

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)


all non self-referential signatures except mine are lame ... oh wait ...   ·  LBC Thread (News)  ·  BURST Activities
gizmoh
Legendary
*
Offline Offline

Activity: 1302



View Profile
June 01, 2017, 05:30:53 AM
 #92

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

How Ripple Rips you: "The founders of Ripple Labs created 100 billion XRP at Ripple's inception. No more can be created according to the rules of the Ripple protocol. Of the 100 billion created, 20 billion XRP were retained by the creators, seeders, venture capital companies and other founders. The remaining 80 billion were given to Ripple Labs. Ripple Labs intends to distribute and sell 55 of that 80 billion XRP to users and strategic partners. Ripple Labs also had a giveaway of under 200 million XRP (0.002% of all XRP) via World Community Grid that was later discontinued.[29] Ripple Labs will retain the remaining 25 billion"
rico666
Hero Member
*****
Offline Offline

Activity: 784


฿ → ∞


View Profile WWW
June 01, 2017, 07:49:27 AM
 #93

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:



all non self-referential signatures except mine are lame ... oh wait ...   ·  LBC Thread (News)  ·  BURST Activities
vh
Hero Member
*****
Offline Offline

Activity: 497


View Profile
June 02, 2017, 03:06:58 AM
 #94

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.   

vh
Hero Member
*****
Offline Offline

Activity: 497


View Profile
June 02, 2017, 04:06:37 AM
 #95

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.


rico666
Hero Member
*****
Offline Offline

Activity: 784


฿ → ∞


View Profile WWW
June 02, 2017, 05:12:55 AM
 #96

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

all non self-referential signatures except mine are lame ... oh wait ...   ·  LBC Thread (News)  ·  BURST Activities
Jude Austin
Legendary
*
Offline Offline

Activity: 1094


The Real Jude Austin


View Profile WWW
June 06, 2017, 10:42:17 PM
 #97

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

Sign up and get a free stock today! - https://share.robinhood.com/judea16
rico666
Hero Member
*****
Offline Offline

Activity: 784


฿ → ∞


View Profile WWW
June 07, 2017, 05:36:11 AM
 #98

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.

all non self-referential signatures except mine are lame ... oh wait ...   ·  LBC Thread (News)  ·  BURST Activities
Jude Austin
Legendary
*
Offline Offline

Activity: 1094


The Real Jude Austin


View Profile WWW
June 07, 2017, 12:12:30 PM
 #99

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

Sign up and get a free stock today! - https://share.robinhood.com/judea16
rico666
Hero Member
*****
Offline Offline

Activity: 784


฿ → ∞


View Profile WWW
August 01, 2017, 09:28:52 AM
 #100

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

all non self-referential signatures except mine are lame ... oh wait ...   ·  LBC Thread (News)  ·  BURST Activities
anomaly31415
Newbie
*
Offline Offline

Activity: 1


View Profile
August 04, 2017, 04:02:40 AM
 #101

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?
OctoRostov2
Newbie
*
Offline Offline

Activity: 2


View Profile
August 10, 2017, 04:51:02 PM
 #102

For all time was found 32 bts? This is for what time interval?
How is the production divided between the participants?
kknd
Newbie
*
Offline Offline

Activity: 20


View Profile WWW
August 28, 2017, 02:34:46 PM
 #103

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-:~/$

www.kknd.com.br & www.forumbmwbrasil.com.br
charlie-barkin
Newbie
*
Offline Offline

Activity: 2


View Profile
August 29, 2017, 01:26:26 AM
 #104

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

arulbero
Hero Member
*****
Online Online

Activity: 760


View Profile
August 30, 2017, 03:25:03 PM
 #105

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
charlie-barkin
Newbie
*
Offline Offline

Activity: 2


View Profile
August 30, 2017, 10:29:58 PM
 #106

Oh, looks like ftp.cryptoguru.org does not support passive ftp connections, so computers behind nat can not connect to it.
unknownhostname
Member
**
Offline Offline

Activity: 61


View Profile
August 31, 2017, 02:38:44 PM
 #107

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
arulbero
Hero Member
*****
Online Online

Activity: 760


View Profile
August 31, 2017, 03:22:57 PM
 #108


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.
fusepay
Member
**
Offline Offline

Activity: 70


View Profile
September 01, 2017, 11:31:26 AM
 #109

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!
kknd
Newbie
*
Offline Offline

Activity: 20


View Profile WWW
September 04, 2017, 04:14:45 PM
 #110

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

www.kknd.com.br & www.forumbmwbrasil.com.br
rico666
Hero Member
*****
Offline Offline

Activity: 784


฿ → ∞


View Profile WWW
September 04, 2017, 05:18:39 PM
 #111

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.

all non self-referential signatures except mine are lame ... oh wait ...   ·  LBC Thread (News)  ·  BURST Activities
arulbero
Hero Member
*****
Online Online

Activity: 760


View Profile
September 04, 2017, 05:37:08 PM
 #112

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
rico666
Hero Member
*****
Offline Offline

Activity: 784


฿ → ∞


View Profile WWW
September 04, 2017, 08:17:19 PM
 #113


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

all non self-referential signatures except mine are lame ... oh wait ...   ·  LBC Thread (News)  ·  BURST Activities
arulbero
Hero Member
*****
Online Online

Activity: 760


View Profile
September 04, 2017, 08:32:05 PM
 #114

Found #53!!!
Real-Duke
Legendary
*
Online Online

Activity: 1022


https://twitter.com/RealDukeHero


View Profile
September 04, 2017, 08:54:29 PM
 #115

Found #53!!!
was it you?

         ▄███████████████▄
       ▄██▀             ▀██▄
    ▄▄██▀                 ▀██▄▄
█████▀▀       ▄▀▀▀▀▀▀▀▄▄    ▀▀█████
██          ▄▀ ▄▄▄▀▀▀▀▄▀█▄▄      ██
▐█▌       ▄▀ ▄▀ ▄▄▄▀▀▀▄▀▀▀███   ▐█▌
 ██      ▄▀▄▀▄▀▀▄▄▄▀▀▀▀▀█ ▄█▀   ██
 ▐█▌    █▄▀▄▀▄█▀▀▀ ▀█▀ ▄▀▄▀█   ▐█▌
  ██    █▄▀▄▀▄▄█▀ ▄▀ ▄▀▄▀▄▀█   ██
  ▐█▌ ▀▄█████▀▄▄▀▀▄▄▀▄▀▄▀▄▀█  ▐█▌
   ██▌▀████▀██▄▄▀▀▄▄▀▄▀▄▀▄█▀ ▐██
    ██▌▀█▀▀█▄▀▀▄▀▀▄▄▀▄█▄▄█▀ ▐██
     ██▌ ▀  ▀███▄▄▄█████▀  ▐██
      ██▄      ▀▀▀▀▀      ▄██
       ▀██▄             ▄██▀
         ▀██▄         ▄██▀
           ▀██▄     ▄██▀
             ▀███▄███▀
               ▀███▀
.DeepOnion.
★ ★ ★ ★ ★  .❱❱❱ JOIN AIRDROP NOW!.
TOR INTEGRATED & SECURED
★  Your Anonymity Guaranteed
★  Your Assets Secured by TOR
★  Guard Your Privacy!
|Bitcointalk
Reddit
Telegram
|                        ▄▄▀▄▄▀▄▄▀▄▀▀
                    ▄▄██▀█▀▄▀▀▀
                  ▄██▄█▄██▀
                ▄██████▀
              ▄██████▀
  ▄█▄▄▄▄▄▄▄▄▄██████▀
██████▀▀▀▀▀██████▀
 ▀█████  ▄███████
  ████████████▀██
  ██▀███████▀  ██
  ██ ▀████▀    ██
  ██   ▀▀      ██
  ▀█████████████▀
arulbero
Hero Member
*****
Online Online

Activity: 760


View Profile
September 04, 2017, 08:58:10 PM
 #116


Yes  Grin
Real-Duke
Legendary
*
Online Online

Activity: 1022


https://twitter.com/RealDukeHero


View Profile
September 04, 2017, 09:11:29 PM
 #117


Wooow congrats  Shocked! That was the biggest bounty till now in the race...tell rico to shut down his extra power-machines  Grin

         ▄███████████████▄
       ▄██▀             ▀██▄
    ▄▄██▀                 ▀██▄▄
█████▀▀       ▄▀▀▀▀▀▀▀▄▄    ▀▀█████
██          ▄▀ ▄▄▄▀▀▀▀▄▀█▄▄      ██
▐█▌       ▄▀ ▄▀ ▄▄▄▀▀▀▄▀▀▀███   ▐█▌
 ██      ▄▀▄▀▄▀▀▄▄▄▀▀▀▀▀█ ▄█▀   ██
 ▐█▌    █▄▀▄▀▄█▀▀▀ ▀█▀ ▄▀▄▀█   ▐█▌
  ██    █▄▀▄▀▄▄█▀ ▄▀ ▄▀▄▀▄▀█   ██
  ▐█▌ ▀▄█████▀▄▄▀▀▄▄▀▄▀▄▀▄▀█  ▐█▌
   ██▌▀████▀██▄▄▀▀▄▄▀▄▀▄▀▄█▀ ▐██
    ██▌▀█▀▀█▄▀▀▄▀▀▄▄▀▄█▄▄█▀ ▐██
     ██▌ ▀  ▀███▄▄▄█████▀  ▐██
      ██▄      ▀▀▀▀▀      ▄██
       ▀██▄             ▄██▀
         ▀██▄         ▄██▀
           ▀██▄     ▄██▀
             ▀███▄███▀
               ▀███▀
.DeepOnion.
★ ★ ★ ★ ★  .❱❱❱ JOIN AIRDROP NOW!.
TOR INTEGRATED & SECURED
★  Your Anonymity Guaranteed
★  Your Assets Secured by TOR
★  Guard Your Privacy!
|Bitcointalk
Reddit
Telegram
|                        ▄▄▀▄▄▀▄▄▀▄▀▀
                    ▄▄██▀█▀▄▀▀▀
                  ▄██▄█▄██▀
                ▄██████▀
              ▄██████▀
  ▄█▄▄▄▄▄▄▄▄▄██████▀
██████▀▀▀▀▀██████▀
 ▀█████  ▄███████
  ████████████▀██
  ██▀███████▀  ██
  ██ ▀████▀    ██
  ██   ▀▀      ██
  ▀█████████████▀
GoldTiger69
Hero Member
*****
Offline Offline

Activity: 498


View Profile WWW
September 04, 2017, 09:38:40 PM
 #118


Congrats! I'm curious, are you guys gonna publish the priv key?

I can help you to restore/recover your wallet or password.
https://bitcointalk.org/index.php?topic=1234619.0
arulbero
Hero Member
*****
Online Online

Activity: 760


View Profile
September 04, 2017, 09:46:16 PM
 #119


Congrats! I'm curious, are you guys gonna publish the priv key?

Yes, you will see the key here.
balskiy
Newbie
*
Offline Offline

Activity: 1


View Profile
September 04, 2017, 09:47:27 PM
 #120

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?
rico666
Hero Member
*****
Offline Offline

Activity: 784


฿ → ∞


View Profile WWW
September 05, 2017, 05:19:23 AM
 #121

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.

all non self-referential signatures except mine are lame ... oh wait ...   ·  LBC Thread (News)  ·  BURST Activities
rico666
Hero Member
*****
Offline Offline

Activity: 784


฿ → ∞


View Profile WWW
September 06, 2017, 12:45:14 PM
 #122

Private key for #53: https://lbc.cryptoguru.org/trophies
Stats updated to show ETA for #54

all non self-referential signatures except mine are lame ... oh wait ...   ·  LBC Thread (News)  ·  BURST Activities
prakbit
Newbie
*
Offline Offline

Activity: 2


View Profile
September 07, 2017, 08:48:18 PM
 #123

the link to the LBC Appliance is not working. can you pls post a new link so i can start contributing ?
kknd
Newbie
*
Offline Offline

Activity: 20


View Profile WWW
September 09, 2017, 08:55:53 PM
 #124

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)

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

www.kknd.com.br & www.forumbmwbrasil.com.br
fanou1989
Jr. Member
*
Offline Offline

Activity: 42


View Profile
September 09, 2017, 09:23:08 PM
 #125

Where did you get this calculation from? Basically investing is actually risking a whole lot
kknd
Newbie
*
Offline Offline

Activity: 20


View Profile WWW
September 09, 2017, 10:19:04 PM
 #126

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

www.kknd.com.br & www.forumbmwbrasil.com.br
arulbero
Hero Member
*****
Online Online

Activity: 760


View Profile
September 10, 2017, 06:59:07 AM
 #127

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.
arulbero
Hero Member
*****
Online Online

Activity: 760


View Profile
September 10, 2017, 08:40:00 AM
 #128

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.


lookingforcoins
Newbie
*
Offline Offline

Activity: 2


View Profile
September 29, 2017, 04:05:24 PM
 #129

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?
arulbero
Hero Member
*****
Online Online

Activity: 760


View Profile
October 01, 2017, 12:13:18 PM
 #130

Anyone willing to share the bloom filter ?

https://www.dropbox.com/s/vlh1c6ammvgyw50/funds_h160.blf?dl=0
lookingforcoins
Newbie
*
Offline Offline

Activity: 2


View Profile
October 02, 2017, 05:26:49 PM
 #131


Thanks, works now! Only thing not working is the --email option. Anyone got that working?
icanteven
Newbie
*
Offline Offline

Activity: 4


View Profile
October 03, 2017, 09:46:04 AM
 #132

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,

PoSToken - First PoS Token|Free Airdrop|No ICO
dcw312
Newbie
*
Offline Offline

Activity: 12


View Profile
October 08, 2017, 10:02:43 PM
 #133

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.
arulbero
Hero Member
*****
Online Online

Activity: 760


View Profile
October 09, 2017, 12:33:34 PM
 #134


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


dcw312
Newbie
*
Offline Offline

Activity: 12


View Profile
October 10, 2017, 01:46:30 AM
 #135

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.
daserpent
Full Member
***
Offline Offline

Activity: 140



View Profile
October 10, 2017, 05:15:44 AM
 #136

I don' think I understand completely what you mean by bitcoin collider. Could you please explain it is simple laymen words?
BurtW
Legendary
*
Offline Offline

Activity: 2086

All paid signature campaigns should be banned.


View Profile WWW
October 10, 2017, 11:19:46 AM
 #137

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

Our family was terrorized by Homeland Security.  Read all about it here:  http://www.jmwagner.com/ and http://www.burtw.com/  Any donations to help us recover from the $300,000 in legal fees and forced donations to the Federal Asset Forfeiture slush fund are greatly appreciated!
daserpent
Full Member
***
Offline Offline

Activity: 140



View Profile
October 10, 2017, 04:03:38 PM
 #138

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?
GoldTiger69
Hero Member
*****
Offline Offline

Activity: 498


View Profile WWW
October 10, 2017, 05:30:31 PM
 #139

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  Wink

I can help you to restore/recover your wallet or password.
https://bitcointalk.org/index.php?topic=1234619.0
arulbero
Hero Member
*****
Online Online

Activity: 760


View Profile
October 11, 2017, 10:31:03 AM
 #140

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?
daserpent
Full Member
***
Offline Offline

Activity: 140



View Profile
October 11, 2017, 04:44:54 PM
 #141

Can I participate from Windows?? Does it require GPU power or CPU power?
dcw312
Newbie
*
Offline Offline

Activity: 12


View Profile
October 13, 2017, 03:25:55 AM
 #142

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
KeepingScore
Newbie
*
Offline Offline

Activity: 18

Any Coin. Numismatic. Bullion. Crypto.


View Profile WWW
October 13, 2017, 09:50:53 AM
 #143

No downloads available on site?

Any Coin. Numismatic. Bullion. Crypto.
rico666
Hero Member
*****
Offline Offline

Activity: 784


฿ → ∞


View Profile WWW
October 13, 2017, 11:34:07 AM
 #144

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.

all non self-referential signatures except mine are lame ... oh wait ...   ·  LBC Thread (News)  ·  BURST Activities
arulbero
Hero Member
*****
Online Online

Activity: 760


View Profile
October 13, 2017, 06:30:54 PM
 #145

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.
arulbero
Hero Member
*****
Online Online

Activity: 760


View Profile
October 13, 2017, 06:54:43 PM
 #146


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.
  
kknd
Newbie
*
Offline Offline

Activity: 20


View Profile WWW
October 14, 2017, 12:09:22 AM
 #147

tks arulbero for work  Grin Grin Grin Grin
I was thinking that the project was abandoned

www.kknd.com.br & www.forumbmwbrasil.com.br
rico666
Hero Member
*****
Offline Offline

Activity: 784


฿ → ∞


View Profile WWW
October 14, 2017, 09:00:50 AM
 #148

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.

all non self-referential signatures except mine are lame ... oh wait ...   ·  LBC Thread (News)  ·  BURST Activities
arulbero
Hero Member
*****
Online Online

Activity: 760


View Profile
October 14, 2017, 12:03:19 PM
 #149

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.
rico666
Hero Member
*****
Offline Offline

Activity: 784


฿ → ∞


View Profile WWW
October 14, 2017, 03:25:54 PM
 #150

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.


all non self-referential signatures except mine are lame ... oh wait ...   ·  LBC Thread (News)  ·  BURST Activities
rico666
Hero Member
*****
Offline Offline

Activity: 784


฿ → ∞


View Profile WWW
October 16, 2017, 12:22:48 PM
 #151

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

all non self-referential signatures except mine are lame ... oh wait ...   ·  LBC Thread (News)  ·  BURST Activities
gizmoh
Legendary
*
Offline Offline

Activity: 1302



View Profile
October 18, 2017, 09:31:15 AM
 #152

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  Smiley

How Ripple Rips you: "The founders of Ripple Labs created 100 billion XRP at Ripple's inception. No more can be created according to the rules of the Ripple protocol. Of the 100 billion created, 20 billion XRP were retained by the creators, seeders, venture capital companies and other founders. The remaining 80 billion were given to Ripple Labs. Ripple Labs intends to distribute and sell 55 of that 80 billion XRP to users and strategic partners. Ripple Labs also had a giveaway of under 200 million XRP (0.002% of all XRP) via World Community Grid that was later discontinued.[29] Ripple Labs will retain the remaining 25 billion"
rico666
Hero Member
*****
Offline Offline

Activity: 784


฿ → ∞


View Profile WWW
October 18, 2017, 11:29:20 AM
 #153

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  Smiley

28% for GPU clients that were not GPU limited - to be precise.  Wink
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.

all non self-referential signatures except mine are lame ... oh wait ...   ·  LBC Thread (News)  ·  BURST Activities
arulbero
Hero Member
*****
Online Online

Activity: 760


View Profile
October 18, 2017, 05:07:38 PM
 #154

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.
rico666
Hero Member
*****
Offline Offline

Activity: 784


฿ → ∞


View Profile WWW
October 18, 2017, 05:26:47 PM
 #155

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.

all non self-referential signatures except mine are lame ... oh wait ...   ·  LBC Thread (News)  ·  BURST Activities
KeepingScore
Newbie
*
Offline Offline

Activity: 18

Any Coin. Numismatic. Bullion. Crypto.


View Profile WWW
October 19, 2017, 07:33:14 PM
 #156

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.

Any Coin. Numismatic. Bullion. Crypto.
CrytpSig
Newbie
*
Offline Offline

Activity: 5


View Profile
October 20, 2017, 03:35:12 AM
 #157

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
rico666
Hero Member
*****
Offline Offline

Activity: 784


฿ → ∞


View Profile WWW
October 21, 2017, 09:12:57 AM
 #158

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.

all non self-referential signatures except mine are lame ... oh wait ...   ·  LBC Thread (News)  ·  BURST Activities
CrytpSig
Newbie
*
Offline Offline

Activity: 5


View Profile
October 22, 2017, 09:54:50 PM
 #159

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.
Suzobo
Jr. Member
*
Offline Offline

Activity: 50


View Profile
October 23, 2017, 01:29:14 AM
 #160

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.  Cheesy Cheesy
rico666
Hero Member
*****
Offline Offline

Activity: 784


฿ → ∞


View Profile WWW
October 23, 2017, 08:15:05 AM
 #161

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: ¯\_(ツ)_/¯

all non self-referential signatures except mine are lame ... oh wait ...   ·  LBC Thread (News)  ·  BURST Activities
CrytpSig
Newbie
*
Offline Offline

Activity: 5


View Profile
October 23, 2017, 08:28:02 AM
 #162

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
kknd
Newbie
*
Offline Offline

Activity: 20


View Profile WWW
October 26, 2017, 10:36:47 PM
 #163

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               

www.kknd.com.br & www.forumbmwbrasil.com.br
dcw312
Newbie
*
Offline Offline

Activity: 12


View Profile
October 28, 2017, 05:06:38 PM
 #164

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.
rico666
Hero Member
*****
Offline Offline

Activity: 784


฿ → ∞


View Profile WWW
October 28, 2017, 07:28:54 PM
 #165

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.

all non self-referential signatures except mine are lame ... oh wait ...   ·  LBC Thread (News)  ·  BURST Activities
dcw312
Newbie
*
Offline Offline

Activity: 12


View Profile
October 29, 2017, 05:19:02 PM
 #166

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.
rico666
Hero Member
*****
Offline Offline

Activity: 784


฿ → ∞


View Profile WWW
October 30, 2017, 07:28:19 AM
 #167

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

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.


all non self-referential signatures except mine are lame ... oh wait ...   ·  LBC Thread (News)  ·  BURST Activities
arulbero
Hero Member
*****
Online Online

Activity: 760


View Profile
October 30, 2017, 03:10:43 PM
 #168

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.
Hereticalsauce
Newbie
*
Offline Offline

Activity: 4


View Profile
October 30, 2017, 11:21:11 PM
 #169

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.
gizmoh
Legendary
*
Offline Offline

Activity: 1302



View Profile
October 31, 2017, 05:29:37 AM
 #170

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.

How Ripple Rips you: "The founders of Ripple Labs created 100 billion XRP at Ripple's inception. No more can be created according to the rules of the Ripple protocol. Of the 100 billion created, 20 billion XRP were retained by the creators, seeders, venture capital companies and other founders. The remaining 80 billion were given to Ripple Labs. Ripple Labs intends to distribute and sell 55 of that 80 billion XRP to users and strategic partners. Ripple Labs also had a giveaway of under 200 million XRP (0.002% of all XRP) via World Community Grid that was later discontinued.[29] Ripple Labs will retain the remaining 25 billion"
rico666
Hero Member
*****
Offline Offline

Activity: 784


฿ → ∞


View Profile WWW
October 31, 2017, 06:28:11 AM
 #171

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.

all non self-referential signatures except mine are lame ... oh wait ...   ·  LBC Thread (News)  ·  BURST Activities
rico666
Hero Member
*****
Offline Offline

Activity: 784


฿ → ∞


View Profile WWW
October 31, 2017, 04:36:23 PM
 #172

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.

all non self-referential signatures except mine are lame ... oh wait ...   ·  LBC Thread (News)  ·  BURST Activities
Hereticalsauce
Newbie
*
Offline Offline

Activity: 4


View Profile
November 01, 2017, 05:21:21 AM
 #173

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.  Roll Eyes  
Might just as well buy a video card and run this locally; time to dust off the ol' 5970.
arulbero
Hero Member
*****
Online Online

Activity: 760


View Profile
November 01, 2017, 10:10:03 AM
 #174

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

*************************************************************************************************************************************************************************************************
dcw312
Newbie
*
Offline Offline

Activity: 12


View Profile
November 01, 2017, 06:42:12 PM
 #175

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.
arulbero
Hero Member
*****
Online Online

Activity: 760


View Profile
November 02, 2017, 09:39:47 AM
 #176

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".
dcw312
Newbie
*
Offline Offline

Activity: 12


View Profile
November 02, 2017, 10:29:15 PM
 #177

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
dcw312
Newbie
*
Offline Offline

Activity: 12


View Profile
November 03, 2017, 03:08:08 AM
 #178

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)
arulbero
Hero Member
*****
Online Online

Activity: 760


View Profile
November 06, 2017, 02:39:50 PM
 #179