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
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
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
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)
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
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
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
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
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
9 matches
Mail list logo
