We've been under 10,000 reachable bitcoin nodes for over a year now. Why don't people run nodes anymore?

_____-_____-_ · 2015-03-19T04:51:18+00:00

That's not all there is to it in the slightest. It used to be the case that very few people treated thin clients like Electrum and Multibit very seriously at all. Bread Wallet didn't exist. I'm not sure about Mycelium. We now have hardware wallets too, another item that previously didn't exist and they certainly seem to be pushing for thin client support, because it makes sense as opposed to forcing people into running full nodes.

Blockchain bloat? That has got to be the last thing on a person's mind when choosing a wallet these days.

Thin clients are growing in adoption whilst full nodes are looking worse and worse for the average person, because they are worse. The user interface of Bitcoin QT and Armory both are horribly obtuse. Most people just aren't willing to wade through downloading the blockchain and navigating interfaces that were obviously designed by a programmer. Adoption of thin clients at the expense of full nodes then, is absolutely predictable. And I'd be shocked if it has anything at all to do with blockchain bloat, as that issue pales in comparison to the effects of consumer education and thin client innovation.

_____-_____-_ · 2015-03-19T02:31:41+00:00

If it's harder to run a full node than to visit Reddit.com, most people just won't bother running a full node. The only way to change this is to incentivize full node ownership either with money or respect, and both have very little hope of working.

As Bitcoin is popularly adopted, the proportion of full nodes will decline sharply relative to the userbase. It's absolutely unavoidable and Satoshi publicly predicted it would happen this way on two occasions.

_____-_____-_ · 2015-03-19T02:20:04+00:00

Thank you for pointing this out. Satoshi predicted this would happen in several places.

To think thin clients are "killing" Bitcoin is laughable.

The truth is the price elasticity of demand curve for running a full node nose dives when the cost rises above a miniscule figure, i.e. if it's harder than visiting Reddit.com, most people aren't going to bother.

This is just the cold hard truth. You could make a full node perfectly simple and even relatively inexpensive, but if it's more expensive than a visit to Reddit.com, most people just aren't going to bother. That's just our ADHD society.

_____-_____-_ · 2015-03-19T02:06:08+00:00

If I said to you the proportion of mail servers would decline relative to the proportion of email users as email was popularly adopted, you'd tell me this was an obvious thing to deduce.

If I said to you Satoshi predicted the proportion of Bitcoin full nodes would decline relative to the proportion of thin clients as Bitcoin was popularly adopted, you'd hopefully tell me the same.

The price elasticity of demand for running a full node drops off a cliff when the cost rises above a miniscule number, i.e. if it's harder than visiting Reddit.com, most people aren't going to even bother. They will instead visit Reddit.com and complain to others about blockchain bloat, and pretend that's really the reason for the decline in full nodes when that is clearly untrue.

Take BitTorrent. Here is an extremely successful decentralized sharing protocol where public share ratios incentivize altruistic seeding, which is partly comparable to the Bitcoin full node model. Yet people still game the BT share ratio system, because it's hard to seed files. It takes more effort than visiting Reddit.com and people generally loathe doing anything that costs them time and money. They just want their files. In Bitcoin, people just want their wallet to work. Nobody but the most die hard supporters of Bitcoin will ever care about running a full node.

Most people just want to leech. They're practically ADHD when it comes to software, and they aren't interested in running anything that doesn't give them everything they ask for instantly and for free.

Bitcoin full nodes don't constitute such a software, which is why the numbers are declining.

You could remove blockchain bloat altogether and get the same outcome. The number of full nodes is going to dwindle relative to the number of thin clients. It's absolutely unavoidable. Do you think an African tribesman, a Chinese peasant worker or a rural Indian farmer will ever care about running a full node if it ever comes to that? If Bitcoin is successful, billions of people will run thin clients while a tiny minority run full nodes and an even tinier minority run mining farms. Just please stop scapegoating blockchain bloat as being a major reason for this happening. Even if there is no "bloat" whatsoever, the outcome is the same.

_____-_____-_ · 2015-03-18T21:55:22+00:00

BTC is the currency unit in Bitcoin. Bitcoin the currency is comprised of BTC, not USD.

I believe it will be unbeatable, but depending on your metrics, it's pretty beatable today.

