Re: [Bitcoin-development] BIP70: PaymentACK semantics

2014-01-28 Thread Mike Hearn
Yeah, that's the interpretation I think we should go with for now. There
was a reason why this isn't specified and I forgot what it was - some
inability to come to agreement on when to broadcast vs when to submit via
HTTP, I think.




On Mon, Jan 27, 2014 at 11:39 PM, Kevin Greene kgree...@gmail.com wrote:

  Should the wallet broadcast the transaction to the bitcoin network when
 it
  receives an ACK, or always assume that the merchant server will do that?
 
  In my opinion, that should be the primary meaning of receiving an ACK:
  acknowledgement that the receiver takes responsibility for getting the
  transaction confirmed (to the extent possible, of course).

 Ok, so if there is no
 payment
 _url specified in the PaymentRequest, then the wallet is responsible for
 broadcasting
 the transaction to the bitcoin network
 .
 Otherwise, the wallet should
 rely on the merchant server to broadcast.


 On Mon, Jan 27, 2014 at 2:17 PM, Pieter Wuille pieter.wui...@gmail.comwrote:

 On Mon, Jan 27, 2014 at 11:03 PM, Kevin Greene kgree...@gmail.com
 wrote:
  +1 for an error field.

 Agree, I think we need a way for client applications to interpret the
 response.

  Should the wallet broadcast the transaction to the bitcoin network when
 it
  receives an ACK, or always assume that the merchant server will do that?

 In my opinion, that should be the primary meaning of receiving an ACK:
 acknowledgement that the receiver takes responsibility for getting the
 transaction confirmed (to the extent possible, of course).



 --
 Pieter



--
WatchGuard Dimension instantly turns raw network data into actionable 
security intelligence. It gives you real-time visual feedback on key
security issues and trends.  Skip the complicated setup - simply import
a virtual appliance and go from zero to informed in seconds.
http://pubads.g.doubleclick.net/gampad/clk?id=123612991iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] BIP70: PaymentACK semantics

2014-01-28 Thread Gavin Andresen
On Tue, Jan 28, 2014 at 6:42 AM, Mike Hearn m...@plan99.net wrote:

 Yeah, that's the interpretation I think we should go with for now. There
 was a reason why this isn't specified and I forgot what it was - some
 inability to come to agreement on when to broadcast vs when to submit via
 HTTP, I think.


If the wallet software is doing automatic CoinJoin (for example), then
typically one or several of the other participants will broadcast the
transaction as soon as it is complete.

If the spec said that wallets must not broadcast until they receive a
PaymentACK (if a payment_url is specified), then you'd have to violate the
spec to do CoinJoin.

And even if you don't care about CoinJoin, not broadcasting the transaction
as soon as the inputs are signed adds implementation complexity (should you
retry if payment_url is unavailable? how many times? if you eventually
unlock the probably-not-quite-spent-yet inputs, should you double-spend
them to yourself just in case the merchant eventually gets around to
broadcasting the transaction, or should you just unlock them and squirrel
away the failed Payment so if the merchant does eventually broadcast you
have a record of why the coins were spent).

-- 
--
Gavin Andresen
--
WatchGuard Dimension instantly turns raw network data into actionable 
security intelligence. It gives you real-time visual feedback on key
security issues and trends.  Skip the complicated setup - simply import
a virtual appliance and go from zero to informed in seconds.
http://pubads.g.doubleclick.net/gampad/clk?id=123612991iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] BIP70: PaymentACK semantics

2014-01-28 Thread Pieter Wuille
On Tue, Jan 28, 2014 at 1:53 PM, Gavin Andresen gavinandre...@gmail.com wrote:
 On Tue, Jan 28, 2014 at 6:42 AM, Mike Hearn m...@plan99.net wrote:

 Yeah, that's the interpretation I think we should go with for now. There
 was a reason why this isn't specified and I forgot what it was - some
 inability to come to agreement on when to broadcast vs when to submit via
 HTTP, I think.


 If the wallet software is doing automatic CoinJoin (for example), then
 typically one or several of the other participants will broadcast the
 transaction as soon as it is complete.

 If the spec said that wallets must not broadcast until they receive a
 PaymentACK (if a payment_url is specified), then you'd have to violate the
 spec to do CoinJoin.

