Topic: AliasCoin Proposal: How To Send Money To "Satoshi" Instead of "1TE6a7tvT..." (Read 3905 times)

Why use registrar, instead we can make alias transactions to a specific burn address and if amount per time is greater than previous, alias is replaced. Minimum amount can be set to prevent spam and sybils.

Why not use NameCoin as the registrar.. ?

Yes, an xpub is a public key "seed" that is used to generate a deterministic sequence of public keys.  There is a corresponding xpriv that generates the corresponding deterministic sequence of private keys.  You have the xpriv, you give someone the xpub then they can send you Bitcoins on a periodic basis but use a different public key every time.  Meanwhile you can generate the corresponding private key when needed.

All HD (Hierarchical Deterministic) wallets can do this.  That is what the HD means.  See:

https://en.bitcoin.it/wiki/Deterministic_wallet

Or other links that come up when you Google HD Bitcoin wallets (Trezor is an example).

Yes, I can see how you'd be sensitive to that... good point.

Is 'xpub' a master public key? Am I correct in thinking that if you have someone's master public key you can generate new public keys that will be recognized by their wallet without any difficulty? I'm not familiar with this technique, is it something most wallets can perform?

You know that your address book in your wallet can be labeled any way you want.  You can have an address for "son" and I can have an address for "son" and there is no issue because we have just labeled an address in our own personal wallets.

If you want to fix the address reuse issue all you need to do is get an xpub from your son, label it "son" in your wallet and then every time he needs pizza money you send it to the next public address calculated from the xpub you have labeled "son" in your wallet.

Personally, I see no need to involve a central DNS type authority in this.  If people register with a central authority then the central authority has immediate an undeniable access to your financial records related to that public key or xpub.  This is a bad idea.

Let's say my son is in college and emails me that he needs pizza money. I'd like to reach a point where I can just send a quick transaction to "ebliever.jr" from my wallet rather than having to look up or cross-reference unmemorizable hash strings. The current approach really only works for transactions with businesses that set up expensive and complex front-ends that minimize the complexity to the customer. I'd like a simple solution for non-techies for everyday life, peer-to-peer and without forcing mom-and-pop shops to invest in expensive solutions.

As far as collisions go, that's why a fair amount of my proposal has to deal with registration issues. It's no different than the problems people face with email. Only one person can grab "[email protected]". So we each try to come up with an email address that isn't too miserable but hopefully is easier to recognize and remember, while still being unique. (I'm fortunate in that regard - I've done a fair amount of genealogy research, and I'm pretty sure my first name/surname combo is unique in human history.)

Centralization will be a big topic with any project like this, to be sure. But it's a fact of life in many areas, and it's just a matter of working out the best solution with the best checks on abuse or undesirable outcomes.

I think the address re-use issue can be addressed with a smart contract type setup as I noted earlier, though I haven't thought that through in any detail.

I have seen a couple of these proposals and I always have one shared thought about all of them: I never understand why people even want to have an easily, memorable phrase instead of that scary hash160 string. When you buy something from an online store you never memorize their payment details, you click a button and are redirected to a payment processor and it automatically fills in the data needed for you to make the payment. And nobody is ever scared of seeing that page. So why making a payment with bitcoin which means either clicking a payment link using BIP21 or scanning a QR code. But that's just my thoughts

Other problem that I see here, is being too limited (I believe the word for it is collision):
With bitcoin everyone who is using it has a unique address and will continue having a unique address for years no matter how many millions of people use it and generate new addresses.
In this proposal what happens when I register name "Foo", then 1000 others after me want to register the same name? "Foo.Bar"? "Foo.2"? "Foo.1000"?
There will always be very limited number of proper names to use before we start getting to hard names area. And the main issue you raised in the beginning will show up again. It will be hard to remember "My.Custom.Foo.Bar.Name.That.Is.Unique.To.Me".

Also the "centralization" and the "address reuse" issues that are already mentioned are not small things to overlook.

This does not solve the problem with financial privacy and pseudo-anonymity for me. I guess if you opt for a public name for your account, you are willing to sacrifice your privacy. I for one, feel very strong about Crypto currency users being pseudo-anonymous, BUT I can see some use cases where this might be used. < Branding & Marketting >

It is just a pity that this is being done by our main competitor. ^grrrrrrr^

Yeah, how many stories have we heard about mistaken addresses. I've only done it once, thankfully only because I right-clicked and copied an address just below the intended one in my Electrum wallet list, so I still received it, just not in the address I intended. A solution like this might make that mistake easier to avoid.

I was just thinking this morning that something like an Ethereum smart contract might be capable of issuing unique public keys within the context of an Aliascoin type project. And lo and behold, it appears I'm not the only one thinking along the lines of using aliases in place of public keys:

