path: root/d2/ddb6a07585ddfa373acdb0d15803ce4bdc26d2

Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
	helo=mx.sourceforge.net)
	by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <gavinandresen@gmail.com>) id 1WFr56-00060x-AQ
	for bitcoin-development@lists.sourceforge.net;
	Tue, 18 Feb 2014 20:15:52 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.213.49 as permitted sender)
	client-ip=209.85.213.49; envelope-from=gavinandresen@gmail.com;
	helo=mail-yh0-f49.google.com; 
Received: from mail-yh0-f49.google.com ([209.85.213.49])
	by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1WFr54-0001pw-QS
	for bitcoin-development@lists.sourceforge.net;
	Tue, 18 Feb 2014 20:15:52 +0000
Received: by mail-yh0-f49.google.com with SMTP id t59so15810237yho.22
	for <bitcoin-development@lists.sourceforge.net>;
	Tue, 18 Feb 2014 12:15:45 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.236.120.17 with SMTP id o17mr6014865yhh.121.1392754545293;
	Tue, 18 Feb 2014 12:15:45 -0800 (PST)
Received: by 10.170.133.213 with HTTP; Tue, 18 Feb 2014 12:15:45 -0800 (PST)
In-Reply-To: <5303B110.70603@bitpay.com>
References: <le05ca$qn5$1@ger.gmane.org>
	<5303B110.70603@bitpay.com>
Date: Tue, 18 Feb 2014 15:15:45 -0500
Message-ID: <CABsx9T2Sz+_OubqUpA1LsZxn5sUCN6A2M-BKjrW-sdzh9NK4fg@mail.gmail.com>
From: Gavin Andresen <gavinandresen@gmail.com>
To: "Ryan X. Charles" <ryan@bitpay.com>
Content-Type: multipart/alternative; boundary=20cf3010e96bee7e2404f2b3ef1a
X-Spam-Score: -0.6 (/)
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
	(gavinandresen[at]gmail.com)
	-0.0 SPF_PASS               SPF: sender matches SPF record
	1.0 HTML_MESSAGE           BODY: HTML included in message
	-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
	author's domain
	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: 1WFr54-0001pw-QS
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] BIP70 proposed changes
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Tue, 18 Feb 2014 20:15:52 -0000

--20cf3010e96bee7e2404f2b3ef1a
Content-Type: text/plain; charset=ISO-8859-1

Fantastic feedback, thanks Ryan and Andreas!

Please don't let me being busy get in the way of progress, so submit pull
requests to the BIP (the UTC timezone issue seems obvious and
non-controversial) or write up draft specs for extensions.

RE: wallets checking the status of payment:  excellent idea. A URL that can
be polled to check payment processing status sounds like the right thing to
do.

That feels very similar to the proposal for recurring payments; I think
they would be separate mechanisms, but maybe their specs could share some
of the same concepts / field names....


On Tue, Feb 18, 2014 at 2:14 PM, Ryan X. Charles <ryan@bitpay.com> wrote:

