On Tue, Sep 25, 2012 at 1:34 PM, Jorge Timón wrote:
> On 9/23/12, Jeff Garzik wrote:
>> - provides a deterministic lifetime for a TX; if you KNOW a TX will
>> disappear 144 blocks (24 hours) after you stop transmitting, then it
>> is probably safe to initiate recovery procedures and perhaps revis
On 9/23/12, Jeff Garzik wrote:
> - provides a deterministic lifetime for a TX; if you KNOW a TX will
> disappear 144 blocks (24 hours) after you stop transmitting, then it
> is probably safe to initiate recovery procedures and perhaps revise
> the transaction
> - prevents zombie TXs from littering
> Sounds good— my only concern is that nodes will repeat their own
> transactions but not the unconfirmed parents.
Nodes repeat wallet transactions and any previous transactions that
are not yet included in the chain (see
CWalletTx::RelayWalletTransaction). So I don't think it's an issue.
(ok, bi
On Sun, Sep 23, 2012 at 4:30 PM, Jeff Garzik wrote:
> Yeah, my public nodes currently have 2200+ Over time, it gets
> cluttered naturally due to the disconnect between what miners mine and
> what relayers relay.
Right, this disconnect is why simple scalar measures of mempool size
aren't terribly
On Sun, Sep 23, 2012 at 8:12 AM, Mike Hearn wrote:
> Has anyone got long term longs that contain the pool size and timestamps?
>
> Unfortunately I forgot to enable timestamps in the logs for my own
> nodes (the privacy benefit of disabling this by default is
> questionable, imho). But just looking
Has anyone got long term longs that contain the pool size and timestamps?
Unfortunately I forgot to enable timestamps in the logs for my own
nodes (the privacy benefit of disabling this by default is
questionable, imho). But just looking at the general trends and
cross-checking against my own memo
6 matches
Mail list logo
