Let’s discuss how to better fund community projects.
2 Likes
I’ve been looking through the post and considering the walk-through. Thank you, by the way, for providing a sort of example environment to discuss it.
I am cheerfully a game designer. Really what that means is I look at systems, I consider how they function, and then I work out how best to break them horribly. I’m a great believer in the old adage, “show me the incentives and I’ll show you how people will behave.”
So I’m looking at the system and thinking about how I would exploit it if I were a whale or central power broker, exactly the kind of people who are literally called out on the quadratic funding webpage. In fact, the claimant is thus:
And that would be true – if this other statement from @grin was accurate in the context of this operation:
Gitcoin has done a ton of work in that regard and we can learn from them, and we have the added advantage of a robust on-chain identity system.
See – the problem is that we don’t have a robust on-chain identity system for the purposes of avoiding exploitation of this particular mechanism. We have bids which are explicitly tied to a Channel, which in theory are the nym of choice, but which are largely blinded as regards an individual wallet they’re associated with. Creating Channels is cheap; by design, notably, barely more than the transaction fee needed to write to the blockchain. If the “robust on-chain identity system” is the necessity of the bid backed by a Channel, the relative value proposition between creating more channels and the possibility of money acquired from any given funding round mean that if I am a whale or central power broker, it’s perfectly reasonable for me to spend the time/effort to automate/simplify the process of creating Channels in order to seriously influence the result of any quadratic vote. Surprisingly, because of the nature of the vote accounting itself, out of proportion to the actual value invested in any specific voting cycle.
Accounted for across multiple voting cycles, because the process of automation only has to be implemented once, the cost drops as the potential gain increases.
And by way of illustration, I will link the website link to help visualize how QF functions:
(If you give me things to tinker with, I tinker with them.)
Obviously these are arbitrary numbers. I am not going to argue that they don’t depict exactly what they purport to, that certain values of bids result in certain values of match result. It’s exactly what it looks like.
Notice that the leading bid has the same total value as the arbitrary number I’ve already selected: $101. With six competitors, it receives almost half of the matching bids. Five times the amount that was actually bid by “individuals.” This is because it has seven individual bids and the next nearest has three.
Obviously, despite the fact that someone cared enough to bid $101 (and received actually less in matching funds than the community bid), it receives half of the overall value.
Unless you assume that all seven of those bids were put in by the same bidder. Which I immediately assume, because creating Channels is extremely cheap and can easily lead to bid proliferation. Sure, each of those individual bids costs the transaction fee of engaging with the blockchain – but that’s chicken feed compared to the potential payoffs.
What is incentivized? What is incentivized is not bidding the most in terms of value but bidding the most in terms of volume.
You can see this even more clearly if you take off one of the one dollar bids from grant one. The funded amount drops to $100 in the match amount almost doesn’t drop at all to land at $437.29.
Let’s take off another of the one dollar bids. The funded amount is now two dollars less than the arbitrarily median bid, and still ends up with just a little bit less than half of the total matching amount.
Let’s take off the final one dollar bid. That gives it four bids, one greater than that of grant three – but it still gets nearly $400 of the $1000 match amount.
A winning strategy becomes very quickly apparent. You want to maximize your number of bids, all of which have a roughly equal value. Compare grant two with grant seven. They have the same number of bids, but because the latter has more equally balanced ones, it has more power in the quadratic formula, and takes not quite twice the payout.
What is incentivized?
Automating access to Channels in order to distribute bids across as many as possible, because even extremely low bids with more numbers being dropped off are more effective at taking more of the cut than more randomly distributed ones. If I have $101 worth of tokens to bid with, I am far more likely to gain a big portion of the payout if I automate the system to make 101 one dollar bids than any other mechanism. This probably holds true down to the smallest quanta that the system is able to deal with above transaction costs.
Transaction costs become the lower bounds limiter for exploitation.
Right, so let’s magically assume that the LBRY protocol develops a mechanism to undoubtedly link a user with an account. That breaks all kinds of privacy assumptions and underlying mechanical requirements, but let’s assume that a unicorn implements it.
The lower bound of exploitation cost is still transaction cost – it’s just that those transaction costs include whatever it takes to create multiple accounts. Multiple wallets. Multiple “users.” And with the potential payout gains being multiples of the total bid, it is extremely valuable to come up with mechanisms to circumvent the identity assumption.
The cheapest and easiest of which is simple collusion. Quadratic funding makes it extremely valuable to creates “mutual admiration societies,” or circle jerks in modern parlance. A group of people agree to vote the same way and put in a portion of the bid purely to get a cut of the resulting payout. The less they care about the outcome the more rewarding it is to invest. The incentive is to collude to acquire the payout.
Yes, I know, this is an entire discourse talking about Sibyl attacks and other identity manipulations. But that is what quadratic funding incentivizes.
And there’s one thing we absolutely know – you always get more of what you incentivize, whether you want it or not.
To really get behind this, I would have to be a lot more reassured about LBRY identification and identity isolation, but even then would absolutely believe that out-of-band communication between bad actors would result in tons of pressure to incentivize collusion, and would be very careful about putting lots of funds at the disposal and direction of a system so implemented.
I hope this is useful feedback, even though it’s probably not what you were looking for. Incentivization. It’s delicate.
1 Like
I’m not too sure what I expected, but any feedback that takes the project seriously is useful, so thank you for that.
You’re right that incentives matter, and that unique identity is a major challenge. if I can pretend to be multiple people, then I can make lots of small donations to pull in a disproportionate amount of matching funds. At the same time, Gitcoin has used this system to allocate tens of million of dollars of funding across thousands of projects. They’ve been doing it for years and by all appearances they’ve been successful in fighting collusion. How do we reconcile these two things?
The answer is that what I sketched out is the simplest version of quadratic funding. It’s not a complete solution. There are many attacks on naive QF. There’s also lots of work being done to address them (e.g. MACI, graduated sanctions). We don’t need to solve every problem perfectly before we can start running funding rounds.
And that’s what I’m suggesting: that we start despite the known problems. Any system can be gamed, and that’s why systems need to grow and learn and adapt to challenges. If we don’t start, we’ll never discover the knowledge we need to create a robust system that works. I believe that this kind of funding is possible, that the downsides are limited if we start small and increase each round as we gain confidence, and that the upside is worth it.
Hello Grin,
I have been observing LBRY for one year, I understand the surface woking mechanism of LBRY. As it’s been stated to be the bitcoin in digital publishing. So for possible project to be delevloped on the website the best bet is like video/book/music website plaform? What’s your view on what kind of project is good to be build on LBRY?
At the same time, Gitcoin has used this system to allocate tens of million of dollars of funding across thousands of projects. They’ve been doing it for years and by all appearances they’ve been successful in fighting collusion. How do we reconcile these two things?
Possibly by acknowledging that, by their own reports, they really haven’t been all that successful in fighting collusion. Once you remove the axiomatic statement, the rest of the argument sort of falls apart.
In GR9 we experienced a significant uptick in Sybil attacks. This was to be expected based on the growing size of the match fund. But this means we, as a web3 community, need to take our defense against Sybil attacks to the next level.
That’s from June 11 of this year. It’s worth noting that several of the projects that they link to in the course of discussing the issue of Sybil attacks have already been closed/canceled, not fulfilled. Of the rest, the most successful/popular generally hinge on out of band methods for validating identity, all of which require significant human intervention and interaction in order to establish that validity.
(It’s also valuable to point out that organizations which are in the business of giving out grants with the assumption that they are allocating those funds in a way that aligns with the intents of the community will not go out of their way to describe and define historical failures to do so. Nor should we expect such organizations to report strictly candidly on those failures. So even if Gitcoin was extremely vulnerable and had misallocated tons of funds due to civil attacks, I wouldn’t expect that “by all appearances” they would be entirely truthful about their success in fighting collusive attacks. That’s not to impugn their trustworthiness, that’s just looking at where the incentives live.)
Pointedly, the LBRY protocol is philosophically and technologically oppositional to those mechanisms. It has been purported to be a positive that it is extremely easy and low friction to create a new account and even easier and lower friction to create a new Channel associated with a new wallet. You can do so without actual access to traditional portals, directly through lbrynet. That’s considered a very important strength of the system, or has been up until now. It means that the bar for getting on board to interact with the rest of the protocol is extremely low, making access to anyone straightforward.
And that’s what I’m suggesting: that we start despite the known problems.
The problem with this is that it is extremely easy to give away somebody else’s money, and I have absolutely no quarter in that pile so, by rights, I shouldn’t really care. But I am also constitutionally opposed to letting even the vaguest acquaintance buy a used car which is clearly dragging the steering and brake cables behind it, leaving a trail of fluids, and saying to them “yeah, go ahead, I’m sure it’ll be fine to drive this thing home.” No skin of my nose if they do; at worst I’m going to drive my own car behind them and watch the ensuing carnage. I know how to have a good time. But I also have to do my due diligence and say “maybe you ought not to.”
If we don’t start, we’ll never discover the knowledge we need to create a robust system that works.
That’s not true at all. If only one group or organization could do this at a time, that would be true. But with multiple groups pursuing this, there’s no shame in saying, “looks dangerous; you go first.” If somebody ahead of you falls, it’s much easier to avoid the dart trap and take their money bag without getting something in the spine yourself. Some would even suggest it’s advisable.
I believe that this kind of funding is possible, that the downsides are limited if we start small and increase each round as we gain confidence, and that the upside is worth it.
Here’s my thought – as long as you assume that the first several rounds are going to be basically throwing money at people who have every opportunity to exploit the system and you may or may not actually get a significant amount of funding in the hands of anyone who will help support the Foundation, that’s fine. LBRY itself has certain inherent weaknesses when it comes to protecting from Sybil attacks on systems like this, all of which will make it much harder in the long run to trust the outcomes.
Any kind of identity resistance is going to have to be injected from outside the LBRY architecture itself. And that is reasonable, in terms of systems that work.
If we’re talking about a set of secured identities who then use QF to distribute funds proportionally and as a result it becomes much harder to execute Sybil attacks (though absolutely not harder to execute collusion attacks), the system becomes a little more robust. But that’s not what you were talking about. Likewise, you didn’t talk about any sort of defenses against attacks on naïve QF; the only thing you described was, in fact, naïve QF. If you want comments on something else, you have to actually say that something else.
Personally, I would be much more interested in hearing about what kind of validation and verification you had in mind in order to secure any kind of voting on Foundation funding distribution, because that is a big deal. Any system is going to need some sort of unified identity mechanism of validation in order to be trustworthy. Once you have that, it doesn’t matter if the mechanism is one man, one vote, QF, or proportional representation.
But as for literally what you described here, in the context you described it, leveraging the mechanisms you described – as an architecture it’s entirely too vulnerable to exploitation for me to suggest even going round one with it. That doesn’t mean you can’t or anyone shouldn’t, but I wouldn’t advise it.
We’re giving it a go with the Foundation: 50k LBC up for grabs.
2 Likes
Okay, I’m not a verified creator (yet), AND I’m not competent to develop the project(s) I’d like to see implemented. How would I, or someone else, create a proposal for a Bounty to be paid at release of a project?
For example:
I would like to improve the procedure for and access to blogging on LBRY. For that, there really needs to be a better suite of upload tools. If I were to make a proposal for a Bounty, it would for a tool similar to a static site generator (Cloudflare: What is a static site generator?), or an extension/plug-in for an existing generator, whose Deploy function would push to LBRY.
Interestingly, there’s really no particular reason why such a tool would be limited to text, either.
BUT I am not myself competent to develop such a tool. Nor am I a verified creator. So I fail on the possibility to propose or receive funding, or create a claimable bounty wallet.
In a real sense, if you can’t build a thing and you want a thing, then you have to pay for a thing. That’s a basic truth of the universe. Or you have to be persuasive enough to convince someone who can pay for thing to do so.
The problem is that it is extremely easy to spend someone else’s money. Thus, those who can afford to fund something tend to make it difficult because there’s no end to the number of things that might be funded.
In this particular instance, about the only recourse you might have is to try and persuade the Foundation that they should create a bounty, but in order to succeed at that you would probably have to actually prove that there is a widespread demand for such a tool, collect the proof of that claim, and present it along with a fairly strong idea of what would be necessary.
Alternately to that alternate, you could make an appeal directly to developers who hang out in the developers channel. Someone might find of the problem interesting enough to put together – but since you’re not paying them in any sense, that would be a project that would not be at the top of their priority list unless they, also, have the same problem.
It might be an interesting experiment for the Foundation to run a quadratic voting round specifically for a bounty fund distribution, much like the recent funding around, except that they would be looking for proposals for good bounties, set a pool for the total value of bounty they want to offer, and let the votes decide how that bounty pool gets cut up. It could be very interesting even if there are some fairly clear issues with the process.
Actually, this would be awesome. Proposals could include details about required user-friendliness, minimum project/software maintenance periods, etc.
The question is, how to determine whether a claimant of said bounty funds qualifies for disbursement–particularly in cases where multiple claimants exist.
Perhaps a bounty funding round–where bounty goals and reward values are established–followed by a developer bidding round–where interested developers place bids in similar fashion to government-construction contract deals.
1 Like