Date   

Re: Membership

Barry Kreiser
 

Seems to me that if the BNO is implicitly a member of the BN then I can just modify the GetMembershipFlow to always include the BNO

_______________________________________________

Barry Kreiser | Director/CTO GuildOne Inc.

Suite 940 333-5th Avenue SW, Calgary, AB T2P 3B6



On Thu, May 30, 2019 at 9:21 AM Barry Kreiser via Groups.Io <barry=guild1.com@groups.io> wrote:
Has there been any design dialog on the BNO being a member?  Seems to me that it doesn't make sense that the BNO request membership on itself.  Perhaps it implicitly a member?

_______________________________________________

Barry Kreiser | Director/CTO GuildOne Inc.

Suite 940 333-5th Avenue SW, Calgary, AB T2P 3B6



On Thu, May 30, 2019 at 9:18 AM Barry Kreiser via Groups.Io <barry=guild1.com@groups.io> wrote:
Ok, thanks.  I submitted a PR for another membership issue if you want to have a look.  It wasn't allowing String to be used for the membership meta data.

_______________________________________________

Barry Kreiser | Director/CTO GuildOne Inc.

Suite 940 333-5th Avenue SW, Calgary, AB T2P 3B6



On Thu, May 30, 2019 at 8:25 AM Ivan Schasny via Groups.Io <Ivan.Schasny=r3.com@groups.io> wrote:
Hi Barry,

currently it's not supported, but it's on our backlog. There are two separate tasks: to allow BNO to be both operator and a member as well as to allow one BNO to operate multiple BNs. We haven't started to work on this yet though. As always - contributions are very welcome!

Regards,

Ivan Schasny | R3 | Solutions Engineer

2 London Wall Place, 12th Floor, London, EC2Y 5AU

M: +44 7904 873089

ivan.schasny@... | www.r3.com | www.corda.net


From: corda-dev@groups.io <corda-dev@groups.io> on behalf of Barry Kreiser via Groups.Io <barry=guild1.com@groups.io>
Sent: 30 May 2019 14:25
To: corda-dev@groups.io
Subject: [corda-dev] Membership
 
Ivan,

Should a BNO be able to join its own Business Network?  Currently it gives an error if you initiate a RequestMembership Flow against yourself with the error (Do not provide flow sessions for the local node. FinalityFlow will record the notarised transaction locally.) .  

_______________________________________________

Barry Kreiser | Director/CTO GuildOne Inc.

Suite 940 333-5th Avenue SW, Calgary, AB T2P 3B6


Re: Membership

Barry Kreiser
 

Has there been any design dialog on the BNO being a member?  Seems to me that it doesn't make sense that the BNO request membership on itself.  Perhaps it implicitly a member?

_______________________________________________

Barry Kreiser | Director/CTO GuildOne Inc.

Suite 940 333-5th Avenue SW, Calgary, AB T2P 3B6



On Thu, May 30, 2019 at 9:18 AM Barry Kreiser via Groups.Io <barry=guild1.com@groups.io> wrote:
Ok, thanks.  I submitted a PR for another membership issue if you want to have a look.  It wasn't allowing String to be used for the membership meta data.

_______________________________________________

Barry Kreiser | Director/CTO GuildOne Inc.

Suite 940 333-5th Avenue SW, Calgary, AB T2P 3B6



On Thu, May 30, 2019 at 8:25 AM Ivan Schasny via Groups.Io <Ivan.Schasny=r3.com@groups.io> wrote:
Hi Barry,

currently it's not supported, but it's on our backlog. There are two separate tasks: to allow BNO to be both operator and a member as well as to allow one BNO to operate multiple BNs. We haven't started to work on this yet though. As always - contributions are very welcome!

Regards,

Ivan Schasny | R3 | Solutions Engineer

2 London Wall Place, 12th Floor, London, EC2Y 5AU

M: +44 7904 873089

ivan.schasny@... | www.r3.com | www.corda.net


