Grin Bulletin Board: Discussing four options and select one for bounty

21

Circling back on this proposal. If anyone has ideas of where we might be able to post this bounty for exposure or better yet, knows someone that might be qualified, please let the community know.

As someone who believes the usability is still a barrier to adoption, I think the sooner we can realize this (in whatever form it takes), would be like super cool.

1 Like
22

Before the bounty is posted we should know what the claimer should implement - afaik it has not been decided yet

2 Likes
23

Well the bounty would depend on the developer, but I think the only one that is currently ready would be the Beam-esque SBBS. What posting for exposure also allows is for outside talent to submit alternatives

1 Like
24

i honestly don’t like sbbs (or in general any that can be attacked - iirc it can be spammed)

2 Likes
25

Can we also nominate slatestore for the bounty?

4 Likes
26

The drawback to this approach is privacy loss. The consequences of which would be amplified if such a service was used prolifically.

However… I think this could be combined with coinswap to provide the best of both worlds. Privacy AND “non-interactive” (from Alice or Bob’s perspective) TX completion. That would kill two birds with one simple stone

3 Likes
27

If spam attack problems simple solution is The CAPCHA

1 Like
28

My idea for this bounty to use decentralised GrinMixers with fee

1 Like
29

Maybe the SBBS system is the easiest and most feasible way to keep the core simple and only need the support of the wallet

1 Like
30

Nobody that is championing a solution has interacted with my point here: Grin Bulletin Board: Discussing three options and select one for bounty - #13 by trab

or the comment below it about how Grinbox could have been great if grin just had an invoice functionality

2 Likes
31

Screenshot_20221014-163108
Screenshot_20221014-163108864×436 82.2 KB

I was wondering if there was an active proposal for the invoicing already designed? Also maybe a few months ago I reached out to @lehnberg on telegram, two “checkmarks” but no reply :confused:

2 Likes
32

On the grin wishlist (wow this doc is weirdly hard to find) see number 6 in the important list: Invoice payment proofs ¡ Issue #10 ¡ stakervali/grin-wishlist ¡ GitHub

Looks like the development is tracked here: https://github.com/mimblewimble/grin-pm/issues/385#issuecomment-771676600

If this was possible, it would open up the ability to pay for services with Grin

3 Likes
33

On the grin wishlist (wow this doc is weirdly hard to find)

Wishlist on GrinCC site.

2 Likes
34

Having 4 systems to chose from is hard,… so lets add another to make things even more confusing:upside_down_face: .

I want to share a very loosely designed transaction “Buddy System” :people_hugging: . The idea is that you can have a buddy who handles the transaction for you, functioning as a Relay/Intermediary. This relay requires your signature to finish the transaction and get his reward, which is a modest relay fee. The proposed solution has some advantages, such as being an Aggregation of a regular RSR and SRS transactions, not requiring side chains, merged mining or much code. The system also has some downsides, such as the Relay knowing who sends to who, although an extra tor address could provide extra anonymity there. Also this idea requires some transaction information wrapper around a slatepack address to define this alternative transaction method.
To be very clear:
1) I am not a cryptographer
2) I am not advocating this solution should ever see the light of day

I designed/explored this solution for fun since I believe there is a wide range of use cases and possibilities using interactive crypto that are worth it to be further explored. Grin is amazing in that transactions can be aggregated at so many levels, this is just one example of an application where aggregation can be interesting.,

Grin is working as it is and I am not convinced any formal transaction relay system or Bulletin Board System is needed. Perhaps integration with Nostr or Signal on the individual wallet level would be more important as proposed by @trab. This does not however mean we should not continue exploring solutions like the Buddy System presented here. I think there are uses cases for using cut-through for aggregating transaction before they hit the chain. Sharing ideas like this one might helps keep everyone open-minded and creative and lead to new cool crypto solutions one day… that is why I share this concept idea.
If you are interested, give the transaction “Buddy System” a read :grin: .
Grin for muggles and aspiring wizards [github]

1 Like
35

In what situation would Alice want to make a payment to Bob without having any means of communication with Bob?
I.e. no email/keybase/telegram/github/facebook/whatsapp/reddit/grin forum that could be used to send slatepacks back and forth?

