vault713 / wallet713 Goto Github PK

switch to floonet

wallet713 configuration will be moved by default to ~/.wallet713//*

As part of this change wallet713 will default to mainnet, and there will be an additional argument (-f, --floonet) to run against floonet.

Wallet get stuck and unlock. Init keeps asking for a password. Ended up deleting wallet config file to init -p pass again.

As a user, I want to be able to restore from the BIP-39 mnemonic phrase, so that I do not have to deal with backing up my .seed file.

As a user, I want to communicate with grinbox via TOR, so that the grinbox server does not receive information about my true IP.

Soon floonet and mainnet will exist in parallel. We want to make sure wallets listening on one network are only able to send and receive to other wallets on the same chain. This can be done by using different version bytes for the grinbox addresses. When sending/receiving, the version bytes should be compared to the one corresponding to the current chain type.

hi, i want to know how to View the history of receive history and send history ,beacuase i send someone 100 grin , and i can confirmed it is successful , but he say he have not accept this amount grin. thanks .

I just received my first tx and several usability issues came up that hopefully are easy fixes:

1. support receive from command line: my first inclination was to try this: ./wallet713 receive --file ./tx-e42b6a54-466b-4fe4-ac46-c2f0087c1ef4 but the wallet only takes flags related to init and unlock. It would be great if I could receive in one command non-interactively, ideally with support for password unlocking
2. Since I have to receive inside the app interactively, please support file name completion. Having to type or paste the names of the tx files is very cumbersome and error prone
3. No output is currently provided on successfully receive. I ran the command and had to exit the wallet and then ls just to see if it worked. It would be nice to see something like:

"./tx-e42b6a54-466b-4fe4-ac46-c2f0087c1ef4" recieved.
"./tx-e42b6a54-466b-4fe4-ac46-c2f0087c1ef4.response" created succesfully.

Hopefully these are helpful suggestions and will lead toward wallet713 becoming a first class experience. Thanks!

accounts command to list existing accounts. account create <name> to create a new account. account switch <name> with optional passphrase to switch to an existing account.

ideally with asynch support as well

As a user, I keep pressing up button on my keyboard expecting the previous wallet commands to be remembered. It would be nice if we would store in memory previous w713 commands, emulate standard shell behaviour.

Note: Not applicable to unlock or restore or init.

• init should always request a password (but can still be empty)
• on start, prompt for password
• unlock should prompt for password

a faucet that works using grinbox

Process panics if api_secret is not found in .grin dir when running for the first time. Instead it should initialize a config file with an empty api_secret and issue a warning.

I downloaded the binary release, on Ubuntu 18.04 server, and on running ./wallet713 I got this error:

./wallet713: error while loading shared libraries: libssl.so.1.0.0: cannot open shared object file: No such file or directory

As a user, I want the slates I send and receive through grinbox to be end-to-end encrypted, so that only the parties participating in the transaction are aware of its contents.

Delete wallet. Generate multiple wallets.

Used info command twice in git checkout of wallet from two days ago. First time it printed some balance as Awaiting confirmation (< 10) at height 9815 and second time it printed the same thing but at height 9858. Isn't the transfer supposed to have confirmed already or am I misunderstanding something?

From ./grin wallet send to wallet713 https://grinbox.io/walletaddress

As a user, I would like to be able to send file-based transactions, so that I can easily send funds between myself and the regular wallet.

Proposed commands:

• send --file <path>: Equivalent of grin wallet send -m file -d <path>
• receive --file <path>: Equivalent of grin wallet receive -i <path>
• finalize --file <path>: Equivalent of grin wallet finalize -i <path>

Would be great if @jaspervdm (and others working on this) could use an OpenPGP key to sign git commits and releases. This way we can nearly eliminate the need to trust GitHub.com and make it much harder for a third-party attacker to inject malicious code undetected just by getting access to the GitHub account.

I'd be happy to advise / help answer any questions you might have.

PS: Very excited about this project and the potential of x-chain atomic swaps, thanks!

wallet_dir to be taken relative to the location of the config file, unless it is an absolute path.
should work the same way also when loading with local config.

Related forum thread

Add support for the reversed flow of send command: a Payee/Receiver uses the invoice command to create a slate to receive a designated amount and passes this to the Payer/Sender that then processes and returns the slate to Payee who then finalises and broadcasts the transaction.

