For example we have 3 Nodes Say
Party A
Party B
Party C
Consider these transactions
Party A Self issues 10 USD
Party A transfers 10 USD to Party B
Party B transfers 10 USD to Party C
So my question is can Party c know that this 10 USD is came from Party A?
Yes, Party C knows that this 10 USD came from Party A. Party C automatically resolves the chain of transactions back to transaction 1 when receiving transaction three.
This allows Party C to ensure that the entire chain of transactions is valid, and not just the latest transaction.
In the future, the use of SGX will likely allow parties to verify an entire transaction chain without seeing the contents of each transaction. So Party C would not see that Party A issued the original cash.
Corda also allows each owner in the transaction chain to choose to identify themselves using an anonymous, one-time-use public key instead of a well-known identity. Thus someone walking the chain will not see who the past owners were.
Related
I have some basic questions about Corda's transaction functionality:
For transactions between alice & bob, does bob have to manually sign/verify the transaction or does bob's node automatically sign for it?
If I am transacting with a bank that is on your platform, like HSBC, and I withdraw funds, would the funds go directly into my HSBC bank account?
From what I've learnt so far, is that Corda's notary service acts as a TTP; however, what if I don't trust Corda's notary service and want a consensus mechanism that isn't reliant on any authority?
Nodes don't have to sign transactions manually, signing happens in the context of the flows written in the CordDapp, the CorDapps are installed in the node.
That would depend on the scope of the implementation. If the central bank is issuing the currency on Corda (something like CBDC), then with the new account functionality, yes that is a possibility.
A notary is just a general Corda node with some extra responsibility for preventing double-spending. You cannot really remove the notary altogether, but yes the consensus in notary cluster is pluggable. You could choose a different consensus algorith. Refer here for more details: https://docs.corda.net/key-concepts-notaries.html#consensus-algorithms
If a group of companies want to create a loyalty token scheme via a Corda network, how do they enable customers to be able to receive or spend loyalty tokens via any of the participating company channels?
For example, Alice earns 100 tokens from Company X's shopping app for being a loyal customer. The record of Alice's balance is captured on the Corda ledger via Company X's Corda node. Alice then wants to spend these tokens on Company Y's shopping app.
How is Alice identified on the Corda network?
How can this be achieved so that only Alice has the power to spend her tokens (i.e. the participating companies cannot edit her balance without her consent.)?
I'm thinking this could be achieved if customers had their own key pair and needed their private key to transact. Is this currently possible on Corda or is it on the roadmap?
Hi this is now possible with accounts-sdk released with Corda 4.3.
So you could now have multiple companies host their customers on their nodes as accounts and have loyalty tokens issued to them. So accounts feature can be integrated with tokens feature.
To your question regarding, How can this be achieved so that only Alice has the power to spend her tokens, tokens sdk makes sure that only the current holder/owner of the token has the right to spend the tokens.
Your last question
I'm thinking this could be achieved if customers had their own key pair and needed their private key to transact. Is this currently possible on Corda or is it on the roadmap?
As I mentioned above that the companies can have their customers represented as accounts on their nodes. But please note that as of now, accounts are not true identities, i.e. they do not have any certificate issued by the doorman. They use anonymous identities to transact with each other. But yes, there is a plan where accounts will be able to move these key pairs outside of the node and effectively own their own private keys.
We have recently been tasked with adding In-App Purchases to our Android mobile application. We have completed this and have started testing small purchases internally in our production environment prior to release.
We're successfully performing the purchase and storing the result in our back-end database. We have a service that contacts the Google API daily to query about the PaymentState for the transaction.
Today our first test purchase changed to 1 (Payment Received).
We have not yet received the money transfer in our bank account, but it's probably on the way.
Our question is, once the PaymentState has changed to 1, how can we reconcile this with our bank account?
Our finance department doesn't like the sound of just trusting that we got the money. We want to ensure that each payment is accounted for in cash.
How are others accomplishing this?
Thanks
Does your bank offer any interface for a computer to interact with your bank account?
In Germany, almost all banks support either the Home Banking Computer Interface (HBCI) or it's successor the Financial Transaction Service (FinTS) to connect arbitrary computer programs with the bank account and pretty much provide all services available on their web-based online banking sites via those interfaces as well.
With such an interface you could then check the transactions on your bank account programmatically and simply check if the transaction reference provided by Google has already arrived on your bank account.
Without knowing where you're based and what your bank is / what interface they provide, it's hard to provide more details. (There are multi-national/somewhat universal electronic interface standards for how banks communicate with one another, but these are usually not open to the customers and most likely don't provide the required data about one account's individual transactions)
Can a third party node view the details within a state without being a participant in the transaction that created that state? The idea is that the transaction created between two nodes is sent to a third node as CC. We don't want to add the third node as a participant since it does not have the right to consume that state.
Any node can see the contents of a transaction if that transaction is sent to it.
Normally, you'd write your flows such that only the relevant parties see the transaction. However, if for whatever reason a third party needs to also see the transaction, you can easily send it to them by including the third party as an additional recipient in FinalityFlow.
Although the third party won't store the transaction in their vault (as they can't spend it), it will still exist in their transaction storage and can be viewed that way.
P.S. Who the transaction's output states can be consumed by depends on the rules imposed by the contracts, and not who the listed participants are.
Other than the use of --testdox for documenting, is there another way I can give a more detailed report for my PHPUnit tests?
Maybe not a direct answer to your question but you could consider using a BDD framework like Behat. The tests are written in plain human language so they express your system behaviour and can be read by non-technical people.
Example from introducing BDD article:
Story: Account Holder withdraws cash
As an Account Holder
I want to withdraw cash from an ATM
So that I can get money when the bank is closed
Scenario 1: Account has sufficient funds
Given the account balance is \$100
And the card is valid
And the machine contains enough money
When the Account Holder requests \$20
Then the ATM should dispense \$20
And the account balance should be \$80
And the card should be returned
Scenario 2: Account has insufficient funds
Given the account balance is \$10
And the card is valid
And the machine contains enough money
When the Account Holder requests \$20
Then the ATM should not dispense any money
And the ATM should say there are insufficient funds
And the account balance should be \$20
And the card should be returned
Scenario 3: Card has been disabled
Given the card is disabled
When the Account Holder requests \$20
Then the ATM should retain the card
And the ATM should say the card has been retained