From: Alex Mizrahi <alex.mizrahi@gmail•com>
To: Bitcoin Development <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] The Bitcoin Freeze on Transaction Attack (FRONT)
Date: Mon, 6 Oct 2014 09:42:40 +0300 [thread overview]
Message-ID: <CAE28kUTBbT5_Jh-aP_rVkLYMSdY+XeQO39LFh+EFHqSp-wFXOQ@mail.gmail.com> (raw)
In-Reply-To: <5431CD8D.7050508@certimix.com>
[-- Attachment #1: Type: text/plain, Size: 1452 bytes --]
I've heard about this idea from TierNolan. Here's some quick an dirty
analysis:
Suppose the last known block claimed a large tx fee of L. A miner who owns
1/N of the total hashrate needs to choose between two strategies:
1. Mine on top of that block and win usual reward R with probability 1/N.
2. Mine on top of the previous block, trying to make two blocks in a row,
might get reward L with probability 1/N^2.
Thus for the first strategy expected payoff is R/N, and for the second the
expected pay-off is L/N^2.
Second strategy is viable if R/N < L/N^2,
R < L/N.
Now suppose the miner who claimed the unusually large reward will share it
with the next miner, for example, using coinbase output with OP_TRUE. If
that shared reward Rs is higher than L/N^2, then the next miner will be
better off mining on top of that block.
This doesn't require protocol changes(*) and can be simply incorporated
into a piece of code which decides what to do when a transaction with
unusually large fee appears. (I.e. it will automatically share the fee, and
others will recognize that). And if the biggest miner has 25% of all
hashrate, sharing 25% of your loot doesn't sound that bad.
(*) Except one problem: coinbase maturity rules won't allow one to share
the fee with the next miner.
So some protocol changes are required. But changes which affect coinbase
maturity and sharing are probably going to be simpler and smaller than what
Sergio have proposed.
[-- Attachment #2: Type: text/html, Size: 2111 bytes --]
next prev parent reply other threads:[~2014-10-06 6:42 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-05 23:00 Sergio Lerner
2014-10-05 23:40 ` Gregory Maxwell
2014-10-05 23:50 ` Gregory Maxwell
2014-10-05 23:54 ` Jorge Timón
2014-10-06 0:01 ` Gregory Maxwell
2014-10-06 11:02 ` Mike Hearn
2014-10-06 12:22 ` Tamas Blummer
2014-10-06 6:42 ` Alex Mizrahi [this message]
2014-10-06 13:21 ` Sergio Lerner
2014-10-06 13:29 ` Tamas Blummer
[not found] <543438E4.8080501@certimix.com>
2014-10-07 19:04 ` Sergio Lerner
2014-10-07 19:16 ` Gregory Maxwell
2014-10-07 20:04 ` Sergio Lerner
2014-10-08 10:19 ` Mike Hearn
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=CAE28kUTBbT5_Jh-aP_rVkLYMSdY+XeQO39LFh+EFHqSp-wFXOQ@mail.gmail.com \
--to=alex.mizrahi@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
/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