[bitcoin-dev] I do not support the BIP 148 UASF

[bitcoin-dev] I do not support the BIP 148 UASF

[Gregory Maxwell]

I do not support the BIP148 UASF for some of the same reasons that I
do support segwit:  Bitcoin is valuable in part because it has high
security and stability, segwit was carefully designed to support and
amplify that engineering integrity that people can count on now and
into the future.

I do not feel the the approach proposed in BIP148 really measures up
to the standard set by segwit itself, or the existing best practices
in protocol development in this community.

The primary flaw in BIP148 is that by forcing the activation of the
existing (non-UASF segwit) nodes it almost guarantees at a minor level
of disruption.

Segwit was carefully engineered so that older unmodified miners could
continue operating _completely_ without interruption after segwit
activates.

Older nodes will not include segwit spends, and so their blocks will
not be invalid even if they do not have segwit support. They can
upgrade to it on their own schedule. The only risk non-participating
miners take after segwit activation is that if someone else mines an
invalid block they would extend it, a risk many miners already
frequently take with spy-mining.

I do not think it is a horrible proposal: it is better engineered than
many things that many altcoins do, but just not up to our normal
standards. I respect the motivations of the authors of BIP 148.  If
your goal is the fastest possible segwit activation then it is very
useful to exploit the >80% of existing nodes that already support the
original version of segwit.

But the fastest support should not be our goal, as a community-- there
is always some reckless altcoin or centralized system that can support
something faster than we can-- trying to match that would only erode
our distinguishing value in being well engineered and stable.

"First do no harm." We should use the least disruptive mechanisms
available, and the BIP148 proposal does not meet that test.  To hear
some people-- non-developers on reddit and such-- a few even see the
forced orphaning of 148 as a virtue, that it's punitive for
misbehaving miners. I could not not disagree with that perspective any
more strongly.

Of course, I do not oppose the general concept of a UASF but
_generally_ a soft-fork (of any kind) does not need to risk disruption
of mining, just as segwit's activation does not.  UASF are the
original kind of soft-fork and were the only kind of fork practiced by
Satoshi. P2SH was activated based on a date, and all prior ones were
based on times or heights.  We introduced miner based activation as
part of a process of making Bitcoin more stable in the common case
where the ecosystem is all in harmony.  It's kind of weird to see UASF
portrayed as something new.

It's important the users not be at the mercy of any one part of the
ecosystem to the extent that we can avoid it-- be it developers,
exchanges, chat forums, or mining hardware makers.  Ultimately the
rules of Bitcoin work because they're enforced by the users
collectively-- that is what makes Bitcoin Bitcoin, it's what makes it
something people can count on: the rules aren't easy to just change.

There have been some other UASF proposals that avoid the forced
disruption-- by just defining a new witness bit and allowing
non-upgraded-to-uasf miners and nodes to continue as non-upgraded, I
think they are vastly superior. They would be slower to deploy, but I
do not think that is a flaw.

We should have patience. Bitcoin is a system that should last for all
ages and power mankind for a long time-- ten years from now a couple
years of dispute will seem like nothing. But the reputation we earn
for stability and integrity, for being a system of money people can
count on will mean everything.

If these discussions come up, they'll come up in the form of reminding
people that Bitcoin isn't easily changed at a whim, even when the
whims are obviously good, and how that protects it from being managed
like all the competing systems of money that the world used to use
were managed. :)

So have patience, don't take short cuts.  Segwit is a good improvement
and we should respect it by knowing that it's good enough to wait for,
and for however its activated to be done the best way we know how.

Re: [bitcoin-dev] I do not support the BIP 148 UASF

[praxeology_guy]

