Let's consider a DvP transaction between NodeA (bond owner) and NodeB (cash owner), where
NodeA sends bond to NodeB.
NodeB sends cash to NodeA.
NodeA builds a tx which InputStates consists of: BondState (queried from its vault) + CashState (sent by NodeB to NodeA using SendStateAndRefFlow).
Let's assume that NodeA does not use Corda's FinalityFlow. NodeA sends the tx to notary. Assume that notary verifies it. Notary then sends back the tx to NodeA. Up until this point, both InputStates in the tx have been marked as consumed.
Now what happens if NodeA is fraudulant, and it does not forward this tx to NodeB? NodeB's cash has been marked as consumed, but it has not received the bond yet.
Interesting question.
I don't think we'd be necessarily dealing with a fraudulent node here, as Node B will have only sign the transaction having confirmed they are the new owner of the bond. In your scenario, the notary will have recorded the bond state with NodeA as the owner as spent and NodeA will be holding a bong that has NodeB as owner. As such, NodeA wouldn't be able to commit fraud, assuming only the current owner can sell on bond.
However, what we are dealing with is a malicious node, and we need to look at this from the perspective of what NodeA gains from this. Aside from creating a problem for NodeB, NodeA gains nothing. They can't go on to use the bond.
As such, you'd anticipate that NodeA opens themselves up to litigation without any gain.
Related
I have experimenting with Bluez 5.50 Bluetooth Stack, Here i have some confusion about procedure Auto-connection using Whitelist.
Suppose,
Device A - Advertiser
Device B - Scanner
Add Advertisers(Device A) Bluetooth address as white list in Scanner(Device B)
Device A will advertise with "Connectable Un-directed" adv type & default adv params
Device B will start scanning with "Accept only PDUs from device in white list" configuration
If B scans A's address, than explicitly B will send connection request to A(Without sending Connection create command)
What is basic difference between paired device & white listed device ?
The white list can be used both when just scanning as well as when connecting.
Note that the packet exchange during advertising is this, when the central device is just scanning:
Advertiser sends ADV_IND.
Scanner sends SCAN_REQ.
Advertiser sends SCAN_RSP.
When the central device has a pending initiation (i.e. connection attempt) to a peripheral, the packet exchange is this:
Advertiser sends ADV_IND.
Initiator sends CONNECT_IND.
The connection is now established.
Note the timing between between to packets in the flow above is 150 microseconds (T_IFS), which is quite quick. If the advertiser does not detect SCAN_REQ, it does not send SCAN_RSP. If it also does not detect CONNECT_IND, it does not enter the connection state, but continue to advertise. There is a need to have a white list because the host would not be quick enough to decide if the packet should be dropped or not. Therefore the white list is implemented directly in the Bluetooth controller hardware.
A central device using the white list, will simply drop any ADV_IND having an address that cannot be found in the white list. Therefore no SCAN_REQ or CONNECT_IND is sent in this case.
"Auto-connect" therefore refers to when the initiator is constantly looking for ADV_IND packets where the sender's address is in the white list. If one is found, a CONNECT_IND is sent and the connection gets established, resulting in an "LE Connection Complete" event. Using the white list is the only way to have two or more pending connections, since otherwise you need to specify exactly one target address when initiating a connection. (Although a workaround sometimes used when the white list cannot be used, for example if it is too small to contain all desired addresses, is to let the central first perform a scan, then initiate a connection to the target addrerss, with some short timeout. This introduces latency as at least two ADV_INDs must be sent.)
Paired/Bonded device is a completely different thing. It means that both devices have stored in its database, information about the remote device, such as encryption keys, client characteristic configuration descriptor state, gatt db cache. Bonded devices are usually listed in a user interface as well.
When the white list is used when establishing connections, you can have addresses in this list of non-bonded devices. You can also have bonded devices which you do not currently want to connect to, which are then not included in the white list.
What I've written above is general BLE without any specific Bluetooth stack in mind. BlueZ might have certain conditions/flows when the white list is used.
What are the cases Access point disconnect station without sending disassociation or deauthentication to station?
I guess it would be pretty strange...the AP is meant to send a disassociation to any connected station. The only possibility that springs to mind is failing to find "clear air" while sending the disassociation.
I.e. AP decides to disassociate a station. The MAC layer receives the request to disassoc the station, and puts it in a queue. Every time the AP attempts to send the disassoc frame there is something else sending, and the AP does not pass the collision avoidance check. Eventually the request in the MAC layer times out.
Party A and Party B doing transaction where Party C extra participant. if Party C wants to reject the transaction by fail to do digital signature while collecting signature, it would possible to do that? if then, how counter parties will get the notification about that transaction to reject or accept?
Party C's Signature has to be mandated to do the Tx. you can put his public key in your Command at the time of creating the Tx between party A and party B. That's how Party C's signature will become mandatory. You can then send the Tx over to Party C to get his signatures, if all goes well as per your business logic then sign the tx and return signed transaction, if not, throw an exception or don't sign the Tx at all.
When you call finality Flow, it checks if all the required signers that were mentioned in the command have signed the tx or not. If not, The Tx is never notarized. I think you can also call verifyRequiredSignatures to check if the required signers have signed the Tx or not. at that point you know Party C has not signed your Tx.
While reading CCENT/CCNA ICND1 Official Exam Certification Guide, I came across steps to how a hub creates an electrical bus:
Step 1 The network interface card (NIC) sends a frame.
Step 2 The NIC loops the sent frame onto its receive pair internally on the card.
Step 3 The hub receives the electrical signal, interpreting the signal as bits so
that it can clean up and repeat the signal.
Step 4 The hub’s internal wiring repeats the signal out all other ports, but not
back to the port from which the signal was received.
Step 5 The hub repeats the signal to each receive pair on all other devices.
However I fail to understand the logic behind step 2 and I am unable to find resources that explain this step. Can anyone kindly explain to me the purpose of step 2?
The NIC doing that loop in Half-Duplex mode (means that cannot TX / RX simultaniously) its normally an old 10baseT / 100baseT implementation. the idea is to check if the received frame received correctly, therefore it assumes that no collision was occured. since today all switches uses Full-Duplex communication, collisions cant occur anyway .
Reading the docs, i have built 2 apps that connects 2 iDevices using BLE.
One device is Central, and the other is Peripheral.
The Central is looking for the Peripheral , and when find it, explore its services and characteristics, than connect to the relevant characteristic.
When an update is come from that characteristic i want to respond with data from the central to the peripheral .
Question is , do i have to switch from central to peripheral at one side and vise versa at the other side , in order to respond ? means, if i wants to make a simple chat, they always have to switch?
if yes- that makes it a problem to chat because there is a possibility that both devices went to peripheral and are trying to send messages at the same time.
So, if there is a way to make a bi-directional communication, how would one perform that, and any links with tutorials about that would be great . thanx.
The BLE communication is bi-directional already.
Central -> Peripheral: write a characteristic.
Peripheral has to have a writable characteristic.
The Central can write that characteristic this way sending the data.
Central <- Peripheral: update the value of the characteristic that the central has subscribed to.
Peripheral has to have a dynamic characteristic that it updates the value of.
The Central subscribes for notifications/indications on that characteristic.
The Peripheral updates the value of the characteristic which in turn sends a notification with the updated value to the Central.
To see how it works, check out the BTLE Transfer demo. You should spend some time studying the way it operates. The Core Bluetooth Programming Guide also has great examples to get a deeper understanding.