path: root/be/7cd2f1c844adad5f663a786bd2ea359f089110

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 <drak@zikula.org>) id 1WIN3Y-00075V-SP
	for bitcoin-development@lists.sourceforge.net;
	Tue, 25 Feb 2014 18:48:40 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of zikula.org
	designates 74.125.82.44 as permitted sender)
	client-ip=74.125.82.44; envelope-from=drak@zikula.org;
	helo=mail-wg0-f44.google.com; 
Received: from mail-wg0-f44.google.com ([74.125.82.44])
	by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1WIN3X-00064k-2q
	for bitcoin-development@lists.sourceforge.net;
	Tue, 25 Feb 2014 18:48:40 +0000
Received: by mail-wg0-f44.google.com with SMTP id a1so770386wgh.3
	for <bitcoin-development@lists.sourceforge.net>;
	Tue, 25 Feb 2014 10:48:32 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:from:date
	:message-id:subject:to:cc:content-type;
	bh=LLPbMEH6OzC3CHEU2oeiQDFPme9msH+YbBw+RqRpsiQ=;
	b=Y6p41A/PF2wnoIukOj6Kdhw/Q1AJnETJnYQTMqiGbRxbiCek0YrkxO4VQsA5Ufjy6j
	zMgVqGpOxPI2ZL5kYGkqTtRf4uujS2dXV7c1maI+VIM4qI5HG0XGvTDjmwffnWUOoVgP
	m1vTBvMuefftmXyYHD+4D1eJ21ZfJiKZ1M7uXVfFTG1Yh7Za6IEDeBN9mzS+tlvifWL6
	4T0dN2MWv/Qbkts7QG7wuP8neW/I7mIS4Wc4YIc8vzkHR/8pWtPzWgcLDWZPIAqfKXM1
	ahwkkF1LqKbxIVO+E1+UChKTwETlWHwh6psNR+MmC5dqPQW4nK4tCSX5qIbHVLb7U3iC
	7x3g==
X-Gm-Message-State: ALoCoQnRwczXf9nEZidlEcIY1JV6GQx1ASd4S2f+IZAiMArs2N82Ax1ym1BeWYKwiZ1wHBk6hokr
X-Received: by 10.194.61.210 with SMTP id s18mr26248406wjr.10.1393353623527;
	Tue, 25 Feb 2014 10:40:23 -0800 (PST)
MIME-Version: 1.0
Received: by 10.194.205.69 with HTTP; Tue, 25 Feb 2014 10:40:03 -0800 (PST)
In-Reply-To: <CANEZrP0-LqFC8N500=mnKbKE+=UtFw_Y5cHR8JRC-zmmGsSAjA@mail.gmail.com>
References: <E1FDB3F2-25ED-4B99-979E-12CE943CBD66@kill-bill.org>
	<CANEZrP10z6_UAHD97mj22kVEGyXgHPQ2PdP_8RxHT5Py+xRP_A@mail.gmail.com>
	<D6BCC0C4-EF22-4DE8-868E-825D19C387E3@kill-bill.org>
	<CANEZrP0FzTGmp1zbaW1VHJLk5117ZnTSehfF4uMX=+UFS+R_Dw@mail.gmail.com>
	<0CC0BE1D-1DAA-4994-B034-EB7712F845CF@kill-bill.org>
	<DBA255DB-4839-4C3A-BA62-BD3926995C12@kill-bill.org>
	<CAEY8wq6F33814d2+97AqDoAicvh=0PigHZ03wHadMq6JqtQMLg@mail.gmail.com>
	<EAEC76DA-A490-4A61-BFB7-611D4ADF1680@kill-bill.org>
	<CAEY8wq5=pAMTqDPM8yeCF+Z2=1GWmD0UDQdgacN1o3jAUh_BYA@mail.gmail.com>
	<CAEY8wq40RxeUYYJS2m=xq26iTd2NE64WR7QOUO0+yR-MJQCoxQ@mail.gmail.com>
	<5F91BEBF-ECDD-4CBD-A85E-FD7E7DB3F01F@kill-bill.org>
	<81FBEA67-45A9-4531-BEA0-071CE9FAEF7E@kill-bill.org>
	<CANEZrP0-LqFC8N500=mnKbKE+=UtFw_Y5cHR8JRC-zmmGsSAjA@mail.gmail.com>