From: corda-dev@groups.io <corda-dev@groups.io> on behalf of Barry Kreiser via Groups.Io <barry=guild1.com@groups.io>
Sent: 30 May 2019 14:25
To: corda-dev@groups.io
Subject: [corda-dev] Membership
 
Ivan,

Should a BNO be able to join its own Business Network?  Currently it gives an error if you initiate a RequestMembership Flow against yourself with the error (Do not provide flow sessions for the local node. FinalityFlow will record the notarised transaction locally.) .  

_______________________________________________

Barry Kreiser | Director/CTO GuildOne Inc.

Suite 940 333-5th Avenue SW, Calgary, AB T2P 3B6


Re: Membership

Barry Kreiser
 

Ok, thanks.  I submitted a PR for another membership issue if you want to have a look.  It wasn't allowing String to be used for the membership meta data.

_______________________________________________

Barry Kreiser | Director/CTO GuildOne Inc.

Suite 940 333-5th Avenue SW, Calgary, AB T2P 3B6



On Thu, May 30, 2019 at 8:25 AM Ivan Schasny via Groups.Io <Ivan.Schasny=r3.com@groups.io> wrote:
Hi Barry,

currently it's not supported, but it's on our backlog. There are two separate tasks: to allow BNO to be both operator and a member as well as to allow one BNO to operate multiple BNs. We haven't started to work on this yet though. As always - contributions are very welcome!

Regards,

Ivan Schasny | R3 | Solutions Engineer

2 London Wall Place, 12th Floor, London, EC2Y 5AU

M: +44 7904 873089

ivan.schasny@... | www.r3.com | www.corda.net


From: corda-dev@groups.io <corda-dev@groups.io> on behalf of Barry Kreiser via Groups.Io <barry=guild1.com@groups.io>
Sent: 30 May 2019 14:25
To: corda-dev@groups.io
Subject: [corda-dev] Membership
 
Ivan,

Should a BNO be able to join its own Business Network?  Currently it gives an error if you initiate a RequestMembership Flow against yourself with the error (Do not provide flow sessions for the local node. FinalityFlow will record the notarised transaction locally.) .  

_______________________________________________

Barry Kreiser | Director/CTO GuildOne Inc.

Suite 940 333-5th Avenue SW, Calgary, AB T2P 3B6


Re: Membership

Ivan Schasny
 

Hi Barry,

currently it's not supported, but it's on our backlog. There are two separate tasks: to allow BNO to be both operator and a member as well as to allow one BNO to operate multiple BNs. We haven't started to work on this yet though. As always - contributions are very welcome!

Regards,

Ivan Schasny | R3 | Solutions Engineer

2 London Wall Place, 12th Floor, London, EC2Y 5AU

M: +44 7904 873089

ivan.schasny@... | www.r3.com | www.corda.net


From: corda-dev@groups.io <corda-dev@groups.io> on behalf of Barry Kreiser via Groups.Io <barry@...>
Sent: 30 May 2019 14:25
To: corda-dev@groups.io
Subject: [corda-dev] Membership
 
Ivan,

Should a BNO be able to join its own Business Network?  Currently it gives an error if you initiate a RequestMembership Flow against yourself with the error (Do not provide flow sessions for the local node. FinalityFlow will record the notarised transaction locally.) .  

_______________________________________________

Barry Kreiser | Director/CTO GuildOne Inc.

Suite 940 333-5th Avenue SW, Calgary, AB T2P 3B6


Membership

Barry Kreiser
 

Ivan,

Should a BNO be able to join its own Business Network?  Currently it gives an error if you initiate a RequestMembership Flow against yourself with the error (Do not provide flow sessions for the local node. FinalityFlow will record the notarised transaction locally.) .  

_______________________________________________

Barry Kreiser | Director/CTO GuildOne Inc.

Suite 940 333-5th Avenue SW, Calgary, AB T2P 3B6


Corda Network builder 4.0 download link is broken

qian yan
 


Re: CE 4.0 - additionalP2PAddresses

Sean
 

