vault713 / grinbox Goto Github PK

View Code? Open in Web Editor NEW

49.0 49.0 34.0 182 KB

Relay service for interactive transaction building for Grin / Mimblewimble

Home Page: http://grinbox.io

License: Apache License 2.0

HTML 5.90% Rust 92.90% Dockerfile 1.08% Shell 0.12%

grin grinbox mimblewimble

grinbox's People

Contributors

Stargazers

Watchers

Forkers

gitter-badger stjordanis lehnberg cgilliard gistonionwei wangke0809 mwcproject gottstech allchain jackzhp kepler-network epiccash davidtavarez iq-scm

grinbox's Issues

add message ttl

currently slate message ttl is 24h for all slates. it is desirable to be able to specify an optional custom slate ttl as part of PostSlate message, as long as it is < 24h (which is the current queue expiration time which should not be changed).

Update grinbox api to replace 'port' reference

As discussed, we should get rid of relay port convention in favour of the more easy to understand address.

The current API uses Grinbox-Port-From and Grinbox-Port-To and needs the following changes:

Update the API to expect Grinbox-Address-From and Grinbox-Address-To instead
Update the README documentation

Enable federated servers to relay all their user communication

As a user connecting to a federated grinbox server, I want all my grinbox communication to be relayed by this server, so that only the federated grinbox server I choose to trust has my IP:

UserA <---> Federated Relay X <--------> Federated Relay Y <---> UserB

can't get grinbox to start

No matter what I set username/password to I always get:

[2019-04-27T06:49:19Z ERROR grinbox::broker::rabbit_broker] broker thread ending!

and process halts.
I have installed a rabbitmq and ensured it's running and has a user name rabbit with password guest. I even println the user name, password, and address and they match what I configured in rabbitmq with the following command:

rabbitmqctl change_password rabbit guest

Any ideas would be appreciated. More detailed failure messages would also be very helpful.

Grinbox charts

As shared at last week's meetup.

Notes: Aug 10 MVP definition call

Meeting details

Friday 10 Aug @ 8:00 UTC
Conference call via https://appear.in/grinbox
Attendance
- @ravidio
- @lehnberg

Agenda

Define scope for Grinbox phases, determine immediate next steps, and actions.

Grinbox purpose

Grinbox facilitates asynchronous Grin transaction building between multiple parties. The protocol through which this is being realised should remain open, secure, and private. It should be decentralised to the degree that is necessary in order to effectively fulfil the other objectives. We envision a future where multiple wallet and payment products and services are built that integrate with the grinbox protocol.

Phases

#	Description	Details	Deliverable
1	Relay service	Server relay service only No client Publish authentication and relay APIs (public/private key based) VPS hosted	Users can manually use the relay to send/receive transaction slates to/from other users. Actual transaction building and broadcasting to blockchain is done through the default grin node and wallet locally.
2	Grinbox client	A simple client accessing the grinbox account/relay and processes slates on behalf of the user. Either as standalone, or through integration into the default grin wallet.	Users can more easily utilize the grinbox relay (without manual steps).
3/4 (tbd)	Grin blockchain support	Grin nodes running through the Grinbox relay service that supports sending and confirming transactions on the user's behalf.	Thin wallet client support.
3/4 (tbd)	Federation	Open the network up to allow for decentralisation and resilience. Allow anyone to host a Grinbox relay server Allow Grinbox relays to communicate between themselves	No single central point of failure for Grinbox.
?	Full decentralisation	Only if there is a strong justification, i.e. in event of domain name seizures or relay servers being shut down. Remove dependency on domain names Remove dependency on central servers Migrate the network to communicate via grinbox clients directly. Similar setup as magnet links for Bittorrent.	Grinbox cannot be shut down without every single client going offline.

Agreed next steps

@ravidio to define and publish APIs
@lehnberg to set up VPS access to ravidio for the initial relay service instance
@ravidio to set up first Grinbox relay

Aim for this to be completed in next week.

Obfuscate grinbox addresses in federation

As a user connected to a federated grinbox relay, I want my true public key to be to be obfuscated as it's passed to other relays, so that other relays cannot associate certain interactions on their servers with my address specifically.

This improves privacy. Suppose there are two relays in operation, @relay-x.com and @relay-y.com. Relay X only needs to know to send a transaction to Relay Y, but does not need to know where exactly the transaction should be routed from there, only Relay Y needs to know this.