layout	base
simple	../

Design Notes

Initial design choices

serverside: perl (or nodejs) clienside: javascript

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

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 ?)