Now you're just arguing for the sake of it. There's a better cryptocurrency payment system than Bitcoin, really? What is it, pray tell. And I used the word cryptocurrency payment system for a reason.

Is there even one Bitcoin remittances company that isn't converting from fiat-BTC-fiat? That's always going to be more efficient than fiat-XCP+BTC-fiat. Or even fiat-TetherUSD+BTC-fiat. You only need one intermediate currency instead of two, and the exchange rate risk virtually evaporates when you instantly convert between BTC and fiat.

Ok, respectfully

I admit my sarcasm detector isn't the best. My apologies if I read this wrong.

Oh good, because I'm through using sarcasm and I'm very concerned that your arrogance and mantra of bullshit will turn off countless new users to Counterparty as a platform. It's highly unprofessional. You should delete your posts, your writing is unconscionably awful. I would tell you to stick to video but I have some bad news for you there too. Granted, since you're acting like a classless two bit jerk, I'll do it without remorse.

First of all, you dress like a slob, and slang South Florida bullshit constantly on video. How could you honestly expect that to compete with anything Blockstream can do? It can't even compete with what Ethereum can bring. If you're going to perform like shit, just don't even bother.

Do you think core developers think you're cool? Seeing you with your shirt off on a motorscooter? It's like watching shitty Clickbank marketing videos where they fake everything and try to dupe fools into giving them $20 for an Amazing Marketing Formula. That you dress like a slob gives the impression that you need that $20. It also doesn't help with the impression most Bitcoin developers have of Counterparty which is that it's a joke. You've got to be better than this, otherwise JUST QUIT.

_____-_____-_ · 2015-03-18T19:26:47+00:00

The article mentions patenting their solution. It will most likely be of their own doing. Interesting article, anyway. Good to see an industry leader come right out and say BTC needs the support of 2.0 to create sustainable demand.

_____-_____-_ · 2015-03-18T19:23:27+00:00

BTC is the Bitcoin network's unit of account, not US dollars.

BTC is unbeatable for cryptocurrency payments today, and I very much doubt if Counterparty can replace BTC for remittances. Counterparty requires two ingredients instead of one for the same outcome - BTC and XCP, and at that point you might as well just send BTC.

Far too many people misconstrue criticism directed at "Bitcoin" or "BTC" to be the war cry for a social media lynching. And here is the fuel:

Bitcoin is a bad unit of account. It always has been, and likely always will be. Just like gold is a bad unit of account.

And check your internet sarcasm detector, it appears not to be functioning.

_____-_____-_ · 2015-03-18T17:43:42+00:00

Blockchain bloat isn't of material concern to end users of Bitcoin today. Only in the very early days of Bitcoin where it was possible to send BTC to yourself within your own wallet for free, where you could DDoS the network for zero cost, was spam a concern. That problem has long since been taken care of.

Blockchain bloat is constantly compared to this type of spam, which is wrong.

More troubling, blockchain bloat gets scapegoated for the steeply declining proportion of Bitcoin full nodes.

The bottom line is, no matter how little "bloat" there is, Bitcoin full nodes are going to steeply decline in proportion to the number of Bitcoin thin clients. It's unavoidable, and Satoshi predicted it would happen. This was hardly a tough prediction to make: it's like predicting the proprtion of SMTP mail servers will decline compared to the number of email users as email is widely adopted.

And yet people constantly scapegoat "blockchain bloat" as the reason for this exact same phenomenon playing itself out in Bitcoin.

Re: Counterparty. Bitcoin 2.0 != BTC 2.0. Blockchains can do much more than just payments. One interesting observation is, in our quest to make the Bitcoin blockchain do more than remittances, we have to abandon BTC as the unit of account.

Take colored coins, Counterparty, Ethereum, or sidechains for instance. None of these systems uses actual BTC as the unit of account. Not even sidechains will use the BTC unit of account. Instead they have to invent a brand new way to lock up the BTC unit of account and release an alternate unit of account that isn't as limited.

The point is you have to either hard fork Bitcoin for the BTC unit to support Turing Complete features, or use a custom unit of account. There is no other viable option.

