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 jgar...@bitpay.com wrote:
On Fri, Aug 8, 2014
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
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)
wrote:
On Thu, Jul 31, 2014 at 1:47 PM, Kaz Wesley kezi...@gmail.com 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 coding page.
Given that you
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 gmaxw...@gmail.com wrote:
On Thu, Jul 31, 2014 at 2:41 PM, Kaz Wesley kezi...@gmail.com wrote:
the need to have transmitted
On Thu, Jul 31, 2014 at 4:18 PM, Gregory Maxwell gmaxw...@gmail.com wrote:
On Thu, Jul 31, 2014 at 3:27 PM, Kaz Wesley kezi...@gmail.com 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 need to solve
On Thu, Jul 31, 2014 at 6:06 PM, Peter Todd p...@petertodd.org 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
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
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
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
17, 2014 at 3:46 PM, Gavin Andresen gavinandre...@gmail.com wrote:
A couple of half-baked thoughts:
On Thu, Jul 17, 2014 at 5:35 PM, Kaz Wesley kezi...@gmail.com wrote:
If there's support for this proposal, I can begin working on the specific
implementation details, such as the bloom filters
11 matches
Mail list logo