[-- Attachment #1: Type: text/plain, Size: 1609 bytes --]

Gregory Maxwell,

Criticizing 148 without suggesting a specific alternative leaves the community in disarray.

I know you are emphasizing patience. But at the same time, with your patience we are allowing ourselves to get dicked for longer than necessary.

I think that core could easily develop code that could create a solid/reliable date/height based activation to allow miners to create SegWit block candidates and having nodes fully verify them. Shaolinfry is the only person Ive seen actually make such a proposal: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-April/014049.html. His makes it so that SegWit default gets activated at the end of the BIP9 signalling timeframe instead of default leaving it non-activated.

I agree that 148 is is not ideal. Non-SegWit signaling blocks are not a Denial of Service, given that other activation methods are available. Someone just needs to code something up that is better that we can all use in a satisfying time frame. So far 148 is the most practical and reliable method I'm aware of.

If 148 causes orphaning and a fork, I don't think such really matters in the long term. The non-SegWit miners will probably just quickly give up their orphans once they realize that money users like being able to have non-mutable TX IDs. If they do create a long lasting branch... well that is good too, I'd be happy to no longer have them in our community. Good luck to them in creating a competitive money, so that we can all enjoy lower transaction fees.

SegWit has already undergone enough testing. It is time to activate it.

Cheers,
Praxeology Guy

[-- Attachment #2: Type: text/html, Size: 1988 bytes --]

Re: [bitcoin-dev] I do not support the BIP 148 UASF

[Chris Stewart]

[-- Attachment #1: Type: text/plain, Size: 3194 bytes --]

>Criticizing 148 without suggesting a specific alternative leaves the
community in disarray.

I really disagree with this sentiment, you don't need to provide
alternatives to criticize a technical proposal. I don't like this "active
segwit at all costs" theme that has been going around the community. I am a
fan of segwit, but we shouldn't push things through in an unsafe manner.

>If 148 causes orphaning and a fork, I don't think such really matters in
the long term.  The non-SegWit miners will probably just quickly give up
their orphans once they realize that money users like being able to have
non-mutable TX IDs.  If they do create a long lasting branch... well that
is good too, I'd be happy to no longer have them in our community.  Good
luck to them in creating a competitive money, so that we can all enjoy
lower transaction fees.

This seems like a lot of reckless hand waving to me.

Food for thought, why are we rejecting *all* blocks that do not signal
segwit? Can't we just reject blocks that *do not* signal segwit, but *do*
contain segwit transactions? It seems silly to me that if a miner mines a
block with all pre segwit txs to reject that block. Am I missing something
here?

-Chris

On Fri, Apr 14, 2017 at 11:50 AM, praxeology_guy via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Gregory Maxwell,
>
> Criticizing 148 without suggesting a specific alternative leaves the
> community in disarray.
>
> I know you are emphasizing patience.  But at the same time, with your
> patience we are allowing ourselves to get dicked for longer than necessary.
>
> I think that core could easily develop code that could create a
> solid/reliable date/height based activation to allow miners to create
> SegWit block candidates and having nodes fully verify them.  Shaolinfry is
> the only person Ive seen actually make such a proposal:
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/
> 2017-April/014049.html.  His makes it so that SegWit default gets
> activated at the end of the BIP9 signalling timeframe instead of default
> leaving it non-activated.
>
> I agree that 148 is is not ideal.  Non-SegWit signaling blocks are not a
> Denial of Service, given that other activation methods are available.
> Someone just needs to code something up that is better that we can all use
> in a satisfying time frame.  So far 148 is the most practical and reliable
> method I'm aware of.
>
> If 148 causes orphaning and a fork, I don't think such really matters in
> the long term.  The non-SegWit miners will probably just quickly give up
> their orphans once they realize that money users like being able to have
> non-mutable TX IDs.  If they do create a long lasting branch... well that
> is good too, I'd be happy to no longer have them in our community.  Good
> luck to them in creating a competitive money, so that we can all enjoy
> lower transaction fees.
>
> SegWit has already undergone enough testing.  It is time to activate it.
>
> Cheers,
> Praxeology Guy
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

[-- Attachment #2: Type: text/html, Size: 4147 bytes --]

Re: [bitcoin-dev] I do not support the BIP 148 UASF

[praxeology_guy]

[-- Attachment #1: Type: text/plain, Size: 1542 bytes --]

Chris,

>Food for thought, why are we rejecting *all* blocks that do not signal segwit? Can't we just reject blocks that *do not* signal segwit, but *do* contain segwit transactions? It seems silly to me that if a miner mines a block with all pre segwit txs to reject that block. Am I missing something here?

If you read my email, you will see that I am requesting that gmaxwell or someone code up an alternative that doesn't unnecessarily orphan blocks, just as you are requesting.

> Re: old blocks containing SegWit transactions
From my understanding, old blocks can contain txos w/ the new SegWit format. But if transaction tries to spend a new SegWit format txo in an old block, such would already break protocol rules, particularly for SegWit activated nodes. And old nodes don't have code that even knows how to spend SegWit format txos. Worst case, such may lead to a fork if <= 50% of the miners are verifying SegWit blocks.

> Re: Reckless hand waving:
Maybe first you need to prove that forks are necessarily bad for our long term success. How much do we need to be getting delayed in rolling out new good policy before we come to consensus on forking from the delayers?

The operating assumption of 148 is that no matter what we are going to fork. So might as well do it then in a controlled manner instead of later when someone creates an invalid SegWit block. Then my only recommendation would be to also implement a boilerplate replay attack prevention just in case the SegWit delayers aren't bluffing.

Cheers,
Praxeology Guy

[-- Attachment #2: Type: text/html, Size: 1814 bytes --]

Re: [bitcoin-dev] I do not support the BIP 148 UASF

[Tom Zander]

On Friday, 14 April 2017 18:50:47 CEST praxeology_guy via bitcoin-dev wrote:
> Criticizing 148 without suggesting a specific alternative leaves the
> community in disarray.

Here is a list of clear alternatives;

https://github.com/bitcoin/bips/

See the BIPs with number 010[1-8].

-- 
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel

Re: [bitcoin-dev] I do not support the BIP 148 UASF

[Tom Zander]

On Friday, 14 April 2017 09:56:31 CEST Gregory Maxwell via bitcoin-dev 
wrote:
> Segwit was carefully engineered so that older unmodified miners could
> continue operating _completely_ without interruption after segwit
> activates.


> They [Older nodes] can
> upgrade to it [segwit] on their own schedule. The only risk 
> non-participating
> miners take after segwit activation is that if someone else mines an
> invalid block they would extend it,

This is false,

a segwit transaction to the miner you describe is an "everyone can spend" 
transaction, and as such a miner that does not validate the segregated area 
in a post-segwit world will be able to create blocks that will not validate 
for segwit miners by including a transaction that spends a SW tx.

This would then lead to a chain-fork as the SW miners reject it and the non-
SW miners continue to mine on it.


-- 
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel

Re: [bitcoin-dev] I do not support the BIP 148 UASF

[James Hilliard]

On Fri, Apr 14, 2017 at 2:20 PM, Tom Zander via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> On Friday, 14 April 2017 09:56:31 CEST Gregory Maxwell via bitcoin-dev
> wrote:
>> Segwit was carefully engineered so that older unmodified miners could
>> continue operating _completely_ without interruption after segwit
>> activates.
>
>
>> They [Older nodes] can
>> upgrade to it [segwit] on their own schedule. The only risk
>> non-participating
>> miners take after segwit activation is that if someone else mines an
>> invalid block they would extend it,
>
> This is false,
>
> a segwit transaction to the miner you describe is an "everyone can spend"
> transaction, and as such a miner that does not validate the segregated area
> in a post-segwit world will be able to create blocks that will not validate
> for segwit miners by including a transaction that spends a SW tx.
>
> This would then lead to a chain-fork as the SW miners reject it and the non-
> SW miners continue to mine on it.

This is false,

Those "everyone can spend" transactions are prohibited from being
mined due to policy rules. The risk is only in regards to mining on
top of an invalid block that intentionally mined an invalid SW
transaction.
>
>
> --
> Tom Zander
> Blog: https://zander.github.io
> Vlog: https://vimeo.com/channels/tomscryptochannel
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] I do not support the BIP 148 UASF

[Tom Zander]

On Friday, 14 April 2017 21:33:49 CEST James Hilliard wrote:
> This is false,
> 
> Those "everyone can spend" transactions are prohibited from being
> mined due to policy rules.

I expected you to know this, but ok, I'll explain.

A policy rule is not a protocol rule, a mining node is certainly not 
guarenteet to have it, and those that do typically make it configurable.

If you depend on one implementation and user configuration for the avoidance 
of chain forks, you are going to have a hard time.

Thanks for your thoughtful reply, though.
-- 
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel

Re: [bitcoin-dev] I do not support the BIP 148 UASF

[James Hilliard]

On Fri, Apr 14, 2017 at 3:34 PM, Tom Zander <tomz@freedommail.ch> wrote:
> On Friday, 14 April 2017 21:33:49 CEST James Hilliard wrote:
>> This is false,
>>
>> Those "everyone can spend" transactions are prohibited from being
>> mined due to policy rules.
>
> I expected you to know this, but ok, I'll explain.
>
> A policy rule is not a protocol rule, a mining node is certainly not
> guarenteet to have it, and those that do typically make it configurable.
Yes one can override policy rules and mine invalid SW transactions,
but that's not something that's likely to happen accidentally.
>
> If you depend on one implementation and user configuration for the avoidance
> of chain forks, you are going to have a hard time.
We don't depend on policy to avoid chain forks, policy however is
quite useful for making forks smoother since it can prevent miners
from accidentally mining invalid blocks and prevents users from
accepting invalid transactions accidentally.
This doesn't remove the need for consensus rule enforcement of course.
>
> Thanks for your thoughtful reply, though.
> --
> Tom Zander
> Blog: https://zander.github.io
> Vlog: https://vimeo.com/channels/tomscryptochannel

Re: [bitcoin-dev] I do not support the BIP 148 UASF

[Tom Zander]

On Friday, 14 April 2017 22:51:04 CEST James Hilliard wrote:
> This doesn't remove the need for consensus rule enforcement of course.

Thanks for confirming my point.

This means that Gregory was incorrect saying that there is no risk to a non-
upgraded node on a SegWit network mining a new invalid block. That risk is 
most definitely there for any miners "left behind" operating on a different 
set of consensus rules than the majority.

Kind of obvious, when you think about it.

-- 
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel

Re: [bitcoin-dev] I do not support the BIP 148 UASF

[James Hilliard]

On Fri, Apr 14, 2017 at 3:58 PM, Tom Zander via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> On Friday, 14 April 2017 22:51:04 CEST James Hilliard wrote:
>> This doesn't remove the need for consensus rule enforcement of course.
>
> Thanks for confirming my point.
>
> This means that Gregory was incorrect saying that there is no risk to a non-
> upgraded node on a SegWit network mining a new invalid block. That risk is
> most definitely there for any miners "left behind" operating on a different
> set of consensus rules than the majority.
Greg is correct. There is effectively no risk to a non-upgrade
accidentally mining a new invalid block itself, the only risk is that
a non-upgraded miner could itself mine on top of an invalid block. You
would have to intentionally modify the code to mine an invalid block
which is not something that would be likely to happen accidentally.
>
> Kind of obvious, when you think about it.
>
> --
> Tom Zander
> Blog: https://zander.github.io
> Vlog: https://vimeo.com/channels/tomscryptochannel
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] I do not support the BIP 148 UASF

[Gregory Maxwell]

On Fri, Apr 14, 2017 at 9:10 PM, James Hilliard via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> would have to intentionally modify the code to mine an invalid block
> which is not something that would be likely to happen accidentally.

IIRC-- If you do it accidentally you'll fail the tests, though there
have been a couple reckless alternative implementations that have just
ripped out most of the tests...

In any case there is no need to speculate or guess-- invalid segwit
spends are not being mined today...

Re: [bitcoin-dev] I do not support the BIP 148 UASF

[Gregory Maxwell]

On Fri, Apr 14, 2017 at 8:34 PM, Tom Zander via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> I expected you to know this, but ok, I'll explain.

Please stop abusing participants on this list. Your activity is
actively driving people off this list.

James Hilliard should be commended for correcting your misinformation.

> If you depend on one implementation and user configuration for the avoidance
> of chain forks, you are going to have a hard time.

Anyone can modify their software to produce invalid blocks at any
time. If they want to be stupid, they can be stupid.

The fact remains that miners who haven't gone and wreaked their
software internals will not mine segwit incompatible blocks. Right now
_no_ observable has broken node in this way.

Re: [bitcoin-dev] I do not support the BIP 148 UASF

[Steven Pine]

[-- Attachment #1: Type: text/plain, Size: 6459 bytes --]

> Segwit is a good improvement
and we should respect it by knowing that it's good enough to wait for,
and for however its activated to be done the best way we know how.

Regarding this last point I was under the impression that if Segwit did not
activate by November then core was going to move on, is that no longer the
case, does the core team plan on trying to activate Segwit in some other
way?

I am also curious, but has there been a softfork, hardfork, or other major
census change that was not rolled out and done by the core team? I only
mention this because BIP148, if it goes ahead (and is successful), would be
the first time a consensus change occurs outside of the core developers --
but again I am not an expert on the history of changes and could be wrong,
I only bring this up because core developers have in the past stressed they
are a part of the bitcoin ecosystem and not the drivers of it (at least
that is the ideal it seems).

My impression is that the community is ready for this and wants it, and if
that impression is correct it will go ahead. No one knows the future, and
simply assuming it's better to be slow and methodical isn't especially
convincing. Technology is in someways the history of failure, we like to
celebrate the seemingly sudden breakthroughs and successes but it's rare
that the original innovator retains a monopoly on their invention, more
often it becomes quickly refined and iterated upon as market forces take
hold to bring costs down and other external political issues
take precedence, all this is say that in ten years everyone could be
chuckling over the 3 year bitcoin scaling debate, or they could be using
litecoin, or ethereum or some other crypto coin, or something entirely
different, no one knows.

On Fri, Apr 14, 2017 at 3:56 AM, Gregory Maxwell via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> I do not support the BIP148 UASF for some of the same reasons that I
> do support segwit:  Bitcoin is valuable in part because it has high
> security and stability, segwit was carefully designed to support and
> amplify that engineering integrity that people can count on now and
> into the future.
>
> I do not feel the the approach proposed in BIP148 really measures up
> to the standard set by segwit itself, or the existing best practices
> in protocol development in this community.
>
> The primary flaw in BIP148 is that by forcing the activation of the
> existing (non-UASF segwit) nodes it almost guarantees at a minor level
> of disruption.
>
> Segwit was carefully engineered so that older unmodified miners could
> continue operating _completely_ without interruption after segwit
> activates.
>
> Older nodes will not include segwit spends, and so their blocks will
> not be invalid even if they do not have segwit support. They can
> upgrade to it on their own schedule. The only risk non-participating
> miners take after segwit activation is that if someone else mines an
> invalid block they would extend it, a risk many miners already
> frequently take with spy-mining.
>
> I do not think it is a horrible proposal: it is better engineered than
> many things that many altcoins do, but just not up to our normal
> standards. I respect the motivations of the authors of BIP 148.  If
> your goal is the fastest possible segwit activation then it is very
> useful to exploit the >80% of existing nodes that already support the
> original version of segwit.
>
> But the fastest support should not be our goal, as a community-- there
> is always some reckless altcoin or centralized system that can support
> something faster than we can-- trying to match that would only erode
> our distinguishing value in being well engineered and stable.
>
> "First do no harm." We should use the least disruptive mechanisms
> available, and the BIP148 proposal does not meet that test.  To hear
> some people-- non-developers on reddit and such-- a few even see the
> forced orphaning of 148 as a virtue, that it's punitive for
> misbehaving miners. I could not not disagree with that perspective any
> more strongly.
>
> Of course, I do not oppose the general concept of a UASF but
> _generally_ a soft-fork (of any kind) does not need to risk disruption
> of mining, just as segwit's activation does not.  UASF are the
> original kind of soft-fork and were the only kind of fork practiced by
> Satoshi. P2SH was activated based on a date, and all prior ones were
> based on times or heights.  We introduced miner based activation as
> part of a process of making Bitcoin more stable in the common case
> where the ecosystem is all in harmony.  It's kind of weird to see UASF
> portrayed as something new.
>
> It's important the users not be at the mercy of any one part of the
> ecosystem to the extent that we can avoid it-- be it developers,
> exchanges, chat forums, or mining hardware makers.  Ultimately the
> rules of Bitcoin work because they're enforced by the users
> collectively-- that is what makes Bitcoin Bitcoin, it's what makes it
> something people can count on: the rules aren't easy to just change.
>
> There have been some other UASF proposals that avoid the forced
> disruption-- by just defining a new witness bit and allowing
> non-upgraded-to-uasf miners and nodes to continue as non-upgraded, I
> think they are vastly superior. They would be slower to deploy, but I
> do not think that is a flaw.
>
> We should have patience. Bitcoin is a system that should last for all
> ages and power mankind for a long time-- ten years from now a couple
> years of dispute will seem like nothing. But the reputation we earn
> for stability and integrity, for being a system of money people can
> count on will mean everything.
>
> If these discussions come up, they'll come up in the form of reminding
> people that Bitcoin isn't easily changed at a whim, even when the
> whims are obviously good, and how that protects it from being managed
> like all the competing systems of money that the world used to use
> were managed. :)
>
> So have patience, don't take short cuts.  Segwit is a good improvement
> and we should respect it by knowing that it's good enough to wait for,
> and for however its activated to be done the best way we know how.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>



-- 
Steven Pine
(510) 517-7075

[-- Attachment #2: Type: text/html, Size: 8111 bytes --]

Re: [bitcoin-dev] I do not support the BIP 148 UASF

[Chris Stewart]

[-- Attachment #1: Type: text/plain, Size: 7680 bytes --]

>Regarding this last point I was under the impression that if Segwit did
not activate by November then core was going to move on, is that no longer
the case, does the core team plan on trying to activate Segwit in some
other way?

Since block size seems to be the controversial issue, AFAIK we *could*
remove the block size increase (by removing the discount on signature
data). This discount was put in place for two reasons

1.) It allows for a block size increase
2.) It makes it more expensive to create UTXOs. UTXO bloat is a problem on
the bitcoin network and segwit was an elegant way to make the network
appreciate their real cost in terms of hardware/RAM.

We would still get the benefits of:
1.) Tx malleability elimination
2.) Script versioning

-Chris

On Fri, Apr 14, 2017 at 9:01 PM, Steven Pine via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> > Segwit is a good improvement
> and we should respect it by knowing that it's good enough to wait for,
> and for however its activated to be done the best way we know how.
>
> Regarding this last point I was under the impression that if Segwit did
> not activate by November then core was going to move on, is that no longer
> the case, does the core team plan on trying to activate Segwit in some
> other way?
>
> I am also curious, but has there been a softfork, hardfork, or other major
> census change that was not rolled out and done by the core team? I only
> mention this because BIP148, if it goes ahead (and is successful), would be
> the first time a consensus change occurs outside of the core developers --
> but again I am not an expert on the history of changes and could be wrong,
> I only bring this up because core developers have in the past stressed they
> are a part of the bitcoin ecosystem and not the drivers of it (at least
> that is the ideal it seems).
>
> My impression is that the community is ready for this and wants it, and if
> that impression is correct it will go ahead. No one knows the future, and
> simply assuming it's better to be slow and methodical isn't especially
> convincing. Technology is in someways the history of failure, we like to
> celebrate the seemingly sudden breakthroughs and successes but it's rare
> that the original innovator retains a monopoly on their invention, more
> often it becomes quickly refined and iterated upon as market forces take
> hold to bring costs down and other external political issues
> take precedence, all this is say that in ten years everyone could be
> chuckling over the 3 year bitcoin scaling debate, or they could be using
> litecoin, or ethereum or some other crypto coin, or something entirely
> different, no one knows.
>
> On Fri, Apr 14, 2017 at 3:56 AM, Gregory Maxwell via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> I do not support the BIP148 UASF for some of the same reasons that I
>> do support segwit:  Bitcoin is valuable in part because it has high
>> security and stability, segwit was carefully designed to support and
>> amplify that engineering integrity that people can count on now and
>> into the future.
>>
>> I do not feel the the approach proposed in BIP148 really measures up
>> to the standard set by segwit itself, or the existing best practices
>> in protocol development in this community.
>>
>> The primary flaw in BIP148 is that by forcing the activation of the
>> existing (non-UASF segwit) nodes it almost guarantees at a minor level
>> of disruption.
>>
>> Segwit was carefully engineered so that older unmodified miners could
>> continue operating _completely_ without interruption after segwit
>> activates.
>>
>> Older nodes will not include segwit spends, and so their blocks will
>> not be invalid even if they do not have segwit support. They can
>> upgrade to it on their own schedule. The only risk non-participating
>> miners take after segwit activation is that if someone else mines an
>> invalid block they would extend it, a risk many miners already
>> frequently take with spy-mining.
>>
>> I do not think it is a horrible proposal: it is better engineered than
>> many things that many altcoins do, but just not up to our normal
>> standards. I respect the motivations of the authors of BIP 148.  If
>> your goal is the fastest possible segwit activation then it is very
>> useful to exploit the >80% of existing nodes that already support the
>> original version of segwit.
>>
>> But the fastest support should not be our goal, as a community-- there
>> is always some reckless altcoin or centralized system that can support
>> something faster than we can-- trying to match that would only erode
>> our distinguishing value in being well engineered and stable.
>>
>> "First do no harm." We should use the least disruptive mechanisms
>> available, and the BIP148 proposal does not meet that test.  To hear
>> some people-- non-developers on reddit and such-- a few even see the
>> forced orphaning of 148 as a virtue, that it's punitive for
>> misbehaving miners. I could not not disagree with that perspective any
>> more strongly.
>>
>> Of course, I do not oppose the general concept of a UASF but
>> _generally_ a soft-fork (of any kind) does not need to risk disruption
>> of mining, just as segwit's activation does not.  UASF are the
>> original kind of soft-fork and were the only kind of fork practiced by
>> Satoshi. P2SH was activated based on a date, and all prior ones were
>> based on times or heights.  We introduced miner based activation as
>> part of a process of making Bitcoin more stable in the common case
>> where the ecosystem is all in harmony.  It's kind of weird to see UASF
>> portrayed as something new.
>>
>> It's important the users not be at the mercy of any one part of the
>> ecosystem to the extent that we can avoid it-- be it developers,
>> exchanges, chat forums, or mining hardware makers.  Ultimately the
>> rules of Bitcoin work because they're enforced by the users
>> collectively-- that is what makes Bitcoin Bitcoin, it's what makes it
>> something people can count on: the rules aren't easy to just change.
>>
>> There have been some other UASF proposals that avoid the forced
>> disruption-- by just defining a new witness bit and allowing
>> non-upgraded-to-uasf miners and nodes to continue as non-upgraded, I
>> think they are vastly superior. They would be slower to deploy, but I
>> do not think that is a flaw.
>>
>> We should have patience. Bitcoin is a system that should last for all
>> ages and power mankind for a long time-- ten years from now a couple
>> years of dispute will seem like nothing. But the reputation we earn
>> for stability and integrity, for being a system of money people can
>> count on will mean everything.
>>
>> If these discussions come up, they'll come up in the form of reminding
>> people that Bitcoin isn't easily changed at a whim, even when the
>> whims are obviously good, and how that protects it from being managed
>> like all the competing systems of money that the world used to use
>> were managed. :)
>>
>> So have patience, don't take short cuts.  Segwit is a good improvement
>> and we should respect it by knowing that it's good enough to wait for,
>> and for however its activated to be done the best way we know how.
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
>
>
> --
> Steven Pine
> (510) 517-7075
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

[-- Attachment #2: Type: text/html, Size: 10378 bytes --]

Re: [bitcoin-dev] I do not support the BIP 148 UASF

[Gregory Maxwell]

On Sat, Apr 15, 2017 at 2:01 AM, Steven Pine via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> Regarding this last point I was under the impression that if Segwit did not
> activate by November then core was going to move on, is that no longer the

Wow. Where did you get that idea? That is _absurd_ and untrue, and I
struggle a bit to even comprehend how someone could believe it.  It
would continue until something clearly better came along or people
lost interest in it, why would it be anything else?

> census change that was not rolled out and done by the core team? I only
> mention this because BIP148, if it goes ahead (and is successful), would be
> the first time a consensus change occurs outside of the core developers --
> but again I am not an expert on the history of changes and could be wrong, I

There is a definitional issue there. There isn't much of "the core
team" there is a lot of amorphous public collaboration; everything
ends up being retroactively defined as the core team.  With open
participation and hundreds of contributors and software running
everywhere in the network, its unlikely that someone would advance to
the point of being able to make a credible proposal without at some
point making some improvement to the project or without the help of
someone who has.

In some sense you are coming very close to asking for a list of people
who have contributed to Bitcoin without contributing to Bitcoin.

CLTV was a proposal by Peter Todd whom has done a number of other
things in core but AFAIR had no involvement in any prior soft-fork
(though perhaps I'm forgetting one?), though he subsequently
contributed to BIP66 (which activated before CLTV), and he contributed
mostly after-the fact review of segwit. CSV was mostly the work of
Mark Friedenbach whom I believe was not involved in any prior or
subsequent soft-fork (and whos total contributions to Bitcoin core
weigh in at 14 commits over 5 years).

> My impression is that the community is ready for this and wants it, and if
> that impression is correct it will go ahead. No one knows the future, and
> simply assuming it's better to be slow and methodical isn't especially

I am not suggesting slow. I am suggesting that we not be outright
reckless. Some people are expecting changes which are effectively
orders of magnitude faster than changes in centralized systems
elsewhere which are far easier and safer to take quickly.

(Some more comparatives here:
https://www.reddit.com/r/Bitcoin/comments/65bch8/gregory_maxwell_i_do_not_support_the_bip_148_uasf/dg9xfam/
)

> Technology is in someways the history of failure,

By all means, take risks-- but you don't get to choose to make other
peoples things fail; you certainly don't get to demand their support,
though you could try to earn it if you care, by figuring out how to
meet their concerns.

Re: [bitcoin-dev] I do not support the BIP 148 UASF

[Steven Pine]

[-- Attachment #1: Type: text/plain, Size: 4086 bytes --]

I don't want to be rude and I will refer to your expertise, but segwit does
have a 'time out' as defined in BIP 9 with the date of November 15th? Does
core plan on just releasing another BIP with a new timeout hoping it will
eventually get 95% census?

As for the other point, we can play semantics but that's boring, I guess my
meaning was every census change has gone through a core defined process
(not counting the changes that occurred before there were BIPs and such),
isn't that the case? If the currently discussed UASF goes through it would
seem like the first time census occurred outside core's mailing list of
pull requests, acks, and merge to master, I only note it as a thing of
interest.

To be clear, the fast and reckless part for you is the mechanism by which
segwit could possibly be made active? Do you envision a means of segwit
being made consensus that does not have 95% mining support?

I appreciate your time and expertise, and to not take up anymore, back to
lurking i go.


On Fri, Apr 14, 2017 at 11:29 PM, Gregory Maxwell <greg@xiph.org> wrote:

> On Sat, Apr 15, 2017 at 2:01 AM, Steven Pine via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> > Regarding this last point I was under the impression that if Segwit did
> not
> > activate by November then core was going to move on, is that no longer
> the
>
> Wow. Where did you get that idea? That is _absurd_ and untrue, and I
> struggle a bit to even comprehend how someone could believe it.  It
> would continue until something clearly better came along or people
> lost interest in it, why would it be anything else?
>
> > census change that was not rolled out and done by the core team? I only
> > mention this because BIP148, if it goes ahead (and is successful), would
> be
> > the first time a consensus change occurs outside of the core developers
> --
> > but again I am not an expert on the history of changes and could be
> wrong, I
>
> There is a definitional issue there. There isn't much of "the core
> team" there is a lot of amorphous public collaboration; everything
> ends up being retroactively defined as the core team.  With open
> participation and hundreds of contributors and software running
> everywhere in the network, its unlikely that someone would advance to
> the point of being able to make a credible proposal without at some
> point making some improvement to the project or without the help of
> someone who has.
>
> In some sense you are coming very close to asking for a list of people
> who have contributed to Bitcoin without contributing to Bitcoin.
>
> CLTV was a proposal by Peter Todd whom has done a number of other
> things in core but AFAIR had no involvement in any prior soft-fork
> (though perhaps I'm forgetting one?), though he subsequently
> contributed to BIP66 (which activated before CLTV), and he contributed
> mostly after-the fact review of segwit. CSV was mostly the work of
> Mark Friedenbach whom I believe was not involved in any prior or
> subsequent soft-fork (and whos total contributions to Bitcoin core
> weigh in at 14 commits over 5 years).
>
> > My impression is that the community is ready for this and wants it, and
> if
> > that impression is correct it will go ahead. No one knows the future, and
> > simply assuming it's better to be slow and methodical isn't especially
>
> I am not suggesting slow. I am suggesting that we not be outright
> reckless. Some people are expecting changes which are effectively
> orders of magnitude faster than changes in centralized systems
> elsewhere which are far easier and safer to take quickly.
>
> (Some more comparatives here:
> https://www.reddit.com/r/Bitcoin/comments/65bch8/gregory_maxwell_i_do_not_
> support_the_bip_148_uasf/dg9xfam/
> )
>
> > Technology is in someways the history of failure,
>
> By all means, take risks-- but you don't get to choose to make other
> peoples things fail; you certainly don't get to demand their support,
> though you could try to earn it if you care, by figuring out how to
> meet their concerns.
>



-- 
Steven Pine
(510) 517-7075

[-- Attachment #2: Type: text/html, Size: 5387 bytes --]

Re: [bitcoin-dev] I do not support the BIP 148 UASF

[Gregory Maxwell]

On Sat, Apr 15, 2017 at 4:10 AM, Steven Pine <steven.pine@gmail.com> wrote:
> but segwit does
> have a 'time out' as defined in BIP 9 with the date of November 15th?

There is a technical requirement that BIP 9 bit allocations must have
a timeout so that a bit is not forever burned if a proposal is ever
abandoned (e.g. because something better came along before it
activated).  This isn't a timeout for the proposal, but for the bit
assignment.  If a proposal hasn't activated but there is still
interest it will just get a new bit (and can alternate back and forth
between a pair). This is a timeout of the bit, not the proposal.

It has to be setup this way because there is no real way to
communicate abandonment to old software, so a timeout must be set in
advance.

> Does core plan

"Core" doesn't plan on much of anything beyond the immediate pipeline
of activities, similar to other large open source collaboration, or
open standards development organizations. It isn't a company.
Individuals have plans about their own work which they may collaborate
in one place or another.

But allocating a new bit is how BIP9 works.

> meaning was every census change has gone through a core defined process (not
> counting the changes that occurred before there were BIPs and such), isn't

What is a "core defined process"?  BIP _itself_ was created by someone
who, AFAICT, has never made a commit to Bitcoin Core.  Numbers are
currently assigned, a nearly judgement-less administrative task, by
someone that authors competing fork of the software (Knots).

> it would seem like the first time census occurred outside core

Yet it was proposed on this list, had a BIP defined... if it got
eventually used it would presumably end up in the Bitcoin Core project
eventually... so what exactly is your definition of outside? Above you
seemed to be saying a BIP was not outside, but here you are saying
something documented as a BIP is outside?

If your preference is to not insult then it may be advisable to not
disregard distinctions which you do not understand as semantics. :) I
am not prone to arguing over semantics-- the continually binning in
almost all public collaboration as the work of some centralized entity
is really harmful to our community. The distinction is real, and not
semantics.

> To be clear, the fast and reckless part for you is the mechanism by which
> segwit could possibly be made active? Do you envision a means of segwit
> being made consensus that does not have 95% mining support?

Sure, and I said so directly in my message.  I believe I was
adequately clear that my complaint about BIP148 is specifically that
it has forced orphaning of passive participants which can be easily
avoided but at the expense of actually needed users to adopt the
change.

For clarity, it could be summarized as: I would not classify BIP148 as
a user activated soft-fork but instead as "user enforced miner
soft-fork activation". The consequence of this is that it likely
cannot achieve low disruptiveness-- this limitation would be excusable
if we weren't aware of any alternative, but in this case we are and
the only relative downside of it is that users will need to upgrade
for it-- which should not be a problem in principle if we believe a
UASF is really user activated.

Re: [bitcoin-dev] I do not support the BIP 148 UASF

[Cameron Garnham]

Hello,

It is hard for me to come out disagreeing with Maxwell, however in this case I feel I must.

As many may remember, there was quite some controversy about the BIP16 vs BIP 17 split; the main argument for BIP16 was the urgency of P2SH, and how this was the already “tested and proven to work” solution.

I was one of the man hold-out supporters of BIP17, not for any clear reason (I now have a much better technical understanding of the Bitcoin technical details, as we all do); But because it was the ‘more elegant’ solution.  I knew from other fields of engineering that elegant solutions very often better deal with the ‘unknown, unknowns’.  I also didn’t agree with Gavin’s ‘the sky is falling’ sense of urgency.

However, of-course the community got behind BIP16, it was activated, fortunately, without any signifiant incident.

I did learn that in Bitcoin there is something more valuable than technical elegance: that is community buy-in. On the technical side, the engineers need to make sure the solutions are viable: however on the community side we need to make sure that the good solutions are adopted in a reasonable timeframe.

It is both my empirical view and heart-felt belief that the wider Bitcoin Community wants SegWit quickly. In this case the sacrifice of some technical elegance and correctness for expediency is prudent!

It is my unfortunate view that Maxwell is missing the political forest for the technical trees.  Not only is SegWit a technical solution to technical problems; it has come to represent, by the larger Bitcoin Community, a political solution to the conflict that we are waist-deep in every, single, day.

BIP 148 is out terms of peace.  The Bitcoin Community is tired-to-death of this war and wants a resolution swiftly. BIP 148 proves a outlet, and in Maxwell words: “...almost guarantees at a minor level of disruption.”.

I am willing to go through this minor level of disruption, as the daily disruption from the “scaling debate war”; in my personal online life, is far greater.

SegWit is a exceptional feat of engineering, it solves and mitigates so many small and highly subtle issues within Bitcoin; yet still managed to be simple enough successfully reviewed: now the community is clearly calling for a quick activation of the ‘viable’ technical choice.

If you/we are going to provide any engineering solution to activating SegWit, then Swiftness should be the 1st priority after viability.

BIP 148 is both Swift and Viable.

Cameron.



> On 14 Apr 2017, at 10:56 AM, Gregory Maxwell via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
> 
> I do not support the BIP148 UASF for some of the same reasons that I
> do support segwit:  Bitcoin is valuable in part because it has high
> security and stability, segwit was carefully designed to support and
> amplify that engineering integrity that people can count on now and
> into the future.
> 
> I do not feel the the approach proposed in BIP148 really measures up
> to the standard set by segwit itself, or the existing best practices
> in protocol development in this community.
> 
> The primary flaw in BIP148 is that by forcing the activation of the
> existing (non-UASF segwit) nodes it almost guarantees at a minor level
> of disruption.
> 
> Segwit was carefully engineered so that older unmodified miners could
> continue operating _completely_ without interruption after segwit
> activates.
> 
> Older nodes will not include segwit spends, and so their blocks will
> not be invalid even if they do not have segwit support. They can
> upgrade to it on their own schedule. The only risk non-participating
> miners take after segwit activation is that if someone else mines an
> invalid block they would extend it, a risk many miners already
> frequently take with spy-mining.
> 
> I do not think it is a horrible proposal: it is better engineered than
> many things that many altcoins do, but just not up to our normal
> standards. I respect the motivations of the authors of BIP 148.  If
> your goal is the fastest possible segwit activation then it is very
> useful to exploit the >80% of existing nodes that already support the
> original version of segwit.
> 
> But the fastest support should not be our goal, as a community-- there
> is always some reckless altcoin or centralized system that can support
> something faster than we can-- trying to match that would only erode
> our distinguishing value in being well engineered and stable.
> 
> "First do no harm." We should use the least disruptive mechanisms
> available, and the BIP148 proposal does not meet that test.  To hear
> some people-- non-developers on reddit and such-- a few even see the
> forced orphaning of 148 as a virtue, that it's punitive for
> misbehaving miners. I could not not disagree with that perspective any
> more strongly.
> 
> Of course, I do not oppose the general concept of a UASF but
> _generally_ a soft-fork (of any kind) does not need to risk disruption
> of mining, just as segwit's activation does not.  UASF are the
> original kind of soft-fork and were the only kind of fork practiced by
> Satoshi. P2SH was activated based on a date, and all prior ones were
> based on times or heights.  We introduced miner based activation as
> part of a process of making Bitcoin more stable in the common case
> where the ecosystem is all in harmony.  It's kind of weird to see UASF
> portrayed as something new.
> 
> It's important the users not be at the mercy of any one part of the
> ecosystem to the extent that we can avoid it-- be it developers,
> exchanges, chat forums, or mining hardware makers.  Ultimately the
> rules of Bitcoin work because they're enforced by the users
> collectively-- that is what makes Bitcoin Bitcoin, it's what makes it
> something people can count on: the rules aren't easy to just change.
> 
> There have been some other UASF proposals that avoid the forced
> disruption-- by just defining a new witness bit and allowing
> non-upgraded-to-uasf miners and nodes to continue as non-upgraded, I
> think they are vastly superior. They would be slower to deploy, but I
> do not think that is a flaw.
> 
> We should have patience. Bitcoin is a system that should last for all
> ages and power mankind for a long time-- ten years from now a couple
> years of dispute will seem like nothing. But the reputation we earn
> for stability and integrity, for being a system of money people can
> count on will mean everything.
> 
> If these discussions come up, they'll come up in the form of reminding
> people that Bitcoin isn't easily changed at a whim, even when the
> whims are obviously good, and how that protects it from being managed
> like all the competing systems of money that the world used to use
> were managed. :)
> 
> So have patience, don't take short cuts.  Segwit is a good improvement
> and we should respect it by knowing that it's good enough to wait for,
> and for however its activated to be done the best way we know how.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] I do not support the BIP 148 UASF

[Gregory Maxwell]

On Sat, Apr 15, 2017 at 6:28 AM, Cameron Garnham <da2ce7@gmail.com> wrote:
> As many may remember, there was quite some controversy about the BIP16 vs BIP 17 split; the main argument for BIP16 was the urgency of P2SH, and how this was the already “tested and proven to work” solution.

And as a result we ultimately got a clearly inferior solution (520
byte script limit; 80-bit security; months of orphaned blocks-- and
two of those were not issues in BIP17).  I went along for the cram
fest on 16 after 12 caught fire, and I was mistaken to do so.

Doubly so because it took years for P2SH to achieve any kind of mass
deployment due to issues far away from consensus.  An extra two months
spent on some ground-work (including communications and documentation)
could have pulled forward practical deployment by a year and given
time to find and fix some of the flaws in the design of P2SH.

> BIP 148 is out (our?) terms of peace.  The Bitcoin Community is tired-to-death of this war and wants a resolution swiftly. BIP 148 proves a outlet, and in Maxwell words: “...almost guarantees at a minor level of disruption.”.

It seems I lost a word in my comment: that should have been "almost
guarantees at _least_ a minor level of disruption". A minor level of
disruption is the _minimum_ amount of disruption, and for no good
reason except an unprecedented and unjustified level of haste.

Considering that you did not spare a single word about the specific
property that I am concerned about-- that the proposal will reject the
blocks of passive participants, due to avoidable design limitations--
I can't help but feel that you don't even care to understand the
concern I was bringing up. :(

How many people barely reviewed the specifics of the proposal simply
because they want something fast and this proposal does something
fast?

> tired-to-death of this war and wants a resolution swiftly

By now competitors and opponents to Bitcoin have surely realized that
they can attack Bitcoin by stirring up drama.

As a result, the only way that we will ever be free from "war" is if
we choose to not let it impact us as much as possible. We must be
imperturbable and continue working at the same level of excellence as
if virtual shells weren't flying overhead-- or otherwise there is an
incentive to keep them flying 24/7. Internet drama is remarkably cheap
to generate. "The only thing we have to fear is fear itself".

The alternative is that we hand opponents a ready made formula for
disruption: astroturf enough drama up that Bitcoiners "sacrifice
correctness" themselves right off a cliff in a futile attempt to make
it go away. :)

Re: [bitcoin-dev] I do not support the BIP 148 UASF

[Chris Acheson]

On 04/15/2017 03:04 AM, Gregory Maxwell via bitcoin-dev wrote:
> Considering that you did not spare a single word about the specific 
> property that I am concerned about-- that the proposal will reject
> the blocks of passive participants, due to avoidable design
> limitations-- I can't help but feel that you don't even care to
> understand the concern I was bringing up. :(

Not sure if you missed my previous reply to you, but I'm curious about
your thoughts on this particular point. I contend that for any UASF,
orphaning non-signalling blocks on the flag date is safer than just
considering the fork active on the flag date.

Unless we have majority miner support for the fork, we have to assume
that a chain split will occur at some point. With the orphaning
approach, we know exactly when that will be, and can plan around it.
Miners know that they need to upgrade by the flag date in order to get
paid. We even have an opportunity to back out if it looks like we don't
have enough economic support.

With the non-orphaning approach, the split won't occur until someone
chooses to craft a malicious block (short bitcoin; rent hash power;
profit). We don't know when that will be, so we can't plan around it.
Some nodes and miners will assume it won't happen at all. When it
happens, our responses to it will be clumsy, uncoordinated, and likely
panicked.

While the orphaning approach is potentially disruptive to miners, it is
necessarily so in order to minimize disruption to users. In general,
users should be prioritized over miners. The point of Bitcoin is to have
secure, digital money that we can *use*, not to enable people to earn
money from running busy-work computations.

> How many people barely reviewed the specifics of the proposal simply 
> because they want something fast and this proposal does something 
> fast?

I have scrutinized the strategy of BIP148 a fair bit. I was initially
opposed to it, but after Bitfury showed their support, and especially
after the Asicboost revelation, I think it has solid potential to
succeed. It would be a waste not to at least attempt to organize around
it. If it turns out that we can't get the necessary support in time, we
can abandon the effort and reassess our options.

Re: [bitcoin-dev] I do not support the BIP 148 UASF

[Natanael]

[-- Attachment #1: Type: text/plain, Size: 3388 bytes --]

Den 15 apr. 2017 13:51 skrev "Chris Acheson via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org>:


Not sure if you missed my previous reply to you, but I'm curious about
your thoughts on this particular point. I contend that for any UASF,
orphaning non-signalling blocks on the flag date is [maybe] safer [for
those in on the UASF fork] than just
considering the fork active on the flag date.


Note my additions.

Enforcement by orphaning non-compliance makes it harder to reverse a buggy
softfork, since you necessarily increase the effort needed to return enough
mining power to the safe chain since you now have mostly unmonitored mining
hardware fighting you actively, whose operators you might not be able to
contact. You'd practically have to hardfork out of the situation.

There's also the risk of the activation itself triggering concensus bugs
(multiple incompatible UASF forks), if there's multiple implementations of
it in the network (or one buggy one). We have already seen something like
it happen. This can both happen on the miner side, client side or both
(miner side only would lead to a ton of orphaned blocks, client side means
netsplit).

It is also not economically favorable for any individual miner to be the
one to mine empty blocks on top of any surviving softfork-incompatible
chain. As a miner you would only volunteer to do it if you believe the
softfork is necessary or itself will enable greater future profit.

Besides that, I also just don't believe that UASF itself as a method to
activate softforks is a good choice. The only two reliable signals we have
for this purpose in Bitcoin are block height (flag day) and standard miner
signaling, as every other metric can be falsified or gamed.

But there's also more problems - a big one is that we have no way right now
for a node to tell another "the transaction you just relayed to me is
invalid according to an active softfork" (or "will become invalid". This
matters for several reasons.

The first one that came to my mind is that we have widespread usage of
zero-confirmation payments in the network.

This was already dangerous for other reasons, but this UASF could make it
guaranteed cost-free to exploit - because as many also know, we ALSO
already have a lot of nodes that do not enforce the non-default rejection
policies (otherwise we'd never see such transactions on blocks), including
many alternative Bitcoin clients.

The combination of these factors means that you can present an UASF invalid
transaction to a non-updated client that is supposedly protected by the
deliberate orphaning effort, and have it accept this as a payment. To never
see it get confirmed, or to eventually see it doublespent by an UASF-valid
transaction.

I would not at all be surprised if it turned out that many
zero-confirmation accepting services do not reject non-default
transactions, or if they aren't all UASF-segwit aware.

This is why a flag day or similar is more effective - it can't be ignored
unlike "just another one of those UASF proposals" that you might not have
evaluated or not expect to activate.

This is by the way also a reason that I believe that all nodes and services
should publish all concensus critical policies that they enforce. This
would make it far easier to alert somebody that they NEED TO prepare for
whatever proposal that might conflict with their active policies.

[-- Attachment #2: Type: text/html, Size: 4426 bytes --]

Re: [bitcoin-dev] I do not support the BIP 148 UASF

[Greg Sanders]

[-- Attachment #1: Type: text/plain, Size: 4123 bytes --]

> Besides that, I also just don't believe that UASF itself as a method to
activate softforks is a good choice. The only two reliable signals we have
for this purpose in Bitcoin are block height (flag day) and standard miner
signaling, as every other metric can be falsified or gamed.

UASF can be just a flag day.

On Sat, Apr 15, 2017 at 9:23 AM, Natanael via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

>
>
> Den 15 apr. 2017 13:51 skrev "Chris Acheson via bitcoin-dev" <
> bitcoin-dev@lists.linuxfoundation.org>:
>
>
> Not sure if you missed my previous reply to you, but I'm curious about
> your thoughts on this particular point. I contend that for any UASF,
> orphaning non-signalling blocks on the flag date is [maybe] safer [for
> those in on the UASF fork] than just
> considering the fork active on the flag date.
>
>
> Note my additions.
>
> Enforcement by orphaning non-compliance makes it harder to reverse a buggy
> softfork, since you necessarily increase the effort needed to return enough
> mining power to the safe chain since you now have mostly unmonitored mining
> hardware fighting you actively, whose operators you might not be able to
> contact. You'd practically have to hardfork out of the situation.
>
> There's also the risk of the activation itself triggering concensus bugs
> (multiple incompatible UASF forks), if there's multiple implementations of
> it in the network (or one buggy one). We have already seen something like
> it happen. This can both happen on the miner side, client side or both
> (miner side only would lead to a ton of orphaned blocks, client side means
> netsplit).
>
> It is also not economically favorable for any individual miner to be the
> one to mine empty blocks on top of any surviving softfork-incompatible
> chain. As a miner you would only volunteer to do it if you believe the
> softfork is necessary or itself will enable greater future profit.
>
> Besides that, I also just don't believe that UASF itself as a method to
> activate softforks is a good choice. The only two reliable signals we have
> for this purpose in Bitcoin are block height (flag day) and standard miner
> signaling, as every other metric can be falsified or gamed.
>
> But there's also more problems - a big one is that we have no way right
> now for a node to tell another "the transaction you just relayed to me is
> invalid according to an active softfork" (or "will become invalid". This
> matters for several reasons.
>
> The first one that came to my mind is that we have widespread usage of
> zero-confirmation payments in the network.
>
> This was already dangerous for other reasons, but this UASF could make it
> guaranteed cost-free to exploit - because as many also know, we ALSO
> already have a lot of nodes that do not enforce the non-default rejection
> policies (otherwise we'd never see such transactions on blocks), including
> many alternative Bitcoin clients.
>
> The combination of these factors means that you can present an UASF
> invalid transaction to a non-updated client that is supposedly protected by
> the deliberate orphaning effort, and have it accept this as a payment. To
> never see it get confirmed, or to eventually see it doublespent by an
> UASF-valid transaction.
>
> I would not at all be surprised if it turned out that many
> zero-confirmation accepting services do not reject non-default
> transactions, or if they aren't all UASF-segwit aware.
>
> This is why a flag day or similar is more effective - it can't be ignored
> unlike "just another one of those UASF proposals" that you might not have
> evaluated or not expect to activate.
>
> This is by the way also a reason that I believe that all nodes and
> services should publish all concensus critical policies that they enforce.
> This would make it far easier to alert somebody that they NEED TO prepare
> for whatever proposal that might conflict with their active policies.
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

[-- Attachment #2: Type: text/html, Size: 5827 bytes --]

Re: [bitcoin-dev] I do not support the BIP 148 UASF

[Cameron Garnham]

Thank-you for your prompt response,

I believe I must have a different prospective of Bitcoin to you.  Ideologically I don’t agree that miners can be passive participants in the Bitcoin Network; and I certainly don’t see them acting as passive participants in the Bitcoin Community now.

The miners are very much political actors.  Hence why I fail to take-to-heart your concern "that the proposal will reject the blocks of passive participants”.

With AsicBoost, there are three miner groups: Those who use it (and have legal sanction to do so); Those who use it (without legal sanction); and those who don’t use it.  If SegWit didn’t directly affect miners, then one could possibly claim that there could be an ideal passive participant miner in reality. However since your important revelations on AsicBoost: SegWit cannot be a ‘passive’ option for miners.

Hence, I don’t care about orphaning the blocks of of the theoretical "passive participant” miner. As I have no logical reasoning to suggest one could exists; and a large amount of evidence to suggesting one dose not exit.


On BIP 16 vs. BIP 17;  I cannot see how BIP 148 similar engineering tradeoffs.  Is there any long-term ‘technical debt’ from BIP 148 that I’m unaware of that could be similar to BIP 16?


On the Drama:  Well 100M USD p/a can pay for lots of Drama; Hence going back to the first point: The miners are not passive participants when it comes to *any* form of activation of SegWit.

Cameron.



> On 15 Apr 2017, at 10:04 AM, Gregory Maxwell <greg@xiph.org> wrote:
> 
> On Sat, Apr 15, 2017 at 6:28 AM, Cameron Garnham <da2ce7@gmail.com> wrote:
>> As many may remember, there was quite some controversy about the BIP16 vs BIP 17 split; the main argument for BIP16 was the urgency of P2SH, and how this was the already “tested and proven to work” solution.
> 
> And as a result we ultimately got a clearly inferior solution (520
> byte script limit; 80-bit security; months of orphaned blocks-- and
> two of those were not issues in BIP17).  I went along for the cram
> fest on 16 after 12 caught fire, and I was mistaken to do so.
> 
> Doubly so because it took years for P2SH to achieve any kind of mass
> deployment due to issues far away from consensus.  An extra two months
> spent on some ground-work (including communications and documentation)
> could have pulled forward practical deployment by a year and given
> time to find and fix some of the flaws in the design of P2SH.
> 
>> BIP 148 is out (our?) terms of peace.  The Bitcoin Community is tired-to-death of this war and wants a resolution swiftly. BIP 148 proves a outlet, and in Maxwell words: “...almost guarantees at a minor level of disruption.”.
> 
> It seems I lost a word in my comment: that should have been "almost
> guarantees at _least_ a minor level of disruption". A minor level of
> disruption is the _minimum_ amount of disruption, and for no good
> reason except an unprecedented and unjustified level of haste.
> 
> Considering that you did not spare a single word about the specific
> property that I am concerned about-- that the proposal will reject the
> blocks of passive participants, due to avoidable design limitations--
> I can't help but feel that you don't even care to understand the
> concern I was bringing up. :(
> 
> How many people barely reviewed the specifics of the proposal simply
> because they want something fast and this proposal does something
> fast?
> 
>> tired-to-death of this war and wants a resolution swiftly
> 
> By now competitors and opponents to Bitcoin have surely realized that
> they can attack Bitcoin by stirring up drama.
> 
> As a result, the only way that we will ever be free from "war" is if
> we choose to not let it impact us as much as possible. We must be
> imperturbable and continue working at the same level of excellence as
> if virtual shells weren't flying overhead-- or otherwise there is an
> incentive to keep them flying 24/7. Internet drama is remarkably cheap
> to generate. "The only thing we have to fear is fear itself".
> 
> The alternative is that we hand opponents a ready made formula for
> disruption: astroturf enough drama up that Bitcoiners "sacrifice
> correctness" themselves right off a cliff in a futile attempt to make
> it go away. :)

Re: [bitcoin-dev] I do not support the BIP 148 UASF

[shaolinfry]

[-- Attachment #1: Type: text/plain, Size: 6878 bytes --]

Dear Greg,

Thank you for taking the time to review the BIP148 proposal.

I agree with much of your thoughts. I originally started working on a generalized way to deploy user activated soft forks, in a way that leveraged BIP9 to allow for optional faster MASF activation. BIP148 came about as a way to satify many people's frustrations about the current segwit activation. I have said several times in various places that the proposal requires a very high amount of consensus that needs to be present to make actual deployment feasible. BIP148 is certainly not what a normal UASF would or should look like.

I remain convinced the community very much wants segwit activated and that the UASF movement in general has gained a lot of traction. While support for BIP148 is surprisingly high, there are definitely important players who support UASF in general but do not like BIP148 approach (which you rightly point out is a UASF to force a MASF).

In any case, I have been working on various iterations for generalized deployment of soft forks. My latest iteration adds a simple flag to a BIP9 deployment so the deployment will transition to LOCKED_IN at timeout if the deployment hasnt already activated or locked in by then. This is nice because it allows for a long deployment of a soft fork, giving the ecosystem plenty time to upgrade with an effective flagday at the end of the timeout. The hash power can still optionally activate earlier under MASF.

BIP8 (was uaversionbits) can be seen here https://github.com/bitcoin/bips/blob/master/bip-0008.mediawiki

With BIP8 we could perform a UASF segwit deployment. Due to some complexities in the peering logic, I recommend a new deployment with a fresh bit that starts right after November 15th (when BIP9 segwit timesout) with a BIP8 timeout for April 2018. The code can deployed much earlier. For example if code was deployed today, it would give the economy a year to upgrade. Activation could still occur safely by MASF any time from now until April 2018 (SEGWIT until Nov, then UASEGWIT from Nov until April 2018).

I am still working on the finer implementation details, but you can see a rough draft from this diff (which includes BIP8 in the first commit, and the proposed bip-segwit-uasf in the second commit).

https://github.com/bitcoin/bitcoin/compare/master...shaolinfry:uasegwit-flagday

I believe this approach would satisfy the more measured approach expected for Bitcoin and does not have the issues you brought up about BIP148.

I do not support the BIP148 UASF for some of the same reasons that I
do support segwit: Bitcoin is valuable in part because it has high
security and stability, segwit was carefully designed to support and
amplify that engineering integrity that people can count on now and
into the future.

I do not feel the the approach proposed in BIP148 really measures up
to the standard set by segwit itself, or the existing best practices
in protocol development in this community.

The primary flaw in BIP148 is that by forcing the activation of the
existing (non-UASF segwit) nodes it almost guarantees at a minor level
of disruption.

Segwit was carefully engineered so that older unmodified miners could
continue operating _completely_ without interruption after segwit
activates.

Older nodes will not include segwit spends, and so their blocks will
not be invalid even if they do not have segwit support. They can
upgrade to it on their own schedule. The only risk non-participating
miners take after segwit activation is that if someone else mines an
invalid block they would extend it, a risk many miners already
frequently take with spy-mining.

I do not think it is a horrible proposal: it is better engineered than
many things that many altcoins do, but just not up to our normal
standards. I respect the motivations of the authors of BIP 148. If
your goal is the fastest possible segwit activation then it is very
useful to exploit the >80% of existing nodes that already support the
original version of segwit.

But the fastest support should not be our goal, as a community-- there
is always some reckless altcoin or centralized system that can support
something faster than we can-- trying to match that would only erode
our distinguishing value in being well engineered and stable.

"First do no harm." We should use the least disruptive mechanisms
available, and the BIP148 proposal does not meet that test. To hear
some people-- non-developers on reddit and such-- a few even see the
forced orphaning of 148 as a virtue, that it's punitive for
misbehaving miners. I could not not disagree with that perspective any
more strongly.

Of course, I do not oppose the general concept of a UASF but
_generally_ a soft-fork (of any kind) does not need to risk disruption
of mining, just as segwit's activation does not. UASF are the
original kind of soft-fork and were the only kind of fork practiced by
Satoshi. P2SH was activated based on a date, and all prior ones were
based on times or heights. We introduced miner based activation as
part of a process of making Bitcoin more stable in the common case
where the ecosystem is all in harmony. It's kind of weird to see UASF
portrayed as something new.

It's important the users not be at the mercy of any one part of the
ecosystem to the extent that we can avoid it-- be it developers,
exchanges, chat forums, or mining hardware makers. Ultimately the
rules of Bitcoin work because they're enforced by the users
collectively-- that is what makes Bitcoin Bitcoin, it's what makes it
something people can count on: the rules aren't easy to just change.

There have been some other UASF proposals that avoid the forced
disruption-- by just defining a new witness bit and allowing
non-upgraded-to-uasf miners and nodes to continue as non-upgraded, I
think they are vastly superior. They would be slower to deploy, but I
do not think that is a flaw.

We should have patience. Bitcoin is a system that should last for all
ages and power mankind for a long time-- ten years from now a couple
years of dispute will seem like nothing. But the reputation we earn
for stability and integrity, for being a system of money people can
count on will mean everything.

If these discussions come up, they'll come up in the form of reminding
people that Bitcoin isn't easily changed at a whim, even when the
whims are obviously good, and how that protects it from being managed
like all the competing systems of money that the world used to use
were managed. :)

So have patience, don't take short cuts. Segwit is a good improvement
and we should respect it by knowing that it's good enough to wait for,
and for however its activated to be done the best way we know how.
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[-- Attachment #2: Type: text/html, Size: 8759 bytes --]

Re: [bitcoin-dev] I do not support the BIP 148 UASF

[Gregory Maxwell]

On Thu, Apr 20, 2017 at 6:39 PM, shaolinfry <shaolinfry@protonmail.ch> wrote:
> I agree with much of your thoughts. I originally started working on a
> generalized way to deploy user activated soft forks, in a way that leveraged
> BIP9 to allow for optional faster MASF activation. BIP148 came about as a
> way to satify many people's frustrations about the current segwit
> activation. I have said several times in various places that the proposal
> requires a very high amount of consensus that needs to be present to make
> actual deployment feasible. BIP148 is certainly not what a normal UASF would
> or should look like.
>
> I remain convinced the community very much wants segwit activated and that
> the UASF movement in general has gained a lot of traction. While support for
> BIP148 is surprisingly high, there are definitely important players who
> support UASF in general but do not like BIP148 approach (which you rightly
> point out is a UASF to force a MASF).
[...]
> With BIP8 we could perform a UASF segwit deployment. Due to some
> complexities in the peering logic, I recommend a new deployment with a fresh
> bit that starts right after November 15th (when BIP9 segwit timesout) with a
> BIP8 timeout for April 2018. The code can deployed much earlier. For example
> if code was deployed today, it would give the economy a year to upgrade.
> Activation could still occur safely by MASF any time from now until April
> 2018 (SEGWIT until Nov, then UASEGWIT from Nov until April 2018).
>
> I am still working on the finer implementation details, but you can see a
> rough draft from this diff (which includes BIP8 in the first commit, and the
> proposed bip-segwit-uasf in the second commit).
>
> https://github.com/bitcoin/bitcoin/compare/master...shaolinfry:uasegwit-flagday
>
> I believe this approach would satisfy the more measured approach expected
> for Bitcoin and does not have the issues you brought up about BIP148.

I have not reviewed it carefully yet, but I agree that it addresses my
main concern!  I think this is a much better approach. Thanks.

Re: [bitcoin-dev] I do not support the BIP 148 UASF

[Luke Dashjr]

On Tuesday 25 April 2017 6:28:14 PM Gregory Maxwell via bitcoin-dev wrote:
> > https://github.com/bitcoin/bitcoin/compare/master...shaolinfry:uasegwit-f
> > lagday
> > 
> > I believe this approach would satisfy the more measured approach expected
> > for Bitcoin and does not have the issues you brought up about BIP148.
> 
> I have not reviewed it carefully yet, but I agree that it addresses my
> main concern!  I think this is a much better approach. Thanks.

FWIW, I disagree in this case. I think given the circumstances, if we are 
going to do a UASF for segwit at all, we need a clearly decisive outcome, 
which is given by BIP 148. Using the approach in BIP 8 makes sense in many 
cases, but in this case, it is liable to simply create a prolonged uncertainty 
where nobody knows the outcome when segwit's rules are challenged by a 
malicious miner.

If BIP 148 fails to achieve widespread support, we could do a BIP 8-based UASF 
with Segwit v2 (along with some other changes I suggested in the other 
thread), but I think the tradeoffs right now favour BIP 148 as the best UASF 
deployment.

Luke

Re: [bitcoin-dev] I do not support the BIP 148 UASF

[Erik Aronesty]

[-- Attachment #1: Type: text/plain, Size: 1591 bytes --]

If the flag day for a wtxid commitment is timed before the current segwit
period end, I suspect segwit would activate within the current period.

On Tue, Apr 25, 2017 at 2:46 PM, Luke Dashjr via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Tuesday 25 April 2017 6:28:14 PM Gregory Maxwell via bitcoin-dev wrote:
> > > https://github.com/bitcoin/bitcoin/compare/master...
> shaolinfry:uasegwit-f
> > > lagday
> > >
> > > I believe this approach would satisfy the more measured approach
> expected
> > > for Bitcoin and does not have the issues you brought up about BIP148.
> >
> > I have not reviewed it carefully yet, but I agree that it addresses my
> > main concern!  I think this is a much better approach. Thanks.
>
> FWIW, I disagree in this case. I think given the circumstances, if we are
> going to do a UASF for segwit at all, we need a clearly decisive outcome,
> which is given by BIP 148. Using the approach in BIP 8 makes sense in many
> cases, but in this case, it is liable to simply create a prolonged
> uncertainty
> where nobody knows the outcome when segwit's rules are challenged by a
> malicious miner.
>
> If BIP 148 fails to achieve widespread support, we could do a BIP 8-based
> UASF
> with Segwit v2 (along with some other changes I suggested in the other
> thread), but I think the tradeoffs right now favour BIP 148 as the best
> UASF
> deployment.
>
> Luke
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 2444 bytes --]

Re: [bitcoin-dev] I do not support the BIP 148 UASF

[Suhas Daftuar]

[-- Attachment #1: Type: text/plain, Size: 9941 bytes --]

I also do not support the BIP 148 UASF, and I'd like to add to the points
that Greg has already raised in this thread.

BIP 148 would introduce a new consensus rule that softforks out non-segwit
signalling blocks in some time period.  I reject this consensus rule as
both arbitrary and needlessly disruptive.  Bitcoin's primary purpose is to
reach consensus on the state of a shared ledger, and even though I think
the Bitcoin network ought to adopt segwit, I don't think that concern
trumps the goal of not splitting the network.

Many BIP 148 advocates seem to start with the assumption that segwit
already has a lot of support, and suggest that BIP 148 does as well.
However I don't think it's fair or correct to separate the activation
proposal for segwit from the rest of the segwit proposal.  The deployment
parameters for segwit are consensus-critical; assuming that some other
deployment has consensus because it would result in the rest of the segwit
proposal activating is an unjustified leap.

Even if there were no feasible alternate segwit deployment method available
to us, I would hesitate to recommend that the network adopt a potentially
consensus-splitting approach, even though I firmly believe that the ideas
behind segwit are fundamentally good ones.  But fortunately that is not the
situation we are in; we have substantially less disruptive methods
available to us to activate it, even if the current BIP 9 deployment were
to fail -- such as another BIP 9 deployment in the future, or perhaps a BIP
149 deployment.

If we do pursue a "user-activated" deployment of segwit, I'd recommend that
we do so in a more careful way than BIP 148 or 149 currently suggest, which
as I understand would otherwise make very few changes to the current
implementation.  However, due to the BIP 9 activation assumption, the
Bitcoin Core 0.13.1 - 0.14.0 segwit implementation largely lumps together
the idea that miners would both enforce the rules and mine segwit blocks.
However, we can separate these concerns, as we started to do in the Bitcoin
Core 0.14.1 release, where mining segwit blocks is not required in order to
generally mine or signal for segwit in the software.  And we can go further
still: without too much work, we could make further improvements to
accommodate miners who, for whatever reason, don't want to upgrade their
systems, such as by improving block relay from pre-segwit peers [1], or
optimizing transaction selection for miners who are willing to enforce the
segwit rules but haven't upgraded their systems to mine segwit blocks [2].

If we would seek to activate a soft-fork with less clear miner signaling
(such as BIP 149), then I think such improvements are warranted to minimize
network disruption.  In general, we should not seek to censor hashpower on
the network unless we have a very important reason for doing so.  While the
issues here are nuanced, if I were to evaluate the BIP 148 soft-fork
proposal on the spectrum of "censorship attack on Bitcoin" to "benign
protocol upgrade", BIP 148 strikes me as closer to the former than the
latter.  There is simply no need here to orphan these non-signalling blocks
that could otherwise be used to secure the network.

To go further: I think BIP 148 is ill-conceived even for achieving its own
presumed goals -- the motivation for adding a consensus rule that applies
to the version bits on blocks is surely for the effect such bits have on
older software, such as Bitcoin Core releases 0.13.1 and later.  Yet in
trying to bring those implementations along as segwit-enforcing software,
BIP 148 would risk forking from such clients in the short term!  If one
really cared about maintaining consensus with older, segwit-enabled
software, it would make far more sense to seek segwit activation in a way
that didn't fork from them (such as BIP 149, or a new BIP 9 deployment
after this one times out).  And if one doesn't care about such consensus,
then it'd be far simpler to just set (e.g.) August 1 as the flag day
activation of segwit, and not play these contortionist games with block
version bits, which carry no useful or intrinsic meaning.  Either of these
two approaches should have the advantage of reduced fork risk, compared
with BIP 148.

Of course, everyone is free to run the software of their choosing.  I write
this to both generally convey my opposition to a careless proposal, which I
believe represents a way of thinking that is detrimental to Bitcoin's long
run success, and specifically explain why I oppose inclusion of this
proposal in the Bitcoin Core implementation [3].  The Bitcoin Core project
hasn't been, and shouldn't be, careless in deploying consensus changes.
Instead, I think the Bitcoin Core project ought to stand up for the best
practices that our community has learned about how to deploy such changes
(specifically for minimizing chain-split risk when deploying a soft fork!),
and I think we should all avoid adoption or encouragement of practices that
would depart from the high standards we are capable of achieving.


 [1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017
-March/013811.html
 [2] https://github.com/bitcoin/bitcoin/pull/9955
 [3] https://github.com/bitcoin/bitcoin/pull/10428#issuecomment-303098925


--Suhas Daftuar


On Fri, Apr 14, 2017 at 3:56 AM, Gregory Maxwell via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> I do not support the BIP148 UASF for some of the same reasons that I
> do support segwit:  Bitcoin is valuable in part because it has high
> security and stability, segwit was carefully designed to support and
> amplify that engineering integrity that people can count on now and
> into the future.
>
> I do not feel the the approach proposed in BIP148 really measures up
> to the standard set by segwit itself, or the existing best practices
> in protocol development in this community.
>
> The primary flaw in BIP148 is that by forcing the activation of the
> existing (non-UASF segwit) nodes it almost guarantees at a minor level
> of disruption.
>
> Segwit was carefully engineered so that older unmodified miners could
> continue operating _completely_ without interruption after segwit
> activates.
>
> Older nodes will not include segwit spends, and so their blocks will
> not be invalid even if they do not have segwit support. They can
> upgrade to it on their own schedule. The only risk non-participating
> miners take after segwit activation is that if someone else mines an
> invalid block they would extend it, a risk many miners already
> frequently take with spy-mining.
>
> I do not think it is a horrible proposal: it is better engineered than
> many things that many altcoins do, but just not up to our normal
> standards. I respect the motivations of the authors of BIP 148.  If
> your goal is the fastest possible segwit activation then it is very
> useful to exploit the >80% of existing nodes that already support the
> original version of segwit.
>
> But the fastest support should not be our goal, as a community-- there
> is always some reckless altcoin or centralized system that can support
> something faster than we can-- trying to match that would only erode
> our distinguishing value in being well engineered and stable.
>
> "First do no harm." We should use the least disruptive mechanisms
> available, and the BIP148 proposal does not meet that test.  To hear
> some people-- non-developers on reddit and such-- a few even see the
> forced orphaning of 148 as a virtue, that it's punitive for
> misbehaving miners. I could not not disagree with that perspective any
> more strongly.
>
> Of course, I do not oppose the general concept of a UASF but
> _generally_ a soft-fork (of any kind) does not need to risk disruption
> of mining, just as segwit's activation does not.  UASF are the
> original kind of soft-fork and were the only kind of fork practiced by
> Satoshi. P2SH was activated based on a date, and all prior ones were
> based on times or heights.  We introduced miner based activation as
> part of a process of making Bitcoin more stable in the common case
> where the ecosystem is all in harmony.  It's kind of weird to see UASF
> portrayed as something new.
>
> It's important the users not be at the mercy of any one part of the
> ecosystem to the extent that we can avoid it-- be it developers,
> exchanges, chat forums, or mining hardware makers.  Ultimately the
> rules of Bitcoin work because they're enforced by the users
> collectively-- that is what makes Bitcoin Bitcoin, it's what makes it
> something people can count on: the rules aren't easy to just change.
>
> There have been some other UASF proposals that avoid the forced
> disruption-- by just defining a new witness bit and allowing
> non-upgraded-to-uasf miners and nodes to continue as non-upgraded, I
> think they are vastly superior. They would be slower to deploy, but I
> do not think that is a flaw.
>
> We should have patience. Bitcoin is a system that should last for all
> ages and power mankind for a long time-- ten years from now a couple
> years of dispute will seem like nothing. But the reputation we earn
> for stability and integrity, for being a system of money people can
> count on will mean everything.
>
> If these discussions come up, they'll come up in the form of reminding
> people that Bitcoin isn't easily changed at a whim, even when the
> whims are obviously good, and how that protects it from being managed
> like all the competing systems of money that the world used to use
> were managed. :)
>
> So have patience, don't take short cuts.  Segwit is a good improvement
> and we should respect it by knowing that it's good enough to wait for,
> and for however its activated to be done the best way we know how.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 11492 bytes --]

Re: [bitcoin-dev] I do not support the BIP 148 UASF

[Steven Pine]

[-- Attachment #1: Type: text/plain, Size: 11052 bytes --]

I'm glad some discussion has been moved back here.

Correct me if I am wrong, but currently core developers are arguing over
whether or not to allow an optional configuration switch which defaults off
but signals and enforces BIP148 when used. Who are we protecting users
from, themselves? Are you protecting core? from what? I am somewhat
genuinely befuddled by those who can't even allow a user config switch to
be set.

I guess I find it all incredibly silly, but perhaps I suffer from some
basic confusion.



On Mon, May 22, 2017 at 3:23 PM, Suhas Daftuar via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> I also do not support the BIP 148 UASF, and I'd like to add to the points
> that Greg has already raised in this thread.
>
> BIP 148 would introduce a new consensus rule that softforks out non-segwit
> signalling blocks in some time period.  I reject this consensus rule as
> both arbitrary and needlessly disruptive.  Bitcoin's primary purpose is to
> reach consensus on the state of a shared ledger, and even though I think
> the Bitcoin network ought to adopt segwit, I don't think that concern
> trumps the goal of not splitting the network.
>
> Many BIP 148 advocates seem to start with the assumption that segwit
> already has a lot of support, and suggest that BIP 148 does as well.
> However I don't think it's fair or correct to separate the activation
> proposal for segwit from the rest of the segwit proposal.  The deployment
> parameters for segwit are consensus-critical; assuming that some other
> deployment has consensus because it would result in the rest of the segwit
> proposal activating is an unjustified leap.
>
> Even if there were no feasible alternate segwit deployment method
> available to us, I would hesitate to recommend that the network adopt a
> potentially consensus-splitting approach, even though I firmly believe that
> the ideas behind segwit are fundamentally good ones.  But fortunately that
> is not the situation we are in; we have substantially less disruptive
> methods available to us to activate it, even if the current BIP 9
> deployment were to fail -- such as another BIP 9 deployment in the future,
> or perhaps a BIP 149 deployment.
>
> If we do pursue a "user-activated" deployment of segwit, I'd recommend
> that we do so in a more careful way than BIP 148 or 149 currently suggest,
> which as I understand would otherwise make very few changes to the current
> implementation.  However, due to the BIP 9 activation assumption, the
> Bitcoin Core 0.13.1 - 0.14.0 segwit implementation largely lumps together
> the idea that miners would both enforce the rules and mine segwit blocks.
> However, we can separate these concerns, as we started to do in the Bitcoin
> Core 0.14.1 release, where mining segwit blocks is not required in order to
> generally mine or signal for segwit in the software.  And we can go further
> still: without too much work, we could make further improvements to
> accommodate miners who, for whatever reason, don't want to upgrade their
> systems, such as by improving block relay from pre-segwit peers [1], or
> optimizing transaction selection for miners who are willing to enforce the
> segwit rules but haven't upgraded their systems to mine segwit blocks [2].
>
> If we would seek to activate a soft-fork with less clear miner signaling
> (such as BIP 149), then I think such improvements are warranted to minimize
> network disruption.  In general, we should not seek to censor hashpower on
> the network unless we have a very important reason for doing so.  While the
> issues here are nuanced, if I were to evaluate the BIP 148 soft-fork
> proposal on the spectrum of "censorship attack on Bitcoin" to "benign
> protocol upgrade", BIP 148 strikes me as closer to the former than the
> latter.  There is simply no need here to orphan these non-signalling blocks
> that could otherwise be used to secure the network.
>
> To go further: I think BIP 148 is ill-conceived even for achieving its own
> presumed goals -- the motivation for adding a consensus rule that applies
> to the version bits on blocks is surely for the effect such bits have on
> older software, such as Bitcoin Core releases 0.13.1 and later.  Yet in
> trying to bring those implementations along as segwit-enforcing software,
> BIP 148 would risk forking from such clients in the short term!  If one
> really cared about maintaining consensus with older, segwit-enabled
> software, it would make far more sense to seek segwit activation in a way
> that didn't fork from them (such as BIP 149, or a new BIP 9 deployment
> after this one times out).  And if one doesn't care about such consensus,
> then it'd be far simpler to just set (e.g.) August 1 as the flag day
> activation of segwit, and not play these contortionist games with block
> version bits, which carry no useful or intrinsic meaning.  Either of these
> two approaches should have the advantage of reduced fork risk, compared
> with BIP 148.
>
> Of course, everyone is free to run the software of their choosing.  I
> write this to both generally convey my opposition to a careless proposal,
> which I believe represents a way of thinking that is detrimental to
> Bitcoin's long run success, and specifically explain why I oppose inclusion
> of this proposal in the Bitcoin Core implementation [3].  The Bitcoin Core
> project hasn't been, and shouldn't be, careless in deploying consensus
> changes.  Instead, I think the Bitcoin Core project ought to stand up for
> the best practices that our community has learned about how to deploy such
> changes (specifically for minimizing chain-split risk when deploying a soft
> fork!), and I think we should all avoid adoption or encouragement of
> practices that would depart from the high standards we are capable of
> achieving.
>
>
>  [1] https://lists.linuxfoundation.org/pipermail/
> bitcoin-dev/2017-March/013811.html
>  [2] https://github.com/bitcoin/bitcoin/pull/9955
>  [3] https://github.com/bitcoin/bitcoin/pull/10428#issuecomment-303098925
>
>
> --Suhas Daftuar
>
>
> On Fri, Apr 14, 2017 at 3:56 AM, Gregory Maxwell via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> I do not support the BIP148 UASF for some of the same reasons that I
>> do support segwit:  Bitcoin is valuable in part because it has high
>> security and stability, segwit was carefully designed to support and
>> amplify that engineering integrity that people can count on now and
>> into the future.
>>
>> I do not feel the the approach proposed in BIP148 really measures up
>> to the standard set by segwit itself, or the existing best practices
>> in protocol development in this community.
>>
>> The primary flaw in BIP148 is that by forcing the activation of the
>> existing (non-UASF segwit) nodes it almost guarantees at a minor level
>> of disruption.
>>
>> Segwit was carefully engineered so that older unmodified miners could
>> continue operating _completely_ without interruption after segwit
>> activates.
>>
>> Older nodes will not include segwit spends, and so their blocks will
>> not be invalid even if they do not have segwit support. They can
>> upgrade to it on their own schedule. The only risk non-participating
>> miners take after segwit activation is that if someone else mines an
>> invalid block they would extend it, a risk many miners already
>> frequently take with spy-mining.
>>
>> I do not think it is a horrible proposal: it is better engineered than
>> many things that many altcoins do, but just not up to our normal
>> standards. I respect the motivations of the authors of BIP 148.  If
>> your goal is the fastest possible segwit activation then it is very
>> useful to exploit the >80% of existing nodes that already support the
>> original version of segwit.
>>
>> But the fastest support should not be our goal, as a community-- there
>> is always some reckless altcoin or centralized system that can support
>> something faster than we can-- trying to match that would only erode
>> our distinguishing value in being well engineered and stable.
>>
>> "First do no harm." We should use the least disruptive mechanisms
>> available, and the BIP148 proposal does not meet that test.  To hear
>> some people-- non-developers on reddit and such-- a few even see the
>> forced orphaning of 148 as a virtue, that it's punitive for
>> misbehaving miners. I could not not disagree with that perspective any
>> more strongly.
>>
>> Of course, I do not oppose the general concept of a UASF but
>> _generally_ a soft-fork (of any kind) does not need to risk disruption
>> of mining, just as segwit's activation does not.  UASF are the
>> original kind of soft-fork and were the only kind of fork practiced by
>> Satoshi. P2SH was activated based on a date, and all prior ones were
>> based on times or heights.  We introduced miner based activation as
>> part of a process of making Bitcoin more stable in the common case
>> where the ecosystem is all in harmony.  It's kind of weird to see UASF
>> portrayed as something new.
>>
>> It's important the users not be at the mercy of any one part of the
>> ecosystem to the extent that we can avoid it-- be it developers,
>> exchanges, chat forums, or mining hardware makers.  Ultimately the
>> rules of Bitcoin work because they're enforced by the users
>> collectively-- that is what makes Bitcoin Bitcoin, it's what makes it
>> something people can count on: the rules aren't easy to just change.
>>
>> There have been some other UASF proposals that avoid the forced
>> disruption-- by just defining a new witness bit and allowing
>> non-upgraded-to-uasf miners and nodes to continue as non-upgraded, I
>> think they are vastly superior. They would be slower to deploy, but I
>> do not think that is a flaw.
>>
>> We should have patience. Bitcoin is a system that should last for all
>> ages and power mankind for a long time-- ten years from now a couple
>> years of dispute will seem like nothing. But the reputation we earn
>> for stability and integrity, for being a system of money people can
>> count on will mean everything.
>>
>> If these discussions come up, they'll come up in the form of reminding
>> people that Bitcoin isn't easily changed at a whim, even when the
>> whims are obviously good, and how that protects it from being managed
>> like all the competing systems of money that the world used to use
>> were managed. :)
>>
>> So have patience, don't take short cuts.  Segwit is a good improvement
>> and we should respect it by knowing that it's good enough to wait for,
>> and for however its activated to be done the best way we know how.
>> _______________________________________________
>> 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
>
>


-- 
Steven Pine
(510) 517-7075

[-- Attachment #2: Type: text/html, Size: 13167 bytes --]

Re: [bitcoin-dev] I do not support the BIP 148 UASF

[Karl Johan Alm]

On Tue, May 23, 2017 at 1:03 PM, Steven Pine via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> Correct me if I am wrong, but currently core developers are arguing over
> whether or not to allow an optional configuration switch which defaults off
> but signals and enforces BIP148 when used. Who are we protecting users from,
> themselves? Are you protecting core? from what? I am somewhat genuinely
> befuddled by those who can't even allow a user config switch to be set.

Essentially, if we make a potentially very harmful option easy to
enable for users, we are putting them at risk, so yes, this is about
protecting users of the base Bitcoin Core implementation. Users have,
hopefully, come to appreciate this implementation for the peer
review-based strict development process, and making a hasty decision
due to time constraints (segwit activation expiration) may have
undesirable consequences. Opinions among the regular contributors are
split on the matter, which to me is an indication we should be
cautious and consider all aspects before making a decision on the
matter.

Re: [bitcoin-dev] I do not support the BIP 148 UASF

[Luke Dashjr]

On Tuesday 23 May 2017 6:30:01 AM Karl Johan Alm via bitcoin-dev wrote:
> Essentially, if we make a potentially very harmful option easy to
> enable for users, we are putting them at risk, so yes, this is about
> protecting users of the base Bitcoin Core implementation.

In this case, NOT enforcing BIP148 puts users at more risk. Since devs are 
divided in opinion, we should at the very least have an option to let users 
decide one way or the other.

Luke

Re: [bitcoin-dev] I do not support the BIP 148 UASF

[Jorge Timón]

On Tue, May 23, 2017 at 2:55 PM, Luke Dashjr via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> On Tuesday 23 May 2017 6:30:01 AM Karl Johan Alm via bitcoin-dev wrote:
>> Essentially, if we make a potentially very harmful option easy to
>> enable for users, we are putting them at risk, so yes, this is about
>> protecting users of the base Bitcoin Core implementation.
>
> In this case, NOT enforcing BIP148 puts users at more risk. Since devs are
> divided in opinion, we should at the very least have an option to let users
> decide one way or the other.

Well, it's putting users at more risk only if for those users who
actively decided to put themselves at risk.
I also feel bip148 is rushed and that makes it more risky. I don't
want to reiterate points other have made but I don't fully agree with
all of them.
I prefer the way it is over the way it was (just activating at a given
date without forcing mining signaling), but I still think it's rushed
and unnecessarily risky (unless activating segwit was urgent, which I
think it's not, no matter how much I want it to become active as soon
as possible).
On the other hand, I support uasf and bip8 to replace bip9 for future
deployments, since bip9 made assumptions that weren't correct (like
assuming miners would always signal changes that don't harm any user
and are good for some of them).
Perhaps bip149 can be modified to activate earlier if the current
proposal is perceived as unnecessarily cautious.

Luke, I've seen you say in other forums that "bip148 is less risky
than bip149", but I think that's clearly false.

As a reminder, one of my complains about bip109 was precisely that it
was also rushed in how fast it could activate.

Re: [bitcoin-dev] I do not support the BIP 148 UASF

[Hampus Sjöberg]

[-- Attachment #1: Type: text/plain, Size: 12014 bytes --]

> Who are we protecting users from, themselves? Are you protecting core?
from what? I am somewhat genuinely befuddled by those who can't even allow
a user config switch to be set.

Indeed. It seems silly. If you're activating the switch, you're most likely
fully aware of what you're doing.
I also saw some very harsh rhetoric being used against BIP148, which seems
unjustified as we have no idea yet how it all will play out. We can only
guess.

Hampus

2017-05-23 6:03 GMT+02:00 Steven Pine via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org>:

> I'm glad some discussion has been moved back here.
>
> Correct me if I am wrong, but currently core developers are arguing over
> whether or not to allow an optional configuration switch which defaults off
> but signals and enforces BIP148 when used. Who are we protecting users
> from, themselves? Are you protecting core? from what? I am somewhat
> genuinely befuddled by those who can't even allow a user config switch to
> be set.
>
> I guess I find it all incredibly silly, but perhaps I suffer from some
> basic confusion.
>
>
>
> On Mon, May 22, 2017 at 3:23 PM, Suhas Daftuar via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> I also do not support the BIP 148 UASF, and I'd like to add to the points
>> that Greg has already raised in this thread.
>>
>> BIP 148 would introduce a new consensus rule that softforks out
>> non-segwit signalling blocks in some time period.  I reject this consensus
>> rule as both arbitrary and needlessly disruptive.  Bitcoin's primary
>> purpose is to reach consensus on the state of a shared ledger, and even
>> though I think the Bitcoin network ought to adopt segwit, I don't think
>> that concern trumps the goal of not splitting the network.
>>
>> Many BIP 148 advocates seem to start with the assumption that segwit
>> already has a lot of support, and suggest that BIP 148 does as well.
>> However I don't think it's fair or correct to separate the activation
>> proposal for segwit from the rest of the segwit proposal.  The deployment
>> parameters for segwit are consensus-critical; assuming that some other
>> deployment has consensus because it would result in the rest of the segwit
>> proposal activating is an unjustified leap.
>>
>> Even if there were no feasible alternate segwit deployment method
>> available to us, I would hesitate to recommend that the network adopt a
>> potentially consensus-splitting approach, even though I firmly believe that
>> the ideas behind segwit are fundamentally good ones.  But fortunately that
>> is not the situation we are in; we have substantially less disruptive
>> methods available to us to activate it, even if the current BIP 9
>> deployment were to fail -- such as another BIP 9 deployment in the future,
>> or perhaps a BIP 149 deployment.
>>
>> If we do pursue a "user-activated" deployment of segwit, I'd recommend
>> that we do so in a more careful way than BIP 148 or 149 currently suggest,
>> which as I understand would otherwise make very few changes to the current
>> implementation.  However, due to the BIP 9 activation assumption, the
>> Bitcoin Core 0.13.1 - 0.14.0 segwit implementation largely lumps together
>> the idea that miners would both enforce the rules and mine segwit blocks.
>> However, we can separate these concerns, as we started to do in the Bitcoin
>> Core 0.14.1 release, where mining segwit blocks is not required in order to
>> generally mine or signal for segwit in the software.  And we can go further
>> still: without too much work, we could make further improvements to
>> accommodate miners who, for whatever reason, don't want to upgrade their
>> systems, such as by improving block relay from pre-segwit peers [1], or
>> optimizing transaction selection for miners who are willing to enforce the
>> segwit rules but haven't upgraded their systems to mine segwit blocks [2].
>>
>> If we would seek to activate a soft-fork with less clear miner signaling
>> (such as BIP 149), then I think such improvements are warranted to minimize
>> network disruption.  In general, we should not seek to censor hashpower on
>> the network unless we have a very important reason for doing so.  While the
>> issues here are nuanced, if I were to evaluate the BIP 148 soft-fork
>> proposal on the spectrum of "censorship attack on Bitcoin" to "benign
>> protocol upgrade", BIP 148 strikes me as closer to the former than the
>> latter.  There is simply no need here to orphan these non-signalling blocks
>> that could otherwise be used to secure the network.
>>
>> To go further: I think BIP 148 is ill-conceived even for achieving its
>> own presumed goals -- the motivation for adding a consensus rule that
>> applies to the version bits on blocks is surely for the effect such bits
>> have on older software, such as Bitcoin Core releases 0.13.1 and later.
>> Yet in trying to bring those implementations along as segwit-enforcing
>> software, BIP 148 would risk forking from such clients in the short term!
>> If one really cared about maintaining consensus with older, segwit-enabled
>> software, it would make far more sense to seek segwit activation in a way
>> that didn't fork from them (such as BIP 149, or a new BIP 9 deployment
>> after this one times out).  And if one doesn't care about such consensus,
>> then it'd be far simpler to just set (e.g.) August 1 as the flag day
>> activation of segwit, and not play these contortionist games with block
>> version bits, which carry no useful or intrinsic meaning.  Either of these
>> two approaches should have the advantage of reduced fork risk, compared
>> with BIP 148.
>>
>> Of course, everyone is free to run the software of their choosing.  I
>> write this to both generally convey my opposition to a careless proposal,
>> which I believe represents a way of thinking that is detrimental to
>> Bitcoin's long run success, and specifically explain why I oppose inclusion
>> of this proposal in the Bitcoin Core implementation [3].  The Bitcoin Core
>> project hasn't been, and shouldn't be, careless in deploying consensus
>> changes.  Instead, I think the Bitcoin Core project ought to stand up for
>> the best practices that our community has learned about how to deploy such
>> changes (specifically for minimizing chain-split risk when deploying a soft
>> fork!), and I think we should all avoid adoption or encouragement of
>> practices that would depart from the high standards we are capable of
>> achieving.
>>
>>
>>  [1] https://lists.linuxfoundation.org/pipermail/bitcoin-
>> dev/2017-March/013811.html
>>  [2] https://github.com/bitcoin/bitcoin/pull/9955
>>  [3] https://github.com/bitcoin/bitcoin/pull/10428#issuecomment-303098925
>>
>>
>> --Suhas Daftuar
>>
>>
>> On Fri, Apr 14, 2017 at 3:56 AM, Gregory Maxwell via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>>> I do not support the BIP148 UASF for some of the same reasons that I
>>> do support segwit:  Bitcoin is valuable in part because it has high
>>> security and stability, segwit was carefully designed to support and
>>> amplify that engineering integrity that people can count on now and
>>> into the future.
>>>
>>> I do not feel the the approach proposed in BIP148 really measures up
>>> to the standard set by segwit itself, or the existing best practices
>>> in protocol development in this community.
>>>
>>> The primary flaw in BIP148 is that by forcing the activation of the
>>> existing (non-UASF segwit) nodes it almost guarantees at a minor level
>>> of disruption.
>>>
>>> Segwit was carefully engineered so that older unmodified miners could
>>> continue operating _completely_ without interruption after segwit
>>> activates.
>>>
>>> Older nodes will not include segwit spends, and so their blocks will
>>> not be invalid even if they do not have segwit support. They can
>>> upgrade to it on their own schedule. The only risk non-participating
>>> miners take after segwit activation is that if someone else mines an
>>> invalid block they would extend it, a risk many miners already
>>> frequently take with spy-mining.
>>>
>>> I do not think it is a horrible proposal: it is better engineered than
>>> many things that many altcoins do, but just not up to our normal
>>> standards. I respect the motivations of the authors of BIP 148.  If
>>> your goal is the fastest possible segwit activation then it is very
>>> useful to exploit the >80% of existing nodes that already support the
>>> original version of segwit.
>>>
>>> But the fastest support should not be our goal, as a community-- there
>>> is always some reckless altcoin or centralized system that can support
>>> something faster than we can-- trying to match that would only erode
>>> our distinguishing value in being well engineered and stable.
>>>
>>> "First do no harm." We should use the least disruptive mechanisms
>>> available, and the BIP148 proposal does not meet that test.  To hear
>>> some people-- non-developers on reddit and such-- a few even see the
>>> forced orphaning of 148 as a virtue, that it's punitive for
>>> misbehaving miners. I could not not disagree with that perspective any
>>> more strongly.
>>>
>>> Of course, I do not oppose the general concept of a UASF but
>>> _generally_ a soft-fork (of any kind) does not need to risk disruption
>>> of mining, just as segwit's activation does not.  UASF are the
>>> original kind of soft-fork and were the only kind of fork practiced by
>>> Satoshi. P2SH was activated based on a date, and all prior ones were
>>> based on times or heights.  We introduced miner based activation as
>>> part of a process of making Bitcoin more stable in the common case
>>> where the ecosystem is all in harmony.  It's kind of weird to see UASF
>>> portrayed as something new.
>>>
>>> It's important the users not be at the mercy of any one part of the
>>> ecosystem to the extent that we can avoid it-- be it developers,
>>> exchanges, chat forums, or mining hardware makers.  Ultimately the
>>> rules of Bitcoin work because they're enforced by the users
>>> collectively-- that is what makes Bitcoin Bitcoin, it's what makes it
>>> something people can count on: the rules aren't easy to just change.
>>>
>>> There have been some other UASF proposals that avoid the forced
>>> disruption-- by just defining a new witness bit and allowing
>>> non-upgraded-to-uasf miners and nodes to continue as non-upgraded, I
>>> think they are vastly superior. They would be slower to deploy, but I
>>> do not think that is a flaw.
>>>
>>> We should have patience. Bitcoin is a system that should last for all
>>> ages and power mankind for a long time-- ten years from now a couple
>>> years of dispute will seem like nothing. But the reputation we earn
>>> for stability and integrity, for being a system of money people can
>>> count on will mean everything.
>>>
>>> If these discussions come up, they'll come up in the form of reminding
>>> people that Bitcoin isn't easily changed at a whim, even when the
>>> whims are obviously good, and how that protects it from being managed
>>> like all the competing systems of money that the world used to use
>>> were managed. :)
>>>
>>> So have patience, don't take short cuts.  Segwit is a good improvement
>>> and we should respect it by knowing that it's good enough to wait for,
>>> and for however its activated to be done the best way we know how.
>>> _______________________________________________
>>> 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
>>
>>
>
>
> --
> Steven Pine
> (510) 517-7075
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

[-- Attachment #2: Type: text/html, Size: 14648 bytes --]

[bitcoin-dev] I do not support the BIP 148 UASF

[Chris Acheson]

Speaking as one of the BIP148 agitators:

> There have been some other UASF proposals that avoid the forced
> disruption-- by just defining a new witness bit and allowing
> non-upgraded-to-uasf miners and nodes to continue as non-upgraded, I
> think they are vastly superior. They would be slower to deploy, but I
> do not think that is a flaw.

I'm assuming that you're referring to the flag date "segwit is on now"
approach. This is more dangerous than the orphaning approach that BIP148
uses.

If we orphan non-signalling blocks on the flag date and don't have
majority hash power supporting us, there will be a chain split on the
flag day. We expect this to happen, we plan for it, and we employ
strategies to mitigate any damage. The bulk of the economy has
coordinated around this event happening. We even had the opportunity to
pull the plug before the flag date if things were looking too grim.

After the dust settles, 100% of the miners are guaranteed to have
upgraded, assuming they didn't choose to forgo 2+ weeks of income. Any
further chain splits would have to be the result of deliberate action by
51%+ of the mining power.

If we just have segwit activate on the flag date without orphaning the
blocks of non-segwit miners, we set ourselves up for a chain split at
some unknown time in the future. Without majority hash power on our
side, as soon as someone mines a segwit-invalid transaction, the chain
will split, with upgraded nodes and miners on one side, and non-upgraded
nodes and miners on the other side. The segwit-invalid transaction
doesn't even need to come from someone with their own mining equipment.
Open a short on BTC, rent some hash power, profit.

Since we don't know when this attack will occur, we won't be organized
and ready for it. It's also easy for both miners and users to get
complacent about it and fail to upgrade. The damage will be far worse
than if we had used the orphaning approach.

> "First do no harm." We should use the least disruptive mechanisms
> available, and the BIP148 proposal does not meet that test.  To hear
> some people-- non-developers on reddit and such-- a few even see the
> forced orphaning of 148 as a virtue, that it's punitive for
> misbehaving miners. I could not not disagree with that perspective any
> more strongly.

Punitive action against miners is not the point of BIP148, it's an
unavoidable side-effect of making the UASF less disruptive for the users
of Bitcoin. Minimizing disruption for users must take priority over
minimizing disruption for miners. Given the intensity of this dispute
and the bad faith of certain actors, some schadenfreude is bound to
occur. Don't let that distract you from the actual reasons that BIP148
is designed the way it is.

> We should have patience. Bitcoin is a system that should last for all
> ages and power mankind for a long time-- ten years from now a couple
> years of dispute will seem like nothing. But the reputation we earn
> for stability and integrity, for being a system of money people can
> count on will mean everything.

I respect this perspective, and I agree with it to a certain extent.
However, continuing to wait has costs. I do not believe we have the
luxury of continuing to wait for a couple more years. In doing so it's
entirely possible that we may damage our reputation for stability and
integrity rather than build on it.

We have a window of opportunity with BIP148, and it would be a waste not
to act on it. In the event that we still lack sufficient support by
July, we can abandon the project, and make plans for how best to proceed
from there.

Re: [bitcoin-dev] I do not support the BIP 148 UASF

[Mark Friedenbach]

[-- Attachment #1: Type: text/plain, Size: 1193 bytes --]

Greg,

If I understand correctly, the crux of your argument against BIP148 is that
it requires the segwit BIP9 activation flag to be set in every block after
Aug 1st, until segwit activates. This will cause miners which have not
upgrade and indicated support for BIP141 (the segwit BIP) to find their
blocks ignored by UASF nodes, at least for the month or two it takes to
activate segwit.

Isn't this however the entire point of BIP148? I understand if you object
to this, but let's be clear that this is a design requirement of the
proposal, not a technical oversight. The alternative you present (new BIP
bit) has the clear downside of not triggering BIP141 activation, and
therefore not enabling the new consensus rules on already deployed full
nodes. BIP148 is making an explicit choice to favor dragging along those
users which have upgraded to BIP141 support over those miners who have
failed to upgrade.

On an aside, I'm somewhat disappointed that you have decided to make a
public statement against the UASF proposal. Not because we disagree -- that
is fine -- but because any UASF must be a grassroots effort and
endorsements (or denouncements) detract from that.

Mark Friedenbach

[-- Attachment #2: Type: text/html, Size: 1608 bytes --]

Re: [bitcoin-dev] I do not support the BIP 148 UASF

[Ryan Grant]

On Sat, Apr 15, 2017 at 8:42 AM, Mark Friedenbach via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> The alternative [Greg presents] (new BIP bit) has the clear downside
> of not triggering BIP141 activation, and therefore not enabling the
> new consensus rules on already deployed full nodes. BIP148 is making
> an explicit choice to favor dragging along those users which have
> upgraded to BIP141 support over those miners who have failed to
> upgrade.

A proposal from yesterday would separate this concern; though not
retroactively.  One way to name this proposal would be "Catch-All
Segwit Activation".

  "extended BIP9 activation of segwit, for legacy nodes"
  https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-April/014160.html

If this release valve exists, then discussions (such as this thread)
can get back to focusing on finding the safest incentive-compatible
transitions, with time improving the situation instead of making it worse.

Re: [bitcoin-dev] I do not support the BIP 148 UASF

[Gregory Maxwell]

[-- Attachment #1: Type: text/plain, Size: 1181 bytes --]

On Sat, Apr 15, 2017 at 1:42 PM, Mark Friedenbach via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> triggering BIP141 activation, and therefore not enabling the new consensus
> rules on already deployed full nodes. BIP148 is making an explicit choice
> to favor dragging along those users which have upgraded to BIP141 support
> over those miners who have failed to upgrade.
>

I do not follow the argument that a critical design feature of a particular
"user activated soft fork" could be that it is users don't need to be
involved.  If the goal is user activation I would think that the
expectation would be that the overwhelming majority of users would be
upgrading to do it, if that isn't the case, then it isn't really a user
activated softfork-- it's something else.


> On an aside, I'm somewhat disappointed that you have decided to make a
> public statement against the UASF proposal. Not because we disagree -- that
> is fine -- but because any UASF must be a grassroots effort and
> endorsements (or denouncements) detract from that.
>

So it has to be supported by the public but I can't say why I don't support
it? This seems extremely suspect to me.

[-- Attachment #2: Type: text/html, Size: 1894 bytes --]

Re: [bitcoin-dev] I do not support the BIP 148 UASF

[Erik Aronesty]

[-- Attachment #1: Type: text/plain, Size: 1688 bytes --]

The "UASF movement" seems a bit premature to me - I doubt UASF will be
necessary if a WTXID commitment is tried first.   I think that should be
first-efforts focus.

On Sat, Apr 15, 2017 at 2:50 PM, Gregory Maxwell via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Sat, Apr 15, 2017 at 1:42 PM, Mark Friedenbach via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> triggering BIP141 activation, and therefore not enabling the new
>> consensus rules on already deployed full nodes. BIP148 is making an
>> explicit choice to favor dragging along those users which have upgraded to
>> BIP141 support over those miners who have failed to upgrade.
>>
>
> I do not follow the argument that a critical design feature of a
> particular "user activated soft fork" could be that it is users don't need
> to be involved.  If the goal is user activation I would think that the
> expectation would be that the overwhelming majority of users would be
> upgrading to do it, if that isn't the case, then it isn't really a user
> activated softfork-- it's something else.
>
>
>> On an aside, I'm somewhat disappointed that you have decided to make a
>> public statement against the UASF proposal. Not because we disagree -- that
>> is fine -- but because any UASF must be a grassroots effort and
>> endorsements (or denouncements) detract from that.
>>
>
> So it has to be supported by the public but I can't say why I don't
> support it? This seems extremely suspect to me.
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

[-- Attachment #2: Type: text/html, Size: 2974 bytes --]

Re: [bitcoin-dev] I do not support the BIP 148 UASF

[Alphonse Pace]

[-- Attachment #1: Type: text/plain, Size: 2090 bytes --]

A WTXID commitment would (likely) need to be a UASF.


On Wed, Apr 19, 2017 at 11:17 AM, Erik Aronesty via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> The "UASF movement" seems a bit premature to me - I doubt UASF will be
> necessary if a WTXID commitment is tried first.   I think that should be
> first-efforts focus.
>
> On Sat, Apr 15, 2017 at 2:50 PM, Gregory Maxwell via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> On Sat, Apr 15, 2017 at 1:42 PM, Mark Friedenbach via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>>> triggering BIP141 activation, and therefore not enabling the new
>>> consensus rules on already deployed full nodes. BIP148 is making an
>>> explicit choice to favor dragging along those users which have upgraded to
>>> BIP141 support over those miners who have failed to upgrade.
>>>
>>
>> I do not follow the argument that a critical design feature of a
>> particular "user activated soft fork" could be that it is users don't need
>> to be involved.  If the goal is user activation I would think that the
>> expectation would be that the overwhelming majority of users would be
>> upgrading to do it, if that isn't the case, then it isn't really a user
>> activated softfork-- it's something else.
>>
>>
>>> On an aside, I'm somewhat disappointed that you have decided to make a
>>> public statement against the UASF proposal. Not because we disagree -- that
>>> is fine -- but because any UASF must be a grassroots effort and
>>> endorsements (or denouncements) detract from that.
>>>
>>
>> So it has to be supported by the public but I can't say why I don't
>> support it? This seems extremely suspect to me.
>>
>>
>>
>> _______________________________________________
>> 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
>
>

[-- Attachment #2: Type: text/html, Size: 3940 bytes --]

Re: [bitcoin-dev] I do not support the BIP 148 UASF

[Erik Aronesty]

[-- Attachment #1: Type: text/plain, Size: 2865 bytes --]

Bitcoin must level the playing field for mining or it is fundamentally
broken.   And there are two obvious solutions:

1. WTXID commitment has as a flag day upgrade. It's a fix to a fairly
serious security issue - made even worse by the existence of patents on the
code.

2. Embed the code for performing a covert ASICBOOST into Bitcoin core's
reference implementation.   But, since this would violate patents held in
China and the U.S., it could be a problem.

Of these, I think the first should be far less controversial.

One or the other must be done - if we can't fix security and licensing
problems in Bitcoin, what can we fix?


On Thu, Apr 20, 2017 at 10:23 AM, Alphonse Pace <alp.bitcoin@gmail.com>
wrote:

> A WTXID commitment would (likely) need to be a UASF.
>
>
> On Wed, Apr 19, 2017 at 11:17 AM, Erik Aronesty via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> The "UASF movement" seems a bit premature to me - I doubt UASF will be
>> necessary if a WTXID commitment is tried first.   I think that should be
>> first-efforts focus.
>>
>> On Sat, Apr 15, 2017 at 2:50 PM, Gregory Maxwell via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>>> On Sat, Apr 15, 2017 at 1:42 PM, Mark Friedenbach via bitcoin-dev <
>>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>>
>>>> triggering BIP141 activation, and therefore not enabling the new
>>>> consensus rules on already deployed full nodes. BIP148 is making an
>>>> explicit choice to favor dragging along those users which have upgraded to
>>>> BIP141 support over those miners who have failed to upgrade.
>>>>
>>>
>>> I do not follow the argument that a critical design feature of a
>>> particular "user activated soft fork" could be that it is users don't need
>>> to be involved.  If the goal is user activation I would think that the
>>> expectation would be that the overwhelming majority of users would be
>>> upgrading to do it, if that isn't the case, then it isn't really a user
>>> activated softfork-- it's something else.
>>>
>>>
>>>> On an aside, I'm somewhat disappointed that you have decided to make a
>>>> public statement against the UASF proposal. Not because we disagree -- that
>>>> is fine -- but because any UASF must be a grassroots effort and
>>>> endorsements (or denouncements) detract from that.
>>>>
>>>
>>> So it has to be supported by the public but I can't say why I don't
>>> support it? This seems extremely suspect to me.
>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>>
>>
>

[-- Attachment #2: Type: text/html, Size: 5164 bytes --]