Christian Decker [ARCHIVE] on Nostr: 📅 Original date posted:2015-05-11 📝 Original message:The propagation speed gain ...
📅 Original date posted:2015-05-11
📝 Original message: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 at hashingit.com> wrote:
>
> > On 11 May 2015, at 12:10, insecurity at 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 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/20150511/9b14788a/attachment.html>;
📝 Original message: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 at hashingit.com> wrote:
>
> > On 11 May 2015, at 12:10, insecurity at 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 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/20150511/9b14788a/attachment.html>;