Author Topic: Membership levels and sub-accounts  (Read 3482 times)

0 Members and 1 Guest are viewing this topic.

Offline bobmaloney

Has this issue been resolved?

Questions for similar scenarios:

1. If I own the "maloney" name and wish to make subdomains for each family member, will there be a way to do so in 2.0?

1a. Will the premium account of "maloney" be an umbrella, or will each subdomain need to purchase a premium account (ie- bob.maloney, erin.maloney, bills.maloney, savings.maloney)

2. What if I own a business? (ie- larrypage.google down to the lowly employees... thx1138.google)



A little outside the box and into the more distant future:

Could it ever be possible for a domain owner to grant permissions for subdomains to be generated where the top domain owner would not have access to the subdomains private key? (some kind of non-hierarchical structure would be required, I assume)
 
Maybe with the ability of the top domain holder to remove the subdomain if abusive, but have the assets of that subdomain sent to another predetermined account (preset by the subdomain creator) upon close by top domain owner.
« Last Edit: September 07, 2015, 08:32:18 pm by bobmaloney »
"The crows seemed to be calling his name, thought Caw."
- Jack Handey (SNL)

Offline Troglodactyl

  • Hero Member
  • *****
  • Posts: 960
    • View Profile
Maybe that's the way it should work, but that's not the way the code is now:

