Is this BIP65 sample script standard? - page 2.

CIYAM

legendary

Activity: 1890

Merit: 1086

Ian Knowles - CIYAM Lead Developer

Shit - just realised I was running 0.11.1 not 0.11.2.

After downloading and re-running I now get this:

Code:

{
"hex" : "0100000001bbc6c76fd91bee5badfb0746204adba70efceb04f21a270de566827dbc34e84100000000842102d1570ab314b7b32ffe76f31232805a7
27d05119958d14b0b8aff9df5709676884c6076a820c775e7b757ede630cd0aa1113bd102661ab38829ca52a6422ab782862f26864687637576a91401d7295f243a3
a6d26516b54e4e6f51278d376b588ac6703ac9a09b17576a914b6a7c89a6774de8c88d0b7a4043a6645983a479588ac68000000000140420f00000000001976a9145
817f2d63208327c21da272a3bb037c3d9ec026988ac00000000",
"complete" : false,
"errors" : [
{
"txid" : "41e834bc7d8266e50d271af204ebfc0ea7db4a204607fbad5bee1bd96fc7c6bb",
"vout" : 0,
"scriptSig" : "2102d1570ab314b7b32ffe76f31232805a727d05119958d14b0b8aff9df5709676884c6076a820c775e7b757ede630cd0aa1113bd
102661ab38829ca52a6422ab782862f26864687637576a91401d7295f243a3a6d26516b54e4e6f51278d376b588ac6703ac9a09b17576a914b6a7c89a6774de8c88d
0b7a4043a6645983a479588ac68",
"sequence" : 0,
"error" : "Locktime requirement not satisfied"
}
]
}

I think if I fix up my nLockTime now then we might have a winner.

CIYAM

legendary

Activity: 1890

Merit: 1086

Ian Knowles - CIYAM Lead Developer

Yes - I am trying to do the CLTV redeem (but without a sig it will never work of course).

Quote from: sonicskye on December 31, 2015, 07:17:33 AM

I wonder why there is a zero there.

That is where the sig should end up (except that it won't sign the tx for me). My understanding is that you can leave a zero as a place-marker in the raw tx to later replace with the signature (assuming it would agree to sign the tx for me which it won't).

You can omit the zero with this version:

Code:

0100000001bbc6c76fd91bee5badfb0746204adba70efceb04f21a270de566827dbc34e84100000000842102d1570ab314b7b32ffe76f31232805a727d05119958d14b0b8aff9df5709676884c6076a820c775e7b757ede630cd0aa1113bd102661ab38829ca52a6422ab782862f26864687637576a91401d7295f243a3a6d26516b54e4e6f51278d376b588ac6703ac9a09b17576a914b6a7c89a6774de8c88d0b7a4043a6645983a479588ac68000000000140420f00000000001976a9145817f2d63208327c21da272a3bb037c3d9ec026988ac00000000

But without being able to sign the tx it doesn't really help me.

So using that version if I try signrawtransaction I get the following output:

Code:

{
   "hex" : "0100000001bbc6c76fd91bee5badfb0746204adba70efceb04f21a270de566827dbc34e84100000000842102d1570ab314b7b32ffe76f31232805a7
27d05119958d14b0b8aff9df5709676884c6076a820c775e7b757ede630cd0aa1113bd102661ab38829ca52a6422ab782862f26864687637576a91401d7295f243a3
a6d26516b54e4e6f51278d376b588ac6703ac9a09b17576a914b6a7c89a6774de8c88d0b7a4043a6645983a479588ac68000000000140420f00000000001976a9145
817f2d63208327c21da272a3bb037c3d9ec026988ac00000000",
   "complete" : false,
   "errors" : [
   {
   "txid" : "41e834bc7d8266e50d271af204ebfc0ea7db4a204607fbad5bee1bd96fc7c6bb",
   "vout" : 0,
   "scriptSig" : "2102d1570ab314b7b32ffe76f31232805a727d05119958d14b0b8aff9df5709676884c6076a820c775e7b757ede630cd0aa1113bd
102661ab38829ca52a6422ab782862f26864687637576a91401d7295f243a3a6d26516b54e4e6f51278d376b588ac6703ac9a09b17576a914b6a7c89a6774de8c88d
0b7a4043a6645983a479588ac68",
   "sequence" : 0,
   "error" : "NOPx reserved for soft-fork upgrades"
   }
   ]
}

