https://en.b= itcoin.it/wiki/BIP_0070 : Network protocol / messages

https://en.bitcoin.it/wiki/BIP_007= 1 : MIME types for the messages

https://en.bitcoin.it/= wiki/BIP_0072 : bitcoin: URI extension

I expec= t the wallet-side implementation to be pulled into Bitcoin-Qt Real Soon:

=A0=A0https:/= /github.com/bitcoin/bitcoin/pull/2539

There is= also a reference implementation of server-side code for generating payment= requests in php and C++ :

=A0=A0http= s://github.com/gavinandresen/paymentrequest

<= /div>

--=A0

--
Gavin Andresen

--089e0122e9223df7c504e2c8d50b-- From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1V4SG1-0007qT-5y for bitcoin-development@lists.sourceforge.net; Wed, 31 Jul 2013 08:59:45 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.219.45 as permitted sender) client-ip=209.85.219.45; envelope-from=mh.in.england@gmail.com; helo=mail-oa0-f45.google.com; Received: from mail-oa0-f45.google.com ([209.85.219.45]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1V4SFz-0000q3-CH for bitcoin-development@lists.sourceforge.net; Wed, 31 Jul 2013 08:59:45 +0000 Received: by mail-oa0-f45.google.com with SMTP id m1so953501oag.32 for ; Wed, 31 Jul 2013 01:59:37 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.60.43.226 with SMTP id z2mr67034590oel.76.1375261177807; Wed, 31 Jul 2013 01:59:37 -0700 (PDT) Sender: mh.in.england@gmail.com Received: by 10.76.23.36 with HTTP; Wed, 31 Jul 2013 01:59:37 -0700 (PDT) In-Reply-To: References: Date: Wed, 31 Jul 2013 10:59:37 +0200 X-Google-Sender-Auth: 4FWgoEqyCP2HG9jzepAOlJA3_0A Message-ID: From: Mike Hearn To: Gavin Andresen Content-Type: multipart/alternative; boundary=001a11333dcefa0cb004e2caf1dd 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: 1V4SFz-0000q3-CH Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Payment Protocol: BIP 70, 71, 72 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, 31 Jul 2013 08:59:45 -0000 --001a11333dcefa0cb004e2caf1dd Content-Type: text/plain; charset=UTF-8 Woo, huzzah :-) Now the BIP draft is available and we know it all hangs together, I'm hoping to (re)start implementation work in bitcoinj in the next month or two. I'm currently trying to figure out which is more important, deterministic wallets or payment protocol, but I think right now the payment protocol would be easier to do and would benefit more from a second implementation. HD wallets have already been shown interoperable. Comments on BIP 70: "PaymentRequest messages larger than 50,000 bytes should be rejected by the merchant's server, to mitigate denial-of-service attacks." Do you mean "users wallet" here? You could note in the motivation section two more motivations: 1) That the protocol can be a foundation on which other features are built 2) That it is required to assist hardware wallets when there is a virus on the system Perhaps note in the BIP that the merchant should not assume the merchant_data field is trustworthy - malicious buyers could rewrite it as they see fit. Point out that a good way to use this is to serialize server state, signed by a merchant-only key, in the same way one might use an HTTP cookie. "PaymentDetails.payment_url must be secure against man-in-the-middle attacks that might alter Payment.refund_to (if using HTTP, it must be TLS-protected). This says "must", but what should a client do here if the payment URL is not HTTPS? I suggest weakening this to "should", as sometimes TLS is redundant (e.g. if you're sending to a Tor hidden service). The PaymentACK message contains a copy of Payment, but the BIP doesn't say what to do with it. I assume this means a client is free to ignore it and rely on TCP state to figure out the payment/ack connection instead? It may be worth noting that explicitly. In the certificates section, you could observe that "validation" means "verification that it correctly chains to a trusted root authority, where trusted roots may be obtained from the operating system. If there is no operating system, the Mozilla root store is recommended". All the rest LGTM. [edit ] On Wed, Jul 31, 2013 at 8:28 AM, Gavin Andresen wrote: > I've turned the preliminary payment protocol spec into three BIPs: > > https://en.bitcoin.it/wiki/BIP_0070 : Network protocol / messages > https://en.bitcoin.it/wiki/BIP_0071 : MIME types for the messages > https://en.bitcoin.it/wiki/BIP_0072 : bitcoin: URI extension > > I expect the wallet-side implementation to be pulled into Bitcoin-Qt Real > Soon: > https://github.com/bitcoin/bitcoin/pull/2539 > > There is also a reference implementation of server-side code for > generating payment requests in php and C++ : > https://github.com/gavinandresen/paymentrequest > > -- > -- > Gavin Andresen > > > > ------------------------------------------------------------------------------ > Get your SQL database under version control now! > Version control is standard for application code, but databases havent > caught up. So what steps can you take to put your SQL databases under > version control? Why should you start doing it? Read more to find out. > http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > --001a11333dcefa0cb004e2caf1dd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Woo, huzzah :-)

Now the BIP draft is av= ailable and we know it all hangs together, I'm hoping to (re)start impl= ementation work in bitcoinj in the next month or two. I'm currently try= ing to figure out which is more important, deterministic wallets or payment= protocol, but I think right now the payment protocol would be easier to do= and would benefit more from a second implementation. HD wallets have alrea= dy been shown interoperable.

Comments on BIP 70:

=C2=A0 =C2= =A0"PaymentRequest messages larger t= han 50,000 bytes should be rejected by the merchant's server, to mitiga= te denial-of-service attacks."

Do you mean "users wallet" here?

You could note in the motivation section two more motiv= ations:

1) That the protocol can be a foundation on which other= features are built

2) T= hat it is required to assist hardware wallets when there is a virus on the = system

Perhaps note in the BIP that the merchant should not as= sume the merchant_data field is trustworthy - malicious buyers could rewrit= e it as they see fit. Point out that a good way to use this is to serialize= server state, signed by a merchant-only key, in the same way one might use= an HTTP cookie.

=C2=A0 =C2=A0"PaymentDetails.payment_url must be secure against man-in-th= e-middle attacks that might alter Payment.refund_to (if using HTTP, it must= be TLS-protected).

This says "must", but what should a cl= ient do here if the payment URL is not HTTPS? I suggest weakening this to &= quot;should", as sometimes TLS is redundant (e.g. if you're sendin= g to a Tor hidden service).

The PaymentACK message cont= ains a copy of Payment, but the BIP doesn't say what to do with it. I a= ssume this means a client is free to ignore it and rely on TCP state to fig= ure out the payment/ack connection instead? It may be worth noting that exp= licitly.

In the certificates section= , you could observe that "validation" means "verification th= at it correctly chains to a trusted root authority, where trusted roots may= be obtained from the operating system. If there is no operating system, th= e Mozilla root store is recommended".

All the rest LGTM.

[edit]

On Wed,= Jul 31, 2013 at 8:28 AM, Gavin Andresen <gavinandresen@gmail.com> wrote:

I've turned the preliminary payment prot= ocol spec into three BIPs:

https://en.bitcoin.it/wiki/BIP_0070 : Network protocol / messages

http= s://en.bitcoin.it/wiki/BIP_0071 : MIME types for the messages

http= s://en.bitcoin.it/wiki/BIP_0072 : bitcoin: URI extension

=
I expect the wallet-side implementation to be pulled into Bitcoi= n-Qt Real Soon:

=C2=A0=C2=A0https://github.com/bitcoin/bitcoin/pull/2539

There is also a reference implementation of server-side cod= e for generating payment requests in php and C++ :

=C2=A0=C2=A0https://github.com/gavinandresen/paymentrequest

--=C2=A0

--
Gavin Andresen

-----------------------------------------------------------------------= -------
Get your SQL database under version control now!
Version control is standard for application code, but databases havent
caught up. So what steps can you take to put your SQL databases under
version control? Why should you start doing it? Read more to find out.
http://pubads.g.doubleclick.net/gam= pad/clk?id=3D49501711&iu=3D/4140/ostg.clktrk
___________________= ____________________________
Bitcoin-development mailing list
Bitcoin-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment

