Content
Various findings.
30 December 2015 -
Filed under
Default
For much of 2015, the Bitcoin community has been consumed with a debate about how best to scale Bitcoin. Scaling is important. Whether you wish to use Bitcoin for daily purchases or to protect your family’s wealth and safety for generations to come, you want Bitcoin to be as useful to everyone as possible. If users find it impossible to use Bitcoin for either case, there are plenty of alternatives. Gift and credit cards already work for instant payments of nearly any consumer-level size. Gold and silver should provide at least some protection when the shit hits the proverbial fan. Scaling is however, only one part of the Bitcoin puzzle.
If scaling is important, so are wallets with great UX. So is easy exchange between Bitcoin and other currencies. So is earning your living in Bitcoin. So is security. So is decentralization. Scaling is important but there are lots of important aspects of Bitcoin’s manifestation in our non-ideal world.
About half of the posts on the r/Bitcoin front page are about just one aspect of scaling, the block size. There are a lot of knobs to turn in Bitcoin, many of which do not require modifying the system’s consensus rules. Why the focus on a potentially dangerous, non-consensus, hard-forking change when there is so much safe and simple stuff to do?
Ok, so the other day I was thinking about this whole issue and the insane level of infighting that we’re seeing on r/Bitcoin I started to listen to some videos around the topic of community infighting. I listened to videos about infighting in the DragonballZ fandom, the free thought community, Gamergate, even spats over terminology in Transgender communities and get this, Pagans who were being called Wickan. Apparently it’s some kind of slur among non-Christians or at least it turns into one if used a certain way. There was a particularly good video around this topic and the truth about 9/11. I care not about the content here. I was listening to try and learn something about infighting and how a community can rise above it.
Among the videos there were pleas for tolerance, explanations of past events, who said what, and who responded back. Again, the details don’t matter. This is human nature. Get two or more people together for any length of time and disagreement will ignite. Videos and the written word will be used as weapons in the debate and it will get nasty. Back to the 9/11 video. This was actually a speech by someone involved in starting the 9/11 truth movement. The video quality isn’t great but listen to it.
How easily are we distracted?
Your puzzle piece may be bigger but my small piece is just as important to assembling the whole. We need to stay focused on what’s best for Bitcoin. Look at the finger that labels, that gets personal, that sensationalizes in order to derail and divide this community. Shun them and work to unite us. We are after all, a very small concern on the global stage united by new technology and the promise of a better, more self-determined future. We have greater enemies than those who are subscribing to this small slice of a social news sharing website.
I ask that each of us consider just how small we are in the big worlds of finance and technology.
Stop the infighting and get back to work building and hodling.
Comments Off on Bitcoin and Internal Fighting ¤
Permalink
¤
2015-12-30
8 December 2015 -
Filed under
Completely Awesome + Decentralization
Just read this post by @joelklabo and I wanted to put down some of my thoughts on the Bitcoin computer by 21, Inc. Before I decided to purchase, I was definitely skeptical. The price tag is a bit rich given the mining economics and cost of a Raspberry Pi, I was not a buyer. What changed it for me was actually joining the Slack channel a day or two after it was opened. While Reddit was set on a boring “it doesn’t mine enough” mode, the Slack channel was full of energy, with proud new owners posting their endpoints, doing tutorials, and generally discussing the future.
Then it clicked and I made the purchase.
We humans are creatures of habit and self-centered ones at that. We tend to evaluate new pieces of technology by what they can do for us. Does it make a better cup of coffee? Can I drive farther on a charge? The 21 Bitcoin Computer is not an end-user device. Instead as Joel points out, this thing is a dev kit and the fact that it comes with a Python library that not only implements a standalone HD wallet but seamlessly connects to 21’s offchain account system, means we can actually do new things quite easily.
It’s almost one of those, why didn’t I think of that, kind of moments. Coinable could have done this the moment they rolled out their API a year or more ago. Make off chain payments easy when you need them, have a standalone wallet for when you don’t.
So what is that future? Before I got the 21, I designed some 3d printed stands and cases for it. Since then however, I’ve been working on another idea I’ve been kicking around which is that of a decentralized professional services marketplace. Think of it like an OpenBazaar for Upwork. The idea is a couple months old and it is in progress.
As I’ve been working toward that dream however, there’s a bigger idea that the 21 is highlighting for me. Machine payments. Computers with wallets.
See, the web is largely segmented into:
A. Things we view/use in exchange for viewing ads
B. Subscription services
C. A wasteland of unmonetized data and services that pop in and out of existence never having had any hope of stability
For A, we might use the 21 or a browser extension connected to an off-chain wallet service to kill the ads, or just use adblock if we’re inclined to participate in arms races and don’t really care about what we’re viewing. I do, by the way. B is figured out though the cognitive load of signing up for a monthly or yearly payment means we tend not to sign up for things that are worth $5/mo or less.
C is where the 21 really livens things up and contains within it an entire new substrate upon which a machine-payable web can be built.
Try to think of services that had a hard time being monetized or that were primarily consumed by other computers. RSS feeds. Community databases. Niche search sites. Networks of sensor information. In each of these cases, a computer with a 21 account can pay satoshis for each query or visit. Multiply that times millions of devices and you start to have a functioning system of value for value: a machine payable economy.
Anyway, it’s a thought.
1 comment ¤
Permalink
¤
2015-12-08
16 July 2015 -
Filed under
Decentralization
A few weeks ago, a phantom of a wallet service claimed to be organizing a stress test on the Bitcoin network by spending 20 BTC in fees over 30 hours. What they did was shine a spotlight on an often overlooked feature of Bitcoin.
Stress testing is a term Bitcoin has recently borrowed from the legacy banking sector where it refers to solvency and liquidity testing. If a bank goes under, is there a domino effect causing other organizations to fail or can the system withstand it? In Bitcoin, the stress test has been introduced in the context of the block size limit debate as a coordinated effort to publish more transactions to the Bitcoin p2p network than can be included in the block chain within a certain period of time. The results of such a test should inform us as to how various wallets and services handle a shift from excess capacity in blocks to a time when demand is high enough that every block is full and fees determine speed of confirmation. Stress testing also tests how different services manage their local versions of the set of unconfirmed transactions, known in Bitcoin Core as a mempool.
This post is about exploring fees in depth. What are they? Why are they part of the protocol? How will they look in a future where Bitcoin is either a settlement network or handles tons of smaller transactions?
Some Background
Despite our tendency to think of bitcoins as coins or individual units of digital currency, the protocol does not handle such units individually. Instead transactions have outputs, each of which sends some amount of bitcoin (0.00000001 or more) to a new destination. Most transactions consume a number of previously created outputs and produce a number of new outputs with both inputs and outputs carrying a quantity of bitcoin. Outputs of a transaction may not have more bitcoin in total than the transaction’s inputs, but they can have less. In that case the excess bitcoin that is not claimed by the outputs is left as a fee that goes to the miner.
As an example, suppose I want to send 0.5 bitcoin to you to pay for a pizza party. I scan your qr code and my wallet then looks for outputs it can spend. It finds an output that I previously received for 1 btc. I have also set in my wallet to pay 0.0001 btc as a fee. The wallet then builds a transaction that sends 0.5 btc to your address, 0.4999 btc to a new address of mine. Since these add up to 0.0001 btc less than the 1 btc output that was consumed, the 0.0001 btc becomes the fee. When a miner includes my transaction and finds a block they are permitted by the Bitcoin protocol to add what used to be my 0.0001 btc to their mining reward. Instead of collecting
25 btc for finding the block, they collect 25 btc + my 0.0001 btc + any fees in other transactions in the block. That is how fees work on a basic level; leftovers are set aside and go to miners.
Why have fees?
Early drafts of the bitcoin software and the protocol it embodied did not have fees but had a significant long-term problem. When the block rewards taper down from 50 btc to 25 btc to 12.5 and so on, the security of the bitcoin network would tend to zero. In an economically efficient world, the system Satoshi imagined, responsible for up to trillions of dollars worth of value would see its miners turn off their machines and leave the system open to attack by nearly anyone.
To prevent this from happening, fees were added to transition from security funded by block rewards to one where active users of the system would compete for block chain space and pay over and above basic operating costs to pay for security of the network (hashes) in the process.
How will fees secure the network?
With the block size limit as it is, we are seeing periods such as in the stress test, where every block is as full as limits allow for hours on end. For the first time in Bitcoin’s history, we are seeing transactional scarcity as varying demand meets fixed supply.
A supply of 1,000,000 bytes worth of transactions every 10 minutes vs. variable demand means a fee market will emerge. In this market a minimum fee per kilobyte will be required to have one’s transaction confirmed. Anything above that gets confirmed in the next block while anything below must wait until competition is not so fierce or risk the transaction simply never being confirmed.
At this time and outside miner’s general desire to maximize profit, mechanisms to enable such a fee market are somewhere between non-existent and rudimentary. There is almost no way to easily view the distribution of fees among unconfirmed transactions. There are few estimates of the fee rate required vs. desired confirmation speed. It’s easy to include too low a fee and hard to increase the
fee to get closer to the front of the line. Thankfully compared to many challenges Bitcoin faces, implementing the machinery for a working fee market is fairly straightforward and mainly requires some basic statistics coupled with virtual knobs and dials.
Once in place, fees will respond to increased demand by rising to a dynamic equilibrium where the cost of fees meets the utility of sending native Bitcoin transactions. There are two basic scenarios to consider once the machinery of the fee market matures.
Two Scenarios
If the fee market matures and fees remain low (< 4% of a premium cup of coffee) this would be a sign that Bitcoin is providing little utility over other kinds of payments and only for a small population of users. Some transactions would pay no fee at all. Alternatives such as off-chain solutions or legacy payment systems provide most of the services that people want. It also would mean that the store-of-value use case for Bitcoin remained largely untapped, for fully uncensored economic activity requires recording transfers directly in the Bitcoin block chain.
If instead, we see fees begin to rise, certain use cases such as the instant low-value purchase will quickly become priced out. Merchants may still prefer the case where the customer pays the fee instead of the merchant but it is likely that trust relationships between off-chain payment processors would start to handle these low value transactions with the benefit that secure instant settlement would become possible. These payment processors would implement irreversible payments to remain compatible with Bitcoin but could offer escrow and fraud protection services for a fee when required.
What new services might a fee market require?
In the process of writing this, I realized that there was no good way to view the distribution of unconfirmed transactions versus their fees. I took that as an opportunity to hack together a simple script to generate such a view. Coding that script (running on http://bitcoinexchangerate.org/fees) helped me realize that fees have been something on the back burner. They haven’t been displayed
well by any block explorers (fee/kb?). There are no sites to help you estimate fees with charts and graphs in the way you can view exchange markets. There are also no ways to hedge against rising Bitcoin fees. All of these are coming and will be used by us Bitcoiners to start. As time passes and a high value for Bitcoin becomes realized, more high-net-worth and financial professionals should start using them.
Wallets will improve in fee estimation and a variety of strategies will be employed to minimize both fees and confirmation time. In the past few weeks, I’ve seen a smoothing out of the fee curve as the fee market has become more aware of the importance of fees.
Conclusion
Bitcoin fees might have been an afterthought but are now an important part of the Bitcoin system. For the first time, we are starting to care about fees, which is sparking a new area of activity in Bitcoin. Like bitcoin, the fee market is new and developing quickly and it is advisable to consider how fee rates might affect your plans going forward.
Comments Off on What are Bitcoin Transaction Fees? ¤
Permalink
¤
2015-07-16
19 June 2015 -
Filed under
Decentralization
Since first gaining public attention in 2010, Bitcoin has been attacked in numerous ways with code exploits, dust transactions, exchange hacks, Ponzi schemes, and outright theft. Bitcoin has also been attacked in the media and in our social communities. Each time, Bitcoin enthusiasts could maintain a view that all such attacks were mounted by outsiders with an interest in destroying the system. Now it seems we are up for something new.
This time, it’s a sort of civil war, with the block size limit as the issue that evidently divides. The issue is largely driven by people who want the best for the system and its users, whether that’s being able to handle accelerated growth, proving that Bitcoin can be upgraded or maintaining decentralization of the network.
Bitcoin is sometimes described as a system for achieving trustless distributed consensus, however, that consensus is based on a common set of fundamental rules. When it comes to changing those rules – things like the twenty-one million cap, or the ten minute block time, or the maximum allowed block size – Bitcoin’s internal mechanisms fall short. With changes at this fundamental level, the process is anything but automated. Like a doctor who must operate on himself, Bitcoin is limited and vulnerable when it comes to planning and executing changes to its foundation. It is important to get this right.
A Better Process
In recognition of the dangers around changing these fundamental rules, we can choose a better process. Thus far, there have been blog, forum, mailing list and reddit posts consisting of and about videos, discussions, and arguments. There have been ad hominems and ad absurdums ad infinitum. There have been many proposals with at least one following the conventional Bitcoin improvement proposal (BIP) process. There have been pleas for
urgent action as well as calls for circumspection. The result is dramatic and disturbing.
What is a better process for reaching the near-unanimity that the change to the block size limit requires?
Perhaps we can find a hint in “A Short Guide to Consensus Building” [PDF] published at the MIT-Harvard Public Disputes Program and The Program on Negotiation at Harvard Law School. Inside, we find an outline for how to build public consensus around contentious issues.
With this post, I am at 1.1. Initiate a Discussion About Whether to Have a Consensus Building Dialogue. In other words, do we as a community feel that we need a better way to build consensus around this contentious issue?
Once selected, a neutral party called the facilitator, would prepare “a document that spells out what the issues are, who the stakeholding interests are, where they disagree and where they might find common ground”.
I could go on to quote the rest of the aformentioned document but key points from there are that we would start to focus on interests rather than positions. Parties would agree to negotiate based on what satisfies most stakeholder interests, selected stakeholders would add comments, and additional stakeholders would be brought in. Then brainstorming and what if’s would be conducted all before the final implementation.
Yes, there is the potential that this might turn into a bureaucratic nightmare, but it could also lead Bitcoin to The Best Way Forward(tm). At the very least, reading that document may help us get back to first principles and more fully understand how and why our own positions have developed. Most importantly we can focus our efforts evolving Bitcoin responsibly, including all voices of civility and with proper respect for this magnificent experiment.
Comments Off on Building Consensus for Bitcoin ¤
Permalink
¤
2015-06-19
11 June 2015 -
Filed under
Decentralization
Technology is no stranger to debate. Emacs vs vi, Gnome vs KDE, Mac vs Windows, the list goes on and on with each having inspired debate that would rival the contents of the Library of Congress in quantity, quality and emotion. As more than one technology option became plausible people examined alternatives, made arguments, and began to dig in their heels little-by-little until their position moved from an errant thought, to a reasoned stance, to core belief, and for some, a full-on holy war.
Bitcoin’s block size debate seems to be following the same pattern. People on both sides started with some level of knowledge and when faced with the question, had little difficulty making a choice. Over the past weeks, discussion has grown as suggestions have been made and emotions have driven heated argument peppered with name calling and allusions to ulterior motives.
There’s just one difference between this debate and those that went before. Consensus is paramount.
So what if someone else uses a different editor, window manager, or operating system? Sure, it might affect a tribe of developers, or what platform has the best apps but in the end each user can make their own choice, even if that means disowning a family member or two. Unfortunately, “To each his own” doesn’t work for Bitcoin.
Bitcoin is the first at-scale experiment in distributed consensus. With a set of rules that provide viable incentives for all parties, Bitcoin is able to channel astronomical hashrates into global agreement. The math of hashing creates a steadily closing window of uncertainty. A specific chain of blocks either does or doesn’t have more work behind it and so we can mechanically march along in time, adding block upon block to the block chain, cementing in an agreed-upon version of the past.
No it’s not the math that is our current weakness. Instead it is that pesky set of rules. How big should we allow those blocks to be? How many transactions can the system handle before it turns into PayPal? How many users can dip their toe in the water of now before it freezes for all eternity?
Instead of being able to make our own choices to mangle our hands or submit to Bill Gates, we have a decision that will be set in stone for all to see. If we don’t decide the outcome before we decide to decide, we risk losing the vital consensus that we’ve been building for the last six and a half years.
If we impatiently ask the Bitcoin network, including miners and users, to move forward with a hard fork without broad agreement that the change is what’s best for the system, we risk splitting the network into two. People talk about life after an unsuccessful hard fork like it’s something we can deal with. It is not. If any significant fraction of the network bails out of the longest chain agreement, we aren’t left with BitcoinA and BitcoinB. We are left with zilch. It’s not a crash landing or waiting days for confirmation or accepting a little too much centralization that we should fear. An unresolved hard fork is the true nightmare scenario.
With a hasty decision we are not just risking distributed consensus today but we are risking it for a long time. It’s not clear that a catastrophic failure in Bitcoin’s consensus will ever be matched by a similarly free and open system. Those with an interest in breaking such consensus as a cosmic force will be on the lookout for anything that could match it, and may destroy it with hashing not long after birth. Others with the resources to withstand an initial attack may offer a replacement that requires AML/KYC for confirmation and would be no true replacement to Bitcoin.
If you agree, not on a specific course of action, at least agree that this decision is important and that it must be agreed upon before we dare to decide. It must be made with the best information available and it must be made together or not at all. With time circumstances will change, the tech will improve and we will hopefully discover that we are once again on the same side.
For more information on both sides of the debate, add Arguments in the Bitcoin Block Size Debate to your weekend reading list.
Comments Off on Bitcoin Consensus – Why We Must Know the Answer Before Asking the Question ¤
Permalink
¤
2015-06-11
10 June 2015 -
Filed under
Decentralization
Ever since Gavin Andresen’s first post about increasing the block size a month ago, a debate has been raging across all Bitcoin discussion forums on whether or not to increase Bitcoin’s block size limit. Actually the debate has been going on for longer than that but the rate and temperature of discussion have been greatly increased since Gavin began to highlight the issue.
There are as many opinions as there are participants in this debate and the sheer volume of discussion is so high that few have time to follow it all. My feeling is that most people with strong technical knowledge of the system have chosen a way forward and would rather argue for that way than summarize the arguments presented by each side. I put together the following to help myself and others make up our own minds.
Technical Background
Before we get to the arguments, here is some technical background on the block reward, fees, miner considerations and the block size limit itself. If you understand them already, feel free to skip to the For and Against sections.
Block Rewards and Fees – Bitcoin miners are currently awarded 25 new bitcoins per block, an amount will halve every 4 years or so until the amount is finally shifted down to zero more than a century from now. Miners are also paid with voluntary fees set by the signatories of each transaction. When a miner finds a block, they collect the fees from each transaction included in their block. A miner is free to choose which, if any, transactions they include in a block as long as the transactions are valid and don’t make the block too big. Miners who wish to increase their income then have an incentive to include transactions with higher fees per kilobyte over ones that provide less.
Add up the block rewards and fees and you have an aggregate budget available to all miners that will go into operating mining nodes, the hashing work that secures the network, and in theory, profit.
Block Size Limit – Bitcoin is the first system in the world to use a block chain, a list of blocks linked together in order by miners running the Bitcoin software. Inside each block are one or more transactions that create and transfer bitcoin, pay fees, and optionally store additional data. These transactions can be created by anyone and as long as they meet certain basic criteria, they are broadcast through Bitcoin’s peer-to-peer network. Miners listen for these transactions and choose which of them they will include in the block they are currently working on.
This entire debate centers on a limit that constrains the size, in bytes, of each new block. That limit, called MAX_BLOCK_SIZE looks like this in the Bitcoin software:
static const unsigned int MAX_BLOCK_SIZE = 1000000;
This constant specifies that no block of more than one million bytes shall be considered valid by nodes with this setting.
Since each transaction takes at least a couple hundred bytes, the block size cap constrains the number of transactions that can be included in each block. With blocks targeted to be found every 10 minutes on average, a limited number of transactions can be recorded in the block chain per second, day, or year. This limit also governs the growth rate of the block chain and the minimum processing power and bandwidth required to run a full node. A full node is one that stores the entire history of transactions and participates completely in the Bitcoin peer-to-peer network.
The transaction rate limit affects how many people can have their transactions confirmed, how quickly, and what minimum fee a rational miner would require to include a transaction in their next block.
The size of a block affects how quickly it can be downloaded, verified, and propagated across the network. Larger blocks take more time to transfer and verify than smaller ones. For most miners, each second taken to download and verify a block is time that they could have been hashing for profit instead of wasting their time building on an old block. For a winning miner, larger blocks increase the likelihood that they will lose what they would have earned if another block is found and propagated to miners who manage a majority of hashing power first.
As you can see there are a lot of variables in play around the block size issue and that a fair amount of background, is required to understand the issues. Now, take a careful look at the arguments below presented in no particular order.
For Block Size Increase:
1. Encourage adoption – Since the block size limits how many transactions can be processed, it places a limit on how many users will be able to use Bitcoin directly. Transaction rates have grown all during Bitcoin’s life and at some point, transaction fees will become an important factor in getting a transaction confirmed in the next few blocks after broadcast. If fees rise too high or transactions must wait too long, this argument posits that users will be driven away from Bitcoin, to some other alternative whether that be another cryptocurrency, a legacy payment system, or an off-chain system that still utilizes the bitcoin currency unit but doesn’t have the same benefits of privacy, irreversibility, and resistance to censorship.
2. Crash landing – This argument describes a scenario where more transactions are broadcast than the Bitcoin network can handle for an extended period of time. Transactions that are not confirmed pile up in each Bitcoin node’s memory pool overloading ones with less memory, thereby degrading the connectivity and performance of the network. Users who want to increase their fee, add even more transactions to the network making the problem worse. Lower performance and the build up would signaling users that Bitcoin is not up to the global payments challenge.
3. Block size is self-correcting – Miners have an incentive to keep blocks small whether there’s a limit or not. Larger blocks are more likely to be orphaned meaning lost revenue for the miner who publishes a large block. For each additional transaction they include, they should be able to calculate and make a decision based on the increased risk of orphaning and the included fee.
4. The limit was temporary – The 1,000,000 byte limit was a temporary spam control measure. When the block size limit was introduced, transaction volumes were very low compared to the limit. The limit was put in place to stop malicious
actors from cheaply inflating the block chain thereby increasing costs forever for users of a new and promising system. Waking up after a week to a block chain requiring tens of gigabytes when very few people used the network could have been disasterous but would be less of a problem today, five years later.
5. Don’t constrain legitimate transactions – The block size limit was not meant to constrain legitimate transactions. While it is difficult to judge whether any transaction is more legitimate than another, miner costs, not a block size limit should be the mechanism relied upon to govern growth in the block chain.
6. Assurance contracts can pay for security – One of the arguments for constraining the block size posits that significant fees will be required to pay for enough hashing to secure the network against a 51% attacker as block rewards halve. An assurance contract is a tool for allowing a set of participants to pay for a good in the face of a the free-rider problem. Participants would then contribute funds to the contract to pay for enough hashing and the network would be secured as necessary by those who are most concerned with security.
Against Block Size Increase
A. Fewer full nodes – As larger blocks are produced, increased costs mean that fewer users will run full nodes. This means they will be placing more trust in those who can run a full node to accurately report on data recorded in the block chain. Users also become more likely to expose details of their bitcoin usage and are more vulnerable to fraud in the form of double-spending or monetary inflation. SPV nodes have no way for example to detect if a node fraudulently reports the receipt of bitcoins to the SPV node’s wallet that don’t exist in the fully-verified block chain.
B. Paying for the hashrate – Bitcoin’s security model depends on honest miners having more hashing power than attackers. From the genesis block on that hashing power has been paid for by block rewards that are scheduled to decrease over the coming years and decades. As that reward goes away, something else must replace or eclipse (depending on the exchange rate and value of transactions that occur) the block reward to secure the network. These fees must pay not only for the cost of transaction verification and any incremental risk of having one’s block orphaned, but must pay for enough hashing by honest miners to defend against an attacker. Fees are the most straightforward way to provide this funding but require that Bitcoin develop a robust fee market and features to enable users to adjust their fee if they are willing to pay to expedite confirmation of their transaction to the next block or so. Assurance contracts as an alternative to fees are untested and may be gamed in a way that reduces their effectiveness.
C. Increased censorship – Larger blocks require higher amounts of bandwidth which would stand out in jurisdictions that monitor network traffic closely. This would make identifying anonymous bitcoin miners easier and enable governments and corporations to coerce miners to enforce censorship on bitcoin transactions. Having some miners be anonymous is not enough as state or corporate controlled mining nodes could ignore blocks produced by those outside the favor of the regulatory regime.
D. No urgency – Transaction volumes today vary quite a bit from hour-to-hour and on average only require 400KB of storage space per block. Some of these transactions are of little economic value and should not be used as justification for a block size increase now. In the time before a change, other options can be explored and implemented to reduce transaction load in trustlesss, decentralized fashion. Even in the absence of such immediate developments, use of centralized off-chain services would be temporary with that volume shifting to trustless, decentralized options once available and competitive.
E. A change would be irreversible – Changing the block size limit requires a hard fork and if the larger block size were to be abused, changing it back may not be possible due to changes in who would still be mining without coersion from outside organizations. The blockchain would then grow at around 1TB per year regardless of the economic utility of that additional transactional data and contribute to a downward spiral of centralization and censorship.
That’s it. Comments about any corrections are welcome.
1 comment ¤
Permalink
¤
2015-06-10
27 December 2014 -
Filed under
Decentralization
For Bitcoin, currency is just the beginning, necessary to bootstrap the system, build mining infrastructure, secure the blockchain, and discourage spam. Recently there has been much talk of smart contracts, smart property, digital assets, and escrow, all of which benefit from the existence of a decentralized global ledger. That talk has been turned into action with a collection of projects with names like Mastercoin, Sidechains, Ethereum and Counterparty. Having researched each of these, I have decided to focus on Counterparty because I think it has the best mix of working code, current use cases and future possibilities. What follows is an overview of the various enhancements and capabilities Counterparty brings to Bitcoin today.
1. Fractional Ownership
In recent years, crowdfunding has enabled tons of folks to go from an idea or rough prototype to build at least a small business. The next frontier in the crowd-space is crowdequity where hundreds or thousands of investors buy a piece of a new enterprise. Counterparty makes crowdequity simple to setup and administer. Create a token and sell it via a token-vending service to grant ownership to shareholders. Later, you can pay dividends in XCP with a single click or hold a shareholder vote by issuing voting tokens to your shareholders.
Note that in the United States, there are restrictions on the number and accreditation of shareholders that may own a business. Hopefully this will change once the SEC finishes Section III of the JOBS Act. Overstock.com is also working on a platform called Medici that will use Counterparty to represent shares of public companies.
2. Bets & Prediction markets
Counterparty’s decentralized exchange (DEx) enables users to do trustless trade between native tokens like XCP and FLDC as well as with bitcoin. Similarly, Counterparty’s betting and contracts-for-difference features enable users to do trustless betting with XCP on virtually any event. These work by attaching a bet to data published by a third party in a broadcast transaction. By promising to report accurately about a future event (whether it be sporting, political, or economic) the broadcaster can collect a small fee while the bets themselves are offered, matched, and settled directly between users by the protocol. In this case there is no “house”; the closest thing is the broadcaster themselves who earn fees for their reporting.
One issue with this system is the possibility that an oracle may misreport an event outcome. In this case, bets can be corrected with later payments, or left as evidence of fraud. While building and trusting online reputation systems is an immense challenge there are ways to increase the cost to an oracle of going rogue, for example proof-of-burn, requiring significant investment in a related web presence or community, or by obtaining a surety bond.
3. Games
You can play a fairly slow, but fully escrowed game of Rock Paper Scissors or [Rock Paper Scissors Lizard Spock](http://en.wikipedia.org/wiki/Rock-paper-scissors-lizard-Spock) with Counterparty.
4. Alternate Token Distribution Schemes
Bitcoin acheives security by rewarding miners for their work. At the same time, mining distributes the coins that will forever be traded in the system. With Counterparty, transactional security is provided by the Bitcoin network freeing token distribution schedules to better for an issuer’s needs.
Let’s Talk Bitcoin distributes LTBcoin according to a published schedule of diminishing issuance and is used as payment to reward certain behaviors in the community. It is accepted by the site for advertising slots and if you create a podcast or blog post, listen to a podcast, or even comment in the forums you earn a share of the week’s LTBcoin. Instead of mining for security, LTBcoins are earned by building content and community.
Another example is [FoldingCoin](http://davidsterry.com/blog/), a project started in mid-2014 where members of Stanford’s Folding@Home project can be paid a portion of daily FLDC distributions. With daily distribution fixed at 500,000 FLDC, a folder who contributes 1% of the FoldingCoin points earns 5000 FLDC. The points tallies are posted along with member addresses and Folding@Home usernames, making payouts transparent. There is a proposal in that system to change the distribution schedule to more closely match the halving rewards of Bitcoin. At the time of writing, this proposal is under a proof-of-stake vote by FLDC holders to decide on its enactment.
Creative, dependable token distribution provides an investor with the option to support not just an individual developer but a platform and an economy based on the token. If you think either of the above projects are doing valuable work or that the value of their tokens may increase, you can buy some to hold or redistribute towards advancement of their respective platforms.
5. Access Control
Advancements such as OAUTH and smart cards are growing in adoption, but what we use today largely depends upon shared secrets. Passwords and PINs have worked for decades but with the growing incidence of hacks on online services, retail and even banks, they are starting to show their limitations. Counterparty tokens can be used for access control and can marry different architectures to provide granular and dynamic access.
By using what’s called Token Controlled Viewpoint (TCV), each account on a service can be cryptographically associated with any number of Bitcoin addresses. Once linked, the inventory of tokens can enable your account to access and interact with certain services. This has been developed in the Let’s Talk Bitoin community where early members of the site received a token called EARLY that as entitles them to access the Founders Forum. Anyone can create an exclusive forum on their platform for a small fee. More imporantly, anyone can create their own forum (look up Tokenly for a head start) and with counterpartyd and a bit of code attach their own roles and responsibilities to holders of tokens.
6. Scarcity
With Counterparty you can acheive simple and inexpensive digital scarcity. Just create an asset, issue units of the asset and lock it. From then, there will never be another satoshi of that asset in the Counterparty universe. Use cases include collectibles (more on that below), currencies, points, shares, awards and medals – anything for which scarcity adds value.
That being said, Counterparty reserves 63-bits for token quantities which translates to 9.223372037×10¹⁸ units. Even if you make an asset divisible (to 8 decimal places), you can still have more than 92 billion finely divisible units in existence. So though you can have scarcity, you can also have amounts of points floating around that get people excited, like the several million points often awarded in a video game.
7. Proofs-of-existence and records of prediction
The broadcast feature need not be connected to a future event or bet. You could also use the system to encode that you are going to become captain of your football team in the next 12 months or that you will lose 10 pounds in 6. Being encoded in the Bitcoin block chain, the security of the system is strong enough that you could encode a prediction and proceed to reference it in legal documents in jurisdictions all around the world.
8. Insta-ETFs
Counterparty also enables the separation of custody and ownership; trade from shipping; physical possession vs. the right to sell. Any pawn broker or secure storage facility can issue a digital asset representing an item or collection of items they hold. Rare coins, gold, silver, art, and collectibles are all candidates that may make sense to be traded in this way. The custodian merely needs to provide inventory reports and the name of the Counterparty asset that goes with each item or collection.
Trade is taken care of either on the DEx or off-chain with no custodial intervention necessary. The custodian can charge storage fees denominated in local currency and payable in BTC or XCP. If the storage fees go unpaid, the shop can liquidate the item and split the proceeds with the owner at some predetermined rate. Perhaps this would be a premium feature that customers will look for in the storage facilities in the future.
Conclusion
As you can see, there are many interesting use cases for Counterparty which wouldn’t be possible without the constant, excellent work of the Counterparty development team but also of the Bitcoin developers, miners, and everyone who has helped us all get to this point. To get started with Counterparty, visit https://counterparty.io.
Discussion
Some pretty good discussion was generated by this article on Reddit at http://www.reddit.com/r/Bitcoin/comments/2qjlr1/8_ways_to_counterparty_new_features_counterparty/
Comments Off on 8 Ways to Counterparty ¤
Permalink
¤
2014-12-27
9 November 2014 -
Filed under
Default
On Thursday Operation Onymous, a joint operation between several US and European law enforcement agencies was announced, shutting down between 20-400 sites running on Tor, arresting 17 people (releasing several after questioning), being sure to highlight that these sites are using Tor and that some are illegally selling drugs and/or weapons. Though Bitcoin was used by many of the markets that were shut down it was not the central headline on the story. Perhaps authorities have realized that Bitcoin is not their biggest problem – there are hundreds of similar currencies – but that being able to operate anonymous markets on the web is.
Tor users I spoke with are not rattled. They see it as a risk to run Tor, especially to run an exit node, which is a gateway between Tor users and the non-Tor sites they visit, and are impressed that the vast majority of hidden services are still online.
The general consensus is that Blake Benthall, who took over Silk Road 2 from one of a line of Dread Pirate Roberts, was careless on a number of fronts. The keyword here is operational security, maintaining separation between his offline identity and all activities related to operating Silk Road 2. Among his mistakes were tweeting about his bitcoin, retweeting previous Silk Road stories, purchasing a Tesla with his bitcoin. Most damning were that he allegedly signed up for server hosting for the Silk Road 2 hidden service using his personal Gmail address and received messages there that came from the administrative interface of SR2. He also hired people who were “just around” to help moderate the forums, one of whom was a government agent, and trusted them more than necessary. Finally, he worked from San Francisco, the same city where Ross Ulbricht, alleged operator of the original Silk Road was arrested.
According to the community, bigger and better run sites including Agora and Evolution are still online and serving customers. Only time will tell how long they last but depending on their own operational security and Tor itself they could run for years saving lives, violence, and jail time for many.
The closure of these services has highlighted another vulnerability with their architecture: they are centralized. One solution to the centralization problem has been in the works for several months going by the name Open Bazaar. OB operates as a peer-to-peer network like Bittorrent and Bitcoin and would allow vendors to establish and manage a reputation, offer goods and services, and collect funds. Though OB is not anonymous, it is designed to work well with Tor to add privacy to its censorship-resistant market features.
In other news, Facebook now offers access via Tor which is odd because Facebook is often viewed as THE big brother for privacy-concerned internet users. Still, it could bring a large amount of mundane Tor use and make it harder allege guilt-by-association for Tor users. At the same time, there is utility in enabling users in the most oppressive jurisdictions to access the leading social network platform even if many would not touch it.
Comments Off on Operation Onymous, Operational Security, Open Bazaar and Facebook on Tor ¤
Permalink
¤
2014-11-09
6 November 2014 -
Filed under
Default
Secret ballots exist to remove intimidation and bribery in voting. In 1970, Congress did away with secret ballots and so began a decades long slide into today’s world of lobbying, special interests, and a government that no longer works for the people. Congress must go back to secret ballots to reestablish confidence in the legislative process and in democracy itself. For the most important civics lesson you will ever receive, watch this:
Comments Off on Kids Use Secret Ballots, Congress Should Too ¤
Permalink
¤
2014-11-06
6 October 2014 -
Filed under
Decentralization
Counterparty is a protocol for the creation and use of decentralized financial instruments using Bitcoin as a transport layer. The protocol currently supports
and implements the creation of assets, issuance of tokens of those assets, payment of dividends, protocol-escrowed trading, binary bets, and contracts-for-difference. The protocol has been operating since January 2014.
To enable the protocol to escrow value for decentralized trading and financial contracts such as binary bets and contracts-for-difference (CFD), there was a need for a common token of value in the Counterparty system. Similarly to how resources are spent to mine bitcoin, bitcoin was “burned” or irretreivably spent to create units of Counterparty’s native currency (XCP). During the 30-day proof-of-burn period in January 2014, 2.6 million XCP were created.
History
The earliest commits to Github of the Counterparty project were in December 2013. The project was announced with a release of the software on Bitcointalk.org on January 2nd, 2014. Since the software was released as free software, the proof-of-burn was started almost immediately opening on January 4th, 2014 and lasting until the 2nd of February. During this period, 2130 bitcoins (worth about $1.9 million at the time) were burned to create the XCP supply. To encourage investment in this system, each bitcoin was rewarded with from 1500 XCP to 1000 XCP at a rate which decreased linearly with each block found on the Bitcoin network during the burn period.
Since that time Counterparty has been responsible for over 77,000 transactions on the Bitcoin network. About 4,300 assets have been created and more than 7,000
informational broadcasts have been published, generally recording the outcomes of sporting events and currency exchange rates. Anyone can make these broadcasts thereby allowing Counterparty users enter into bets, binary bets and contracts for difference using them.
According to Blockscan.com, some of the most active assets include LTBCOIN, XCP, XBTC, EARLY, COMICCOIN, SJCX, and FLDC with numbers of transactions ranging from over 3300 for LTBCOIN to 800 for FLDC. In addition to the DEX, XCP trades on the Bter exchange and SJCX trades on Poloniex.
Distributed Exchange
The Counterparty protocol supports decentralized, trustless trading of native tokens in two steps using a facility called Distributed Exchange (DEX). Since the protocol parses transactions recorded on Bitcoin’s block chain, corresponding buy and sell transactions of one token for another are automatically matched and can be considered executed when each have been recorded in a block. Bitcoin can also be traded using DEX by adding an additional step called the BTCpay transaction where by the protocol holds the Counterparty token in escrow for 20 blocks. If a BTCpay transaction is confirmed during that period, Counterparty considers the trade complete and considers the tokens to be then owned by the buyer.
Consensus
Counterparty transactions are Bitcoin transactions. Depending on their form they may encode additional data in an OP_RETURN output or as additional addresses in a multisignature outut. Consensus is then achieved by interpreting the extra data in the Bitcoin block chain consistently. The Counterparty software does a check at Github for the latest minimum version required but other possibilities are being considered for ensuring that different services are interpreting the protocol and block chain consistently.
Development
Counterparty is developed as a free open source software project under the MIT license. Several projects are hosted at Github under the link https://github.com/CounterpartyXCP which include counterpartyd, the core software; counterparty_build, the automated build system; and counterblockd, a json rpc service that provides information for counterwallet, the web wallet.
The core software has seen improvements or less since the beginning of the git history in December 2013. It uses a number of python libraries and specifies version numbers of those libraries during environment setup to ensure uniformity across installations.
Service Availability
Counterparty use largely revolves around Counterwallet, the free software web- based wallet hosted by the development team. The core team also manages a wiki and forum. Blockscan.com is a block explorer for Counterparty providing charts and information on transactions, assets, orders, bets and broadcasts. The counterpartyd code provides a JSON RPC interface but also uses an SQLite database to store its information which facilitates access to the information managed by the protocol.
Outside the core and informational services, a few projects are developing tools around the assets including for crowdfunding (Vennd.io, Koinify, Swarm) and
rewards programs (LTBcoin.com).
Forks
There are two forks for the Counterparty code. The first, called Clearinghouse runs on the separate block chain provided by Viacoin. The second is Dogeparty which was implemented by Humint.is on the Dogecoin block chain. Dogeparty initialized the balances of their own central token-of-value using the same proof of burn process used by Counterparty with some tweaks. Clearinghouse developers instead sold XCH by rewarding funds sent in Viacoin to an exodus address with the new currency. It should be noted that while each of these systems launched on their prospective block chains, there is nothing in the Counterparty code base that permanently ties an instance of the system to a particular block chain. Therefore should there be issues with the security of the network either system uses, the respective communities could opt to switch to another block chain.
Conclusion
Counterparty is a decentralized system for extended financial transactions that has seen steady development and adoption since its launch. The project and its network are young and many are working on competing systems that could pose significant risk to those who would get involved with the project or invest in its fledgling economy. Further study is advised before making decisions on investment of time or capital.
Update: Oct 23, 2014 Clearinghouse seems to have confusingly labeled their XCH initialization process as burning and a “Fire Sale” when in fact developers kept the funds instead of having them sent to an unspendable address.
Update: Nov 14, 2014 Counterparty announced two days ago that they have integrated Ethereum’s EVM contracts on testnet. This means that any smart contracts written for Ethereum will run on Counterparty on the Bitcoin block chain. Only two days later Ethereum, countered by implementing Counterparty’s smart contracts in Serpent, one of the languages for writing Ethereum EVM contracts. Innovation is alive and well in the Bitcoin 2.0 space!
2 comments ¤
Permalink
¤
2014-10-06