path: root/1a/c6b93db17bb1632c483cca8973d7347f9010d9

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 <mh.in.england@gmail.com>) id 1WIKtC-0005oB-Ti
	for bitcoin-development@lists.sourceforge.net;
	Tue, 25 Feb 2014 16:29:50 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.214.179 as permitted sender)
	client-ip=209.85.214.179; envelope-from=mh.in.england@gmail.com;
	helo=mail-ob0-f179.google.com; 
Received: from mail-ob0-f179.google.com ([209.85.214.179])
	by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1WIKtB-0001Ob-MB
	for bitcoin-development@lists.sourceforge.net;
	Tue, 25 Feb 2014 16:29:50 +0000
Received: by mail-ob0-f179.google.com with SMTP id wn1so3857181obc.10
	for <bitcoin-development@lists.sourceforge.net>;
	Tue, 25 Feb 2014 08:29:44 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.60.95.5 with SMTP id dg5mr2150351oeb.8.1393345784313; Tue,
	25 Feb 2014 08:29:44 -0800 (PST)
Sender: mh.in.england@gmail.com
Received: by 10.76.71.231 with HTTP; Tue, 25 Feb 2014 08:29:44 -0800 (PST)
In-Reply-To: <81FBEA67-45A9-4531-BEA0-071CE9FAEF7E@kill-bill.org>
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>
Date: Tue, 25 Feb 2014 21:59:44 +0530
X-Google-Sender-Auth: 3DVHkC1XZUsPO7D3u44ML-8w_DY
Message-ID: <CANEZrP0-LqFC8N500=mnKbKE+=UtFw_Y5cHR8JRC-zmmGsSAjA@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Stephane Brossier <stephane@kill-bill.org>
Content-Type: multipart/alternative; boundary=089e01227f508605f404f33d985f
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: 1WIKtB-0001Ob-MB
Cc: Pierre-Alexandre Meyer <pierre@kill-bill.org>,
	Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
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 16:29:51 -0000

--089e01227f508605f404f33d985f
Content-Type: text/plain; charset=UTF-8

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.

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