You cannot prevent transactions from being broadcasted, but an ACK can
still mean You're now relieved of the responsibility of getting the
transaction confirmed. That's independent from being allowed to
broadcast it.

 And even if you don't care about CoinJoin, not broadcasting the transaction
 as soon as the inputs are signed adds implementation complexity (should you
 retry if payment_url is unavailable? how many times? if you eventually
 unlock the probably-not-quite-spent-yet inputs, should you double-spend them
 to yourself just in case the merchant eventually gets around to broadcasting
 the transaction, or should you just unlock them and squirrel away the failed
 Payment so if the merchant does eventually broadcast you have a record of
 why the coins were spent).

If a payment_url is unavailable, you should imho retry. If you
broadcasted, and the payment_url is unavailable, you should
*certainly* retry. Otherwise the recipient cannot rely on receiving
memo and refund address, which would imho make these fields completely
useless.

I still like suggesting not broadcasting if a payment_uri to minimize
that risk further, but as you say - there are enough cases where you
cannot enforce that anyway.

-- 
Pieter

--
WatchGuard Dimension instantly turns raw network data into actionable 
security intelligence. It gives you real-time visual feedback on key
security issues and trends.  Skip the complicated setup - simply import
a virtual appliance and go from zero to informed in seconds.
http://pubads.g.doubleclick.net/gampad/clk?id=123612991iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] BIP70: PaymentACK semantics

