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

Cheers mate.

brilliantly summarized by stonehedge.

Thanks.


merge-mining is only possible within the same hashing algorithm, in our case SpreadX11 only.

Spreadcoin Project Weekly Update #1

7th August 2015

Improving Communications

Following some fair feedback from the community, the Spreadcoin team acknowledge that community engagement hasn’t been strong enough recently.  To improve communications we aim to publish a weekly update every Friday.  These updates may be long or short depending on what there is to say.  After a discussion in the development channel on Slack, the team agreed that the updates should meet the following standards:

•   The updates will use the least amount of developer time possible.
•   The updates will be non-promotional in nature.
•   The updates will be factual and open.  If there is no progress or a problem, we will say so.

Project Objectives – A Brief History of Spreadcoin

As many of you know, Spreadcoin was originally intended as a fork and rival of Darkcoin.  When the original Lead Dev walked away from the project, Spreadcoin was just about to begin the second round of masternode testing.  A dedicated core of Spreadcoin supporters started to look at the code in more detail and began to realise that Spreadcoin had much greater potential than simply trying to mimic the functionality that Darkcoin/Dashpay already provided.

After several months of furious Slack activity a new fundamental approach was agreed.  Spreadcoin, using a two tier network with Service Nodes, can be used to provide a huge variety of decentralised applications and services whilst rewarding the owners of Service Nodes for doing so. 

It was agreed that the first service to be provided by Spreadcoin Service Nodes would be PoBN or Proof of Bitcoin Node.  PoBN is simply a mechanism to help the Bitcoin network combat the declining number of full Bitcoin Nodes by financially incentivising Service Node owners to also run full Bitcoin Nodes.  What better way to start your project than to offer some support to your mothership?  The next service has not been agreed but the many options range from file sharing applications to decentralised altcoin exchange.

What Have the Dev Team Been Doing Since Relaunch?

Over the last few months Georgem and Chaositec have had a mammoth challenge to tackle.  Whilst Spreadcoin was originally a Darkcoin fork, large amounts of code had been rewritten by the original lead developer. This included a total re-write of the masternode code.  It is vital that the new dev team gain an understanding of what is in the code and why it is there.

The crypto community has seen several Darkcoin/Dash copy and paste clones come and go over the last few months but the Spreadcoin project will not sacrifice quality for pace.  Nothing will be released until the project team are satisfied beyond reasonable doubt that the code is stable and appropriate.

Every day has thrown up surprises in how the code works.  A fact that astounded me personally is that Spreadcoind conducts five million operations in the first 10 seconds of execution.  Understanding your product is necessary before release, even into testnet.

The focus over the past few months and for the near term future will continue to be reviewing, understanding and improving the fundamentals that are already there.  Spreadcoin is doing something that nobody else has done before and the intention is to do it properly.

Dev Team Activity This Week

The dev team have been working on a tool to assist with the analysis of the operation and efficiency of Spreadcoin.  This tool has the ability to capture the literally millions of things that happen when Spreadcoin is running but also gives the ability to filter spurious information and to help identify algorithmic solutions to problems.  This tool is taking a lot of dev time at the moment but is expected to pay dividends in the near future as it will allow the dev team to simulate scenarios and code changes which we believe will speed up the testnet process and main net launch of Service Nodes and PoBN.

The new tool helped Georgem spot this bug on August 5th https://bitcointalksearch.org/topic/m.12063817

Progress on Testnet & Updated Roadmap.

As of today, it looks like the first implementation of Service Nodes in testnet will be empty Service Nodes that are limited in their number by coinsupply/2880.

Whilst some members of the dev team have been testing and investigating the interaction between Spreadcoin Nodes and Bitcoin Full Nodes on the same VPS instance, the community must understand that the path to our first functioning service will be taken in small steps.  However it is important to stress that each step will help trigger the next step at an increasing pace.

When Service Nodes are ready for testnet we will depend on the community for help with testing.  We are excited for when that process can begin.

A new roadmap will be included with next week’s update to give an indication of our current view of the steps and timescales involved.

Other Activities of Interest

Coins101 and others have put a lot of work into a thorough whitepaper and press release that gives full details on our plans for PoBN.  This whitepaper has been reviewed by the dev team and the SPR community and has now been sent to a wide range of peers including current and past members of the Bitcoin foundation for comment.  We expect to release the whitepaper (version 1.0) within the next two weeks.

Chaositec has announced the Beta of his new mining pool which will soon have Spreadcoin payouts.  Chaositec is currently somewhere in the North Sea so expect to hear news from him when he’s back in the world of the internet.

Coins101 has proposed a competition to use vanitygen to find a Spreadcoin address beginning with SatoshiNakamoto.  The proposal is open to community debate.  Please express your view if you have one!

Questions from the Community

Future editions of the weekly update will have a summary of questions asked by the community in the previous week.  I will also collate the questions for the purpose of creating a FAQ in due course.

And finally…

Apologies for the verbosity of this update!  We feel that it was important to make the first one comprehensive.  Questions and criticisms are welcome, either on BCT or by PM to Stonehedge.  Expect a shorter update with more from the dev team, none of the history and an updated roadmap next week.

-Stonehedge

