I had to dig deep into LightningPeach source code[1] to figure this out and please note that I have little expertise in JavaScript so don't take this as review of the code.

Your wallet depends on LND which in turn creates the seeds for you (based on my understanding) and the seed scheme is not BIP39 but instead a modified version of it which they call AEZSeed (AEZ = easy authenticated-encryption method made easy) differences include addition of a version byte, a timestamp and using scrypt instead of PBKDF2 and using AEZ encryption! [2]
This is why you are getting "BIP 39 (checksum:failed)" exception in Electrum.

I don't know of any tool that you could use to convert your seed words to BIP32 extended master private key but it doesn't seem that hard to write a script to do that.

[1] https://github.com/LightningPeach/lightning-peach-wallet
[2] https://github.com/lightningnetwork/lnd/blob/d541ebe3765bc0db9fe568332f7aabd3a2014612/aezeed/README.md

This is a bitcoin forum, so it is guaranteed that (at least) every legendary member has a bitcoin wallet and is capable of signing a message with his private key. Security of that digital signature (ECDSA) is no less than security of PGP signatures (RSA or DSA). But the problem is most members don't have any use for PGP so you would be forcing them to use something they don't need.

P.S. BIP322 exists for signing standard.

It really isn't that hard to implement even if different wallets used different standards, the difference would be in the first byte and the rest is the same. Every signature has a "signature" that is r and s which you use to recover the possible public keys (most cases only 1 possible but can be up to 4) hash them and compare it to the given address. The first byte is just telling you which address is supposed to be correct, which you can ignore and loop through all possibilities.

Also regarding SHA-1 here is my thoughts:

Legacy is about 1.6x bigger for the most common cases. The link you posted yourself has a good example, the size is decreased about 37% (from 904 to 561 weight units).

