LogoLogo
Exchange
Exchange
  • Introducing: LX
  • Main Features
    • Social Features
  • Reliability
  • High Liquidity
  • High Performance
  • Simple Trading
  • Diversity
  • Interoperability/Bridge
  • User Support
  • Transparency
  • Security
  • The Problem
    • Negative Consequences of Centralization
  • The Solution
    • Security Solutions as a Decentralized Exchange
  • LX: A Decentralized Social Trading Platform
    • Lux Exchange DAO
  • Decentralized Application
  • User Experience
    • Easy to use
  • Accounts, Wallets, and Keys
  • Authentication
  • Features
    • Hardware Wallets
  • Portfolios
  • Social Trading
  • People Based Portfolios
  • Copy Swaps
  • Trading Charts
  • Indicator Alarm Manager
  • Smart Search
  • Watchlist
  • Community Support
    • Decentralized community service
  • Rewarded Content Production/Trading Bots
  • Token Curated Customer Service
  • LX Architecture
    • LX Architecture Comparison
  • eToro
  • EtherDelta
  • 0x Protocol
  • LX
  • Lux Protocol
    • Lux as a Distributed Autonomous Organization (DAO)
  • Governance
  • Lux Consensus
  • Terminology
  • Election Triggers
  • Attacks
    • Tragedy of Commons
  • Collusion
  • Censorship
  • ASIC Attacks
  • Long Range Attacks
  • Treasury and Bounty
    • Budgeting
  • Bounty
  • Lux Tokenomics
  • Decentralized Liquidity Pool (DLP)
  • Market Maker Fees
  • LX C++ Application Programming Interface (API)
  • Permission Mapping
  • Permission Evaluation Applied to Copy Trading
  • Parallel Permission Evaluation
  • LX Key Capabilities
  • Atomic Swaps
  • Facilitating Liquidity
  • Exchange Traded Funds
  • Crypto-asset Custody for Gateways
  • Cold Wallet
  • Smart coins
  • Crypto-asset Volatility
  • Gold as Collateral
  • Incentives
  • Interest Rate
  • Development Roadmap
  • LUX Constitution and Ricardian Contracts
  • Lux Protocol
  • DEX Core Platform
  • DApp UI/UX
  • Hardware Wallet Integration
  • Quality Assurance
Powered by GitBook
On this page

Was this helpful?

Censorship

Censorship or denial of service could occur when a 1/3rd of the bond holders refuse to validate any sequences with new bonds. The protocol can defend against this form of attack by dynamically adjusting how fast bonds become stale. In the event of a denial of service, the larger partition will be designed to fork and censor the Byzantine bond holders. The larger network will recover as the Byzantine bonds become stale with time. The smaller Byzantine partition would not be able to move forward for a longer period of time. The algorithm would work as follows. A majority of the network would elect a new Leader. The Leader would then censor the Byzantine bond holders from participating. Proof of History generator would have to continue generating a sequence, to prove the passage of time, until enough Byzantine bonds have become stale so the bigger network has a super majority. The rate at which bonds become stale would be dynamically based on what percentage of bonds are active. So the Byzantine minority fork of the network would have to wait much longer than the majority fork to recover a super majority. Once a super majority has been established, slashing could be used to permanently punish the Byzantine bond holders.

PreviousCollusionNextASIC Attacks

Last updated 2 years ago

Was this helpful?