<div dir=3D"ltr">Hey there,<div><br></div><div>So the essence of this proto=
col is as follows:</div><div><br></div><div><pre style=3D"font-family:Conso=
las,&#39;Liberation Mono&#39;,Courier,monospace;font-size:12px;margin-top:0=
px;margin-bottom:0px;color:rgb(51,51,51);line-height:18px">
<div class=3D"" id=3D"LC72" style=3D"padding-left:10px"><span class=3D"" st=
yle=3D"font-weight:bold">enum</span> <span class=3D"" style>PaymentFrequenc=
yType</span> <span class=3D"" style>{</span></div><div class=3D"" id=3D"LC7=
3" style=3D"padding-left:10px">
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<span class=3D"" style=3D"c=
olor:teal">WEEKLY</span> <span class=3D"" style=3D"font-weight:bold">=3D</s=
pan> <span class=3D"" style=3D"color:rgb(0,153,153)">1</span><span class=3D=
"" style>;</span></div><div class=3D"" id=3D"LC74" style=3D"padding-left:10=
px">
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<span class=3D"" style=3D"c=
olor:teal">MONTHLY</span> <span class=3D"" style=3D"font-weight:bold">=3D</=
span> <span class=3D"" style=3D"color:rgb(0,153,153)">2</span><span class=
=3D"" style>;</span></div><div class=3D"" id=3D"LC75" style=3D"padding-left=
:10px">
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<span class=3D"" style=3D"c=
olor:teal">QUARTERLY</span> <span class=3D"" style=3D"font-weight:bold">=3D=
</span> <span class=3D"" style=3D"color:rgb(0,153,153)">3</span><span class=
=3D"" style>;</span></div><div class=3D"" id=3D"LC76" style=3D"padding-left=
:10px">
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<span class=3D"" style=3D"c=
olor:teal">ANNUAL</span> <span class=3D"" style=3D"font-weight:bold">=3D</s=
pan> <span class=3D"" style=3D"color:rgb(0,153,153)">4</span><span class=3D=
"" style>;</span></div><div class=3D"" id=3D"LC77" style=3D"padding-left:10=
px">
<span class=3D"" style>}</span></div><div class=3D"" id=3D"LC78" style=3D"p=
adding-left:10px"><span class=3D"" style=3D"font-weight:bold">message</span=
> <span class=3D"" style=3D"color:rgb(68,85,136);font-weight:bold">Recurrin=
gPaymentDetails</span> <span class=3D"" style>{</span></div>
<div class=3D"" id=3D"LC78" style=3D"padding-left:10px"><span class=3D"" st=
yle>        </span><span style=3D"color:rgb(153,153,136);font-style:italic"=
>// Namespace for the merchant such as org.foo.bar</span></div><div class=
=3D"" id=3D"LC79" style=3D"padding-left:10px">
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<span class=3D"" style=3D"f=
ont-weight:bold">required</span> <span class=3D"" style=3D"color:rgb(68,85,=
136);font-weight:bold">string</span> <span class=3D"" style=3D"color:teal">=
merchant_id</span> <span class=3D"" style=3D"font-weight:bold">=3D</span> <=
span class=3D"" style=3D"color:rgb(0,153,153)">1</span><span class=3D"" sty=
le>;</span>                 </div>
<div class=3D"" id=3D"LC79" style=3D"padding-left:10px">        <span style=
=3D"color:rgb(153,153,136);font-style:italic">// Id for the recurring subsc=
ription</span></div><div class=3D"" id=3D"LC80" style=3D"padding-left:10px"=
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<span class=3D"" style=3D"=
font-weight:bold">required</span> <span class=3D"" style=3D"color:rgb(68,85=
,136);font-weight:bold">bytes</span> <span class=3D"" style=3D"color:teal">=
subscription_id</span> <span class=3D"" style=3D"font-weight:bold">=3D</spa=
n> <span class=3D"" style=3D"color:rgb(0,153,153)">2</span><span class=3D""=
 style>;</span>              </div>
<div class=3D"" id=3D"LC80" style=3D"padding-left:10px">        <span style=
=3D"color:rgb(153,153,136);font-style:italic">// Contracts associated with =
a given subscription</span></div><div class=3D"" id=3D"LC81" style=3D"paddi=
ng-left:10px">
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<span class=3D"" style=3D"f=
ont-weight:bold">repeated</span> <span class=3D"" style>RecurringPaymentCon=
tract</span> <span class=3D"" style=3D"color:teal">contracts</span> <span c=
lass=3D"" style=3D"font-weight:bold">=3D</span> <span class=3D"" style=3D"c=
olor:rgb(0,153,153)">3</span><span class=3D"" style>;</span> </div>
<div class=3D"" id=3D"LC82" style=3D"padding-left:10px"><span class=3D"" st=
yle>}</span></div><div class=3D"" id=3D"LC83" style=3D"padding-left:10px"><=
span class=3D"" style=3D"font-weight:bold">message</span> <span class=3D"" =
style=3D"color:rgb(68,85,136);font-weight:bold">RecurringPaymentContract</s=
pan> <span class=3D"" style>{</span></div>
<div class=3D"" id=3D"LC83" style=3D"padding-left:10px"><span class=3D"" st=
yle>        </span><span style=3D"color:rgb(153,153,136);font-style:italic"=
>// Unique id for a given contract</span></div><div class=3D"" id=3D"LC84" =
style=3D"padding-left:10px">
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<span class=3D"" style=3D"f=
ont-weight:bold">required</span> <span class=3D"" style=3D"color:rgb(68,85,=
136);font-weight:bold">bytes</span> <span class=3D"" style=3D"color:teal">c=
ontract_id</span> <span class=3D"" style=3D"font-weight:bold">=3D</span> <s=
pan class=3D"" style=3D"color:rgb(0,153,153)">1</span><span class=3D"" styl=
e>;</span>                           </div>
<div class=3D"" id=3D"LC84" style=3D"padding-left:10px">        <span style=
=3D"color:rgb(153,153,136);font-style:italic">// URL to poll to get the nex=
t PaymentRequest</span></div><div class=3D"" id=3D"LC85" style=3D"padding-l=
eft:10px">
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<span class=3D"" style=3D"f=
ont-weight:bold">required</span> <span class=3D"" style=3D"color:rgb(68,85,=
136);font-weight:bold">string</span> <span class=3D"" style=3D"color:teal">=
polling_url</span> <span class=3D"" style=3D"font-weight:bold">=3D</span> <=
span class=3D"" style=3D"color:rgb(0,153,153)">2</span><span class=3D"" sty=
le>;</span>                          </div>
<div class=3D"" id=3D"LC85" style=3D"padding-left:10px">        <span style=
=3D"color:rgb(153,153,136);font-style:italic">// Timestamp; when this contr=
act starts</span></div><div class=3D"" id=3D"LC86" style=3D"padding-left:10=
px">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<span class=3D"" style=
=3D"font-weight:bold">required</span> <span class=3D"" style=3D"color:rgb(6=
8,85,136);font-weight:bold">uint64</span> <span class=3D"" style=3D"color:t=
eal">starts</span> <span class=3D"" style=3D"font-weight:bold">=3D</span> <=
span class=3D"" style=3D"color:rgb(0,153,153)">3</span><span class=3D"" sty=
le>;</span>                               </div>
<div class=3D"" id=3D"LC86" style=3D"padding-left:10px">        <span style=
=3D"color:rgb(153,153,136);font-style:italic">// Timestamp; when this contr=
act should be considered invalid </span></div><div class=3D"" id=3D"LC87" s=
tyle=3D"padding-left:10px">
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<span class=3D"" style=3D"f=
ont-weight:bold">optional</span> <span class=3D"" style=3D"color:rgb(68,85,=
136);font-weight:bold">uint64</span> <span class=3D"" style=3D"color:teal">=
ends</span> <span class=3D"" style=3D"font-weight:bold">=3D</span> <span cl=
ass=3D"" style=3D"color:rgb(0,153,153)">4</span><span class=3D"" style>;</s=
pan>                                 </div>
<div class=3D"" id=3D"LC87" style=3D"padding-left:10px">        <span style=
=3D"color:rgb(153,153,136);font-style:italic">// Expected payment frequency=
</span></div><div class=3D"" id=3D"LC88" style=3D"padding-left:10px">=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<span class=3D"" style=3D"font-we=
ight:bold">optional</span> <span class=3D"" style>PaymentFrequencyType</spa=
n> <span class=3D"" style=3D"color:teal">payment_frequency_type</span> <spa=
n class=3D"" style=3D"font-weight:bold">=3D</span> <span class=3D"" style=
=3D"color:rgb(0,153,153)">5</span><span class=3D"" style>;</span> </div>
<div class=3D"" id=3D"LC88" style=3D"padding-left:10px">        <span style=
=3D"color:rgb(153,153,136);font-style:italic">// Max payment amount within =
that frequency (e.g. no more than 5 BTC per month)</span></div><div class=
=3D"" id=3D"LC89" style=3D"padding-left:10px">
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<span class=3D"" style=3D"f=
ont-weight:bold">optional</span> <span class=3D"" style=3D"color:rgb(68,85,=
136);font-weight:bold">uint64</span> <span class=3D"" style=3D"color:teal">=
max_payment_per_period</span>  <span class=3D"" style=3D"font-weight:bold">=
=3D</span> <span class=3D"" style=3D"color:rgb(0,153,153)">6</span><span cl=
ass=3D"" style>;</span>              </div>
<div class=3D"" id=3D"LC89" style=3D"padding-left:10px">        <span style=
=3D"color:rgb(153,153,136);font-style:italic">// Max payment amount (e.g. n=
o more than 3 BTC per payment)</span></div><div class=3D"" id=3D"LC90" styl=
e=3D"padding-left:10px">
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<span class=3D"" style=3D"f=
ont-weight:bold">optional</span> <span class=3D"" style=3D"color:rgb(68,85,=
136);font-weight:bold">uint64</span> <span class=3D"" style=3D"color:teal">=
max_payment_amount</span> <span class=3D"" style=3D"font-weight:bold">=3D</=
span> <span class=3D"" style=3D"color:rgb(0,153,153)">7</span><span class=
=3D"" style>;</span>                   </div>
<div><span class=3D"" style=3D"color:rgb(153,153,136);font-style:italic">}<=
/span></div><div><span class=3D"" style=3D"color:rgb(153,153,136);font-styl=
e: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>

--089e01227f508605f404f33d985f--