--- layout: simple base: '../' --- # Design Notes ## Initial design choices - protocol/routing/network layer: websockets (multi nonblocking clients) - server-side fileformat : yaml - client-side fileformat : JSON ## Language choice: serverside: perl (or nodejs) clienside: javascript ## block chain structure minimally sized blocks : - segreated signature, timestamp, audit etc. - block: {address, previous, pow} - use balances for state rather than TXO to avoid the need keep txo states, and link txi to utxo ## observation ... - revokable block if sign w/ a DH on txo and ECDSA on txi - txroot (merkle root can be global) - PoW is to slow down chainupdate to avois spam - consensus is on the longest length - /!\ maximal work is hackable (as pow is exponential to difficulties) - sort of tx sequence can be done on node side - block chain can store tx out of order (FIFO style) - does mining really need to be conpetitive ? - if mining is done by all node the recipient of txo will be willing to mine! - if a .2% tax on transaction can replace/solve all VAT taxes then mining rewards is "artificially" inflated to compensate for a wasteful technology - nano-trading is stealing (i.e. taking advantage of who has the power to be informed fast) on need to put a "lowpass" filter on trading : speculation is necessary for long term protection against future uncertainty... short term predicition make no sense ! long unpredictable queue time (mempools) can deter speculator as it would be like "lotery" lotery is a "gamified" tax extractor. - PoW can be replaced by ZK proof of some Work - should it be txo which carries the burden of proof of work ? - validator already do a great job making the system "alive" - block reward could be proportional to the number of tx in the block i.e. the "real" work is indeed the verif not a hash-puzzle - How to mitigate DDoS on Mempool ? - - why would we want making block more and more difficult to add when technology advance ??? (how to make spice of spamming constant through technology ?)