jeremy82many I've been thinking about how you'd do that, but haven't come up with an actual implementation.

I think you'd want to do it with accounts. In other words, each "kitten" would be an account and you'd trade them around by updating the signers in the same transaction you transferred XLM.

Curious to hear other people's thoughts!

      zcc Very interesting! After reading through your Medium post, and trying to wrap my mind around the way signers and thresholds work, it really changes your perspective on what an account is -- essentially an account is a an address that "owns" value as recorded on the blockchain. The "owner" of that address, owns that value. So, by altering the signing weights, this account can be a transferable asset. (Mind blown). For a CryptoKitties knock off, you'd need a way to "assign" a genotype (unique id corresponding to kitty traits) to an account. You could store this when the account is created in a data entry.

      To ensure this data entry is never altered, is it possible to set this weight extremely high?

      Also, I am very interested in decentralized poker (Mental Poker) and brainstorming how this may work with Stellar's "Smart Contracting" capabilities.

      • zcc replied to this.

          The setup of one Cat

          Public Key: pk
Cat Id:     c
Signature: H( c || pk ) = s

          Essentially, a trusted entity creates cats. Knowing this entity's public key, we can then verify that this is a legitimate cat. Even if people can mess with the cat around the cat, the will not be able to fake cats because this cat id is only valid with this public key.

          Setup

          A trusted party is the "Cat God" and generates the cats:

          1. Create account (public key = pk)
2. Attach data:
        cat_id : c
3. Attach signature as data:
         sig : s = H( c || pk )
3. Set all thresholds to 1

          Trading

          Exchange Cat

          Lets call buyer B and seller A (owner of cat)
1. A: Add B as signer with weight 1
2. A: Set A weight to 0
3. B: transfer X XLM to A

          At the end of this, A receives X XLM and B receives the cat.

          Thoughts??? (Just a rough sketch, probably missed some stuff)

            rob

            Yup, that's how the discussion has been going, since about a year ago.

            I was on my way to write a SEP for this, but was hindered by how stellar-core deals with signatures and changing signature weights within a transaction envelope.

                dzham

                Just adding... @MikeFair on the Slack channel was a big influence on this, when we tried to figure out how to use Stellar accounts as a way of doing bookkeeping for funds, IIRC.

                  rob -

                  To ensure this data entry is never altered, is it possible to set this weight extremely high?

                  The "manage data" operation has the same weight as most of the other account operations, so I don't think there's be a way to prevent managing data without also crippling the entire account. Since "manage data" is medium, if you wanted to lock someone out of it you'd also lock them out of everything besides "allow trust".

                  Essentially, a trusted entity creates cats....

                  Cryptokitties is an interesting example because the value of a cat is entirely tied to its appearance and even though the data behind a cat is stored on the blockchain the appearance comes from how it looks on a specific website. At least that's how I understand it, I'm not a cryptokitties expert. ?

                  If I was going to recreate that in Stellar and make it truly distributed, I'd publish some art assets and an algorithm for generating a random number and then turning that number into a set of properties that rendered a cat (color, stripes vs. spots, does it have crazy whiskers, etc.)

                  Instead of using data values I think you could use the public key of an account as part of the random number generator. Since you can generate tons of keypairs for free offline, you'd also have to add in another source of entropy. So, taking a rough stab at a cryptokitties algorithm:

                  1. Generate a keypair. This represents a cryptokitty.
                  2. Fund the account and keep track of the hash of the ledger that the account was funded in (call it L0)
                  3. Wait until 5 more ledgers have passed
                  4. Calculate the sha256 of public key + L0 hash + L1 hash + L2 hash + ... + L5 hash
                  5. Use the value calculated in step 4 as the seed of a random number generator
                  6. Use some agreed upon algorithm to generate and display the graphic for the kitty

                  As long as everyone agrees on the RNG algorithm and is using the same art assets, they should all agree what the resulting kitty looks like. Since you have to fund an account and wait 5 ledgers, there's a price for creating new kitties so you can't generate an infinite number offline and wait until you get one that looks cool and might be valuable. Hopefully it's not possible to control the hash of 5 Ledgers, so you have a source of entropy.

                  I think that would let you get rid of the "cat god" and still have valuable cats.

                  Also, I am very interested in decentralized poker (Mental Poker) and brainstorming how this may work with Stellar's "Smart Contracting" capabilities.

                  That's a really neat problem, perhaps you could use the same technique of getting entropy from Ledger hashes to make a fair card shuffling algorithm? Great suggestion for a smart contract example!

                    rob I haven't had any luck coming up with a way to do a real random result with Stellar. The closest I got was a really bad hack to implement a "coin flip" game:

                    1. A creates txAWins (valid starting at noon tomorrow) that merges GWAGER to GA
                    2. B creates txBWins (valid starting at noon tomorrow) that merges GWAGER to GB
                    3. A and B both sign txAWins and txBWins
                    4. At noon (within the same ledger) both transactions are submitted and SCP randomly chooses one that ends up getting confirmed

                      Thank you for the post. During the txTransfer transaction process, the post mentions that "Since the Worker knows the private keys for GWORKER and GVANITY it can provide these signatures and write them as data entries on the GWORKER account". So in this case, the private keys of GWORKER and GVANITY are disclosed to the customer? I'm a bit confused. Can someone please help me out?

                      • zcc replied to this.

                        atawera In this case it's the signature being provided and not the private key. Here's the detailed process:

                        1. The worker builds txTransfer
                        2. The worker uses SWORKER to generate signature1 and writes signature1 as a data entry
                        3. The worker uses SVANITY to generate signature2 and writes signature2 as a data entry

                        signature1 and signature2 end up being public, which is OK since they are only valid on txTransfer and can't be used for any other transactions.

                            zcc Thanks. Could you please guide me on how to generate these signatures (signature1 and signature2)? What api function do you use? I tried searching but couldn't seem to find how this can be done.

                            • zcc replied to this.