The real links are: https://github.com/spesmilo/electrum (the github repository hosting the code) https://electrum.org/ (website of the project) 6694D8DE7BE8EE5631BED9502BD5824B7F9470E6 (the real PGP public key of the developer) Anything else is fake. Don't just trust me, double and triple check these values yourself. I have also included the PGP public key because I have been seeing many scammers in the past signing the malicious Electrum releases with a PGP public key (obviously a different one that they own) and if you check the signature with their public key you will see a correct signature and it can create the illusion of being real! Additionally if you see the following error message, ignore it and change your server. It is the malicious server of the attacker and as you can see the link is also fake:  More information: https://github.com/spesmilo/electrum/issues/4953https://github.com/spesmilo/electrum/issues/4968 |
|
|
|
I need to implement a simple wallet using bitcore-lib by node.js.
Like manage private/public keys and addresses .
Have you checked the already existing open source projects on GitHub? https://github.com/search?l=JavaScript&q=bitcoin+wallet&type=RepositoriesSo why I cannot setup a node with library code inside my project? Does a node must be an external program?
A library is a set of functions that are put together by the programmer to serve a purpose. In order for a bitcoin library to have node functionalities it has to have implemented the P2P protocol and also have some wrappers allowing the caller to open up sockets for communication. I haven't had the chance to finish up this myself but it is not that complicated, I've already implemented the protocol part. |
|
|
|
Thanks a lot for the explanations. 27 = lower X even Y. 28 = lower X odd Y. 29 = higher X even Y. 30 = higher X odd Y.
That comment didn't make sense mainly because it says nothing about when s is being replaced by -s and I was initially trying to figure out how it is implemented in the code and without that little part the result will be false specially since most of the times s is replaced by -s. A random example from my unit tests that I kept checking against: key=0x4c4a90ace8ef549428b7ad24c8ca8940f130e4a32653bd3e88159ebb8ea0b775
message(utf8)=RDCaaa12234
R.x=111298013310039999727697889470430012371955796234135497681489525089601162729219
R.y=85994739553350295227584036738266368184641250776239259839118099187520698057269
s=63478024937324404321232340287682534731003226978885669652358186946685961083092
lower x + odd y = 28 BUT high s so it should be 27! and it is. public Signature Sign(byte[] data, byte[] key)
{
BigInteger e = CalculateE(data);
// do something about this loop, it is currently pointless
// possibly change kGenerator so that it can generate the next k value
for (int i = 0; i < 100; i++)
{
Rfc6979 kgen = new Rfc6979(curve.N, hashSize);
BigInteger k = kgen.GetK(data, key.ToBigInt(true, true));
EllipticCurvePoint rp = ScalarMult(k, curve.G);
byte v = (byte)(((rp.X > curve.N) ? 2 : 0) | (rp.Y.IsEven ? 0 : 1));
BigInteger r = rp.X % curve.N;
if (r == 0)
{
continue;
}
BigInteger s = InverseMod(k, curve.N) * (e + (r * key.ToBigInt(true, true))) % curve.N;
if (s == 0 || s > curve.N)
{
continue;
}
if (s > curve.N / 2)
{
v ^= 1;
s = curve.N - s;
}
//the following conditions based on that comment alone do not work
//if (rp.X < curve.N && rp.Y.IsEven)
//{
// v = 0;
//}
//else if (rp.X < curve.N && !rp.Y.IsEven)
//{
// v = 1;
//}
//else if (rp.X > curve.N && rp.Y.IsEven)
//{
// v = 2;
//}
//else if (rp.X > curve.N && !rp.Y.IsEven)
//{
// v = 3;
//}
return new Signature(r, s, v);
}
throw new Exception("Failed");
}
|
|
|
|
OK, this is what I have understood so far. There are two methods to get the "recovery ID". I am 99% sure about the first method and have tested it but I am not sure at all about the second so someone please shed some light on it: Method 1 (Finding recId after signing or from r and s integers):This is basically working backwards and is the steps defined in section 4.1.6 of Standards for Efficient Cryptography: 1. The recId is the index of the valid public key among all possible public keys that these steps recover if followed exactly as the documentation. Method 2 (Finding recId during signing or from R which is the point, and s which is the integer):I still don't understand what the mathematical logic behind this is yet. During signing when R is produced (multiplication result of k * G), we use R.y and the value of s to get the recId. Here is the c# code: int recid = ((R.X > curve.N) ? 2 : 0) | (R.Y.IsEven ? 0 : 1);
recid = (s > curve.N / 2) ? recid ^1 : recid;
* This is a more complete version of the link posted above by @darosior since it is considering the rare case of R.X being bigger than curve order. * This seems to be working but I am not sure. * I believe this is the function in bitcoin core that is responsible for signing messages (recoverable sigs) but I am not sure if I understood it correctly specially the overflow part! * Additionally there is this comment by Pieter Wuille which doesn't make any sense 27 = lower X even Y. 28 = lower X odd Y. 29 = higher X even Y. 30 = higher X odd Y.
|
|
|
|
|
That doesn't quite answer my question though. I understand that it is a "recovery ID" but I am trying to figure out how that number is obtained.
For example to sign "123" with the key to this address "muRAUfvSXQKXJm9sPsAbPsxDTMsMJoDQes"
I add 0 * n to r (first iteration of first loop)
Calculate Q with R, (first iteration of second loop) it is invalid
continue
Calculate Q with -R, (second iteration of second loop) it is valid
break.
The byte should be 32 meaning only 1 is added (27 + 4 + 1). Trying to figure out why 1 was chosen based on above operation?
|
|
|
|
|
I can't find any documentation on how to sign a message, I get that there is no standard but there should be some wiki page at least on bitcoinwiki explaining it IMO.
The problem is that I don't get how we produce the first byte. I can get this far:
1- Produce r and s
2- Attempt recovering public key from it
3- Do something here
4- Add 27 + (isCompressed ? 4 : 0) + (a number from step 3)!
Now in that "step 3 (and 2)" I am following the steps in section 4.1.6 of Standards for Efficient Cryptography: 1
From j = 0 to h (which is 1 for sec256k1)
* Calculate x and R assuming y is even
From k = 1 to k = 2
* Calculate Q from R if not valid then Q from -R which basically makes y odd
My guess is that the number in step 3 is (j + k-1) for some reason! I guess the libraries don't loop like this, they are looping from 0 to 3 (4 times) and then report that number, am I right?
Also was 27 chosen for "aesthetic" reasons, or is there more to it than meets the eye?
|
|
|
|
Don't forget to check out BIP14 for userAgents. By the way, how is your "code conversion" going? |
|
|
|
When signing a transaction you need to have a valid previous output. So when you pass tx hex into your bitcoin-cli signrawtransaction function you need to get scriptPubKey from previous tx aka the transaction you are spending which in this case is df360<...>19b0 which you say is fake. So you can't really spend it! I think this should be the right one (I am really not familiar with P2SH yet): a914dfef1d923975d18237d655068041f666ad2bd3e687
|
|
|
|
|
Elliptic Curve Cryptography is just math, and in the mathematical operations you are basically working with numbers. So when you want to sign something you convert that into a number and then perform your calculations using that number.
Signing needs to happen on anything. It can be 1 byte or it can be 1000 bytes. You can't calculate if everything else is 32 byte while you message size varies. So what you do is that you find a way to "shrink" the size of that message you want to sign to an always-the-same size. That is where Hash function comes in.
The hash function which is chosen needs to be secure so that there is no collision risk and since security level of secp256k1 curve is 128 bit we need to choose a hash function that has at least 128 bit security level. SHA256 has 258/2 bit or 128 bit security level. So it is used for bitcoin.
Now this "message" can be anything. In bitcoin when someone creates a transaction and signs it, there is a standard about what that "message" should be so everyone can easily calculate it too. In short it is serialization of the transaction with its script signature replaced by previous output's scriptpub and then hashed twice using SHA256.
So in other words to answer your second question above, the hash doesn't need to be included anywhere, it is easily calculated.
|
|
|
|
I can not understand why RFC6979 is used for generating k while creating a signature. 4.1.3 Signing Operation
1. Select an ephemeral elliptic curve key pair (k,R) with R = (xR, yR) associated with the elliptic curve domain parameters T established during the setup procedure using the key pair generation primitive specified in Section 3.2.1
So basically k is the same as a private key. So why not use the same process for creating a truly random private key here also? Why make it "deterministic " and most importantly what are the pros and cons of doing this? Also which implementations are doing this? I can already confirm that Electrum is using RFC6979 ref since it is easier to go through python for me and also I didn't have time to check all of them yet... |
|
|
|
Allow this output to be spent to anyone,
if:
spent amount (including mining fees and change) = output balance
amount(s) and destination address(es) is/are signed by my private key
The problem is that we don't have any operations for these, so they have to be implemented. Imagine a calculator that has +, -, * operations but doesn't have log, so you have to define log operation first before you can use it. For example you should propose a fork that adds a new OP code with NOP4 and NOP5. OP_CheckAmountEqualVerify can for example check the amount field in the spending tx and run OP_Equal and OP_Verify. OP_CheckTxInEqualVerify can check the Tx_In run OP_Equal and OP_Verify. But you can't just waste 2 OP code for something like this! Let's not overlook the fact that you are technically creating an Anyone-Can-Spend Output here with a different kind of conditions. So unless you add additional restrictions/conditions, these outputs will be spent by anyone. |
|
|
|
|
Both versions 1 and 2 would be valid in your case. And whenever you are in doubt, just use the highest version which is currently 2!
|
|
|
|
The easiest would probably be to simply use a hash function (e.g. sha256).
Hash your 'brain seed', and use this hash as the private key.
Note that hashing something doesn't make it random. For example if you compute SHA256 hash of a weak password such as "123" you will get a665a45920422f9d417e4867efdc4fb8a04a1f3fff1fa07e998e86f7f7a27ae3 which looks random but really isn't! Because it can simply be produced as long as the method for its creation is known. |
|
|
|
Why create/sign a transaction? Why not create an output that needs to satisfy a condition? I think what can work for "coupons" is some non-standard output script which doesn't require a private key to spend. For instance it can be a script like this (note that I am new to scripts): <OP_OP_HASH256><push 32 byte data><OP_EQUALVERIFY>
The 32 byte data can be double SHA256 of some password that you give away on a website. Like this: super secret bitcoin giveaway #652
ScriptPub: aa20a301dde3776eb53a939f6875fcb156b5c8825ecd5c078bd5f2dc15bff037ff7288
In order to spend it, I need to know the password and use it as my signature script: scriptsig: 2273757065722073656372657420626974636f696e2067697665617761792023363532
Note that the problem with this script is that as soon as you broadcast it, anyone who is looking can take the transaction's signature out and create a new one with a different destination address and steal the funds. |
|
|
|
AFAIK this can not be a security risk since Electrum uses hardened keys when it derives each of them using BIP32. Someone might need to confirm this.
TL;DR: Electrum raw unsigned transactions contain the master public key of the wallet, which means ALL the addresses of that wallet will be known.In the past it has happened that someone has some issues with signing their transaction with their offline wallet or some other issue and they are asked to post their unsigned tx here. While this can be necessary in some cases to find the problem but it is worth issuing a warning to them that they are losing a great deal of their privacy. They are not just sharing one public key, they are instead sharing ALL of their public keys since the raw unsigned transaction contains their master public key. Here is a test transaction on TestNet: The wallet master public key: tpubD6NzVbkrYhZ4XDUCSwr7Hgi2EDnxVthfLN9gmJZzHoMVYnbFGxafVWQ5pSEijmbg5b9ac3wJuvYGZ6X7PvX9bU9aVQ2vX2pUi9grDsAdggJ The raw unsigned transaction spending 1 input: 0100000001164da872049fd8ea5024a89ba73221ca4ed7fbf3d027023bef7c878fe1b13538010000005701ff4c53ff043587cf000000000000000000580e8e00eed10f8ee39b8d0e9602935c0f6f4acae6b531185d0013e7432438590387447aa43f4b68c366e9a2e6fee6df5181e1969c834d87322b6906825088004800000000fdffffff01b2ae9b00000000001976a9149f9a7abd600c0caa03983a77c8c3df8e062cb2fa88ac49221300 Let's break it down: ScriptSig: 01ff4c53ff043587cf000000000000000000580e8e00eed10f8ee39b8d0e9602935c0f6f4acae6b531185d0013e7432438590387447aa43f4b68c366e9a2e6fee6df5181e1969c834d87322b6906825088004800000000 Human Readable ScriptSig: <push 1 byte> 0xff <OP_PUSHDATA1> <push 83 byte> 0xff version: 043587cf
ExtendedKeyDepth: 00
ParentFingerPrint: 00000000
ChildNumber: 00000000
ChainCode: 580e8e00eed10f8ee39b8d0e9602935c0f6f4acae6b531185d0013e743243859
PublicKey: 0387447aa43f4b68c366e9a2e6fee6df5181e1969c834d87322b69068250880048ExtendedKeyDepth (depth of the used key, here it is 0 since it is the first address): 00000000 Base58EncodingWithChecksum of the bold part is tpubD6NzVbkrYhZ4XDUCSwr7Hgi2EDnxVthfLN9gmJZzHoMVYnbFGxafVWQ5pSEijmbg5b9ac3wJuvYGZ6X7PvX9bU9aVQ2vX2pUi9grDsAdggJ P.S. This works with all Electrum wallet types. |
|
|
|
Still, they are not meaningful numbers. We use int or unsigned int data types when we are dealing with quantities in respected ranges or there is any possibility for such a use case in future.
In block version number case and BIP 34 we are using least significant byte to signal a compatibility level and in txn it is always set to 1 for compatibility purposes and AFAIK occasionally Shipshift sets it to 2. again sort of signaling.
Suppose we declare txn version number as char[4], then we would assert txnVN[3] should be set to a value between 1 and the highest version number.
If you think that way then everything else can only be interpreted as an array of bytes instead of a variable type. But setting the 4 bytes as an int makes things easier. For instance when you get a block and deserialize its transactions it is easier to put the first 4 bytes in an int instead of a byte array and then in the verification process you just say if version<2 && has OP_CHECKSEQUENCEVERIFY then reject as invalid rather than saying if byte[0]<2 && byte[1]==0 && byte[2]==0 && byte[3]==0 && hash OP_..... And transaction version does have a meaning. Check BIP68. |
|
|
|
As for why, it's because satoshi chose to use an int instead of an unsigned int in the original code, so the signedness has stuck around since then.
I could find no history of or a reason for either fields, tx/block version number, to be used as a signed integer, hence there would be no side-effect in case of declaring them as unsigned in the code, Right? That said, I don't understand how would it make any difference at all? As of my understanding of the client code, they are used neither as signed nor as unsigned integer right now. I mean, we could just declare them as char[4], Couldn't we? In short whether you implement it as uint or Int you will be compatible with bitcoin core implementation until version 2147483647! But technically it should never matter as long as nobody sets the last byte bigger than 127 because that is where Int32 and UInt32 start to differ. A signed integer uses the highest bit of the last byte for its sign. For example {255, 255, 255, 255} is 4294967295 as uint but is -1 if interpreted as Int. |
|
|
|
Bitcoin under the hood has a tendency of surprising me! The latest one which I can't find anything about is why is block version and transaction versions defined as signed integers instead of being unsigned integers like any other 4 byte "numbers" that exists in them? While we are on the subject, developer's reference is saying data type is uint32_t for transaction version. I wanted to open a PR but I thought maybe I am missing something since my C++ understanding is limited! ( bitcoin core code?) |
|
|
|
|
Show Posts
