Bitcoin Update Board: Distributd update proposals & user activation coordination

[praxeology]

TL;DR: Distributed solution to responsibly coordinate activation of soft forks and other updates in a "User Activated" manner.  Distributed solution to propose BIPs and other updates.

=================================
Messaging Based on Locked Outputs
=================================

Message itself:
version, type, txid, Payload, Signature

Transaction:
- some amount locked for N blocks
- maybe some amount burned
- output requires same public key as used in message signature

Messages are 1:1 associated with a transaction in order to mitigate spam.  Nodes can ignore a message if the tx is spent, tx already has a message associated, tx amount is lower than user specified threhold.  tx amount could be locked for N blocks, or burned as more ways to filter spam.  Messages can be trashed when their associated tx is spent.  Relaying such messages can be optional... nodes who are interested in various types of messages can look for other nodes that support that type.

====================
Bitcoin Update Board
====================

= Purpose =

To provide a distributed place where different groups can see what other groups' status is on proposed updates to Bitcoin software. To enable entities in the Bitcoin ecosystem to responsibly activate updates.

= Background =

It is a complex task to roll out updates for any kind of networking software. Bitcoin is one of the most complex networking architectures. There are many different kinds of software in the bitcoin network: miners, relay nodes, exchanges, blockchian explorers, wallets... each running different versions of software that may even be implemented by entirely different development teams. Any update to Bitcoin software can negatively impact members of the network. In the worst case, a policy change can result in the bitcoin ledger being forked into two separate ledgers. To make things worse, there is no central authority for bitcoin software, and hence there is currently no good place to host update coordination information. BitcoinUpdateBoard creates a new distributed method of communication to coordinate updates to bitcoin software.

= General Description =

The end result of the BitcoinUpdateBoard proposal is to provide a more distributed and automated version of Bitcoin Core's SegWit adoption table located here: "https://bitcoincore.org/en/segwit_adoption/". The system helps various distributed groups in coordinating when to release or activate an update.

No vote is involved. No activation is automatically triggered in all clients by some threshold being met. Instead, entities decide for themselves which updates/policy changes they want to adopt, and when. This can be done by choosing which software to run. Developers can either hard code activation dates, or create their own automated system that looks at the UpdateStatus messages to decide when to activate.

For communicated data structures, I propose:

- UpdateSpec: a bitcoin network message
- UpdateStatus: a bitcoin network message
- GetUpdateSpecList(MinBlockHeight, MinTxAmount)
- GetUpdateSpecList(MinBlockHeight, publicKey)
- GetUpdateStatusList(MinBlockHeight, UpdateSpec.GUID, MinTxAmount)
- GetUpdateStatusList(MinBlockHeight, UpdateSpec.GUID, publicKey)
- UpdateSpecList
- UpdateStatusList
- MemberFilter: json file with a list of public keys

UpdateSpec and UpdateStatus are Messaging Based on Locked Outputs

= UpdateSpec =

Payload: UUID, Resolved:yes/no, IsPolicyChange:yes/no, Name, VersionTag, ProposedActivationDate, SpecText

UpdateSpec messages create specifications for updates.

An UpdateSpec can be updated by submitting a new tx+UpdateSpec message with the same UUID. The VersionTag is for human readability. The "Resolved" field is used by the UpdateSpec owner to help clients filter resolved UpdateSpecs. ProposedActivationDate can be null.

= UpdateStatus =

Payload: UpdateSpec.txid, Accept: yes/no/undecided, ExpectedActivationPerparedDate, Prepared:yes/no, ActivatingDate, Activated:yes/no, CurrentSoftware:[{SoftwareName:"", SoftwareVerson:""}, ...], Comment

UpdateStatus messages communicate to others in the bitcoin network the intention of an entity in thier accepting, preparing, and activating an update.

An UpdateStatus can be updated by submitting a new tx+UpdateStatus message w/ the same UpdateSpec.txid. Dates can be null.

= MemberFilter =

{
Name : MemberFilterName,
Version : VersionTag,
Date: TheDate,
ShowMembers : [ Member:{}, ... ],
}