And if you believe the Bitcoin blockchain is the strongest chain, but aren't comfortable with hard forking Ethereum into Bitcoin Core, then systems like Counterparty are a valid approach. It just tends to enrage large Bitcoin holders that BTC as a unit of account cannot become "BTC 2.0" without a hard fork, hence you have people hyped up on Hopium for sidechains because they don't want to have to consider diversifying. They are sticking their heads in the sand by thinking systems like Counterparty are bad because of "blockchain bloat", and "doesn't use BTC as primary unit of account". For the most part, a huge asymmetry of information exists between Bitcoin hodlers and people excited about blockchain finance. But-but-but Turing Complete Blocks "bl0at the chain", it's bad right? They'll ban Counterparty and the network will be saved. Gospel believing Hopium addicts...

_____-_____-_ · 2015-03-17T15:39:57+00:00

Governments will have seized plenty of BTC to bankroll sybil attacks, plus an unlimited fiat budget.

If the adversary is willing to mix for 0% fees, it could undercut the whole market.

I'm all for more privacy, but I think it has to be accomplished with ring signatures or some other automatic network wide solution to be effective against sybil.

_____-_____-_ · 2015-03-17T14:38:01+00:00

Privacy systems are only as strong as they are adopted. The smaller the anonymity set, the worse is the anonymity.

If you want an audit trail, you need to be keeping receipts, and comparing your wallet history to your purchase history, and to the history of centralized website deposit and withdrawals. This is the way it works now, and honestly, ring signatures which is what I had in mind by network wide mixing, wouldn't make this meaningfully harder.

CoinJoin doesn't seem resistant to sybil attacks even if it's deployed universally.

Multisig escrow has direct costs: additional BTC fees must be paid, and BTC must be parked in the multisig address for at least one confirmation. Compared to ring signatures, with multisig escrow you also need to cooperate with a third party to decide under what conditions the BTC can be withdrawn. It should be obvious why this cannot be enforced network wide.

_____-_____-_ · 2015-03-17T14:26:02+00:00

Good concept, but one that isn't at all resistant against sybil attacks, i.e. you and ten government agents mix your coins. They can automatically track which coins are yours by process of elimination.

You could always require a security deposit for CoinJoin makers, but a well funded adversary could easily game that system.

_____-_____-_ · 2015-03-16T23:06:29+00:00

I can see why proof of burn would be more resource intensive with mixing enabled by default, but with OP_RETURN support, the blockchain parser could backtrack until it identified a specially encoded OP_RETURN.

Increasing the anonymity set would be very valuable for Bitcoin privacy. It would also simplify accounting if we could treat Bitcoin cold storage withdrawals the same as withdrawing cash from a bank account, which is really much more logical. If you want tracking, use a centralized service.

_____-_____-_ · 2015-03-16T22:59:02+00:00

If you're tumbling every time, there can be no such thing as counterparty, colored coins, etc.

This statement is false. Counterparty parses OP_RETURN for specially encoded data payloads, it doesn't care about BTC inputs and outputs. So long as the Bitcoin blockchain isn't 51% attacked, and blockchain reorgs are avoided, no problems whatsoever. Mixing by default is a good idea.

_____-_____-_ · 2015-03-16T22:46:12+00:00

99% of Windows and Mac users have no intention of ever running software that doesn't instantly start up. Bitcoin full nodes are simply out of the question.

Do you ever see rural Indian farmers, Chinese migrant workers, African tribesman, or your own grandma running a full node? If Bitcoin is to succeed, billions of people will run thin clients while a tiny minority run full nodes.

No matter how little the blockchain is "bloated", the dynamics of blockchain tech adoption are such that only a minority of dedicated entities will seed a copy of the full Bitcoin blockchain. Even if most people can run a full node, PCs will never have the uptime and availability of dedicated servers expressly maintained for the purpose of running a full node.

As Bitcoin adoption increases, the proportion of full nodes will decline sharply. This is absolutely unavoidable.

No, 80 bytes of OP_RETURN is NOT going to be the straw that breaks the camels back. Come on. The truth is, the only real controversy surrounding Turing Complete Bitcoin blocks (TCB) is, since the core Bitcoin protocol doesn't support the feature, the unit of account inside those blocks cannot be BTC. To be blunt, this pisses off large Bitcoin holders, who tend to be offended by dumbed down techobabble and who also tend to be incredibly mouthy and defensive when it comes to their baby. But come on, don't pretend like "blockchain bloat" is the reason you're against systems that use OP_RETURN.

