@DavidBurkett
- Yes we use a modified BIP32 hasher - see https://github.com/vault713/wallet713/blob/master/src/common/hasher.rs#L74
- Yes, challenge is sent immediately after establishing the websocket connection.
- Challenge was initially used for signing the slate so we wanted to have a shared challenge between all users, however it’s not used like that anymore, and only relevant when subscribing, so indeed we might switch to session based in the future
- No, not at the moment
- JSON is a plaintext
EncryptedMessagehttps://github.com/vault713/wallet713/blob/master/src/common/message.rs#L13, which contains an encrypted payload - At night
@jaspervdm Why use PBKDF2 here? https://github.com/vault713/wallet713/blob/master/src/common/message.rs#L39
A PBKDF is only to help prevent brute forcing, but since there’s no user-entered inputs involved, it’s a waste of computing resources and unnecessarily slow
we're planning on implementing Grinbox, and a question came up.... Instead of using a federated server, why not use IPFS (or other pubsub service) for tx slates ?
Hi @keo glad to hear! Let me know if you need any help, here’s some integration instructions:
https://github.com/vault713/grinbox/blob/master/docs/integration.md
Quick answer to why not IPFS: To keep it performant, simple, and make messages transient. Over time, we’ve the ambition to make the entire system completely decentralized but opted to start with something really basic and straight forward that we knew we could make performant and re-evaluate later.
error[E0658]: imports can only refer to extern crate names passed with
--extern on stable channel (see issue #53130)
@jaspervdm @ravidio @lehnberg I'm releasing Grinbox support in Grin++ tomorrow, but I have a few more quick questions first.
1) Are you aware of any users generating non-standard addresses/versions? Is it better to require the version bytes to be correct, or would a warning be better?
2) Is anyone else hosting a grinbox server yet, or is it enough to only support grinbox.io addresses for now?
3) Any weird situations you can think of that I should be testing? It seems pretty straightforward - it either works or it doesn't. But I have a tendency to oversimplify things when I'm testing.
4) Does wallet713 only generate a single grinbox address per account? I couldn't figure out a way to generate a second, so that's all I was initially planning to support.
1) Are you aware of any users generating non-standard addresses/versions? Is it better to require the version bytes to be correct, or would a warning be better?
2) Is anyone else hosting a grinbox server yet, or is it enough to only support grinbox.io addresses for now?
3) Any weird situations you can think of that I should be testing? It seems pretty straightforward - it either works or it doesn't. But I have a tendency to oversimplify things when I'm testing.
4) Does wallet713 only generate a single grinbox address per account? I couldn't figure out a way to generate a second, so that's all I was initially planning to support.
awesome!
1) not as far as i know, currently wallet713 only supports the default version bytes for floonet and for mainnet. we are considering using specific bytes for other address types such as musig and swaps
2) so far only grinbox.io, but it wouldnt surprise me if more relays will pop up soon. at least i hope they will
3) not that i can think of otomh
4) users can switch to a different address: https://github.com/vault713/wallet713/blob/master/docs/usage.md#switching-address
1) not as far as i know, currently wallet713 only supports the default version bytes for floonet and for mainnet. we are considering using specific bytes for other address types such as musig and swaps
2) so far only grinbox.io, but it wouldnt surprise me if more relays will pop up soon. at least i hope they will
3) not that i can think of otomh
4) users can switch to a different address: https://github.com/vault713/wallet713/blob/master/docs/usage.md#switching-address
@DavidBurkett
Hi there, im trying to build grinbox on ubuntu 18.04 and im getting this error when running cargo build
error: no matching package named `grin_wallet` found
location searched: https://github.com/mimblewimble/grin
required by package `grinboxlib v1.0.1 (/home/daniel/grinbox/grinbox/grinboxlib)`
... which is depended on by `grinbox v0.1.0 (/home/daniel/grinbox/grinbox)`
Careful with deleting stuff if you have non-repository files there.
if so, is a standard way to exchange encrypted message between two parties like some sort of protocol? I am not quite familiar with cryptography ：）
@lehnberg @jaspervdm
I get the secret key from the C++ logic, which if you want to match wallet713 & Grin++, you'll have to also implement in some way. I can help with that when you get to it, but assuming you have the secret key, then you should be able to just start at the connect function:
And then once the user logs in, subscribe to receive slates for their address: https://github.com/GrinPlusPlus/GrinPlusPlusUI/blob/e04d057413a048600152dbbf5eb090b1d1ede7a6/src/main/Grinbox/GrinboxConnection.js#L125
And message encryption starts here: https://github.com/GrinPlusPlus/GrinPlusPlusUI/blob/e04d057413a048600152dbbf5eb090b1d1ede7a6/src/main/Grinbox/GrinboxConnection.js#L13
@jaspervdm run grinbox with "RUST_LOG=DEBUG ./grinbox " , show this error. why?
And it looks like I'm in the wrong "wallet713" chan, sorry.
Seems like nobody answered that question on Bisq forum: https://bisq.community/t/we-need-to-remove-grin/7013/19
The question is: "Is there a online services as well similar to http://xmrchain.net/ 5 ? if arbitrators need to run all full nodes of all the privacy coins it is quite a burden."
That's probably the main reason why Grin hasn't made it back on Bisq.
you can search with kernel excess, output commitment, block hash etc
Might be interesting to have an online proof verifier.