Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WVJri-0000Hq-Bd for bitcoin-development@lists.sourceforge.net; Wed, 02 Apr 2014 12:01:58 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.214.177 as permitted sender) client-ip=209.85.214.177; envelope-from=mh.in.england@gmail.com; helo=mail-ob0-f177.google.com; Received: from mail-ob0-f177.google.com ([209.85.214.177]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1WVJrh-0000hh-7G for bitcoin-development@lists.sourceforge.net; Wed, 02 Apr 2014 12:01:58 +0000 Received: by mail-ob0-f177.google.com with SMTP id wo20so88414obc.8 for ; Wed, 02 Apr 2014 05:01:51 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.182.105.1 with SMTP id gi1mr166537obb.9.1396440111780; Wed, 02 Apr 2014 05:01:51 -0700 (PDT) Sender: mh.in.england@gmail.com Received: by 10.76.71.231 with HTTP; Wed, 2 Apr 2014 05:01:51 -0700 (PDT) In-Reply-To: References: <5339418F.1050800@riseup.net> <51C10069-5C3B-462A-9184-669ABC6CD9D0@meek.io> <8ACA8DF1-30BF-47F4-92CE-E625F44F687C@meek.io> Date: Wed, 2 Apr 2014 14:01:51 +0200 X-Google-Sender-Auth: elEXM-ttvQKpd17Yzcx928pMoQc Message-ID: From: Mike Hearn To: Daryl Banttari Content-Type: multipart/alternative; boundary=e89a8ff1cf66d05fac04f60e0cf6 X-Spam-Score: -0.5 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (mh.in.england[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1WVJrh-0000hh-7G Cc: "bitcoin-development@lists.sourceforge.net" Subject: Re: [Bitcoin-development] secure assigned bitcoin address directory X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Apr 2014 12:01:58 -0000 --e89a8ff1cf66d05fac04f60e0cf6 Content-Type: text/plain; charset=UTF-8 Hi Daryl, I think the reason nobody has done that is that BIP70 isn't really that much work. It's basically just certs inside a protobuf, with a bit of extra data. I'm not sure yet another way to do the same thing is worth much. On Wed, Apr 2, 2014 at 2:59 AM, Daryl Banttari wrote: > Chris, > > Thank you for taking the time to look at my proposal. > > 1) pay to addresses are not fixed - ie you can have a different address >> for each transaction (which is why BIP70 is necessary to allow per >> transaction addresses via https.) >> > > This is certainly true for a "published" address; however a new address > (and URL) can be generated for each one-off peer-to-peer transaction. > However, I'd expect that most of the time this use case will be handed by > BIP70. Still, this could allow someone to implement a authenticated, > non-repudiable payment request without having to go through the hassle of a > full BIP70 implementation. > > >> 2) unless you are already aware of the public key of the signature, you >> do not know if the signature is made by the person you think it is supposed >> to be from. See recent concern over fake key for Gavin Andresen. Ie a >> signature can always be verified with a valid public key, the question is >> was it the real person's key. That is what WoT tried to resolve with >> so-called "signing parties", nowadays keys posted to a public forum by a >> known user, but it's not a standard and not ideal. >> > > My proposal leverages the existing SSL key system (yes, PKI), so there is > a reasonable expectation that if the signature verifies, it came from the > party indicated on the cert. While SSL (and the PKI system underpinning > it) have its faults, the example you highlighted was specifically a problem > with WoT, not PKI. Can a compromised web server cause payments to be made > to the wrong party? Of course-- but that's already true. And that's not > something BIP70 solves (or attempts to solve) either. > > (To explain [better than I could] why I feel PKI is a pragmatic solution, > I defer to Mike Hearn 's article: > https://medium.com/bitcoin-security-functionality/b64cf5912aa7) > > --Daryl > > > ------------------------------------------------------------------------------ > > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > --e89a8ff1cf66d05fac04f60e0cf6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Daryl,

I think the reason nobody has= done that is that BIP70 isn't really that much work. It's basicall= y just certs inside a protobuf, with a bit of extra data. I'm not sure = yet another way to do the same thing is worth much.


On Wed,= Apr 2, 2014 at 2:59 AM, Daryl Banttari <dbanttari@gmail.com> wrote:
= Chris,

Thank you for taking the time to look at my proposal.

1) pay to addresses are not fixed - ie you can have a= different address for each transaction (which is why BIP70 is necessary to= allow per transaction addresses via https.)

This is certainly tr= ue for a "published" address; however a new address (and URL) can= be generated for each one-off peer-to-peer transaction. =C2=A0However, I&#= 39;d expect that most of the time this use case will be handed by BIP70. = =C2=A0Still, this could allow someone to implement a authenticated, non-rep= udiable payment request without having to go through the hassle of a full B= IP70 implementation.
=C2=A0
2) unless you = are already aware of the =C2=A0public key of the signature, you do not know= if the signature is made by the person you think it is supposed to be from= . See recent concern over fake key for Gavin Andresen. Ie a signature can a= lways be verified with a valid public key, the question is was it the real = person's key. That is what WoT tried to resolve with so-called "si= gning parties", nowadays keys posted to a public forum by a known user= , but it's not a standard and not ideal.

My proposal leverages the existing SSL key sys= tem (yes, PKI), so there is a reasonable expectation that if the signature = verifies, it came from the party indicated on the cert. =C2=A0While SSL (an= d the PKI system underpinning it) have its faults, the example you highligh= ted was specifically a problem with WoT, not PKI. =C2=A0Can a compromised w= eb server cause payments to be made to the wrong party? =C2=A0Of course-- b= ut that's already true. =C2=A0And that's not something BIP70 solves= (or attempts to solve) either.

(To explain= [better than I could] why I feel PKI is a pragmatic solution, I defer to M= ike Hearn 's article: =C2=A0https://medium.com/bitcoi= n-security-functionality/b64cf5912aa7)

--Daryl

-----------------------------------------------------------------------= -------

_______________________________________________
Bitcoin-development mailing list
Bitcoin-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment


--e89a8ff1cf66d05fac04f60e0cf6--