Having explored more drastic approaches, it looks like Kaz' basic idea
stands well. His #1...
1. start setting nLockTime to the current height by default in newly
created transactions (or slightly below the current height, for
reorg-friendliness)
is already implemented in bitcoin-qt #2340,
On Fri, Aug 8, 2014 at 1:38 PM, Tom Harding t...@thinlink.com wrote:
4. add a new IsStandard rule rejecting transactions with an nLockTime
more than N blocks behind the current tip (for some fixed value N, to
be determined)
It cannot be assumed that transaction creation time and transaction
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
How is eventual expiration of a tx that started life with an nLockTime
in the future breaking, any more than any other tx expiring?
On 8/6/2014 6:54 AM, Mike Hearn wrote:
We could however introduce a new field in a new tx version. We know we
need to rev the format at some point anyway.
...because nLockTime is the exact opposite of expiration. A locked TX
begins life invalid, and becomes valid (not-expired) after nLockTime passes.
A new field containing expiration time would work.
On Wed, Aug 6, 2014 at 10:44 AM, Tom Harding t...@thinlink.com wrote:
How is eventual
+1 for the new field, overloading fields with new meaning is definitely not
a good idea.
Something like nExpireAt with a block height sounds reasonable to me, but
we need to document that the usual caveats with blockchain reorgs apply.
On Wed, Aug 6, 2014 at 4:08 PM, Jeff Garzik
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 6 August 2014 08:17:02 GMT-07:00, Christian Decker
decker.christ...@gmail.com wrote:
+1 for the new field, overloading fields with new meaning is definitely
not
a good idea.
To add a new field the best way to do it is create a new, parallel,
A fork is not necessarily required, if you are talking about information
that deals primarily with pre-consensus mempool behavior. You can make a
network TX with some information that is digitally signed, yet discarded
before it reaches miners.
On Wed, Aug 6, 2014 at 11:42 AM, Peter Todd
Today we have first-eligible-height (nLockTime), and mempool expiration
measured from this height would work for the goals being discussed, no
fork or protocol rev.
With first-eligible-height and last-eligible-height, creator could
choose a lifetime shorter than the max, and in addition,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 6 August 2014 09:31:24 GMT-07:00, Mark Friedenbach m...@monetize.io wrote:
I highly doubt that is the best approach.
If this nExpiry field is a consensus rule, then the Merkle tree or the
appropriate paths through needs to be included with the
That won't necessarily work through large reorgs. You don't want to create
a situation where a miner cannot mine a previously mined transactions.
On Wed, Aug 6, 2014 at 1:02 PM, Tom Harding t...@thinlink.com wrote:
Today we have first-eligible-height (nLockTime), and mempool expiration
On 08/06/2014 01:02 PM, Tom Harding wrote:
With first-eligible-height and last-eligible-height, creator could
choose a lifetime shorter than the max, and in addition, lock the whole
thing until some point in the future.
Note that this would be a massive, *massive* change that would
completely
On 08/06/2014 01:20 PM, Peter Todd wrote:
The general case doesn't require transmission of any merkle data; it
is derived from the tx data.
How can that possibly be the case? The information is hidden behind the
Merkle root in the transaction. The validator needs to know whether
there is an
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 6 August 2014 10:21:56 GMT-07:00, Mark Friedenbach m...@monetize.io wrote:
On 08/06/2014 01:02 PM, Tom Harding wrote:
With first-eligible-height and last-eligible-height, creator could
choose a lifetime shorter than the max, and in addition,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 6 August 2014 10:30:11 GMT-07:00, Mark Friedenbach m...@monetize.io wrote:
On 08/06/2014 01:20 PM, Peter Todd wrote:
The general case doesn't require transmission of any merkle data; it
is derived from the tx data.
How can that possibly be
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
Glad this was brought up.
Transaction expiration is something that I have wanted to see happen in
bitcoin for a long, long time. The user experience of unconfirming
transactions setting around in limbo is just horrible. Bitcoin software by
necessity has gotten better about attaching fees so
A distinction there is that they can only become invalid via a
conflict— replaced by another transaction authored by the prior
signers. If no other transaction could be created (e.g. you're a
multisigner and won't sign it again) then there is no such risk.
You need to check transaction's
The user experience of unconfirming transactions setting around in limbo
is just horrible. Bitcoin software by necessity has gotten better about
attaching fees so this sort of behavior is uncommon, but that does not
eliminate the problem.
Yes, indeed. I suspect there's a quick hack that
I feel like a lot of this will be driven by implementation, and costs of
changing the implementation. Additional look-backs are of course doable,
but they incur some disk I/O costs. The fields available in memory for
each mempool TX are
uint256 tx_hash; // hash of next field
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 Tue, Aug 5, 2014 at 3:10 PM, Kaz Wesley kezi...@gmail.com wrote:
Any approach based on beginning a transaction expiry countdown when a
transaction is received (as in mempool janitor) seems unviable to me:
...
That's why I think including information in the transaction itself, as
with my
On 8/5/2014 12:10 PM, Kaz Wesley wrote:
Any approach based on beginning a transaction expiry countdown when a
transaction is received (as in mempool janitor) seems unviable to me:
once a node has forgotten a transaction, it must be susceptible to
reaccepting it;
It's hard to argue with
On 7/31/2014 5:58 PM, Kaz Wesley wrote:
1. start setting nLockTime to the current height by default in newly
created transactions (or slightly below the current height, for
reorg-friendliness)
Reorg-frendliness is the opposite of the rationale behind #2340, which
proposes setting nLockTime at
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
30 matches
Mail list logo
