Maybe (likely?) someone has already thought of this earlier, but does the fact that we have an immutable public readable storage make it possible to create a whole bunch of new kind of crypto coins? Since the data layer is immutable, we do not need a blockchain. We can make the transaction completely independent of each others (except input/output)
First, just create a genesis block with initial coins. Use the block address as a hard coded id for your new coin.
When the coins are sent to someone, just create a transaction (sender block addr, amount, recipient pk address, signed with your secrer key), store it and send the stored block address to the recipient.
Then the recipient could use the coins just a similar way. The coin validity could be checked by following the blocks back to the genesis block.
The only question is how to prevent double spend? We would need some once writable data to mark the block where the coins are as “used at block xxx” or something?
Or some method to freeze scratchpad to the latest state, ie change the type to a normal block?
The Autonomi network could be a platform to a completely new kind if crypto coins, with very simple implementation? If it is possible, it would make other altcoin platforms ancient..
What am I missing? If possible, I guess it would have already been done?
community token project does pretty precisely what you suggest there the only issue is that we need to traverse the whole path back to genesis to validate the TX
(I would see this as an issue - but funnily that’s precisely what blockchains do - right? validating the chain of blocks back to genesis xD )
Bitcoin uses checkpoints, ie defined points on the blockchain which are known to be valid, so the latest version does not need to travel the whole path (unless very old coins are used, i guess).
And that might not work as well on this kind of crypto, since it is more like a tree structure vs chain.
if you want to validate a TX today and validated another one yesterday (and traversed the whole block-stream to genesis yesterday) you can validate the blocks within the last 24h … (if you trust the miners not to include invalid (due to insufficient balance) TXs … or stored all balances of all addresses for that point yesterday …)
…with the DAG structure history most certainly isn’t shared … but then again you need to validate a smaller proportion of it … so if we’re honest the blockchain checkpoint stuff only makes it easier for people who trust the miners … just like DAG nodes that the team planned to include in their concept of the native currency
so using @loziniak’s community token concept and e.g. the creator might be required to offer DAG validation as a service …
doing this for a small fee might be a viable way … people might want to save some cents when just sending/receiving to/from family … but e.g. a shop might only accept a payment that includes a pointer to a valid certificate that this the DAG has been validated to this TX (or may charge an additional fee to validate the payment at a trusted DAG validator) …
This sounds like an interesting approach, but I can’t quite grasp it. Could you describe the idea in more detail?
That’s assumed the system functions purely on App layer. If we could modify node/network layer and go back to separate Transaction datatype, nodes could validate transactions on data insertion, so no need to validate all the way to genesis, because it would already be validated. That could also enable free transactions and a Native Token implementation.
That would mean centralizing and complicating the system, and depending on implementation could even introduce privacy concerns (like recording IP of validation request and tie it to specific transaction etc.)
Initially I thought of some later writeable metadata (pointer) that could be added to a chunk after it’s creation, but which could be written only once.
ie:
create a chunk, it’s does not have a pointer (=null)
when used, add a pointer to the chunk (can be done only once)
but that would need support at autonomi protocol level.
Something like this might also work:
Block A has unspent outputs of some earlier transaction. When the recipient wants to use them, he creates block B and writes to block A a pointer pointing to the block B. After that write, block A should be made immutable. Either turn the data type from scratchpad to chunk or something like that. Or consider valid data with versions 0 (unspent) and 1(spent) only.
The problem:
Block A is created by person A, but only person B should be able to update it and only once (hmm.. maybe Person B could create it with the data received from person A?)
the only issue is that we need to traverse the whole path back to genesis to validate the TX