From: Christian Decker <decker.christian@gmail•com>
To: Dave Hudson <dave@hashingit•com>, insecurity@national•shitposting.agency
Cc: bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] Reducing the block rate instead of increasing the maximum block size
Date: Mon, 11 May 2015 12:34:43 +0000 [thread overview]
Message-ID: <CALxbBHXutSo7rbPNEffWj5=ZM8JbEFuvfUvzMLjEC9106AbJ0A@mail.gmail.com> (raw)
In-Reply-To: <DF13D23D-1F04-4970-A80A-4892374E5247@hashingit.com>
[-- Attachment #1: Type: text/plain, Size: 2887 bytes --]
The propagation speed gain from having smaller blocks is linear in the size
reduction, down to a small size, after which the delay of the first byte
prevails [1], however the blockchain fork rate increases superlinearly,
giving an overall worse tradeoff. A high blockchain fork rate is a symptom
of inefficient use of the network's mining resources and may give an
advantage to an attacker that is more efficient in communicating internally.
I'd strongly against increasing the block generation rate in Bitcoin, it'd
be a very controversial proposal and would not solve anything.
[1]
http://www.tik.ee.ethz.ch/file/49318d3f56c1d525aabf7fda78b23fc0/P2P2013_041.pdf
On Mon, May 11, 2015 at 1:51 PM Dave Hudson <dave@hashingit•com> wrote:
>
> > On 11 May 2015, at 12:10, insecurity@national•shitposting.agency wrote:
> >
> > On 2015-05-11 10:34, Peter Todd wrote:
> >> How do you see that blacklisting actually being done?
> >
> > Same way ghash.io was banned from the network when used Finney attacks
> > against BetCoin Dice.
> >
> > As Andreas Antonopoulos says, if any of the miners do anything bad, we
> > just ban them from mining. Any sort of attack like this only lasts 10
> > minutes as a result. Stop worrying so much.
>
> This doesn't work because a large-scale miner can trivially make
> themselves look like a very large number of much smaller scale miners.
> Their ability to minimize variance comes from the cumulative totals they
> control so 10 pools of 1% of the network cumulatively have the same
> variance as 1 pool with 10% of the network. It's also very easy for miners
> to relay blocks via different addresses and the cost is minimal. The
> biggest cost would be in DDoS prevention and a miner that actually split
> their pool into lots of small fragments would actually give themselves the
> ability to do quite a lot of DDoS mitigation anyway. If no-one is doing
> this right now it's simply because they've not had the right incentives to
> make it worthwhile; if the incentives make it worthwhile then this is
> pretty trivial to do.
>
> This is one area where anonymity on behalf of transaction validators and
> block makers essentially makes it pretty-much impossible to maintain any
> sort of sanctions against antisocial behaviour.
>
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
[-- Attachment #2: Type: text/html, Size: 3703 bytes --]
next prev parent reply other threads:[~2015-05-11 12:34 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-11 7:03 Sergio Lerner
2015-05-11 10:34 ` Peter Todd
2015-05-11 11:10 ` insecurity
2015-05-11 11:49 ` Dave Hudson
2015-05-11 12:34 ` Christian Decker [this message]
2015-05-11 16:47 ` Luke Dashjr
[not found] ` <5551021E.8010706@LeoWandersleb.de>
2015-05-12 18:55 ` Sergio Lerner
2015-05-11 7:30 Thy Shizzle
2015-05-11 8:16 ` Dave Hudson
2015-05-11 8:50 insecurity
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='CALxbBHXutSo7rbPNEffWj5=ZM8JbEFuvfUvzMLjEC9106AbJ0A@mail.gmail.com' \
--to=decker.christian@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=dave@hashingit$(echo .)com \
--cc=insecurity@national$(echo .)shitposting.agency \
/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