[poll] bug found Should the committee use the committee-trade account to trade

[Thom]

you guys are making such a small task so complicated.

just put up a sell order at +15% for all bitassets and leave it there.
It doesn't need adjusting or a bot or discussion. you are making a mountain over a mole hill. simple transparent accounting is more important than  selling at the perfect price.

No JC, IT IS COMPLICATED! You say it's not but look at the evidence to the contrary:
- Lack of people participating in these threads or polls
- # of questions and length of responses to them
- the number of elements (fee pool, -trade accounts, bug or not, multisig, purpose of accounts)

The fact you can see the relationship between all of these things clearly does not mean others do. I'm not spring chicken and this is just not as simple as you seem to portray it, nor simple based on the multiple threads discussing all of these elements and factors.

[JonnyB]

you guys are making such a small task so complicated.

just put up a sell order at +15% for all bitassets and leave it there.
It doesn't need adjusting or a bot or discussion. you are making a mountain over a mole hill. simple transparent accounting is more important than  selling at the perfect price.

[xeroc]

Thx xeroc for the explanation. From your affirmative response to the second statement of mine you quoted, then we're not talking about a bug here. We're talking about how to resolve a practical problem the committee has in liquidating / using / trading committee account assets.

I don't really see a practical problem. As it is now, it is pretty much
a self-governed sub-committee that can be replaced entirely by the
(super) committee while the subcommittee itself can reach consensus
about who should be part of the committee-trade account.
It's almost an advantage in this scenario.

I'm trying to wrap my head around this issue. There are several aspects scattered across multiple threads. Puppies has explained the problem concerning the sale of assets and timing constraints, thus the need for a committee-trade account to get around that. Sounds like the difficulties due to committee members living in different time zones coupled with the volatility of the assets the committee wants to trade / liquidate / utilize  and the shareholder approval process makes using the original committee account difficult if not impractical.

The committee-account has a minimum preview period of 1h currently. That
means it can only react to markets within 1h. This 1h delay should
eventually be way higher (like 1 day to 1 week) just to let shareholders
see what is coming next and have them rethink their voting position
before a proposal is executed on chain. That way, shareholders have the
last say and can vote out approving committee-members just before
proposals get executed.

The committee-trade account does not have this limitation and can
execute proposals right away if they are approved by sufficiently many
members. It can surely not change any blockchain parameters though

However, there is a drawback here namely, that the committee-account
cannot peg to USD denoted fees with high accuracy simply because the
proposals need at least the review period.
IMHO, we need to find a solution for that issue eventually .. (before we
increase the review period)

The new committee-trade account must use a different set of accounts from that in the original account to get around the problem. If that is the case and the committee has reached consensus on the altered permissions, then the only issue is making sure the shareholders at large agree with those changes and approve the new authority structure. This seems to be a key consideration. It has the effect of changing the approval accounts dictated by shareholder voting to a different (perhaps only a subset) set of accounts on the -trade account. If all the same signatories were in both accounts the problem would still remain.

If shareholders do not agree with the members of that committee-trade,
they could simply create a proposal to replace those members and "force"
the committee-account to approve the proposal. That way the shareholders
have a say over the committee-trade account due to the fact that the
committee-account is the sole owner of committee-trade.
Makes sense?

I think this needs a thorough examination, and I see no reason to rush into a decision.

A few questions I still have:

1) How do these various assets make their way into the committee account? Where do those funds originate?

Those funds are profits from the fee pool currently and later will also
be profits from trading with smartcoins (0.10% if the current fee
schedule proposal is approved). Those funds need to be claimed by the
committee-account and need to be transfered to the committee-trade
account.
Another spot where shareholders could disagree and unvote every
committee-member that approves any of those two proposals (or a combined
proposal)

2) What is the intended purpose of those funds? Is that left entirely up to the committee?

The current committee has decided that those funds belong to the
shareholders (they are essentially profits from bitshares' products) and
thus should be exchanged back into BTS to
a) refill the fee pool and
b) put them back into the reserves

