bitboxswiss / dbb-app Goto Github PK

• sent transaction to dbb
• observe entry on history tab
• switch to send tab, observe amount to receive shown as available balance
• create transaction
• observe message "Insufficient funds"
• switch to history tab, transaction not visible any more

Expectation: History entry should not disappear. Ideally shown as unconfirmed.

macOS Sierra 10.12.5, dbb-app 2.2.1, device 2.1.1

Hi,

Probably as a result of my 144 dpi setup, the receiving addresses do not properly fit in the Qt application window. As a result, the first 3-5 characters of any address are not displayed.

In the past I've reported a few other issues that seem related to my 144 dpi monitor setup. I think most of them can be solved by making the Qt application window slightly bigger. Or even better: resizable!

On my Arch LInux using the latest release:

I enter the new password twice, but clicking the button doesn't do anything. It works when I press enter - so no big problem.

I have two different screens, and the GUI is really ugly on the second screen different:

On the first screen (17 inch 4k):

On the second screen (32-inch 4k) I see that:

I running an Archlinux.

Hi,

i've restored my digital bitbox - everything worked fine. I was using it together with a copay multisig. After restoring the device, the digital bitbox app asks me for the Wallet Invitation Code which i can not find in my copay app as it was only showing once during initial creation of the multisig wallet (in copay). Something i'm missing here?

Thanks
Emin

Unable to unlock device for a 2 of 2 multisig wallet with open payment proposal (from copay mobile wallet). High priority, coins stuck.

Error thrown appears to be

JSON integer out of range

