Hi folks,

Great work you're doing here 👍
Wanted to ask if it would be possible to create a patch version to include the commit bb8c4fa and publish it to crates.io, to allow ethers-rs to update, since there are Ledgers Nano S and Nano X (like mine) that respond with a APDU Response error Code 9000 ([APDU_CODE_NOERROR]) before that commit.

Thanks!

This would accept some public key type, and convert it to a standard P2PKH or P2WPKH ScriptPubkey

Right now, a WitnessTX can be instantiated with a number of witnesses that does not match the length of the vin

https://github.com/summa-tx/bitcoins-rs/blob/master/bitcoins/src/types/witness.rs#L291-L303

There is a lot of copy/paste code between hash256.rs, blake2b256.rs and sha3_256.rs (handshake branch, https://github.com/summa-tx/bitcoins-rs/pull/43/files#diff-4a068cf29f566ee9c1fee95ad83ee1f0). This could likely turn into a macro, it needs part of:
https://github.com/summa-tx/bitcoins-rs/blob/53a107c3002e1a3cb1375b46ef9024cbdc6c6624/core/src/macros.rs#L191

Maybe turn the part of the macro that implements ByteFormat into another macro, impl_32_byte_format, that can be also called on its own as well as inside of mark_32_byte_hash?
https://github.com/summa-tx/bitcoins-rs/blob/53a107c3002e1a3cb1375b46ef9024cbdc6c6624/core/src/macros.rs#L224

I've been building a PoC for using this lib to sign PSBTs and I've run into an issue that I can't resolve.

My PoC is here: https://github.com/thomaseizinger/rust-ledger-poc
You can run the shell script with a ledger plugged in and it should error with:

Error: failed to get signatures from device

Caused by:
    Ledger device: APDU Response error `Code 6985 ([APDU_CODE_CONDITIONS_NOT_SATISFIED] Conditions of use not satisfied)`

Any ideas of what could be the issue?

I've been considering breaking out the Ledger transport lib and its related code to a separate workspace to reduce cognitive load and build times for this repo.

@gakonst, are you still interested in collaborating on this?

read_from has a second argument that is unused in most cases. It only gets used when we're reading a sequence like Vec<T>::read_from(source, 5). Instead, we should drop this method, avoid implementing implement something like T::read_sequence(5)

We should consider splitting up ByteFormat into an Encode and a Decode trait. Maybe consider re-using nomic's work. https://docs.rs/ed/0.1.5/ed/

• Outpoint
• TxIn
• TxOut
• WitnessStackItem
• InputWitness
• Tx

oh my goodness we've done so much refactoring.

add sha256, hash256, rmd160, and hash160 utils to core

differentiate the Hash256Digest type to be hash-function specific (newtype-wrapped [u8;32])

This means that prefix vecs can be removed as a concept 🎉

https://twitter.com/_prestwich/status/1246159783490510848

Syntacitcally invalid transactions can be constructed. E.g. those with 0 inputs. This should be disabled

Should we update the transaction trait to new -> Result<Self, Self::Error> ?

• Digest for Hashers from https://docs.rs/rust-crypto/0.2.36/crypto/digest/trait.Digest.html
• Signer/Verifier from https://docs.rs/signature/1.2.2/signature/

Address encoders assume things go to Script. Instead, we should make a basic trait and have it be an associated type of the encoder

sketch:

pub trait APDUTransport {
    type Result;
    fn exchange (&self, packet: APDUCommand) -> Self::Result;
}

pub trait TransportNew: Sized {
    type Error: Debug;
    fn init() -> Result<Self, Self::Error>;
}

struct TransportSync{...}
struct TransportAsync{...}

BTC app protocol varies based on app version. We should generalize the signing functionality to query device version and select an appropriate protocol

Pretty much everything else about a TX is genericized to allow easy implementation of other networks. But the Builder still has Outpoint hardcoded into its type signatures. Should figure out an elegant way of genericizing this into a UTXO ID kinda thing that is instantiated as an Outpoint

i2le
i2le_padded
i2le_script
le2i
be2i
i2be
i2be_padded
change_endianness
rmd160
sha256
hash160
hash256

indexing beyond length will panic. Should try to remove indexes wherever possible

• TXID, WTXID
• bitcoins/src/enc/bases - generalize bech32 and have network specific wrappers in each network crate

Bitcoins has undergone significant updates since I made this. Plus I've learned a bunch about wasm wrapping things. It would be relatively easy to restart.

• disable CI in build.sh
• redesign macros
• redo all exports
• fix the docs

This is not a blocker for initial release, I think

Currently blocked by bug in wasm-pack

See:
rustwasm/wasm-pack#698

Secrets such as Private Keys must remain in memory for as little as possible to minimize chances of extraction via side-channels and similar methods. They must also never be logged.

All such types in the repo should implement Zeroize, so that they're written with 0's once they're dropped (or manually zeroized), and they should be wrapped with Secret so that they're not accidentally logged. The internal type can be accessed via ExposeSecret.

These traits will often want to communicate with the outside world

currently preludes are macros and other things that should be available within the module/crate

Instead, make preludes common exports and useful things for consumers of the library.

I am using nearly all of the macros defined in bitcoins/src/macros.rs in the Handshake crate

https://github.com/summa-tx/riemann-ledger

Parity is basically unmaintained at this point.

https://crates.io/crates/k256

Write/find a PSBT encoder/decoder.
Instantiate builder and transaction objects from PSBT.
Serialize builder and transaction objects to PSBT