I am going to try this with "-regtest" next (but that might have to wait until tomorrow).

sonicskye

jr. member

Activity: 41

Merit: 3

Quote from: CIYAM on December 31, 2015, 04:35:13 AM

Hmm... I have nearly got there (perhaps):

Code:

0100000001bbc6c76fd91bee5badfb0746204adba70efceb04f21a270de566827dbc34e8410000000085002103d30f361b0d5dacba61a56db0903fe32244b5616f950cac1081694e81148dd7594c6076a820c775e7b757ede630cd0aa1113bd102661ab38829ca52a6422ab782862f26864687637576a91401d7295f243a3a6d26516b54e4e6f51278d376b588ac6703ac9a09b17576a914b6a7c89a6774de8c88d0b7a4043a6645983a479588ac68000000000140420f00000000001976a9148a7dd4d0e29f50f989dd2b97d463d706a7ef0c7b88ac00000000

When I decode this I am seeing the following (which I think looks fine):

Code:

{
   "txid" : "b6ae7d90587b27adef7c36571cc1fdf4fbe04c77d2a3113a2239188285f581cf",
   "version" : 1,
   "locktime" : 0,
   "vin" : [
   {
   "txid" : "41e834bc7d8266e50d271af204ebfc0ea7db4a204607fbad5bee1bd96fc7c6bb",
   "vout" : 0,
   "scriptSig" : {
   "asm" : "0 03d30f361b0d5dacba61a56db0903fe32244b5616f950cac1081694e81148dd759 76a820c775e7b757ede630cd0aa1113bd10266
1ab38829ca52a6422ab782862f26864687637576a91401d7295f243a3a6d26516b54e4e6f51278d376b588ac6703ac9a09b17576a914b6a7c89a6774de8c88d0b7a4
043a6645983a479588ac68",
   "hex" : "002103d30f361b0d5dacba61a56db0903fe32244b5616f950cac1081694e81148dd7594c6076a820c775e7b757ede630cd0aa1113bd
102661ab38829ca52a6422ab782862f26864687637576a91401d7295f243a3a6d26516b54e4e6f51278d376b588ac6703ac9a09b17576a914b6a7c89a6774de8c88d
0b7a4043a6645983a479588ac68"
   },
   "sequence" : 0
   }
   ],
   "vout" : [
   {
   "value" : 0.01000000,
   "n" : 0,
   "scriptPubKey" : {
   "asm" : "OP_DUP OP_HASH160 8a7dd4d0e29f50f989dd2b97d463d706a7ef0c7b OP_EQUALVERIFY OP_CHECKSIG",
   "hex" : "76a9148a7dd4d0e29f50f989dd2b97d463d706a7ef0c7b88ac",
   "reqSigs" : 1,
   "type" : "pubkeyhash",
   "addresses" : [
   "mt9EHSSeERgWKNqYfdmkpa4Mjb4EXr4QY2"
   ]
   }
   }
   ]
}

But unfortunately if I try and sign it I get this output:

Code:

{
   "hex" : "0100000001bbc6c76fd91bee5badfb0746204adba70efceb04f21a270de566827dbc34e8410000000085002103d30f361b0d5dacba61a56db0903fe
32244b5616f950cac1081694e81148dd7594c6076a820c775e7b757ede630cd0aa1113bd102661ab38829ca52a6422ab782862f26864687637576a91401d7295f243
a3a6d26516b54e4e6f51278d376b588ac6703ac9a09b17576a914b6a7c89a6774de8c88d0b7a4043a6645983a479588ac68000000000140420f00000000001976a91
48a7dd4d0e29f50f989dd2b97d463d706a7ef0c7b88ac00000000",
   "complete" : false,
   "errors" : [
   {
   "txid" : "41e834bc7d8266e50d271af204ebfc0ea7db4a204607fbad5bee1bd96fc7c6bb",
   "vout" : 0,
   "scriptSig" : "002103d30f361b0d5dacba61a56db0903fe32244b5616f950cac1081694e81148dd7594c6076a820c775e7b757ede630cd0aa1113
bd102661ab38829ca52a6422ab782862f26864687637576a91401d7295f243a3a6d26516b54e4e6f51278d376b588ac6703ac9a09b17576a914b6a7c89a6774de8c8
8d0b7a4043a6645983a479588ac68",
   "sequence" : 0,
   "error" : "NOPx reserved for soft-fork upgrades"
   }
   ]
}

