[ANN] SpreadCoin | Decentralize Everything (decentralized blockexplorer coming) - page 327.

entropycoin

full member

Activity: 171

Merit: 100

Quote from: coins101 on May 02, 2015, 03:33:30 PM

Quote from: e1ghtSpace on May 02, 2015, 03:01:42 PM

Quote from: entropycoin on May 02, 2015, 02:57:31 PM

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

full member

Activity: 171

Merit: 100

Quote from: e1ghtSpace on May 02, 2015, 03:01:42 PM

Quote from: entropycoin on May 02, 2015, 02:57:31 PM

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?

coins101

legendary

Activity: 1456

Merit: 1000

Quote from: e1ghtSpace on May 02, 2015, 03:01:42 PM

Quote from: entropycoin on May 02, 2015, 02:57:31 PM

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.

WCIR

full member

Activity: 144

Merit: 100

http://worldcoinindex.com/coin/spreadcoin

e1ghtSpace

legendary

Activity: 1540

Merit: 1001

Crypto since 2014

Quote from: entropycoin on May 02, 2015, 02:57:31 PM

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.

entropycoin

full member

Activity: 171

Merit: 100

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

legendary

Activity: 1540

Merit: 1001

Crypto since 2014

Quote from: ocminer on May 02, 2015, 12:22:50 PM

Quote from: georgem on May 02, 2015, 12:04:16 PM

Quote from: defunctec on May 02, 2015, 11:42:27 AM

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.

coins101

legendary

Activity: 1456

Merit: 1000

Quote from: georgem on May 02, 2015, 02:04:37 PM

Quote from: coins101 on May 02, 2015, 01:59:42 PM

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

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/

georgem

legendary

Activity: 1484

Merit: 1007

spreadcoin.info

Quote from: coins101 on May 02, 2015, 01:59:42 PM

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

But we both know that.

georgem

legendary

Activity: 1484

Merit: 1007

spreadcoin.info

Quote from: stonehedge on May 02, 2015, 01:50:22 PM

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?

Quote from: stonehedge on May 02, 2015, 01:50:22 PM

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.

coins101

legendary

Activity: 1456

Merit: 1000

Quote from: georgem on May 02, 2015, 01:37:04 PM

Quote from: coins101 on May 02, 2015, 01:24:49 PM

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?

stonehedge

legendary

Activity: 1722

Merit: 1002

Decentralize Everything

Quote from: georgem on May 02, 2015, 01:43:47 PM

Quote from: stonehedge on May 02, 2015, 01:33:21 PM

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

georgem

legendary

Activity: 1484

Merit: 1007

spreadcoin.info

Quote from: stonehedge on May 02, 2015, 01:33:21 PM

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.

georgem

legendary

Activity: 1484

Merit: 1007

spreadcoin.info

Quote from: coins101 on May 02, 2015, 01:24:49 PM

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.

stonehedge

legendary

Activity: 1722

Merit: 1002

Decentralize Everything

Quote from: coins101 on May 02, 2015, 01:24:49 PM

Quote from: georgem on May 02, 2015, 01:22:19 PM

Quote from: coins101 on May 02, 2015, 12:48:29 PM

We can write the PR articles over the next few weeks and get them out to our new PR contacts.

Maybe we can get the Bitcoin core devs and the Bitcoin Foundation running a couple of ServiceNodes Wink

I will work on my own implementation of servicenodes and hopefully have something for testnet ready by the end of this month.

First I always thought I would let those first servicenodes do some kind of "empty" service just for testing sake,
but it could very well be that their first service will be around how to "insure" that every servicenode is running a full bitcoin node,
and not trying to game the system, as this user in your thread correctly emphasizes:

Quote from: dive on April 30, 2015, 10:31:42 AM

The problem is identifying who really is a full node. You can set up thousands of "ghost nodes" that are just passthrough gateways for the same node but will look like multiple different ones.
The moment you start with paid incentives, you have to try to fend off everyone that is trying to game the system.

And this problem could be harder to solve than it sounds: proving that you run a full node.

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

I love the idea of a symbiotic relationship between SPR and BTC. Obviously we'd be the tiny little fish picking scraps from its teeth but its a great starting point for servicenodes nonetheless. A perfect demonstration of the potential of a service node "payload".

I have to say George, I'm still very sceptical about having a cap on the number of masternodes that moves with coin supply. I'd love to have a discussion in more detail on this. 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.

I thought I understood it a few days ago but the more I think about it, the fewer benefits I can define.

coins101

legendary

Activity: 1456

Merit: 1000

Quote from: georgem on May 02, 2015, 01:22:19 PM

Quote from: coins101 on May 02, 2015, 12:48:29 PM

We can write the PR articles over the next few weeks and get them out to our new PR contacts.

Maybe we can get the Bitcoin core devs and the Bitcoin Foundation running a couple of ServiceNodes Wink

