Bitcoin Forum
June 22, 2024, 02:04:42 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: [1]
1  Bitcoin / Project Development / LBC website issue on: November 11, 2017, 03:30:35 PM
Rico gave me a link to show the hooks documentation. It opened up a "secret manual" that I had never seen before!

Here is the problem with the website I am seeing. Steps to reproduce:
1. Click  https://lbc.cryptoguru.org/man/user#hooks
2. Verify that you see the hooks information
3. Click trophies from the left bar
4. Click Manual from the left bar

Expected behavior: The hooks documentation is visible
Actual behavior: The hooks documentation is not visible on the page

I am using Chrome on Mac.

Can anyone else verify the problem?
2  Bitcoin / Project Development / Re: Some News on: November 11, 2017, 05:25:10 AM
New client 1.192 (see News in my sig for changes);

I found the cause of the spam. I was using Amazon EC2 Container Service. With the service you configure how many containers you want running at a time. I think I had it set for 8 "desired tasks". The service will deploy 8 containers, execute their entrypoint file, when a container/task stops running, it will start a new one in its place.

I just ran the container locally by supplying "bash" as an override entrypoint.

Code:
Mac$ sh secret/run-local.sh
 
lbc@22be2fedf198:~$ cat entrypoint.sh
#!/usr/bin/env bash
./LBC --id $LBC_ID --secret $LBC_SECRET --cpus $LBC_CPU --loop $LBC_LOOP
./send-it.sh

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

At this point the container thinks it is done with it's task and stops. The service will replace it with a new container. This is also how Open Shift, Kubernetes, etc work.

So there was just a "groundhog day" (Bill Murray movie) scenario. A fresh container would be made from the image. It would get the update, but think it was finished.

I just reviewed the LBC -h help and see there already is a flag for update.
I think I fixed in: https://github.com/dcw312/lbc-client-docker/issues/7
The entrypoint is now like this:

Code:
./LBC --update
./LBC --id $LBC_ID --secret $LBC_SECRET --cpus $LBC_CPU --loop $LBC_LOOP
3  Bitcoin / Project Development / Re: Large Bitcoin Collider Thread 2.0 on: November 10, 2017, 01:09:11 AM
At 10:48 PM Thursday (UTC), Rico announced on Discord that we crossed into the 54 bit search space.
4  Bitcoin / Project Development / Re: Large Bitcoin Collider Thread 2.0 on: November 07, 2017, 03:20:44 PM
On Rico's advise just now, I added a hook-find file because I am running in the cloud.

https://github.com/dcw312/lbc-client-docker/commit/15874d4dc14fdb48e92b3288ff98bd9645172c26

Rico suggested:
Code:
#!/bin/bash
mail -s 'LBC FOUND' name@example.com < FOUND.txt

Mine sends to a queue that I would prefer not to share.
5  Bitcoin / Project Development / Re: Large Bitcoin Collider Thread 2.0 on: November 03, 2017, 03:08:08 AM
in the next days I will add a section called "Probability & LBC".

I was able to find this formula:
p(different) ~ e^(n^2 / -2 * T)
https://betterexplained.com/articles/understanding-the-birthday-paradox/

Which calculates the probability of avoiding a collision for a given search size (2^x) as:
Code:
search_range p_different
70 0.999999523163
72 0.999992370635
74 0.999877937138
76 0.998048781107
78 0.969233234476
79 0.882496902585
80 0.606530659713
81 0.135335283237
82 0.000335462627903
83 1.26641655491e-14
84 2.57220937264e-56

with the following python code
Code:
import numpy as np

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

search = range(70, 85, 2)
print 'search_range', 'p_different'
for x in search:
    print_different(x)
6  Bitcoin / Project Development / Re: Large Bitcoin Collider Thread 2.0 on: November 02, 2017, 10:29:15 PM
From the LBC website: In the rare event of a collision, the funds on the address in question would become accessible to the collision finder.

I was confused about this earlier but I found my point of confusion. I'll add here in the hope it saves others some time.

The public key is exposed when the sender (Alice) lists it as an input to a transaction. I thought that the public key could be compared to the previous transaction or another transaction. While there may be another transaction from Alice that identifies the full public key from her address, there is no verification that the same public key is being used for all transactions from her address. So if we find a key pair X2 that hash160(X1) == hash160(X2), the finder could transfer the money   .

Code:
Input:
Previous tx: f5d8ee39a430901c91a5917b9f2dc19d6d1a0e9cea205b009ca73dd04470b9a6
Index: 0
scriptSig: 304502206e21798a42fae0e854281abd38bacd1aeed3ee3738d9e1446618c4571d10
90db022100e2ac980643b0b82c0e88ffdfec6b64e3e6ba35e7ba5fdd7d5d6cc8d25c6b241501

