Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 8192B105E for ; Tue, 29 Dec 2015 19:07:26 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A09FE120 for ; Tue, 29 Dec 2015 19:07:25 +0000 (UTC) Received: from [192.168.1.190] (63.135.62.197.nwinternet.com [63.135.62.197] (may be forged)) (authenticated bits=0) by c.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id tBTJ7Lu7019628 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 29 Dec 2015 11:07:22 -0800 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_70AA736C-19C0-44A9-8F01-566018B97C42"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5.2 From: Jonathan Toomim In-Reply-To: Date: Tue, 29 Dec 2015 11:08:16 -0800 Message-Id: <386A5974-2368-4CA5-93BC-0DD7D5DA9D3D@toom.im> References: <20151219184240.GB12893@muck> <4882BD35-D890-4860-9222-5C23AEB6AE89@mattcorallo.com> <20151220044450.GA23942@muck> <20151228191228.GC12298@muck> To: Dave Scotese X-Mailer: Apple Mail (2.1878.6) X-Sonic-CAuth: UmFuZG9tSVbiJx99LPgGGboCJQtZXKyFjBsYSdZrfEcSDbNeKV8Ytt2/ZDmZmBOZfAa0qiuGSVG9jaUIAffuwpzoHkUuQF/M X-Sonic-ID: C;VGRxY1+u5RGeV/8vZz0oYQ== M;lAr0Y1+u5RGeV/8vZz0oYQ== X-Sonic-Spam-Details: 3.8/5.0 by cerberusd X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,HTML_MESSAGE, RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: Bitcoin Dev Subject: Re: [bitcoin-dev] We need to fix the block withholding attack X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Dec 2015 19:07:26 -0000 --Apple-Mail=_70AA736C-19C0-44A9-8F01-566018B97C42 Content-Type: multipart/alternative; boundary="Apple-Mail=_BB3F9C90-F8EB-4D62-A68C-36A716C15098" --Apple-Mail=_BB3F9C90-F8EB-4D62-A68C-36A716C15098 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Ultimately, a self-interested miner will chose to build on the block = that leaves the most transaction fees up for grabs. (This usually means = the smallest block.) It's an interesting question whether the default = behavior for Core should be the rational behavior (build on the = "smallest" block in terms of fees) or some other supposedly altruistic = behavior (most BTCDD). This also applies to the decision of the "same = time" threshold -- a selfish miner will not care if the blocks arrived = at about the same time or not. I currently do not have a strong opinion on what that behavior should = be, although if the blocksize limit were increased substantially, I may = prefer the selfish behavior because it ends up also being fail-safe = (punishes selfish mining using large blocks or fee-stealing attempts). On Dec 29, 2015, at 10:59 AM, Dave Scotese via bitcoin-dev = wrote: > There have been no decent objections to altering the block-selection = mechanism (when two block solutions appear at nearly the same time) as = described at >=20 > http://bitcoin.stackexchange.com/questions/39226 >=20 > Key components are: > Compute BitcoinDaysDestroyed using only transactions that have been in = your mempool for some time as oBTCDD ("old BTCDD"). > Use "nearly the same time" to mean separated in time by your guess of = the average duration of block propagation times. > When two block solutions come in at nearly the same time, build on the = one that has the most oBTCDD, rather than the one that came in first. > The goal of this change is to reduce the profitability of withholding = block solutions by severely reducing the chances that a block solved a = while ago can orphan one solved recently. "Came in first" seems more = easily gamed than "most oBTCDD". As I wrote there, "old coins is always = a dwindling resource and global nodes willing to help cheat is probably = a growing one." >=20 > I will write a BIP if anyone agrees it's a good idea. >=20 >=20 > On Mon, Dec 28, 2015 at 12:26 PM, Ivan Brightly via bitcoin-dev = wrote: > On Mon, Dec 28, 2015 at 2:12 PM, Peter Todd via bitcoin-dev = wrote: > Far more concerning is network propagation effects between large and > small miners. For that class of issues, if you are in an environemnt > where selfish mining is possible - a fairly flat, easily DoS/sybil > attacked network topology - the profitability difference between small > and large miners even *without* attacks going on is a hugely worrying > problem. OTOH, if you're blocksize is small enough that propagation = time > is negligable to profitability, then selfish mining attacks with <30% > hashing power aren't much of a concern - they'll be naturally defeated > by anti-DoS/anti-sybil measures. >=20 > Let's agree that one factor in mining profitability is = bandwidth/network reliability/stability. Why focus on that vs = electricity contracts or vertically integrated chip manufacturers? = Surely, sufficient network bandwidth is a more broadly available = commodity than <$0.02/kwh electricity, for example. I'm not sure that = your stranded hydroelectric miner is any more desirable than thousands = of dorm room miners with access to 10gbit university connections and = free electricity. >=20 > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >=20 >=20 >=20 >=20 > -- > I like to provide some work at no charge to prove my value. Do you = need a techie? > I own Litmocracy and Meme Racing (in alpha). > I'm the webmaster for The Voluntaryist which now accepts Bitcoin. > I also code for The Dollar Vigilante. > "He ought to find it more profitable to play by the rules" - Satoshi = Nakamoto > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev --Apple-Mail=_BB3F9C90-F8EB-4D62-A68C-36A716C15098 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Ultimately, a self-interested miner will chose = to build on the block that leaves the most transaction fees up for = grabs. (This usually means the smallest block.) It's an interesting = question whether the default behavior for Core should be the rational = behavior (build on the "smallest" block in terms of fees) or some other = supposedly altruistic behavior (most BTCDD). This also applies to the = decision of the "same time" threshold -- a selfish miner will not care = if the blocks arrived at about the same time or = not.

