📅 Original date posted:2017-05-09 📝 Original message:Doing a second soft-fork ...

James Hilliard [ARCHIVE] /

npub10r9…gk2d

2023-06-07 18:00:58

in reply to nevent1q…9a6j

📅 Original date posted:2017-05-09
📝 Original message:Doing a second soft-fork from 50% to 75% sounds more difficult since
that's going from a more restrictive ruleset to less restrictive, you
might be able to hack around it but it wouldn't be a fully backwards
compatible change like going from 75% to 50% would be. 50% vs 75% does
affect max transactions/second in practice, the exact amount depends
on the real world usage of course though.

On Tue, May 9, 2017 at 11:19 AM, Sergio Demian Lerner via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> Thanks Johnson and Hampus for the clarifications.
> However, I would rather do the opposite: soft-fork to 50% now, and soft-fork
> again to 75% discount later if needed, because it doesn't affect the max
> transactions/second.
>
> Segwit as it is today should be activated. However if it is not before
> November, then for the next Segwit attempt I would choose a more
> conservative 50% discount.
>
>
>
> On Tue, May 9, 2017 at 12:45 PM, Johnson Lau <jl2012 at xbt.hk> wrote:
>>
>>
>> > On 9 May 2017, at 21:49, Sergio Demian Lerner via bitcoin-dev
>> > <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> >
>> >
>> > So it seems the 75% discount has been chosen with the idea that in the
>> > future the current transaction pattern will shift towards multisigs. This is
>> > not a bad idea, as it's the only direction Bitcoin can scale without a HF.
>> > But it's a bad idea if we end up doing, for example, a 2X blocksize
>> > increase HF in the future. In that case it's much better to use a 50%
>> > witness discount, and do not make scaling risky by making the worse case
>> > block size 8 Mbytes, when it could have been 2*2.7=5.4 Mbytes.
>> >
>>
>> As we could change any parameter in a hardfork, I don’t think this has any
>> relation with the current BIP141 proposal. We could just use 75% in a
>> softfork, and change that to a different value (or completely redefine the
>> definition of weight) with a hardfork later.
>>
>>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

Author Public Key

npub10r9d6edmnrljk59wsf06zqp494l3qtjpa3w245hy6t5euqxlzw2qdkgk2d

Show more details

Published at

2023-06-07 18:00:58

Kind type

1 Short Text Note

Event JSON

{ "id": "e3cea5c6bc41a9585aff42f9aca6ff28e5235030934a29e19577b696772b5f61", "pubkey": "78cadd65bb98ff2b50ae825fa100352d7f102e41ec5caad2e4d2e99e00df1394", "created_at": 1686160858, "kind": 1, "tags": [ [ "e", "4aacc31e765e9e31a3d8eb41d296ff5dc213462528e2e5335cec5ccb80e70465", "", "root" ], [ "e", "9990d5d8aa0fee0acf5707cc71ed7e0826c98bcb26e966caa24db8b76aa0a366", "", "reply" ], [ "p", "492fa402e838904bdc8eb2c8fafa1aa895df26438bfd998c71b01cb9db550ff7" ] ], "content": "📅 Original date posted:2017-05-09\n📝 Original message:Doing a second soft-fork from 50% to 75% sounds more difficult since\nthat's going from a more restrictive ruleset to less restrictive, you\nmight be able to hack around it but it wouldn't be a fully backwards\ncompatible change like going from 75% to 50% would be. 50% vs 75% does\naffect max transactions/second in practice, the exact amount depends\non the real world usage of course though.\n\nOn Tue, May 9, 2017 at 11:19 AM, Sergio Demian Lerner via bitcoin-dev\n\u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e Thanks Johnson and Hampus for the clarifications.\n\u003e However, I would rather do the opposite: soft-fork to 50% now, and soft-fork\n\u003e again to 75% discount later if needed, because it doesn't affect the max\n\u003e transactions/second.\n\u003e\n\u003e Segwit as it is today should be activated. However if it is not before\n\u003e November, then for the next Segwit attempt I would choose a more\n\u003e conservative 50% discount.\n\u003e\n\u003e\n\u003e\n\u003e On Tue, May 9, 2017 at 12:45 PM, Johnson Lau \u003cjl2012 at xbt.hk\u003e wrote:\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e \u003e On 9 May 2017, at 21:49, Sergio Demian Lerner via bitcoin-dev\n\u003e\u003e \u003e \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\u003e \u003e\n\u003e\u003e \u003e\n\u003e\u003e \u003e So it seems the 75% discount has been chosen with the idea that in the\n\u003e\u003e \u003e future the current transaction pattern will shift towards multisigs. This is\n\u003e\u003e \u003e not a bad idea, as it's the only direction Bitcoin can scale without a HF.\n\u003e\u003e \u003e But it's a bad idea if we end up doing, for example, a 2X blocksize\n\u003e\u003e \u003e increase HF in the future. In that case it's much better to use a 50%\n\u003e\u003e \u003e witness discount, and do not make scaling risky by making the worse case\n\u003e\u003e \u003e block size 8 Mbytes, when it could have been 2*2.7=5.4 Mbytes.\n\u003e\u003e \u003e\n\u003e\u003e\n\u003e\u003e As we could change any parameter in a hardfork, I don’t think this has any\n\u003e\u003e relation with the current BIP141 proposal. We could just use 75% in a\n\u003e\u003e softfork, and change that to a different value (or completely redefine the\n\u003e\u003e definition of weight) with a hardfork later.\n\u003e\u003e\n\u003e\u003e\n\u003e\n\u003e\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e", "sig": "13831a646ebbef8a1d2234a05edf8dea6bff3d90fa297ce350d261402bb811b36466814eae7db6a71333ad8ebc7d6014b4a55391f11fcaaf463ab62b99f3541d" }