I configured Jenkins continuous integration software on my local server, and now it rebuilds the project whenever any source code changes on the GitHub Texai project. About 170 unit tests pass OK. There are two downstream projects that are not yet on GitHub. The JavaCV is a computer vision library that I will not be using with Bitcoin CPoS, and the second is the Texai X509 certificate server which I will later add to GitHub as a project.  |
|
|
|
So is anyone buying and selling based on this logarithmic action? It seems like it could be a good indicator. If the price is x% higher than the curve, maybe it's a wise time to sell and buy in when it drops to x% under the curve.
Yes, I have been buying fractional bitcoin every workday since March at my local Bitcoin ATM because the Log10 difference from trend has been largely negative. The current price is $585, and the expected price according to the average trend is $1,624. Supposing the bubble peaks in July, then I expect a selling target price of $4000-$5000, and higher if the bubble is postponed. |
|
|
|
I added the Texai Java module X509Security to GitHub at https://github.com/StephenLReed/texai. 41 unit tests passed OK. X509 certificates are commonly used by websites to authenticate servers in the HTTPS protocol. In Texai, both endpoints of the communication channel authenticate themselves during the TLS/SSL encryption negotiation with X509 certificates issued by the Texai certificate authority server - which has a certain self-signed certificate as the root certificate. Only full node operators need to be concerned about these certificates when they initially install the software. |
|
|
|
I pushed, i.e. uploaded, two Java modules to my GitHub project repository at https://github.com/StephenLReed/texai. The first was the main project Texai which has been pruned down to one maven module - Utilities. I upgraded the Java platform to 1.8 and am using NetBeans version 8.0 as the programming environment. The Utilities module has 133 unit tests that passed OK. I use three different static bug-finding and style checking tools. Next to adapt and push to GitHub are the RDF Entity Manager and X509Security modules. Although the Bitcoin core developers have the advantage of portability and performance with their C++ language choice, I for one, am much better off using Java. It will be much, much faster for me to adapt the existing Texai Java source code than to learn C++ well enough to adapt the existing Bitcoin Core source code. When Bitcoin CPoS is deployed for testing starting this year and for ultimate launch in early 2016, it will only be designed to run on paid-for full nodes, that will get paid only if the full node executes the specified configuration. At the moment I am thinking that the full node operators will be instructed how to run Ubuntu Linux LTS, i.e. the long term stable version, Java 1.8, the CPoS Java components, and the then available Bitcoin Code bitcoind executable. Unlike the Bitcoin core developers who have to design and test code to run on Windows, Linux, MacOS, and other platforms, Bitcoin CPoS will be designed and tested to run on one platform, chosen for optimum security. |
|
|
|
|
A Blockchain-Based Exchange Between Proof-of-Work (PoW) Bitcoin and Cooperative Proof-of-Stake (CPoS) Bitcoin
Imagine that in early 2016 there are two versions of the Bitcoin blockchain and network. There is the legacy Satoshi Bitcoin network with proof of work mining. And there is the new fork CPoS Bitcoin blockchain and network. There will be a need to exchange value between the two blockchains as hopefully, the new fork becomes more valuable when users appreciate its benefits.
An nomadic exchange agent in the CPoS system would be connected to the PoW (old fork) network using a suitably configured bitcoind instance. The exchange agent could thus transact on both Bitcoin blockchain forks, i.e. PoW-fork and CPoS-fork simultaneously. Each user of the exchange would have both a PoW Bitcoin wallet and a CPoS wallet, which are two instances of the same program pointed at different networks. The wallets would be used to execute market orders. Multiple signature transactions should permit limit orders, in which the exchange agent provides the second signature when required as the limit condition is met.
There would be a one-hour settlement time on the PoW-fork side of the exchange transaction. The CPoS-fork side of the exchange transaction would occur at the end of the transaction settlement period.
The exchange agent would not have a hot wallet, as all transactions are performed on the respective blockchains. The earned trading commissions would be distributed immediately as microtransactions to the exchange owner. The exchange agent would have an API for charting sites. Trading bots could use that API to determine the market situation, and use their own bitcoind instances, in lieu of wallets, to perform the trades.
Being on-blockchain should allow fees to be lower as the design is simpler and there is no exchange hot wallet to secure. Without any connection to fiat currencies, it should be easy to find jurisdictions to operate the nomadic exchange in which the wallet interface alone is sufficient - without an enrollment that requires certain identification.
|
|
|
|
CPoS To Be Implemented Using the Texai Cognitive ArchitectureThe Texai cognitive architecture will be used to implement the multi-agent network that connects bitcoind, i.e. Bitcoin Core, instances together and enables a single nomadic mint agent that is the core idea of CPoS. Here are references and videos about my work with Texai . . . Texai is a cognitive architecture to achieve artificial intelligence via a dialog system whereby mentors teach the system skills. For Bitcoin Cooperative Proof-of-Stake, I will remove the demonstration dialog modules, leaving modules that perform . . . - X509 certificate server - provides Texai X509 certificates when installing full nodes
- X509 authentication - each agent and each hardware node is assigned an X509 certificate for pseudonymous authentication
- SSL/TLS network - communications between authenticated full nodes are encrypted with X509 certificates on both endpoints
- SSL Bittorrent - the torrent protocol is encrypted and used to catch up the blockchain on relaying full nodes as required
- Webserver - full node statistics and network operations are presented to the operator via HTML pages
- Albus Hierarchical Control Network - a robotics-inspired multi-agent network consisting of agencies, agents, roles and skills
- RDF Entity Manager - a Java object persistence framework that uses an RDF quad store as the storage. RDF is a semantic web language for knowledge representation
- Open Cyc - the open source RDF version of the Cyc commonsense knowledge base, which provides the extensible ontology that structures what Texai agents know and can do
My work plan for the remainder of June is to upload the selected modules to GitHub and begin implementing the first system test case which is a single relay agent full node communicating with a single mint agent full node. The initial version will not perform any peer validation, nor DDoS traffic scrubbing. Note that I need to test whether my approach requires any changes to the Bitcoin Core bitcoind code. I think not. Here is how I will slave bitcoind to the Texai network . . . 
|
|
|
|
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. |
|
|
|
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. |
|
|
|
I think it is worth noting that the "recovery" phase in June 2014 is the most smooth -- with the implicit assumption that this may show the "confidence" of buyers. In the previous two recovery phases, there's a significant amount of buyer "hesitation" if you will, indicating more anxiety about losing money, and therefore more "choppiness" in the line move up. However, the larger picture is that the buying pressure has consistently been stronger in all three recovery phases. I might explain that the obvious lack of "anxiety" in the buyers in this current phase may reflect the stronger position Bitcoin is currently in than ever in the past -- i.e., all of the ever increasingly more positive news regarding the adoption of Bitcoin by ever larger companies, continuing exponential growth of bitcoin wallet numbers, etc. and increasingly more supportive political/governmental environment for Bitcoin in the US. In other words, ever increasing fundamentals are supporting the price of Bitcoin more so now than ever, with the assumption that this fundamental trend will continue exponentially. Just my humble opinion.
I commend your line of reasoning regarding the increasing fundamentals. According to Peter_R's interpretation of Metcalf's Law that says bitcoin prices have a relationship to square of the number of users, addresses and quantity of transactions. The site Bitcoin Pulse has an excellent set of fundamental adoption data series. For prices to increase as they have in the past, 10x annual price growth is supported by 3.2x growth in the adoption fundamentals. My own CPoS project has as one of its benefits, low transaction fees and capacity for many more micro transactions than Satoshi's Bitcoin. |
|
|
|
My theory is that it is impossible to create an objective decentralized time-stamp server without a tether to the physical world.
CPoS has plenty of physical grounding in its timestamping. In what way is CPoS tethered to external objective reality? I can only see a tether to the subjective reality of the current and past stake holders. Anyhow, the obvious solution is to disallow rollbacks. Doesn't really matter how you get there.
Do you mean make orphans impossible? I think the only way orphans can be eliminated is if all the blocks are correct. And the only way all the blocks can be assumed to be correct is if the participants are assumed to be honest. But if the participants are honest, you don't need PoW or PoS: you just trust by default. You could also say, "OK, let's allow orphans, but only a certain way back." But if you do this, then you need checkpoints. And if you use checkpoints, who decides what checkpoints to use? So I don't think such a system can be Byzantine robust. Anyhow, I should read more about PoS before I make myself look even more foolish than I usually do.
I would suggest starting with this thread: https://bitcointalk.org/index.php?topic=615843.msg6751334#msg6751334The whitepaper describing Bitcoin Cooperative Proof-of-Stake (CPoS) is here. Essentially, CPoS has a single nomadic mint agent that periodically moves its state from one full node to the next. The single mint canonically timestamps each directly received new transaction and broadcasts an acknowledgement to the network. There is a thus a single blockchain appended to by the mint's slaved bitcoind instance, and the remaining full nodes replicate their own version of the blockchain to verify the mint agent's behavior. |
|
|
|
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. |
|
|
|
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. |
|
|
|
|
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++.
|
|
|
|
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. |
|
|
|
Bitcoin Centralization Problem Evolving Into Trusting a Third Party - GHash.ioSee: 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.
|
|
|
|
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. |
|
|
|
|
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 suggest a better system in a discussion thread elsewhere on this forum.
|
|
|
|
I know I'm getting ahead of myself here, but the NEXT bubble after the July one should take us into the $25,000 area sometime in March/April 2015.  The Bitcoin ETF's should be live by then. That would fuel the 2015 bubble. If there is a single bubble this year, then perhaps 2015 will be similar to 2013 and have two bubbles. |
|
|
|
Too late to the game? I hope not, I'm just starting to hold BTC now in addition to using it for purchases when I can.
Not much to say except 'hello!' as I enter on page 75 and look forward to more conversation in the future.
Come back at least once a year to check in. The price today is $664.11 per bitcoin. |
|
|
|
[I find it interesting to note that the number of transactions (ex. popular addresses) moves in 7 day cycles and hitting its low point without fail on Sundays.
Because payments to miners from pools occur every day, I suppose the day-of-week variation is due to consumer and investor behavior. Likewise bitcoin exchange volume drops on weekends. |
|
|
|
|
Show Posts
