BitShares Forum
Main => General Discussion => Topic started by: bluebit on November 12, 2014, 07:40:34 pm
-
Looking forward to seeing the escrow feature in the next update :)
https://github.com/BitShares/bitshares/issues/944
Once again great job at adding this!!!
+5%
-
wow that will be awesome
-
So I'll be able to do this, rather than cold storage, to safely store my millions of BTS?
Who and how will be able to control the voting rights of such shares?
Nice.
-
So I'll be able to do this, rather than cold storage, to safely store my millions of BTS?
Nice.
You mean a cold key as escrow agent? Hmm. I guess it would allow you to view your balance without it being spendable. Interesting.
Sent from my SM-G900T using Tapatalk
-
So I'll be able to do this, rather than cold storage, to safely store my millions of BTS?
Nice.
You mean a cold key as escrow agent? Hmm. I guess it would allow you to view your balance without it being spendable. Interesting.
No, I just want to have easier access to my bitshares, so I can vote the shares, and so if I get hit by a bus, or my cold storage key gets destroyed,.... my family/loved ones can still get access to them...
And I want a safer way so if any of my important keys gets compromised, I won't get my shares stolen.
-
http://www.reddit.com/r/BitShares/comments/2m3r43/escrow_feature_to_be_included_in_the_next_release/
I finally can take out my coldstorage and make it coldcoldstorage :)
-
Looking forward to seeing the escrow feature in the next update :)
https://github.com/BitShares/bitshares/issues/944
Once again great job at adding this!!!
+5%
So everyone knows, the GitHub issues are constantly being reorganized--so having this in the next milestone right now does not guarantee it will make the next release.
-
Escrow balances will not earn yield.
Escrow agents can only divide the funds among the sender/receiver.
Sender can only release to receiver.
Receiver can only release to sender.
Sender & Receiver can divide funds among the sender/receiver
Blockchain support is mostly there (in testing)... wallet support and GUI support is likely a ways off.
-
Now we just need to copy smart contracts and we can be up 100% like counterparty! ;)
-
Awesome, this is really useful to have! Can it be used like an (almost) standard 2 of 2 address if an escrow agent simply isn't specified?
-
2 of 2 is standard multisig which is supported
Sent from my SCH-I535 using Tapatalk
-
2 of 2 is standard multisig which is supported...
...on the blockchain but not the client currently. Meaning from the user's perspective it currently pretty much doesn't exist. Sorry but sometimes I get the frustrating (hopefully incorrect?) feeling that important features like multisig, offline transaction signing, and decoupling BTS voting keys from spending keys are being pushed aside for other things that are nice to have but IMHO lower priority (like escrow transactions, voting booth, Turing complete scripts, and frankly even the lightweight client is slightly less priority in my view than multisig/offline transaction signing/decoupling voting keys).
I don't see how this helps with cold storage concerns like some people in this thread are speculating that it does (at least not as long as offline transaction signing does not exist in the client).
The point of the cold storage is to not require the computer, which holds the private key that gives access to the funds, to be made accessible to the internet. Since the client does not currently have offline transaction signing, that means it needs to connect to the internet to broadcast its transaction.
So say you put your BTS wealth into an escrow transaction with three keys you ultimately control (sender key, receiver key, escrow key). The sender key is online because you had to broadcast the transaction to move your BTS into the escrow in the first place using your online client. The receiver and escrow key can initially be offline. But what if you want to get some part of the BTS back into your possession to spend it? Then you are forced to either bring the receiver or escrow key on to an online computer to broadcast the necessary transaction. At that point, if your computer(s) are compromised, an attacker can use the keys to release all of the funds to the sender and then send the sender's now released funds to the attacker. Also even if you succeed at only releasing a partial amount to the sender and the rest to the receiver, what happens when you want to get access to a little bit more? Now you need to bring the receiver key online to move the remaining funds back into a new escrow transaction!
This brings up an interesting question. Does this escrow implementation allow the sender/receiver/escrow accounts to each individually be multisig accounts? Ideally it should. If I am the sender or the receiver, I would ideally want to be able to send large funds to an escrow or receive funds from an escrow from/to my default 2-of-3 multisig address so that I am at no time exposed to theft if my hot client's private key is compromised. Allowing the escrow account to also be multisig adds security benefits there as well but also allows other interesting possibilities like requiring a group of people come to a consensus on how the funds should be divided between sender and receiver. This is not doable in a straightforward manner with a traditional multsig (although it is possible with threshold signatures like in CryptoNote), since you want just the sender and receiver (2 keys) to be able to divide funds between each other without requiring any outside intervention, but you also want to allow the escrow to be a M-of-N multisig (with M > 2) while still making it impossible for just 2 of the N escrow signatures (or 1 signature from either sender/receiver AND 1 of the N escrow signatures) from being enough to divide the funds between sender and receiver. Allowing multisig for the escrow account in this escrow transaction solves this problem. A crude approximation to this solution can be accomplished through traditional multisig by having a (N+M)-of-(3*N) multisig, where the sender holds N of the keys, the receiver holds another N of the keys, the remaining N keys are distributed among the N escrow parties, and of course M <= N is the number escrow parties that need to agree with a particular distribution between sender and receiver. Another (more general and efficient) solution would be to just implement threshold signatures so that each of the N keys in a multisig have a fractional weight associated with them and the transaction is only valid if the sum of only the weights associated to keys with valid signatures attached the transaction is greater than 1.
-
Off line trx signing infrastructure has been put in place.
Multi sig is what toast is working on right now.
-
Off line trx signing infrastructure has been put in place.
Multi sig is what toast is working on right now.
+5%
Please don't forget to create a multisig transaction type where the transaction output can be spent like a normal multisig if there are enough signatures, but signature(s) from a subset of the keys (perhaps just one particular key) alone can only change the delegate slate that the BTS balance is voting for but not the multisig addresses of the original transaction. This way a user can update their votes with a hot client but to move their funds they would need to also sign the transaction with their cold storage keys. Bonus points if the same mechanism can also be used to claim yield on BitAssets without exposing all of the keys to move BitAssets to another owner.
-
Great to see the new functions, great work!
-
Off line trx signing infrastructure has been put in place.
Multi sig is what toast is working on right now.
+5%
Please don't forget to create a multisig transaction type where the transaction output can be spent like a normal multisig if there are enough signatures, but signature(s) from a subset of the keys (perhaps just one particular key) alone can only change the delegate slate that the BTS balance is voting for but not the multisig addresses of the original transaction. This way a user can update their votes with a hot client but to move their funds they would need to also sign the transaction with their cold storage keys. Bonus points if the same mechanism can also be used to claim yield on BitAssets without exposing all of the keys to move BitAssets to another owner.
In the pipeline: https://github.com/BitShares/bitshares/issues/981
-
Off line trx signing infrastructure has been put in place.
Multi sig is what toast is working on right now.
+5%
Please don't forget to create a multisig transaction type where the transaction output can be spent like a normal multisig if there are enough signatures, but signature(s) from a subset of the keys (perhaps just one particular key) alone can only change the delegate slate that the BTS balance is voting for but not the multisig addresses of the original transaction. This way a user can update their votes with a hot client but to move their funds they would need to also sign the transaction with their cold storage keys. Bonus points if the same mechanism can also be used to claim yield on BitAssets without exposing all of the keys to move BitAssets to another owner.
In the pipeline: https://github.com/BitShares/bitshares/issues/981
+5% Great. I think this will make a big difference to voter participation.
-
Off line trx signing infrastructure has been put in place.
Multi sig is what toast is working on right now.
+5%
Please don't forget to create a multisig transaction type where the transaction output can be spent like a normal multisig if there are enough signatures, but signature(s) from a subset of the keys (perhaps just one particular key) alone can only change the delegate slate that the BTS balance is voting for but not the multisig addresses of the original transaction. This way a user can update their votes with a hot client but to move their funds they would need to also sign the transaction with their cold storage keys. Bonus points if the same mechanism can also be used to claim yield on BitAssets without exposing all of the keys to move BitAssets to another owner.
In the pipeline: https://github.com/BitShares/bitshares/issues/981
+5% Fantastic. This with cold storage will make voting safely so much easier.
for( auto owner : current_balance_record->owners() ) //eventually maybe multisig can delegate vote
But let's not have that be a maybe. Eventually, multisig balances should absolutely be allowed to change the delegate slate (or restricted owner) using only a signature by the restricted owner. A 2-of-3 multisig arrangement for security purposes should not require the primary owner to bother the multisig authentication company every time they want to change their vote.
By the way, am I understanding the code in set_vote_info (https://github.com/BitShares/bitshares/commit/dad5c882bd587ce1cdebf43720a08fb90e55915a) correctly in that the required transaction fee can come from the same balance that the user wants to update the votes for? If so, this is bad because I think it means that if a hacker can compromise the voter key they can burn all of the user's funds. While not really profitable to them (other than the tiny deflationary effect it can have as a BTS stakeholder), there can be malicious hackers who just want to hurt their victim. Therefore, I don't think any funds should be allowed to be spent with just a signature from the voter key. The transaction fee should be paid for from another balance for which the user can sign the transaction with the corresponding owner keys.
-
If so, this is bad because I think it means that if a hacker can compromise the voter key they can burn all of the user's funds. While not really profitable to them (other than the tiny deflationary effect it can have as a BTS stakeholder), there can be malicious hackers who just want to hurt their victim. Therefore, I don't think any funds should be allowed to be spent with just a signature from the voter key. The transaction fee should be paid for from another balance for which the user can sign the transaction with the corresponding owner keys.
It is rate-limited. Keep an eye on your balance and you won't lose much.
Read the validation code, not the thing building the transactions ;)
-
But yes, eventually. A good learning task IMO hint hint
-
If so, this is bad because I think it means that if a hacker can compromise the voter key they can burn all of the user's funds. While not really profitable to them (other than the tiny deflationary effect it can have as a BTS stakeholder), there can be malicious hackers who just want to hurt their victim. Therefore, I don't think any funds should be allowed to be spent with just a signature from the voter key. The transaction fee should be paid for from another balance for which the user can sign the transaction with the corresponding owner keys.
It is rate-limited. Keep an eye on your balance and you won't lose much.
Can you provide more details on the rate limiting? Also, I would still feel more confident if I at least had the option to prevent any spending of balance funds with only a voter key signature.
-
Well right now the code says you can do 1 update for 0.5 BTS every hour. I can change those parameters now but more advanced functionality will have to wait for a more comprehensive rewrite. This is a hack to let big stake start voting at all.
-
Well right now the code says you can do 1 update for 0.5 BTS every hour. I can change those parameters now but more advanced functionality will have to wait for a more comprehensive rewrite. This is a hack to let big stake start voting at all.
Okay, as long as that more advanced functionality (which I presume avoids the vulnerability I discussed) is planned. It is a good enough hack for now. As long as you check your funds at least once a week, the most you can lose (assuming it is all in one balance and not multiple ones) is 84 BTS, which at the current market value for BTS is less than $2.
-
2 of 2 is standard multisig which is supported
Sent from my SCH-I535 using Tapatalk
We need more than 2 of 2 but this is what I've been waiting for.