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

I'm working on a table to account for everything we know so far from the SlarkBoy Bounty Galore: https://bitcointalk.org/index.php?topic=1877935.msg18672178#msg18672178

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.

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-


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.

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.

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


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

 ::) self-moderation seems to get unchecked after session timeout - sorry

Ich würde das mit dem Linux Subsystem unter WIndows gerne selbst probieren, muss mich aber hierfür als totaler Windows-DAU outen.

Was ich weiß/glaube zu wissen:

Für Windows 10 gibt es aktuell ein sog. "Creators Update" und das beinhaltet wohl auch die Möglichkeit ein "Linux Subsystem" zu installieren.
Das ist wohl auf Basis von Ubuntu(?) und wird auch nicht automatisch installiert, sondern man muss irgendwo klickibunti und dann erst...?

=> Bitte um Kurzanweisung, wie ich also unter meinem Windows 10 zu einer bash komme, von da aus sehe ich schon mal weiter


Was ich nicht weiß:

Wie die Linux-Integration unter Windows realisiert ist - VM, Paravirtualisierung, API Emulation, ... ?
Das will ich nach o.g. Anleitung und Experiment herausfinden.

Ob eine GPU unter dieser Linux Umgebung unter Windows funktioniert weiß ich nicht, wage es aber erst einmal zu bezweifeln, bzw. würde die Hoffnungen erstmal nicht zu hoch ansetzen. Im "schlimmsten Fall", könnte man sich die LBC Appliance und den Download von VMplayer und 1.6GB Arch Geknödel für den CPU client sparen - das wäre immerhin etwas.


Rico

any update on the newest finds? I see some already claimed. Unknown - was it you?

Rico

The RCE can potentially run with whatever permissions the LBC client runs. Break out of VM is to the best of my knowledge out of question, same applies to a In-Container operation.

