From: Sjors Provoost <sjors@sprovoost.nl>
To: Douglas Roark <joroark@vt.edu>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] A DNS-like decentralized mapping for wallet addresses?
Date: Mon, 18 Dec 2017 12:26:19 +0100 [thread overview]
Message-ID: <1085B203-DB5E-42AB-A9F3-467D09246314@sprovoost.nl> (raw)
In-Reply-To: <c889543b-8dbe-b88c-5f47-7aee1db697aa@vt.edu>
[-- Attachment #1: Type: text/plain, Size: 2147 bytes --]
Have you thought about combining this with BIP-47? You could associate payment codes with email via DNS.
It would be nice if there was a way to get rid of the announcement transaction in BIP-47 and establish a shared secret out of bound. That would simplify things, at the cost of an additional burden of storing more than an HD seed to recover a wallet that received funds this way.
Perhaps the sender can email to the recipient the information they need to retrieve the funds. The (first) transaction could have a time locked refund in it, in case the payment code is stale.
Sjors
> Op 1 dec. 2017, om 04:08 heeft Douglas Roark via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> het volgende geschreven:
>
> On 2017/11/30 14:20, mandar mulherkar via bitcoin-dev wrote:
>> I was wondering in terms of mass adoption, instead of long wallet
>> addresses, maybe there should be a DNS-like decentralized mapping
>> service to provide a user@crypto address?
>
> A few years ago, I was part of an effort with Armory and Verisign to
> make something similar to what you're describing.
> https://tools.ietf.org/html/draft-wiley-paymentassoc-00 is where you can
> find the one and only official draft. I worked on a follow-up with some
> changes and some nice appendices, explaining some nice tricks one could
> use to make payment management flexible. For various reasons, it never
> got published. I think it's an interesting draft that could be turned
> into something useful. Among other things, it was able to leverage BIP32
> and allow payment requests to be generated that automatically pointed
> payees to the correct branch. DNSSEC may have some issues but, AFAIK,
> it's as the easiest way to bootstrap identity to a common, reasonably
> secure standard.
>
> --
> ---
> Douglas Roark
> Cryptocurrency, network security, travel, and art.
> https://onename.com/droark
> joroark@vt.edu
> PGP key ID: 26623924
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2017-12-18 11:26 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-30 22:20 [bitcoin-dev] A DNS-like decentralized mapping for wallet addresses? mandar mulherkar
2017-12-01 0:00 ` Tao Effect
2017-12-01 0:10 ` Justin Newton
2017-12-01 3:08 ` Douglas Roark
2017-12-18 11:26 ` Sjors Provoost [this message]
2017-12-19 9:05 ` Damian Williamson
2017-12-19 13:11 ` Hampus Sjöberg
2017-12-01 3:15 ` Lucas Clemente Vella
2017-12-01 4:17 ` CANNON
2017-12-01 8:24 ` Jérémie Dubois-Lacoste
2017-12-01 4:12 ` CANNON
2017-12-01 11:07 ` Antonis Anastasiadis
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1085B203-DB5E-42AB-A9F3-467D09246314@sprovoost.nl \
--to=sjors@sprovoost.nl \
--cc=bitcoin-dev@lists.linuxfoundation.org \
--cc=joroark@vt.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox