Andrew Chow [ARCHIVE] on Nostr: 📅 Original date posted:2017-07-13 📝 Original message:What's special about block ...
📅 Original date posted:2017-07-13
📝 Original message: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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170713/0c5c6106/attachment-0001.html>;
📝 Original message: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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170713/0c5c6106/attachment-0001.html>;