Revisiting the initial Safecoin Design for native Token

[Traktion]

BTW, I checked the source code and it appears to be as expected.

The client libraries set the address to a public key derived from the private key owner:

autonomi/src/client/data_types/pointer.rs

While the client code to actually set the address could be overridden, the ant node code checks that the owner.public_key is the address:

ant-node/src/put_validation.rs

After checking the signature here:

ant-node/src/put_validation.rs

And in ant protocol, the pointer address is derived from the owner public key again:

ant-protocol/src/storage/pointer.rs

Also, the address is not actually stored, which means it must be derived from owner:

ant-protocol/src/storage/pointer.rs

Given the signature of the owner is being checked, I think the assertions here feel correct: Revisiting the initial Safecoin Design for native Token - #15 by Traktion

So, I guess the question is, would it be easy to change and is it necessary?

On the ease of change front, it would seem relatively straightforward. You’d just store the address in the struct, then only validate it is a valid address (i.e. a public key length/format).

Is it necessary?

@Toivo

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.

Perhaps this is the core of it, but the code could still derive a public key for the address. On creation, a mnemonic could be used as a seed, for example.

So, I’m not sure why this constraint is present. It feels unnecessary at this point, but would love some feedback from the team.

Another change would be to allow the owner to mutate, as well as the data. This would require some changes to ant node to handle that, presumably much like the PUT validation/store, including a mechanism to check the old owner signature. If that code needs to be stateless, a ‘next_owner’ field may need to be populated, which is then stored in ‘owner’, for example.

[riddim]

@Traktion

Perhaps this is the core of it

Yeah … But what we talk about is using one key for address derivation and another one for content mutation… It doesn’t change the randomness (or non randomness) of addresses..

@Traktion

but would love some feedback from the team.

[Traktion]

@riddim

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

Run that past me again? I’m not following the flow/terminology on this bit.

[riddim]

One full coin: owned Scratchpad A

As long as we pass it around we change the public key of the owner (your key, my key, back and forth)

Now I do a split into 4 coin of value 0.25 each

Chunk S(plit) content:

Scratchpad A

Split into 
0.25 Scratchpad b1
0.25 Scratchpad b2
0.25 Scratchpad b3
0.25 Scratchpad b4

Now we store the split on the network, write owner of Scratchpad A to address(Chunk S) and burn it with that

@Traktion

but would love some feedback from the team.

(nothing against you @Traktion - please keep talking - I’m just not sure we’re making great plans and the ones who are in charge don’t even read it so I decided to include this citation to every following message from here on)

[Traktion]

Ah, ok - so it’s more about how to implement native token, once we have owned mutable types?

I think we would have a few options once the above is in place.

I could imagine arbitrary sized splits could also be possible, e.g. 80/20 splits, or 90/10, etc. Same with joins. There may be a bit of house keeping to do now and again to tidy them up, but nothing too dramatic (and maybe the same as equal splits anyway).

Perhaps an owned graph entry like DAG would suit too though? You could create a derived child graph entries, linking back to the parent. Then you could just swap these tokens too.

If the DAGs got unworkable in size / privacy, you could use a smart contract to re-create/combine them again (burn + re-create / combine as new). I don’t the idea of minting smart contracts is a fine thing, considering the network doesn’t have a native solution. They could also be pretty latency insensitive for these operations.

Maybe there is a bit more work using this approach to actually prep ‘the right change’ for the payment, but an app could manage that for you async to spends. E.g. you could have the equivilent to a regular paper/coin money wallet, but with a bonus of someone always giving you the ideal note/change mix!

[Traktion]

@riddim

(nothing against you @Traktion - please keep talking - I’m just not sure we’re making great plans and the ones who are in charge don’t even read it so I decided to include this citation to every following message from here on)

@chriso / @rusty.spork I know you folks are active on the forum. Maybe we could just get a team member’s eye balls on this thread? Maybe we are missing something important, but maybe we’re onto something that would add great flexibility to mutable types too. It would be nice to understand the context around only using owner key as the address for mutables in general.

FWIW, I think there are 2 questions:

