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

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

[Ryan Carboni]

[-- Attachment #1: Type: text/plain, Size: 12872 bytes --]

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-request@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-request@lists.sourceforge.net
>
> You can reach the person managing the list at
>         bitcoin-development-owner@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 <pete@petertodd.org>
> Subject: Re: [Bitcoin-development] BIP70: PaymentACK semantics
> To: Mike Hearn <mike@plan99.net>
> Cc: Andreas Schildbach <andreas@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
> 000000000000000085c725a905444d271c56fdee4e4ec7f27bdb2e777c872925
> -------------- 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 <stephane@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 <pierre@kill-bill.org>, PikaPay
>         <hello@PikaPay.com>
> Message-ID: <D6BCC0C4-EF22-4DE8-868E-825D19C387E3@kill-bill.org>
> Content-Type: text/plain; charset="windows-1252"
>
> >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 the customer agreed on.
> If so, the payment is made without asking for explicit approval from
> customer, and the flow is similar to BIP-0070: The message is sent to the
> merchant, and in parallel, a transaction is sent to the btcnet. The
> merchant sends an ACK to the wallet and of course checks the states of the
> transactions on the btcnet to mark that payment as successful.
>
> Subscription change (optional):
> - - - - - - - - - - - - - - - - - - - - - - - -
>
> Optionally we could implement a change in the ongoing subscription to
> address the upgrade/downgrade scenarios. Of course, we could also simply
> support a cancellation followed by a creation of a new subscription, but
> having that as a one atomic message is probably better. The steps are very
> similar to the initial registration.
>
> 1. The customer clicks 'upgrade', 'downgrade', ? -> A msg is sent to the
> merchant.
> 2. The merchant sends back a msg to the wallet with the detail of the NEW
> subscription.
> 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 change in the subscription.
>
> Cancellation of the subscription:
> - - - - - - - - - - - - - - - - - - - - - - - - -
>
> The cancellation is initiated from the customer:
>
> 1. The customer clicks 'cancel' -> The wallet is informed that it  should
> not accept any new payment associated to that subscription.
> 2. The wallet sends a message to the merchant to inform about the
> cancellation.
> 3. The merchant confirms the subscription was cancelled.
>
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
>
> ------------------------------
>
>
> ------------------------------------------------------------------------------
> 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=123612991&iu=/4140/ostg.clktrk
>
> ------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
> End of Bitcoin-development Digest, Vol 32, Issue 57
> ***************************************************
>

[-- Attachment #2: Type: text/html, Size: 15181 bytes --]