[ANN] SpreadCoin | Decentralize Everything (decentralized blockexplorer coming)

[georgem]

But if you create the servicenode protocol, you can be in charge of how it launches to be accepted by the network.

That should be super easy to police.

> If bitcoin node closed, close servicenode.
> If bitcoin node client not xxxx, close servicenode.
> Bitcoin wallet can be zero balance.

But an operator has both the servicenode and the bitcoin node in his full control,
so he will have the possibility to fake the state of either one of those.

It's not as easy I am afraid.

[1715163409]

1715163409

[1715163409]

1715163409

[1715163409]

1715163409

[1715163409]

1715163409

[georgem]

The Darkcoin model of 1000DRK to buy in and the market value of 1000DRK will determine how many people have masternodes (some will cash out at points etc).  
That model is tried and tested and I can't quite understand the benefits of the proposed SPR method yet.  

Horses were also "tried and tested" once, and they still had to make room for the automobile.

My though process comes from the desire that I want to expose the collateral to the same market forces that hashrate and currency value are also exposed to.

This exposure can never be wrong. Think of it as an additional parameter, a "valve" in which the market is allowed to influence (and be influenced back) by the network.

Sure, it makes things more complicated, much like people are pissed that BTC price isn't always increasing, and that difficulty rises instead of staying where it is.

Yeah, let the people be discontent, it will keep them on their feet and engaged, and this will only serve the system.


But that's something I will have to prove to you on testnet in a real world situation.

[stonehedge]

The Darkcoin model of 1000DRK to buy in and the market value of 1000DRK will determine how many people have masternodes (some will cash out at points etc).  
That model is tried and tested and I can't quite understand the benefits of the proposed SPR method yet.  

Horses were also "tried and tested" once, and they still had to make room for the automobile.

My though process comes from the desire that I want to expose the collateral to the same market forces that hashrate and currency value are also exposed to.

This exposure can never be wrong. Think of it as an additional parameter, a "valve" in which the market is allowed to influence (and be influenced back) by the network.

Sure, it makes things more complicated, much like people are pissed that BTC price isn't always increasing, and that difficulty rises instead of staying where it is.

Yeah, let the people be discontent, it will keep them on their feet and engaged, and this will only serve the system.


But that's something I will have to prove to you on testnet in a real world situation.

You present your logic flawlessly and articulately but from my perspective, a servicenode operator is best on their feet and engaged when they are assured that their node is up and running and stable thus ensuring that their operating costs are not in vain should they be kicked from the active node list.

It has been a long time since I have been this excited about a project.  Testnet, as you say, is going to be a proving ground but also a lot of fun 

[coins101]

But if you create the servicenode protocol, you can be in charge of how it launches to be accepted by the network.

That should be super easy to police.

> If bitcoin node closed, close servicenode.
> If bitcoin node client not xxxx, close servicenode.
> Bitcoin wallet can be zero balance.

But an operator has both the servicenode and the bitcoin node in his full control,
so he will have the possibility to fake the state of either one of those.

It's not as easy I am afraid.

The Bitcoin wallet is open source.

Why not add a start instruction linked to the launch of a servicenode, and then make them depend on each other?

[georgem]

a servicenode operator is best on their feet and engaged when they are assured that their node is up and running and stable thus ensuring that their operating costs are not in vain should they be kicked from the active node list.

And he can be assured with the new model too: it's his decision to not be near the weakest link.

It's really his decision. Suppose he has 1000 SPR to invest:

1) Does he want to run 1 servicenode with 1000 SPR in it, that can basically not be challenged (kicked out) by anybody (except if his servicenode is deemed invalid or "not up to the job"),
or
2) does he want to run 10 servicenodes with 100 SPR each, which makes them very risky (because they could be shut down easily, but not necessarily), but also increases his changes of profit 10x?

It has been a long time since I have been this excited about a project.  Testnet, as you say, is going to be a proving ground but also a lot of fun  

The testnet sessions we had in january/february are the reason I am so motivated.

[georgem]

The Bitcoin wallet is open source.

