29

Sequence numbers aren't shown on the Bitcoin Block Explorer HTML pages because they are not used by the network currently. Non-default sequence numbers would be shown on raw block/tx pages, but I'm not sure whether this has ever happened. Sequence numbers are intended to be used for replacement. Replacement is currently disabled, but how it would work is: ...


16

Note that the accepted answer is outdated. Currently, sequence numbers are mainly used for signaling RBF - replace-by-fee - that allows you to resend a transaction with a higher fee. See https://bitcoincore.org/en/faq/optin_rbf/ , https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki


8

Original meaning of nSequence in transactions nSequence is a 4 byte input level feature. The original meaning of nSequence was to allow modification of transactions in the mempool. So, if the nSequence value of the input was less than 0xFFFFFFFF (4294967295 in decimal), it indicated a transaction that was not yet finalized. Such a transaction would be held ...


6

No, there isn't currently any way to do what you describe without using a third-party oracle. Yes, you may be able to do this relatively soon. A soft fork has been proposed to introduce a OP_CHECKLOCKTIMEVERIFY op code` (CLTV), and what what I can tell it has strong support from the core dev team (but note that soft forks require miner support for ...


5

It stand for a number, it is commonly used in programming to designate a variable that gonna hold an amount of something see: https://en.bitcoin.it/wiki/NLockTime and https://en.bitcoinwiki.org/wiki/NSequence


4

If you're creating a version 2 transaction with the disable flag not set, then by definition the whole nSequence value will be less than 0xFFFFFFFE (because it will be at most 0x7FFFFFFF). This implies that a transaction with an active relative locktime will always be replacable according to BIP125. This is intentional. Nonreplacable transactions attempt ...


4

TL;DR: It seems that Bitcoin Wallet for Android incorrectly labels nLockTime transactions as OptInRBF due to a bug in bitcoinj. The issue has been reported. You don't need to do anything. Apparently, Bitcoin Wallet for Android recognized your transaction as OptInRBF (as pointed out by the code you found). The warning you are seeing was only added to the ...


3

For a transaction to be processed it must use the very next available sequence number (as returned by account_info). If an otherwise valid signed transaction has a sequence number too small (matching a previously used sequence number), then the transaction is guaranteed to never be valid and will produce an error and should be discarded by servers receiving ...


3

If you look at git blame of BOLT 03 you can track the sentence regarding the locktime down to this commit: https://github.com/lightningnetwork/lightning-rfc/commit/f1eaa2544665c9b85a2fd95be9c83dad45888982 luckily the author gave a good explanation in the commitment message in git of why the 0x20 was introduced for the upper 8 bits in the locktime field (I ...


3

Sequence is part of any input, before segwit as well. feffffff is the hexadecimal number 0xfffffffe because the bytes need to be reversed. This sequence number, as per BIP 125, is because: Wallets that don't want to signal replaceability should use either a max sequence number (0xffffffff) or a sequence number of (0xffffffff-1) when then also want to use ...


3

Say that currently, the block height is 377199. If I wanted to send money to someone, but only have them receive it at some time in the future, then I could make a transaction to their address, set the locktime to 400000 and set all sequence numbers in the transaction to 0xffffffff. This transaction will get mined into block 377200 or maybe 377201. ...


2

I'm unable to find the bitcointalk thread/github issue discussing this, but a block index opcode was considered and rejected. The reason (IIRC) is that it's important that if a transaction does not get into a block, it can still be included in another block. It would be very surprising if a transaction was reversed because the block it was in became extinct,...


2

The other answers here are currently outdated because OP_CSV and OP_CHECKLOCKTIMEVERIFY were adopted by the network, both of which provide ways to do construct locked outputs.


2

The only other relevance of the nSequence field is as relative locktime (in version 2 transactions); see BIP 68. If you do use relative locktime, they will determine the value of nSequence. If you don't use that feature, any nSequence lower than 0xfffffffe will do. In BIP125, there is no need for strictly increasing nSequence versions. instead, the ...


2

I could broadcast a second transaction that has the same inputs but a higher fee, without marking the original transaction as replaceable. Default node behaviour is to accept the first-seen transaction into the node's mempool. So your second transaction that spends the same inputs would likely be dropped by most nodes, and thus it would be less reliably ...


1

i manage to find answer for myself. OP_CSV date consensus is based on median time past (mtp), not block's confirmed date. once funding tx above has been confirmed, it is located in block#1609592 with block MTP is 2019-11-24 09:05:26 (UTC 0). At same time, chain's MTP is 2019-11-24 09:25:27 (UTC 0) now come to spending tx, since utxo's confirmed date i ...


1

The sequence number is always 4 bytes, it is a fixed size, little endian, 32 bit integer which makes it always 4 bytes. What you are missing is the scriptSig. The scriptSig always begins with the size of the script (as a compact size unsigned integer). If the scriptSig is empty, then the size must still be there to say that it is a 0 length byte. So the ...


1

If you look at https://blockstream.info/address/bc1qdv0fk4c73fem89s708pzdny8q25d7k5nrckckp87c8alwaw803fq3mqrpz you will see that there are two transactions. The first one https://blockstream.info/tx/943f18e17aa2ba716f2d13785268a1bd6b25c39d2718f3b4785559a5eeaba883 is the funding TX to open the payment channel included in block 587093 (at least according to ...


1

Note: Although this answer is written for testnet, it is absolutely valid for the mainnet as well. The script will be similar, just the address encoding will be different (P2PKH start with 1 vs m for testnet as we use 0x00 as prefix in address base58check in mainnet). I tried to make transaction with Locktime on bitcoin testnet. I am not able to broadcast ...


1

The tx is located with the person who created it. Nodes will not hold onto the transaction because it is not ready for the mempool. The only places a node will hold someone else's transaction is in the mempool or in the blockchain so a node will not store a non-final transaction anywhere. It is up to the transaction creator to hold onto the transaction and ...


1

I believe you can use either at this stage. The marker and the flag show let the client decipher which scheme is being used and interpret appropriately. lockTime sets when the transaction is valid from. 0x00 is from the first block, 0x11 is from a later block. You can continue to use 0x00 if you wish. https://bitcoin.org/en/glossary/locktime. Most ...


1

BTCJerk on reddit noticed that "Blockchain.info is having issues, the last block they show is 442341". Other block explorers were already on block 442349… Since the transaction was timelocked until block 442345, and timelocked transactions are considered invalid until the appropriate blockchain height is reached, blockchain.info was still considering the ...


1

When a specific locktime is specified in the nLockTime field in a transaction. It means that said transaction cannot be broadcasted/be accepted by miners until either the blockheight or unixtime has elapsed. On the other hand, when a OP_CSV is used, it means that a transaction referencing said input cannot be spent until some blockheight or unixtime has ...


Only top voted, non community-wiki answers of a minimum length are eligible