I suspect it is something that is going to have to be dealt with in the
future (I just don't know how yet).
The web has managed to survive despite constant fast crawls being the norm
for the past 10 years or so. I wouldn't worry too much about this unless
you can prove that a big chunk of
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I may be able to provide some insight regarding request volume / abuse via my
public node at http://statoshi.info
My node receives a 'getaddr' request about every 50 seconds:
http://i.imgur.com/XEpnWfG.png
In terms of the 'addr' messages that it
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/30/2014 09:50 PM, Alan Reiner wrote:
(though, in the future, we hope to provide an optional service to
help synchronize the data between parties)
Before rolling your own service, it might be a good idea to add
Bitmessage integration to
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)
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 know
the need to have transmitted the transaction list [..] first
32 bits per transaction is at least double the communication overhead
of the simple approach, and only offers a bound on the probability of
needing a round trip.
On Thu, Jul 31, 2014 at 2:29 PM, Gregory Maxwell gmaxw...@gmail.com
On Thu, Jul 31, 2014 at 2:41 PM, Kaz Wesley kezi...@gmail.com wrote:
the need to have transmitted the transaction list [..] first
32 bits per transaction is at least double the communication overhead
of the simple approach, and only offers a bound on the probability of
needing a round trip.
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 that problem, since the protocol
already involves exchanging the information necessary to determine
(with some false positives) what a peer is missing,
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 that problem, since the protocol
already involves exchanging the information
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 that
On Thu, Jul 31, 2014 at 05:58:23PM -0700, Kaz Wesley wrote:
I have a proposal for a way to add finite and predictable lifespans to
transactions in mempools: we d̶e̶s̶t̶r̶o̶y̶ ̶t̶h̶e̶
̶r̶e̶s̶u̶r̶r̶e̶c̶t̶i̶o̶n̶ ̶h̶u̶b̶ use nLockTime and a new standardness
rule. It could be done in stages, would
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
It would make more sense to introduce a new script opcode that pushes the
current block height onto the operand stack. Then you could implement arbitrary
logic about which blocks the transaction can be valid in. This would require
that the client revalidate all transactions in its mempool
On Thu, Jul 31, 2014 at 6:38 PM, Matt Whitlock b...@mattwhitlock.name wrote:
It would make more sense to introduce a new script opcode that pushes the
current block height onto the operand stack. Then you could implement
arbitrary logic about which blocks the transaction can be valid in. This
On Thursday, 31 July 2014, at 7:28 pm, Gregory Maxwell wrote:
On Thu, Jul 31, 2014 at 6:38 PM, Matt Whitlock b...@mattwhitlock.name wrote:
It would make more sense to introduce a new script opcode that pushes the
current block height onto the operand stack. Then you could implement
On Thu, Jul 31, 2014 at 8:26 PM, Matt Whitlock b...@mattwhitlock.name wrote:
I understand what you're saying, but I don't understand why it's a problem.
Transactions shouldn't be considered final until a reasonable number of
confirmations anyway, so the possibility that an accepted
16 matches
Mail list logo