Are you trying to redeem the CLTV block? BX decodes the tx as follows.

Quote

transaction
{
   hash b6ae7d90587b27adef7c36571cc1fdf4fbe04c77d2a3113a2239188285f581cf
   inputs
   {
   input
   {
   previous_output
   {
   hash 41e834bc7d8266e50d271af204ebfc0ea7db4a204607fbad5bee1bd96fc7c6bb
   index 0
   }
   script "zero [ 03d30f361b0d5dacba61a56db0903fe32244b5616f950cac1081694e81148dd759 ] [ 76a820c775e7b757ede630cd0aa1113bd102661ab38829ca52a6422ab782862f26864687637576a 91401d7295f243a3a6d26516b54e4e6f51278d376b588ac6703ac9a09b17576a914b6a7c89a6774 de8c88d0b7a4043a6645983a479588ac68 ]"
   sequence 0
   }
   }
   lock_time 0
   outputs
   {
   output
   {
   address mt9EHSSeERgWKNqYfdmkpa4Mjb4EXr4QY2
   script "dup hash160 [ 8a7dd4d0e29f50f989dd2b97d463d706a7ef0c7b ] equalverify checksig"
   value 1000000
   }
   }
   version 1
}

I wonder why there is a zero there.

sonicskye

jr. member

Activity: 41

Merit: 3

Quote from: sniveling on December 31, 2015, 05:40:28 AM

This Bitcoin Script IDE might be useful, but there might be a bug in it.

http://www.cs.princeton.edu/~tongbinw/bitcoinIDE/build/editor.html

The following thread discusses signing transactions on the testnet, and using the IDE to track down problems, but one of the final comments says it was giving inconsistent results with known good values. However, the IDE might have been updated since then.

Last time I checked, it is still buggy. This one https://webbtc.com/script is one of the best so far, despite it does not work lately.

sonicskye

jr. member

Activity: 41

Merit: 3

Quote from: CIYAM on December 30, 2015, 08:19:15 PM

Quote from: sonicskye on December 30, 2015, 03:23:54 PM

I was trying to add another branch of OP_ELSE to mimic Gmaxwell's CoinSwap but I don't really know how to skip the previous OP_ELSE and run the next OP_ELSE. Do you know how to do it?

I think I remember reading that you can nest the OP_IFs - in which case you would do something like this:

OP_IF

OP_IF
...
OP_ELSE
...
OP_ENDIF
OP_ELSE
...
OP_ENDIF

Hi, many thanks for the clue. I managed to construct the following structure

Quote

OP_IF
OP_IF
OP_DUP OP_SHA256 OP_EQUAL
OP_DROP
OP_DUP OP_HASH160 OP_EQUALVERIFY OP_CHECKSIG
OP_ELSE
OP_NOP2 OP_DROP
OP_DUP OP_HASH160 OP_EQUALVERIFY OP_CHECKSIG
OP_ENDIF
OP_ELSE
2 2 OP_CHECKMULTISIG
OP_ENDIF

The structure probably is the first few steps of Gmaxwell's Coinswap. I am not sure whether this can be called as atomic. Basically the tx can be redemed by 3 different ways:
- secret value + sig2
- sig1 + pubkey1 after certain CLTV
- sig1 + sig2 (in 2-of-2 multisig)

sniveling

sr. member

Activity: 719

Merit: 250

This Bitcoin Script IDE might be useful, but there might be a bug in it.

http://www.cs.princeton.edu/~tongbinw/bitcoinIDE/build/editor.html

The following thread discusses signing transactions on the testnet, and using the IDE to track down problems, but one of the final comments says it was giving inconsistent results with known good values. However, the IDE might have been updated since then.

http://bitcoin.stackexchange.com/questions/36496/how-to-redeem-non-standard-script-tx-testnet-instance

CIYAM

legendary

Activity: 1890

Merit: 1086

Ian Knowles - CIYAM Lead Developer

Actually the error now makes me wonder if testnet3 even currently supports CLTV?

If not should I be using -regtest instead of -testnet and generate my own test blockchain?

CIYAM

legendary

Activity: 1890

