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

[defunctec]

I expect that I need another 50 hours or so to finish everything and put all the loose ends together before we can start testing it.

This could mean best case, that I will be ready in 1 week, or worst case by the end of january.

Is end of January still looking feasible?

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.

Let me get this right. By the 7th (latest) i will be able to test a service node on testnet?

If so will they have decentralised block ex?

[1714863136]

1714863136

[1714863136]

1714863136

[1714863136]

1714863136

[coins101]

...

Let me get this right. By the 7th (latest) i will be able to test a service node on testnet?

If so will they have decentralised block ex?

IMO, I don't think exact dates matter now, but it does look like testing will begin in Feb.  

Georgem has given a reasonable time window, but the more important announcements that haven't been factored and which should give this community huge confidence is that Georgem says this is going to be a full time effort and he will likely do a video update.

Back in May 2015, there were discussions about a p2p exchange. That was based around creating some form of anonymous accounts hosted by serivcenodes to create a decentralised form of Coinbase.

A few months ago Evan over at Dash began releasing details about Evolution which we now know has some similar ideas.

... they love and envy the technology so much they wanna steal it and start "DASH Classic" LOL. Good luck, losers

Just for future reference, some of the good stuff in evolution was discussed elsewhere in a reasonably similar context, before the evolution paper.



https://docs.google.com/presentation/d/19djUkzO04BhgKrh4VURFC55bI8zvo8qspSmWhJPuXrY/edit#slide=id.p

Not wishing to diminish the work being done on Evolution, though. Not in the least.

It's all good. And it's all Open Source.

What would be really interesting is to find a way to create a bridge between two crypto currencies using the serivcenodes / masternodes.  This is like currency transfers in the real world and would open up a path over the next 10-20 years for nations to adopt crpto as a mechanism to digitally transact their national fiat currencies - although that opens up problems with regulations  that might be difficult to resolve in the immediate future.

Still the Evolution work is likely to take between 12 months to 24 months and that is the timing for getting 3000 to 5000 bitcoin nodes on the network, so a few weeks to wait for testing is no big deal when the size of the prize is a decentralised Coinbase and PayPal, with an ability to exchange value with bitcoin, Dash, SPR, ETH, etc.

Crypto has never been so exciting as its about to get.

[spreadcoiner]

...

Let me get this right. By the 7th (latest) i will be able to test a service node on testnet?

If so will they have decentralised block ex?

IMO, I don't think exact dates matter now, but it does look like testing will begin in Feb.  

Georgem has given a reasonable time window, but the more important announcements that haven't been factored and which should give this community huge confidence is that Georgem says this is going to be a full time effort and he will likely do a video update.

Back in May 2015, there were discussions about a p2p exchange. That was based around creating some form of anonymous accounts hosted by serivcenodes to create a decentralised form of Coinbase.

A few months ago Evan over at Dash began releasing details about Evolution which we now know has some similar ideas.

... they love and envy the technology so much they wanna steal it and start "DASH Classic" LOL. Good luck, losers

Just for future reference, some of the good stuff in evolution was discussed elsewhere in a reasonably similar context, before the evolution paper.

https://i.imgur.com/4hZSTPN.png

https://docs.google.com/presentation/d/19djUkzO04BhgKrh4VURFC55bI8zvo8qspSmWhJPuXrY/edit#slide=id.p

Not wishing to diminish the work being done on Evolution, though. Not in the least.

It's all good. And it's all Open Source.

What would be really interesting is to find a way to create a bridge between two crypto currencies using the serivcenodes / masternodes.  This is like currency transfers in the real world and would open up a path over the next 10-20 years for nations to adopt crpto as a mechanism to digitally transact their national fiat currencies - although that opens up problems with regulations  that might be difficult to resolve in the immediate future.

Still the Evolution work is likely to take between 12 months to 24 months and that is the timing for getting 3000 to 5000 bitcoin nodes on the network, so a few weeks to wait for testing is no big deal when the size of the prize is a decentralised Coinbase and PayPal, with an ability to exchange value with bitcoin, Dash, SPR, ETH, etc.

Crypto has never been so exciting as its about to get.

I agree with you, and I know SPR has got a huge role to play.

Even though I am but a mere newbie, I dare ask if what came to my mind would be feasible for Spreadcoin:

http://oi63.tinypic.com/2s6lc3a.jpg

I guess what I'm talking about SPR having a sidechain on each main cryptocurrency...

... does it at least make any sense (coding illiterate here  )

Please, keep up the amazing work! Do your best!

[georgem]

