scope of token contract includes pricing, file management and a name system?

[dckc]

The scope of token contracts that I'm familiar with doesn't include setting prices. Prices are set elsewhere... in an auction, or an exchange, etc.

In fact, the way this contract is arranged seems to preclude things like auctioning off NFTs.

[fabcotech]

NFT (non-fungible token) in the way I see it, is a bag with "quantity": 1, "n": "silver" and with no other bag referring to the same tokenId "silver", if you have those 2 conditions you will never ever have another "silver" coin in this contract, there is only one that can be sold/sent, but cannot be divided, or cloned. It is non-fungible (isn't it ?)

Auctioning is not available at the moment, even the "SET_PRICE" for a bag is not coded, I don't see anything preventing auctioning mechanism. You would put you bag in a "auctions" object, and then purses come in, at some point, the one with highest balance is emptied, and the bag changes ownership, other purses are refunded of course.

[dckc]

Can that sort of NFT be owned by another contract?

If you just use an ERTP style Mint to make the NFTs (#2), then it can. And auctions contracts compose straightforwardly.

The RChain MakeMint contract doesn't have flexible AmountMath, but that's a straightforward enhancement.

The NFT in this contract is not just a bag, but a bag paired with a public key; i.e. a bag plus an access control list. But ACLs don't.

[fabcotech]

No, a bag (can be NFT or FT) cannot be owner by a contract because the mechanism of authentication is signature-based and not unforgeablename-based. This means that the rchain-token contract verifies signature before allowing an operation to be executed, signature is generated from payload + unique nonce and must match a public key, it can only be issued by off-chain agents (expect if you let a contract manage a private key).

Right now I'm working on fixing version 4, and will use it for various things in dappy, I do think dropping signatures in the favor of unforgeable names for authentication is the way to go (simpler), if we make sure that it does not open attack vectors that are non-existent with the current implementation.

Note 1: rchain-token has an advantage, which is the ability to dump all bags/data off-chain redeploy them, and have the ownerships still 100% preserved. (no unforgeable name for authentication)

Note 2: I principally developped rchain-token to address in a single codebase/protocol the needs for different components of dappy: files managment and name system. I noticed that a general purpose contract could be made out of it, it may have some capabilities that MakeMint does not have, and the other way around also.

[dckc]

dump/restore is definitely a challenge for unforgeable-name / ocap strategies. If that's a requirement, it wasn't explicit until now, AFAIK. Perhaps a benefit of this discussion was discovering it. Perhaps you want to document it more explicitly in the README or a code comment?

[dckc]

if the scope is file management and a name system, I suggest you reconsider the name "rchain-token"... or at least replace the 1st sentence of the readme: "Fungibles and non-fungibles tokens on the RChain blockchain."

[fabcotech]

Another challenge, let's say you have 100 tokens.

If ownership is expressed by the capability of generating a user-specific unforgeable name (like rho:rchain:deployerId in locker, I don't know about MakeMint), is it possible to send 50 tokens to some agent without requiring any action/deploy from this agent ?

It is possible with the current rchain-token architecture, simply create another bag with 50 tokens in it, and set .publicKey to someone else's: you don't own those 50 tokens anymore. This is what SEND_TOKENS does.

[dckc]

Sending ERTP style tokens does, in general, require that someone has deployed something to receive the tokens. But just like the .rho contracts here are deployed before anyone interacts with them, it's straightforward to deploy a sort of "post office" contract where anyone can send tokens to the post office and say "give these only to the party with public key XYZ".

Or people can use "mailbox" contracts in the registry a la inbox.rho in https://github.com/rchain-community/liquid-democracy/ .

There are other ways for the parties to rendezvous; in general, either of them may be another smart contract... an auction, or a covered call, or ...

[dckc]

... I don't know about MakeMint

It's one page of code¹. It's much simpler than the cryptographic stuff going on in these .rho contracts.

Please, before we continue this conversation any further, watch the 8 minutes from to 25:00 33:00 in Agoric + Protocol Labs // Higher-order Smart Contracts across Chains. Tell me the 1st line of code presented there or the 1st second of video that is not entirely clear.

Alternatively, look at the original "Simple Money" section of From Objects to Capabilities . Let me know the 1st word that is not entirely clear.

¹ in a traditional language such as JS; .rho is so verbose that it's longer there

[fabcotech]

Ok thanks I looked at the agoric presentation, I got it, you either possess an object/purse identifiable by the issuer (MakeMint for example) or you don't.

I will in fact need offchain dump/redeploy for what I want to do with this repo (but it is just for the #files branch). I'll fix release 4.0 on #master + #files that I both use, and work on understanding MakeMint, and if it can cover the usecases, eventually remove crypto and maybe just work on a ocap branch.

[dckc]

Discussion above addressed #3 and made progress on #2; what remains of this issue, for me, is the difference in scope between

• what's implied by the name rchain-token and stated in the 1st sentence of the README "Fungibles and non-fungibles tokens on the RChain blockchain" on one hand vs.
• the actual functionality of the contract and @fabcotech 's clarification that the contract was principally developed to fill a need for file management and a name system.

[dckc]

dump/restore is definitely a challenge for unforgeable-name / ocap strategies.

@fabcotech , discussion with @tgrospic of the PoS upgrade and rchain/rchain#2956 reminded me that the dump/restore challenge has a long history in the ocap community:

• upgrade: Live fast, die young and leave a good-looking corpse
• Persistence and Upgrade

In rchain-community/rstake#7 I learned @leithaus discussed upgrade in a presentation:

• Biologically inspired consensus Apr 2018