multibit-legacy / multibit-hardware Goto Github PK

The AddressN entry in a TX_OUTPUT is required to let the Trezor know that this address is a change address (or at least belongs to the wallet). As a result the Trezor will ignore the sign confirmation since no funds will leave the wallet.

The Trezor display will also accurately reflect what the wallet is showing in terms of funds leaving the wallet.

Reserved for communicating announcements to developers watching this repository.

User @ollekullberg provided the following feedback:

When compiling MBHD i get this warning:

[INFO] Including org.objenesis:objenesis:jar:1.0 in the shaded jar.
[WARNING] protobuf-java-2.5.0.jar, trezor-develop-SNAPSHOT.jar define 90 overlappping classes:
[WARNING] - com.google.protobuf.DescriptorProtos$DescriptorProtoOrBuilder
[WARNING] - com.google.protobuf.DescriptorProtos$FileOptions$OptimizeMode$1
[WARNING] - com.google.protobuf.DescriptorProtos$FieldDescriptorProtoOrBuilder
[WARNING] - com.google.protobuf.DescriptorProtos$FileOptions$Builder
[WARNING] - com.google.protobuf.DescriptorProtos$UninterpretedOption$NamePart$Builder
[WARNING] - com.google.protobuf.DescriptorProtos$FileDescriptorSetOrBuilder
[WARNING] - com.google.protobuf.DescriptorProtos$ServiceOptions$Builder
[WARNING] - com.google.protobuf.DescriptorProtos$FieldOptionsOrBuilder
[WARNING] - com.google.protobuf.DescriptorProtos$MessageOptionsOrBuilder
[WARNING] - com.google.protobuf.DescriptorProtos$SourceCodeInfo$Location$1
[WARNING] - 80 more...

The warning seems to be caused by trezor-develop-SNAPSHOT.jar, and I can see that JAR has com.google.protobuf.DescriptorProtos inside it. This seems very strange, since this class belongs in the protobuf-java-2.5.0.jar. And for me this is even worse since it means that i cannot use getDefaultInstance() (on a ProtoBuf object I have created) because of this conflict.

Why is the DescriptorProtos in the Trezor JAR? Can it be removed/renamed or even excluded in the dependency?

The example I'll be using is the 'TrezorV1PingExample' but others have the same behaviour.
Environment: Trezor v1.4.0, macOS Sierra

Sometimes the ping example works succesfully, other times it rejects one message and gets stuck in a loop afterwards, see the output in this gist:
https://gist.github.com/mrosseel/8065264579fe7418399b02346519d07c

Any idea what could cause this issue?

There is a breaking change in Trezor 1.3.3 firmware - GetPublicKey now issues a PIN challenge

The current maven build does not include Findbugs which is a prerequisite for release.

As usual the first threshold is "Medium" to prevent swamping the project. If "Low" is possible with little additional effort then that should be met as early as possible.

At present the Trezor V1 HID wallet client introduces an immediate read after a write. This causes problems with terminating threads cleanly in higher level applications.

A better approach is to have a continuous monitor thread on the HID read buffer and have writes simply write and nothing more.

The HidService does not directly support a requestPing() which is an API omission.

This is required to allow MultiBit HD to derive the same addresses as the Trezor device without the seed.

TREZOR Firmware 1.3.5 Allows for Multisession Operation

Could you please add support for that so API can be used in parallel with e.g. myTrezor page?

Thank You, Martin

There have been some API changes in Bitcoinj 0.13.2 that are reflected in Alice 0.1.3. These need to be reflected into the code (where necessary) and verified with real devices.

Indirect through https://rawgithub.com to get better artifact resolution.

Remove any references to Google Code repos.

Having a local facility to handle secure seed phrase recovery on a device is a good step forward for privacy and resiliency.

There are small troubles on USB level that makes device init last a bit longer (10-20 sec) in certain situations.

Repeat scenario:

1. Plugin Trezor, run any example requiring PIN.
2. Provide PIN, finish example happily. Keep Trezor plugged in.
3. Run same example, trezor does not ask for PIN (which is ok) but getting device to READY state takes considerably long time.
4. Replug device and try example again. Everything is fast again.

I suspect some problem when finishing communication and exiting services. Calling disconnect() or softDetach() on wallet doesnt help.

For more security, can you change old spongycastle (based on old bouncycastle) to bouncycastle?

• https://www.bouncycastle.org/
• https://www.bouncycastle.org/releasenotes.html
• http://www.bouncycastle.org/latest_releases.html
• https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=bouncy%20castle
• https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=bouncycastle
• https://www.cvedetails.com/vulnerability-list/vendor_id-7637/Bouncycastle.html

It would be useful if the HardwareSystemEvent gave an indication of which Trezor fired the event, specifically:
o The label of the Trezor

Hi, for certain Identity URIs the public key value that is returned by TrezorV1SignIdentityExample and TrezorV1GetPublicKeyForIdentityExample varies. I suspect IdentityUtils.buildAddressN may be reason.

Try:
"ssh://btc_rulez/connect"

Thanks, M.

It would make it easier to redistribute multibit-hardware if each source file contains a license header.

Check https://bugzilla.redhat.com/show_bug.cgi?id=1360292#c6 for details.

The following was received from user BakSAj on Bitcoin Talk:

Hi,

I'm struggling with MB HW API for Trezor device. I'm using examples from the repo below, but I always get TrezorV1HidHardwareWallet - Device not attached.

