Unlike with traditional cryptocurrencies, Grin requires users to connect to each other with their wallet software in order to complete a transaction. This is not always convenient, but fortunately, Grinbox to the rescue.
Grinbox is a transaction protocol that utilizes relay servers to build and broadcast valid Grin transactions in a secure and scaleable way, without compromising on privacy.
- 100% free and open source.
- An address for your grin wallet.
- End to end encryption.
- Asynchronous messaging.
- Transaction proofs.
- Federation supported.
Learn more at https://grinbox.io, or watch the short video below.
What’s up bud?!?! Nice to put a face to the name. I didn’t know you did youtube videos! I’ll check out your channel.
I think it’s funny that they made a realy great tool to make sending/receiving grin easier, but only for use with a wallet that requires command line inputs for installation. I use a mac and sometimes I eat Elmer’s Glue, can I still use wallet713?
It will be need for mobile wallets
Today mobile are behind Nat, Double Nat, Carrier Nats…
Grinbox is absolutely fantastic. It allows you to use addresses like in every other crypto, making onboarding much more convenient.
I wish other wallets would have it so that each didn’t have different address types. Makes using exchanges a pain.
Yeah, would be nice if they come up with a specification so interoperation between other wallets would work out of the box
Grinbox is in fact an open protocol. Wallet713 implemented it, and every other wallet out there is free to do the same.
There’s massive difference between a specification everyone agrees upon and collaborates on and a implementation of some massaging architecture produced in-house.
I’m btw very ignorant regarding grinbox and hedwig v1 relay service, i don’t know if they are the same/interoperational,…
Sorry I missed this earlier.
https://github.com/mimblewimble/grin-rfcs/pull/24 and https://github.com/mimblewimble/grin-rfcs/pull/25 are an attempt to create that very specification. Would love to get some reviewers.
And no, grinbox and hedwig are not the same/interoperational at all. Hedwig routes standard http(s) traffic through a 3rd party making it look (to the sender) as if it’s a standard http(s) transaction. Grinbox is a separate protocol creating bitcoin-like addressing and allowing asynchronous/offline txs, and thus requires wallet support from both sender and receiver.
epic! I think the burden for non-tech ppl to transact grin is reduced tremendously with something like this. Thank you!
Would you mind telling me how this can scale? Glanced over it at and thought this looks like O(n log n)ish (POW for every tx, every node checks if a tx belongs to him from a pool of TXs,…) but I’m again ignorant and have no clue really merci bien!
The online method is direct sender-to-receiver, so it obviously scales fine. So I’ll assume you’re talking about the async method.
PoW can be validated quickly (even quicker thanks to a recent optimization by @hashmap: https://github.com/mimblewimble/grin/pull/3035). The expensive parts are:
- Broadcasting/receiving the slates - If the PoW succeeds in preventing spam, this shouldn’t be much worse than broadcasting/receiving full txs for inclusion in blocks.
- Attempted decryption of slates - This is a relatively fast operation. Just a single EC point multiplication to get the key, and attempt to AES decrypt.
The real burden is placed on the opt-in “relays” which will frequently be polled for txs by nodes coming online, but if we keep expirations short and only use this in situations where the receiver cannot be contacted directly (via tor/online method), then there’s no reason every node couldn’t be a relay. Worst case scenario, we could always add sharding to limit how much data a single relay has to store and serve to peers, but I don’t think that will be necessary.