Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
I wouldn't be interested in recording or making music. I would rather be some what of a spokesman and helping artists & labels hop on board.
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()) );
...
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.
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'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.
Hello!
First time poster/lurker here, going to get strait to the point: Are you guys hiring?
This would be an absolute dream job for me working with Peertracks and the team.
Music and bitcoin are both my passion. I went to school for recording/engineering, I produce music, and keep up to date with the current music trends. I also freelance graphic design for the cryptosphere doing graphics for altcoins and websites. I have fell inlove with bitcoin and the blockchain since I first discovered it in 2013. I am a strong believer in the use of the blockchain and all the endless and new possibilities it has to offer.
I would love to help artists start using Peertracks and realizing its potential to be huge and putting control and profits back into their hands.
I currently work a 9-5 I'm not in love with. It gets me by financially but not emotionally. I would love to take my passion for music, bitcoin, and the blockchain and put it to good use everyday for a project I truly believe in.
-Chris
Core command line client and basic CLI wallet will be available.
Will it be possible to serve the website from a local daemon but still have it connect using websockets to the third-party wallet host server?
I really don't want my only GUI lightweight solution available at launch to risk my private keys because of a server compromise or SSL certificate compromise.
Yes
Also, we must also let go in the belief in authority...which may take a few centuries.
Until then...Vote with your feet!
Awesome!
Although I seriously doubt ridding humanity of the belief in authority will happen in my lifetime, I think it could happen faster than a few centuries once momentum in the paradigm shift begins to move in that direction. You're right tho, in how deeply entrenched in our psyche it is. Here's hoping Larken Rose will live a long and fruitful life!
People went into the Wild West in search of freedom from authority.
The first thing they found they needed was a sheriff.
We will wind up needing a digital sheriff.
Order book sharing between exchanges? I could put up a buy order on exchange A and get it filled by someone selling on exchange B?
It's more complicated than that:
* You deposit USD on CCEDK
* You trade it for CCEDK.USD on CCEDK
* You withdraw CCEDK.USD to your bitshares wallet
At this point you can trade CCEDK.USD for any other token on the bitshares DEX. So in order for you to trade against another exchange's tokens, you'd need to have a market between (or a route to) CCEDK.USD and the other token.
</educated guess>