Merit: 1086

Ian Knowles - CIYAM Lead Developer

Hmm... I have nearly got there (perhaps):

Code:

0100000001bbc6c76fd91bee5badfb0746204adba70efceb04f21a270de566827dbc34e8410000000085002103d30f361b0d5dacba61a56db0903fe32244b5616f950cac1081694e81148dd7594c6076a820c775e7b757ede630cd0aa1113bd102661ab38829ca52a6422ab782862f26864687637576a91401d7295f243a3a6d26516b54e4e6f51278d376b588ac6703ac9a09b17576a914b6a7c89a6774de8c88d0b7a4043a6645983a479588ac68000000000140420f00000000001976a9148a7dd4d0e29f50f989dd2b97d463d706a7ef0c7b88ac00000000

When I decode this I am seeing the following (which I think looks fine):

Code:

{
"txid" : "b6ae7d90587b27adef7c36571cc1fdf4fbe04c77d2a3113a2239188285f581cf",
"version" : 1,
"locktime" : 0,
"vin" : [
{
"txid" : "41e834bc7d8266e50d271af204ebfc0ea7db4a204607fbad5bee1bd96fc7c6bb",
"vout" : 0,
"scriptSig" : {
"asm" : "0 03d30f361b0d5dacba61a56db0903fe32244b5616f950cac1081694e81148dd759 76a820c775e7b757ede630cd0aa1113bd10266
1ab38829ca52a6422ab782862f26864687637576a91401d7295f243a3a6d26516b54e4e6f51278d376b588ac6703ac9a09b17576a914b6a7c89a6774de8c88d0b7a4
043a6645983a479588ac68",
"hex" : "002103d30f361b0d5dacba61a56db0903fe32244b5616f950cac1081694e81148dd7594c6076a820c775e7b757ede630cd0aa1113bd
102661ab38829ca52a6422ab782862f26864687637576a91401d7295f243a3a6d26516b54e4e6f51278d376b588ac6703ac9a09b17576a914b6a7c89a6774de8c88d
0b7a4043a6645983a479588ac68"
},
"sequence" : 0
}
],
"vout" : [
{
"value" : 0.01000000,
"n" : 0,
"scriptPubKey" : {
"asm" : "OP_DUP OP_HASH160 8a7dd4d0e29f50f989dd2b97d463d706a7ef0c7b OP_EQUALVERIFY OP_CHECKSIG",
"hex" : "76a9148a7dd4d0e29f50f989dd2b97d463d706a7ef0c7b88ac",
"reqSigs" : 1,
"type" : "pubkeyhash",
"addresses" : [
"mt9EHSSeERgWKNqYfdmkpa4Mjb4EXr4QY2"
]
}
}
]
}

But unfortunately if I try and sign it I get this output:

Code:

{
"hex" : "0100000001bbc6c76fd91bee5badfb0746204adba70efceb04f21a270de566827dbc34e8410000000085002103d30f361b0d5dacba61a56db0903fe
32244b5616f950cac1081694e81148dd7594c6076a820c775e7b757ede630cd0aa1113bd102661ab38829ca52a6422ab782862f26864687637576a91401d7295f243
a3a6d26516b54e4e6f51278d376b588ac6703ac9a09b17576a914b6a7c89a6774de8c88d0b7a4043a6645983a479588ac68000000000140420f00000000001976a91
48a7dd4d0e29f50f989dd2b97d463d706a7ef0c7b88ac00000000",
"complete" : false,
"errors" : [
{
"txid" : "41e834bc7d8266e50d271af204ebfc0ea7db4a204607fbad5bee1bd96fc7c6bb",
"vout" : 0,
"scriptSig" : "002103d30f361b0d5dacba61a56db0903fe32244b5616f950cac1081694e81148dd7594c6076a820c775e7b757ede630cd0aa1113
bd102661ab38829ca52a6422ab782862f26864687637576a91401d7295f243a3a6d26516b54e4e6f51278d376b588ac6703ac9a09b17576a914b6a7c89a6774de8c8
8d0b7a4043a6645983a479588ac68",
"sequence" : 0,
"error" : "NOPx reserved for soft-fork upgrades"
}
]
}

CIYAM

legendary

Activity: 1890

Merit: 1086

Ian Knowles - CIYAM Lead Developer