--001a11333dcefa0cb004e2caf1dd-- From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1V4Seu-0000PQ-QL for bitcoin-development@lists.sourceforge.net; Wed, 31 Jul 2013 09:25:28 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gnomon.org.uk designates 93.93.131.22 as permitted sender) client-ip=93.93.131.22; envelope-from=roy@gnomon.org.uk; helo=darla.gnomon.org.uk; Received: from darla.gnomon.org.uk ([93.93.131.22]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1V4Ses-00028b-Rq for bitcoin-development@lists.sourceforge.net; Wed, 31 Jul 2013 09:25:28 +0000 Received: from darla.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by darla.gnomon.org.uk (8.14.3/8.14.3) with ESMTP id r6V8jdAh029094 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 31 Jul 2013 09:45:44 +0100 (BST) (envelope-from roy@darla.gnomon.org.uk) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.95.3 at darla.gnomon.org.uk Received: (from roy@localhost) by darla.gnomon.org.uk (8.14.3/8.14.1/Submit) id r6V8jdRt029093; Wed, 31 Jul 2013 09:45:39 +0100 (BST) (envelope-from roy) Date: Wed, 31 Jul 2013 09:45:39 +0100 From: Roy Badami To: Gavin Andresen Message-ID: <20130731084538.GL16713@giles.gnomon.org.uk> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) X-Spam-Score: -3.0 (---) 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 SPF_HELO_PASS SPF: HELO matches SPF record -0.0 SPF_PASS SPF: sender matches SPF record -1.5 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain X-Headers-End: 1V4Ses-00028b-Rq Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Payment Protocol: BIP 70, 71, 72 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, 31 Jul 2013 09:25:28 -0000 On Wed, Jul 31, 2013 at 04:28:25PM +1000, Gavin Andresen wrote: > I've turned the preliminary payment protocol spec into three BIPs: > > https://en.bitcoin.it/wiki/BIP_0070 : Network protocol / messages > https://en.bitcoin.it/wiki/BIP_0071 : MIME types for the messages > https://en.bitcoin.it/wiki/BIP_0072 : bitcoin: URI extension Is it envisaged to be possible/sensible to have a URI that is *only* a payment request? i.e. something like the following (although I'm not sure this is a valid URI): bitcoin:?request=https%3A%2F%2Fmerchant.com%2Fpay.php%3Fh%3D2a8628fc2fbe roy From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1V4UR2-0005LG-B1 for bitcoin-development@lists.sourceforge.net; Wed, 31 Jul 2013 11:19:16 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com designates 74.125.82.169 as permitted sender) client-ip=74.125.82.169; envelope-from=gavinandresen@gmail.com; helo=mail-we0-f169.google.com; Received: from mail-we0-f169.google.com ([74.125.82.169]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1V4UQx-000078-Td for bitcoin-development@lists.sourceforge.net; Wed, 31 Jul 2013 11:19:16 +0000 Received: by mail-we0-f169.google.com with SMTP id n5so485536wev.14 for ; Wed, 31 Jul 2013 04:19:05 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.102.37 with SMTP id fl5mr3889018wib.52.1375269545702; Wed, 31 Jul 2013 04:19:05 -0700 (PDT) Received: by 10.194.82.198 with HTTP; Wed, 31 Jul 2013 04:19:05 -0700 (PDT) In-Reply-To: References:

Date: Wed, 31 Jul 2013 21:19:05 +1000 Message-ID: From: Gavin Andresen To: Mike Hearn Content-Type: multipart/alternative; boundary=f46d044517f7bdfe7a04e2cce4b1 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: 1V4UQx-000078-Td Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Payment Protocol: BIP 70, 71, 72 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, 31 Jul 2013 11:19:16 -0000 --f46d044517f7bdfe7a04e2cce4b1 Content-Type: text/plain; charset=ISO-8859-1 Thanks, Mike! "PaymentRequest messages larger than 50,000 bytes should be rejected by > the merchant's server, to mitigate denial-of-service attacks." > > Do you mean "users wallet" here? > Yes, fixed. > You could note in the motivation section two more motivations: > 1) That the protocol can be a foundation on which other features are built > I don't like putting "this is what we think will happen in the future" types of statements in specifications, so I'm inclined to leave that out. > 2) That it is required to assist hardware wallets when there is a virus on > the system > Added: "Resistance from man-in-the-middle attacks that replace a merchant's bitcoin address with an attacker's address before a transaction is authorized with a hardware wallet." Perhaps note in the BIP that the merchant should not assume the > merchant_data field is trustworthy - malicious buyers could rewrite it as > they see fit. Point out that a good way to use this is to serialize server > state, signed by a merchant-only key, in the same way one might use an HTTP > cookie. > Added: "Note that malicious clients may modify the merchant_data, so should be authenticated in some way (for example, signed with a merchant-only key)." > "PaymentDetails.payment_url must be secure against man-in-the-middle > attacks that might alter Payment.refund_to (if using HTTP, it must be > TLS-protected). > > This says "must", but what should a client do here if the payment URL is > not HTTPS? I suggest weakening this to "should", as sometimes TLS is > redundant (e.g. if you're sending to a Tor hidden service). > done. > The PaymentACK message contains a copy of Payment, but the BIP doesn't say > what to do with it. I assume this means a client is free to ignore it and > rely on TCP state to figure out the payment/ack connection instead? It may > be worth noting that explicitly. > Added: "payment | Copy of the Payment message that triggered this PaymentACK. Clients may ignore this if they implement another way of associating Payments with PaymentACKs." > > In the certificates section, you could observe that "validation" means > "verification that it correctly chains to a trusted root authority, where > trusted roots may be obtained from the operating system. If there is no > operating system, the Mozilla root store is recommended". > Modified that section to say: "...followed by additional certificates, with each subsequent certificate being the one used to certify the previous one, up to a trusted root authority. The recipient must verify the certificate chain according to [RFC5280] and reject the PaymentRequest if any validation failure occurs. Trusted root certificates may be obtained from the operating system; if validation is done on a device without an operating system, the Mozilla root store is recommended." -- -- Gavin Andresen --f46d044517f7bdfe7a04e2cce4b1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thanks, Mike!

=A0 =A0"Pa= ymentRequest messages larger than 50,000 bytes should be rejected by the me= rchant's server, to mitigate denial-of-service attacks."

Do you mean "users wallet" here?
=

Yes, fixed.

=A0

= You could note in the motivation section two more motivations:

1) That the protocol can be a founda= tion on which other features are built

I don't like putting "this is what we think will ha= ppen in the future" types of statements in specifications, so I'm = inclined to leave that out.

=A0

2) That it is required to assist hardware wallets= when there is a virus on the system

Added:

&quo= t;Resistance from man-in-the-middle atta= cks that replace a merchant's bitcoin address with an attacker's ad= dress before a transaction is authorized with a hardware wallet."

Perhaps note in the BIP that the mer= chant should not assume the merchant_data field is trustworthy - malicious = buyers could rewrite it as they see fit. Point out that a good way to use t= his is to serialize server state, signed by a merchant-only key, in the sam= e way one might use an HTTP cookie.

=A0

Added:

"= ;Note that malicious clients may modify = the merchant_data, so should be authenticated in some way (for example, sig= ned with a merchant-only key)."

=A0

=A0 =A0"PaymentDetails.payment_u= rl must be secure against man-in-the-middle attacks that might alter Paymen= t.refund_to (if using HTTP, it must be TLS-protected).

This says "must", but what should a cl= ient do here if the payment URL is not HTTPS? I suggest weakening this to &= quot;should", as sometimes TLS is redundant (e.g. if you're sendin= g to a Tor hidden service).

done.

=A0

The Payme= ntACK message contains a copy of Payment, but the BIP doesn't say what = to do with it. I assume this means a client is free to ignore it and rely o= n TCP state to figure out the payment/ack connection instead? It may be wor= th noting that explicitly.

