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
> > transact
On Fri, Jun 14, 2013 at 4:06 PM, Peter Todd 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 ones gives you th
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 c
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 do
On 10 June 2013 23:09, Peter Todd 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 g
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 thei
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
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 challe
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
9 matches
Mail list logo
