Author Topic: MultiSig with TITAN?  (Read 1669 times)

0 Members and 1 Guest are viewing this topic.

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: xeroc

Offline arhag

  • Hero Member
  • *****
  • Posts: 1214
    • View Profile
    • My posts on Steem
  • BitShares: arhag
  • GitHub: arhag
Great. It's good to know that there is a plan in place for this. I'm sure you have already thought through a lot of this, but I would like to throw in my two cents on how I would like to see this implemented.

What I am looking for is to have the option for something that goes beyond just a straightforward multisig. First, each registered account would publically register three public keys (PRIMARY_PUBLIC_KEY which I guess is equivalent to the Active Key in the current system, SECONDARY_PUBLIC_KEY, and TERTIARY_PUBLIC_KEY) and a MULTISIG_EXPIRATION_DELTA which specifies the time increment from the time of the transaction to the time when the transaction can be spent by just one of the keys. For privacy reasons users should not choose a rare MULTISIG_EXPIRATION_DELTA.

When a spender creates a transaction that sends money to a recipient, the spender takes OneTimePrivateKey and does elliptic curve point multiplication with PRIMARY_PUBLIC_KEY, SECONDARY_PUBLIC_KEY, and TERTIARY_PUBLIC_KEY, to get SECRET1, SECRET2, and SECRET3, respectively. Then, PRIMARY_PUBLIC_KEY.child(SECRET1) => PRIMARY_RECEIVE_PUBLIC_KEY, SECONDARY_PUBLIC_KEY.child(SECRET2) => SECONDARY_RECEIVE_PUBLIC_KEY, TERTIARY_PUBLIC_KEY.child(SECRET3) => TERTIARY_RECEIVE_PUBLIC_KEY. The corresponding receive addresses are added to the transaction for multisig purposes, along with MULTISIG_EXPIRATION_DELTA, and also two encrypted memos: PRIMARY_MEMO and TERTIARY_MEMO. PRIMARY_MEMO, which would be encrypted with SECRET1, would contain the same information currently put in the memo with TITAN. TERTIARY_MEMO (encrypted with SECRET3) would only contain information on which registered account was the intended recipient of the transaction.

Spending the transaction before (TIME_OF_TRANSACTION + MULTISIG_EXPIRATION_DELTA) would require a signature from either PRIMARY_RECEIVE_PRIVATE_KEY and SECONDARY_RECEIVE_PRIVATE_KEY or PRIMARY_RECEIVE_PRIVATE_KEY and TERTIARY_RECEIVE_PRIVATE_KEY. Spending the transaction after (TIME_OF_TRANSACTION + MULTISIG_EXPIRATION_DELTA) would require a signature from either PRIMARY_RECEIVE_PRIVATE_KEY or SECONDARY_RECEIVE_PRIVATE_KEY (but not TERTIARY_RECEIVE_PRIVATE_KEY).

Users would use their wallet root key to deterministically generate the primary key, randomly generate a secondary key and safely store it offline, assign TERTIARY_PUBLIC_KEY to the well known public key of a third-party validator, and set MULTISIG_EXPIRATION_DELTA to some reasonable value like 6 months. As long as they move their unspent transactions at least every 6 months (they already have to do it once a year anyway to avoid the inactivity fee), they get the security benefits described in my previous post. But there are additional benefits with this approach. The validator can also act as an observer for received funds. The validator would only have to scan the blockchain with just one key and then look in the tertiary memo to see which of their customers the funds belong to. They could then alert each customer with just the subset of relevant transaction for thin client wallet setups. The validators would not be able to see the primary memo field or who the money came from. They would only see the user's account balance as a function of time for the duration of time that the user had chosen that validator. If the user loses access to their wallet root key but is able to recover the offline SECONDARY_PRIVATE_KEY, they can still get access to all of their funds after at most 6 months; however, they won't be able to see their old transaction history. Also, if the user dies but had given a copy of SECONDARY_PRIVATE_KEY to their beneficiary, the beneficiary can claim the funds after at most 6 months after the benefactor's death. The beneficiary would of course not be able to claim the funds while the user was still alive and active.

Offline bytemaster

We already have a field in the account record to operate exactly like you are describing, it is just not implemented in the wallet yet.   Ie: the blockchain is willing, but the wallet is weak.
For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline arhag

  • Hero Member
  • *****
  • Posts: 1214
    • View Profile
    • My posts on Steem
  • BitShares: arhag
  • GitHub: arhag
Does the BitShares toolkit currently have support for multisig transactions? And how does that work with TITAN? It would be great if there was some documentation on it.

Regardless of the current state of support of multisig, I think it would be really great if registered accounts could post their default multisig preferences. I suppose they can include that information today by storing it in the public data JSON, but I would like a protocol where the wallet clients of people sending money by default automatically respect the multisig wishes of the recipient. This would make multisig for the purposes of security far more convenient, since the receiver of money wouldn't have to immediately spend the transaction to themself just to secure it with multisig.

For example, one could upload 3 public keys to the blockchain under their account name, one of them a primary key and the rest secondary keys. The primary private key would be used to derive the shared SECRET used to decrypt the memo (also maybe a 4th observer key could also do this to track received transactions on the user's behalf). The secondary keys would not be able to derive SECRET (and thus not see the memo or who the transaction was from), but would be necessary to sign the user's spending transactions with a 2 of 3 multisig. One of the secondary public keys would be that of a user-chosen third-party validator that validates the user's spending transactions, and for the other secondary public key, its randomly generated private key would be encrypted and stored offline as a backup (possibly split among friends and family using something like Shamir's Secret Sharing). It should also be possible to change the public keys stored on the blockchain under the registered account at any time, again using multisig.

This kind of functionality would be incredibly useful from a security standpoint. In fact, I think the default behavior of the wallet should be to ask users to setup 2 of 3 multisig. Normal operation for the user would be to use a secure connection to the semi-trusted third-party validator to prove their identity in some way and send the transactions for the validator to sign. The strength of the proof of identity could vary depending on the conditions of the transaction, anything from just a BitShares XT Login to coming into a facility in person to verify using bio-metrics. If the validator is suspicious of the user's activity, or the accumulated spent amount of money signed by the validator in the last 48 hours is larger than some threshold, etc., then the validator can ask for a stronger proof of identity as a safeguard against thieves compromising your wallet (hacking, extortion, etc.). If the user no longer trusts the validator, or the validator is refusing to sign legitimate requests, the user can always wait until they can get access to their offline key and together with the primary key spend any transaction they want (most likely to change the validator on their account).

I am interested in what bytemaster has to say with regards to: incorporating this functionality in all BitShares DACs; whether this needs a hard fork to accomplish; how multisig works with TITAN and without compromising user privacy; and, assuming the blockchain and network allows for all of this today, how much of a priority it is to implement this functionality in a user-friendly way in the clients.
« Last Edit: July 22, 2014, 06:53:38 pm by arhag »