Jeff Garzik [ARCHIVE] on Nostr: š Original date posted:2015-12-18 š Original message:On Wed, Dec 16, 2015 at ...
š
Original date posted:2015-12-18
š Original message:On Wed, Dec 16, 2015 at 1:34 PM, Pieter Wuille <pieter.wuille at gmail.com>
wrote:
> On Wed, Dec 16, 2015 at 3:53 PM, Jeff Garzik via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> 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" and strongly urge users to examine their fee
> > policies, wallet software, transaction volumes and other possible User
> > impacting outcomes.
>
> You present this as if the Bitcoin Core development team is in charge
> of deciding the network consensus rules, and is responsible for making
> changes to it in order to satisfy economic demand. If that is the
> case, Bitcoin has failed, in my opinion.
>
Diverging from the satoshi block size change plan[1] and current economics
would seem to require a high level of months-ahead communication to users.
> all. Yes, old full nodes after a soft fork are not able to fully
> validate the rules new miners enforce anymore, but they do still
> verify the rules that their operators opted to enforce. Furthermore,
> they can't be prevented. For that reason, I've proposed, and am
> working hard, on an approach that includes Segregated Witness as a
> first step. It shows the ecosystem that something is being done, it
> kicks the can down the road, it solves/issues half a dozen other
> issues at the same time, and it does not require the degree of
> certainty needed for a hardfork.
>
Segregated Witness does not kick the can, it solves none of the problems
#1, #3 - #8 explicitly defined and listed in email #1.
1) A plan of "SW + no hard fork" is gambling with ECE risk, gambling there
will be no Fee Event, because the core block size is still heavily
contended -- 100% contended at time out SW rollout.
2) We are only 100% certain that bitcoin works in the
blocks-not-full-on-avg state, where there is a healthy buffer between the
hard limit and the average block size.
There is remains major ECE risk due to the core block size freeze, possibly
pushing the system into a new, untried economic state and causing major
market and actor disruption. Users of the Service can still drift randomly
and unpredictably into a Fee Event.
SW mitigates this
- only after several months
- only assuming robust adoption rates by up-layer ecosystem software, and
- only assuming transaction volume growth is flat or sub-linear
Those conditions *must* go as planned to fulfill "SW kicked the can" -- a
lot of if's.
As stated, SW is orthogonal to the drift-into-uncharted-waters problem
outlined in email #1, which a short term bump does address.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151218/df9746ce/attachment.html>;
š Original message:On Wed, Dec 16, 2015 at 1:34 PM, Pieter Wuille <pieter.wuille at gmail.com>
wrote:
> On Wed, Dec 16, 2015 at 3:53 PM, Jeff Garzik via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> 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" and strongly urge users to examine their fee
> > policies, wallet software, transaction volumes and other possible User
> > impacting outcomes.
>
> You present this as if the Bitcoin Core development team is in charge
> of deciding the network consensus rules, and is responsible for making
> changes to it in order to satisfy economic demand. If that is the
> case, Bitcoin has failed, in my opinion.
>
Diverging from the satoshi block size change plan[1] and current economics
would seem to require a high level of months-ahead communication to users.
> all. Yes, old full nodes after a soft fork are not able to fully
> validate the rules new miners enforce anymore, but they do still
> verify the rules that their operators opted to enforce. Furthermore,
> they can't be prevented. For that reason, I've proposed, and am
> working hard, on an approach that includes Segregated Witness as a
> first step. It shows the ecosystem that something is being done, it
> kicks the can down the road, it solves/issues half a dozen other
> issues at the same time, and it does not require the degree of
> certainty needed for a hardfork.
>
Segregated Witness does not kick the can, it solves none of the problems
#1, #3 - #8 explicitly defined and listed in email #1.
1) A plan of "SW + no hard fork" is gambling with ECE risk, gambling there
will be no Fee Event, because the core block size is still heavily
contended -- 100% contended at time out SW rollout.
2) We are only 100% certain that bitcoin works in the
blocks-not-full-on-avg state, where there is a healthy buffer between the
hard limit and the average block size.
There is remains major ECE risk due to the core block size freeze, possibly
pushing the system into a new, untried economic state and causing major
market and actor disruption. Users of the Service can still drift randomly
and unpredictably into a Fee Event.
SW mitigates this
- only after several months
- only assuming robust adoption rates by up-layer ecosystem software, and
- only assuming transaction volume growth is flat or sub-linear
Those conditions *must* go as planned to fulfill "SW kicked the can" -- a
lot of if's.
As stated, SW is orthogonal to the drift-into-uncharted-waters problem
outlined in email #1, which a short term bump does address.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151218/df9746ce/attachment.html>;