Jae Kwon light clients.md

• Light clients can verify that their shit is correct

• you need a certain number of votes

• quorum of signatures to verify that the block hash at a certain height is what was signed by the quorum

• set of validators, supermajority is more than 2/3 or more of the validator set signing a block hash at a certain height. tells you that block was commited by the block chain

• if that's not true and they actually signed another block hash at that height, in tendermint you can figure out who double signed. they get slashed. with caveats.

• the block hash is a merkle tree root hash that includes all the transactions for that block as well as the validator signatures for the prev block

• it also includes the entire application state tree in the merkle hash path. the entire application state and contract data are all stored in tree

• you can prove that the value of a key in the app state tree is a certain value at a certain block height by checking the merkle proof against the block hash

• this is good for light clients because if they are swindled they can punish the perp.

• jae is receiving money from an entity known only as "shadow"

• the only full node that jae is able to connect to belongs to shadow

• jae wants to verify shadow's payment of one tendersteak

• jae queries for his account's current balance from shadow's full node

• shadow's node returns the requested account state

• it's literally just a data structure

• he also gives jae the merkle proof of that data to prove that it's the application state that corresponds to a block hash that he also gives jae, along with a supermajority of precommit signatures for that block hash.

• the attack that can happen in pow is, you're talking through shadow's wifi to shadow's full node

• in bitcoin you can't know that shadow's wifi and shadow's box is just not showing you any longer blockchain so they can effectively fork and you wouldn't know

• shadow would show jae a block that includes the transaction that sends the money to jae and possibly some confirmation blocks

• jae's clock has to be accurate to avoid an attack

• seeing a block with payment of that address is proof that the block hadnt been pregenerated

• so that's nice because when you see that block and confirmations on top you can see that the block was generated since having interacted with shadow

• btc light clients are secure as long as i wait for confirmations

• tendermint light clients are secure after only one block!!!! <-- BEST POINT TO MAKE

• tendermint light clients also do not require to have all the block headers

• if you have proof that the quorum of validators has signed a block at a particular height, they couldn't have signed anything else cause their scared of slashing.

• if you want to get the current value of some key, umm, and thats all you want to do, in bitcoin, you would think that it's enough to see some confirmations that set that value somewhere along the blockchain in the past, at any point it might of changed. if it's mutable.

• in tendermint secure name lookups in mutable name systems are free.

• this is great for mesh nodes.