Interesting.
I think I will start a full node right now myself.
Haven't done that in a while.

coinsupply/2880 is also the amount of bitcoin nodes we can then provide.

Absolutely.

And although I am a big fan of fierce competition, I do love the fact that we are steping outside this game for a moment,
by creating something that would help other coins too for a change.  

Most other coins are trying to outrun competition (sometimes even by going closed source for a while   because they hate open source in that moment  ),
but in our case, if we make this work, when other people then copy our code, it would only help bitcoin (or other coins) even more?

Wasn't there a name in circulation a few months/weeks ago?

Spreadnodes?

Well, that's what spreadnodes do in principle: spread crypto nodes.

We can call this first project "Spread the Nodes".

BTW, spreadnodes.com/net/org is free if someone from the community wants to grab them.

(hurry)

I hear you.

But, proving to the network that a server is running a service is one of the most elementary things we have to know how to do if we want to proceed with spreadcoin's service apps.

So running a "24/7 supervised" bitcoin node sounds like a perfect contender for this test we need to do.

Sounds like the most perfect "first app"...

This doesn't mean it's the last, or the most important.
People can decide to not run this service and receive a small penalty depending on how many additional services they keep running.

I'd rather make it simple for now (we can always make it more complex in the future),
and make people NEED to run every newly introduced service on their servers or recieve a penalty (lower payment) for every service they deliberately ommit.

This would have two benefits:

1) It would encourage people to move away from those low end servers that will not be of much use to our service network anyway.

2) It would guarantee that any new service has automatically a strong network behind it, and not just a handful of nodes that decide to run it.

33Gb

https://blockchain.info/de/charts/blocks-size

Definitely,

I was never a fan on those 5-10$ per month servers... sure 10 years ago, but since I want my servers to do some real heavylifting I can't expect them to be that cheap.

E.g. ATM I run two servers with 24 GB ram each, and 1 Terabyte of space. (each has a 2x2Ghz CPU), and I pay about 60$ for each of them each month.

I did a test a few months ago, about how many daemons I could run successfully on such a machine, and I was very well able to run 20 daemons of 20 different coins simultaneously.

If you add more you then start running into problems.

But I think a single bitcoin daemon shouldn't eat away more then 10% of the ressources of such a machine, and even run on a low end server.

33 Gbyte....
and yes, that about reflects how important bitcoin is.

we have to face this, bitcoin has problems, and if bitcoin crumbles, we can all kiss our sideproject's asses goodbye.


But then I am not sure how we are going to give the people a score...

We can't have someone install say 10 different services and get payed the same amount as someone who only wants to install 1 service.

Yes, we can give people the freedom to participate in those projects (say if someone doesn't want to run full bitcoin nodes)... but this would then mean that they will recieve a smaller SN payment.

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.

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?


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

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.

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.

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:


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)

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.

I'll give you the benefit of the doubt until I understand every last byte of Mr. Spread's code. (not just syntactically but semantically)
Meanwhile I am still not going to post your pool (for now).


Thanks.

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


Best compliment I recieved today, thanks.

Yes it has been posted, but thanks anyway for mentioning it.

I am looking into YaCy and there also other ones like faroo (http://en.wikipedia.org/wiki/FAROO) and scholarninja (http://juretriglav.si/an-open-distributed-search-engine-for-science/)

But they all seem to not be very much used by anybody...
probably most of the people just got too much used to the results google gives and don't like other formats... hm...

Help them so they help us.
I like this.

If we could somehow force any servicenode to also run a full bitcoin-node, this would immediately be something of value to the whole cryptoworld, not just SPR.

More such ideas please!

Interesting question.

Running a full bitcoin node will always be a purely voluntary act.

There is also a feedback effect in work: people who are longterm invested in BTC are also automatically the people who will run a full bitcoin node (or keep on mining) indefinitely,
because for them this is like some kind of insurance.

They understand that without their help the perceived value of the BTC they hold vanishes...

So in their mind, I don't think that they need any additional incentives to do something that is healthy for the network.

So your question I guess is more about... how can we incentivise someone to run a full bitcoin node who doesn't own any BTC at all?

....

Now, if we as a network of a few thousand servicenodes could have a bitcoin node installed on each of our service nodes, than this would serve bitcoin well.
Maybe if this decentralized searchengine is also a giant decentralized blockexplorer? Then we could help all cryptocoins (we take in) and they would be incentivised to help us... by buying SPR I guess...

EXACTLY right.

I've been dreaming about a decentralized browser since the days I went "all in" on namecoin about two years ago, lol.

A decentralized in-wallet browser with blockchain access also finally makes it easy to browse those *.bit (namecoin) or...

let's say *.coin (spreadcoin) domains?



Yep, you know what... let's wait with the roadmap, I'd rather chat with you guys a little longer and gather more material.
But what I will put online later is the next immediate "TO DO" list for the month of may.