Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id E434EC9A for ; Tue, 19 Dec 2017 13:11:27 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wr0-f175.google.com (mail-wr0-f175.google.com [209.85.128.175]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 7074F87 for ; Tue, 19 Dec 2017 13:11:26 +0000 (UTC) Received: by mail-wr0-f175.google.com with SMTP id w68so6805581wrc.10 for ; Tue, 19 Dec 2017 05:11:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=ZifdwbVwVwQRpyC6WK7kJtghRSq++qwEEkRK7H0sijE=; b=uXXeX59ogKrI0QeIYF0zB1Yg+MWA6rTMBjPM+BD65nK+zyH6+fX7F9l8j1UNPvuAP0 qmEptOjTi20e2eXbp60wNnRAotQPPLn5LgY44rGrPrIMjqGIBmeEDT5yf0qru7ZysUPa fx8qaMHZ1uLfPG6t4AEGBjUzdEAxwMRKe3DJ1ccmLFkRHtBDm4VN6LTkjhzEE4asALDz wksD2Vl7m5nYOMjLNfFQbUMEZFIzKmw4Iyi+kSXrWfDaPC4TuaucUX9eu27h3KskKrHS o93bFJqIgiZsyHA911/M99bjT6mRJrnX/cBGfef4RuyoIep0hMFuCsrDn5O1Zo3oWLDg cu6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=ZifdwbVwVwQRpyC6WK7kJtghRSq++qwEEkRK7H0sijE=; b=Fr/87S/x92Ui9oqcFvEpJfumWdRpG9bIdTPMOE9YgcpSJtuDP4ZO+5CQTB+wqi/2K1 o0HrEOzbk/xto9JV5LNos0yEM7st9ROblPdLiDCgBziYXOCpP+Isa1JmM4naO3iSgTXv Q+aZPGPRm5uRdv78GFoGcozDVhnhrclTMmxce+WR3gwjz7QlZhciIOG+nbOihKx/IDqR uEUNjXJBU4rCVRdf4XO298//PRYOi0jST3fN9cCjpcIm7CRCqJyeli26qZgPz3ifQ/3a 25VsKDsp0yiFMRWLdznT2dT3YLPWg0z21uukE+3TsR8uacq4Uq0TI2Hj1iVi4p6cDSDz X3Hw== X-Gm-Message-State: AKGB3mLySIe7nTy4TWDCnVmHuWxlv+0A0owocjyzD8zY5c4Qg26CRXWd TVOkT+shHoBshdkq1XWJll3bopw02PdT0JbBvRIusYRW X-Google-Smtp-Source: ACJfBosKSRAixOvT2KMADpaWFaGK8WtwZuRE6OvBeVotuOGtja/5JT/Xrb94hFaDZHEm9JpqE6GsLwlmK0U/WWrmvJ8= X-Received: by 10.223.184.200 with SMTP id c8mr4971229wrg.268.1513689084682; Tue, 19 Dec 2017 05:11:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.188.77 with HTTP; Tue, 19 Dec 2017 05:11:24 -0800 (PST) In-Reply-To: References: <1085B203-DB5E-42AB-A9F3-467D09246314@sprovoost.nl> From: =?UTF-8?Q?Hampus_Sj=C3=B6berg?= Date: Tue, 19 Dec 2017 14:11:24 +0100 Message-ID: To: Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="f403045f4c803164fc0560b134da" X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: Re: [bitcoin-dev] A DNS-like decentralized mapping for wallet addresses? X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Dec 2017 13:11:28 -0000 --f403045f4c803164fc0560b134da Content-Type: text/plain; charset="UTF-8" Most solutions only work with a single Bitcoin address (terrible for privacy, and also potentially a security risk) or xpubkey (also terrible for privacy). I think the best solution here is some kind of store-and-forward server, where you trade a little bit of privacy (to the server, that is), but get the convenience of using (for example) an email address as the account. I like for example BIP75 for this, and I hope the community can work towards a solution like this. This could potentially work good with LN as well. https://github.com/bitcoin/bips/blob/master/bip-0075.mediawiki Hampus 2017-12-19 10:05 GMT+01:00 Damian Williamson via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org>: > There is no reason it should not be easily possible to develop a Bitcoin > wallet that has an integrated name to address mapping feature. It might be > a good idea for a software product, it could even be based on Bitcoin Core. > There is no specific reason that people wanting that sort of feature could > not use it. In fact, you could map names, strings, email addresses, it > could be very flexible. > > > Relying on an additional service like DNS which is flexible enough to > handle the job, does introduce an additional availability risk. There is no > additional privacy risk provided each mapped name or address is only used > once to send/receive one payment unless you directly use something > personally identifiable like an email address which could be used to map > bitcoin addresses to an individual. Personally, I am not concerned about > privacy so much but can understand that some highly value their privacy. > > > If you get it right it will be a service better than namecoin transacting > in Bitcoin. If you think that is valuable, go for it. > > > Regards, > > Damian Williamson > > > ------------------------------ > *From:* bitcoin-dev-bounces@lists.linuxfoundation.org < > bitcoin-dev-bounces@lists.linuxfoundation.org> on behalf of Sjors > Provoost via bitcoin-dev > *Sent:* Monday, 18 December 2017 10:26 PM > *To:* Douglas Roark; Bitcoin Protocol Discussion > *Subject:* Re: [bitcoin-dev] A DNS-like decentralized mapping for wallet > addresses? > > 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 > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > --f403045f4c803164fc0560b134da Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Most solutions only work with a single Bitc= oin address (terrible for privacy, and also potentially a security risk) or= xpubkey (also terrible for privacy).

I think the best solutio= n here is some kind of store-and-forward server, where you trade a little b= it of privacy (to the server, that is), but get the convenience of using (f= or example) an email address as the account.
I like for example BI= P75 for this, and I hope the community can work towards a solution like thi= s. This could potentially work good with LN as well. https://github.com/bit= coin/bips/blob/master/bip-0075.mediawiki

Hampus=

2017-1= 2-19 10:05 GMT+01:00 Damian Williamson via bitcoin-dev &l= t;bitcoin-dev@lists.linuxfoundation.org>:

There is no reason it should not = be easily possible to develop a Bitcoin wallet that has an integrated name = to address mapping feature. It might be a good idea for a software product,= it could even be based on Bitcoin Core. There is no specific reason that people wanting that sort of feature= could not use it. In fact, you could map names, strings, email addresses, = it could be very flexible.


Relying on an additional service = like DNS which is flexible enough to handle the job, does introduce an addi= tional availability risk. There is no additional privacy risk provided each= mapped name or address is only used once to send/receive one payment unless you directly use something persona= lly identifiable like an email address which could be used to map bitcoin a= ddresses to an individual. Personally, I am not concerned about privacy so = much but can understand that some highly value their privacy.


If you get it right it will be a = service better than namecoin transacting in Bitcoin. If you think that is v= aluable, go for it.


Regards,

Damian Williamson



From: = bitcoin-dev-bounces@lists.linuxfoundation.org <bitcoin-dev-bounces@lists.linuxfoundation.org> on behalf of Sj= ors Provoost via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
Sent: Monday, 18 December 2017 10:26 PM
To: Douglas Roark; Bitcoin Protocol Discussion
Subject: Re: [bitcoin-dev] A DNS-like decentralized mapping for wall= et addresses?
=C2=A0
Have you thought about combin= ing 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 transact= ion in BIP-47 and establish a shared secret out of bound. That would simpli= fy things, at the cost of an additional burden of storing more than an HD s= eed 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 <bitco= in-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<= br> >> addresses, maybe there should be a DNS-like decentralized mapping<= br> >> 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 y= ou can
> find the one and only official draft. I worked on a follow-up with som= e
> changes and some nice appendices, explaining some nice tricks one coul= d
> use to make payment management flexible. For various reasons, it never=
> got published. I think it's an interesting draft that could be tur= ned
> into something useful. Among other things, it was able to leverage BIP= 32
> and allow payment requests to be generated that automatically pointed<= br> > payees to the correct branch. DNSSEC may have some issues but, AFAIK,<= br> > it's as the easiest way to bootstrap identity to a common, reasona= bly
> 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


_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.= linuxfoundation.org
https://lists.linuxfoundation.org= /mailman/listinfo/bitcoin-dev


--f403045f4c803164fc0560b134da--