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 risk, so yes, this is about
>> protecting u
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
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 when used. Who are we protecting users from
> 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 s
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 p
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 di
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 Grego
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 bro
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 about as a
> way to satify many
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 wa
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 perfo
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 thin
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, 2
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
On Sat, Apr 15, 2017 at 8:42 AM, Mark Friedenbach via bitcoin-dev
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
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 thei
> 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 ju
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 [m
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 f
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 mine
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 ultima
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
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
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 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
>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
> 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,
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
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 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 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 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 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 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
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 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
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
>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
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
39 matches
Mail list logo