Hi Bogdan,
  You are right I misunderstood how that works. I had hoped that the back-up is always running in some kind of disabled mode - it does not process flows and/or handle messages, but it does periodically (per waitInterval) query the database to figure out if the active lease has expired to determine if it is its own turn to become the primary. That is, I had thought the back-up is a warm standby which can automatically become active shortly after the primary becomes inactive.
  After briefly testing the primary and back-up nodes with additionalP2PAddresses and mutualExclusionConfiguration, I have realized that is not the case. What actually happens is that, it seems to me, when the back-up tries to start, it first queries the db for the current lease timestamp, then it waits for a period as determined by waitInterval to query the db again to see if the timestamp has changed. If yes, the back-up will shut itself down (become cold). If no, then the back-up will start to take over as the new primary. Not sure about the exact algorithm implemented but seems to be something like that. Of course, to make it work, as documented, the primary updateInterval must be smaller that the back-up waitInterval.
  Please let me know if my new understanding is still off.
  Thanks.
\Sean 
  


Security Advisory - Corda Settler

James Brown
 

Affects: Corda Settler

Severity: Medium

Overview

A vulnerability in Corda Settler was reported to R3 through the Corda vulnerability disclosure process. The vulnerability affected, but was limited to, XRP payments in the Corda Settler application. Other payment mechanisms were unaffected. No parties were affected by the vulnerability, and users of Corda Settler should take advantage of the fix made in the public GitHub repository. R3 would like to thank Markus Alvila (@RareData) for his research efforts, and for responsibly disclosing the vulnerability.

Analysis

Corda Settler is an open source CorDapp that allows payment obligations arising on the Corda Network to be settled via parallel crypto-assets. The vulnerability was caused by the Settler application's handling of the partial payments feature in the Ripple protocol. 

The vulnerability was limited to XRP payments in a Corda network; other payment mechanisms were unaffected. A malicious node in a Corda network could have exploited the partial payments feature in the Ripple protocol to withhold payment, whilst the Corda obligation would resolve as fully settled.

The trust model of a Corda network mitigates the impact of this vulnerability. Identities are unique on a network, with assurance of that uniqueness provided by a mutually trusted Network Operator. Nodes verify the identity asserted by a peer is well known to them before accepting XRP payments. The vulnerability was not exposed to users of the Settler application; in order to have exploited the flaw, a node operator would have needed to act maliciously and manually settle an obligation.

Remediation

The vulnerability was fixed on  and is available on the master branch of the Corda Settler GitHub public repository. Any party using Settler as a basis for settlement should take advantage of the fix by pulling from master. Updating will also benefit from recent changes to use the new Tokens SDK and rebasing onto Corda 4.1.


Re: Token SDK Corda 4 issues

Hanuman kumar
 

Dear Roger,

We've resolved this issue.

Regards,
Hanu


On Thu, May 23, 2019 at 4:17 PM Roger Willis via Groups.Io <roger.willis=r3.com@groups.io> wrote:
Thanks for raising this. Tokens team will look into it. Can you email me direct? roger.willis@.... Would be useful to see node logs. Thanks.

 

From: corda-dev@groups.io on behalf of hanubc7743 via Groups.Io <hanubc7743=gmail.com@groups.io>
Sent: Thursday, May 23, 2019 11:45 am
To: corda-dev@groups.io
Subject: [corda-dev] Token SDK Corda 4 issues
 
Hi All,
 
We have modeled 2 scenarios using TokenSDK, outlined below, using Ownable state.
 
Scenario 1: issueToken - Self issue of tokens i.e. PartyA issuing tokens to itself
Scenario 2: moveToken - moving tokens between 2 parties, for instance transferring from PartyA (issuer) to PartyB (receiver).
 
