Re: [Bitcoin-development] Decentralizing mining

2013-06-17 Thread Jeff Garzik
On Fri, Jun 14, 2013 at 4:06 PM, Peter Todd p...@petertodd.org wrote: It strikes me that this would work best if the pool has a mempool with child-pays-for-parent support where conflicts *are* allowed. IE you record whatever transactions you know about, conflicting or not, calculate which

Re: [Bitcoin-development] Decentralizing mining

2013-06-17 Thread Peter Todd
On Mon, Jun 17, 2013 at 11:16:01AM -0400, Jeff Garzik wrote: Part of the broader issue that when we send peers INV advertisements we should be telling them what the fee/kb is so our peers can prioritize properly. That'd also help for the case where you want to broadcast two transactions in

Re: [Bitcoin-development] Decentralizing mining

2013-06-14 Thread Peter Todd
On Mon, Jun 10, 2013 at 09:23:14PM +, Luke-Jr wrote: 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

Re: [Bitcoin-development] Decentralizing mining

2013-06-14 Thread Luke-Jr
On Friday, June 14, 2013 8:06:54 PM Peter Todd wrote: On Mon, Jun 10, 2013 at 09:23:14PM +, Luke-Jr wrote: Might as well just use higher difficulty shares (each one audited) for the same effect. Block proposals allow the miner to tell the pool its transaction set once (per txset change)

Re: [Bitcoin-development] Decentralizing mining

2013-06-10 Thread Peter Todd
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

Re: [Bitcoin-development] Decentralizing mining

2013-06-10 Thread Luke-Jr
On Monday, June 10, 2013 9:09:13 PM Peter Todd wrote: # Protocol Work This is basically done. 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

Re: [Bitcoin-development] Decentralizing mining

2013-06-10 Thread Melvin Carvalho
On 10 June 2013 23:09, Peter Todd p...@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

Re: [Bitcoin-development] Decentralizing mining

2013-05-31 Thread Adam Back
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