Gregory Maxwell,

Sorry for my outburst.  I read between the lines, interpreting your message in the most negative light.  Then I implied you meant something that you didn't say.

I do appreciate your patience, wisdom, and insights.  I can be a hot head sometimes, wanting to make changes happen before everything is ready.

Sincerely,
Praxeology Guy

rizzlarolla,

"Replay attack" prevention means that a user is able to choose which branch their transaction occurs on.  The current BIP148 assumes that there would be no interest to transact on the branch that it orphans.  In my opinion that is reckless.  Below is my proposal on how to once and for all implement replay attack prevention.  It should make forks cleanly separate money supplies.  Whether people choose to use a branch is a completely different question.

---

Draft BIP: Use Policy ID for Clean Forking

=== In Short ===

Create a "Policy ID" that nodes can use to identify desirable peers, blocks, and which transactions belong in a particular Bitcoin blocktree (blockchain-no-more) Branch.

=== Rational ===

Users want Bitcoin to be able to handle two different use cases. One (Core) is to be able to inexpensively operate a fully verifying node. The other (Unlimited) is to have more expensive operation, in order to support more usage.

Neither of the groups want to compromise. The money capitalization of both systems would likely be greater in total if there was a fork rather than continuing together in a stalemate. See my analysis of competing money here: https://bitcointalk.org/index.php?topic=1873155.0

=== Details ===

1. Create a new kind of identifier... a "Policy ID". This ID is metadata used by a node and wallets to distinguish which Policy they are interested in, which Policy a Block conforms to, and which Branch a transaction is for. The transaction's target Policy may or may not have actually created a fork yet in the Bitcoin blockchain (or blocktree ).

2. The Policy ID need not be included in the Block header nor coinbase. It can be transmitted as metadata, and the node can verify for itself whether the Block conforms to the Policy ID.

3. The Policy ID should be used in a transaction in a virtual field that is visible to the signing script, but is not visible to the algorithm that generates the transaction's ID. The ID would need to be transmitted in the metadata when relaying an unconfirmed transaction, or when relaying a transaction included in a block... similar to how SegWit witness data is transmitted.

4. In Validation, a node will require that each transaction in a Block has the same Policy ID as the Policy ID of the Branch that the node is currently working on. There is a potential that a Node may maintain multiple Branches. The Policy ID doesn't need to be part of the Block Header, it can just be metadata that is transmitted with the Block ID and/or Block Header.

5. Policy ID should probably be a variable byte length non-negative integer when serialized with a transaction in the block and fed into the signature. I'm not sold on any particular technique for compressing the Policy ID for various purposes. Maybe when signing it and transmitting it with a transaction, its first 4 bits should encode the smallest byte length that can hold it, then the remaining bits be the actual Policy ID.

Discussion: Nodes can then find other nodes that are interested in the same Policy ID(s). Wallets can generate transactions that can only be spent on the user's desired Branch. In the long term future, if there are multiple actively mined Bitcoin Branches, node and wallet software could potentially maintain many different Branches.

At first one might be concerned about spam consuming the Policy ID numberspace.  But I'm pretty sure that a Policy ID can be reclaimed in the future if there is no active miner/branch using it... users won't be concerned if their transaction gets spent on an inactive branch.

Cheers,
Praxeology Guy

jonald_fyookball,


I don't know how you can go and call me "misinformed" when you fail to read my post.  bitcoincore.org is not divine truth.  I came up with a solution that they didn't consider.

Sorry for my frustration with you.  Have a nice day.

cryptoanarchist,

Each Bitcoin Node has a Policy chosen by its operator.  Anybody can produce block candidates that conform to a node's policy.  A node will look for the chain of blocks with the greatest PoW THAT MEETS ITS POLICY.  Differences in node policy can result in chain splits.  There is nothing stopping long lasting chain splits, where each is its own separate money supply/ledger.

In fact, alt coins can be considered Bitcoin nodes that adopted a different Policy, who forked at or before the Bitcoin genesis block.

Miners are motivated to increase their mining work on a coin until the following equation equalizes:

Energy Cost + Capital Rent + Labor ~= block bonus + transaction fees

So as long as a branch's coins are worth something to somebody... they will be mined.

Cheers,
Praxeology Guy

jonald_fyookball,

Above in my reply I propose a way that non-upgrading miners could continue to mine non-segwit blocks while still verifying SegWit blocks, which would avoid a chain split.  You claimed that such was not possible, I showed how it was possible.

=============

The One,

Policy: Rules that a node performs on block candidates in order to decide whether a block should be accepted into their block "tree", and then more rules that decide which branch tip describes the current ledger.

Soft Fork: A change to policy that is more constraining.

