Is it possible to have a longer or full list of all active "miners"?
And how do I check what ID I have so I can find myself on there.
(When I overtake everyone else with an army of computers)
Topic: Large Bitcoin Collider (Collision Finders Pool) - page 55. (Read 193404 times)
Just got my first rig up and running thanks to you Rico <3
Doing 1 million keys pr sec atm.
If anyone needs any help, then PM and ill do my best to guide you.
Doing 1 million keys pr sec atm.
If anyone needs any help, then PM and ill do my best to guide you.
My terminal works, but on pool stats no change.
Edit: I use VM and my ID changed, if i use more procesor and more memory for my VM machine.
Edit: I use VM and my ID changed, if i use more procesor and more memory for my VM machine.
In case you're wondering why no news: Heavy development and testing.
Next release will be a big one, so despite RERO, it may take another week or even two.
Meanwhile pool runs und churns.
As the image is too big for bitcointalk, click on this to view.
Rico
edit: Pool performance 24h average pretty steady at 23.5 MKeys/s, short term fluctuations between 21 MKeys/s and 29 MKeys/s
Next release will be a big one, so despite RERO, it may take another week or even two.
Meanwhile pool runs und churns.
As the image is too big for bitcointalk, click on this to view.
Rico
edit: Pool performance 24h average pretty steady at 23.5 MKeys/s, short term fluctuations between 21 MKeys/s and 29 MKeys/s
Well, I can do a danish translation of just about everything you can provide to me.
Material that can make it easier to understand and maybe more updates would be nice
I just got another pc today which should be like the other one I have at home.
Will see when I can have both setup and running with linux and have them mining 24/7.
My money is still up for graps for developers that can help this project to move forward.
Material that can make it easier to understand and maybe more updates would be nice
I just got another pc today which should be like the other one I have at home.
Will see when I can have both setup and running with linux and have them mining 24/7.
My money is still up for graps for developers that can help this project to move forward.
I also want to invest into the project.
I have 1 BTC that I can throw into this.
I have 1 BTC that I can throw into this.
Thank you for the nice/generous offer. When I started this, I made the decision to stem the cost for pool operation myself.
I intend to keep it that way, both for idealistic as well as for legal reasons. This is a hobby/geek project and I shall never make money out of this, because I'm pretty sure somewhere some legal a**orifice would then like to construe this as "commercial interest".
Therefore, no banners, no "begging" for pool support and - not even taking unsolicited grants like this.
You still can support the pool with your 1 BTC another way:
https://bitcointalksearch.org/topic/m.16267353
https://bitcointalksearch.org/topic/m.16273114
I am willing to pay also an incentive for a GPU-based LBC miner. If we can make a formal "pot" with the incentive, I'm pretty sure there is now more than enough monetary incentive to either hack oclvanitygen to our bidding or do something LBC specific. I'm already in the process of writing up a formal requirements specification.
If the more generic question "What can I do to help?" comes up, here's a few things:
Hack
If you are a good hacker and know OpenCL and/or CUDA ... see above!
Help to spread the news
While I can maintain this English thread - and to a certain degree also the German one (as we don't have a Czech one, I can't be of any help there) - I would certainly welcome if someone could maintain HQ information about the project in other languages that are inaccessible to me. Don't underestimate the language barrier.
Think of a situation when this becomes well aware in the Chinese boards and some day some manufacturer would approach us with some ASICs
Also, while bitcointalk.org certainly is a good megaphone for this project, it certainly isn't the only one and I'm not even sure it's the biggest. I would like to see some /r/bitcoin information maintenance of this project, but I am afraid I don't find the time to do so myself.
I'm also very old school so I do own neither a Facebook, nor a Twitter account...
Help with the documentation
I'm trying to document as good as I can, but in a rapidly changing project like this, there will inevitably be some outdated information. Also, I may already be getting a little bit project-blind and assuming the user-in-spe knows things he simply can't know. Both making it harder for newbies to participate. Actually IF you are a newbie, exactly this situation is valuable.
Of course you are expected "to read it all", but if you then see inconsistencies, outdated information, missing information... assemble and report that (I prefer bulk processing).
If you can do a small How-To in some other language, then by any means do it!
Rico
Havent been able to setup the server yet.
Will have time this week.
I also want to invest into the project.
I have 1 BTC that I can throw into this.
For either hardware to test this on, or anything else that might be needed.
I am at your service Rico
EDIT:
Can you link to any sources so I can learn more about this?
And maybe even help one day.
Will have time this week.
I also want to invest into the project.
I have 1 BTC that I can throw into this.
For either hardware to test this on, or anything else that might be needed.
I am at your service Rico
EDIT:
Can you link to any sources so I can learn more about this?
And maybe even help one day.
I bet most of you - if you are not Satoshi Nakamoto - have asked themself "Why oh why didn't I mine for da precious BTC back in 2009?"
The answer is actually trivial: It's either because you didn't see its value (as at that time it had none) or you were unaware (because others also didn't see its value therefore the news "have you checked out this new cool cryptocurrency..." didn't spread).
If you do not participate in the LBC yet, you will ask yourself the same question in a year or so. Deja Vu at its finest.
2016-07-10 0.0000000000000000000000000000000000000000000000000000000000%
2016-09-17 0.0000000000000000004524764939984744324231018884855317923702%
2016-09-21 0.0000000000000001253458951869845883453371545658596111253200%
2016-09-24 0.0000000000000043042164539298425445359190647758710199397875%
2016-09-26 0.0000000000000073909029565816723002553643394779850994024627%
2016-09-26 0.0000000000000094983619014185236171698521342910676276368576%
If you participate in the LBC, you know that number. If you don't - find out.
Very soon, the (yes - still small) probability to find an address with funds will be 16384 times higher than it was (then) 10 days ago.
Done.
The math behind this is simple, the pool has searched an additional 14bits of search space since then.
Now contrary to BTC mining this seems to be inverse. You do not need to participate now. The later you get in, the better probability you start with.
Right.
Except... you know this, I know this. The pool knows this. The pool is aware of when a client started and how many blocks it contributed since then.
Since we all want to serve up justice (right?), the pool will take that information into account in the future.
How? What? You may ask.
I could say "Wait and see". I could say "I don't know yet". I could explain how, but I won't now.
Suffice to say, the possibilities how to steer justice are many. Early adopters can get "better blocks" a.k.a more promising search space, there can (and will) be bounties for all where exactly these parameters will be taken into account for an aliquot share. You know - the old school aliquot... "pro-rata". "Proportionately" for the younger among us.
Some are probably already aware of the new options that have popped up in the LBC help
They are there for a reason and the NYI will vanish soon.
Rico - serving justice since 1970
The answer is actually trivial: It's either because you didn't see its value (as at that time it had none) or you were unaware (because others also didn't see its value therefore the news "have you checked out this new cool cryptocurrency..." didn't spread).
If you do not participate in the LBC yet, you will ask yourself the same question in a year or so. Deja Vu at its finest.
2016-07-10 0.0000000000000000000000000000000000000000000000000000000000%
2016-09-17 0.0000000000000000004524764939984744324231018884855317923702%
2016-09-21 0.0000000000000001253458951869845883453371545658596111253200%
2016-09-24 0.0000000000000043042164539298425445359190647758710199397875%
2016-09-26 0.0000000000000094983619014185236171698521342910676276368576%
If you participate in the LBC, you know that number. If you don't - find out.
Done.
The math behind this is simple, the pool has searched an additional 14bits of search space since then.
Now contrary to BTC mining this seems to be inverse. You do not need to participate now. The later you get in, the better probability you start with.
Right.
Except... you know this, I know this. The pool knows this. The pool is aware of when a client started and how many blocks it contributed since then.
Since we all want to serve up justice (right?), the pool will take that information into account in the future.
How? What? You may ask.
I could say "Wait and see". I could say "I don't know yet". I could explain how, but I won't now.
Suffice to say, the possibilities how to steer justice are many. Early adopters can get "better blocks" a.k.a more promising search space, there can (and will) be bounties for all where exactly these parameters will be taken into account for an aliquot share. You know - the old school aliquot... "pro-rata". "Proportionately" for the younger among us.
Some are probably already aware of the new options that have popped up in the LBC help
Code:
...
Options:
--address
Give a BTC address for rewards to this client. NYI
...
--secret <[oldpassword:]password>
Set or change password for enhanced security (changing BTC address).
They are there for a reason and the NYI will vanish soon.
Rico - serving justice since 1970
"There is also a small bounty to be found within the next few blocks: 1AKKm1J8hZ9HjNqjknSCAfkLR4GgvCAPjq and when that is found, there will be another one. ;-)"
How great is your "small bounty" actually?
Since when are Hero Members incapable of browsing blockchain.info?
Rico
Since it become unreliable do to the constant lag they see.
https://blockr.io is the go to for many people now.
Great, that sounds nice!
And thx for your nice work so far!!!
And thx for your nice work so far!!!
I would prefer a flag, to start at a specific block, instead of a range(which is limited to one day work). So i don't need to start over again, once it has done the work of one day.
Like in a loop, ./LBC -c 4 and just go on with the work like forever
Like in a loop, ./LBC -c 4
I know what you mean and LBC will have in the next (or one of the next) version a very sophisticated way of defining search space. Additionally to
auto
it will offer also
janitor
and you will be able to enter the numbers in various formats
12121 (normal - old - 1M block)
#2382392832 (concrete key number)
#b10101010101 (same, but binary)
#xffa100d (guess...
Oh - 'janitor' will explicitely ask the server for leftovers no one had a look at so far (or didn't deliver PoW).
etc.
Rico
Rico, i've got an suggestion.
I would prefer a flag, to start at a specific block, instead of a range(which is limited to one day work). So i don't need to start over again, once it has done the work of one day.
Like in a loop, ./LBC -c 4 and just go on with the work like forever
I would prefer a flag, to start at a specific block, instead of a range(which is limited to one day work). So i don't need to start over again, once it has done the work of one day.
Like in a loop, ./LBC -c 4
Testing mode. Using page 0, turning off looping.
Benchmark info not found - benchmarking... done.
Benchmarked factor 1.7527004375
oTest check failed! Expected 4 hits and got 28!
...
Simply ignore it. "Someone" (not me) planted a surprise in block 1. Surprise surprise, test broken because - see https://bitcointalksearch.org/topic/m.16295924
Quote
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 X hits.
And "someone else" (me) ... didn't make LBC -x with the new blf before releasing.
edit:
Behold! The incremental updater/purifier! If and only if (iff) you experience the problem above (28 hits instead of 4 when running LBC -x)
and you do not want to download again a blob of 512 MB bloom filter, you do this:
* Install xdelta3 (http://xdelta.org/) - your distribution should have it
* download http://62.146.128.45/download/unpollute.bindiff <--- a fabulous only 10 Kb
* in LBC-client dir do:
Code:
xdelta3 -d -s funds_h160.blf unpollute.bindiff funds_h160_clean.blf
mv funds_h160_clean.blf funds_h160.blf
done. LBC -x should work as documented. I will incorporate this into LBC, so I can finally establish a quick and seamless update of addresses with funds on them with minimum network traffic for the clients.
Very truly yours,
Rico
HRD-core client Linux64 available for download: http://62.146.128.45/download/LBChrd-0.837_l64.tbz2
Docs how to install, see https://bitcointalksearch.org/topic/m.16338052
and README.txt
Everyone should update, Early adopters too because this package contains an updated .blf file and the fairy told me, there are some surprises waiting...
Rico
Docs how to install, see https://bitcointalksearch.org/topic/m.16338052
and README.txt
Everyone should update, Early adopters too because this package contains an updated .blf file and the fairy told me, there are some surprises waiting...
Rico
These are all compressed addresses, and if you watch closer, you'll see you don't need to search the whole key-space. If you're 'hunting' these https://blockchain.info/tx/08389f34c98c606322740c0be6a7125d9860bb8d5cb182c02f98461e5fa6cd15 addresses, you can start with the lowest 'possible' inside the given key-space(it's not always the first-one), and after a found you can skip to the next one!
EDIT:
For example
Address 48: 281474976710656 - 562949953421311 (whole bit-space)
Address 49: 1000000000000000 - 1125899906842623 (just a part of the bit-space)
EDIT:
For example
Address 48: 281474976710656 - 562949953421311 (whole bit-space)
Address 49: 1000000000000000 - 1125899906842623 (just a part of the bit-space)
That was accounted for in my estimate.
I'm surprised how - from pool operation and development - I still get new insight every day.
This also affects my motivation.
When I started this project, I simply wanted to test how far an individual can go. To get some practical feeling for the task at hand that has been discussed so often in theory. In theory only. I also wanted to be able to make some estimate about the capabilities some clandestine group doing such a thing might have.
When what seemed to be limits kept being pushed more and more to what seemed to be new limits, there was also some motivation to disprove common beliefs and mantras about the infeasibility of such an endeavor. Or - at least - to correct the numbers.
When I read about Ryans lower bound estimate of capabilities of "someone" already having been searching the PK-space @ 28 MKeys/s here, I suddenly felt the need to get this pool up to speed, so a public community project could at least outperform such clandestine Muffugahz.
So that is currently my motivation, to amass a keyrate that will draw level with aforementioned capabilites and eventually pull ahead.
------
Currently the pool operates the HRD-core on the equivalent of roughly 22 Skylake cores. I will make a polished version of it available today evening (CEST) for everyone interested to download. The pool has seen - so far - 59 individual clients of which alone the top5 are responsible for 80% of it's performance.
I am quite confident, that my current goal of surpassing ~ 28 MKeys/s will be reached within a week. And then let's just pick another goal - together.
Rico
This also affects my motivation.
When I started this project, I simply wanted to test how far an individual can go. To get some practical feeling for the task at hand that has been discussed so often in theory. In theory only. I also wanted to be able to make some estimate about the capabilities some clandestine group doing such a thing might have.
When what seemed to be limits kept being pushed more and more to what seemed to be new limits, there was also some motivation to disprove common beliefs and mantras about the infeasibility of such an endeavor. Or - at least - to correct the numbers.
When I read about Ryans lower bound estimate of capabilities of "someone" already having been searching the PK-space @ 28 MKeys/s here, I suddenly felt the need to get this pool up to speed, so a public community project could at least outperform such clandestine Muffugahz.
So that is currently my motivation, to amass a keyrate that will draw level with aforementioned capabilites and eventually pull ahead.
------
Currently the pool operates the HRD-core on the equivalent of roughly 22 Skylake cores. I will make a polished version of it available today evening (CEST) for everyone interested to download. The pool has seen - so far - 59 individual clients of which alone the top5 are responsible for 80% of it's performance.
I am quite confident, that my current goal of surpassing ~ 28 MKeys/s will be reached within a week. And then let's just pick another goal - together.
Rico
I'm sorry, but ryan is wrong with his 28 MKeys/s, he's regarding always the whole key/bit space. These are all compressed addresses, and if you watch closer, you'll see you don't need to search the whole key-space. If you're 'hunting' these https://blockchain.info/tx/08389f34c98c606322740c0be6a7125d9860bb8d5cb182c02f98461e5fa6cd15 addresses, you can start with the lowest 'possible' inside the given key-space(it's not always the first-one), and after a found you can skip to the next one!
EDIT:
For example
Address 48: 281474976710656 - 562949953421311 (whole bit-space)
Address 49: 1000000000000000 - 1125899906842623 (just a part of the bit-space)
I'm surprised how - from pool operation and development - I still get new insight every day.
This also affects my motivation.
When I started this project, I simply wanted to test how far an individual can go. To get some practical feeling for the task at hand that has been discussed so often in theory. In theory only. I also wanted to be able to make some estimate about the capabilities some clandestine group doing such a thing might have.
When what seemed to be limits kept being pushed more and more to what seemed to be new limits, there was also some motivation to disprove common beliefs and mantras about the infeasibility of such an endeavor. Or - at least - to correct the numbers.
When I read about Ryans lower bound estimate of capabilities of "someone" already having been searching the PK-space @ 28 MKeys/s here, I suddenly felt the need to get this pool up to speed, so a public community project could at least outperform such clandestine Muffugahz.
So that is currently my motivation: to amass a keyrate that will draw level with aforementioned capabilites and eventually pull ahead.
------
Currently the pool operates the HRD-core on the equivalent of roughly 22 Skylake cores. I will make a polished version of it available today evening (CEST) for everyone interested to download. The pool has seen - so far - 59 individual clients of which alone the top5 are responsible for 80% of it's performance.
I am quite confident, that my current goal of surpassing ~ 28 MKeys/s will be reached within a week. And then let's just pick another goal - together.
Rico
This also affects my motivation.
When I started this project, I simply wanted to test how far an individual can go. To get some practical feeling for the task at hand that has been discussed so often in theory. In theory only. I also wanted to be able to make some estimate about the capabilities some clandestine group doing such a thing might have.
When what seemed to be limits kept being pushed more and more to what seemed to be new limits, there was also some motivation to disprove common beliefs and mantras about the infeasibility of such an endeavor. Or - at least - to correct the numbers.
When I read about Ryans lower bound estimate of capabilities of "someone" already having been searching the PK-space @ 28 MKeys/s here, I suddenly felt the need to get this pool up to speed, so a public community project could at least outperform such clandestine Muffugahz.
So that is currently my motivation: to amass a keyrate that will draw level with aforementioned capabilites and eventually pull ahead.
------
Currently the pool operates the HRD-core on the equivalent of roughly 22 Skylake cores. I will make a polished version of it available today evening (CEST) for everyone interested to download. The pool has seen - so far - 59 individual clients of which alone the top5 are responsible for 80% of it's performance.
I am quite confident, that my current goal of surpassing ~ 28 MKeys/s will be reached within a week. And then let's just pick another goal - together.
Rico
FWIW, my interest in this project is primarily to find various "easter egg" transactions people have made, and try to infer the cracking others have done in the past. I find it unlikely at this point that there are keys produced by broken random number generators that have not already been drained.
https://bitcointalksearch.org/topic/m.16324187
aaaaand 41bit! Did someone take time?
Anyway - regarding new client: progress is good, cleaning up the code, packaging process runs through smooth, just need more sanity checks and safeguards in the code. Here are your instructions after you have downloaded the package.
The package will be around 161M named LBChrd-0.833_l64.tbz2 (probably some later version number).
1) tar xf LBChrd-0.833_l64.tbz2 in some directory, you'll end up with the usual LBC-client subdir.
2) LBC-client contains these files
2a) You want to install libgmp-dev (or similar) to have the header files for the GNU MP Library, else you will experience nuisance Math::BigInt::GMP messages.
2b) You need to be root, or do a sudo ./LBC ... at least in the 1st call when LBC tries to install modules. When these are installed, LBC can of course run under regular user.
3) You simply do a ./LBC -h on your 1st call. This will install all packages needed. If you had LBC running before, you're set, as the new version doesn't need any additional modules.
3a) Therefore, if you are a Win-User with a new Linux VM installation, it doesn't hurt to install the Go-based LBC for Linux 64bit in there. Running this will prove you have prepared the environment correctly. Also, make sure your VM sees your current processor features and not just some kind of emulated CPU. Ideally, when doing a grep avx2 /proc/cpuinfo you will get hits.
3b) If LBC -h is ok, don't forget to do a LBC -x (testing). You need to do this only once. It will also re-benchmark your computer. You should see this output (different factor - of course):
Then your system works flawlessly. Do as it says with the FOUND.txt file and you're ready to go.
4) If you have an AVX2 capable CPU (Skylake, Xeon v4, Xeon v3), LBC will choose the gen-hrdcore-avx2-linux64 generator. This is currently your best possible ride. If it doesn't find avx2, it will use gen-hrdcore-westmere-linux64. This will also run on anything between Westmere and Xeon v2. Maybe even Nehalem CPUs will run with this, but no guarantee. If your CPU is older - no gen at the moment.
The gen-hrdcore-westmere-linux64 will also run on AVX2 architectures, albeit slower. On my Skylake notebook, the gen-hrdcore-avx2-linux64 needs 28 seconds to search 16 mio PKs, the gen-hrdcore-westmere-linux64 works also on Skylake, but needs 36 seconds. So make sure, your cpuinfo shows avx2 if you have it.
5) Well - you're ready to go: LBC -c 4 -t 1240 The HRD-version will probably disallow anything below -t 600, because - honestly - it doesn't make sense. If you look at the stats, we have already clients who gulp 25000 blocks an hour 24/7. (Which is good for the smaller clients, because these fatties take the pool "forefront" (and thus all of us) to greener pastures which start at 50/51 bit search space)
6) You should see something like this
plusminus YMMV.
One more thing: The new generators use a bloom filter that is aware of all hash160 with funds on them. A bloom filter is a probabilistic data structure, which will never overlook a hash160 with funds on it, but it may give out a false positive for a hash160 it sees. The error probability for this to happen is ~ 10-27 with the current size and number of hash160 we have. So not a big deal, but be prepared to see a hit which is none. Also, there are no funds stored with the bloom filter - only the hash160. So if you get a hit and if this hit is not a false positive, you will have to look up the funds for the hash160 yourself (blockchain.info e.g.).
Rico
aaaaand 41bit! Did someone take time?
Anyway - regarding new client: progress is good, cleaning up the code, packaging process runs through smooth, just need more sanity checks and safeguards in the code. Here are your instructions after you have downloaded the package.
The package will be around 161M named LBChrd-0.833_l64.tbz2 (probably some later version number).
1) tar xf LBChrd-0.833_l64.tbz2 in some directory, you'll end up with the usual LBC-client subdir.
2) LBC-client contains these files
Code:
md5sums
LBC
README.txt
gen-hrdcore-avx2-linux64
gen-hrdcore-westmere-linux64
funds_h160.blf
2a) You want to install libgmp-dev (or similar) to have the header files for the GNU MP Library, else you will experience nuisance Math::BigInt::GMP messages.
2b) You need to be root, or do a sudo ./LBC ... at least in the 1st call when LBC tries to install modules. When these are installed, LBC can of course run under regular user.
3) You simply do a ./LBC -h on your 1st call. This will install all packages needed. If you had LBC running before, you're set, as the new version doesn't need any additional modules.
3a) Therefore, if you are a Win-User with a new Linux VM installation, it doesn't hurt to install the Go-based LBC for Linux 64bit in there. Running this will prove you have prepared the environment correctly. Also, make sure your VM sees your current processor features and not just some kind of emulated CPU. Ideally, when doing a grep avx2 /proc/cpuinfo you will get hits.
3b) If LBC -h is ok, don't forget to do a LBC -x (testing). You need to do this only once. It will also re-benchmark your computer. You should see this output (different factor - of course):
Code:
Testing mode. Using page 0, turning off looping.
Benchmark info not found - benchmarking... done.
Benchmarked factor 1.7556270625
o
Test ok. Your test results were stored in FOUND.txt.
Have a look and then you may want to remove the file.
2d17543d32448acc7a1c43c5f72cd5be459ab302:u:(hex)priv:000000000000000000000000000000000000000000000000000000000000005f
02e62151191a931d51cdc513a86d4bf5694f4e51:c:(hex)priv:0000000000000000000000000000000000000000000000000000000000000066
9d74ffdb31068ca2a1feb8e34830635c0647d714:u:(hex)priv:00000000000000000000000000000000000000000000000000000000000f9f8d
3d6871076780446bd46fc564b0c443e1fd415beb:c:(hex)priv:00000000000000000000000000000000000000000000000000000000000f9f8d
Ending test run.
Then your system works flawlessly. Do as it says with the FOUND.txt file and you're ready to go.
4) If you have an AVX2 capable CPU (Skylake, Xeon v4, Xeon v3), LBC will choose the gen-hrdcore-avx2-linux64 generator. This is currently your best possible ride. If it doesn't find avx2, it will use gen-hrdcore-westmere-linux64. This will also run on anything between Westmere and Xeon v2. Maybe even Nehalem CPUs will run with this, but no guarantee. If your CPU is older - no gen at the moment.
The gen-hrdcore-westmere-linux64 will also run on AVX2 architectures, albeit slower. On my Skylake notebook, the gen-hrdcore-avx2-linux64 needs 28 seconds to search 16 mio PKs, the gen-hrdcore-westmere-linux64 works also on Skylake, but needs 36 seconds. So make sure, your cpuinfo shows avx2 if you have it.
5) Well - you're ready to go: LBC -c 4 -t 1240 The HRD-version will probably disallow anything below -t 600, because - honestly - it doesn't make sense. If you look at the stats, we have already clients who gulp 25000 blocks an hour 24/7. (Which is good for the smaller clients, because these fatties take the pool "forefront" (and thus all of us) to greener pastures which start at 50/51 bit search space)
6) You should see something like this
Code:
# ./LBC -c 4 -t 1240
done.
Fetching adequate work... got block interval [1659184-1661667]
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
plusminus YMMV.
One more thing: The new generators use a bloom filter that is aware of all hash160 with funds on them. A bloom filter is a probabilistic data structure, which will never overlook a hash160 with funds on it, but it may give out a false positive for a hash160 it sees. The error probability for this to happen is ~ 10-27 with the current size and number of hash160 we have. So not a big deal, but be prepared to see a hit which is none. Also, there are no funds stored with the bloom filter - only the hash160. So if you get a hit and if this hit is not a false positive, you will have to look up the funds for the hash160 yourself (blockchain.info e.g.).
Rico
Will setup everything on saturday.
Thanks for the info
Thanks for the info
Jump to: