From 559aa39c6d5659292af5e0769e20f97ab4d8392e Mon Sep 17 00:00:00 2001 From: Abu Shifrah <35174370+muaawiyahtucker@users.noreply.github.com> Date: Sat, 5 Jul 2025 09:07:22 +0300 Subject: [PATCH 1/3] Corrected rounding error and used mapfile to better handle the results from array --- src/04_2_i_txfee-calc.sh | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/src/04_2_i_txfee-calc.sh b/src/04_2_i_txfee-calc.sh index 64a884a23..4fea0c369 100644 --- a/src/04_2_i_txfee-calc.sh +++ b/src/04_2_i_txfee-calc.sh @@ -1,14 +1,14 @@ #!/bin/bash -if [ -z $1 ]; +if [ -z "$1" ]; then echo "You must include the raw transaction hex as an argument."; exit; fi -usedtxid=($(bitcoin-cli decoderawtransaction $1 | jq -r '.vin | .[] | .txid')) -usedvout=($(bitcoin-cli decoderawtransaction $1 | jq -r '.vin | .[] | .vout')) -btcin=$(for ((i=0; i<${#usedtxid[*]}; i++)); do txid=${usedtxid[i]}; vout=${usedvout[i]}; bitcoin-cli listunspent | jq -r '.[] | select (.txid | contains("'${txid}'")) | select(.vout | contains('$vout')) | .amount'; done | awk '{s+=$1} END {print s}') -btcout=$(bitcoin-cli decoderawtransaction $1 | jq -r '.vout [] | .value' | awk '{s+=$1} END {print s}') -btcout_f=$(awk -v btcout="$btcout" 'BEGIN { printf("%f\n", btcout) }' Date: Sat, 5 Jul 2025 10:02:24 +0300 Subject: [PATCH 2/3] Added the same 8 decimal to the btcin for consistency. --- src/04_2_i_txfee-calc.sh | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/04_2_i_txfee-calc.sh b/src/04_2_i_txfee-calc.sh index 4fea0c369..c918c694f 100644 --- a/src/04_2_i_txfee-calc.sh +++ b/src/04_2_i_txfee-calc.sh @@ -8,7 +8,7 @@ fi mapfile -t usedtxid < <(bitcoin-cli decoderawtransaction "$1" | jq -r '.vin | .[] | .txid') mapfile -t usedvout < <(bitcoin-cli decoderawtransaction "$1" | jq -r '.vin | .[] | .vout') -btcin=$(for ((i=0; i<${#usedtxid[*]}; i++)); do txid=${usedtxid[i]}; vout=${usedvout[i]}; bitcoin-cli listunspent | jq -r '.[] | select (.txid | contains("'"${txid}"'")) | select(.vout | contains('"$vout"')) | .amount'; done | awk '{s+=$1} END {print s}') -btcout=$(bitcoin-cli decoderawtransaction "$1" | jq -r '.vout [] | .value' | awk '{s+=$1} END {print "%.8f\n, s}') +btcin=$(for ((i=0; i<${#usedtxid[*]}; i++)); do txid=${usedtxid[i]}; vout=${usedvout[i]}; bitcoin-cli listunspent | jq -r '.[] | select (.txid | contains("'"${txid}"'")) | select(.vout | contains('"$vout"')) | .amount'; done | awk '{s+=$1} END {printf "%.8f\n, s}') +btcout=$(bitcoin-cli decoderawtransaction "$1" | jq -r '.vout [] | .value' | awk '{s+=$1} END {printf "%.8f\n, s}') btcout_f=$(awk -v btcout="$btcout" 'BEGIN { printf("%.8f\n", btcout) }' Date: Sat, 5 Jul 2025 11:37:54 +0300 Subject: [PATCH 3/3] Corrected the use of nTimeLock to nLockTime, and deleted an erronious hex code --- 11_3_Using_CSV_in_Scripts.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/11_3_Using_CSV_in_Scripts.md b/11_3_Using_CSV_in_Scripts.md index 745f9b99a..ec0a994c2 100644 --- a/11_3_Using_CSV_in_Scripts.md +++ b/11_3_Using_CSV_in_Scripts.md @@ -12,19 +12,19 @@ A relative timelock is a lock that's placed on a specific input of a transaction Easy! -> :information_source: **NOTE — SEQUENCE:** This is the third use of the `nSequence` value in Bitcoin. Any `nSequence` value without the 32nd bit set (1<<31), so 0x00000001 to 0x7ffffffff, will be interpreted as a relative timelock if `nVersion ≥ 2` (which is the default starting in Bitcoin Core 0.14.0). You should be careful to ensure that relative timelocks don't conflict with the other two uses of `nSequence`, for signalling `nTimeLock` and RBF. `nTimeLock` usually sets a value of 0xffffffff-1, where a relative timelock is disallowed; and RBF usually sets a value of "1", where a relative timelock is irrelevent, because it defines a timelock of 1 block. +> :information_source: **NOTE — SEQUENCE:** This is the third use of the `nSequence` value in Bitcoin. Any `nSequence` value without the 32nd bit set (1<<31), so 0x00 00 00 01 to 0x7f ff ff ff, will be interpreted as a relative timelock if `nVersion ≥ 2` (which is the default starting in Bitcoin Core 0.14.0). You should be careful to ensure that relative timelocks don't conflict with the other two uses of `nSequence`, for signalling `nLockTime` and RBF. `nLockTime` usually sets a value of 0xff ff ff ff-1, where a relative timelock is disallowed; and RBF usually sets a value of "1", where a relative timelock is irrelevent, because it defines a timelock of 1 block. -> In general, remember: with a `nVersion` value of 2, a `nSequence` value of 0x00000001 to 0x7fffffff allows relative timelock, RBF, and `nTimeLock`; a `nSequence` value of 0x7fffffff to 0xffffffff-2 allows RBF and `nTimeLock`; a `nSequence` value of 0xffffffff-1 allows only `nTimeLock`; a `nSequence` value of 0xffffffff allows none; and `nVersion` can be set to 1 to disallow relative timelocks for any value of `nSequence`. Whew! +> In general, remember: with a `nVersion` value of 2, a `nSequence` value of 0x00 00 00 01 to 0x7f ff ff ff allows relative timelock, RBF, and `nLockTime`; a `nSequence` value of 0x7f ff ff ff to 0xff ff ff ff-2 allows RBF and `nLockTime`; a `nSequence` value of 0xff ff ff ff-1 allows only `nLockTime`; a `nSequence` value of 0xff ff ff ff allows none; and `nVersion` can be set to 1 to disallow relative timelocks for any value of `nSequence`. Whew! ### Create a CSV Relative Block Time -The format for using `nSequence` to represent relative time locks is defined in [BIP 68](https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki) and is slightly more complex than just inputting a number, like you did for `nTimeLock`. Instead, the BIP specifications breaks up the four byte number into three parts: +The format for using `nSequence` to represent relative time locks is defined in [BIP 68](https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki) and is slightly more complex than just inputting a number, like you did for `nLockTime`. Instead, the BIP specifications breaks up the four byte number into three parts: * The first two bytes are used to specify a relative locktime. * The 23rd bit is used to positively signal if the lock refers to a time rather than a blockheight. * The 32nd bit is used to positively signal if relative timelocks are deactivated. -With that said, the construction of a block-based relative timelock is still quite easy, because the two flagged bits are set to `0`, so you just set `nSequence` to a value between 1 and 0xffff (65535). The new transaction can be mined that number of blocks after the associated UTXO was mined. +With that said, the construction of a block-based relative timelock is still quite easy, because the two flagged bits are set to `0`, so you just set `nSequence` to a value between 1 and 0xff ff (65535). The new transaction can be mined that number of blocks after the associated UTXO was mined. ### Create a CSV Relative Time @@ -65,7 +65,7 @@ Except pretty much no one does this. The [BIP 68](https://github.com/bitcoin/bip | | Absolute Timelock | Relative Timelock | |:--------------------:|-------------------|-------------------| -| **Lock Transaction** | nTimeLock | nSequence | +| **Lock Transaction** | nLockTime | nSequence | | **Lock Output** | OP_CHECKLOCKTIMEVERIFY| OP_CHECKSEQUENCEVERIFY | ## Understand the CSV Opcode @@ -93,7 +93,7 @@ CSV has many of the same subtleties in usage as CLTV: * The `nVersion` field must be set to 2 or more. * The `nSequence` field must be set to less than 0x80000000. -* When CSV is run, there must be an operand on the stack that's between 0 and 0xf0000000-1. +* When CSV is run, there must be an operand on the stack that's between 0 and 0xf0 00 00 00-1. * Both the stack operand and `nSequence` must have the same value on the 23rd bit. * The `nSequence` must be greater than or equal to the stack operand.