Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.215.45 as permitted sender)
	client-ip=209.85.215.45; envelope-from=melvincarvalho@gmail.com;
	helo=mail-la0-f45.google.com; 
MIME-Version: 1.0
In-Reply-To: <20130610210913.GA17242@petertodd.org>
References: <20130527111149.GB8955@tilt> <20130531165445.GA29104@petertodd.org>
	<20130531165758.GA29135@petertodd.org>
	<20130610210913.GA17242@petertodd.org>
Date: Mon, 10 Jun 2013 23:31:18 +0200
Message-ID: <CAKaEYhKDhPmORRgXSYg+4wrCFcCdvmRW9nJcbzWba4NraEqkQA@mail.gmail.com>
From: Melvin Carvalho <melvincarvalho@gmail.com>
To: Peter Todd <pete@petertodd.org>
Content-Type: multipart/alternative; boundary=001a11c3738a46f9bc04ded3807e
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Decentralizing mining
Precedence: list

--001a11c3738a46f9bc04ded3807e
Content-Type: text/plain; charset=ISO-8859-1

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
>
>

--001a11c3738a46f9bc04ded3807e
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 10 June 2013 23:09, Peter Todd <span dir=3D"ltr">&lt;<a href=3D"=
mailto:pete@petertodd.org" target=3D"_blank">pete@petertodd.org</a>&gt;</sp=
an> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">So here&#39;s the parts that need to be done=
 for step #1:<br>
<br>
<br>
# Protocol Work<br>
<br>
Basic idea is the miner makes two connections, their pool, and a local<br>
bitcoind.<br>
<br>
They always (usually?) work on the subset of transactions common to both<br=
>
the pool&#39;s getblocktemplate and their local one. When they find a share=
<br>
if it doesn&#39;t meet difficulty they just hand it to the pool. Currently<=
br>
that is done by handing the whole block over, correct? I know the BIP<br>
says otherwise, but we should optimize this to just hand over tx hashes<br>
where possible.<br>
<br>
If the share does meet difficulty, hand it to both the pool and the<br>
local bitcoind. Should hand it to the pool first though, because the<br>
pool likely has the fastest block propagation, then hand it to local<br>
bitcoind. An optimized version may want to have some record of measured<br>
bandwidth - this applies Bitcoin in general too, although also has other<br=
>
issues.<br>
<br>
<br>
## Reducing bandwidth<br>
<br>
How about for normal shares we just pass the block header, and have the<br>
pool randomly pick a subset of transactions to audit? Any fraud cancels<br>
the users shares. This will work best in conjunction with a UTXO proof<br>
tree to prove fees, or by just picking whole shares randomly to audit.<br>
<br>
We&#39;ll need persistent share storage so if your connection disconnects<b=
r>
you can provide the pool with the full share later though.<br>
<br>
Incedentally, note how the miner can do the reverse: pick random block<br>
headers and challenge the pool to prove that they correspond to a valid<br>
block. With some modifications Stratum can support this approach.<br>
<br>
<br>
## Delibrate orphaning of slow to propagate blocks<br>
<br>
Block headers can be flooded-filled much faster than blocks themselves.<br>
They are also small enough to fit into a UDP packet. Nodes should pass<br>
headers around separately via UDP, optinally with some tiny number of<br>
transactions. When we see a valid block header whose contents we do not<br>
know about a miner should switch to mining empty or near empty blocks in<br=
>
solo mode that would orphan the still propagating block. Doing this is<br>
safe, we&#39;ll never build on an invalid block, economically rational whil=
e<br>
the inflation subsidy is still high, and helps reduce (although not<br>
eliminate!) the advantage a large miner with high-bandwidth connections<br>
has over those who don&#39;t.<br>
<br>
Of course, the other option is to build a block extending the one you<br>
don&#39;t know about, which is even more rational, but doing poses major<br=
>
risks to Bitcoin...<br>
<br>
This functionality can be implemented later - it&#39;s not strictly part of=
<br>
pooled-solo mode.<br>
<br>
<br>
# Pool work<br>
<br>
So does eliopool already accept arbitrary shares like this and do the<br>
correct accounting already? (IE adjust share amount based on fees?) What<br=
>
happens when the pool doesn&#39;t get the share directly, but does see the<=
br>
new block?<br>
<br>
+ possible protocol extensions<br>
<br>
<br>
# Miner work<br>
<br>
Basically we need code to merge the two block templates together to find<br=
>
commonality. I guess you probably want to implement this in bfgminer<br>
first, so add the code to libblkmaker first, then maybe python-blkmaker.<br=
>
<br>
We also want an automatic fallback to local solo mining if the pool<br>
can&#39;t be contacted.<br>
<br>
+ possible protocol extensions<br></blockquote><div><br></div><div>Sounds v=
ery promising.=A0 Suspect it will need a fair amount of testing ...<br></di=
v><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8e=
x;border-left:1px #ccc solid;padding-left:1ex">

<span class=3D"HOEnZb"><font color=3D"#888888"><br>
<br>
--<br>
&#39;peter&#39;[:-1]@<a href=3D"http://petertodd.org" target=3D"_blank">pet=
ertodd.org</a><br>
000000000000005576673e616271f762a5d8779d5fe7796c6e43ed43df5aa189<br>
</font></span><br>---------------------------------------------------------=
---------------------<br>
This SF.net email is sponsored by Windows:<br>
<br>
Build for Windows Store.<br>
<br>
<a href=3D"http://p.sf.net/sfu/windows-dev2dev" target=3D"_blank">http://p.=
sf.net/sfu/windows-dev2dev</a><br>_________________________________________=
______<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
<br></blockquote></div><br></div></div>

--001a11c3738a46f9bc04ded3807e--