Re: [Bitcoin-development] Fee drop
So, just to be clear, we're adding, say, a memory limited mempool or something prior to release so this fee drop doesn't open up an obvious low-risk DDoS exploit right? As we all know, the network bandwidth DoS attack mitigation strategy relies on transactions we accept to mempools getting mined, and the clearance rate of the new low-fee transactions is going to be pretty small; we've already had problems in the past with mempool growth in periods of high demand. Equally it should be obvious to people how you can create large groups of low-fee transactions, and then cheaply double-spend them with higher fee transactions to suck up network bandwidth - just like I raised for the equally foolish double-spend propagation pull-req. It's good that the core devs keep doing good work on these topics, thanks. Of course, there's also the problem that we're basically lying to people about whether or not Bitcoin is a good medium for microtransactions. I don't hear anyone lying. It's not. Actually, it is, and comparatively speaking, Bitcoin is better than the most common alternatives in use by people around the world. There are obvious issues (dust, how to handle fee issues moving forward, one could blather on forever about that), but again, I think core devs have done fairly well and will probably continue to do so along with many others. That's just my own 0.4 BTC though (my way of saying, at time of posting this, my own 2 cents). Saying otherwise by releasing software that has known and obvious DoS attack vulnerabilities that didn't exist in the previous version is irresponsible on multiple levels. That was not very specific. Could you be more specific? -- 'peter'[:-1]@petertodd.org b28e2818c4d8019fb71e33ec2d223f5e09394a89caccf4e2 -- 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=126839071iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- 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=126839071iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Fee drop
On Tue, Feb 25, 2014 at 06:25:18PM +0530, Mike Hearn wrote: Given that the fee drop puts fees in real (i.e. dollar) terms back to where they were some months ago, it seems odd to claim this is creating vulnerabilities that didn't exist in the previous version. The cost of an attack would be the same as before. No it's not. The cost is only incurred in the transactions actually get mined, and unlike before the drop appears to be well under the break-even orphan cost of transactions; we've got no reason to think the clearance rate of these low-fee transactions will be significant. But anyway, mostly I'm writing this to register my strong opposition knowing full well that I don't expect it to change your minds. -- 'peter'[:-1]@petertodd.org eb671d932a8d310e8ab963c53b2be8a27bd5de2a712c2f59 signature.asc Description: Digital signature -- 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=126839071iu=/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
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
Re: [Bitcoin-development] Fee drop
There are two possibilities. One is that the value of transactions with the new lower fee is outweighed by increased orphan costs and miners refuse to include them en-masse. Wallet authors lose the staring match and go back to setting higher fees until such a time as block propagation is optimised and the orphan costs go down. Nodes that are encountering memory pressure can increase their min relay fee locally until their usage fits inside their resources. It's annoying to do this by hand but by no means infeasible. The other is that the total value of transactions even with the lower fee is not outweighed by orphan costs. The value of a transaction is higher than its simple monetary value - the fact that Bitcoin is useful, growing and considered cheap also has a value which is impossible to calculate, but we know it's there (because Bitcoin does not exist in a vacuum and has competitors). In this case miners stop including lots of useful transactions that represent desired economic activity and are put under pressure by the community to change their policies. If all miners do this and making small blocks is considered errant behaviour, then we're back to the same situation we're in today. The possibility you're worried about - that someone does a DoS attack by flooding the network with small transactions - is only an issue in the first situation, and it is by no means the easiest or cheapest way to DoS Bitcoin. We all want to see more DoS resistance but basically any change to Bitcoin can be objected to on anti-DoS grounds at the moment, and this will remain the case until someone steps up to spend significant time on resource scheduling and code audits. -- 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=126839071iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Fee drop
On Tue, Feb 25, 2014 at 10:25:58PM +0530, Mike Hearn wrote: Well, I've done my responsible disclosure, and I've got better things to do than argue with wishful thinking. There are two possibilities. One is that the value of transactions with the new lower fee is outweighed by increased orphan costs and miners refuse to include them en-masse. Wallet authors lose the staring match and go back to setting higher fees until such a time as block propagation is optimised and the orphan costs go down. Nodes that are encountering memory pressure can increase their min relay fee locally until their usage fits inside their resources. It's annoying to do this by hand but by no means infeasible. The other is that the total value of transactions even with the lower fee is not outweighed by orphan costs. The value of a transaction is higher than its simple monetary value - the fact that Bitcoin is useful, growing and considered cheap also has a value which is impossible to calculate, but we know it's there (because Bitcoin does not exist in a vacuum and has competitors). In this case miners stop including lots of useful transactions that represent desired economic activity and are put under pressure by the community to change their policies. If all miners do this and making small blocks is considered errant behaviour, then we're back to the same situation we're in today. The possibility you're worried about - that someone does a DoS attack by flooding the network with small transactions - is only an issue in the first situation, and it is by no means the easiest or cheapest way to DoS Bitcoin. We all want to see more DoS resistance but basically any change to Bitcoin can be objected to on anti-DoS grounds at the moment, and this will remain the case until someone steps up to spend significant time on resource scheduling and code audits. -- 'peter'[:-1]@petertodd.org 445db8e568846d542c86ab395137b32b2a05577afcc7c6a3 signature.asc Description: Digital signature -- 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=126839071iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Fee drop
If I understand correctly, the risk here is this would open a historically large discrepancy between MIN_RELAY and the expected minimum fee to actually obtain block inclusion. I don't know if that's true, but I think that's what Peter is saying makes it different this time.The relay network does anti-spam with MIN_RELAY and MIN_DUST, but of course only transactions which hit the blockchain actually PAY the fee, so this allows lower-cost spam in the true dollar sense.I guess it comes down to how 'sharp' the edge is between staying above MIN_RELAY and staying OUT of the blockchain. In the worst case, there's a completely deterministic boundary, so an attacker can generate an infinite number of transactions which are guaranteed never to see the inside of a block, and so therefore completely free for the attacker, and all of which the network will relay (by default).On Tue, 25 Feb 2014 08:55:58 -0800, Mike Hearn m...@plan99.net wrote:Nodes that are encountering memory pressure can increase their min relay fee locally until their usage fits inside their resources. It's annoying to do this by hand but by no means infeasible. Perhaps this is just another way to think of the floating fee problem. What does MIN_RELAY need to be so that my local resources stay within some reasonable limit (and 'reasonable' means different things to different nodes).We have an input gate on transactions entering mempool, we persist mempool, and I don't know the specifics but, I assume there's some expiration policy other than block inclusion to clear out a Tx from mempool. But are transactions prioritized in any way after they make it into mempool today?How closely should mempool selection align with the expected block inclusion? I think if they align perfectly in theory that means optimal mempool resource allocation. For example, a miner would push out cheaper transactions which they were previously hashing against to make room for higher fee transactions (bsaed on max block size or orphan rate projections), but do we do the same for mempool? E.g. - After hitting X number of transactions, the fee has to be larger than a transaction in mempool in order to get in, - That in turn that ejects a random transaction which paid less fees than the incoming Tx from mempool - We would have to consider how ejection would work with chains of unconfirmed transactions (cumulative average fee/kb?) but again in this case, you would want to 'do what miners would do' if you couldThanks,Jeremy-- 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=126839071iu=/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
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 m...@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
Re: [Bitcoin-development] Extension for BIP-0070 to support recurring payments
Given the enormous number of variations on time periods for a
recurring payment, might it be better to simple allow a list of
timestamps? It costs almost nothing, bandwidth wise, and shifts the
thinking to the merchant platform. That doesn't give you an infinite
time frame, but you just get a new list of timestamps every time you
pay the service.
Continuing that thought, is a next_payment_time field with each
incremental transaction enough to cover everything?
On Tue, Feb 25, 2014 at 1:40 PM, Drak d...@zikula.org wrote:
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 m...@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:
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;
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?
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.
I assume the amounts are specified in terms of satoshi, and timestamps are
UNIX time, but better to make that explicit.
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.
What's the merchant ID namespace thing about? What's it for? What
happens if I set my competitors merchant ID there?
What's the subscription ID? Is this stuff not duplicative/redundant with
the existing merchant_data field?
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?
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?
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
Re: [Bitcoin-development] Fee drop
Am suggesting a (possible) mitigation of [possible flooding, etc], via some kind of discussion (potentially process BIP, related to bundling and / or randomization) not now, but down the road. However, needs more thought and analysis (you mentioned code audit?) before it could be floated around or acted on in any way shape or form. Thanks for this discussion, things to think about am watching, listening (...) There are two possibilities. One is that the value of transactions with the new lower fee is outweighed by increased orphan costs and miners refuse to include them en-masse. Wallet authors lose the staring match and go back to setting higher fees until such a time as block propagation is optimised and the orphan costs go down. Nodes that are encountering memory pressure can increase their min relay fee locally until their usage fits inside their resources. It's annoying to do this by hand but by no means infeasible. The other is that the total value of transactions even with the lower fee is not outweighed by orphan costs. The value of a transaction is higher than its simple monetary value - the fact that Bitcoin is useful, growing and considered cheap also has a value which is impossible to calculate, but we know it's there (because Bitcoin does not exist in a vacuum and has competitors). In this case miners stop including lots of useful transactions that represent desired economic activity and are put under pressure by the community to change their policies. If all miners do this and making small blocks is considered errant behaviour, then we're back to the same situation we're in today. The possibility you're worried about - that someone does a DoS attack by flooding the network with small transactions - is only an issue in the first situation, and it is by no means the easiest or cheapest way to DoS Bitcoin. We all want to see more DoS resistance but basically any change to Bitcoin can be objected to on anti-DoS grounds at the moment, and this will remain the case until someone steps up to spend significant time on resource scheduling and code audits. -- 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=126839071iu=/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
Hi Mike, Jeremy, Drak, Before going through your questions, I would like to bring some clarity on a few key elements in that protocol. There are really two aspects to it: The contract negotiation; when the user first subscribes, it is prompted by a contract that will define the payment bounds associated with that subscription. Once accepted, the wallet is in charge and the user does not have to interact anymore -- this is the point of the recurring payment protocol. The wallet will poll the merchant and issue payments as they are requested by the merchant as long as they stay within the bounds of what was specified by the contract (and accepted by the customer). I think it would help to explain how we ended up with the type of contract we introduced in that protocol. In an ideal world and in a NON recurring scheme, the contract should simply be the exact amount to be paid. In our case the exact amount may not be completely known in advance -- for e.g taxes, shipping, pro-rations, … and so we decided to introduce first a max amount per payment, and also a max amount per period. It is up to the merchant to decide whether to specify none, any or both bounds (max amount per payment and max amount per period). By specifying both, the contract is tighter and the client would feel safer to accept it. In the extreme case, by specifying none, the client would be presented with a contract to pay whatever is requested -- probably not a good option in the Bitcoin world unless there is a high sense of trust with the merchant. From reading your comments, it appears we have not been clear on how that frequency (PaymentFrequencyType) is being used. Its sole purpose is to define the max amount per period in the contract. The frequency of the payment is implicitly dictated by the merchant but not specified in the protocol by design: the wallet has to poll with a fine granularity (ideally each day when it is up) to understand if there is something pending. In the same way, a specified amount was not enough in the contract, we feel it would be restrictive to specify in advance when payments are due. There are a lot of complex scenarios in the billing space, and having the wallet poll the merchant to inquire for pending payments is the most flexible option and the contract is there to ensure the client will not be abused. To give a concrete example, imagine a data plan where you pay a base recurring price of $70 per month, but you are charged $10 per GB of data used beyond your included limit. If you exceed your limit on the 15th and the 23rd of a given month, two extra payment attempts will be requested by the merchant, that you couldn’t predict (this scenario is often referred to as usage billing with Prepay Credits and Top-up, where the customer pays in advance for blocks of N units, and once they are consumed another N are purchased). See answers in your questions inlined below: I have the following comments: 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; OK, we'll fix it. 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? 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. I hope the explanation above answers the questions. I assume the amounts are specified in terms of satoshi, and timestamps are UNIX time, but better to make that explicit. Yes. 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. As explained above, contract would define none, 1 or both conditions. First the merchant should not return such 'conditions' but if it does the client should not accept the contract. If the client decides to accept it anyway, then the wallet just verifies both conditions are met separately regardless of whether there is such violation and if so, makes the