My impatience is masking my excitement, I'm just really pumped for testnet whenever that may be. Certainly I'm glad you're taking the methodical approach as the ambitions of the project reach uncharted waters.  Gonna donate to your dev fund as a sign of appreciation for your hard work and would encourage others to do the same

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

[georgem]

Let me get this right. By the 7th (latest) i will be able to test a service node on testnet?

If so will they have decentralised block ex?

IMO, I don't think exact dates matter now, but it does look like testing will begin in Feb.  

Georgem has given a reasonable time window, but the more important announcements that haven't been factored and which should give this community huge confidence is that Georgem says this is going to be a full time effort and he will likely do a video update.

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!  

[georgem]

What would be really interesting is to find a way to create a bridge between two crypto currencies using the serivcenodes / masternodes.  This is like currency transfers in the real world and would open up a path over the next 10-20 years for nations to adopt crpto as a mechanism to digitally transact their national fiat currencies - although that opens up problems with regulations  that might be difficult to resolve in the immediate future.

Still the Evolution work is likely to take between 12 months to 24 months and that is the timing for getting 3000 to 5000 bitcoin nodes on the network, so a few weeks to wait for testing is no big deal when the size of the prize is a decentralised Coinbase and PayPal, with an ability to exchange value with bitcoin, Dash, SPR, ETH, etc.

Crypto has never been so exciting as its about to get.

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.

Maybe block explorer needs to be shelved for a while in order to start building the service network.

I'm looking at you, kid!  

[defunctec]

I'm looking at you, kid!  

lol, no means no right? 

[pokeytex]

Quick crazy question - when the test net goes live what is the length of time that we will be testing?  BTW - I am getting back on my feet and slowly accumulating. :-)

[georgem]

Quick crazy question - when the test net goes live what is the length of time that we will be testing?  BTW - I am getting back on my feet and slowly accumulating. :-)

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.

[stonehedge]

Quick crazy question - when the test net goes live what is the length of time that we will be testing?  BTW - I am getting back on my feet and slowly accumulating. :-)

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.

Music to my ears 

[georgem]

Quick crazy question - when the test net goes live what is the length of time that we will be testing?  BTW - I am getting back on my feet and slowly accumulating. :-)

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.

Music to my ears  

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.

[coins101]

...

Let me get this right. By the 7th (latest) i will be able to test a service node on testnet?

If so will they have decentralised block ex?

IMO, I don't think exact dates matter now, but it does look like testing will begin in Feb.  

Georgem has given a reasonable time window, but the more important announcements that haven't been factored and which should give this community huge confidence is that Georgem says this is going to be a full time effort and he will likely do a video update.

Back in May 2015, there were discussions about a p2p exchange. That was based around creating some form of anonymous accounts hosted by serivcenodes to create a decentralised form of Coinbase.

A few months ago Evan over at Dash began releasing details about Evolution which we now know has some similar ideas.

... they love and envy the technology so much they wanna steal it and start "DASH Classic" LOL. Good luck, losers

Just for future reference, some of the good stuff in evolution was discussed elsewhere in a reasonably similar context, before the evolution paper.



https://docs.google.com/presentation/d/19djUkzO04BhgKrh4VURFC55bI8zvo8qspSmWhJPuXrY/edit#slide=id.p

Not wishing to diminish the work being done on Evolution, though. Not in the least.

It's all good. And it's all Open Source.

What would be really interesting is to find a way to create a bridge between two crypto currencies using the serivcenodes / masternodes.  This is like currency transfers in the real world and would open up a path over the next 10-20 years for nations to adopt crpto as a mechanism to digitally transact their national fiat currencies - although that opens up problems with regulations  that might be difficult to resolve in the immediate future.

Still the Evolution work is likely to take between 12 months to 24 months and that is the timing for getting 3000 to 5000 bitcoin nodes on the network, so a few weeks to wait for testing is no big deal when the size of the prize is a decentralised Coinbase and PayPal, with an ability to exchange value with bitcoin, Dash, SPR, ETH, etc.

Crypto has never been so exciting as its about to get.

I agree with you, and I know SPR has got a huge role to play.

Even though I am but a mere newbie, I dare ask if what came to my mind would be feasible for Spreadcoin:



I guess what I'm talking about SPR having a sidechain on each main cryptocurrency...

... does it at least make any sense (coding illiterate here  )

Please, keep up the amazing work! Do your best!

What a really interesting chart.  Its got the brain cells working away faster than normal. There is a mention of side chains with bitcoin in the PoBN white paper, but if Dash were to add support for side chains, then that opens up so many opportunities for every project. Great contribution, thanks.

[sirazimuth]

Looks like big difficulty drop. Whats up with that?
Fire up the spreadminers folks!

[dominuspro]