From: Drak <drak@zikula.org>
Date: Tue, 25 Feb 2014 18:40:03 +0000
Message-ID: <CANAnSg3LF6m9u-MV8XiiomMPrbihJh7hm5o=menOWY71bLkdAg@mail.gmail.com>
To: Mike Hearn <mike@plan99.net>
Content-Type: multipart/alternative; boundary=047d7b86d586c6f79704f33f6b48
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 SPF_PASS               SPF: sender matches SPF record
	1.0 HTML_MESSAGE           BODY: HTML included in message
X-Headers-End: 1WIN3X-00064k-2q
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>,
	Stephane Brossier <stephane@kill-bill.org>,
	Pierre-Alexandre Meyer <pierre@kill-bill.org>
Subject: Re: [Bitcoin-development] Extension for BIP-0070 to support
	recurring payments
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, 25 Feb 2014 18:48:41 -0000

--047d7b86d586c6f79704f33f6b48
Content-Type: text/plain; charset=UTF-8

Forgive me if I missed it, but the spec doesnt look like it can handle only
handle periods of per week, per month, per quarter rather than 'n period'.
I take Paypal as a reference example for subscription payments where you
can set recurring to every: n days, n weeks, n months, n years. That way a
quarterly payment is every 3 months. This fine granularity is necessary
because sometime a payment scheme can be per 4 weekly rather than per
monthly.

So in summary the spec needs daily as an option, and to specify the
recurring cycle as every n*period (one of daily, weekly, monthly, yearly):
and you can drop quarterly since it's just expressed as per 3*monthly.

Drak


On 25 February 2014 16:29, Mike Hearn <mike@plan99.net> wrote:

