Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id B7F05E98 for ; Thu, 17 Dec 2015 03:48:31 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mout.perfora.net (mout.perfora.net [74.208.4.197]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 0259F125 for ; Thu, 17 Dec 2015 03:48:30 +0000 (UTC) Received: from mail-io0-f181.google.com ([209.85.223.181]) by mrelay.perfora.net (mreueus003) with ESMTPSA (Nemesis) id 0LzqsP-1aDh4Y40fb-0154zN for ; Thu, 17 Dec 2015 04:48:30 +0100 Received: by mail-io0-f181.google.com with SMTP id e126so42255401ioa.1 for ; Wed, 16 Dec 2015 19:48:29 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.107.13.139 with SMTP id 133mr20306224ion.70.1450324109365; Wed, 16 Dec 2015 19:48:29 -0800 (PST) Received: by 10.36.49.200 with HTTP; Wed, 16 Dec 2015 19:48:29 -0800 (PST) In-Reply-To: References: <49257841-66C8-4EF7-980B-73DC604CA591@mattcorallo.com> Date: Thu, 17 Dec 2015 04:48:29 +0100 X-Gmail-Original-Message-ID: Message-ID: From: Adam Back To: Jeff Garzik Content-Type: text/plain; charset=UTF-8 X-Provags-ID: V03:K0:VyINXz3PMiYQD2XRXKcIjZ2RJEB/qrAFnpgrZvrWSrnZOHCyyUX nxfDs1LqC7fBEi4bMc9f91nkQLQtWLUvmRqptYEpbhP1khJcTBqm1ZzO5DhFU3u/HXma1eR 6C9dKk3prsdeCFYQ74KogtY9+/Fx/YfLvwOSKkq6XGb/Bt9H2t8HBMANsiYXkLKbeObIkLJ SsQlVAJz3UBdJBwehEdwA== X-UI-Out-Filterresults: notjunk:1;V01:K0:jKAdP0LDvlA=:6HTHhQiECWiYPXtqGYs024 e9nTbGt4g/F2ZSN3GQ21WsEa4OkHsXyZKPe77sBc0/BT42QAQA8Vy4pnoe0psZR3jPUvhxVw2 DIMcYfoohDxFXzuHyEiNBvRWKTIrCF4T51SsK+IpgmShCsv2iUgNPuI8avCgM2YKC2EwM4mOy fP36aFXeejldZngb8dWVt40ZiWnKP4tMQs9oJmGjZnUO4wEbroGodU6E3PfzGkHtywXW12FFN WaX5GQyE37G6bwtzIc9sVa1kz+YrM2Zf0C6yCDqe09y3WG46IqK31mOl3A1G6OOPzxgKsrNif EWfl7K9UOQcMI4Pj/dquRra0lczzWZ/e9Lqt+tyUTb0QgnT3OIp6J1TqraAI0YEjr4z9Ew0u6 dMfnoeyrXf5ZYilnuuAwfW/U24sGbXElSQKFcMZQsUIX9vVEtyP6/sCuQcxAwBIsBdt6t77MN zsf6Br9KAmZsk9L7+rgzeBHpQeIS9wr2pwFkQiXM9woRLcaKrDh4ANYbbcBJFCdesv80sfKTe E4OgMyt2/lBOVEcSzOAzlhRIwCRRdNIWSokxRIfFBSb8/cqSF/NKFMian74N/W5c3UZafJ5xA kT40krPVZmM4jR0W0lBJG8b7Yzz/J0lx2GbEIb7UEp3/B0yaD+WSLZJnpTSdEwbpwuQXpaYSd GUE+JLgIHkaqnmZ/ESbtvG1A/mk2npKyQPp45MaCGvHLrRLIBWskjNOsFRceHf3lHx6nurZlO ggV00uFuM5s91X6L X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: Jeff Garzik via bitcoin-dev Subject: Re: [bitcoin-dev] Segregated Witness in the context of Scaling Bitcoin X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2015 03:48:31 -0000 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 wrote: > On Wed, Dec 16, 2015 at 9:44 PM, Eric Lombrozo 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 >