Added:

&quo= t;payment | Copy of the Payment message that triggered this PaymentACK. Cli= ents may ignore this if they implement another way of associating Payments = with PaymentACKs."

=A0

In the certificates section= , you could observe that "validation" means "verification th= at it correctly chains to a trusted root authority, where trusted roots may= be obtained from the operating system. If there is no operating system, th= e Mozilla root store is recommended".

Modified that section to say:

"...followed by additional certificates, with each su= bsequent certificate being the one used to certify the previous one, up to = a trusted root authority. The recipient must verify the certificate chain a= ccording to [RFC5280] and reject the PaymentRequest if any validation failu= re occurs.

On 31 July 2013 13:33, Gavin Andresen <gavinandresen@gmail.c= om> wrote:

On Wed, Jul 31, 2013 at 6:= 45 PM, Roy Badami <roy@gnomon.org.u= k> wrote:
>
> Is it envisaged to be possible/sensible to have a URI that is *only* a=
> payment request? =A0i.e. something like the following (although I'= m not
> sure this is a valid URI):
>
> bitcoin:?request=3Dhttps%3A%2F%2Fmerchant.com%2Fpay.php%3Fh%3D2a8628fc= 2fbe

I think we'll want a bitcoin address in there for a long time for=
backwards compatibility.

