[ANN][OC] Orangecoin ★★ POS ★★ Anon Transactions ★★ Masternodes

[Jim_Rambler]

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.

[Bloodpainter]

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

[btcMagnet]

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.

ok suppose that the only basic change we make is that the wallet adds X% OC to each trans and Mnodes pick up that X.  
We just paid em.  and we can control that amount completely.

now suppose the network advertises (maybe right on the wallet, maybe just to node clients, or even on a web page somewhere) that oc wallet software is currently paying X amount of OC (about one dollars worth) to any MN for a minimum transaction.  We would get trampled in the stampede, so that's too much, but what about 10 cents worth, or is a penny's worth enough?  idk

To nail this figure we need to know how many trans the average node will handle in say a day.
if it's 100, and we want the average node to make 10$ a day, we pay em a dime's worth. and so on.

[Jim_Rambler]

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.       

[Specialkey]

Good time for a vote 

[Specialkey]

Minting Coins for Free and Proof of Stake on sweet OC 

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

Good job orangecoin 

[Specialkey]

And here is Orangecoins You tube channel 

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

[fonzerrellie]

And here is Orangecoins You tube channel 

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

WoW that youtube channel is really coming along, clever videos

[Orangecoin]

Lol, you found my videos.

[Specialkey]

Lol, you found my videos.

Really nice information. Good work. 

[Halofire]

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

[btcMagnet]

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.        

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.

[cryptoba]

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

[Halofire]

Welcome To

ⓄⓇⒶⓃⒼⒺⒸⓄⒾⓃ

Don't forget to vote @ Cryptsy, Poloniex, and Mintpal!
https://www.cryptsy.com/coinvotes
https://www.mintpal.com/voting
https://poloniex.com/voting

Come on over to orangecoins.info/forum/ for the latest updates on everything Orange!
Stop by and check out the giveaways, Art Contest with BIGGER OC prizes, bounties, paid referral program and more...!

ONLY 2 DAYS LEFT TO ENTER THE ART CONTEST!
Don't miss your chance at 30k in prizes!

We're on IRC! #orangecoindev

Do you have something to add to Orangecoin? A service or merchandise, perhaps?
Inquire with Orangecoin or myself!

[daxiake]

so many anon coins appear,anonimity will dilute,people will not like anon soon....


oc can turn to develop gambling...

[Specialkey]

so many anon coins appear,anonimity will dilute,people will not like anon soon....


oc can turn to develop gambling...

Where you are right is the point that new features will pop up endless. To the new features will fleed the money as we see actually.
The art will be to master this features that they work  and to know which one is really interesting / usefull.
Anon is really interesting and can get very usefull. But it has to work.
With OC we have a pretty good developer team and oc himself mastered everything fabously until now.
Longterm people will recoginze this and join more and more  into OC.

The coin of future will be all time in transformation and BTC will be the dino  

[cryptoba]

This price stabilization between 350sat-450sat is for me a great sign of the market.

People just understand that something big is on the way with Oc and this the thruth !  

And, we have been talking a lot about 200 Mio coins after 41 years...

 but OC has NOW 51 Mio coins just a reminder !!!

[fonzerrellie]

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

+1 very reasonable question... I have been fonzerrellie online since like 2005 or so and have never needed to hide behind new names. I can't see any real legit reason for it.

[Specialkey]

This price stabilization between 350sat-450sat is for me a great sign of the market.

People just understand that something big is on the way with Oc and this the thruth !  

And, we have been talking a lot about 200 Mio coins after 41 years...

 but OC has NOW 51 Mio coins just a reminder !!!

+1 

[cryptoba]

so many anon coins appear,anonimity will dilute,people will not like anon soon....


oc can turn to develop gambling...

Where you are right is the point that new features will pop up endless. To the new features will fleed the money as we see actually.
The art will be to master this features that they work  and to know which one is really interesting / usefull.
Anon is really interesting and can get very usefull. But it has to work.
With OC we have a pretty good developer team and oc himself mastered everything fabously until now.
Longterm people will recoginze this and join more and more  into OC.

The coin of future will be all time in transformation and BTC will be the dino  

A lot of talk talk coins, alll those Anon coins are great on the paper, but all those coins are just using the words Anon and Masternodes, all those Devs are just switching from a coin to the other one.

Still, the possibility to choice between anonymity or not, is very important, but not so many coins will manage to do the work or will have the network to do it...

The OC strategy is about QUALITY, TRUST and TIMING...OC will beat the market.