A new network tx field would have the same problem, right?
With a child-refreshes-parent policy, someone wishing to redeem a
transaction that has passed its relay window without being confirmed could
still do so.
On Aug 8, 2014 11:16 AM, "Jeff Garzik" wrote:
> On Fri, Aug 8, 2014 at 1:38 PM, Tom
> In general, if a transaction has not made it into a block within 144*X
> blocks, there is _some_ reason it is getting rejected by the miners.
This is the crux of my concern: relay policy and miner priorities will
not necessarily always be in sync, and node resource management
shouldn't rely on
On Thu, Jul 31, 2014 at 6:06 PM, Peter Todd wrote:
> Anything that changes the semantics of nLockTime will do harm to
> existing and future applications that make use of nLockTime for things
> like refund transactions.
I think this would be compatible with most uses of nLockTime -- e.g.,
at the t
On Thu, Jul 31, 2014 at 4:18 PM, Gregory Maxwell wrote:
> On Thu, Jul 31, 2014 at 3:27 PM, Kaz Wesley wrote:
>>> the FEC still lets you fill in the missing transactions without knowing in
>>> advance all that will be missing.
>>
>> I don't see why we
There is currently little in place for managing transaction lifetime
in the network's mempools (see discussion in github in #3722 "mempool
transaction expiration", and it seems to be a major factor blocking
some mempool exchange, see #1833/1918, #3721). Expiry per-node a
certain amount of wall time
block forwarding time that can't be realized by FEC-based mempool
synchronization, implemented separately from channel-memory based
index-coding?
On Thu, Jul 31, 2014 at 2:51 PM, Gregory Maxwell wrote:
> On Thu, Jul 31, 2014 at 2:41 PM, Kaz Wesley wrote:
>>> the need to have
u, Jul 31, 2014 at 1:47 PM, Kaz Wesley wrote:
>> trip to request the missing tx; if we could somehow get the "What's
>> the Difference" approach to effectively operate on full transactions
>> instead
>
> I explain how to do this on the network block codin
I don't see how set reconciliation alone would be practical for
condensed block exchange -- if the keys are txids it'd require a round
trip to request the missing tx; if we could somehow get the "What's
the Difference" approach to effectively operate on full transactions
instead, the log(keysize) f
The inv trickling mechanism currently serves two purposes:
- protect casual users' privacy by slightly obscuring a tx's originating node
- reduce invs unnecessarily sent both directions for a connection
It has some drawbacks:
- it slows transaction propagation
- it delays knowledge between two node
I've updated the gist, and added an additional proposal that I think
meshes well:
https://gist.github.com/kazcw/43c97d3924326beca87d#ultra-fast-block-validation
sparseblocks + UFBV would tighten the new-block process to this (when
txes have been received in advance):
- receive block (~2kB for 1000
es of invs.
On Fri, Jul 18, 2014 at 10:48 AM, Jeff Garzik wrote:
> On a flood-fill network, you don't want to create a storm of "I
> already have this" replies.
>
> On Fri, Jul 18, 2014 at 1:39 PM, Kaz Wesley wrote:
>> Peers exchanging mempool priority policies is
Peers exchanging mempool priority policies is great; that accomplishes
the flexibility in what txes to remember that I was going for with the
forget-filters, but much more neatly, with less overhead and some side
benefits.
Here's what I'm picturing now:
- exchange priority policies in peer introdu
ter arrives.
On Thu, Jul 17, 2014 at 3:46 PM, Gavin Andresen wrote:
>
> A couple of half-baked thoughts:
>
> On Thu, Jul 17, 2014 at 5:35 PM, Kaz Wesley wrote:
>>
>> If there's support for this proposal, I can begin working on the specific
>> implementa
OVERVIEW
To improve block propagation, add a new block message that doesn't include
transactions the peer is known to have. The message must never require an
additional round trip due to any transactions the peer doesn't have, but
should
be compatible with peers sometimes forgetting transactions t
14 matches
Mail list logo
