I am reading to understand and trying to adapt Corda into my project and I found this issue as one of the drawbacks of corda: link.
Basically, in Corda, since no one holds all the ledger. So if one node receives a tx proposal, he must also prove that the tx input is also valid by recursively verifying all txs that create this input from the issuance tx.
Can someone explain or point me out or show me where can I read more about this from the official documentation of Corda. Thanks.
I think it's about Notaries. Please check here:
https://docs.corda.net/key-concepts-notaries.html
Related
I've been working on some ideas to determine the initiator of a transaction in Corda. It's quite hard to prove since transactions can be signed by one (trivial to prove), or more (hard to prove) parties.
However I'm now wondering if there's something inherent to the transaction itself that can be used to trivially determine who initiated a transaction.
When a transaction that requires multiple signatures is created, we call the CollectSignaturesFlow to obtain counter-party signatures, however if we do this before signing the transaction ourselves, we get the following exception:
The Initiator of CollectSignaturesFlow must have signed the transaction.
Therefore I could assume that the first signature in the transaction must have some from the initiator. Is it safe to assume that SignedTransaction.sigs[0] is the transaction initiator?
Footnote 1: The code that throws the above exception is implemented as such:
require(partiallySignedTx.sigs.any { it.by in myKeys }) {
"The Initiator of CollectSignaturesFlow must have signed the transaction."
}
This would suggest that one (or specifically more) signatures applied to the transaction will belong to the initiator.
Footnote 2: Would transaction storage (serialization/deserialization) have any impact on the ordering of the sigs list? - If it's order isn't deterministic, then we cannot rely on sigs[0] being the initiator.
Phoned a friend from r3, from Alex Koller
I looked at the question and it's not very clear to me what is Matthew trying to achieve. AFAIK corda doesn't record who initiated a transaction and trying to devise that from the order of the signatures on the tx is probably prone to error now or in the future. A possibility would be to look at the notary and see who requested the notarisation. But that may be suitable in minority of use cases. If the holder of the tx should need to know who initiated it then it may have to be recorded in one of the states. But you obviously cannot prove the correctness of the value in the state from the tx contracts, so it would have to be atested to by the other signers on the tx (in the collect signature responding flow, before the counterparties sign). I think we would need to know more about what he's doing to be able to advise. He should get in touch with Professional Services.
I am new to Corda. My question is not about any particular implementation, but more of an architectural question.
What happens during back chain validation if one of the nodes involved permanently dies and fails to respond? How is that transaction validated?
I have seen this issue that only talks about how of transaction volume could slow down validation. Does validation come to a grinding halt if one of the nodes fails permanently?
As per Corda webinar on Consensus, in the example that is 5 minutes into the video, the back chain is Charlie -> Dan -> Alice -> Bob. In this, if either Charlie or Dan are unavailable, the proposed transaction cannot be validated. The same webinar further says that this is not a problem in other blockchains such as Ethereum.
Applications that can foresee the need for a highly-available record keeper, can surely accommodate such a node during the design phase, as suggested by Adel Rustum.
However, a privacy-conscious application reluctant to leak information that is deployed globally, could suffer from many transaction-validation failures due to the vagaries of a wide-area network. Thoughts?
The short answer is, transaction verification will fail (if that node was the only node that had that transaction); and that's the point of using a DLT (or a blockchain). If you can't go back in the history of a certain block of data until genesis, then you can't verify how that block and its ancestors were created.
As for the issue that you referenced in your question; Corda Enterprise 4.4 introduced a new feature called bulk back-chain fetching, which allows modifying the way the transactions that are needed to verify a certain transaction are fetched. Previously it was depth first, now you can change that to breadth first and specify how many transactions you want to fetch in one call. More details in this video.
The back chain validation doesn't depend on the nodes who were part of the transaction in the past. The validation of the back chain is only done by those nodes who are part of the current ongoing transaction. The other nodes who were part of a past transaction that involves the evolution of a state in question don't need to be contacted (or stay online) while the back chain is validated.
Back chain validation only involves checking that all transaction which happened in the past on a particular state used as input in the current transaction is valid. The validity is checked by running the contracts again for those previous transactions. There is no real need to reach to the parties of a previous transaction.
However, you need to make sure that the parties involved in the current transaction are online and responding since you would need signatures from them to successfully complete the transaction.
I am new to Corda and have a question how to properly implement a whitelist in Corda.
Let's assume a fungible security token is issued on Corda that has to meet a certain kind of regulation (e.g., the investor is not allowed to be from a certain country). Therefore a whitelist would be required to make sure that all regulation requirements are met.
In a private network I assume that there is no need for an actual whitelist, as the issuer who runs the node can control who is allowed to join the network and who isn't.
But on the public Corda network there are potentially many identities who are not allowed to hold a certain type of token and a whitelist would be required.
What would be the proper design choice for this kind of problem?
I thought about having a WhitelistState which holds a set of all whitelisted investors. But if I understood correctly, each participant of the state (in this case the issuer and the investors) would have to sign a transaction if a new investor was added or removed from the whitelist, which is not a suitable solution.
I would appreciate any helpful advice on how to solve such an issue!
Have a look at the blacklist project in the samples repo:
https://github.com/corda/samples/tree/release-V4/blacklist
Essentially what they do:
1. Inside ReachAgreementFlow they add an attachment to the transaction, that attachment is a jar file that contains blacklist.txt file.
2. Inside the state contract AgreementContract (which validates the transaction) they extract the jar and read its contents and make sure that the company listed in the agreement is not part of the blacklist.
I`m trying to build a script that will capture the credit card info like card number,cvc and expiration date using asterisk 11.x and asterisk-java library for AMI/AGI integration.
Right now I am able to build a script that will acquire that info if it is called via dialplan but i have a different scenario:
1. A call enters a queue.
2. An agent from the specific queue answer the call
3. The caller wants to input the card details
4. After the caller has entered the card details is redirected back to agent to continue the call.
My specific problem is related to step 3 as I do not know how to route the caller to my AGI and then back to the same agent. (eventually the agents has to be still involved in (some) call to guarantee that when the caller returns from agi it is still available)
Any idea how can I achieve that ? I know that this is a common practice so I think that there has to be a way.
When the call is delivered to the agent, use a macro to set a custom channel variable with the agent ID or extension in it.
Then, when your credit-card authentication function is done, read the variable and use an AGI command to transfer the call back to the agent.
Further Reading
http://www.voip-info.org/wiki/view/Asterisk+variables
http://www.voip-info.org/wiki/view/Asterisk+manager+Example:+Transfer
Note if this solution solves your problem, please 'accept' it to make it easier for others with the same issue to find it. thanks!
There are no any common practice for business process like you have. That depend of you and your client only.
You can use features conf or transfer. Can transfer to special extension or to conference room.
No way say what suite you better.
For sure you need understand how asterisk work before write any AGI/AMI or dialplan application. I can recommend ORelly's "Asterisk the future of telephony" book as start point.
In Blackberry application I want to check what type of network connection is being used on particular phone, whether it is BES/MDS,BIS-B or Direct Tcp.
Is there any way to find out this?
Many applications like Jive,Opera and many more are doing this kind of check.
Please help.
The question is quite logical and I do agree with Richard as well. Though a better answer lies in the fact that there can be a logic developed which would involve Service Book parsing and making use of system listeners to check the current coverage status.
I had attempted to make one such logic once in my project which worked for me. I had shared my findings and understanding about the concept in more detail at my blog post. May be you would like to check once.
You can find my blog post here.
Your question springs from an incorrect assumption. A Blackberry could be communicating over any or all of those channels simultaneously. In fact any application may as well. At any particular time you can determine if coverage is sufficient for one of those channels, or register a listener for notification of changing status using net.rim.device.api.system.CoverageInfo.