Thanks for the report. I opened a new issue addressing this: https://github.com/spesmilo/electrum/issues/6449apparently this is intentional since they don't want to force people to update to v4 as of yet.
But it has been released as an stable version for a while now. It would have made sense when it was beta release. |
|
|
|
A 256-bit number bigger than n modulo n is at most only 128 bits.
It actually is at most 136 bits (0x014551231950b75fc4402da1732fc9bebe). If one knows the xpub, then k-par is known, and it is possible to recover the private key.
You can't know the parent private key from xpub, you only know the parent public key (capital K) and even then to compute a child private key you still need another private key, even if the next key was only 1G ahead. P.S. I honestly can't think of any reason why this decision was made. |
|
|
|
I have some experience with working on C and Python. I can read that code and make sense of it. The maximum program size that I have ever written would be just a couple hundred lines only. How would you rate C# for someone with basic knowledge of C?? Is there a starting point you can suggest??
You'll probably love C# too. I find C# to be one of the most balanced programming languages. It is easy to learn, develop, scale and maintain. You can write code that runs nearly as fast as the same code written in a low level language such as C, and with .Net 5 and 6 I'd expect the gap shrinks even more to the point where they both compile to the same exact machine code. In some ways you could say it is between C and Python. C# can be used to write a wide variety of applications and for all platforms, from desktop apps to web apps and mobile apps. It is also being used to write games. The size of the binary can be as small as 8 kilobytes to several GB. Knowing C you could also write low level code for specific parts that need to be like that and then simply call it inside your C# app using PInvoke. To get started take a look at this similar question: https://www.reddit.com/r/csharp/comments/88v4w5/transitioning_from_c_to_c/ also check the sidebar for more useful links. MSDN has excellent documentation and guides to get you started with C#. I see and appreciate your work, especially the way you simplify and explain things. I would love to learn from following you.
Thanks for your kind words. Hope to see your projects and/or contributions on GitHub soon.  |
|
|
|
Follow up ques: If parent key at m/44'/0'/0'/0 is found to be valid, shouldn't I be checking the corresponding parent key of internal chain at m/44'/0'/0'/1 before assuming its safe to use? Otherwise we would have no valid change addresses to send money to.
Each key is checked only when it is generated and wallets usually generate a bunch of them at a time, there is no need to check the ones that may be generated in the future. Keep in mind that chances of finding an invalid key is extremely small since sekp256k1 order is very close to 2 256. If a child key was invalid you simply skip it and get the next one, meaning m/44'/0'/0'/0/0, m/44'/0'/0'/0/1, m/44'/0'/0'/0/2, m/44'/0'/0'/0/4, m/44'/0'/0'/0/5 assuming index=3 gave an invalid key. But if the parent key (eg the key at depth 1) was invalid you should stop, that would be a very unlikely error and the seed must be changed, meaning stop if m/44'/ was invalid. At least that is what I do in my Bitcoin.Net code. |
|
|
|
Version 0.3.0 released. This release is focusing on the default transaction signing methods and Script classes by improving the code and increasing their test coverage to near 100%. - New BIP: Signatures of Messages using Private Keys (BIP-137)
- Improve Address and FastStream classes
- Add missing parts in transaction methods for signing
- Some improvements and bug fixes in script classes
- Various code improvements, xml doc correction, additional tests and some bug fixes
Version 0.4.0 released. This release is focusing on the improving P2PNetwork namespace - Improvements in P2PNetwork namespace
- New BIP: Compact Block Relay: SendCmpct, CmpctBlock, GetBlockTxn (BIP-152)
- New hash algorithm: SipHash
- Add a miner with limited functionality to add the option to mine a block if needed (will be improved in the future)
- BIP-39 now lets caller get the entire 2048 words from its wordlists
- Various code improvements and additional tests
Version 0.4.1 released. This minor version focuses on improving P2PNetwork namespace more and adds a new BIP - New BIP: Electrum mnemonics
- Minor optimization of some of the classes under Cryptography.Hashing
- Separated listening and connecting operations from Node class
- Decouple more classes in P2PNetwork and introduce NodeStatus and ClientSettings classes
|
|
|
|
|
It could potentially cause problems if we ignore validity (being in range) of the parent derived keys because even though BIP-32 may look like any other Key Derivation Function but it is more than a simple KDF. For instance each non-hardened child key is derived using the parent's public key which means that parent key must have been in range to be used in EC multiplication.
BIP-44 is not relevant here but since you mentioned it, lets take the path used in this BIP:
m / 44' / 0' / 0' / 0 / 0
The bold one is the child keys used in creating addresses.
You won't notice the problem in first 3 depths since they are all hardened but the last one is not. If the parent key at m/44'/0'/0'/0 returned a key that is outside of curve range you can't derive the child key at m / 44'/0'/0'/0/0 anymore.
So the standard has to enforce this validity check on each step.
|
|
|
|
I'm trying to add Electrum mnemonic recovery option to The FinderOuter and looking at the test_mnemonic.py file I'm having trouble understanding the tests even though I think I understand how the mnemonic.py file works. The English test vectors in this file and also random keys I created using Electrum work fine meaning after computing HmachSha512(data=words, key="Seed version") I get a digest that starts with SEED_PREFIX (01) or SEED_PREFIX_SW (100). eg. the first digest is 1001bc7d1ea.... which is all Electrum looks for in a valid mnemonic (there is no checksum). But the rest don't. Take the Chinese case for example, the digest is 0f5c4c9ff66e87bcbdde59f06ad540eba48fe06f7bdfa16b1248cb868ae3cd3fe7f6ea08e50bc77fdec1f08d8b5710bd25a9d76427e636feed23cbcb3ec8b8cb
Which is incorrect. It is worth mentioning that the words are normalized using form KD as is with BIP-39 and return the same bytes as the "words_hex" in test vector. So what is the problem here? |
|
|
|
I'm trying to decode a bech32 address tb1qwm3dqje4wc7cs2u9sv39yh2as8ae0ntzqkjunw into the h160 of the public key
Same process steps in reverse: Map each character to its index in Bech-32 charset after removing hrp (q=0; w=14,...): The result is in base-32 (5-bits group) and has to be converted back to base-256 (8-bits or 1 octet/byte group). Also since this is an address, the first item is the witness version that has to be dropped and evaluated separately. 14 = 01110
27 = 11011
17 = 10001
13 = 01101
0 = 00000
18 = 10010
25 = 11001
...
Select 8-bits at a time: 01110110 11100010 11010000 01001011 ...
118 226 208 75 ...
which is 0x76e2d0... in hex and the same result that the site you linked gives. PS. The additional steps to expand H.R.P and compute and verify checksum are skipped for simplicity but are mandatory. Try again, when decoding Bech32=tb1qwm3dqje4wc7cs2u9sv39yh2as8ae0ntzqkjunw it returns 0x76e2d04b35763d882b858322525d5d81fb97cd62 as data (hexadecimal). |
|
|
|
Surprisingly, '99' flag resulted in 'K' or 'L' in every random private key that I've tried
There are a bunch of different variations that could give similar looking key strings. Here are 3 examples from Bitcoin.Net test vectors: 5GPHYxaeAAqL2egjmyU8Kaaqh831aw12XJ92y2rgRWi1zc
L5HydKmZoMcqfoY9Rgi8BRnWGmDw9YhoUS9ArnToVxvyFbM9GyfJ
KwFAa6AumokBD2dVqQLPou42jHiVsvThY1n25HJ8Ji8REf1wxAQb
Same with BIP-32 extended keys. |
|
|
|
the thing is when manually added the address with balance. it shows 0 btc,
Possibly because blockexplorer.com no longer works. |
|
|
|
|
I'm adding BIP-39 recovery option to The FinderOuter and even though adding the option to also check uncompressed public keys or the addresses created using those is trivial, I'd rather not add it if it were never used in the history since sometimes having too many options is creating more confusion and my focus is simplicity of the tool as much as possible.
|
|
|
|
but is cascasius present at forum, or reading this,
Barely. Last activity on bitcointalk was 2019-12-29. Last activity on GitHub was 2013-02. |
|
|
|
Do you have any idea how many "anyone can spent" outputs there have been in history like the one you linked where it always pushes a 1 to the stack at the end?
No, I haven't done any research in that area, actually I didn't know that address was used before either. Here is another one on TestNet though: 2MyHxGtCH53AhhWTzqwRRCq3MUZ5DahmhRi |
|
|
|
Is this a complete list or am I missing something?
If you think of "addresses" as human readable form of certain scripts then you'll see that there really isn't any cap to the number of addresses you can create, of course some may make no sense and some may be non-standard but for the sake of technical discussion here are some examples: P2SH-P2PK: 33SjdVkpGHBENVKtYCEDtk4RmAPK7kvJUA P2SH-P2PKH: 3LyehHxt2uq83FJz9EudBEVQR8mgtsPg8D P2SH-1of1MultiSig: 3Ly4mSGMWhXq9KTXMnUvwy5rHoLoFBKYq9 P2SH-(locktime): 37TUHj9a2T7ip3m23Z5jX6YHJShZBRoHYv (locktime= e359de5e) P2WSH(locktime): bc1q7le8nq4pem836mn702n3svx9q82wps9nv3rxhgh69eh2cl84ewrsv6f8t2 (locktime= e359de5e) ... And here is an address that anyone can spend from: 3MaB7QVq3k4pQx3BhsvEADgzQonLSBwMdj As an exercise try to guess redeem script of each of the above addresses. Here is the code I used to create these: https://gist.github.com/Coding-Enthusiast/5e58b3ddc2161c853562bc483beddf69 |
|
|
|
|
I've seen some reasons here and there but looking for full arguments against this BIP.
|
|
|
|
|
Show Posts
