BitShares Forum

Main => General Discussion => Topic started by: toast on November 19, 2014, 05:46:34 pm

Title: Test network: Multisig and offline transaction building
Post by: toast on November 19, 2014, 05:46:34 pm
build this:  https://github.com/BitShares/bitshares/tree/ce5e49e5f6cf13df9f409979900addb161892350

test funds:  https://github.com/BitShares/bitshares/blob/ce5e49e5f6cf13df9f409979900addb161892350/dev-test-keys.txt
tests:
https://github.com/BitShares/bitshares/blob/ce5e49e5f6cf13df9f409979900addb161892350/tests/acceptance_tests/features/multisig.feature
https://github.com/BitShares/bitshares/blob/ce5e49e5f6cf13df9f409979900addb161892350/tests/acceptance_tests/features/cold_storage.feature

multisig usage:
Code: [Select]
>>> wallet_multisig_deposit 100 XTS 2 [addr1, addr2, addr3]
balance_id = >>> wallet_multisig_get_balance_id 2 [addr1, addr2, addr3]
builder = >>> wallet_multisig_withdraw_start id withdraw_addr
builder' = >>>wallet_builder_add_signature builder true    // etc
cold storage usage:
Code: [Select]
addr = >>> wallet_address_create my-acct
>>> wallet_transfer_asset_to_address 100 XTS from-acct addr
builder = >>> wallet_withdraw_from_address 99 XTS addr to-acct
>>> wallet_builder_add_signature builder true  // "true" to broadcast
Title: Re: Test network: Multisig and offline transaction building
Post by: arhag on November 19, 2014, 06:46:24 pm
This is exciting.

So does this allow someone to also create a transaction that withdraws from one multisig balance and deposits it into another multisig balance in one atomic operation so that the funds are never in a single address balance?

Also, I am hoping this is the lower level stuff that a later multisig version of TITAN will eventually use. It seems these commands are dealing with raw addresses and not TITAN names. So I expect that eventually the client will come up with derived child public keys for each of the N users in the multisig and then put the corresponding addresses in the wallet_multisig_deposit command (in order to protect privacy like TITAN does). Then the existence of that balance and the secret index used to derive the child key can be privately shared to each of the N users through the encrypted mail system.

Also, it would be even better if the default mode was for the secret index to derive each child key was the same for all N addresses and was calculated by EC point multiplication of the one time private key and the public active key of the primary receiver so that the primary receiver could at least be aware that they had incoming funds in multisig balances by scanning the blockchain and without being dependent on the mail system functioning. Then if they have access to the other (M-1) private keys, they could theoretically access all the funds sent to them even if the mail system wasn't functioning properly. This would be very useful in the typical 2-of-3 multisig cases that I expect to be common for security reasons.
Title: Re: Test network: Multisig and offline transaction building
Post by: toast on November 19, 2014, 07:05:04 pm
This is exciting.

So does this allow someone to also create a transaction that withdraws from one multisig balance and deposits it into another multisig balance in one atomic operation so that the funds are never in a single address balance?

Also, I am hoping this is the lower level stuff that a later multisig version of TITAN will eventually use. It seems these commands are dealing with raw addresses and not TITAN names. So I expect that eventually the client will come up with derived child public keys for each of the N users in the multisig and then put the corresponding addresses in the wallet_multisig_deposit command (in order to protect privacy like TITAN does). Then the existence of that balance and the secret index used to derive the child key can be privately shared to each of the N users through the encrypted mail system.

Also, it would be even better if the default mode was for the secret index to derive each child key was the same for all N addresses and was calculated by EC point multiplication of the one time private key and the public active key of the primary receiver so that the primary receiver could at least be aware that they had incoming funds in multisig balances by scanning the blockchain and without being dependent on the mail system functioning. Then if they have access to the other (M-1) private keys, they could theoretically access all the funds sent to them even if the mail system wasn't functioning properly. This would be very useful in the typical 2-of-3 multisig cases that I expect to be common for security reasons.

Not yet for bolded part. Everything else sounds about right.