FutureMinds 6: Community Generosity

General
1

This topic comes from @7veter1, who was selected for this topic from the FutureMinds5 thread. 7veter1 writes:

I’m no miner, and as a novice in the cryptocurrency field, I do not trade on the crypto exchange. Still, visiting related sites and faucets has brought me some number of coins in various cryptocurrencies — except for PPC as there seems to be no related PPC faucets (therefore, my PPC balance remains the same for some years). That’s why the only reasons for me to visit Peercoin.net so far is checking for wallet updates and looking for help in case I’ve got any troubles.

From my point of view, the thing that could encourage users to visit Peercoin.net more often is receiving a portion of PPC for each entrance to the site or staying on-line for a certain amount of time. Ideally, with the possibility of withdrawing the coins to users’ wallets. I think that could increase the number of users visiting the site as well as its traffic.

Cryptocurrency has a broad history of being a movement built off generosity and mutual exploration of the value of a digital currency. Faucets and tipping and promises of great returns and rags to riches have people flocking to scams and legitimate fledgling projects alike. A generous crypto community can be a net positive, as flow of money aids in creating on-ramps and off-ramps for users. It can also allow new would-be community members a chance to try out the mechanism of the blockchain first-hand.

I want to expand this topic to include all concepts of community generosity, from Foundation donations to the tipbot on Discord. I want to know people’s thoughts on the generosity of Peercoin’s community and how we might collectively work with it better.
Are there more initiatives with rewards that might be beneficial and easy to host?
Are there ways we can increase community generosity, or at least passing coin back and forth, even if it’s off-chain like in a tipbot?
What is the relationship between generosity and market liquidity/volume?
Would making donations or ‘pay for commit’ concepts more granular using the recent ROAST upgrades be something people would use?

4 Likes
2

I wonder what type of new community members this generosity would attract? Sure we could get some genuine new members that come for the giveaway and end up sticking around long term but I would say this could be a very small percentage. Will it be worth it or not? How much would we need to give away to each new ‘discord’ member. Or how much could we give to each new person that downloads a Flutter wallet? 1 PPC? Or 10 PPC? I’m not very familiar with what is attractive because I’ve never searched around for free giveaways. In this case you were offering a chance to win 100 PPC and @Nagalim attracted one new member to the forum. Which is great! I wonder if it would have had the same result for 10 PPC? We could try more offers in the forum and test. IMO, a giveaway for the Flutter wallet download could work well. I think the most attractive offer would be that each new Flutter wallet downloaded, before a certain date, would have the chance to win a large amount of PPC. Say 500 PPC. I would donate 100 PPC towards an offer like this if it was promoted properly. Maybe it could be promoted with any news articles released at the time when the ROAST Coordinator is ready. I’m not sure how to police it though… Another giveaway I have heard mentioned in Discord is for current members to go into other ‘Crypto Discord’ communities and offer a reward for each new member that joins the Peercoin Discord community. Then that person making the offer then tips that new member when they come in and comment in the Peercoin Trading channel. You could offer 5 PPC for the FIRST 10 new members only, to protect yourself from spending too much. I am not a member of any other Discord communities though so if someone else wanted to do it on my behalf I could also offer 100 PPC total to new members (ie. 10 x 10 PPC or 20 x 5 PPC). I think this one could help drive a bit of liquidity if we attracted some new traders… I think the original website giveaway or faucet idea offered by @7veter1 is also a good idea to rank higher in Google searches. I would support this too. I think anything and everything is worth a shot as a test and then measure results.

3 Likes
3

There can be very creative ways of being generous, and it often is less about the direct impact as much as the knock-on effects to the community. The recent efforts of Patchcoin can certainly be seen as a kind of giving back and generosity, as the intention is to mirror the peercoin chain. This is a more distributed approach essentially using a snapshot of the Peercoin blockchain as a ledger to distribute proportionally to.

In some ways, this is an opposite tack to what this thread was doing. This thread aimed at rewarding an individual idea expressed publicly. Patchcoin, on the other hand, appears to be aimed at rewarding the entire community in an equal and fair manner.

3 Likes
4

It is uncanny that this airdrop was announced just after this thread was created. I hope the community isn’t going to stop efforts here and hang their hats on Patchcoin attracting new members for us. Patchcoins’ goal is to reward existing and active community members that hold Peercoins.

Although…

Patchcoins airdrop may attract previous members but it remains to be seen how these sleepy Peercoin holders will know that this offer is available to them.

Again, the Patchcoin airdrop generosity could be very helpful to liquidity/volume but this depends on a lot of things like price, exchanges to trade, white paper etc etc.

I was looking forward to know more of your thoughts on the above @Nagalim.

5

Let’s take the recent images of Storas as a starting point, with the goal of imagining a way to re-use it for a Peer4Commit replacement.

There are two pages of inputs described in that UI, let’s focus on that and not pay so much attention to the back-end until we know what we want. Name, Image, Description, Categories, these things I feel we could easily fill out, saying something like “updating the website to have kitten logos - 100 PPC”. The second page may provide more clarity for how this would work, however.

