You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Based on the Bitcoin Address Prefix List, the address for HD SegWit address generated prefixed with bc1 and the multi-sig P2SH address generate prefixed with 3. The basic format is confirmed to be correct.
Based on comparison with Crypto Mobile App, the generated HD SegWit address is same to the value in App when path is m/84'/0'/0'/0/0 using App's generated seed phrase.
Based on the comparison with Online Multi-Sig P2Sh tool, the result is the same given the same m and publicKeys
Security
In order to make the random source strong, we develop another api to generate a seed with mnemonic words, using Node.js crypto library randomBytes method link here. If the security is required to be real random, hardware needs to be involved. (e.g TrueRNG V3)
To protect HD wallet from child private key leakage, we enforce using hardened index in account level. e.g m/84'/0'/0'/0/0 as the path. Attacker can use child private key (non-hardened one) with parent public key to get the parent private key. But hardened private key has its trade-off, it requires to know the parent private key to generate the child key, which weaken the segregation between private key and and public key. In reality, the non-hardened keys are still quite secure as long as user doesn't save the child private key online.
In order to increase the security of user, they should write down the mnemonic words on paper or record in some hardware to keep it secure. Besides, they should keep private key offline and use it only for spending situation (for signature). For public key, they could save it online and should be used for receiving.
Documents
Graphql itself serves as a strong-type documentation for developer to integrate into a bigger system. I've also added extra description in graphql for client to read and understand.
The latest Apollo Studio has provided a user-friendly interface for developer to interact with the API with all options and descriptions displayed.
Any other documents is recorded in the project README.md file to understand how to use this project.
Coding
Testing: Unit tests is 100% covered.
Dependency-Injection: Dependency-Injection and Provider Pattern is utilized to create loosely-coupled codebase.
Validation: DTO is used to validate input externally from API and ban any bad request as early as possible.
Entity will be a good entity to convert into a DDD domain object in future once the business get quite large and complex. It's also the candidate place to send domain events for asynchronous communication in a micro-service system.
Utility: Self-developed utilities are used as well. For example, the trace function automate logging the input into each layer and also measure the performance.
Code Reuse: I have developed one class called DTOBase to extract common code for DTO class to do transformation, validation. Especially, developer could override validate method to hook some complex validation logic into DTO. e.g validate at least 2 fields should be provided.
Development Tools:
github action is used to run unit tests and detect if the branch is not rebased from main branch
husky is used to do eslint, prettier and conventional commit check when running git commit ... command