nSequence and P2P exchange

Date: 2018-11-13

Source: https://craigwright.net/blog/bitcoin-blockchain-tech/nsequence-and-p2p-exchange

In the beginning, Bitcoin allowed two parties to engage in a peer-to-peer trade and exchange that was P2P and then to be sent to the blockchain (the miners) for settlement. Welcome to what Bitcoin was and will be again.

The original version of Bitcoin used sequence numbers. These cannot be seen on Bitcoin block explorers as they are now no longer used in Bitcoin and default to the final FFFF’FF time. Any non-default sequence numbers end up displayed only in raw transactions.

Sequence numbers were designed to be used for transaction replacement before a transaction was finalised. This feature has been disabled, but in Bitcoin SV we will have this in action again, allowing users the following:

Alice sends a transaction where the nLockTime value is set to a date in the future. We can start with anything, but by default we would start at a sequence number of 0.
The miners will not recognise this transaction to be valid, and thus, it is not “final”. The network of miners will not include it in a block before it is final, and that will only occur when the nLockTime value has been reached.
As the transaction cannot be included in a block until the time specified in the nLockTime is reached, there is a final state that both parties have agreed to and also the ability to send updated transactions. If there is a 2-of-3 address, the parties can use an escrow (such as a licenced shared registry) to ensure that a transaction that has been agreed is final. If not, we can also have the parties negotiate and allow a means to “pull out” of the negotiation at any time before the nLockTime deadline.
Using this method, and prior to when the set nLockTime is reached, the users can replace the transaction with a higher-version transaction. A higher sequence number is a newer version that replaces the ones before. That is, the network will accept the highest sequence number for transactions once the nLockTime has been reached, rejecting all others with a lower value.
The negotiations can also be finalised. If a party sets the sequence number to UINT_MAX, the transaction is considered as being finalised by the miners. No replacement can occur. When the sequence equals UINT_MAX, miners will no longer accept a replacement transaction even where the nLockTime value remains in the future.
If you ever want to lock the transaction permanently, you can set the sequence number to UINT_MAX. Then the transaction is considered to be final, even if the time represented in nLockTime remains in the future.

We can use this feature in the original version of Bitcoin to allow two (or more) negotiating parties to create and sign a prepared transaction.

These prepared transactions can be negotiated, agreed, and signed by the the parties allowing them to move money between each other. This can allow for a base agreement and payment stream. This is conducted securely and without fees — the fees paid are to the miners for the settled transaction, not the exchange.
Extended this would allow for a range of services to be created that involve users withdrawing and depositing funds into a service without waiting for confirmations.
If the user breaches the contract, the final transaction could be signed with an escrow to ensure compliance and that the merchant is not “cheated”.

As this was disabled in Bitcoin Core (BTC), all Bitcoin Core transactions use an nLockTime = 0 with a Sequence = UINT_MAX.

As was explained to Mike Hearn in the following post:


An unrecorded open transaction can keep being replaced until nLockTime. It may contain payments by multiple parties. Each input owner signs their input. For a new version to be written, each must sign a higher sequence number (see IsNewerThan). By signing, an input owner says "I agree to put my money in, if everyone puts their money in and the outputs are this."


There are other options in SignatureHash such as SIGHASH_SINGLE which means "I agree, as long as this one output (i.e. mine) is what I want, I don't care what you do with the other outputs.". If that's written with a high nSequenceNumber, the party can bow out of the negotiation except for that one stipulation, or sign SIGHASH_NONE and bow out completely.

The parties could create a pre-agreed default option by creating a higher nSequenceNumber tx using OP_CHECKMULTISIG that requires a subset of parties to sign to complete the signature. The parties hold this tx in reserve and if need be, pass it around until it has enough signatures.

One use of nLockTime is high frequency trades between a set of parties.


They can keep updating a tx by unanimous agreement. The party giving money would be the first to sign the next version. If one party stops agreeing to changes, then the last state will be recorded at nLockTime. If desired, a default transaction can be prepared after each version so n-1 parties can push an unresponsive party out. Intermediate transactions do not need to be broadcast. Only the final outcome gets recorded by the network. Just before nLockTime, the parties and a few witness nodes broadcast the highest sequence tx they saw.

The end, is that we can create payment channels and more. This includes high-frequency trades and transactions including auctions.

So much has been lost in those wanting to change Bitcoin rather than in understanding it.

This design is secure. Those who say that a miner can collude, specifically “one party could collude with a miner to commit a non-final version of the transaction”, never understood Bitcoin nor the capability of script. Bitcoin is an economic system that uses technology.

That all changes. Bitcoin will remain cash, and it returns to the first version: 0.1.0 as was set in stone.

Notes:

See the following pages:

Extracted Insights (14 total, showing top 10)

R8 In the beginning, Bitcoin allowed two parties to engage in a peer-to-peer trade and exchange that was P2P and then to be sent to the blockchain (the miners) for settlement. Welcome to what Bitcoin was...

R7 The original version of Bitcoin used sequence numbers. These cannot be seen on Bitcoin block explorers as they are now no longer used in Bitcoin and default to the final FFFF’FF time. Any non-default ...

R7 Sequence numbers were designed to be used for transaction replacement before a transaction was finalised. This feature has been disabled, but in Bitcoin SV we will have this in action again, allowing ...

R7 - Alice sends a transaction where the nLockTime value is set to a date in the future. We can start with anything, but by default we would start at a sequence number of 0. - The miners will not recogni...

R7 - These prepared transactions can be negotiated, agreed, and signed by the the parties allowing them to move money between each other. This can allow for a base agreement and payment stream. This is c...

R7 This design is secure. Those who say that a miner can collude, specifically “one party could collude with a miner to commit a non-final version of the transaction”, never understood Bitcoin nor the ca...

R5 We can use this feature in the original version of Bitcoin to allow two (or more) negotiating parties to create and sign a prepared transaction.

R5 As this was disabled in Bitcoin Core (BTC), all Bitcoin Core transactions use an nLockTime = 0 with a Sequence = UINT_MAX.

R5 ``` An unrecorded open transaction can keep being replaced until nLockTime. It may contain payments by multiple parties. Each input owner signs their input. For a new version to be written, each must ...

R5 ``` They can keep updating a tx by unanimous agreement. The party giving money would be the first to sign the next version. If one party stops agreeing to changes, then the last state will be recorded...

+ 4 more insights

← Back to archive