Member: { Name: "", Key: "", Role:"", Email:"", Website:"" }  // Role: exchange, miner, developer, trader, other..

MemberFilter is a json file containing public keys of UpdateStatus messages that an entity considers interesting.  In addition to filtering policy messages by tx amount... Clients can load a MemberFilter. Entities can publicly provide evidence of their public key. Entities can provide an (optionally signed) MemberFilter for the public to use. A MemberFilter is not communicated over the Bitcoin Node Network.  Verification of identities is performed in the real world, off chain.

= User Interface Requirements =

- UI to create the new message/transaction types.
- UI to display a UpdateSpec, an its associated UpdateStatus message data.
- The wallet would need to somehow mark the transactions as Do Not Spend, or require users to create a separate wallet.

= Future work =

Once organizations start identifying themselves by Bitcoin's public keys, this provides an entirely new distributed system for confirming identity. Entities can find eachother through the bitcoin node network and establish fast, secure, reliable communication channels.

= Concluding Remarks =

This is an early draft. Comments welcomed!

Cheers,
Praxeology

[1715321247]

1715321247

[1715321247]

1715321247

[-ck]

Why the hell do all these radical proposals always come from new accounts? Are you all so scared of associating coordinating radical change with your existing online personas?

[praxeology]

ck,

TL;DR: "radical" because its never been done before or proposed before?  I'll take that as a compliment of my innovation.  But if it has merit then maybe we should do it.  I would greatly appreciate constructive feedback.


Hi I'm Praxeology.  I'm a software engineer, Austrian school economist, and a philosopher with various backgrounds including Objectivism and Voluntaryism*.

* Not disclosing my current philosophical or religious beliefs

The account is new because I am new to this place.  I haven't really been interested in ever posting here because I haven't really felt you guys needed me that much... and its risky to stick my head up worried it might get smashed down by the powers-that-be's hammer.  About a month ago I realized that SegWit adoption was being stalled, and I've been working long hours to figure out why and what to do about it.  I've come to the conclusion that block producers are strong arming the user base in order to get control of block size... and in the long term then control of bitcoin policy in general.

The debate of SegWit vs Unlimited, how an individual can judge which one is better, and how an update to bitcoin should be selected and activated all depend on:
- Understanding of software engineering and Bitcoin software
- Understanding of Austrian school economics
- Understanding of Objectivist metaphysics, and ethics from the perspective of special interest groups

My task is to help everyone discover that Bitcoin is a money system built for the benefits of a specific special interest group.  That we should identify others in the special interest group and work towards making the money better for us.  Not allow it to be compromised or progress overly delayed by the opinions of people in other special interest groups who have contradictory goals.  This is necessary for a User Activated Soft Fork to happen in a world where the Core sympathetic special interest group is the minority*.

* we may be the minority in numbers, but we are the entrepreneurs, the people who create price floors in market cap.
* people who want sound money are a minority in the US population.  Otherwise the popular vote would have never permitted 1913/1933 and/or quickly restored decentralized money.
* I have yet to date not been a participating member of Core, and I only began participating in the social bitcoin community about a month ago.

We have used Bitcoin to help protect us from theft, censorship, monopoly transaction fees, and to be able to stop contributing our purchasing power and work towards the goals of the corrupt money printers.  I am part of the special interest group that wants competition in money to achieve the goal of having this kind of money.  I want to use a money where verification, ownership, and policy decisions are performed by end users (distributed), money supply policy is set at onset and never changed, and the ledger state is determined by the policy I decide for myself combined with the greatest proof of work.  I believe that Bitcoin Core is also working toward these objectives.

Block candidate producers are only service providers to us.  They work for us.  It was a mistake to give them the power to choose policy change (BIP9).  The mistake was the assumption that miners were in the same special interest group as other users in the bitcoin ecosystem (and particularly us in our special interest group).

Software updates, and particularly policy changing software updates, should entirely be up to individuals/organizations that use it.  They choose which currency/policy they want to use, they have all the authority, its an entirely voluntary system.  Bitcoin Update Board helps individuals do this with relevant information in a system that I haven't seen anyone else propose.

[praxeology]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Praxeological Economic Analysis of Bitcoin Forks