These 2 scenarios have been perfectly woking in Corda 3.0. Later we migrated to code to Corda 4.0, to integrate with ‘accounts’ capability. We are facing a strange issue in Scenario 2 - moveTokens. 
When tokens are moved between parties; the transaction is updated in issuer ledger/vault immediately, but not in receiver ledger/vault. The receive ledger lags by one update. For instance, after 3 moveToken transactions with PartyA as issuer and PartyB as receiver, with vault query we could see a 3 ledger updates in PartyA value, whilst only 2 in PartyB. The receiver vault is always showing ’N-1’ state. Apart the required code alignment for compiling in Corda 4, code set is are across projects. 
 
Appreciate your help to resolve this issue. Let me know, if you need more details.
 
PS: We have raised this in Corda Slack community as well.


Regards,
Hanuman


Re: Changes related to networkmap interface for Corda 4.0

Mahesh Govind
 

Thank you


On Wed, May 22, 2019 at 6:52 PM <krishnathp@...> wrote:

Fuzz, 

Cordite NMS "edge" version (docker version) works fine with Corda 4 Enterprise 



--
Co-Founder - Digiledge
+91 9591810218


Re: Token SDK Corda 4 issues

Don Li <lichunshen84@...>
 

Roger,

I meant, the sender/account owner/user would be explicitly required to enter private key during the "send" or "transfer" process or operation with Corda, yes?

Thanks.

(Don) Chunshen Li


On Thu, May 23, 2019 at 9:03 AM Roger Willis via Groups.Io <roger.willis=r3.com@groups.io> wrote:

Yes, of course holders of tokens must sign transactions with the private key corresponding to the public key which the tokens are assigned to. Cheers

 

From: <corda-dev@groups.io> on behalf of "Don Li via Groups.Io" <lichunshen84=gmail.com@groups.io>
Reply-To: "corda-dev@groups.io" <corda-dev@groups.io>
Date: Thursday, 23 May 2019 at 13:58
To: "corda-dev@groups.io" <corda-dev@groups.io>
Subject: Re: [corda-dev] Token SDK Corda 4 issues

 

Hi,

 

I'm curious to know if moveToken operation or function requires private key. I understand with EOS etc. public blockchain initiative, each send or transfer operation requires private key of the sender (account or user), which I think is a good idea from security point of view because with the private key requirement and when it is not stored on the file system then even if the account (sender)'s password is hacked, the hacker won't be able to steal since he/she does not have the private key.

 

Though I'm not a Corda developer I'm keenly interested in crypto economy concept and Corda's development.

 

Thanks.

(Don) Chunshen Li

 

 

On Thu, May 23, 2019 at 6:44 AM <hanubc7743@...> wrote:

Hi All,

 

We have modeled 2 scenarios using TokenSDK, outlined below, using Ownable state.

 

Scenario 1: issueToken - Self issue of tokens i.e. PartyA issuing tokens to itself

Scenario 2: moveToken - moving tokens between 2 parties, for instance transferring from PartyA (issuer) to PartyB (receiver).

 

These 2 scenarios have been perfectly woking in Corda 3.0. Later we migrated to code to Corda 4.0, to integrate with ‘accounts’ capability. We are facing a strange issue in Scenario 2 - moveTokens. 

When tokens are moved between parties; the transaction is updated in issuer ledger/vault immediately, but not in receiver ledger/vault. The receive ledger lags by one update. For instance, after 3 moveToken transactions with PartyA as issuer and PartyB as receiver, with vault query we could see a 3 ledger updates in PartyA value, whilst only 2 in PartyB. The receiver vault is always showing ’N-1’ state. Apart the required code alignment for compiling in Corda 4, code set is are across projects. 

 

Appreciate your help to resolve this issue. Let me know, if you need more details.

 

PS: We have raised this in Corda Slack community as well.


Regards,
Hanuman


Re: Token SDK Corda 4 issues

Ryan Gledhill
 

Don Li, this is one of the key tenets of any cryptographically-secured ledger - and of course the Token SDK/Corda.


Re: Token SDK Corda 4 issues

Roger Willis <roger.willis@...>
 

Yes, of course holders of tokens must sign transactions with the private key corresponding to the public key which the tokens are assigned to. Cheers

 

