AI Coin Development Diary

[SlipperySlope]

CPoS Network Proxy

I have been thinking about a way to deploy CPoS in a way that minimally impacts Bitcoin Core, and their pull request regime.

The idea is to have CPoS code execute as a network proxy for bitcoind - the Bitcoin Core program. A paid CPoS full node operator would launch the CPoS program - preferably automatically upon start of the server, The CPoS proxy would configure its bitcoind to have a single peer, namely the collocated proxy. That bitcoind, by default, would have generation turned off. The CPoS proxy would connect to other such proxies forming the super peer network described in my whitepaper. All the agent related code would be implemented in the proxy. The proxy-to-bitcoind communication protocol code would be adapted from bitcoind source code for complete compatibility. The proxy-to-proxy communication protocol would be inspired by FIPA agent-to-agent protocol.

The single nomadic mint would launch bitcoind every 10 minutes, and configure it to generate the new block. After creating the new block, the mint would shut down its bitcoind. Alternatively if the bitcoind RPC (remote procedure call) interface permits sufficiently robust dynamic control of block generation, then that would be preferable.

Bitcoind would verify transactions received from the proxy and build the blockchain replica with new blocks provided by the single nomadic mint agent via the proxy. The full-node's tamper-evident log would be maintained by the proxy. The bitcoind instance would listen on its standard Internet port for SPV nodes, e.g. mobile wallets, and process their requests. For full nodes desiring local Bitcoin-QT wallets, the proxy would launch the wallet after launching bitcoind. The wallet would communicate with bitcoind directly, and not the proxy.

If and when the blockchain hard fork planned for early 2016 succeeds, the proxy code I write can be merged into the bitcoind code for a single program by willing core developers. This possibility constrains me to write the proxy in the language of bitcoind, which is C++ and the Boost library.

-Stephen Reed

[1715618515]

1715618515

[1715618515]

1715618515

[1715618515]

1715618515

[SlipperySlope]

Bitcoin Cooperating Agent

Nothing that the core developers maintain will be touched. The agent code, in this case a Relay Agent, will run the non-generating bitcoind instance. Bitcoind communicates with the reference wallet, bitcoin-qt, and also with the optional command line interface. Simplified Payment Verification wallets communicate with the listening bitcoind.

The notable change is that the bitcoind instance is configured to communicate with other full nodes only via the Relay agent.



-Stephen Reed

[SlipperySlope]

Bitcoin Cooperating Agent Design

Here is the first portion of the project specifications . . .

Bitcoin Cooperating Agent Design

[SlipperySlope]

Communication with the BlackCoin Foundation

BlackCoin is the number 8 cryptocurrency when ranked by market capitalization. Today I corresponded with Adam Krykow, from the BlackCoin Foundation.

Hi Stephen,
 
I am a member of the BlackCoin Foundation and I had called a week or so ago looking to talk about the article you posted about CPoS. Basically, I am looking to open up some dialogue with you to see if you have any interest in bringing some of your technical expertise to the altcoin realm.
 
Here at BlackCoin we have been attempting to tackle the mining problem of bitcoin with a fast, decentralized, PoS system but it is quite a difficult process. We are still in the early stages of our development, relying on centralized checkpoints currently, but we have been discussing plans for a multinode network within our system. When we stumbled across your whitepaper, it was like reading a fully developed version of our internal discussions.
 
I don’t know how far along you are with your current BitCoin startup, but at BlackCoin we can offer you a community of adopters and a real desire to perfect a system very similar (but not identical there are some differences of opinions to be hashed out) to your CPoS.
 
Thanks for your time and your whitepaper. At the very least I believe we will be citing it frequently as we move forward!
 
Adam Kryskow
Public Relations Director for the Americas
BlackCoin Foundation
a.kryskow@blkfoundation.org
www.blkfoundation.org
www.blackcoin.co

I responded . . .

Hi Adam,