If web browser support for arbitrary MIME types is strong enough (I
haven't tested), then a payment request can be initiated with just an anchor tag:
=A0 <a href=3D"https://merchant.com/pay.php?3D2a8628fc2fbe"=
type=3D"application/bitcoin-paymentrequest">

<= div>

Unless I'm mistaken you cant generally set the "= ;Accept" header on a browser via a standard href ... one of those anno= ying quirks

=A0

Doing it that way saves a http round-trip.

--
--
Gavin Andresen

---------------------------------------------------------------------------= ---
Get your SQL database under version control now!
Version control is standard for application code, but databases havent
caught up. So what steps can you take to put your SQL databases under
version control? Why should you start doing it? Read more to find out.
http://pubads.g.doubleclick.net/gam= pad/clk?id=3D49501711&iu=3D/4140/ostg.clktrk
_______________________________________________
Bitcoin-development mailing list
Bitcoin-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment

P2SH addresses support exotic transaction outputs, bu= t not all exotic transactions. This payment protocol can allow for combinin= g multiple outputs. A PaymentRequest for sending money to multiple parties,= for example, could not fall back to a single address.

I'd like to hear from other wallet implementors. Do you have a notion of 'locked inputs' ? =C2=A0The tricky bit in constructing a transac= tion but
not broadcasting it right away is the inputs must be locked, so
they're not accidentally double-spent.

<= div>bitcoinj separates the concept of committing a tx to the wallet from br= oadcasting it. However by default transactions that weren't seen in the= chain yet will be announced when a new peer is connected to. It'd take= extra code to suppress that, and it's unclear to me why that's use= ful. I agree with Pieter that it should be the merchants responsibility to = get the tx out there, but having the client do the broadcast as well can= 9;t really hurt (except perhaps some privacy impact).

My concerns here are:
* Making sure wallet applications can function without supporting the
P2P protocol (which drops a huge implementation overhead for simple -
perhaps hardware-based - wallets)

=C2=A0

How wou= ld such wallets get transactions into their wallet in the first place?

The P2P protocol is really the simplest part of implem= enting a wallet, IMO.=C2=A0

I don't really have a strong opinion either way, bu= t doing more work to prevent transactions being announced to the network fe= els weird.=C2=A0

--e89a8fb1f56c357a3704e36272d2-- From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1V7BZo-0006Oy-Px for bitcoin-development@lists.sourceforge.net; Wed, 07 Aug 2013 21:47:28 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.216.48 as permitted sender) client-ip=209.85.216.48; envelope-from=etotheipi@gmail.com; helo=mail-qa0-f48.google.com; Received: from mail-qa0-f48.google.com ([209.85.216.48]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1V7BZo-0005nd-1F for bitcoin-development@lists.sourceforge.net; Wed, 07 Aug 2013 21:47:28 +0000 Received: by mail-qa0-f48.google.com with SMTP id o19so1356051qap.0 for ; Wed, 07 Aug 2013 14:47:22 -0700 (PDT) X-Received: by 10.224.12.81 with SMTP id w17mr2903891qaw.37.1375912042483; Wed, 07 Aug 2013 14:47:22 -0700 (PDT) Received: from [192.168.1.85] (c-76-111-96-126.hsd1.md.comcast.net. [76.111.96.126]) by mx.google.com with ESMTPSA id i1sm14101071qas.10.2013.08.07.14.47.21 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 07 Aug 2013 14:47:21 -0700 (PDT) Message-ID: <5202C05B.8090509@gmail.com> Date: Wed, 07 Aug 2013 17:47:07 -0400 From: Alan Reiner User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: bitcoin-development@lists.sourceforge.net References:

In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: multipart/alternative; boundary="------------010800050007040508020100" 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 (etotheipi[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: 1V7BZo-0005nd-1F Subject: Re: [Bitcoin-development] Payment Protocol: BIP 70, 71, 72 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, 07 Aug 2013 21:47:29 -0000 This is a multi-part message in MIME format. --------------010800050007040508020100 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 08/07/2013 05:10 PM, Gavin Andresen wrote: > I'd like to hear from other wallet implementors. Do you have a notion > of 'locked inputs' ? The tricky bit in constructing a transaction but > not broadcasting it right away is the inputs must be locked, so > they're not accidentally double-spent. > I have avoided any notion of locking inputs in Armory for offline wallets. The underlying concept of why a seemingly-random amount of funds are inaccessible at a given time is so non-intuitive and difficult to explain to a non-expert, that I haven't even tried to deal with it. Luckily, most users do one operation at a time, so it's not a real a problem. But as more businesses have started to use Armory, it /will/ become a problem that will need to be addressed /somehow/. I have considered at least "marking" inputs to indicate to the user that the transaction they are creating may not be valid unless all previous transactions have been broadcast. The user will not necessarily understand why, but they might easily comprehend the solution (and perhaps a button that says "Forget all previously created transactions that haven't been broadcast. Press this button if there are no transactions waiting to be broadcast"). Even if the user somewhat understands the concepts behind locking, you easily end up with a mess of some coins being locked and rejecting transaction creation somewhat randomly, especially when they create transactions that they later decide not to execute. And you have to give the user a way to manually unlock the outputs which they wouldn't know to use because it's so non-intuitive. I'd much rather say "either do one transaction at a time, or bundle payments into a single multi-output transaction. Or risk invalid transactions that have to be re-created and signed." -Alan --------------010800050007040508020100 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 08/07/2013 05:10 PM, Gavin Andresen wrote:

I'd like to hear from other wallet implementors. Do you have a notion
of 'locked inputs' ?  The tricky bit in constructing a transaction but
not broadcasting it right away is the inputs must be locked, so
they're not accidentally double-spent.

I have avoided any notion of locking inputs in Armory for offline wallets. The underlying concept of why a seemingly-random amount of funds are inaccessible at a given time is so non-intuitive and difficult to explain to a non-expert, that I haven't even tried to deal with it. Luckily, most users do one operation at a time, so it's not a real a problem. But as more businesses have started to use Armory, it will become a problem that will need to be addressed somehow.

I have considered at least "marking" inputs to indicate to the user that the transaction they are creating may not be valid unless all previous transactions have been broadcast. The user will not necessarily understand why, but they might easily comprehend the solution (and perhaps a button that says "Forget all previously created transactions that haven't been broadcast. Press this button if there are no transactions waiting to be broadcast").

Even if the user somewhat understands the concepts behind locking, you easily end up with a mess of some coins being locked and rejecting transaction creation somewhat randomly, especially when they create transactions that they later decide not to execute. And you have to give the user a way to manually unlock the outputs which they wouldn't know to use because it's so non-intuitive. I'd much rather say "either do one transaction at a time, or bundle payments into a single multi-output transaction. Or risk invalid transactions that have to be re-created and signed."

-Alan

--------------010800050007040508020100-- From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1V7BaY-0007CU-J4 for bitcoin-development@lists.sourceforge.net; Wed, 07 Aug 2013 21:48:14 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gnomon.org.uk designates 93.93.131.22 as permitted sender) client-ip=93.93.131.22; envelope-from=roy@gnomon.org.uk; helo=darla.gnomon.org.uk; Received: from darla.gnomon.org.uk ([93.93.131.22]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1V7BaX-0007i7-2v for bitcoin-development@lists.sourceforge.net; Wed, 07 Aug 2013 21:48:14 +0000 Received: from darla.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by darla.gnomon.org.uk (8.14.3/8.14.3) with ESMTP id r77Llv6t045309 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 7 Aug 2013 22:48:02 +0100 (BST) (envelope-from roy@darla.gnomon.org.uk) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.95.3 at darla.gnomon.org.uk Received: (from roy@localhost) by darla.gnomon.org.uk (8.14.3/8.14.1/Submit) id r77LlvM5045308; Wed, 7 Aug 2013 22:47:57 +0100 (BST) (envelope-from roy) Date: Wed, 7 Aug 2013 22:47:57 +0100 From: Roy Badami To: Gavin Andresen Message-ID: <20130807214757.GA45156@giles.gnomon.org.uk> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) X-Spam-Score: -1.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 SPF_HELO_PASS SPF: HELO matches SPF record -0.0 SPF_PASS SPF: sender matches SPF record -0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain X-Headers-End: 1V7BaX-0007i7-2v Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Payment Protocol: BIP 70, 71, 72 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, 07 Aug 2013 21:48:14 -0000 Very brief comment on BIP 72: I wonder if there should be some discussion included in the specification as to how the BIP 21 amount, message and label parameters should be processed when the payment protocol is used. Presumably amount should be completely ignored? But is the total amount requestd by the PaymentRequest required to match the amount parameter (when present)? Is the client permitted to complain if they don't? And what about message? Presumably the memo from PaymentDetails should take precedence, but if it's not present, and message is? I think this is an area perhaps more suited to SHOULDs and MAYs rather than MUSTs, but it is probably worthy of mention... roy From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1V7BbO-0002ik-Ej for bitcoin-development@lists.sourceforge.net; Wed, 07 Aug 2013 21:49:06 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.223.181 as permitted sender) client-ip=209.85.223.181; envelope-from=pieter.wuille@gmail.com; helo=mail-ie0-f181.google.com; Received: from mail-ie0-f181.google.com ([209.85.223.181]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1V7BbN-0005v6-RO for bitcoin-development@lists.sourceforge.net; Wed, 07 Aug 2013 21:49:06 +0000 Received: by mail-ie0-f181.google.com with SMTP id x14so461557ief.26 for ; Wed, 07 Aug 2013 14:49:00 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.50.124.10 with SMTP id me10mr636141igb.40.1375912140628; Wed, 07 Aug 2013 14:49:00 -0700 (PDT) Received: by 10.50.73.74 with HTTP; Wed, 7 Aug 2013 14:49:00 -0700 (PDT) In-Reply-To: References:

Date: Wed, 7 Aug 2013 23:49:00 +0200 Message-ID: From: Pieter Wuille To: Mike Hearn Content-Type: text/plain; charset=ISO-8859-1 X-Spam-Score: -1.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 (pieter.wuille[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record -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: 1V7BbN-0005v6-RO Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Payment Protocol: BIP 70, 71, 72 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, 07 Aug 2013 21:49:06 -0000 On Wed, Aug 7, 2013 at 11:44 PM, Mike Hearn wrote: > >> My concerns here are: >> * Making sure wallet applications can function without supporting the >> P2P protocol (which drops a huge implementation overhead for simple - >> perhaps hardware-based - wallets) > > > How would such wallets get transactions into their wallet in the first > place? By connecting to some other client, presumably. Have a small hardware client that is able to do payments via NFC/QR/... directly with a merchant, and can get 'recharged' by connecting with your desktop client, for example. Maybe too futuristic to be a concern, but it nicely illustrates how doing direct sender-to-receiver negotiation can help decoupling tasks. > I don't really have a strong opinion either way, but doing more work to > prevent transactions being announced to the network feels weird. Ok. -- Pieter From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1V7Bgx-0007R2-82 for bitcoin-development@lists.sourceforge.net; Wed, 07 Aug 2013 21:54:51 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.223.181 as permitted sender) client-ip=209.85.223.181; envelope-from=pieter.wuille@gmail.com; helo=mail-ie0-f181.google.com; Received: from mail-ie0-f181.google.com ([209.85.223.181]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1V7Bgw-0006lQ-Aw for bitcoin-development@lists.sourceforge.net; Wed, 07 Aug 2013 21:54:51 +0000 Received: by mail-ie0-f181.google.com with SMTP id x14so469946ief.26 for ; Wed, 07 Aug 2013 14:54:45 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.50.124.10 with SMTP id me10mr646900igb.40.1375912484939; Wed, 07 Aug 2013 14:54:44 -0700 (PDT) Received: by 10.50.73.74 with HTTP; Wed, 7 Aug 2013 14:54:44 -0700 (PDT) In-Reply-To: <20130807214757.GA45156@giles.gnomon.org.uk> References: <20130807214757.GA45156@giles.gnomon.org.uk> Date: Wed, 7 Aug 2013 23:54:44 +0200 Message-ID: From: Pieter Wuille To: Roy Badami Content-Type: text/plain; charset=ISO-8859-1 X-Spam-Score: -1.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 (pieter.wuille[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record -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: 1V7Bgw-0006lQ-Aw Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Payment Protocol: BIP 70, 71, 72 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, 07 Aug 2013 21:54:51 -0000 I see payment URIs rather as a replacement for bitcoin: URI rather than an extension. It solves everything they did in a much cleaner way, Given that bitcoin: have gotten some traction, we probably want to reuse the moniker, but replace the rest entirely. In other words, if a request is specified, nothing else should be. There is just no useful way to combine them either - payments generalize destinations to arbitrary scripts, messages are handled inline, amounts are defined inline. And if you want to rely on the payment infrastructure to work, you cannot risk people using the old-style static address in the URI. On Wed, Aug 7, 2013 at 11:47 PM, Roy Badami wrote: > Very brief comment on BIP 72: > > I wonder if there should be some discussion included in the > specification as to how the BIP 21 amount, message and label > parameters should be processed when the payment protocol is used. > > Presumably amount should be completely ignored? But is the total > amount requestd by the PaymentRequest required to match the amount > parameter (when present)? Is the client permitted to complain if they > don't? > > And what about message? Presumably the memo from PaymentDetails > should take precedence, but if it's not present, and message is? > > I think this is an area perhaps more suited to SHOULDs and MAYs rather > than MUSTs, but it is probably worthy of mention... > > roy > > ------------------------------------------------------------------------------ > Get 100% visibility into Java/.NET code with AppDynamics Lite! > It's a free troubleshooting tool designed for production. > Get down to code-level detail for bottlenecks, with <2% overhead. > Download for free and get started troubleshooting in minutes. > http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1V7BqA-0003Di-Ld for bitcoin-development@lists.sourceforge.net; Wed, 07 Aug 2013 22:04:22 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gnomon.org.uk designates 93.93.131.22 as permitted sender) client-ip=93.93.131.22; envelope-from=roy@gnomon.org.uk; helo=darla.gnomon.org.uk; Received: from darla.gnomon.org.uk ([93.93.131.22]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1V7Bq7-0006VT-6b for bitcoin-development@lists.sourceforge.net; Wed, 07 Aug 2013 22:04:22 +0000 Received: from darla.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by darla.gnomon.org.uk (8.14.3/8.14.3) with ESMTP id r77M3w8H045501 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 7 Aug 2013 23:04:03 +0100 (BST) (envelope-from roy@darla.gnomon.org.uk) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.95.3 at darla.gnomon.org.uk Received: (from roy@localhost) by darla.gnomon.org.uk (8.14.3/8.14.1/Submit) id r77M3wDa045500; Wed, 7 Aug 2013 23:03:58 +0100 (BST) (envelope-from roy) Date: Wed, 7 Aug 2013 23:03:58 +0100 From: Roy Badami To: Pieter Wuille Message-ID: <20130807220358.GB45156@giles.gnomon.org.uk> References: <20130807214757.GA45156@giles.gnomon.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) X-Spam-Score: -1.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 SPF_HELO_PASS SPF: HELO matches SPF record -0.0 SPF_PASS SPF: sender matches SPF record -0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain X-Headers-End: 1V7Bq7-0006VT-6b Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Payment Protocol: BIP 70, 71, 72 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, 07 Aug 2013 22:04:22 -0000 But the reality is that in many applications you need to provide a single URL. Consider existing point-of-sale systems that display QR codes for the user to scan. They live within the limitations of existing bitcoin URLs, but would no doubt benefit from the payments protocol. It's not realistic for the terminal operator in a retail establishment to have to select which protocol will be used before generating the QR code - so the effect of your proposal is to require lowest common denominator and effectively prevent such systems from using the payments protocol (at least until it is sufficiently ubiquitous that they feel happy to simply require its use). roy On Wed, Aug 07, 2013 at 11:54:44PM +0200, Pieter Wuille wrote: > I see payment URIs rather as a replacement for bitcoin: URI rather > than an extension. It solves everything they did in a much cleaner > way, Given that bitcoin: have gotten some traction, we probably want > to reuse the moniker, but replace the rest entirely. In other words, > if a request is specified, nothing else should be. > > There is just no useful way to combine them either - payments > generalize destinations to arbitrary scripts, messages are handled > inline, amounts are defined inline. And if you want to rely on the > payment infrastructure to work, you cannot risk people using the > old-style static address in the URI. > > > > On Wed, Aug 7, 2013 at 11:47 PM, Roy Badami wrote: > > Very brief comment on BIP 72: > > > > I wonder if there should be some discussion included in the > > specification as to how the BIP 21 amount, message and label > > parameters should be processed when the payment protocol is used. > > > > Presumably amount should be completely ignored? But is the total > > amount requestd by the PaymentRequest required to match the amount > > parameter (when present)? Is the client permitted to complain if they > > don't? > > > > And what about message? Presumably the memo from PaymentDetails > > should take precedence, but if it's not present, and message is? > > > > I think this is an area perhaps more suited to SHOULDs and MAYs rather > > than MUSTs, but it is probably worthy of mention... > > > > roy > > > > ------------------------------------------------------------------------------ > > Get 100% visibility into Java/.NET code with AppDynamics Lite! > > It's a free troubleshooting tool designed for production. > > Get down to code-level detail for bottlenecks, with <2% overhead. > > Download for free and get started troubleshooting in minutes. > > http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk > > _______________________________________________ > > Bitcoin-development mailing list > > Bitcoin-development@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1V7EOk-00066N-RG for bitcoin-development@lists.sourceforge.net; Thu, 08 Aug 2013 00:48:14 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com designates 74.125.82.177 as permitted sender) client-ip=74.125.82.177; envelope-from=gavinandresen@gmail.com; helo=mail-we0-f177.google.com; Received: from mail-we0-f177.google.com ([74.125.82.177]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1V7EOj-0007T4-UV for bitcoin-development@lists.sourceforge.net; Thu, 08 Aug 2013 00:48:14 +0000 Received: by mail-we0-f177.google.com with SMTP id m46so2086466wev.36 for ; Wed, 07 Aug 2013 17:48:07 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.189.9 with SMTP id ge9mr3578330wic.52.1375922887762; Wed, 07 Aug 2013 17:48:07 -0700 (PDT) Received: by 10.194.82.198 with HTTP; Wed, 7 Aug 2013 17:48:07 -0700 (PDT) In-Reply-To: <20130807220358.GB45156@giles.gnomon.org.uk> References: <20130807214757.GA45156@giles.gnomon.org.uk> <20130807220358.GB45156@giles.gnomon.org.uk> Date: Thu, 8 Aug 2013 10:48:07 +1000 Message-ID: From: Gavin Andresen To: Bitcoin Dev Content-Type: text/plain; charset=ISO-8859-1 X-Spam-Score: -1.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 -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: 1V7EOj-0007T4-UV Subject: Re: [Bitcoin-development] Payment Protocol: BIP 70, 71, 72 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: Thu, 08 Aug 2013 00:48:15 -0000 I've updated the BIP 72 spec at https://en.bitcoin.it/wiki/BIP_0072 so the bitcoin address is optional: "If the "request" parameter is provided and backwards compatibility is not required, then the bitcoin address portion of the URI may be omitted (the URI will be of the form: bitcoin:?request=... )." The spec already said what should happen if both request and address/amount/etc were given: "it should ignore the bitcoin address/amount/label/message in the URI and instead fetch a PaymentRequest message and then follow the payment protocol" I think this gives us a smooth, clear upgrade path. -- -- Gavin Andresen From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1V7MHX-0000G5-Lk for bitcoin-development@lists.sourceforge.net; Thu, 08 Aug 2013 09:13:19 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.214.180 as permitted sender) client-ip=209.85.214.180; envelope-from=mh.in.england@gmail.com; helo=mail-ob0-f180.google.com; Received: from mail-ob0-f180.google.com ([209.85.214.180]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1V7MHV-0006LP-Sg for bitcoin-development@lists.sourceforge.net; Thu, 08 Aug 2013 09:13:19 +0000 Received: by mail-ob0-f180.google.com with SMTP id up14so4919637obb.39 for ; Thu, 08 Aug 2013 02:13:12 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.182.110.226 with SMTP id id2mr5509765obb.95.1375953192115; Thu, 08 Aug 2013 02:13:12 -0700 (PDT) Sender: mh.in.england@gmail.com Received: by 10.76.84.231 with HTTP; Thu, 8 Aug 2013 02:13:11 -0700 (PDT) In-Reply-To: References: <20130807214757.GA45156@giles.gnomon.org.uk> <20130807220358.GB45156@giles.gnomon.org.uk> Date: Thu, 8 Aug 2013 11:13:11 +0200 X-Google-Sender-Auth: bZtsqO_x5KPYCgQ9oqjZvqZj0pA Message-ID: From: Mike Hearn To: Gavin Andresen Content-Type: multipart/alternative; boundary=089e0112ce203e8adc04e36c117a 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: 1V7MHV-0006LP-Sg Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Payment Protocol: BIP 70, 71, 72 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: Thu, 08 Aug 2013 09:13:19 -0000 --089e0112ce203e8adc04e36c117a Content-Type: text/plain; charset=UTF-8 Agreed, this looks good to me. --089e0112ce203e8adc04e36c117a Content-Type: text/html; charset=UTF-8

Agreed, this looks good to me.

--089e0112ce203e8adc04e36c117a-- From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1V7Qxw-00085X-7m for bitcoin-development@lists.sourceforge.net; Thu, 08 Aug 2013 14:13:24 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.223.178 as permitted sender) client-ip=209.85.223.178; envelope-from=pieter.wuille@gmail.com; helo=mail-ie0-f178.google.com; Received: from mail-ie0-f178.google.com ([209.85.223.178]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1V7Qxv-0004u4-A6 for bitcoin-development@lists.sourceforge.net; Thu, 08 Aug 2013 14:13:24 +0000 Received: by mail-ie0-f178.google.com with SMTP id f4so1889665iea.37 for ; Thu, 08 Aug 2013 07:13:18 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.42.66.200 with SMTP id q8mr2202913ici.25.1375971198011; Thu, 08 Aug 2013 07:13:18 -0700 (PDT) Received: by 10.50.73.74 with HTTP; Thu, 8 Aug 2013 07:13:17 -0700 (PDT) In-Reply-To: References: <20130807214757.GA45156@giles.gnomon.org.uk> <20130807220358.GB45156@giles.gnomon.org.uk> Date: Thu, 8 Aug 2013 16:13:17 +0200 Message-ID: From: Pieter Wuille To: Gavin Andresen Content-Type: text/plain; charset=ISO-8859-1 X-Spam-Score: -1.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 (pieter.wuille[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record -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: 1V7Qxv-0004u4-A6 Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Payment Protocol: BIP 70, 71, 72 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: Thu, 08 Aug 2013 14:13:24 -0000 On Thu, Aug 8, 2013 at 2:48 AM, Gavin Andresen wrote: > I've updated the BIP 72 spec at https://en.bitcoin.it/wiki/BIP_0072 so > the bitcoin address is optional: > > "If the "request" parameter is provided and backwards compatibility is > not required, then the bitcoin address portion of the URI may be > omitted (the URI will be of the form: bitcoin:?request=... )." Sounds good. I'd still like to see some effort to avoid losing metadata and reducing the responsibilities of the sender. I see there's an implementation difficulty in avoiding to broadcast a transaction, but for example, if a payment_uri is specified, and it cannot be contacted (at all), the transaction should fail. As soon as you manage to connect, and have at least attempted to submit the transaction, the merchant may have received it, and you want to mark the coins spent, so store it after that point. But without such protection we'll likely see a unnecessary payments happening without metadata, when the payment server cannot be contacted for some reason. Also, the receiver most certainly needs a P2P implementation (and probably a strongly validating one) to verify incoming transactions, so having him broadcast it shouldn't be hard. I don't think the client should be required to stay online to broadcast at all, after a paymentACK is received. The transaction arrived safely at that point. -- Pieter From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1V9Z9T-0007fD-TA for bitcoin-development@lists.sourceforge.net; Wed, 14 Aug 2013 11:22:07 +0000 X-ACL-Warn: Received: from entix.nl ([178.22.57.40] helo=mail.entix.nl) by sog-mx-3.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1V9Z9R-0004EZ-TE for bitcoin-development@lists.sourceforge.net; Wed, 14 Aug 2013 11:22:07 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.entix.nl (Postfix) with ESMTP id 80C7A164133 for ; Wed, 14 Aug 2013 12:56:58 +0200 (CEST) Received: from mail.entix.nl ([127.0.0.1]) by localhost (entix.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JTnNW9SlLItl for ; Wed, 14 Aug 2013 12:56:57 +0200 (CEST) Received: from [192.168.1.69] (specht [92.64.70.65]) by mail.entix.nl (Postfix) with ESMTPSA id DE6AA16400D for ; Wed, 14 Aug 2013 12:56:57 +0200 (CEST) Message-ID: <520B6278.9050909@bitonic.nl> Date: Wed, 14 Aug 2013 12:56:56 +0200 From: Jouke Hofman User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130404 Thunderbird/17.0.5 MIME-Version: 1.0 To: bitcoin-development@lists.sourceforge.net References:

In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. X-Headers-End: 1V9Z9R-0004EZ-TE Subject: Re: [Bitcoin-development] Payment Protocol: BIP 70, 71, 72 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, 14 Aug 2013 11:22:08 -0000 On 08/07/2013 11:10 PM, Gavin Andresen wrote: > I'd also like to hear from merchants: any issue with your payment > processing server having "broadcast transaction" functionality? > On the contrary, we would prefer to broadcast the transaction ourselves. From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1VBXjU-0001Td-HX for bitcoin-development@lists.sourceforge.net; Mon, 19 Aug 2013 22:15:28 +0000 X-ACL-Warn: Received: from petersson.at ([213.239.210.117]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1VBXjT-0003Su-5L for bitcoin-development@lists.sourceforge.net; Mon, 19 Aug 2013 22:15:28 +0000 Received: by petersson.at (Postfix, from userid 65534) id A3C4D19A063; Tue, 20 Aug 2013 00:15:20 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on petersson.at X-Spam-Level: X-Spam-Status: No, score=-1.0 required=4.0 tests=ALL_TRUSTED autolearn=disabled version=3.3.1 Received: from [192.168.0.199] (chello084114039092.14.vie.surfer.at [84.114.39.92]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: andreas) by petersson.at (Postfix) with ESMTPSA id 5FCE119A063 for ; Tue, 20 Aug 2013 00:15:20 +0200 (CEST) Message-ID: <521298F0.20108@petersson.at> Date: Tue, 20 Aug 2013 00:15:12 +0200 From: Andreas Petersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: bitcoin-development@lists.sourceforge.net References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -2.8 (--) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -2.8 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain X-Headers-End: 1VBXjT-0003Su-5L Subject: Re: [Bitcoin-development] Payment Protocol: BIP 70, 71, 72 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: Mon, 19 Aug 2013 22:15:28 -0000 I was just reviewing the integration work to integrate the Payment Protocol into our products. Is there any notion of a standardized invoice serialisation? If i pay for two Burgers and one Club Mate, how would my Bitcoin Wallet be able to know that? Right now, i would simply put that into "memo" and come up with my own serialisation mechanism. Second, is there a way to communicate acceptance levels of TX (unconfirmed, 1 conf, 6 conf) maybe using several PaymentACK? -Andreas From mboxrd@z Thu Jan 1 00:00:00 1970 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 1VBYjh-0006e6-TC for bitcoin-development@lists.sourceforge.net; Mon, 19 Aug 2013 23:19:45 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com designates 74.125.82.177 as permitted sender) client-ip=74.125.82.177; envelope-from=gavinandresen@gmail.com; helo=mail-we0-f177.google.com; Received: from mail-we0-f177.google.com ([74.125.82.177]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1VBYjh-0005EC-1g for bitcoin-development@lists.sourceforge.net; Mon, 19 Aug 2013 23:19:45 +0000 Received: by mail-we0-f177.google.com with SMTP id m46so4201516wev.8 for ; Mon, 19 Aug 2013 16:19:38 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.106.228 with SMTP id gx4mr10192993wib.9.1376954378862; Mon, 19 Aug 2013 16:19:38 -0700 (PDT) Received: by 10.194.156.163 with HTTP; Mon, 19 Aug 2013 16:19:38 -0700 (PDT) In-Reply-To: <521298F0.20108@petersson.at> References: <521298F0.20108@petersson.at> Date: Tue, 20 Aug 2013 09:19:38 +1000 Message-ID: From: Gavin Andresen To: Andreas Petersson Content-Type: multipart/alternative; boundary=e89a8f13ed049fc6c604e4552c13 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: 1VBYjh-0005EC-1g Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Payment Protocol: BIP 70, 71, 72 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: Mon, 19 Aug 2013 23:19:46 -0000 --e89a8f13ed049fc6c604e4552c13 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Aug 20, 2013 at 8:15 AM, Andreas Petersson wrote: > I was just reviewing the integration work to integrate the Payment > Protocol into our products. Is there any notion of a standardized > invoice serialisation? If i pay for two Burgers and one Club Mate, how > would my Bitcoin Wallet be able to know that? No. There are XML-based (shudder) standards for electronic invoicing that include all sorts of bells and whistles; the PaymentDetails message could easily encapsulate one of them in an 'invoice' field extension. Or we could reinvent the wheel and come up with our own, but I'd rather use an existing standard (or maybe a subset of an existing standard). I didn't want to wade into that swamp for the 1.0 version of the payment protocol. > Right now, i would simply > put that into "memo" and come up with my own serialisation mechanism. > "Two Burgers, one Club Mate" seems pretty user-friendly. Second, is there a way to communicate acceptance levels of TX > (unconfirmed, 1 conf, 6 conf) maybe using several PaymentACK? > No, because the Payment->PaymentACK communication round-trip is done in one, non-persistent http request-response round-trip. I don't think we want to allow merchants to push messages to the wallet (wouldn't take long for merchants to use the opportunity to push annoying advertising at me, I think), and I don't think we want wallets to poll the merchant. Although maybe a payment protocol version 2.0 feature could be a PaymentACK extension that says "ask me how the transaction is going at THIS URL in THIS many minutes." -- -- Gavin Andresen --e89a8f13ed049fc6c604e4552c13 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tue, Aug 20, 2013 at 8:15 AM, Andreas Petersson <an= dreas@petersson.at> wrote:

I was just reviewing the integration work to= integrate the Payment
Protocol into our products. Is there any notion of a standardized
invoice serialisation? If i pay for two Burgers and one Club Mate, how
would my Bitcoin Wallet be able to know that?

No. There are XML-based (shudder) standards for electronic invoicing tha= t include all sorts of bells and whistles; the PaymentDetails message could= easily encapsulate one of them in an 'invoice' field extension. Or= we could reinvent the wheel and come up with our own, but I'd rather u= se an existing standard (or maybe a subset of an existing standard).

I didn't want to wade into that swamp for the 1.0 v= ersion of the payment protocol.

=A0

Right now, i would simply
put that into "memo" and come up with my own serialisation mechan= ism.

"Two Burgers, one Club Mate&q= uot; seems pretty user-friendly.=A0

Second, is there a way to communicate acceptance levels of TX
(unconfirmed, 1 conf, 6 conf) maybe using several PaymentACK?

No, because the Payment->PaymentACK communication= round-trip is done in one, non-persistent http request-response round-trip= .

I don't think we want to allow merchants to p= ush messages to the wallet (wouldn't take long for merchants to use the= opportunity to push annoying advertising at me, I think), and I don't = think we want wallets to poll the merchant. Although maybe a payment protoc= ol version 2.0 feature could be a PaymentACK extension that says "ask = me how the transaction is going at THIS URL in THIS many minutes."

--
--
Gavin Andresen

I think the confidence of the tx is not really the users c= oncern anyway. They wrote it so they know it's valid. If the merchant d= isagrees for some reason then the user can find out, out of band when the g= oods/services are not delivered.

On Tue, A= ug 20, 2013 at 8:15 AM, Andreas Petersson <andreas@petersson.at>= wrote:

I was just reviewing the integration work to= integrate the Payment
Protocol into our products. Is there any notion of a standardized
invoice serialisation? If i pay for two Burgers and one Club Mate, how
would my Bitcoin Wallet be able to know that?

No. There are XML-based (shudder) standards for electronic invoici= ng that include all sorts of bells and whistles; the PaymentDetails message= could easily encapsulate one of them in an 'invoice' field extensi= on. Or we could reinvent the wheel and come up with our own, but I'd ra= ther use an existing standard (or maybe a subset of an existing standard).<= /div>

I didn't want to wade into that swamp for the 1.0 v= ersion of the payment protocol.

=C2=A0

Right now, i would simply
put that into "memo" and come up with my own serialisation mechan= ism.

"Two Burgers, one Club = Mate" seems pretty user-friendly.=C2=A0

No, because the Payment->PaymentACK communi= cation round-trip is done in one, non-persistent http request-response roun= d-trip.

--
--
Gavin Andresen

BTW, on the "make qrcodes more scannable" front = -- is it too late to change BIP 72 so the new param is just "r" i= nstead of "request"? Every byte helps when it comes to qrcodes ..= .

On Tue, Aug 20, 2013 at 1:19 AM, Gavin Andresen <gavinandr= esen@gmail.com> wrote:

On Tue, Aug 20, 2013 at 8:15 AM, Andreas Petersson <andr= eas@petersson.at> wrote:

I was just reviewing the integration work to= integrate the Payment
Protocol into our products. Is there any notion of a standardized
invoice serialisation? If i pay for two Burgers and one Club Mate, how
would my Bitcoin Wallet be able to know that?

I didn't want to wade into that swamp for the 1.0 v= ersion of the payment protocol.

=C2=A0

Right now, i would simply
put that into "memo" and come up with my own serialisation mechan= ism.

"Two Burgers, one Club = Mate" seems pretty user-friendly.=C2=A0

Second, is there a way to communicate acceptance levels of TX
(unconfirmed, 1 conf, 6 conf) maybe using several PaymentACK?

No, because the Payment->PaymentACK communi= cation round-trip is done in one, non-persistent http request-response roun= d-trip.

--
--
Gavin Andresen

-----------------------------------------= -------------------------------------
Introducing Performance Central, a new site from SourceForge and
AppDynamics. Performance Central is your source for news, insights,
analysis and resources for efficient Application Performance Management. Visit us today!
http://pubads.g.doubleclick.net/gam= pad/clk?id=3D48897511&iu=3D/4140/ostg.clktrk
___________________= ____________________________
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment

On Tue, Sep 24, 2013 at 11:52 PM, Mike Hearn <mike@plan99.n= et> wrote:

BTW, on the "make qrcodes more scannable" front = -- is it too late to change BIP 72 so the new param is just "r" i= nstead of "request"? Every byte helps when it comes to qrcodes ..= .

Not too late, assuming there are no object= ions. Smaller QR codes is a very good reason to change it.

=A0

--
--
Gavin Andresen

--e89a8f502c4c4c119b04e7299671-- From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) id 1VOlNH-0002lK-8p for bitcoin-development@lists.sourceforge.net; Wed, 25 Sep 2013 09:27:11 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.214.50 as permitted sender) client-ip=209.85.214.50; envelope-from=mh.in.england@gmail.com; helo=mail-bk0-f50.google.com; Received: from mail-bk0-f50.google.com ([209.85.214.50]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1VOlNG-0006Zv-4Y for bitcoin-development@lists.sourceforge.net; Wed, 25 Sep 2013 09:27:11 +0000 Received: by mail-bk0-f50.google.com with SMTP id mz11so2248478bkb.9 for ; Wed, 25 Sep 2013 02:27:03 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.205.78.5 with SMTP id zk5mr26934814bkb.25.1380101223480; Wed, 25 Sep 2013 02:27:03 -0700 (PDT) Sender: mh.in.england@gmail.com Received: by 10.204.237.74 with HTTP; Wed, 25 Sep 2013 02:27:03 -0700 (PDT) In-Reply-To: References: <521298F0.20108@petersson.at>

Date: Wed, 25 Sep 2013 11:27:03 +0200 X-Google-Sender-Auth: Phtp-EzGXUPX1x6Xc0ZFG1Aq7b4 Message-ID: From: Mike Hearn To: Gavin Andresen Content-Type: multipart/alternative; boundary=f46d041038a72e319f04e731db46 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: 1VOlNG-0006Zv-4Y Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Payment Protocol: BIP 70, 71, 72 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, 25 Sep 2013 09:27:11 -0000 --f46d041038a72e319f04e731db46 Content-Type: text/plain; charset=UTF-8 We could also say that if protocol part (https://) is missing, it's implied automatically. So just: bitcoin:1abc........?r=bob.com/r/aZgR I think that's about as small as possible without re-using the pubkey as a token in the url. On Wed, Sep 25, 2013 at 1:35 AM, Gavin Andresen wrote: > On Tue, Sep 24, 2013 at 11:52 PM, Mike Hearn wrote: > >> BTW, on the "make qrcodes more scannable" front -- is it too late to >> change BIP 72 so the new param is just "r" instead of "request"? Every byte >> helps when it comes to qrcodes ... >> > > Not too late, assuming there are no objections. Smaller QR codes is a very > good reason to change it. > > -- > -- > Gavin Andresen > --f46d041038a72e319f04e731db46 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

We could also say that if protocol part (https://) is miss= ing, it's implied automatically. So just:

bitcoin:1a= bc........?r=3Dbob.com/r/aZgR

I think that's about as small as possible without re-usi= ng the pubkey as a token in the url.

On Tue, S= ep 24, 2013 at 11:52 PM, Mike Hearn <mike@plan99.net> wrote:

BTW, on the "make qrcodes more scannable" front = -- is it too late to change BIP 72 so the new param is just "r" i= nstead of "request"? Every byte helps when it comes to qrcodes ..= .

Not too late, assuming there are no = objections. Smaller QR codes is a very good reason to change it.

=C2=A0

--
--
Gavin Andresen<= br>

It won't fit. But I don't see the logic. A URI con= tains instructions for making a payment. If that instruction is "pay t= o this address" or "download this file and do what you find there= ", it's no different unless there's potential for a MITM attac= k. If the request URL is HTTPS or a secured Bluetooth connection then there= 's no such possibility.

On Wed, Sep 25, 2013 at 12:28 PM, Andreas Schildbach <andreas@schildbach.de> wrote:

While it's good to save space, I'm a= t the moment not convinced that
taking a de-route via an URL is a good idea to begin with.

The main problem is trust. If you scan a QR code from a foreign phone,
you trust that that phone is owned by the one you want to send money to. By adding the HTTP request that trust is voided.

As soon as there is a BIP70 implementation, I will begin playing with
putting the payment request directly into the QR code.

On 09/25/2013 11:27 AM, Mike Hearn wrote:
> We could also say that if protocol part (https://) is missing, it'= s
> implied automatically. So just:
>

> bitcoin:1abc........?r=3Dbob.com/r/aZgR <http://bob.com/r/aZgR>

>
> I think that's about as small as possible without re-using the pub= key as
> a token in the url.
>
>
> On Wed, Sep 25, 2013 at 1:35 AM, Gavin Andresen <gavinandresen@gmail.com

> <mailto:gavinandresen@gmail.com>> wrote:
>
> =C2=A0 =C2=A0 On Tue, Sep 24, 2013 at 11:52 PM, Mike Hearn <mike@plan99.net

> =C2=A0 =C2=A0 <mailto:mike@plan99.net>> wrote:
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 BTW, on the "make qrcodes more scanna= ble" front -- is it too
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 late to change BIP 72 so the new param is = just "r" instead of
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 "request"? Every byte helps when= it comes to qrcodes ...
>
>
> =C2=A0 =C2=A0 Not too late, assuming there are no objections. Smaller = QR codes is
> =C2=A0 =C2=A0 a very good reason to change it.
>
> =C2=A0 =C2=A0 --
> =C2=A0 =C2=A0 --
> =C2=A0 =C2=A0 Gavin Andresen
>
>
>
>

> ----------------------------------------------------------------= --------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance. > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the mo= st from
> the latest Intel processors and coprocessors. See abstracts and regist= er >
> http://pubads.g.doubleclick.net= /gampad/clk?id=3D60133471&iu=3D/4140/ostg.clktrk

>
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-d= evelopment@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitco= in-development
>

---------------------------------------------------------------------= ---------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most fr= om
the latest Intel processors and coprocessors. See abstracts and register &g= t;
http://pubads.g.doubleclick.net/gam= pad/clk?id=3D60133471&iu=3D/4140/ostg.clktrk

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

On 25 September 2013 13:15, Mike Hearn <mike@plan99.net> wrote:

It won't fit. But I don= 't see the logic. A URI contains instructions for making a payment. If = that instruction is "pay to this address" or "download this = file and do what you find there", it's no different unless there&#= 39;s potential for a MITM attack. If the request URL is HTTPS or a secured = Bluetooth connection then there's no such possibility.

It depends on the attacker.=A0 I think a l= arge entity such as a govt or big to medium size corporation *may* be able = to MITM https, of course the incentive to do so is probably not there ...

=A0

On Wed, Sep 25, 2= 013 at 12:28 PM, Andreas Schildbach <andreas@schildbach.de> wrote:

While it's good to save space, I'm a= t the moment not convinced that
taking a de-route via an URL is a good idea to begin with.

The main problem is trust. If you scan a QR code from a foreign phone,
you trust that that phone is owned by the one you want to send money to. By adding the HTTP request that trust is voided.

As soon as there is a BIP70 implementation, I will begin playing with
putting the payment request directly into the QR code.

On 09/25/2013 11:27 AM, Mike Hearn wrote:
> We could also say that if protocol part (https://) is missing, it'= s
> implied automatically. So just:
>

> bitcoin:1abc........?r=3Dbob.com/r/aZgR <http://bob.com/r/aZgR>

>
> I think that's about as small as possible without re-using the pub= key as
> a token in the url.
>
>
> On Wed, Sep 25, 2013 at 1:35 AM, Gavin Andresen <gavinandresen@gmail.com

> <mailto:gavinandresen@gmail.com>> wrote:
>
> =A0 =A0 On Tue, Sep 24, 2013 at 11:52 PM, Mike Hearn <mike@plan99.net

> =A0 =A0 <mailto:mike@plan99.net>> wrote:
>
> =A0 =A0 =A0 =A0 BTW, on the "make qrcodes more scannable" fr= ont -- is it too
> =A0 =A0 =A0 =A0 late to change BIP 72 so the new param is just "r= " instead of
> =A0 =A0 =A0 =A0 "request"? Every byte helps when it comes to= qrcodes ...
>
>
> =A0 =A0 Not too late, assuming there are no objections. Smaller QR cod= es is
> =A0 =A0 a very good reason to change it.
>
> =A0 =A0 --
> =A0 =A0 --
> =A0 =A0 Gavin Andresen
>
>
>
>

> ----------------------------------------------------------------= --------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance. > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the mo= st from
> the latest Intel processors and coprocessors. See abstracts and regist= er >
> http://pubads.g.doubleclick.net= /gampad/clk?id=3D60133471&iu=3D/4140/ostg.clktrk

>
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitco= in-development
>

---------------------------------------------------------------------= ---------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most fr= om
the latest Intel processors and coprocessors. See abstracts and register &g= t;
http://pubads.g.doubleclick.net/gam= pad/clk?id=3D60133471&iu=3D/4140/ostg.clktrk

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

-----------------------------------------------------------= -------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most fr= om
the latest Intel processors and coprocessors. See abstracts and register &g= t;
http://pubads.g.doubleclick.net/gam= pad/clk?id=3D60133471&iu=3D/4140/ostg.clktrk
___________________= ____________________________
Bitcoin-development mailing list
Bitcoin-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment

On Wed, Sep 25, 2013 at 1:33 PM, Andreas Schildbach <= andreas@schildbach.de> wrote:

<= div class=3D"gmail_quote">

Why do you think that? Of course, I woul= d skip the certificate, as its
unnecessary if you see your partner in person.

<= /div>

OK, it might fit if you don't use any of the features the pro= tocol provides :) You can try it here:

https://bitcoincor= e.org/~gavin/createpaymentrequest.php

=C2=A0

HTTPS trust is utterly = broken unless you fix it by adding the

certificate or a fingerprint to the QR code.

It's not "utterly broken", that's over-dramatic.= It's just the best that can be done with todays technology. I wrote ab= out the SSL PKI and how it's being upgraded here:

https://bitcointalk.org/index.php?topic=3D300809.0

If you're thinking about governments and so on subvert= ing CA's, then there is a plan for handling that (outside the Bitcoin w= orld) called certificate transparency which is being implemented now.

Now when you are getting a QR code from the web, it'= ;s already being served over HTTPS. So if you're up against an attacker= who can break a CA in order to steal your money, then you already lose, th= e QRcode itself as MITMd.

In the Bluetooth case we might have to keep the address= around and use it to do ECDHE or something like that. The current BT suppo= rt doesn't need that because it's just blasting out a tx, the entir= e protocol is write only. Once it's reading data as well then it'll= need a custom security layer.

=C2=A0

Low light shouldn't be an issue for QRcodes generated = by phones. They have backlit screens that should always be bright enough. I= can see how it might be an issue for printed codes.

If = your phone has no Bitcoin app installed then being redirected to an invoice= page is pretty useless, you still won't be able to pay the bill no mat= ter what (where do you get the money from?). If they are just raw HTTP URLs= then it means the effect of scanning a QRcode with a standalone scanner ap= p is different to scanning it inside the wallet, which is unlike all other = uses of QRcodes I know of. So I'm not really convinced by that UX yet. = Perhaps we can thrash it out in Amsterdam. Right now I'm thinking QRcod= es should always contain bitcoin URIs.