A couple observations:
- The consensus block limit is different than the disk space required to
do validation. Some participants are worried about one and some about the
other, and sometimes they feel what amounts to an imaginary contention
because they perceive these two different th
Not entirely correct, no. Edge cases also matter. Segwit is described as
4MB because that is the largest possible combined block size that can be
constructed. BIP 102 + segwit would allow a maximum relay of 8MB. So you
have to be confident that an 8MB relay size would be acceptable, even if a
block
Anthony,
On Thu, Dec 17, 2015 at 6:55 PM, Anthony Towns via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> On Thu, Dec 17, 2015 at 04:51:19PM +0100, sickpig--- via bitcoin-dev wrote:
> > On Thu, Dec 17, 2015 at 2:09 PM, Jorge Timón wrote:
> > > Unless I'm missing something, 2 mb x
While it is interesting to contemplate moving to a world with
hard-fork only upgrades (deprecate soft-forks), now is possibly not
the time to consider that. Someone can take that topic and make a
what-if sketch for how it could work and put it on the wishlist wiki
if its not already there.
We wan
Doesn't a good soft fork signaling mechanism along with an activation warning
system for non-upgraded nodes (i.e. BIP9, or even block version ISM for that
matter) essentially fix this? I don't quite get why this should be an issue.
On December 17, 2015 10:52:39 AM PST, Jeff Garzik via bitcoin-de
This is not correct.
As only about 1/3 of nodes support BIP65 now, would you consider CLTV tx
are less secure than others? I don't think so. Since one invalid CLTV tx
will make the whole block invalid. Having more nodes to fully validate
non-CLTV txs won't make them any safer. The same logic a
On Thu, Dec 17, 2015 at 1:46 PM, jl2012 wrote:
> This is not correct.
>
> As only about 1/3 of nodes support BIP65 now, would you consider CLTV tx
> are less secure than others? I don't think so. Since one invalid CLTV tx
> will make the whole block invalid. Having more nodes to fully validate
>
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.
>
> A different set o
On Thu, Dec 17, 2015 at 04:51:19PM +0100, sickpig--- via bitcoin-dev wrote:
> On Thu, Dec 17, 2015 at 2:09 PM, Jorge Timón wrote:
> > Unless I'm missing something, 2 mb x4 = 8mb, so bip102 + SW is already
> > equivalent to the 2-4-8 "compromise" proposal [...]
> isn't SegWit gain ~75%? hence 2mb x
On Thu, Dec 17, 2015 at 2:09 PM, Jorge Timón <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> Unless I'm missing something, 2 mb x4 = 8mb, so bip102 + SW is already
> equivalent to the 2-4-8 "compromise" proposal (which by the way I never
> liked, because I don't think anybody should be in a po
Although I agree that how safe a pre-hardfork upgrade period is depends on
the complexity of the changes (we should assume everyone may need time to
reimplementat it themselves in their own implementations, not just upgrade
bitcoin core) and bip102 is indeed a very simple hardfork, I think less
tha
A planned hardfork, similar to certain softforks, leaves users with some
reduction in security. It does not leave them defenseless. Consider the
following:
1: Hard to be robbed on the basis of hashpower.
In reality the old chain will see mining all but stop, and blocks would be
hours to days ap
On Wed, Dec 16, 2015 at 12:50 PM, Matt Corallo via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> 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 sig
I know my reply is a long one but please read before you hit send. I
have 2 proposals: fast BIP102 + slow SWSF and fast SWSF only. I guess no
one here is arguing for not doing segwit; and it is on the top of my
wish list. My main argument (maybe also Jeff's) is that segwit is too
complicated an
Maybe we should first gather concrete estimates about and roughly agree on
- how long SW (SF) development will probably take
- how long the ecosystem needs to prepare for a hardfork (SW (HF) or a
simple can kicking block size increase)
Opinions differ wildly from what it looks like, but maybe we
On Thu, Dec 17, 2015 at 12:32:11AM -0500, jl2012 via bitcoin-dev wrote:
> 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
I think there's a few variants of (2) -- the
There are many reasons to support segwit beyond it being a soft-fork. For
example:
* the limitation of non-witness data to no more than 1MB makes the
quadratic scaling costs in large transaction validation no worse than they
currently are;
* redeem scripts in witness use a more accurate cost accou
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
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
> >> creates a sing
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 assump
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
> transaction
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 ben
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 fork,
> once the code is re
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 that,
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
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.
>
separate-but-simil
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 resource
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 to maximize fee per
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 separate, supply limited
> > resources.
>
> Not correct. I propo
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 virtual_block_size as base_size +
witness_size * 0.25,
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 ver
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 cl
32 matches
Mail list logo