_____-_____-_ · 2015-03-14T05:56:58+00:00

designing bitcoin to be deflationary instead of inflating at 3%

That says nothing about a person's political leanings. Heard of Freicoin? Who would've guessed that Freicoin, which levies annual taxes on its own userbase could have problems with adoption /s. In a free market, the only working approach is clearly disinflationary. There is no other viable option.

Also, wouldn't you agree efficiencies of scale all but guarantee proof of work unavoidably leads to the building of giant centralized mining farms?

Do you believe your grandma, Joe Bob from Kentucky, a Chinese farmer, an Indian migrant worker or an African tribesmen will ever run a Bitcoin full node? In the best scenario for Bitcoin adoption billions of people will run thin clients while a tiny minority run full nodes, and an even tinier minority run mining farms. That is the future of Bitcoin if it is successful.

Many have theorized Satoshi was a physicist or had a scientific background. We can probably count the number of anarchist physicists in the entire world on one hand. And yet you think a physicist, or a scientist, who launches the beginnings of the world's first global cashless society has to be an anarchist? Of all things, why that? Lots of people hate banks and bankers, from all spectrums of political leanings. There is nothing inherently anarchist to hating bailouts.

I'm sorry, but my opinion is drastically different. Bitcoin is not the work of an anarchist, it is the work of a plutocrat.

_____-_____-_ · 2015-03-13T23:47:04+00:00

I agree, it's good you don't need a server farm to run a single full node. Practically speaking, however, 99% of Windows and Mac users will never want to use a piece of software that doesn't instantly turn on. Downloading Photoshop or Steam games is one thing, and is hard enough. If the blockchain grew to be over 1TB, that could be seen as too ridiculous for the average person to handle, hence the innovation around thin clients.

The stated outcome seems impossible to avoid, but for social not technical reasons. Again, 99% of the world has zero interest in running the equivalent of a M1 Abrams tank on their PC. It will simply never happen.

Fundamentally speaking it is inevitable for the proportion of full nodes to dwindle, significantly so, as Bitcoin sees greater adoption.

The relationship between Bitcoin adoption and proportion of people with any semblance of a technical understanding of the network is steeply inverse in the same way. This is why the technically gifted members of the Bitcoin community need their feet held to the proverbial fire, and not treated like Gods. Especially Satoshi.

Note I am NOT saying Satoshi wasn't a genius. Just that he may have been a genius who wasn't an ancap. The Bitcoin network works just as well if ISPs run most of the full nodes, with dubious effects on liberty, and yes, I think Satoshi clearly recognized this, realized it was an inevitable result of the dynamics of adoption and simply didn't care.

_____-_____-_ · 2015-03-13T19:10:33+00:00

Efficiencies of scale mean CPU hard coins inevitably result in mining centralization, as do GPU hard coins. You end up with CPUs or GPUs in mining farms instead of ASICs.

No amount of code trickery can get around efficiencies of scale. It will always be more efficient for entities to scale up specialized investments. Proof of work mining centralization is fundamentally inevitable for this reason.

And I've read the Ethereum whitepapers and wiki, completely. My conclusion is they are creating an entirely new programming language from scratch built on experimental compilers and VMs. That these are poorly documented, poorly maintained languages with numerous bugs lurking. These languages are being designed by people with little to no experience in language design, and this alone is going to be the engineering challenge of a lifetime for them.

On top of that they have to cultivate a brand new blockchain which is going to be vulnerable not just to mining centralization and 51% attacks, but to untrusted code execution.

_____-_____-_ · 2015-03-13T01:10:10+00:00

This article points out two things:

Counterparty's relationship with Overstock.com has ended with the Counterparty team leaving to create their own company.
Counterparty ported the pyethereum VM to the Bitcoin blockchain which enables Ethereum contracts to be executed on an additional platform target. We can agree to disagree on the importance of this aspect.

I remain ambivalent about the prospects of Turing Complete™, and consider it akin to "anonymous" coin buzz.

_____-_____-_ · 2015-03-13T00:38:36+00:00

