public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Adam Back <adam@cypherspace•org>
To: Peter Todd <pete@petertodd•org>
Cc: bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] Decentralizing mining
Date: Fri, 31 May 2013 20:14:23 +0200	[thread overview]
Message-ID: <20130531181423.GA30165@netbook.cypherspace.org> (raw)
In-Reply-To: <20130531165758.GA29135@petertodd.org>

I like this idea a lot.

To add: I think it is a bug and security risk if pooled-solo or (current
pooled miners) do not add randomness to their extraNonce2 (like 128-bits of
it).  For privacy and to avoid various hostile-pre-mining attacks it should
be done this way.  Lack of the self-chosen challenge field is the reason
Satoshi's first year mining is marked (plus forgetting to reset the
counter).  (Bitcoind I believe considered the direct miners key as defense
enough as a stand in for self-chosen challenge, which has a few problems).

The base counter I think is only 32-bits, the extranonce2 itself being
random can be incremented while still looking random.  But incrementing
extranonce directy while initializing it to 0 is not good (per previous
mining extranone marked coins bug - is that even fixed?)

(You dont want to  reveal the miners power in his pool shares, if the full
counter is revealed with no randomness it also reveals how many iterations
he can do since the block start).

Adam

On Fri, May 31, 2013 at 12:57:58PM -0400, Peter Todd wrote:
>I just posted the following to bitcointalk.
>
>https://bitcointalk.org/index.php?topic=221164.0
>
>
>Right now between two to four running the largest pools control Bitcoin
>in the short term. That's a lot of hashing power in the hands of very,
>very few people. In addition pools have little incentive to run secure
>operations, and many pools have been hacked with their funds stolen.
>Those hacks could just have easily been used to attack the network
>itself.
>
>This needs to change.
>
>Pooled-solo mining is a concept Gregory Maxwell, Luke Dashjr and I were
>discussing at the conference two weeks ago. (credit goes to Greg and
>Luke; I was mostly just listening) Basically the idea is that miners
>with mining equipment run a local Bitcoin node and use that node to
>construct the blocks they mine - the same as if they were solo mining.
>The pools job is then to only track shares and organize payouts.
>
>If the pool gets hacked the worst that can happen is miners are ripped
>off, rather than Bitcoin itself being attacked. With pooled-solo mining
>even a pool with a majority of hashing power wouldn't be able to do much
>harm to Bitcoin. (depending on the implementation they may be able to
>blacklist specific transactions - the pool needs to know what
>transactions are in the share to credit fees properly)
>
>Tech-wise Luke created getblocktemplate last year as a means to audit
>mining pools. I'm sure Greg and Luke can explain the nitty gritty
>details better than I can, but essentially the plan is to take
>getblocktemplate and extend it as required for pooled-solo mining. This
>will include pool and miner software initially, and later improvements
>to GUIs and what not to make the whole process easier.
>
>
>With the success of my recent video project I also want to make this
>Keep Bitcoin Free's next project, specifically funding a developer
>(likely Luke) to make this happen. Additionally once software is written
>and easily usable a good follow-up would be a video and other media to
>promote the idea to miners. No guarantees we'll be able to come up with
>commercially competitive remuneration, but we can at least come up with
>a "Thank you" tip. But first lets discuss the technical requirements to
>get an idea of what the scope is.
>
>
>Finally, for the record, a big part of the reason why myself and other
>Keep Bitcoin Free supporters are interested in doing this is very much
>to take power over the direction of the network from big pools and put
>it into the hands of thousands of individual miners. It's much easier to
>convince people that changes to Bitcoin, like increasing the blocksize,
>are directly impacting decentralization when individual miners are
>seeing that happen to themselves.
>
>-- 
>'peter'[:-1]@petertodd.org
>00000000000000c14fa7031b2431ab32785efdf1e5aaecc83555ee52a2fc550b



>------------------------------------------------------------------------------
>Get 100% visibility into Java/.NET code with AppDynamics Lite
>It's a free troubleshooting tool designed for production
>Get down to code-level detail for bottlenecks, with <2% overhead.
>Download for free and get started troubleshooting in minutes.
>http://p.sf.net/sfu/appdyn_d2d_ap2

>_______________________________________________
>Bitcoin-development mailing list
>Bitcoin-development@lists•sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/bitcoin-development




  reply	other threads:[~2013-05-31 18:14 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20130527111149.GB8955@tilt>
     [not found] ` <20130531165445.GA29104@petertodd.org>
2013-05-31 16:57   ` Peter Todd
2013-05-31 18:14     ` Adam Back [this message]
2013-06-10 21:09     ` Peter Todd
2013-06-10 21:23       ` Luke-Jr
2013-06-14 20:06         ` Peter Todd
2013-06-14 21:05           ` Luke-Jr
2013-06-17 15:16           ` Jeff Garzik
2013-06-17 17:39             ` Peter Todd
2013-06-10 21:31       ` Melvin Carvalho

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=20130531181423.GA30165@netbook.cypherspace.org \
    --to=adam@cypherspace$(echo .)org \
    --cc=bitcoin-development@lists$(echo .)sourceforge.net \
    --cc=pete@petertodd$(echo .)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