> Hey there,
>
> So the essence of this protocol is as follows:
>
> enum PaymentFrequencyType {
>
>         WEEKLY = 1;
>
>         MONTHLY = 2;
>
>         QUARTERLY = 3;
>
>         ANNUAL = 4;
> }
> message RecurringPaymentDetails {
>         // Namespace for the merchant such as org.foo.bar
>
>         required string merchant_id = 1;
>
>         // Id for the recurring subscription
>         required bytes subscription_id = 2;
>
>         // Contracts associated with a given subscription
>
>         repeated RecurringPaymentContract contracts = 3;
>
> }
> message RecurringPaymentContract {
>
>         // Unique id for a given contract
>
>         required bytes contract_id = 1;
>
>         // URL to poll to get the next PaymentRequest
>
>         required string polling_url = 2;
>
>         // Timestamp; when this contract starts
>         required uint64 starts = 3;
>
>         // Timestamp; when this contract should be considered invalid
>
>         optional uint64 ends = 4;
>
>         // Expected payment frequency
>         optional PaymentFrequencyType payment_frequency_type = 5;
>
>         // Max payment amount within that frequency (e.g. no more than 5 BTC per month)
>
>         optional uint64 max_payment_per_period  = 6;
>
>         // Max payment amount (e.g. no more than 3 BTC per payment)
>
>         optional uint64 max_payment_amount = 7;
>
> }
>
> I have the following comments:
>
>    1. There's no need to serialize RecurringPaymentDetails as bytes here.
>    It's done that way outside of PaymentDetails in order to support digital
>    signatures over protobufs that may have extensions the wallet app isn't
>    aware of, but it's a pain and inside PaymentDetails (and therefore for most
>    extensions) it shouldn't be necessary. So you can just use "optional
>    RecurringPamentDetails recurring_payments = 8;"
>
>    2. There's only 4 possibilities here for recurrences. That seems
>    rather restrictive. Is the cost of being more expressive really so high?
>    Why not allow more flexible specification of periods?
>
>    3. If there's no payment_frequency_type field then what happens? A
>    quirk of protobufs to be aware of is that making an enum field "required"
>    can hurt backwards compatibility. Because it will be expressed using a
>    languages underlying enum type, if there's a new enum member added later
>    old software that attempts to deserialize this will throw exceptions
>    because the new "unknown" member would be unrepresentable in the old model.
>    Making the field optional avoids this problem (it will be treated as
>    missing instead) but means software needs to be written to know what to do
>    when it can't read the enum value / sees enum values from the future.
>
>    4. I assume the amounts are specified in terms of satoshi, and
>    timestamps are UNIX time, but better to make that explicit.
>
>    5. Seems there's an implicit value constraint that max_payment_amount
>    <= max_payment_per_period. What happens if that constraint is violated?
>    Best to document that.
>
>    6. What's the "merchant ID" namespace thing about? What's it for? What
>    happens if I set my competitors merchant ID there?
>
>    7. What's the "subscription ID"? Is this stuff not
>    duplicative/redundant with the existing merchant_data field?
>
>    8. In what situations would you have >1 contract per payment request?
>    I'm not sure I understand why it's repeated. Presumably if there are zero
>    contracts included the data should be ignored, or an error thrown and the
>    entire payment request rejected? Which should it be?
>
>    9. It's unclear to me given such a contract when the payment should
>    actually occur. For instance if it's "monthly" then what day in the month
>    would the payment occur?
>
>    10. You'll notice I moved the comments to be above the field
>    definitions. I know the current proto isn't done that way, but let's change
>    it - long comments are good and putting them above the field definitions
>    encourages people to write enough detail without being put off by line
>    length constraints
>
>
> I think the next step would be to talk to BitPay/get Jeff+Stephen involved
> because I know they have customers that really want recurring payments, and
> those guys will have a clearer idea of customer requirements than we do. I
> feel uncomfortable with designing or reviewing in a vacuum without some
> actual people who would use it chiming in, as I don't really know much
> about the underlying business processes.
>
> I have some other comments about the bitcoinj implementation specifically
> - for instance, we don't have a "wallet directory" concept: everything goes
> into the wallet file. So we'll need to think about how to structure the
> code to allow that. Also, just using a background polling thread is likely
> not flexible enough, as on some platforms you can't stay running all the
> time (e.g. Android) without upsetting people, but the underlying OS can
> wake you up at the right times, so wallet apps should have an ability to
> control wakeup tasks. But we can discuss that over on the bitcoinj list
> specifically. Let's keep this thread for the general protocol design.
>
> BIP 70 is indeed implemented in Bitcoin Core on the C++ side, so that
> isn't a concern. It could be done there too.
>
>
>
> ------------------------------------------------------------------------------
> Flow-based real-time traffic analytics software. Cisco certified tool.
> Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
> Customize your own dashboards, set traffic alerts and generate reports.
> Network behavioral analysis & security monitoring. All-in-one tool.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

--047d7b86d586c6f79704f33f6b48
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Forgive me if I missed it, but the spec doesnt look like i=
t can handle only handle periods of per week, per month, per quarter rather=
 than &#39;n period&#39;. I take Paypal as a reference example for subscrip=
tion payments where you can set recurring to every: n days, n weeks, n mont=
hs, n years. That way a quarterly payment is every 3 months. This fine gran=
ularity is necessary because sometime a payment scheme can be per 4 weekly =
rather than per monthly.<div>

<br></div><div>So in summary the spec needs daily as an option, and to spec=
ify the recurring cycle as every n*period (one of daily, weekly, monthly, y=
early): and you can drop quarterly since it&#39;s just expressed as per 3*m=
onthly.</div>

<div><br>Drak</div></div><div class=3D"gmail_extra"><br><br><div class=3D"g=
mail_quote">On 25 February 2014 16:29, Mike Hearn <span dir=3D"ltr">&lt;<a =
href=3D"mailto:mike@plan99.net" target=3D"_blank">mike@plan99.net</a>&gt;</=
span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">Hey there,<div><br></div><d=
iv>So the essence of this protocol is as follows:</div><div><br></div><div>=
<pre style=3D"font-family:Consolas,&#39;Liberation Mono&#39;,Courier,monosp=
ace;font-size:12px;margin-top:0px;margin-bottom:0px;color:rgb(51,51,51);lin=
e-height:18px">

