Buffet will not buy bitcoin until he is convinced that the brand is a sort of monopoly and immune to a superior technology. That is still a question, so long as the foundation's chief scientist calls Bitcoin an experiment.

Buffet's companies will be mid to late adopters. I believe that they will use bitcoin to replace bank payments when it is obviously better to do so.

We are early adopters, paying perhaps one-thousandth the price now that Buffet or his successor will pay in a few more years.

I watch this chart daily. Three days ago I believe that the collected data was corrupted  34,888 is too low. Earlier that day values were higher.

From March, the recovery in transaction volume seems to lag. Others have suggested that this is due to an increasing portion of transactions occurring through payment processors such as BitPay and coinbase, which may be performing off-chain settlement if both parties have off-chain accounts at the payment processor.

Today I am working on my first bitcoin pull request. Following Gavin's instructions How to create a PULL request.

I am using the NetBeans C++ IDE on Ubuntu, which is not what most core devs use apparently. They use tools from decades ago, and depend on clear thinking, not the intelligent abilities of modern Integrated Development Environments.

The core devs mostly ignore compiler warnings as long as the code builds and tests OK. NetBeans dynamically parses the code in its editor and warnings are highlighted. I messaged sipa on #bitcoin-dev about some cruft in main.h and he is fixing that. Now I want to fix another warning/bug in main.h myself.

I am using Gavin's procedure for a pull request to fix just one line of code that will not really make any difference at all in how Bitcoin works. My plan for the next few days is to fix all the warnings that are easily fixed in the source code as revealed by NetBeans.

Then I need to get a couple of bitcoind instances running in a single machine testnet.

And I will begin to document how to write the tamper-evident log that is a key component of this project. The core devs have been helpful and have encouraged me, as is right, to explore an idea as an easily revised document, rather than as blind-alley coding.

Thanks for responding. I need very much to continue listening if there is any hope of achieving the wide approval this project needs to launch in early 2016. I am now downplaying the payment of dividends to those who offer hot-wallet stakes. I think that needs to happen to the extent required to prevent an attacker creating many controlled puppet full nodes and out-voting the correct nodes when a detected inconsistency requires correction. The bitcoin core developers are skeptical yet awaiting "neat technology".

The daily mining reward has risen to $1.8 million. I suggest that a well funded team of say 200 programmers can easily be paid from this sum to out-compete subsequent forks.

The system I am presenting has a one-time opportunity to re-engineer the network, while preserving the Satoshi Social Contract. The reward schedule, the blockchain format, the fixed number of bitcoins, and the decentralized, trustless protocol  are untouched. The system remains a global distributed database, with additions to the database by consent of the majority, based on a set of transparent rules they follow.

Metcalf's Law, as charted by Perter_R, would suggest that the user base need only grow at a third of the rate of price growth. His model is that the network value, i.e. the market cap, is proportional to the square of the number of network nodes, e.g. number of investors, number of transactions, or number of Bitcoin addresses. Price growth averaging 10x annually is accordingly supported by 3.2x annual growth of new users, which works out to 13-14% average monthly growth in users.

http://www.bitcoinpulse.com/ as most know has many adoption indicators being tracked.

Here is a 3-day resolution chart of the breakout rally that probably marks the end of the November 2013 bubble collapse. My logistic model says the prices must rise about $10 each day to stay parallel with the long term Log10 trend. The trend price for today by the way is $1344.

Respectfully, I do not understand the irony.

Could you please elaborate on your reasoning that allows an interpretation the opposite of what I perhaps poorly wrote?

If we are going to drive Visa and bank wire transfers out of business, then our network needs to be better than theirs. It cannot depend on part-time laptops and ADSL connections. It can be supplemented by those sort of home computers, but the network needs to be non-stop, redundant, and robust in case of power failure and Internet connection outages.

Enterprise class servers and networks are a solved problem. All it takes is money. Each day block creation rewards total about $1.6 million. There is plenty of money to give Bitcoin the hardware it deserves and to pay people around the world to run full nodes - if and when CPoS replaces PoW.

The response was . . .

Bitcoin is not a democracy. It's a micro-government, but where those with the hashing-power are for ever the rulers of Bitcointopia. There is no necessity to preserve the existing wealth. If the system is superior it will earn it of the market. And so we have a market of competing currencies. The incentives are high enough for people to make a better invention. Starting from scratch in software is often a good thing.

Initial Install of Bitcoin Core and wallet . . .