http://www.coindesk.com/ethereum-name-service-prepares-take-off/

"For example, it will be much easier to do simple things like send ether (the token of the ethereum blockchain) to 'alice.wallet.eth' or pull up content on Swarm (etherum's decentralized storage space) by typing 'alice.swarm.eth', rather than cutting and pasting, or worse having to type, '0x123f681646d4a755815f9cb19e1acc8565a0c2ac'."

Good to see a project like this moving forward, especially if all crypto can take advantage of it.

Well, yeah, that would be pretty centralized and require trust in the issuer. If schemes like mine did not come to fruition though, I could actually see somewhat trusted institutions (by the general public) doing something like that as mainstream acceptance grew. For example, a major bank doing just what you said in return for a micropayment, or as a free service to customers keeping their funds with them. That could be canny marketing.

But let's do something better before it comes to that...

This is where I get out of my depth very quickly. I don't know what is technically possible in terms of being able to quickly search and/or route transactions if the alias used could come from any of a number of blockchains. There is also the question of how to prevent the same alias being used on two blockchains run by two different registrars. The latter issue can probably be resolved through some sort of universally agreed rule of precedence.

I actually own the first bits "1BurtW", pretty cool, still works, you can look it up, etc.  However now everyone knows all of my transactions on that address.  I no longer support address reuse, first bits, or this proposal (unless it solves the address reuse issue).  Ideally all addresses should be used exactly twice:  once to receive BTC and once to be spent.

I also met the guy that invented first bits (FreeMoney).  He moved away from Boulder, does not come here to bitcointalk anymore so I lost touch with him.

Back in the day there was the firstbits project, which aimed to provide a canonical shorter version of bitcoin addresses.  As people decided that you shouldn't be reusing addresses, this fell out of favor.

If you solve all your other issues you are still stuck with this - which is your biggest problem.  This affects Bitcoin at a fundamental level, privacy and fungibility.

If, instead of registering a Bitcoin address, you registered a place to get a Bitcoin address (a URL?) then the entity could hand out new addresses every time the "place to get addresses" was accessed.

Of course this is even further removed from the idea of Bitcoin and has even more security issues/concerns.

I like that already more. Registrars could be voted in a similar way "delegates" are voted in DPOS currencies like Bitshares or Lisk - by a Proof of Stake vote of the "whales" of the sidechain. Or, if it's a merged-mined sidechain, also the miners could have voting power like suggested for a future "Drivechain".

As of the name issue: Couldn't there simply be one single namespace that would have to be used by all registrars? So the additional step probably could be avoided, or am I understanding something wrong?

Just thinking out loud here... a more complicated but more decentralized approach to this alias concept would be to allow for multiple competing registrars in a free market. It would be more complex because your alias would also need to identify which registrar needs to be consulted to look up the corresponding key. For example "John@ABC" for ABC Registrar versus "John@XYZ" for XYZ registrar.

I was hoping to avoid such complications, but it would allow for things like national registrar bodies and/or free market competition. Shady registrars could be blacklisted by various parties, with legal pressure, boycotts and sanctions against them to discourage corruption. So it might be worth it, and might simply be needed to deal with trademark disputes across national boundaries that cannot be otherwise resolved.

Ahh, I see your point now. So a corrupt Registrar could assign a trademarked or otherwise economically valuable alias to themselves or accomplices. Problems with this idea:

1. The governance mechanism I suggest above (Addendum 3) could be used to replace a corrupted Registrar if things got significantly bad.
2. Infringed parties and defrauded parties would rapidly learn of the corrupt actions, and would know that the Registrar was involved either as the instigating party, an accomplice, or responsible through negligence. All three would rapidly put the Registrar in the crosshairs for litigation as well as a governance challenge as noted in #1 above if they didn't correct things ASAP and make amends if anything but negligence was involved.

If they approve registrations, then nothing would stop them from approving an arbitrary entity's registration for an alias that has nothing to do with the entity, including an entity controlled by the registry.

Thanks for the info and comments. I'm fine with moving the thread if that's more appropriate. I agree some won't want anything to do with it and that's fine so long as they don't dedicate themselves to FUDing it.

I've wondered about the likelihood of conflict over trademarks and if there is a current international framework for resolving such disputes. I've been hoping to avoid/minimize the degree to which my proposed Registrar would need sanctioning by governments, but it's probably a safe assumption that it would need to demonstrate a scrupulous and consistent effort to honor existing trademarks or it would itself become a defendant in litigation.

There are probably many forms the Alias concept can be implemented and had how it would be managed with respect to trademarks and disputes. Hopefully the best one can be worked out and implemented so everyone can take advantage.