Fascinating idea... would that merge-mining work with X11 or SHA256 coins also? Perhaps with additional programming efforts?

I was thinking that in the future, since spreadcoin is solo-mineable and pretty hard to mine, we can introduce merge mining that will allow other future coins (that are based on SpreadX11) to be merge-mineable with eachother (or atleast with Spreadcoin).
This will give solo-miners a little bit more income possibilities.

There will be a special solo-miner software that will bring all SpreadX11 coins together, facilitating merge-solo-mining.

Since spreadcoin can be considered a think tank, when we have a nice idea that can't make it into spreadcoin (for whatever reason), why not create an additional coin, and make it merge-mineable with spreadcoin?
This is all just speculation, but a possible path we could walk. (Just opening doors and windows here....)

I am very interested in this statement: "make such sideproject coins merge-mineable with spreadcoin". How would you describe such a feature? Could you elaborate on the "merge-mineable" aspect?

I've been wondering if something like that could be possible but I never heard anyone say it. Before I jump to conclusions it would be great if you could elaborate on the idea for just a minute. Much appreciated

VanGen Competition is definitely going to happen. But we will already have a servicenode network by then.

I left the round2 masternode client unchanged.
Only corrected master and newwallet.

Aren't you supposed to be on holiday? 

I'm with AnotherNode.  I think we'd be foolish not to persue the vanitgen idea.  However as Coins101 says, we'd be even stupider to prioritise it over the work that the devs are currently doing.  In my view we either consider finding another pair of hands to help or implement this idea at a later date.

@coins 101...yes, could well be although I suspect the issue is more likely to be that the hardcoded testnet nodes have been powered down.  If I get a chance this weekend I might create a testnet node on vps.

^ any changes to rewards require dev time, so this can wait until service node testing begins.

@stonehedge, the issue just fixed by georgem with source connections could be why I couldn't connect using the round2 masternodes testing client?

Everyone has been busy testing Dash V12 but now the release is delayed. I'm catching up and reading through the last few pages of the thread and can anyone tell me what happened to the finding Satoshi vanity generator competition? It is one of the few brilliant ideas that I really like around here that can be started without waiting around.

Looking at everyone's posts, there seems to be consensus that it is a good idea, including what looks like tentative agreement by the devs, but there is a problem using mining rewards? lordy consensus is always king \o/

The Dash community has no issue with using mining rewards to support and promote Dash. The miners are now taking far less with no complaints.



https://www.dashpay.io/news/self-sustainable-decentralized-governance-by-blockchain/

I would vote for 10% of Spreadcoin rewards going to the find Satoshi vanity generator competition :-P

As does Sunny King, for PeerCoin.


Cheers

Graham

I do agree with you but the intention of these updates are that they are very short if there isn't much to say and longer if there is lots to say.  I would personally post a short summary every week because people don't tend to read more than one or two pages back on BCT.

Ultimately I'll go with whatever the dev team feel is more appropriate whether that is biweekly or every week.

Biweekly report would be sufficient until SN is about ready at testnet.

Great idea.  I'll have a think about the best way to capture these questions.  Cheers!

Good idea!

Maybe include a questions from users section?

I have just put a proposal to the devs that they update me every Thursday on Slack with a view to me collating and providing a full community update on BCT every Friday.

I want this update to include a clear snapshot of the roadmap and the project's progress against it and a summary of what the dev team have been working on, problems encountered...bugs found...new ideas...development progress.  I like project updates to be PR free and consist of simple factual statements.  Obviously these updates will contain good news and bad news about the project as it progresses.

Does anybody have any suggestions on anything else that should be included?

I second this or something of the like that provides some transparency into development progress.  If the aim was to have servicenodes ready by the end of July and there is no mention of progress made, hangups, or a revised timetable by that time, investor confidence= shaken.  The outward appearance is nothing has been accomplished, because if anything had been why would it not be promoted?  If methodical and meticulous work goes into a exceptional product that misses a deadline by 6 months, fantastic.  no complains here.  It just would be nice to know the work is ongoing and to what extent.

I just realized there is sometimes a problem with the wallet (both old and new) and how it connects to the 9 Fallback-Nodes.
Seems to be a problem that has been here since atleast when Spreadcoin started over a year ago.

I fixed it, both in the master and newwallet branch, and the sourcecode is updated.

https://github.com/spreadcoin/spreadcoin/commit/2d96865d6bd4faa0a22318989bccb9186fd2c60e
https://github.com/spreadcoin/spreadcoin/commit/50122c5b299705407074dcc96efcf66b4a571c02

Give me a few hours to also recompile all the wallets and then the Connectivity with Fallback-Nodes will work much better than it used to.
So that's why we still get some people complaining about no block source. But this is now a thing of the past.

(What did I do? I Reduced waiting time for considering Fallback-nodes to 20 sec (instead of 60 sec),
plus there was an error in the condition that triggers Fallback-nodes....
if addrman.size()==0 doesn't make sense because sometimes the program will even consider 127.0.0.1 (localhost connection with itself) an address (and sometimes even [:::] - whatever it thinks that is), and then addrman.size() is already  = 1 or 2 and the condition to connect with the Fallback-Nodes will never be met, that's why I changed it to addrman.size<=2)