From: Melvin Carvalho <melvincarvalho@gmail•com>
To: Peter Todd <pete@petertodd•org>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Decentralizing mining
Date: Mon, 10 Jun 2013 23:31:18 +0200 [thread overview]
Message-ID: <CAKaEYhKDhPmORRgXSYg+4wrCFcCdvmRW9nJcbzWba4NraEqkQA@mail.gmail.com> (raw)
In-Reply-To: <20130610210913.GA17242@petertodd.org>
[-- Attachment #1: Type: text/plain, Size: 3917 bytes --]
On 10 June 2013 23:09, Peter Todd <pete@petertodd•org> wrote:
> So here's the parts that need to be done for step #1:
>
>
> # Protocol Work
>
> Basic idea is the miner makes two connections, their pool, and a local
> bitcoind.
>
> They always (usually?) work on the subset of transactions common to both
> the pool's getblocktemplate and their local one. When they find a share
> if it doesn't meet difficulty they just hand it to the pool. Currently
> that is done by handing the whole block over, correct? I know the BIP
> says otherwise, but we should optimize this to just hand over tx hashes
> where possible.
>
> If the share does meet difficulty, hand it to both the pool and the
> local bitcoind. Should hand it to the pool first though, because the
> pool likely has the fastest block propagation, then hand it to local
> bitcoind. An optimized version may want to have some record of measured
> bandwidth - this applies Bitcoin in general too, although also has other
> issues.
>
>
> ## Reducing bandwidth
>
> How about for normal shares we just pass the block header, and have the
> pool randomly pick a subset of transactions to audit? Any fraud cancels
> the users shares. This will work best in conjunction with a UTXO proof
> tree to prove fees, or by just picking whole shares randomly to audit.
>
> We'll need persistent share storage so if your connection disconnects
> you can provide the pool with the full share later though.
>
> Incedentally, note how the miner can do the reverse: pick random block
> headers and challenge the pool to prove that they correspond to a valid
> block. With some modifications Stratum can support this approach.
>
>
> ## Delibrate orphaning of slow to propagate blocks
>
> Block headers can be flooded-filled much faster than blocks themselves.
> They are also small enough to fit into a UDP packet. Nodes should pass
> headers around separately via UDP, optinally with some tiny number of
> transactions. When we see a valid block header whose contents we do not
> know about a miner should switch to mining empty or near empty blocks in
> solo mode that would orphan the still propagating block. Doing this is
> safe, we'll never build on an invalid block, economically rational while
> the inflation subsidy is still high, and helps reduce (although not
> eliminate!) the advantage a large miner with high-bandwidth connections
> has over those who don't.
>
> Of course, the other option is to build a block extending the one you
> don't know about, which is even more rational, but doing poses major
> risks to Bitcoin...
>
> This functionality can be implemented later - it's not strictly part of
> pooled-solo mode.
>
>
> # Pool work
>
> So does eliopool already accept arbitrary shares like this and do the
> correct accounting already? (IE adjust share amount based on fees?) What
> happens when the pool doesn't get the share directly, but does see the
> new block?
>
> + possible protocol extensions
>
>
> # Miner work
>
> Basically we need code to merge the two block templates together to find
> commonality. I guess you probably want to implement this in bfgminer
> first, so add the code to libblkmaker first, then maybe python-blkmaker.
>
> We also want an automatic fallback to local solo mining if the pool
> can't be contacted.
>
> + possible protocol extensions
>
Sounds very promising. Suspect it will need a fair amount of testing ...
>
>
> --
> 'peter'[:-1]@petertodd.org
> 000000000000005576673e616271f762a5d8779d5fe7796c6e43ed43df5aa189
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
[-- Attachment #2: Type: text/html, Size: 5063 bytes --]
prev parent reply other threads:[~2013-06-10 21:31 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
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 [this message]
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=CAKaEYhKDhPmORRgXSYg+4wrCFcCdvmRW9nJcbzWba4NraEqkQA@mail.gmail.com \
--to=melvincarvalho@gmail$(echo .)com \
--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