Sending using 'raw' instead of block height or date

[Charles-Tim]

I have been seen this quite sometimes ago when I was making transaction on desktop Electrum. If I want to make transaction, I click on send, input the amount I want to send, click on pay, click on 'advanced'. From there, I can decide to use a 'LockTime' which can be 'Raw', 'Block height' or 'Date', that depends on the one you decide to choose. I understand using the height or the date, the transaction would be broadcasted which are block height and date respectively, but what about raw?

For example, I want to make a bitcoin transaction, the 'raw' is at 1654427298. What does that 'raw' mean?

[1714864074]

1714864074

[1714864074]

1714864074

[1714864074]

1714864074

[1714864074]

1714864074

[ranochigo]

That is the actual value that goes into the nlocktime field of the transaction. As such, you can either specify a block height or the Unix time, depending on the value.

nLocktime takes either the block height or the time in Unix format. Electrum allows their user to specify the date and time using a standardized ISO8601 format, and converts it to unix in the background. If the nlocktime field is <500,000,000 , then the block height will be used. If any other value is indicated, then the block height unix time is considered.

[o_e_l_e_o]

It just means the date, but in raw Unix format. Put the number 1654427298 in to a Unix time stamp converter to "decode" it to a more familiar date and time, such as this one: https://www.unixtimestamp.com/

If the nlocktime field is <500,000,000 , then the block height will be used. If any other value is indicated, then the block height is considered.

What ranochigo meant to say (typo ) is any value below 500,000,000 is considered as a block height, and any value from 500,000,000 upwards is considered as a Unix time stamp. See here: https://github.com/bitcoin/bitcoin/blob/d492dc1cdaabdc52b0766bf4cba4bd73178325d0/src/script/script.h#L41-L43

[Charles-Tim]

---snipped---

---snipped---

Thank you both for the explanation. Which means I can easily just use date directly for the locktime.

@o_e_l_e_o, this has been the first time I ever known anything like Unix, I checked the site and saw the Unix format and able to convert real date to the Unix format, it is quite exciting to know about this.

[o_e_l_e_o]

@o_e_l_e_o, this has been the first time I ever known anything like Unix, I checked the site and saw the Unix format and able to convert real date to the Unix format, it is quite exciting to know about this.

It is widely used in the back end of electronic devices, computers, phones, etc., although most software will convert Unix time stamps to human readable date formats prior to displaying them. It is simply the number of seconds since 00:00:00 on 1st January 1970 UTC. It has the bonus of being unaffected by timezones, so is the same for everyone in the world at all times. It also ignores leap seconds, so every day Unix time increments by exactly 86,400.

Now, an interesting quirk for bitcoin. Unix time suffers from what is known as the Year 2038 problem. Most systems store Unix time as a 32 bit signed integer, meaning the values run between -2³¹ and 2³¹-1. This means that they will hit their maximum possible value of 2³¹-1 at 03:14:07 on 19th January 2038 UTC, causing them to overflow and experience an error. Bitcoin, on the other hand, stores Unix time as a 32 bit unsigned integer, meaning the values run between 0 and 2³²-1. This means that bitcoin won't experience this bug until 06:28:15 on 7th February 2106 UTC.