Nice charts. I especially like the central tendency illustration over the past 12 months.

Here is the one-week resolution log chart of Bitstamp prices with your regression line approximated by me. The bottom technical indicator is the KDJ as provided by Bitcoin Wisdom. A backtested strategy suggests buying when the J line (purple) rises above 50 and selling when the J line falls below 50.

Thanks for contributing to this discussion!

You suggest a way that mining payouts can be filtered out of the ordinary bitcoin transactions, so that we have a more principled data series of economic bitcoin transactions as input to a Metcalfe Law network-effects model relating either bitcoin price or market cap. A scan of the recent blocks created could be used to filter out transactions output directly or indirectly from a coinbase, i.e. 25 BTC block reward transaction.

In addition to perhaps obtaining a less noisy Metcalfe Law model, I wonder if the unexpected might occur. Satoshi envisioned that miners would be enthusiastic supporters of Bitcoin, and I was there back in 2010 to see that happen. If we remove the effects of their reward-based transactions from the data series, we might end up with more noise instead of less, if indeed the filter removes a substantial portion of the daily transactions.

For the present, I will continue to rely on the Blockchain.info data series for the Number of transactions excluding popular addresses. I invite other modellers to pursue alternatives and share their findings.

When Satoshi Dice used dust transactions to indicate wager results, Blockchain.info developed the simple algorithm of discarding transactions that involved any of the 100 most popular addresses each day - Satoshi Dice of course being high on that list.

https://blockchain.info/popular-addresses

When I was mining for BTCGuild on my GPU rigs a couple of years ago, I suppose that the origin pool payer address was the same for each miner. It might be harder today if the pools are using unique payer addresses to enhance anonymity.  Looking over my daily payout last spring from LeaseRig.net, I do not see any address reuse.

Any miners on this thread know if their daily pool payouts originate from the same address from day to day?

I consider mining transactions to be economic, but of lesser importance than using bitcoin for purchases or earned income. I suppose that network difficulty is arguably unrelated to transaction volume, and that the correlation you observe is merely a coincidence. I could argue that vertically integrated industrial mining leads to fewer miners and thus fewer transactions required to pay them.

I suffered through a steep increase in mining difficulty the week in June-July 2010 when I first downloaded bitcoin and began CPU mining on my then-awesome quad core AMD server. Within a few hours I solved my first block, but the next one took a week and that was it for solo CPU mining. I learned of Bitcoin from the widely read Slashdot blog article, and that same article was also read by many system administrators who proceeded to install the software on the hundreds and thousands of computers that they managed. According to the Blockchain.info data series, the number of daily transactions back then was about 200-300 and did not match the sudden difficulty increase from 24 to 182 - a factor of 7.5x.

I will be speaking on a panel presentation on the subject of mining algorithms at the Hasher' United Conference in Las Vegas this month. I wonder what mining equipment vendors' answer will be to the question of the relative proportion of small miners vs large miners over time.

Yes, and thank you for the helpful clarification.

Mathematically, the logistic model has the property of decreasing exponential growth, which is most obvious on a log graph as we near full adoption. It is only a falsifiable hypothesis that a logistic model can explain bitcoin prices. My reason for choosing this model was to fit the obvious constraint that exponential price growth must eventually end. Perhaps we are at that point now, but I believe not based upon the steady improvement in Bitcoin transactional infrastructure. http://www.bitcoinpulse.com/

There is at least one mathematical theory of price bubbles that could be used to elaborate this logistic model, but I hesitate to combine them for fear of unsound overfitting given the additional number of parameters whose values must be set. The bitcoin logistic model has only two parameters: the maximum price and the full adoption duration.

As stated in the original post, my high price of $1 million is simply a guess. I could get a better fit on the logistic model with the data series to-date by assuming a high price of $2500. But that implies that we are near or have passed the adoption midpoint - which is hard to believe.

Alternatively, I am intrigued by the suggestion that the logistic model is a better fit to market capitalization data than to price data, because market cap takes into account the supply of bitcoin that meets the demand of the marginal new adopter.

I shall prepare another model using bitcoin market cap, but I would very much like to wait until the new year or a bubble, whichever occurs first because bubble peaks are easy to recognize and bottoms much more difficult. The right hand side of the model graph is hand fit to balance the central tendency and it is not clear yet where that region is for the bubble that peaked in November 2013.

Thanks to you and to the foundation for the Developer Guide.

Most of the conversation is on-topic. Not trollish behavior I believe. Crowdsourced projects need to air their issues, while achieving consensus on their policies.

