Delegates please Use Sub-Accounts

[emski]

angel-delegate     =>      angel.bitdelegate
lotto-delegate      =>       lotto.bitdelegate
emski                   =>        emski.bitdelegate

I suggest:
angel-delegate     =>      angel-delegate.agsexplorer
lotto-delegate      =>       lotto-delegate.agsexplorer
emski                    =>      delegate.emski

Why should I do that?

Only if you want to run more than one spot and has votes from BM  :)

Starting Thursday I will only vote for delegates that are seeking more than one spot if they use sub-accounts.   This prevents attacks where someone registers similar but different sub-accounts.

Let me rephrase that:
Why should i use agsexplorer instead of bitdelegate ?

[dcchong]

Which command do I use to create a subaccount?


Edit:  Now I know how to create a subaccount from parent account, but how to use the sub account to produce blocks instead of the parent account?

[emski]

angel-delegate     =>      angel.bitdelegate
lotto-delegate      =>       lotto.bitdelegate
emski                   =>        emski.bitdelegate

I suggest:
angel-delegate     =>      angel-delegate.agsexplorer
lotto-delegate      =>       lotto-delegate.agsexplorer
emski                    =>      delegate.emski

Why should I do that?

[emski]

angel-delegate     =>      angel.bitdelegate
lotto-delegate      =>       lotto.bitdelegate
emski                   =>        emski.bitdelegate

[liondani]

And how we create a sub account? Example?

[bytemaster]

https://github.com/BitShares/bitshares_toolkit/wiki/Subaccounts

BitShares supports a system of account hierarchies, where one parent account may have many children, grandchildren, etc. and that parent can update children or grandchildren at will. Subaccounts are denoted by dots in their names, similar to subdomains, so if a user registers an account bob, he may register the subaccount child.bob using bob's private key. This means that only bob may register child.bob, and bob can update child.bob at any time.

Subaccounts can be recursive, so child.bob could authorize the creation of grand.child.bob if he desired. It is useful to note that bob is not able to create grand.child.bob as it is not a direct descendent; however, bob can later update a grandchild after its registration if he desires.

Naming Rules
Each component of a subaccount name must be a valid name, so in the subaccount delegate1.delegates.delegated-proof-of-steak, all of delegate1.delegates.delegated-proof-of-steak, delegates.delegated-proof-of-steak, and delegated-proof-of-steak must be valid accounts as well. This means that 1.delegates.delegated-proof-of-steak is not a valid account name, because 1 is not a valid account name. Names cannot have consecutive dots, i.e. a..b is not a valid account name.

Subaccount rules only apply in one direction, i.e. child.parent and child have no relationship, and both of these accounts may exist.

Updating Rules
A parent may perform a wallet_account_update_registration on any of its descendents, so grand.child.parent may be updated by child.parent or parent, and child.parent may be updated by parent. The parent may authorize such an update using either its active key or its owner key.

Starting Thursday I will only vote for delegates that are seeking more than one spot if they use sub-accounts.   This prevents attacks where someone registers similar but different sub-accounts.