<div style=3D"padding-left:10px"><span style=3D"font-weight:bold">enum</spa=
n> <span>PaymentFrequencyType</span> <span>{</span></div><div style=3D"padd=
ing-left:10px">
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<span style=3D"color:teal">=
WEEKLY</span> <span style=3D"font-weight:bold">=3D</span> <span style=3D"co=
lor:rgb(0,153,153)">1</span><span>;</span></div><div style=3D"padding-left:=
10px">
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<span style=3D"color:teal">=
MONTHLY</span> <span style=3D"font-weight:bold">=3D</span> <span style=3D"c=
olor:rgb(0,153,153)">2</span><span>;</span></div><div style=3D"padding-left=
:10px">
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<span style=3D"color:teal">=
QUARTERLY</span> <span style=3D"font-weight:bold">=3D</span> <span style=3D=
"color:rgb(0,153,153)">3</span><span>;</span></div><div style=3D"padding-le=
ft:10px">
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<span style=3D"color:teal">=
ANNUAL</span> <span style=3D"font-weight:bold">=3D</span> <span style=3D"co=
lor:rgb(0,153,153)">4</span><span>;</span></div><div style=3D"padding-left:=
10px">
<span>}</span></div><div style=3D"padding-left:10px"><span style=3D"font-we=
ight:bold">message</span> <span style=3D"color:rgb(68,85,136);font-weight:b=
old">RecurringPaymentDetails</span> <span>{</span></div>
<div style=3D"padding-left:10px"><span>        </span><span style=3D"color:=
rgb(153,153,136);font-style:italic">// Namespace for the merchant such as o=
rg.foo.bar</span></div><div style=3D"padding-left:10px">
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<span style=3D"font-weight:=
bold">required</span> <span style=3D"color:rgb(68,85,136);font-weight:bold"=
>string</span> <span style=3D"color:teal">merchant_id</span> <span style=3D=
"font-weight:bold">=3D</span> <span style=3D"color:rgb(0,153,153)">1</span>=
<span>;</span>                 </div>


<div style=3D"padding-left:10px">        <span style=3D"color:rgb(153,153,1=
36);font-style:italic">// Id for the recurring subscription</span></div><di=
v style=3D"padding-left:10px">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0<span style=3D"font-weight:bold">required</span> <span style=3D"color:rg=
b(68,85,136);font-weight:bold">bytes</span> <span style=3D"color:teal">subs=
cription_id</span> <span style=3D"font-weight:bold">=3D</span> <span style=
=3D"color:rgb(0,153,153)">2</span><span>;</span>              </div>


<div style=3D"padding-left:10px">        <span style=3D"color:rgb(153,153,1=
36);font-style:italic">// Contracts associated with a given subscription</s=
pan></div><div style=3D"padding-left:10px">
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<span style=3D"font-weight:=
bold">repeated</span> <span>RecurringPaymentContract</span> <span style=3D"=
color:teal">contracts</span> <span style=3D"font-weight:bold">=3D</span> <s=
pan style=3D"color:rgb(0,153,153)">3</span><span>;</span> </div>


<div style=3D"padding-left:10px"><span>}</span></div><div style=3D"padding-=
left:10px"><span style=3D"font-weight:bold">message</span> <span style=3D"c=
olor:rgb(68,85,136);font-weight:bold">RecurringPaymentContract</span> <span=
>{</span></div>


<div style=3D"padding-left:10px"><span>        </span><span style=3D"color:=
rgb(153,153,136);font-style:italic">// Unique id for a given contract</span=
></div><div style=3D"padding-left:10px">
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<span style=3D"font-weight:=
bold">required</span> <span style=3D"color:rgb(68,85,136);font-weight:bold"=
>bytes</span> <span style=3D"color:teal">contract_id</span> <span style=3D"=
font-weight:bold">=3D</span> <span style=3D"color:rgb(0,153,153)">1</span><=
span>;</span>                           </div>


<div style=3D"padding-left:10px">        <span style=3D"color:rgb(153,153,1=
36);font-style:italic">// URL to poll to get the next PaymentRequest</span>=
</div><div style=3D"padding-left:10px">
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<span style=3D"font-weight:=
bold">required</span> <span style=3D"color:rgb(68,85,136);font-weight:bold"=
>string</span> <span style=3D"color:teal">polling_url</span> <span style=3D=
"font-weight:bold">=3D</span> <span style=3D"color:rgb(0,153,153)">2</span>=
<span>;</span>                          </div>


