path: root/82/a0ba614fe4fe2323083f0d5c333d0bce24957c

Return-Path: <info@AndySchroder.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id C253992
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 22 Jun 2016 15:12:08 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from uschroder.com (uschroder.com [74.142.93.202])
	by smtp1.linuxfoundation.org (Postfix) with ESMTP id 46E8F1B7
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 22 Jun 2016 15:12:07 +0000 (UTC)
Received: from [192.168.253.4] (cpe-96-28-21-149.kya.res.rr.com [96.28.21.149])
	by uschroder.com (Postfix) with ESMTPSA id 3341F233B2296;
	Wed, 22 Jun 2016 11:12:06 -0400 (EDT)
To: Erik Aronesty <erik@q32.com>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
	Thomas Voegtlin <thomasv@electrum.org>
References: <CAJowKg+zYtUnHv+ea--srehVa5K46sjpWbHVcVGRY5x0w5XRTQ@mail.gmail.com>
	<576A44F1.9050108@electrum.org>
	<CAJowKgLTtPKCV_6YWdTU2DiF0CAAiouggfGYVA+cax0Fyzc9Mg@mail.gmail.com>
From: Andy Schroder <info@AndySchroder.com>
Openpgp: id=893F9F58D7AECF9DF0F772F534FAEFDB2D44186B;
	url=http://andyschroder.com/static/AndySchroder.asc
Message-ID: <576AAAC4.1020304@AndySchroder.com>
Date: Wed, 22 Jun 2016 11:12:04 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
	Thunderbird/38.8.0
MIME-Version: 1.0
In-Reply-To: <CAJowKgLTtPKCV_6YWdTU2DiF0CAAiouggfGYVA+cax0Fyzc9Mg@mail.gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature";
	boundary="F87xTMvHj7to8En5S53RDPbqTXstC94Wg"
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,HTML_MESSAGE
	autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
X-Mailman-Approved-At: Wed, 22 Jun 2016 19:33:43 +0000
Subject: Re: [bitcoin-dev] Even more proposed BIP extensions to BIP 0070
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Wed, 22 Jun 2016 15:12:08 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--F87xTMvHj7to8En5S53RDPbqTXstC94Wg
Content-Type: multipart/mixed; boundary="eWq69pWhwntMC9qbMUAMQ42EQONbUWUPE"
From: Andy Schroder <info@AndySchroder.com>
To: Erik Aronesty <erik@q32.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
 Thomas Voegtlin <thomasv@electrum.org>
Message-ID: <576AAAC4.1020304@AndySchroder.com>
Subject: Re: Even more proposed BIP extensions to BIP 0070
References: <CAJowKg+zYtUnHv+ea--srehVa5K46sjpWbHVcVGRY5x0w5XRTQ@mail.gmail.com>
 <576A44F1.9050108@electrum.org>
 <CAJowKgLTtPKCV_6YWdTU2DiF0CAAiouggfGYVA+cax0Fyzc9Mg@mail.gmail.com>
In-Reply-To: <CAJowKgLTtPKCV_6YWdTU2DiF0CAAiouggfGYVA+cax0Fyzc9Mg@mail.gmail.com>

--eWq69pWhwntMC9qbMUAMQ42EQONbUWUPE
Content-Type: multipart/alternative;
 boundary="------------020104060409070205030709"

This is a multi-part message in MIME format.
--------------020104060409070205030709
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable




>
>     Only large merchants are able to maintain such an infrastructure;
>     (even
>     Coinbase recently failed at it, they forgot to update their
>     certificate). For end users that is completely unpractical.
>
>
> Payment protocol is for when you buy stuff from purse.io=20
> <http://purse.io>, not really needed for face-to face transfers, end=20
> users, IMO.



I disagree with your statements. There are many face to face use cases=20
where the payment protocol is essential. Pretty much anything where the=20
payee's hardware device that the payer interacts with is automated in=20
public and/or operated or accessible by untrusted employees. In any of=20
those cases the software on the payee's hardware device can be modified. =

