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

[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  

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.

+1 

[btcMagnet]

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

this is a fair question
but sadly i cannot answer it without defeating the purpose of creating the new handle
but i do promise that my reason is nothing sinister

im holding a few legacy coins like most ppl, but my focus now is on the coin i believe is currently most seriously undervalued,
it's being overlooked for several reason which i clearly, and perhaps uncommonly, understand.

the undervalue ratio of this coin puts it lengths ahead of all other investment contenders at the moment
(like Secretariat at Belmont actually)

it's bad business however for me to reveal the name of this coin
since i plan on buying more before the price goes vertical....

but sometimes i throw a little money away just to make a greater point,
so i'll break my own rule and tell you the name before i should
it's OrangeCoin
she just has the far brightest future in sight 

[fonzerrellie]

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  

the old credits "CR" (seems to be completely dead now) had a really great idea for a full on poker site, like one of the big legit ones like partypoker or pokerstars but for their crypto instead, I thought it was an awesome idea and have quite a few friends that make good money on poker sites so it would make it easy to introduce them to crypto's through it.

 EDIT: CR wanted it to be strictly CR.

 the one flaw I saw in the "cr" poker site I saw (or major improvement that could be made) If we had one made or someone makes one for OC yes the main focus should be on OC with the majority of tables dedicated to OC but my thought was to have a couple for btc to attract people as well as having weekly voting on a guest coin, the winning coin would receive a few tables for the weekend or maybe the whole week. the supporters of guest coins would appreciate the attention as well as opening OC to even more people... win win.

[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

this is a fair question
but sadly i cannot answer it without defeating the purpose of creating the new handle
but i do promise that my reason is nothing sinister

im holding a few legacy coins like most ppl, but my focus now is on the coin i believe is currently most seriously undervalued,
it's being overlooked for several reason which i clearly, and perhaps uncommonly, understand.

the undervalue ratio of this coin puts it lengths ahead of all other investment contenders at the moment
(like Secretariat at Belmont actually)

it's bad business however for me to reveal the name of this coin
since i plan on buying more before the price goes vertical....

but sometimes i throw a little money away just to make a greater point,
so i'll break my own rule and tell you the name before i should
it's OrangeCoin
she just has the far brightest future in sight 

Nice answer,+1 

[Halofire]

keep voting!

[jamestown2035]

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  

the old credits "CR" (seems to be completely dead now) had a really great idea for a full on poker site, like one of the big legit ones like partypoker or pokerstars but for their crypto instead, I thought it was an awesome idea and have quite a few friends that make good money on poker sites so it would make it easy to introduce them to crypto's through it.

 EDIT: CR wanted it to be strictly CR.

 the one flaw I saw in the "cr" poker site I saw (or major improvement that could be made) If we had one made or someone makes one for OC yes the main focus should be on OC with the majority of tables dedicated to OC but my thought was to have a couple for btc to attract people as well as having weekly voting on a guest coin, the winning coin would receive a few tables for the weekend or maybe the whole week. the supporters of guest coins would appreciate the attention as well as opening OC to even more people... win win.

Maybe talk with sealswithclubs.eu about adding oranges.

[btcMagnet]

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

excellent point, and i've reprinted some rel posts below:

The most conservative aspect of my estimates is the fact that I used BC as a comparison,
which is not even an anon coin. (could have used dark you know, even when compensating for the difference in total number (12 to 1) this bumps the 80k figure to well over 300k per year for the service in question)

And here's a free tip... any coin that is not anon is going to be very seriously disadvantaged when ppl generally realize that non-anon coins (including btc btw) leave a double-wide trail engraved in digital stone.
because... At least half the wealth flowing into cc is trying to escape being tracked somewhere down the road.

i wonder how many have noticed that when comparing BC to OC, BC has more coins (almost 50% more currently), and this will be true for many years to come.  OC has a relatively low rate of new coin creation which is obviously being overlooked by the market, but eventually the laws of S+D will define these smaller numbers with price adjustment, and you wanna be up to your bloody eyeballs in orange when this happens.

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

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.

Ok I'm going to try and explain to you another way because your making to much work out of this. I have decided just to trust your word about your intentions and will try to explain this all to you. You must first stop looking at this like we are paying on a per-transation bases for this, and that its a service. It is only a diffrent way to send your coins, that takes a certain set up to do such. MN are no more a service then PoS, so enough look at it like a service.

When a MN is set up all it is doing is SHIFTING coins from hot active wallets to locked wallets. This is not some 3rd party entity, these is our own coins just in a different type of wallet that is it. Ok time for the math

year 1 if you have a wallet with 2000 OC in it and your sitting there looking at it thinking should I SHIFT my OC to a MN. ANYONE would say let me do the math and see if it is worth doing or not. Ok 2000 OC in the first year if stacked on time, stacks 24.333 time every 365 days. So 2000 OC earn 400 OC PoS in that first year. Now any investor such as yourself would simply go look at the number of MN then divid the reward amount and add the cost of the server. They get the number X and if X is less then 400 OC then they just keep the OC in their wallet.

If the server cost are around 2000 OC (for 2000 OC to = $60, price/OC need = $0.03) then there can be
416 MN.

(the more OC SHIFTED in to MN the more EVERYONE stacking PoS makes)
(the more MN available the more stable and secure the MN system is to attack, The more MN the more random the selection of which MN will process the transaction.)

So let us look at what this means, to have an SELF adjusting system like this.

So the number of MN will be controlled by what the 2000 OC would have stacked PoS + server cost ($60) divided by rewards paid to MN. Also there will be a new PoS amount bc the MN coins no longer get PoS and that leaves more for the coins left in PoS. Remember the 2000 OC would only get 400 with out MN.
 
Value of OC in $        # of MN        new PoS
 $0.03                         416               406.7
 $0.08                         869               414.4

And so on...

 You keep adding $ in to this and only saying that MN are a service, and not referring to PoS as a service as well as leaving out PoS earnings in $.

YOU need to understand that the amount of OC that will be given out to MN will only me slightly higher then PoS earnings on the same 2000 OC. And this will all happen on its own, without complex wallets and bidding. 

[jamestown2035]

I was under the impression that the first year I will stake 20% independent of what anyone else does, or are you saying if fewer people don't stake this year then I could receive 50%?  I would imagine the MN not staking their 2000 would just increase the POS length until all coins have finally been released.

[Jim_Rambler]

I was under the impression that the first year I will stake 20% independent of what anyone else does, or are you saying if fewer people don't stake this year then I could receive 50%?  I would imagine the MN not staking their 2000 would just increase the POS length until all coins have finally been released.

yeah I think my spreadsheet calculated it by dividing it by 41 years more like an avg. sry

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

Ok I'm going to try and explain to you another way because your making to much work out of this. I have decided just to trust your word about your intentions and will try to explain this all to you. You must first stop looking at this like we are paying on a per-transation bases for this, and that its a service. It is only a diffrent way to send your coins, that takes a certain set up to do such. MN are no more a service then PoS, so enough look at it like a service.

When a MN is set up all it is doing is SHIFTING coins from hot active wallets to locked wallets. This is not some 3rd party entity, these is our own coins just in a different type of wallet that is it. Ok time for the math

year 1 if you have a wallet with 2000 OC in it and your sitting there looking at it thinking should I SHIFT my OC to a MN. ANYONE would say let me do the math and see if it is worth doing or not. Ok 2000 OC in the first year if stacked on time, stacks 24.333 time every 365 days. So 2000 OC earn 400 OC PoS in that first year. Now any investor such as yourself would simply go look at the number of MN then divid the reward amount and add the cost of the server. They get the number X and if X is less then 400 OC then they just keep the OC in their wallet.

If the server cost are around 2000 OC (for 2000 OC to = $60, price/OC need = $0.03) then there can be
416 MN.

(the more OC SHIFTED in to MN the more EVERYONE stacking PoS makes)
(the more MN available the more stable and secure the MN system is to attack, The more MN the more random the selection of which MN will process the transaction.)

So let us look at what this means, to have an SELF adjusting system like this.

So the number of MN will be controlled by what the 2000 OC would have stacked PoS + server cost ($60) divided by rewards paid to MN. Also there will be a new PoS amount bc the MN coins no longer get PoS and that leaves more for the coins left in PoS. Remember the 2000 OC would only get 400 with out MN.
 
Value of OC in $        # of MN        new PoS
 $0.03                         416               406.7
 $0.08                         869               414.4

And so on...

 You keep adding $ in to this and only saying that MN are a service, and not referring to PoS as a service as well as leaving out PoS earnings in $.

YOU need to understand that the amount of OC that will be given out to MN will only me slightly higher then PoS earnings on the same 2000 OC. And this will all happen on its own, without complex wallets and bidding.  

a free live market is the only way to avoid this ludicrous overpaying were talking about
and no free market sys is possible without some form of 'price discover'
which your approach doesn't seem to be including
this 'price discover' is your only eye on the changing market,
without it you're blind, ie in the dark (pun violation.. sry)

You may be making to many suppositions about what we need to do here.
i believe we only need to establish a flawless anon transfer network.

if were going to escape darks overpaying we have to color outside the lines now.
[and notice orange was always the brightest crayon in the box lol]
we need a different approach, new ideas, this is a time for innovation.

My suggestion is NOT likely to be the best solution possible,
so improve on it, come up with a new one, (which includes price discovery)

with 'wallet controlled transpay' the software intrusion appears minimal, less complicated than what was being proposed.
im sure there are a thousand ways that would work, it's not rocket science ya know, just a moon shot lol.

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

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.

Ok I'm going to try and explain to you another way because your making to much work out of this. I have decided just to trust your word about your intentions and will try to explain this all to you. You must first stop looking at this like we are paying on a per-transation bases for this, and that its a service. It is only a diffrent way to send your coins, that takes a certain set up to do such. MN are no more a service then PoS, so enough look at it like a service.

When a MN is set up all it is doing is SHIFTING coins from hot active wallets to locked wallets. This is not some 3rd party entity, these is our own coins just in a different type of wallet that is it. Ok time for the math

year 1 if you have a wallet with 2000 OC in it and your sitting there looking at it thinking should I SHIFT my OC to a MN. ANYONE would say let me do the math and see if it is worth doing or not. Ok 2000 OC in the first year if stacked on time, stacks 24.333 time every 365 days. So 2000 OC earn 400 OC PoS in that first year. Now any investor such as yourself would simply go look at the number of MN then divid the reward amount and add the cost of the server. They get the number X and if X is less then 400 OC then they just keep the OC in their wallet.

If the server cost are around 2000 OC (for 2000 OC to = $60, price/OC need = $0.03) then there can be
416 MN.

(the more OC SHIFTED in to MN the more EVERYONE stacking PoS makes)
(the more MN available the more stable and secure the MN system is to attack, The more MN the more random the selection of which MN will process the transaction.)

So let us look at what this means, to have an SELF adjusting system like this.

So the number of MN will be controlled by what the 2000 OC would have stacked PoS + server cost ($60) divided by rewards paid to MN. Also there will be a new PoS amount bc the MN coins no longer get PoS and that leaves more for the coins left in PoS. Remember the 2000 OC would only get 400 with out MN.
 
Value of OC in $        # of MN        new PoS
 $0.03                         416               406.7
 $0.08                         869               414.4

And so on...

 You keep adding $ in to this and only saying that MN are a service, and not referring to PoS as a service as well as leaving out PoS earnings in $.

YOU need to understand that the amount of OC that will be given out to MN will only me slightly higher then PoS earnings on the same 2000 OC. And this will all happen on its own, without complex wallets and bidding.  

a free live market is the only way to avoid this ludicrous overpaying were talking about
and no free market sys is possible without some form of 'price discover'
which your approach doesn't seem to be including
this 'price discover' is your only eye on the changing market,
without it you're blind, ie in the dark (pun violation.. sry)

You may be making to many suppositions about what we need to do here.
i believe we only need to establish a flawless anon transfer network.

if were going to escape darks overpaying we have to color outside the lines now.
[and notice orange was always the brightest crayon in the box lol]
we need a different approach, new ideas, this is a time for innovation.

My suggestion is NOT likely to be the best solution possible,
so improve on it, come up with a new one, (which includes price discovery)

with 'wallet controlled transpay' the software intrusion appears minimal, less complicated than what was being proposed.
im sure there are a thousand ways that would work, it's not rocket science ya know, just a moon shot lol.

I can no longer follow you down this rabbit hole that you have cleverly designed to distract me. I'm turning all my attention to the code. I thought on some level I could help everyone see our vision. The specs are set and the code is being written, I encourage you to buy while the price is low.         

[Halofire]

Vote!

[Byter88]

Downloaded a windows wallet and keeps getting stuck around half way, i already cleared my appdata roaming file, and still gets stuck, anything else i can do?

[Bloodpainter]

Jim,
   Does this mean you guys are looking into a auto adjusting MN payment system?  That would be quite a new idea/system, and if so should be announced if you guys are looking into this.  Would cause some serious investment...
   

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

Ok I'm going to try and explain to you another way because your making to much work out of this. I have decided just to trust your word about your intentions and will try to explain this all to you. You must first stop looking at this like we are paying on a per-transation bases for this, and that its a service. It is only a diffrent way to send your coins, that takes a certain set up to do such. MN are no more a service then PoS, so enough look at it like a service.

When a MN is set up all it is doing is SHIFTING coins from hot active wallets to locked wallets. This is not some 3rd party entity, these is our own coins just in a different type of wallet that is it. Ok time for the math

year 1 if you have a wallet with 2000 OC in it and your sitting there looking at it thinking should I SHIFT my OC to a MN. ANYONE would say let me do the math and see if it is worth doing or not. Ok 2000 OC in the first year if stacked on time, stacks 24.333 time every 365 days. So 2000 OC earn 400 OC PoS in that first year. Now any investor such as yourself would simply go look at the number of MN then divid the reward amount and add the cost of the server. They get the number X and if X is less then 400 OC then they just keep the OC in their wallet.

If the server cost are around 2000 OC (for 2000 OC to = $60, price/OC need = $0.03) then there can be
416 MN.

(the more OC SHIFTED in to MN the more EVERYONE stacking PoS makes)
(the more MN available the more stable and secure the MN system is to attack, The more MN the more random the selection of which MN will process the transaction.)

So let us look at what this means, to have an SELF adjusting system like this.

So the number of MN will be controlled by what the 2000 OC would have stacked PoS + server cost ($60) divided by rewards paid to MN. Also there will be a new PoS amount bc the MN coins no longer get PoS and that leaves more for the coins left in PoS. Remember the 2000 OC would only get 400 with out MN.
 
Value of OC in $        # of MN        new PoS
 $0.03                         416               406.7
 $0.08                         869               414.4

And so on...

 You keep adding $ in to this and only saying that MN are a service, and not referring to PoS as a service as well as leaving out PoS earnings in $.

YOU need to understand that the amount of OC that will be given out to MN will only me slightly higher then PoS earnings on the same 2000 OC. And this will all happen on its own, without complex wallets and bidding.  

a free live market is the only way to avoid this ludicrous overpaying were talking about
and no free market sys is possible without some form of 'price discovery'
which your approach doesn't seem to be including
this 'price discovery' is your only eye on the changing market,
without it you're blind, ie in the dark (pun violation.. sry)

You may be making to many suppositions about what we need to do here.
i believe we only need to establish a flawless anon transfer network.

if were going to escape darks overpaying we have to color outside the lines now.
[and notice orange was always the brightest crayon in the box lol]
we need a different approach, new ideas, this is a time for innovation.

My suggestion is NOT likely to be the best solution possible,
so improve on it, come up with a new one, (which includes price discovery)

with 'wallet controlled transpay' the software intrusion appears minimal, less complicated than what was being proposed.
im sure there are a thousand ways that would work, it's not rocket science ya know, just a moon shot lol.

I can no longer follow you down this rabbit hole that you have cleverly designed to distract me. I'm turning all my attention to the code. I thought on some level I could help everyone see our vision. The specs are set and the code is being written, I encourage you to buy while the price is low.        

I realize you have no clue what i'm talking about
unless OC does, this coin will be following dark's mistakes for sure,
but with no such guarantee of its successes
 
but like i said before... it won't matter in the end
when the community realizes how deep the gouging goes (deeper than your rabbit hole btw)
they will object with such volume
the devs will have to fix it anyway

your mind is completely closed to any but one hopeless double-blind payola plan doomed to fail at great expense to the unsuspecting oranges, they are not here you know, only ppl drooling over these 100x payoffs have the time to camp on this thread.

and as i said two days ago, i have no more time to waste on ppl who can't even understand their own problem, let alone a solution.

[Jim_Rambler]

Jim,
   Does this mean you guys are looking into a auto adjusting MN payment system?  That would be quite a new idea/system, and if so should be announced if you guys are looking into this.  Would cause some serious investment...
   

NO

[btcMagnet]

Jim,
   Does this mean you guys are looking into a auto adjusting MN payment system?  That would be quite a new idea/system, and if so should be announced if you guys are looking into this.  Would cause some serious investment...
  

NO

lol....    NO Jim is not considering anything new

[Jim_Rambler]

Jim,
   Does this mean you guys are looking into a auto adjusting MN payment system?  That would be quite a new idea/system, and if so should be announced if you guys are looking into this.  Would cause some serious investment...
   

NO

lol....  NO Jim is not considering anything new

And just bc I'm not using your un-needed idea, doesn't mean we have nothing new.

[Halofire]

Downloaded a windows wallet and keeps getting stuck around half way, i already cleared my appdata roaming file, and still gets stuck, anything else i can do?

What block are you getting stuck around? There's been no forks to speak of, but wondering if you're getting stuck same place each time.
What wallet version are you using?