Why not add a start instruction linked to the launch of a servicenode, and then make them depend on each other?

Yes, but that also means that too simple rules can easily be deleted from the source.

Much like for example, you don't need neither the wallet nor the protocol to create a valid BTC address.
You can literaly do that with pen and paper only.

What I want to say with that, is that there are parts of the whole crypto construct that are completely outside of both code and protocol.

The same way any rule we implement that wants to enforce a perfect teamwork between servicenode and bitcoin node would require that we create rules that are deeply embedded in the protocol, and not just "present" in the open source code.

In effect, this means that not your service node will check if you run a bitcoin node, but other service nodes will check you.  

But we both know that.

[coins101]

The Bitcoin wallet is open source.

Why not add a start instruction linked to the launch of a servicenode, and then make them depend on each other?

Yes, but that also means that too simple rules can easily be deleted from the source.

Much like for example, you don't need neither the wallet nor the protocol to create a valid BTC address.
You can literaly do that with pen and paper only.

What I want to say with that, is that there are parts of the whole crypto construct that are completely outside of both code and protocol.

The same way any rule we implement that wants to enforce a perfect teamwork between servicenode and bitcoin node would require that we create rules that are deeply embedded in the protocol, and not just "present" in the open source code.

In effect, this means that not your service node will check if you run a bitcoin node, but other service nodes will check you.  

But we both know that.

So now every other node can check if specific protocol instructions have been tampered with. That moves things on a little.

edit

I suppose if bitcoin nodes are on the servicenode network, hosted in the same place, you can send a ping request around the network and if you don't keep getting responses, servicenodes don't get paid?

The nodes do leak information that can be used https://getaddr.bitnodes.io/nodes/incentive/

[e1ghtSpace]

It's quite the predicament.

I agree with ocminer that more pools will come to life if the price of spreadcoin keeps rising.

At the same time I wouldn't like the promotion of any pools in the OP, we need promotion of solo.

But I feel its only ethical to make it 1000% crystal clear that there are pools, that work.

Yes they work as long as everybody plays nice, and doesn't try to use the protocol rules which are in their favour (or not - in the case of the pools)

Thats not true george, the pools work like all the other pools - no one can steal anything, just some adaption was needed and done.

No, Mr. Spread said that you will be able to steal from the pool and claim it was the miner. This "attack" will work if everyone believes you.

[entropycoin]

Would requiring servicenode operators to operate a full bitcoin node disincentivize users with larger holdings from dumping into the market?  For example, it may be resource restrictive for someone with 50000 coins to run 2-10k nodes, so they opt instead to cash out their holdings for say dash, where they can run multiple masternodes for cheaper.

Why not have a two tiered approach.  

Option 1: run a full bitcoin node with a fixed number of spr, preventing nodes from ever going offline while not capping the total number of bitcoin nodes in existence and allowing servicenodes to continuously receive rewards.  

Option 2: dynamic servicenodes for users providing less resource dependent services like instant transactions, private messaging, etc.  Allows for greater ease of setup than masternodes (run multiple servicenodes from the qt client with the click of a button).  This market would likely dictate that the cost of doing so is higher than running a bitcoin node but would be a strong incentive for newcomers and bagholders alike to maintain a strong position in the coin.

[e1ghtSpace]

Would requiring servicenode operators to operate a full bitcoin node disincentivize users with larger holdings from dumping into the market?  For example, it may be resource restrictive for someone with 50000 coins to run 2-10k nodes, so they opt instead to cash out their holdings for say dash, where they can run multiple masternodes for cheaper.

Why not have a two tiered approach.  

Option 1: run a full bitcoin node with a fixed number of spr, preventing nodes from ever going offline while not capping the total number of bitcoin nodes in existence and allowing servicenodes to continuously receive rewards.  

Option 2: dynamic servicenodes for users providing less resource dependent services like instant transactions, private messaging, etc.  Allows for greater ease of setup than masternodes (run multiple servicenodes from the qt client with the click of a button).  This market would likely dictate that the cost of doing so is higher than running a bitcoin node but would be a strong incentive for newcomers and bagholders alike to maintain a strong position in the coin.

