Bitcoin Forum
November 18, 2018, 01:34:28 PM *
News: Latest Bitcoin Core release: 0.17.0 [Torrent].
  Home Help Search Login Register More  
  Show Posts
Pages: [1] 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 »
1  Other / Beginners & Help / Re: Check the balance of your Bitcoin address at a specific date on: November 14, 2018, 04:36:04 AM
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.
2  Bitcoin / Development & Technical Discussion / Need someone verifying these versioned private keys (BIP178 & Electrum) on: November 03, 2018, 12:51:42 PM
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.

hex: 0c28fca386c7a227600b2fe50b7cae11ec86d3bf1fbe471be89827e19d72aa1d [1]
P2PKH: KwdMAjGmerYanjeui5SHS7JkmpZvVipYvB2LJGU1ZxJwYx2CqY6c
P2WPKH: KwdMAjGmerYanjeui5SHS7JkmpZvVipYvB2LJGU1ZxJwYxCGTuAe
P2WPKH_P2SH: KwdMAjGmerYanjeui5SHS7JkmpZvVipYvB2LJGU1ZxJwYxGoTEdc

Note that above is only the BIP178 proposal which is not what Electrum is using. Electrum Extended WIFs will look like these:
hex: 0c28fca386c7a227600b2fe50b7cae11ec86d3bf1fbe471be89827e19d72aa1d
P2WPKH: L6Cyjtdfq1TimFfgG9qBEHQF2FmaL96H5ceTrip74S4eqFapbcDJ
P2SH: LgXW2Y5GXd8GfKikUTQkQynC1zaBfpBBjP8z6YCV2M5VxaMBQ5C1
P2WSH: Lq78bhSAhn3QdqjX2XoeD9sgGRmqWESutpm7ezYaWpqDEuYfi2Sc
P2WSH_P2SH: LygmAro4svxYcMkHacCY1KyAWryVLeie4GPFDStg1JavXEn8H9X5

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?

3  Bitcoin / Development & Technical Discussion / Re: Bitcoind does not like ECDSA (r, s) pair produced by OpenSSL on: October 19, 2018, 06:12:11 PM
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!
4  Bitcoin / Development & Technical Discussion / Re: Bitcoind does not like ECDSA (r, s) pair produced by OpenSSL on: October 19, 2018, 04:57:14 AM
I read about DER encoding and checked how IsValidSignatureEncoding is enforcing it, but I do not know why OpenSSL generates not-DER-compliant (r, s) values?

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,...

How should I overcome this? I am thinking of something along the lines of (pseudocode):

Pair (r, s);
   (r, s) = sign(hash, pvtkey);
} while (r[0] >= 128 || s[0] >= 128); // where r[0], s[0] should be the very first byte of each value

But isn't that kind of redundant? Can I give OpenSSL any flag to produce a valid DER (R, S) pair in the first place?

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.
5  Bitcoin / Development & Technical Discussion / Re: Bitcoin script. Need help. on: October 13, 2018, 04:37:15 PM
function Hash(str)
    const buffer = str.length % 2 != 0 ? Buffer.from(str) : Buffer.from(str, "hex");
    return require('crypto').createHash("ripemd160").update(buffer).digest('hex')

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!
6  Bitcoin / Project Development / Re: Help choose a name for this library... on: October 13, 2018, 04:29:40 PM
Quite a project you got there Smiley are you planning to open the source code?

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...
7  Bitcoin / Development & Technical Discussion / Re: Same private key for 02 and 03 key with same X coord? on: October 12, 2018, 03:04:21 PM
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 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: y2=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 (yp mod 2 = 0) you start the octet string with 0216 and if y is odd (yp mod 2 = 1) then you start the octet string with 0316. (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 0416 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):
public key hex compressed (02/03|x coordinate):

If you have only x (the compressed public key) and calculate y you will end up with 2 values:
y = {32670510020758816978083085130507043184471273380659243275938904335757337482424}
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
8  Bitcoin / Project Development / Help choose a name for this library... on: October 12, 2018, 07:29:45 AM
(Not sure whether to post this in off-topic board?)

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.
9  Bitcoin / Development & Technical Discussion / Re: Signing a sum of bitcoin on: October 06, 2018, 04:05:10 AM
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 Tongue
10  Bitcoin / Development & Technical Discussion / Re: bitcoin wallet master key on: October 05, 2018, 05:37:16 AM
which one is the xprv key ?

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:

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.
11  Bitcoin / Bitcoin Technical Support / Re: C# compute public key from private key, very slow, ~10Keys/s on: October 02, 2018, 04:15:17 AM

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).
12  Bitcoin / Development & Technical Discussion / Re: Is this a puzzle/canary transaction? Unusual patterns in MD160 values. on: September 29, 2018, 04:33:19 AM
To 'solve' patterns like this - matching a specific RIPEMD-160 hash - would effectively require brute forcing the private key space, right?
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.

