The logistic model of bitcoin prices that I maintain shows a relatively large deviation downwards from the trendline that I hand fit back in November 2013. I plan to refit the trendline after the peak of the next  bubble whenever that is. It is difficult for me to believe that we are anywhere near the midpoint of adoption.

My model indicates that the trend price for today is $2,405 and obviously we are far beneath that price on Bitstamp.

https://docs.google.com/spreadsheet/ccc?key=0ArD8rjI3DD1WdFIzNDFMeEhVSzhwcEVXZDVzdVpGU2c

The adjusted number of bitcoin transactions chart from Blockchain.info suggests that fundamentally Bitcoin is resuming transaction quantity growth in the past few weeks . . .

Here is the latest bitcoin adjusted transaction quantity graph with log scale and 7-day moving average. Note the transaction quantity in the month of August  is now above May levels. The Bitstamp bitcoin price in May peaked at $683.

As a US taxpayer, the tax treatment of bitcoin transactions is most favorable when Bitcoin is categorized as a commodity, such as gold. I endorse the domestic legal actions of the Bitcoin Foundation in this regard.

If and when some national jurisdiction chooses Bitcoin as a legal tender currency, we in the USA may pay ordinary income taxes on the gains resulting from using bitcoins to buy stuff. My understanding that foreign currency held for investment however, e.g. a possible future Bitcoin currency, receives favorable tax treatment when sold for dollars.

Bitcoin is a currency however right now, simply because enough people worldwide believe it to be one. It certainly has the primary properties of a currency: Durability, Divisibility, Transportability, and Noncounterfitability.

The document loaded in Linux/Libre Office for me but used a lot of CPU so I was suspicious. Anyway, the content was not directly related to a logistic model of pricing.

I have a thread on the logistic model as applied to bitcoin prices here . . .

https://bitcointalk.org/index.php?topic=366214.0

and a shared spreadsheet with graphs here . . .

https://docs.google.com/spreadsheet/ccc?key=0ArD8rjI3DD1WdFIzNDFMeEhVSzhwcEVXZDVzdVpGU2c

The math of the logistic (S-Curve) model is simple. f(x) = 1 / (1 + e^-x). On a linear graph you get the familiar S-curve, but that is not very useful yet for bitcoin because prices have increased on average 10x every year so a log graph is best right now.

If bitcoin prices were to exactly follow the logistic function then the following properties would hold . . .

1. At the beginning starting from zero adoption, the growth is approximately exponential, decreasing rapidly near the midpoint.

2. At the midpoint of adoption, the growth is linear.

3. At the ending with full adoption, the growth is zero, decreasing rapidly after the midpoint.

Note that currently prices are substantially lower than my model projects. I do not believe that we are yet near the midpoint of adoption - so I expect either to revise the model lower or to witness a surge in prices sometime in the next few months.

According to Peter R's interpretation of Metcalfe's Law, to support the historical 10x annual average growth in bitcoin prices, transaction volume needs to grow an average of 3.2x annually. We are not there yet - but the last 30 days might just resume the historical trend.

Here is the one-year chart of adjusted bitcoin transactions showing the 7 day moving average on a log scale.

Note that in the last 30 days the trend is somewhat higher. I accept Peter R's argument that there is a Metcalf Law relationship between the transaction quantity and the price, namely that price is proportional to the square of the quantity.

Supposing the transaction quantity increase trend holds, then that should support higher bitcoin prices . . .

Here is the Bitstamp price chart at 3-day resolution. I drew the price resistance line at $681. The rightmost candle currently has the form of a "hammer" which often marks a trend reversal. We could be moving up from here into the $600's this month. On the other hand a hammer can also indicate the midpoint of a trend - but there is an abundance of good news and no bad news so I expect sentiment to not get worse.

The expected July rally did not occur. I am wondering to what extent 2014 price action will resemble 2012 price action as both these periods followed a year of dramatic rallies.

CPOS Bitcoin will create a new block exactly every 10 minutes, so on average the CPOS Bitcoin blockchain should be equal in length to the original Satoshi Bitcoin blockchain after the fork. Transaction counts per block will differ because of the relative popularity of the two forks.

Additionally I want CPOS Bitcoin to reliably accept low fee transactions and especially microtransactions to highlight an important advantage of CPOS.

Thanks for the tip!
-Steve

Sorry, I was on vacation. The regular updates have resumed. I resolve to perform the updates in the future even on vacation.

The widely expected July rally did not occur. Bitcoin transaction volume has been relatively flat this year, and I believe that a resumption of bitcoin transaction growth will fuel the next rally.