Providing a signed payment request gives the payer additional confidence =

that they are paying the correct person.

See some examples here: http://andyschroder.com/BitcoinFluidDispenser/2.3=
/


There was a secure bluetooth protocol that Andreas Schildbach and Eric=20
Voskuil and I were working on, but we never pulled it all the way=20
together. This would also need a two way exchange for a face to face=20
payment. This could be used without using some sort of key/certificate=20
verification service if being done between two humans who are the direct =

senders and receivers of the payment and are using hardware that they=20
personally own (not necessarily the case of untrusted employees or=20
public vulnerable machines).




>     The same benefit can be achieved without the complexity of BIP70, b=
y
>     extending the Bitcoin URI scheme. The requestor is authenticated us=
ing
>     DNSSEC, and the payment request is signed using an EC private key. =
A
>     domain name and an EC signature are short enough to fit in a
>     Bitcoin URI
>     and to be shared by QR code or SMS text.
>
>      bitcoin:address?amount=3Dxx&message=3Dyyy&name=3Djohn.example.com
>     <http://john.example.com>&sig=3Dzzz
>
>
> I agree.  A TXT record at that name could contain the pubkey.


Did you not see my previous message about the size of the bitcoin: URI=20
getting too big for NFC and QR codes? Do you not care about giving the=20
payer the option of using multiple destination payment addresses? This=20
is important for many reasons.


>     That extension is sufficient to provide authenticated requests,
>     without
>     requiring a https server. The signed data can be serialized from th=
e
>     URI, and DNSSEC verification succeeds without requesting extra
>     data from
>     the requestor. The only assumption is that the verifier is able to
>     make
>     DNS requests.
>
>
> The problem is that there's no way for a merchant to /refuse /a=20
> payment without a direct communication with the merchant's server.   =20
> Verify first / clear later is the rule.   Check stock, ensure you can=20
> deliver, and clear the payment on the way out the door.

So, are you saying first the payer should send an unsigned transaction=20
for review, and then once the payee has agreed it's good, they can send=20
an ACK message back and then wait for the signed version? I don't think=20
this is a bad option to have. Many wallets simultaneously broadcast a=20
signed transaction to their peers and and also back to the payee via=20
https or bluetooth. So, you'd have to add another step to do the=20
unsigned transaction review in order to avoid a transaction being=20
accidentally broadcast that both parties don't like.


>
> Also, as a merchant processing monthly subscriptions, you don't want=20
> the first time you hear about a user's payment to be /after /it hits=20
> the blockchain.  You could add a refund address to deal with it after=20
> the fact... stuff a refund address int OP_RETURN somehow?
>
> bitcoin:address?amount=3Dxx&currency=3Dccc&message=3Dyyy&name=3Djohn.ex=
ample.com=20
> <http://john.example.com>&offset=3D3d&interval=3D1m&sig=3Dzzz

Again, my comments above about issues with using bitcoin: URI for=20
everything. Also, why do you want to bloat the blockchain with=20
unnecessary refund transaction data?



--------------020104060409070205030709
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<html>
  <head>
    <meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Ty=
pe">
  </head>
  <body text=3D"#000000" bgcolor=3D"#FFFFFF">
    <div class=3D"moz-cite-prefix"><br>
      <br>
      <br>
    </div>
    <blockquote
cite=3D"mid:CAJowKgLTtPKCV_6YWdTU2DiF0CAAiouggfGYVA+cax0Fyzc9Mg@mail.gmai=
l.com"
      type=3D"cite">
      <div dir=3D"ltr"><br>
        <div class=3D"gmail_extra">
          <div class=3D"gmail_quote">
            <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px=

              0.8ex;border-left:1px solid
              rgb(204,204,204);padding-left:1ex">
              Only large merchants are able to maintain such an
              infrastructure; (even<br>
              Coinbase recently failed at it, they forgot to update
              their<br>
              certificate). For end users that is completely
              unpractical.<br>
            </blockquote>
            <div><br>
            </div>
            <div>Payment protocol is for when you buy stuff from <a
                moz-do-not-send=3D"true" href=3D"http://purse.io">purse.i=