Useful in online merchant flows or for "requesting payments" of certain amounts.

As title, after I send a transaction through

send --to @contact

and I saw the transaction is not confirmed using info and the amount sent is being locked.

Repost the transaction using, e.g. repost -i 3 would output ERROR: Client Callback Error: Posting transaction to node

In git clone from few h ago, there doesn't seem to be any other way to see my (grinbox) address except to restart. Commands that sound like they would be helpful in this case don't show my address: account, accounts, info, contacts.

In git clone from a few h ago, adding --help to any command always replies with ERROR: cmd as first line:

wallet713> accounts

____ Wallet Accounts ____

 Name    | Parent BIP-32 Derivation Path 
---------+-------------------------------
 default | m/0/0 

wallet713> accounts --help
ERROR: accounts 
lists available accounts

USAGE:
    accounts

FLAGS:
    -h, --help       Prints help information
    -V, --version    Prints version information

also help command itself should support --help since that's listed:

wallet713> help
ERROR:  

USAGE:
     [SUBCOMMAND]

FLAGS:
    -h, --help       Prints help information
...
wallet713> help --help
ERROR: error: The subcommand '--help' wasn't recognized

USAGE:
         help <subcommands>...

For more information try --help

Add the option to send to a HTTPS wallet listener

wallet713> check
checking and repairing... please wait as this could take a few minutes to complete.
thread 'main' panicked at 'called Option::unwrap() on a None value', libcore/option.rs:355:21
note: Run with RUST_BACKTRACE=1 for a backtrace.

restore command has the same error message.

how to resolve?

Symptoms

• Grinbox listener stops randomly and spontaneously without any error log (as shown below)
• Before it stops, it usually runs fine for a few hours
• Observed this issue multiple times on two different machines, both are AWS t2.mirco instances with fully synced grin node

Log example

wallet713> listen
starting grinbox listener...
listener started for [***]
(after a few hours)
listener [***] stopped
wallet713> 

Suggestions & Questions

• Is there a way to increase logging level?
• Is there a way to run wallet713 as a service (vs REPL)?

https://travis-ci.org/

optional -g, --message param to send command to include a message with the tx.

to reproduce try to run with --floonet arg and then do config --generate-keys

When performing a command that errors out, it is not available in the command buffer.

Wallet713 to direct slates to different grinbox instances based on the domain part of the grinbox address. i.e. send 1 --to [email protected]. By default client would use the grinbox port 13420, however the port could be further specified in the address as well: [email protected]:5555

 Compiling untrusted v0.6.2
error: Edition 2018 is unstable and only available for nightly builds of rustc.

error: Could not compile `zeroize`.
warning: build failed, waiting for other jobs to finish...
error: build failed

what he doesn't like?

Background

There are some mining pools only offer to withdraw grin with HTTP IP rather than Grinbox backed hash address.

Propose feature

As a Wallet713 user, I'd like to receive Grin with HTTP IP option.

receive command can be invoked and passed an input file (-i, --input). it will read a sender-initiated slate from the file, receive it to the wallet, and produce the corresponding .response file.

As part of the send command using Grinbox, a time to live ttl should be defined for when a transaction would expire if it has not yet been finalised. This should automatically cancel the transaction and free up the locked outputs.

Clear the screen. It'd be nice to be able to clear the screen from private/sensitive information.

A lot of sites want to reuse grinbox addresses, but this potentially leaks a lot of information to the server. It'd be better if you used stealth addresses. So:

• Addresses would be A | B, with A and B being pubkeys.
• The sender would calculate a one-time public key and R using the address and random data, and would use this one-time public key as the recipient's pubkey is used now.
• The sender would upload R, the usual slate data, and their own pubkey to the server. If you're not already, the sender should always generate a new-per-transaction pubkey at this step - there's no reason not to.
• The recipient would download all transactions from the server in the time period that they're interested in and scan each of them until they find one that they can get the private key for.

As a bandwidth optimization, you could generate a "key ID" as hash(days_since_epoch | address) (so it changes every day), and the server would require that you provide/subscribe-to the first few bits of this key ID in order to filter out a large percentage of the keys.