The purpose of BIP9 is to activate a Soft Fork that almost every miner wants without risk of a chain split (fork).  If a significant portion of miners (maybe 5% or more) do not want the policy change, then BIP9 fails.  Then we decide if we want to propose something new, or if we should cause a fork (via user activated policy change).

The next step is to User Activated Soft Fork.  I'm not too particular on which method is used to get SegWit activated.  Whatever (reasonable) option BitFury goes with, I'm in.

Cheers,
Praxeology Guy

Fundamentalist Long-Positioned Money Investment

TLDR: Invest in monies that you expect can handle more uses than it currently does while maintaining lower usage cost (such as transaction fees) than established competition.

1. Calculating How Good a Money Is For a Use Case

Money is a tool used to transfer market purchasing power. Market participants prefer to use a money that has the greatest expected rate of return.

Return = spend value / (purchase value + use cost)
Rate of Return = 100% * (1 - Return ^ (1/(spend date - purchase date)))

In a more stable money market, the rate of return is likely negative for most users.  Rate of Return can then be viewed as a transfer efficiency.  In a less stable money market, the choice of which money to use is an entrepreneurial decision, because the exchange rate at time of spend is in the future and not known with certainty at the time of acquisition.  Such entrepreneurial decisions were the original source of Bitcoin's market value.

Value over time is not an exact measurement given man's changing goals and context.  Never the less, we measure "use cost" and "value" in the least volatile currency, adjusted for inflation.  "use cost" can include costs other than transaction fees, such as the labor and time.  When predicting the efficiency of using a money option, its spend value would have some probability distribution depending on the user's expectations.  Insuring against risk of loss would have a use cost.

One of the least volatile currencies (at least on a day to day basis) is the US Dollar.  According to BASENS, GFDEBTN, and shadowstats.com CPI inflation (1980 method), all three are consistent with USD's purchasing power decreasing at about 8% per year since the year 2000, unlike official numbers of around 2%.  You are free to use your own measure of inflation.  I use money supply inflation, since it is the least arbitrary and hardest to manipulate.  Given 8%, if you want to use USD as a benchmark to measure market value, you need to account for 8% inflation.  If you maintain ownership of $100 USD for a year, then you also have to account for the costs of giving $8 of purchasing power to corrupt bankers and politicians.

2. Market Dynamics with Competing Currencies

Money efficiency is important, because people look for the most efficient money available for each of their use cases.  Each use of a money temporarily consumes some portion of the money's supply.  The greater the demand for being able to use the money's supply, the higher the money's market cap, the more a given fraction of the money supply is worth.

If a new money can fulfill all of an established money's uses while still offering a better efficiency, then I'd expect it to eventually absorb the other money's users (and market cap).  I'd call this a voluntary "monopolization", which can overcome the transient "network effect" via entrepreneurial investment.  Instead, if its efficiency decreases during the process of increasing in usage, if the efficiency of both currencies become equal, then both currencies will be used in parallel.  If a new money can't fulfill any use case better than any other currency to any extent, then it likely will be worthless.

Each money has a different efficiency for a particular use case.  A trade partner may value an offered currency at a different exchange rate than others at a popular local exchange (network effect).  A money may have a different cost to meet the use case's specific requirements on security, anonymity, transfer speed, value storage duration, distance, and other factors.  Hence a competing money might be used only because it can be more efficient in a niche use case.

3. Concluding Investment Strategy

An entrepreneur looking to invest long term in monies would look for a money that can still handle significantly more uses while still having a better transfer efficiency than established monies in its niche use case(s).

jonald_fyookball,

Potentially the non-SegWit supporting miners could filter their blocks with a SegWit node... if they actually wanted to avoid a fork.  Its really hard to say what Bitcoin Unlimited signalling miners would do after SegWit validation rules were activated.

The solution is to fork when two different special interest groups with different use cases diverge on policy preference.

Unfortunately there is an unfounded stigma in the public's eye that forks are a bad thing.

If a money supply forks and two money supplies develop, it is better for everyone.  There is a net gain increase in money market cap, entrepreneurs who invest in both profit.  Money users in both enjoy lower transaction fees than otherwise possible.

If one branch immediately dies, its just an insignificant short term problem for the entrepreneurs mistakenly invested in it. 

The only thing I request is better replay attack prevention.  I'd propose each branch use the transaction version bits for a sort term solution.  Long term if there are lots of forks, then use a "Pre-TX branch ID" that is not part of the TX ID, but is signed on by the witness data, and part of a SegWit style merkle tree commitment.

