 Show Posts
|
|
Pages: [1] 2 3 4 5 »
|
You can find the basics of the agorithm here:
http:<slashslash>gobittest.appspot.com/VanityAll
On this site your can combine both private and public key to generate new results.
It show you raw private/public keys as well as the generated bitcoin addresses.
It supports both addition and multiplication of the private keys.
Vanitygen only uses the additions methode because public keys can only be added.
Thanks so much. I have used this site and it's really helpful, but unfortunately doesn't answer my questions around exactly how Vanitygen calculates the address and the PrivkeyPart. The actual nuts and bolts of it. With regards to combining keys there is nothing more to it then can be found on the website. The Vanitygen c-code itself just makes use of library functions to work with the generated keys. The calls are all based on EC (Eliptic Curve) mathematics, where bitcoin just uses the specs according to SECP256k1. https:<slashslash>en.wikipedia.org/wiki/Elliptic_curve. Transforming a public key to a bitcoin address can be found here: https:<slashslash>en.bitcoin.it/wiki/Technical_background_of_version_1_Bitcoin_addresses. But I guess I probably do not understand your questions. Are you looking for more information on how Vanitygen 'searches' for the BitcoinPrefix? |
|
|
|
Hi,
I am fascinated by Bitcoin and found Vanitygen particularly interesting.
I think I understand most of how it works except for the split key generation.
I get how the process works, but I cannot understand exactly how the PrivkeyPart and the address are calculated as the PrivkeyPart is not the private key for the Address. So how are they calculated seperately?
If anyone could provide an answer it would be much appreciated.
Thanks in advance.
You can find the basics of the agorithm here: http:<slashslash>gobittest.appspot.com/VanityAll On this site your can combine both private and public key to generate new results. It show you raw private/public keys as well as the generated bitcoin addresses. It supports both addition and multiplication of the private keys. Vanitygen only uses the additions methode because public keys can only be added. |
|
|
|
Over the years I've seen requests for P2SH multisignature vanity addresses. The basic support of Vanitygen was a 1 signature out of 1 key P2SH address. I thought it was time to add more multisignature support :-) The code for the following proof can be found in my https://github.com/kangaderoo/vanitygen repository. Generating two public keys for a 2 signature out of 3 keys P2SH redeem script: Pubkey Compressed (hex):
02a3fdb80c5da1ceb4da75e56c900da9baf2dfde0a2d2efbf81387e5ab2e91e985
Address Compressed (P2PKH):
1Q9U3bchykTsm5Ri4ZgJsgcYiBWPUSM3zE
Pubkey Compressed (hex):
03d2c632fa06281b97eba0475de8e6e4597bc19b1ce0edfb36ad889141137f7dc3
Address Compressed (P2PKH):
1BU2z1UTxmtVTrCsRWTnKuXpWXtvh9gDH3
Searching for the 2/3 P2SH address starting with 3P14159 (or ℼ): ./vanitygen.exe -M 2 -X 5 -j [\"02a3fdb80c5da1ceb4da75e56c900da9baf2dfde0a2d2efbf81387e5ab2e91e985\",\"03d2c632fa06281b97eba0475de8e6e4597bc19b1ce0edfb36ad889141137f7dc3\"] -v -i -F compressed 3P14159 -M <M> --> script address needing M signatures -X <scriptaddresstype> --> 5 is for bitcoin adresses starting with 3, other values could be used for alt-coins -j [\"pubkey1\",\"pubkey2\",....,\"pubkey(N-1)\"] --> list of keys, one key will be added by the vanitygen search to complete N keys -v --> verbose -i --> ignore case -F --> public key type Response: Pattern: 3P14159
Pubkey Compressed (hex):
0279600e5939f4f7baace27acefcc6191f260d23d30da8c779bc557c50eaf01751
Address Compressed (P2PKH):
1BU2z1UTxmtVTrCsRWTnKuXpWXtvh9gDH3
Address (P2SH):
3P14159mYzQdm5eozWLMBkaMJMxzQKu7am
Verify the generated Private Key using the keyconv utility: ./keyconv -M 2 -X 5 -C -j [\"02a3fdb80c5da1ceb4da75e56c900da9baf2dfde0a2d2efbf81387e5ab2e91e985\",\"03d2c632fa06281b97eba0475de8e6e4597bc19b1ce0edfb36ad889141137f7dc3\",\"0279600e5939f4f7baace27acefcc6191f260d23d30da8c779bc557c50eaf01751\"] or: ./keyconv -M 2 -X 5 -C -j [\"02a3fdb80c5da1ceb4da75e56c900da9baf2dfde0a2d2efbf81387e5ab2e91e985\",\"03d2c632fa06281b97eba0475de8e6e4597bc19b1ce0edfb36ad889141137f7dc3\"] <PrivKey> Response: P2SH (hex):
522102a3fdb80c5da1ceb4da75e56c900da9baf2dfde0a2d2efbf81387e5ab2e91e9852103d2c632fa06281b97eba0475de8e6e4597bc19b1ce0edfb36ad889141137f7dc3210279600e5939f4f7baace27acefcc6191f260d23d30da8c779bc557c50eaf0175153ae
P2SH address:
3P14159mYzQdm5eozWLMBkaMJMxzQKu7am
Verification in Bitcoin-qt: createmultisig 2 "[\"02a3fdb80c5da1ceb4da75e56c900da9baf2dfde0a2d2efbf81387e5ab2e91e985\",\"03d2c632fa06281b97eba0475de8e6e4597bc19b1ce0edfb36ad889141137f7dc3\",\"0279600e5939f4f7baace27acefcc6191f260d23d30da8c779bc557c50eaf01751\"]"
Response: "address": "3P14159mYzQdm5eozWLMBkaMJMxzQKu7am",
"redeemScript": "522102a3fdb80c5da1ceb4da75e56c900da9baf2dfde0a2d2efbf81387e5ab2e91e9852103d2c632fa06281b97eba0475de8e6e4597bc19b1ce0edfb36ad889141137f7dc3210279600e5939f4f7baace27acefcc6191f260d23d30da8c779bc557c50eaf0175153ae"
As I'm a puzzle solver, not a software professional, my github repository has a fixed setup to my personal environment and does not automatically configure to other development environments. My personal environment also does not support OpenCL, so this part of the code is not updated. |
|
|
|
... snip ...
As for why 168 kkeys/s for approximately 5 seconds only outputs 2971 addresses: that's only 1 in approximately 280. I'm not sure why that is.
Vanitygen is a address search application, it runs the calculations in address-batches to optimize the heavy EC_POINT calculations. The search functionality will disregard remaining calculations in the batch when it finds a match. If only a "1" is specified in the search, each calculation yields a valid result, so the first in the batch is a match, the rest is disregarded. If you want to use vanitygen as an address generator, you need to change the code to search in smaller batches. I don't know the specifics of oclvanitygen, but most software that runs on a GPU runs even larger (parallel) batches. If the same match and throw away routine is used, oclvanitygen will be less productive then vanitygen on small searches. |
|
|
|
// snip //
When I run oclvanitygen.exe 1Test I can hear my video card fan fire up and then I get the exception.
According to Dependency Walker I am using c:\windows\system32\OPENCL.DLL
Anyone have any ideas?
I guess 'standard' vanitygen runs on your system. I only have the CPU version, this one uses the SSL libaries to perform the ec-point calculations. The way I made the change has a bug when starting from offset 0. At each iteration an increment ec-point is added, this increment point is equal to the number hashes in one iteration. If offset=0 the last entry in the field has a value equal to the increment value during the first iteration, resulting in a EC-point-add with two equal numbers on the second iteration. EC-point-add with two equal numbers results in a div#0 error, I'm not sure if the ocl code handles a div#0 like the SSL lib does. run a tests using an offset. example an offset of 0x1000 would be: oclvanitygen.exe 1Test -P 04175E159F728B865A72F99CC6C6FC846DE0B93833FD2222ED73FCE5B551E5B739D3506E0D9E3C7 9EBA4EF97A51FF71F5EACB5955ADD24345C6EFA6FFEE9FED695 Assuming this offset is bigger than the increment value, you avoid the div#0. |
|
|
|
Im very bad at programming, all I did was add
const BN_ULONG rekey_max = 10000000000000000;
BIGNUM *bnprivkey, *bnpubkey;
BIGNUM start;
BIGNUM *res;
BN_init(&start);
int keylen = 32;
res = &start;
BN_hex2bn(&res,"6000000000000");
// pkey = EC_KEY_new_by_curve_name(NID_secp256k1);
pgroup = EC_KEY_get0_group(pkey);
pgen = EC_POINT_new(pgroup);
EC_KEY_set_private_key(pkey,res);
if (!EC_POINT_mul(pgroup, pgen, res, NULL, NULL, vxcp->vxc_bnctx));
printf("ERROR AT EC POINT MUL");
EC_KEY_set_public_key(pkey, pgen);
rekey_at = 999999999999999;
my change in the cpu version: const BN_ULONG rekey_max = 1000000000000000000;
// snip//
while (!vcp->vc_halt) {
if (++npoints >= rekey_at) {
vg_exec_context_upgrade_lock(vxcp);
/* Generate a new random private key */
// remove the random key generation
// EC_KEY_generate_key(pkey);
// add start point equal to 1 * generator
BN_set_word(&vxcp->vxc_bntmp, 1);
EC_KEY_set_private_key(pkey, &vxcp->vxc_bntmp);
EC_KEY_set_public_key(pkey, pgen);
and the second change I made, just to prevent a EC_point add where EC_Point double is needed if (vcp->vc_pubkey_base){
EC_POINT_add(pgroup,
ppnt[0],
ppnt[0],
vcp->vc_pubkey_base,
vxcp->vxc_bnctx);
EC_POINT_add(pgroup,
ppnt[1],
ppnt[0],
pgen,
vxcp->vxc_bnctx);
}
else{
EC_POINT_dbl(pgroup,
ppnt[1],
ppnt[0],
vxcp->vxc_bnctx);
}
// point 0 and 1 in the array are predefined, start from point 2.
for (nbatch = 2;
(nbatch < ptarraysize) && (npoints < rekey_at);
nbatch++, npoints++) {
and this is the result :~/workspace/32BTC-Challenge$ ./vanitygen 1CUNE -F compressed -v -t 1 Pattern: 1CUNE Pubkey (hex): 04f9308a019258c31049344f85f89d5229b531c845836f99b08601f113bce036f9388f7b0f632de 8140fe337e62a37f3566500a99934c2231b6cb9fd7584b8e672 Privkey (hex): 03 Address: 1CUNEBjYrCn2y1SdiUMohaKUi4wpP326Lb Privkey: KwDidCf1aesp7ibPmj64maKRXJoHJnKKtTvvuwAjME7BcDHW33X2 And using the -P <public_key> for the offset with the pubkey = 2*the generator pattern: :~/workspace/32BTC-Challenge$ ./vanitygen 1CUNE -F compressed -P 04C6047F9441ED7D6D3045406E95C07CD85C778E4B8CEF3CA7ABAC09B95C709EE51AE168FEA63DC 339A3C58419466CEAEEF7F632653266D0E1236431A950CFE52A -v -t 1 Pattern: 1CUNE Pubkey (hex): 0479be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798483ada7726a3c 4655da4fbfc0e1108a8fd17b448a68554199c47d08ffb10d4b8 Privkey (hex): 01 Address: 1CUNEBjYrCn2y1SdiUMohaKUi4wpP326Lb PrivkeyPart: KwDidCf1aesp7ibPmj64maKRXJoHJnKKtTvvuwAjME7Bb2yevh1x I guess the same change should work in oclvanitygen. The next point(s) generation code was already sequential and based on the generator point. The only thing you need is the pub key of 2^51 or any other point you want to start (example: 2^51 + 2^33) for your start point of the search. |
|
|
|
2nd EDIT:
I decided to abandon this project. Basically can't get Oclvanitygen to work in Windows with sequential search and the speeds seem very slow when using a 1x riser. It would take too long to find the 51st key and 52nd and 53rd would take months.
I had a look at the vanitygen code the last couple of day's to see how to make the sequential search. I just needed a minor change to have the CPU code to run from EC_key=0x01. Using the online generator at gobittest(dot)appspot(dot)com/VanityAll a key can be made to generate an offset or start code. (for the -P split-key function) There are still two issue that need to be solved 1) when starting from 1, there are parts of the code that perform an EC_POINT_ADD on two equal value's, here a EC_POINT_DOUBLE is needed. 2) when running multiple threads the old code uses a random key generation to make sure the threads used unique values, currently all my threads run the same data. 1) Is no issue when an offset key is used 2) I just execute the code in single thread, and run the executable #cpu times with another offset start code. Since I don't have a GPU system I don't know if the change in that code there is just as hard/easy. I was kind of curious what code changes you made to get it to run. |
|
|
|
Hi, It seems there are more yescrypt P2Pool networks running on different ports. I thought the strength was to join the networks. Info on the other network is here: http://p2pool.unitus.online/homeI also do not understand why you have myriad(yescrypt) and unitus (yescrypt) running independent. Unitus can be merged mined with myriad, increasing your Unitus hashrate. The p2pool software itself can not make automatic payments for auxiliary coins that's way for the moment we run them separate Ok, that seems to be a lacking from the p2pool software. I guess the password field could be used for the merged mining address, its just distribution that needs to be coded. But what about merging the myriad p2pool networks? |
|
|
|
Hi, It seems there are more yescrypt P2Pool networks running on different ports. I thought the strength was to join the networks. Info on the other network is here: http://p2pool.unitus.online/homeI also do not understand why you have myriad(yescrypt) and unitus (yescrypt) running independent. Unitus can be merged mined with myriad, increasing your Unitus hashrate. |
|
|
|
Is anyone here familiar enough with the code to understand this issue? https://github.com/samr7/vanitygen/issues/83(Not like there are enough private key choices), but: Can anyone confirm if vanitygen is using the entire private key range of 0x1 to 0xFFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFE BAAE DCE6 AF48 A03B BFD2 5E8C D036 4140 to choose private keys OR does vanitygen use a smaller range? Thanks! Vanitygen uses the standard openssl libraries, the key's generated are secp256k1. One of the secp257k1 constants it the mentioned key range, so yes it is using this range. |
|
|
|
A few (!) pages back I mentioned the discrepancies with the time estimation for 50% 75% etc This is from my system right now: Searching for pattern: "1EXAmoney" Reward: 0.008000 Value: 0.000001 BTC/MkeyHr
Difficulty: 50656515217834
[38.97 Mkey/s][total 33002830692352][Prob 47.9%][50% in 15.0h] using OclVanityMiner64.exe - to my way of thinking, half of 50 should be 25... Similarly, this is where I'm at now... Searching for pattern: "1EXAmoney" Reward: 0.008000 Value: 0.000001 BTC/MkeyHr
Difficulty: 50656515217834
[42.58 Mkey/s][total 40233450078208][Prob 54.8%][75% in 8.2d] (again, I would have imagined at 40/50 I'd be 80% done - No?) The percentage is not based on a linear algorithm. The key's that you are processing are generated based on randomness. So the progress indicator is following some statistical algorithms that involve normal distribution, 'bell-curves', probability etc. In short; this indicator shows the chance that you would have found a hit by now. |
|
|
|
Really good the aplication i pointed 4 servers to the pool to help bit.
Now i have a question
1MPmZ99f52t8cYchJMcD19QqeZnwVo2S8v
I want to bruteforce this btc adress, I own already the private keys but i wanna do some test.
shall i introduce my btc address as pattern and wait for the solution?
Ignoring that it is no use to find a complete bitcoin adress. :-) You can not put the whole bitcoin adress in vanitygen. the adress is a base58 of a hash+checksum. You will have unbase58; remove the checksum, then rebase58 and try and find that sequence. When found, that checksum part will be regenerated by vanitygen when it presents the result.... in a couple of million years. Edit:
I wanna create thousands of btc address with vanity but something give me a error
vanitygen 1 -ko test.log
what im doing wrong?
try: vanitygen 1 -k -o test.log As far as I know the flags cannot combined. |
|
|
|
So another question...
is it possible to run the oclvanitygen and stop and safe it and later continue?
Or are -f -o -s only for the actual found addresses?
It depends a bit on what you would consider a 'save' state. -f --> input file The input file of the matches you want to find, if the -k is not used a found match would be scratched of the list. Restarting would put it back on the list. -o --> output file output file, no change here with start/restart. all found matches will be appendend. -s --> seed file for randomness. This is a tricky one. The brute force search requires a high entropy source for the EC-Points generation to be truly random. If you have a system that has a more psuedo random entropy source; i.e. a possiblity to repeat the randomness in a set time, and you might end up generating the same sequence of addresses all the time. Using a seed file to bring in more randomess could help here. Most OS-systems use a combination of randomness like CPU temp, time, HDD temp, HDD head locations etc to generate something true random. I don't know if this the same case when a GPU is used. So in a restart, if you are using -s, I would advice to use a different file each time you restart. |
|
|
|
MobileCash (MBL) has been added as a merge mined coin on the Lyra2REv2 ports. It has yet to hit an exchange so if you want to keep your share, you need to set your MBL address in your settings.
Cheers!
If tried to update my settings with a MBL address, but since my default settings are NXT based, the sign message procedure to add this wallet to my account is not available. The procedure mentions a NXT-QT client, that as far as I know is not available and in the standard web-based client I cannot find a sign message function. Please advice. |
|
|
|
OP, plz consider adding Lyra2REv2 algo (at least VTC and MONA)
The wrong lyra2 was added. It needs to be lyra2v2 (lyra2REv2). Look at the pool page. All coins are lyra2rev2: MONA, VTC... And the number of found coins is still 0. I tried both settings Lyra2RE and Lyra2REv2, and only with the Lyra2RE setting blocks got accepted. The protocol does not match the listed coins. |
|
|
|
|
It's a pity there is no 'real' pool that rewards the common effort.
Most of the third party generation is a rat race where the first find is rewarded.
This could relative easy be setup in a three stage approach.
1 - Client delivers a public key and a wanted prefix to the pool.
2 - Pool adds or multiplies their own private key and generates a new public key.
3 - Workers are now hashing with this new pool public key, and results are send back to the pool.
(intermediate results to generate shares are needed here)
2 - Pool combines his private key with the found private key, provides proof of work to client and collects reward.
1 - Clients takes the combined private key, combines it with it's own private key.
All miners can now be payed by share ratio.
|
|
|
|
Can I generate a vanity address with my spare Antminer S3+ ? Because I want an address like this :
"1InDiaNaCoINBTC...."
Short answer is no. The ASIC based miners only support the SHA and or Scrypt algorithms. But 80% of the processing time for vanitycoins is related to the ECSDA calculations, and there is also a RIMD hashing involved. These last two protocols are not supported by the ASIC's. You would need GPU hashing for this one, and looking at the length of your prefix.... a lot of time. each char is roughly a multiple of 60; in your case you might need to run the program for 60^14/hashingspeed seconds. Even when hashing 10GH/s that would take 25 million years.... give or take... |
|
|
|
I had to add to the conf file for solo mining. The default value for a minimum transaction (0.01 IFC) is lower than the block reward, so the block reward did not show up in the wallet during mining. Took me some time to find out, any idea what happens to the block rewards of the found blocks that were blocked by this low threshold setting of the wallet? |
|
|
|
|