By Praxeology Guy

Version 0.0a

Tips always appreciated @ 1scf9JP4uYfLJvTpw1LB3wxHJ8fAMdvPS

Copyright (c) March 29 2017 Praxeology Guy

Permission is hereby granted, free of charge, to any person obtaining a copy of this document which includes surrounding digital signature (the "Document"), to read, copy, publish, distribute, sub-license, and/or sell full intact copies of the Document, and to permit persons to whom the Document is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies of the Document.

Verification of truth is the responsibility of the reader. Any consequences to actions taken by a choice influenced by information in this document is the sole responsibility of the reader, and none what-so-ever of the author.

=================================================
=================================================
Praxeological Economic Analysis of Bitcoin Forks
=================================================
=================================================

==============
SegWit Example
==============

Lets talk about how a fork would not be bad given special interest group dynamics.  Lets use the specific case of SegWit.  SegWit is a policy change where the signature data is removed from transaction IDs, and it currently comes bundled with an effective block size increase to 2MB.

What are the different options on how we can activate SegWit?

1. We can fork via orphaning blocks.  Then we are causing the fork to happen, unless a good portion of old-version miners are ok with getting orphaned. If they are not ok with getting orphaned, and decide to fork due to our action in this manner, then I feel like we'd be responsible for the fork, and we would have to implement the replay attack protection. We would know exactly when the fork would happen. Orphaning their blocks could be considered a kind of rude way to go about the fork, especially when there are other options.

2. We can soft fork via a user activated future date/block height threshold.  Sure its true that with a soft fork you cannot know when or if a chain split will ever happen... especially when they are threatening to fork/refusing to adopt our soft fork. It is foolish for us to wait for miners to adopt policy change when they are refusing not by reason of merit, instead to strong arm. Without > 50% hash power a split is more likely yes.

3. The other option is maybe we can convince the miners to activate SegWit in the future. That does not seem likely to me. At least not in a reasonable time frame.

Are there any other options?

===========================
Date Threshold UASF Options
===========================

Let me go more into detail of what could happen if we adopt a date threshold User Activated Soft Fork (UASF):

Chain split due to Unlimited nodes actively rejecting SegWit blocks?
Result: That's a conflicting soft fork.

Chain split due to someone making an invalid SegWit block, and then non-upgrading nodes mining on it? They would have to chose to:
A. Pre-filter their blocks by connecting to their own instance of a SegWit node
B. Upgrade
C. Manually enter in checkpoints
D. Fork.

I'm pretty sure they would rapidly do A or B in preparation for activation. Maybe some lazy people would do C/fail to do A/B and then scramble to do them. That's just a temporary problem for them where they waste some of their own resources.

================================================================
Economic analysis of a fork; Dependency: Source of Money's Value
================================================================

First we need to know why money has value in the first place. Money is a tool used to transfer market purchasing power.  Market participants prefer to use a money that has the greatest purchasing power transfer efficiency (Return) using the following equation:

Return = spend value / (purchase value + use cost)

Or more correctly, they prefer the one with the greatest expected [interest rate/rate of return] calculated as:

Yearly Rate of Return = Return ^ (1/(spend date - purchase date))

"value" here refers to market purchasing power.  Its actually a subjective amount:  "value" depends on how much an individual determines a good or service or action would increase or decrease his goal attainment.  But given that a person's goals/values do not change by much over time, and neither do other market participants, and the environment that we live in doesn't change much... exchange rates between different goods and services stabilize.

"use cost" here refers to all costs that negatively impact a user's goal attainment.  Time spent performing the transaction, transaction delays, fees, theft of money, inflation (bankers taking our purchasing power) decreasing the money's value, having to work & accomplish the corrupt bankers' goals to get their money, banker's directing action including bribing politicians and the government to perform violence against us and our trade partners, taking extra steps to get around/fulfill censorship and taxation requirements: there are all sorts of use costs of a money.

