xGov-100 - GPU-based vanity address generator for Algorand

if ppl here can’t see why the GPU will be better, then they shouldnt be talking crypto just sayin, you have my support drag! id 100% use this tool

1 Like

See also Generating Vanity Addresses - #5 by mmorselli
We are “almost there”.

1 Like

This post was my inspiration for the vanity generator and I’m using a modified kernel, licensed by the iIIusi0n there.

Please cast your votes in the poll in the first message here xGov-100 - GPU-based vanity address generator for Algorand

There are so many already existing generators, do we really need another one?
How many people use these, and how often?
How much time in the average users life are you going to save here?

Seems so unimportant for the expansion of the ecosystem…
But a perfect side project if you’re passionate about it… I guess.

1 Like

Hi and thank you for the feedback.

There are so many already existing generators, do we really need another one?

The proposal has stayed to the voting phase because I’ve got positive feedback too. I’m not aware of any other GPU vanity generators for Algorand.

How many people use these, and how often?
How much time in the average users life are you going to save here?

I don’t have any usage data for such tools.

Seems so unimportant for the expansion of the ecosystem…
But a perfect side project if you’re passionate about it… I guess.

This is why we’ve got xgovs. Once proposals go into the voting phase, it’s up to the xgovs to evaluate what’s needed and either vote for it or not. I’m totally fine with whatever xgovs decision is.

What do you think is important for the expansion of the ecosystem?

Absolutely true. Maybe this is more impactful than it seems to me… I just haven’t needed such a tool, and there is no data to validate the idea. I wish you the best of luck on it!

The difference to a CPU-based generator would be getting vanity of 7-8 characters instead of the usual 5-6, and I would absolutely love that. :heart:

It sounds like a small difference, but it’s not, especially when linked to a dictionary to look up interesting addresses instead of searching for a prefix

https://allo.info/account/SILVIOMICALIANDALGORANDWILLRULETHEBLOCKCHAINWORLD222XNHM4I/

this can be done in 2 milliseconds. But beware, it’s a black hole, everything that goes in will never come out again :grin:

This instead is a real example of an (active) wallet with a 9-character vanity, using the dictionary approach

https://allo.info/account/EVILLAUGHQNACOFE6D7CSOEEMKBB7ZXJZSUBA2NVU4KP5UXENP42QYKO2I/

I’m not a fan of this proposal because of the following reasons:

  1. It was open-sourced, but now you closed it and you’re asking for funds to reopen it.

  2. You are “maintaining” the code for 3 months if you receive the funding. What happens after 3 months? Will you close everything down? Will you keep it open source? Or will you ask for another round of funding from AF/xGov?

  3. multiple open-sourced projects do similar things (maybe not to the efficiency of this generator).

  4. The population that will be using this tool will be very small due to its complexity and use case:

    • I don’t think many of us will be mining for 6+ letter vanity wallets.
    • The general public will probably lack the tools or knowledge to set it all up.

I think these things will make sense to add to your proposal even though I’m still doubtful that it’ll add much value to the ecosystem:

  1. Instead of reopening the code and maintaining it for 3 months, build a UI/frontend that lets the community use it without too much complexity.

  2. Release the code as open-source after 3 months of maintenance if you’re shutting down.

  3. Include an actual business model so that there is revenue and not reliant on handouts.

Hi, thank you for the feedback.

  1. I’m asking for funds to deliver the tool described in the proposal and not the prototype you’re mentioning. The prototype distribution was open source (MIT license), I’m no longer distributing it and never been paid to build/distribute. I have detailed the reasoning and mitigation plan if used as a critical component on Vestige Discord - see my latest messages in the #algorand channel there. You can still distribute/use/sell the prototype if you have a copy or can get a copy from anyone.

  2. Yes, I’m maintaining for at least three months. There are not many (if any at all) xGov proposals that include maintenance for their open source. Obviously the maintenance is a cost to me and I can’t promise more for the amount requested at this point. I don’t really see a reason for closing my repos once I’m paid for the delivery. This makes no sense as well as doesn’t really matter. You can copy/fork if you want to as well as keep maintaining it if you like.

The tool is proposed as open source since day one and there’s no point waiting for three months to make it open source.

I’m not asking for funds to build myself a business here. It’s for a tool you or anyone else can use to build a business.

Let me know if you have any questions. Also noted all the other suggestions, thanks for that.

Please vote, see it after the proposal.

Now, at 01-Mar-2024 the vote results are:

What’s the fair ask here (ALGO requested)?

    67%		10k

    17%		0k

    16%		20k

6voters

amount_requested: 47474

There is a “slight” mismatch between requested amount, and vote results.

Yes, the ongoing poll average is lower than the amount requested. Do you have any questions or comments? Would you be able to bring more people to vote please?

I’d be a big fan of this tool, but I don’t think its complexity justifies months of work and too high remuneration, these things take a few days of work

I’m all good with someone else delivering a well performing vanity generator in a few days of work.

It doesn’t mean someone will, but there are many coders here, we know how to evaluate a project’s complexity. Galvanity, a vanity generator written in go, is about 1K lines of code. We are talking about a command-line tool, much of it already available as open source, I think your estimation is a bit exaggerated.

Mine is not a criticism, it’s an advice, a request perceived as exaggerated has 0% chance of being accepted

Thanks but it doesn’t really seem like you’re talking about anything comparable. This Galvanity generator isn’t a GPU generator so that’s a different thing.

I think just give it a day or two then try optimizing to get a better idea on how to evaluate the amount of work required.

For some reason, iIIusi0n’s Ed25519 key generation code using OpenCL has become private

here: https://lib25519.cr.yp.to/