Nearly the same as when you make a payment to a legacy address!

TX Size =
4 byte version
1 byte txInCount
  TxIn:
  36 byte outpoint
  1 byte scriptLength
  72 byte script
  33 byte public key
  4 byte sequence
1 byte txOutCount
  txOut:
  8 byte amount
  1 byte size of script
  1 byte OP_Return + 1 byte size of the data + (0 to 40 bytes)
4 byte locktime

Min size=167 bytes
Multiply that with fee in satoshi/byte unit and you will get how much it can cost.
If you use SegWit then you have to calculate virtual size which is 89 vbytes so it an cost even less.

I haven't seen this term before but based on context he probably means a "256 bit hash"!

I am no linux expert but sha256sum in linux is for computing hash values of files and it adds a dash (-) at the end of the input so you are hashing your 'Sf2i....TdPrQ-' instead of 'Sf2i....TdPrQ'. Try this¹:
and you will get the real sha256 hash result. Append the ? at the end and you will get the following hash:
00d3989fec08a5eefc3b2d891f579de60b59bc8fe90fb6af823592ced2372458

Bam!

My knowledge about point at infinity is a little shaky. Try reading this https://trustica.cz/en/2018/03/29/elliptic-curves-point-at-infinity/ it may help.

In order for the elliptic curve cryptography to work we all need to use the same Elliptic Curve. And that curve is defined by a sextuple T = (p, a, b, G, n, h), so yeah G is defined by the curve and is the same when using the same curve.


No, O is defined as the point at infinity.


If you want to understand why there are two public keys (with 0x04 and 0x02/0x03) read this comment:
https://bitcointalk.org/index.php?topic=5049111.msg46800542#msg46800542

Programming language (in my opinion) is the last thing that is affecting speed and efficiency of a code. It is the programmer that is making it fast or slow depending on the way their implementation is.
In any case I always love to see projects that are in C♯ although I would suggest building it from scratch instead of "converting" code. That way you won't import bugs or inefficiencies in your own code. What you can do is to implement each part then compare implementations with each other to improve your code (that is what I have been doing for my library so far).

FWIW you don't need to know "the math behind bitcoin" to write a blockchain parser.

It is called "G" for Generator not Q!

Order (or n) is the order of the generator or G.
Order of a point (G is a point on the curve) is the smallest positive integer such that nP = O.

Base point is a point on the curve which is used in public key cryptography.

What you need to have in mind is that calculations used in Elliptic Curve Cryptography are not regular arithmetic. Instead they are Modular Arithmetic. So y²=... is in fact y²=... mod p.
Calculating it requires using special algorithms one example is Tonelli–Shanks algorithm. There are special cases which can speed up the calculation. In case of secp256k1 elliptic curve that bitcoin is using, the prime number has a special characteristic which makes the calculation easier. And that is the fact that p%4=3 so you can use that formula above with (p+1/4 mod p)

Can you think of a reason why you would want to know your balance on an "specific date" instead of an "specific block height"? Your BCH fork example above would require you to check your balance at a block height not a date.
I am trying to decide whether to implement this in my watch-only-wallet which currently has the height thing.

In want to make sure I understood Extended Wallet Import Format (which is what BIP178 proposes and a couple of Electrum versions used as defaulted), also have some data for unit testing.


Note that above is only the BIP178 proposal which is not what Electrum is using. Electrum Extended WIFs will look like these:

I can't find any test vectors to use so I need verification for these. And c++ has never made any sense to me [2]! So I can't really tell how that PR is tested.
P.S. Is BIP178[3] missing bytes P2SH, P2WSH and P2WSH_P2SH and are they 0x13, 0x14 and 0x15 respectively?

[1] https://en.bitcoin.it/wiki/Wallet_import_format
[2] https://github.com/bitcoin/bitcoin/pull/12869/files
[3] https://github.com/bitcoin/bips/blob/master/bip-0178.mediawiki