Elsewhere I asked about the fee pool and how that fits into the picture. I'll review that thread for those answers.

Currently, the core exchange rates for smartcoins is above the feed
price. that means that every one that pays the fees in USD or EUR ..,
pays some 5% extra to the fee pool to exchange into BTS.
Those 5% extra are then part of the accumulated fees from the USD, EUR
asset and those are the fees we are currently talking about.
Later we will probably also see market fees (0.10%) that are collected
there as well.

When I think about the primary purpose of the committee, that being to adjust fees and policies related to fees, or blockchain parameters such as the maintenance period, I don't see how a committee account is required to do that. I just don't recall that element or it's purpose.  Yet that is what seems to be driving this problem to the fore.

The point was that the smart assets accumulated way over 7k USD and this
directly results in a high premium for USD since some of the liquidity
was locked up in the accumulated fees.
We (read: the current committee) also felt the need to provide some
liquidity with those funds.
We even discussed shorting USD with the accumulatd BTS but decided to
not take the risk. So, the current committee is not speculating with the
profits made from the products.

[Thom]

Thx xeroc for the explanation. From your affirmative response to the second statement of mine you quoted, then we're not talking about a bug here. We're talking about how to resolve a practical problem the committee has in liquidating / using / trading committee account assets.

I'm trying to wrap my head around this issue. There are several aspects scattered across multiple threads. Puppies has explained the problem concerning the sale of assets and timing constraints, thus the need for a committee-trade account to get around that. Sounds like the difficulties due to committee members living in different time zones coupled with the volatility of the assets the committee wants to trade / liquidate / utilize  and the shareholder approval process makes using the original committee account difficult if not impractical.

The new committee-trade account must use a different set of accounts from that in the original account to get around the problem. If that is the case and the committee has reached consensus on the altered permissions, then the only issue is making sure the shareholders at large agree with those changes and approve the new authority structure. This seems to be a key consideration. It has the effect of changing the approval accounts dictated by shareholder voting to a different (perhaps only a subset) set of accounts on the -trade account. If all the same signatories were in both accounts the problem would still remain.

I think this needs a thorough examination, and I see no reason to rush into a decision.

A few questions I still have:

1) How do these various assets make their way into the committee account? Where do those funds originate?
2) What is the intended purpose of those funds? Is that left entirely up to the committee?

Elsewhere I asked about the fee pool and how that fits into the picture. I'll review that thread for those answers.

When I think about the primary purpose of the committee, that being to adjust fees and policies related to fees, or blockchain parameters such as the maintenance period, I don't see how a committee account is required to do that. I just don't recall that element or it's purpose.  Yet that is what seems to be driving this problem to the fore.

[xeroc]

However, neither of you really clarified the issue of whether it's a bug
or not for the active participants to change the multisig account
characteristics.

The only thing that is now possible, that wasn't documented as such is
that the active authority can change the active authority.
They can still not change the owner authority.
Owner authority can still overwrite any other authority.

Everything that changes is that the active authority has slightly more
power which could be seen as a good thing if you think of the owner key
as a cold-storage key.
For instance, you have an account on your mobile phone which has a cold
owner key. Now you can change phones and migrate to a new phone without
even exchanging private keys at all and without the need to take
your owner key out of coldstorage.

From an attackers perspective not so much changes (assuming the owner has
access to its owner key) because the theft of the active key can result
in a loss of all funds in any case.

The only thing that really changes is if someone has lost his owner key.
Then, the loss of the active key would allow an attacker to take owner
ship of the account.

Correct me if this is wrong, but the only difference between active keys
and owner keys is that owner keys can change the active keys. Aside from
that they are equal. If that is true then the active key holders are
indeed allowed to alter the account characteristics.

Yes.

Either the active keys or owner keys could be used by a witness account
to sign blocks for example. I know that is definitely how it was in BTS
1. However, regarding multisig accounts it would make sense if ONLY the
owner keys could alter the account characteristics. I'm afraid the
manual is rather short on details concerning the distinctions, it only
describes the general difference.

