new libraries required

[gorazdko]

Abstract

BIP32

I see 2 options:

• bip32 from trezor: this would need to be cleaned up (of altcoin code), it has many dependencies, including secp256k1 (written by trezor). It would probably need tweaking to work on arduino.

• there is a library Micro-Bitcoin by stepan snigirev which is also based on trezor crypto. But this library already works out of the box on arduino. It also supports psbts, different types of address derivation etc. It is nice to work with.

QR encoded UR format

From bc-seedtool-cli the following is required:

• cbor
• ur
• bc-bech32

I will rewrite this (or the necessary subset of it) for Arduino.

Questions

What are your thoughts on bip32 library? I'm thinking second option.

[ChristopherA]

I was told that LibWally was designed with embedded in mind, and that is what we are planning on using for bc-seedtool-cli.

@wolfmcnally is planning to write some simple cobra & ur code, but is critical pathed on another project. You should coordinate with him, one of those might be a good project for you.

[gorazdko]

I was told that LibWally was designed with embedded in mind, and that is what we are planning on using for bc-seedtool-cli.

LibWally supports desktop and mobile platforms and is the right choice for bc-seedtool-cli, but not necessarily for bc-lethekit. It does not support Arduino.

However, there is an embedded version of libwally (by stepan snigirev) that
works out of the box on Arduino. So we should import that as an Arduino library if we're going with libwally.

@wolfmcnally is planning to write some simple cobra & ur code, but is critical pathed on another project. You should coordinate with him, one of those might be a good project for you.

@wolfmcnally, what is the status of a simple (embedded) cbor/ur library that can be (im)ported to Arduino? If there are any branches active Id like to join in and help.

The cbor/ur from bc-seedtool-cli is a too heavy c++ to be ported to Arduino. I have written a smallish UR library for arduino myself only for what i'll be needing in lethekit:
the simplest cbor encode/decode (bc-bech32 used from bc-seedtool-cli) and UR encode (using Arduino String). At some point later ArduinoCbor can be introduced for complex cbor structures. It is an Arduino wrapper around cn-cbor which is listed in https://cbor.io/impls.html

In conclusion:

• which bitcoin library should we introduce into bc-lethekit? Should we take libwally-embedded over uBitcoin?
• Is there a plan or an active development of an embedded version of cbor/UR?

cc: @ksedgwic what are your thoughts?

[ChristopherA]

However, there is an embedded version of libwally (by stepan snigirev) that
works out of the box on Arduino. So we should import that as an Arduino library if we're going with libwally.

@gorazdko I'd prefer to go this this direction as I'm comfortable with the underlying security of libwally. However, it looks like this specific repo is more of a build wrapper around libwally itself, which I'd rather not point to as a dependency, and even the author feels it is a bit of a build hack.

I'd rather see our own repo that does roughly the same thing, but works the way the rest of our C and C++ builds work. The build method is something that @wolfmcnally has been working on for other repos.

I suggest that you both look at https://github.com/diybitcoinhardware/libwally-embedded and see if we can replicate it but with our tooling in a new repo bc-libwally or bc-libwally-embedded or some such.

-- Christopher Allen

[ksedgwic]

I'm a little familiar with libwally because c-lightning uses it. It seems well regarded and generally well maintained. My experience with it has been good.

I'm not familiar with the embedding wrapper described.

[gorazdko]

I've imported libwally into bc-lethekit, compiled and ran an example without problems. The program storage space of lethekit increased to 54% which is ok. Also, bitbox02 hw wallet (also a version of samd51) is using libwally - this is reassuring regarding run-time behaviour of the lib on the MCU. The secp256k1 also supports using less RAM at the cost of (signing/verification) speed.

There was one function definition clash with bc-bip39 (bip39_get_word) which we can deprecate (eventually) or fix for now.

I'd rather see our own repo that does roughly the same thing

All we need is to integrate properly the script into bc-lethekit and call it within install-lethekit. This would restructure libwally-core so that it is understandable for building with Arduino. In addition, we would have to write some code to extract and install the secp256k1 compliant with arduino library folder structure.

This way we access the same libwally-core from bc-lethekit and bc-seedtool-cli.

I'm not familiar with the embedding wrapper described.

Just like bc-lethekit dependencies (e.g. bc-crypto-base) need to have a certain folder structure libwally has to have one. That's all that wrapper is for (It is generated with script).

I'll use the library. In the meantime, let me know what you think about the approach of accessing and integrating the library with this repo.

[gorazdko]

My UR library (with tests) for Arduino is here: https://github.com/gorazdko/bc-lethekit/blob/ur_encode_lib/seedtool/ur.ino

Let me know what you think.

[wolfmcnally]

@gorazdko The UR functionality in seedtool is functional but still what I'd call a prototype, not a full reference implementation. I'm currently architecting the fountain codes piece in Swift, and once I have that I'll most likely be doing a C++ implementation as a separate library that seedtool will then migrate to use.

[gorazdko]

Regarding libwally integration:

#49 is one attempt at integrating libwally.

I think I would rather see libwally-embedded and secp256k1-embedded recreated in this group and make a reference and ditch the build script in #49 that generates libwally wrappers. secp256k1-embedded can reference the secp256k1 from bc group (lipsecp256k1-schnorrsig, to pull in the latest changes would be nice) and libwally-embedded can reference libwally-core from this group. We can take this approach, but somebody with sufficient rights has to fork libwally-core into bc group. Let me know.

[ChristopherA]

@gorazdko, @ksedgwic:

Ok, I have created https://github.com/BlockchainCommons/libwally-core-embedded however, but I'd really like to see you try to get these changes upstreamed into the upstream LibWally as it is under active development and could require a lot of admin to keep updated. As long as they are active and doing great work, I'd prefer not to lock things here.

A harder problem is secp256k1 as I've already forked https://github.com/bitcoin-core/secp256k1 here into https://github.com/BlockstreamCommons/secp256k1-schnorrsig. I'll puzzle through that in a little bit, but it shows the lager problem — I can't seem to merge updates from secp256k1 as the test harness doesn't seem to function anymore. I'd just delete and start over except I've got some issues there about SchnorrSig I'd like to preserve. Will puzzle later.

-- Christopher Allen

[gorazdko]

Ok, I have created https://github.com/BlockchainCommons/libwally-core-embedded however, but I'd really like to see you try to get these changes upstreamed into the upstream LibWally as it is under active development and could require a lot of admin to keep updated. As long as they are active and doing great work, I'd prefer not to lock things here.

I don't think I understand this. We can't work on a libwally-core fork and get changes upstreamed. Libwally-core fork has to be inlcuded as a submodule into libwally-core-embedded.

The approach in my last post is better if we are going to work with our own versions of libwally-core and secp256k1 and/or we don't want arduino wrappers to be generated by bc-lethekit. I now think we should go with #49 and update the approach once we see what bc-seedtool-cli does.

@ksedgwic what do you think?

[ChristopherA]

Did I not clone the correct library?

[gorazdko]

I "deleted" my last two posts because they are confusing.

In #49 I documented libwally as an external dependency 929d903. We can reference instead this fork you just did, but it should be named normally as libwally-core or bc-libwally-core, but not libwally-core-embedded.