Well if it ever comes to the point where running a Dash masternode is cheaper than a Spreadcoin servicenode then that means Spreadcoin has overtaken Dash. Why would you want to invest in a dying crypto?

Also, if you didn't know, in Spreadcoin you can have multiple servicenodes for cheaper. So I don't really know what you're on about.

[WCIR]

http://worldcoinindex.com/coin/spreadcoin

[coins101]

Would requiring servicenode operators to operate a full bitcoin node disincentivize users with larger holdings from dumping into the market?  For example, it may be resource restrictive for someone with 50000 coins to run 2-10k nodes, so they opt instead to cash out their holdings for say dash, where they can run multiple masternodes for cheaper.

Why not have a two tiered approach.  

Option 1: run a full bitcoin node with a fixed number of spr, preventing nodes from ever going offline while not capping the total number of bitcoin nodes in existence and allowing servicenodes to continuously receive rewards.  

Option 2: dynamic servicenodes for users providing less resource dependent services like instant transactions, private messaging, etc.  Allows for greater ease of setup than masternodes (run multiple servicenodes from the qt client with the click of a button).  This market would likely dictate that the cost of doing so is higher than running a bitcoin node but would be a strong incentive for newcomers and bagholders alike to maintain a strong position in the coin.

Well if it ever comes to the point where running a Dash masternode is cheaper than a Spreadcoin servicenode then that means Spreadcoin has overtaken Dash. Why would you want to invest in a dying crypto?

Also, if you didn't know, in Spreadcoin you can have multiple servicenodes for cheaper. So I don't really know what you're on about.

the ability to have mutiple servicenodes is and should be an aspiration.

but having too many in the hands of a few works against the network - it becomes less decentralised.

[entropycoin]

Would requiring servicenode operators to operate a full bitcoin node disincentivize users with larger holdings from dumping into the market?  For example, it may be resource restrictive for someone with 50000 coins to run 2-10k nodes, so they opt instead to cash out their holdings for say dash, where they can run multiple masternodes for cheaper.

Why not have a two tiered approach.  

Option 1: run a full bitcoin node with a fixed number of spr, preventing nodes from ever going offline while not capping the total number of bitcoin nodes in existence and allowing servicenodes to continuously receive rewards.  

Option 2: dynamic servicenodes for users providing less resource dependent services like instant transactions, private messaging, etc.  Allows for greater ease of setup than masternodes (run multiple servicenodes from the qt client with the click of a button).  This market would likely dictate that the cost of doing so is higher than running a bitcoin node but would be a strong incentive for newcomers and bagholders alike to maintain a strong position in the coin.

Well if it ever comes to the point where running a Dash masternode is cheaper than a Spreadcoin servicenode then that means Spreadcoin has overtaken Dash. Why would you want to invest in a dying crypto?

Also, if you didn't know, in Spreadcoin you can have multiple servicenodes for cheaper. So I don't really know what you're on about.

I was referring to operational costs being higher if you are required to operate a full bitcoin node.  One of the things that drew me initially to the project was the ease of set up in running multiple servicenodes instances in the qt client.  How will this be possible, if each servicenode needs to be attached to a full bitcoin node?

[entropycoin]

Would requiring servicenode operators to operate a full bitcoin node disincentivize users with larger holdings from dumping into the market?  For example, it may be resource restrictive for someone with 50000 coins to run 2-10k nodes, so they opt instead to cash out their holdings for say dash, where they can run multiple masternodes for cheaper.

Why not have a two tiered approach.  

Option 1: run a full bitcoin node with a fixed number of spr, preventing nodes from ever going offline while not capping the total number of bitcoin nodes in existence and allowing servicenodes to continuously receive rewards.  

Option 2: dynamic servicenodes for users providing less resource dependent services like instant transactions, private messaging, etc.  Allows for greater ease of setup than masternodes (run multiple servicenodes from the qt client with the click of a button).  This market would likely dictate that the cost of doing so is higher than running a bitcoin node but would be a strong incentive for newcomers and bagholders alike to maintain a strong position in the coin.

