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.
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?
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,…
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!
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.