So then, it's more like a canary: if the funds assigned to any of these non-random patterns ever moved, it would be a very unlikely coincidence, or an indication that something is very wrong.
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.
13  Bitcoin / Development & Technical Discussion / Re: Deterministic Wallet, BIP 39, Seed Words, and relating Public Addresses on: September 28, 2018, 03:19:39 AM
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.
14  Bitcoin / Development & Technical Discussion / Isn't doing % N while generating a random key a flaw? on: September 26, 2018, 04:23:37 PM
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 I256 % 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
While the order of the curve (for example secp256k1 that bitcoin uses):
So the difference would be:
(Which is 17 bytes by the way).

So technically you can end up with a number that is between n and 2256 and eventually because of that mod end up with a key with little entropy. For example if I256 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?
15  Bitcoin / Development & Technical Discussion / Re: The duplicate input vulnerability shouldn't be forgotten on: September 22, 2018, 07:27:09 PM
But you just described Sybil Attack which can happen with or without multiple implementations of bitcoin. It doesn't even need a vulnerability or hashrate to happen.
It's easier to perform this type of attack when you can get other people to voluntarily be your sybil nodes. That's what multiple implementations do in this situation: other people are voluntarily being the sybil nodes.
I may be wrong about this but the way I see it, like everything else such as block size this is purely about what is less bad.

On one hand we have a network of nodes that all run one implementation that if that has a vulnerability which is exploited the whole network will be crippled and the damage will be big.
On the other hand we have new different implementation(s) that might have vulnerabilities and might introduce attack surfaces that will not cripple the network and we have ways to fight these attacks to some extent. So any damage done won't be near as big.

What is the damage of this sybil attack? Some exchange and the traders losing money? That is not new.
What is the damage of a vulnerability like this being exploited? We would be forced to do a "roll back" and lose immutability of bitcoin.
16  Bitcoin / Development & Technical Discussion / Re: The duplicate input vulnerability shouldn't be forgotten on: September 22, 2018, 06:49:00 PM
Suppose there is an exchange that happens to be connected to some nodes that are vulnerable to some kind of attack. Or perhaps they aren't connected directly to those nodes, but connected to node which are connected to those nodes. Suppose this attack causes those nodes to go offline or otherwise become disconnected from the network. Even if there are a very small number of these vulnerable nodes, if they happen to form a ring around the exchange, an attacker can attack those nodes and cause the network to partition.

But you just described Sybil Attack which can happen with or without multiple implementations of bitcoin. It doesn't even need a vulnerability or hashrate to happen.

I do say we need more implementations of bitcoin from scratch. It won't be a perfect solution and it will take time for the software to reach maturity of bitcoin core but the benefits of it are more.
17  Bitcoin / Development & Technical Discussion / Re: How can I verify ECDsa signature that I made? on: September 21, 2018, 01:21:51 PM
then your length fields are screwed up.

YUP. That was it. Thanks.
I missed the fact that 47 (or the right one 48) is the size of the first stack Tongue I mistook it for a DER-length.

If I am not mistaken 48 should be a Compact size integer?
18  Bitcoin / Development & Technical Discussion / Re: How can I verify ECDsa signature that I made? on: September 21, 2018, 01:07:12 PM
(there is an extra 01 in yours)

That is not "extra", that is sigHashType (01 for signall).
An example tx from last block:
19  Bitcoin / Development & Technical Discussion / How can I verify ECDsa signature that I made? on: September 21, 2018, 12:37:02 PM
I have been working on EC calculations, ECDsa signatures and DER-encoding, considering the randomness of the results and the fact that I am not using any kind of external libraries for any of the steps, I don't know how correct my resulting signatures are!

Lets take the transaction in this example with the following private key:

How can I verify whether the following transaction has a valid signature (ignore the fact that the transaction it is spending does not exist):

I will try with TestNet coins later, but for now I would like to know which part I messed up (if any) for today.
20  Bitcoin / Development & Technical Discussion / Re: Generating public compressed/uncompressed key from given private key in C# on: September 19, 2018, 04:36:13 AM
If you want a vanity address then use the project here:
It is fast and tested.

If you want to create your own code then I'm afraid you have to write it from scratch if you want it to be fast. NBitcoin has a lot of bottlenecks that is slowing the process down. That library was not meant to be used for speed.

I can't understand parts of your code. For instance what is currentAddress in part 1, is it public key? And why perform double sha256 on it?
Also try Buffer.BlockCopy it is slightly faster.

In your part 2 the base58 encoding is entirely unnecessary since BitcoinSecret constructor will decode it again!
Create a new instance of Key and pass that in the ctor instead:

Your part 3 has multiple cases where it slows down. The ECC which is unavoidable to convert private to public key (although some methods of scalar multiplications are way faster than others, I believe NBitcoin uses bouncy castle for that which will most probably use a fixed time method. This can be improved if you care to rewrite ECC but I wouldn't recommend it), then another base58 decode and check of the input which can be avoided if you code it from scratch yourself and another base58 encode which may be avoided but I am not sure, have to really check how vanity address creation works under the hood.

P.S. All the Base58 encode/decode functions are slow because they are all using BigInteger which will slow things down drastically (specifically 6 times slower based on my tests)
Pages: [1] 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 »
Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!