Generator of personalized addresses for TON blockchain

[mcnckc]

Summary

User's public address is a random, meaningless string of characters. It is possible to make it not entirely random, but partly personalized, and we propose the software with such functionality

Context

The software is going to be distributed in a form of an executable file, working as a command line utility, due to a very simple functionality. Software is designed to give the user a real TON address matching user's constraints, along with private data, allowing to sign transactions for this address.

User can constrain the appearance of the start or the end of the address, or both. For each character user may leave one or more options.
For example user can constrain the end of the address to be exactly _123456, possible result is: UQCF1NqCCBCUaDsmm1fC51wMpV0vwt3loKf997ArRtJ_123456

Or constrain the start of the address to be exactly APPLE:
UQAPPLE4APeEfnGAbTIbXYGALf0rp9ALm5iJuFvddzg-6A0I

It will be possible to add several variants of constraints, to search for any of them.

Process of searching for an address takes some time, so the main focus in development is on performance in searching speed, to reduce this time. There will be two versions of software, one performs search on a CPU and works everywhere. The second one is for NVIDIA GPU-enabled systems, with increased performance.

In short, realistic number of single-option characters will be 7-8. Here is the table of claimed performance. Note that time reduces, if the user leaves more than one option for a character, or provides several constraint variants. Lower numbers of characters are a matter of seconds for any hardware.

	5 characters	6 characters	7 characters	8 characters
Intel Core i5-8350U(4C, 8T) (low-end CPU)	4 min 20 sec	4 h 40 min	12,5 days	> 2 years
AMD Ryzen 5 3600(6C, 12T) (budget CPU)	26 sec	30 min	31 h 30 min	84 days
NVIDIA GTX 1650 SUPER (cheapest GPU)	2 sec	2 min	2 hours	5,5 days
NVIDIA RTX 4090 (most expensive home GPU)	0 sec	13 sec	13,5 min	14,5 hours

And it is possible to achieve more characters, ignoring character case, allowing 0 instead of O, and other tricks.

To sum up, this tool allows user to have a personalized address in TON mainnet, for aesthetic purposes or for fun. Personalization is always a good opportunity.
Having a personalized address can be compared to owning an NFT, or more precisely a SBT, because it is hard to sell an ownership of an address. But unlike with NFTs, a valuable entity is embedded in the address itself, and not stored somewhere in the blockchain.

Main advantage of our particular tool is a decent performance.

Maybe some services for custodial storage can implement ideas from our software, or even take it as is, to add a feature of address personalization to their products, because on the server side they have much more computing power, than a typical user on his home PC.

References

We don't know about tools with similar functionality and comparable performance. We are not aware of such tools for other blockchains either.

Estimate suggested reward

$800-$4000

[novusnota]

See https://github.com/ton-community/vanity-contract

[mcnckc]

Thank you for a reference! This project solves similar problem, however we see many advantages of our project in comparsion with this one, so I still ask @delovoyhomie to review our proposal

Performance

Our miner is significantly faster.
On a GTX 1650 SUPER it gives 600 MH/s, while vanity-contract miner gives around 172 MH/s.

Flexibility

In vanity contract, only option is to find address, with suffix exactly matching specified string. Our constraints are much more flexible: you can also constrain beginning of address, you can add individual options for each character, add several address variants. In example, but not limited to, this allows to ignore character cases, allows to find 0 instead of o, and some other hacks to make mining even faster, the same applies to several address variants.

User-friendliness

As for our project user only has to:
Download our executable file, run it, follow instructions, and then use received mnemonic for standard WalletV3R2 deployment and usage procedures.

Here's what user has to perform, using vanity contract:

• User has to install python, and has to be familiar with python package managers, to install some (probably) missing packages like pyopencl
• For some reason on Windows it is impossible to abort the miner with Ctrl+C, Ctrl+D, or other abortion command known to us, only option is to close the window, which we didn't find convenient
• After mining, user has to manually deploy non-standard contract. Only tool vanity contract provides is a code example, which obviously requires some knowledge and skills to be able to use it
  • User has to have some minimal understanding about programming, because user has to edit and run program code
  • User has to be familiar with JavaScript, to understand what language the provided code even is. User has to know how to run JavaScript
  • import { Address, beginCell, Cell } from 'ton'; - user has to be familiar with TON ecosystem, to know what is 'ton' - it is actually a JS library, and nothing in vanity project's readme links to it. User is expected to (somehow) find this library and install with JS package manager
  • User has to be ready to troubleshoot running the script. It may be our fault, but we ran into a problem, running the script in a straightforward way. Anyway, mistakes can be made by user, when running the script
  • User has to understand what happens in this part, and edit it accordingly. It requires knowledge about how things work in TON, what is contract, where to find it's code, and clear understanding what user is doing
• User has to have some basic knowledge about TON protocol, just to understand the concept of vanity-contract, to understand that standard wallets are contracts, to understand why now user has 2 contracts, what is the relation between them, what deployment means, and how user's wallet will function from now
• Also our solution shows expected mining progress and remaining time to a user, while vanity contract's miner doesn't. Progress is constantly updated, unlike in vanity contract

We think that usage of vanity contract is complicated and not user-friendly, and requires some amount of knowledge and skills, while our approach requires nothing

Simplicity

Our project finds an address for a standard wallet, and that's it. The approach of vanity contract is kinda hacky, it creates an extra contract, which's address can be used to receive funds - but the user's main address of a wallet, where the user stores his funds, maybe has some NFTs or SBTs, remains completely random. We think that our concept is closer to actually owning a customized address, and is much simpler, not only for an address owner, but also for a users whom owner may want to show his address

Summary

Considering aforementioned advantages, we think that our solution to address personalization is better than vanity contract, and can be a good replacement/addition to vanity contract project

[delovoyhomie]

Thank you for submitting your proposal. While the miner you propose demonstrates superior speed, the existing vanity-contract miner offers greater flexibility, enabling users to create custom scripts for generating virtually any address.

Although your solution simplifies the process and makes it more accessible for users who may lack the technical expertise to modify the vanity-contract, we believe this flexibility addresses the broader needs of the community. As such, we regret to inform you that we are unable to provide financial support for this project at this time.

We appreciate your efforts and encourage you to continue exploring innovative solutions for the ecosystem. Looking forward to see your new ideas and projects!

[mcnckc]

Actually, our project is already finished, for those who found it interesting, here is our github. We would be glad if ton-society could find opportunities to reward us even with a small amount of funds.

We also disagree, that vanity-contract provides greater flexibility, here is description of address constraints we allow - actually they allow to describe any subset of addresses:

It is easy to see, that any subset of addresses can be described, because user can add several options with |.
For some crazy address subsets, user will need too many variants, but the 'script' for vanity-contract miner will be unfeasibly large either!

In vanity contract, constraints are provided as a list of boolean conditions inside an if statement - it is not an arbitrary script.
Can someone provide us with example of subset of addresses, which can be easily scripted inside an if statement, but takes a very large number of variants in our constraints? If there are no such examples, it proves that vanity contract miner doesn't have advantage in flexibility.