📅 Original date posted:2017-05-31
📝 Original message:Maybe there's some hole in Jorge's logic and scrapping blockmaxsize has
quadratic hashing risks, and maybe James' 10KB is too ambitious; but even
if so, a simple 1MB tx size limit would clearly do the trick. The broader
point is that quadratic hashing is not a compelling reason to keep
blockmaxsize post-HF: does someone have a better one?
On May 30, 2017 9:46 PM, "Jean-Paul Kogelman via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> That would invalidate any pre-signed transactions that are currently out
> there. You can't just change the rules out from under people.
>
>
> On May 30, 2017, at 4:50 PM, James MacWhyte via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>
>
>> The 1MB classic block size prevents quadratic hashing
>> problems from being any worse than they are today.
>>
>>
> Add a transaction-size limit of, say, 10kb and the quadratic hashing
> problem is a non-issue. Donezo.
>
> _______________________________________________
> 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/20170530/a232820b/attachment.html>;
Jacob Eliosoff [ARCHIVE] /
npub1ml…4yf8d
2023-06-07 18:01:50
in reply to nevent1q…zuut
Author Public Key
npub1mlpmsc5sm93tw2fp2dhhuwmxcqm59wz6hjg5g3afq5rucfll3f9sh4yf8dPublished at
2023-06-07 18:01:50Event JSON
{
"id": "ac13c5d378bad5a173b449846a4f971f1fdeaca1d1111256ecd36ab53976ab10",
"pubkey": "dfc3b86290d962b72921536f7e3b66c03742b85abc914447a90507cc27ff8a4b",
"created_at": 1686160910,
"kind": 1,
"tags": [
[
"e",
"73fcf5be84fca4568a5398ecee91a18c841c9abc02915b258aa02af58b0a4b4a",
"",
"root"
],
[
"e",
"023fa00dbd0da1d1726b4449aa261075185f87e64df394313e8a64467ca850b1",
"",
"reply"
],
[
"p",
"874fa44d110b2119208ba6fb27607799f16a00c82143201ad7f179a89f0df349"
]
],
"content": "📅 Original date posted:2017-05-31\n📝 Original message:Maybe there's some hole in Jorge's logic and scrapping blockmaxsize has\nquadratic hashing risks, and maybe James' 10KB is too ambitious; but even\nif so, a simple 1MB tx size limit would clearly do the trick. The broader\npoint is that quadratic hashing is not a compelling reason to keep\nblockmaxsize post-HF: does someone have a better one?\n\n\nOn May 30, 2017 9:46 PM, \"Jean-Paul Kogelman via bitcoin-dev\" \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e That would invalidate any pre-signed transactions that are currently out\n\u003e there. You can't just change the rules out from under people.\n\u003e\n\u003e\n\u003e On May 30, 2017, at 4:50 PM, James MacWhyte via bitcoin-dev \u003c\n\u003e bitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\n\u003e\n\u003e\n\u003e\u003e The 1MB classic block size prevents quadratic hashing\n\u003e\u003e problems from being any worse than they are today.\n\u003e\u003e\n\u003e\u003e\n\u003e Add a transaction-size limit of, say, 10kb and the quadratic hashing\n\u003e problem is a non-issue. Donezo.\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\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/a232820b/attachment.html\u003e",
"sig": "9ec43616ad752f369686766601e49362e3bfaef5513e3420ad7acafe9c9b338c642eafd157ebedd5e2c6c51479ef8058def9c70ce982da212b6bfafed81dffc7"
}