Am trying now to get this to work with testnet but I'm having troubles working out how to construct the raw tx in a way that will let bitcoin-cli sign it for me. Sad

This is basically what I have created:

Code:

0100000001bbc6c76fd91bee5badfb0746204adba70efceb04f21a270de566827dbc34e84100000000cc47304402204caf58993eceb55c5df0db0c4d96571327a6678c0acd648c21133ca39034b7d70220093a8b935d651d59330b3e6b0e1ce52c3610bad9f6f1b9cd1ae48e7e6528838e012103d30f361b0d5dacba61a56db0903fe32244b5616f950cac1081694e81148dd7594c6076a820c775e7b757ede630cd0aa1113bd102661ab38829ca52a6422ab782862f26864687637576a91401d7295f243a3a6d26516b54e4e6f51278d376b588ac6703ac9a09b17576a914b6a7c89a6774de8c88d0b7a4043a6645983a479588ac68000000000140420f00000000001976a9148a7dd4d0e29f50f989dd2b97d463d706a7ef0c7b88ac00000000

which when decoded looks like this:

Code:

{
   "txid" : "9ed60a3a4218fb5c8469e37ff9c726570527ab327f886e84fb8a3019c0a02919",
   "version" : 1,
   "locktime" : 0,
   "vin" : [
   {
   "txid" : "41e834bc7d8266e50d271af204ebfc0ea7db4a204607fbad5bee1bd96fc7c6bb",
   "vout" : 0,
   "scriptSig" : {
   "asm" : "304402204caf58993eceb55c5df0db0c4d96571327a6678c0acd648c21133ca39034b7d70220093a8b935d651d59330b3e6b0e1ce52
c3610bad9f6f1b9cd1ae48e7e6528838e01 03d30f361b0d5dacba61a56db0903fe32244b5616f950cac1081694e81148dd759 76a820c775e7b757ede630cd0aa11
13bd102661ab38829ca52a6422ab782862f26864687637576a91401d7295f243a3a6d26516b54e4e6f51278d376b588ac6703ac9a09b17576a914b6a7c89a6774de8
c88d0b7a4043a6645983a479588ac68",
   "hex" : "47304402204caf58993eceb55c5df0db0c4d96571327a6678c0acd648c21133ca39034b7d70220093a8b935d651d59330b3e6b0e1ce
52c3610bad9f6f1b9cd1ae48e7e6528838e012103d30f361b0d5dacba61a56db0903fe32244b5616f950cac1081694e81148dd7594c6076a820c775e7b757ede630c
d0aa1113bd102661ab38829ca52a6422ab782862f26864687637576a91401d7295f243a3a6d26516b54e4e6f51278d376b588ac6703ac9a09b17576a914b6a7c89a6
774de8c88d0b7a4043a6645983a479588ac68"
   },
   "sequence" : 0
   }
   ],
   "vout" : [
   {
   "value" : 0.01000000,
   "n" : 0,
   "scriptPubKey" : {
   "asm" : "OP_DUP OP_HASH160 8a7dd4d0e29f50f989dd2b97d463d706a7ef0c7b OP_EQUALVERIFY OP_CHECKSIG",
   "hex" : "76a9148a7dd4d0e29f50f989dd2b97d463d706a7ef0c7b88ac",
   "reqSigs" : 1,
   "type" : "pubkeyhash",
   "addresses" : [
   "mt9EHSSeERgWKNqYfdmkpa4Mjb4EXr4QY2"
   ]
   }
   }
   ]
}

Now the problem with the above is that I stuffed in a rubbish signature (first part of the scriptSig) in order to get the raw transaction to correctly decode (I tried numerous versions that were missing the signature but they all failed to decode). So the question is how do I remove the rubbish signature and end up with a raw transaction that "signrawtransaction" will work with?

CIYAM

legendary

Activity: 1890

Merit: 1086

Ian Knowles - CIYAM Lead Developer

Quote from: sonicskye on December 30, 2015, 03:23:54 PM

I was trying to add another branch of OP_ELSE to mimic Gmaxwell's CoinSwap but I don't really know how to skip the previous OP_ELSE and run the next OP_ELSE. Do you know how to do it?

I think I remember reading that you can nest the OP_IFs - in which case you would do something like this:

OP_IF

