On Wed, May 6, 2015 at 8:37 AM, Jorge Timón jti...@jtimon.cc wrote:
This gives you less flexibility and I don't think it's necessary.
Please let's try to avoid this if it's possible.
It is just a switch that turns on and off the new mode.
In retrospect, it would be better to just up the
I think that should be greater than in the comparison? You want it to fail
if the the height of the UTXO plus the sequence number is greater than the
spending block's height.
There should be an exception for final inputs. Otherwise, they will count
as relative locktime of 0x. Is this
What I was describing was an attempt to fix a similar proposal by Mark
Friedenbach, but it didn't needed fixing: I was simply
misunderstanding it.
Mark's RCLTV is completely reorg safe, so there's no need for the 100
block restriction. It also keeps the script validation independent
from the utxo.
On 04/21/15 07:59, Peter Todd wrote:
On Mon, Mar 16, 2015 at 10:22:13PM +, Matt Corallo wrote:
In building some CLTV-based contracts, it is often also useful to have a
method of requiring, instead of locktime-is-at-least-N,
locktime-is-at-least-N-plus-the-height-of-my-input. ie you could
Even if it's new and has not received any feedback, I think my solution to
op_maturity is quite clean.
But anyway, yes, the non-relative cltv is much simpler in design and
doesn't have to wait for the other. On the other hand, I would upgrade it
to absolute cltv like you suggested and take the
On Sun, Apr 26, 2015 at 02:20:04PM +0200, Jorge Timón wrote:
On Sun, Apr 26, 2015 at 1:35 PM, Jorge Timón jti...@jtimon.cc wrote:
And a new softfork rule could enforce that all new CTxIn set nHeight
to the correct height in which its corresponding prevout got into the
chain.
That would
On Sun, Apr 26, 2015 at 1:35 PM, Jorge Timón jti...@jtimon.cc wrote:
There's another possibility that could keep the utxo out of Script
verification:
class CTxIn
{
public:
COutPoint prevout;
CScript scriptSig;
uint32_t nSequence;
}
could turn into:
class CTxIn
{
On Tue, Apr 21, 2015 at 9:59 AM, Peter Todd p...@petertodd.org wrote:
Thus we have a few possibilities:
1) RCLTV against nLockTime
Needs a minimum age COINBASE_MATURITY to be safe.
2) RCLTV against current block height/time
Completely reorg safe.
Yes, can we call this one OP_MATURITY
On Mon, Mar 16, 2015 at 10:22:13PM +, Matt Corallo wrote:
In building some CLTV-based contracts, it is often also useful to have a
method of requiring, instead of locktime-is-at-least-N,
locktime-is-at-least-N-plus-the-height-of-my-input. ie you could imagine
an
I'm in favor of relative CHECKLOCKTIMEVERIFY, but I don't have a very
specific reason. I just have a vague worry that there can be race
conditions in which a txn with an absolute CHECKLOCKTIMEVERIFY goes
into the blockchain later than one of its signers expected that it
would, and therefore there
In building some CLTV-based contracts, it is often also useful to have a
method of requiring, instead of locktime-is-at-least-N,
locktime-is-at-least-N-plus-the-height-of-my-input. ie you could imagine
an OP_RELATIVECHECKLOCKTIMEVERIFY that reads (does not pop) the top
stack element, adds the
11 matches
Mail list logo