I just arrived at my summer home in the Colorado mountains, where I will escape Austin heat for a month.

The spreadsheet has been updated. Interesting that the trend price is growing at $25 daily.

I have migrated a few more code modules from the Texai system over to the Texai CPoS code repositories on GitHub. Notably there is an implementation of BitTorrent over TLS/SSL which I will later use for rapid blockchain update of new full nodes.

Texai previously used the Chord distributed hash table to find peers, but I want to replace this mechanism with something else that can connect the CPoS network and be subject to remote verification by peers. Continuing the pattern I set by a single writer to the canonical blockchain, which is then widely replicated, I suppose that the MessageRouter will use a shared dictionary of full node IDs and IP addresses. This shared tamper-evident dictionary would be maintained by a single writer and widely replicated. Changes to the dictionary should be verifiable by peers.

I will think about this feature and also the tamper-evident logs required by the blockchain operations. I believe that there is a Java abstraction that both these use-cases may inherit from.

Here is my contribution activity chart from GitHub. The migrated and tested code from Texai now totals 42,000 lines of Java source code, not including the 450 regression test methods.

Another great idea. I will add a glossary to the OP.

I completed upgrading the Bouncy Castle cryptographic libraries. I added two more modules from Texai now that their dependencies are in the project. The first is support for bittorrent messages, which is required by the SSLBitTorrent module to be added after the Network module is added. And the second is support for the Albus Hierarchical Control Network - AlbusHCN module, that is the Texai agent framework.

Over 300 unit tests are running OK on my local continuous integration server, which automatically rebuilds the project whenever I push new updates to the GitHub source code repository. Over 32,000 lines of Java source code have been added to the project, not including the regression tests.

I expect that I will add less than 10 more modules from Texai before I am ready to begin coding the first Bitcoin CPoS test case, which simply runs two slave full nodes that take turns hosting the nomadic mint agent which creates new blocks, without yet performing the required verification of the peer tamper-evident logs.

I did not know about Web ID. Your ideas are great. I was using UUIDs (random) as subject UIDs in the X.509 certificates I generate. I can revise the server to accept a Web ID from the user, and return the certificate as you suggest. Actually I have intermediate X.509 certificates that issue the end-user certificates. The root certificate is self-signed for texai.org - so no dependency on a trusted third party as a Certificate Authority.

The full node will host multiple agents and each agent can have skillful roles. The roles message other agent-roles in the network and need certificates to sign their messages if leaving the full node and going across the network. I can use UUID subject certificates for this purpose. I use a single IANA port already reserved for Texai, over which I will run TLS/SSL encrypted messages for Bitcoin, plus HTTPS for network operations, and BitTorrent for rapid provisioning of new full nodes.

For the past couple of days, I have been upgrading the Bouncy Castle Java cryptographic libraries to the newest versions. When those unit tests all work again, I will add the TLS/SSL networking code from Texai, and after that the agent framework from Texai.

An RDF API would be straight forward. I use the Sesame quad store to contain RDF statements. I will leave bitcoind and the blockchain alone, but the quad store will contain the OpenCyc knowledge base, and persisted java objects. I wrote an RDF entity manager which persists Java objects analogous to how Hibernate does it with a relational database.

Here is the 3-day resolution Bitstamp chart, in which I have drawn the resistance line at $835. This would be a target for the current rally at which point it may hesitate before moving higher . . .

The unsustainable super-exponential growth that characterized the three great bitcoin price bubbles is very much like the other academically studied asset bubbles. It is true however that the two bubbles of 2013 collapsed to a price very much higher than the starting bubble price.

I, like other occasional traders, love bitcoin bubbles.

I pushed the OpenCyc RDF repository to a new GitHub repository - https://github.com/StephenLReed/texai-rdf-repositories. Also there are a couple of testing repositories, Test and Benchmark.

The OpenCyc repository is used as the commonsense ontology, i.e. vocabulary and taxonomy, for organizing the conversations between Texai agents.

At the moment, some of the unit tests for the RDFEntityManager module are broken. The RDF repository files are comparatively large and so I moved them to a separate GitHub repository to make commits to the Java source code repositories faster.

The X509 certificate server project is now on GitHub and is working with my local Jenkins CI (Continuous Integration) software such that whenever I push a source code change to the GitHub project, Jenkins automatically downloads the changes, builds the project, and runs the regression test suite.

Here is the GitHub project page . . .



And here is my local Jenkins CI server page for the X509CertificateServer project . . .