For companies it would be useful to have the possibility to use multisig for signing profile data or updating the zone file (for example 2/3, 4/5, 10/10, m/n has to agree on it).
Is this planned to add to Blockstack in the future?
Hi @vsund,
I’m going to provide a thorough answer, so I can point to it in the future when others ask about keys 
Overview
There are three sets of keys in Blockstack: your owner keys, your payment keys, and your data keys.
The payment keys are used only for funding your transactions. They cannot execute name operations, nor can they be used for signing data. If you look at a Blockstack transaction, for example, you’ll always see at least two inputs: an input from the owner key signed with the SIGHASH_ANYONECANPAY hash code, and one or more inputs from the payment key(s) that pay the dust fees, name fees, and transaction fees.
The owner keys are used for authorizing name operations. A Blockstack transaction is only valid if the owner key has signed it. The data keys are used for signing your off-chain data, like profile data. By default, other users discover your data public key by looking up your name, fetching the associated zone file, and searching for the key in a specially-crafted TXT record.
Data keys with Onename-registered names
When someone registers a name in Onename and then transfers it to the CLI, they cannot get a data key put into their zone file (since there is no safe way for Onename to generate the data key for them). This poses a problem: how do other users look up and verify the name’s profile if there is no data key? The best thing to do is to have the user run an update command to set a new data key and then run set_profile to replicate a new signed profile, but we thought this would be too time-consuming and difficult (i.e. the user needs to obtain Bitcoin and then wait a few hours).
As a work-around, we modified set_profile so that once a user transfers their name to a new address, set_profile uses the owner key to sign the profile, saving users both time and money. For that reason, when someone runs lookup on a name, the lookup command will use the data public key in the zone file if it is present, or it will use the public key in the profile.json JWT and also verify that the public key’s base58check address matches the owner address (which is obtained from the blockchain).
Once we have the Onename application running locally, this option will be deprecated, since the local application will generate a data public key from the get-go. We’ll probably set up some way to fund users’ first registrations, so they won’t have to obtain Bitcoin to get started with Blockstack.
Owner keys: Future Directions
As of 0.14, a user has 3 owner keys, and 2 of them must sign all name transactions. Going forward, we’re going to have a set of keys for each name operation. For example, there will be a multisig key bundle for NAME_UPDATE that can only issue NAME_UPDATE transactions. Same for NAME_TRANSFER and NAME_REVOKE.
The reason is that we’d like it to be possible to delegate some aspects of name stewardship to other people. For example, a user might keep the NAME_UPDATE keys to herself, but distribute the NAME_TRANSFER keys to different people so that 2 of 3 people must agree to a NAME_TRANSFER. We imagine that there could be services in the future that take the place of GoDaddy–they would let the user register and transfer names, but the user would retain the power to update and revoke them.
Data keys: Future Directions
In 0.14, all the data you sign is signed by your data private key (or if you do not have a data private key, your owner private key will be used instead). In the future (starting in 0.14.1), the data private key will be used to create hardened child private keys–one for each datastore. Datastores will be used to both store app-specific data, and to allow users to create “sub-users” for holding different kinds of data.
Once we have datastores working in production, what we’d like to do is use DEX [1] instead of data signatures. Then, the user can specify whatever signature acceptance criteria they want for their data, much like how they do in Bitcoin transactions today. This covers the case of 2/3 or m/n or whatever multisig criteria the user wants for datastores.
Hope this helps!
1 Like
That looks great!
Though I got questions
- What’s the reason for splitting owner and data keys? Is there an use case that I miss currently?
- In the zone file one public key gets specified. You wrote that it currently needs
2/3. Why there’s only one key? - Is it possible to specify an own
m/nof required signatures that it needs for an update to be valid?
What’s the reason for splitting owner and data keys? Is there an use case that I miss currently?
It’s good security practice to have one key for one task, since the security properties of each task will be task-specific. For example, name operations are rare when compared to account-creations, and a particular name operation (NAME_UPDATE) can re-set the key used to create accounts (the data key). As such, the owner key should be kept more secure than the data key, and should only be used in settings where it is less likely to be stolen.
In the zone file one public key gets specified. You wrote that it currently needs 2/3. Why there’s only one key?
Changing the zone file (via NAME_UPDATE) or executing any name operation requires 2-of-3 of the owner keys, and paying for name operations requires 2-of-3 of the data keys. Signing off-chain data like profile.json or writing to datastores (in 0.14.1) only requires a single key signature (from the data key). We intend to change this in the future by adding support for smart signatures written in DEX.
Is it possible to specify an own m/n of required signatures that it needs for an update to be valid?
Yes, In 0.14.1, you should be able to create wallets with arbitrary m/n keys for the owner signature and payment signature.
2 Likes