@dirvine@maidsafe I would like to discuss revisiting the initial safecoin design. I liked it a lot; it was easy to explain. Every coin was one “data point” in the network that has an owner. Checking ownership of a coin was easy because you just needed to poll the coin and check the public key against what you were told. no DAG crawling, no validator nodes (you need to trust). no speed issues (on validator nodes), no questions about invalidating branches, no issues with incoming TXs that need to be processed by the recipient to become part of their DAG structure, … so nice and easy.
AFAIK it was put to rest because of:
divisibility (but as you mentioned many times it’s easy to add divisibility by breaking up one coin into a couple of pieces → so a mini-DAG with known root and easy to validate by even the smallest devices with a couple of network calls)
issues with transferring large amounts of coins because the network then would need to change ownership of hundrets, thousands, millions, possibly billions or even more of little data points …
Idea:
2 Data types:
Token
– fixed Value 1 Token and can be broken up into pieces
– has an owner (either directly a BLS key or Address of an Owner Datapoint in the Network)
– (amount/parent(s)? that would enable token split, community token and possible even recombination if we allow it)
– counter based mutable Datatype
Owner
– has an address in the network and contains a public BLS key
– counter based mutable Datatype
users/wallets can group coin and broken up coins into useful denominations (or split them up later on when they get “too valuable”). Large TXs of Token can be done by simply transferring the Owner to another BLS key.
benefits:
No questions about ownership and validity of coin
no validator nodes needed
spam doesn’t increase the stored data amount in the network, TXs could be made free and just breaking up coin into smaller pieces would need to come with a tiny fee.
no question about how to deal with falsified branches
truly decentralized (because easy to validate and no reliance on external services) and easy to explain to people.
I know I said a couple of times it’s not the time to discuss the network token xD …
… but I would like to see this discussed before we invest months and years into a super sophisticated DAG concept with validator nodes (that also need to be paid by someone) and solve complex issues that wouldn’t be needed to be solved at all if the overall concept was simpler …
(as it was when I fell in love with this project)
maybe @oetyng or @mav have thoughts about this? (sorry for linking both of you - you were just at the top of my mind when it comes to a topic like this … and doesn’t mean there aren’t other capable people in the community I probably should have linked …)
@loziniak you could even mimic this with immutable data as genesis event and scratchpads for token/owner … by defining all valid genesis token (scratchpads) in the genesis event…
…I know this comes pretty late in the game now but it’s not super different to the DAG structure you’re using now (basically the token genesis event is a DAG root pointing to all valid Token and is immutable - and the token then are scratchpads containing the owner / need to be burned (setting counter to max_counter) on split-up into pieces …) … so somewhat DAGish but with DAG nodes where ownership is transferrable.
Easy to validate for community created token too. No backward-forward-validation needed. no validator nodes needed. nobody needs divisibility into 10^-18 … but even that would be possible if you really would need it… (and if you don’t start with denomination 1 but somewhat reasonable in relation to created community token amount … so for creating 1 million token e.g. creating 1000x1000 Token groups that can be split up later on again) creating larger amounts of community token wouldn’t immediately result in insane fee payments for paying for all those token creations.
oupsie … sorry forget that … we can only change content of scratchpads … not the owner … stupid me …
Nice idea, certainly worth debating. The benefits are clear.
Could it be possible to also merge coins somehow? It could fix the problem of big transactions.
But then probably most transactions would include merge/division operations, so aren’t we left with a DAG of scratchpads growing with every transaction anyway…?
Doesn’t Scratchpad/Pointer require to be signed by current owner? You can change owner field, but you only can sign for yourself, not the other person? Am I getting it right?
Wouldn’t it also break the entire concept, leave alone community token?
Not sure about that if merge/split comes with fees… But it certainly would make validating a lot harder if people would merge on a regular basis… Would kill a lot of the simplicity…
Yeah the Scratchpad address is directly derived from the owner key… Trying to use current Scratchpads was a mind fart…
If we could have an owner separate from the address of a Scratchpad (and only the owner could change the content) then it would enable a community token as I was thinking about… But in the current implementation Scratchpads are useless here…
This is probably designed this way, so that the address could not be chosen freely, like 0x00000…000 or some other that would make it be handled by malicious node.
Oh, and suppose we could change owner of scratchpad, what would stop me from just creating a new 1ANT scratchpad out of thin air and sign it? How could other person say that it’s invalid?
So we have a growing DAG vs big amounts problem. And what if safecoin becomes very valuable, people divide it to small parts, and then it looses value? All transactions become huge in terms of coin parts count then.
Because that Scratchpad address is not listed in the genesis event (immutable data stored in chunks) that defines the coin
Sure - as I said trying to use the current Scratchpad wasn’t a good idea and doesn’t work - but since you can choose the private key freely just adding a ‘owner field’ that can freely be changed by providing a current owner signature doesn’t do harm or weaken security in any way - right?
Yes exactly - that’s why I was suggesting creating 2 additional data types that have other properties (stable address but changing owner… It’s not that different to changing content for a Scratchpad… But the checked signature would not be be connected to the address of the data but only connected to the (previous) owner field content
… Maybe adding previous and current owner makes even more sense..? )
Afaik, the only reason keys are used to derive address is to make it unqiue easily addressible by the owner. (Edit: after all, immutable data uses a hash of its content to be self-addressible as an alternative).
I don’t see why we can’t use a different ‘seed’ to derive the address and then associate a public key with it, along with any useful meta data.
It also seems very feasible to change that public key to another, by providing a signed instruction to do so. Once complete, only the new public key owner could transfer it.
The problem seems to be who can mint the token. It seems straightforward for that entity to sign a new token too (perhaps that is the first, immutable, meta data). They could also use a random element to derive addresses, prior to signing.
Ofc, anyone could issue a token, but then you have a trust issue. You could have minting events, where a number of tokens are minted, with their addresses stored in another immutable data type for easy lookup. Perhaps this could be linked with a smart contract to do so and the minting quantities could be defined algorithmically.
The distribution of newly minted tokens could take many shapes, but rewards/payments for network services would be a good start. Perhaps new tokens could be minted for node running?
Maybe you could also use multisignature to split tokens too. Current owner and minter signatures could allow the token to be split and marked as burned. I suspect a splitting smart contract owned by the original minter could provide such a service.
Anyone could mint new tokens. However, the network may choose to only accept and distribute tokens signed by a specific minter/private key. Other tokens could use the same types though.
Well… In the case of native ant those could be spread evenly across the address space and predefined (since people used the eth key of their metamask wallet already as BLS keys on autonomi there might be a way with just freezing all ANT and doing an airdrop to the network with the corresponding keys..?)
And for community token it’s not super different… They would need a genesis event (of maybe a Scratchpad that contains the list of valid Genesis token if the owner is allowed to print as many token as he wants :D)
… Just a definition where users can look up the list of valid genesis objects
Hmm - possible but the current owner being able to split (pointing to a data map where the fractions and their new addresses are located) should be sufficient - shouldn’t it..? (with cash I can decide too if I want to split the 20 usd into 20x1 or 2x10..? Why would I need the minter involved at all?
Oh - you mean as proof it’s a legit coin… I wouldn’t think it’s needed tbh bevause even after split I personally wouldn’t expect the dag chain there to be be super huge…
One thing that would be a bit uncool would be micro payments not really making sense to be too small bevause of the need to split a small amount into a lot of little data objects… But then again it’s not like the situation would be better with a dag… So maybe it’s still possible…
If it they were minted just prior to awarding node runners, perhaps that would do too? There isn’t a latency issue at that point at least.
Maybe the mint could also accept ANT to burn and swap for native too. The same signer could do both then.
I was just thinking to avoid the dag and keep each separate, but yeah, probably could split without a mint, as long as the genesis token was linked. Maybe both could be an option, depending on cost/privacy preference.
Size wise, I’d pick something pretty chunky to start with, then split to smaller as needed. The mint could even combine them too, if needed. Maybe the mint wouldn’t even be needed (as per above too).
Indeed, with arbitrary splits/combines, you could make up any suitable fractions pretty easily.
Tbh, even if this wasn’t a solution for tokens, it would be great for transferable assets.
Using an arbitrary seed, it could be used for owned key/value stores, which could be transferred between parties. Great for NFTs, domain name lookups, key/value databases, etc.
Edit: Other cool use cases:
Shared data types, e.g. append only for non-owner. Owner could monitor it for changes, wipe it, etc. Useful for email/message inbox/queues. A big current limitation is changing someone elses data to let them know about something (i.e. a change event).
Variation of above, but with a defined list of other public keys to define append permissions. Handy for (owner) moderated versions of above. Could also be safer full write access to all parties.
So, this has got in my head now. Just woke up thinking about it!
I’m actually wondering why all mutable types currently use key addressing, with derived private key. I’m tempted to review the code to understand more.
I’m assuming it is because it is a cheap operation to validate that the owner is the one doing the mutation. It is just a unique value that is impossible to guess. Therefore, signature checking becomes a secondary, more computationally costly step.
However, (private) key addressing is frustrating in a number of use cases, where being able to derive an address (from a public convention) would be extremely useful (see above post for these, but others too).
Assuming this is a decision for validation efficiency, that comes at a high usability cost in many cases.
Given we could attach a public key to any mutable data, which could be used to validate the owner for mutations, it would seem like a feasable alternative. The seed key to derive the address could be based on public information instead, allowing arbitrary keys for storage and reassignment of ownership.
Ofc, it would mean nodes having to check signatures as a primary validation operation, but arguably getting quotes to perform a potential mutation is at least a heavy lift.
Edit: fwiw, just adding an ‘owner’ public key field to existing types, then using this to derive ownership could suffice. Allowing more flexibility in address choice would improve on that too.
My understanding is that the users are not allowed to choose “these kind of things” in order to ensure random distribution of data. To not be able to effect which node handles what.
Which would still be the case for mutable owned data - it’s just data that would come with the additional owner property and nodes would check changes of content/owner changes against the signature of the owner instead of the private key that is being used to derive the randomish address…
So you need one private key for data creation and that can be the same for changes of Scratchpads… Or in the case of an ‘owned chunk’ (immutable data coming with an owner… Like @Traktion mentioned such a thing could be used/useful for nfts like the shareholder nfts that maidsafe utilised not long ago) the address would be the hash of the content - and to change ownership nodes would check against the previous owner signature to validate the change.
owned immutable would enable e.g. Community token / initial safecoin design / random nft stuff that is unique and cannot change but has a easy to identify unambiguous and transferable owner
on split the owner could be written to the address of the splitting datamap (if we e.g. Define that splits have to come in 1:100 that would make the cost to create a split: 100x owned chunk + 1x splitting map (regular chunk) - 101 write operations… Oh well maybe 1:10 would be enough… That wouldn’t be unthinkable iterations but ‘just’ 3 or so… Would make sense to have the splitting maps further down just list the previous splitting maps+coin(parts) - then the parents could be called in parallel and more efficiently)
In theory we could mark ownership through external data too… - e.g. by deriving a graphEntry private key from the datamap address of public data… But then there are infinite ways to do the derivation and on top of that you need to traverse a possibly very long chain of graphEntries to get to the current owner which makes it not a viable solution imho…
… If you get 100 coin of different denominations and need to traverse 1000s of owner changes at every denomantion level to be sure the chain is correct would take forever (you only know where the next graphEntry is when you read the previous one because they cannot be a derived chain (otherwise previous owners would be able to know the private keys of the current coin owner))
… Owned mutable would enable pretty straightforward DNS with ownership change for domains …
Implementing graphEntry traversal and ownership marking for mutable would be possible for mutable too as described above for immutable but the previous owners would then always be able to change the mutable data so there is not really a point in doing it… So the owned mutable would basically be a chain of graph entries for ownership and them pointing to Scratchpads …
Unlike registers or @happybeing s history datatype the traversal of graphEntries cannot be accelerated by pointers because those would need to be known by previous owners too and therefore could be manipulated by them…
So unlike my first intuition there really is a case for owned mutable data too from what I see @Traktion
… And if we’re honest to make nodes check the signature against the public key being the address of the mutable data or against the value in an owner field shouldn’t make too much of a difference for them…
-for the immutables this would be more kind of metadata without significant consequences…(except for the nft use case… Without owner and owner change there is no nft..)
-for mutables the signature should be checked against the owner public key instead of the address of the mutable..
I’m not sure we need owned immutables? It makes a lot of sense for immutable to be content addressed.
I was more thinking the content address of a chunk could be used to derive the key of an owned mutable. If derived in a standard way, it would be pretty easy to claim ownership this way (and their couldn’t be duplictates).
For general tokens, using something like an owned graph would probably be enough. They have lots of slots for meta data for signatures, etc? Not sure it needs to be immutable data?
The derivation needs to be standardised then but with owned Scratchpad where the check would be against owner of the previous version we could do everything. - transferring ownership to a immutable datamap (splitting map) included effectively making the split up coin represented by the (parent) owned Scratchpad immutable
…