There are a range of opinions about input assumptions by different people. In each case, short of misunderstanding, if we have the same input assumptions we're going to reach the same conclusions. This is the way of the world in a meritocracy. The interesting point is to compare the input assumptions and try to figure out which are more realistic, pragmatic and achieve the best outcome.
It might be instructive to re-read Greg's roadmap and others to re-read Jeff's original post (I will). There is a proposed roadmap and soft-fork block-size increase and code that Pieter is working on. There has been rationale described for this approach, and it achieves many useful things both short, mid and long term for scale and other issues. There seem to be a range of opinions on the fee market, and one question is when do we deem it safe to aim to be prepared to support a fee market. How elastic is block-size demand? (I think there is evidence of some elasticity which indicates a partly working fee market already). What I mean by elasticity of block-size demand is there are off-chain transactions and people make an economic choice of whether to go on chain or not, and the vast majority of transactions, all told, are off-chain. Clearly it is ideal if they all go on chain, scale permitting. If we look at the roadmap at high-level: 1) bump (seg-wit or ...) 2) network improvements (IBLT/weak-block/other) 3) longer term dynamic block-size (flexcap) 4) write-cache (lightning) It would probably be good to see some work on preparing for fee markets. That has happened somewhat recently in response to the stress tests. We do have an observed problem that if there is no incentive to prepare, the improvements dont happen, and so we can never be ready for a fee market. That's kind of how we got here, people were talking about fee-estimation and dynamic fees several years ago before the block-size went from 250kB to 750kB, and then lost interest as there was another 500kB to play with. There could be a best practice doc written asking people to prepare. That might help. Presumably it's good if we do see the fee market more, for it to come in gradually. Flexcap probably helps there because the block-size itself becomes elastic to demand (pay for bigger blocks). If we want to avoid a fee market for the immediate term, are we more worried about period 1, or period 2 or 3. Probably 2 is more of a worry as we're scaling in 1 where in period 2 we're preparing for scaling and more time has passed for demand to grow. That might for example argue for seg-wit because it brings us closer to 4) and if we spread things out we might delay the possibility to do lightning as there is only so many cycles for forks (hard or soft) in testing, deployment planning etc so it can be good to have a holistic view. Also the question of time-frame that is safe for soft-forks or hard-forks is another input where views seem to vary. I think some people are more optimistic about being able to avoid people losing money in fast hard-forks. One lesson on users, is users find failure modes that testing cant, or do things you would expect them not to do. Also we're calling hard-forks things that are really soft-forks to SPV clients, and hard-forks only to full-nodes. If we wanted to make a real economic choice, we could artificially make an SPV hard-fork, however that would make upgrade harder. As I said in an earlier email I think everyone is empathetic to user requirements, including economic desires - but Bitcoin has inherent constraints that are complex to improve. Each proposal is trying to best meet those holistic user requirements. There are no free lunches and we dont want to economically hurt anyone in total or as a group or type of use. Not all requirements can be met, they are in a trade off, so that calls for balance, planning and transparency. This is also a market, we can discuss protocol tradeoffs without being melodramatic - would be kind of undesirable if a dramatic or emotive way to express something as easily or more clearly expressed in technical constructive words is moving the price around. Adam On 17 December 2015 at 03:58, Jeff Garzik via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote: > On Wed, Dec 16, 2015 at 9:44 PM, Eric Lombrozo <elombr...@gmail.com> wrote: >> >> At least SW *is* a scaling solution (albeit most of the important benefits >> are long term). The issue of fee events has nothing to do with scaling - it >> has to do with economics...specifically whether we should be subsidizing >> transactions, who should pay the bill for it, etc. My own personal opinion >> is that increasing validation costs works against adoption, not for >> it...even if it artificially keeps fees low - and we'll have to deal with a >> fee event sooner or later anyhow. You may disagree with my opinion, but >> please, let's stop confounding the economic issues with actual scaling. > > > At least on my part, the title of the 1st email was "It's economics & ..." > and focused on (a) economics and (b) transition issues. There was no > confounding. There was a list of real problems and risks taken when 1M is > not lifted in the short term. > > Thus "SW is orthogonal" in these emails, because these problems remain > regardless of SW or no, as the 1st email outlined. > > The 2nd email addresses the specific assertion of "no 1M hard fork needed, > because SW." > > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