> Here are my complementary thoughts after working on the payment protocol
> on the merchant side at BitPay.
>
> The most important missing piece of the payment protocol is that is has
> no concept of the status of a payment after it has been made. What if
> the payment is too little? Too much? What if it is never confirmed? What
> if it is confirmed, but very late? These are regular occurrences at
> BitPay (although hopefully they will be a lot fewer after the payment
> protocol is widely adopted).
>
> One way to handle this would be to add another type of message, say with
> content-type bitcoin-paymentstatus, that can return the merchant's view
> of the status of the transaction(s). Are the transactions under or
> overpaid? Are they confirmed? How many confirmations? Is the payment
> "accepted" even if the transactions aren't confirmed?
>
> I think it would be great if wallets could check the status of a
> payment, and if anything goes wrong, request a refund, all within the
> payment protocol.
>
> The payment protocol is also the perfect opportunity to implement merge
> avoidance to increase customer and merchant privacy. The merchant can
> simply deliver multiple outputs in the payment details, say 10 or so,
> and the customer can spend multiple outputs to those outputs in separate
> transactions. It would be great if BitPay could work with wallet authors
> to make merge avoidance a reality in the near-term.
>
> Merge avoidance would increase the need to have a bitcoin-paymentstatus
> message since it's possible that some, but not all, of the transactions
> would confirm, and so knowing the status of payment would be a complex
> question that should be handled automatically by the software.
>
> On an unrelated note, X.509 is a terrible standard that should be
> abandoned as quickly as possible. BitPay is working on a new standard
> based on bitcoin-like addresses for authentication. It would be great if
> we could work with the community to establish a complete, decentralized
> authentication protocol. The sooner we can evolve beyond X.509 the better.
>
> One more thing. The new bitcoin URI in BIP 72 is extremely long and
> makes for very dense QR codes. BitPay has proposed a new standard, BIP
> 73, for shorter URIs and less dense QR codes. We hope wallet authors
> will implement this better standard.
>
> My response to Andreas' thoughts:
>
> On 2/18/14, 12:31 PM, Andreas Schildbach wrote:
> > I'm starting a thread on proposed changes on BIP70 based on my
> > experience in implementing the payment protocol in Bitcoin Wallet:
> >
> > - certificate chain in pki_data: I think it should be required that is
> > most contain the first certificate PLUS all intermediate certificates
> > (if any), but NOT the root certificate. Reason: We want to be able to
> > verify offline.
>
> So long as the root certificate remains an optional addition, this seems
> like a good idea. My experience with tls in node is that it is required
> for the root certificate to be present, so we don't want to require that
> the root certificate be absent, since that would make it painful to make
> code that is interoperable between the two. IIRC setting
> rejectUnauthorized=true will reject connections that do not deliver the
> root certificate, so allowing the root certificate to be present would
> be compatible with this and presumably other tls code.
>
> Would be great if someone with more experience with tls weighed in on
> whether the root certificate can/should be present.
>
> >
> > - definition of timezone: Its not clear if times (e.g. expires) are in
> > UTC or local. I suggest to require UTC. If if we can't agree on this,
> > there should be a sentence about timezones in the spec.
>
> The world needs to abandon timezones altogether for everything and only
> use UTC. So, agreed. Require UTC.
>
> >
> > (probably more to be added...)
> >
> >
> >
> ------------------------------------------------------------------------------
> > Managing the Performance of Cloud-Based Applications
> > Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
> > Read the Whitepaper.
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk
> > _______________________________________________
> > Bitcoin-development mailing list
> > Bitcoin-development@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >
>
> --
> Ryan X. Charles
> Software Engineer, BitPay
>
>
> ------------------------------------------------------------------------------
> Managing the Performance of Cloud-Based Applications
> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
> Read the Whitepaper.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>


-- 
--
Gavin Andresen

--20cf3010e96bee7e2404f2b3ef1a
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Fantastic feedback, thanks Ryan and Andreas!<div><br></div=
><div>Please don&#39;t let me being busy get in the way of progress, so sub=
mit pull requests to the BIP (the UTC timezone issue seems obvious and non-=
controversial) or write up draft specs for extensions.</div>
<div><br></div><div>RE: wallets checking the status of payment: =A0excellen=
t idea. A URL that can be polled to check payment processing status sounds =
like the right thing to do.</div><div><br></div><div>That feels very simila=
r to the proposal for recurring payments; I think they would be separate me=
chanisms, but maybe their specs could share some of the same concepts / fie=
ld names....</div>
</div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Tue,=
 Feb 18, 2014 at 2:14 PM, Ryan X. Charles <span dir=3D"ltr">&lt;<a href=3D"=