Process: dbb-app [5646]
Path: /Volumes/VOLUME/*/DigitalBitbox 2.app/Contents/MacOS/dbb-app
Identifier: com.shiftdevices.digitalbitboxapp
Version: 2.1.0 (2.1.0)
Code Type: X86-64 (Native)
Parent Process: ??? [1]
Responsible: dbb-app [5646]
User ID: 501

Date/Time: 2017-03-09 11:26:57.335 -0500
OS Version: Mac OS X 10.12.4 (16E183b)
Report Version: 12
Anonymous UUID: ***

Sleep/Wake UUID: ***

Time Awake Since Boot: 61000 seconds
Time Since Wake: 2900 seconds

System Integrity Protection: enabled

Notes: Translocated Process

Crashed Thread: 0 Dispatch queue: com.apple.main-thread

Exception Type: EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Exception Note: EXC_CORPSE_NOTIFY

Application Specific Information:
abort() called
terminating with uncaught exception of type std::runtime_error: JSON integer out of range

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 libsystem_kernel.dylib 0x00007fffb3111d42 __pthread_kill + 10
1 libsystem_pthread.dylib 0x00007fffb31ff787 pthread_kill + 90
2 libsystem_c.dylib 0x00007fffb3077420 abort + 129
3 libc++abi.dylib 0x00007fffb1bcd84a abort_message + 266
4 libc++abi.dylib 0x00007fffb1bf2c37 default_terminate_handler() + 243
5 libobjc.A.dylib 0x00007fffb2700713 _objc_terminate() + 124
6 libc++abi.dylib 0x00007fffb1befd69 std::__terminate(void (*)()) + 8
7 libc++abi.dylib 0x00007fffb1bef9f2 __cxa_rethrow + 99
8 libobjc.A.dylib 0x00007fffb26fe94a objc_exception_rethrow + 40
9 com.apple.CoreFoundation 0x00007fff9d87624b CFRunLoopRunSpecific + 555
10 com.apple.HIToolbox 0x00007fff9cdd7ebc RunCurrentEventLoopInMode + 240
11 com.apple.HIToolbox 0x00007fff9cdd7cf1 ReceiveNextEventCommon + 432
12 com.apple.HIToolbox 0x00007fff9cdd7b26 _BlockUntilNextEventMatchingListInModeWithFilter + 71
13 com.apple.AppKit 0x00007fff9b372e24 _DPSNextEvent + 1120
14 com.apple.AppKit 0x00007fff9baee85e -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 2796
15 com.apple.AppKit 0x00007fff9b3677ab -[NSApplication run] + 926
16 com.shiftdevices.digitalbitboxapp 0x0000000106f2ffc0 QCocoaEventDispatcher::processEvents(QFlagsQEventLoop::ProcessEventsFlag) + 2480
17 com.shiftdevices.digitalbitboxapp 0x000000010777e2ad QEventLoop::exec(QFlagsQEventLoop::ProcessEventsFlag) + 397
18 com.shiftdevices.digitalbitboxapp 0x0000000107781585 QCoreApplication::exec() + 341
19 com.shiftdevices.digitalbitboxapp 0x0000000106d807f4 main + 1236
20 com.shiftdevices.digitalbitboxapp 0x0000000106d7fe14 start + 52

Hello, I know this is not an issue, but rather a request for enhancement, but it has happened to me several times that I get confused with the meaning of the green indicator and the arrows in the history screen of the application. It would be great to follow some already well accepted convention: colouring in red for outgoing payments and adding a balance column (just as Electrum does)

The arrows are meaningless in most of the ocassions (they would be useful if they would point to something, such as an incoming address that we can identify as ours or not at first glance which is not the case)

Thank you. Happy to try a pull request if this is something that makes sense

Hey,
I'm following the depends build instructions and am unable to complete the build because what seems to be a missing patch file

$ make -j4 BASE_CACHE=/absolute/path/to/deps-cache SOURCES_PATH=/absolute/path/to/deps-cache/sources
sha256sum: /absolute/path/to/dbb-app/depends/patches/qt/fix_qt_pkgconfig.patch: No such file or directory
Preprocessing qt...
cp: cannot stat 'fix_qt_pkgconfig.patch': No such file or directory
funcs.mk:242: recipe for target '/absolute/path/to/dbb-app/depends/work/build/x86_64-pc-linux-gnu/qt/5.7.1-175bb550631/.stamp_preprocessed' failed
make: *** [/absolute/path/to/dbb-app/depends/work/build/x86_64-pc-linux-gnu/qt/5.7.1-175bb550631/.stamp_preprocessed] Error 1

The files present in the patches/qt directory are the same ones in the repo. I'm building the master branch on debian testing.

• replace it by the mcu c functions or extract and refactor serval classes from bitcoin-core

A simple bitcoin c library (basic functions like hashing, serialization, base58check, bip32/secp256k, etc.) would be nice.

Right now the signing interface for the dbb-app is very difficult to use due to some intricacies with byte encoding of messages to be signed. It is simply inaccessible to the laymen. It'd be great if there was a convenient wrapper signmessage function that takes a message and an address as input arguments, then output the signature for some bitcoin address.

Trying to build on an AARCH64 box without qt fails while trying to build dbb_app:

  CXX      dbb_app-dbb_app.o
dbb_app.cpp: In function ‘int main(int, char**)’:
dbb_app.cpp:223:5: error: ‘QApplication’ was not declared in this scope
     QApplication app(argc, argv);
     ^

It did detect the absence of qt, and set DBB_ENABLE_QT appropriately, but the build system seems to assume that the dbapp can still be built without qt, which doesn't succeed.

Luckily it did manage to build the cli beforehand.

I just had a mildly confusing experience - it looked like the bitbox was no longer being detected by either dbb-cli or dbb-app.

However it turned out that the application was already running in the background!

Wouldn't know how to do this with hidapi, but it'd be nice to have a different error message when the device is already 'claimed'.

When creating wallets with large length passwords e.g. 70+ with both alphanumeric and symbol-based characters, there appears to be a very serious issue in that passwords are not valid. With various permutations, I get the attached message JSON parse error. I haven't had time to figure exact lengths where issue starts but I do get consistent errors at 100+ characters.

Thankfully, no funds were lost but it does appear that there are some restrictions concerning password length and/or character types that are not validated upon creating the wallet and only appear when trying to log back into the wallet, putting at risk the users funds.

OS: OSX 10.12.6

The address should be 1FiroDvTrXmU8P8KpPqEVTo5byaVkg9X9o

Running the latest release (not master).

BBC cash and freeteam will be joining together too try to get to where your going first

Use case: User has a wallet they would like to empty before creating a new wallet on the device. The only viable approach to send all funds in a single transaction is to over-estimate the fee, cancel the resulting transaction and viewing the fee suggested, then manually calculating a send amount. This is prone to errors and might make it difficult to clean out a wallet with change in it.

UPDATE: This issue does not appear when downloading through curl or firefox, only Chrome.
I suspect it has to do with the webserver's configured MIME types.
The server's response indicates Content-Type: application/octet-stream and Content-Encoding: gzip, so I think Chrome may be unzipping the file automatically (thinking it was gzipped by the webserver) resulting in a .tar.gz file name that is actual the unzipped tar file.

Possible fix: I checked another web server that works fine for Chrome + .tar.gz files (see Electrum download link). Server response indicates a different MIME type: Content-Type: application/x-gzip and resulting file is indeed a .tar.gz.

The sha256 checksums listed on https://digitalbitbox.com/start_linux do not match actual files:

1. DigitalBitbox_2.2.2_Linux64.tar.gz

   • Website: 7b9ac7628a2d9b42d44d05580762d267086c4f82b6bc2ff85257db77aab9b057
   • Actual: f5b510a3db38dcb03195b6f4e224feeb64f23648799e88c4f2ada45830d8ee22

2. DigitalBitbox_2.2.2_Linux32.tar.gz

   • Website: 7f9b096125cd5c546e6f503f82a46c55cf676d090a496540fb1a4cd847e59bcf
   • Actual: 42693e186627af94c1ecefa436346404b7369fbb9eb5cae4ddc6f1ef945e3642

I'm not good at interpreting or debugging udev rules, but for some reason those given on https://digitalbitbox.com/start_linux don't seem to work. After pasting the rules

SUBSYSTEM=="usb", TAG+="uaccess", TAG+="udev-acl", SYMLINK+="dbb", ATTRS{idVendor}=="03eb", ATTRS{idProduct}=="2402"

into the right directory and rebooting, nothing changes, the user cannot access the device but root can.

What did work for me is the brute-force way that I usually use to give users (in the plugdev group) access to a device:

SUBSYSTEM=="usb", ATTRS{idVendor}=="03eb", ATTRS{idProduct}=="2402", GROUP="plugdev", MODE="0664"

Using the latest dbb-app master.

The error in the pop-up alert is:
"Could not post signatures"
Then it's stuck at the black screen saying "Broadcast Transaction"

The output of the dbb-app (from start until black screen):
http://pastebin.com/tuCjnjv0

Fresh update device, resetted, DBB v0.2.1-v0.2.1, Device version v1.3.2

Hi, can interface be translated? And if can, how?

Libcurl is used also for the Qt part right now.
The reason for this is that we can use most core classes in a non QT cmd tool later.

HTTP Request handling should be refactored and there should be only one C++ class handling the request.
Currently, dbb_gui.cpp (update checker) / libbitpaywalletclient.cpp (copay backend) and soon the ComServer will use curl and do not share the http request code.