[Bitcoin-segwit2x] segwit2x rc Version 1.14.4 released

Tue Jul 18 22:08:12 UTC 2017

> I don't agree with you that Miners are the one setting the rules here.

That's a philosophical opinion, and one you're welcome to.  Your question
was about my technical perspective, which I answered.  I'm happy to explain
why, in this particular case(but not all cases), the game theory favors the
miners, but it is straying off topic.  Peter's proposals that are not in
line with the philosophy of supporting this charter don't serve a purpose
here.

Jared

On Jul 18, 2017 5:53 PM, "Marcel Jamin" <marcel at jamin.net> wrote:

> I don't agree with you that Miners are the one setting the rules here.
>
>
> On 18 July 2017 at 22:59, Jared Lee Richardson <jaredr26 at gmail.com> wrote:
>
>> > on a technical level you cannot guarantee that the hard fork happens 3
>> months after segwit
>>
>> I feel that if this supermajority of miners(~90% or more) holds to their
>> agreements, the hardfork should be able to be guaranteed from a technical
>> perspective.  <10% of the hashrate will have a very difficult time reaching
>> the first difficulty change without defections, and every defection will
>> make the legacy chain that much less viable.
>>
>> Can I guarantee that the miners that signed/signaled for s2x will follow
>> through?  Of course not.  And if that happens, segwit2x is definitely in
>> danger and may fail.  Honestly though, if that happens though, drastically
>> different steps will have to be taken.  At that moment bitcoin will be
>> splitting, perhaps forever.  I see segwit2x as a last ditch effort to avoid
>> a permanent split, and I wish Core would see that too.
>>
>> If we proceed under the assumption that segwit2x will be the permanent
>> split... Well, frankly that sucks, and segwit2x is probably the wrong split
>> for us to even be trying.  If what you describe is truly what will happen,
>> the best bet is not segwit2x/segwit-only, it's bitcoin ABC or BU vs
>> segwit/core.
>>
>> Ergo, I don't see any value in assuming that segwit2x will not have that
>> supermajority.  That theory warrants an entirely different project than
>> this one.
>>
>> Jared
>>
>> On Jul 18, 2017 4:28 PM, "Marcel Jamin" <marcel at jamin.net> wrote:
>>
>> Regardless of what the stated goals of this list are, on a technical
>> level you cannot guarantee that the hard fork happens 3 months after segwit
>> activation, wouldn't you agree?
>>
>> On 18 July 2017 at 18:06, Jared Lee Richardson via Bitcoin-segwit2x <
>> bitcoin-segwit2x at lists.linuxfoundation.org> wrote:
>>
>>> > The agreement is quite irrelevant
>>>
>>> On this list, the agreement is not irrelevant.  This list exists for the
>>> sole purpose of fulfilling the agreement; what other "experts" are
>>> recommending or doing is also not going to change the purpose of the list,
>>> and neither will other projects or tweets.
>>>
>>> I am reminded also that you yourself signed an agreement in January
>>> 2016...
>>>
>>> "This hard-fork is expected to include [..] an increase in the
>>> non-witness data to be around 2 MB"
>>>
>>> "We will run a SegWit release in production by the time such a hard-fork
>>> is released in a version of Bitcoin Core."
>>>
>>> "If there is strong community support, the hard-fork activation will
>>> likely happen around July 2017."
>>>
>>> https://medium.com/@bitcoinroundtable/bitcoin-roundtable-con
>>> sensus-266d475a61ff
>>>
>>> The purpose of the agreement in this email list is largely the same as
>>> the agreement you signed, yet still you fight against the hardfork.  I'm
>>> not sure how you justify that to yourself, but the words in both, as well
>>> as the requirements that this list support the goals of coupled activation
>>> seem to be crystal clear.
>>>
>>> Jared
>>>
>>> On Jul 18, 2017 11:17 AM, "Peter Todd" <pete at petertodd.org> wrote:
>>>
>>> On Tue, Jul 18, 2017 at 08:10:17AM -0700, Jared Lee Richardson wrote:
>>> > > But anyway, let's take you at face value: that makes it clear that
>>> bit-4
>>> > is
>>> > *not* intended to be the segwit2x activation, just a way to activate
>>> segwit
>>> > at
>>> > 80% hashing power.
>>> >
>>> > You're still trying to convince yourself and others that the hardfork
>>> and
>>> > the segwit2x activation are separate or separable.  They are one and
>>> the
>>> > same, no matter what other people do or say.  Go re-read the agreement
>>> > please.
>>>
>>> The agreement is quite irrelevant: nothing stops miners from activating
>>> segwit
>>> via bit-4, and ignoring the hard-fork. In fact, it's highly likely that a
>>> majority of miners aren't running the btc1 codebase - among other things
>>> they're producing blocks inconsistent with btc1.
>>>
>>> After all, segsignal exists, which is core+bip91:
>>> https://github.com/segsignal/bitcoin
>>>
>>> It's much less complex than btc1, so it's no surprise that experts like
>>> Charlie
>>> Lee are recommending miners run it.
>>>
>>> The only thing that'll make the agreement relevant is if users decide to
>>> run
>>> it.
>>>
>>> --
>>> https://petertodd.org 'peter'[:-1]@petertodd.org
>>>
>>>
>>>
>>> _______________________________________________
>>> Bitcoin-segwit2x mailing list
>>> Bitcoin-segwit2x at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x
>>>
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-segwit2x/attachments/20170718/03139569/attachment.html>