 Show Posts
|
|
Pages: [1] 2 3 4 5 »
|
Well I don't think the problem is the use of (OP_CHECKLOCKTIMEVERIFY), which was added to Bitcoin ( https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki) and nice to see being used in other coins. The problem STEEM has is it was 99% NinjaMined which is worst and more dishonest then PreMined. This was amplifed with public post in other threads. Gliss has STEEM listed proper as it is right now in my eyes, like Ripple. |
|
|
|
|
Guys I know it's taking longer then we all wanted MN to take!!
Trust me I want this part of the project over way more then you guys want MN launched. I have spent so many hours and days on this code, it's a major project just know we had to overhaul the whole code to do this.
|
|
|
|
Well this is one of many things I'm working on as a NEW function. Ahh ok, thanks jim, explained it perfectly. So when you get change back it goes in to its own temporary address, is it ever meant to return back to the address it came from?
Other than anon and master nodes, what are the future plans for OC? Can you guys put together a road map? Because it looks like anon is fading and is becoming a feature on every coin just to stay afloat, so i dont know if its going to make much of a difference in price except to stabilize it.
I will explain some of the new things we are working on which will answer both the questions and I'm sure a few others watching this thread. First this is not all the things we are working on, I just can't paint the whole picture for you in a roadmap style. Some of the things in the works are not being worked on by others yet and we want to keep it that way. As well as some of the thing further down the road are experimental, and can not be promised yet. Ok Insomniac8, lets start with your temporary address question. I feel like it may be best to give a little in-depth explanation of how crypto input/output works. When you receive an input and then later spend from that input you must use all that input. The left over is sent back to you as change. You own that new wallet address already, you just didn't use it until that moment you got the change back. Ok what I mean is your wallet has a "keypool" inside it and it holds 100 public and private key pairs pre-generated and stored in a queue. public and private key pairs- meaning you own the private key hidden and only used when you need to send OC from that public key (wallet). So you keep that private hidden in your wallet and have the change sent to its public pair. Ok a very over simple explanation, You: Hey wallet send out 10 OC Wallet: I will use this 12 OC input bc it just minted, we will need a "public and private key pair" from the keypool, to receive the 2 OC back. Here this should start this video at 3:30, you more then welcome to watch the whole 22 mins http://www.youtube.com/watch?v=Lx9zgZCMqXE?t=3m30sSo with all this said by design the change is sent to a new wallet ( public key) Bitcoin did this so you don't just have 1 wallet making it easy to track. 1. New wallet feature will allow you to pick which address the change is sent to. (A change wallet, new wallet, the same wallet it came from....) 2. Better and easier wallet feature will allow for multiple wallets visible to receive OC (so creating multiple receive wallets addresses) - There will be many things to come from MN, they will be used not only for Anon, but also used to secure the network (not going to explain too much yet) - We are working on an improved PoS, more on this at a later date. - We have done some work with a "Block chain free" PoS idea. - We have even tested changing the elliptic curve algo, to something lighter with increased security like (Ed25519 DSA ) (may even be able to mint on mobile device) this one is a major undertaking and very experimental. But our number one priority at this moment is getting MN up and running stable before adding many other new things. So yes Anon will be a great addition, but we don't plan on stopping there. So the next major release is focused solely on MN, some of the other things mentioned will shortly follow the MN release. |
|
|
|
Nice. Thx.  Great I will look in to this later... I'm on my mobile atm... Just a quick look, It does look like Guncoin is #2 and they got the same post on there thread as us. So 4hrs ago this exchange posted in there forum, no one replied back yet but they have 487 votes. It could happen I just know Guncoin has a smaller community. Does anyone know anything about this exchange? |
|
|
|
The richlist has my balance wrong... I guess it doesn't count coins that have just staked and are waiting for confirmation?
exactly I compiled the new wallet daemon and it's downloading the blockchain again. Hope this will fix the isues on the richlist. I'll leave a reply when it is updated. Also, is there a working block explorer? cryptoblox is not updating (2014-06-21 22:50:20) edit: blockchain has been downloaded and processed. can someone please verify if the ballance is correct? (note this is not the wallet amount but the address amount) you can check the address amount under advanced coin control. Insomniac: The richlist goes by your deposit addresses, not the total OC in your wallet. Oizo: You the man, thanks. No regrets asking you for the richlist! I know, I only have one address in my wallet, but the rich list is still not showing the correct amount. Strange, are you staking, have you staked? Does the rich list show more or less than you should have? There's been no forks, so that's not the reason. If you'd like to PM with your details, I'll try to figure it out for you. Finally worked this out, it seems that when staking the wallet will generate new addresses to put the coins in. In my case the missing coins are in one of these addresses. The dont show up in "recieve" but you can see them under coin control. Had a thought after I replied to your PM. Just my opinion from experiences: I think the Wallet or PoS has code that tries to self-maintain, self-level or self-preserve to even out the staking difficulty or "PoS hashrate", as my experience with staking has been halving my minting over and over as time goes by. Also, when I receive large amounts to my wallet from the exchange or wherever, the transaction is for X but the coin control shows the deposit into my wallet as X divided by two and as 2 deposits. All my minting and deposits are 100% correct in the total amounts, they are what they are supposed to be. I haven't experienced this anywhere else in crypto, but is a neat feature(?) - self-leveling PoS difficulty. Yes this all is correct, this is a great thing Split PoS does. One other the things Spliting does is allows easier spending, with out throwing of the whole stacks coin age. What I mean is, if you have 20 OC and it mints. You get 2- 10 OC stacks, both start coin age over agian to 0 after minting. Now if you want to send 5 OC 10 days after that mint, you can pick 1 of the 2- 10 OC stacks (stack A and B) to send it from. So you pick stack A to send from. Well stack B stays in your wallet and stays at age 10 days only 4 days away from minting. Stack A is send out and the 5 OC remaning returns to you wallet as change. So Stack A now has 5 OC at age 0 and Stack B has 10 OC at 10 day old. Instead of the whole 20 OC being now 15 OC at age 0. Sending out whole stacks and getting the change back is how all cryptos work, when the stack is bigger then the sending amount. It's just with our PoS split it helps to solve resetting big block coin age to send small amounts just before mint age hits. I hope I explained this ok, I'm on my mobile atm, and hard to keep rereading what I have |
|
|
|
The richlist has my balance wrong... I guess it doesn't count coins that have just staked and are waiting for confirmation?
exactly I compiled the new wallet daemon and it's downloading the blockchain again. Hope this will fix the isues on the richlist. I'll leave a reply when it is updated. Also, is there a working block explorer? cryptoblox is not updating (2014-06-21 22:50:20) edit: blockchain has been downloaded and processed. can someone please verify if the ballance is correct? (note this is not the wallet amount but the address amount) you can check the address amount under advanced coin control. Insomniac: The richlist goes by your deposit addresses, not the total OC in your wallet. Oizo: You the man, thanks. No regrets asking you for the richlist! I know, I only have one address in my wallet, but the rich list is still not showing the correct amount. New block explorer and rich list is up http://chainz.cryptoid.info/oc/#I'm working with the new explorer Dev, for Masternode data display so it will be ready for launch. Some of the things we have talked about, MN count per country, a world map, and maybe a chart for the inactive/active. |
|
|
|
The richlist has my balance wrong... I guess it doesn't count coins that have just staked and are waiting for confirmation?
exactly I compiled the new wallet daemon and it's downloading the blockchain again. Hope this will fix the isues on the richlist. I'll leave a reply when it is updated. Also, is there a working block explorer? cryptoblox is not updating (2014-06-21 22:50:20) edit: blockchain has been downloaded and processed. can someone please verify if the ballance is correct? (note this is not the wallet amount but the address amount) you can check the address amount under advanced coin control. We have been looking to add another explorer to our list, we should have min of 2 at all times. We have settled on this one, it supports MN as well. (See DRK) http://chainz.cryptoid.info/I have PM'd the dev, however if you guys get the chance swing by and echo my request to be added, let them see our great community. https://bitcointalk.org/index.php?topic=571254.0 |
|
|
|
Many thanks but the link does not work Thanks for letting me know. I'll work on it. I was able to pull her up on the iPad, but it may be a good idea to have more then one site host this for us.  |
|
|
|
Is anyone else having sync issues?
I downloaded the new 1.0.4 wallet and tried to sync from fresh.
I get to block 10 000 and then it just stays there.
I'm getting a lot of these warnings/errors in my log.
ERROR: CheckProofOfStake() : INFO: read txPrev failed
WARNING: ProcessBlock(): check proof-of-stake failed for block 3885c0a20f393c935affab1b31e4d5224d2fdbc09d436f19f9f83176c010bdc0
received block 420a3ccffef3c2d24aa7
yes same thing with me too!!!!! I closed the wallet and opened again it synced to 10500 and stuck then I closed and open again synced to 11000 then stuck again then closed and open 4th time it has synced all the way to end. just try it a few times. I only have a mac wallet but it seems to be the same. Then it works without complaints  This worked like you said. Thanks Thank you for reminding me guys, I have it on my to-do list, to look in to this issue. While closing and opening the wallet does fix this, it's not an acceptable solution to have to do this. This issues was present in the wallet before 1.0.4, and will be fixed ASAP |
|
|
|
Don't forget to vote, only takes a second!
voted. there are many server anonymity coins popping out. and another multisig implementation coin under my radar. i know patience will reward, but are we going to see the MN in near future? sorry to be so rude.... i am holding. You keep asking the same thing, when, when, when... I told ya my opinion on the the timeline. While I can't say why, our feature IS worth the wait and will meet AND exceed expectations, I know that for a fact. Doesn't matter what other coins have, it's what those coins DON'T have that will set OC apart. Anticipation is so hard to deal with sometimes, haha Our devs are geniouses... Here's the thing I would love to keep you all posted on what we have going on behind the door. But some of this stuff we are adding hasn't been either thought of or not wanted to be worked on bc it's timely and a pain. Trust us, once we have her all done and packaged with a nice little bow, you all will flip sh1t. I know that a lot of you would like to hear more but, just know you have a dev team that cares about privacy. Meaning we are not telling the open forum all of our plans, I'm sure most of you don't want your dev's telling all the secrets. I'm ok with coins using our hard work after we have it up and posted. I just don't want them taking our concept and doing it wrong to beat us. Enjoy the lower price that comes with sellers doubts. We are not coming on here promising this and that making the price jump for a flash in the pan. We are working on real solutions to problems that plagues most coins weather they see it yet or see it and don't care. Masternodes are our top priority, getting them right, fast and set up for all the stuff to come and merge properly. This takes building, testing, tweaking, rebuilding, testing, tweaking...... With all that said, they will probably be a dump on the market soon, from some one scared that we can't do this all. Or someone that reads this and thinks masternodes are to far off for them to hold out. MN are coming soon, I'm not going to hold their release any more then testing they work proper with what we need now. If I guess on a timeframe it would only be a guess. I don't just guess on stuff like that, this is your investment, When I say something I mean it. With that said, MN are close and you will like what we have done, and you will like Halofire's contest. More info will come soon on all of this. Just know I read this forum 10+ times a day, we are here and working hard. |
|
|
|
Just an update on how the code binge is coming along, we are all eager to get Anon going. OC and I not only want to release Anon, but we want it set up so that we are as future-proof as one can be in this fast moving world. This takes calculated planning for the code being released now, so that we are Proactive and not Reactive to what people will need from a crypto. There will be no more expounding on this at this time, just know things are coming along well. Everything futuristic must me tried and true before information is released, which will take time. This schedule still holds true, I just felt you all to know there is a bigger picture and it takes time to do this right. Anon/masternodes will be coming in stages
First stage - give the community the "proposed" spec on masternodes, as well as some info on masternodes to start the familiarity process of the community.
Second stage - Release the masternode files and detailed instructions on how to set one up.
Third stage - after maternodes have been up, running and stable We will then start sending Anon transactions through them
Stage 2 & 3 don't have dates set yet, the closer we get the more you will know
Also during stage 2 the masternodes will began receiving reward payout even though Anon transactions are not being sent through them until stage 3. This will be done to both test rewards working proper and help off set server cost. We want masternode servers earning rewards from day one. Will it be likely to be weeks or months before you get Anon going? Good question, didn't want to make people think this is delaying things majorly right now. Anon will be weeks, just setting things up for further down the road that's all. |
|
|
|
Just an update on how the code binge is coming along, we are all eager to get Anon going. OC and I not only want to release Anon, but we want it set up so that we are as future-proof as one can be in this fast moving world. This takes calculated planning for the code being released now, so that we are Proactive and not Reactive to what people will need from a crypto. There will be no more expounding on this at this time, just know things are coming along well. Everything futuristic must me tried and true before information is released, which will take time. This schedule still holds true, I just felt you all to know there is a bigger picture and it takes time to do this right. Anon/masternodes will be coming in stages
First stage - give the community the "proposed" spec on masternodes, as well as some info on masternodes to start the familiarity process of the community.
Second stage - Release the masternode files and detailed instructions on how to set one up.
Third stage - after maternodes have been up, running and stable We will then start sending Anon transactions through them
Stage 2 & 3 don't have dates set yet, the closer we get the more you will know
Also during stage 2 the masternodes will began receiving reward payout even though Anon transactions are not being sent through them until stage 3. This will be done to both test rewards working proper and help off set server cost. We want masternode servers earning rewards from day one. |
|
|
|
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. It is the price of all this that's getting old, dark is paying nearly 10% of their cap a year
$3.9 million dollars^^^^^^^^^^^^^^Do you want to clone that bs because you are uncomfortable with any solution that isn't copy/paste? because anyone that knows their way around a wallet network could implement and test the changes i propose in a few days [another coin following this thread for instance] A new and innovated super-efficient transpay system would be a first in cc as Bloodpainter pointed out, This idea of savings nearly 10% of your coin's yearly cap would certainly stoke investments, besides being a 1st-feather in the orange cap, we could advertise anon for 1/20th or less the price drain others are paying but there i go again thinking too big for follow-the-leader landThis is a warning to the community!!! btcMagnet not only has posted here under multiple accounts, but he has dumped coins at the same time as his post to manipulate the price. This user has bad intentions for OC, at this point he has the look a failed Dev and is trying to take over our great coin. I take this as a compliment of how great OC is, however what I have seen and the PM's I have gotten show me this user is no good. |
|
|
|
|
please edit your post we dont need to see your ip
what platform are you running? windows?
|
|
|
|
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? First go to the debug window under the help menu, How many connections do you have? Then try going to the console tab type getinfo on the command line and hit enter, do you see any errors at the bottom? |
|
|
|
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. |
|
|
|
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 |
|
|
|
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 includingthis '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. |
|
|
|
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 |
|
|
|
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. |
|
|
|
|
