-
-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add Libwally, show xpub in different formats #49
Conversation
Installation looks good, one nit above. I'm seeing: |
yeah this PR is blocked by BlockchainCommons/bc-bip39#19. I updated my WIP points in Status above to make it more understandable. Once that PR is in I'll update the submodule here and the build will work. EDIT: Let me know if you have any tips in how to manage PRs dependent like that. I see one can merge the dependent PR into a develop branch and can than update the submodule in the main PR. But I think one needs to have certain permissions to be able to commit into develop too. |
9fd4ae8
to
d8a6984
Compare
I'm seeing:
I tried adding secp256k1-embedded link to
pls advise |
I fixed the missing dependency in the installation script
Can you check if your clone was recursive, i.e. you have secp256k1-embedded, and your secp256k1 inside is not empty Can you delete all relevant links from your arduino lib folder and try again fresh with this procedure:
|
Now I see:
Looks like |
Yes, you'll need to manually patch it with BlockchainCommons/bc-bip39#19. See my WIP status above |
Ok, I switched |
@gorazdko I think it's going to be important for others to play with the UI as easily as possible. Could you change the |
I don't want to come off as too negative here ... this is exciting and very useful! |
I'm happy you've taken the time to review my code, Ken. I'll address all the points soon.
Yes I can. And I will. This means removing the current
I dont think this will solve the problem though. Because simple recursive clone (git clone --recursive) is pulling the submodules based on the information in master branch. So once you do a checkout to a different branch your submodules become invalid so you have to update them. |
I've updated the status. Regarding the shamir shard ur export, it is not clear to me whether the spec is outdated or is the notation Is there a way to generate test vectors (like ur:crypto-slip39, ur:hd-key etc.) for linux users? cc: @wolfmcnally For one of the test vectors i used in selftest, i got a different result: // https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2020-006-urtypes.md#exampletest-vector-1 The last thing to implement here is slip132 then I'll finish the project with more testing and documentation. RAM usage is currently very big, and the problems already started occurring. I have ran into memory errors and they can occur without a hard fault. Cutting down on globals and string literals put the problems away. We'll have to start following the guidelines for memory optimization. Currently, our selftest has gotten pretty |
slip132 option added.
It's not. I did actual measurements which showed only about 10% usage. The memory problems were due to I think this is now ready for review. Binaries
|
82d9173
to
6e3f187
Compare
…memory allocation
plus another bugfix and resolve compiler warnings
@gorazdko Except for the missing hyphen in
Which is what your input buffer is. The reason it doesn't match the test vector is that you didn't include the "birthday" field, which is included in the test vector. That field is optional, however. |
Abstract
@wolfmcnally I've fixed the URs All the test vectors should follow from this seed: LegacyThese were tested against specter hww: xpub single native segwit mainnet: xpub single native segwit mainnet with slip132: xpub single native segwit regtest with slip132: xpub single native segwit testnet with slip132: xpub single nested segwit mainnet: xpub single nested segwit regtest with slip132: xpub single nested segwit regtest without slip132: xpub m/1: xpub m/1h/0/50h: URThese should be checked by reviewers: single native segwit mainnet UR: A3035821026D717E2446747BC5016ADA285A9FCB9A23F9919BC0F25DBCBA9E3CFFAE0D152D045820A953E7CB9C09B1A5C8AD42E0D3C890D385068A278B864DD1D330C8AA0A50269C06D90130A201861854F500F500F5021AB821DA4E {3: h'026D717E2446747BC5016ADA285A9FCB9A23F9919BC0F25DBCBA9E3CFFAE0D152D', 4: h'A953E7CB9C09B1A5C8AD42E0D3C890D385068A278B864DD1D330C8AA0A50269C', 6: 304({1: [84, true, 0, true, 0, true], 2: 3089226318})} A3 # map(3) ur:crypto-hdkey/otaxhdclaojnjskbdkfgjykgskadimtndehtnesbnycnytmendrtwzhlrfrdnnfnzoplbtbzdpaahdcxptguvdsbnsaspaonsppmfwvttespmhteltamledilulpgttttedysppkbkgddsnsamtaaddyoeadlpcsghykaeykaeykaocyrocltnglhnlbdtin single native segwit testnet UR: A40358210258FB54040F85C69772C2C2807BAA4D67555B6EA2EF81B57450C0DACCB7F52F5D045820C50A16A190D62D7C2DC961F1AEB528A63D2E816495037F55D75635505731563D05D90131A1020106D90130A201861854F501F500F5021A4F4B9336 {3: h'0258FB54040F85C69772C2C2807BAA4D67555B6EA2EF81B57450C0DACCB7F52F5D', 4: h'C50A16A190D62D7C2DC961F1AEB528A63D2E816495037F55D75635505731563D', 5: 305({2: 1}), 6: 304({1: [84, true, 1, true, 0, true], 2: 1330352950})} A4 # map(4) ur:crypto-hdkey/oxaxhdclaohdztghaabsltswmsjpsasalakgpkgtiogohpjtoewslyrejygdrttnsfrlykdlhlaahdcxskbkcmoymhtbdpkedpsohswnplredeolfsdmlyiemdaxlbgotshfecgdhgehhffsahtaadehoyaoadamtaaddyoeadlpcsghykadykaeykaocygwgrmuenestylaut |
Closing this as I'll open a new PR by tomorrow which supercedes this one. It will contain the new shamir shards, wallet output descriptors/addresses and refactored code. |
Abstract
This is one way of integrating libwally support for Arduino (which does not support recursive builds): libwally wrappers are generated with a script whereas secp256k1-embedded is referenced as a submodule
secp256k1-embeeded is included as a submodule because it's too complicated to build it with a script. It is also required to
compile secp256k1 with CC to first get certain files which are then part of the library. This endeavour (building it with a script) can be pursued at some point in future if desired.
Status
Ready for review:
Blocked by BlockchainCommons/bc-bip39#19Edit
Now also using this branch for my further work: