|
I am guessing if I can work out the format that is suitable for signing (which will have that 00 and I think requires another 01000000 to be added at the end of the inputs from memory) then I can manually sign it and then try and send the tx.
Anyone can for sure tell me the hex input for signing?
|
|
|
|
Unfortunately no such luck: {
"hex" : "0100000001bbc6c76fd91bee5badfb0746204adba70efceb04f21a270de566827dbc34e84100000000842102d1570ab314b7b32ffe76f31232805a7
27d05119958d14b0b8aff9df5709676884c6076a820c775e7b757ede630cd0aa1113bd102661ab38829ca52a6422ab782862f26864687637576a91401d7295f243a3
a6d26516b54e4e6f51278d376b588ac6703ac9a09b17576a914b6a7c89a6774de8c88d0b7a4043a6645983a479588ac68000000000140420f00000000001976a9145
817f2d63208327c21da272a3bb037c3d9ec026988acac9a0900",
"complete" : false,
"errors" : [
{
"txid" : "41e834bc7d8266e50d271af204ebfc0ea7db4a204607fbad5bee1bd96fc7c6bb",
"vout" : 0,
"scriptSig" : "2102d1570ab314b7b32ffe76f31232805a727d05119958d14b0b8aff9df5709676884c6076a820c775e7b757ede630cd0aa1113bd
102661ab38829ca52a6422ab782862f26864687637576a91401d7295f243a3a6d26516b54e4e6f51278d376b588ac6703ac9a09b17576a914b6a7c89a6774de8c88d
0b7a4043a6645983a479588ac68",
"sequence" : 0,
"error" : "Operation not valid with the current stack size"
}
]
}
using the version with the extra 00 at the start of the inputs produces this: {
"hex" : "0100000001bbc6c76fd91bee5badfb0746204adba70efceb04f21a270de566827dbc34e8410000000085002102d1570ab314b7b32ffe76f31232805
a727d05119958d14b0b8aff9df5709676884c6076a820c775e7b757ede630cd0aa1113bd102661ab38829ca52a6422ab782862f26864687637576a91401d7295f243
a3a6d26516b54e4e6f51278d376b588ac6703ac9a09b17576a914b6a7c89a6774de8c88d0b7a4043a6645983a479588ac68000000000140420f00000000001976a91
45817f2d63208327c21da272a3bb037c3d9ec026988acac9a0900",
"complete" : false,
"errors" : [
{
"txid" : "41e834bc7d8266e50d271af204ebfc0ea7db4a204607fbad5bee1bd96fc7c6bb",
"vout" : 0,
"scriptSig" : "002102d1570ab314b7b32ffe76f31232805a727d05119958d14b0b8aff9df5709676884c6076a820c775e7b757ede630cd0aa1113
bd102661ab38829ca52a6422ab782862f26864687637576a91401d7295f243a3a6d26516b54e4e6f51278d376b588ac6703ac9a09b17576a914b6a7c89a6774de8c8
8d0b7a4043a6645983a479588ac68",
"sequence" : 0,
"error" : "Script evaluated without error but finished with a false/empty top stack element"
}
]
}
|
|
|
|
Shit - just realised I was running 0.11.1 not 0.11.2. After downloading and re-running I now get this: {
"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. |
|
|
|
Yes - I am trying to do the CLTV redeem (but without a sig it will never work of course). 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: 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: {
"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). |
|
|
|
|
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?
|
|
|
|
Hmm... I have nearly got there (perhaps): 0100000001bbc6c76fd91bee5badfb0746204adba70efceb04f21a270de566827dbc34e8410000000085002103d30f361b0d5dacba61a56db0903fe32244b5616f950cac1081694e81148dd7594c6076a820c775e7b757ede630cd0aa1113bd102661ab38829ca52a6422ab782862f26864687637576a91401d7295f243a3a6d26516b54e4e6f51278d376b588ac6703ac9a09b17576a914b6a7c89a6774de8c88d0b7a4043a6645983a479588ac68000000000140420f00000000001976a9148a7dd4d0e29f50f989dd2b97d463d706a7ef0c7b88ac00000000
When I decode this I am seeing the following (which I think looks fine): {
"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: {
"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"
}
]
}
|
|
|
|
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.  This is basically what I have created: 0100000001bbc6c76fd91bee5badfb0746204adba70efceb04f21a270de566827dbc34e84100000000cc47304402204caf58993eceb55c5df0db0c4d96571327a6678c0acd648c21133ca39034b7d70220093a8b935d651d59330b3e6b0e1ce52c3610bad9f6f1b9cd1ae48e7e6528838e012103d30f361b0d5dacba61a56db0903fe32244b5616f950cac1081694e81148dd7594c6076a820c775e7b757ede630cd0aa1113bd102661ab38829ca52a6422ab782862f26864687637576a91401d7295f243a3a6d26516b54e4e6f51278d376b588ac6703ac9a09b17576a914b6a7c89a6774de8c88d0b7a4043a6645983a479588ac68000000000140420f00000000001976a9148a7dd4d0e29f50f989dd2b97d463d706a7ef0c7b88ac00000000
which when decoded looks like this: {
"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? |
|
|
|
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: <cond1> OP_IF <cond2> OP_IF ... OP_ELSE ... OP_ENDIF OP_ELSE ... OP_ENDIF |
|
|
|
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. |
|
|
|
So far I have now come up with the following P2SH template: 76a820 <SCTH>87637576a914 <PKH1>88ac6703 <BLKN>b17576a914 <PKH2>88ac68 which can be better understood as this: OP_DUP
OP_SHA256
<SCTH>
OP_EQUAL
OP_IF
OP_DROP
OP_DUP
OP_HASH160
<PKH1>
OP_EQUALVERIFY
OP_CHECKSIG
OP_ELSE
<BLKN>
OP_NOP2
OP_DROP
OP_DUP
OP_HASH160
<PKH2>
OP_EQUALVERIFY
OP_CHECKSIG
OP_ENDIF
Noting that: <SCTH> is the SHA256 hash of the "secret" <PKH1> is the public key hash for the "reveal secret" redeem script <BLKN> is the block number for a CLTV refund to occur at and <PKH2> 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 <BLKN> to instead be a timestamp (something I'll be looking into a little later). |
|
|
|
Edit: I think I found your problem. It isn't the time specified in your transaction yet so you will need to wait until then to spend the funds. It is currently 12/30/2015 @ 3:56am (UTC) but it is locked until 12/30/2015 @ 5:00am (UTC)
i was about to say is it even time yet  I thought that the time was only within 2 hours of the actual time (although I guess that will depend upon the particular node's clock). |
|
|
|
After taking a closer look at the code I found this (scroll down to the bottom): 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). |
|
|
|
"Can't" and "never" are not exactly the right words when it gets to evolution.
I think you should watch the YouTube video about the "expert" and the seven perpendicular red lines (your idea makes about just as much sense as that does). It is a bit like trying to explain to people that private keys are *safe* when they are created randomly. They will always respond with "but there is a chance I might create the same key as someone else?". So yes - there is a chance you could do that and there is also a chance that there is a bird about 1km above your head right now that is going to drop a shit that will hit you (but I doubt you are going to now move because I have stated that are you?). |
|
|
|
|
Seriously I am surprised the OP doesn't have an ad sig to be posting such nonsense.
You can't compress random data. Does that make sense to you or not?
(next step is to get yourself an ad sig so you can make money with such posts)
|
|
|
|
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). |
|
|
|
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: // 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. |
|
|
|
The one thing that is bothering me (taken from the BIP) is the following: // 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.
I'm not certain how to interpret this but I am concerned if it means that CLTV could be ignored. Can anyone better explain this? |
|
|
|
I think we have basically nutted it out ( https://webbtc.com/script/7fec1a377344333496cca3d67b06d418f199702cf4a9f5fcb8fbb38c5de963ca:0) where the P2SH script is as follows: OP_DUP
OP_SHA256
c775e7b757ede630cd0aa1113bd102661ab38829ca52a6422ab782862f268646
OP_EQUAL
OP_IF
OP_DROP
OP_DUP
OP_HASH160
937fe2ee82229d282edec2606c70e755875334c0
OP_EQUALVERIFY
OP_CHECKSIG
OP_ELSE
c8f505
OP_NOP2
OP_DROP
OP_DUP
OP_HASH160
20fbf78ba8f2f36feaec0efc5b82d5e07fb261a9
OP_EQUALVERIFY
OP_CHECKSIG
OP_ENDIF
This tx has been issued on mainnet with the CLTV refund operating as expected: https://blockchain.info/tx/7fec1a377344333496cca3d67b06d418f199702cf4a9f5fcb8fbb38c5de963ca (thanks to @sonicskye for creating the txs). Note that c8f505 is the CLTV value that will be checked against nLockTime for the CLTV refund redeem and c775e7b757ede630cd0aa1113bd102661ab38829ca52a6422ab782862f268646 is the hash of the secret that would need to be pushed for the secret revealing refund. This version uses public key hashes rather than public keys so that you would only need to provide an "address" to the other user (which will be easier for end users to understand). So the tx can be redeemed immediately by pushing signature 1, public key 1, secret and P2SH script or either at or after the CLTV block by pushing signature 2, public key 2 and the P2SH script (the OP_DUP and OP_DROPs in the P2SH script take care of the stack imbalance when using the CLTV redeem method). Note that nLockTime with a value >= to the CLTV must be provided for the refund redeem to work. |
|
|
|
they just didnt calculate the amount to send back correctly
Oh - yes - hmm... that does make you wonder then (perhaps a typo?). |
|
|
|
|
Show Posts