Expires seems straightforward, as does minimal offer. These are the requisite fields for the validity of the Peer4Commit proposal. However, we already have something of an ambiguity with “minimal offer”, represented by the asymmetry of the involved parties. Let us consider possible outcome 1 and 2. For outcome 1, this should resolve in such a way that the person who did the work is paid for their efforts. In outcome 2, this should resolve in such a way that everyone who put coin into this gets their coin back. This is a boolean yes or no, at its simplest, so that is what we will consider. This immediately faces an interesting conflict with the way Storas is performed: we would ideally like to allow anyone to donate coin to a collective cause and anyone to do the work to get that coin (with oracles as verifiers of work). However, Storas is aimed at discrete bets with a party and counterparty. If we try to project these roles onto a Peer4Commit concept, we must treat the asymmetry of the parties.

In this case, only one party locks coin, while the other only seeks to unlock it. If we consider this with only one person who gives the coin and one person who does the work then we can perhaps approach this more easily. Alice wants the website to have kitten logos and has 100 PPC. Bob knows how to code kitten logos. Charlie can determine whether kitten logos have been added to the website or not. Charlie is designated as Oracle.

This can go one of two ways, either Bob makes the Storas occurrence or Alice does. If Bob makes it, then Bob locks up no coin and the “minimal offer” is the price required for them to do the work. Bob waits until Alice fills the offer, then does the work before the deadline, then Charlie unlocks the coin for Bob. If Alice makes the original Storas occurrence then the initial offer coins are locked up and the “minimal offer” can be 0, or some finite collateral penalty if Bob fails to accomplish the task.

I believe that more or less works, then we just have to think a bit more about how to work with multiple groups, and try to avoid e.g. people making frivolous offers or accepting jobs they can’t do. Also, the example given of work on the website would require access to the back-end, which can only be done by certain parties. The vetting of the work by the oracle could get messy, as it would be difficult to keep all parties anonymous in these situations. However, if even a little of this worked, it could make for a great method of decentralized incentives across the ecosystem.

6

I’m not to sure how Storas backend works but is it possible to add a “Weighted ROAST Threshold” here?

7

Im not sure i understand the application here of oracle granularity. A vast majority of the time the question of “did the performer fulfill the task?” Is a simple consensus boolean of “yes, it was completed” or “no, they didnt do it in time”. Im not sure i can think of a situation where we would want a bunch of oracles with different weights as opposed to simple consensus. Remember that the oracles can talk to each other, and compare notes about how the work was done, so they should all reach a more or less unanimous conclusion most of the time.

8

I thought you were trying to have many donors for each project. That would mean that they could have different amounts to donate each. This is why I was thinking of adding a weighted ROAST application.

9

Ah, I see, interesting. Of the three parties, Alice is the person we want to multiply, while Charlie is the person who multiplies with the weighted ROAST application. Perhaps we can think of a way to make a deeper connection between the two, but that would eliminate the independence of the actors. That said, in some ways we have already more or less mandated that Bob and Charlie know who each other is in the process of github code review. Perhaps there is a way to make a 1:1 correlation between Alice instances and Charlie instances, to represent the distribution. Let’s try an oversimplified example:

Alice and David both want to donate 100PPC each for kittens and Bob can make kittens for 200PPC. Charlie and Eunice are equally good at telling if Bob make kittens properly. Alice and David would both need to contribute to the multisig creation together, while Charlie and Eunice’s signatures are both required for the resolution of the transaction.

I’m a little at a loss here for how to map Alice to Charlie and David to Eunice. Let’s even imagine that we have two performers, Bob and Frank, who each work on different parts of the Kitten code, each valued at 100PPC. It is easy to map Bob to one part and Frank to another part, then map Charlie to Bob and Eunice to Frank, such that the oracle signature is a combination of Charlie vouching for Bob and Eunice vouching for Frank. So we can segregate the task and play around with weighted ROASTs for the task. However, I still don’t see any way to intelligently map Alice to Charlie and David to Eunice, such that the donations don’t seem segregable. Either the contract is paid for, or it’s not.

10

Could Alice and Bob set up a DKG as equal partners and then act as one (TeamAB) to create a DLC Offer? Charlie and Eunice could act as the Oracle between TeamAB and whoever takes up the offer to make the kittens.

If that works then you could go further and have all types of weighted donator pools. You could also have weighted teams that agree to make kittens. John agrees to make 3, Sonya makes 1 and Peter makes 4. They divide the payment accordingly. Or rather they make a DKG according to how many kittens they agree to make.

The above quote is from the article, Weighted ROAST threshold signatures

11

You can, of course, have two people pool their money externally and go in together, and possibly have them both include their signatures in the DKG. However, that is not really the same as allowing two strangers to both go in on a donation, and it definitely doesnt use wieghted keys. Essentially, those two actors would justc collude separately to the Storas interaction. We would probably need to modify the way Storas works if we wanted this kind of functionality in-app.

The reason this doesn’t use weighted keys is because there are only two outcomes here, either the performer is unlocking the funds upon completion or the donators are retrieving their funds. I think including more options, such as a partial dissolution, is quite complex and ambiguous for how it would work.

12

Think of it this way:
In a standard Storas bet, can multiple parties claim a single bet together, splitting the amount? So someone says “1:1 chances for 100 PPC that the sun comes up tomorrow” and two other people each put in 50 ppc to match the bet. It’s a cool idea, and hypothetically possible, but I dont think Storas will work that way to begin with.