I don't see anything wrong.
But I don't know two things, your full code and how OpenSSL works. For instance I am not sure appending that 0 is even needed. Usually when these functions return a value like this they also take care of that initial 0 for you. So your second if may never be true!

2 questions.
Are you doing the DER encoding yourself or is OpenSSL does it for you? If it is the later then it is doing it correctly.
And what do you mean by "non-DER-compliant"? DER is just an encoding, you have some data that you encode using a form of TLV encoding scheme. This way of encoding can handle any kind of value. From 32 byte integers (r and s) to anything else like booleans, strings,...


If OpenSSL is doing the DER-encoding then let it be like that. If you are DER-encoding yourself then first you have to understand why that initial 0 is appended to the result.
For humans when we want to represent sign we put a symbol behind the number showing its sign: -2 or +2
For computer there is no "sign" under the hood so the way it does it is with manipulating the bits (zeros and ones). The way it works for big numbers (like r and s here) is that the computer looks at the highest-order bit of the last byte (little endian order) if that is set the number is negative, if it is not set then the number is positive.
1 byte is 8 bits: 0000 0000 you look at the bold bit and if it was set then you decide about the sign.
127 = 0111 1111
128 = 1000 0000
129 = 1000 0001
...
So if the last byte (or first byte since DER encodes in big endian) is bigger than or equal to 128 and you want the number to be positive (which is the case with r and s) you append a new byte (0) to it to make the computer treat that number as positive.

So this code you posted is wrong because if the first byte of the byte array of 'r' or 's' is bigger than 128 that doesn't make them invalid that you want to try again. They can still be valid, you just have to append a first 0 byte to make it positive.

What you need to check are listed in sec1 pdf section 4.1.3 (!=0 & <N)
In bitcoin there is an additional check for s value only and that is to check if s is bigger than curve order. In which case you use s'=N-s and because of the way used arithmetic works s' is valid.
So here technically you always* end up with a value for s that is small, hence doesn't have its highest-order bit of the first byte (big endian order) set so you don't need that appended 0.

* I haven't really thought about this much but I believe it may be possible to find a smaller s (eg. 31 bytes instead of 32) and that s is lower than N/2 but can have its highest-order bit set (>=128 will fail and reject this valid s) which is another reason why the posted code is wrong.

Your condition is too simplified and it will pass for non-hex strings too. For instance it will pass for Hello world! since it is 12 char long and the length % 2 == 0. You have to do some additional character check too. Psedu code:
if each char is >=a & <=f || >=A & <=F || >=0 & <=9
This can be simplified with regex or something!

Of course. That has always been my goal. I usually release them under MIT license to make it easier for anyone to use without worrying. This library is in its early stages but so far I am very pleased with my progress and design. Hopefully I don't encounter any unsolvable problems.


I appreciate all the suggestions. Keep them coming...

There is only one public key for any private key (a 1-1 correspondence). This part:
"There are two possible y coordinates for any x of a given P
The either of the two possibilities for y is encoded in some way in the compressed representation"
from ietf.org link is explaining the process when you are calculating y from x and in that equation you are left with 2 results which you have to decide which one is the correct one. Not when you calculate public key (x and y coordinates) from a private key.

In simple terms (simple math that is not modular) imagine you have the following formula: y²=x And I tell you x=4. You use your basic math to calculate y and come up with two values: +2 and -2 but you don't know which one is correct. But if I told you x=p4 and we agreed on a standard that when a number starts with 'p' that means the y value must be positive (n for negative) so you calculate y again and discard the negative number and say the point was (4,+2).

Now in modular arithmetic things are the same. There still is only one valid point that corresponds with your private key. But because of the way Elliptic Curve looks, a vertical line crosses the curve on two points hence 2 y values. The standard for ECC based on SEC1 is that if y is even (y_p mod 2 = 0) you start the octet string with 02₁₆ and if y is odd (y_p mod 2 = 1) then you start the octet string with 03₁₆. (SEC1 page 10 part 2.3.3). The reddit comment is saying positive/negative instead of odd/even which was a mistake.
The 02 and 03 are like the standard I explained above with (p and n). And 04₁₆ means we are reporting x and y both.
Reporting x and y is called uncompressed public key.
Reporting x alone is called compressed public key.