2014-01-28 Thread Mike Hearn

 And even if you don't care about CoinJoin, not broadcasting the
 transaction as soon as the inputs are signed adds implementation complexity
 (should you retry if payment_url is unavailable? how many times?


I guess a lot of wallets just won't broadcast at all and try to submit via
the URL. If they don't succeed, then the transaction is just never
committed to the wallet. Doesn't seem like a big deal. Payment submission
is online, interactive. If it fails, you keep the coins. This seems simple
and straightforward.

If someone really wanted to do a real-time coinjoin, they can build the
transaction together and submit it via payment_url, and broadcast as well.
If the merchant has an issue with the payment for some reason (e.g. request
is expired or the tx is non-standard), well, you'll have to sort it out
with them manually.
--
WatchGuard Dimension instantly turns raw network data into actionable 
security intelligence. It gives you real-time visual feedback on key
security issues and trends.  Skip the complicated setup - simply import
a virtual appliance and go from zero to informed in seconds.
http://pubads.g.doubleclick.net/gampad/clk?id=123612991iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] BIP70: PaymentACK semantics

2014-01-28 Thread Peter Todd
On Tue, Jan 28, 2014 at 07:53:14AM -0500, Gavin Andresen wrote:
 On Tue, Jan 28, 2014 at 6:42 AM, Mike Hearn m...@plan99.net wrote:
 
  Yeah, that's the interpretation I think we should go with for now. There
  was a reason why this isn't specified and I forgot what it was - some
  inability to come to agreement on when to broadcast vs when to submit via
  HTTP, I think.
 
 
 If the wallet software is doing automatic CoinJoin (for example), then
 typically one or several of the other participants will broadcast the
 transaction as soon as it is complete.
 
 If the spec said that wallets must not broadcast until they receive a
 PaymentACK (if a payment_url is specified), then you'd have to violate the
 spec to do CoinJoin.
 
 And even if you don't care about CoinJoin, not broadcasting the transaction
 as soon as the inputs are signed adds implementation complexity (should you
 retry if payment_url is unavailable? how many times? if you eventually
 unlock the probably-not-quite-spent-yet inputs, should you double-spend
 them to yourself just in case the merchant eventually gets around to
 broadcasting the transaction, or should you just unlock them and squirrel
 away the failed Payment so if the merchant does eventually broadcast you
 have a record of why the coins were spent).

Also users don't have infinite unspent txouts in their wallets - if they
need to make two payments in a row and run out their wallet software is
(currently) going to spend the change txout and either be forced to
broadcast both transactions anyway, or the second payment-protocol-using
recipient will do so on their behalf. (in the future they might also do
a replacement tx replacing the first with a single tx paying both to
save on fees, again with the same problem)

Anyway what you want is payment atomicity: the customer losing control
of the funds must be atomic with respect to the payment going through.
From that point of view it's unfortunate that Payment message contains
refund_to, memo, etc. That information should have been provided to the
merchant prior to them providing the list of addresses to pay.

-- 
'peter'[:-1]@petertodd.org
85c725a905444d271c56fdee4e4ec7f27bdb2e777c872925


signature.asc
Description: Digital signature
--
WatchGuard Dimension instantly turns raw network data into actionable 
security intelligence. It gives you real-time visual feedback on key
security issues and trends.  Skip the complicated setup - simply import
a virtual appliance and go from zero to informed in seconds.
http://pubads.g.doubleclick.net/gampad/clk?id=123612991iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] BIP70: PaymentACK semantics

2014-01-28 Thread Mike Hearn
In practice this should only be an issue if a payment is submitted and
fails, which should be rare. Barring internal server errors and screwups on
the merchants side, the only reasons for a rejection at submit time would
be the imperfect fungibility of bitcoins, e.g. you try and pay with a huge
dust tx or one that's invalid/too low fee/etc.

So I think we have a bit of time to figure this out. But yes - once you
broadcast, you probably accept that there might be a more painful path to
resolve issues if something goes wrong, I guess. Right now BitPay has a
support system where you can file a ticket if you pay the bitcoins and they
don't recognise it or the tx never confirms or whatever. It's grotty manual
work but they do it. Not broadcasting unless you have to seems like an
optimisation that can reduce pain without much additional complexity.



On Tue, Jan 28, 2014 at 6:23 PM, Peter Todd p...@petertodd.org wrote:

 On Tue, Jan 28, 2014 at 07:53:14AM -0500, Gavin Andresen wrote:
  On Tue, Jan 28, 2014 at 6:42 AM, Mike Hearn m...@plan99.net wrote:
 
   Yeah, that's the interpretation I think we should go with for now.
 There
   was a reason why this isn't specified and I forgot what it was - some
   inability to come to agreement on when to broadcast vs when to submit
 via
   HTTP, I think.
  
 
  If the wallet software is doing automatic CoinJoin (for example), then
  typically one or several of the other participants will broadcast the
  transaction as soon as it is complete.
 
  If the spec said that wallets must not broadcast until they receive a
  PaymentACK (if a payment_url is specified), then you'd have to violate
 the
  spec to do CoinJoin.
 
  And even if you don't care about CoinJoin, not broadcasting the
 transaction
  as soon as the inputs are signed adds implementation complexity (should
 you
  retry if payment_url is unavailable? how many times? if you eventually
  unlock the probably-not-quite-spent-yet inputs, should you double-spend
  them to yourself just in case the merchant eventually gets around to
  broadcasting the transaction, or should you just unlock them and squirrel
  away the failed Payment so if the merchant does eventually broadcast you
  have a record of why the coins were spent).

 Also users don't have infinite unspent txouts in their wallets - if they
 need to make two payments in a row and run out their wallet software is
 (currently) going to spend the change txout and either be forced to
 broadcast both transactions anyway, or the second payment-protocol-using
 recipient will do so on their behalf. (in the future they might also do
 a replacement tx replacing the first with a single tx paying both to
 save on fees, again with the same problem)

 Anyway what you want is payment atomicity: the customer losing control
 of the funds must be atomic with respect to the payment going through.
 From that point of view it's unfortunate that Payment message contains
 refund_to, memo, etc. That information should have been provided to the
 merchant prior to them providing the list of addresses to pay.

 --
 'peter'[:-1]@petertodd.org
 85c725a905444d271c56fdee4e4ec7f27bdb2e777c872925

--
WatchGuard Dimension instantly turns raw network data into actionable 
security intelligence. It gives you real-time visual feedback on key
security issues and trends.  Skip the complicated setup - simply import
a virtual appliance and go from zero to informed in seconds.
http://pubads.g.doubleclick.net/gampad/clk?id=123612991iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] BIP70: PaymentACK semantics

2014-01-28 Thread Peter Todd
On Tue, Jan 28, 2014 at 06:33:28PM +0100, Mike Hearn wrote:
 In practice this should only be an issue if a payment is submitted and
 fails, which should be rare. Barring internal server errors and screwups on
 the merchants side, the only reasons for a rejection at submit time would
 be the imperfect fungibility of bitcoins, e.g. you try and pay with a huge
 dust tx or one that's invalid/too low fee/etc.
 
 So I think we have a bit of time to figure this out. But yes - once you
 broadcast, you probably accept that there might be a more painful path to
 resolve issues if something goes wrong, I guess. Right now BitPay has a
 support system where you can file a ticket if you pay the bitcoins and they
 don't recognise it or the tx never confirms or whatever. It's grotty manual
 work but they do it. Not broadcasting unless you have to seems like an
 optimisation that can reduce pain without much additional complexity.

That's the reason you use a model where things happen atomicly: the
funds either can or can't be transferred, so if the merchant screws up
due to a server failure at worst the wallet can always send the
original, signed, payment request and transaction details proving to the
merchant that they agreed. Since the asked for txouts exist in the
blockchain they must either refund the money, or ship the goods.

Wallet software can handle that kind of worst-case failure by
automatically sending the original payment request back to the merchant.
At worst all customer support has to do is tell the customer Sorry
about that; we didn't get your payment. Please start your wallet up and
hit the 'resend transaction' button in your wallet and we'll clear that
right up.

Keep in mind that we're probably going to see fraudsters figuring out
ways to make payment servers fail. This means conversely that a customer
calling up a merchant and saying Hey! Something didn work but the
wallet says I paid! is going to be treated more suspiciously. By using
atomic protocols the issue of did or didn't they pay becomes much more
black and white, and failure resistant. That's exactly what we keep
saying Bitcoin offers that PayPal doesn't.

-- 
'peter'[:-1]@petertodd.org
85c725a905444d271c56fdee4e4ec7f27bdb2e777c872925


signature.asc
Description: Digital signature
--
WatchGuard Dimension instantly turns raw network data into actionable 
security intelligence. It gives you real-time visual feedback on key
security issues and trends.  Skip the complicated setup - simply import
a virtual appliance and go from zero to informed in seconds.
http://pubads.g.doubleclick.net/gampad/clk?id=123612991iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Extension for BIP-0070 to support recurring payments

2014-01-28 Thread Stephane Brossier
From what I have seen so far, there seems to be an agreement that this is a 
nice feature to add. We are pretty new to that community and so we don't know 
exactly what the process is, and in particular how we reach consensus via 
email. I am certainly open to follow 'the way' if there is one, but one 
solution would be to follow Mike's suggestion on providing a (prototype) 
implementation first and then defining/refining the BIP. Odinn also suggested a 
possible retribution for our time through crowd-sourcing which I am interested 
to pursue if that makes sense.


We have quite some experience on the subscription side of things and while we 
are growing our knowledge on the Bitcoin technology (and ecosystem at large) we 
would benefit from:
* some feedbacks on the high level proposal
* additional requirements we might have missed

So, below is a high level description of what we have in mind. If this sounds 
reasonable, we could start working on an implementation.


 
I. Abstract
---

This describes a protocol to enable recurring payments in bitcoins and can be 
seen as an extension of BIP-0070. The main goal here is to have the customer 
subscribe to a service of some kind (that is, agreeing on the terms of that 
subscription contract), and then have the wallet make recurring payments 
without any intervention from the customer as long as the payments match what 
the customer agreed on paying.

An example of such service would be an online streaming website, to which a 
user pays a fixed recurring monthly fee to access videos (a.k.a. resources). 
Note that there is also usage based billing: for example, the user may need to 
purchase additional access for premium videos (overage charges). This type of 
billing is more complicated and there are many variations to it used in the 
industry (pre-paid, …). For the sake of discussion, we’ll focus on fixed 
recurring payments only, but we will keep usage in mind to make sure the 
protocol will be able to support it as well.


II. Motivation
--

Subscription based services have been growing in the past few years and so the 
intent it to make it possible for customers to pay in bitcoins. 

Bitcoin’s push model presents new advantages for the customer compared to 
traditional payment methods: the user has control over the subscription (for 
example, there is no need to call the merchant to explicitly cancel the credit 
card payments). It also opens the door to subscription management tools in 
wallets (e.g. Hive apps), which would give user an overview of what they are 
paying each month.


III. Flow of Operations



Creation of the subscription:
- - - - - - - - - - - - - - - - - - - - - - 

1. The customer clicks 'subscribe' - A message is sent to the merchant.
2. The merchant sends back a message to the wallet with the details of the 
subscription such as the amount to be paid. In reality, there will be more 
information but for the purpose of the prototype implementation this is 
sufficient.
3. The wallet prompts the customer for authorization.
4. The customer authorizes (or denies) it.
5. The wallet sends the confirmation to the merchant.
6. The merchant confirms the subscription was created.

Ongoing payments:
- - - - - - - - - - - - - - - -

From that time on and since Bitcoin is a 'push' model, the wallet is 
responsible to poll the merchant for due payments associated with that 
subscription. Note that the merchant could specify hints to the wallet on when 
to poll (specific dates) or not during the registration of the subscription.

Note that we can't simply have the wallet push X bitcoins every month: the user 
account on the merchant side may have gotten credits, invoice adjustments, etc. 
since the last invoice, so the amount to pay for a given billing period may be 
lower than the regular amount. It could even be zero if the user decides to 
make a one-time payment to the merchant directly using a different wallet. 
Hence, the wallet needs to get the latest invoice balance to make sure how much 
it should pay. This also opens the door for the support of overage charges.


Quick note on the implementation on the merchant side: an entitlement system is 
a piece of logic on the merchant side which grants the user access to certain 
resources depending on the account status (unpaid invoices, etc.). This goes 
often hand in hand with a dunning system, which progressively restricts access 
as the user's account is more and more overdue. Since wallets can be offline 
for an extended period of time, payments may be missed and lead to an overdue 
state (e.g. extra fees, service degraded). It is the responsibility of the 
customer to ensure the wallet is up often enough for payments to happen.


In that recurring phase where the wallet polls the merchant, the wallet is 
responsible to check that payments match the subscription contract; that is, 
the amount, frequency of payments, … match what 

Re: [Bitcoin-development] Bitcoin-development Digest, Vol 32, Issue 57

2014-01-28 Thread Ryan Carboni
This will easily create too much data in the block chain.
I think it's probably better to trust online wallets to handle complex
financial transactions such a debits or credits.
If Bitcoin achieves Visa-levels of popularity, that would mean one megabyte
of transactions per second (even assuming script isn't used), or ~30
terabytes per year. After a decade the Bitcoin blockchain can only be
stored by Amazon or Google or the Web Archive, even assuming Kryder's Law
continues.
If the Bitcoin blockchain instead becomes cheque clearinghouse style
transaction system, many problems involving blockchain growth become
negligible.
Sure, this is supposed to be a trustless system, but there's a reason why
everyone relies on trust in the real world.


On Tue, Jan 28, 2014 at 7:13 PM, 
bitcoin-development-requ...@lists.sourceforge.net wrote:

 Send Bitcoin-development mailing list submissions to
 bitcoin-development@lists.sourceforge.net

 To subscribe or unsubscribe via the World Wide Web, visit
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development
 or, via email, send a message with subject or body 'help' to
 bitcoin-development-requ...@lists.sourceforge.net

 You can reach the person managing the list at
 bitcoin-development-ow...@lists.sourceforge.net

 When replying, please edit your Subject line so it is more specific
 than Re: Contents of Bitcoin-development digest...


 Today's Topics:

1. Re: BIP70: PaymentACK semantics (Peter Todd)
2. Re: Extension for BIP-0070 to support recurring payments
   (Stephane Brossier)


 --

 Message: 1
 Date: Tue, 28 Jan 2014 16:12:18 -0500
 From: Peter Todd p...@petertodd.org
 Subject: Re: [Bitcoin-development] BIP70: PaymentACK semantics
 To: Mike Hearn m...@plan99.net
 Cc: Andreas Schildbach andr...@schildbach.de, Bitcoin Dev
 bitcoin-development@lists.sourceforge.net
 Message-ID: 20140128211218.GE22059@savin
 Content-Type: text/plain; charset=us-ascii

 On Tue, Jan 28, 2014 at 06:33:28PM +0100, Mike Hearn wrote:
  In practice this should only be an issue if a payment is submitted and
  fails, which should be rare. Barring internal server errors and screwups
 on
  the merchants side, the only reasons for a rejection at submit time would
  be the imperfect fungibility of bitcoins, e.g. you try and pay with a
 huge
  dust tx or one that's invalid/too low fee/etc.
 
  So I think we have a bit of time to figure this out. But yes - once you
  broadcast, you probably accept that there might be a more painful path to
  resolve issues if something goes wrong, I guess. Right now BitPay has a
  support system where you can file a ticket if you pay the bitcoins and
 they
  don't recognise it or the tx never confirms or whatever. It's grotty
 manual
  work but they do it. Not broadcasting unless you have to seems like an
  optimisation that can reduce pain without much additional complexity.

 That's the reason you use a model where things happen atomicly: the
 funds either can or can't be transferred, so if the merchant screws up
 due to a server failure at worst the wallet can always send the
 original, signed, payment request and transaction details proving to the
 merchant that they agreed. Since the asked for txouts exist in the
 blockchain they must either refund the money, or ship the goods.

 Wallet software can handle that kind of worst-case failure by
 automatically sending the original payment request back to the merchant.
 At worst all customer support has to do is tell the customer Sorry
 about that; we didn't get your payment. Please start your wallet up and
 hit the 'resend transaction' button in your wallet and we'll clear that
 right up.

 Keep in mind that we're probably going to see fraudsters figuring out
 ways to make payment servers fail. This means conversely that a customer
 calling up a merchant and saying Hey! Something didn work but the
 wallet says I paid! is going to be treated more suspiciously. By using
 atomic protocols the issue of did or didn't they pay becomes much more
 black and white, and failure resistant. That's exactly what we keep
 saying Bitcoin offers that PayPal doesn't.

 --
 'peter'[:-1]@petertodd.org
 85c725a905444d271c56fdee4e4ec7f27bdb2e777c872925
 -- next part --
 A non-text attachment was scrubbed...
 Name: not available
 Type: application/pgp-signature
 Size: 685 bytes
 Desc: Digital signature

 --

 Message: 2
 Date: Tue, 28 Jan 2014 18:47:20 -0800
 From: Stephane Brossier steph...@kill-bill.org
 Subject: Re: [Bitcoin-development] Extension for BIP-0070 to support
 recurring payments
 To: bitcoin-development@lists.sourceforge.net
 bitcoin-development@lists.sourceforge.net
 Cc: Pierre-Alexandre Meyer pie...@kill-bill.org, PikaPay
 he...@pikapay.com
 Message-ID: d6bcc0c4-ef22-4de8-868e-825d19c38...@kill-bill.org