<div style=3D"padding-left:10px">        <span style=3D"color:rgb(153,153,1=
36);font-style:italic">// Timestamp; when this contract starts</span></div>=
<div style=3D"padding-left:10px">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0<span style=3D"font-weight:bold">required</span> <span style=3D"color=
:rgb(68,85,136);font-weight:bold">uint64</span> <span style=3D"color:teal">=
starts</span> <span style=3D"font-weight:bold">=3D</span> <span style=3D"co=
lor:rgb(0,153,153)">3</span><span>;</span>                               </=
div>


<div style=3D"padding-left:10px">        <span style=3D"color:rgb(153,153,1=
36);font-style:italic">// Timestamp; when this contract should be considere=
d invalid </span></div><div style=3D"padding-left:10px">
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<span style=3D"font-weight:=
bold">optional</span> <span style=3D"color:rgb(68,85,136);font-weight:bold"=
>uint64</span> <span style=3D"color:teal">ends</span> <span style=3D"font-w=
eight:bold">=3D</span> <span style=3D"color:rgb(0,153,153)">4</span><span>;=
</span>                                 </div>


<div style=3D"padding-left:10px">        <span style=3D"color:rgb(153,153,1=
36);font-style:italic">// Expected payment frequency</span></div><div style=
=3D"padding-left:10px">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<spa=
n style=3D"font-weight:bold">optional</span> <span>PaymentFrequencyType</sp=
an> <span style=3D"color:teal">payment_frequency_type</span> <span style=3D=
"font-weight:bold">=3D</span> <span style=3D"color:rgb(0,153,153)">5</span>=
<span>;</span> </div>


<div style=3D"padding-left:10px">        <span style=3D"color:rgb(153,153,1=
36);font-style:italic">// Max payment amount within that frequency (e.g. no=
 more than 5 BTC per month)</span></div><div style=3D"padding-left:10px">
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<span style=3D"font-weight:=
bold">optional</span> <span style=3D"color:rgb(68,85,136);font-weight:bold"=
>uint64</span> <span style=3D"color:teal">max_payment_per_period</span>  <s=
pan style=3D"font-weight:bold">=3D</span> <span style=3D"color:rgb(0,153,15=
3)">6</span><span>;</span>              </div>


<div style=3D"padding-left:10px">        <span style=3D"color:rgb(153,153,1=
36);font-style:italic">// Max payment amount (e.g. no more than 3 BTC per p=
ayment)</span></div><div style=3D"padding-left:10px">
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<span style=3D"font-weight:=
bold">optional</span> <span style=3D"color:rgb(68,85,136);font-weight:bold"=
>uint64</span> <span style=3D"color:teal">max_payment_amount</span> <span s=
tyle=3D"font-weight:bold">=3D</span> <span style=3D"color:rgb(0,153,153)">7=
</span><span>;</span>                   </div>


<div><span style=3D"color:rgb(153,153,136);font-style:italic">}</span></div=
><div><span style=3D"color:rgb(153,153,136);font-style:italic"><br></span><=
/div></pre></div><div>I have the following comments:</div>
<div><ol><li>There&#39;s no need to serialize RecurringPaymentDetails as by=
tes here. It&#39;s done that way outside of PaymentDetails in order to supp=
ort digital signatures over protobufs that may have extensions the wallet a=
pp isn&#39;t aware of, but it&#39;s a pain and inside PaymentDetails (and t=
herefore for most extensions) it shouldn&#39;t be necessary. So you can jus=
t use &quot;optional RecurringPamentDetails recurring_payments =3D 8;&quot;=
<br>