1. Can we have one key for address derivation and another one for content mutation, rather than combining the two?
2. Native token implementation - probably a bigger debate, but would be most keen on hearing about 1, as then we know if it is worth digging into.

[chriso]

Hey,

I will read the thread in more detail at some point soon.

[riddim]

@Traktion

I could imagine arbitrary sized splits could also be possible, e.g. 80/20 splits, or 90/10, etc. Same with joins.

Sure - but if we go there we’ll probably end up with a very dag like structure with the validating issues for regular users - while it we split into 10 (or 100) smaller units that have a owner and try to reuse them to get the right amounts through multiple ownership transfers we’d have something significantly more similar to real world coin and people could easily validate them…

Even stupid stuff like 10-18 are just 18x 1:10 splits and would enable transfer of stupid amounts with a lot of digit precision…

[Traktion]

I hear you, but equal splits mean many, many, tiny coins if equal splits. Just shaving a nanos off a big token may be more manageable.

[riddim]

And shaving again and shaving again and shaving again… While splitting 9x 1:10 does lead to nanos and it you need 10 more you split the denomination 1 up 1x more

I hear you too but I think when just working with multiple different denominations there will be an equilibrium where people just don’t need to split anymore at some point…

And/or there may be market places… Node runners who want to trade those super small denominations they have at stupid numbers for full coin at a smallish discount/bonus … And it’s just computers who need to track all your small coin stuff…

Platforms will limit the digits of your withdrawal to 2 behind the decimal place if there is a reason for it… They will go 18 decimal places if there is no reason

[Southside]

We know you are busy.
Please try to get adequate sleep and exercise.
Last thing we need right now is a burnt-out @chriso

Or any other team member.

Just when you have a minute Chris - or stick it in front of some other appropriate person.

[Traktion]

If it’s a possible solution, I’d be tempted to have a crack at implementing an owned pointer on a test net. It should be the simplest type and it could be used for a number of duties.

I’m guessing there is more to it than meets the eye, but it would be a great learning project for Autonomi internals. If it is worthy, it could become a PR to main code base too.

[rreive]

@riddim

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.

This above proposal makes perfect sense, your keys, your money. J

said another way, if I understand the general essense of the solution proposed:

1- group the tokens needed to settle the transaction into the appropriate ‘denomination bundle’

2 gen the key for the group of whole tokens and ‘divisible token bits’ and then

3.re-assign the key ownership to bundle complete the transaction.

Observation- The above proposed digital approach solves the age old unsolvable problem the old physical money world (not currency) has using Inter-country trade physical gold settlement vaults.

For example, right now, even as BRIC and associate countries move to re-organize the constant physical movement of gold to settle the portion of a country’s gold (world has 195 countries) balance relative to other BRICs country balance, using this new BRICs mini vault(maybe at more than one site in their country) method,

there is still a labour intensive component required to constantly facilitate the daily shuffling of gold bars between mini vaults each month to settle Inter-country balance of payments at the very top level of the money system.

The solution above implies creating new wallet functions to group tokens and token bits into a ‘denomination bundle’.

Which means some fairly straight forward native token wallet development as I understand it?

[rreive]

@riddim

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

I concur, as one who followed the IOTA project really closely, the supersized DAG approach they attempted to put into play was in fact a sort of centralized multi-branching and re-joining of branching which was super complex.

The solution being proposed as I understand it, maintains a small ‘nano DAG’ at every antnode in the network, and then when a user who owns the value represented in the nano-DAG at the node swaps keyownership for a set of nano-DAG nodes representing a ‘denominated bundle’ amount, by simply sending the other end of the transaction settlement one key which represents those DAG value points,

a bundle of nano-DAG points of value associated to the one key, which in fact those value points are/may be located in many other antnode ‘hosted’ native token nano-DAGs, which means the public key exchanged representing that ‘bundle’ also has a map to those value points which need a key update?

The challenge, if I am understanding this properly, will be the same as it is for the current chunk replication already solved , that is

maintaining the replication(redundancy) of those "money’ nano-DAG value points of with their associated access keys,

should any of the antnodes representing such value stop or be removed from the network…,