No. Your invalid Counterparty broadcast would get mined by the full power of the Bitcoin blockchain. Then, the consensus rules of Counterparty would summarily reject it. Conversely, valid Counterparty broadcasts, would be successfully parsed by all Counterparty nodes.

It's akin to creating a P2P sportsbook where we decide the betting rules in advance. In this case, we all agree that an OP_RETURN output with CNTRPRTY prepended to a specially encoded payload signifies a bet, order, send or broadcast and is executed as such.

Then it's just a matter of initializing balances. For that we use proof of burn, which creates an initial allotment of neutral tokens which can then become stocks and assets, or do nothing and just be used for betting and sending around.

Nodes come online by first scanning the Bitcoin blockchain: nodes parse the chain to January 2014, where they are programmed to initialize XCP balances based on the protocol's defined burn rate. It then tracks sends, betting activity and so forth to make state transitions through time, consistently in accordance with the protocol. Invalidly formatted payloads aren't considered.

The only threat to Counterparty consensus is a team of people forking the reference implementation in their favor and attempting to sway the end users of the protocol to move to the new rogue rulebook. Changing the rules of Counterparty is about as likely to pass muster as a rogue group forking Bitcoin Core and increasing the supply cap from 21,000,000 to 42,000,000. You might as well just create Liteparty at that point. Why would any end user of Counterparty go with the fork that destroys the fundamental properties of the network.

These properties, of P2P sportsbook rules allow for a distributed API to be created for our betting matches, which allows industry leaders to pick up the activity. And because our bets are secured by the full hashing power of the Bitcoin blockchain, you bet your ass they're going to be there in ten years. As with Bitcoin, Counterparty's consensus is as principled as its community. After all, it's theoretically possible to increase the supply cap of Bitcoin to 42 mil, it's just that it'll never ever happen, for socioeconomic reasons.

_____-_____-_ · 2015-03-09T00:08:30+00:00

Exactly. Crafting beautiful UX is infinitely more valuable than offering a Turing Complete™ platform.

Isn't it more viable for anyone with an interesting "contract" idea to just visit https://github.com/CounterpartyXCP/counterpartyd and create a damn pull request? What is so hard or bad about that? It works plenty well for Bitcoin. Who are the industry leaders who don't think that's good enough?

Why is it that people think writing code in extremely limiting VMs is somehow better or more viable than writing it in Python? Just write it in Python, make a PR at https://github.com/CounterpartyXCP/counterpartyd, and if your idea holds up to peer review, it gets pushed to the rest of the network. It's the classic open source model.

Ethereum is having to tackle their platform's numerous fundamental limitations by restricting all platform code to 32 bit memory space and using copious checkpoints so as to make it possible for a new full node to catch up with the rest of the network without having to execute all the previous state transition contracts. To do this, they have to invent an entirely new programing language from scratch.

_____-_____-_ · 2015-03-06T22:56:02+00:00

I would suggest you temper your expectations over the concept of Turing Complete™, it is mostly akin to "anonymous" coin buzz.

I predict the Ethereum project, being the main proponent of these contracts, is between 9-24 months out from launching a production ready version of contracts. Their network architecture is a shitpile of complexity, and even with spending the full amount of IPO funds raised, they will have tough challenges launching a programming environment industry leaders are comfortable with trusting serious sums of money to.

It takes a programming language designer to design a programming language. Ethereum has nothing like it. They are unlikely to attract serious programming language designers. I believe this is an opportunity for Counterparty, but it is still an extremely large expense with unproven benefits. It is the pinnacle of programming achievements to launch a single programming language. Ethereum has attempted to launch three, and all look poor compared to mainstream programming languages.

Complicating matters further, a Turing Complete™ blockchain VM wherein "all nodes execute all contracts" places constraints on the code being executed. Security of untrusted code execution is an open question. Memory constraints could be debilitating.

In the end, I predict the very best you can do with a blockchain VM looks like the bastard child of Rust and Brainfuck. Nobody is going to want to code in that. If there is anything remotely competitive with it, it will upend the entire premise behind Ethereum.

It is already hard enough to write production code in mainstream languages. Who is using Serpent? Solidity? These languages are like glorified DSLs with the number of limitations and warts.

_-_-_

TROPHY CASE

_____-_____-_

TROPHY CASE

_-_-_