The thing about TPS is that there is no "expected value", there is only a minimum and a maximum. The minimum is when there is only 1 transaction per block (like Block #364292 and a bunch of others) where TPS becomes 0.0016 and when the blocks are filled with 100% SegWit transactions in their smallest form which that SO link is explaining. In the end we will reside somewhere in between depending how how people are using bitcoin, for example the more they use multisignatures the less transaction is going to fit in a block and the lower the final TPS is going to be.

P.S. To clarify the limit is not longer 1 MB size, it is instead 4 MB weight.

Your first line was very misleading because from what I understand from Mandelbrot Sets usage in fractal based cryptography it has nothing to do with hash function (ie. SHA256) which you start this topic about.[one of the usages of] Mandelbrot Sets fall under the category of Asymmetric Cryptography so what you are saying here is an alternative to Elliptic Curve Cryptography that bitcoin and most other altcoins use.
I am intrigued to know more about difficulty of this algorithm compared to ECC and RSA and efficiency of its calculations though. Do you have anything on that kind of comparison?

Is it really insecure in this context?
To my knowledge the only problem with SHA-1 so far is collision. Considering SHA-1 is 160-bit and there is a known structural weakness, it has a time complexity of 2⁶³ which is very fast. But in this context the security depends on ability to find a second preimage (since the message aka the pubkey and the hash of it is already known), and there has been no weaknesses found to help perform this any faster so this has a time complexity of 2¹⁶⁰ which makes it expensive enough to be secure.

For the (nearly) past year I have been working on a library from scratch mostly to educate myself about cryptocurrencies and cryptography and at the same time increase my coding skills. I chose this kind of project because I saw some gaps in the existing libraries that I wanted to solve to best of my abilities. At this point I would like to brainstorm and know about things that other developers think are missing from existing libraries or things that you don't like about them.

Here are some examples that I have noticed:
1. Lack of independence
Many of the libraries are basically wrappers around other libraries which means you have to download multiple other projects sometimes in different languages. This sometimes introduces flaws such as the case with that Javascript malicious code injection through one of dependencies in one of the libraries.

2. Lack of documentation
This is probably the most annoying because sometimes it is hard to figure out what some functions do or how to use them.

3. Lack of originality
I will probably open up a separate topic soon about this in Development & Technical Discussion board discussing this topic in depth. For now lets just say there is a lot of code copying going on. This one has introduced bugs such as the case with BIP39/32 with those python and javascript libraries that were copying flaws over to their own code.

4. Scalability
For example if you want to create a multi-coin wallet you will have to download multiple libraries and depend on all of them each for a different coin while this can easily be done through one singular code designed in a way to work with all of them! That would eliminate new releases for both the library and the wallet. Adding a new coin would require injecting a new settings file (like an xml) to the already released wallet built on top of that library.

@darosior
I believe that it does not matter what you hash as long as you use the same algorithm for verification too. Meaning during verification if you calculated c by hashing (msg + R) you do the same thing again which I do since I use the same value for c that was already calculated! By the way the Musig paper is saying you should hash (Xagg + R + msg).
I actually checked a couple of libraries last night and it seems like everyone is doing a different thing when it comes to MuSig!

BUMP!
I still need help figuring out why I am getting false when trying to verify the signature.
https://gist.github.com/Coding-Enthusiast/6596a29fe361695a169f40ffd7d1e1f7

why are you rounding N? That is not the correct value.

I am not really familiar with python but you may need to change sizeof(x) and sizeof(y) here to a hardcoded value '32' instead since x and y can be less than 32 bytes but you must return them with zeros appended.
Here is a unit test that must pass:

To OP:
You need to use another library on top of this one. You call your GetPrivateKey(shortKey) function with your mini private key and it will return an actual private key in hexadecimal formal. Then pass that into a key function in that library. Check out https://github.com/warner/python-ecdsa for example.

To be fair, that has nothing to do with Schnorr, the size is reduced by simply dropping the useless (in case of bitcoin) DER encoding. You can already drop the extra 6 to 8 bytes from every single signature that has been created in the past 10 years since they all tell you the same thing:
- 1x DER-sequence tag: 0x30 (we already know it is 2x 32 byte integers)
- 3x DER-length: telling us what we already know about the lengths (32 bytes)
- 2x DER-int tag: 0x02 which we already know it is an integer (r and s)
- possible upto 2x 0 byte appended to tell us these numbers are positive which again we already know

I see what you say. I am mainly reading them out of interest then only focus on those that are actually used somewhere. Like URI scheme (BIP21), Version Extended WIF (BIP178 + the original one used by a couple of Electrum versions), HD wallet BIPs,...

Recently I've started going through BIPs from #1 to implement whatever I've missed and I realized there are many numbers missing. I am wondering whether they were never assigned or were there BIPs that got deleted. If they were deleted then what was the reason since we already have many BIPs that were either withdrawn, rejected or replaced by newer versions but they are not removed?

Here are some of them from the start:
3 to 7
24 to 29
46
48
51 to 59
76 to 78
[..more..]
A jump to 300s

Since nobody has answered you yet, I'll give it a try.

Let me start by saying that P as in Fp is a prime that is defining your finite field or the finite set of elements in your group in which you are doing all your calculations. So when we talk about point addition your modulus is P since you are working in that group which has P elements.

N is the order of the subgroup of the main group that you had and is generated by the generator G. That is also why N is smaller than P. And it is mainly used in signature schemes. For example when you calculate `s` you are using mod(N). And that is because now you are working in that subgroup instead.

More information: http://www.secg.org/sec1-v2.pdf

@arulbero thanks for the explanation but it seems like you made a small mistake here:
In giant steps you pre-compute 0G, 1G, 2G, ..., (m-1)G. So in this case it seems you should be calculating kG, (k+1)G, (k+2)G, (k+3)G

Then for the baby step you calculate
s= m * -G
loop: r=r+s

Previous outputs which this transaction is spending weren't "scripthash", they were Pay To Witness Pubkey Hash[1]. That is why the signature (or more precisely the scriptsig) is "transferred" elsewhere in a field called "witness" instead of it being in its usual place after the outpoint.

[1] https://bitcoin.stackexchange.com/questions/64733/what-is-p2pk-p2pkh-p2sh-p2wpkh-eli5


This is your scriptsig.
30 <-Sequence tag of DER
45 <-DER length
02 <-Int tag of DER
21 <-DER Length
009c081fce7e263de3c8a0b0b12b18b6338cb2db4fc2f37ce3d22ec4ad618d6110 <-x coordinate of R
02 <-Int tag of DER
20 <-DER Length
521e0fbabb810593ef6878169e0d1020e69b167b9bbf54915b44e92c5b55ab73 <-s
01 <-SigHashType
21 <-OP_PushData
0279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798ac <-compressed public key

(there are some CompactInt sizes among these numbers that the JSON serialization has omitted though)

Public key's X and Y coordinates are represented as big endian.

It is not padding, you are representing an x-byte integer in little endian order. So for example when you have UInt16=253 it is actually 2 bytes in your memory (16-bit) and since it is little endian the least significant bit is at the beginning meaning { 253, 0 } and UInt16=256 would look like { 0, 1 } (256= 0*256⁰ + 1*256¹)

The correct form is: fe8297fc00

That part is in serious need of at least 2 or 3 examples, I have had trouble understanding it too. This page has an example which can help.
More:

integer	|	compact	|	Base16
_________________	|	_______________	|	____________________________
252	|	{ 252 }	|	{ 0xfc }
253	|	{ 253, 253, 0 }	|	{ 0xfd, 0xfd, 0x00 }
UInt16.MaxValue	|	{ 253, 255, 255 }	|	{ 0xfd, 0xff, 0xff }
UInt16.MaxValue + 1	|	{ 254, 0, 0, 1, 0 }	|	{ 0xfe, 0x00, 0x00, 0x01, 0x00 }

Sorry for my laziness, copying from PDF is hard

---

I must still be missing something here (possibly in Hash steps) because I get a false in my verification step whereas I can do it fine with alternate version for collective signature creation.

Here is the (stripped off) code: https://gist.github.com/Coding-Enthusiast/6596a29fe361695a169f40ffd7d1e1f7
Maybe someone can see where I am messing things up?