02 FF 00 is the shortest representation of 255 - so I'm guessing the error is somewhere else.
Yes - the issue has been tagged as a bug on Github. |
|
|
|
does that mean, that there is no speed increase for average internet users? dont think so.
Never said that - but according to your list of figures the world average is back between 2001 and 2003 in your first chart. See the problems that you get with charts? Perhaps you would care to post a chart with "world average times" from 1990 to 2010 for comparison? Again I'll say that unfortunately statistics and charts are most commonly used to spread nonsense rather than useful information. |
|
|
|
The following tx uses the "secret reveal" method which doesn't use the CLTV op so it can be issued as soon as the P2SH address is funded (hence locktime is zero). {
"txid" : "1dc407204055e72bdc2bc9579a8827b89a51e8a677c4d46b7ae1a32a4c2280d9",
"version" : 1,
"locktime" : 0,
"vin" : [
{
"txid" : "e8d0014d1bcefa75df448cd30e0225978bf4efec1c1f44b6763ce671aced6b49",
"vout" : 0,
"scriptSig" : {
"asm" : "3045022100f384542d66de1a19d5b1181b9894e14d44f34b83e9a190c0c43046486fbb2d9e02205bb2b9795e4f35c40aa38275a900c
a01ea5f7d7747fcdb657b0c656a130d20cb01 02681362f33ab4c48884c5f7f5aaf5011d53f0584cf0b257c6c3aff8b0b08241b3 31323334353637383930 76a820
c775e7b757ede630cd0aa1113bd102661ab38829ca52a6422ab782862f26864687637576a9145e6199a3c0ad658480247a0f30e314aee23db1eb88ac67017fb17576
a9145e6199a3c0ad658480247a0f30e314aee23db1eb88ac68",
"hex" : "483045022100f384542d66de1a19d5b1181b9894e14d44f34b83e9a190c0c43046486fbb2d9e02205bb2b9795e4f35c40aa38275a90
0ca01ea5f7d7747fcdb657b0c656a130d20cb012102681362f33ab4c48884c5f7f5aaf5011d53f0584cf0b257c6c3aff8b0b08241b30a313233343536373839304c5
e76a820c775e7b757ede630cd0aa1113bd102661ab38829ca52a6422ab782862f26864687637576a9145e6199a3c0ad658480247a0f30e314aee23db1eb88ac67017
fb17576a9145e6199a3c0ad658480247a0f30e314aee23db1eb88ac68"
},
"sequence" : 0
}
],
"vout" : [
{
"value" : 50.00000000,
"n" : 0,
"scriptPubKey" : {
"asm" : "OP_DUP OP_HASH160 5e6199a3c0ad658480247a0f30e314aee23db1eb OP_EQUALVERIFY OP_CHECKSIG",
"hex" : "76a9145e6199a3c0ad658480247a0f30e314aee23db1eb88ac",
"reqSigs" : 1,
"type" : "pubkeyhash",
"addresses" : [
"mp7zjTrEszZezRBM1cUmTvaK2zf3MuDAHt"
]
}
}
]
}
|
|
|
|
I extended the P2SH redeem command to allow for "extra data" to be pushed onto the scriptSig stack which means the "secret reveal" method can also now be used - modified script is as follows: ; Copyright (c) 2016 CIYAM Developers
;
; Distributed under the MIT/X11 software license, please refer to the file license.txt
; in the root project directory or http://www.opensource.org/licenses/mit-license.php.
;
; CIYAM Bitcoin test script for ACCT using either a CLTV or secret reveal redemption tx
; -------------------------------------------------------------------------------------
;
; NOTE: In order to utilise the following script you will first need to install Bitcoin
; into the directory where CIYAM has been compiled or else set the TBITCOIN environment
; variable accordingly (check the 'tbitcoin' script to work out how to do this and when
; doing this don't forget the '-regtest' option). Check that there is no 'regtest' data
; before starting 'bitcoind' and then running this script.
;
;SECRET_REDEEM=1
;
@ifndef $SECRET_REDEEM
#Redeeming using CLTV refund...
@else
#Redeeming using secret reveal...
@endif
~tbitcoin generate 101
;
; Define an address and matching WIF private key for testing
;
ADDR=mp7zjTrEszZezRBM1cUmTvaK2zf3MuDAHt
WKEY=cPR4DC5NXVkR37wEbCuUVuvuFxSozsMr8SHYteB2iqG8yV3uHdFR
;
; To simplify testing just uses the same address for redemption
;
crypto_addr_hash $ADDR
PKH1=$OUTPUT
PKH2=$OUTPUT
;
; Setup an ACCT P2SH script and then get its address and script hash
;
SCTH=c775e7b757ede630cd0aa1113bd102661ab38829ca52a6422ab782862f268646
~tbitcoin importprivkey $WKEY
TXID=@~tbitcoin sendtoaddress $ADDR 50
BLKN=7f
SCRIPT=76a820%SCTH%87637576a914%PKH1%88ac6701%BLKN%b17576a914%PKH2%88ac68
crypto_p2sh_addr TBTC $SCRIPT
P2SH_ADDR=$OUTPUT
crypto_addr_hash $P2SH_ADDR
P2SH_HASH=$OUTPUT
;
; Send funds to the P2SH address
;
~tbitcoin generate 3
TXID=@~tbitcoin sendtoaddress $P2SH_ADDR 50
OLD_TX=@~tbitcoin getrawtransaction $TXID
~tbitcoin decoderawtransaction $OLD_TX
;
; (check that the VOUT matches or change the next line)
; (also verify the P2SH scriptPubKey's script and hash)
;
VOUT=0
#$P2SH_HASH
~tbitcoin generate 3
~tbitcoin getblockcount
LOCK=127
@ifndef $SECRET_REDEEM
crypto_p2sh_redeem $TXID $VOUT $SCRIPT $ADDR 5000000000 $WKEY $LOCK
@else
crypto_p2sh_redeem $TXID $VOUT $SCRIPT $ADDR 5000000000 $WKEY -e=31323334353637383930
@endif
RAW_TX=$OUTPUT
~tbitcoin decoderawtransaction $RAW_TX
~tbitcoin signrawtransaction $RAW_TX
@ifndef $SECRET_REDEEM
;
; Note this attempt will fail due to being non-final (i.e. locktime)
;
~tbitcoin sendrawtransaction $RAW_TX
;
; Increase the block height and then redeem funds from the P2SH UTXO
;
~tbitcoin generate 20
@endif
~tbitcoin getblockcount
TXID=@~tbitcoin sendrawtransaction $RAW_TX
NEW_TX=@~tbitcoin getrawtransaction $TXID
~tbitcoin decoderawtransaction $NEW_TX
~tbitcoin generate 1
So the same script can redeem either way (set the SECRET_REDEEM environment variable for the "secret reveal" method). |
|
|
|
|
The problem with adding the zero byte is that there is another check when pushing bytes that you have pushed the "minimum number possible".
So it currently won't accept 0x02ff00 which is how it apparently should accept 255.
The problem won't affect mainnet as its block numbers will appear as non-negative numbers (and it probably also doesn't affect *nix timestamp values).
|
|
|
|
i dont treat it as panic.. but more so.. frustration that scaling for new 'potential' is stagnant
People are not "not using" Bitcoin for remittance due to scaling (the average person wouldn't even understand this topic). If you increased the block size by 10x I seriously doubt you'll see any further progress in the Bitcoin remittance area (as that is not what is stopping it). |
|
|
|
|
As Bitcoin is currently responsible for practically zero remittance txs then I guess it has quite a lot of time to scale up (so we don't have a "panic" situation in regards to the block size due to the remittance market).
If you think that I am wrong then please post proof of the huge amount of remittance that Bitcoin is currently doing.
|
|
|
|
I don't see a problem with the 10 minutes delay. My email software checks for new mail every 10 minutes, and that's fine. I guess it isn't an issue with remittance either. The problem really is in the number of transactions.
The delay is not an issue for remittance but it is an issue for "buying coffee". If you can't confirm a tx then you are giving someone a coffee in the hope that they haven't purposely paid zero (or a very low) tx fee that might result in the tx being dropped from the mempool before it ever got confirmed (allowing the person to then repeat this). The only way you can really prevent this problem is going to be allowing child tx's to pay for parent ones (which itself could cause problems). At this stage the Bitcoin network doesn't even recognise this (although some nodes do) so you enter into a very murky area when you get involved with 0 confirmations. |
|
|
|
Could you use OP_MAX after pushing zero to the stack, then use OP_NOP2? If OP_MAX returns the larger of the two top items then I assume it would return zero rather than a negative value.
That doesn't seem right to me - personally I think there is a bug with the way that OP_CHECKLOCKTIMEVERIFY is working. I have reported it on here: https://github.com/bitcoin/bitcoin/issues/7275 and it seems that the core devs agree that something is not right. Unfortunately the problem might be a generic one (that unsigned values cannot be used in Bitcoin scripts). |
|
|
|
0 MAX CHECKLOCKTIMEVERIFY
Yes - I read that in the code - but how exactly do you do that? |
|
|
|
Honestly I have no idea. All I could find is that the actual nLockTime in the transcation (not in an OP_CLTV script) is supposed to be unsiged. I don't know why it would be signed for OP_CLTV. Bring it up in an issue on github, you'll get more answers that way.
Yup - it seems the core devs don't bother with this forum now (can't blame them - it is mostly just ad sig nonsense posts anyway). https://github.com/bitcoin/bitcoin/issues/7275EDIT: It appears that I found a bug. |
|
|
|
Yup - I checked the source code and that is what is confusing me. If nLockTime is unsigned (which all the docco and source code I looked at shows that it is) then why on earth is OP_CHECKLOCKTIMEVERIFY expecting a signed value? |
|
|
|
Ok, so maybe 0 padding makes the script non-standard. The script verifies fine which is why you have no error, so I guess it just doesn't pass standardness checks, probably because of 0 padding.
So - back to square one - how to get OP_CHECKLOCKTIMEVERIFY to understand block 255? |
|
|
|
Have you tried padding it with 0's?
Not yet - but I thought that padding with zeros is going to fall foul of the rule that the pushed data must be minimal (as I read when looking into doing this P2SH stuff). EDIT: I tried changing 0x017f to 0x02ff00 but then when I try and redeem (after 255 blocks) I get the following error: error: {"code":-26,"message":"64: non-mandatory-script-verify-flag (No error)"}
Which is a strange looking error (but an error nonetheless). |
|
|
|
Some exciting news is that I have successfully tested an ACCT CLTV redeem using Bitcoin (regest)!!! The script to do this has been added to the CIYAM project so provided that you install Bitcoin you will be able to run this using the ciyam_client application. Usage is as follows (make sure you have bitcoind running before doing this): ./ciyam_client -echo -quiet -no_prompt < test_acct_cltv.cin
The script contents is as follows: ; Copyright (c) 2016 CIYAM Developers
;
; Distributed under the MIT/X11 software license, please refer to the file license.txt
; in the root project directory or http://www.opensource.org/licenses/mit-license.php.
;
;CIYAM Bitcoin regression test script for ACCT CLTV redemption
;-------------------------------------------------------------
;
;NOTE: In order to utilise the following script you will first
;need to install Bitcoin either into the directory where CIYAM
;has been compiled or if not then set the TBITCOIN environment
;variable accordingly (check the 'tbitcoin' script to work out
;how to do this and don't forget the '-regtest' option). First
;make sure that any existing 'regtest' data has been destroyed
;then start 'bitcoind'.
;
~tbitcoin generate 101
;
; Define an address and matching WIF private key for testing
;
ADDR=mp7zjTrEszZezRBM1cUmTvaK2zf3MuDAHt
WKEY=cPR4DC5NXVkR37wEbCuUVuvuFxSozsMr8SHYteB2iqG8yV3uHdFR
;
; To simplify testing just uses the same address for redemption
;
crypto_addr_hash $ADDR
PKH1=$OUTPUT
PKH2=$OUTPUT
;
; Setup an ACCT P2SH script and then get its address and script hash
;
SCTH=c775e7b757ede630cd0aa1113bd102661ab38829ca52a6422ab782862f268646
~tbitcoin importprivkey $WKEY
TXID=@~tbitcoin sendtoaddress $ADDR 50
BLKN=7f
SCRIPT=76a820%SCTH%87637576a914%PKH1%88ac6701%BLKN%b17576a914%PKH2%88ac68
crypto_p2sh_addr TBTC $SCRIPT
P2SH_ADDR=$OUTPUT
crypto_addr_hash $P2SH_ADDR
P2SH_HASH=$OUTPUT
;
; Send funds to the P2SH address
;
~tbitcoin generate 1
TXID=@~tbitcoin sendtoaddress $P2SH_ADDR 50
OLD_TX=@~tbitcoin getrawtransaction $TXID
~tbitcoin decoderawtransaction $OLD_TX
;
; (check that the VOUT matches or change the next line)
; (also verify the P2SH scriptPubKey's script and hash)
;
VOUT=0
#$P2SH_HASH
~tbitcoin getblockcount
LOCK=127
crypto_p2sh_redeem $TXID $VOUT $SCRIPT $ADDR 5000000000 $WKEY $LOCK
RAW_TX=$OUTPUT
~tbitcoin decoderawtransaction $RAW_TX
~tbitcoin signrawtransaction $RAW_TX
;
; Note this attempt will fail due to being non-final (i.e. locktime)
;
~tbitcoin sendrawtransaction $RAW_TX
;
; Increase the block height and then redeem funds from the P2SH UTXO
;
~tbitcoin generate 25
~tbitcoin getblockcount
TXID=@~tbitcoin sendrawtransaction $RAW_TX
NEW_TX=@~tbitcoin getrawtransaction $TXID
~tbitcoin decoderawtransaction $NEW_TX
~tbitcoin generate 1
In order to use it you will need to delete any existing 'regtest' stuff first. This is only the CLTV redeem (or "refund redeem") - so the next step will be the "reveal secret redeem". |
|
|
|
|
Neilson's law does not apply to "average internet users" only to "high end" ones (which is a small minority) so I think you need to be careful when trying to introduce that diagram without supplying this information (as otherwise it can be really quite misleading).
Personally I think such charts are of generally no benefit to anyone other than politicians (who use them to try and trick/confuse/enthuse people).
|
|
|
|
I've been testing a P2SH redeem script that looks like this: OP_DUP
OP_SHA256
<secret hash>
OP_EQUAL
OP_IF
OP_DROP
OP_DUP
OP_HASH160
<public key hash 1>
OP_EQUALVERIFY
OP_CHECKSIG
OP_ELSE
<CLTV value>
OP_NOP2
OP_DROP
OP_DUP
OP_HASH160
<public key hash 2>
OP_EQUALVERIFY
OP_CHECKSIG
OP_ENDIF
I got it to work using -regtest (after a lot of mucking around as it appears that "coinbase" txs can't send to P2SH addresses without screwing up the scriptPubKey script) by using a <CLTV value> of 0x7f (block 127) and the CLTV redeem is working perfectly (in that it won't redeem until you have generated 127 blocks). But if I change the <CLTV value> to 0xff (for block 255) suddenly the script interpreter is complaining about a "Negative locktime". So how exactly am I supposed to tell it block 255? (and according to the documentation locktime is an unsigned value so why is the OP_CHECKLOCKTIMEVERIFY reading a signed value?) |
|
|
|
Finally I got the regtest version to work!! {
"txid" : "5fcebe8baf36c6936485465dedbc22934e7b29164dc4379bcab5c66b53ba5571",
"version" : 1,
"locktime" : 353,
"vin" : [
{
"txid" : "1a0af915d3585fa627927b8d74ebc6b1c15ba01179d25b7ebc0a18bfdb003732",
"vout" : 0,
"scriptSig" : {
"asm" : "304402206a780b785554c3f486a64e734d8cc019baf5e3203a8225894aa207ce5ecedf4902206ac5ed47274f1bb3e8d03fc838ee01a
f158a30197500f7bb554645cbc7ae53e301",
"hex" : "47304402206a780b785554c3f486a64e734d8cc019baf5e3203a8225894aa207ce5ecedf4902206ac5ed47274f1bb3e8d03fc838ee0
1af158a30197500f7bb554645cbc7ae53e301"
},
"sequence" : 4294967294
},
{
"txid" : "d779110252411719dac10d06bba948287a254754d8fd970737350932021e8563",
"vout" : 0,
"scriptSig" : {
"asm" : "3045022100a8f068a234814ff39bed454ba0fcea57542410af4730bbe6ea71cef3fff1bc80022078406403872928398378d05192541
128e5cf069168d03cd03082aef06941014b01",
"hex" : "483045022100a8f068a234814ff39bed454ba0fcea57542410af4730bbe6ea71cef3fff1bc80022078406403872928398378d051925
41128e5cf069168d03cd03082aef06941014b01"
},
"sequence" : 4294967294
}
],
"vout" : [
{
"value" : 50.00000000,
"n" : 0,
"scriptPubKey" : {
"asm" : "OP_HASH160 fda3b60118555482c3463148bf18ff12e1f29c2c OP_EQUAL",
"hex" : "a914fda3b60118555482c3463148bf18ff12e1f29c2c87",
"reqSigs" : 1,
"type" : "scripthash",
"addresses" : [
"2NGNM4erqJ14dNdq5QhJorunWZqPY4danqv"
]
}
}
]
}
And this is the redeem tx (using CLTV): {
"txid" : "7fd77a5f62081e113147a31550b6262febd2e3273165c3fb6a59c814d0a97796",
"version" : 1,
"locktime" : 252,
"vin" : [
{
"txid" : "5fcebe8baf36c6936485465dedbc22934e7b29164dc4379bcab5c66b53ba5571",
"vout" : 0,
"scriptSig" : {
"asm" : "30440220429b09433f70c16b26021bd19f71a7d30087c3bbd7e1255cfda7c00fdc126bed02207219634bd0f66eee1b73e60552bbf17
7f278ba856b99100bdc610b5da720168501 02681362f33ab4c48884c5f7f5aaf5011d53f0584cf0b257c6c3aff8b0b08241b3 76a820c775e7b757ede630cd0aa11
13bd102661ab38829ca52a6422ab782862f26864687637576a9145e6199a3c0ad658480247a0f30e314aee23db1eb88ac67017fb17576a9145e6199a3c0ad6584802
47a0f30e314aee23db1eb88ac68",
"hex" : "4730440220429b09433f70c16b26021bd19f71a7d30087c3bbd7e1255cfda7c00fdc126bed02207219634bd0f66eee1b73e60552bbf
177f278ba856b99100bdc610b5da7201685012102681362f33ab4c48884c5f7f5aaf5011d53f0584cf0b257c6c3aff8b0b08241b34c5e76a820c775e7b757ede630c
d0aa1113bd102661ab38829ca52a6422ab782862f26864687637576a9145e6199a3c0ad658480247a0f30e314aee23db1eb88ac67017fb17576a9145e6199a3c0ad6
58480247a0f30e314aee23db1eb88ac68"
},
"sequence" : 0
}
],
"vout" : [
{
"value" : 50.00000000,
"n" : 0,
"scriptPubKey" : {
"asm" : "OP_DUP OP_HASH160 5e6199a3c0ad658480247a0f30e314aee23db1eb OP_EQUALVERIFY OP_CHECKSIG",
"hex" : "76a9145e6199a3c0ad658480247a0f30e314aee23db1eb88ac",
"reqSigs" : 1,
"type" : "pubkeyhash",
"addresses" : [
"mp7zjTrEszZezRBM1cUmTvaK2zf3MuDAHt"
]
}
}
]
}
The P2SH redeem script is as follows: OP_DUP
OP_SHA256
c775e7b757ede630cd0aa1113bd102661ab38829ca52a6422ab782862f268646
OP_EQUAL
OP_IF
OP_DROP
OP_DUP
OP_HASH160
5e6199a3c0ad658480247a0f30e314aee23db1eb
OP_EQUALVERIFY
OP_CHECKSIG
OP_ELSE
7f
OP_NOP2
OP_DROP
OP_DUP
OP_HASH160
5e6199a3c0ad658480247a0f30e314aee23db1eb
OP_EQUALVERIFY
OP_CHECKSIG
OP_ENDIF
The two address hashes were intentionally made the same to simplify testing - for practical usage they would be different (one for Alice and one for Bob). |
|
|
|
Strange as the tx 41e834bc7d8266e50d271af204ebfc0ea7db4a204607fbad5bee1bd96fc7c6bb can be found on other testnet3 block explorers. I am starting to agree that "testnet" is actually not at all useful for testing.  The trouble I'm having with "regtest" is the initial P2SH payment. I am sending to what I think should be a valid testnet/regtest P2SH address 2MyPZMFn1fbyo3udjFQwvutmMheV3t2S1GQ but the payment tx to it looks like this: {
"txid" : "f2c870cda40f8f2134fa6d52ab5629055949f0f7b4e554956934be813dec6807",
"version" : 1,
"locktime" : 0,
"vin" : [
{
"coinbase" : "01660101",
"sequence" : 4294967295
}
],
"vout" : [
{
"value" : 50.00000000,
"n" : 0,
"scriptPubKey" : {
"asm" : "02f0d1b577793c518bf5c3b94f6c0a14637b3d883da7e5f80c6511167e1825bdd1 OP_CHECKSIG",
"hex" : "2102f0d1b577793c518bf5c3b94f6c0a14637b3d883da7e5f80c6511167e1825bdd1ac",
"reqSigs" : 1,
"type" : "pubkey",
"addresses" : [
"mioQggSG7tw6M3ixQcvWYWXmcbDEMYBZz7"
]
}
}
]
}
So instead of this: OP_HASH160 <hash> OP_EQUAL it has done this: 02f0d1b577793c518bf5c3b94f6c0a14637b3d883da7e5f80c6511167e1825bdd1 OP_CHECKSIG WTF? |
|
|
|
Hmm... I don't think the problem is with the DER format as I just tried this: #include <string>
#include <vector>
#include <iomanip>
#include <iostream>
using namespace std;
bool static IsValidSignatureEncoding(const std::vector<unsigned char> &sig) {
// Format: 0x30 [total-length] 0x02 [R-length] [R] 0x02 [S-length] [S] [sighash]
// * total-length: 1-byte length descriptor of everything that follows,
// excluding the sighash byte.
// * R-length: 1-byte length descriptor of the R value that follows.
// * R: arbitrary-length big-endian encoded R value. It must use the shortest
// possible encoding for a positive integers (which means no null bytes at
// the start, except a single one when the next byte has its highest bit set).
// * S-length: 1-byte length descriptor of the S value that follows.
// * S: arbitrary-length big-endian encoded S value. The same rules apply.
// * sighash: 1-byte value indicating what data is hashed (not part of the DER
// signature)
cout << "at 0..." << endl;
cout << "sig.size() = " << sig.size() << endl;
// Minimum and maximum size constraints.
if (sig.size() < 9) return false;
if (sig.size() > 73) return false;
cout << "at 1..." << endl;
// A signature is of type 0x30 (compound).
if (sig[0] != 0x30) return false;
cout << "at 2..." << endl;
// Make sure the length covers the entire signature.
if (sig[1] != sig.size() - 3) return false;
cout << "at 3..." << endl;
// Extract the length of the R element.
unsigned int lenR = sig[3];
cout << "at 4..." << endl;
// Make sure the length of the S element is still inside the signature.
if (5 + lenR >= sig.size()) return false;
cout << "at 5..." << endl;
// Extract the length of the S element.
unsigned int lenS = sig[5 + lenR];
cout << "lenR = " << lenR << endl;
cout << "lenS = " << lenS << endl;
// Verify that the length of the signature matches the sum of the length
// of the elements.
if ((size_t)(lenR + lenS + 7) != sig.size()) return false;
cout << "at 6..." << endl;
// Check whether the R element is an integer.
if (sig[2] != 0x02) return false;
cout << "at 7..." << endl;
// Zero-length integers are not allowed for R.
if (lenR == 0) return false;
cout << "at 8..." << endl;
// Negative numbers are not allowed for R.
if (sig[4] & 0x80) return false;
cout << "at 9..." << endl;
// Null bytes at the start of R are not allowed, unless R would
// otherwise be interpreted as a negative number.
if (lenR > 1 && (sig[4] == 0x00) && !(sig[5] & 0x80)) return false;
cout << "at 10..." << endl;
// Check whether the S element is an integer.
if (sig[lenR + 4] != 0x02) return false;
cout << "at 11..." << endl;
// Zero-length integers are not allowed for S.
if (lenS == 0) return false;
cout << "at 12..." << endl;
// Negative numbers are not allowed for S.
if (sig[lenR + 6] & 0x80) return false;
cout << "at 13..." << endl;
// Null bytes at the start of S are not allowed, unless S would otherwise be
// interpreted as a negative number.
if (lenS > 1 && (sig[lenR + 6] == 0x00) && !(sig[lenR + 7] & 0x80)) return false;
cout << "at 14..." << endl;
return true;
}
int main( int argc, char* argv[ ] )
{
if( argc != 2 )
cout << "usage: x <DER sig>" << endl;
else
{
string sig( argv[ 1 ] );
vector< unsigned char > bytes;
for( size_t i = 0; i < sig.size( ); i += 2 )
{
unsigned char ch = '\0';
if( sig[ i ] == 'a' || sig[ i ] == 'A' )
ch = 0xa0;
else if( sig[ i ] == 'b' || sig[ i ] == 'B' )
ch = 0xb0;
else if( sig[ i ] == 'c' || sig[ i ] == 'C' )
ch = 0xc0;
else if( sig[ i ] == 'd' || sig[ i ] == 'D' )
ch = 0xd0;
else if( sig[ i ] == 'e' || sig[ i ] == 'E' )
ch = 0xe0;
else if( sig[ i ] == 'f' || sig[ i ] == 'F' )
ch = 0xf0;
else if( sig[ i ] >= '0' && sig[ i ] <= '9' )
ch = ( sig[ i ] - '0' ) << 4;
if( sig[ i + 1 ] == 'a' || sig[ i + 1 ] == 'A' )
ch |= 0x0a;
else if( sig[ i + 1 ] == 'b' || sig[ i + 1 ] == 'B' )
ch |= 0x0b;
else if( sig[ i + 1 ] == 'c' || sig[ i + 1 ] == 'C' )
ch |= 0x0c;
else if( sig[ i + 1 ] == 'd' || sig[ i + 1 ] == 'D' )
ch |= 0x0d;
else if( sig[ i + 1 ] == 'e' || sig[ i + 1 ] == 'E' )
ch |= 0x0e;
else if( sig[ i + 1 ] == 'f' || sig[ i + 1 ] == 'F' )
ch |= 0x0f;
else if( sig[ i + 1 ] >= '0' && sig[ i + 1 ] <= '9' )
ch |= ( sig[ i + 1 ] - '0' );
bytes.push_back( ch );
}
cout << IsValidSignatureEncoding( bytes ) << endl;
}
}
And then ran this: > x 3044022069c288dd4f1995d6f95c6338842dd55934b7ac78c3bae65950ec64e7477cd5c902203fb73d7c329ec4f3da2f403eddc635215673cb13487f0e7e803969488678565001
at 0...
sig.size() = 71
at 1...
at 2...
at 3...
at 4...
at 5...
lenR = 32
lenS = 32
at 6...
at 7...
at 8...
at 9...
at 10...
at 11...
at 12...
at 13...
at 14...
1
which tells me that there is nothing wrong with it. I'm guessing I have something else wrong with a script so that the item on the stack is not actually a signature. |
|
|
|
|
Show Posts