We will never look at any file outside the LBC set (LBC client, generator, BLF, OpenCL payload, bench.pst, maybe hooks but ATM I do not see any use case) or perform any operation outside the scope of LBC client operation (and I'm willing to have the scope publicly and formally defined in the mini EULA).

Luckily this is on Linux, so even without VM and container or "taking our word for it"(tm) one should be able to set up ACLs for the mentioned set of LBC files.
Or - if this is still not good enough, run on a dedicated machine (bare installation + LBC).

The server reserves the right to peek at these files and these files only. We honestly don't give a damn about your porn collection in the directory next to the LBC or material that proofs who shot JFK. The server furthermore reserves the right to incapacitate any or all of these files if these have been altered.
FS traversing is taboo - if there are preferred methods how to ensure this by access configuration, I'll be happy to add them to the admin/user docs.



Rico

Ryan,

the correct answer would have been: "Yeah - there are double standards".


Rico

https://lbc.cryptoguru.org/static/

Testing new version with host name verification against this https repo.


edit: I also removed all direct links to LBC client download from the webpages and replaced them with links to the download page with its shiny warning.



Also in the News (or not):

https://www.debian.org/mirror/list   <= 0 SSL mirrors
https://wiki.archlinux.org/index.php/Mirrors  <= 4 SSL mirrors
http://mirrors.opensuse.org/  <= 0 SSL mirrors

etc.   But hey - why not?


Rico

Egal! um Himmels Willen nicht sorry sein. Das war gut und richtig so. Und ehrlich gesagt - heute sieht der Tag auch anders aus als gestern - auch der Shitstorm ist gut so. Wird man wenigstens sensibilisiert, dass die ganze Geschichte nicht mehr ein "halabala machen wir mal Software" ist.

Ok - so lapidar habe ich das bislang eh nicht gesehen, aber an einige Sachen habe ich weniger Gedanken "verschwendet". Security ist mir zwar wichtig - aber bislang war halt Speed wichtiger. Ok, sehe ich mir momentan wieder mehr Security an.

Habe heute als Erste Maßnahme eine dicke fette Warnung auf die Download-Seite gepappt, bin mal gespannt ob nun der Formulierungs-Krieg beginnt   ... naja.


Danke, weiß ich wenigstens, dass ich nicht unter Halluzinationen leide bzw. mir die Sache aus den Fingern sauge.


Unknownhostname - ich kenne den Kerl nicht, er kennt mich nicht - hat mir den SSH key für seine Server geschickt (inkl. Rootzugang) mit den Worten "mach mal" (installieren, testen). Bis ich abgewunken habe und meinte er soll das selbst machen ich habe besseres zu tun.  

__KULME__ - ich kenne den kerl nicht, er kennt mich nicht, Schickt mir mal eben 30 privkeys für die Bounties (>300$) weil "er die nächsten Tage zu tun hat und ich soll das beaufsichtigen".

Leute sind der irrigen Auffassung, ihre ach-so-wertvollen Clients wären für mich von Interesse. Es ist genau andersherum: Für mich ist von Interesse, dass die Clients problemlos funktionieren und keinen Mist auf dem Server veranstalten.




Rico

1st measure: https://lbc.cryptoguru.org/download

Wording to not lure poor users into a trap. I'm sure there will be numerous comments on the wording, so we may finally end up with a 17-pages EULA like Apple has (or was it 53-pages? I never read it), but at least as of now it does not require you to send in a sperm sample (eeek) in order to run the software. We may change that and reserve the right to monetize that sample. (*)

LBC and generator binary download will be moved to the LBC https server, the BLF, Texts and Appliance will remain on FTP.
host name verification and potential shell injection will be addressed in the next release.

Remote code execution from LBC server will not be addressed in the next release. If you do not like it: DO NOT RUN THE SOFTWARE.

Seriously.

Rico


(*) That is, of course, until people start accusing us of being sexist and barring women from using the software.

I am really trying hard to figure out what this has to do with LBC project development, but I fail.
Instead you are performing some bizarre ego-wank show having hijacked the thread long ago,
burying what might have been left as useful information for users under piles of crap.

Moderator is asleep or cannot be bothered, or too much work - I don't blame him. Janitoring these amounts
of (liquid) manure in all possible threads is beyond non-automated capacities.

I do kind of consider this thread "lost" and am seriously thinking about opening a shiny pretty clean new one
and self-moderated.

And yes, I would kick out these kind of "contributions". If someone would call that censorship - so be it.



Rico

No - that makes the situation actually funny. So kind of thanks for the laugh.
And you are a pitiful individual - I do not even feel the urge to close this thread as I have when it was WAY LESS polluted than with your crap.

You shit-flinging chimp really are bad at retrieving information from the internet. You are also bad at quoting, your choice of color and size is unaesthetic, all in all you appear as some inferiority complex ridden poor soul. You should seek professional help.

Why is it I read all over the place you are a scammer? Are you? Do you try to cover something up by shit-flinging on others?

https://bitcointalk.org/index.php?topic=1012713.0



You might want to stop thinking with it and use your head instead... oh right you can't do that.

edit: Now I read you were a former employee of BFL. Hm. Must have been pretty pressing idea in your "head".


Rico

Oh now I get it. You had involuntary buttseks from BFL and now you are butthurt for all eternity (must have been quite a schlong) so you need to carry your Lugan ass around and show your butthurt all over the place?

Whatever makes you comfy man...

(hint: Rico may be a Suffix)

Rico

  I agree. Oh god - please try to contact these people "Carpenter my ass"



I am not.

edit: No really. I mean it. I feel sorry for them, but it cannot be my fault if some Gleb Gamov Lugano sorry ass whatever feels he is investigator extraordinaire and "works" like this. With all sorts of color and size.
Good news for all projects Gleb Gamowski called SCAM. You can relieve now: He's just a sorry idiot who cannot use "the internet"(tm).


Rico

So. Rootkit Shitstorm Kurzfassung: fronti ist schuld. Ende der Kurzfassung.

 

War nur Spaß - wenn es irgendwo Verantwortung gibt, dann trage ich die natürlich, aber so als Hintergrundinfo nur hier, weil ich mich jetzt lange genug in englischen Mails gebadet habe:

Irgendwann um den 19/20. Oktober 2016 herum hat fronti ein paar Penetrationstests mit dem LBC durchgeführt. Das auch vorher angekündigt, sogar nach einem development Server gefragt um den Produktivserver nicht zu zerschiessen, aber mutig wie ich bin, habe ich ihn auf dem Produktionsserver machen lassen und die Sache beobachtet.

Die PMs aus der Zeit habe ich noch, Fronti vielleicht auch.

Er ging von dem was ich auf dem Server sehen konnte recht strukturiert vor, hat den perl code analysiert, die quine entdeckt (eine Art checksum der Quelltextes) und hat eben versucht dem Server ungültige Blöcke als gültige unterzuschieben. So in etwa.

Gut, die clients von ihm sind damals in der Blacklist (IPs, Ids) gelandet, aber das konnte man ja mit Tor umgehen etc. etc.

Jedenfalls konnte LBC damals die Angriffe abwehren, aber es war klar, dass es eigentlich nur eine Frage des Aufwands (und somit der Zeit) war, bis jemand - egal welche Barrieren ihm der Client in den Weg stellte - diese prinzipiell umgehen konnte.

Es ist ähnlich wie mit dem Kopierschutz: Jede standalone Software kann prinzipiell geknackt werden. Also habe ich noch eine 3. Verteidigungslinie eingebaut: quine-check vom Server durchgeführt. Das macht man in Perl mit einem eval und das ist prinzipiell eine remote-code-execution. Da gibt es auch nichts was man auf dem client hacken könnte, denn der Code ist ja nicht da. Da flippen nun einige (muss man auch nüchtern sehen, dass es da nur einige Alarmisten gibt) aus.

Der Client kann sich vollständig selbst auto-updaten (= den kompletten Code auswechseln mit meinetwegen 100 "evals")

=> stört keinen 

Hat mich gestört, also habe ich ohne Diskussion, ohne Druck ein "no_update" für die Paranoiden eingebaut.

Suma sumarum:

Ganz klar, wer Bedenken hat, soll die Software nicht einsetzen. Ansonsten Container, VM (siehe hier: https://lbc.cryptoguru.org/man/admin#security) oder dedizierte Hardware. Wer trotzdem Bedenken hat: siehe vor-vorherigen Satz.
Gerade LBC benötigt eben zu seiner Funktion keine Wallet oder Blockchain oder sonstige BTC (oder jedwede andere Coin) Infrastruktur auf der Maschine...

---

Im Laufe der Diskussion sind dankenswerter Weise auch einige m.E. valide Punkte aufgetaucht (update sollte via HTTPS statt FTP erfolgen, HTTPS host name Verifikation sollte an sein, Shell execution mit Parametern sollte geschützt sein). Ja, das baue ich natürlich ein, bzw. ändere das.


Gestern habe ich noch geschaut, wie News über den LBC auf Vietnamesischen und chinesischen Seiten aufgetaucht sind, klar dass sich damit 100x mehr Leute beschäftigt haben als bisher. Ich bin durchaus für konstruktive Kritik was die Sicherheit des LBC anbelangt - mit irgendwas um die 200 clients wird das ja auch zu einer waschechten Verantwortung, aber heute ist mir der Begriff "skandalisierende Aufmerksamkeitshure" mehr als einmal in den Sinn gekommen.

Also so in etwa. Ich spiele momentan mail Ping-Pong mit ca. 100 Leuten, darunter auch einige Autoren, die neulich erst Artikel über den LBC geschrieben haben und jetzt wissen wollen was Sache ist. Wenn Fragen sind, antworte ich gerne, wenn's länger dauert: nicht weil ich mich drücke, sondern weil ich nur eine Tastatur habe.


Rico

I believe, it's way better not to use savagely bad software containing bullshit at all. Why going through the loops of trying to fix it?

At the moment I am changing some issues that were addressed and which I consider valid (host verification, FTP -> HTTPS, qx -> open, etc.), I'm not changing core features that are there for a reason. If you have a problem with that, don't use the software.

https://lbc.cryptoguru.org/man/admin#security


If you have concerns running it "on iron" i.e. not in a VM because you run the GPU client, use a dedicated machine. If all of this is not an alternative for you, don't use the software.

If you then still are afraid, LBC could some day mutate on that dedicated machine into some mail-spam sending or DDoS-Zombie machine... my condolences. And then of course don't use the software!



Rico