OP_IF
...
OP_ELSE
...
OP_ENDIF
OP_ELSE
...
OP_ENDIF

sonicskye

jr. member

Activity: 41

Merit: 3

Quote from: CIYAM on December 30, 2015, 11:27:43 AM

So far I have now come up with the following P2SH template:

76a82087637576a91488ac6703b17576a91488ac68

which can be better understood as this:

Code:

OP_DUP
OP_SHA256

OP_EQUAL
OP_IF
OP_DROP
OP_DUP
OP_HASH160

OP_EQUALVERIFY
OP_CHECKSIG
OP_ELSE

OP_NOP2
OP_DROP
OP_DUP
OP_HASH160

OP_EQUALVERIFY
OP_CHECKSIG
OP_ENDIF

Noting that:
is the SHA256 hash of the "secret"
is the public key hash for the "reveal secret" redeem script
is the block number for a CLTV refund to occur at and
is the public key hash for the "CLTV refund" redeem script

The lengths of things being pushed onto the stack has been hard-coded in this template which is fine for the hashes but would not be fine if you changed to instead be a timestamp (something I'll be looking into a little later).

I was trying to add another branch of OP_ELSE to mimic Gmaxwell's CoinSwap but I don't really know how to skip the previous OP_ELSE and run the next OP_ELSE. Do you know how to do it?

CIYAM

legendary

Activity: 1890

Merit: 1086

Ian Knowles - CIYAM Lead Developer

Quote from: achow101 on December 30, 2015, 11:30:02 AM

What software are yous using to make these transactions? Or are you writing the hex by hand?

@sonicskye was using BX (originally SX by Amir Taaki) but I am just doing the raw txs by hand (although I have developed my own tools which I will be using to make this simpler).

You can actually use bitcoin-cli to do quite a bit of this stuff also (apart from the above script template which is why I wanted to get that done first).

What is neat about this template is that it works with two addresses (well hashes but it is straight forward to convert an address to its hash rather than having to exchange public keys like you have to with multisig) with one being tied to revealing the secret and the other being tied to the CLTV refund.

achow101

staff

Activity: 3458

Merit: 6793

Just writing some code

What software are yous using to make these transactions? Or are you writing the hex by hand?

CIYAM

legendary

Activity: 1890

Merit: 1086

Ian Knowles - CIYAM Lead Developer

So far I have now come up with the following P2SH template:

76a82087637576a91488ac6703b17576a91488ac68

which can be better understood as this:

Code:

OP_DUP
OP_SHA256

OP_EQUAL
OP_IF
OP_DROP
OP_DUP
OP_HASH160

OP_EQUALVERIFY
OP_CHECKSIG
OP_ELSE

OP_NOP2
OP_DROP
OP_DUP
OP_HASH160

OP_EQUALVERIFY
OP_CHECKSIG
OP_ENDIF

Noting that:
is the SHA256 hash of the "secret"
is the public key hash for the "reveal secret" redeem script
is the block number for a CLTV refund to occur at and
is the public key hash for the "CLTV refund" redeem script

The lengths of things being pushed onto the stack has been hard-coded in this template which is fine for the hashes but would not be fine if you changed to instead be a timestamp (something I'll be looking into a little later).

CIYAM

legendary

Activity: 1890

Merit: 1086

Ian Knowles - CIYAM Lead Developer

After taking a closer look at the code I found this (scroll down to the bottom):

Code:

bool TransactionSignatureChecker::CheckLockTime(const CScriptNum& nLockTime) const
{
   // There are two kinds of nLockTime: lock-by-blockheight
   // and lock-by-blocktime, distinguished by whether
   // nLockTime < LOCKTIME_THRESHOLD.
   //
   // We want to compare apples to apples, so fail the script
   // unless the type of nLockTime being tested is the same as
   // the nLockTime in the transaction.
   if (!(
   (txTo->nLockTime < LOCKTIME_THRESHOLD && nLockTime < LOCKTIME_THRESHOLD) ||
   (txTo->nLockTime >= LOCKTIME_THRESHOLD && nLockTime >= LOCKTIME_THRESHOLD)
   ))
   return false;

   // Now that we know we're comparing apples-to-apples, the
   // comparison is a simple numeric one.
   if (nLockTime > (int64_t)txTo->nLockTime)
   return false;

   // Finally the nLockTime feature can be disabled and thus
   // CHECKLOCKTIMEVERIFY bypassed if every txin has been
   // finalized by setting nSequence to maxint. The
   // transaction would be allowed into the blockchain, making
   // the opcode ineffective.
   //
   // Testing if this vin is not final is sufficient to
   // prevent this condition. Alternatively we could test all
   // inputs, but testing just this input minimizes the data
   // required to prove correct CHECKLOCKTIMEVERIFY execution.
   if (txTo->vin[nIn].IsFinal())
   return false;

   return true;
}

So the check for IsFinal (which is what checks for 0xffffffff) is actually preventing OP_CHECKLOCKTIMEVERIFY from being disabled.

Will be doing some further testing to see what happens if a CLTV redeem that accidentally (or on purpose) does set the nSequence to 0xffffffff (the main concern being that if the tx remains in the mempool it could actually block the secret revealing tx as a double spend attempt).

sniveling

sr. member

Activity: 719

Merit: 250

On the 14th of December Peter Todd tweeted that BIP65 OP_CHECKLOCKTIMEVERIFY can be used in production.

https://twitter.com/petertoddbtc/status/676453190443773954

Quote

BIP65 OP_CHECKLOCKTIMEVERIFY can now be used in production on Bitcoin mainnet.

He made this reddit post which contains a demo script that might be useful to the top coders here. His script time locked any Bitcoins sent to 3F6ZKHjT4iGW5vimA54htkVErTpdxw6994 until Dec 21st.

https://www.reddit.com/r/Bitcoin/comments/3wt8fw/bip65_op_checklocktimeverify_can_now_be_used_in/cxyvpo6

Quote

[–]petertodd - Bitcoin Expert 3 points 15 days ago

Here's a quick-n-dirty script to play with if you want to try it out:

https://github.com/petertodd/checklocktimeverify-demos/blob/master/hodl.py

For example, here's me creating a P2SH-using address with a locktime set to about a week in the future:

Code:

./hodl.py -v 1450719427 create
DEBUG:root:redeemScript: 04c3387856b1752103f5f810828bcb3805ed0c28afebbaf064977195dc06aed0e2edd6d0c4378fcc01ac
3F6ZKHjT4iGW5vimA54htkVErTpdxw6994

Quote

The verbose (-v) flag enabled debugging output, which lets me see the actual redeemScript for that address. We can use Bitcoin Core's decodescript RPC command to decode it:

Code:

$ bitcoin-cli decodescript 04c3387856b1752103f5f810828bcb3805ed0c28afebbaf064977195dc06aed0e2edd6d0c4378fcc01ac
{
  "asm": "1450719427 OP_NOP2 OP_DROP 03f5f810828bcb3805ed0c28afebbaf064977195dc06aed0e2edd6d0c4378fcc01 OP_CHECKSIG",
  "type": "nonstandard",
  "p2sh": "3F6ZKHjT4iGW5vimA54htkVErTpdxw6994"
}

Quote

OP_NOP2 is the same as OP_CHECKLOCKTIMEVERIFY - to keep the CLTV pull-req as minimal and risk-free as possible I didn't change the name! An easy project for a dev new to Bitcoin Core would be to fix this.

If anyone sends any bitcoins to 3F6ZKHjT4iGW5vimA54htkVErTpdxw6994, I'll be able to spend them after about Dec 21st 18:00 UTC with:

Code:

./hodl.py -v 1450719427 spend txid:n [txid:n ...]

fbueller

sr. member

Activity: 412

Merit: 287

Quote from: sonicskye on December 27, 2015, 05:41:20 AM

Quote from: CIYAM on December 27, 2015, 04:45:59 AM

Again I'm pretty sure that the IF..ELSE shown in the BIP65 example is not the same as OP_IF and OP_ELSE.

The way it reads in the BIP is:

IF

ELSE

ENDIF

but in Bitcoin Script AFAICT you would need to actually do this:

OP_IF
(where this will be executed if was true)
OP_ELSE
(where these will be executed if was false)

OP_ENDIF

It is odd that you would be having troubles pushing the tx to testnet (as it is more relaxed about things like txs being standard).

I do have a testnet peer running so perhaps I could help with trying to push the raw transactions (and seeing if anything appears to be wrong with say the P2SH address or the like).

I think you are right about this. It really helps me to understand how the conditional script works.

Anyway, here is another tx to study https://webbtc.com/script/1dcdcaad7cb6550170662d7190d4a5cab6c5e3c61e1f289a91331dec4b811835:0
Instead of redeeming the "else" conditional, it entered the "if" block by exposing the secret value.

Notice that in the example it's specified as an output script, or p2sh script. The ScriptSig is where you push , triggering the different branches.

sniveling

sr. member

Activity: 719

Merit: 250

I don't know if the discussion in the following thread is relevant, or if the information in it is up to date, but it references part of the bitcoin.org developer guide comcerning locktime and sequence number.

http://bitcoin.stackexchange.com/questions/40706/why-is-op-checklocktimeverify-disabled-by-maximum-sequence-number

This is the part of the developer's guide it references. However, I have often read warnings to only rely on the source code and find the functions relevant to your problem, as knightdk was attempting to do. The developer's guide isn't as authoritative as the source code and can contain errors, or be out of date.

https://bitcoin.org/en/developer-guide#locktime-and-sequence-number

Quote

Locktime allows signers to create time-locked transactions which will only become valid in the future, giving the signers a chance to change their minds.

...

Previous versions of Bitcoin Core provided a feature which prevented transaction signers from using the method described above to cancel a time-locked transaction, but a necessary part of this feature was disabled to prevent denial of service attacks. A legacy of this system are four-byte sequence numbers in every input. Sequence numbers were meant to allow multiple signers to agree to update a transaction; when they finished updating the transaction, they could agree to set every input’s sequence number to the four-byte unsigned maximum (0xffffffff), allowing the transaction to be added to a block even if its time lock had not expired.

Even today, setting all sequence numbers to 0xffffffff (the default in Bitcoin Core) can still disable the time lock, so if you want to use locktime, at least one input must have a sequence number below the maximum Since sequence numbers are not used by the network for any other purpose, setting any sequence number to zero is sufficient to enable locktime.

CIYAM

legendary

Activity: 1890

Merit: 1086

Ian Knowles - CIYAM Lead Developer

Quote from: achow101 on December 29, 2015, 12:36:54 PM

Also, I don't think that code is in production since I didn't find it in the source, although I may have just skipped over it. Here is the code in the actual source code: https://github.com/bitcoin/bitcoin/blob/327291af02d05e09188713d882bf68ac708c1077/src/script/interpreter.cpp#L331

Aha - yes - so those final checks don't actually happen. I do know that we had created an ACCT tx but managed to "lock it up" by sending a refund tx that was basically invalid (but was not dropped so stayed in the mempools preventing the "secret reveal" tx from being able to be correctly sent).

That is my major concern (that the whole thing might actually be flawed).

If it is possible for the one party to just block the other party with an invalid tx then it basically means that CLTV is a fail for the ACCT use case (and presumably for any other use case also).

achow101

staff

Activity: 3458

Merit: 6793

Just writing some code

Quote from: CIYAM on December 29, 2015, 12:25:13 PM

Quote from: jl777 on December 29, 2015, 12:06:35 PM

however if at least one txin has a sequence that is not 0xffffffff then the CHECKLOCKTIMEVERIFY wont be bypassed. at worst, you would need to mix in some small satoshis worth of inputs

Not so sure about that as this:

Code:

// Testing if this vin is not final is sufficient to
// prevent this condition. Alternatively we could test all
// inputs, but testing just this input minimizes the data
// required to prove correct CHECKLOCKTIMEVERIFY execution.
if (txTo.vin[nIn].IsFinal())
return false;

Means that it only actually tests the one vin.

A proper OP_CLTV input needs to be nonfinal. It needs to have a sequence number that is not maxint. Since this code is part of the code that runs for each input (it loops and evaluates each input independently), it just needs to check that this one input with OP_CLTV is nonfinal in order for OP_CLTV to work. It doesn't need to check the sequence number of any of the other inputs if this one input is nonfinal. It would need to check those sequence numbers if this was final.

Also, I don't think that code is in production since I didn't find it in the source, although I may have just skipped over it. Here is the code in the actual source code: https://github.com/bitcoin/bitcoin/blob/327291af02d05e09188713d882bf68ac708c1077/src/script/interpreter.cpp#L331

Topic: Is this BIP65 sample script standard? - page 2. (Read 4759 times)