From: Moral Agent <ethan.scruples@gmail•com>
To: bitcoin-dev@lists•linuxfoundation.org
Subject: Re: [bitcoin-dev] Reasons to add sync flags to Bitcoin
Date: Thu, 28 Jul 2016 12:41:48 -0400 [thread overview]
Message-ID: <CACiOHGx6+wW_6iShPvRQWHHXsrdSq7yv3_hxc0xcPzuqPUHuOA@mail.gmail.com> (raw)
In-Reply-To: <CACiOHGxpTEOzUBovuJstNEVQOpD+Yv0JivuyeOFsba_jhdyydw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2691 bytes --]
If there is concern about the
block-with-valid-header-but-invalid-transactions-spam-attack, I have a
strategy using sync flags that may drastically reduce the problem.
Sync flags documented here:
https://github.com/moral-agent/sync_flags/blob/master/README.md)
The strategy to defeat the above attack is illustrated here:
https://s32.postimg.org/e94tqdqat/sync_flag_invalid_block.png
The key is to relax the requirement that a flag commit to a completely
valid block. The flag is valid if it commits to a valid block header, even
if the block body is invalid.
From the perspective of an individual miner, they can safely commence
mining a flag the moment they obtain (or discover) a valid block header.
As soon as the spam is discovered, miners can choose to either abandon the
flag and return to mining on the previous block, or they can continue
mining on the flag.
It's difficult for me to game out which of these strategies would be
preferable. My first thought is that the miners should have the incentive
to mine whichever option has the fewest miners, which should result in a
50/50 split.
However, the miners who continue mining the flag have a chance of ending up
in a situation where they mine the flag before anyone mines a valid block.
If this happens, it is sub-optimal for them. They can start mining for the
next valid block but if someone else broadcasts a valid block header they
will be in the same pickle that miners under the current protocol are: they
must either keep mining for a valid block, or SPV mine the newly arrived
block while they do validation. The third option, of mining a flag, is not
available to them, because the flag has already been mined for this cycle.
As a result of the above, it may be most rational for miners to (upon
learning that they are mining a flag on top of an invalid block) split
their hashpower unevenly between the flag and continuing to mine for a
valid block. The hashpower split reflects their estimates of the cost of
the above negative outcome. I think the split would be pretty close to
50/50, but deviations from 50/50 would not necessarily be bad. For example,
if they split 52/48, with more hashpower toward finding the valid block
instead of the flag, then that decreases the likelyhood that the flag will
be discovered before the next valid block, which is good for all of the
miners. So it's a nice positive feedback.
*****
This approach mostly neutralizes the harm done by the (currently very rare)
invalid block spam attack. As a kind of amazing side effect, the work done
to produce the spam is incorporated into the blockchain cumulative Proof of
Work, and the spammer is not paid for this contribution.
[-- Attachment #2: Type: text/html, Size: 3682 bytes --]
next prev parent reply other threads:[~2016-07-28 16:41 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-26 12:47 Moral Agent
2016-07-26 13:51 ` Tom
2016-07-26 17:27 ` Erik Aronesty
2016-07-26 22:03 ` Nick ODell
2016-07-27 14:42 ` Moral Agent
2016-07-28 16:41 ` Moral Agent [this message]
2016-07-26 20:58 Martijn Meijering
2016-07-26 21:45 ` Tier Nolan
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=CACiOHGx6+wW_6iShPvRQWHHXsrdSq7yv3_hxc0xcPzuqPUHuOA@mail.gmail.com \
--to=ethan.scruples@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/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