Post
Topic
Board Announcements (Altcoins)
Re: [ANN][OC] Orangecoin ★★ POS ★★ Anon Transactions ★★ Masternodes
by
Bloodpainter
on 13/06/2014, 06:48:50 UTC
Ok I'm on my moblie but will be at my 80+ spreadsheets in a little while here.

btcMagnet : what do you feel a comfy amount in $ is to pay MN and I will work the numbers out. I'm being for really here, do you like $50k or $30k what do you feel is a good number? Just a rough number so I can work out the grid for use all..
i don't think i could divine or dictate these numbers any better than u could,
 but i do know how to get them.

first we don't mind overpaying a little the first few months, but if were going to pay in orange
we have to be able to control the amount.  eventually we pay just enough to keep em lining up for a MNs, but we don't just throw tons of money away for decades.

idk, so what does it cost to set up/and maintain an MN?  we want to be generous, especially in the beginning. this has to work.

if someone invests say $1000 or a couple of btc for a year, we should probable arrange at least a $300 to $500 (30-50%) profit for the first 6 months or so, but even for that period we would need to control OC amounts, unless we promise btc or USD equivalents (which would also vary OC amounts)

i think there is also a limit to the number of MN we will need at a given moment based on historical user traffic ratios,
50% more than we seem to need would be one thing, while 10x what we need would be something else.

so we want to overpay at first because this service has to be first class all the way, and we want to always have a fluent number of nodes, ie more than we need by some comfortable %, say 15-30% maybe.
 
but we need a way to control the OC payouts down the road, we simply cannot make long range payment plans in a currency we know is going up dramatically, but not how much, this would be self destructive.

yeah halo if dark needs any piece of wise-up intel, it's that 4 mil figure, which is almost 10% of their cap
so every ten years or so these simple trans stations get the whole bleeding cake

anyway we need control down the road, no getting around it, that is the mistake dark made, and we don't need to repeat it.

i think a tranpay (earlier post) method might solve all the problems with relatively little programming,
and it would only cost a fraction of the blind payment plan.  But anything that allows the market to function naturally would work.




Cool let me work out a model for you based on a % of coins in circulation, giving a stable amount in MN so that transaction can go through. Seeing how we have no idea what amount of transaction will go through MN we will just use a % of total coins out there.
k sounds great.  hmmmm notice also that in transpay, wallet software could subsidize user transfers , ie the network adds as much or little OC as wanted; (these coins being pealed from last pos as halo suggested) this % of subsidy being either keyed in periodically, or better yet automatic ie derived by computation. So if we need more MN support to maintain our lofty reliable service standards, then the software bumps the price, if we have more nodes than we want, it lowers.  Such adjustment could be severe if needed, especially early on, but i tend to think eventually they will steady down.


Good point should address this whole "software" wallet mod. Servers take time to set up, while I get where your coming from. Bumping to price or any other bidding, just will not work. Like you said we must have this whole system running as smooth as possible. And like you also said to some extent must over pay for it to run with a buffer. Now I feel like your looking at this like in a time of need MN will just run quickly to be added. We need a solid % of the total coins in MN earning an amount just a little higher then if they had it in a wallet staking. So that we are not trying to send transactions and waiting for the MN number to pick back up.

Sorry to quote so much, but would there be a way to have a scalable MN payment system basing it off of total coins in existence and # of masternodes in existance at any one time?  Hate to bring up examples of other coins, but say maybe similiar the PoS system of VRC, but in masternode payments, using the variables I was describing?

Perhaps this wouldn't be implemented right away (as I'm sure you guys are damn near done with the masternode coding/ percentages), but with a later revision perhaps?

This would definitely be a unique idea, would get orangecoin some serious looks from everyone....