I am excited about the opportunity to collaborate with your team. Indeed my focus is on Bitcoin, but my plan for 2015 involves demonstrating cooperating proof-of-stake agents with one or more Altcoins, before hard-forking Bitcoin in early 2016. Previously I was informally contacted by a Bytecoin developer who offered to run my code when ready. I have participated in a podcast with Dan Larimer's Delegated Proof-Of-Stake project, and will continue a periodic sharing of ideas.

My design is evolving towards an agent based framework that can support multiple cryptocurrencies. Supposing that altcoins follow the Bitcoin coding convention of deploying an executable similar to bitcoind, then a full node in the CPoS system could operate multiple bitcoind instances, each belonging to a different cryptocurrency. The full node operator would be compensated by each such currency via their respective block creation reward policies. This leads to economies of scale, and significant benefits to lower capitalization altcoins. Message traffic on the CPoS network, e.g. transactions and blocks, would be tagged as to which cryptocurrency they belonged.

See: Bitcoin Cooperating Agent illustration


I completed the CPoS whitepaper in May. I plan to complete the public high level design in June, and enough of the public message workflow specifications to begin open-source coding in July. I have bitcoind compiling in my C++ NetBeans IDE now. The agent message passing architecture will be adapted from a very similar one that I wrote in Java for my now-postponed AI project. My plan is to have significant elements of the CPoS architecture running in the late fall, with public system testing and altcoin deployment scheduled throughout 2015.

My GitHub repository is currently a Bitcoin clone. I periodically synchronize it with the core developer's repository. For CPoS, I will establish a new public repository. The code that talks to the local bitcoind instances, I will adapt from existing core code. The networking code, the tamper-evident logs, and agent framework will be new code. As I mentioned, the agent framework will be a simplified version of Java code that I wrote some years ago. The agents will each extend a C++ class and provide specialized behavior. Each agent will be simply enough for its peers to easily verify. There may therefore be many agents in total to provide all the required behavior.  A testing framework will be specified and completed that enables robust regression testing of the agent network.

I look forward to continuing discussion with your group, especially regarding our respective development schedules and what components are needed first.

-Steve
 
Stephen L. Reed
Austin, Texas, USA
512.791.7860

[SlipperySlope]

Advice on securing a re-engineered Bitcoin network

This is the email message that I sent to Defense.net, Staminus Communications, Cloudflare, Black Lotus, and Incapsula.

Hi,

I founded a project to re-engineer the Bitcoin network. This project, if it achieves wide acceptance during a year of system testing in 2015, will launch in early 2016. The whitepaper describing this project is Bitcoin Cooperative Proof-of-Stake.

The current Bitcoin network contains approximately 8,000 volunteer nodes. My plan would be to use a portion of the daily bitcoin block creation reward to fund an upgrade to robust Virtual Private Server instances, which would be dispersed and hosted at datacenters around the world. Currently the daily block creation rewards amount to $2.4 million.  

I seek your advice about protecting 10,000 or more such dispersed servers against large DDoS attacks. Each server will have at least one public IP address that could be attacked, and each shall use the public Internet for connectivity with other servers and with client software.

Currently the Bitcoin network has no Network Operations Center. My plan provides for nomadic one, but it needs to be highly automated.

How much would it cost to use your services to protect the Bitcoin network that I propose? I desire a scalable solution, and perhaps tiered pricing as the available funding depends upon the volatile price of bitcoin.

As this is an open source and public project, I am posting this query and your response in the project's discussion thread. Because I need to keep a transcript of our conversation, I desire to converse by email if that is OK with your sales staff. I would be delighted to answer your questions, and will thoughtfully consider what you say.

Note that I am sending a similar query to a few other vendors offering DDoS protection.

Thanks!

-Steve
 
Stephen L. Reed
Austin, Texas, USA
512.791.7860

Black Lotus

Hello Stephen,

Thank you for reaching out to Black Lotus. I understand you are interested in our Protection for Networks service.

In order to qualify for this service, you must have an ASN, a network capable of BGP sessions, and at least a /24 to allocate for protection. Will you meet these requirements when you launch your project? If not, we have other solutions that will work for your needs as well.

