Why does "createrawtransaction $(decoderawtransaction $hexString)" not work?

[Automatic]

Inputting the output of "decoderawtransaction" into "createrawtransaction" results in an error, I want to make a small change to a transaction before I sign it manually (Add a "lock_time", I want to see how it works), but, I can't seem to be able to do it.

Here's my hex string:-

Code:

0100000001f699454faacb036aab2411e38ea00f5db9ffa7e831432c8945e8f0e21c7f26620000000000ffffffff0228397100000000001976a914b0c8172cbdc5ef9962574fbf945d7d39b4f2738788ac40420f00000000001976a914c37e2eb773d2314f92dc078f0c3a8277accc65f588ac00000000010000000137268479bae60a643efbc656957b3e18d328d373af03db164633a1c63eb3fa38010000008b483045022100da354c1d60683b69656bb9c8e5d1f0c39a1c2c7d06ee0058b8f1dd4f455e41a50220063268fbf586095994a0b5cb2c1369a4a2bd365b83dd262baf992d1f81cfeac901410431676a8a5bd9629598daf9bd8249d4d6ce8298dbf26bb5d9cd7e3092d3c12be051c8bce0a4ecf6ec219e6b99259c5256641a7c00d18e2c48e728f4fdc0705438ffffffff02687b8000000000001976a914e6e58a7f6393bd51adaf6865ada8ca151ecd30b588ac46fe620d000000001976a914079c4a24d14153c77aa71a3ca451afd60fcc119388ac00000000

decodes into:-

Code:


{
	"txid": "2150f5a18448b5cafe5f0a41d8c61606178d52fca52a8e53f486a288dd433caa",
	"version": 1,
	"locktime": 0,
	"vin": [{
		"txid": "62267f1ce2f0e845892c4331e8a7ffb95d0fa08ee31124ab6a03cbaa4f4599f6",
		"vout": 0,
		"scriptSig": {
			"asm": "",
			"hex": ""
		},
		"sequence": 4294967295
	}],
	"vout": [{
		"value": 0.07420200,
		"n": 0,
		"scriptPubKey": {
			"asm": "OP_DUP OP_HASH160 b0c8172cbdc5ef9962574fbf945d7d39b4f27387 OP_EQUALVERIFY OP_CHECKSIG",
			"hex": "76a914b0c8172cbdc5ef9962574fbf945d7d39b4f2738788ac",
			"reqSigs": 1,
			"type": "pubkeyhash",
			"addresses": [
				"1H7jdJ9bfkoj45pnwrXyJ7xxCeJx3Mmfx6"
			]
		}
	}, {
		"value": 0.01000000,
		"n": 1,
		"scriptPubKey": {
			"asm": "OP_DUP OP_HASH160 c37e2eb773d2314f92dc078f0c3a8277accc65f5 OP_EQUALVERIFY OP_CHECKSIG",
			"hex": "76a914c37e2eb773d2314f92dc078f0c3a8277accc65f588ac",
			"reqSigs": 1,
			"type": "pubkeyhash",
			"addresses": [
				"1JpfvikTE3jF3YG9XPswibceZMfGVi4nFa"
			]
		}
	}]
}

Piping that back in as:-

Code:


{
	"txid": "2150f5a18448b5cafe5f0a41d8c61606178d52fca52a8e53f486a288dd433caa",
	"version": 1,
	"locktime": 284300,
	"vin": [{
		"txid": "62267f1ce2f0e845892c4331e8a7ffb95d0fa08ee31124ab6a03cbaa4f4599f6",
		"vout": 0,
		"scriptSig": {
			"asm": "",
			"hex": ""
		},
		"sequence": 4294967295
	}],
	"vout": [{
		"value": 0.07420200,
		"n": 0,
		"scriptPubKey": {
			"asm": "OP_DUP OP_HASH160 b0c8172cbdc5ef9962574fbf945d7d39b4f27387 OP_EQUALVERIFY OP_CHECKSIG",
			"hex": "76a914b0c8172cbdc5ef9962574fbf945d7d39b4f2738788ac",
			"reqSigs": 1,
			"type": "pubkeyhash",
			"addresses": [
				"1H7jdJ9bfkoj45pnwrXyJ7xxCeJx3Mmfx6"
			]
		}
	}, {
		"value": 0.01000000,
		"n": 1,
		"scriptPubKey": {
			"asm": "OP_DUP OP_HASH160 c37e2eb773d2314f92dc078f0c3a8277accc65f5 OP_EQUALVERIFY OP_CHECKSIG",
			"hex": "76a914c37e2eb773d2314f92dc078f0c3a8277accc65f588ac",
			"reqSigs": 1,
			"type": "pubkeyhash",
			"addresses": [
				"1JpfvikTE3jF3YG9XPswibceZMfGVi4nFa"
			]
		}
	}]
}

Results in "Error: Error parsing JSON:{txid" or "Error: Error parsing JSON:{", depending on if I copy it formatted or all on one line. The format of createrawtransaction (createrawtransaction [{"txid":txid,"vout":n},...] {address:amount,...}) is obviously different to the output of decoderawtransaction, so, what's the best way of doing this?

[1713550328]

1713550328

[1713550328]

1713550328

[1713550328]

1713550328

[1713550328]

1713550328

[Ins]

I think there is problem in txid, txid is sha256 hash of all transaction.
You made changes in transaction, so there is new hash.
Also, there is other format of createrawtransaction
bitcoind createrawtransaction '[{"txid":"2150f5a18448b5cafe5f0a41d8c61606178d52fca52a8e53f486a288dd433caa","vout":0,"locktime":2}]' '{"1JpfvikTE3jF3YG9XPswibceZMfGVi4nFa":0.01}'
https://people.xiph.org/~greg/escrowexample.txt check this

[Automatic]

I think there is problem in txid, txid is sha256 hash of all transaction.
You made changes in transaction, so there is new hash.

Point I'm trying to make it less that, and more the fact that the input for 'createrawtransaction' is different than the output of 'decoderawtransaction', so, I'm confused on how to do this.

EDIT:- after learning that the encoded transaction is just a concatenated string of the data in the JSON fields (Source here) and not some super duper l33t h3k3r string that only the jedis of Bitcoin can decode, I realized I could just manually replace the 'locktime' field, and, that's what I did:-

Code:

0100000001f699454faacb036aab2411e38ea00f5db9ffa7e831432c8945e8f0e21c7f26620000000000ffffffff0228397100000000001976a914b0c8172cbdc5ef9962574fbf945d7d39b4f2738788ac40420f00000000001976a914c37e2eb773d2314f92dc078f0c3a8277accc65f588ac8c560400010000000137268479bae60a643efbc656957b3e18d328d373af03db164633a1c63eb3fa38010000008b483045022100da354c1d60683b69656bb9c8e5d1f0c39a1c2c7d06ee0058b8f1dd4f455e41a50220063268fbf586095994a0b5cb2c1369a4a2bd365b83dd262baf992d1f81cfeac901410431676a8a5bd9629598daf9bd8249d4d6ce8298dbf26bb5d9cd7e3092d3c12be051c8bce0a4ecf6ec219e6b99259c5256641a7c00d18e2c48e728f4fdc0705438ffffffff02687b8000000000001976a914e6e58a7f6393bd51adaf6865ada8ca151ecd30b588ac46fe620d000000001976a914079c4a24d14153c77aa71a3ca451afd60fcc119388ac00000000

is equal to:-

Code:

