Jason Dreyzehner

Looking great so far! For the BIP39 implementation, maybe a reasonable strategy is including a `bip39.ts` under `src/lib/key`, and importing the const string `bip39WordListEnglish` from `bip39.english.ts`? (Similar to what we...

Just pushed my initial recommendation, but feel free to experiment with other options 👍

Wow, fantastic work @jimtendo! Thanks for the attention to detail, this looks great. I'm going to dedicate some more time to reviewing it, and I'll pull it in with the...

Thanks again for all your work here @jimtendo! Merged manually in https://github.com/bitauth/libauth/pull/116/commits/8e032c2f9878d6f20cf805be6b21274534622d56. I added a few more functions, expanded the docs, and added a few more tests (including fuzzing/property-based testing)...

Thanks for this PR @mainnet-pat! Sorry to keep you waiting here. I think it makes sense to formalize this sort of format a bit more, maybe calling it (within Libauth)...

@emergent-reasons I agree that trying to pass `Uint8Array`s between JS contexts is needlessly high-friction, it's probably always better to use a hex-encoded string. 👍 In the JS context, Libauth requires...

> @bitjson would you be open to a tree-traversing function to go along with this also? Certainly! As long as it has full test coverage (so we can maintain it...

I'm not sure what you mean here, could you provide more detail? Closing for now, but we can re-open if needed.

Latest spitball for v5 TXs (given [Limits](https://github.com/bitjson/bch-vm-limits)/[BigInt](https://github.com/bitjson/bch-bigint) work): - Both fractional satoshis and fractional cashtokens could be represented by two `CompactUint`s - first is whole units, second is a numerator...

Adding to spitball ([revisiting byte saving ideas from here](https://bitcoincashresearch.org/t/supporting-input-aggregation-musig-using-transaction-introspection/350)): - Allow non-push opcodes in unlocking bytecode: this would create a malleability concern in v1 and v2 transactions, but since v5...