I have attached a PDF with some valuable information about Black Lotus and the protection we provide as well as a PDF with more specific information about Protection for Networks. I am also including a PDF about our Protection for Services that will specifically protect your site.

Please feel free to let me know if you have any questions or would like a custom quote.

Christine Gaylor
Inside Sales Representative, Black Lotus Communications
direct: (678) 608-2575 | mobile: (757) 536-0509 | gtalk: christigaylor@blacklotus.net | skype: christi.gaylor

Hi Christine,

I believe that the Bitcoin network is not ready for an Autonomous System Network with our own routers. That should come in the years beyond the launch in 2016. In the meantime, I am interested in your Protection for Services product. Am I correct that the customer decides whether a server is under DDoS attack and if so, redirects its IP address to Black Lotus for traffic scrubbing? What are ways to automate this?

Note that I am talking about 10,000 dispersed VPS instances. Can you provide a quote?

Thanks!

-Steve

Hi Stephen,

Thank you for this information. I am thinking a more custom solution is going to be a better option to meet your specific needs. Would you be open to a call to to discuss this in detail with my lead sales engineer?

I have Friday at 3pm CDT / 1pm PDT available. Let me know, I will be happy to arrange it.

Best Regards,

Christine Gaylor
Inside Sales Representative, Black Lotus Communications
direct: (678) 608-2575 | mobile: (757) 536-0509 | gtalk: christine.gaylor@blacklotus.net | skype: christi.gaylor

Christine,

I regret that I am travelling that day to open my mountain home in Colorado. It will be great to escape the summer heat of Austin for a week. I can make the call anytime at your convenience from Colorado, Monday June 12 through Friday June 16. I will need to make a transcript of the conversation so that I can publish it on my open source project's discussion site. [ANNOUNCE] Bitcoin Cooperative Proof-of-Stake
 
I look forward to speaking with a sales engineer who can give this project the technical guidance it needs.

-Steve
 
Stephen L. Reed
Austin, Texas, USA
512.791.7860

[SlipperySlope]

Prolexic advice on securing a re-engineered Bitcoin network.

Prolexic

Dear Stephen,
Thank you for your interest in Prolexic, the global leader in Distributed Denial of Service (DDoS) protection services.  We are processing your request and will contact you within 24 hours.
Prolexic represents the gold standard in DDoS monitoring and mitigation.  We mitigate all attack types no matter how large or complex and we do it fast for one flat monthly fee -regardless of how many times you are attacked or how much bandwidth is consumed.  Even better, this is supported by the industry’s first ever time-to-mitigate Service Level Agreement (SLA).
 If you are currently, or will be, evaluating DDoS protection providers, here are four facts about Prolexic to keep in mind:
More than 10 of the world’s largest banks rely on Prolexic for DDoS protection every day
Prolexic operates the world’s largest and most sophisticated cloud-based mitigation platform with over 1.8 Tbps of bandwidth (3x larger than our biggest competitor)
In 2014, Prolexic mitigated the world’s largest attack (190 Gbps).
Prolexic uses 20 distinct mitigation and analysis technologies where others use 3 or 4
 You may also find the following documents useful:
White Paper: 12 Questions to Ask a DDoS Mitigation Provider
Evaluation Worksheet:  DDoS Mitigation Providers
Brochure: Prolexic Overview
If this an emergency call us at + 1 (888) 368 2923 (Toll Free in the U.S.)  or + 1 (207) 608 6213 (Local/International) to be connected with a DDoS mitigation expert.
Best Regards,
Prolexic Sales Operations
http://www.prolexic.com

David from Akami, who acquired Prolexic phoned me to set up an appointment with a sales engineer. Their preferred solution involves an interface with routed network having BGP. This means that each Bitcoin full node would have its own router that guides message traffic to other full nodes. DDoS protection for the entire Bitcoin network would be $20-30K per month.

