Moores law would relate there ? so a growth of 100% every two years or average 1.5^34 which would be 970739.737366476
Is the GTX 1080 now nearly a million times faster then your ZX spectrum ? if so maybe you can speculate on the future potential.
Yes, Moore gives a pretty good estimate. A modern i7 is about 400 000 times faster than the Z80 in the good old Speccy, a 1080 adds a factor of 30 on top of that. So the 1080 is about 12 million times faster. Which means that everything I could possibly have computed with the ZX Spectrum in the past 34 years, the 1080 would finish in 89 seconds. It seems this pool will soon check more keys daily than it has checked for its whole life time so far (40 days). Soon. Mark my words. Rico |
|
|
|
The bounty has been claimed.  Let's hope by its "true owner".  Rico |
|
|
|
denkst du auch das ganze wäre mit einem Miner möglich? Du kannst dich ja mal nach erfahrenen Programmierern hier umschauen, vielleicht findest du jemanden der dir bei dem ganzen Thema helfen könnte.  Nein, die derzeitigen SHA256 Miner sind zu spezialisiert und nicht für diese Aufgabe geeignet. Aber ja, theoretisch könnte man auch hier FPGAs - und später ASICs machen, die noch wesentlich schneller und energieeffizienter als GPUs wären. Im Grunde genommen die gleiche Evolution wie sie beim Mining stattgefunden hat. Massiv parallele ASICs, die eben PK -> EC -> SHA256 -> RIPEMD160 machen und die Ergebnisse dann gegen einen Bloom Filter abgleichen. Ich kann ja mal bei KnC nachfragen. Rico |
|
|
|
Why do you think it's an HD wallet? The first output was sent to an address with a private key of 0x01. That would never be generated by an HD wallet.
Yes, I'm probably wrong. The remainder after the nth bit doesn't seem that deterministic. After some more thought I believe it is either a witty joke or an "early warning system" exactly against this kind of incremental brute force search we (and as it seems others) do. Speaking of which: Our pool bounty has been found hours ago, but still not claimed. https://blockchain.info/address/1pdSSfCx4QynTwXTtVDjEEavZ4dDnYdhPI wonder what the operator of 540bbf4beaaa58ca981d0917da0c3a82 who got and delivered the block containing the PK of the bounty address is doing??? Either he's asleep and letting his comp cracking keys, or he got an heart attack when he saw the FOUND message, or ... don't know. But evidently there seems not to be some omnipotent clandestine cracker running around in the lower 50bits PK search space, else the bounty would have been gone by now. So lesson learned: Watch your LBC directory for a FOUND.txt file people! Rico |
|
|
|
Trying this on a windows machine now seems to be running fine but only works if you call the perl before the lbc program variables.
Yes. I'm new to this but assume it's working however like you said windows forces only one core at a time. Does this mean we should open more command line windows to get more cores used?
Yes. Actually there is a nice twist to this. Operators of Windows clients could use the following start-up script (taken from https://bitcointalk.org/index.php?topic=1581701.msg16290488#msg16290488): @echo off
cd %userprofile%\Desktop\LBC-client
start perl LBC -c 1 -t 3600
start perl LBC -c 1 -t 1100
start perl LBC -c 1 -t 600
start perl LBC -c 1 -t 60
This starts 4 LBC instances, each using just 1 core, but each claiming a different-sized chunk of work. Remember when I wrote about the "small holes" that are inaccesible to fat clients? With this, your client does scavenge a very broad range of available intervals. Big ones, but also small leftovers no one had a look at so far. The -t 60 is of course not as efficient as the efficiency (less overhead) is better the longer it works, so you could issue that -t 60 only from time to time. Also how can I be sure it's pulling new blocks and not ones previously collided?
Pretty sure, as I have explained above to quite some extent. The server is juggling with intervals done/not done/issued/pending and I dare to say that is working with mathematical precision. There is lots of work to do, we cannot afford to do it over and over again (if it's not necessary). There are circumstances, when work is being done twice, but in these (rare) cases it's unavoidable. In general, your client boldly goes where no client has gone before. Lastly is there a way we can use our gpu for this instead of cpu?
Not yet. https://bitcointalk.org/index.php?topic=25804.msg16267353#msg16267353https://forums.khronos.org/showthread.php/13206-Need-OpenCL-program-(oclvanitygen)-modification... Maybe someone with the skills finally wants to earn some BTC doing this. Rico PS: Congrats to operator of 540bbf4beaaa58ca981d0917da0c3a82! You should have found the bounty. Please do claim it, so I know everything is working as it should. |
|
|
|
I feel the need to explain what happened yesterday in greater detail and also what I have done to make sure something like that doesn't happen again. Also, give you some insight in the pools work distribution operation. First I would like to describe the fun - almost dramatic - situation that led to the discovery of the bug. The bounty ( https://blockchain.info/address/1pdSSfCx4QynTwXTtVDjEEavZ4dDnYdhP) was in a block that was about to be issued "any moment now". "client X" finally asked the server for work which contained the block. You must know, that the whole client<->server interaction is a game of promise and deliver. When a client asks for work, he gives nothing but a promise to work on the assigned block(s). The server knows when this work was issued and the server also knows about the clients computation speed. Therefore the server knows when the delivery of the promised work is due. The server waits for 200% of this time, because the client may have a higher load and not be able to utilize its capacity 100% to check blocks. The user might have halted the process (under Linux Ctrl+Z) for some time to start it later on. There may be some network lag etc. etc. If after more than double of the promised time, the client does not return a POW of the checked block (client-id, interval), the server considers that interval not having been checked and will reissue it to the next client who asks for work (which actually may be the same client-id). In the meantime however, the server will not issue blocks from the promised interval to other clients to avoid double work.However, "client X" did not deliver the interval back in time, so its interval was open to reissue. Meanwhile, other clients asked for work and delivered it back, so basically the interval for reissue is a "hole" in the work done. Have a look at this JSON representation: [["0",653587],[653708,654825],[654848,657098],[657111,657122],[657135,660588],[660608,672324],[672392,674026],[674055,674193],[674222,676045],[677393,677444],[677775,678894],[69545491,69545512],.....
The "holes" are the intervals between the intervals. Like 653588-653707, then 654826-654847 etc. This happens all the time, is a natural process and expected. Clients promise and do not/cannot deliver, so work is done later. Naturally the holes have different sizes, depending on the computational strength of the client who promised and did not deliver. Now if a slow client promised and did not deliver, the resulting "hole" is small. Which actually means, that it becomes inaccessible for "fat" clients who ask for (promise to do) bigger chunks of work. These get new work at the current "forefront" of the pool. Nevertheless, a new (another) "client Y" came along and asked for work within the hole in the intervals that contained the bounty. And guess what? He didn't deliver also. Meanwhile the hole/interval containing the bounty was even smaller (like 3 blocks). That's when I was reminded of the pulp fiction scene of missed shots. FINALLY, a "client Z" came along, claimed the blocks and ... delivered. AND ... nothing happened! I thought WTF? I gave my notebook (Linux) the specific block number and .. HIT. WTF? WTF? I went to my Windows machine, gave it the specific block number and ... NOTHING! In this very moment there was a rapid change of operation of my sweat glands. Potentially, every win-client was not getting hits despite them being there. Every second of operation added to wasted work. And this at a time when we finally had stable win clients and the pool evidently got more and more clients. For a second, I thought "Maybe I can fix it without telling anyone and embarrassing myself?" Nope. I had to stop the pool operation to prevent issuing of work which would have been moot anyway. I stopped the pool, put out a quick message here and started a frantic bug hunt. I compared the output of the Linux and Win versions of the generators byte-by-byte. Same. Of course - I did that test before. I issued a "LBC -x" on Linux: correct 3 hits. I issued "LBC -x" on Windows: bummer! 2 hits  It's not "not working" - it's somehow a little bit not working? WTF 2? Ok. I hacked some debug information into LBC and let it print out what the LBC client "thinks" it sees coming from the generator right before the hash160 check. And there it was: Some 50000 bytes down the stream, the Linux and Win versions started to differ. What was going on? I pinned down the exact location of the 1st change and there I saw it: Linux "0a0a6f" Windows "0a0a0d6f". Naturally, all subsequent hash160 checks for the current block in the Windows version were 1 byte off and could not match. CRLF anyone? The windows client considered the stream from the generator to be a text stream. Which at the time when it was a text stream (base58) was perfectly ok. But since the client 0.823 when the stream became binary, this was not ok. Oh this was so badly not ok. For Linux, it didn't matter, as the default mode of operation on incoming pipes is ":raw" don't change anything. But on Windows, the default mode of operation on incoming pipes is ":crlf" - yeah munge the data by default. And the problem is - of course known and documented http://perldoc.perl.org/functions/binmode.htmlOn some systems (in general, DOS- and Windows-based systems) binmode is necessary when you're not working with a text file. For the sake of portability it is a good idea always to use it when appropriate, and never to use it when it isn't appropriate. So the fix was a binmode ":raw" on the pipe filehandle. Then LBC -x on windows had it's 3 hits. Then the windows client showed a hit when processing the specific block containing the bounty. I put in some information here, had the pool server accept only clients 0.831 or higher (unfortunately it cannot do that separately on OS versions, so Linux clients had to update too although for them it was not necessary - collateral damage) put the new versions for download, rolled back the "forefront" of the pool and started up the pool. Phew! There were of course some more details done. When checking the Windows client via LBC -x, I realized, that there was no way, a user could determine if the check ran successful if there were only some hits. So now the check checks itself and will bail out if there are not exactly 3 hits. The windows client refuses now to be called with anything else than -c 1, respectively sets the number of CPUs always to 1. Unfortunately there is a small annoying message even if you set -c 1, but it's not breaking anything. ---- All in all, I certainly hope this was the last incident of this type and hopefully the dust will settle now and everything will run smooth. Good hunting everyone! Rico |
|
|
|
I have another suggestion:
Is it possible to update the LBC with out having to download everything all over again?
If possible, an "upgrade" link that just provides the necessary binaries to update.
This will save on download time and HD space.
Same request was in the german thread, https://bitcointalk.org/index.php?topic=1581701.msg16291208#msg16291208In this case, download of http://62.146.128.45/download/LBC-client/LBCis sufficient and it's a meagre 17kB. Just replace the old LBC with it. I was thinking about some autoupdate/incremental update but hadn't yet the time to implement that. Rico |
|
|
|
Bei mir läuft Version 0.827 auf Windows wesentlich besser als die älteren Versionen. Ich habe mir zum starten einfach folgendes Batch-Script erstellt: @echo off
cd %userprofile%\Desktop\LBC-client
start perl LBC -c 1 -t 1
start perl LBC -c 1 -t 1
start perl LBC -c 1 -t 1
start perl LBC -c 1 -t 1 Nice. Mittlerweile gibt es jedoch version 0.832 und die verlangt der Server auch. Leider leider war die Windows-version zwar stabil, hat aber nicht alle hash160 gefunden die sie sollte... Lange Geschichte, könnte man nun breittreten wer der größere Idiot ist - ob ich oder Windows. Belassen wir es dabei, dass jetzt der Windows client tatsächlich belastbar ist. Zu dem obigen Skript habe ich folgenden Verbesserungsvorschlag. Der Client ist nun wirklich stabil und mit -c 1 sind schon etliche Win clients mehr als 48h durchgelaufen. -t 1 ist daher überflüssig. Ich würde es mit folgenden Zeiten probieren: @echo off
cd %userprofile%\Desktop\LBC-client
start perl LBC -c 1 -t 3600
start perl LBC -c 1 -t 1100
start perl LBC -c 1 -t 600
start perl LBC -c 1 -t 60
Ist ein kleiner Geheimtipp, weil dann finden einige der Windows Clients "Löcher" in den Intervallen, die einem fetten -c 20 -t 3600 linux client entgehen... Rico |
|
|
|
The price of Bitcoin will not budge because of this project. Even if >100BTC was found, nobody is going to worry about this I think the developer here is just having a bit of fun and giving anyone who wants to join in a chance of finding a small bounty. Projects like this have existed since BTC was born. If you have nothing constructive to contribute and all you post is pure negativity and FUD, then I am sure you can find another thread/forum that you can vent in. We get it, you disapprove. Now move on and stop being a nuisance (no offense intended).
While I do have fun with this project (at least when all runs well), I take it seriously and it's not just meant as some weird kind of faucet. I think I know statistics pretty well. I also think I know the speed of my ZX Spectrum (1982) and of my GTX 1080 (2016). That's 34 years and the speedup is ... homework for everyone interested. Let's see if this pool, or bitcoin or we all are here in 34 years before we speak of the "age of the universe". Rico |
|
|
|
Pool halted for emergency fix. Sorry for the inconvenience. More info soon.Sun Sep 18 19:17:59 CEST 2016Shitty bug in Windows client which caused it not to find all matches. I found out after client got a block containing the bounty, delivered it back and no bounty was claimed. In the binary stream, Windows replaced some "0a" with "0a0d" - or whatever. So yeah, it's official: I'm an idiot for relying on UNIX default behavior. Now that stream is set unconditionally to ":raw". => Bug found and fixed, new versions in the making. Pool will demand at least version 0.831 which you will find for download shortly. Sun Sep 18 19:36:55 CEST 2016Packages are available for download. Would the operator of client 06be1b85e82e538529d23390c6fd06c5 contact me via PM: I will give you the bounty out-of-band, because you would have found it Please everyone do a LBC -x first. This should simulate 3 hits under various conditions. Only then you can be 100% sure you will find everything. (needs to be done only once) Sun Sep 18 19:48:53 CEST 2016Had to roll back 25000 blocks. We all know how small the chance is that they contained something an old buggy windows client overlook, but just to be sure. 1 day of work lost.  Rico |
|
|
|
And - BTW - we seem to have quite some new clients, the pool capacity is rising Which means, the bounty will be found definitely today - probably within the next 6-8 ~2 hours like now. edit: Thriller! Some client already claimed the block containing the bounty, but did not deliver it back, so the server will reissue it again... edit2: Unbelievable. Do you know that scene from pulp fiction? https://youtu.be/Vr6aIURrFvE?t=77I am being reminded of that. Congrats to client 273870c7c71bfe2e82e2a537580e63cf you threw away the 2nd chance the pool gave you. So pool is reissuing again. Hey! We have time. Rico |
|
|
|
Is that threads or actual physical cpu. Theres cpu with 44 threads or 22 cores now and quite a few old server chips with about half that so maybe thats a useful source of power. Not sure its all minor compared to gpu parallel processing power though I couldnt even crack a secure rar password nevermind something as involved as this
On windows, it's threads, but you should - on windows - assign each thread it's own CPU. So on aforementioned server, for max performance, start around 20 times perl LBC -c 1 AND use http://62.146.128.45//download/LBC-0.827_w64.zipas this is a Windows version without the aforementioned instability. Several clients with this version ran for over 48h now. Or wait a couple of hours, as I will put a more polished windows 0.830 (or so) in the download section today. Rico |
|
|
|
Congrats, that's an HD wallet you hit. Rico |
|
|
|
I've added a new stat to http://lbc.cryptoguru.org:5000/statsThe effective search space until something (except bounties) is found is 136.75 bits. Given current search speed, the probability to find an address with funds on it within the next 24h is 0.0000000000000000004524764939984744324231018884855317923702%. 2 hours later... The effective search space until something (except bounties) is found is 136.75 bits. Given current search speed, the probability to find an address with funds on it within the next 24h is 0.0000000000000000004556237169019694490259313869322519435127%. Now you may think that number is ridiculously small. For me, it is surprisingly high. First off, before the project started, it was 0, but let's assume it was 0.0000000000000000000000000000000000000000000000000000000001%. Then today, when I started this stats computation, the probability of a collision within the next 24h is 4524764939984744324231018884855317923702 times bigger than when the project started. You still may think the number is small. Even if nothing happens and the pool remains at its current capacity, this number will grow. Because that's actually the effect you can observe in the "2 hours later" probability. If the address generation capacity of the pool rises (better clients x more clients), this number will start to exhibit geometric growth. Rico |
|
|
|
So you just have to find somebody who can modificate your client or the oclvanitygen... Am I right? Just the oclvanitygen. The Go-generator is probably already 90% of what can be done with it (I guess). "My client" is the Perl stuff that holds all this together and there are no (not yet) time critical pieces of code in there. Very probably the hash check (hash/map/asociative array of funds) would also have to be moved in the GPU as the CPU wouldn't catch up checking the generated hash160s. Maybe similar to brainflayer with bloom filters, and only in case of a hit, the CPU would check it. If the rate of false positives would be low enough, the CPU should have no problems catching up. From what I read in the vanitygen/oclvanitygen docs, it seems the code is already 99% there, maybe even 99,5% as it does the checking and also does sequential PK increments for speed. I would only need a means to be able to steer the offset where these sequential PK increments start from. Rico |
|
|
|
ldd doesn't indicate libreadline or libhistory is linked: # ldd /usr/bin/bitcoin-qt
linux-vdso.so.1 (0x00007ffea858d000)
libunivalue.so.0 => /usr/lib64/libunivalue.so.0 (0x00007f54822ec000)
libleveldb.so.1 => /usr/lib64/libleveldb.so.1 (0x00007f548208e000)
libmemenv.so.1 => /usr/lib64/libmemenv.so.1 (0x00007f5481e86000)
libboost_system.so.1.61.0 => /usr/lib64/libboost_system.so.1.61.0 (0x00007f5481c82000)
libboost_filesystem.so.1.61.0 => /usr/lib64/libboost_filesystem.so.1.61.0 (0x00007f5481a68000)
libboost_program_options.so.1.61.0 => /usr/lib64/libboost_program_options.so.1.61.0 (0x00007f54817e7000)
libboost_thread.so.1.61.0 => /usr/lib64/libboost_thread.so.1.61.0 (0x00007f54815be000)
libboost_chrono.so.1.61.0 => /usr/lib64/libboost_chrono.so.1.61.0 (0x00007f54813b6000)
libQtGui.so.4 => /usr/lib64/qt4/libQtGui.so.4 (0x00007f548083d000)
libQtNetwork.so.4 => /usr/lib64/qt4/libQtNetwork.so.4 (0x00007f5480530000)
libQtDBus.so.4 => /usr/lib64/qt4/libQtDBus.so.4 (0x00007f54802c9000)
libQtCore.so.4 => /usr/lib64/qt4/libQtCore.so.4 (0x00007f547fdb2000)
libqrencode.so.3 => /usr/lib64/libqrencode.so.3 (0x00007f547fba6000)
libprotobuf.so.10 => /usr/lib64/libprotobuf.so.10 (0x00007f547f72d000)
libdb_cxx-4.8.so => /usr/lib64/libdb_cxx-4.8.so (0x00007f547f38b000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f547f16f000)
libcrypto.so.1.0.0 => /usr/lib64/libcrypto.so.1.0.0 (0x00007f547ed98000)
libsecp256k1.so.0 => /usr/lib64/libsecp256k1.so.0 (0x00007f547eb72000)
libanl.so.1 => /lib64/libanl.so.1 (0x00007f547e96e000)
libstdc++.so.6 => /usr/lib/gcc/x86_64-pc-linux-gnu/5.4.0/libstdc++.so.6 (0x00007f547e5ec000)
libm.so.6 => /lib64/libm.so.6 (0x00007f547e2e9000)
libgcc_s.so.1 => /usr/lib/gcc/x86_64-pc-linux-gnu/5.4.0/libgcc_s.so.1 (0x00007f547e0d2000)
libc.so.6 => /lib64/libc.so.6 (0x00007f547dd39000)
librt.so.1 => /lib64/librt.so.1 (0x00007f547db31000)
libglib-2.0.so.0 => /usr/lib64/libglib-2.0.so.0 (0x00007f547d820000)
libpng16.so.16 => /usr/lib64/libpng16.so.16 (0x00007f547d5ed000)
libz.so.1 => /lib64/libz.so.1 (0x00007f547d3d7000)
libfreetype.so.6 => /usr/lib64/libfreetype.so.6 (0x00007f547d128000)
libSM.so.6 => /usr/lib64/libSM.so.6 (0x00007f547cf1f000)
libICE.so.6 => /usr/lib64/libICE.so.6 (0x00007f547cd02000)
libXi.so.6 => /usr/lib64/libXi.so.6 (0x00007f547caf2000)
libXrender.so.1 => /usr/lib64/libXrender.so.1 (0x00007f547c8e8000)
libXrandr.so.2 => /usr/lib64/libXrandr.so.2 (0x00007f547c6dd000)
libXfixes.so.3 => /usr/lib64/libXfixes.so.3 (0x00007f547c4d7000)
libXcursor.so.1 => /usr/lib64/libXcursor.so.1 (0x00007f547c2cc000)
libfontconfig.so.1 => /usr/lib64/libfontconfig.so.1 (0x00007f547c088000)
libXext.so.6 => /usr/lib64/libXext.so.6 (0x00007f547be75000)
libX11.so.6 => /usr/lib64/libX11.so.6 (0x00007f547bb36000)
libssl.so.1.0.0 => /usr/lib64/libssl.so.1.0.0 (0x00007f547b8ca000)
libQtXml.so.4 => /usr/lib64/qt4/libQtXml.so.4 (0x00007f547b68e000)
libdbus-1.so.3 => /usr/lib64/libdbus-1.so.3 (0x00007f547b447000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f547b243000)
/lib64/ld-linux-x86-64.so.2 (0x00007f54824fe000)
libpcre.so.1 => /lib64/libpcre.so.1 (0x00007f547afff000)
libbz2.so.1 => /lib64/libbz2.so.1 (0x00007f547adef000)
libbsd.so.0 => /usr/lib64/libbsd.so.0 (0x00007f547abd8000)
libexpat.so.1 => /usr/lib64/libexpat.so.1 (0x00007f547a9ae000)
libxcb.so.1 => /usr/lib64/libxcb.so.1 (0x00007f547a785000)
libXau.so.6 => /usr/lib64/libXau.so.6 (0x00007f547a581000)
libXdmcp.so.6 => /usr/lib64/libXdmcp.so.6 (0x00007f547a37b000)
The only other "anomaly" of my bitcoin-qt I am aware of, is that I start it on my server with remote display to my notebook (X Server Protocol). It should be completely transparent, but not sure if that could do something. Naturally I would want this mystery to be solved, but I am quite reluctant to put my bitcoin-qt binary somewhere to download for inspection, as I do not know what could be stored in it. Rico |
|
|
|
I'm not a programmer, nore do I profess to understanding what modifications are being asked, so with that in mind I'm wondering: How will this benefit us? Will we all be able to use this modified program?
I have no plans to withhold the resulting code from the community. (Although then I'd expect the modifications to be done "cheaper". Basically it's for the collision project and promises speedups of thoretically a factor of 100 - 150. So everything you see done at http://lbc.cryptoguru.org:5000/stats could theoretically be done within 12 hours on the GPU in my notebook. Right now it's the effort of 1 month from around 25 CPU cores. There was a speedup by a factor of 3 recently, but still... Rico |
|
|
|
Vielleicht teste ich deinen Windows Client auch mal.
Ist keine offizielle Release, aber endlich die erste Win version, die stabil läuft. http://62.146.128.45//download/LBC-0.827_w64.zipBraucht sogar nicht mehr Speicher als die Linuxversion FALLS man nur eine CPU pro Prozess nutzt. Also perl LBC -c 1 -t 600notfalls halt in mehreren Fenstern eingeben, dann laufen eben x LBC prozesse, von denen jeder eine CPU nutzt. Das ist überhaupt kein Problem, der Server kommt mit sowas klar. Wenn man -c 3 oder so eingibt, läuft es zwar immer noch stabil, aber die Speicherhölle geht los. Also: zweimal LBC -c 1 starten ist wesentlich schonender als einmal LBC -c 2 edit: mindestens zwei Win clients haben die ganze Nacht über Daten geknuspert und sind ohne Probleme durchgelaufen. Rico |
|
|
|
No version I've ever used saves history when closed. Are you quite sure you're not just minimising it?
Minimising? You're talking to someone who starts (and sees ending) his bitcoin-qt like this: # bitcoin-qt
[1]+ Done bitcoin-qt
it's a self-compiled version under Gentoo linux: # eix bitcoin-qt
[I] net-p2p/bitcoin-qt
Available versions: 0.10.2 (~)0.10.2-r1 (~)0.11.0 (~)0.11.1 (~)0.11.2 (~)0.12.0 (~)0.12.1 (~)0.13.0 **9999 {1stclassmsg bitcoin_policy_cltv bitcoin_policy_cpfp bitcoin_policy_dcmp (+)bitcoin_policy_rbf bitcoin_policy_spamfilter dbus +http kde +libevent libressl ljr +qrcode qt4 qt5 test +tor upnp +wallet xt zeromq LINGUAS="ach af af_ZA ar be_BY bg bg_BG bs ca ca@valencia ca_ES cmn cs cs_CZ cy da de el el_GR en en_GB eo es es_419 es_AR es_CL es_CO es_DO es_ES es_MX es_UY es_VE et eu_ES fa fa_IR fi fil fr fr_CA fr_FR gl gu_IN he hi_IN hr hu id_ID it it_IT ja ka kk_KZ ko_KR ku_IQ ky la lt lv_LV mk_MK mn ms_MY nb nl pam pl pt_BR pt_PT ro ro_RO ru ru_RU sah sk sl_SI sq sr sr@latin sv ta th_TH tr tr_TR uk ur_PK uz@Cyrl uz@Latn vi vi_VN zh zh_CN zh_HK zh_TW"}
Installed versions: 0.13.0(06:14:35 PM 08/30/2016)(dbus ljr qrcode qt4 wallet -bitcoin_policy_rbf -bitcoin_policy_spamfilter -http -kde -libevent -libressl -qt5 -test -tor -upnp -zeromq LINGUAS="cs de en -af -af_ZA -ar -be_BY -bg -bg_BG -ca -ca@valencia -ca_ES -cs_CZ -cy -da -el -el_GR -en_GB -eo -es -es_AR -es_CL -es_CO -es_DO -es_ES -es_MX -es_UY -es_VE -et -eu_ES -fa -fa_IR -fi -fr -fr_CA -fr_FR -gl -he -hi_IN -hr -hu -id_ID -it -it_IT -ja -ka -kk_KZ -ko_KR -ku_IQ -ky -la -lt -lv_LV -mk_MK -mn -ms_MY -nb -nl -pam -pl -pt_BR -pt_PT -ro -ro_RO -ru -ru_RU -sk -sl_SI -sq -sr -sr@latin -sv -ta -th_TH -tr -tr_TR -uk -ur_PK -uz@Cyrl -vi -vi_VN -zh -zh_CN -zh_HK -zh_TW")
Homepage: http://bitcoincore.org/
of course, when I end it, no bitcoin* process runs anymore # ps aux | grep bitcoin
root 17280 0.0 0.0 114584 772 pts/0 S+ 17:28 0:00 grep --colour=auto bitcoin
So if you say I'm experiencing something no one has seen so far... interesting... Rico |
|
|
|
|
Show Posts
