Alex Xiong

I'm running into a similar problem on [`num-bigint`](https://github.com/rust-num/num-bigint) ``` └─○ cargo nono check num-bigint: ❌ - Source code contains an explicit `use std::` statement. --> src/lib.rs:119:4 | 119 |use std::error::Error;...

seconded for overloading for bytes! 🙌 btw, current error message when I try to console.log bytes isn't super helpful: ``` TypeError: Member "log" not found or not visible after argument-dependent...

Yes, you are right. Thanks for catching this @tarcieri, fixed in [835fa55](https://github.com/dalek-cryptography/ed25519-dalek/pull/205/commits/835fa55dfe602be682a3bc8b166fe10d258fd7ba). Now given a `struct Keypair`, user should only have read access, not internal mutability to its fields.

it really isn't our call, maybe maintainers like @isislovecruft and @hdevalence can review then approve?

> KeyPair::from_bytes should probably be removed too. instead of removing it, I added simple validation logic to ensure matching key pair in [fd8c5fb](https://github.com/dalek-cryptography/ed25519-dalek/pull/205/commits/fd8c5fb5aeffb6c389b39dddda890e7a5b4f70f1) @sopium wdyt?

Same feature request here 🙌 , would be great if we can have the tracing gas report like [eth-brownie has](https://eth-brownie.readthedocs.io/en/stable/core-transactions.html?#call-traces). May I ask what's the inherent limitation for not supporting...

> As far as I know, we don't really have any edge-case situations in the library where it becomes unclear whether we should be using a sparse or dense polynomial....

we should define something like `trait AppendOnlyMerkleTree` (or `ForgettableMerkleTree` or whatever, name subject to change), so that the interface of our MT is clear from the outset.

currently, code compiles, but there are two tests failing: ``` ---- circuit::customized::transcript::tests::test_rescue_transcript_append_vk_and_input_circuit stdout ---- thread 'circuit::customized::transcript::tests::test_rescue_transcript_append_vk_and_input_circuit' panicked at 'assertion failed: `(left == right)` left: `Fp384(BigInteger384([15540749464332904421, 18331995328304195891, 13822085341868466267, 7299705786554684320, 13531873085501677006, 96083863222528029]))`,...

> to_field_elements() actually generate 3 field elements where as we originally had 2 in the transcript IIUC no, I know that. thus `Point(fe[0], fe[1])`