Coming soon, bear with me!

Thanks, I have the same opinion about the community here.

Sorry for not being very active here right now.

big update coming soon.

 

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.  

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.

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.

Exactly, you just answered your own question.


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

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?

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.

Absolutely.

Each successful testnet version should immediately be converted into the next mainnet version.

So when we are at testnet version2, we will simultaneously have moved to mainnet version 1.
Starting testnet version 3 means we are now at mainnet version 2,

etc

That's how its supposed to run, if we are to get the maximum network effect out of our ongoing development.

But it's ofcourse entirely possible that we will have a few isolated testnet versions inbetween, before we think that's now worthy of a new mainnet version,
like when we try to solve a particular persistant problem.

But then again, that's why I do lots of preliminary testing in my private network.

There's no need to engage the whole community in my debugging sessions, that wouldn't make sense.
No, testnet means we are testing something that I think is already pretty stable and now ready for a fieldtest.

Well, we will follow standard procedure: Test until we have a stable functioning version,
and try to bring it as quickly as possible to mainnet, even if it is not 100% complete (functionality wise).

It's important to start building a strong network as soon as possible.

Yes, that's a pretty neat idea, with like mindboggling potential.

I say once we have achieved a BreakThrough (see roadmap), we can always slightly adjust the roadmap to factor in new ideas (research areas), before we continue to the next BreakThroughs.
It's good to be that flexible. But it's also absolutely necessary to keep working rigorously towards the nearest goal!

Without deviation.


I'm looking at you, kid!  

Yes, I couldn't agree more.
Currently I have to juggle too many priorities (spreadcoin community, my customers, private life), and everybody is pretty anxious to get my full attention.

I'll do the best I can to not worsen the situation (by NOT adding more factors into the equation) and the goal is to basically turn spreadcoin community into my main customer soon (thereby reducing the factors).

It should get pretty interesting to see how this will look like: to work for a community as the dayjob!  

Thanks!
There is nothing more motivating than receiving donations in SPR!
So yeah, I highly welcome additional encouragement of this sort!

Being creative like that is fun and relaxing, so when spreadcoin has replaced my dayjob, I'll keep creating animations in my freetime, why not.
Can't wait to show you some of my music too.  

I don't wanna be one of those savant syndrome coders... very good at one thing, but still an idiot.  

My approach to everything is very interdisciplinary!

Pretty much.  

I was able to do about 50% of what's still needed.
If might not be able to finish the other half in the next week (collisions with dayjob), so it might slide a few days into first week of february.

I'll probably create an explanatory video about current state of overlay network and how the blockexplorer behaves, so you better know what the problems are I'm working on.

I owe you that much.

I love how activity seems to follow the "sunrise" terminator line.
But not sunset?
hm...

what is this anyway? It's not WW3, I know that much.

Thanks, looks right.

please post only in our forum, it might be considered spam if we post what might look like "gibbrish" to moderators here.

Just copypaste the string without any tags at all to http://spreadcointalk.org/index.php?topic=731.0