Example with private key = 1
private key hex: 0000000000000000000000000000000000000000000000000000000000000001
public key hex uncompressed (04|x coordinate|y coordinate):
0479be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798483ada7726a3c4655da4fbfc0e1108a8fd17b448a68554199c47d08ffb10d4b8
public key hex compressed (02/03|x coordinate):
0279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798

If you have only x (the compressed public key) and calculate y you will end up with 2 values:
y = {32670510020758816978083085130507043184471273380659243275938904335757337482424}
or
y = {83121579216557378445487899878180864668798711284981320763518679672151497189239}
but since the compressed public key had a "helper" in it (the first byte which was 2) it tells us that we should choose the even value of y which is the first one which was an even y. And 32670.... in hex is exactly 483ada7726a3c4655da4fbfc0e1108a8fd17b448a68554199c47d08ffb10d4b8

(Not sure whether to post this in off-topic board?)

---

TL;DR.
Current library name: SharpCryptoLibrary
What it does: A .Net library focusing on being stand alone, fast, documented, fully tested and used for as many cryptocurrencies as possible while being able to do anything such as creating a wallet, full/SPV node, writing smart contracts,...

I prefer using consistency which is why the name "Sharp..." was chosen, and since this is written fully in C♯. So I'd prefer to keep the name this way. Maybe the current name is good but I though a brainstorming here wouldn't hurt.

---

Some explanation about the focus of this library:
1. Basically I am learning and enjoying the cryptocurrency world and related topics. And as I learn more about it, I develop this library as a way to have a deeper understanding of the technology while creating a useful tool. Although many libraries already exist, I feel like there is still many features lacking.

2. One of the main focuses is being stand alone. Meaning no external libraries will be used for any operations. This has advantages and disadvantages. The positive part is that there will be no need for downloading a third party huge library to only use a small part of it (eg. Bouncy Castle for E.C.C.) and this makes it very flexible. But the negative part is that the library is going to be as good as "I" make it so obviously it may not be as secure (hopefully it becomes secure one day after extensive testing and review).

3. Another main focus is the usage of each function for almost every cryptocurrency that exists, while making it easy to extend it to new coins with custom settings. This includes:
- bitcoin and all of its forks (bitcoin-something, litecoin, dogecoin,...) which use the same transactions, same cryptography schemes (secp256k1 curve), same way of communication, encoding,...
- and will extend to other coins that are not forks but are similar (XRP, ETH,...) that use different encoding techniques (KECCAK for ethereum), and sometimes different curves (secp256r1 and some others),...
- and coins that are very different (IOTA,...) that are are very different (Winternitz hash-based cryptography in case of IOTA).

4. Thanks to Microsoft's recent(ish) move to make .Net framework multi platform you would be able to build applications for any platform from Windows to linux and smart phones. All using the same library.