I would accept that this observation weakens the Metcalfe Law hypothesis with regard to Bitcoin network effects. But as Peter_R has shown in his charts, there is considerable variability in the data series, although over time the correlation is significant.

I continue to wait for the 7-day smoothed number of transactions excluding the 100 most popular addresses to exceed 80000. That would be an all-time-high. And if bitcoin price is still depressed then that would be stronger evidence against the hypothesis.

Perhaps I can change that opinion. I suppose that because Bitcoin Core was written by Satoshi in C++, that language is the traditional approach in cryptocurrency. C++ is arguably more performant than Java, but the latter's many security and productivity advantages are well known.

For example ....

1. Java has a number of excellent Integrated Development Environments which enable the faster design, writing, debugging and regression testing of applications. In contrast, Bitcoin Core developers often use command line tools.

2. Java is inherently safer than C++ in that security is provided by a runtime environment which abstracts the underlying operating system and hardware.

3. Java encourages reuse. Notably, I use the Bouncy Castle cryptography library in this project.

4. Java source code is easier to read and understand than the same behavior written in C++. Please look at the source for BitcoinJ on GitHub vs the Bitcoin Core source on GitHub. More programmers have been taught Java than C++. Unfortunately, I believe that Satoshi received a Computer Science degree before Java was popularized in the late 1990's.

5. The community you speak of probably does not develop applications for Android, the world's dominant mobile device operating system, which because of the reasons I mention, strongly favors their rebranded Java language.

Bitcoin Core developers are stuck with the messy C++ code Satoshi left them, and have been forced to rewrite half of it, according to Gavin Andressen. In this project I have made very modest changes to C++ Bitcoin Core to repurpose its testing behavior, allowing the creation of a new block every 10 minutes with a trivial proof-of-work. I treat bitcoind as a slave process entirely controlled and proxied on the network by Java software agents. Thus this project retains full feature and bug fidelity with the Bitcoin protocol, and compatibility with existing wallets and processors via a set of TexaiCoin seed IP addresses and port.

Writing in Java, i.e the NetBeans IDE on Ubuntu, enables me to swiftly explore alternative implementations of new features.

As suggested in a prior post by Scumby, I am currently working on keyless signature infrastructure as part of the tamper-evident log module. I am using SHA-512 hashing as provided by Bouncy Castle. Each full node's logs will be temporally salted with the current Solar Flux indicator and hashed into a network-wide, timestamped merkle tree whose root value is widely known and archived, e.g. into an operators' mail list. This prevents equivocation misbehavior by a peer which cannot undetectably report an incorrect version of its state to an attesting peer, who verifies the target peer's version state hash in the distributed provenance merkle hash tree.

I am so glad to be using Java.

Self-signed X.509 Certificate Transparency

In this project I need a tamper-evident log-store of X.509 certificates replicated in, or otherwise available to, each container. I could simply trust a remote peer's certificate upon first use, but that method does not prevent a man-in-the-middle attack. A better alternative is a replicated tamper-evident log-store that is checked by the sender for correct listing of its IP address and certificate. The message recipient verifies the message signature of the message using the certificate looked up, or previously cached, for the sender's qualified role name: container-name.agent-name.role-name.

Each peer agent/role that communicates beyond its container to a remote agent/role will generate its own self-signed X.509 certificate and safeguard the private key in the local container encrypted keystore. I am thinking about following the keyless signature infrastructure (KSI) design suggested by Scumby in which a growable binary merkle hash tree timestamps and stores the certificates along with a Solar Flux Index chaos value. An index over the log-store records keys consisting of the qualified role name, and values consisting of the IP address and certificate of a peer agent/role. A later-dated entry for a peer supersedes an earlier-dated entry in the log-store, which permits container operators to occasionally migrate from one IP address to another. I expect paid super peers to have static, seldom changing IP addresses. Lesser-paid, blockchain archiving nodes, may execute using a residential internet connection having a dynamic IP address, which would not be recorded in the certificate log-store.

 The tamper-evident log for the certificates would be part of the downloaded container for a new installation, and would be updated securely by polling a sufficient number of peers once connected to the network.

The previous version of Texai used a Chord distributed hash table to contain the certificates. But for TexaiCoin I have removed the Chord library as it was another moderately complex attack surface that could be avoided by using a simple tamper-evident distributed data structure.

I see now. For this reason and to filter out other non-economic transactions, Blockchain excludes the 100 most popular addresses when calculating the data series that I follow.

Awesome.

This is a nice complement to what Peter_R calculated. I hope that transaction quantity growth continues for the next few months. My hypothesis is weakened a bit with this chart which shows transaction quantity relatively surpassing market cap in the summer of 2012, without a major new bubble.