{
"txid" : "4aea2297b036092db495296ceeb5921b47b111b605942db360fc44fbd12e0193",
"version" : 1,
"locktime" : 284300,
"vin" : [
{
"txid" : "62267f1ce2f0e845892c4331e8a7ffb95d0fa08ee31124ab6a03cbaa4f4599f6",
"vout" : 0,
"scriptSig" : {
"asm" : "",
"hex" : ""
},
"sequence" : 4294967295
}
],
"vout" : [
{
"value" : 0.07420200,
"n" : 0,
"scriptPubKey" : {
"asm" : "OP_DUP OP_HASH160 b0c8172cbdc5ef9962574fbf945d7d39b4f27387 OP_EQUALVERIFY OP_CHECKSIG",
"hex" : "76a914b0c8172cbdc5ef9962574fbf945d7d39b4f2738788ac",
"reqSigs" : 1,
"type" : "pubkeyhash",
"addresses" : [
"1H7jdJ9bfkoj45pnwrXyJ7xxCeJx3Mmfx6"
]
}
},
{
"value" : 0.01000000,
"n" : 1,
"scriptPubKey" : {
"asm" : "OP_DUP OP_HASH160 c37e2eb773d2314f92dc078f0c3a8277accc65f5 OP_EQUALVERIFY OP_CHECKSIG",
"hex" : "76a914c37e2eb773d2314f92dc078f0c3a8277accc65f588ac",
"reqSigs" : 1,
"type" : "pubkeyhash",
"addresses" : [
"1JpfvikTE3jF3YG9XPswibceZMfGVi4nFa"
]
}
}
]
}

Time to sign this, and, broadcast it, and, see how it works!

EDIT:- Had to change input address due to the fact that my client (Armory) was complaining about the wait time, and, my laptop (offline wallet) is in the other room, so, signed with an online wallet:-
https://blockchain.info/tx/54fc5ba26ddee61c1338a7196b58a0c954039c3f08408a497ba4f79d80f61d98

Let's see if this takes till block ID 284300 to confirm.

EDIT2:- Nope, didn't work at all:-
https://blockchain.info/address/1JpfvikTE3jF3YG9XPswibceZMfGVi4nFa

Managed to receive, then spend my BTC before block 284300, I must be missunderstanding this.

Proof I didn't fuck up:-
https://blockexplorer.com/rawtx/54fc5ba26ddee61c1338a7196b58a0c954039c3f08408a497ba4f79d80f61d98

>"lock_time": 284300,

[harding]

Automatic:

I just saw your post. The reason your transaction went through immediately was that the sequence number of all inputs was set to the maximum value (4294967295), indicating the transaction was finalized and the locktime didn't apply.

Changing any sequence field to any number less than the maximum will prevent the transaction from being entered into a block until the locktime (or, in your case, lockblock number) passes.

I got tired of changing locktimes manually, so I wrote a quick shell script that changes the locktime to an arbitrary date and sets the sequence number to zero. The script then does some quick validation of the resulting transaction to help prevent me from doing anything simple.

I added some comments to the script to help explain what's going on, but let me know if you have any questions.  Note: I haven't tested it on multiple-input transactions.

Code:

#!/bin/bash -eu

BITCOIND="bitcoind"
#BITCOIND="bitcoind -testnet"

