On Thu, Jul 31, 2014 at 8:26 PM, Matt Whitlock 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" transaction could
> becom
On Thursday, 31 July 2014, at 7:28 pm, Gregory Maxwell wrote:
> On Thu, Jul 31, 2014 at 6:38 PM, Matt Whitlock 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
On Thu, Jul 31, 2014 at 6:38 PM, Matt Whitlock 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
> would require th
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 (reall
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 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, wou
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 need to solve that problem, since the protoco
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
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 need to solve that problem, since the protocol
> already involves exchanging the information necessary to de
> 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 2:41 PM, Kaz Wesley 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.
"(e.g. from
> 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 wrote:
> On Thu, Jul 3
On Thu, 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 coding page.
Given that you know the sizes and o
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
-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 pro
-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 se
>
> 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
17 matches
Mail list logo
