📅 Original date posted:2015-05-30
📝 Original message:> or achieving less than great DOS protection
Right now a bunch of redditors can DOS the network at the cost of a few
thousand dollars per day, shared between them. Since the cost of validating
transactions is far lower than current minimum relay fees, then increasing
the block size increases the cost of DOSing the network.
Aaron Voisine
co-founder and CEO
breadwallet.com
On Fri, May 29, 2015 at 10:53 AM, Admin Istrator <andy at ftlio.com> wrote:
> What about trying the dynamic scaling method within the 20MB range + 1
> year with a 40% increase of that cap? Until a way to dynamically scale is
> found, the cap will only continue to be an issue. With 20 MB + 40% yoy,
> we're either imposing an arbitrary cap later, or achieving less than great
> DOS protection always. Why not set that policy as a maximum for 2 years as
> a protection against the possibility of dynamic scaling abuse, and see what
> happens with a dynamic method in the mean time. The policy of Max(1MB,
> (average size over previous 144 blocks) * 2) calculated at each block seems
> pretty reasonable.
>
> As an outsider, the real 'median' here seems to be 'keeping the cap as
> small as possible while allowing for larger blocks still'. We know
> miners will want to keep space in their blocks relatively scarce, but we
> also know that doesn't exclude the more powerful miners from
> including superfluous transactions to increase their effective share of the
> network. I have the luck of not being drained by this topic over the past
> three years, so it looks to me as if its two poles of 'block size must
> increase' and 'block size must not increase' are forcing what is the clear
> route to establishing the 'right' block size off the table.
>
> --Andrew Len
> (sorry if anybody received this twice, sent as the wrong email the first
> time around).
>
> On Fri, May 29, 2015 at 5:39 AM, Gavin Andresen <gavinandresen at gmail.com>
> wrote:
>
>> What do other people think?
>>
>>
>> If we can't come to an agreement soon, then I'll ask for help
>> reviewing/submitting patches to Mike's Bitcoin-Xt project that implement a
>> big increase now that grows over time so we may never have to go through
>> all this rancor and debate again.
>>
>> I'll then ask for help lobbying the merchant services and exchanges and
>> hosted wallet companies and other bitcoind-using-infrastructure companies
>> (and anybody who agrees with me that we need bigger blocks sooner rather
>> than later) to run Bitcoin-Xt instead of Bitcoin Core, and state that they
>> are running it. We'll be able to see uptake on the network by monitoring
>> client versions.
>>
>> Perhaps by the time that happens there will be consensus bigger blocks
>> are needed sooner rather than later; if so, great! The early deployment
>> will just serve as early testing, and all of the software already deployed
>> will ready for bigger blocks.
>>
>> But if there is still no consensus among developers but the "bigger
>> blocks now" movement is successful, I'll ask for help getting big miners to
>> do the same, and use the soft-fork block version voting mechanism to
>> (hopefully) get a majority and then a super-majority willing to produce
>> bigger blocks. The purpose of that process is to prove to any doubters that
>> they'd better start supporting bigger blocks or they'll be left behind, and
>> to give them a chance to upgrade before that happens.
>>
>>
>> Because if we can't come to consensus here, the ultimate authority for
>> determining consensus is what code the majority of merchants and exchanges
>> and miners are running.
>>
>>
>> --
>> --
>> Gavin Andresen
>>
>>
>> ------------------------------------------------------------------------------
>>
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150530/bf19ef13/attachment.html>;
Aaron Voisine [ARCHIVE] /
npub18g…knkzl
2023-06-07 15:34:08
in reply to nevent1q…3f8a
Author Public Key
npub18gjvug29c4yg46lmplq38e75gg6wn5mn8taytckcsr4jt8p74h3s5knkzlPublished at
2023-06-07 15:34:08Event JSON
{
"id": "0b35b8644f20eb16bfd1785d674927cd82895c116b11d6cda30519001c4f9c6d",
"pubkey": "3a24ce2145c5488aebfb0fc113e7d44234e9d3733afa45e2d880eb259c3eade3",
"created_at": 1686152048,
"kind": 1,
"tags": [
[
"e",
"aec396df7693e37c124fbd2891fe6c4a3b28f46e7fbc3f304a7b1d78d2f5ffbe",
"",
"root"
],
[
"e",
"820eac24e8b2b99d4b16ac36ac3ffb9905d624ed1d03855a092fa272130e297f",
"",
"reply"
],
[
"p",
"e37870c588b33266137112296e447b7b47ad9489c706e2d5a983b6eb58398a6a"
]
],
"content": "📅 Original date posted:2015-05-30\n📝 Original message:\u003e or achieving less than great DOS protection\n\nRight now a bunch of redditors can DOS the network at the cost of a few\nthousand dollars per day, shared between them. Since the cost of validating\ntransactions is far lower than current minimum relay fees, then increasing\nthe block size increases the cost of DOSing the network.\n\n\nAaron Voisine\nco-founder and CEO\nbreadwallet.com\n\nOn Fri, May 29, 2015 at 10:53 AM, Admin Istrator \u003candy at ftlio.com\u003e wrote:\n\n\u003e What about trying the dynamic scaling method within the 20MB range + 1\n\u003e year with a 40% increase of that cap? Until a way to dynamically scale is\n\u003e found, the cap will only continue to be an issue. With 20 MB + 40% yoy,\n\u003e we're either imposing an arbitrary cap later, or achieving less than great\n\u003e DOS protection always. Why not set that policy as a maximum for 2 years as\n\u003e a protection against the possibility of dynamic scaling abuse, and see what\n\u003e happens with a dynamic method in the mean time. The policy of Max(1MB,\n\u003e (average size over previous 144 blocks) * 2) calculated at each block seems\n\u003e pretty reasonable.\n\u003e\n\u003e As an outsider, the real 'median' here seems to be 'keeping the cap as\n\u003e small as possible while allowing for larger blocks still'. We know\n\u003e miners will want to keep space in their blocks relatively scarce, but we\n\u003e also know that doesn't exclude the more powerful miners from\n\u003e including superfluous transactions to increase their effective share of the\n\u003e network. I have the luck of not being drained by this topic over the past\n\u003e three years, so it looks to me as if its two poles of 'block size must\n\u003e increase' and 'block size must not increase' are forcing what is the clear\n\u003e route to establishing the 'right' block size off the table.\n\u003e\n\u003e --Andrew Len\n\u003e (sorry if anybody received this twice, sent as the wrong email the first\n\u003e time around).\n\u003e\n\u003e On Fri, May 29, 2015 at 5:39 AM, Gavin Andresen \u003cgavinandresen at gmail.com\u003e\n\u003e wrote:\n\u003e\n\u003e\u003e What do other people think?\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e If we can't come to an agreement soon, then I'll ask for help\n\u003e\u003e reviewing/submitting patches to Mike's Bitcoin-Xt project that implement a\n\u003e\u003e big increase now that grows over time so we may never have to go through\n\u003e\u003e all this rancor and debate again.\n\u003e\u003e\n\u003e\u003e I'll then ask for help lobbying the merchant services and exchanges and\n\u003e\u003e hosted wallet companies and other bitcoind-using-infrastructure companies\n\u003e\u003e (and anybody who agrees with me that we need bigger blocks sooner rather\n\u003e\u003e than later) to run Bitcoin-Xt instead of Bitcoin Core, and state that they\n\u003e\u003e are running it. We'll be able to see uptake on the network by monitoring\n\u003e\u003e client versions.\n\u003e\u003e\n\u003e\u003e Perhaps by the time that happens there will be consensus bigger blocks\n\u003e\u003e are needed sooner rather than later; if so, great! The early deployment\n\u003e\u003e will just serve as early testing, and all of the software already deployed\n\u003e\u003e will ready for bigger blocks.\n\u003e\u003e\n\u003e\u003e But if there is still no consensus among developers but the \"bigger\n\u003e\u003e blocks now\" movement is successful, I'll ask for help getting big miners to\n\u003e\u003e do the same, and use the soft-fork block version voting mechanism to\n\u003e\u003e (hopefully) get a majority and then a super-majority willing to produce\n\u003e\u003e bigger blocks. The purpose of that process is to prove to any doubters that\n\u003e\u003e they'd better start supporting bigger blocks or they'll be left behind, and\n\u003e\u003e to give them a chance to upgrade before that happens.\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e Because if we can't come to consensus here, the ultimate authority for\n\u003e\u003e determining consensus is what code the majority of merchants and exchanges\n\u003e\u003e and miners are running.\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e --\n\u003e\u003e --\n\u003e\u003e Gavin Andresen\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e ------------------------------------------------------------------------------\n\u003e\u003e\n\u003e\u003e _______________________________________________\n\u003e\u003e Bitcoin-development mailing list\n\u003e\u003e Bitcoin-development at lists.sourceforge.net\n\u003e\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\u003e\u003e\n\u003e\u003e\n\u003e\n\u003e\n\u003e ------------------------------------------------------------------------------\n\u003e\n\u003e _______________________________________________\n\u003e Bitcoin-development mailing list\n\u003e Bitcoin-development at lists.sourceforge.net\n\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150530/bf19ef13/attachment.html\u003e",
"sig": "e5d9144ddc6fdb1b1f77df7b6a3fd442dcc221975323e86a4287abf7648692ce7ebfeacffdd3e79bca08418bdd9834ba11ab0b5e23c6b24ec0ac2eb94af05b70"
}