How is Alice communicating with Bob, and how is Bob communicating with Charlie?

1 Like
36

TLDR; All communication happens over tor using slatepack addresses like normal.

The idea is to contact Bob over tor (slatepack address), with a request to setup a relay transaction for Charlie. So in short, there is no new methods of interaction, just different information send over tor. If Alice finds Charlie cannot be reached over tor, he will contact his buddy Bob over tor.
The same holds for the communication between Bob and Charlie, simple communication over tor. Charlie can use his normal slatepack/tor address. Some arguments could be made for using a second tor address for extra anonymity but for now lets assume there is only a single transaction buddy and everyone uses their normal slatepack addresses. Bob’s only role is to be online and serve as a backup to be contacted when Alice finds that Charlie is offline. Bob serves as a buffer for the transaction and as reward earn his relay fee which is paid by Charlie.

What this proposal would require:

  1. An extra wrapper around the slatepack address for Charlie to specify in order the ways Charlie prefers to receive transactions. If method 1 fails (Charlies slatepack address), try method 2 (transaction buddy slatepack addres). The wrapper would specify the method (transaction buddy) and the slatepack address of this buddy for Alice to contact to request the relay transaction. The wrapper would for the method “relay buddy” not only contain the buddies tor address but also Charlies PubKey to be uses by Alice to construct the output for Charlie.
  2. A normal call to the wallet to initiate a RSR transaction with the addition of one relay output by Bob.
  3. A new type of call to check with a transaction buddy if there are any pending transactions.
  4. A normal SRS transaction send by Bob to Charlie when he comes online, to sign the SRS transaction with as only change that Charlie creates a new output so cut-through can be applied to replace the output that Alice constructed with the known PubKey.

Edit: I suddenly realize a major downside of this proposal. Only Alice should know this particular PubKey of Charlie, otherwise Bob or anyone who knows the PubKey could brute force try values to find the value in the output send to Charlie. Even if the output never appears on chain, it does mean Charlie must trust Bob or share the PubKey in private to Alice beforehand.

1 Like
37

Another question: if Alice can communicate with Bob, and Bob with Charlie, why does Bob have to do any transacting? Can’t he just relay Alice’s slatepack to Bob once Bob comes online, and similarly relay Charlie’s response slatepack back to Alice once Alice comes back online?

1 Like
38

The main advantage is that Alice does not need to stay online, she creates the transaction with Bob, Signs it ands she can go offline and forget about the transaction. In fact, she does not care the transaction is a relay transaction since here wallet switches automatically from the direct transaction to the relay transaction. To her the user experience is similar to a 1 step interactive transaction where you can Send and go offline.

The whole thing should be automated via tor, Bob does not need to give any manual confirmation, he just likes to earn transfer fees similar to a lightening node. Bob’s wallet handles the the rest of the transaction with Charlie. When Charlie comes online, he automatically checks with his buddy if there are any pending transactions. If there are, the transactions are presented to him in his wallet where he can chose to accept the transaction or reject it. Only if he accepts the transaction by Signing, it is send back to Bob for completion.

I think the Buddy System would be especially interesting for mobile wallets which cannot be online all the time but which can check in regularly.

1 Like
39

She doesn’t have to stay online when using
email/keybase/messenger/telegram/github/facebook/whatsapp/reddit/grin forum either. All these services are already available to relay messages between users that are only occasionally online. And they don’t charge a fee.

And in many cases they are the medium in which Alice and Bob agreed on a need for payment in the first place?!

2 Likes
40

Indeed, that is also why I clearly state

Actually I am not convinced we even need any Bulletin Board system at al. But that does not mean we should stop exploring options.

Still I thought it was fun enough to share the idea since the “Buddy System” has as main advantage that it could make transaction one step interactive (send and forget) while using a normal RSR and SRS transactions under the hood. But the whole problem with anyone who knows Charlies PubKey being able to deduce the value is a really big bummer/disadvantage and makes it clear that it is at least in its current form not worth the extra complexity for wallets.

1 Like