if [ $# -ne 1 ]
then
    echo "Command to change the locktime of a bitcoin transaction provided on standard input"
    echo "  Usage: ... | $0 '<date>'"
    echo "  Example: btc-spend-all | $0 'tomorrow'"
    exit 1
fi

## I usually use this script in a pipeline with btc-spend-all, i.e.:
##    btc-spend-all | btc-change-locktime tomorrow | bitcoind signrawtransaction $(cat)
## or
##    echo '01000000017f286f35362457e961925835bff28351e0b679c7810827396c76967712a6714d0000000000ffffffff0100e1f505000000001976a9144c56a8926eeb911b06575be05bad06e66463fb1e88ac00000000' | btc-change-locktime
## Load the raw transaction from standard in
RAW_TRANSACTION=$(cat)

## Get the desired locktime in human-readable format and convert it into
## epoch time in both decimal format and little-endian hexadecimal format
LOCKTIME_DECIMAL=$( date +%s -ud "$1" ) || { echo 'Invalid date' ; exit 1 ; }
LOCKTIME_HEX=$( echo $LOCKTIME_DECIMAL | awk '{ printf "%x", $1 }' | sed 's/^\(..\)\(..\)\(..\)\(..\)/\4\3\2\1/' )


#### SAMPLE TRANSACTION
# 01000000017f286f35362457e961925835bff28351e0b679c7810827396c76967712a6714d0000000000ffffffff0100e1f505000000001976a9144c56a8926eeb911b06575be05bad06e66463fb1e88ac00000000
#### Every two characters (char) in hex equals one byte
# 01000000 .............................Version (8 char)
# 01 ...................................Vin count (2 char)
# 7f286f35362457e961925835bff28351e0b679c7810827396c76967712a6714d ...Prevout hash (64 char)
# 00000000 .............................Prevout index (8 char)
# 00 ...................................Signature script length (2 char)
# ffffffff .............................**Sequence number** (8 char)
# ++++++++++++++++++++++++++++++++++++++[[[[ additional inputs can go here ]]]]
# 01 ...................................vout count (2 char)
# 00e1f50500000000 .....................satoshis to transfer to send in this output (16 char)
# 19 ...................................public key length (2 char)
# 76a9144c56a8926eeb911b06575be05bad06e66463fb1e88ac public key claim script (50 char)
# ++++++++++++++++++++++++++++++++++++++[[[[ additional outputs can go here ]]]]
# 00000000 .............................**locktime** (8 char)

## Modify the transaction
MODIFIED_TRANSACTION=$( 
    echo $RAW_TRANSACTION | sed '''
        ## createrawtransaction by default creates transactions with
        ## max-value sequence numbers, which prevents locktime from having
        ## any effect. We need to change one of these sequence numbers to a
        ## lower value. Since the first sequence number always appears in
        ## the same byte location within the encoded transaction (after 84
        ## hexits), we will reduce it down to zero.
        s/\(.\{84\}\)ffffffff/\100000000/;

        ## Now we need to set locktime to the earliest date when we want to
        ## be able to spend the bitcoins. Locktime is always the last 8
        ## hexits of the encode transaction, and by default it is set to zero.
        s/00000000$/'$LOCKTIME_HEX'/;
    '''
)

## Pre-build the decode command so we can reuse it several times
_dc_cmd="$BITCOIND decoderawtransaction"

## Now lets diff the original and modified transactions to test for changes.
## The diff should always produce 11 lines of output: a two-line header
## listing the file names, three one-line headers for each changed part,
## and three two-line diffs
_diff_line_count=$( eval diff -u0 <( $_dc_cmd $RAW_TRANSACTION ) <( $_dc_cmd $MODIFIED_TRANSACTION ) | wc -l )
if [ $_diff_line_count -ne 11 ]
then
    echo Unexpected output from the diff command.  Dying...
    exit 1
fi

## Now test that all of the expected changes were made
eval diff -u0 <( $_dc_cmd $RAW_TRANSACTION ) <( $_dc_cmd $MODIFIED_TRANSACTION ) \
        | egrep -v  '^(---|\+\+\+|@@) '  \
        | sed '''
            ## Whitelist all of the expected changes in the diff by
            ## deleting them so we can then test for unexpected changes
            #
            ## The new locktime should decode to the decimal locktime
            /^+.*"locktime".*'$LOCKTIME_DECIMAL'/d;
            ## The old locktime should have been zero
            /^-.*"locktime".* 0,/d;
            ## The new sequence should be zero
            /^+.*"sequence".* 0$/d;
            ## The old sequence should have been the maximum, 4294967295
            /^-.*"sequence".* 4294967295/d;
            ## The only thing left should be the automatically-computerd
            ## txid hashes
            /"txid" : /d

            ## If anything remains, somenthing went wrong
        ''' | grep . && { echo "Unexpected changes.  Dying..." ; exit 1 ; }

## If we get here, all of the tests have been passed, so give the user
## the modified transaction so they can sign it
echo $MODIFIED_TRANSACTION

[Automatic]

Automatic:

I just saw your post. The reason your transaction went through immediately was that the sequence number of all inputs was set to the maximum value (4294967295), indicating the transaction was finalized and the locktime didn't apply.

Changing any sequence field to any number less than the maximum will prevent the transaction from being entered into a block until the locktime (or, in your case, lockblock number) passes.

I got tired of changing locktimes manually, so I wrote a quick shell script that changes the locktime to an arbitrary date and sets the sequence number to zero. The script then does some quick validation of the resulting transaction to help prevent me from doing anything simple.

I added some comments to the script to help explain what's going on, but let me know if you have any questions.  Note: I haven't tested it on multiple-input transactions.

Code:

#!/bin/bash -eu

BITCOIND="bitcoind"
#BITCOIND="bitcoind -testnet"

if [ $# -ne 1 ]
then
    echo "Command to change the locktime of a bitcoin transaction provided on standard input"
    echo "  Usage: ... | $0 '<date>'"
    echo "  Example: btc-spend-all | $0 'tomorrow'"
    exit 1
fi

## I usually use this script in a pipeline with btc-spend-all, i.e.:
##    btc-spend-all | btc-change-locktime tomorrow | bitcoind signrawtransaction $(cat)
## or
##    echo '01000000017f286f35362457e961925835bff28351e0b679c7810827396c76967712a6714d0000000000ffffffff0100e1f505000000001976a9144c56a8926eeb911b06575be05bad06e66463fb1e88ac00000000' | btc-change-locktime
## Load the raw transaction from standard in
RAW_TRANSACTION=$(cat)

## Get the desired locktime in human-readable format and convert it into
## epoch time in both decimal format and little-endian hexadecimal format
LOCKTIME_DECIMAL=$( date +%s -ud "$1" ) || { echo 'Invalid date' ; exit 1 ; }
LOCKTIME_HEX=$( echo $LOCKTIME_DECIMAL | awk '{ printf "%x", $1 }' | sed 's/^\(..\)\(..\)\(..\)\(..\)/\4\3\2\1/' )


#### SAMPLE TRANSACTION
# 01000000017f286f35362457e961925835bff28351e0b679c7810827396c76967712a6714d0000000000ffffffff0100e1f505000000001976a9144c56a8926eeb911b06575be05bad06e66463fb1e88ac00000000
#### Every two characters (char) in hex equals one byte
# 01000000 .............................Version (8 char)
# 01 ...................................Vin count (2 char)
# 7f286f35362457e961925835bff28351e0b679c7810827396c76967712a6714d ...Prevout hash (64 char)
# 00000000 .............................Prevout index (8 char)
# 00 ...................................Signature script length (2 char)
# ffffffff .............................**Sequence number** (8 char)
# ++++++++++++++++++++++++++++++++++++++[[[[ additional inputs can go here ]]]]
# 01 ...................................vout count (2 char)
# 00e1f50500000000 .....................satoshis to transfer to send in this output (16 char)
# 19 ...................................public key length (2 char)
# 76a9144c56a8926eeb911b06575be05bad06e66463fb1e88ac public key claim script (50 char)
# ++++++++++++++++++++++++++++++++++++++[[[[ additional outputs can go here ]]]]
# 00000000 .............................**locktime** (8 char)

## Modify the transaction
MODIFIED_TRANSACTION=$( 
    echo $RAW_TRANSACTION | sed '''
        ## createrawtransaction by default creates transactions with
        ## max-value sequence numbers, which prevents locktime from having
        ## any effect. We need to change one of these sequence numbers to a
        ## lower value. Since the first sequence number always appears in
        ## the same byte location within the encoded transaction (after 84
        ## hexits), we will reduce it down to zero.
        s/\(.\{84\}\)ffffffff/\100000000/;

        ## Now we need to set locktime to the earliest date when we want to
        ## be able to spend the bitcoins. Locktime is always the last 8
        ## hexits of the encode transaction, and by default it is set to zero.
        s/00000000$/'$LOCKTIME_HEX'/;
    '''
)

## Pre-build the decode command so we can reuse it several times
_dc_cmd="$BITCOIND decoderawtransaction"

## Now lets diff the original and modified transactions to test for changes.
## The diff should always produce 11 lines of output: a two-line header
## listing the file names, three one-line headers for each changed part,
## and three two-line diffs
_diff_line_count=$( eval diff -u0 <( $_dc_cmd $RAW_TRANSACTION ) <( $_dc_cmd $MODIFIED_TRANSACTION ) | wc -l )
if [ $_diff_line_count -ne 11 ]
then
    echo Unexpected output from the diff command.  Dying...
    exit 1
fi

## Now test that all of the expected changes were made
eval diff -u0 <( $_dc_cmd $RAW_TRANSACTION ) <( $_dc_cmd $MODIFIED_TRANSACTION ) \
        | egrep -v  '^(---|\+\+\+|@@) '  \
        | sed '''
            ## Whitelist all of the expected changes in the diff by
            ## deleting them so we can then test for unexpected changes
            #
            ## The new locktime should decode to the decimal locktime
            /^+.*"locktime".*'$LOCKTIME_DECIMAL'/d;
            ## The old locktime should have been zero
            /^-.*"locktime".* 0,/d;
            ## The new sequence should be zero
            /^+.*"sequence".* 0$/d;
            ## The old sequence should have been the maximum, 4294967295
            /^-.*"sequence".* 4294967295/d;
            ## The only thing left should be the automatically-computerd
            ## txid hashes
            /"txid" : /d

            ## If anything remains, somenthing went wrong
        ''' | grep . && { echo "Unexpected changes.  Dying..." ; exit 1 ; }

## If we get here, all of the tests have been passed, so give the user
## the modified transaction so they can sign it
echo $MODIFIED_TRANSACTION

I never actually posted back, as, I thought it was dead, but, I realized this, when I tried to change the sequence number, bitcoind (and blockchain.info/pushtx) both gave me shit for "invalid sequence number", I'll try your bash script in a second, but, I thought I'd point that out.

Can you actually transmit a transaction with a sequence less than 0xFFFFFFFF, or, is it just theory?

EDIT:- Just used it, it spewed out (I signed it after):-

Code:

0100000001d616b7980a925ffe19ba70df38d48c3d15f6a4ea262fbea952e1b4bfd1914cf7000000006c4930460221009e57c7f746a03839ca7a74787106214179328960359be5d22e4f6e051ad05918022100f154e04e0e1aea41205e73b31ee42d24069119884abf56080336ada457dec42a012103487e2a93bb376f4f14a21b9caa0824f7e9a0258cade248cdf3369cbbb089b4220000000001905f0100000000001976a91416c5c7873f291e3420afb2a659cae594fcf7623c88ac80450553

Code:

{
   "lock_time":1392854400,
   "inputs":[
      {
         "prev_out":{
            "index":0,
            "hash":"f74c91d1bfb4e152a9be2f26eaa4f6153d8cd438df70ba19fe5f920a98b716d6"
         },
         "script":"4930460221009e57c7f746a03839ca7a74787106214179328960359be5d22e4f6e051ad05918022100f154e04e0e1aea41205e73b31ee42d24069119884abf56080336ada457dec42a012103487e2a93bb376f4f14a21b9caa0824f7e9a0258cade248cdf3369cbbb089b422"
      }
   ],
   "vout_sz":1,
   "hash":"324185cc3d5e63eb3276c7d41956d0651ad14674e0452a1f5c77a5110125082e",
   "vin_sz":1,
   "out":[
      {
         "address":"135QoB7inwoqLsyMdc81M5Rg8i6TkTNMYR",
         "script_string":"OP_DUP OP_HASH160 16c5c7873f291e3420afb2a659cae594fcf7623c OP_EQUALVERIFY OP_CHECKSIG",
         "value":90000,
         "script":"76a91416c5c7873f291e3420afb2a659cae594fcf7623c88ac"
      }
   ],
   "size":193,
   "version":1
}

Let's test it (In order:- Blockchain.info/pushtx, Debug window on Bitcoin-QT Win x64, Bitcoind on Arch Linux):-

[harding]

I assure you, you can set sequence to non-max. Here's a locked transaction I sent myself last week:

    https://blockexplorer.com/rawtx/5af2104b1d7f9524f9bb2d5b81e79e7d6e3b21cb5552e31a96a24a7adc3344c7

Note that since early 2013, the memory pool will not accept non-finalized transactions in order to prevent DOS attacks. This may be the source of your error. Try sending the transaction when the locktime/lockblock is in the past.

[Automatic]

I assure you, you can set sequence to non-max. Here's a locked transaction I sent myself last week:

    https://blockexplorer.com/rawtx/5af2104b1d7f9524f9bb2d5b81e79e7d6e3b21cb5552e31a96a24a7adc3344c7

Note that since early 2013, the memory pool will not accept non-finalized transactions in order to prevent DOS attacks. This may be the source of your error. Try sending the transaction when the locktime/lockblock is in the past.

If you can't actually broadcast the transaction, may I ask what the point is? Just to simply give it to the other party and be like "Yeah... can't currently send it yet, but, heyho, you'll be able to in X days/blocks"? Seems a lot less cool than actually broadcasting it.

EDIT:- And what's the point of sequence then? If you can't even broadcast it till it's valid anyway.

[harding]

Not being able to broadcast it before the effective date may be less cool, but it's not any less functional.  I use locktime to send money to myself in the future---sort of like buying myself a savings bond.

The sequence number lets you publish multiple versions of a transaction. The network is supposed to drop a pending transaction when another transaction appears spending the same input but with a higher sequence number.  Sequence number and locktime are both currently used for payment channels as implemented in bitcoinj.  See the following link for details:

    https://en.bitcoin.it/wiki/Contracts#Example_7:_Rapidly-adjusted_.28micro.29payments_to_a_pre-determined_party

I'm curious: what cool thing did you want to do with locktime that you can't do now?

[Automatic]

Not being able to broadcast it before the effective date may be less cool, but it's not any less functional.  I use locktime to send money to myself in the future---sort of like buying myself a savings bond.

The sequence number lets you publish multiple versions of a transaction. The network is supposed to drop a pending transaction when another transaction appears spending the same input but with a higher sequence number.  Sequence number and locktime are both currently used for payment channels as implemented in bitcoinj.  See the following link for details:

    https://en.bitcoin.it/wiki/Contracts#Example_7:_Rapidly-adjusted_.28micro.29payments_to_a_pre-determined_party

I'm curious: what cool thing did you want to do with locktime that you can't do now?

Nothing I can't do now, but, now it requires the other party to know what they're doing to be able to broadcast the transaction themselves, before, they'd be able to just look it up on blockchain.info, see "Oh, unless Automatic changes his mind, you'll get your money on Feb 20th", now, it's "oh, here's some really complicated string of numbers, now what I need you to do is save it, and, remember it, then, on the 20th, I need you to broadcast it.".

[harding]

Fair enough.  Although now if you get bored, you can be the person who codes up a simple web service that stores locktimed transactions and broadcasts them when appropriate.  :-)

[Automatic]

Fair enough.  Although now if you get bored, you can be the person who codes up a simple web service that stores locktimed transactions and broadcasts them when appropriate.  :-)