Akami's other solution, the Proxy Solution, is designed for HTTP traffic, and thus works on ports 80 and 443. Not Bitcoin.

The Bitcoin network would need to acquire a /24 autonomous system (AS) number.

[jubalix]

wont NXT do most of this when it implements transparent forgeing??

[SlipperySlope]

wont NXT do most of this when it implements transparent forgeing??

Good question. I am quite open to borrowing and sharing ideas with altcoin projects. I of course examined next last month when writing my whitepaper, but I felt at the time that PeerCoin alone was a sufficient example of existing proof-of-stake implementations.

I will revisit transparent forging.

[SlipperySlope]

Bitcoin Centralization Problem Evolving Into Trusting a Third Party - GHash.io

See: Who cares about the 45% Ghash.io have - will you care when they are at 51%?

I responded . . .

The truth is that proof of work leads inevitably to a single hasher-pleasing dominant mining pool. The hashers have sufficient trust in that pool to permit a 51% attack, that hashers think is not a threat. Hashers have observed that the pools are well behaved, and those pools are efficient due to competition. The dominant pools knows that if there is misbehavior they will be possibly ruined by deserting hashers.

Thus proof-of-work as a means to secure the Bitcoin blockchain now fails Satoshi's design of a system in which there is no trusted third party. .

I claim CPoS will have no trusted third parties. Humans who act as paid agents for the system will themselves create tamper-evident logs justifying their observable actions, which can be checked by a certain number of human agent-peers.

[RSchexnayder]

Hello Stephan
I conceived a method for how a digital PoS currency could possibly have a 10 second average transaction time, if it had a block time of 1 minute. I wrote about this on r/BlackCoin before you published your whitepaper. Adam Kryskow of the BlackCoin Foundation has since told me that my method is essentially the same is your. From what I understand of yours, that is the case. However, I envisioned a much simpler and mush less powerful implementation than your sub-second proposal.
I did this shortly after I became interested in BlackCoin. I came up with the idea of how to implement it after I read the Follow the Coin article at the link below were rat4 and Soepkip are interviewed, and the 10 second transaction time of BlackCoin is prominently mentioned in that article dated April 4th 2014.
http://www.followthecoin.com/interview-creator-blackcoin-bc/
Since BlackCoin has a 1 minute block time, the minimum average transaction time should be 30 seconds.
The methodology that I foresaw is made possible by the fact that all of the nodes are cooperating, which is not possible with a PoW coin like Bitcoin. Therefore, whenever nodes with 51% of the stake at the start of a block have eventually confirmed that a transaction can be in the current block, it can be confirmed to the entire network that it will eventually be in the block. If an attempt at a double spend is occurring in the block, then the first node that subsequently becomes aware of the attempt should immediately ensure that second spend will not be added to the current block by sending an immediate alert that a double spend has been attempted. Each node receiving this alarm should verify that it is accurate. If it is a false claim, the offending node should be blackballed.
I assumed that this method was being programmed by rat4 when it was announced on r/BlackCoin that he was working on PoS 2.0 based on the Peercoin protocol.
It had never been adequately explained to me why Soepkip and others who should have known better had allowed the 10 second fiction to continue after the big pump and dump occurred shortly after the article came out. The 10 second claim was certainly used during that pump. I have tried on several occasions to get an explanation, but I have not tried recently to get one directly from Soepkip because all of my earlier attempts had been brushed aside by him. 
I subsequently found out that that is not what rat4 is working on. That is when Alan told me that your scheme is a more sophisticated version of mine that assumes that the master nodes are sitting astride the backbones of the internet.
With regard to jubalix’s question, it is my understanding that NXT, as it is written now does not incorporate this methodology. However, I could be wrong. Nevertheless, the cat is now out of the bag. IMO it will not be long before the NXT community understands how to modify their protocol and set out to do it. I would think that their first step would be to implement a simplified, bare bones version like my proposed version to determine in practice what kind of actual average transaction times can be achieved. The next step would be your Internet backbone version. 
What Alan refers to as our internal discussions at the Blackcoin Foundation has just been within one relatively small committee where there is much resistance to rocking the Bitcoin boat and a realization that we do not have the ability to properly fund such a project at this time. However, I am sure that NXT does, if the initial investors  think it is worthwhile, which I do not see why they would not.
RSchexnayder   

