Topic: [ANN][OC] Orangecoin ★★ POS ★★ Anon Transactions ★★ Masternodes - page 73. (Read 209551 times)

BtcMagnet, you are not at all new to Bct, so I am interested to know which other coins you have been supporting ?

Why did you create a new account especially for OC ?

It is no attack, I am just curious

We have to build in some method for discovering the market value of the service, ie what the job is worth.  
In other words if a given mnode handles say 1% of our traffic (on say an average month) do we buy em (with OC) a hamburger, a hat, or a hummer?

The only way to find out is to offer them something and see if they show up, that's market price discovery.
(and in the beginning we have to make sure that this offer is more than enough)

If ppl are lining up to do this for say a hamburger a week (ie what a hamburger cost today if you paid in OC), were good.
if not lining up, we offer a hat, or 2 hats...
no line yet?...  20, 100, or 200 hats, then a hummer, whatever it takes.

But long before we get to the hummer or even 200 hats, somebody will take the job.
because they decided there is enough profit in it for their time, investment, and trouble.

So in order to perceive the market, someone, or thing (cpu), has to bid, either the Mnodes, the devs, or the wallets (i think it should wallets).
At some point, with all our relevant commodity prices in flux, somebody has to offer a new price (this offer being a query to the market), based on historical time/investment for the task, the market will react to the new price (this reaction being the market's answer to the query).

Periodically (hourly, daily) somewhere in the system one of the three available entities (wallet, devs, MN operators) has to rediscover the value (purchasing power) of transfer cost.  This is what takes the blindness out of our payment play.

This entity will look at the value of oc and try to readjust the amount offered to equal the amount of purchasing power we currently wish to pay for the task.

The amount of purchasing power we award/offer for a given node depends on how much more, or less, Mnode availability the market needs to stay vibrant.

In other words, do we need to pay an mnode operator the price of a hamburger, a hat, or a hummer for say every month of working for us? Time will tell very quickly and updates will be built into this system cycle.

So this price setting entity also needs to be able to perceive the condition of the trans network at any time:
Is the network satisfactory?  Are there enough nodes available for smooth transfer?  If 100 wallets tried to make transfers in the next 10 min would there be enough MN resources?

If this entity perceives the network as adequate, the price/offer stays the same. if the network appears deficient, the entity offers more, if there's a substantial surplus of node availability, the entity lowers the offer.

With this offer now standing, the market responds, answering the question "is this enough?" if the answer is yes, nodes will want to work and our network availability checks will show an adequate trans availability during these periods between price adjustments.  

Notice that these price awards could change every five minutes if needed. The value of OC and 'the cost/time involve with the task' are both subject to change, our system has to compensate for these two fluctuation, oc being the more volatile obviously.

In this (wallet entity) approach the market is responding to our standing [but changing] offer, as opposed to us responding to their multiple bids, which i think is cleanest.

crazy lady in videos haz bitcoinz for you....

Really nice information. Good work. 

Lol, you found my videos.

WoW that youtube channel is really coming along, clever videos

And here is Orangecoins You tube channel 

https://www.youtube.com/channel/UC8G0FS6MG1lJuT2UJOeClqQ

Minting Coins for Free and Proof of Stake on sweet OC 

https://www.youtube.com/watch?v=-mwlKIS9L_8

Good job orangecoin 

Good time for a vote 

Ok while playing with a few ways to implement this I can see I need to do more testing on this, I really don't want to shoot you down at the first sign this won't work. However this system that has been purposed, leaves us very vulnerable for attacks. The amount of MN just cant be this easy to manipulate, the amount of MN must remain higher then the request load at all time as to not allow attacks. Also this number can't be a moving variable based of a public demand so easily changed. This is why the price of 2000 OC has been set with a fixed compensation (reward %) as a way to control how many MN there are. Bc that number can't be moved up and down easily. I will work more on this to see if there is a way to secure it with some sort of almost Diff re-target equation. I'm still convinced that set amounts with stable long gradual number fluctuations is our most secure way to do this.       

Oh first when rereading I saw your mistake, MN will NOT get PoS while they are MN they are rewarded out of the MN reward. It is not a penalty, your misunderstanding here a little. MN earn a separate reward. Sorry for the confusion, this has been said a few times here. This was the whole point of finding their %

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.

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..

Well the darkcoin is not looking at this the weird way is has been manipulated in these post. PoS can be done for small rewards just the same. They only reasone these numbers are so high is because the coins prices is proportionately higher as well. I mean we don't go lowering PoW rewards based on the coins price, bc just like MD we know there will be more miners the spread the reward thinner. The fact that we are looking at this large amount and not saying, more MN will be put up or that PoS will be 10x higher is just wierd and Im not sure how else to say it.

curious to see what darkcoin says about 4 million. lol....