Three quick notes:
1. Over time the amount of collateral to run a tron/throne may change -- this will be decided based on tron voting / node voting capability inherited from Dash which will be implemented soon.  The preference of the team is not to change the collateral amount until after the meeting in Prague at the end of April and the release of the API. 

2. Please refer to the previous post I put up regarding how to think about the value of a Tron (not a throne -- we need to leave that behind, a throne sits still -- but the goal is to shift to an active node providing applications as well as transaction confirmation)... owning a single Tron gives the operator what may be thought of as a "franchise" to develop and offer applications in the cloud.  In this second phase (API enable Crown, but not the core updates yet), the focus is really on starting to build a community of node operators and application developers.  So once this community starts to come together, I think we will be able to start to think about what the "right" collateral amount for a "node" and what sorts of applications are working well or not. 

3. My guess is that if one doesn't have the capital for a tron or throne, other options will emerge for fractional ownership - as they have with other coins with masternodes... it's a business opportunity for someone. And if you have some skills or interest in coding, developing/packaging applications to work with the API and run "on" the network (on the network probably doesn't literally mean in the same VM or VPS instance as the core for a number of reasons -- but that would be up to the node operator). 

So if one is interested in CRW but the price rise puts owning and operating a throne out of reach for now -- please keep an eye on the thread and we hope to have our API in a form where people can start to play with it and learn soon.  Then, if it works, that opens up a way for developers to capitalize or profit from their skills on the network -- and that's one of the things that the core team is excited to be able to do.

Just want to jot a note, and say that from my perspective one shouldn't look at the tokens as an investment -- but an experiment.  If you understand what the experiment is, and want to take part in it -- then you can accumulate tokens in different ways, but the easiest way is to buy them.

The ideas behind the experiment are outlined at a high level in a brief set of papers, the Crown Papers, which are available on the website.

The implementation details of the project are a work in process.  The next step will be the release of an API which will handle the "conversation" between applications and the trons (nodes) managing them.  The API will enable an application economy, in which trons will offer applications, developers of applications will negotiate revenue sharing arrangements with the trons running their applications and users will be able to pay for the applications using CRW.  The purpose of the API isn't to be a tool for the core team to develop apps and make money -- it's will be a tool that just comes with the platform and is there to enable node operators and developers to build businesses or experiment with.

While the Tron Operator and Developer community is getting comfortable with the API, work will continue on tightening and accelerating the functionality of the Crown core, which will just be focused on keys and transactions - nothing else to distract it.

And along the way there will be a steady drumbeat of other features being integrated in different ways -- Infernoman has a nice list of what he knows he wants to make sure we get baked in.  And we will welcome ideas from the community -- while the broad plan is set -- the details/implementation of anything can almost always be improved.

I bring up the API and quote LucD88's reference to the throne yield calculations just to illustrate that while the throne returns from the block rewards are interesting -- the real opportunity for the platform will be building out applications and uses.  The thrones will be able to earn revenues from the applications they provide -- and this is important to note -- because if the project is core team is able to build what is envisioned - then each throne is functionally a cloud service provider and depending on the configuration and tools utilized by the tron operator -- one throne could be, effectively, an elastic service provider.  Because the thone gets a proportional share of the block reward -- but in the application sharing, the bulk of the revenues will go to the tron which provides the compute capacity for the application....

This is why Stonehedge's post about how he has built and has his tron's running as a primitive "tron swarm" is probably worth going back and reading if you are curious.

Since, the "marginal economic value" of a CRW token will arguably be the price at which a node operator would buy the token to place in collateral for operating a sort of "crown cloud franchise" versus letting it be used in exchange -- the bottom line that this whole discussion maps back to is what a reasonable price for a token might be.  And that will depend on the vigor of the application economy which entrepreneurs set up on the Crown platform... which hasn't happened yet.

But that's kind of how I think of it and it gives folks a little bit of a structure for trying to figure it out for themselves.  As stated -- this is all an experiment which is in process -- and to an extent it's success will depend on having enough people believe it will be successful to work to make it successful.

The encouraging feedback from the market price at this point isn't that the team has accomplished their goal yet -- but it is that some of the folks out there watching are starting to believe.  Now the team has to deliver.

The local wallet is used to send a signal to the network initially that a "throne" is up and available to be included or "logged in" to the network.

Once the throne is logged in, payments to that throne are independent of the local wallet -- you might want to check periodically to make sure the "throne/node" is still up and "logged in" -- but otherwise there's no dependency on the local wallet.

Just to add to what defunctec said -- if you just analyze the "crypto" universe as an industry -- bitcoin was a proof of concept for a system... that's all, it was meant to evolve in ways that it hasn't but still may.  Traditionally, when a major new technology, like what I think we all believe these "crypto" systems are, well, you have an explosion of systems and then there is a consolidation process.

Often this gets characterized as "bubbles" -- but that's not quite right, but it's worth remembering that in any innovation cycle, much of the capital invested is destroyed because most of the businesses that are created to pursue the opportunity end up getting destroyed:
 https://www.youtube.com/watch?v=K-NXDCXzrao

So if one is going to wade into the "deep end" of an innovative new technology, you need to ask what your edge might be... and what if any edge your team might have...

In the case of Crown -- we would like think that we have an edge from just looking at the platform as something which provides business opportunities -- not an opportunity itself but a vehicle on which businesses can be built and operated.  Not just one sort of business or product -- but a lot of different ones... So maybe that's #1.  But then you can look around and convince yourself that other people are doing that... and you can run through any single thing and it's not really clear that anything is necessarily unique.  There are a lot of smart people trying to solve this problem and it's foolish to assume that there aren't smarter people or people with better ideas and or skill out there... but,

What no one seems to have really created is a truly distributed collaborative community and token -- where as entropycoin points out, it doesn't depend on any one person...

And then if you think of building a distributed collaborative culture as your differentiator -- one might imagine a world where one mechanism at play in the consolidation phase would be to create a team that could attract developers and some of those very smart potential competitors to collaborate with Crown (since it's open source, there is no reason that whatever we build at Crown can't be borrowed by anyone else - just as we have borrowed from others, so the code can never really be a final differentiator -- it's just a cost of admission).  To have Crown be a place where people can try out ideas and develop skills, experiment with new things, and learn from and enjoy the folks they are working with...

That experimentation is also essential -- if you believe that there is anything to evolution -- because the way evolution and a lot of technology really seem to work is trial and error -- so we want to be able to run as many experiments (safely) as possible on the Crown Platform -- and if that happens then there is a chance we will start to learn from those experiments and the development process and usefulness of the token accelerates...

crowncoin_knight sometimes suggests this is being good guys... arguably it's more of just don't be an asshole (having worked in finance for too long as made me suspicious of anyone claiming to do good - so I prefer and trust people who are just working hard not to be complete assholes most of the time)...

thanks for noticing...
 

in terms of what DApps would be most successful or useful -- I don't think any of us really know, but I would offer a few simple observations to help you thinking about the issue -- these examples are meant to be illustrative/informative of potential ways that the functionality we are trying to achieve could be implemented:

1. Just think of it as a client - server network that is cryptographically secured using the key pair and verification capabilities in the Crown Core.  So, what can a secure open client server network be used for?

2. The first stage of applications are likely to just be a migration of services or applications which you have elsewhere onto the platform because it is less expensive, more secure, or ideally just better.  For this first layer of applications, just imagine if you could spin up a docker container of any application that is easily containerized in a single container... don't know if docker will be used, but there will be some sort of containerization and orchestration capabilities which will be able to be used with the API.  Imagine that initially all these simple apps are free to use, but that as the system evolves there would be different purchase models for different applications.

3. Each node operator will have discretion over and responsibilities for applications running on their node/tron.  So there will need to be a service discovery and connection protocol, because users will be selecting a service and a node to run it on.  

4. The application interface will just be a browser window.  In the papers the "temporary mode" of Crown is referred to as the journal.  Functionally, the best way to think of the "journal" implementation is probably just as a browser with a Crown Journal plug-in/extension -- or that is probably the quickest way to implement it.  It's tempting to imagine a customized browser -- but that is probably overkill...

5. No computation is happening on the blockchain.  The blockchain is just being used for transactions & keys -- that's what it for and what it is best at.  The blockchain is permanent -- but the application uses are not.  

6. So what we are talking about isn't DApps like Ethereum has popularized them.  We are just proposing that one might be able to offer the existing applications that are out there, but in a more secure and efficient way.  And we would like to invite developers to come to our platform as a marketplace for their applications over time -- since we would ideally offer access to a global user base, instant payment and our platform doesn't need to charge excessive fees to provide returns for venture investors...

7. In terms of what you would be able to do on this platform -- well, it's a general purpose platform for compute, communication and commerce.  You have integrated payments and you can do whatever you would with any server, as long as it has been packaged as a service by one of the Trons/nodes.  The services themselves may run on the actual machine which is also the machine running the Crown Server software we call a Tron, or it could just be another VM/machine/container which is controlled from the Tron or just contracting with the Tron.  That will be up to the operator of the Tron -- as are the costs of services offered by that node/Tron.  The nodes are thus each really running as cloud service providers, with access and payment managed through the Crown Network.  

8.  There are a number of logic flaws in the DApp model as it exists now -- and they are probably fundamental.  The biggest issue with the DApp model is that by creating a true distributed application framework Ethereum has created an instrument for CENTRALIZATION -- not decentralization.  This is because the point of centralization is in the control structures and logic in the DApps which can't be shut down.  This logic flaw is precisely why Ethereum and clones of it are of interest to corporations -- because a DApp is a perfect instrument for someone to project control through programmatic means.  In this way, I think we all need to consider whether DApps --as appealing as they may sound actually achieve the opposite of their intended object -- or whether there might at least be some unintended consequences.  It would seem we should be open to logic flaws in this system since the existence of last years fork is a sort of testament to one of those logic flaws, and that was just an operational detail -- not the larger ones that scare me.
  
9.  General purpose platform for compute, communication & commerce.  That's a key to really think about.  The value of a currency is from its many uses -- money is useful because it removes the coincidence of wants which constrains a barter economy.  So the best way to create a valuable currency is to create something with many uses... a sort of leatherman tool.... But the other quality of money is that you have to have a community of users -- you can't just build something perfect do an ICO and expect everyone to come -- you have to build the code and the community together and we all have to have ownership.  It has to be shared.  

10.  Anyone launching a coin with a single use, or focus, by definition may be a genius coder -- but they are economically stupid and don't understand what a currency is or why money exists. Anyone doing an ICO also faces an uphill battle because they also don't understand money, and the fact that it's value is socially constructed and that it also needs to be broadly distributed to those who find it useful to be of value -- money does not appear in a voila or unveiling -- or if it does it is meaningless, has no social construct supporting it.  

11.  So this general purpose platform for compute, communication and commerce -- just simply offering this platform as a creative canvas to the community --- that's the key. And if we can attract creative entrepreneurs -- then there is no reason that someone couldn't run a VOIP phone service from a Tron, or a virtual desktop, or run a machine learning / data science server service.  You could just stream video from India or Philippines to expats for a subscription fee...etc  

12. The business model of the core team is that the business of the core team is to provide this canvas.  We will not compete with service providers who are operating outside a set of "utility applications" -- the utility applications will need to be explicitly defined and this will be done through the proposal system Crown inherited from Dash. This commitment of the core team not to be in the application business but to provide an application platform on which entrepreneurs can build businesses is another important feature discussed in the papers which I don't think anyone actually read...   If you think about the business opportunities on and around this sort of platform there are three broad opportunity sets: (1) node operator / service provider, (2) application developer, (3) onboarding & bridging.  The first opportunity is just starting to be implemented; the second opportunity will become active once the API is defined and we will be starting to test it -- so this starts before the code update which pushes the API and other changes out to everyone; the third opportunity set is the one most often forgotten but essential -- how do people get money into Crown?  how and why would a merchant adopt crown in a community?  how do addresses get registered so that they can be used in the future to hold other assets as regulators understand how blockchains lower oversight and compliance costs?  what are the opportunity to move different real world economic transactions and businesses onto the network over time?  

So that's kind of the idea.  General purpose compute first -- then probably communication, and then once we have shown reliability for those -- more and more commerce will come on board.   And the value of the currency would be derived not from the cost of subsidized power in China -- but from the value in use to perform tasks which help people live their lives... pretty simple when you step back a little -- but the devil is in the details...

Hope that makes a little sense...

stonehedge -- very cool.

as alluded to in the update -- one of the keys to the continued development of the crown network will be to integrate different devops capaibilities into Trons as well as integrating Tron's themselves within devops / orchestration and management tools and cloud apis.  

the key idea here is that crypto reduces transaction costs in the currencies -- yes -- but are there other adjacent technologies which are proven which can be applied from the development of the cloud to simplify the network set-up and operation and to improve security?  

very cool...

thanks stonehedge!

Bigmo: 

The key for this project is that we are a distributed team of people with different skills beliefs work styles / strengths and weakness etc, all that blah blah blah...  but where the diversity stops and where we have to be unified is in our goals and language.  The shared language issue sounds esoteric -- but we just need to make sure that when I say "container" and you say "container" we mean the same thing... so it's really just a blocking and tackling thing to make sure we understand each other.  The shared goals/objective is that we will all be pulling the cart to the same destination.

This is described in the crown papers and the principles - but it may not be described in a way that makes sense to everyone.  Part of idea of the papers and principles is to state and define who fits in the community precisely because no one in a community of any size "likes" everyone else in the community. But while we may not "like" each other -- if we have a common goal and communicate clearly about it, we can all benefit from working together.

For the core team there are additional element but it basically boils down to the fact that each team members have the others' back -- you watch out for each other.  And there is debate. but no second guessing.  Team members need to be able to take initiative and have support and be willing to try things that might not work... if you don't have that culture, you don't innovate.

And I guess the point here is that if someone on the team has had an issue working with one of the guys on the team in the past - I would encourage you to contact that person directly and patch it up, or not -- your call.  But I would also appreciate it if you kept any past problems in the past -- because part of how I want the team to work, and the community as a whole as much as possible -- is that we support each other.  We are trying to do something new and if it works, there will be enough competitors trying to trip us up and be negative in different ways, that we don't need to do it to each other.

Thank you for you suggestions and the services you have developed so far and I look forward to hearing more of your ideas.  We will need as much help as we can get to make this happen.

Bigmo -- sandstorm looks cool.  Thank you for the heads up!

Sandstorm is of interest for two reasons:
1. The ability to self host so that we could have the tools used by the team available on the platform. 
2. Their approach to containerization and the quality of their development team.

Two of the issues for us now are (1) developing applications to work on the crown platform or which can be ported to the platform -- part of API design is having actual use cases, (2) within that thinking about different strategies for how one would deploy the applications and contain/encapsulate the applications running on the platform.

I PM'd stonehedge and he is going to take a look at it.  As stated before -- I'm new to this stuff and learning, but I know what the goal is, or what I would like for Crown to be able to build...  and we will need help from the community to do it.

I/we appreciate your help.

Bigmo:

Crowncoin_Knight says he remembers you from your earlier involvement in the project.  Always good to have people come back.  

The name of the game for CRW at this point is to build the community -- and part of the business model of CRW is for the core team to develop the capabilities of the core code -- which is the focus right now, and will hopefully always be the focus.  This focus for the core team is alluded to in the crown papers.  

What this means though is that there are opportunities for entrepreneurs to build different businesses and services around the core.  These would include things like the wallet you developed or getting on Bitsquare -- or Bittrex, which is really just another business operating on the platform.  

I know the team has discussed Bitsquare and Shapeshift and other things as desirable services -- but we also know that more of these things will happen and we will attract more folks to the community if we can just deliver on the vision we have set out.  

The first steps of that vision for the core team are trimming down the Crown core to what is "permanent" or relatively permanent and hopefully doing a few things to not just trim it down but also speed it up.  This differentiation between what is temporary and what is permanent is also discussed in the papers -- privacy tends to be associated with ephemeral/temporary content and a crypto platform should differentiate between records which need to be kept forever and those which shouldn't.  The idea that any part of a permanent record is private is a little silly since it implicitly assumes that technology will not advance.  The only true privacy comes from forgetting.  But I digress... I'm the member of the group who reads too much and took too many philosophy classes so I know I drive some people crazy, sorry about that.

The second step is to make it all conversational.  People gossip, so should your software.  So that's the API.  Then the third step is building the "journal" or the sandbox which is where you do temporary things and the really gossipy part of the software.  Or that's what I think but I am more of a philosopher than a programmer...  Not really rocket science -- just work.

Just letting you know what we're focused on right now.  Appreciate your work on the wallet and any progress or perspectives on other services.    

As bigmo mentions -- the raspberry pi is probably the cheapest way to host a throne at this point, and also offers the network a degree of heterogeneity since most of the thrones are VPS.

The thrones are useful for getting acquainted with the idea of nodes or servers on a crypto network if you aren't familiar with it.  I know I'm fairly new to all this.

The goal is that as the Crown Platform gets ready to add applications or services - however exactly that gets worked out, the legacy masternode code which comes from Dash will be updated to provide those applications and services instead of what it did for Dash.  So one way to look at it is that Dash introduced a sort of client-server framework, and Crown is just loading some software onto that... and since it's a crypto system, the payment mechanism will be integrated with the token and there are other security options too.

But if you read through the Crown Papers, the idea isn't for the platform to charge some big fee -- but just to charge a mark-up on it's costs.  Depending on how the pricing gets set up, thrones could compete on providing services or they could collaborate.  The network and the thrones (trons) would then profit according to the amount of services offered and a portion of the fees would also be recycled through the block rewards system to continue incenting the base level functionality of the network.

The key point here is that the throne are the backbone of the network providing services at a fair cost -- and by not seeking monopoly rents like historic platform companies - name a valuable software company... the platform may also be able to provide the services for a lower price.  The ability to offer a better price will ultimately be enabled by the community developing the platform -- because once a project takes corporate money, it has to produce a return for those corporations.

The idea with Crown is that corporations are welcome to use the platform to provide services and compete with solutions on the platform -- but the platform itself should be a sort of digital commons, which is shared but not owned.  

The thrones are the ones literally providing the compute space and capacity for this digital commons and getting paid for it -- so it's an interesting and slightly different sort of business proposition... or it seems that way to me, but I'm new to all this stuff...

So defunctec -- what would this be?  Would this be a device with a chip which would have the keys to a wallet - where the wallet would how X coins?  So it's more of a crown chip?  And I guess the chip could just display the balance of the wallet/keys it holds? 

Since addresses can be used on multichains -- I guess you could also have a multi-coin chip?

Then theoretically people could use digital tokens by transacting in these chips -- just like they transact with cash....

I guess, I would just imagine possibilities in a "general purpose model"  ....  and I would imagine that one would spend "crown chips" or "crown cards" like cash. 

so yeah... that sounds interesting.

Other may have different ways of describing it -- but the move from Slack to Mattermost is driven by a few different factors:
1. We are an open source project and strongly prefer open source products.
2. We are developing an application platform and the first use case for the application platform can be thought of as the maintenance and development of the platform itself, and the applications which will run on the platform will be limited to open source projects.
3.  No platform development team succeeds if they don't use their own products.  And even then the odds aren't necessarily the best...
4. So all the tools which the team uses should be open source for both philosophical and practical reasons.

5. Slack isn't open source so we needed an alternative.
6. Stonehedge picked up the ball and took care of it.

7. This is all part of the ongoing process of developing Crown to utilize more of the capabilities inherent in crypto-currency protocols which are open PKI's with p2p networking capabilities and tokens available for use in both transfers of value but also in message encryption, authorization and verification.  The general principles are outlined in the papers.  

At the end of the day, the crypto-currencies are just systems that lower transactions costs -- but as Ronald Coase noted in the 1930's, we organize firms around where there are transaction costs -- so something that changes transaction costs logical has some impact on the structure of the economy.

As outline in the papers -- one can think of what Crown would like to create as a digital commons -- or an open platform to be used for compute, communication and commerce.  Currently the popular business models are for platforms to be monopolies charging tolls on everyone to use them, sort of the opposite of a commons.  Seems like a worthwhile experiment to try.

Working on a throne docker pre-built container and also the dockerfile to enable building from the script and then syncing the blockchain yourself.

The docker throne file is around 4 GB, and already has the blockchain sync'd so one would just need to install docker and do docker pull, then update the settings in the crown.conf file.

Would this be useful to folks? 

And the papers are available on kindle for free right until Sunday night... feel free to grab a copy if that is your preferred medium...

https://www.amazon.com/Crown-Papers-Core-Development-Team-ebook/dp/B06WP2JQXT/

Amazon Kindle sets a minimum price of $0.99 but allows for a 5 day free promotion every 90 days.

Don't know who folks are using for throne set-up....

OVH is great, but the network seems to have plenty of exposure there.

Aruba (www.arubacloud.com) has several data centers (Czech, Italy, France, Germany, etc) and also has cloud servers priced at 1 euro a month right now.

Tiktalik (tiktalik.com) is a polish cloud provider that has servers for 10 PLN.

Openvz.io has some reasonably priced VM/Containers available across a range of geographies.  This takes you to iniz.com, which is SYN Ltd in the UK... but it's reasonably priced.

Ultimately, there are good arguments for Crown to have:
1. A guide or list of cloud service providers, where you can either set up your own thrones/trons or whom you can contract with to operate the throne/tron servers.
2. A preference for cloud service providers who operate within a single legal jurisdiction - the complicated thing about crypto-currencies and the platforms of services which they could support isn't so much the technology, as how different regulatory and legal systems will deal with the capabilities of these systems.  Since different countries will react differently, it is probably easier to know that when you have a server in a country you are subject to the legal system of that country -- rather than dealing with the issues of a corporate parent in one country with one set of laws and regulators and a server somewhere else.

#2 isn't an issue yet -- but just worth thinking about as folks set up their throne servers and as the team thinks about the next steps for the platform... so applying the logic from point #2 to the list of VPS providers above, Tiktalik is the only one which has it's servers and legal organization in one jurisdiction - and this is the sort of profile of a VPS provider that is probably a better long-term host for throne/tron servers than the multi-national businesses with complex multi-jurisdictional regulatory and legal issues...

Would be curious what other VPS/Cloud providers folks might recommend with a similar profile?

thx.  

Amazon allows for  5 day free promotional giveaway every 90 days.  So the papers will be free for download on Amazon from this Wednesday 2/15 to 2/19...

Also -- Amazon allows you to turn off their DRM (Digital Rights Management) -- which we did -- and book lending is allowed.  Also, if you are a kindle person, you can also just open the PDF into Kindle -- the formatting isn't perfect on any of it anyway.  We are still just bootstrapping this thing.

The point is to just get some of the ideas out there and invite folks of a similar mind to join us on this project to see how far we can go with it.  The idea behind putting it on Amazon is so that when folks search for books on altcoins, bitcoin, open source, crypto and other things -- we may show up in the list.

Anybody here used Vagrant with LXC and the different cloud plug-ins before?

Just starting to play with it as a way to manage thrones.  If you think about it -- one could probably figure out a way to daisy chain some open source tools like this together and make the networks of "thrones" less static... more elastic... where capacity could adapt to demand through the configuration of "trons" (sort of active thrones -- and hey Hal Finney was the game designer for Tron, but nobody caught that link in the papers... which just means no one has actually read them -- LMFAO).

The trick to this model is that it assumes that a node operator is able to trust the network enough to have what is functionally automated access to his/her account on different cloud platforms...  so this wouldn't be "step one" and may not ever completely make sense because of legal complexities with the contracts from the cloud providers -- but it is one of the possible combination out there.

But for now... just starting to play with Vagrant -- any tips appreciated.

I am just catching up on what's going on -- been working at the job that pays the bills...  

For those following this -- since it gets hard to follow from the stream and also in the internal Crown Slack, I will offer a summary of what I think happened and is happening.  Other members of the Crown team are welcome to affirm or correct me if I miss something or get something wrong -- but I think some of the guys in Europe are getting some sleep after a long day.

SUMMARY
1.  The Crown update which the team released had enforcement turned on -- meaning that the new nodes rejected connections from the old nodes.
2.  In the process of testing the team had not discussed (to my knowledge) whether enforcement should be turned on or not -- because enforcement was one of the many features which hadn't worked in the old code.
3.  The team's plan was to do a managed fork at block number set for approximately next Monday Feb 13th -- but instead has been working to manage the unintended fork which occurred as miners and thones began running on the new code release.
4.  Due to the fact that large miners hadn't updated their wallets yet -- NOT THEIR FAULT -- they were told they would have some time, and I believe that not all of the pools had necessarily been contacted before the fork happened.  
5. Due to enforcement being on in the release, the fork was a necessary result of the first miner who started running the new code. And because at that initial point, after the first mining installed the new code, less hashing power was working on the fork/network/blockchain which the new release mines on -- the fork which the new nodes and new code is running on has a shorter blockchain.
6.  The default way that a node knows which blockchain is valid is by it's length -- so this un-anticipated fork has created a blockchain which is (or was until al little bit ago in my understanding) being mined by miners running the old buggy code.  So as long as the blockchain mined by old-buggy code is longer -- it will be preferred as "valid" by the wallets.  This is part of the logic of mining and wallets -- the longer chain is always the one which has more compute power invested in it and right... except...
7. BUT in this case the longer chain is running on old buggy code, and going with the longer chain would only punish the folks who updated their code, which includes CCEX, the exchange.  

8. So some of the team members have purchased hash power and are aiming it at pools running the new code -- and the pools which hadn't updated (once again -- not their fault, but ours for having enforcement on in the release), have been contacted.

9. CURRENTLY:
    Chainz & CCEX show the fork being mined on the new code:     https://chainz.cryptoid.info/crw
    Blockpioneers shows the fork being mined with the old code:    http://crw.blockpioneers.info/index.php
    The has rate for the shorter chain / new code is higher than for the old code / longer chain.  So the new code chain is catching up.

10.  The core team takes full responsibility for fucking up on the enforcement.  No dancing around it.  We didn't realize that infernoman was going to build a new codebase where things actually worked just like they were supposed to.  And I think infernoman may have surprise himself.  

11.  I would like to thank the members of the core team who were working and sweating managing this process today.  

12.  There will always be mistakes and surprises and the key to this being a successful team and project will be in how we deal with the mistakes and surprises -- and how we communicate with the community.  This fork was an unforced error on our part -- that is disappointing to us and no one should really be happy about it... but the team and community have responded constructively and pivoted -- and while the problem isn't resolved yet -- everything is moving in the right direction.  

Hopefully that makes sense.

And for what it's worth, one of the lessons of all of this is that IN THE NEXT RELEASE ENFORCEMENT WILL BE TURNED OFF INITIALLY....
 

And on Darksend... the original purpose of nodes in Darkcoin/Dash was to do the mixing for Darksend.  

So the plan is basically to remove Darksend and use that node capacity for other purposes -- but removing Darksend ends up being complicated, so the only uncertainty is if it will just be disabled, or if it will be fully removed... And that we really depend on just if we have enough coding skill/manpower on the team.

The thing is that once you understand that a blockchain is a universal open PKI -- then the issue isn't coming up with ideas and uses for it... it's writing the code and building the community...