So, what if I can't afford to keep buying SPR?
If it so should happen that you own 1 or more Servicenodes but can't afford to keep buying SPR (because SPR price has risen too much)... it means you are rich.  Next step is to enjoy your new wealth. Actually, what I an others will probably do is use servicenode revenue to buy SPR and keep the price artificially high  Yes, but don't call it "artificial". JPMorgan does "artificial" stuff, since they can just create money out of thin air... lol  Nothing in crypto and free market is "artificial" if you ask me. You as a seller can only keep the price artificially high if there are people voluntarily willing to buy at those prices. And you will always have to fight against the miners who are in the business of dumping fast, and will always underbid your "artificially high" offers. (but again, why call it artificial, I think you are allowed to sell your SPR at whatever price you wish. ) The dynamic will be interesting to observe. Crypto is as "free market" as it gets. JPMorgan and friends can only do their "artificial stuff" because they can use government regulation to do so. |
|
|
|
I think I get it. Let's see.
So I start with a servicenode that has 500SPR (for the sake of discussion).
over time, all the seats for a given coin supply fill up.
So now, we all have the same 500 SPR. But this will never happen, that we all have the same amount of SPR. There will always be people that play it more risky (and go with lower collateral so that they can create more Servicenodes to make more profit) and others that are less willing to take risk (and will put more "cushion" in their collateral).... ...and everything in between. That's essentialy THE SPREAD. And in my opinion what will give the coin its name identity and symbolism. Someone wants to take a seat and decided to put in 501 SPR. My servicenode is not looking healthy, so I'm in danger of moving out of the revenue generation seats.
To overcome this, I buy 5 SPR and bump myself up into a safe zone.
So, what if I can't afford to keep buying SPR?
|
|
|
|
Awesome man, glad to have you on the team. |
|
|
|
So, what if I can't afford to keep buying SPR?
If it so should happen that you own 1 or more Servicenodes but can't afford to keep buying SPR (because SPR price has risen too much)... it means you are rich. Next step is to enjoy your new wealth. |
|
|
|
2. The collateral was intended to avoid sybil attacks in the future. Well, if we limit the cap now and that dictates the price of servicenodes, we still get protection from sybil attackers. A sybil attacker would have to ask the market to purchase servicenode seats.
Why not find cryptographic ways of preventing sybil attacks, instead of artificially limiting the access to the overlay network by making it dependend on how much money you got? You can't. Everyone has tried. The only thing that works, let's say at the moment, is cold hard digital cash. If an attacker has to spend money, you reduce those that are motivated to attack. If you don't require collateral of some sorts, people will just spend their lives on their computers trying to find ways to break in. I am sure that some form of validation can help prevent sybil attacks. We surely can "challenge" the joining servicenodes in a different way than simply checking the amount of SPR in their collateral. Let them solve a puzzle, or something.... I see there are some promising papers out there.... somebody has already done the theoretical research for us, it seems... |
|
|
|
devils advocate.
So, we are all happily creating service nodes. Then one day, a great service goes live. Big businesses like the idea of the service and decide to dip into their deep pockets and hoover up cheap service nodes and then only big businesses will be able to operate a node.
The little man in the housing projects will never be able to outspend JP Morgan.
What are we going to do about them apples?
That's where the maximum coinsupply comes in. Mr. Spread and I have explained that countless times. If you wanted to take over all the already established Servicenodes you would need multiple times the whole coinsupply. If you want your Servicenode to be secure even against a JPMorgan Takeover, just put more SPR in it than the average joe. If your SPR is well positioned, JPMorgan needs to take away .... 1) ... all the seats below you, 2) ... lift their position higher than you by putting MORE SPR (than you have in yours) in EACH ONE of those servicenodes... ... and only then will they be able to kick you out. The math is on our side, not on JPMorgans. Also, I repeat, as I currently look at it, kicking out merely means "not getting payed anymore".Since the goal is to cryptographically secure the decentralized services, it is not unthinkable that we will let basically everyone join our network as "free servicenodes", as long as they follow our protocol, why not? That's an interesting thought, isn't it?  I am not sure yet, testnet will tell. |
|
|
|
|
BTW, when I say "a servicenode is being kicked" I merely mean that they stop receiving any payments, until they add more funds to their collateral to get back on the payroll.
The operation of the servicenode itself (all the decentralized services) will not be stopped or anything like that.
You simply don't get payed for helping the network until you "balance your account" (so to speak).
Since free price discovery means that the price can also drop, it is possible that your collateral has more SPR in it than are necessary, and you can then move those excess SPR away.
(But that would be unwise...)
|
|
|
|
4. Servicenodes are intended to be business units - servers. The collateral is just a protection mechanism.
No, it isn't really. Well, not in the same way that a collateral supposedly secures the Dash network from sybil attacks. The collateral serves a different purpose in spreadcoin/servicenodes. The most interesting thing about letting the servicenode collateral be decided by the free market (spreadcoin protocol) is that every person will be allowed to run a servicenode with the least amount of collateral the market let's you get away with. As long as there are empty seats in the amount of allowed Servicenodes and no one is willing to bet more than you (to kick you out of your "cheap seat"), you can run a servicenode basically for free. At least for a while, because running a cheap servicenode will be risky. You understand that this will also be the reason why we will get many interested persons to run servicenodes intitially, by basically allowing everybody to run one. (contrast that with DASH where early investors pretty much control the masternode network) Only after all seats are filled (which are dynamically increased pretty much every other day so as to ALWAYS welcome newcomers) will the weakest servicenode operators (and only they) see their servers being kicked, which hopefully will ignite a slow and steady price discovery to find the most "efficient" collateral. Yes, this also means that our overlay network must have true cryptographic protection against sybil attacks and other unwanted activities, making it more complex to realize. |
|
|
|
2. The collateral was intended to avoid sybil attacks in the future. Well, if we limit the cap now and that dictates the price of servicenodes, we still get protection from sybil attackers. A sybil attacker would have to ask the market to purchase servicenode seats.
Why not find cryptographic ways of preventing sybil attacks, instead of artificially limiting the access to the overlay network by making it dependend on how much money you got? |
|
|
|
In a nutshell, any cap on servicenode count whether it be static or dynamic (your proposal or Mr Spread's) is an immediate turn off for me because if the servicenode network is to be providing decentralized services, then surely the more servicenodes the better? Anything kind of cap theoretically could compromise quality of service.
This is the reason why I have always preferred the Dash approach...no limit, leave it to the market to decide.
Think of it this way... even if we had no limit on the amount of servicenodes.... how many do you think we are going to have with a maximum coinsupply of 20 million, anyway? With my proposal we are going to see maybe 7000 Servicenodes over the years... Now if we imagine for a minute that we have no limit, and that 50% of all coinsupply is locked in servicenodes that cost on average 1000 SPR, then this would lead to about 10000 Servicenodes... So just about 30% more than my approach.... so what's the big deal? I don't think Dash will EVER see more than 10k Masternodes, it's just an economical impossibility. Are you envisioning a network that has 100k Servicenodes? Or a million of them? Of course you aren't. The mere coinsupply limit doesn't allow for such a thing. That's why I say... with the ca 7000 Servicenodes my approach allows over time we will safely be able to be provide high quality decentralized services of many kinds. I don't think youtube has that many servers. Decentralize everything! |
|
|
|
This is the reason why I have always preferred the Dash approach...no limit, leave it to the market to decide.
How is creating a fixed price collateral "leaving it to the market to decide" ? That's like saying: sure you can drive a taxi in new york, you just have to buy this 250k$ license. That's not a free market. Remember, with spreadcoin we are going the decentralized way, so the market will even have to dictate the price of the collateral, not you or I or any special group of people. |
|
|
|
Trying to make the video I have more info about the "issue". The minning is not interrupted in any way when transferring smaller amounts of SPR. Sending 10 or 100 SPR proceeds smoothly. I get the ballon(wallet notification) in the windows taskbar immediately after pressing send. Sending 1000SPR shows small interruption(few seconds) in the gpuz graph. Also the taskbar balloon shows many seconds after pressing send button. I cannot test it further because I don't have any more SPR in the wallet.  My usual transfer is 5000SPR and there You can see a noticeable interruption. The time before the taskbar balloon shows after pressing send button is much longer. The cpuZ shows no gpu utilization in the meantime and the miner shows something like: Cannot connect...retrying after 30s Probably it is not a bug...it just takes some time to process a bigger transfer because it is accumulated from big number of blocks. Anyway I'm unable to reproduce it now for some weeks  Thanks for the explanation. I will try and recreate it myself. Something tells me this behaviour will disappear once we have upgraded to CORE. |
|
|
|
Hey! I have a few worlds to say about the wallet(Win7). It is great but I would like it even more if it would be shrinkable to a smaller layout. Especially the width. An additional line showing average on the hashrate/diff charts would be nice. The wallet prevents minning for some time when transferring coins from the wallet to another address(bittrex). It is not a big problem because I transfer coins rarely(unluckily ) and it lasts for something like 1 minute(maybe less). I don't remember it happening with the old wallet but I'm not 100% sure about that. It could be a normal (expected) behavior waiting a new block to be found... Those are just my (noobish)personal thoughts and don't want beeing counterproductive in any way. Keep up the good work! That's a great idea, making it shrink to different sizes (widget mode) like a mp3 player or something... Thanks for your feedback, I will consider it for the next newwallet update. PS, never heard about the bug you describe... can someone confirm this? or can you make a video showing it in action, dominuspro? I can make a video, probably tomorrow. looking forward to it. |
|
|
|
Ok everybody, official website now has a news/blog section: spreadcoin.info . . .  . . .  . . . Stay tuned |
|
|
|
Hey! I have a few worlds to say about the wallet(Win7). It is great but I would like it even more if it would be shrinkable to a smaller layout. Especially the width. An additional line showing average on the hashrate/diff charts would be nice. The wallet prevents minning for some time when transferring coins from the wallet to another address(bittrex). It is not a big problem because I transfer coins rarely(unluckily ) and it lasts for something like 1 minute(maybe less). I don't remember it happening with the old wallet but I'm not 100% sure about that. It could be a normal (expected) behavior waiting a new block to be found... Those are just my (noobish)personal thoughts and don't want beeing counterproductive in any way. Keep up the good work! That's a great idea, making it shrink to different sizes (widget mode) like a mp3 player or something... Thanks for your feedback, I will consider it for the next newwallet update. PS, never heard about the bug you describe... can someone confirm this? or can you make a video showing it in action, dominuspro? |
|
|
|
 Nearly finished with the news/blog section. In localhost it works, I just need to make some adjustments on the server. (Will do so over the weekend) Stay tuned. |
|
|
|
....
BTW... did you abandon the Hashrate distribution chart at http://104.36.83.126/spreadcoin/ ? I am just asking. No problem if you don't want to run it anymore. |
|
|
|
if (nHeight > (int)getFirstHardforkBlock())
Should have read like this:
if (nHeight >= (int)getFirstHardforkBlock())
If the code says if (nHeight > (int)getFirstHardforkBlock()) then it must be read as if (nHeight > (int)getFirstHardforkBlock()) and NOTHING else. You can't start reinterpreting things based on shoulda coulda woulda. The whole confusion I had there for a minute was because the two forks use two different kinds of nHeight. getFirstHardforkBlock uses pLastBlock->nHeightwhile getSecondHardforkBlock works with pindex->nHeightAnyway, I should have just researched it 5 minutes longer before posting here, and I would have found the solution myself, but then we wouldn't be having this nice discussion. |
|
|
|
I think you are right, thanks for pointing this out. |
|
|
|
|
Show Posts
