Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    jaspervdm
    @jaspervdm
    @DavidBurkett
    1. Yes we use a modified BIP32 hasher - see https://github.com/vault713/wallet713/blob/master/src/common/hasher.rs#L74
    2. Yes, challenge is sent immediately after establishing the websocket connection.
    3. 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
    4. No, not at the moment
    5. JSON is a plaintext EncryptedMessage https://github.com/vault713/wallet713/blob/master/src/common/message.rs#L13, which contains an encrypted payload
    6. At night
    David Burkett
    @DavidBurkett
    Excellent! Thanks @jaspervdm!
    jaspervdm
    @jaspervdm
    np!
    David Burkett
    @DavidBurkett
    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
    Barnabas Debreczeni
    @keo
    Hi Everyone
    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 ?
    lehnberg
    @lehnberg

    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.

    Barnabas Debreczeni
    @keo
    understand - makes sense. Thank you for clarifying.
    Cash2BTC
    @Cash2BTC_twitter
    trying to build grinbox and getting an error ----------- not an extern crate passed with `--extern`
    error[E0658]: imports can only refer to extern crate names passed with --extern on stable channel (see issue #53130)
    David Burkett
    @DavidBurkett
    @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.
    jaspervdm
    @jaspervdm
    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
    @DavidBurkett
    David Burkett
    @DavidBurkett
    Thanks @jaspervdm!!
    lehnberg
    @lehnberg
    @DavidBurkett 🛴
    danielj86
    @danielj86
    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)`
    Leo Wandersleb
    @Giszmo
    grin and grin-wallet are different repositories now. Judging from git experience, how about deleting the folder (grin_wallet) I assume and then running git submodule update --init --recursive?
    Careful with deleting stuff if you have non-repository files there.
    danielj86
    @danielj86
    thanks
    xiaojay
    @xiaojay
    hello, is the encrypt message in this way: 1. use Elliptic Curve Diffie–Hellman key Exchange get a shared secret; 2. using PBKDF2 hash the shared secret 3. use the hashed key and chacha20-ploy1305 do aead encrypt?
    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
    jaspervdm
    @jaspervdm
    Yes those steps sound about right. The key derivation and encryption is taken from the encrypted wallet seed
    David Burkett
    @DavidBurkett
    @xiaojay Don't mind the terrible code, I've cleaned it up a lot locally but haven't pushed yet. Here's a messy example in js though:
    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:
    David Burkett
    @DavidBurkett
    It's not the most clever code, but it's more accurate than reading a document.
    xiaojay
    @xiaojay
    That's great, thank you @DavidBurkett I will check it out definitely :)
    xiaojay
    @xiaojay
    屏幕快照 2019-08-31 16.04.47.png
    @jaspervdm run grinbox with "RUST_LOG=DEBUG ./grinbox " , show this error. why?
    xiaojay
    @xiaojay
    ok, I figured it out, enable srabbitmq_web_stomp plugin first. "sudo rabbitmq-plugins enable rabbitmq_web_stomp"
    François
    @mably
    When sending funds with wallet713, they seem to be stuck in an "awaiting finalization" state on the receiver side. Though the slate is said to be finalized on the sender side. Funds are locked on the sender side. Am I doing something wrong ?
    François
    @mably
    Ok, just reposted the finalized tx and everything seems to be ok now.
    François
    @mably
    Probably related to the "send all available funds" bug.
    And it looks like I'm in the wrong "wallet713" chan, sorry.
    David Burkett
    @DavidBurkett
    @mably grin-wallet (wallet713 is built on this) continues to have issues with posting transactions. I don't know if it's an issue with Dandelion++, or something else, but it's pretty common to need to repost transactions.
    François
    @mably
    Yep, still seems to be the case, I'll remember it for next time.
    David Burkett
    @DavidBurkett
    :thumbsup: I wish I had time to investigate. Maybe someday haha
    François
    @mably
    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.
    jaspervdm
    @jaspervdm
    grinscan has that functionality
    you can search with kernel excess, output commitment, block hash etc
    François
    @mably
    Ok will answer that.
    Might be interesting to have an online proof verifier.