o</a>,
              not really needed for face-to face transfers, end users,
              IMO.<br>
            </div>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
    <br>
    <br>
    I disagree with your statements. There are many face to face use
    cases where the payment protocol is essential. Pretty much anything
    where the payee's hardware device that the payer interacts with is
    automated in public and/or operated or accessible by untrusted
    employees. In any of those cases the software on the payee's
    hardware device can be modified. Providing a signed payment request
    gives the payer additional confidence that they are paying the
    correct person.<br>
    <br>
    See some examples here:
    <a class=3D"moz-txt-link-freetext" href=3D"http://andyschroder.com/Bi=
tcoinFluidDispenser/2.3/">http://andyschroder.com/BitcoinFluidDispenser/2=
=2E3/</a><br>
    <br>
    <br>
    There was a secure bluetooth protocol that Andreas Schildbach and
    Eric Voskuil and I were working on, but we never pulled it all the
    way together. This would also need a two way exchange for a face to
    face payment. This could be used without using some sort of
    key/certificate verification service if being done between two
    humans who are the direct senders and receivers of the payment and
    are using hardware that they personally own (not necessarily the
    case of untrusted employees or public vulnerable machines).<br>
    <br>
    <br>
    <br>
    <br>
    <blockquote
cite=3D"mid:CAJowKgLTtPKCV_6YWdTU2DiF0CAAiouggfGYVA+cax0Fyzc9Mg@mail.gmai=
l.com"
      type=3D"cite">
      <div dir=3D"ltr">
        <div class=3D"gmail_extra">
          <div class=3D"gmail_quote">
            <div>=C2=A0</div>
            <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px=

              0.8ex;border-left:1px solid
              rgb(204,204,204);padding-left:1ex">
              The same benefit can be achieved without the complexity of
              BIP70, by<br>
              extending the Bitcoin URI scheme. The requestor is
              authenticated using<br>
              DNSSEC, and the payment request is signed using an EC
              private key. A<br>
              domain name and an EC signature are short enough to fit in
              a Bitcoin URI<br>
              and to be shared by QR code or SMS text.<br>
              <br>
              =C2=A0<a class=3D"moz-txt-link-freetext" href=3D"bitcoin:ad=
dress?amount=3Dxx&amp;message=3Dyyy&amp;name=3D">bitcoin:address?amount=3D=
xx&amp;message=3Dyyy&amp;name=3D</a><a
                moz-do-not-send=3D"true" href=3D"http://john.example.com"=

                rel=3D"noreferrer" target=3D"_blank">john.example.com</a>=
&amp;sig=3Dzzz<br>
            </blockquote>
            <div><br>
            </div>
            <div>I agree.=C2=A0 A TXT record at that name could contain t=
he
              pubkey.=C2=A0=C2=A0 <br>
            </div>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
    <br>
    Did you not see my previous message about the size of the bitcoin:
    URI getting too big for NFC and QR codes? Do you not care about
    giving the payer the option of using multiple destination payment
    addresses? This is important for many reasons.<br>
    <br>
    <br>
    <blockquote
cite=3D"mid:CAJowKgLTtPKCV_6YWdTU2DiF0CAAiouggfGYVA+cax0Fyzc9Mg@mail.gmai=
l.com"
      type=3D"cite">
      <div dir=3D"ltr">
        <div class=3D"gmail_extra">
          <div class=3D"gmail_quote">
            <div>=C2=A0</div>
            <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px=

              0.8ex;border-left:1px solid
              rgb(204,204,204);padding-left:1ex">
              That extension is sufficient to provide authenticated
              requests, without<br>
              requiring a https server. The signed data can be
              serialized from the<br>
              URI, and DNSSEC verification succeeds without requesting
              extra data from<br>
              the requestor. The only assumption is that the verifier is
              able to make<br>
              DNS requests.<br>
            </blockquote>
            <div><br>
            </div>
            The problem is that there's no way for a merchant to <i>refus=
