<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On 10 June 2013 23:09, Peter Todd <span dir="ltr"><<a href="mailto:pete@petertodd.org" target="_blank">pete@petertodd.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">So here'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's getblocktemplate and their local one. When they find a share<br>
if it doesn'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'll need persistent share storage so if your connection disconnects<br>
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'll never build on an invalid block, economically rational while<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't.<br>
<br>
Of course, the other option is to build a block extending the one you<br>
don'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'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'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't be contacted.<br>
<br>
+ possible protocol extensions<br></blockquote><div><br></div><div>Sounds very promising. Suspect it will need a fair amount of testing ...<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="HOEnZb"><font color="#888888"><br>
<br>
--<br>
'peter'[:-1]@<a href="http://petertodd.org" target="_blank">petertodd.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="http://p.sf.net/sfu/windows-dev2dev" target="_blank">http://p.sf.net/sfu/windows-dev2dev</a><br>_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href="mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-development@lists.sourceforge.net</a><br>
<a href="https://lists.sourceforge.net/lists/listinfo/bitcoin-development" target="_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-development</a><br>
<br></blockquote></div><br></div></div>