so that the other affected antnodes in the close group quorum or otherwise are triggered to appropriately request the new/re-assigned nodes now joining the close group (getting auto shuffled based on their XOR address relative closeness)

to then balance the close group total number

that is add copies of those nano-dag value points (lost when an antnode shuts down with them) to their own nano-Dag,

Where the end result of antonodes with nano-DAGs relative to the ‘key ownership change’ in nano-DAG values (representing the transaction)

means there is some minimum # of ‘change of ownership’ copies(of those nano-DAG value points) rule needed

to ensure this proposed native token money system is redundantly protected

and be designed in a manner that keep all antnodes ‘change of ownership of value points’ performant (fast key re-associations to existing nano-DAG value points) ,

where one 'master value point/XOR location) is marked ‘primary’ for fast settlement exchange, and the other copies of those value points are ‘burnt’ after finality (of settlement/transfer of value confirmation), sent a message to burn the copies of the same value points found on at least two other antnode’s nano-DAG ?

@riddim @traktion please comment and correct..

I think we could use an infographic on the above diagramming this properly?

maybe in Archimate 3.0 or UML (draw.io anyone , access from gdocs when creating a new diagram) ?

[Traktion]

@Traktion

If it’s a possible solution, I’d be tempted to have a crack at implementing an owned pointer on a test net

So, I had a crack at this in scraps of spare time.

After a bit of faffing getting AntTP to play nicely with a local test network, the actual changes were relatively easy.

I changed the logic of POST pointer to accept both an owner private key and an address public key.

I then updated the AntTP REST endpoints to allow the GET/PUT pointer endpoints to accept a ‘name’, instead of an address.

The underlying ant client libraries and ant node functionality was also changed to accommodate separate owner/address keys.

The result:

• You can derive the address from an arbitrary string for both GET and PUT (update). You need to know a common seed secret key, but given we only need it to derive the public key, sharing it is fine (it doesn’t imply ownership, etc).
• Associating the pointer with a chunk, allows Autonomi to become a huge key/value store of chunks (or mutables).
• This could be leveraged in many ways, including DNS style name lookups for chunks (or other mutables).
• It decouples ownership from addressing. One person can create/update a pointer, derived from their private key and an arbitrary string (a ‘name’). Anyone else can derive the address of the pointer from a separate/shared ‘private’ key.

Next…