I briefly chatted with Gregory Maxwell on #bitcoin-wizards last spring as I was publishing my whitepaper on Bitcoin Cooperative Proof-of-Stake. Certainly the Bitcoin core developers are skeptical that anything other than proof-of-work can solve the distributed consensus problem. He graciously wished me well with regard to my approach, and I believe that the core developers, e.g. those chatting in #bitcoin-wizards IRC channel, will have more pointed questions and comments when this project's working code is deployed into production, vs commenting on a whitepaper.

Satoshi designed bitcoin, I think, by adapting a napster style peer-to-peer network, e.g. omitting the central index server, to support an anonymous digital currency. His envisioned users were also operators who mined bitcoins using their laptops, from residential internet connections, while joining and leaving the network at will. This is the context of how core developers view distributed consensus.

In contrast, this design fits the Satoshi Social Contract into a conventional distributed enterprise-style financial network, e.g. omitting central control. Its envisioned users are wallet owners and payment processors. Its envisioned operators are non-affiliated paid system administrators who securely provision identical software containers on bare metal dedicated servers in geographically disparate datacenters. The system is innovatively managed by peer-verified software agents having no single point of failure. The nomadic mint agent builds a canonical non-forking blockchain, which is widely copied, and allows immediate transaction processing without confirmations.

Andytoshi, a core developer and mathematician here in Austin, said to me over lunch: "But this is not Bitcoin!". He elaborated to say that a single mint was opposite of what Satoshi wanted. Andytoshi was not then persuaded by my argument that a peer-verified nomadic mint solved the problem of trusting a central mint. Rather he was interested in the vulnerabilities my scheme might have with regard to attacks and network faults in which the system must come to agreement on the correct or optimal version of system state, e.g. who gets to be the mint, and what happens if there are forged blockchains. That is why this project needs to reach production for such fault scenarios to be designed, tested and reported.

Here is the 15-minute resolution chart showing what I believe to be a short-covering bitcoin price rally. Large blocks are being purchased on Bitstamp. Gold prices have rallied a bit in the last hour too.

And here is the daily gold/USD price chart which shows a small rally coincident in time with today's bitcoin price rally ...

Here is the 15-minute chart of Bitstamp prices showing what I believe to be a short-covering rally. It will be interesting to see if this continues past a few more days....

Short covering rally would be expected.

Sorry, that I am very busy with my altcoin development. I will add the data series from Blockchain.info on bitcoins in circulation ...

Total Bitcoins in Circulation (CSV)

Thanks Scumby for your articulate understanding of my work.

I examined the DRAO website and have written a message to their webmaster asking about why the displayed solar flux index is months old instead of current. Another potential micro-revenue service for TexaiCoin would be to wrap an API around the daily solar flux measurement and its recent archived values.

I am constrained to keep the blockchain structure unchanged so as to maximise the opportunity that my changes will someday be incorporated into Bitcoin Core. But that does not keep me from creating a parallel data structure as you describe for KSI, which I now somewhat comprehend because of your explanation. The blockchain must remain a public ledger in its entirety, but I can envision a KSI process as you describe to irreversibly record blockchain hashes at each new block.

And here is a link to a recent Ahto Buldas' paper which at first glance may be what you are describing ...

Keyless Signatures’ Infrastructure: How to Build Global Distributed Hash-Trees

Could you elaborate on the non-shared portion of the KSI hash tree? This appears to be the key to irreversibility. If an adversary had more than 50% of the nodes in his control, then he could out vote the legitimate nodes - right?

I believe that I can publicly publish the blockchain hash as well as the KSI top hash when each new block is created as a trust anchor. For example it would be easy to automatically publish those in a dedicated forum such as Yahoo or Google groups in append-only style where the account is administered by TexaiCoin core developers. Likewise the system could append hash value entries to an otherwise readonly Google Docs spreadsheet. Then an adversary would have to hack each of these public records to maintain integrity with his forged blockchain.

According to this chart of the smoothed adjusted number of bitcoin transactions, the uptrend of the past few months could, if continued at the same pace, surpass the previous all time high 0f 76394 within two to three more months. In the history of this data series, a new all time high has always been associated with the inflation stage of a price bubble.

This is my falsifiable hypothesis: if the 7-day average of the number of transactions excluding popular addresses as calculated by Blockchain.info exceeds 76394, e.g. reaches 80000, then bitcoin price will be rallying into a new bubble.

Among the ways this notion could be wrong is that transaction volume is now including more bitcoin tumblers to provide anonymity, or some other sort of non-commerce transactions, not filtered by Blockchain.info's simple algorithm.