Well if it ever comes to the point where running a Dash masternode is cheaper than a Spreadcoin servicenode then that means Spreadcoin has overtaken Dash. Why would you want to invest in a dying crypto?

Also, if you didn't know, in Spreadcoin you can have multiple servicenodes for cheaper. So I don't really know what you're on about.

the ability to have mutiple servicenodes is and should be an aspiration.

but having too many in the hands of a few works against the network - it becomes less decentralised.

in my provided example, it would still be incredibly decentralized when factoring in the bitcoin node operators.  If spreadcoin is going to be successful, it's going to because of the potential for profitability.  If it's less feasible for large holders to run multiple servicenode instances, this may drive price downward as the incentive to hold diminishes.  Where would bitcoin or dash be without the whales?

[entropycoin]

If we're accommodating the running of a full bitcoin node and this costs $5/month in cloud server fees (I have no idea if this is accurate) and your servicenode receives say an average of 2 payments/day (770 max nodes to start) at 30 percent reward rate, or 120 spr/month, this could definitely work with a bit of profitability.

$5 in bitcoin= .0205/120 spr reward per month= .00001708.  If the price of bitcoin remains constant and the price of spr increases to .0003 where it has been for a large portion of its lifespan, you would initially net $3.53 in profit/month per node.

[e1ghtSpace]

If we're accommodating the running of a full bitcoin node and this costs $5/month in cloud server fees (I have no idea if this is accurate) and your servicenode receives say an average of 2 payments/day (770 max nodes to start) at 30 percent reward rate, or 120 spr/month, this could definitely work with a bit of profitability.

$5 in bitcoin= .0205/120 spr reward per month= .00001708.  If the price of bitcoin remains constant and the price of spr increases to .0003 where it has been for a large portion of its lifespan, you would initially net $3.53 in profit/month per node.

But the cool thing with spreadcoin is, you are able to have more then one spreadnode on each ip address, so that means if you have 2 nodes, you receive $8.53 a month and 3 nodes would be $13.53/month.

[IBGigglin]

If we're accommodating the running of a full bitcoin node and this costs $5/month in cloud server fees (I have no idea if this is accurate) and your servicenode receives say an average of 2 payments/day (770 max nodes to start) at 30 percent reward rate, or 120 spr/month, this could definitely work with a bit of profitability.

$5 in bitcoin= .0205/120 spr reward per month= .00001708.  If the price of bitcoin remains constant and the price of spr increases to .0003 where it has been for a large portion of its lifespan, you would initially net $3.53 in profit/month per node.

IMO It should be obvious sooner or later SPR will be worth more .0003

[AnotherNode]

All looks great, so far, especially the BTC full node feature.

Bitcoin lost about 2-3k full nodes since last year.

Some info on full nodes from gmaxwell in CT

Maxwell explained some ongoing projects to increase privacy, and he recommended that users run a full node, rather than run simple payment verifications (SPVs). He says:

“We have been working along to make it easier for users to run full nodes since full nodes have fundamental privacy advantages. The existing models for SPVs are fundamentally weak from a privacy perspective.”

However, it is quite painful for clients to run a 30 GB full node on their devices, and it is not practical. Therefore, devs are releasing a pruning version that brings the size down to 1.3 GB. Pruning allows users to run a full node that autonomously validates the network, and it’s still fully private, while it doesn’t store the whole blockchain. It is even practical for a Bitcoin core to be run on a mobile phone with pruning, offering more privacy.

http://cointelegraph.com/news/114137/while-core-development-declines-gregory-maxwell-and-sf-devs-remain-focused

Can't wait for the rest of the road map.

[e1ghtSpace]

All looks great, so far, especially the BTC full node feature.

Wait, we're actually going through with this???
I thought it was just someone's idea.

[coins101]

All looks great, so far, especially the BTC full node feature.

Wait, we're actually going through with this???
I thought it was just someone's idea.

Looks like its just under investigation.

If it could be done, SPR would get so much publicity out of it it's not funny.

An altcoin supporting Bitoin? The price of servicenodes would go through the roof.