From: Aaron Voisine <voisine@gmail•com>
To: Admin Istrator <andy@ftlio•com>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Proposed alternatives to the 20MB step function
Date: Sat, 30 May 2015 02:03:36 -0700 [thread overview]
Message-ID: <CACq0ZD7-qr4BCdnqOSXLYv-i58vAXWGcQ1oLsrbHoNFMeiNTtg@mail.gmail.com> (raw)
In-Reply-To: <CA+VAk3O7SmDkxL9rATWe9oqCVVKcT=cFXDJnARPN8pv=UiHaiA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4214 bytes --]
> 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@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@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@lists•sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
[-- Attachment #2: Type: text/html, Size: 5988 bytes --]
next prev parent reply other threads:[~2015-05-30 9:03 UTC|newest]
Thread overview: 69+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-08 7:20 Matt Whitlock
2015-05-08 10:15 ` Mike Hearn
2015-05-08 10:30 ` Clément Elbaz
2015-05-08 12:32 ` Joel Joonatan Kaartinen
2015-05-08 12:48 ` Matt Whitlock
2015-05-08 13:24 ` Matt Whitlock
2015-05-08 12:48 ` Gavin Andresen
2015-05-08 16:51 ` Peter Todd
2015-05-08 22:36 ` Joel Joonatan Kaartinen
2015-05-09 18:30 ` Peter Todd
2015-05-08 15:57 ` Alex Mizrahi
2015-05-08 16:55 ` Bryan Bishop
2015-05-08 20:33 ` Mark Friedenbach
2015-05-08 22:43 ` Aaron Voisine
2015-05-08 22:45 ` Mark Friedenbach
2015-05-08 23:15 ` Aaron Voisine
2015-05-08 23:58 ` Mark Friedenbach
2015-05-09 3:36 ` Gregory Maxwell
2015-05-09 11:58 ` Gavin Andresen
2015-05-09 13:49 ` Tier Nolan
2015-05-10 17:36 ` Owen Gunden
2015-05-10 18:10 ` Mark Friedenbach
2015-05-10 21:21 ` Gavin Andresen
2015-05-10 21:33 ` Gregory Maxwell
2015-05-10 21:56 ` Rob Golding
2015-05-13 10:43 ` Tier Nolan
2015-05-16 0:22 ` Rusty Russell
2015-05-16 11:09 ` Tier Nolan
2015-05-18 1:42 ` Rusty Russell
2015-05-19 8:59 ` Tier Nolan
2015-05-10 21:48 ` Thomas Voegtlin
2015-05-10 22:31 ` Mark Friedenbach
2015-05-10 23:11 ` Thomas Voegtlin
2015-05-28 15:53 ` Gavin Andresen
2015-05-28 17:05 ` Mike Hearn
2015-05-28 17:19 ` Gavin Andresen
2015-05-28 17:34 ` Mike Hearn
2015-05-28 18:23 ` Gavin Andresen
2015-05-29 11:26 ` Mike Hearn
2015-05-29 11:42 ` Tier Nolan
2015-05-29 11:57 ` Mike Hearn
2015-05-29 12:39 ` Gavin Andresen
2015-05-29 14:00 ` insecurity
2015-05-29 14:15 ` Braun Brelin
2015-05-29 14:09 ` Tier Nolan
2015-05-29 14:20 ` Gavin Andresen
2015-05-29 14:22 ` Mike Hearn
2015-05-29 14:21 ` Mike Hearn
2015-05-29 14:22 ` Tier Nolan
2015-05-29 16:39 ` [Bitcoin-development] Proposed alternatives to the 20MB stepfunction Raystonn .
2015-05-29 18:28 ` Tier Nolan
2015-05-29 17:53 ` [Bitcoin-development] Proposed alternatives to the 20MB step function Admin Istrator
2015-05-30 9:03 ` Aaron Voisine [this message]
2015-06-01 11:30 ` Ricardo Filipe
2015-06-01 11:46 ` Marcel Jamin
2015-05-29 18:47 ` Bryan Cheng
2015-05-30 1:36 ` Cameron Garnham
2015-05-28 17:39 ` [Bitcoin-development] Proposed alternatives to the 20MB stepfunction Raystonn .
2015-05-28 17:59 ` Pieter Wuille
2015-05-28 18:21 ` Gavin Andresen
2015-05-28 17:50 ` [Bitcoin-development] Proposed alternatives to the 20MB step function Peter Todd
2015-05-28 17:14 ` Thomas Voegtlin
2015-05-28 17:34 ` Pieter Wuille
2015-05-29 17:45 ` Aaron Voisine
2015-05-08 14:57 Steven Pine
2015-05-09 0:13 Raystonn
[not found] <CAAjy6kDdB8uODpPcmS8h4eap8fke7Y2y773NHJZja8tB5mPk4Q@mail.gmail.com>
2015-05-28 16:30 ` Steven Pine
[not found] ` <CABsx9T03aNRC5DRbR06nNtsiBdJAcQsGAHvbCOe3pnuRpdvq5w@mail.gmail.com>
2015-05-28 18:25 ` Steven Pine
2015-05-28 18:31 ` Gavin Andresen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CACq0ZD7-qr4BCdnqOSXLYv-i58vAXWGcQ1oLsrbHoNFMeiNTtg@mail.gmail.com \
--to=voisine@gmail$(echo .)com \
--cc=andy@ftlio$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox