From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Yrmv6-0007tt-Pr for bitcoin-development@lists.sourceforge.net; Mon, 11 May 2015 12:34:52 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.215.43 as permitted sender) client-ip=209.85.215.43; envelope-from=decker.christian@gmail.com; helo=mail-la0-f43.google.com; Received: from mail-la0-f43.google.com ([209.85.215.43]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Yrmv4-00018Q-Tz for bitcoin-development@lists.sourceforge.net; Mon, 11 May 2015 12:34:52 +0000 Received: by laat2 with SMTP id t2so92000891laa.1 for ; Mon, 11 May 2015 05:34:44 -0700 (PDT) X-Received: by 10.112.35.230 with SMTP id l6mr7859478lbj.5.1431347684550; Mon, 11 May 2015 05:34:44 -0700 (PDT) MIME-Version: 1.0 References: <55505441.3010906@certimix.com> <20150511103402.GA21748@savin.petertodd.org> <66648462658adebb5e5be7fcba65e670@national.shitposting.agency> In-Reply-To: From: Christian Decker Date: Mon, 11 May 2015 12:34:43 +0000 Message-ID: To: Dave Hudson , insecurity@national.shitposting.agency Content-Type: multipart/alternative; boundary=001a11c3787649afa00515cd9a49 X-Spam-Score: -0.6 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (decker.christian[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1Yrmv4-00018Q-Tz Cc: bitcoin-development@lists.sourceforge.net Subject: Re: [Bitcoin-development] Reducing the block rate instead of increasing the maximum block size X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2015 12:34:52 -0000 --001a11c3787649afa00515cd9a49 Content-Type: text/plain; charset=UTF-8 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 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 > --001a11c3787649afa00515cd9a49 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The propagation speed gain from having smaller blocks is l= inear 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 su= perlinearly, giving an overall worse tradeoff. A high blockchain fork rate = is a symptom of inefficient use of the network's mining resources and m= ay give an advantage to an attacker that is more efficient in communicating= internally.

I'd strongly against increasing the blo= ck generation rate in Bitcoin, it'd be a very controversial proposal an= d would not solve anything.

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 wa= s 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<= br> > minutes as a result. Stop worrying so much.

This doesn't work because a large-scale miner can trivially make themse= lves look like a very large number of much smaller scale miners. Their abil= ity to minimize variance comes from the cumulative totals they control so 1= 0 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 l= ot of DDoS mitigation anyway. If no-one is doing this right now it's si= mply 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 bl= ock 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-de= velopment
--001a11c3787649afa00515cd9a49--