Market purchasing power is then basically the going exchange rate of a good or service... and it is usually measured in the most stable money, adjusted for inflation (increases in money supply).  Some economists use other measures of inflation such as "price inflation", but this is more arbitrary and less useful for an entrepreneur since price inflation is most directly effected supply inflation.  Also, other changes in goals/values & environment can also effect price inflation, which kind of break down the assumptions of such "not changing much"... and make comparisons of "market purchasing power" over time more arbitrary.  Whenever I say “inflation” I follow default Austrian school convention: it means “supply inflation” unless I specifically say “price inflation”.

Why do people want to transfer market purchasing power?  Such is an abstraction of trade.  Trade is a mutually consensual interaction between two entities, where both would rather have some quantity of what the other has, and come to an agreement on the exchange rate.  For example if I am a chair maker, and I have so many chairs they are filling up my shed, I'd have two options:
- - Trade a chair in my shed and free some shed space in exchange for some other market good/service that someone else has
- - Continue having a shed full of chairs
If I determine the exchange rate that another market participant is offering me should result an a net increase in my goal attainment, then I accept the offer and trade.

Lastly, why trade at all? Why don't people just produce everything they need for themselves?  The answer is: a specialized producer can create/use tools and processes that are more efficient than a non-specialized producer.  So as long as the efficiency increase due to specialization exceeds the costs of losses in trade efficiency, individuals will tend to choose to specialize and trade rather than directly create the product/service themselves.

=============
Fork Analysis
=============

Now that we understand money and why people use it... we have the dependencies resolved where we can use praxeology to analyze the economic consequences of a currency fork.

Forking is a short term problem for market participants. Its an entrepreneurial problem where people need to predict the consequences of the fork, and try to figure out which branch will result in the greatest money transfer efficiency/rate of return.  If people expect they will be able to spend some quantity of money later at a higher price, they are more willing to pay the currently offered market price.  This is the source of a money's market capitalization.  Deduction (fundamental analysis: deducing utility of a good) investors have the best chance to make the most profits, followed by induction investors (seeing utility of a good).  Herd investors who employ technical analysis (watching price) can unfortunately be mislead by invalid arguments and propaganda... and stand to either make no profits or actually have losses.

After a fork, if both branches/money supplies are good competition in the market for different use cases of money... then they will both retain some market capitalization.  For example, if there was a fork between Core and Unlimited, Core's branch may still be used for higher value and especially longer term money storage... verses Unlimited would be used for lesser important transactions and shorter term money storage.  This is because Core's policy is more resilient to corruption but doesn't have enough tx throughput for lesser important (lower fee) transactions...  but Unlimited's policy is less resilient to corruption (hence more vulnerable to price collapse), but has greater tx throughput and hence can transmit a greater quantity of lesser important (lower fee) transactions.

If Unlimited's policy can be controlled and not runaway into my expectations of an extremely centralized system where only a few mining pools exist and are the only retainers/validators of the block chain... (a centralized system not much different than a central bank that allows users to use public key cryptography)...  then maybe it can retain its purchasing power over a longer time like Core.  Or maybe government will take control of it, and they will make it the next version of International Money Fund's Special Drawing Rights.  There it will continue to compete with Core's branch... where the costs of corruption on its money transfer cannot greatly exceed the costs of using the more decentralized Core money.  Here we can finally see that Unlimited currency users should prefer that a Core branch continues to exist, because the Core branch's competition reduces the corruption costs in their currency.

Forking should become a less frequent and significant of a problem for market participants as the technology behind bitcoin matures.  Fewer and fewer experimental policy changes will be considered worth trying by market participants.  The currency that retains the best policy, that enables the greatest money transfer efficiency, will over the long term continue to exist, retaining market purchasing power & market capitalization.

Being able to handle more and more use cases at high efficiency can also increase a currency’s “network effect”, where a currency is easier to directly trade with more people, increasing its money transfer efficiency.  Hence if there are two otherwise functionally identical currencies, if one starts with more users and can handle all the users transactions for both currencies, it will tend to collect all of the other currency’s users.  I do not think that Core’s and Unlimited’s policies are functionally equivalent enough that such would happen if they forked…  Core’s resilience to centralized corruption again provides a market need that Unlimited will likely not be able to provide.

====================================================
Praxeology Guy's SegWit Activation Strategy Proposal
====================================================

