{"type":"rich","version":"1.0","author_name":"npub1pl6kcz00s7wgn6syh73dta0qm9sqpmtw4adv8rnm2w9fmynkw45sayj0hj","author_url":"https://nostr.ae/npub1pl6kcz00s7wgn6syh73dta0qm9sqpmtw4adv8rnm2w9fmynkw45sayj0hj","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-12-08\n📝 Original message:On Dec 8, 2015, at 6:02 AM, Gregory Maxwell via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e The particular proposal amounts to a 4MB blocksize increase at worst.\n\nI understood that SegWit would allow about 1.75 MB of data in the average case while also allowing up to 4 MB of data in the worst case. This means that the mining and block distribution network would need a larger safety factor to deal with worst-case situations, right? If you want to make sure that nothing goes wrong when everything is at its worst, you need to size your network pipes to handle 4 MB in a timely (DoS-resistant) fashion, but you'd normally only be able to use 1.75 MB of it. It seems to me that it would be safer to use a 3 MB limit, and that way you'd also be able to use 3 MB of actual transactions.\n\nAs an accounting trick to bypass the 1 MB limit, SegWit sounds like it might make things less well accounted for.\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151209/a0eca647/attachment.html\u003e\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 496 bytes\nDesc: Message signed with OpenPGP using GPGMail\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151209/a0eca647/attachment.sig\u003e"}