I will work on my own implementation of servicenodes and hopefully have something for testnet ready by the end of this month.

First I always thought I would let those first servicenodes do some kind of "empty" service just for testing sake,
but it could very well be that their first service will be around how to "insure" that every servicenode is running a full bitcoin node,
and not trying to game the system, as this user in your thread correctly emphasizes:

Quote from: dive on April 30, 2015, 10:31:42 AM

The problem is identifying who really is a full node. You can set up thousands of "ghost nodes" that are just passthrough gateways for the same node but will look like multiple different ones.
The moment you start with paid incentives, you have to try to fend off everyone that is trying to game the system.

And this problem could be harder to solve than it sounds: proving that you run a full node.

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.

georgem

legendary

Activity: 1484

Merit: 1007

spreadcoin.info

Quote from: coins101 on May 02, 2015, 12:48:29 PM

We can write the PR articles over the next few weeks and get them out to our new PR contacts.

Maybe we can get the Bitcoin core devs and the Bitcoin Foundation running a couple of ServiceNodes Wink

I will work on my own implementation of servicenodes and hopefully have something for testnet ready by the end of this month.

First I always thought I would let those first servicenodes do some kind of "empty" service just for testing sake,
but it could very well be that their first service will be around how to "insure" that every servicenode is running a full bitcoin node,
and not trying to game the system, as this user in your thread correctly emphasizes:

Quote from: dive on April 30, 2015, 10:31:42 AM

The problem is identifying who really is a full node. You can set up thousands of "ghost nodes" that are just passthrough gateways for the same node but will look like multiple different ones.
The moment you start with paid incentives, you have to try to fend off everyone that is trying to game the system.

And this problem could be harder to solve than it sounds: proving that you run a full node.

What plays in our favour is that we are not trying to "tip" full nodes, we just want to check if our servicenodes are running full bitcoin nodes at all times,
and if they don't, then they are simply kicked out.
If they are ok, they simply remain in the club and recieve their fix SPR payment... (30% of every block or something along that line)

coins101

legendary

Activity: 1456

Merit: 1000

Quote from: stonehedge on May 02, 2015, 12:59:31 PM

Quote from: coins101 on May 02, 2015, 12:48:29 PM

Quote from: georgem on May 02, 2015, 12:43:09 PM

Quote from: coins101 on May 02, 2015, 12:24:32 PM

...
So maybe, to run a servicenode, you also need to run a full bitcoin node.
..

The more I hear about this idea the more I like it.
And it shouldn't be that hard to implement this as the first "service" the servicenodes are going to provide.

Cool.

We can write the PR articles over the next few weeks and get them out to our new PR contacts.

Maybe we can get the Bitcoin core devs and the Bitcoin Foundation running a couple of ServiceNodes Wink

Oooh PR! Can I help?

Sounds like a plan is forming.

Press, Bitcoin Magazine, CoindDesk, Let's talk Bitcoin, etc.

I can see the headlines: Spreadcoin saves Bitcoin.

stonehedge

legendary

Activity: 1722

Merit: 1002

Decentralize Everything

Quote from: coins101 on May 02, 2015, 12:48:29 PM

Quote from: georgem on May 02, 2015, 12:43:09 PM

Quote from: coins101 on May 02, 2015, 12:24:32 PM

Funny you should mention incentives to people running a full bitcoin node.

I started a thread about that a few days ago.

https://bitcointalksearch.org/topic/m.11238697

So maybe, to run a servicenode, you also need to run a full bitcoin node.

That would stop people spamming the servicenode network with dummy accounts to get a share of rewards.

Roll Eyes

The more I hear about this idea the more I like it.
And it shouldn't be that hard to implement this as the first "service" the servicenodes are going to provide.

Cool.

We can write the PR articles over the next few weeks and get them out to our new PR contacts.

Maybe we can get the Bitcoin core devs and the Bitcoin Foundation running a couple of ServiceNodes Wink

Oooh PR! Can I help?

coins101

legendary

Activity: 1456

Merit: 1000

Quote from: georgem on May 02, 2015, 12:43:09 PM

Quote from: coins101 on May 02, 2015, 12:24:32 PM

Funny you should mention incentives to people running a full bitcoin node.

I started a thread about that a few days ago.

https://bitcointalksearch.org/topic/m.11238697

So maybe, to run a servicenode, you also need to run a full bitcoin node.

That would stop people spamming the servicenode network with dummy accounts to get a share of rewards.

Roll Eyes

The more I hear about this idea the more I like it.
And it shouldn't be that hard to implement this as the first "service" the servicenodes are going to provide.

Cool.

We can write the PR articles over the next few weeks and get them out to our new PR contacts.

Maybe we can get the Bitcoin core devs and the Bitcoin Foundation running a couple of ServiceNodes Wink

Topic: [ANN] SpreadCoin | Decentralize Everything (decentralized blockexplorer coming) - page 327. (Read 790414 times)