Based only on the general description, it looks like a bug to me. Based
on what puppies said, who holds the owner keys for the multisig
committee accounts?

there are no "keys" involved in the multi-sig accounts.
Essentially, an authority can consist of
* pubkey
* bts address (used for stealth), and
* account_ids
A multisig account that contains account_ids as authority (i.g. the
committee-account) requires approval by the active (or owner) keys of
the corresponding account_ids.

[cube]

bump.

To all shareholders, proxies:

Your input is needed.

[puppies]

There is no owner permission for the committee-account.  The owner of committee-trade account is the committee-account.

[Thom]

Thax abit. Xeroc is really moving along on those docs. Much progress since I last looked.

And yes, Owner key should be what puppies was referring to. If not he better switch his wallet keys 

However, neither of you really clarified the issue of whether it's a bug or not for the active participants to change the multisig account characteristics.

Correct me if this is wrong, but the only difference between active keys and owner keys is that owner keys can change the active keys. Aside from that they are equal. If that is true then the active key holders are indeed allowed to alter the account characteristics.

Either the active keys or owner keys could be used by a witness account to sign blocks for example. I know that is definitely how it was in BTS 1. However, regarding multisig accounts it would make sense if ONLY the owner keys could alter the account characteristics. I'm afraid the manual is rather short on details concerning the distinctions, it only describes the general difference.

Based only on the general description, it looks like a bug to me. Based on what puppies said, who holds the owner keys for the multisig committee accounts?

[puppies]

I for example, do not have the active key of dele-puppy loaded into any wallets.

I think you mean owner key.

Quite right.  thanks abit.

[abit]

I for example, do not have the active key of dele-puppy loaded into any wallets.

I think you mean owner key.

[puppies]

@Thom The committee-account does not have an owner.  The committee-account active authorities are determined by voting. 

The owner key is not the key that registered the account.  It is supposed to be the key that is used to adjust the active keys.  I for example, do not have the active key of dele-puppy loaded into any wallets.  If someone hacked one of my servers and got my active key, I should be able to use that offline owner key to change my active key and lock the attacker out. 

[abit]

This is a fundamental question, and one I would normally go to the "owner's manual" to get a definitive answer about. How is the design supposed to work? Unfortunately no such "manual" exists that I know of.

Here is the manual: http://docs.bitshares.eu/bitshares/user/account-permissions.html

[Thom]

Not truly certain I understand the issue. There are 2 aspects:

1) is it a bug for the active authority of a multisig account to be able to change the active authority?
2) which account (committee-trade vs some other account) should be used until #1 is settled?

As for #1, to say its a bug to allow the account's characteristics to be altered by the active account participants presumes a higher authority than those active account holders. I may be wrong but I believe the BitShares account ownership model is a strict hierarchical model, and every single account (except maybe some root account at the top of the hierarchy) has an owner, which I presume is the account that performs the registration. Again, this is not real clear to me.

Presumably multisig accounts are no different than any other in terms of this ownership hierarchy. The question seems more related to registrars, b/c that is a class of ownership that creates accounts for other parties to use. I'd hate to think that my BitShares accounts have an "overlord" owner than has more control over my accounts than I do.

On the other hand if I wish to create an account and give the owner keys to it away (which I believe is the way registrars work - I hope) I should have zero control over what happens to it from that point on.

This raises the question of "who owns" the committee account? The committee or someone else? If the answer is CNX it is not the right answer IMO. The whole point of a multisig account to mitigate the risk of an individual or defined minority from controlling the account. If CNX is STILL in control then they not demonstrating any confidence in the DPoS model they implemented and the "training wheels" are STILL bolted on.

This is a fundamental question, and one I would normally go to the "owner's manual" to get a definitive answer about. How is the design supposed to work? Unfortunately no such "manual" exists that I know of.

[puppies]

Ill create the proposal later.  If someone beats me to it that would be just fine.

[Bhuz]

Let's use the poll result.

It is a yes, use the committee-trade