If Unlimited doesn't want to adopt such a merkle tree commitment in the coinbase due to asicboost, but we still want two separate merkle tree commitments for with and without Witness/branch data, then a hard fork that has these two merkle roots under the merkle root commited in the block header could be used.  Such could be used to develop additional extensions like SegWit that Gregory Maxwell was concerned asicboost usage would prevent.

Cheers,
Praxeology Guy

Gregory Maxwell,

> If the goal is user activation I would think that the
> expectation would be that the overwhelming majority of users would be
> upgrading to do it, if that isn't the case, then it isn't really a user
> activated softfork-- it's something else.

Oh... so _that_ comes out.  I do not care what the majority wants.  The majority of people are thieves if they could get away with it.  Consider this: Lets propose a policy where the world can vote on taking half of the current Bitcoin owner's coins away and evenly distributing them to each world citizen.  Screw that, I've had enough of that.  Distributed money doesn't have to be that way.

Lets stop with the whole soft/hard fork designation when there are two disparate groups with conflicting preferences on a policy change.  Soft/Hard doesn't matter anymore.  Its just a fork.

I want SegWit.  I'm perfectly happy w/ forking the money supply I use from the people who don't want SegWit.  I just want replay attack prevention.

To all of you out there who want sound money, this is our song:
Green Day - Minority
https://www.youtube.com/watch?v=cDBlqu6KF4k

Cheers,
Praxeology Guy

Starting this thread in response to Gregory Maxwell's post on the bitcoin developer mailing list:

"I do not support the BIP 148 UASF"
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-April/014152.html

For people who would like to comment, but cannot due to tighter moderation restrictions on the dev mailing list.

Such is possible with a browser addon/plugin that interacts with the user's bitcoin wallet, but does not currently exist AFAIK.

Disparate groups are arguing over what "Bitcoin" should be.  There is concern from all parties about what the general public will end up thinking "Bitcoin" is.

In my opinion, trademarking "Bitcoin" is too late.  But there is another option where all parties can continue to use the word "Bitcoin" and yet have a different Brand and Policy.

Logos!

Logos are vector/bitmap images that have extra distinguishing information beyond a short ascii stream like "Bitcoin".  Logos can be copyrighted, and their usage can be defended in common law.

In order to complete such a task, the following would need to be done:
- Create an Awesome Logo
- Create a formal Policy document that includes a layman (yet still accurate) description
- Maybe further refactor and separate Policy code from other aspects of Bitcoin software... so that it can be cleanly reviewed, signed, and required for Logo use.

Here is a longer winded exploration of this idea:
https://lists.linuxfoundation.org/pipermail/bitcoin-discuss/2017-April/000137.html

Please let me know if you'd like your Bitcoin software to have such a Logo!
Thank you for your Logo ideas!

Cheers,
Praxeology Guy

Luke-jr is working on a more formal API for exchange rates.  https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-March/013660.html

In order to create such a button/form you would need to communicate with an exchange etc to get their latest prices... either through Luke-jr's API in the future or whatever the exchange provides now.

Where is the "Both with fork, and Unlimited also adopts SegWit in their fork because its good and not orthogonal" option?

-----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-----

I just talked to gmaxwell about this.

He said something like: you can specify relative lock time in a transaction.  So lets say you make a transaction where it can't be included in the block until 10,000 blocks after its newest input.

Then you increment the transaction's sequence number and change the lock to 9,000 and say adjust the amount sent.
Then you ** 8,000 and adjust the amount sent again.
Then you ** 7,000 **.

Block candidate producers (miners) would then be very likely to include the first available transaction that becomes unlocked... so that a particular block producer can gain the benefit of the tx fee instead of some other producer say 1000 blocks from now w/ the previous sequence number.  Also, in general, entities prefer attaining ownership of more durable money/resources earlier rather than later, all else being equal.

With Child Pays For Parent, or other methods, even the recipient could motivate miners to include the transaction with the shortest lock time.

Such an explanation satisfied all of my questions.  Do you need more or are you now satisfied too?

Cheers,
Praxeology

Hi Kano.  Maybe what you are missing is that in SegWit blocks, the SegWit transaction signature data is moved into a data structure that older versions of the software don't see nor consider to be a part of the block.  And signature data takes up like 75% of a pre-segwit transaction's size.  Given that we need to forever remember pre-segwit transactions to calculate their txids, but segwit transactions we can eventually throw away the signature data and still calculate the txid... this is the other reason why old transactions are weighted more...  other than that they are also weighted more because they take up more space in the perspective of non-segwit nodes.

Edit: and about the "slow" stuff you are talking about... I think that has more to do with schnorr signatures... "https://en.wikipedia.org/wiki/Schnorr_signature" which are not a part of SegWit.  I don't think CPU time has anything to do with weighting differences.  Correct me if I'm wrong.

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.

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