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

On Tue, May 23, 2017 at 2:55 PM, Luke Dashjr via bitcoin-dev 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

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

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

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

On Tue, May 23, 2017 at 1:03 PM, Steven Pine via bitcoin-dev 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

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

> 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

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

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

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

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

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

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

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

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

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

On Thu, Apr 20, 2017 at 6:39 PM, shaolinfry 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

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

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

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

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

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

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

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

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,

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

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

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

> 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

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

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

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

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

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

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

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

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

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

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

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

On Sat, Apr 15, 2017 at 4:10 AM, Steven Pine 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

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

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

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

On Sat, Apr 15, 2017 at 2:01 AM, Steven Pine via bitcoin-dev 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?

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

>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

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

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

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

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

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

On Fri, Apr 14, 2017 at 9:10 PM, James Hilliard via bitcoin-dev 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

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

On Fri, Apr 14, 2017 at 3:58 PM, Tom Zander via bitcoin-dev 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

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

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

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

On Fri, Apr 14, 2017 at 8:34 PM, Tom Zander via bitcoin-dev 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

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

On Fri, Apr 14, 2017 at 3:34 PM, Tom Zander 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,

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

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

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

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

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

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

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

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

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

>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

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

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

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

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