[SlipperySlope]

Hello Stephan
I conceived a method for how a digital PoS currency could possibly have a 10 second average transaction time, if it had a block time of 1 minute. I wrote about this on r/BlackCoin before you published your whitepaper. Adam Kryskow of the BlackCoin Foundation has since told me that my method is essentially the same is your. From what I understand of yours, that is the case. However, I envisioned a much simpler and mush less powerful implementation than your sub-second proposal.

Right. My main theme is to implement Nick Szabo's idea about agents with non-forgable logs, what an academic paper I cite calls tamper-evident logs. The proof-of-stake is used mainly to deter Sybil attacks, as there is only a certain amount of stake in the post-fork bitcoins that will be thus qualified for dividends.

The single nomadic mint is permitted by the notion of cooperating agents that do not trust the mint, but rather allow it to timestamp the incoming new transactions from clients. The peers verify the mint operations by replaying the operations themselves as they each assemble the blockchain replicant locally in canonical timestamp order. The single mint in turn permits a non-forking blockchain and definite transaction acknowledgment back to the client with sub second response time.

[SlipperySlope]

CPoS To Be Written in the Java programming Language

I made the big decision a few days ago to write my new Bitcoin system in the Java programming language rather than C++ and the Boost library used by the Bitcoin code contributor team. The Java alternative became possible given the evolution of the design into incorporating bitcoind unchanged but slaved to a new component that contains the agent behavior, but has minimal dependence upon the objects and functions defined in bitcoind.

I will use the bitcoinj client implementation classes as the network adapter to the local bitcoind instance, as well as the adapter for bitcoin data structures.

I have been working with Java for as long as it existed, and I have written over a hundred thousand lines of Java code for my previous artificial intelligence project. There is a thorough suite of unit tests and a continuous integration development environment already in place. My previous project was named Texai. I shall continue using the Java package naming convention "org.texai.bitcoin.*" for the Java source code ported from from the old project.

I concede that Java is slower by 30% or more than the equivalent C++ algorithm. But I do not believe that performance is an issue until very high transaction rates are tested. Aside from a comfort with Java, I believe that its runtime checks reduce the bugginess of production code, Personally I can write code much faster in Java than in C++.

[RSchexnayder]

Hello Stephan
I conceived a method for how a digital PoS currency could possibly have a 10 second average transaction time, if it had a block time of 1 minute. I wrote about this on r/BlackCoin before you published your whitepaper. Adam Kryskow of the BlackCoin Foundation has since told me that my method is essentially the same is your. From what I understand of yours, that is the case. However, I envisioned a much simpler and mush less powerful implementation than your sub-second proposal.

Right. My main theme is to implement Nick Szabo's idea about agents with non-forgable logs, what an academic paper I cite calls tamper-evident logs. The proof-of-stake is used mainly to deter Sybil attacks, as there is only a certain amount of stake in the post-fork bitcoins that will be thus qualified for dividends.

The single nomadic mint is permitted by the notion of cooperating agents that do not trust the mint, but rather allow it to timestamp the incoming new transactions from clients. The peers verify the mint operations by replaying the operations themselves as they each assemble the blockchain replicant locally in canonical timestamp order. The single mint in turn permits a non-forking blockchain and definite transaction acknowledgment back to the client with sub second response time.

I think I can follow what you are saying there, but I am not sure of what exactly you are calling the nomadic mint, the cooperating agent, the client, and peers.

I have enough programming experience and knowledge of data structures that I know that the system that I came up with can work. Furthermore, no one else in the BlackCoin Foundation that I discussed the method with found a problem with it.

