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

[Mark Friedenbach via bitcoin-dev]

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
___
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

[Greg Sanders via bitcoin-dev]

> 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
>
>
___
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

[Natanael via bitcoin-dev]

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

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

[Chris Acheson via bitcoin-dev]

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.
___
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

[Cameron Garnham via bitcoin-dev]

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  wrote:
> 
> On Sat, Apr 15, 2017 at 6:28 AM, Cameron Garnham  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. :)

___
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 via bitcoin-dev]

On Sat, Apr 15, 2017 at 6:28 AM, Cameron Garnham  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. :)
___
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

[Cameron Garnham via bitcoin-dev]

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 
>  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