Re: [bitcoin-dev] Block size: It's economics & user preparation & moral hazard

On Wed, Dec 16, 2015 at 1:34 PM, Pieter Wuille wrote: > On Wed, Dec 16, 2015 at 3:53 PM, Jeff Garzik via bitcoin-dev > wrote: > > 2) If block size stays at 1M, the Bitcoin Core developer team should > sign a > > collective note

[bitcoin-dev] Segregated Witness in the context of Scaling Bitcoin

1. Summary Segregated Witness (SegWitness, SW) is being presented in the context of Scaling Bitcoin. It has useful attributes, notably addressing a major malleability vector, but is not a short term scaling solution. 2. Definitions Import Fee Event, ECE, TFM, FFM from previous email. Older

Re: [bitcoin-dev] Segregated Witness in the context of Scaling Bitcoin

A large part of your argument is that SW will take longer to deploy than a hard fork, but I completely disagree. Though I do not agree with some people claiming we can deploy SW significantly faster than a hard fork, once the code is ready (probably a six month affair) we can get it deployed

Re: [bitcoin-dev] Segregated Witness in the context of Scaling Bitcoin

On Wed, Dec 16, 2015 at 9:38 PM, Jeff Garzik via bitcoin-dev wrote: > 4.3. Observations on new block economic model > > SW complicates block economics by creating two separate, supply limited > resources. Not correct. I propose defining the

Re: [bitcoin-dev] Block size: It's economics & user preparation & moral hazard

On Wed, Dec 16, 2015 at 3:53 PM, Jeff Garzik via bitcoin-dev wrote: > 2) If block size stays at 1M, the Bitcoin Core developer team should sign a > collective note stating their desire to transition to a new economic policy, > that of "healthy fee market"

Re: [bitcoin-dev] Block size: It's economics & user preparation & moral hazard

I would also like to summarize my observation and thoughts after the Hong Kong workshop. 1. I'm so glad that I had this opportunity to meet so many smart developers who are dedicated to make Bitcoin better. Regular conference like this is very important for a young project, and it is

Re: [bitcoin-dev] Segregated Witness in the context of Scaling Bitcoin

On Wed, Dec 16, 2015 at 3:59 PM, Pieter Wuille wrote: > On Wed, Dec 16, 2015 at 9:38 PM, Jeff Garzik via bitcoin-dev > wrote: > > 4.3. Observations on new block economic model > > > > SW complicates block economics by creating two

Re: [bitcoin-dev] Block size: It's economics & user preparation & moral hazard

On Wed, Dec 16, 2015 at 4:24 PM, Jorge Timón wrote: > Assuming we adopt bip102, eventually you will be able to say exactly the > same about 2 MB. When does this "let's not change the economics" finishes > (if ever)? > The question is answered in the original email. In the

Re: [bitcoin-dev] Segregated Witness in the context of Scaling Bitcoin

We should probably start by defining "economically important". To me, it's pretty clear that every, or at least around 99% of, " economically important" node have upgraded by the time the fork kicks in, with way more than sufficient time given to everyone to upgrade (minding that this is not an

Re: [bitcoin-dev] Segregated Witness in the context of Scaling Bitcoin

As for "the ecosystem waiting around for laggards", yes, it is absolutely the ecosystems y responsibility to not take actions that will result in people losing money without providing them far more than enough opportunity to fix it. One of the absolute most important features of Bitcoin is

Re: [bitcoin-dev] Segregated Witness in the context of Scaling Bitcoin

On Wed, Dec 16, 2015 at 10:27 PM, Jeff Garzik wrote: >> Not correct. I propose defining the virtual_block_size as base_size + >> witness_size * 0.25, and limiting virtual_block_size to 1M. This >> creates a single variable to optimize for. If accepted, miners are >> incentived

Re: [bitcoin-dev] Segregated Witness in the context of Scaling Bitcoin

Maybe a new analogy helps. SW presents a blended price and blended basket of two goods. You can interact with the Service through the blended price, but that does not erase the fact that the basket contains two separate from similar resources. A different set of economic actors uses one

Re: [bitcoin-dev] Segregated Witness in the context of Scaling Bitcoin

On Wed, Dec 16, 2015 at 5:09 PM, Jeff Garzik wrote: > SW presents a blended price and blended basket of two goods. You can > interact with the Service through the blended price, but that does not > erase the fact that the basket contains two separate from similar resources. >

Re: [bitcoin-dev] Segregated Witness in the context of Scaling Bitcoin

There are no good short-term scaling solutions...this is a very hard problem that necessarily requires a lot of out-of-the-box thinking, something 2015 has seen a LOT of...and I'm optimistic about the ideas presented thus far. At least SW *is* a scaling solution (albeit most of the important

Re: [bitcoin-dev] Block size: It's economics & user preparation & moral hazard

On Wed, Dec 16, 2015 at 1:11 PM, Pieter Wuille via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > I indeed think we can communicate much better that deciding consensus > rules is not within our power. I'm not a core dev, so maybe I have the power to change the consensus rules. No

Re: [bitcoin-dev] Segregated Witness in the context of Scaling Bitcoin

There are at least 2 proposals on the table: 1. SWSF (segwit soft fork) with 1MB virtual block limit, approximately equals to 2MB actual limit 2. BIP102: 2MB actual limit Since the actual limits for both proposals are approximately the same, it is not a determining factor in this discussion

Re: [bitcoin-dev] Segregated Witness in the context of Scaling Bitcoin

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

Re: [bitcoin-dev] Segregated Witness in the context of Scaling Bitcoin

On Wed, Dec 16, 2015 at 10:36:09PM +0100, Pieter Wuille via bitcoin-dev wrote: > On Wed, Dec 16, 2015 at 10:27 PM, Jeff Garzik wrote: > >> Not correct. I propose defining the virtual_block_size as base_size + > >> witness_size * 0.25, and limiting virtual_block_size to 1M. This

Re: [bitcoin-dev] Segregated Witness in the context of Scaling Bitcoin

On Wed, Dec 16, 2015 at 3:50 PM, Matt Corallo wrote: > A large part of your argument is that SW will take longer to deploy than a > hard fork, but I completely disagree. Though I do not agree with some > people claiming we can deploy SW significantly faster than a hard

[bitcoin-dev] Block size: It's economics & user preparation & moral hazard

All, Following the guiding WP principle of Assume Good Faith, I've been trying to boil down the essence of the message following Scaling Bitcoin. There are key bitcoin issues that remain outstanding and pressing, that are* orthogonal to LN & SW*. I create multiple proposals and try multiple