I get that, but what I'm saying is that there's no factual difference.
I know there is no factual difference. I am just looking for a way to force vanity gen to work with overlapping patterns as if they were "unique" patterns. (meaning, vanitygen will not compare patterns with eachother and get rid of overlapping patterns, and will always print out the resulting privkey etc) That would be the easiest solution for what I am trying to achieve: Pass an array of strings to vanity gen thread, and getting results back over time on EVERY item in the array. |
|
|
|
The reason it's skipping them is reasonable, though. If you're looking for any address starting with '1ad' in the first place, then what makes '1adfg' special? '1adfg' will naturally occur in some percentage of all '1ad' results.
Maybe someone wants to periodically update his favorite vanity address by using an increasingly better match over time. Why not. Suppose I'd like to use 1superduper, but since this is going to take ages, I am willing to use 1super for now, while letting vanitygen keep on working on subsequent larger patterns like 1superd 1superdu 1superdup etc... And whenever one of those is found, I can atleast use the intermediate result, and getting closer and closer to the ultimate goal. |
|
|
|
Thanks guys. I am working on an in-wallet vanity gen, using this codebase. I just want to let the user pass any valid patterns he wants to the vanity gen thread, so if he specifically desires to search for two patterns that overlap, then he should be allowed to do so. I have excluded regex from the code, to make it easier and to not require PCRE. So I can't use that. As far as I can see, in this function here (in pattern.cpp), it tells the program to get rid of the overlapping pattern: https://github.com/samr7/vanitygen/blob/master/pattern.c#L1044static vg_prefix_t *vg_prefix_add(avl_root_t *rootp, const char *pattern, BIGNUM *low, BIGNUM *high)
{
vg_prefix_t *vp, *vp2;
assert(BN_cmp(low, high) < 0);
vp = (vg_prefix_t *) malloc(sizeof(*vp));
if (vp) {
avl_item_init(&vp->vp_item);
vp->vp_sibling = NULL;
vp->vp_pattern = pattern;
vp->vp_low = low;
vp->vp_high = high;
vp2 = vg_prefix_avl_insert(rootp, vp);
if (vp2 != NULL) {
fprintf(stderr,
"Prefix '%s' ignored, overlaps '%s'\n",
pattern, vp2->vp_pattern);
vg_prefix_free(vp);
vp = NULL;
}
}
return vp;
} But if I remove the vg_prefix_free(vp);
vp = NULL; it still gets rid of the overlapping pattern, so I assume there is some restricting code elsewhere that I have overlooked. I want the program to keep any valid pattern and work with it, instead of automatically removing overlaps. |
|
|
|
|
I am trying to get rid of the limitation that doesn't allow you to look for patterns that overlap.
For example: I would like to be able to search for 1ad, 1adf, 1adfg,
but it will not let me search for all of them in a row, instead it will say that 1adf and 1adfg "are ignored because they overlap with 1ad"
So how can I fix that? Or am I missing a parameter?
|
|
|
|
Thanks for putting this together. |
|
|
|
At syncing, the download speed is irrelevant, the hard work for the wallet is to process the incoming data (checkblock: verify hash, verify data, etc) Well, I wouldn't say that download speed is irrelevant, but the bottleneck of synching a full node is definitely the CPU. Also, if I am not mistaken (I am not sure how Core does it), a full node will always download a single block, then validate it, then ask and wait for the next block to download, validate again etc... A very serial process. While the CPU is validating, the program isn't allowed to download the next block, for obvious reasons: if the last block is false, all following blocks are also false (wrong fork). But not being allowed to download further blocks is what makes synching even slower. (And vice versa, while the next block is still downloading, the CPU can't validate yet. All those waiting times add to a large delay, especially when you consider hundreds of thousands of blocks.) So is this the best way of doing things? The goal is to have better initial synching speed. It concerns people who download a blockchain from scratch, or need to sync weeks or months of data. It can be argued that syncing could be much faster by downloading a large chunk of the longest available blockchain once (servicenodes will help out), and then do the initial validation process in one sweep, and if there are errors, go back to serial processing as it is done now--> validate and download the rest of the blockchain from the last validated index, block by block. Serial processing is necessary once your wallet is up-to-date (or near up-to-date), and you just need to keep track of the best blockchain available on a per-minute basis. But is it necessary for the initial sync process, that is the question.... |
|
|
|
vanitygen is working with uncompressed addresses. the displayed SieiiXS9E2... address is an uncompressed address, while SSCwYC... address is the compressed (private key is VK39vRX8uy5MwaQ72ySKwV66KXyZDebGct65W3nMg69kgXf3vBL9 ) both have the same private ECDSA key (621CFB6D7AA39D2AD993F39AB560CD1A872DD68D1C22199A7E48B5F96AECE153) you can verify it: http://www.universalwalletgenerator.net/ -> setup custom, public address: 63 Elbandi So I managed to adjust the vanitygen so that it generates compressed addresses by borrowing from this: https://github.com/salfter/vanitygen/commit/7ee7d9b0aa5b3841d17f0be14d2cc00f719b579fAnd it works, it generates compressed SPR privkeys (starting with Letter V instead of 7 (uncompressed). And I check the validity of the privkey on http://www.universalwalletgenerator.net/ (setup with 63,191, and then wallet-details) and it works, it recognizes the correct SPR Vanity address. Problem I still have is, how can I import this address into the wallet? When I do a simple importprivkey it reports an error. Is importprivkey as it is implemented ATM even able to import compressed keys? Doesn't look like it. |
|
|
|
i suspect this might have something to do with it: in spreadcoin // secp256k1: // const unsigned int PRIVATE_KEY_SIZE = 279; // const unsigned int PUBLIC_KEY_SIZE = 33;// const unsigned int SIGNATURE_SIZE = 65; in darkcoin: // secp256k1: // const unsigned int PRIVATE_KEY_SIZE = 279; // const unsigned int PUBLIC_KEY_SIZE = 65;// const unsigned int SIGNATURE_SIZE = 72; // see www.keylength.com // script supports up to 75 for single byte push Now it makes sense why it is only size of 33 with spreadcoin.... ---> it's compressed!  |
|
|
|
So the program gives me a result after a second: Address: SieiiXS9E2Gc22AtmAnzGXFpjGr1VbokaG
Privkey: 7R2PsAdjaJEgBZ34dhRmcuanABeHMzTLrN6EFjmiPT69zXyFUJi But after I import this privkey into my wallet (doesn't matter if it's the old or new wallet).... importprivkey 7R2PsAdjaJEgBZ34dhRmcuanABeHMzTLrN6EFjmiPT69zXyFUJi SOMELABEL false ....it does import the privkey alright, but it's from a totally different address: SSCwYCKryr2gSLxuyDaCxCRGtangqxLfSi vanitygen is working with uncompressed addresses. the displayed SieiiXS9E2... address is an uncompressed address, while SSCwYC... address is the compressed (private key is VK39vRX8uy5MwaQ72ySKwV66KXyZDebGct65W3nMg69kgXf3vBL9 ) both have the same private ECDSA key (621CFB6D7AA39D2AD993F39AB560CD1A872DD68D1C22199A7E48B5F96AECE153) you can verify it: http://www.universalwalletgenerator.net/ -> setup custom, public address: 63 Elbandi what is the use of a vanity address? ... i mean - that really doesnt have any real bearing on spr itself and the project as a whole does it? ... or am i missing something obvious here? ... #crysx Thanks to elbandi for explaining this. That's the reason I do the vanitygen, it forces me to explore everything about spreadcoin step by step. |
|
|
|
Has anyone tried elbandi's vanitygen out? I've compiled it on ubuntu and it seems to have a bug. Here's what happens: for example I let it search for a Vanity address that starts with Sie......... So the program gives me a result after a second: Address: SieiiXS9E2Gc22AtmAnzGXFpjGr1VbokaG
Privkey: 7R2PsAdjaJEgBZ34dhRmcuanABeHMzTLrN6EFjmiPT69zXyFUJi But after I import this privkey into my wallet (doesn't matter if it's the old or new wallet).... importprivkey 7R2PsAdjaJEgBZ34dhRmcuanABeHMzTLrN6EFjmiPT69zXyFUJi SOMELABEL false ....it does import the privkey alright, but it's from a totally different address: SSCwYCKryr2gSLxuyDaCxCRGtangqxLfSi Can someone confirm this? Linux-Building of vanitygen is very easy. Just follow these steps: sudo apt-get install libpcre3-dev git clone https://github.com/spreadcoin/vanitygen go to vanitygen folder: Build Vanitygen: Start Vanitygen: This will search for a vanityaddress that starts with "Sexy". (or whatever rocks your boat. Remember there is this limitation of the second character as I mentioned a post earlier. It will NOT let you search for S pread.) After it outputs the privkey, copypaste it into your wallet, and import it. Give it a LABEL so that you can recognize it immediately in your address list: importprivkey PRIVKEY SOMELABEL false After it has been imported, check your address list and compare the SPR address. I am afraid it is from a totally different SPR address. So something is wrong with this vanitygen: https://github.com/spreadcoin/vanitygenMaybe elbandi can take a look at it while I continue my work on my in-wallet-implementation... BTW, I tested vanitygen for Litecoin and Bitcoin addresses (by adjusting the code) and they work 100% and can be imported correctly. There seems to be something special about SPR in this regard, something that I am missing. Any ideas? |
|
|
|
Hey Georgem, got an ETA on the release of that sexy new wallet?  I can't wait fo dat shyt boi. Is coo.It is going to be so awesome, I really like it. I'd like to know how you change the wallet layout. Is it a text editing thing or is there a GUI? Well, the longer I work on every aspect of the wallet, the more mysterious things I uncover. It takes time man. For example: did you know that you will not find any SPR address that starts with S and whose second character is one of these: m,n,o,p,q,r,s,t,u,w,x,y,z,1,2,3,4,5,6,7,8,9 I dare you to find one. Those characters are ofcourse allowed after the second character, but not as second character. e.g. you will not find any SPR address that starts with Sm.... or St.... you will ofcourse find SM... and ST.... (capital letters) As far as I know, bitcoin doesn't have this limitation. Sadly, this does limit a little bit the appearance of our SPR Vanity addresses, but only the second char. Well, Everyday something keeps blowing me away! Going deeper down the rabbit hole... Stay tuned! |
|
|
|
So we need to run bitcoin core and bitcoin xt, just in case or gavin andresen will be put in an asylum, whatever happens first. Changing coin protocol that late is a big NO NO! |
|
|
|
in the long run im thinking that we need a kind of API and a extra layer for communications between nodes, and services, then it would be possible to implement whatever services people would want, and the node owners could pick whatever extra services they would like to run.... but alas, this is in the future
I was thinking along the same lines. First we need to create fix hardcoded services so that we can gather experience and knowledge, and get the project started. (full node service, decentralized messaging, decentralized domain service maybe?, decentralized search engine, github, forum, etc, etc,...) But while we are doing that, keep in mind that the end goal would always be to create an environment that is capable to run one last service that allows you to create your own services, in a modular way. This final service will then also replace all previous services because they can now be emulated. Something like this music program I use, that lets you create your own synthesizers thru a modular node-based system, where you are allowed to connect all kinds of moduls thru signals and slots.  Something like that but with crypto related moduls and dependencies ---> revolution!!! |
|
|
|
Once the wallet is out (Due any time now) georgem can start working on releasing SN's to testnet.
And I get very useful help by CHAOSiTEC. Within 1 week we will have a new more practical wallet ready to house servicenode maintenance.
Within 3 weeks servicenodes will be in testnet, with a 75% chance the current devteam can actually pull off a successful test and subsequent realese of SN's to mainnet.
Good estimation. I am not good at estimating those things, all I can guarantee is that I am doing a thorough job. After the new wallet is out, it is like a proof that I have good knowledge in Qt-Programming. For what it's worth, with every step I will want to prove that I have unlocked the next power level.  lol |
|
|
|
Very large and frequent Net Hashrate fluctuations over the last few days: New wallet will let you observe this closely:  Based on past observations I'd say net hashrate will be at 1 GH/s in a few hours. |
|
|
|
How's masternodes doing?
I want to know this too. I just picked up 400 spr for 0.02 btc, What a bargain! Anyway, I know georgem is working on a new wallet update, but I am unsure if he is also going to release a masternode testing wallet. I will, but not at the same time, first the new wallet. I'm very close. Don't let the price discourage you, it's volume you should look at. Patience will pay off, I am doing a thorough job, so it takes longer than I anticipated. |
|
|
|
Seems like BCT is back?
Everybody, don't forget to create new passwords.
I changed my password when it was back before you posted this but it looks like Theymos reset the forum so now my posts are gone and my password is not changed like it used to be. good to know, then better change the password once more. |
|
|
|
A few impressions about the new wallet:   Main new layout features: - Main Categories and SubCategories (Wallet, Mining, etc...)
- Constantly visible Header (with information about amount of SPR in your wallet and Recent Notifications)
- Very similar design between Windows, Mac and Linux.(Using a design template with little differences between systems)
- New Splashscreen
- New OverView Screen (Welcoming Screen). To be discussed what we want to put there. (Maybe general information and reminders --> "you haven't made a backup in the last 10 days", etc...)
Main technical features: - VanityAddress-Generator
- Additional Graph NetHashRate in Mining Info Screen
- New DNS Seeder + Full Nodes embedded
Will be ready very soon. Stay tuned. |
|
|
|
|
Seems like BCT is back?
Everybody, don't forget to create new passwords.
|
|
|
|
|
Show Posts