e
            </i>a payment without a direct communication with the
            merchant's server.=C2=A0=C2=A0=C2=A0 Verify first / clear lat=
er is the
            rule.=C2=A0=C2=A0 Check stock, ensure you can deliver, and cl=
ear the
            payment on the way out the door.=C2=A0=C2=A0 <br>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
    So, are you saying first the payer should send an unsigned
    transaction for review, and then once the payee has agreed it's
    good, they can send an ACK message back and then wait for the signed
    version? I don't think this is a bad option to have. Many wallets
    simultaneously broadcast a signed transaction to their peers and and
    also back to the payee via https or bluetooth. So, you'd have to add
    another step to do the unsigned transaction review in order to avoid
    a transaction being accidentally broadcast that both parties don't
    like.<br>
    <br>
    <br>
    <blockquote
cite=3D"mid:CAJowKgLTtPKCV_6YWdTU2DiF0CAAiouggfGYVA+cax0Fyzc9Mg@mail.gmai=
l.com"
      type=3D"cite">
      <div dir=3D"ltr">
        <div class=3D"gmail_extra">
          <div class=3D"gmail_quote"><br>
            Also, as a merchant processing monthly subscriptions, you
            don't want the first time you hear about a user's payment to
            be <i>after </i>it hits the blockchain.=C2=A0 You could add a=

            refund address to deal with it after the fact... stuff a
            refund address int OP_RETURN somehow?<br>
            <br>
          </div>
          <div class=3D"gmail_quote">
            <div><a class=3D"moz-txt-link-freetext" href=3D"bitcoin:addre=
ss?amount=3Dxx&amp;currency=3Dccc&amp;message=3Dyyy&amp;name=3D">bitcoin:=
address?amount=3Dxx&amp;currency=3Dccc&amp;message=3Dyyy&amp;name=3D</a><=
a
                moz-do-not-send=3D"true" href=3D"http://john.example.com"=

                rel=3D"noreferrer" target=3D"_blank">john.example.com</a>=
&amp;offset=3D3d&amp;interval=3D1m&amp;sig=3Dzzz<br>
            </div>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
    Again, my comments above about issues with using bitcoin: URI for
    everything. Also, why do you want to bloat the blockchain with
    unnecessary refund transaction data?<br>
    <br>
    <br>
  </body>
</html>

--------------020104060409070205030709--

--eWq69pWhwntMC9qbMUAMQ42EQONbUWUPE--

--F87xTMvHj7to8En5S53RDPbqTXstC94Wg
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iQEcBAEBAgAGBQJXaqrEAAoJEDT679stRBhr/MoIANZ0BJsy7meoWgCa/mr/0tEC
VNJOiDvSOQRuLt2G6K1QynSzGfNaeB41Sjfi9wzd0SKRWFvojFbnE9m0st/uoVOC
X4sAHW4paCL6NGd5UnYzi2PgJAh30aTEIt8PeXEX4XjhHKOHJYs1jHiPCBF27BNz
dfsABIJpsCmR401VeRSLD5WcXvFfEeSjedww4h8mksQmrouzbQtNOAWXbotur7iz
O9nArey5lEQGsl4JO0ypgwsSFMHpcdvHpdIH4kI8dzKbmbmvZvP8WYipwaMwHQml
V/Lp7BdJBPyMiDeBu2M/sGrqtuZuHomPRACeX7cWDvs9Rj19oaDlvMp/9mq9etM=
=0tZz
-----END PGP SIGNATURE-----

--F87xTMvHj7to8En5S53RDPbqTXstC94Wg--