Output:
Value: 5000000000
scriptPubKey: OP_DUP OP_HASH160 404371705fa9bd789a2fcd52d2c580b65d35549d
OP_EQUALVERIFY OP_CHECKSIG
https://en.bitcoin.it/wiki/Transaction#Principle_example_of_a_Bitcoin_transaction_with_1_input_and_1_output_only
7  Bitcoin / Project Development / Re: Large Bitcoin Collider Thread 2.0 on: November 01, 2017, 06:42:12 PM
I like where you are going with expanding the search space because it puts the focus on proving the likelihood of collision. I think this is the interesting question.

Looking at all used addresses seems the simplest way to expand the search space because those addresses are publicly available.

Has anyone seen a calculation on how many attempts it should take to have a high chance of finding a collision? (The binomial probably) I tried calculating it but the library I used wasn’t able to handle the large numbers.
8  Bitcoin / Project Development / Re: Large Bitcoin Collider Thread 2.0 on: October 29, 2017, 05:19:02 PM
The Remote Code Execution is there by design and not a vulnerability.
My apologies for implying that the RCE was a bug. I was using the word "vulnerability" to refer to the "state of being exposed to the possibility of being attacked" without judgement of it being a "bug" or a "feature". Your analogy to Javascript is a good one. Browsers provide an execution sandbox so to manage the risks of RCE. Users of LBC should, as you say, take appropriate steps to provide an appropriate sandbox.

To avoid repeating yourself further, you might consider having the client print a message on startup, like: "The LBC client contains a feature update itself. In the unlikely event that the LBC server were compromised by an attacker, the attacker would be able to execute arbitrary code on your machine as the user that executes LBC. Please execute LBC accordingly."  This is just a well intended suggestion.

Apologies again for any insult.
9  Bitcoin / Project Development / Re: Large Bitcoin Collider Thread 2.0 on: October 28, 2017, 05:06:38 PM
sudo ./LBC -x               

RUNNING LBC AS ROOT IS NOT REQUIRED OR A GOOD PRACTICE

The LBC app contains a remote code execution vulnerability. Rico assures us that he as taken many steps to avoid a malicious attacker from leveraging the vulnerability. But since root privilege is not required, there is no reason to run LBC as root.

For extra protection, you might consider running LBC inside a Docker container. I provide a base image (dcw312/lbc-base:latest) as well as code to create it and use it at:
https://github.com/dcw312/lbc-client-docker

p.s. Thanks for providing the nvidia libraries. My Docker image does not use that and some extra Docker foo is required to leverage the GPU.
10  Bitcoin / Project Development / Re: Large Bitcoin Collider Thread 2.0 on: October 13, 2017, 03:25:55 AM
GPU version of LBC usually works only on Linux, not on Windows. With your Dockerfile is it possibile to exploit GPU on Win?

A quick Google search indicates that Nvidia/Docker does not support Windows. For Linux, see this project here for Nvidia+Docker https://github.com/NVIDIA/nvidia-docker/tree/2.0
11  Bitcoin / Project Development / Re: Large Bitcoin Collider Thread 2.0 on: October 10, 2017, 01:46:30 AM
I have Ubuntu 17.04.  
Looking into the Perl script these are modules you need for sure:
Code:
JSON
LWP::UserAgent
Net::SSLeay
LWP::Protocol::https
Parallel::ForkManager
Term::ReadKey

Thank you! My Dockerfile now works: https://github.com/dcw312/lbc-client-docker
You need to manually add the funds_h160 file. I'll try to post instructions for that.
12  Bitcoin / Project Development / Re: Large Bitcoin Collider Thread 2.0 on: October 08, 2017, 10:02:43 PM
First of all, thank you for this project. Mostly because I suspected that bitcoin was vulnerable to key collision but when I shared these suspicions, I was told that the earth was more likely to explode than for that to happen. So your work will has done me the great service of seeming smarter than I am.

I tried yesterday to get the client running on my local machine yesterday. I tried using Docker to provide the safe sandbox discussed in the documentation.

I've put my Dockerfile on Github at https://github.com/dcw312/lbc-client-docker

I'm new to Arch Linux and Perl so I don't expect to make significant contributions.

As an aside, I'm a little surprised that the dependency management of Perl seems to be such a challenge. In my work yesterday, I'd keep seeing messages like "LWP::UserAgent not found - installing it." I'm most recently using Java and Maven so I expected the dependency management to be a bit more straightforward.

Would someone be willing to reply with the list of Arch Linux packages that are installed on the VM image?  I ask so I can add them to the Dockerfile.

This can be done with:
Code:
pacman -Q

Please also supply installed cpan modules:
Code:
cpan -l
Or one of the other methods described here: https://stackoverflow.com/questions/115425/how-do-i-get-a-list-of-installed-cpan-modules#

Also, if something special was required to install cpan, please let me know so I can close this https://github.com/dcw312/lbc-client-docker/issues

Thanks!!  

p.s. My motivation is mostly to continue to see how Docker can be used for sandboxed work like this.
Pages: [1]
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!