Looks like big difficulty drop. Whats up with that?
Fire up the spreadminers folks!

I guess ETH is taking miners at the moment

[coins101]

Looks like big difficulty drop. Whats up with that?
Fire up the spreadminers folks!

I guess ETH is taking miners at the moment

I have been trying to find some time to mine ETH, so I can sell for SPR.  Those SPR miners by Wolf0 make it tricky to mine direct.

The main issue that's stopping me mining ETH is of my own making. I have managed to brick four rigs because I left them unused for a few months in my cold garage which i had vented for mining, and I guess some of the rigs just want to be kept nice and warm.

[stonehedge]

@georgem

On the developer slack channel there have been numerous conversations about whether PoBN would be open to abuse by service node operators running multiple full bitcoin nodes sharing a single blockchain.

I have been doing some research into this over the last few days and I think that it isn't necessary to require cryptographic proof that a bitcoin node is using a unique blockchain copy.

Bitcoin Core (and XT for that matter) uses a database lock which locks the Berkeley Database when a blockchain is mounted and prevents another instance from connecting to the same blockchain copy.  This lock was put in place because if you have multiple bitcoin instances reading/writing to the same blockchain, near instant corruption occurs stopping synchronisation and forcing a reindex.

It is possible to over-ride the lock by deleting the lock file and opening another instance but blockchain corruption is rapid, almost instantaneous.

Does this mean that if a service node is scoring well in quality of service and has an up to date block height it can be trusted as a unique node?  

[coins101]

I like the scoring approach because it makes use of a  unique set of circumstances we have access to: a second tier where you can introduce queries and additional checks to validate against fake nodes.

One of the things you can do, for example, is triangulate ping and query response rates. If I ping nodes in my immediate network I can record the ping times of my group of connected nodes.  If I ping and query, the query times should have some level of correlation, unless you are running a fake node. A fake node has to send a request to another node (hey, AnotherNode :-)) in order to get data to respond to the queries it is being asked for.  Do this enough times and you will be able to figure out who are the fake nodes, but even if they are not fake you can score them down.

If you add random ping and qurry rules into the equation, then you can avoid someone trying to game the ping and queries by running 5:2 bitcoin full nodes to fake nodes.

[stonehedge]

I like the scoring approach because it makes use of a  unique set of circumstances we have access to: a second tier where you can introduce queries and additional checks to validate against fake nodes.

One of the things you can do, for example, is triangulate ping and query response rates. If I ping nodes in my immediate network I can record the ping times of my group of connected nodes.  If I ping and query, the query times should have some level of correlation, unless you are running a fake node. A fake node has to send a request to another node (hey, AnotherNode :-)) in order to get data to respond to the queries it is being asked for.  Do this enough times and you will be able to figure out who are the fake nodes, but even if they are not fake you can score them down.

If you add random ping and qurry rules into the equation, then you can avoid someone trying to game the ping and queries by running 5:2 bitcoin full nodes to fake nodes.

You could even throw a random transaction verification into the mix.

[coins101]

I like the scoring approach because it makes use of a  unique set of circumstances we have access to: a second tier where you can introduce queries and additional checks to validate against fake nodes.

One of the things you can do, for example, is triangulate ping and query response rates. If I ping nodes in my immediate network I can record the ping times of my group of connected nodes.  If I ping and query, the query times should have some level of correlation, unless you are running a fake node. A fake node has to send a request to another node (hey, AnotherNode :-)) in order to get data to respond to the queries it is being asked for.  Do this enough times and you will be able to figure out who are the fake nodes, but even if they are not fake you can score them down.

If you add random ping and qurry rules into the equation, then you can avoid someone trying to game the ping and queries by running 5:2 bitcoin full nodes to fake nodes.

You could even throw a random transaction verification into the mix.

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.

[georgem]

On the developer slack channel there have been numerous conversations about whether PoBN would be open to abuse by service node operators running multiple full bitcoin nodes sharing a single blockchain.

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.

I have been doing some research into this over the last few days and I think that it isn't necessary to require cryptographic proof that a bitcoin node is using a unique blockchain copy.

Bitcoin Core (and XT for that matter) uses a database lock which locks the Berkeley Database when a blockchain is mounted and prevents another instance from connecting to the same blockchain copy.  This lock was put in place because if you have multiple bitcoin instances reading/writing to the same blockchain, near instant corruption occurs stopping synchronisation and forcing a reindex.

It is possible to over-ride the lock by deleting the lock file and opening another instance but blockchain corruption is rapid, almost instantaneous.

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.  

Does this mean that if a service node is scoring well in quality of service and has an up to date block height it can be trusted as a unique node?

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.

You could even throw a random transaction verification into the mix.

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