From: <corda-dev@groups.io> on behalf of "Don Li via Groups.Io" <lichunshen84@...>
Reply-To: "corda-dev@groups.io" <corda-dev@groups.io>
Date: Thursday, 23 May 2019 at 13:58
To: "corda-dev@groups.io" <corda-dev@groups.io>
Subject: Re: [corda-dev] Token SDK Corda 4 issues

 

Hi,

 

I'm curious to know if moveToken operation or function requires private key. I understand with EOS etc. public blockchain initiative, each send or transfer operation requires private key of the sender (account or user), which I think is a good idea from security point of view because with the private key requirement and when it is not stored on the file system then even if the account (sender)'s password is hacked, the hacker won't be able to steal since he/she does not have the private key.

 

Though I'm not a Corda developer I'm keenly interested in crypto economy concept and Corda's development.

 

Thanks.

(Don) Chunshen Li

 

 

On Thu, May 23, 2019 at 6:44 AM <hanubc7743@...> wrote:

Hi All,

 

We have modeled 2 scenarios using TokenSDK, outlined below, using Ownable state.

 

Scenario 1: issueToken - Self issue of tokens i.e. PartyA issuing tokens to itself

Scenario 2: moveToken - moving tokens between 2 parties, for instance transferring from PartyA (issuer) to PartyB (receiver).

 

These 2 scenarios have been perfectly woking in Corda 3.0. Later we migrated to code to Corda 4.0, to integrate with ‘accounts’ capability. We are facing a strange issue in Scenario 2 - moveTokens. 

When tokens are moved between parties; the transaction is updated in issuer ledger/vault immediately, but not in receiver ledger/vault. The receive ledger lags by one update. For instance, after 3 moveToken transactions with PartyA as issuer and PartyB as receiver, with vault query we could see a 3 ledger updates in PartyA value, whilst only 2 in PartyB. The receiver vault is always showing ’N-1’ state. Apart the required code alignment for compiling in Corda 4, code set is are across projects. 

 

Appreciate your help to resolve this issue. Let me know, if you need more details.

 

PS: We have raised this in Corda Slack community as well.


Regards,
Hanuman


Re: Timestamp on Transactions

Mike Hearn
 

There's never a bad time to invoke special relativity!

TrueTime uses time windows too, they're just automatically adapted to be as small as possible with as tight a tolerance as possible. Clock drift causes time windows to be widened, which means transactions take longer to commit and thus latency / resource usage goes up, but otherwise is handled appropriately.