Following Jameson Lopp's directions http://coinchomp.com/2014/04/03/set-ide-developing-bitcoin-core-ubuntu-linux/

I have the branch from GitHub at https://github.com/StephenLReed/bitcoin

I followed the directions in build-unix.md. I have Ubuntu 13.10.
 
I added the bitcoin repository - ppa:bitcoin/bitcoin

Of the options, I chose to install libdb4.8, libboost1.53 and libminiupnpc-dev.

I executed ./autogen.sh
I executed ./configure until no errors
I executed make
OK

I installed NetBeans for C++ and compiled the bitcoin project OK. NetBeans gives hints as to problems it finds in the editor pane and I messaged sipa on #bitcoin-dev about this unresolved forward reference in main.h . . .


sipa said it should be . . .


The change built OK in NetBeans, so the next step is to run the provided regression tests. The regression tests ran OK.

The bitcoin core code only has perhaps 30% of Satoshi's code remaining. It can change.

The proposed system takes pains to preserve as much as the Satoshi Social Contract as possible. That is what users see. For them nothing much should change, and what does change should be much better. Full nodes are the foundation of Satoshi's Bitcoin. My proposal pays for upgrades so that they may process all the world's transactions.

A comment from the bitcoin-development email list . . .

I'm doing a hard fork, too. In my version 78% of the wealth will go to me, which I will redistribute on based on personal preferences. Come and join me into a new and obviously superior system.

More seriously though: the paper is not bad, but I can guarantee you that Bitcoin will never change that drastically. That's the whole point. It has an indestructible kernel (think DNA). Rather it will do a slow death, probably in 5-10 years. If you care for PoS than just launch your own.

Thanks for commenting on my whitepaper. I linked proof-of-stake and infrastructure incentives because reallocating the block creation rewards yields $1.6 million daily, which pays for a lot of infrastructure, transaction fee subsidies - and just say 200 paid developers.

The banning of misbehaving nodes is an unclear statement on my part which is an attempt to characterize how a bitcoind instance currently disconnects from peers who repeatedly send invalid messages to it. That aspect of bitcoind I would not change. I extend that behavior so that peers actively replay each other's operations to check for consistency. When an inconsistent peer is identified by a quorum of its peers, it is disconnected - for some temporary period. And the reason would be made clear to the disconnected peer owner by an alert.

Relevant chat log from the #bitcoin-wizards IRC channel . . .