Since you're allowing for centralization anyway, there might be a more clever solution than just using stealth addresses, but I wasn't able to immediately think of one.

always use ssl when connecting to grinbox, on the default 443 port.

• Allow users to optionally set a password.
• This is then required each time wallet is launched.
• Option to also set a "lock time" after a period of inactivity (configurable in minutes) that requires the wallet to be unlocked before it can be used again. During lock time, the wallet still listens (if listeners are active) and processes slates as usual - it's just the interface that's locked.
• Ability to remove password. Requires current password.
• Ability to change password. Requires current password.

As a team paying for the hosting of grinbox servers, we need grinbox to reasonably rate limit usage from unique IPs, so that companies do not take the piss and use us as infrastructure they ought to be hosting themselves.

from a user:

wallet713> listen --keybase starting keybase listener... 
wallet713> thread '<unnamed>' panicked at 'No output: Os { code: 2, kind: NotFound, message: "No such file or directory" }', libcore/result.rs:1009:5 note: Run with `RUST_BACKTRACE=1` for a backtrace.

what's that?
ravidio
10:33 AM
must be keybase app missing or something like that.
should be more graceful for sure.

Development of crate put on hold temporarily

Based on @jaspervdm's comment we should make sure incoming slates belong to address on the correct chain based on the address version.

• Passing passphrase directly to wallet713 via -p <passphrase> involves typing it (and seeing it) in the terminal
• Explicit unlock once in wallet713 involves typing and seeing the passphrase

It would be good to mask the passphrase when entering it.

• Allow -p to be passed in without a passphrase and then prompt the user for the password and mask it.
• Allow unlock without a passphrase and then prompt the user for the passphrase and mask it.

Or am I missing something and this is already possible?

any ideas?

error: failed to run custom build command for croaring-sys v0.3.7 process didn't exit successfully:/home/rick/Schreibtisch/wallet713/target/release/build/croaring-sys-d68cb3fa2ec6ec43/build-script-build` (exit code: 101)
--- stdout
TARGET = Some("x86_64-unknown-linux-gnu")
OPT_LEVEL = Some("3")
HOST = Some("x86_64-unknown-linux-gnu")
CC_x86_64-unknown-linux-gnu = None
CC_x86_64_unknown_linux_gnu = None
HOST_CC = None
CC = None
CFLAGS_x86_64-unknown-linux-gnu = None
CFLAGS_x86_64_unknown_linux_gnu = None
HOST_CFLAGS = None
CFLAGS = None
DEBUG = Some("false")
running: "cc" "-O3" "-ffunction-sections" "-fdata-sections" "-fPIC" "-m64" "-Wall" "-Wextra" "-std=c11" "-march=native" "-O3" "-o" "/home/rick/Schreibtisch/wallet713/target/release/build/croaring-sys-13974c0d36bbcb4f/out/CRoaring/roaring.o" "-c" "CRoaring/roaring.c"
exit code: 0
AR_x86_64-unknown-linux-gnu = None
AR_x86_64_unknown_linux_gnu = None
HOST_AR = None
AR = None
running: "ar" "crs" "/home/rick/Schreibtisch/wallet713/target/release/build/croaring-sys-13974c0d36bbcb4f/out/libroaring.a" "/home/rick/Schreibtisch/wallet713/target/release/build/croaring-sys-13974c0d36bbcb4f/out/CRoaring/roaring.o"
exit code: 0
cargo:rustc-link-lib=static=roaring
cargo:rustc-link-search=native=/home/rick/Schreibtisch/wallet713/target/release/build/croaring-sys-13974c0d36bbcb4f/out

--- stderr
CRoaring/roaring.h:37:10: fatal error: 'stdbool.h' file not found
CRoaring/roaring.h:37:10: fatal error: 'stdbool.h' file not found, err: true
thread 'main' panicked at 'Unable to generate bindings: ()', libcore/result.rs:1009:5
note: Run with RUST_BACKTRACE=1 for a backtrace.

warning: build failed, waiting for other jobs to finish...
error: build failed `

As an inexperienced user, I'd like to download and install a pre-compiled binary, so that I don't have to go through the process of compiling my own.

Related comment: mimblewimble/grin#2363 (comment)

Would also be good if we could sign these binaries.