https://github.com/cryptonomex/graphene/blob/master/libraries/chain/account_evaluator.cpp
Quote
void_result account_create_evaluator::do_evaluate( const account_create_operation& op )
{ try {
   database& d = db();
   FC_ASSERT( d.find_object(op.options.voting_account) );
   FC_ASSERT( is_relative(op.options.memo_key) || d.find_object(op.options.memo_key) );
   FC_ASSERT( fee_paying_account->is_lifetime_member() );
   FC_ASSERT( op.referrer(d).is_member(d.head_block_time()) );
...

Offline arhag

  • Hero Member
  • *****
  • Posts: 1214
    • View Profile
    • My posts on Steem
  • BitShares: arhag
  • GitHub: arhag
Personally, I think any account should be able to pay to register new accounts, even if they can't receive any rewards for it.

Agreed. Surely that is an easy tweak. If Alice's account is not a lifetime member and it wants to register the account Bob, then the registrant of Bob's account is set to the registrant of Alice's account and the referrer of Bob's account is also set to referrer of Alice's account.

Nevermind. Apparently, that is how it already works.
The terms and conditions are kind of confusing here: https://bitshares.org/referral-program-terms-and-conditions/

Quote
Any User can also be a Registrar by create an account for a friend; however, their friends account will be configured to have the same Registrar and Referrer settings as the User. There are no referrer rewards for regular Users.
So free users can create and register new accounts. 
Thanks Xeldal.


I also think sub-accounts should inherit lifetime membership from the base account.  As it is now this is going to be far messier and more confusing than it needs to be.

Why do we have sub-accounts again? I don't quite understand the purpose of it. Apparently, in the new system there will only be one level of child accounts that will be delimited by a slash (/) not a dot. The dot will no longer have the semantics of a parent-child relationship. I'm wondering if it doesn't make sense to go all the way and just get rid of the slash and parent-child idea entirely.

It would simplify a lot. For example, what happens to the child account names when the parent account name is transferred or renamed? How do name relationships correlate to account ownership relationships. Honestly, I am not clear about that in BitShares 0.x with account names that are tied to the owner key. It only gets more confusing in BitShares 2.0. Dynamic account permissions allow for flexible and sensible ownership relationships between accounts that anyone can examine by looking at the blockchain. If the only purpose of child account names was as a proxy for those ownership relationships, then it no longer serves that purpose in BitShares 2.0.

If the purpose of child account names is as a tag modifying an account so that people who send funds to a tagged account will actually send it to another account other than the main account (for accounting or security purposes), then I can think of a more elegant way of structuring that. The slash can be repurposed for that role (again only one level deep). However, it would not be part of an account's name. There would be a map from tags (satisfying the same naming rules as regular account names, although perhaps we could allow it to start with a digit) to account IDs that is stored with the account (the account owner can modify that map at any time). For example, I may have two accounts: one with ID 100 and another with ID 101. Account ID 100 might have an account name "arhag" and account ID 101 might be nameless. Account 100 would have a map {"checking": 100, "savings": 101}. If someone sends funds to "arhag" or "arhag/checking" (or "100" or "100/checking"), their client would send the funds to account 100. If someone sends funds to "arhag/savings" (or "100/savings" or "101"), their client would send the funds to account 101.
« Last Edit: June 25, 2015, 02:50:58 am by arhag »

Xeldal

  • Guest
The terms and conditions are kind of confusing here: https://bitshares.org/referral-program-terms-and-conditions/

Quote
Any User can also be a Registrar by create an account for a friend; however, their friends account will be configured to have the same Registrar and Referrer settings as the User. There are no referrer rewards for regular Users.
So free users can create and register new accounts. 

Quote
    User - any account that has not paid a lifetime membership fee.
    Member - any account that has paid a lifetime membership fee.
    Registrar - an existing account that pays a transaction fee necessary to create new accounts.
    Referrer - A Member account, defined by Member Registrars, that receives a percentage of referral fees.

This is also confusing because it makes no mention of the Annual members.
Also this sounds like Users can hold the registrar field
Is the referrer field left blank if the registrar is only a User and not a "Member Registrar"?

How does this work? if the "User Registrar" later becomes a Member?

Are there any other docs on this?

Quote
When a user pays a $20 annual subscription fee to become an Annual Member, $10 is paid to their Referrer, $6 is paid to the nearest Lifetime Member, and $4 is paid to the Network. The Annual Member becomes its own Referrer for one year. In one year, the renewal fee is divided in a similar manner to the original annual subscription.

When an Basic Account pays $100 to become a Lifetime Member, $50 is paid to their Referrer, $30 is paid to the nearest Lifetime Member, and $20 is paid to the Network. After this point the Lifetime Member becomes its own referrer and nearest Lifetime Member and its prior Referrers no longer get any revenue from this user.

If an account’s Referrer is an Annual Member whose subscription has expired, then the Referrer fee goes to the nearest Lifetime Member.

If an Annual Member decides to upgrade to a Lifetime Member then $50 goes to his Referrer, $30 to the nearest Lifetime Member and $20 goes to the Network. Annual Members do not qualify for a 50% Cashback Referral on the upgrade fee.

how is this "nearest" lifetime member found?  Because certainly in our example before, User B after upgrading would be the nearest member to all his sub accounts and referred friends etc.
« Last Edit: June 25, 2015, 02:16:36 am by Xeldal »

Offline Troglodactyl

  • Hero Member
  • *****
  • Posts: 960
    • View Profile
Actually, after discussing with Nathan, there is no referral chain traversal.  I believe each account has two fields: one for the registrant, who must be a lifetime member, and another for the referrer, who must be at least a subscriber.  If these identities are different and the account is not a lifetime member, then fees are split between them.  Only lifetime members can register accounts, but when an account upgrades to lifetime membership it overwrites the account's registrant id with its own id.

Personally, I think any account should be able to pay to register new accounts, even if they can't receive any rewards for it.  I also think sub-accounts should inherit lifetime membership from the base account.  As it is now this is going to be far messier and more confusing than it needs to be.

Surely a free account can register new accounts? its just the registrar and referrer fields won't be updated if you don't have an upgraded account. ?  maybe I'm just using the wrong words now.

If thats true I can see how that might be a problem.

If I understand correctly, for all new free accounts created the registrant and referrer field are passed down.

The fields are replaced when the user upgrades.

As an example:
User A is a lifetime member and registers user B as a free member
User B has registrant = "A" and referrer = "A"
If B then goes on and creates a.B , b.B , c.B , i.a.B, ii.a.B , C , D , E etc  then all these accounts will have user A as both the registrar and referrer.

Then if later B decides to upgrade to lifetime member, only account B will have registrar = "B" referrer = "B"
all the other accounts would still have registrar = "A" referrer = "A" ????

I should probably read through this all again.  In some ways I can see how this might make sense but I'm conflicted.

To create a.B etc, I believe user B would need A to create the registration transaction, and then B would have to provide the additional signature on that transaction to make it valid.  This is because only life members like A have rights to create new accounts, but only B has rights to authorize subaccounts of B.

But yes, it sounds like if you don't optimally sequence your account creations and upgrades, you'd have to either pay for a life membership for each subaccount, or deal the frustration of some of your accounts having pointlessly higher fees than others.  Not the most elegant user experience.

Xeldal

  • Guest
Actually, after discussing with Nathan, there is no referral chain traversal.  I believe each account has two fields: one for the registrant, who must be a lifetime member, and another for the referrer, who must be at least a subscriber.  If these identities are different and the account is not a lifetime member, then fees are split between them.  Only lifetime members can register accounts, but when an account upgrades to lifetime membership it overwrites the account's registrant id with its own id.

Personally, I think any account should be able to pay to register new accounts, even if they can't receive any rewards for it.  I also think sub-accounts should inherit lifetime membership from the base account.  As it is now this is going to be far messier and more confusing than it needs to be.

Surely a free account can register new accounts? its just the registrar and referrer fields won't be updated if you don't have an upgraded account. ?  maybe I'm just using the wrong words now.

If thats true I can see how that might be a problem.

If I understand correctly, for all new free accounts created the registrant and referrer field are passed down.

The fields are replaced when the user upgrades.

As an example:
User A is a lifetime member and registers user B as a free member
User B has registrant = "A" and referrer = "A"
If B then goes on and creates a.B , b.B , c.B , i.a.B, ii.a.B , C , D , E etc  then all these accounts will have user A as both the registrar and referrer.

Then if later B decides to upgrade to lifetime member, only account B will have registrar = "B" referrer = "B"
all the other accounts would still have registrar = "A" referrer = "A" ????

I should probably read through this all again.  In some ways I can see how this might make sense but I'm conflicted. 

Offline Troglodactyl

  • Hero Member
  • *****
  • Posts: 960
    • View Profile
Actually, after discussing with Nathan, there is no referral chain traversal.  I believe each account has two fields: one for the registrant, who must be a lifetime member, and another for the referrer, who must be at least a subscriber.  If these identities are different and the account is not a lifetime member, then fees are split between them.  Only lifetime members can register accounts, but when an account upgrades to lifetime membership it overwrites the account's registrant id with its own id.

Personally, I think any account should be able to pay to register new accounts, even if they can't receive any rewards for it.  I also think sub-accounts should inherit lifetime membership from the base account.  As it is now this is going to be far messier and more confusing than it needs to be.

Offline sittingduck

  • Sr. Member
  • ****
  • Posts: 246
    • View Profile
This should motivate users to upgrade rather than delay. 


Sent from my iPhone using Tapatalk

Xeldal

  • Guest
I'd like to suggest that membership status should always apply to the base level account and be inherited by sub accounts, rather than applying to each account separately.  Given that the base account can replace the keys of sub accounts, each tree of accounts represents a single entity from a trust perspective, and it would be terribly inconvenient to have different fees and rewards for different accounts created for organizational purposes.

The other question is whether rewards should always be pooled to the base account, or if they should be scattered across the tree according to where they were generated.

Thoughts?

If you pay the fee to register your own sub account from your member account, you will be collecting the fees from these sub accounts anyways and the effect is the same.  There would be no need to inherit membership status as you are already inheriting the closest upline member referrer(base account).   All free-member sub accounts would essentially be full members(assuming the same user) because 80% of their fees would be collected by the full-member base account.
This is only true when the base account purchases membership before any subaccounts are created.  For any existing Genesis accounts with subaccounts, and for any new users who create subaccounts and then decide to purchase membership later, the issue still exists.

I'm not sure how genesis accounts will be handled though I assume that the account that payed the registration will be carried over to genesis and the chain of referrals should be intact. 

Any new sub accounts, post genesis, with the registration payed by the base account, doesn't matter when the base account elects to upgrade, before or after creation of sub accounts.  The sub accounts simply walk up the chain of referrers till it finds a full member.  If at a later time the base account upgrades, the sub accounts will find them as the nearest upline full-member referrer and the fees will go to them. 

Offline Troglodactyl

  • Hero Member
  • *****
  • Posts: 960
    • View Profile
I'd like to suggest that membership status should always apply to the base level account and be inherited by sub accounts, rather than applying to each account separately.  Given that the base account can replace the keys of sub accounts, each tree of accounts represents a single entity from a trust perspective, and it would be terribly inconvenient to have different fees and rewards for different accounts created for organizational purposes.

The other question is whether rewards should always be pooled to the base account, or if they should be scattered across the tree according to where they were generated.

Thoughts?

If you pay the fee to register your own sub account from your member account, you will be collecting the fees from these sub accounts anyways and the effect is the same.  There would be no need to inherit membership status as you are already inheriting the closest upline member referrer(base account).   All free-member sub accounts would essentially be full members(assuming the same user) because 80% of their fees would be collected by the full-member base account.
This is only true when the base account purchases membership before any subaccounts are created.  For any existing Genesis accounts with subaccounts, and for any new users who create subaccounts and then decide to purchase membership later, the issue still exists.

Xeldal

  • Guest
I'd like to suggest that membership status should always apply to the base level account and be inherited by sub accounts, rather than applying to each account separately.  Given that the base account can replace the keys of sub accounts, each tree of accounts represents a single entity from a trust perspective, and it would be terribly inconvenient to have different fees and rewards for different accounts created for organizational purposes.

The other question is whether rewards should always be pooled to the base account, or if they should be scattered across the tree according to where they were generated.

Thoughts?

If you pay the fee to register your own sub account from your member account, you will be collecting the fees from these sub accounts anyways and the effect is the same.  There would be no need to inherit membership status as you are already inheriting the closest upline member referrer(base account).   All free-member sub accounts would essentially be full members(assuming the same user) because 80% of their fees would be collected by the full-member base account.
« Last Edit: June 24, 2015, 04:31:12 pm by Xeldal »

Offline fav

  • Hero Member
  • *****
  • Posts: 4278
  • No Pain, No Gain
    • View Profile
    • Follow Me!
  • BitShares: fav
@Thom I see. go ahead and open a request in meta :)

Offline Thom

Yet another excellent topic of discussion that should be moved under a "Policies & Procedures" child board, where ever that works best. By the time the 30 day countdown to 2.0 launch begins topics like this will be scattered far and wide on this forum, many of which will just "fall in the cracks".

@fav - here is another one for you to move so that doesn't happen.
Injustice anywhere is a threat to justice everywhere - MLK |  Verbaltech2 Witness Reports: https://bitsharestalk.org/index.php/topic,23902.0.html

Offline Troglodactyl

  • Hero Member
  • *****
  • Posts: 960
    • View Profile
I'd like to suggest that membership status should always apply to the base level account and be inherited by sub accounts, rather than applying to each account separately.  Given that the base account can replace the keys of sub accounts, each tree of accounts represents a single entity from a trust perspective, and it would be terribly inconvenient to have different fees and rewards for different accounts created for organizational purposes.

The other question is whether rewards should always be pooled to the base account, or if they should be scattered across the tree according to where they were generated.

Thoughts?