5. Another focus/goal is to have everything neatly categorized and fully documented. So that it would be easier to find a desired function and know right away what it does and what it needs. Current categories are:
- BIPs: which is every Bitcoin Improvement protocol created (only 10% covered so far)
- Blockchain: everything related to blockchain including blocks, transactions, (de)serialization, verification, scripting, smart contract,...
- Coins: cryptocurrencies and their settings used to feed the functions through dependency injection.
- ECC: everything related to Elliptic Curve Cryptography such as calculation, modular arithmetic, primality test (so that you can create any custom Elliptic Curve that is not defined by SEC2),...
- Encoders: any baseX encoding used, DER encoding, encryption such as AES used for wallet storage,...
- Extensions: simple extension classes to be used throughout the library to make things simpler.
- Hashing: contains hash function wrappers for SHA and a stand alone implementation of RIPEMD160
- KeyPairs: responsible for key pairs! private/public keys and addresses
- P2PNetwork: responsible for the communication protocol used by nodes.
(I mentioned the categories here so that if you have any suggestions about where things should be you can tell me, also if I am missing something that I haven't covered feel free to post below).
Example of how the documentation would look like:


The library is far from finished. There is a lot of work remaining to do and a lot more tests to write and some parts need to have their security improved (such as PrivateKey class and the modular arithmetic used for ECC). I think about roughly 30% of the work is done with about 80% of it being covered by extensive unit tests.

If you want to define something that does not exist then you also have to define a standard for it too. For example in this case you can define it like this:
1. Append all the transaction outputs you want to sign together. (Lets assume it is 5 UTXO belonging to 3 keys). Put transactions that belong to one key together and the order is important.
Perform a SHA256 on the whole thing to make it 32 bytes.
2. Sign with key1, key2, key3 and then concatenate 3 resulting signatures together. You can DER encode it if you like:
* Seq and int are DER flags.
** There is an additional part in signatures for recovering public key that I am not familiar with yet but assume we added that to the signature

You are looking for an extended master private key which is in the first line saying "extended private masterkey".
xprv is the starting 4 characters when you have a master private key for bitcoin mainNet but when you use a different network (TestNet here) the first characters can be different. In this case they are tprv.
Check this out: https://en.bitcoin.it/wiki/List_of_address_prefixes

The next two lines are the addresses that were derived from that master key with the mentioned paths.

P.S. TestNet coins don't have any value but remember that you should never post your keys anywhere like this.

FYI, NBitcoin is "other soft" which he was asking not to use. Not to mention that it is a wrapper around C# implementation of Bouncy Castle which is a wrapper around the main project which is Bouncy Castle and it is written in Java.

P.S. If you want fast EC calculations then you have to have the Gs pre-calculated and use that for the scalar multiplication. Otherwise if you are using the usual "Double-and-add" method, it will be time consuming. Of course 10 second is not because of that. It is because of all the overhead that these libraries have! Otherwise if you re-write the same functions and use that, your timing will be reduced to <3 second per 100 iteration (checked with debug mode, it will be faster in compiled).

You can't go in reverse. There are first two hashing algorithms that you have to reverse in order to find the public key: RIPEMD160 then SHA256 which is obviously impossible to reverse one, let alone two!
Even having the public key you still have to reverse the Elliptic Curve calculations to get to the private key. Which is again obviously impossible.

Not necessarily. All you can say is that it is impossible to find the private key by having the address. But what you don't know is that someone might have gotten lucky and actually created one of those addresses from a private key so they can spend the funds belonging to that key.

If you have ...
- The seed (set of words)
- The master private key (a long string starting with "xrpv")
Then you can get all the addresses that can ever exist with any path that you like as long as it comes after this extended key.

If you have ...
- Master public key (a long string starting with "xpub")
Then you can only get addresses that are not hardened

If you have ...
- Individual private key(s)
- Individual public key(s)
- Individual address(es)
Then you can't associate them together or find their master key.

If you have ...
- A master public key + a derived non-hardened private key
Then there may be a way for an attacker to find the master key.

I have been going around and reading a lot of ECC code lately, and recently I realized some of them do something that at first sight seems harmless but I think can potentially cause some bugs. But I am not sure!

Basically when generating a new key they generate a new 256 bit number (byte[32]) then they calculate I₂₅₆ % n (I being the 256 bit number equivalent) to make sure it falls within range of curve values.

Here is the problem. A 256 bit number can be as big as
115792089237316195423570985008687907853269984665640564039457584007913129639935
While the order of the curve (for example secp256k1 that bitcoin uses):
115792089237316195423570985008687907852837564279074904382605163141518161494337
So the difference would be:
432420386565659656852420866394968145598
(Which is 17 bytes by the way).

So technically you can end up with a number that is between n and 2²⁵⁶ and eventually because of that mod end up with a key with little entropy. For example if I₂₅₆ is n+1 you will end up with private key 1 while the byte[32] was random and big enough.

I guess my question is whether this chance is too small that it doesn't matter or is it in fact a flaw in this type of implementation?