Unlimited & other sympathetic block producer's strategy to strong-arm-delay-SegWit is long term ineffective in accomplishing Unlimited's goal (because their goal compromises Core's goal). I'm not going to compromise on bitcoin's distributed nature (end user synchronization & verification). SegWit is good and we should activate it. Its a bluff for them to act like they won't accept SegWit. They will. We can call them on it with a date threshold UASF.

I am confident that the negative economic consequences of Unlimited sympathetics' decision to perform a [conflicting soft fork/hard fork/build on invalid SegWit block fork] would only be short term and not too important. It will just be fools losing money if their fork fails, or temporary price variance and a long term benefit for everyone if their fork succeeds.  The collapse of the MtGox exchange showed us that the price floor of a distributed currency like bitcoin can be found and confidence return about 2 years after an unwarranted loss of confidence. Long term we need to keep on making good policy changes and upgrades to Bitcoin Core so that we can have better (more efficient money transfer) distributed money... and as long as we are in overwhelming agreeing on a feature being good: sooner rather than later.  I know gmaxwell is uncertain to whether we should also bundle the effective block size to increase to 2MB in the SegWit soft fork.

So here is what I propose: Core sympathetic nodes activate SegWit according to the process of BIP9 whether or not it meets the threshold requirements on the last 2016 blocks in SegWit's BIP9 activation window (which ends on 15 Nov 2017).  We announce and implement such.  Then Unlimited/Classic can respond with what they are going to do in response. Then exchanges etc can prepare on how they want to handle what will happen. So then most every important party would be prepared for a fork if it happens.

I don't really think delaying SegWit's activation further will have any positive effect.  The only concern I have is the one I share with gmaxwell, that maybe we shouldn't bundle in the effective block size increase to 2MB.

===========================================================================
Praxeology Guy's Investment Strategy in the Case of a SegWit/Unlimited Fork
===========================================================================

If Unlimited sympathetic users do fork from Core, my current investment strategy is to hold onto both currencies, but not to buy an additional Unlimited coins.  If I see that Unlimited can be secure enough from the corruption of centralization, then I will hold onto it longer.  If I predict Unlimited coins will soon become too corrupted and become a less efficient form of money, then at that time I will sell it.

This is not investment advice. My communication is in no way guaranteed to be correct.  It is fully the recipient's responsibility to verify the information I offer, and hence the consequences of any decisions based on the offered information is also fully the recipient's responsibility.

==================
Concluding Remarks
==================

I very much hope my economic analysis will help everyone understand money better, and how to make better decisions about what money they want to invest in and use.  I hope it also helps us more rapidly conclude this Unlimited/SegWit debate and then also in the future adopt policies faster.  I honestly hope that they fork sooner rather than later, and that Unlimited gets a good development team together so that they can viably create a competing currency.  I like having better money sooner rather than later.  Every day of my life I think about all of the wonderful things that could exist but don't: due to all of the corruption involved in centralized money, that diverts our economy from creating products that producers and consumers want to the products and goals that central bankers want.  The sooner we have better competition to money (and all of that corruption goes away) the better.

Please let me know if you find a mistake.  I'll make diffs and new versions.  Comments/Questions welcomed.  Thanks,
Praxeology Guy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJY2+8MAAoJENNlMIy4c2uXx78H/iIcVc/KZihODqp1S2vK3+05
MJR2HAJd9U/WGA9qp/GqCk/vv1R+66CQ3QDdyR8K9EWTN6UedygDcJJytqT4b5dE
MZJ0oIrXmdXna3URmGJ0cKADfVVd6HL05QW6/gcoI905t5uMS8OWRt6VyXSoz9rW
dFneCaEguO6UM2aIHMNWJ305S3V61AELs3QVDfeOxMNZhbypgwfgxmA53M5DNeeA
zdcFgrqvfrUq1NgmukjVyXjosXWUGYOQyEnZtH2uGG8Gd9QDA1azVRAgaIT/JJnQ
b7hHrPi/pBwkt/n+9a6R+TjPJjOLivNMQasLOEeJNDGMTZPgKr8NJGp9ueiJXKs=
=GucF
-----END PGP SIGNATURE-----