Bitcoin Forum
November 19, 2017, 04:44:20 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 »  All
  Print  
Author Topic: Large Bitcoin Collider Thread 2.0  (Read 22152 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 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
Join ICO Now A blockchain platform for effective freelancing
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1511109860
Hero Member
*
Offline Offline

Posts: 1511109860

View Profile Personal Message (Offline)

Ignore
1511109860
Reply with quote  #2

1511109860
Report to moderator
1511109860
Hero Member
*
Offline Offline

Posts: 1511109860

View Profile Personal Message (Offline)

Ignore
1511109860
Reply with quote  #2

1511109860
Report to moderator
1511109860
Hero Member
*
Offline Offline

Posts: 1511109860

View Profile Personal Message (Offline)

Ignore
1511109860
Reply with quote  #2

1511109860
Report to moderator
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
*
Online Online

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
*
Online Online

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
Pages: « 1 [2] 3 4 5 6 7 8 9 10 11 »  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!