I wanted to open up the topic here to have a point of reference instead of the chat.
We know that interaction is required to construct a rangeproof, to prove the transaction is not negative. But there is no time limit, nor is there any actual requirement for the interaction to happen via the current build in methods on Grin.
But does peers have to interact this way? Cant peers encrypt the messages between them, and interact independently of the Grin construction, via third party software that works with Grin?
There is no address format in Grin, thus we can only send to other peers if those peers are online. It defies the purpose of anonymity as the ip of nodes can be easily indexed.
At the very least an open API/method to allow third parties to create different interactions for transactions would help a lot. Think pastebin/termbin transactions as an example.
Hey @jackrack,
You’re right, it’s possible to build a third party software that could handle Grin transaction (and aggregation).
Currently, you can absolutely take the libwallet/libtx code and create this software. We can imagine that the only interaction with the Grin network would be the broadcasting of the transaction.
Also @Yeastplume is working on exposing several wallet APIs here https://github.com/mimblewimble/grin/pull/1133.
We’ve started to build grinbox.io which is aiming to provide just that - a unique wallet address and an online/offline transport method for “slates” to allow parties to interactively build and complete a transaction without having to expose incoming ports and/or be online and the same time.
Still early days and we’d love to coordinate our efforts and work together to put something useful out there.
Is that planned to be built with or without muli-coin ln tech?
The plan is to support Grin only, but this could potentially be leveraged for any other coin in the future.
Will Grinbox predominantly focus on encrypting the messaging, or is it intended to be its own specialized layer, with addresses as the main way of interaction?
If its open enough, and focuses more on communication rather than a a specific format for sending and receiving, it would give us the option to add more ways of sending Grin.
I would say our focus is definitely on communication. At this point in time, the priority is getting something up and running whilst we’re still on testnet, and evolving the solution as we go.
Note that one advantage of submitting your transactions trustlessly through a more centralized service, like grinbox, is that said service can do cut-through before pushing to the network.
Do we have an up to date visual display showing the current required steps before a transaction can be published? I think I saw something in docs long ago, but unsure if it is still relevant.
Do you mean to build the transaction or really to propagate it on the network?
I believe the visuals were about building the transactions, with the final portion showing that it got pushed to the network. I cant find it any longer as the docs of Grin are all over the place now.
Note that this chart is out of date @jackrack, the way transactions are done now reduces the complexities of the flow in the diagram:
- Sender → Recipient
- Recipient → Sender
- Sender broadcasts transaction to blockchain
You are right, I noticed this.
This also means that recipient actually cant claim anything, since it implies sender is the only one that can “finish” the transaction, right?
Also how are the two transactions distinguished between each other? In one state it waits for recipient, and in another state it waits for sender. If interactions are not time sensitive, they must be recognized by each party in the state they are in, and whom the next peer is to commit to an action.
I keep going back to wanting to build a wallet that allows peers to interact and transact via public places such as pastebin or termbin, as those open up some really interesting ways of sending money.
I believe @lehnberg is working on just that, maybe you can help each other 
Yes, exactly, that’s what Grinbox is meant to do. And from what Yeastplume told us, the wallet API is going to support transaction building via any medium, for example via email, pastebin, or whatever else. We’d love to sync on this and build something together that’s useful for the community!
I am adding the below to this thread or it will be lost in a wall of text from the chat. I thought this was relevant to keep in mind and store here.
@lehnberg
Jul 31 16:16
@yeastplume so what’s discussed here is correct or not? Reverse transaction building
@hashmap one round-trip, i.e. two single trips afaiu.
jaspervdm
@jaspervdm
Jul 31 16:21
3 steps. but it can be done (and currently is done) with 1 HTTP request (and response)
Yeastplume
@yeastplume
Jul 31 16:24
any transaction can be set up in a number of ways with an arbitrary number of participants, and the transaction has to be passed around to all of them somehow. The current model is the shortest path with a sender sending, which I’d think is the most natural way of approaching it… but all sorts of other permutations are possible
Gary Yu
@garyyu
Jul 31 16:26
@yeastplume mimblewimble/grin#1305
lehnberg
@lehnberg
Jul 31 16:27
But to be perfectly clear: the number of steps (3) and times of interaction (2) are identical regardless of who initiates. Right?
Gary Yu
@garyyu
Jul 31 16:28
And mimblewimble/grin#1292 also ready for merge. but I don’t have Windows PC for test, only test on Linux and Mac. @yeastplume
jaspervdm
@jaspervdm
Jul 31 16:29
@lehnberg yes, basically what needs to happen is that all parties need to know the sum of public nonces to calculate the partial signature. and of course they have to let the other parties know what inputs/outputs they want to add to the tx
Yeastplume
@yeastplume
Jul 31 16:31
right, so everyone needs to pass around their nonces to everyone else, then everyone has to sign with their partial sigs, then someone needs to add them all together to create the final sig. So there are 2 rounds+finalisation necessary no matter what happens
Is this under active development? The Github link seems to contain just the static site and mailing list.
There’s a draft implementation in progress but hasn’t gotten that far yet. Feel free to jump in and join the discussion here https://gitter.im/vault713/grinbox. The aim is still to get something up and running on testnet, fully open sourced.
1 Like