Submitted by John Smith
Bitcoin XT: Premature intervention?
TLDR: Bitcoin XT proposes a premature fix to a potential problem; let's first wait and see how market forces react
These viewpoints illustrate my main objections to the Bitcoin XT proposal.
They are NOT comprehensive explanations of the proposed changes!
-PUBELIUS
BITCOIN XT FOR ACCOUNTANTS:
"The Blockchain" is Bitcoin's global ledger. It contains pages ("blocks") of ledger entries ("transactions"). Thousands of people maintain complete copies of the ledger worldwide. Having many copies of the ledger improves the resilience of the Bitcoin network.
The first 2 years of ledger pages (2009-2011) are largely blank. Since then, almost every page has some entries. Some of the recent pages are almost full.
Bitcoin XT proposes that everyone switch to using a redesigned extra tall ledger, whose pages have room for 8 times as many entries. Every two years thereafter, the page size will double.
The original and new ledgers are incompatible. Unless A) everyone keeps using the old books, or B) everyone switches to the new books, then everyone will get screwed by 2 diverging sets of books.
I prefer option A, keeping the existing ledgers:
- If there are too many transactions to fit on a new page, just write down the most important transactions, and leave the unimportant ones pending.
- Ledger space is valuable - the costs of storing each entry are multiplied by the number of ledgers worldwide for all time.
- fewer people will maintain ledgers if those exponentially increase in size (thus decreasing the network's resilience.)
BITCOIN XT FOR ECONOMISTS:
Let "transaction bandwidth" be a scarce resource that is required to settle a pending Bitcoin transaction.
A technical decision made in 2009 set the transaction bandwidth available in each Bitcoin block at 1 megabyte; thus to date it has always had the same fixed supply.
Due to altruistic miners and plenty of spare room in blocks, Bitcoin users are accustomed to obtaining transaction bandwidth for free or minimal cost. There's always room for all transactions - so far.
Thus the unit cost of transaction bandwidth (the amount you must pay for your Bitcoin transaction to be settled) is, today, currently low or zero.
And, today, the demand for transaction bandwidth in a given block is nearly always less than the supply.
However, once demand exceeds the supply of transaction bandwidth (when transactions become so frequent that it becomes normal to see more than 1Mb pending transactions at each block) then some of these transactions will never settle.
Bitcoin XT proposes to modify Bitcoin to increase the maximum block size at 8mb, i.e. to increase the supply of transaction bandwidth eightfold; and thereafter to automatically increase it exponentially, doubling every two years.
I oppose the proposal because:
- The market for transaction bandwidth is immature and has not yet seen competition or price discovery, thus intervention may well be premature
- Increasing the limit reduces or removes market pressures to use available transaction bandwidth for important transactions instead of unimportant transactions
- Changing a resource from a flat, fixed supply to an exponentially increasing could possibly, just maybe, lead to unwelcome and unknown side effects
- This is probably the first large scale opportunity to see whether unrestricted market forces actually do optimize a supply curve
- Storage costs are externalized so users have no disincentive to spam unimportant transactions
BITCOIN XT FOR DEVS:
http://lmgtfy.com/?q=bitcoin+xt
[5]
BITCOIN XT FOR ENGINEERS:
Let Bitcoin be a black box having inputs: "bitcoin users" and "consensus rules"
and outputs: "blockchain state" and "unconfirmed transactions".
Theory suggests that if we don't touch the inputs, the blockchain state will continue updating but eventually there will be many unconfirmed transactions.
Theory also suggests that if we modify the block size limit, the blockchain state will continue updating, and there will be no unconfirmed transactions.
Has anyone yet asked why we care about confirming every transaction?
Could we add a killswitch to pending transactions after 24 hours, so you can try again with a more reasonable transaction fee?
As a reminder, this is a 3.5 billion dollar production system with 6 years of uptime that depends on human interaction and is sort of magic, are you SURE that we should fuck with its inputs?