• I want to try changing the address and/or owner of the pointer. Right now, this doesn’t work as the originals are used to 1) check ownership and 2) check uniqueness of the address. Maybe ‘new_owner’ and ‘new_address’ fields will be needed, which then get switched during ant node checks/persists.
• Once owner can be changed, obviously it means a different person can mutate the data or it can be sent to a burn address to make it immutable and/or ‘burnt’.
• As above, this is basically NFTs working right of the gates too (first to create the pointer with the known private key + name, gets to own the pointer (and therefore the NFT).
• This is obviously a simple pointer type, but I see no reason why the other types couldn’t be changed/cloned to allow similar functionality.

Obviously, these are breaking changes to the network. They work on my local network, but the changes would need to be supported by production nodes to be rolled out. However, it’s been very interesting understanding how straightforward it is to change these types.

It’s also been interesting to understand the role of evm-testnet and how it is present on local networks. I wonder how embedded this is in the flows and how easily it could be substituted for token exchange (i.e. mutable data ownership change) for payments. Minting is a whole other kettle of fish, but understanding ‘payments’ is something I want to dig into more.

It also doesn’t cover things like splitting, minting, etc. However, I wanted to prove out splitting ownership from addressing first, as that unlocks the first steps.

[rreive]

@rreive

For example, right now, even as BRIC and associate countries move to re-organize the of

something like this - generated on DiagramGPT in 15 minutes of command prompt engineering by moi

Share link

Settlement Flow of Fungible Token Transaction on DAG XOR Network

[Traktion]

@rreive

@riddim @traktion please comment and correct..

AFAIK, the Maidsafe DAG oriented design was to seed the DAG with a start token, then split the graph heads for each spend. This is more scalable than one huge DAG, for all the tokens.

However, it still has privacy concerns, as there is an audit trail of transactions prior, albeit with limited context (IIRC, key privacy details remained private, but it was obvious the transaction had happened).

There are also concerns over DAG forks. While an owner may only split their token in an organised way, having a whole DAG with many owners, could lead to some interesting merges. I would have thought it would be safe as each token owner would only be changing their part of the DAG, making forks resolvable. I may be simplifying the challenges though (I don’t know enough about how forks are resolved).

This thread proposes returning to the original white paper concept of tokens represented as digital assets, which could just be transferred between owners. Much like handing a physical token from one person to another.

In order to have smaller token units, the plan was to split them into smaller tokens, much like you would break a large note into coins. It would also mean a transaction may be made up of many tokens, much like a cash transaction may.

In current form, the autonomi network doesn’t have a concept of ownership transfer. This prevents a whole raft of useful use cases, including the above. Indeed, for mutable data, the address is derived by the owner’s key, coupling the two together.

In response to this thread, I’ve looked at decoupling owner from address. This is step one for transferable assets. Step two will be to attempt an ownership change. If we can accomplish these two things, we have the basis for the original white paper concept.

Minting and splitting tokens is a whole additional challenge though. Minting may need a smart contract to interact with the network (we have that integration already, anyway!). Splitting may mean creating small DAGs to connect the parent token to the child tokens (splits). The parent token could be ‘burned’ (ownership changed to public key, with no known private key) in the process, with the child tokens living on.

An alternative could be a using a smart contract to split a token by burning the original and minting child tokens, without needing a DAG. However, it is slower, adds complexity, reduces privacy, etc. It’s an option though, with token splitting.

That’s the thought journey so far, at least from my perspective.

[Traktion]

@Traktion

So, I had a crack at this in scraps of spare time.

In case anyone is interested, here are the branches for AntTP and Autonomi (former depends on the latter):

GitHub - traktion/AntTP at separate-owner-address-mutables

GitHub - traktion/autonomi at separate-owner-address-mutables

To reiterate, these are only for local network consumption (warts and all)!

[riddim]

Haha your thinking is over my head I’m afraid xD at least in this moment of time - will re-read later when I have some more time =)

What @Traktion said - in the case of only full coin there wouldn’t be a dag involved anywhere - on token split the idea would be to break up a full coin into smaller denominations and unse those (I personally would only do 1:10 or 1:100 splits… But I guess that’s a matter of taste… When doing less generic splits you run into the issue of not having good reusable amounts or the mini dag starting from the full coin becomes a complicated dag again… )

---

okay - re-read and I had something so much simpler in mind …

just having an owner field for each token … and being able to change that owner field on ownership transfer …

if you want to pay 7.86 ANT instead of doing DAG-magic and sending 7.86 as one TX, having an unspent rest and stuff (and for validating the TX the recipient needs to traverse all TX back to genesis) you look at your wallet and you may transfer ownership of:

6x full ANT
18x 0.1 ANT
6x 0.01 ANT

30 network operations total (that can be executed in parallel)

the recipient can query those 30 objects in parallel too and therefore the complete TX can be done within ~2-15 seconds (currently observed as population time for scratchpads - arbitrum isn’t faster)

… the next level of the suggestion is to create the possibility to make ownership something a network object can have (probably debatable because the question is how to get back to individually owned coin after having ownership transferred somewhere else once …) to create the possibility to bundle e.g. 98 ANT + 10x 0.1 ANT + 100x 0.01 ANT into an collection of token worth 100 ANT that can then be transferred with a singled ownership update (on the collection) without the need to update ownership of all those little token individually

the nano DAG only comes into play when splitting full coin to validate the parts of the coin are valid (and if we’d agree to always go for x10 splits … with 18 splits we’d be at 10^-18 so the nano-dag would have a maximum length of 18 hops … if the payee communicates coin addresses and their parent-split-addresses with the TX info the recipient could easily fetch that data and validate it - even if it’s a raspberry pi/phone/… old pc … there’s no way the DAG could be crawled all the way to genesis by a regular user… “for everyone” )

[neo]

Can they be rejoined and have say 1.1 tokens. Or maybe 0.91 if we always ensure that you cannot combine back to over one token?