Billing Problem with Leaking Billing State amongst participants on a transaction about corda-solutions

[mattbradburyuk]

Hi Barry,
We talked about this when we were developing the pattern. (Originally we didn't have the BillingState as a reference in the Transaction). The advantage is that as a BNO you can stop somebody operating on your network immediately even if they have stock piled pre chipped of BillingChips.

However, whether the BillingState is included in the Transaction or not, the information held in the BillingState Chain is still resolved by the Transaction so the participants in the Transaction all get to see the BillingState history anyway. What you never do though is resolve any previous Transactions (with Competitors)

So if it's a problem having the BillingState history, maybe it shows transaction volume history, or credit limit information, you can do a few things to hide actual volumes:

• Over issue tokens, then at a later date Attach the excess back. Somebody looking at the chain before the attach back would not know how many tokens have actually been used in Transactions.

• The BNO can issue multiple BillingStates to a single Party

I haven’t thought it through fully, but I think you may be able to get to the point where with the right obfuscation you leak no information about how much actual billing has taken place and can only infer that the Party’s total credit limit is greater or equal to the credit limit on that particular BillingState.

Although, I don’t think these obfuscation flows have been included in the coded application.

Matt

[bkreiser]

Thanks Matt. I don't currently view this as 'show stopper' type stuff currently. I do have another billing related thing that I will have to sort out soon. How would I atomically return billing states and issue the next month billing states. I don't want to risk members having a period of time without a billing state no matter how short for fear of a flow failing. Let me know if you need more clarification

…

_______________________________________________ *Barry Kreiser | **Director/CTO* *| **GuildOne Inc.* Suite 940 333-5th Avenue SW, Calgary, AB T2P 3B6

On Wed, Apr 24, 2019 at 10:48 AM mattbradburyuk ***@***.***> wrote: Hi Barry, We talked about this when we were developing the pattern. (Originally we didn't have the BillingState as a reference in the Transaction). The advantage is that as a BNO you can stop somebody operating on your network immediately even if they have stock piled pre chipped of BillingChips. However, whether the BillingState is included in the Transaction or not, the information held in the BillingState Chain is still resolved by the Transaction so the participants in the Transaction all get to see the BillingState history anyway. What you never do though is resolve any previous Transactions (with Competitors) So if it's a problem having the BillingState history, maybe it shows transaction volume history, or credit limit information, you can do a few things to hide actual volumes: - Over issue tokens, then at a later date Attach the excess back. Somebody looking at the chain before the attach back would not know how many tokens have actually been used in Transactions. - The BNO can issue multiple BillingStates to a single Party I haven’t thought it through fully, but I think you may be able to get to the point where with the right obfuscation you leak no information about how much actual billing has taken place and can only infer that the Party’s total credit limit is greater or equal to the credit limit on that particular BillingState. Although, I don’t think these obfuscation flows have been included in the coded application. Matt — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#91 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA2AWHRZ5WBOZCHH6NUYV5TPSCFPLANCNFSM4HGYDD4A> .

[bkreiser]

Futhre And not just atomically, but somehow blocking flows on the members until the new billing state is there.

…

_______________________________________________ *Barry Kreiser | **Director/CTO* *| **GuildOne Inc.* Suite 940 333-5th Avenue SW, Calgary, AB T2P 3B6

On Wed, Apr 24, 2019 at 2:11 PM Barry Kreiser ***@***.***> wrote: Thanks Matt. I don't currently view this as 'show stopper' type stuff currently. I do have another billing related thing that I will have to sort out soon. How would I atomically return billing states and issue the next month billing states. I don't want to risk members having a period of time without a billing state no matter how short for fear of a flow failing. Let me know if you need more clarification _______________________________________________ *Barry Kreiser | **Director/CTO* *| **GuildOne Inc.* Suite 940 333-5th Avenue SW, Calgary, AB T2P 3B6 On Wed, Apr 24, 2019 at 10:48 AM mattbradburyuk ***@***.***> wrote: > Hi Barry, > We talked about this when we were developing the pattern. (Originally we > didn't have the BillingState as a reference in the Transaction). The > advantage is that as a BNO you can stop somebody operating on your network > immediately even if they have stock piled pre chipped of BillingChips. > > However, whether the BillingState is included in the Transaction or not, > the information held in the BillingState Chain is still resolved by the > Transaction so the participants in the Transaction all get to see the > BillingState history anyway. What you never do though is resolve any > previous Transactions (with Competitors) > > So if it's a problem having the BillingState history, maybe it shows > transaction volume history, or credit limit information, you can do a few > things to hide actual volumes: > > - > > Over issue tokens, then at a later date Attach the excess back. > Somebody looking at the chain before the attach back would not know how > many tokens have actually been used in Transactions. > - > > The BNO can issue multiple BillingStates to a single Party > > I haven’t thought it through fully, but I think you may be able to get to > the point where with the right obfuscation you leak no information about > how much actual billing has taken place and can only infer that the Party’s > total credit limit is greater or equal to the credit limit on that > particular BillingState. > > Although, I don’t think these obfuscation flows have been included in the > coded application. > > Matt > > — > You are receiving this because you authored the thread. > Reply to this email directly, view it on GitHub > <#91 (comment)>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/AA2AWHRZ5WBOZCHH6NUYV5TPSCFPLANCNFSM4HGYDD4A> > . >

[mattbradburyuk]

The billing states have an expiry + the BNO is a participant on the billing state. Just prior to the expiry time the BNO could issue the next BillingState then recall the previous one. Hence no period not covered by a billing state.

[bkreiser]

Smart. Let me noodle that Thanks

On Thu, Apr 25, 2019 at 6:30 AM mattbradburyuk ***@***.***> wrote: The billing states have an expiry + the BNO is a participant on the billing state. Just prior to the expiry time the BNO could issue the next BillingState then recall the previous one. Hence no period not covered by a billing state. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#91 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA2AWHVXWFGFOF25CKZTBPTPSGP6JANCNFSM4HGYDD4A> .

--

…

_______________________________________________ *Barry Kreiser | **Director/CTO* *| **GuildOne Inc.* Suite 940 333-5th Avenue SW, Calgary, AB T2P 3B6

[bkreiser]

Matt, In regards to what you have suggested, what would you think of having an effectiveDate on a billing state?

…

_______________________________________________ *Barry Kreiser | **Director/CTO* *| **GuildOne Inc.* Suite 940 333-5th Avenue SW, Calgary, AB T2P 3B6

On Thu, Apr 25, 2019 at 7:21 AM Barry Kreiser ***@***.***> wrote: Smart. Let me noodle that Thanks On Thu, Apr 25, 2019 at 6:30 AM mattbradburyuk ***@***.***> wrote: > The billing states have an expiry + the BNO is a participant on the > billing state. Just prior to the expiry time the BNO could issue the next > BillingState then recall the previous one. Hence no period not covered by a > billing state. > > — > You are receiving this because you authored the thread. > Reply to this email directly, view it on GitHub > <#91 (comment)>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/AA2AWHVXWFGFOF25CKZTBPTPSGP6JANCNFSM4HGYDD4A> > . > -- _______________________________________________ *Barry Kreiser | **Director/CTO* *| **GuildOne Inc.* Suite 940 333-5th Avenue SW, Calgary, AB T2P 3B6

[mattbradburyuk]

By effective date I assume you mean 'valid from' date. That sounds like a reasonable idea. Would that be so the switch over between previous and new BillingState can be near instantaneous, Ie reduced scope for edge cases at the swap over point as the swap over is necessarily in two non simultaneous transactions.

[bkreiser]

Yes, 'valid from date'. And yes, I think it would make for a more seamless switch over.

…

_______________________________________________ *Barry Kreiser | **Director/CTO* *| **GuildOne Inc.* Suite 940 333-5th Avenue SW, Calgary, AB T2P 3B6

On Thu, Apr 25, 2019 at 3:50 PM mattbradburyuk ***@***.***> wrote: By effective date I assume you mean 'valid from' date. That sounds like a reasonable idea. Would that be so the switch over between previous and new BillingState can be near instantaneous, Ie reduced scope for edge cases at the swap over point as the swap over is necessarily in two non simultaneous transactions. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#91 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA2AWHSLFT2PGVNUOLRFUHDPSIRRDANCNFSM4HGYDD4A> .

[mattbradburyuk]

@IvanR3 FYI above on effective date.

[ischasny]

There is one already called issued: https://github.com/corda/corda-solutions/blob/master/bn-apps/billing/billing-contracts-and-states/src/main/kotlin/com/r3/businessnetworks/billing/states/BillingContract.kt#L227.

@bkreiser great point about leading billing state itself. The main idea behind adding billing state as a reference state into a transaction is to give the issuer an ability to revoke the billing state as a result of a governance action or something.

[bkreiser]

I am not sure what ‘issued’ has to do with effective date (valid from date). Issued is the max number of chips to spend.

On Fri, Apr 26, 2019 at 4:22 AM Ivan Schasny ***@***.***> wrote: There is one already called issued: https://github.com/corda/corda-solutions/blob/master/bn-apps/billing/billing-contracts-and-states/src/main/kotlin/com/r3/businessnetworks/billing/states/BillingContract.kt#L227 . @bkreiser <https://github.com/bkreiser> great point about leading billing state itself. The main idea behind adding billing state as a reference state into a transaction is to give the issuer an ability to revoke the billing state as a result of a governance action or something. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#91 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA2AWHSDPLN2FTOMRAXWANDPSLJXFANCNFSM4HGYDD4A> .

--

…

_______________________________________________ *Barry Kreiser | **Director/CTO* *| **GuildOne Inc.* Suite 940 333-5th Avenue SW, Calgary, AB T2P 3B6

[ischasny]

Ah yes, sorry my bad. we might need to add an issuedDate field

[bkreiser]

I was thinking a deferred effectiveDate so that you can pre issue a BillingState for the upcoming period to avoid not having a BillingState available. But yeh, issuedDate would be good too

On Fri, Apr 26, 2019 at 6:34 AM Ivan Schasny ***@***.***> wrote: Ah yes, sorry my bad. we might need to add an issuedDate field — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#91 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA2AWHW6OZMVP2XHNWSUYDTPSLZHBANCNFSM4HGYDD4A> .

--

…

_______________________________________________ *Barry Kreiser | **Director/CTO* *| **GuildOne Inc.* Suite 940 333-5th Avenue SW, Calgary, AB T2P 3B6

[bkreiser]

The problem I am trying to solve is to ensure that I always have a billing state available and don’t have month end issues when I call for the return of states and then flows fire and have no active billing states.

On Fri, Apr 26, 2019 at 6:50 AM Barry Kreiser ***@***.***> wrote: I was thinking a deferred effectiveDate so that you can pre issue a BillingState for the upcoming period to avoid not having a BillingState available. But yeh, issuedDate would be good too On Fri, Apr 26, 2019 at 6:34 AM Ivan Schasny ***@***.***> wrote: > Ah yes, sorry my bad. we might need to add an issuedDate field > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > <#91 (comment)>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/AA2AWHW6OZMVP2XHNWSUYDTPSLZHBANCNFSM4HGYDD4A> > . > -- _______________________________________________ *Barry Kreiser | **Director/CTO* *| **GuildOne Inc.* Suite 940 333-5th Avenue SW, Calgary, AB T2P 3B6

--

…

_______________________________________________ *Barry Kreiser | **Director/CTO* *| **GuildOne Inc.* Suite 940 333-5th Avenue SW, Calgary, AB T2P 3B6

[ischasny]

That definitely makes sense. Would you mind adding this field and creating a PR? @bkreiser

[bkreiser]

I can do that, no problem but might not get around to it for a couple of days.

…

_______________________________________________ *Barry Kreiser | **Director/CTO* *| **GuildOne Inc.* Suite 940 333-5th Avenue SW, Calgary, AB T2P 3B6

On Mon, Apr 29, 2019 at 2:41 AM Ivan Schasny ***@***.***> wrote: That definitely makes sense. Would you mind adding this field and creating a PR? @bkreiser <https://github.com/bkreiser> — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#91 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA2AWHTOYVUFQENJUVEGHHTPS2YELANCNFSM4HGYDD4A> .

[ischasny]

That's fine! Thanks Barry