I'm trying to write a simple cordapp for issuing and selling bonds.
Got this:
1) Bank issues a bond. (0 inputs, one output, bank the issuer and still the holder)
Want also this:
1) Client can query the bank for the type of bond the client wants to buy (i.e. currency, face value, maturity) and the price of the bond.
If the bank has the bond the client seeks and the client agrees with the price I would like to create a transaction where the bond changes owner from bank to client and where money is exchanged.
Now this transaction should be initiated by the client I'd think. But the client doesn't have the bond state. I can get that from the bank by using sendAndReceive but then the bond state doesn't resolve when translating to ledger transaction (understandably). So I'm thinking do I have to send the whole transaction that issued the bond over to the client first? I guess that would work but seems clunky. Am I missing something?
Yes, the client would need the transaction that issued the bond. Without this, they wouldn't be able to verify this issuance transaction, and therefore couldn't assure themselves that the new transaction they were creating was valid.
It would work as follows:
The bank would retrieve the bond issuance transaction from their transaction storage and call SendTransactionFlow to send this transaction to the client (who would call ReceiveTransactionFlow in response)
The bank would retrieve the bond state from their vault and send it to the client
The client would build the transaction as normal
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.
At the risk of sounding naive, I ask myself "Is a validating notary necessary?", given all the issues with it - transaction and dependencies leak, exposure of state model, to name a few.
The answer I hear has something to do with the potential attack where a dishonest node tries to steal someone else's asset. For example, in a legitimate transaction, partyA sold partyB some asset S subject to a Move contract. Immediately afterwards, partyA creates a self-signed transaction that transfers S back to himself subject to a dummy contract in a bogus flow that does not even run the ledger transaction verify(). But when he calls FinaltyFlow to satisfy the simple notary to commit the transaction on the ledger, it will fail the verifyContracts() because S appoints to the Move contract which should say owner partyB must sign the bogus transaction.
So that does not convince me of the need for a validating notary.
Apparently, I must have missed something. Can someone enlighten me?
Thanks.
\Sean
As you say, the advantage of the validating notary is that it prevents a malicious party from "wedging" a state - that is, creating an invalid transaction that consumes an unconsumed state that they are aware of. Although the transaction is invalid, the non-validating notary would not be aware of this, and would mark the state as spent.
You're correct that this invalid transaction would fail the FinalityFlow's call to verifyContracts(). However, we cannot force a malicious node to use FinalityFlow to send something to the notary. If the malicious node was sufficiently motivated, they could build the invalid transaction hash by hand and send that to the notary directly, for example.
However, note that in the non-validating notary case, there are still multiple layers of protection against wedging:
The malicious party has to be aware of the state(s) they want to wedge. Since information in Corda is only distributed on a need-to-know basis, the node would only be aware of a small subset of unconsumed states
If the state is wedged by accident, the node can show the invalid transaction to the notary. Upon seeing that the transaction is invalid, the notary will mark the re-mark the state as unconsumed
As Corda is a permissioned network, the notary can keep a record of the legal identity of everyone who submits a transaction. If a malicious node is submitting invalid transactions to consume states, their identity will be known, and the dispute can be resolved outside of the platform, based on the agreements governing participation in the network
On the other hand, SGX addresses the data leak issue associated with validating notaries. If the validation of the transaction occurs within an SGX enclave, the validating notary gains no information about the contents of the transaction they are validating.
Ultimately, the choice between validating and non-validating notaries comes down to the threat model associated with a given deployment. If you are using Corda in a setting where you are sure the participants won't deliberately change their node's code or act maliciously, then a validating notary is not needed.
But if you assume somebody WILL try to cheat and would be willing to write their own code to do so, then a validating notary provides an extra layer of protection.
So Corda provides choices:
Choose to reveal more to a notary cluster if you trust the participants relatively less...
Choose to reveal less to a notary cluster if you consider the risk of revealing too much to the notaries to be the bigger problem
(and use SGX if you're paranoid about everybody!)
ORPOS transaction queue is getting stuck due to "the customer name that is read from the magnetic stripe of the card comes in as 50+ characters that looks like an encryption code
The details you provide indicate the fault with the card and/or the validation system. But regarding the transaction queue thing, make sure the connection is robust because having the BO database or the store server offline leaves you getting transaction queued up at POS.
I am making Billing server for Conference calls. I am using Asterisk and A2Billing. All things work when Single Calling Card make call. But when Single Calling Card make concurrent calls then Billing server don't perform well due to A2Biling programming.
When call was generated from a2biling then A2B check credit and then after testing with Tariiffplan convert into nen0seconds. So don't check that we are making Single call or making another call from that card.
So if anyone know how to make real-time billing with asterisk server then please help me .....
In that case, it might be best to use a billing system able to do real time billing. NibbleBill is a billing system available for Freeswitch and it can do it. A2Billing will not cut it for you because it does things differently by checking the account balance only at the beginning of the call and updating the account balance at the en of the call. Let's make the following assumptions:
The account's credit is $10
The average session time of 5 minutes
There are 10 participants in the conference
The following WILL happen:
If all the participants get connected in less than 5 minutes (the average session duration), then they will all hear (if audio where activated): You have 10$
At the end of the call, each participant will potential consume a maximum of 10$
If all the participant use up the $10, the final account balance will be a big fat negative -$90 which is the initial $10 minute $10 x 10 participants ($100).
A real real-time billing system will have a daemon running in the background and monitoring the lines. It will be able to disconnect any call when the total credit used by all the instances of a given account reaches ~0.
When do distributed transactions make sense in a service-oriented architecture?
Distributed transactions are used very often in SOA environments. If you've a composite service calling multiple services, the underlying service calls should be handled as a single transaction. Business processes should allow for a roll-back of their steps. If the underlying resources allow for it, you can use 2-phase commits, but in many cases it is impossible. In these cases compensating actions should be done on the services/resources invoked before the failed step. In other words, undo the succeeded steps in a reverse order.
Imaginary example: telecom company provisions a new VoIP product for a customer with 6 service calls:
query inventory to check the customer has the right equipment
configure customer equipment via mediation
update inventory with new configuration
set up rating engine to count CDR's for customer
set up billing software to charge the customer with the correct price plan
update CRM system with the result of the provisioning process
The 6 steps above should be parts of one transaction. E.g. if inventory update fails, you (may) need to undo the customer equipment configuration.
Not really a case of when they make sense. A transaction (distributed or not) is implemented by necessity rather than arbitrary choice, to guarentee consistency. The alternative is to implement a reconcilliation process to ensure eventual consistency.
In the classic bank example (money out of account A, into account B), transactional consistency is pretty much essential. In some inventory systems (check inventory, decrement inventory, sell to customer), it may be acceptable for stock levels to be roughly accurate, rather than guarenteed. In which case, ignoring a failure (decrement inventory, sale fails to complete) could be dealt with by reconciling later.