<br></li><li>There&#39;s only 4 possibilities here for recurrences. That se=
ems rather restrictive. Is the cost of being more expressive really so high=
? Why not allow more flexible specification of periods?<br><br></li><li>


If there&#39;s no payment_frequency_type field then what happens? A quirk o=
f protobufs to be aware of is that making an enum field &quot;required&quot=
; can hurt backwards compatibility. Because it will be expressed using a la=
nguages underlying enum type, if there&#39;s a new enum member added later =
old software that attempts to deserialize this will throw exceptions becaus=
e the new &quot;unknown&quot; member would be unrepresentable in the old mo=
del. Making the field optional avoids this problem (it will be treated as m=
issing instead) but means software needs to be written to know what to do w=
hen it can&#39;t read the enum value / sees enum values from the future.<br=
>


<br></li><li>I assume the amounts are specified in terms of satoshi, and ti=
mestamps are UNIX time, but better to make that explicit.<br><br></li><li>S=
eems there&#39;s an implicit value constraint that max_payment_amount &lt;=
=3D max_payment_per_period. What happens if that constraint is violated? Be=
st to document that.<br>


<br></li><li>What&#39;s the &quot;merchant ID&quot; namespace thing about? =
What&#39;s it for? What happens if I set my competitors merchant ID there?<=
br><br></li><li>What&#39;s the &quot;subscription ID&quot;? Is this stuff n=
ot duplicative/redundant with the existing merchant_data field?<br>


<br></li><li>In what situations would you have &gt;1 contract per payment r=
equest? I&#39;m not sure I understand why it&#39;s repeated. Presumably if =
there are zero contracts included the data should be ignored, or an error t=
hrown and the entire payment request rejected? Which should it be?<br>


<br></li><li>It&#39;s unclear to me given such a contract when the payment =
should actually occur. For instance if it&#39;s &quot;monthly&quot; then wh=
at day in the month would the payment occur?<br><br></li><li>You&#39;ll not=
ice I moved the comments to be above the field definitions. I know the curr=
ent proto isn&#39;t done that way, but let&#39;s change it - long comments =
are good and putting them above the field definitions encourages people to =
write enough detail without being put off by line length constraints</li>


</ol></div><div><br></div><div>I think the next step would be to talk to Bi=
tPay/get Jeff+Stephen involved because I know they have customers that real=
ly want recurring payments, and those guys will have a clearer idea of cust=
omer requirements than we do. I feel uncomfortable with designing or review=
ing in a vacuum without some actual people who would use it chiming in, as =
I don&#39;t really know much about the underlying business processes.</div>


<div><br></div><div>I have some other comments about the bitcoinj implement=
ation specifically - for instance, we don&#39;t have a &quot;wallet directo=
ry&quot; concept: everything goes into the wallet file. So we&#39;ll need t=
o think about how to structure the code to allow that. Also, just using a b=
ackground polling thread is likely not flexible enough, as on some platform=
s you can&#39;t stay running all the time (e.g. Android) without upsetting =
people, but the underlying OS can wake you up at the right times, so wallet=
 apps should have an ability to control wakeup tasks. But we can discuss th=
at over on the bitcoinj list specifically. Let&#39;s keep this thread for t=
he general protocol design.</div>


<div><br></div><div class=3D"gmail_extra">BIP 70 is indeed implemented in B=
itcoin Core on the C++ side, so that isn&#39;t a concern. It could be done =
there too.<br><br></div></div>
<br>-----------------------------------------------------------------------=
-------<br>
Flow-based real-time traffic analytics software. Cisco certified tool.<br>
Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer<br>
Customize your own dashboards, set traffic alerts and generate reports.<br>
Network behavioral analysis &amp; security monitoring. All-in-one tool.<br>
<a href=3D"http://pubads.g.doubleclick.net/gampad/clk?id=3D126839071&amp;iu=
=3D/4140/ostg.clktrk" target=3D"_blank">http://pubads.g.doubleclick.net/gam=
pad/clk?id=3D126839071&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></div>

--047d7b86d586c6f79704f33f6b48--