Re: [Bitcoin-development] BIP70: PaymentACK semantics
The merchant can always act maliciously by simply not delivering the goods. The only recourse the payment protocol provides at that point is that you have proof the merchant is acting maliciously (or at the very least his payment system is broken). Your scheme just adds an ACK of the specific unsigned transactions before the payment is effectively irreversible. I can't come up with a situation where the combination of signed request and blockchain entry aren't enough evidence, yet where adding an ACK by the merchant of the unsigned transaction tips the balance the other way. If you know of such a possibility, I'd love to hear it, because we'd know what we're trying to fix. The only way I can see a malicious merchant exploiting wallet behaviour around PaymentACK is by accepting the Payment message, not broadcasting it, not returning an ACK, and hoping the wallet/user retries paying with a new, non-conflicting transaction. Then he can try milking multiple small payments out of the user before they realize what happened, and broadcast them all at once, stealing more funds than the user ever was willing to risk in the transaction. But this is trivial to guard against at the wallet level (by making every new payment conflict with all previous non-acked payments). The non-reliability of getting memo/refund fields is a separate problem, but it seems BitcoinJ's approach addresses that nicely. On Thu, Jan 30, 2014 at 11:16 PM, Chuck chuck+bitcoin...@borboggle.com wrote: On 1/31/2014 3:16 AM, Jeremy Spilman wrote: I think we want to separate the two issues; 1) Reliably getting refund/memo fields to the merchant/payee 2) Who broadcasts a TX, how it's retried, how outputs are 'locked' and if/when they should be [double]-spent to clear them We should be able to solve '1' without having to fully spec out behavior for 2. My original message was focused on #1. Not only #1, but ensuring the merchant can't act maliciously too. As far as #2 is concerned, I don't think it makes any difference - it's in both the customer and the merchant's best interest to have the transactions confirmed. c) Send them as a response to the PaymentRequest/PaymentDetails with the UNsigned transaction, and then follow up with the signed transaction in a separate message. ... On Wed, 29 Jan 2014 21:47:51 -0800, Chuck chuck+bitcoin...@borboggle.com wrote: 3. Customer builds a set of transactions and sends a new PaymentApprovalRequest message which includes a refund address and the unsigned transactions and their associated fully-signed transactionhash, the whole message signed with the private key of the refund address. Unsigned transactions and their associated fully-signed transaction hash -- isn't that a fully signed transaction? In this case, it doesn't solve the core problem of the server being able to broadcast that transaction without ACKing. What I meant was (and maybe this was roundabout?): the customer includes the UNsigned transactions as well as the hashes (and only the hashes) of the fully signed transactions. The customer keeps the fully signed transactions private until the merchant ACKs the unsigned versions. If the merchant has the hash of the fully signed transaction, he can monitor the network for delivery of the signed transaction. It definitely complicates things, but it's nothing that can't be done. Cheers, Chuck -- 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 -- 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
That looks OK at a very high level. Things you probably want to think about: - How to trigger it off the existing payment protocol (no new top level messages or mime types or uri extensions please) - Data structures to define the payment schedule - Do you allow pre-submission of time locked transactions or not? I think as you prototype these things will become clearer. You could try prototyping either in Bitcoin Core (C++) or bitcoinj (java, look at the PaymentSession class). On Wed, Jan 29, 2014 at 3:47 AM, Stephane Brossier steph...@kill-bill.orgwrote: *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 missedSo, 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
