` 28 D. Mazieres probability 1, but in worse expected running time for the common case that most or all nodes are well-behaved or fail-stop. 7. LIMITATIONS SCPcanonlyguaranteesafetywhennodeschooseadequatequorumslices.Section3.2 discusses why we can reasonably expect them to do so. Nonetheless, when security depends upon a user-configurable parameter, there is always the possibility people will set it wrong. Even when people set quorum slices correctly and SCP guarantees safety, safety alone does not rule out other security issues that may arise in a federated system. For example, in a financial market, widely trusted nodes could leverage their position in the network to gain information with which to engage in front running or other unethical activities. Byzantine nodes may attempt to filter transactions on the input side of SCP while otherwise producing the correct output. If well-behaved nodes accept all transactions, the combine function takes the union of transactions, and there are intact nodes, then such filtering will eventually fail to block victim transactions with probability 1, but maynonetheless impose delays. ThoughSCP’ssafetyisoptimal,itsperformanceandcommunicationlatencyarenot. In the commoncasethatnodeshavenotpreviouslyvotedtocommitballotsincompati- ble with the current one, it is possible to reduce the number of communication rounds by one. An earlier version of SCP did so, but the protocol description was more com- plex. First, it required nodes to cache and retransmit signed messages previously sent by failed nodes. Second, it was no longer possible to gloss over the distinction between votes and confirmations of abort statements in PREPARE messages, so nodes had to send around potentially unbounded lists of exceptions to their abort votes. SCPcansufferperpetualpreemptionasdiscussedinSection6.3.Anopenquestionis whether,withoutrandomness,adifferentprotocolcouldguaranteeterminationassum- ing bounded communication latency but tolerating Byzantine nodes that continuously to inject bad messages at exactly the point where timeouts fire. Such a protocol is not ruled out by the FLP impossibility result [Fischer et al. 1985]. However, the two main techniques to guarantee termination assuming synchrony do not directly apply in the FBAmodel: PBFT [Castro and Liskov 1999] chooses a leader in round-robin fashion, which is not directly applicable when nodes do not agree on membership. (Possibly something along the lines of priority in Section 6.1 could be adapted.) The Byzan- tine Generals protocol [Lamport et al. 1982] relays messages so as to compensate for ill-behaved nodes saying different things to different honest nodes, an approach that cannot help when nodes depend on distinct ill-behaved nodes in their slices. Still an- other possibility might be to leverage both randomness and synchrony to terminate with probability 1, but in shorter expected time than Ben Or-style randomized proto- cols [Ben-Or 1983] that make no synchrony assumptions. Public coin techniques [?] that speed up randomized centralized Byzantine agreement protocols appear to be dif- ficult to adapt to the federated model, barring some cryptographic breakthrough in federated threshold signatures. Unfortunately, changing slices mid-slot to accommodate failed nodes is problematic for liveness if a well-behaved node v has ever experienced a wholly malicious and col- luding v-blocking set. The good news is that Theorem 13 guarantees safety to any set S of well-behaved nodes enjoying quorum intersection despite V⧵S, even when S has befouled members. The bad news is that updating Q may be insufficient to unblock nodesifwell-behavednodesweretrickedintovotingtoconfirmabadcommitmessage. In such a situation, nodes must disavow past votes, which they can do only by rejoin- ing the system under a new node names. There may exist a way to automate such