<gmaxwell> stephenreed: Yes, bitcoin is ugly in many ways. I spent a decade working for a company building huge routers for internet backbones and working with big providers... I'm well familar with big communications infrastructure.  Bitcoin uses non-scalable mechnimes in a way which "can't work" to achieve an end— an anonymous decenteralized consensus— which "isn't possible" by conventional thinking.  In practice, so far, it does work.  ...
<gmaxwell> ... And I'd love to see something that achieved the same ends, but wishing it doesn't make it so... The uglyness in Bitcoin is not an accident, not a result of ignorance... the problem space truly is hard.
. . .
<gmaxwell> At one point I wrote long winded essays that what bitcoin achieves— a decenteralized consensus— was precluded by physical law. I was wrong, because I didn't consider the right relaxations of the requirements (the the consensus could be eventual and only so under certian economic assumptions, that a vote could be sufficiently sybil resources through the provable expendature of physically finite resources and at the same time ...
<gmaxwell> ... create the incentives the first required). There might be similar alterations of the assumptions or requirements that yield alternative solutions. I certantly hope so.  But I'd expect the presentation any successful attempt to start with a very clear statement of what the assumptions and limitations are, and how it addresses the hard problems that arise in this space.
<gmaxwell> (well to be clear, I'm already aware of some different designs with different assumptions— e.g. there are some proposals which achieve awesome properties— fast, secure, and scalable— that depend on a simple majority of non-anonymous signing registrars being honest. E.g. the compromise decenteralization to get basically every other property you could ask for)
<stephenreed> adam3us: I saw the link to Chris' paper on the dev mail list, read it, and asked him for permission to use it as a reference in my paper. He gave it.
<gmaxwell> adam3us: Amiller, jbonneau and others have been working on a systemizing bitcoin knoweldge paper: https://github.com/citp/bitcoin-sok
. . .
<stephenreed> gmaxwell: this is a key paper that I referenced - http://iris.csail.mit.edu/irisbib/papers/aaom:sosp21/paper.pdf    Attested Append-Only Memory: Making Adversaries Stick to their Word, Chun et al. Their math says it is byzantine fault tolerant with respect to relicas less than 50% faulty. Then I use timeline entanglement to make the logs tamper-evident. Also a reference from my paper.
<stephenreed> gmaxwell: Nick Szabo explained the benefit of unforgeable logs as you probably alreadky know.
<gmaxwell> stephenreed: I believe I've read this before? Will check... but generally the problem the clasical approaches have is they do not work in the model of anonymous membership. You have have agreed in advance the identity of the members of the participants in the system. (and have some method to be confident that they are not mostly sybils of a single party)
<stephenreed> gmaxwell: given your network architecture experience, superior to my own, would you say that such a network could indeed handle all the world's transactions?
<stephenreed> gmaxwell: in my system the peers provide a controlled bitcoin address both for identity and for signing their non-transaction messages. That is the audit trail peers can easily verify.
<stephenreed> gmaxwell: Sybils are prevented by the need to sufficient stake them.
<gmaxwell> stephenreed: Bitcoin the payment network? of course not, but it doesn't need to for bitcoin the currency to handle all the worlds transactions (if the world wished it so).  With a sold, throughly secure and decenteralized base we can run additional payment systems on top of bitcoin to achieve additional features and scale.
<stephenreed> gmaxwell: I mean is the super peer network truly capable of handling all the worlds transactions? I think so based on what I read about VisaNet and SwiftNet.
<gmaxwell> stephenreed: If the identity is a propery inside the system how do you prevent simulation?  An example of simulation attacks: past participants leave the system, someone obtains their keys, recovers a snapshot from when they were still a quorum, then plays forward creating a new alternative history.  A new entrant joins the system, he can tell that someone cheated (by the conflicting signatures) but how can he distinguish which state ...
<gmaxwell> ... is the 'real one'?
<stephenreed> gmaxwell: the point is weakened if the peer behaves correctly. A thief to the original owner - but that is same in the current system with regard to hacking a hot wallet.
<andytoshi> stephenreed: the problem is that you have humans determining which transactions go where, so there is no canonical "behaves correctly" in this case
<stephenreed> The orginal history was created by a very carefully single nomadic mint. Did you get that point? All full nodes replicate the single version blockchain.
<gmaxwell> Those thefts happen all the time, even when there is something significant at stake— in my example though they keys could be stolen after the peer has no involvement with bitcoin at all and will lose nothing in an attack (and in fact, may gain handsomly by facilitating an attack)
<stephenreed> gmaxwell: created by a very carefully watched single nomadic mint agent ...
<gmaxwell> stephenreed: I'm not sure I follow your question wrt super peer network. My own prior comment was that I believe the bitcoin ecosystem in total would be able to handle all the worlds transactions, if we wished it to.
<adam3us> gmaxwell: i think the scale question should be with the caveat that to interestingly scale, the main bitcoin properties should still be available to all users (unseizable, unfreezable, user control) for that to be an interesting scaling architecture.  its less interesting if we have a $100k min transaction clearing network with unseizability for them, but trust me for users.  (less but still interesting, viz international banking freezes and spats)
<stephenreed> gmaxwell: Indeed a mesh network could have preferred connections and that is how I intend to modify the core to become a super peer network.
<jgarzik> noooo
<andytoshi> stephenreed: to a newcomer, the original history and a forked history may be indistinguishable as far as legitimacy goes. it's hard to verify things like "carefully watched" even if you are forcing your superpeers to basically be visible economic entities (since they need so much space and bandwidth)
<gmaxwell> stephenreed: There are a great many things you can do if you have a centeral point of trust. And lots of ways to achieve audiability where misconduct of that agent is visible... Thats a viable approach but _very_ philosophically different from Bitcoin, because that agent is still trusted. (I wonder if you've seen the original p2pfoundation announcement of bitcoin? http://p2pfoundation.ning.com/forum/topics/bitcoin-open-source )
<jgarzik> somebody else proposed a super node network at the AMS conference
<jgarzik> how many variants of "but, if we just TRUST these guys over here a little bit more" do we need?
<stephenreed> jgarzik: my ideas are not new. The super peer idea evolved out of the p2p stuff back when Satoshi was looking at napster.
<stephenreed> gmaxwell: My software agents are trustless as Szabo suggests. The unforgeable log enables peers to validate.
<stephenreed> jgarzik: Super peers have superior network/server capability but run the same code base.
<jgarzik> same code base or not is immaterial
<stephenreed> andytoshi: yes visible so that cooperation is assumed but cheating quickly detected. The network reengineering can easily handle the increased traffic - point to point, not mesh.
<andytoshi> detecting cheating is easy, determining who is/isn't cheating is not
<andytoshi> stephenreed: even if you get trustless software agents (e.g. by auditing their behavior or somehow TPM-verifying that they are clean VMs running only your software) you still have (a) random coins, e.g. for peer selection, and (b) user decisions, e.g. transactions, which are inputs from the real world and therefore can be used to introduce distortions and/or forks
<stephenreed> jgarzik: material because tamper-evident logs record every action, inputs and outputs of a peer.
<stephenreed> andytoshi: that point addressed in the paper linked above - less than 50% faulty agents can be tolerated.
<adam3us> stephenreed: how can i audit a network entities tamper-evident logs? TPM remote attestation?
<jgarzik> andytoshi, indeed.  And RE detecting cheating, Sybil'd views can make you particularly vulnerable
<stephenreed> adam3us: yes, but I omitted TPM attestation from the paper because current implementations are too proprietary. I want a TPM enabled stack that says your current release of bitcoind is running and nothing else - no keyloggers etc.
<stephenreed> adam3us: here is the paper on TPM attestation that I studied - http://www.mysmu.edu/faculty/xhding/publications/stc08.pdf
<gmaxwell> stephenreed: These are all neat technologies that we've talked about in here and ought to exist as part of the greater bitcoin ecosystem... but they are really not a replacement for what Bitcoin provides.  E.g. the TPM hardware maker can trivially compromise those systems.
<stephenreed> adam3us: For TPM I was looking at a bare metal implementation not a hypervisor.
<gmaxwell> (I happen to have an IBM cryptocard myself— which is basically the pinnical of remote attest technology right now— ... and I've been playing around with the nexus operating system, which is a hypervisory OS that facilitates remote attest)
<stephenreed> gmaxwell: right about TPM. I understand you need a license to use it in China for example. So remote attestation of unforgeable logs per Szablo works too.
<stephenreed> gmaxwell: They are not a replacement for proof-of-work. They are a replacement that preserves the Satoshi Social Contract between developers and users. My ideas are half-baked now. The code to be written will speak for itself.
<gmaxwell> Traditional reserve currencies are backed by power and authority of natition states— entities with the power to extinguish all life on earth (well, at least all human life)— and yet they do not behave in a way that many people consider trustworthy— they are rules by politics and personalities not by Law.  Some of them have apparently strong social contracts, and yet they do not prevent mission drift.
<gmaxwell> Well I look forward to seeing some neat stuff!
<stephenreed> I wish the Barcelona test harness was done. I need to orchestrate lots of peers to meet your challenges.
<gmaxwell> (don't take my cycnism for dislike)
<stephenreed> gmaxwell: according to Gavin's videos you are the core developer that I need to convince first - Thanks and wait for code.
<stephenreed> Thanks for observing while I write the code of a lifetime.
<adam3us> stephenreed: i would encourage generally to explain algo before coding it because its many orders of magnitude faster to explain an algo than to code it; that way you get feedback early if there are problems that'd need a rewrite
<gmaxwell> Right well in particular make sure the high level objectives of the algorithim are clear before the details.  It's a lot of work to sort out the limitations in the architecture of an idea starting at the 'molecular level'.
<jgarzik> Yes, gmaxwell is the gateway to a new universe ;p
<gmaxwell> Hopefully not in the sense of some volcano-involving rital sacrifice.
<gmaxwell> In other news, the bytecoin-derrived cryptocurrencies ecosystem is now using merged mining, there is now a fork that is merged mined against and of the 3 (or more?) prior bytecoin-derrived cryptocurrencies. (this isn't super news its a few weeks old, but its news to me)
<stephenreed> adam3us: After making or reusing a test harness,  the first bit of work is the tamper evident log, which should be easy to document since I will look closely at the current debug log of bitcoind. The step beyond that would be timeline entanglement which makes the logs tamper-evident. I need to be able to digitally sign a peers log. The functions I need should already be in the core, provided I can capture the key p
<stephenreed> air somehow.
<sipa> "the keypair", which?
<stephenreed> sipa: If you have been following the conversation, then Szabo style unforgeable logs can be created if peers sign  each others logs. I propose for a peer operating a full node to provide a key pair for that purpose, e.g. a bitcoin address public/private key pair.
<sipa> you say "capture the keypair somehow" -> which keypair?
<gmaxwell> stephenreed: in bitcoin the blockchain itself is the unforgable log, but because the system is anonymous (there are no enumerated identities) they are signed via cumulative proof of work instead of a traditional digital signature.  Debug.log is orthorgonal, it's just for software QA, and very little of it is about information which is interesting to other parties.
<stephenreed> sipa: Well the QT wallet securely stores private keys so I suppose I would reuse that method.
<sipa> nodes have nothing to do with wallets
<sipa> it's a historical accident that satoshi's software does both
<gmaxwell> stephenreed: normally bitcoin keys in wallets are intended to be single use, one transaction. As sipa notes we've been slowy working towards seperating the functionality.
<stephenreed> separation is great. My purposes require that a peer sign another peers log to make it tamper-evident. I need for the node operator to provide the private key to bitcoind. The wallet has a method to input and securely store private keys. I may need the wallet in order to received daily dividends from the "reward agent".
<sipa> sounds like you just need something like a host key
<sipa> independent of the wallet
<stephenreed> sipa: how would you store it?
<sipa> oh, you also use it to receive coins?
<stephenreed> sipa: I need to receive bitcoins yes but that may be orthogonal
<sipa> you get rewards for running a full node?
<stephenreed> sipa: I hope that you will read my whitepaper ... https://docs.google.com/document/d/1C4m-MFnxw0JjDorzrKs_IRQRqD9ila79o0IDt6KsbcE
<andytoshi> sipa: as i understand it, that is part of stephenreed's proposal because he has mechanisms by which peers enter and leave the system (which include proving some amount of dedicated resources as a sybil prevention)
<stephenreed> sipa: I also have a good set of extended references on the bitcointalk thread OP - https://bitcointalk.org/index.php?topic=584719.0
<andytoshi> stephenreed: you want to separate bitcoin addresses from authentication, you can attach addresses (for receiving funds) to your ID by signing them with your auth key, but because addresses are supposed to be ephemeral they are not well-suited to auth on their own
<stephenreed> sipa:  The whitepaper describes -  a proof-of-stake version which uses a single nomadic verifiable mint agent and distributed replication of a single blockchain by compensated full nodes to achieve 6-hop, sub-second transaction acknowledgement times. Plus it pays dividends to holders instead of paying miners. Subsidized transaction fees are thus lower.
<sipa> sounds like a very different trust model than bitcoin
<sipa> (which is not a bad thing, but suggesting it as a replacement seems strange)
<stephenreed> sipa: a different trustless model yes. Cooperate to save effort, and verify peers to ban cheaters.
<sipa> bitcoin isn't fully trustless, and neither is this
<stephenreed> andytoshi: I will  note your comment.
<stephenreed> andytoshi: compared to todays bitcoin, I strongly desire permanent full nodes and would allocate sufficient reward to them to make that happen. SPV nodes can come and go.
<andytoshi> i guess you mean quasi-permanent, like tor, and that's another hard problem (though i don't believe it's impossible) to incentivize in a sybil-resistant way
<stephenreed> andytoshi: You must think that there is a hard problem that I am missing. I appears simple to me to keep track of peer uptime. I would create another agent to perform that duty.
<andytoshi> stephenreed: the hard problem is getting people to stay up when it's costing them resources and maintenance
<stephenreed> andytoshi: the peer would be identified by IP address and offered public bitcoin address. I would pay them to stay up. The current reward is $1.6 million per day divided by say 10000 full nodes!
<andytoshi> right, but it's easy to farm IP addresses and route them to a single box, it's hard to prove that every IP corresponds to disparate physical resources
<stephenreed> andytoshi: That is true of the current system where full nodes are hosted for $19 per month in a data center sharing a portion of some server. Replication of the blockchain is very important.
<andytoshi> it's true but why would anyone bother? it doesn't improve the decentralization or value of the network (which is the only incentive to run a full node today, besides goodwill and geek cred, which are also not helped by standing up sybils)
<stephenreed> andytoshi: Identity is supported by the controlled bitcoin address offered by each full node. The more stake, then more likely they are to be Sybil resistant.
<stephenreed> andytoshi: If there was a way for a software probe to determine, and to ensure, dispersed geographical locations - then I would use that.
<andytoshi> we had a recent discussion on ##crypto (or was it here?) about cryptographic proof of location, and i think we landed on "it's probably impossible" at least on earth since attackers can use fast airborne radio waves while honest parties have to use slow quantum signals in fiber optics
<andytoshi> regarding sybil resistance, if i have a lot of stake i'll get more reward but that still doesn't incentivize me to start more physical nodes. i'll open as many fake ones as my stake allows
<andytoshi> if anything using stake as a gatekeeping mechanism will cause your system to tend to oligarchy
<stephenreed> andytoshi: have to go, but I think online wallet hosting will be the largest stake holders.
<andytoshi> alright, ttyl, but as sipa says this is a large philosophical shift away from bitcoin

Comment from the Bitcoin-development email list . . .

I look at this and agree of course that the nodes are decreasing, see,
https://getaddr.bitnodes.io/   But when I see stuff in the white paper
like "misbehaving nodes" in the context of an "audit agent," a "single
non-forking blockchain," the notion of "Misbehaving nodes" that would be
"banned from the network" so as to "motivat(e) honest behavior," ~ really,
all of this does sound as though a sort of morality is being formulated
rather than a mathematical solution.

This is not to say that the white paper hasn't addressed a problem that
needs to be addressed, namely... the problem of the nodes disappearing,
and a few other things.  But to take that and then layer onto that the
issues associated with proof of stake... There does seem to be a simpler
way to address this and I think first without suggesting the complex issue
of some kind of thing that would involve dividends for those in a
proof-of-stake system, consensus achieved by stake-weighted voting, and so
forth, one would be better off removing all references to voting and
stake, and determining ways simply to incentivize more substantively those
who actually run a full node.  Additionally I am hesitant to characterize
behavior as has been described in the white paper, as it would seem that
(in such a system) there would be an inclination or a tendency to exclude
certain patterns or groups of participants rather than determine ways in
which all participants or potential peers can serve the network.

As a result of writing the whitepaper and listening to constructive comments, e.g. yours, about the proposed Bitcoin system, I am persuaded that paying dividends to stakeholders is a lower priority than investing bitcoin block creation rewards into a network capable of processing all the world's transactions.

This system needs a way to prevent an attacker from establishing numerous puppet nodes, who by acting in concert, could outvote the correct nodes and allow misbehavior. Proof-of-stake provides a means to limit the ability of an attacker to outvote correct nodes. The assumption is that correct nodes will offer sufficient stake in a hot wallet in return for a certain amount of dividends.

The reward allocation policy is most certainly going to be contentious, and increasingly so as the technical barriers are overcome by working code through the end of this year. Core developers are skeptical of my ideas. But if they are won over by working code, then what to do with the $1.6 million daily block creation reward is moved from fantasy conjecture to pressing importance.

The block creation rewards increase with the price of bitcoin, halving in the summer of 2016 to 12.5 bitcoins per block, but staying at that schedule through 2020. Supposing bitcoin indeed reaches $1 million per bitcoin in 2017-2018, then the daily block reward in 2017 might be $1.8 billion per day.

Provided that network infrastructure is generously funded, including just say two hundred paid developers, and that sufficient dividends are paid to support proof-of-stake voting, why not subsidize transaction fees with the block creation reward? I can imagine circumstances in which bitcoin transaction fees could be negative. Visa could not compete with that. The challenge is to prevent abuse, e.g. we could figure out a way for merchants to identify themselves and subsidize transactions paid to them.

Just wondering from your user name if you are a fellow miner?

If so, would you be better off buying dividend paying bitcoins with the money you otherwise set aside to upgrade your rigs? The bitcoin bubble and bust cycles tend to ruin miners. I keep my GPU scrypt rigs leased out for bitcoin on LeaseRigs. I will not sell the cards, I just migrate the mining algorithm away from ASICs.

Ok, I sort of get your chain of reasoning but I think it is faulty. Its not so much about where the purchasing power came from, but to me rather how it is spent. For example dollar bills can be literally burned. That is a form of useless spending. Or dollar bills can be used to buy bitcoins. That is better in my opinion, regardless of how much coal was consumed to create those dollars in the first place. And that is all I have to say on this until the code to be written can speak for itself.

Great start in your role as chartist. Plus it is much more fun to chart a breakout.

Finally we had a week in which the saying "this week is critical" actually held true.

The answer is Yes. But I do not follow your argument. A better response from me will have to await the availability of code to test.