From: s7r <s7r@sky-ip.org>
To: Andrew Johnson <andrew.johnson83@gmail.com>,
Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Managing block size the same way we do difficulty (aka Block75)
Date: Mon, 12 Dec 2016 01:22:53 +0200 [thread overview]
Message-ID: <8679ecea-b449-0f5a-d4d7-1f23ae6e29b2@sky-ip.org> (raw)
In-Reply-To: <CAAy62_KLAJ2OOv863HB4CzoAr7QOURRMFF2pH2pGUVQ9gMpecg@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 2530 bytes --]
Andrew Johnson wrote:
> "You miss something obvious that makes this attack actually free of cost.
> Nothing will "cost them more in transaction fees". A miner can create
> thousands of transactions paying to himself, and not broadcast them to
> the network, but hold them and include them in the blocks he mines. The
> fees are collected by him because transactions are included in a block
> that he mined and the left amount is in another wallet of the same
> person. Repeat this continuously to fill blocks."
>
> This is easily detectable as long as the network isn't heavily
> partitioned(which is an assumption we make today in order for
> transaction propagation to work reliably as well as for xThin and
> CompactBlocks to work effectively to reduce block transmission time).
> Other miners would have an incentive to intentionally orphan blocks that
> contained a large number of transactions that their nodes were unaware of.
>
> I don't think this sort of attack would last long. Even later when
> subsidies are drastically reduced, you would still lose out on
> significant genuine fee revenue if your orphan rate increased even
> 10%(one out of ten of your poison blocks intentionally orphaned by
> another miner).
>
I disagree.
I didn't say this is impossible to detect, but it is hard to act against
it. One miner orphaning the block intentionally is very unlikely if that
miner acts rationally. It would only make sense if 51% of the hash rate
would intentionally orphan it. Otherwise the miner who intentionally
orphans a valid block, let's say block X, has to continue to mine one in
its place on top of block X-1, and by the time he finds one:
a) his block X' is rejected by other miners because they already have a
valid block X on top of which they already started to mine;
b) block X+1 was already found and broadcasted, so the miner who
orphaned X intentionally is on the shorter chain ignored by the network.
So, one miner cannot do anything about it. Even a pool cannot do
anything about it, because the loss is greater. You need 51% of the hash
rate to intentionally orphan it, and all the miners forming 51% need to
be colluding and know for sure that every one will intentionally orphan
the said block, otherwise there's a huge risk of loss for who does it.
Nobody would gamble to do this (I am not sure if gambling is the right
word, since the loss is 100% sure here). But, we are not discussing 51%
attacks because those are a different topic.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2016-12-11 23:23 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-05 15:27 [bitcoin-dev] Managing block size the same way we do difficulty (aka Block75) t. khan
2016-12-10 10:44 ` s7r
2016-12-10 12:05 ` Hampus Sjöberg
2016-12-11 0:26 ` t. khan
2016-12-11 0:40 ` James Hilliard
2016-12-11 1:07 ` Bram Cohen
2016-12-11 17:11 ` s7r
2016-12-11 19:55 ` t. khan
2016-12-11 20:31 ` James Hilliard
2016-12-11 21:40 ` t. khan
2016-12-11 21:53 ` Bram Cohen
2016-12-11 21:55 ` James Hilliard
2016-12-11 22:30 ` t. khan
2016-12-11 20:38 ` Andrew Johnson
2016-12-11 23:22 ` s7r [this message]
2016-12-18 21:53 ` James MacWhyte
2016-12-19 1:42 ` Tom Harding
2016-12-10 23:12 ` Bram Cohen
2016-12-11 0:52 ` t. khan
[not found] <CAEgR2PEMPo3veqJat7OAps1DzTSNFJmJiRbkFgYKvYfxqdbUiw@mail.gmail.com>
[not found] ` <CAEgR2PELB1_s+o0Bj4Kj9vS27eoqP7gV_VS_6QHQtTUAOnMORg@mail.gmail.com>
[not found] ` <CAEgR2PFpGWxngq=fKGi7CC_d+=5YWzWwbEEsQNEifCuHAAPAHw@mail.gmail.com>
[not found] ` <CAEgR2PHnrsdaBiDgywvE9amK8_yPE_hBo0yYOYwUk4T8n7wnAQ@mail.gmail.com>
[not found] ` <CAEgR2PEgPkRe76hW0Jj7_Z1EdmmNTpTAOKGm_of2dG=XXUOtnA@mail.gmail.com>
[not found] ` <CAEgR2PHew+fcJWnAt+t8umcwKu4TkshH=AFJ-8MeYysud2MkBQ@mail.gmail.com>
[not found] ` <CAEgR2PEVwt_shiqwGjK6dPscRUTHayis0PaQO5Dj_fVEGGgaCQ@mail.gmail.com>
2016-12-10 12:23 ` Daniele Pinna
2016-12-10 17:39 ` Pieter Wuille
2016-12-11 3:17 ` Daniele Pinna
2016-12-11 5:29 ` Eric Voskuil
2016-12-11 9:21 ` Adam Back
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=8679ecea-b449-0f5a-d4d7-1f23ae6e29b2@sky-ip.org \
--to=s7r@sky-ip.org \
--cc=andrew.johnson83@gmail.com \
--cc=bitcoin-dev@lists.linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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