📅 Original date posted:2017-05-30
📝 Original message:- We now are witnessing this... COOP vs LukeJr COOP, vs BIP148 vs BIP149 vs
BIP91 ... how many are there?:
https://xkcd.com/927
- If some miners and exchanges collude to enact a rapid 2MB+Segwit hard
fork coin... and calling it "bitcoin" on major exchanges this could swiftly
fragment the network.
- If this fork fails to contain an ASICBOOST defense, then this is
essentially an example of core failing to appropriately respond to the CVE
security vulnerability in time.
- A swift BIP148 release in core seems necessary to defend against this.
I am no longer in favor of adding a BIP148 option with default "false"..
I think it should be merged in...enabled, and released ASAP to defend
against these attacks.
On Mon, May 29, 2017 at 7:49 PM, Oliver Petruzel via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> >>if the community wishes to adopt (by unanimous consensus) a 2 MB block
> size hardfork, this is probably the best way to do it right now... Legacy
> Bitcoin transactions are given the witness discount, and a block size limit
> of 2 MB is imposed.<<
>
>
> The above decision may quickly become very controversial. I don't think it's
> what most users had/have in mind when they discuss a "2MB+SegWit" solution.
>
> With the current 1MB+SegWit, testing has shown us that normal usage
> results in ~2 or 2.1MB blocks.
>
> I think most users will expect a linear increase when Base Size is
> increased to 2000000 bytes and Total Weight is increased to 8000000 bytes.
> With normal usage, the expected results would then be ~4 or 4.2MB blocks.
>
> Am I missing something here, or does Luke's suggested 2MB cap completely
> nullify that expected linear increase? If so, why? What's the logic behind
> this decision?
>
> I'd love to be armed with a good answer should my colleagues ask me the
> same obvious question, so thank you ahead of time!
>
> Respectfully,
> Oliver Petruzel
>
>
>
> _______________________________________________
> 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/20170530/127b8af6/attachment-0001.html>;
Erik Aronesty [ARCHIVE] /
npub1y2…5taj0
2023-06-07 18:02:00
in reply to nevent1q…slwn
Author Public Key
npub1y22yec0znyzw8qndy5qn5c2wgejkj0k9zsqra7kvrd6cd6896z4qm5taj0Published at
2023-06-07 18:02:00Event JSON
{
"id": "46a8b9a4193fad0088aa183bb11da4cca696c3e894e52ef361ecf462750763dc",
"pubkey": "22944ce1e29904e3826d25013a614e4665693ec514003efacc1b7586e8e5d0aa",
"created_at": 1686160920,
"kind": 1,
"tags": [
[
"e",
"ccc6e3c96b1f8e9c851874b13a34ae6d02225fb40b90f324de2248a35a9d7c41",
"",
"root"
],
[
"e",
"8ceccfed4a03aaa294e13bd38bf648c71366d8ba86249e0c887688a52a7fc019",
"",
"reply"
],
[
"p",
"b154095dcfd4a38dc9c97341b6488b66574c38e9c4207d396b236f23600b276a"
]
],
"content": "📅 Original date posted:2017-05-30\n📝 Original message:- We now are witnessing this... COOP vs LukeJr COOP, vs BIP148 vs BIP149 vs\nBIP91 ... how many are there?:\n\nhttps://xkcd.com/927\n\n- If some miners and exchanges collude to enact a rapid 2MB+Segwit hard\nfork coin... and calling it \"bitcoin\" on major exchanges this could swiftly\nfragment the network.\n\n- If this fork fails to contain an ASICBOOST defense, then this is\nessentially an example of core failing to appropriately respond to the CVE\nsecurity vulnerability in time.\n\n- A swift BIP148 release in core seems necessary to defend against this.\nI am no longer in favor of adding a BIP148 option with default \"false\"..\nI think it should be merged in...enabled, and released ASAP to defend\nagainst these attacks.\n\n\nOn Mon, May 29, 2017 at 7:49 PM, Oliver Petruzel via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e \u003e\u003eif the community wishes to adopt (by unanimous consensus) a 2 MB block\n\u003e size hardfork, this is probably the best way to do it right now... Legacy\n\u003e Bitcoin transactions are given the witness discount, and a block size limit\n\u003e of 2 MB is imposed.\u003c\u003c\n\u003e\n\u003e\n\u003e The above decision may quickly become very controversial. I don't think it's\n\u003e what most users had/have in mind when they discuss a \"2MB+SegWit\" solution.\n\u003e\n\u003e With the current 1MB+SegWit, testing has shown us that normal usage\n\u003e results in ~2 or 2.1MB blocks.\n\u003e\n\u003e I think most users will expect a linear increase when Base Size is\n\u003e increased to 2000000 bytes and Total Weight is increased to 8000000 bytes.\n\u003e With normal usage, the expected results would then be ~4 or 4.2MB blocks.\n\u003e\n\u003e Am I missing something here, or does Luke's suggested 2MB cap completely\n\u003e nullify that expected linear increase? If so, why? What's the logic behind\n\u003e this decision?\n\u003e\n\u003e I'd love to be armed with a good answer should my colleagues ask me the\n\u003e same obvious question, so thank you ahead of time!\n\u003e\n\u003e Respectfully,\n\u003e Oliver Petruzel\n\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\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170530/127b8af6/attachment-0001.html\u003e",
"sig": "6b70e12658e0af2ed3e744b86d5d7b296e6bca805fa627071cb39ee916a85535e3188f206fe4169964f73fd870a7f1b108c07654973e4674b28a84b562c57f88"
}