[bitcoin-dev] A Segwit2x BIP

[Charlie 'Charles' Shrem]

Andrew,

Block 475776 and block 477792 (July 26) are the last 2 difficulty
adjustment periods before Aug 1st.

Charlie

On Thu, Jul 13, 2017 at 3:48 PM, Andrew Chow via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> What's special about block 475776?
>
> On July 13, 2017 12:23:46 PM Sergio Demian Lerner via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> The BIP has been updated.
>>
>> Changes:
>> - The technical spec has been improved: now the block size increase is
>> specified in terms of weight and not in terms of bytes.
>> - The increase in the maximum block sigops after HF has been documented.
>> - Comments added about the worst case block size.
>>
>> Happy weekend! And don't forget to start signaling something before block
>> 475776 !  It's just 90 blocks away.
>> Bit 1 or 4,1 or whatever you wish, but please signal something.
>>
>> To the moon!
>>
>>
>> On Wed, Jul 12, 2017 at 2:38 PM, Jorge Timón via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>>
>>>
>>> On 12 Jul 2017 2:31 pm, "Tom Zander via bitcoin-dev" <
>>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>
>>> On Monday, 10 July 2017 20:38:08 CEST Jorge Timón via bitcoin-dev wrote:
>>> > I think anything less than 1 year after release of tested code by some
>>> > implementation would be irresponsible for any hardfork, even a very
>>> > simple one.
>>>
>>> Good news!
>>>
>>> Code to support 2x (the hard fork part of the proposal) has been out and
>>> tested for much longer than that.
>>>
>>>
>>> Not true. It's different code on top of segwit. The first attempt in
>>> btc1 (very recent) didn't even increased the size (because it changed the
>>> meaningless "base size" without touching the weight limit. As for the
>>> current code, I don't think it has been properly tested today, let alone
>>> "for mucj longer than 1 year.
>>> Anyway, I said, one year from tested release. Segwitx2 hasn't been
>>> released, has it? If so, too late to discuss a bip imo, the bip may end up
>>> being different from what has been released due to feedback (unless it is
>>> ignored again, of course).
>>>
>>>
>>> --
>>> Tom Zander
>>> Blog: https://zander.github.io
>>> Vlog: https://vimeo.com/channels/tomscryptochannel
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>>
>>>
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170713/6321b907/attachment.html>