mailto:ryan@bitpay.com" target=3D"_blank">ryan@bitpay.com</a>&gt;</span> wr=
ote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">Here are my complementary thoughts after wor=
king on the payment protocol<br>
on the merchant side at BitPay.<br>
<br>
The most important missing piece of the payment protocol is that is has<br>
no concept of the status of a payment after it has been made. What if<br>
the payment is too little? Too much? What if it is never confirmed? What<br=
>
if it is confirmed, but very late? These are regular occurrences at<br>
BitPay (although hopefully they will be a lot fewer after the payment<br>
protocol is widely adopted).<br>
<br>
One way to handle this would be to add another type of message, say with<br=
>
content-type bitcoin-paymentstatus, that can return the merchant&#39;s view=
<br>
of the status of the transaction(s). Are the transactions under or<br>
overpaid? Are they confirmed? How many confirmations? Is the payment<br>
&quot;accepted&quot; even if the transactions aren&#39;t confirmed?<br>
<br>
I think it would be great if wallets could check the status of a<br>
payment, and if anything goes wrong, request a refund, all within the<br>
payment protocol.<br>
<br>
The payment protocol is also the perfect opportunity to implement merge<br>
avoidance to increase customer and merchant privacy. The merchant can<br>
simply deliver multiple outputs in the payment details, say 10 or so,<br>
and the customer can spend multiple outputs to those outputs in separate<br=
>
transactions. It would be great if BitPay could work with wallet authors<br=
>
to make merge avoidance a reality in the near-term.<br>
<br>
Merge avoidance would increase the need to have a bitcoin-paymentstatus<br>
message since it&#39;s possible that some, but not all, of the transactions=
<br>
would confirm, and so knowing the status of payment would be a complex<br>
question that should be handled automatically by the software.<br>
<br>
On an unrelated note, X.509 is a terrible standard that should be<br>
abandoned as quickly as possible. BitPay is working on a new standard<br>
based on bitcoin-like addresses for authentication. It would be great if<br=
>
we could work with the community to establish a complete, decentralized<br>
authentication protocol. The sooner we can evolve beyond X.509 the better.<=
br>
<br>
One more thing. The new bitcoin URI in BIP 72 is extremely long and<br>
makes for very dense QR codes. BitPay has proposed a new standard, BIP<br>
73, for shorter URIs and less dense QR codes. We hope wallet authors<br>
will implement this better standard.<br>
<br>
My response to Andreas&#39; thoughts:<br>
<div class=3D""><br>
On 2/18/14, 12:31 PM, Andreas Schildbach wrote:<br>
&gt; I&#39;m starting a thread on proposed changes on BIP70 based on my<br>
&gt; experience in implementing the payment protocol in Bitcoin Wallet:<br>
&gt;<br>
&gt; - certificate chain in pki_data: I think it should be required that is=
<br>
&gt; most contain the first certificate PLUS all intermediate certificates<=
br>
&gt; (if any), but NOT the root certificate. Reason: We want to be able to<=
br>
&gt; verify offline.<br>
<br>
</div>So long as the root certificate remains an optional addition, this se=
ems<br>
like a good idea. My experience with tls in node is that it is required<br>
for the root certificate to be present, so we don&#39;t want to require tha=
t<br>
the root certificate be absent, since that would make it painful to make<br=
>
code that is interoperable between the two. IIRC setting<br>
rejectUnauthorized=3Dtrue will reject connections that do not deliver the<b=
r>
root certificate, so allowing the root certificate to be present would<br>
be compatible with this and presumably other tls code.<br>
<br>
Would be great if someone with more experience with tls weighed in on<br>
whether the root certificate can/should be present.<br>
<div class=3D""><br>
&gt;<br>
&gt; - definition of timezone: Its not clear if times (e.g. expires) are in=
<br>
&gt; UTC or local. I suggest to require UTC. If if we can&#39;t agree on th=
is,<br>
&gt; there should be a sentence about timezones in the spec.<br>
<br>
</div>The world needs to abandon timezones altogether for everything and on=
ly<br>
use UTC. So, agreed. Require UTC.<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
&gt;<br>
&gt; (probably more to be added...)<br>
&gt;<br>
&gt;<br>
&gt; ----------------------------------------------------------------------=
--------<br>
&gt; Managing the Performance of Cloud-Based Applications<br>
&gt; Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.=
<br>
&gt; Read the Whitepaper.<br>
&gt; <a href=3D"http://pubads.g.doubleclick.net/gampad/clk?id=3D121054471&a=
mp;iu=3D/4140/ostg.clktrk" target=3D"_blank">http://pubads.g.doubleclick.ne=
t/gampad/clk?id=3D121054471&amp;iu=3D/4140/ostg.clktrk</a><br>
&gt; _______________________________________________<br>
&gt; Bitcoin-development mailing list<br>
&gt; <a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-d=
evelopment@lists.sourceforge.net</a><br>
&gt; <a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-develo=
pment" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitco=
in-development</a><br>
&gt;<br>
<br>
</div></div><span class=3D"HOEnZb"><font color=3D"#888888">--<br>
Ryan X. Charles<br>
Software Engineer, BitPay<br>
</font></span><br>---------------------------------------------------------=
---------------------<br>
Managing the Performance of Cloud-Based Applications<br>
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.<br>
Read the Whitepaper.<br>
<a href=3D"http://pubads.g.doubleclick.net/gampad/clk?id=3D121054471&amp;iu=
=3D/4140/ostg.clktrk" target=3D"_blank">http://pubads.g.doubleclick.net/gam=
pad/clk?id=3D121054471&amp;iu=3D/4140/ostg.clktrk</a><br>__________________=
_____________________________<br>

Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
<br></blockquote></div><br><br clear=3D"all"><div><br></div>-- <br>--<br>Ga=
vin Andresen<br>
</div>

--20cf3010e96bee7e2404f2b3ef1a--