I currently do not have a strong opinion = on what that behavior should be, although if the blocksize limit were = increased substantially, I may prefer the selfish behavior because it = ends up also being fail-safe (punishes selfish mining using large blocks = or fee-stealing attempts).


On Dec 29, = 2015, at 10:59 AM, Dave Scotese via bitcoin-dev <bitcoin-dev@lists.li= nuxfoundation.org> wrote:

There have been no decent objections to altering the = block-selection mechanism (when two block solutions appear at nearly the = same time) as described at

http://bitcoin.s= tackexchange.com/questions/39226

Key components = are:
  • Compute BitcoinDaysDestroyed using only transactions = that have been in your mempool for some time as oBTCDD ("old = BTCDD").
  • Use "nearly the same time" to mean separated in time by = your guess of the average duration of block propagation = times.
  • When two block solutions come in at nearly the same = time, build on the one that has the most oBTCDD, rather than the one = that came in first.

The goal of this change is to reduce the = profitability of withholding block solutions by severely reducing the = chances that a block solved a while ago can orphan one solved = recently.  "Came in first" seems more easily gamed than "most = oBTCDD".  As I wrote there, "old coins is always a = dwindling resource and global nodes willing to help cheat is = probably a growing one."

I will write a BIP if anyone agrees = it's a good idea.


On Mon, Dec 28, 2015 at 12:26 PM, Ivan Brightly = via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> = wrote:
On Mon, Dec 28, 2015 at 2:12 PM, Peter = Todd via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>&nbs= p;wrote:
Far more concerning is network propagation effects between large and
small miners. For that class of issues, if you are in an environemnt
where selfish mining is possible - a fairly flat, easily DoS/sybil
attacked network topology - the profitability difference between = small
and large miners even *without* attacks going on is a hugely = worrying
problem. OTOH, if you're blocksize is small enough that propagation = time
is negligable to profitability, then selfish mining attacks with = <30%
hashing power aren't much of a concern - they'll be naturally = defeated
by anti-DoS/anti-sybil = measures.

Let's agree that = one factor in mining profitability is bandwidth/network = reliability/stability. Why focus on that vs electricity contracts or = vertically integrated chip manufacturers? Surely, sufficient network = bandwidth is a more broadly available commodity than <$0.02/kwh = electricity, for example. I'm not sure that your stranded hydroelectric = miner is any more desirable than thousands of dorm room miners with = access to 10gbit university connections and free = electricity.

_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.li= nuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitco= in-dev




--
I like to provide some work = at no charge to prove my value. Do you need a techie? 
I own Litmocracy and = Meme Racing = (in alpha).
I'm the webmaster for The = Voluntaryist which now accepts Bitcoin.
I also code for The Dollar = Vigilante.
"He ought to find it more profitable to play by the = rules" - Satoshi Nakamoto
_______________________________________________
bitcoin-dev mailing = list
bitcoin-dev@lists.li= nuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinf= o/bitcoin-dev

= --Apple-Mail=_BB3F9C90-F8EB-4D62-A68C-36A716C15098-- --Apple-Mail=_70AA736C-19C0-44A9-8F01-566018B97C42 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJWgtohAAoJEIEuMk4MG0P1as0H/jb70xk0KQ/49VGzxO9S0WB5 Jb6mXlIhaiB9/VJCrPiUoSoI6pNxPuXl5j5oTtO8r8JoqLfqLRUAs7E2YIyH54Xj UMu/1EuTdWTo1rZFhGBCWl/hR56XiRwbyKIrPWVPw9ntoA6EJoCjpjXfDJye419B 2Uel0UtXDxRgHQKjcYXmbspEu8/9qjBMtab/3Ds2TcxF7Ot37JNoSbLECyEtgo2H 6TjSp9dLwCWT42+aTHNKiPGaPgIE4V5QrXwsaRyWYt6uX410YEo+LyCthRyC/Vxq pquw3gxQ4z0S4BkAj7GUkNSbKyp0oNtuX/O2GtHP1WOL7cQTwgueEfKiMjQ7kqs= =rjfG -----END PGP SIGNATURE----- --Apple-Mail=_70AA736C-19C0-44A9-8F01-566018B97C42--