Yes, that is correct. The network will not relay until locktime reaches
"maturity", i.e. it can be confirmed into a block.
The wallet holds onto the transaction -- or simply does not generate --
until it can be confirmed.
On Sun, Jun 21, 2015 at 5:11 AM, Braun Brelin wrote:
> So, basically it
Hi,
Well, depends on your model and what you want to achieve. That would
depend on each wallet, I couldn't confirm nor deny that this is or isn't
true. You have to check with your wallet how it handles transactions
with nLockTime. Maybe you are the one who generates the nLockTime
transaction, but
So, basically it sounds as though the wallet generating the transaction is
what is responsible for holding on to the transaction and then
only releasing it to the network when the NLOCKTIME value is less than or
equal to the current time. Does that sound right?
Braun
On Sun, Jun 21, 2015 at 10:
Hi
I don't think that a transaction with nLockTime>0 will be accepted by
nodes / relayed in the Bitcoin network, until its time expires (e.g.
nLockTime==now). This means it obviously cannot be stored in a block,
before its locktime expires. nLockTime is designed in a way that you,
need to keep it
Hi all,
When a transaction with N_LOCKTIME>0 is created, does that transaction get
stored in a block on the blockchain or is it stored in the mempool until
the actual time (or block number) exceeds the current value? If it is
stored on the blockchain, how does that affect the concept of pruning t
5 matches
Mail list logo
