Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Current »

Date

Attendees

Goals

  • Discuss the lazy validator trap

Discussion items

TimeItemWhoNotes
Types of lazy validatorsMichael Stay (Unlicensed)
  • Validator joins, pretends to never receive any blocks.
    • Involves Ejection, which is not implemented.  
    • Indistinguishable from network failure.
  • Validator joins, issues blocks, but isn't keeping the whole tuplespace, so cannot distinguish invalid from valid ones
    • Feasible to detect.
    • they build on an invalid block
    • they can watch other validators and see which blocks they build on
  • They may be able to keep a partial record of the tuplespace, but it will be very difficult for them to create any blocks without a full state.
  • They could publish empty blocks.
  • They could steal transactions from another validator


 Kyle Butt
  •  Disallow blocks who's root state hash is the same as the parent.
  • Fee splitting contract will need access to an Oracle - because it doesn't know anything about the DAG.  
    • Goal - transaction fees are not delivered until a block is built on top of the block you proposed.  The transaction fees are held in trust in the PoS contract.
    • Bag of fees for a transaction.  Initially, the fees go to the proposer, and as validatorB  creates a block referencing that block, the fees now go to the proposer & validatorB

Action items

  • No labels