You can order transactions by taking the mid-point of the time window (assuming it's closed at both ends) and treating that as the canonical timestamp. Of course many transactions may end up being located on the exact same moment of the timeline and those can't be ordered temporally, a consistent ordering would need to fall back to e.g. hash or perhaps better, hash of the notary signatures, to stop people trying to game their position in the list by grinding the Merkle root.

But for billing it's maybe not needed. A local clock is sufficient.


Re: Token SDK Corda 4 issues

Don Li <lichunshen84@...>
 

Hi,

I'm curious to know if moveToken operation or function requires private key. I understand with EOS etc. public blockchain initiative, each send or transfer operation requires private key of the sender (account or user), which I think is a good idea from security point of view because with the private key requirement and when it is not stored on the file system then even if the account (sender)'s password is hacked, the hacker won't be able to steal since he/she does not have the private key.

Though I'm not a Corda developer I'm keenly interested in crypto economy concept and Corda's development.

Thanks.

(Don) Chunshen Li


On Thu, May 23, 2019 at 6:44 AM <hanubc7743@...> wrote:
Hi All,
 
We have modeled 2 scenarios using TokenSDK, outlined below, using Ownable state.
 
Scenario 1: issueToken - Self issue of tokens i.e. PartyA issuing tokens to itself
Scenario 2: moveToken - moving tokens between 2 parties, for instance transferring from PartyA (issuer) to PartyB (receiver).
 
These 2 scenarios have been perfectly woking in Corda 3.0. Later we migrated to code to Corda 4.0, to integrate with ‘accounts’ capability. We are facing a strange issue in Scenario 2 - moveTokens. 
When tokens are moved between parties; the transaction is updated in issuer ledger/vault immediately, but not in receiver ledger/vault. The receive ledger lags by one update. For instance, after 3 moveToken transactions with PartyA as issuer and PartyB as receiver, with vault query we could see a 3 ledger updates in PartyA value, whilst only 2 in PartyB. The receiver vault is always showing ’N-1’ state. Apart the required code alignment for compiling in Corda 4, code set is are across projects. 
 
Appreciate your help to resolve this issue. Let me know, if you need more details.
 
PS: We have raised this in Corda Slack community as well.


Regards,
Hanuman


Re: Timestamp on Transactions

Farzad
 

Definitely agree with this Richard. 
How is the width of the time-range calculated/defined? Is it sensitive to network latency, load, and server clock errors?

I'm thinking that in a leaderless multi-node notary cluster, where there isn't a single unified clock, timestamps and windows cannot be used to order transactions in a consistent way.

The premise being that in any lock-free distributed system (e.g. the notary), a unified clock, in the general case, is not possible, right? Clocks drift and no algorithm is perfect in keeping synchrony (I'm sure we all have our horror stories here). 
LAN clusters like Coherence use involved algorithms and heuristics to compensate for server clock errors, but I've seen them go wrong before. Allegedly, Google's Spanner TrueTime is an exception.

One of the earlier posters said that this doesn't matter as long as transactions can be grouped in a coarse-grained range. I wonder if the use-case is sensitive to close-to-midnight transactions.

PS Is this the moment we can invoke Special Relativity? ;)

On 9 May 2019, at 16:21, richard via Groups.Io <richard@...> wrote:

It definitely makes sense that a node should have the ability to record (for its own use) what time it thinks various things happened (eg the time it thinks it proposed, or signed, or received, a finalised transaction, et) – and that’s what I thought this discussion about database tables was about.  I does feel like a gap/oversight that we don’t currently record something useful here.  *Mike* - I think you were suggesting we’d look favourably on PRs in that area?
 
However, as James hints, the question of timestamps upon which _other_ parties rely is harder.  Put bluntly, a “transaction proposed” timestamp James attaches to a transaction is not actually the time he proposed it. It is the time he _claims_ he proposed it.  And it’s hard to think of many situations where anybody else on the network could or should rely on that.  And I happen to know James is a pretty honest individual……
 
When you take it further and work through real examples one quickly concludes that you have to delegate some of this to the notary cluster.   One particularly useful thought experiment was that of an option with an expiry time of midnight tonight.
 
Imagine I own that option.  If I can simply assert the time at which I exercised it then I could try to exercise it at 00:01 tomorrow (after expiry) but put a timestamp of 23:59 today.  That’s not going to work in the real world of course.   So what if we say: ‘you have to get the transaction signed by a timestamp oracle’?  Well… I could get it signed at 23:59… but then hold on to it until tomorrow…. Maybe it was out of the money today but turns out to be in the money tomorrow…. So I now reveal the transaction and you have to, say, deliver the underlying asset to me. I’ve effectively just stolen value from you.     
 
Follow through the logic and you end up concluding that “the act of securing a timestamp upon which other people can rely” has to be coincident with “the act of confirming the transaction”.  In other words, the notary has to be the timestamp oracle.   Hence the (weird when you first encounter it) approach of asserting a time range in a command and then inviting the notary to countersign only if the notary’s time is within that window.  Any other approach leads to opportunities for clever gameplay.
 
But, that all said, if you just want a local record of when various things happened from your perspective, we should definitely make it easy to do that!
 
Richard
 
Richard G Brown R3. | Chief Technology Officer
2 London Wall Place | Floor 12 | London | EC2Y 5AU
M: +44 7764 666821 | T: @gendal
 
From: <corda-dev@groups.io> on behalf of "James Brown via Groups.Io" <james.brown@...>
Reply-To: "corda-dev@groups.io" <corda-dev@groups.io>
Date: Thursday, 9 May 2019 at 16:09
To: "corda-dev@groups.io" <corda-dev@groups.io>
Subject: Re: [corda-dev] Timestamp on Transactions
 
Where's the integrity if the timestamp isn't part of the signature? i.e. if it's a separate column, it doesn't truly form part of the transaction because it's not signed over, righr



Re: Token SDK Corda 4 issues

Roger Willis <roger.willis@...>
 

Thanks for raising this. Tokens team will look into it. Can you email me direct? roger.willis@.... Would be useful to see node logs. Thanks.

 


From: corda-dev@groups.io on behalf of hanubc7743 via Groups.Io <hanubc7743@...>
Sent: Thursday, May 23, 2019 11:45 am
To: corda-dev@groups.io
Subject: [corda-dev] Token SDK Corda 4 issues
 
Hi All,
 
We have modeled 2 scenarios using TokenSDK, outlined below, using Ownable state.
 
Scenario 1: issueToken - Self issue of tokens i.e. PartyA issuing tokens to itself
Scenario 2: moveToken - moving tokens between 2 parties, for instance transferring from PartyA (issuer) to PartyB (receiver).
 
These 2 scenarios have been perfectly woking in Corda 3.0. Later we migrated to code to Corda 4.0, to integrate with ‘accounts’ capability. We are facing a strange issue in Scenario 2 - moveTokens. 
When tokens are moved between parties; the transaction is updated in issuer ledger/vault immediately, but not in receiver ledger/vault. The receive ledger lags by one update. For instance, after 3 moveToken transactions with PartyA as issuer and PartyB as receiver, with vault query we could see a 3 ledger updates in PartyA value, whilst only 2 in PartyB. The receiver vault is always showing ’N-1’ state. Apart the required code alignment for compiling in Corda 4, code set is are across projects. 
 
Appreciate your help to resolve this issue. Let me know, if you need more details.
 
PS: We have raised this in Corda Slack community as well.


Regards,
Hanuman


Token SDK Corda 4 issues

Hanuman kumar
 

Hi All,
 
We have modeled 2 scenarios using TokenSDK, outlined below, using Ownable state.
 
Scenario 1: issueToken - Self issue of tokens i.e. PartyA issuing tokens to itself
Scenario 2: moveToken - moving tokens between 2 parties, for instance transferring from PartyA (issuer) to PartyB (receiver).
 
These 2 scenarios have been perfectly woking in Corda 3.0. Later we migrated to code to Corda 4.0, to integrate with ‘accounts’ capability. We are facing a strange issue in Scenario 2 - moveTokens. 
When tokens are moved between parties; the transaction is updated in issuer ledger/vault immediately, but not in receiver ledger/vault. The receive ledger lags by one update. For instance, after 3 moveToken transactions with PartyA as issuer and PartyB as receiver, with vault query we could see a 3 ledger updates in PartyA value, whilst only 2 in PartyB. The receiver vault is always showing ’N-1’ state. Apart the required code alignment for compiling in Corda 4, code set is are across projects. 
 
Appreciate your help to resolve this issue. Let me know, if you need more details.
 
PS: We have raised this in Corda Slack community as well.


Regards,
Hanuman


Re: Changes related to networkmap interface for Corda 4.0

krishnathp@...
 

Fuzz, 

Cordite NMS "edge" version (docker version) works fine with Corda 4 Enterprise 


Re: Changes related to networkmap interface for Corda 4.0

Farzad
 

I think there are reports that it doesn't work with Corda 4 enterprise. I'm working on the upgrade to v4 as I type :-) ETA hopefully next week

On 22 May 2019, at 13:27, Remo Meier <remo.meier.ch@...> wrote:

The Cordite network map works fine for us both with Corda 4.0 and the RC branch of Corda 4.1.

Regards Remo

521 - 540 of 1475