# Bounce: A High Performance Satellite-Based Blockchain System
## 4 Slot Protocol
### Failure/Response Summary  
We summarize the possible failure cases, their consequences, and how we handle those in Figure 3. Sending Stations might fail both cleanly (e.g., fail-stop) and traitorously. Neither failure type requires any specific action, because a failing Sending Station cannot forge user transactions nor the signatures of other agent. Sending Station failures do increase the response time of transactions that were sent to the failing Sending Stations. Such transactions will have to be sent to other Sending Stations.  
Figure 3: Traitorous Sending Stations cannot forge user messages because they are signed. They can censor transactions, but censored users can then send their transactions to other Sending Stations. The censoring Sending Stations would then acquire a bad reputation and lose revenue. As long as \(f\) or fewer Broadcast Ground Stations fail, all that the failing or traitorous Broadcast Ground Stations can do is to fail to sign a Merkle Root or a Commit Record. The same user transactions that would have gone into that Merkle Tree can go into another. When \(f+1\) Broadcast Ground Stations (even traitorous ones) sign a Commit Record, progress can continue. A failing Satellite Bounce Unit will not send a positive Commit Record. This will trigger the reset protocol discussed at length in [3].  
Regarding the assumption of at most \(f\) failing (clean and traitorous) Broadcast Ground Stations, with \(f\) a number in the high teens, we believe this is reasonable given that the failure of any Broadcast Ground Station will be evident given that it signs a Merkle Tree (or Commit Record), but fails to send that to User Nodes. The only damage \(f\) or fewer traitorous Broadcast Ground Stations can do is to cause denial of service. Malicious Ground Stations cannot forge user messages because messages are signed. Moreover, even if only \(1\) out of \(f+1\) properly makes information (Merkle trees and Commit Records) widespread, that is sufficient. This is in contrast to consensus algorithms such as Byzantine Fault Tolerance [52] for which a supermajority of agents need to work correctly. Spreading information is simpler than consensus. Denial of service causes a slower response time for some transactions, but does not slow down the whole system.  
Recall the assumption that the Bounce Units in the satellites don't suffer from traitorous failures. We believe that this is reasonable because the Bounce Unit protocol is quite simple (check the signatures of one or more Sending Station messages, sign and send) and therefore can be verified and burned into Read-Only memory. Such an architecture makes Bounce Units secure against remote software modification.  
Note however that satellites can fail cleanly, so may fail to send messages either intermittently or permanently. We believe satellite failures will be very infrequent though, on the order of once every few months or years. When such failures do occur, we invoke the reset protocol in which the human participants of Mission Control (over several minutes possibly) decide on a new slot assignment and send a reset message.