public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Jonathan Toomim <j@toom•im>
To: Dave Scotese <dscotese@litmocracy•com>
Cc: Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] We need to fix the block withholding attack
Date: Tue, 29 Dec 2015 11:08:16 -0800	[thread overview]
Message-ID: <386A5974-2368-4CA5-93BC-0DD7D5DA9D3D@toom.im> (raw)
In-Reply-To: <CAGLBAhdqKLgK09s5Mp6C4nv0k4hHBYM5c8NpgP5G7J110NseqQ@mail.gmail.com>


[-- Attachment #1.1: Type: text/plain, Size: 4043 bytes --]

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•linuxfoundation.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.stackexchange.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> 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•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-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•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


[-- Attachment #1.2: Type: text/html, Size: 5875 bytes --]

[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 496 bytes --]

  reply	other threads:[~2015-12-29 19:07 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-19 18:42 Peter Todd
2015-12-19 19:30 ` Bob McElrath
2015-12-19 20:03 ` jl2012
2015-12-20  3:34 ` Chris Priest
2015-12-20  3:36   ` Matt Corallo
2015-12-20  3:43     ` Chris Priest
2015-12-20  4:44       ` Peter Todd
2015-12-26  8:12         ` Multipool Admin
2015-12-27  4:10           ` Geir Harald Hansen
2015-12-28 19:12           ` Peter Todd
2015-12-28 19:30             ` Emin Gün Sirer
2015-12-28 19:35               ` Multipool Admin
2015-12-28 19:33             ` Multipool Admin
2015-12-28 20:26             ` Ivan Brightly
2015-12-29 18:59               ` Dave Scotese
2015-12-29 19:08                 ` Jonathan Toomim [this message]
2015-12-29 19:25                 ` Allen Piscitello
2015-12-29 21:51                   ` Dave Scotese
2015-12-20  3:40   ` jl2012
2015-12-20  3:47     ` Chris Priest
2015-12-20  4:24       ` jl2012
2015-12-20  5:12         ` Emin Gün Sirer
2015-12-20  7:39           ` Chris Priest
2015-12-20  7:56             ` Emin Gün Sirer
2015-12-20  8:30               ` Natanael
2015-12-20 11:38           ` Tier Nolan
2015-12-20 12:42             ` Natanael
2015-12-20 15:30               ` Tier Nolan
2015-12-20 13:28           ` Peter Todd
2015-12-20 17:00             ` Emin Gün Sirer
2015-12-21 11:39               ` Jannes Faber
2015-12-25 11:15                 ` Ittay
2015-12-25 12:00                   ` Jonathan Toomim
2015-12-25 12:02                   ` benevolent
2015-12-25 16:11                   ` Jannes Faber
2015-12-26  0:38               ` Geir Harald Hansen
2015-12-28 20:02               ` Peter Todd
2015-12-26  8:23             ` Eric Lombrozo
2015-12-26  8:26               ` Eric Lombrozo
2015-12-26 15:33               ` Jorge Timón
2015-12-26 17:38                 ` Eric Lombrozo
2015-12-26 18:01                   ` Jorge Timón
2015-12-26 16:09               ` Tier Nolan
2015-12-26 18:30                 ` Eric Lombrozo
2015-12-26 19:34                   ` Jorge Timón
2015-12-26 21:22               ` Jonathan Toomim
2015-12-27  4:33                 ` Emin Gün Sirer

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=386A5974-2368-4CA5-93BC-0DD7D5DA9D3D@toom.im \
    --to=j@toom$(echo .)im \
    --cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
    --cc=dscotese@litmocracy$(echo .)com \
    /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