 Show Posts
|
|
Pages: [1] 2 3 4 5 6 7 »
|
Try and explain yourself clearly.
Did you mean segwit version 0 and segwit version 1? That is what I think of that is very similar to what you might be referring to version 1 and 2.
A years ago I have written blockchain analyzer for Bitcoin,Litecoin Dash and Bitcoin Cash. Now I download 150 GB Litecoin blocks (above 500 for Bitcoin is too much for me) and run analyzing. In block LTC 2398213 my program crash on last transaction. I don't know, transaction is bad, or I not handle this format. Transaction is version = 2, s segwit, Processing inputs and outputs but I get huge sizes of witness blocks. Transaction 9e919a5cc9a38f79d687cb84f0005a452589adbb33a5c092837137df19549dcb This is Litecoin topic, but I think, the same transaction extension have Bitcoin (?) |
|
|
|
|
What are difference between version 1 and version 2 of transaction?
|
|
|
|
|
1.
Undo data is used to rollback from fork? For example: was 500000 blocks, now incoming block 500001, but is fork and incoming new 500001 and 500002.
We use 500001-rev to undo transactions?
2.
I use Litecoin client for test because Bitcoin blocks have a lot gigabytes. I don't see *.rev files but probably undo info exists. Undo information is in *.dat?, also in new Bitcoin client?.
3.
What is format of undo data?
|
|
|
|
|
If I used Bitcoin client several years ago, in "blocks" directory were files *.dat and *.rev. These *.rev files contains information about undo. What is mean? Blockchain data is immutable.
Now I have Litecoin client and don't see *.rev files. I analyze LevelDB data for Litecoin testnet and here is info about undo size and undo position for block. Now undo information is in *.dat files?
|
|
|
|
|
I am looking for people for a project new crypto. This crypto should be fully decentralized with huge amounts of transactions per second. The project is in the planning phase. It needs a brainstorm. Please send me private message for more info.
|
|
|
|
|
In short:
Indeed is imposible get public key from signing, is possible check siging with known public key and it is enough.
|
|
|
|
|
Merkle tree has a big adavantage compared to simple hash list: if we have 1000 transactions and must test one transaction, we compute only 10 hashes, not 1000.
But is problem - I analysed Bitcoin block and there is no hashes stored, there are transactions with inputs and outputs, hashes of transactions are computed, I don't see hashes of highest level, only merkleRoot.
|
|
|
|
|
I'm not thinking stricte about cryptocurrency but something like a forum based on blockchain. For example forum bitcointalk required registration. I am thinking about decentralized forum.
My idea: an equal amount is lost per day on each address, man can earns when downloading blockchain, but above all, when sharing blockchain - earns by disk space. Problem: client program is turn off by months, and funds decreasing?
|
|
|
|
|
I do not necessarily insist on e-mail addresses but I would like a method assigning one crypto address to one user or to one PC. Maybe 2-3 crypto addresses per one PC but not 100-1000. Is known Proof of Space used by BurstCoin, but it only proves that the user has enough disk space and probably he can prove their 100 other private addresses with the same disk space.
|
|
|
|
|
I would like the user's address to be valuable to him and he not be able to generate easy e.g. 100 addresses.
|
|
|
|
|
Sometimes we wants not so much anonymity, but valuable participation in crypto community.
How to prove e-mail address?
Suppose, that I am registered user and Bob want to be register.
First stage is online off-blockchain:
Bob search registered users online, send (maybe by crypted channel) own e-mail address.
I know his e-mail address
I publish on lobckchain hash of my secret number
I sent him my secret number.
He public full secret number singed by him.
How to ensure, I not stole his e-mail address?
maybe..
he send to 2 or more random users his e-mail address and get 2-3 secrets?
Maybe are better, faster ways?
|
|
|
|
How Bob prove that his address is associated wih his private key? In https://en.bitcoin.it/wiki/Help:Introduction we read: Suppose Alice wants to send a bitcoin to Bob.
Bob sends his address to Alice.
Alice adds Bob’s address and the amount of bitcoins to transfer to a message: a 'transaction' message.
Alice signs the transaction with her private key, and announces her public key for signature verification.
Alice broadcasts the transaction on the Bitcoin network for all to see.
(Only the first two steps require human action. The rest is done by the Bitcoin client software.)
Looking at this transaction from the outside, anyone who knows that these addresses belong to Alice and Bob can see that Alice has agreed to transfer the amount to Bob, because nobody else has Alice's private key. Alice would be foolish to give her private key to other people, as this would allow them to sign transactions in her name, removing funds from her control.
Later on, when Bob wishes to transfer the same bitcoins to Charley, he will do the same thing:
Charlie sends Bob his address.
Bob adds Charlie's address and the amount of bitcoins to transfer to a message: a 'transaction' message.
Bob signs the transaction with his private key, and announces his public key for signature verification.
Bob broadcasts the transaction on the Bitcoin network for all to see.
Only Bob can do this because only he has the private key that can create a valid signature for the transaction. Bob can sign, Alica can sign, but how to associate Bob address (given by Alice) with his private key? Anyone can compute public key->address, but how from sign compute public key? |
|
|
|
|
Which hash is better CPU friendly? Argon2 or hash used by Litecoin?
|
|
|
|
|
Usually (but not all) inuts script have two tables, first: 70-72 bytes, second 33 or 65 bytes.
This second table is public key? Where this is in Bitcoin documentation?
|
|
|
|
In block 500186 BTC: in transaction (big endian) 83951f7cb7db18e22f30f319ecbfba2adfc0828a31a0df4edecb46a580c4df10 input script is: ScriptSig: PUSHDATA(72)[3045022100df7b1f04615972c7e9d05e9c6c176b95f1a9fc9b73e86eb6d6747336da118a4d02202021d00dab65b6000ef2fcae7525427d1dbec40a2def4196111b8b11c5247bfd01] PUSHDATA(33)[03eafee16adb27d36dc89e4aae0d1b5e0f8ddb2c9136612dc733ec65b1db128cca] and hash previous transaction is 132d98c0bf70264d224f8a2d19325a1f34edd5fddd387939c1f51dd9790aead5 and CPubKey key = (normal or reverse?, le or be)03eafee16adb27d36dc89e4aae0d1b5e0f8ddb2c9136612dc733ec65b1db128cca
hash = (from big endian) 132d98c0bf70264d224f8a2d19325a1f34edd5fddd387939c1f51dd9790aead5
signature = (from little endian)3045022100df7b1f04615972c7e9d05e9c6c176b95f1a9fc9b73e86eb6d6747336da118a4d02202021d00dab65b6000ef2fcae7525427d1dbec40a2def4196111b8b11c5247bfd01 now: key.Verify(hash, signature) - give me false! |
|
|
|
|
Main problem: there are two ways of signing: normal key1.Sign(hashMsg, sign1) and compat key1.SignCompact(hashMsg, csign1) and one recovering rkey1.RecoverCompact(hashMsg, csign1)
CKey::SignCompact uses secp256k1_ecdsa_sign_recoverable but CKey::Sign uses secp256k1_ecdsa_sign (not recoverable) and uses extra_entropy.
It is impossible recover public key from normal signed message?
Warning: inputs signatures are normal signed (70-72 bytes) not compact (65 bytes) followed by key. Is any way to verify?
|
|
|
|
What I am wrong using only Bitcoin code? I move source code from key_tests.cpp : ....................
CPubKey pubkey1 = key1. GetPubKey();
CPubKey pubkey2 = key2. GetPubKey();
CPubKey pubkey1C = key1C.GetPubKey();
CPubKey pubkey2C = key2C.GetPubKey();
BOOST_CHECK(key1.VerifyPubKey(pubkey1));
BOOST_CHECK(!key1.VerifyPubKey(pubkey1C));
BOOST_CHECK(!key1.VerifyPubKey(pubkey2));
BOOST_CHECK(!key1.VerifyPubKey(pubkey2C));
.................... and it is OK, but my code: vector<uint8_t> vch;
hashFromString("3f74be6a1fbd15a5e1101c48e7e31b7777c68fb125f143587d19e1e1c157575c", vch);
uint256 hashMsgMy(vch);
CPubKey rkeymy;
std::vector<unsigned char> csignmy;
hashFromStringLE("304502205d2cb95368167baa75ff86a36827a732ac1ab4ea5c9f53ebebf1c2ae738cc9db0221009cbec84f5941c7a85a76ef4c617b66a0c52e66e9ec5e8374480521d57a588eb701", csignmy);
BOOST_CHECK(rkeymy.RecoverCompact (hashMsgMy, csignmy));
string str = hashToStringLE(rkeymy.data(), 65);
cout << str <<endl;
should be key (33 bytes) 026795b2f312bf34204cd314d06b165ca8bb56702eb5ff27b57acfd7c8051e75d8 but is ff0000007d5671f4de5e3d054859e06f20919cc3d882220266c7a16014560000160000000000000 04d32a26014560000a0f9bcdbff7e0000000000000000000000 Maybe trash in - trash out, hash is bad or signature is bad, but why in result is so zeros, even if we get first 33 bytes from 65 bytes note: string str = HexStr(rkeymy.begin(), rkeymy.end()); give me empty string, because size is 0, all 65 bytes are trash because bool CPubKey::RecoverCompact(const uint256 &hash, const std::vector<unsigned char>& vchSig) {
if (vchSig.size() != COMPACT_SIGNATURE_SIZE)
return false;Must be 65 not 72 bytes, I again must take a look at changing 72 to 65 bytes --------------- NOW is without old problems r = 205d2cb95368167baa75ff86a36827a732ac1ab4ea5c9f53ebebf1c2ae738cc9 s = 009cbec84f5941c7a85a76ef4c617b66a0c52e66e9ec5e8374480521d57a588eb7 but key is 0229364d20762e423fb1d93d1fa05150a2d0277f49feaff924405785de9b6abb4d - look ok, but I want key 026795b2f312bf34204cd314d06b165ca8bb56702eb5ff27b57acfd7c8051e75d8 What I do wrong? I give one LTC transaction input. I give script (thus r and s) give key from script to verify message to recover script I give hash previous transaction, it is ok? another: hash Be 57ad3c7b7ce0654e43ecf7477879c167dcfb079614a1f785a5e87b84823f7d47 signature (71 bytes) 304402200f2f95941a847d5f43d241297e98de0da340cdb4232176be61babd7572b641b30220353 ed805ecda266dfc8ebf56c142239030d3e8be432d3590aeeacfdae15b8abc01 key (33 bytes) 025a76dd6561c1da7be001fa3b7aab0c56496be0230d06c5cd28bdec6ca6a71c85 - can't recover and other can't recover, only can (with other pubkey than derived fro script) hash Be 3f74be6a1fbd15a5e1101c48e7e31b7777c68fb125f143587d19e1e1c157575c signature (72 bytes) 304502205d2cb95368167baa75ff86a36827a732ac1ab4ea5c9f53ebebf1c2ae738cc9db0221009 cbec84f5941c7a85a76ef4c617b66a0c52e66e9ec5e8374480521d57a588eb701 WARNING: only first signature has 32+33 int numbers within, else have 32+32 or 33+33, it is possible? I call: myRecover("3f74be6a1fbd15a5e1101c48e7e31b7777c68fb125f143587d19e1e1c157575c",
"304502205d2cb95368167baa75ff86a36827a732ac1ab4ea5c9f53ebebf1c2ae738cc9db0221009cbec84f5941c7a85a76ef4c617b66a0c52e66e9ec5e8374480521d57a588eb701");
myRecover("57ad3c7b7ce0654e43ecf7477879c167dcfb079614a1f785a5e87b84823f7d47",
"304402200f2f95941a847d5f43d241297e98de0da340cdb4232176be61babd7572b641b30220353ed805ecda266dfc8ebf56c142239030d3e8be432d3590aeeacfdae15b8abc01");
myRecover("ae18beb79e3f3f61f080a6a6e4ad793f4557b1a4c0f2bd03bbe0f581916ff24a",
"3046022100f4d66692601dca84a67c4115affbce4824d02b602197c03f931ae8d5e41fa50c022100b7926308754801fcaacb0a961ebac249b4e4415185df022dae807b3385067d5401");
where void myRecover(string hashStr, string signatureStr) {
vector<unsigned char> script, signature;
hashFromStringLE(signatureStr.c_str(), signature);
vector<unsigned char> rnumber, snumber;
decodeSignature(signature, rnumber, snumber);
printf("%d %d\n", rnumber.size(), snumber.size());
decodeSignature(signature, rnumber, snumber);
string str = hashToStringLE(rnumber);
printf("r = %s\n", str.c_str());
str = hashToStringLE(snumber);
printf("s = %s\n", str.c_str());
vector<unsigned char> vchSig = rnumber;
vchSig.insert(vchSig.end(), snumber.begin(), snumber.end());
vector<uint8_t> vch;
hashFromString(hashStr.c_str(), vch);
uint256 hashMsgMy(vch);
CPubKey rkeymy;
printf("%d\n", rkeymy.RecoverCompact(hashMsgMy, vchSig));
str = HexStr(rkeymy.begin(), rkeymy.end());
cout << str << endl;
}
|
|
|
|
|
Two problems:
1. When I secp256k1_ecdsa_sig_parse with sample signature, len mismatch
2. Result are two 32 bytes numbers, whereas
COMPACT_SIGNATURE_SIZE = 65
(32+33, not 32 +32)
|
|
|
|
Now, let try it with example: (this exmaple is from LTC block 500186, but for Bitcoin this should be similar) hash (big endian) 3f74be6a1fbd15a5e1101c48e7e31b7777c68fb125f143587d19e1e1c157575c signature (72 bytes) 304502205d2cb95368167baa75ff86a36827a732ac1ab4ea5c9f53ebebf1c2ae738cc9db0221009 cbec84f5941c7a85a76ef4c617b66a0c52e66e9ec5e8374480521d57a588eb701 key (33 bytes) 026795b2f312bf34204cd314d06b165ca8bb56702eb5ff27b57acfd7c8051e75d8 From signature I tried two methods of extract r and s, first is mine procedure: void decodeSignature(vector<unsigned char> &signature, vector<unsigned char> &rnumber, vector<unsigned char> &snumber)
{
rnumber.clear();
snumber.clear();
uint8_t* bytesBegin = signature.data();
ptrdiff_t ptr = 0;
if (bytesBegin[ptr] != 0x30)
throw Exception("signature must have seq. tag = 0x30");
ptr++;
int seqLen = bytesBegin[ptr];
if (seqLen+3 != signature.size())
throw Exception("signature seq. len mismatch");
ptr++;
if (bytesBegin[ptr] != 0x02)
throw Exception("signature must have int tag = 0x02");
ptr++;
int intLen = bytesBegin[ptr];
rnumber.insert(rnumber.end(), signature.begin()+ptr, signature.begin()+ptr+intLen);
ptr+=intLen+1;
if (bytesBegin[ptr] != 0x02)
throw Exception("signature must have int tag = 0x02");
ptr++;
intLen = bytesBegin[ptr];
snumber.insert(snumber.end(), signature.begin()+ptr, signature.begin()+ptr+intLen);
} This procedure give me: r= 205d2cb95368167baa75ff86a36827a732ac1ab4ea5c9f53ebebf1c2ae738cc9 s=21009cbec84f5941c7a85a76ef4c617b66a0c52e66e9ec5e8374480521d57a588e is easy to verify that its are substring of signature hex string Second method: is using secp256k1_ecdsa_sig_parse uint8_t rr[32], rs[32];
secp256k1_ecdsa_sig_parse((secp256k1_scalar*)rr, (secp256k1_scalar*)rs, signature.data(), signature.size()-1);
Note: 1. I must write signature.size()-1 instead of signature.size() because else is called secp256k1_der_read_len and len mismatch with byte signature[1] meaing len = 69 But output are: r = dbc98c73aec2f1ebeb539f5ceab41aac32a72768a386ff75aa7b166853b92c5d s = b78e587ad521054874835eece9662ec5a0667b614cef765aa8c741594fc8be9c both len are 32 instead of 32 and 33, Next I concat s+r (mine, because second method give me 32 and 32 not 33) and call method: vchSig.insert(vchSig.end(), snumber.begin(), snumber.end());
recoverCompact(hash.data(), vchSig);
bool recoverCompact(const uint8_t hash[32], const std::vector<unsigned char>& vchSig) {
if (vchSig.size() != COMPACT_SIGNATURE_SIZE)
return false;
int recid = (vchSig[0] - 27) & 3;
bool fComp = ((vchSig[0] - 27) & 4) != 0;
secp256k1_pubkey pubkey;
secp256k1_ecdsa_recoverable_signature sig;
if (!secp256k1_ecdsa_recoverable_signature_parse_compact(secp256k1_context_verify, &sig, &vchSig[1], recid)) {
return false;
}
if (!secp256k1_ecdsa_recover(secp256k1_context_verify, &pubkey, &sig, hash)) {
return false;
}
unsigned char pub[PUBLIC_KEY_SIZE];
size_t publen = PUBLIC_KEY_SIZE;
secp256k1_ec_pubkey_serialize(secp256k1_context_verify, pub, &publen, &pubkey, fComp ? SECP256K1_EC_COMPRESSED : SECP256K1_EC_UNCOMPRESSED);
//Set(pub, pub + publen);
return true;
}
Is error in secp256k1_ecdsa_recover if (i < bits_ng && (n = wnaf_ng[i])) {
ECMULT_TABLE_GET_GE_STORAGE(&tmpa, *ctx->pre_g, n, WINDOW_G);
secp256k1_gej_add_zinv_var(r, r, &tmpa, &Z);
}
in ecmult-impl.h I must use not miny but r and s returned by second method? But the are both 32 bytes and is called signature.size()-1 |
|
|
|
I see Bitcoin method: bool CPubKey::RecoverCompact(const uint256 &hash, const std::vector<unsigned char>& vchSig) {
if (vchSig.size() != COMPACT_SIGNATURE_SIZE)
return false;
int recid = (vchSig[0] - 27) & 3;
bool fComp = ((vchSig[0] - 27) & 4) != 0;
secp256k1_pubkey pubkey;
secp256k1_ecdsa_recoverable_signature sig;
if (!secp256k1_ecdsa_recoverable_signature_parse_compact(secp256k1_context_verify, &sig, &vchSig[1], recid)) {
return false;
}
if (!secp256k1_ecdsa_recover(secp256k1_context_verify, &pubkey, &sig, hash.begin())) {
return false;
}
unsigned char pub[PUBLIC_KEY_SIZE];
size_t publen = PUBLIC_KEY_SIZE;
secp256k1_ec_pubkey_serialize(secp256k1_context_verify, pub, &publen, &pubkey, fComp ? SECP256K1_EC_COMPRESSED : SECP256K1_EC_UNCOMPRESSED);
Set(pub, pub + publen);
return true;
}
What is compact signature? It have 65 bytes instead of 73. This are r+s numbers alone? How I find if r have 32 or 33 bytes? |
|
|
|
|
