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 no
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 c
>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 communit
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
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
B
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 sc
On Fri, Apr 14, 2017 at 2:20 PM, Tom Zander via bitcoin-dev
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
>> acti
Thinking about this a bit, I support this proposal for a BIP.
This is not Bitcoin, but address types are bound to meet in meat-space and
it would be good to have a central place where this is defined.
I would very much appreciate someone that worked on BIP32/BIP43 itself to
comment on the detail
Segwit has proven more contentious to activate than anticipated
(although my read has long been that the technical consensus is clear,
despite noisy objections). No matter which method is used to
eventually activate segwit, or on what timeline, it would be
beneficial if validating nodes already ca
You might be interested in my bip-uaversionbits proposal
https://github.com/shaolinfry/bips/blob/bip-uavb/bip-uaversionbits.mediawiki
Segwit has proven more contentious to activate than anticipated
(although my read has long been that the technical consensus is clear,
despite noisy objections). N
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
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, I'll explain.
>
> A pol
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 commended for correcting your misinformation.
>
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
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 that Gregory was incorrect saying that ther
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 the tests, though there
have been a coup
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
> 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,
>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 *coul
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? That is _absurd_ and untrue, and I
strug
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
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 is ever
abandoned (e.g. b
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 wor
23 matches
Mail list logo