One idea is that project was not tested with latest Trezor firmware.

I've tried Java7 32, Java7 64, Java8 64. Any ideas? Thank You.

Log fragment after running TrezorV1FeaturesExample.main():
16:10:24.821 [default] [safe-scheduled-monitor-hw-client-0] DEBUG o.m.h.h.t.c.TrezorHardwareWalletClient - Attempting to connect...
16:10:24.821 [default] [safe-scheduled-monitor-hw-client-0] DEBUG o.m.h.h.t.w.v.TrezorV1HidHardwareWallet - Suspect recently detached device. Attempting to locate...
16:10:24.830 [default] [safe-scheduled-monitor-hw-client-0] INFO  o.m.h.h.t.w.v.TrezorV1HidHardwareWallet - Device not attached
16:10:24.831 [default] [safe-scheduled-monitor-hw-client-0] DEBUG o.m.h.h.t.w.v.TrezorV1HidHardwareWallet - Failed to locate. Device must be detached. 

After upgrading to TREZOR firmware 1.4.0, multibit is not able to communicate with the device.

At first, multibit wasn't able to detect the device. It was due to the issue described at: https://www.reddit.com/r/TREZOR/comments/52tcff/mytrezor_not_working_with_new_firmware/d7ncnqs. After applying the fix, the device was detected, but multibit was still unable to talk to the device. The error that is:

Requesting TREZOR Unlock
Failed to communicate with TREZOR device

Firmware version 1.3.6 works as expected on all platforms. Firmware version 1.4.0 works as expected on Mac osx.

Very little troubleshooting has been done so there may be a simple fix. This possibly includes:

• Rebooting the machine
• Looking at the logs for any clues
• Rebuilding with the most recent .proto files.
• Wiping the device and trying again.

We are shipping with this bug in Multibit release 0.4.1 and will get trezor 1.4.0 working in a future release (hopefully within the next 2 weeks).

@jhoenicke Any ideas about other things we should look for?

To support Trezor on OS X we need to update the Java HID API project to use the signal11/hidapi source code. We can:

1. Hope that someone steps up to create "hid4java" and does all the work for us :-)
2. Just compile the OS X parts of hidapi and use the javahidapi code to act as a basis
3. Do the full implementation ourselves and maintain it

At present Option 2 will yield the quickest ROI of time. The usb4java library covers the Windows and Linux cases so we'd only need the specialised HID library for OS X variants.

Regardless of the option, we will still need to implement a custom HidUsbClient for OS X since it would rely on a different native library. Fortunately, much of this new client code could be lifted from the Raspberry Pi if we used javahidapi as the basis.

While not used within the MultiBit HD project, it would be useful addition to continue the support of the API for other projects.

At present an exception is generated if no Trezor is attached in AbstractHardwareWalletState due to the event message not being present.

Third-party consumers of MultiBit Hardware require the advanced use case of the optional BIP44 passphrase support during wallet creation and recovery.

This was accidentally assumed to be deprecated but here's the documentation.

Trezor locks up when attempting to pay to script hash ("multisig") addresses.

Remove code duplication through the use of MultiBit Commons.

Please remove following check as it has no grounds and is making ssh auth challenges (with over 200bytes) impossible. Thanks, M.

//Preconditions.checkArgument(challengeHidden.length <= 64, "'challengeHidden' must be 64 bytes or less");

The softDetach methods are synchronized at the method level and this leads to deadlocks during the close.

To verify correct operation please refer to MultiBit HD #302.

The protobuf definitions have changed between the 1.2.x and 1.3.x firmware in an incompatible manner and need to be updated.

The direction from SatoshiLabs is that we should direct users to use the latest firmware so this fix should include a minimum firmware version check before raising a new DEVICE_NOT_SUPPORTED message.

Please add support for SignIdentity message for Trezor API. Also if you could extend GetPublicKey for ecdsa name. Im building new SSH-Agent Windows application for Trezor, however Im not very good at coding lowlevel API. Thank You.

In Ubuntu, took a fresh clone of multibit-hardware project. Tried to do:

mvn clean compile exec:java -Dexec.mainClass="org.multibit.hd.hardware.examples.trezor.usb.TrezorV1FeaturesExample"

but it returned

[WARNING] Warning: killAfter is now deprecated. Do you need it ? Please comment on MEXEC-6.
[WARNING] 
java.lang.ClassNotFoundException: org.multibit.hd.hardware.examples.trezor.usb.TrezorV1FeaturesExample
    at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
    at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
    at org.codehaus.mojo.exec.ExecJavaMojo$1.run(ExecJavaMojo.java:281)
    at java.lang.Thread.run(Thread.java:745)
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary:
[INFO] 
[INFO] MultiBit HD Hardware .............................. FAILURE [1:05.777s]
[INFO] Core .............................................. SKIPPED
[INFO] Trezor ............................................ SKIPPED
[INFO] Emulators ......................................... SKIPPED
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 1:17.522s
[INFO] Finished at: Wed Nov 26 23:47:02 GMT 2014
[INFO] Final Memory: 10M/25M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.codehaus.mojo:exec-maven-plugin:1.3.2:java (default-cli) on project parent: An exception occured while executing the Java class. org.multibit.hd.hardware.examples.trezor.usb.TrezorV1FeaturesExample -> [Help 1]