My only question at this time concerns the point at which a transaction is initially confirmed in your system. You do no mention waiting until 51% of the nodes with stake at the start of the block have determined that it can be in the block being assembled.

Are you saying that the simple nomadic mint is a part of your program that assembles the master ledger in timestamp order? For it to work this way, it would have to have the sole responsibility to verify that the transaction is legitimate and thus verify it to the network. Thus, it has the responsibility to stop any attempted double spends when presented with the second or subsequent ones.

IMO the two methods accomplish the same thing, but are slightly different in execution

The method that I came up with does not require a centralized mint. I am not trying to argue that one is better than the other, because I have not thought about it. I have no desire to try to start programing either one.

[SlipperySlope]

Are you saying that the simple nomadic mint is a part of your program that assembles the master ledger in timestamp order? For it to work this way, it would have to have the sole responsibility to verify that the transaction is legitimate and thus verify it to the network. Thus, it has the responsibility to stop any attempted double spends when presented with the second or subsequent ones.

IMO the two methods accomplish the same thing, but are slightly different in execution

The method that I came up with does not require a centralized mint. I am not trying to argue that one is better than the other, because I have not thought about it. I have no desire to try to start programing either one.

Yes I have a single mint which solves many problems that annoy bitcoin users. That mint is nomadic because it's verified object state periodically moves from full node to full node. What i call a nomadic mint agent is isomorphic to the notion that full nodes take turns being the mint. Each other full node, having the role of relay agent, closely verifies the log output of the mint agent.

Because CPoS has a single mint there is immediate acknowlegement by the mint when it queues up a received transaction. There is no chance of a double spend or that an orphan block can be created. CPoS has a single, non-forking blockchain which is simply appended to by the mint's local slave bitcoind instance with trivial Satoshi difficulty effort

My first system test will be two full nodes in a box, cooperating to create new blocks, and quickly exchanging relay and mint roles. Another system test will be three full nodes in a box, performing an exhaustive regression test of  failure modes of one of the three nodes.

Since BlackCoin has a 1 minute block time, the minimum average transaction time should be 30 seconds.

The methodology that I foresaw is made possible by the fact that all of the nodes are cooperating, which is not possible with a PoW coin like Bitcoin.

Therefore, whenever nodes with 51% of the stake at the start of a block have eventually confirmed that a transaction can be in the current block, it can be confirmed to the entire network that it will eventually be in the block.

If an attempt at a double spend is occurring in the block, then the first node that subsequently becomes aware of the attempt should immediately ensure that second spend will not be added to the current block by sending an immediate alert that a double spend has been attempted. Each node receiving this alarm should verify that it is accurate. If it is a false claim, the offending node should be blackballed.

I assumed that this method was being programmed by rat4 when it was announced on r/BlackCoin that he was working on PoS 2.0 based on the Peercoin protocol.

It had never been adequately explained to me why Soepkip and others who should have known better had allowed the 10 second fiction to continue after the big pump and dump occurred shortly after the article came out. The 10 second claim was certainly used during that pump. I have tried on several occasions to get an explanation, but I have not tried recently to get one directly from Soepkip because all of my earlier attempts had been brushed aside by him.  

.

Could you point me to a writeup of your algorithm? Or if this is still exploratory, then could you explain more about how proof-of-stake works in your system to create new blocks? Does your system, like Satoshi's, permit a forking blockchain? Note that any such blockchain forks could confuse the user accessing the minority branch.

[RSchexnayder]

.
Could you point me to a writeup of your algorithm? Or if this is still exploratory, then could you explain more about how proof-of-stake works in your system to create new blocks? Does your system, like Satoshi's, permit a forking blockchain? Note that any such blockchain forks could confuse the user accessing the minority branch.

Steve

I have not tried to further define the algorithm, and I do not intend to. I certainly do not want to try to compete with you.

However, I do intend to try to spread the word on the concept. What I have tried to do, and what I think I have accomplished, is to describe an algorithm in such a way that a person familiar with programming techniques can understand how one can get average transaction times much smaller than half of the block time.   

