There have been a few vanity keypair generators that popped up recently and I was curious if there was a secure way to do distributed keypair generation so that you could pay someone to generate a keypair for you.

I came up with a way to do it via a series of Stellar transactions that I've described in this post: https://medium.com/@zulucrypto_23845/distributed-trustless-workers-with-stellar-e197fd1b77f6

I also created a repository with a code example: https://github.com/zulucrypto/stellar-smart-contracts/blob/master/distributed-worker/README.md

After working on this, I think it would be really handy to have a collection of typical smart contracts that people could start building with. If anyone has a smart contract they'd like to see implemented or is able to contribute an implementation or description of how you could do one, please open a github issue!

    Fascinating! So if you receive ten offers you should create ten escrow accounts one for each worker? Then the final winner takes all and you simply merge back all remaining escrows? Or the escrow creation is done only after you've settled on a worker?

    • zcc replied to this.

      zcc
      Request: CryptoAliens smart contract ?

      • zcc replied to this.

          Torkus If there was a big enough market for this service, there would probably be multiple worker companies all working on lots of customer requests at once, so the customer would still create a single escrow account and then sign it over to the first worker that found a valid keypair.

          I think it would end up being similar to mining... workers are generating random keypairs as fast as they can and if any of them match an outstanding customer request they publish the data entry indicating that they've found a keypair and the customer claims it. Your profits would be based on how fast you can generate keypairs and what customers are willing to pay.

          The example only deals with a single worker, but it should work the same way if you had a bunch. There would just be more communication back and forth with data entries on the various accounts.

          fritz I'd have to find someone who was really good at drawing cute aliens ?

              This is awesome, thanks for sharing this. Just today I was looking into how "smart contract" functionality could be implemented in Stellar. I will mess around with this over the weekend!

              • zcc likes this.

              Thank you for the post, you shared some great insights. I stumbled upon vanity addresses the other day and looking at your post today I can say that there will be a market for it as more people become aware of this feature. The potential for marketing is huge. I can only see this market audience grow as Stellar grows (and companies start mass producing addresses for their customers).

              Just a few questions: To conserve energy, would there be any way to 'pool' the resources from multiple 'miners' to generate those vanity addresses? (it takes a long time to produce anything above 4 letters, maybe multiple computers can shorten the time if they all work together?) I don't even know if that's possible, but i'll read more about and come back to you. (maybe that's a smart contract idea :p)

              One more thing... in terms of security, would encryption prevent the private key from being revealed if someone hacks the 'miners' computer?

              Great idea by the way. I can see this smart contract be used for other areas where 'mining' (processing images, testing math algorithms, etc) for work can be paid in lumens between the customer and the worker while still having it all on the ledger.

              • zcc replied to this.

                pantheon52

                To conserve energy, would there be any way to 'pool' the resources from multiple 'miners' to generate those vanity addresses?

                This won't conserve energy since you'd still need to do the same amount of work, but it would shorten the time it takes to find an address.

                In terms of security, would encryption prevent the private key from being revealed if someone hacks the 'miners' computer?

                Once the miner finds the new keypair they switch the account over to the customer. There's no way the customer can trust that the miner didn't keep the keypair themselves, so what the miner does is add the customer as a signer and disables the original private key so that no one can use it.

                Since the private key won't ever be used, you don't even need to worry about encryption.

                I can see this smart contract be used for other areas where 'mining' (processing images, testing math algorithms, etc) for work can be paid in lumens between the customer and the worker while still having it all on the ledger.

                I think so too! Vanity keypairs are kind of a special case because it's easy to prove that you've created the keypair without actually giving it up. Something like processing an image would be harder to "prove" without giving up the image you generated.

                I'm hoping this demo contract will inspire some more ideas and implementations for practical things that are outside of the Stellar network!

                    zcc

                    Thank you for the response.

                    Since the private key won't ever be used, you don't even need to worry about encryption.

                    I had to read your article again, I missed the bottom part where it explains the multisig part lol.

                    Something like processing an image would be harder to "prove" without giving up the image you generated.

                    It would require just a bigger smart contract and escrow service but I can see it be done in the future for sure.

                    Fantastic job with this by the way, great first step towards moving mountains! I'll be checking back on this to see how you are doing. If you need any help with testing, let me know!

                      Can smart contracts on Stellar be written to issue editions of digital art (like cryptokitties does with ERC 721, or the newer ERC821?)

                      • zcc replied to this.

                        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.