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

Are there anymore details out about the masternodes for spr ?

Im not new to crypto but im new to masternodes and server nodes , and there pretty confussing its almost the same like staking right
masternodes ?

How much coins will you need ofr one node ?

The Easiest Way to Run a Full Bitcoin Node: Bitcore Comes to the Microsoft Azure Cloud

25 JANUARY 2016 ENGINEERING

Earlier this month Microsoft announced our addition to their new blockchain as a service (BaaS) platform hosted on the cloud service Azure. Our open source Bitcoin full node and development platform Bitcore is the first Bitcoin service available for Azure users.

Run A Full Bitcoin Node in the Cloud

We built Bitcore to lower the barrier to entry to Bitcoin development. Whether you want to help build Bitcoin's peer to peer network or build better Bitcoin infrastructure for your company, running a full node is the best way to get started. Running Bitcore on the Azure cloud will make hosting a node even easier by getting rid of the need for local, dedicated machines.


https://blog.bitpay.com/bitcore-for-microsoft-azure/

If only there was a way to fund the hosting 

I'm liking the idea of a type of  PoW for block chain validation.

Thanks for the info.

Challenge accepted

Those would have to be special custom versions of bitcoin daemons, to be able to link with the same blockchain.
(only one would be writing, and the others would be in readmode, answering to external nodes. They would be mere mirroring/echoing nodes. They might alternate this assignment with one another.)
To the rest of the bitcoin network they would appear normal, except that they would have this unnatural synchronicity ( no time or height differential whatsoever)

Shouldn't be that hard to create even for an average dev.
He would have to remove any locking restrictions from the code, and remove any update/writing capabilities.
He would keep everything in there that is for listening and answering requests, like getheaders, getdata, getblocks, etc..)

If you have access to a server with 2 IPs and network storage maybe you can run a test and see what happens. (It won't work)
Maybe someone could create one of these mirroring/echoing-nodes until it indeed works?

That would be quite interesting to see.  

I'm talking about somebody runnning 500 bitcoin daemons as full nodes from one copy of the blockchain with 500 service nodes.

So, someone whose goal it is to reuse one bitcoin node (blockchain) for 500 servicenodes, so he can save costs,
is actually doing a disservice to both the bitcoin network (which requires as many distinct full nodes as possible)
and the servicenode network (whose services require high decentralization and the resiliance that follows from it).

Let's see how this goes.

For BreakThrough 1 I can't concern myself with solving this problem yet.

All I know is that this scenario you describe is a very artificial one anyway, and most distinct servicenode actors will run distinct servers with distinct full nodes anyway.

No he wouldn't. Well he would distribute those 500 fake bitcoin feeds to the spreadcoin network, so that they can be used within the blockexplorer.

But this single bitcoin node isn't mirrored 500 times to the rest of the bitcoin node network.

To the outside "bitcoin" world, this one bitcoin daemon is still just one bitcoin daemon.

Remember, we are not interfering with the bitcoin daemon in any way.
You are talking about someone who runs 500 Servicenodes that reuse that same single bitcoin node as data feed.
Servicenodes don't communicate with the bitcoin network.
We are our own network.

We are grabbing bitcoin data for our decentralized blockexplorer.

That's the first service.

That person would still be providing the service of 500 bitcoin nodes.  That in my opinion seems better for Bitcoin than not running 500 nodes although the decentralisation issue is serious as you say.

It's a question of decentralization.

The effect of his blockchain having some kind of error (or being manipulated) will immediately affect 500 nodes.
This guy just restarting his server farm will be "felt" by the rest of the network. (and I mean spreadcoin network)


A person that doesn't run any node isn't part of the servicenode network anyway.
I expect that someone who runs such a large amount of servicenodes will run into many problems just from a micro-management point of view.
I'm looking forward to actually seeing someone try to run that many servicenodes in this "bot-net" like fashion and how he will keep hackers away who will see him as the easiest target available.

I confused myself.  It has been a long day.

Exactly, you just answered your own question.


That's what confused me, I thought we were obviously talking about uniqueness the whole time.

So, if somebody has 500 nodes running off one valid copy of the blockchain on appropriate hardware, is the impact on network resilience the only concern or are there other problems caused by this too?

Is somebody running 500 decently performing nodes from one blockchain copy better or worse than that person running no nodes at all?

I'm not moving the goalposts.

All you had to do was point out that proving that a node has correct data is different to proving that a node is unique.

Veracity?  

Veracity has been solved a long time ago by the decentralized P2P distribution of a PoW secured public ledger.


It's a trustless system.

Listen, you can't keep moving the goal posts like that.
We were talking about uniqueness (and its many facets, like availability, connectivity and storage).

Why bring in veracity?

Fairly hardcore.

I have a facetious question.  With all of this talk about it not being possible to prove the veracity of a bitcoin node, why should somebody trust bitcoin?

To get a glimpse of how hardcore the solution of PoBN might look like, take a look at some posts of this mad scientist here:

https://bitslog.wordpress.com/2014/11/03/proof-of-local-blockchain-storage/

https://bitslog.wordpress.com/2015/09/16/proof-of-unique-blockchain-storage-revised/

Abuse is the wrong word.
PoBN (Breakthrough 3) wants to find a way of proving unique storage of a blockchain.
(The key word here is storage. It is neither about availabilty nor connectivity or anything like that.)

So the worst thing that can happen without PoBN is that blockchains are reused within the network,
meaning that the actual number of full nodes would just be an illusion, appearing more numerous than they actually are.

But that is a known ongoing problem with all cryptocurrencies, and nobody has yet found a solution.


File locks don't prevent other instances from connecting to the same blockchain copy.
That's why UBA is easily able to read out "locked" blockchains.
It's merely the write/update process that is tied to a certain process by a lock.
And even this access restriction can easily be circumvented within the system by using a more privileged user or processes with higher priority levels.

Look at a lock file as something like an "etiquette", where one process is claiming temporary ownership of a folder/files and expects other processes to respect this.
Basing security on such a superficial approach would be ridiculous.  


Again, PoBN is about BreakTrough 3, which is a hard scientific problem, and that's why it's far in the future and low priority right now.

The "Uniqueness of a servicenode" I'm currently working on for the upcoming decentralized blockexplorer (BreakThrough 1) is based on (and enforced by things like)

1) collateral
2) IP
3) how other servicenodes/UBA score your "contributions" to the network

Note that this concerns the uniqueness of a servicenode regarding its availability and connectivity, and not the unique storage of blockchains.


I'm sorry, but this problem is not gonna be solved by just throwing stuff at it.

I suppose that if you introduce segregated witness into the equation, you can ask a node to sign message with the hash of the last 10 confirmed blocks and then sign a hash of the same blocks with the signatures in.  Add that to the random ping, query,  verify and Fake nodes should have a hard time keeping up.

There is also push pull data validation you can add on top: If you ask a node to keep track of the data it pushed out, you might b able to triangulate that by others confirming how much data they got from a node.