From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Xb20O-0004SC-20 for bitcoin-development@lists.sourceforge.net; Mon, 06 Oct 2014 06:42:48 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com designates 74.125.82.52 as permitted sender) client-ip=74.125.82.52; envelope-from=alex.mizrahi@gmail.com; helo=mail-wg0-f52.google.com; Received: from mail-wg0-f52.google.com ([74.125.82.52]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Xb20N-0000Dj-4C for bitcoin-development@lists.sourceforge.net; Mon, 06 Oct 2014 06:42:48 +0000 Received: by mail-wg0-f52.google.com with SMTP id a1so5656845wgh.23 for ; Sun, 05 Oct 2014 23:42:40 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.90.71 with SMTP id bu7mr16581217wib.33.1412577760825; Sun, 05 Oct 2014 23:42:40 -0700 (PDT) Received: by 10.27.175.95 with HTTP; Sun, 5 Oct 2014 23:42:40 -0700 (PDT) In-Reply-To: <5431CD8D.7050508@certimix.com> References: <5431CD8D.7050508@certimix.com> Date: Mon, 6 Oct 2014 09:42:40 +0300 Message-ID: From: Alex Mizrahi To: Bitcoin Development Content-Type: multipart/alternative; boundary=f46d043be0f4a6d5d00504bb63c4 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 (alex.mizrahi[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: 1Xb20N-0000Dj-4C Subject: Re: [Bitcoin-development] The Bitcoin Freeze on Transaction Attack (FRONT) 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, 06 Oct 2014 06:42:48 -0000 --f46d043be0f4a6d5d00504bb63c4 Content-Type: text/plain; charset=UTF-8 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. --f46d043be0f4a6d5d00504bb63c4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I've heard about this idea = from TierNolan. Here's some quick an dirty analysis:

Suppose the last known b= lock claimed a large tx fee of L. A miner who owns 1/N of the total hashrat= e needs to choose between two strategies:
<= br>
1. Mine on top of that block and win us= ual 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,
=C2=A0R < L/N.
<= div class=3D"gmail_extra">
Now suppose = the miner who claimed the unusually large reward will share it with the nex= t miner, for example, using coinbase output with OP_TRUE. If that shared re= ward Rs is higher than L/N^2, then the next miner will be better off mining= on top of that block.=C2=A0

=
This doesn't require protocol changes(*) and= can be simply incorporated into a piece of code which decides what to do w= hen a transaction with unusually large fee appears. (I.e. it will automatic= ally share the fee, and others will recognize that). And if the biggest min= er 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 shar= e the fee with the next miner.
So some prot= ocol changes are required. But changes which affect coinbase maturity and s= haring are probably going to be simpler and smaller than what Sergio have p= roposed.

--f46d043be0f4a6d5d00504bb63c4--