But then people have to trust me to broadcast 'em, isn't the whole point of bitcoin peer to peer implementations to not rely on any single person  

Anyway, it'd be very simple to do, I would do it, but, the issue is that I couldn't guarantee uptime of months on months (Which, I know some people would want, to say "I want this broadcasted in X months/years"), so, I'm not going to.

[flynn]

Anyway, it'd be very simple to do, I would do it, but, the issue is that I couldn't guarantee uptime of months on months (Which, I know some people would want, to say "I want this broadcasted in X months/years"), so, I'm not going to.

Actually, several services like this could should be set up, all of them broadcasting the same transactions (at about the same time, when they'll be accepted)  - If one of them fail, it doesn't matter because the others would do the job. What should be done is some kind of replication server to do that job... so all the servers stay synchronized and maybe more importantly nobody can't put a threat on a server's owner to make a transaction disappear as an exemple for financial reasons...

Ho damn, I just reinvented the peer-to-peer, ho well ...

[Automatic]

Anyway, it'd be very simple to do, I would do it, but, the issue is that I couldn't guarantee uptime of months on months (Which, I know some people would want, to say "I want this broadcasted in X months/years"), so, I'm not going to.

Actually, several services like this could should be set up, all of them broadcasting the same transactions (at about the same time, when they'll be accepted)  - If one of them fail, it doesn't matter because the others would do the job. What should be done is some kind of replication server to do that job... so all the servers stay synchronized and maybe more importantly nobody can't put a threat on a server's owner to make a transaction disappear as an exemple for financial reasons...

Ho damn, I just reinvented the peer-to-peer, ho well ...

Well, if bitcoins just accepted transactions that were in the future, there's your setup.

Unfortunately, people have to ruin the fun and use it for DoS attacks (I believe that's why it's disabled?).

[pvoltaire]

I was pretty disappointed to see that this doesn't work. I expected a transaction with a locktime in the future to be broadcast and confirmed, but that the outputs wouldn't be spendable until the locktime was reached (except the miner fee). This seems to have many advantages:

1. No need for a seperate service to store such transactions, they're in the blockchain
2. No risk of the sender double-spending his part of the transaction
3. Only one private key must be kept secret: the recipients
4. No danger that the transaction format may be changed in the future, making the transaction useless
5. Much simpler end-user experience - the coins appear in the wallet, but aren't spendable. No need to fiddle with transactions.

Can someone explain why it can't be implemented this way? Every node would have to start checking whether inputs come from transactions which haven't reached their locktime, but this seems fairly minor.

[fbueller]

Probably because some clients may not code it as such, and just allow people to spend it. Locktime is not designed for what you want to do.

[pvoltaire]

Probably because some clients may not code it as such, and just allow people to spend it. Locktime is not designed for what you want to do.

It wouldn't matter much if some clients didn't support it once the majority of nodes supported it. I assume most clients use listunspent, which arguably shouldn't return such locked outputs anyway.

My reading of the wiki is that this is indeed what locktime is for, but it's broken:
https://en.bitcoin.it/wiki/Contracts#A_warning_about_the_mempool_transaction_replacement_mechanism , and Flynn has pointed out how absurd the alternative is.

[harding]

I expected a transaction with a locktime in the future to be broadcast and confirmed, but that the outputs wouldn't be spendable until the locktime was reached (except the miner fee). This seems to have many advantages:

1. No need for a seperate service to store such transactions, they're in the blockchain
2. No risk of the sender double-spending his part of the transaction
3. Only one private key must be kept secret: the recipients
4. No danger that the transaction format may be changed in the future, making the transaction useless
5. Much simpler end-user experience - the coins appear in the wallet, but aren't spendable. No need to fiddle with transactions.

Can someone explain why it can't be implemented this way? Every node would have to start checking whether inputs come from transactions which haven't reached their locktime, but this seems fairly minor.

Locktime was initially designed to be used with transaction replacement---the replacing of one version of a transaction with another.  This is a feature used today in "contracts" such as a micropayment channel.

Obviously, if time locked transactions are added to the block chain, you can't do transaction replacement.

Now my question: why would you want to irrevocably pay someone but not let them spend the money until a later point?  I kind of like the current method where I can give someone a time locked transaction but rescind (double-spend) it prior to the locktime maturing.   With this method, you can accomplish everything on your list except for #4:

1. No need for a separate service: the time locked transaction can be stored in the same wallet as the receiver's private key.  If you lose your private key, then the transaction is worthless to you anyway.

2. No risk of the spender double-spending if you use a two-hop transaction where the first transaction goes to a 2-of-2 multisig output that has one key each from the spender and the receiver.

3. Only one private key needs to be kept secret if the spender deletes his private key.

4. (You do not get protection against the transaction format changing.)

5. Simple UIs have already been written for micropayment channels which use time locked transactions.  For example: http://www.youtube.com/watch?v=r0BXnWlnIi4

[pvoltaire]

It looks like Peter Todd understood why this is a good idea:

https://twitter.com/petertoddbtc/status/510360423770898432
https://github.com/viacoin/viacoin/issues/5