Author Topic: Fantastic Job Bytemaster!!! Escrow Feature  (Read 5565 times)

0 Members and 1 Guest are viewing this topic.

Offline luckybit

  • Hero Member
  • *****
  • Posts: 2921
    • View Profile
  • BitShares: Luckybit
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.
https://metaexchange.info | Bitcoin<->Altcoin exchange | Instant | Safe | Low spreads

Offline arhag

  • Hero Member
  • *****
  • Posts: 1214
    • View Profile
    • My posts on Steem
  • BitShares: arhag
  • GitHub: arhag
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.

Offline toast

  • Hero Member
  • *****
  • Posts: 4001
    • View Profile
  • BitShares: nikolai
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.
Do not use this post as information for making any important decisions. The only agreements I ever make are informal and non-binding. Take the same precautions as when dealing with a compromised account, scammer, sockpuppet, etc.

Offline arhag

  • Hero Member
  • *****
  • Posts: 1214
    • View Profile
    • My posts on Steem
  • BitShares: arhag
  • GitHub: arhag
Quote
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.

Offline toast

  • Hero Member
  • *****
  • Posts: 4001
    • View Profile
  • BitShares: nikolai
But yes, eventually. A good learning task IMO hint hint
Do not use this post as information for making any important decisions. The only agreements I ever make are informal and non-binding. Take the same precautions as when dealing with a compromised account, scammer, sockpuppet, etc.

Offline toast

  • Hero Member
  • *****
  • Posts: 4001
    • View Profile
  • BitShares: nikolai
Quote
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  ;)
Do not use this post as information for making any important decisions. The only agreements I ever make are informal and non-binding. Take the same precautions as when dealing with a compromised account, scammer, sockpuppet, etc.

Offline arhag

  • Hero Member
  • *****
  • Posts: 1214
    • View Profile
    • My posts on Steem
  • BitShares: arhag
  • GitHub: arhag
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.

Code: [Select]
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 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.

Offline Empirical1.1

  • Hero Member
  • *****
  • Posts: 886
    • View Profile
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.

Offline vikram

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

Offline Overthetop

Great to see the new functions, great work!
个人微博账号: Overthetop_万里晴空
“块链创新与创业”交流群: 330378613

Offline arhag

  • Hero Member
  • *****
  • Posts: 1214
    • View Profile
    • My posts on Steem
  • BitShares: arhag
  • GitHub: arhag
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.

Offline bytemaster

Off line trx signing infrastructure has been put in place.   

Multi sig is what toast is working on right now.   

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
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.

Offline toast

  • Hero Member
  • *****
  • Posts: 4001
    • View Profile
  • BitShares: nikolai
2 of 2 is standard multisig which is supported

Sent from my SCH-I535 using Tapatalk

Do not use this post as information for making any important decisions. The only agreements I ever make are informal and non-binding. Take the same precautions as when dealing with a compromised account, scammer, sockpuppet, etc.

Offline Rune

  • Hero Member
  • *****
  • Posts: 1120
    • View Profile
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?