[SlipperySlope]

However, I do intend to try to spread the word on the concept. What I have tried to do, and what I think I have accomplished, is to describe an algorithm in such a way that a person familiar with programming techniques can understand how one can get average transaction times much smaller than half of the block time.    

Indeed the CPoS response time has no relationship to the block creation cycle, as the single nomadic mint agent canonically timestamps each received transaction. The round trip number-of-hops is less with CPoS because the mint is the hub of an organized hub-and-spoke, super-peer network. I chose to keep the Satoshi precedence of 10 minute block creation intervals, for the sake of the Satoshi Social Contract - not for any other reason.

I believe that CPoS's optimum network configuration will permit more transactions at lower user fees. This is an indicator that I need to create and test.

[RSchexnayder]

If the coin creation method is changed, the ASIC owners have nothing to say.

Bitcoin uses proof-of-work, and therefore the majority of the hashing power decides. Why would the current stake-holders be so stupid to switch to a system which is unproven and where there economic advantages, i.e. their capital investment becomes worthless? That makes no sense whatsoever. Coin creation in Bitcoin doesn't arbitrarily change. That's why its a solid system. If such changes were possible Bitcoins would be worthless. All of this should be obvious to anyone who wants to understand why Bitcoin works. The reason is works is that hashing-power can not possibly become worthless. And those that own the hashing power will not agree to give it up. That's the fundamental limitation as well.

Steve, I agree the above post that the Bitcoin mining community will not voluntarily give up their printing press. However, I seriously doubt that they will be collectively confronted with that decision on your timeline.

There is already at least one member of the NXT community who at least suspects that this system can be implemented in that coin. It undoubtedly can, if enough devs are charged with the task. The founding 70 odd members certainly have the capital to invest to make that happen,

Furthermore, the BlackCoin community is already aware of its potential, and you have posted your correspondence with their representative letting anyone who reads this thread know about it.

I suspect that you will have to reconsider your plan before the end of this month.   

[SlipperySlope]

Steve, I agree the above post that the Bitcoin mining community will not voluntarily give up their printing press. However, I seriously doubt that they will be collectively confronted with that decision on your timeline.

There is already at least one member of the NXT community who at least suspects that this system can be implemented in that coin. It undoubtedly can, if enough devs are charged with the task. The founding 70 odd members certainly have the capital to invest to make that happen,

Furthermore, the BlackCoin community is already aware of its potential, and you have posted your correspondence with their representative letting anyone who reads this thread know about it.

I suspect that you will have to reconsider your plan before the end of this month.   

I encourage the spread of CPoS as a technique to altcoins. I expect that public system tests meeting all challenges will sway the Bitcoin community by the time of an early 2016 launch.

[hbadger]

Hello Stephen.

Some problems I found in the OP:

- The linked specifications file doesn't seem to exist.
- The reward policy link requires authentication.
- Your linkedin link requires authentication. There is probably another way to link to it, though I wouldn't be surprised if there isn't, as linkedin has become so aggressive in their spam and tries to make everyone register.

I have read the paper and really liked it. Wouldn't it be good to add a little summary in the OP and insist on reading the paper, as most people tend to skip the links? Because at first sight, for someone who skips the paper, it seems like there aren't even any ideas on the concrete solution yet.

[SlipperySlope]

Hello Stephen.

Some problems I found in the OP:

- The linked specifications file doesn't seem to exist.
- The reward policy link requires authentication.
- Your linkedin link requires authentication. There is probably another way to link to it, though I wouldn't be surprised if there isn't, as linkedin has become so aggressive in their spam and tries to make everyone register.

I have read the paper and really liked it. Wouldn't it be good to add a little summary in the OP and insist on reading the paper, as most people tend to skip the links? Because at first sight, for someone who skips the paper, it seems like there aren't even any ideas on the concrete solution yet.

Thanks! I fixed the specifications links and permissions on the reward policy link. The LinkedIn profile is probably something I cannot change. I will add the whitepaper abstract to the OP.