Topic: AI Coin Development Diary - page 10. (Read 49308 times)

Good to know. If you have questions or need explanations, PM me.

What the hell are you talking about?

I make this post to go on record that I'm in favor of a hard fork of Bitcoin. The core devs and culture surrounding Bitcoin have allowed a 51% attack to occur, MtGox to become centralized, fail, and generate months of bad press, and refuse to switch out of SHA-256 and on to another hashing algorithm or at least Proof of Stake.

Other developers have been warning them, people were warned about MtGox, nothing changes. Instead excuses are constantly being made for increasing centralization. Every month we look and see more signs of centralization.

Either Bitcoin must be hard forked or I'll be using something else like NXT or Bitshares.

Nice idea. With GHASH.IO coming back again and again like a zombie, I think that this hardfork might get more popular soon.

Too bad it is estimated for January 2016. I hope that we will not need that sooner.

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.

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.

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.

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.   

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.

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.   

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.


.

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.

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.

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++.

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.

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   

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 . . .


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.

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.

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

Prolexic advice on securing a re-engineered Bitcoin network.


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.

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.