And who do you think brought it up on their radar? That's right, yours truly. I posted about Bitcoin on their forums last year, I was rejected straight away.
Nice job assimilating quark. Just keep at it; resistance is futile. They not only denied me back then, they also deleted the thread. |
|
|
|
|
And who do you think brought it up on their radar? That's right, yours truly. I posted about Bitcoin on their forums last year, I was rejected straight away.
|
|
|
|
|
Yup, Proof-of-Stake is an interesting concept, which is why PPC should be given a chance.
|
|
|
|
Hi all. Been a rather long time, but honestly I kinda wanted to rest since even though aVanityGen is incomplete, I poured a lot of precious time into it. I've decided to pick it up again, but this time I need help from the community. One problem I am facing is the connection between Java and JNI. You see, the way I display the private and public key in the UI is by having two global variables in my main class/activity on the Java side, when a key is requested JNI takes over and generates a keypair and sets the Java global variables(privkey and pubkey;both are of type String but with no access modifiers) but nothing guarantees they are set(could happen if something went wrong with JNI). Then on the Java side is where I do the regular expression matching. Here lies the problem, in order to actually match them, I must return from JNI to Java, thereby exiting the generating function. Samr7 discovered that it's possible to batch up EC points and do batched modular inversion which is why he achieved such great speeds. EC_POINTs_make_affine(pgroup, nbatch, ppnt, vxc_bnctx);
for (i = 0; i < nbatch; i++, vxc_delta++) {
// Hash the public key
len = EC_POINT_point2oct(pgroup, ppnt[i], POINT_CONVERSION_UNCOMPRESSED, eckey_buf, sizeof(eckey_buf), vxc_bnctx);
SHA256(eckey_buf, len, hash1);
RIPEMD160(hash1, sizeof(hash1), &vxc_binres[1]);
// Debug
char address[64];
Base58Encode(vxc_binres,21, address); //Funny, but I do not remember why I skip the 4 byte check code. Duh, for debug purposes :P
__android_log_print(ANDROID_LOG_INFO, "aVanityGen", "%s=%s", bin2hex(vxc_binres,21), address);
npoints = 0;
rekey_at = 0;
i = nbatch;
break; //No point in continuing further.
} This is the relevant C code. I am still using it in my code despite the fact that it does NOTHING at this point. The problem is, I have no way to return to Java on every loop and check it before the next loop begins. Doing the actual checking in there sounds like a plan, but how? Using PCRE sounded like a nice idea, but it would add a lot of size to the program. I offer an 100 PPcoin bounty for real ideas on how to overcome this. I know 100 ppcoins is not nearly enough, but hey, I didn't see 100 litecoins being a lot at the time as well. |
|
|
|
The boy is 16. I wonder what his parents would say if one called them. It's not like the number isn't easily found. Or his soccer coach. Man, these soccer coaches, they're always up in your face about stuff. BTW, nice house, Kennard  Yeah, nice photoshop. Love the kid with the dog on the chimney. |
|
|
|
|
Yep, and a problem arises for people who use PayPal, reversible it is no matter if you use dual-key wallets or a gazillion-key wallet.
|
|
|
|
|
Ok, but is it possible in future versions to add a field in listtransactions that shows the age of the coins(in days if possible)? So I can for instance calculate faster and easier how much till they are stake?
Also, in the FAQ it says it will TRY to generate a stake block, what conditions control if I generate one or don't? And how often will it try to generate a stake block?
|
|
|
|
|
I am sure it's been asked a lot, but there are dozens of pages here and searching would not be effective. But can someone tell me how you generate proof-of-stake blocks?
I know that you need to let the money "rot" for 30 or so days and then automagically blocks 'might' appear, but I'd really like a better explanation.
And what about the stake part? By stake I assume gambling where it's a win OR lose meaning I could find a proof-of-stake block or lose my money?
|
|
|
|
|
I've heard that at a few hundred GH/s pushpool is unable to handle it anymore.
|
|
|
|
How did you find them?
That's what I wanna know. Dumpster diving out back of a pc shop that had a cleanout? seriously they are old tech, the only use for them will be people with old pcs whose gfx card fails and they wont upgrade to a new system. If you want to get an idea of the real value, start an auction on ebay at $2 and see where it sells  The value is in what someone will pay for it, not what someone wants to get for it  and all us nerds who do family/friend tech support know someone like that, who just refuses to commit a few bucks to buying a new system. sigh. i've flat out told my friends and family that if it's more than 3yrs old, i ain't helping them with it. Especially my brother in law, who likes to THINK he's a techie, but is really just an idiot. NASA, up until recently, has been buying up old 386 hardware on the sly in order to maintian their legacy control computers, mostly in the shuttles. The reason that they were necessary was because the old & slow cpu's were much more tolerant to ionizing radiation making into the computer case, and thus did not require nearly as much shielding as a more recent cpu arch. For similar reasons, the USMC had 486 machines in hardened cases up until around 1995. These thing s are worth something to someone, if only a enterprise business in Africa. True, but bit-rot can and does occur on earth but around once per year. For clustered memory perhaps more. |
|
|
|
|
Are you talking about the vanity miner or vanitygen?
|
|
|
|
|
Bitcoin websites and services are just prone to hacks/attacks.
|
|
|
|
Haha! Doh! I was using the Debug build. The Release build is 1.1 MB. EDIT: Hmm. I see references to .so files when I check the executable via strings: rune@rune-desktop:~/.workspace/sbag/Release$ strings sbag|grep "\.so"
/lib64/ld-linux-x86-64.so.2
libc.so.6
ld-linux.so is the dynamic linker and libc.so is the Standard C Library. All of these are specific to that ABI and therefore wont work on anything else. |
|
|
|
samr7,
Is it possible for you to comment a little on what the difficulty number represents and how it's calculated. I tried looking thru the code and figuring it out but BN math and probability is definitely not my forte. I ended up being pretty confused.
I'd like to be able to estimate the probability for a prefix pattern in my own code without running vanitygen - if not perfect mathematically then a rough time estimate would work.
Hi BkkCoins, Difficulty is the number of keys that have to be checked, on average, to find a match. The simplest way to do this is to have a table of prefix difficulties, and for each character after the beginning of the prefix, multiply by 58. For this, you'd have something like: 11 = 256 12-1P = 22 1Q = 65 1R-1z = 1353 So, 1Abc = 22 x 58 x 58 = 74008, and 1egg = 1353 x 58 x 58 = 4551492, which are very close to the exact difficulties. This scheme wouldn't be very accurate for multiple leading 1s, and certain suffixes of 1Q, without special handling of those cases. The exact, but more complicated way to do this is to follow the formula: Difficulty = (Total addresses) / (Matching addresses) The tricky part is figuring out the number of matching addresses. If your keys were 10-digit base-10 numbers, and you wanted to find everything with a prefix of 12345, with no leading 0s, then: Total keys = 10000000000 Matches = 1234500000 ... 1234599999 = 100000 total matches Difficulty = 10000000000 / 100000 = 100000, or 1:100000 keys It's more complex to do this for base-58, but as in the example, the task is to convert a base-58 prefix into ranges of numbers that result in matches. If you're interested, I will post more about this. How did you come up with this algorithm? |
|
|
|
|
Sent a bet a few 30 minutes ago, never received anything. Was using client 0.6.3.c-beta.
|
|
|
|
|
It tries to, but as it has been pointed out. Luck is the variation. There's just no real way to control block finding so it's exactly 10 minutes. It could be more, it could be less.
|
|
|
|
|
Block finding is random. I have seen blocks being found within seconds of each other. It all depends on luck. Sometimes due to luck, blocks are found faster even if the difficulty corresponds to the network computational power.
And sometimes, again due to luck, some blocks take a while(20-30 minutes).
|
|
|
|
|
Don't want to be a grammar nazi, but perhaps OP should learn to use capital letters, and less space between sentences.
|
|
|
|
|
Show Posts
