Bitcoin Forum

Bitcoin => Bitcoin Technical Support => Topic started by: Charles-Tim on June 05, 2022, 11:15:31 AM



Title: Sending using 'raw' instead of block height or date
Post by: Charles-Tim on June 05, 2022, 11:15:31 AM
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?


Title: Re: Sending using 'raw' instead of block height or date
Post by: ranochigo on June 05, 2022, 11:22:03 AM
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.


Title: Re: Sending using 'raw' instead of block height or date
Post by: o_e_l_e_o on June 05, 2022, 11:43:29 AM
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 :P) 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


Title: Re: Sending using 'raw' instead of block height or date
Post by: Charles-Tim on June 05, 2022, 12:34:39 PM
---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 (https://www.unixtimestamp.com/) and saw the Unix format and able to convert real date to the Unix format, it is quite exciting to know about this.


Title: Re: Sending using 'raw' instead of block height or date
Post by: o_e_l_e_o on June 05, 2022, 12:58:36 PM
@o_e_l_e_o, this has been the first time I ever known anything like Unix, I checked the site (https://www.unixtimestamp.com/) 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 (https://en.wikipedia.org/wiki/Year_2038_problem). Most systems store Unix time as a 32 bit signed integer, meaning the values run between -231 and 231-1. This means that they will hit their maximum possible value of 231-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 232-1. This means that bitcoin won't experience this bug until 06:28:15 on 7th February 2106 UTC.