If only the source initiates the transaction and broadcasts that information to the whole network, then it can also broadcast false information. So how does the other connected nodes verifies the confirmations of the transaction without actually querying the sender node ?
A bitcoin transaction includes all information necessary to verify its validity. Once broadcast to the network the other nodes will be able to verify it independently. Invalid transactions are rejected from the network so you can't broadcast invalid transactions/false information
Related
A bitcoin SPV (Simplified Payment Verification) client doesn't have to trust any full node. It submits a bloom filter to a full node for processing only a small subset of all blocks.
But what if an SPV client connected to a malicious full node, and this malicious full node intended not to send a block to this SPV client, which actually contains a transaction that this SPV client is interested in.
How does an SPV client protect itself that it didn't miss any transaction for its wallet address from a full node?
The SPV node connects to multiple, semi-trusted nodes to prevent this attack. Only a single node needs to be honest.
First, while the SPV client can not be easily fooled into thinking a transaction is in a block when it is not, the reverse is not true. A full node can simply lie by omission, leading an SPV client to believe a transaction has not occurred. This can be considered a form of Denial of Service. One mitigation strategy is to connect to a number of full nodes, and send the requests to each node. However this can be defeated by network partitioning or Sybil attacks, since identities are essentially free, and can be bandwidth intensive. Care must be taken to ensure the client is not cut off from honest nodes.
From https://bitcoin.org/en/operating-modes-guide#potential-spv-weaknesses
Consider section 8.5.3.1 of USB 2.0 specification:
Control write transfers return status information in the data phase of the Status stage transaction.
For control writes, the host sends an IN token to the control pipe to initiate the Status stage. The function
responds with either a handshake or a zero-length data packet to indicate its current status.
In IN transactions handshake is done by host, not device!
Question is: how device can send handshake for an IN transaction?
In IN transactions handshake is done by host, not device!
I believe there is some misunderstanding.
Device sends NAK/STALL during handshake phase of IN transaction(control write) if there is no data packet during status stage.
If there is a data packet from function corresponding to the IN token, the function expects ACK handshake from host after sending the data packet.
Data packets during status stages are Zero Length Packets.
This is the illustration of scenario in the question:
See also link in comments.
In a blockchain system like bitcoin, each peer (participate node) keeps a full copy of the ledger. A peer updates its copy of ledger when it receives and validates a newly arrived block. However, the peers are scattered around the globe, and the network latency among these peers varies a lot. Therefore, how the blockchain system guarantees that all the peers have finished updating their copies of ledger after a block has been propagated?
Bitcoin doesn't guarantee that all ledgers become updated at the same time, bitcoin blockchain provides you with consistent ledger following:
Proof-of-work to cut new block with set of transactions
Longest chain rule
Above guaranties you that if there no more than 51% of the network controlled by one group you will eventually see consistent ledger, e.g. given your ledger at block sequence number 1001 means all nodes in the network will see identical chain of blocks until 1001.
To your question bitcoins use random overlay network to distribute new blocks (pretty similar to gossip algorithm).
UPDATE
See section B. Propagation Method from here:
For the purpose of updating and synchronizing the ledger
replicas only transaction (
tx
) and block (
block
) messages are
relevant. These messages are far more common than any other
message sent on the network and may grow to a considerable
size. In order to avoid sending transaction and block messages
to nodes that already received them from other nodes, they are
not forwarded directly. Instead their availability is announced
to the neighbors by sending them an
inv
message once the
transaction or block has been completely verified. The inv
message contains a set of transaction hashes and block hashes
that have been received by the sender and are now available
to be requested. A node, receiving an inv message for a
transaction or block that it does not yet have locally, will issue
a
getdata
message to the sender of the inv message containing
the hashes of the information it needs. The actual transfer of the block or transaction is done via individual block or tx
messages. Figure 2 visualizes the protocol flow for a single
hop in the broadcast.
I'm trying to understand a concept of WebRTC. As I found in some descriptions (for example here http://www.innoarchitech.com/content/images/2015/02/webrtc-complete-diagram.png), there is such a way of making a connection:
Call STUN, to get your IP:port address.
Get some channel from TURN - with that channel you can send info to other peer.
Send to other peer ICE candidates.
Accept ICE candidates with other peers- start a call.
The question is, what do we need ICE candidates for? We know our IP, we can send it to TURN therefore to other peer, and on TURN we have a nice connection with other peer- so we don't have to scary about NATs. Why except that we are sending ICE candidates (why many?), and why we need to use them?
We have 3 main concepts here:
ICE
TURN
STUN
The ICE negotiation is not that simple...
To execute ICE, UAs have to identify all address candidates, transport addresses. Transport addresses are a combination of IP address and port for a particular transport protocol. There are three types of candidates:
Host Candidate – transport address associated with a UA’s local interface
Relayed Candidate – transport address associated with a TURN server (can only be obtained from a TURN server)
Server Reflexive Candidate – translated address on the public side of the NAT (obtained from either a STUN server or a TURN server)
After UA1 has gathered all of its candidates, it arranges them in order of priority from highest to lowest and sends them to UA2 in attributes in an SDP offer message. UA2 performs the same candidate gathering and sends a SDP response with it’s list of candidates. Each UA takes the two lists of candidates and pairs them up to make candidate pairs. Each UA gathers these into check lists and schedules connectivity checks, STUN request/response transaction, to see which pairs work. Figure 3 shows the components of the candidate pairs that make up the UA check list.
ICE assigns one of the agents as the “Controlling Agent” and the other as the “Controlled Agent”. The controlling agent used the valid candidate pairs to nominate a pair to use for the media. There are two nomination methods that can be used:
Regular Nomination The checks continue until there is at least one valid candidate pair. The controlling agent picks from the valid pairs and sends a second STUN request on that pair with a flag to tell the peer that this is the one that is nominated for use.
Aggressive Nomination The nomination flag is sent with every STUN request, once the first check succeeds ICE processing for that media stream is finished and a second STUN request is not needed.
Each candidate pair in the check list has a state associated with it. The state is assigned by the UA once the check list has been computed. There are five possible states:
Frozen This pair can only be checked after being put in the waiting state. To enter the waiting state some other check must succeed first.
Waiting As soon as this is the highest priority pair in the check list a check will be performed.
In-Progress A check has been sent for this pair and the transaction is in progress
Succeeded Successful result from pair check.
Failed Failed result from pair check.
The link below includes more information and diagrams of the ICE flow.
Reference:
http://www.vocal.com/networking/ice-interactive-connectivity-establishment/
RFC https://www.rfc-editor.org/rfc/rfc5245#page-9
TURN is typically used only as a fallback when a direct peer-to-peer connection cannot be established. The latter is the hard part, and is what ICE is for.
Always using TURN, is an option, but a bit of an edge-case.
To establish WebRTC connections the ICE protocol is used with a signaling server which must send messages in both directions. I wonder why after the initiator sent its offer and candidates to the other participant, the participant needed to send back its answer and candidates using the signaling channel in the other direction. Cannot the participant open the connection to the initiator using candidates from both sides and send back its answer using the open connection?
I started reading ICE RFC and the only relevant part I found is in section 5.2 where the initiator must take the controlling role and nominates candidate pairs. But it does not explain why the other could not initiate connection.
To give some background, I am trying to build a webapp for which I want users to establish WebRTC connections without using a signaling server. I thought of having the app to generate a URL including the offer and candidates and providing this URL to other participants through other medium like instant messaging. The issue I got is that the participant need to send back its answer and candidates using the same medium, which is not practical. In the end I will go for a signalling server but I wonder the technical reason.
Yes, you can do that if caller is behind public IP or Full Cone NAT(in this case, router connection mapping needs not to be timed out).
You can able full fill above conditions rarely.
What's the problem with other NAT types?
For example , PRC(port restricted cone) NAT won't allow you to receive a packet from a IP:Port , if you didn't send any packet to that IP:Port before. So callee will never able to send you a packet.
So if callee sends her candidates list to you . you can send some dummy data(with low TTL) to her IP:Port to fool your PRC NAT (now it allow incoming packets from callee's IP:Port as it sends a packet to that IP:Port before).
To know more about different types of NAT:
https://en.wikipedia.org/wiki/Network_address_translation
http://think-like-a-computer.com/2011/09/16/types-of-nat/