Software engineer working in philanthropy/crypto. Former co-founder / Head of Tech, Effective Altruism Funds
SamDeere
Karma: 1,159
For the last two years we’ve run a donor lottery through the December Giving Season, drawn in January, and we intend to do this again this year-end. Assuming that preparations go well, we’ll aim to have this open by Giving Tuesday.
To add to this, I re-analysed the EA Survey responses on cause areas, restricting to just Giving What We Can Members:
Obviously there’s a selection effect where the members who take the survey are more likely to be more involved with EA, but I think it’s still instructive that Giving What We Can members are a fairly broad church with respect to cause areas, and that it’s reasonable to offer different cause areas to them as a default setting on EA Funds.
Disclosure: I work at CEA, and am the person primarily responsible for both EA Funds and the technical implementation of the new Pledge Dashboard.
Is there a way to give Algolia additional information from the user’s profile so that it can fuzzy search it?
The success of our factored evaluation experiments depends on Mosaic, the core web interface our experimenters use.
Is Mosaic an open-source technology that an applicant would be expected to have existing familiarity with, or an in-house piece of software? (The text of the job ad is a little ambiguous.) The term is unfortunately somewhat ungoogleable, due to confusion with the Mosaic web browser.
It has some investigations in progress but hasn’t made any grants yet. It was used to back the late-2018 Donor Lottery.
Re 1, this is less of a worry to me. You’re right that this isn’t something that SHA256 has been specifically vetted for, but my understanding is that the SHA-2 family of algorithms should have uniformly-distributed outputs. In fact, the NIST beacon values are all just SHA-512 hashes (of a random seed plus the previous beacon’s value and some other info), so this method vs the NIST method shouldn’t have different properties (although, as you note, we didn’t do a specific analysis of this particular set of inputs — noted, and mea culpa).
However, the point re 2 is definitely a fair concern, and I think that this is the biggest defeater here. As such, (and given the NIST Beacon is back online) we’re reverting to the original NIST method.
Thanks for raising the concerns.
ETA: On further reflection, you’re right that it’s problematic knowing whether the first 10 hex digits will be uniformly distributed given that we don’t have a full-entropy source (which is a significant difference between this method and the NIST beacon — we just made sure that the method had greater entropy than the 40 bits we needed to cover all the possible ticket values). So, your point about testing sample values in advance is well-made.
The NIST Beacon is back online. After consulting a number of people (and notwithstanding that we previously committed to not changing back), we’ve decided that it would in fact be better to revert to using the NIST beacon. I’ve edited the post text to reflect this, and emailed all lottery participants.
AFAIK random.org offers to run lotteries for you (for a fee), but all participants still need to trust them to generate the numbers fairly. It’s obviously unlikely that there would in fact be any problem here, but we’re erring on the side of having something that’s easier for an external party to inspect.
The draw should to have the following properties:
The source of randomness needs to be generated independently from both CEA and all possible entrants
The resulting random number needs to be published publicly
The randomness needs to be generated at a specific, precommitted time in the future
The method for arriving at the final number should ideally be open to public inspection
This is because, if we generated the number ourselves, or used a private third-party, there’s no good guarantees against collusion. Entrants in the lottery could reasonably say ‘how do I know that the draw is fair?’, especially as the prize pool is large enough that it could incentivise cheating. The future precommitment is important because it guarantees that we can’t secretly know the number, and the specific timing is important because it means that we can’t just keep waiting for numbers to be generated until we see one that we like the look of.
The method proposed above means that anyone can see how we arrived at the final random number, because it takes a public number that we can’t possibly influence, and then hashes it using SHA256, which is well-verified, deterministic (i.e. anyone can run it on their own computer and check our working) and distributes the possible answers uniformly (so everyone has an equal chance of winning).
Typical lottery drawings have these properties too: live broadcast, studio audience (i.e. they are publicly verifiable), balls being mixed and then picked out of a machine (i.e. an easy-to-inspect, uniformly-distributed source of randomness that, because it is public, cannot be gamed by the people running the lottery).
Earthquakes have the nice property that their incidence follows a rough power law distribution (so you know approximately how regularly they’ll happen), but the specifics of the location, magnitude, depth or any other properties of any given future earthquake are entirely unpredictable. This means that we know that there will be a set of unpredictable (i.e. random) numbers generated by seismometers, but we (and anyone trying to game the lottery) have no way of knowing what they will be in advance.
(This is not actually that different to how your computer generates randomness — it uses small unpredictable events, like the very precise time between keystrokes, or tiny changes in mouse direction, to generate the entropy pool for generating random numbers locally. We’re just using the same technique, but allowing people to see into the entropy pool).
Other plausible sources of randomness we considered included the block hash of the first block mined after the draw date on the Bitcoin blockchain, and the numbers of a particular Powerball drawing.
Agree with the sentiment, but we’re most definitely not rolling our own crypto. The method above relies on the public and extremely-widely-vetted SHA256 algorithm. This algorithm has the nice property that even slightly different inputs produce wildly different outputs. Secondly, it should distribute these outputs uniformly across the entire possibility space. This means that it would be useless to bruteforce the prediction, because each of your candidates would have an even chance of ending up basically anywhere.
For example, compare the input strings
1111111111111111111111111111and1111111111111111111111111112with their SHA256 outputs:sha256(1111111111111111111111111111) = fe16863cfd4015c58da63aa5d2fe80e6e1fcd0bbdd57296fe28844cc7d79581b sha256(1111111111111111111111111112) = b74822540995e7aa1b50a4d9d23a4b13aff99910c3c2111b9bf649e947e5f49cIt doesn’t matter how much of the API response remains the same (for example, we could pad the input of every hash we generated with the same fixed string and have the same randomness properties as the proposal above). All that matters is that each response is going to be (unpredictably) different from the next.
ETA: It’s perhaps more helpful to see the digits from the API response as a publicly verifiable seed to a pseudorandom number generator, rather than as the random number itself.
Hey Eli – there has definitely been thinking on this, and we’ve done a shallow investigation of some options. At the moment we’re trying to avoid making large structural changes to the way EA Funds is set up that have the potential to increase accounting complexity (and possibly audit compliance complexity too), but this is in the pipeline as something we’d eventually like to make happen, especially as the total holdings get larger.
The grant payout reports are now up on the EA Funds site:
Long Term Future - $917,000.00
EA Community - $526,000.00
Note that the Grant Rationale text is basically the same for both as Nick has summarised his thinking in one document, but the payout totals reflect the amount disbursed from each fund
Two thoughts, one on the object-level, one on the meta.
On the object level, I’m skeptical that we need yet another platform for funding coordination. This is more of a first-blush intuition, and I don’t propose we have a long discussion on it here, but just wanted to add my $0.02 as a weak datapoint. (Disclosure — I’m part of the team that built EA Funds and work at CEA which runs EA Grants so make of that what you will. Also, to the extent that the sense that small projects are falling through the gaps because of evaluation-capacity constraints, CEA is currently in the process of hiring a Grants evaluator.)
On the meta level (i.e. how open should we be to adding arbitrary integrations that can access a user’s forum account data) I think there’s definitely some merit to this, and that I can envisage cool things that could be built on top of it. However, my first-blush take is that providing an OAuth layer, exposing user data etc, is unlikely to be a very high priority (at least from the CEA side) when considered against other possible feature improvements and other CEA priorities, especially given the likely time cost involved in maintaining the auth system where it interfaces with other services, and the magnitude of the impact that I’d expect having EA Forum data integrated with such a service would have. However, as you note, the LW codebase is open source, so I’d suggest submitting an issue there, discussing with the core devs and making the case, and possibly submitting a PR if it’s something that would be sufficiently useful to a project you’re working on.
Thanks for the comments on this Marcus (+ Kyle and others elsewhere).
I certainly appreciate the concern, but I think it’s worth noting that any feedback effects are likely to be minor.
As Larks notes elsewhere, the scoring is quasi-logarithmic — to gain one extra point of voting power (i.e. to have your vote be able to count against that of a single extra brand-new user) is exponentially harder each time.
Assuming that it’s twice as hard to get from one ‘level’ to the next (meaning that each ‘level’ has half the number of users than the preceding one), the average ‘voting power’ across the whole of the forum is only 2 votes. Even if you make the assumption that people at the top of the distribution are proportionally more active on the forum (i.e. a person with 500,000 karma is 16 times as active as a new user), the average voting power is still only ≈3 votes.
Given a random distribution of viewpoints, this means that it would take the forum’s current highest-karma users (≈5,000 karma) 30-50 times as much engagement in the forum to get from their current position to the maximum level. Given that those current karma levels have been accrued over a period of several years, this would entail an extreme step-change in the way people use the forum.
(Obviously this toy model makes some simplifying assumptions, but these shouldn’t change the underlying point, which is that logarithmic growth is slooooooow, and that the difference between a logarithmically-weighted system and the counterfactual 1-point system is minor.)
This means that the extra voting power is a fairly light thumb on the scale. It means that community members who have earned a reputation for consistently providing thoughtful, interesting content can have a slightly greater chance of influencing the ordering of top posts. But the effect is going to be swamped if only a few newer users disagree with that perspective.
The emphasis on can in the preceding sentence is because people shouldn’t be using strong upvotes as their default voting mechanism — the normal-upvote variance will be even lower. However, if we thought this system was truly open to abuse, a very simple way we could mitigate this is to limit the number of strong upvotes you can make in a given period of time.
There’s an intersection here with the community norms we uphold. The EA Forum isn’t supposed to be a place where you unreflectively pursue your viewpoint, or about ‘winning’ a debate; it’s a place to learn, coordinate, exchange ideas, and change your mind about things. To that end, we should be clear that upvotes aren’t meant to signal simple agreement with a viewpoint. I’d expect people to upvote things they disagree with but which are thoughtful and interesting etc. I don’t think for a second that there won’t be some bias towards just upvoting people who agree with you, but I’m hoping that as a community we can ensure that other things will be more influential, like thoughtfulness, usefulness, reasonableness etc.
Finally, I’d also say that the karma system is just one part of the way that posts are made visible. If a particular minority view is underrepresented, but someone writes a thoughtful post in favour of that view, then the moderation team can always promote it to the front page. Whether this seems good to you obviously depends on your faith in the moderation team, but again, given that our community is built on notions like viewpoint diversity and epistemic humility, then the mods should be upholding these norms too.
Yeah MoneyForHealth, it does seem like it would be useful if you can point out instances of this happening on LW. Then we’ll have a better shot at figuring out how it happened, and avoiding it happening with the EA Forum migration.
Implementing the same system here makes the risks correlated.
The point re correlation of risks is an interesting one — I’ve been modelling the tight coupling of the codebases as a way of reducing overall project risk (from a technical/maintenance perspective), but of course this does mean that we correlate any risks that are a function of the way the codebase itself works.
I’m not sure we’ll do much about that in the immediate term because our first priority should be to keep changes to the parent codebase as minimal as possible while we’re migrating everything from the existing server. However, adapting the forum to the specific needs of the EA community is something we’re definitely thinking about, and your comment highlights that there are good reasons to think that such feature differences have the important additional property of de-correlating the risks.
Feature request: integrate the content from the EA fora into LessWrong in a similar way as alignmentforum.org
That’s unfortunately not going to be possible in the same way. My understanding is that the Alignment Forum beta is essentially running on the same instance (server stack + database) as the LessWrong site, and some posts are just tagged as ‘Alignment Forum’ which makes them show up there. This means it’s easier to do things like have parallel karma scores, shared comments etc.
We see the EA Forum as a distinct entity from LW, and while we’re planning to work very closely with the LW team on this project (especially during the setup phase), we’d prefer to run the EA Forum as a separate, independent project. This also us the affordance to do things differently in the future if desired (e.g. have a different karma system, different homepage layout etc).
An update on this: Cryptocurrency donations are now live on the site, so you can now enter the lottery (or make a regular donation to EA Funds) using BTC, ETH and LTC
An alternative model for variable pot sizes is to have a much larger guarantor (or a pool of guarantors), and then run rolling lotteries. Rather than playing against the pool, you’re just playing against the guarantor, and you could set the pot size you wanted to draw up to (e.g. your $1000 donation could give you a 10% shot at a $10k pot, or a 1% shot at a $100k pot). The pot size should probably be capped (say, at $150k), both for the reasons Paul/Carl outlined re diminishing returns, and to avoid pathological cases (e.g. a donor taking a $100 bet on a billion dollars etc). Because you don’t have to coordinate with other donors, the lottery is always open, and you could draw the lottery as soon as your payment cleared. Rather than getting the guarantor to allocate a losing donation, you could also ‘reinvest’ the donations into the overall lottery pool, so eventually the system is self-sustaining and doesn’t require a third-party guarantor. [update: this model may not be legally possible, so possibly such a scheme would require an ongoing guarantor]
This is more administratively complex (if only because we can’t batch the manual parts of the process to defined times), but there’s a more automated version of this which could be cool to run. At this stage I want validate the process of running the simpler version, and then if it’s something there’s demand for (and we have enough guarantor funds to make it feasible) we can look into running the rolling version sometime next year.
In practice, CEA technically gets to make the final donation decision. But I can’t see them violating a donor’s choice.
To emphasise this, as CEA is running this lottery for the benefit of the community, it’s important for the community to have confidence that CEA will follow their recommendations (otherwise people might be reticent to participate). So, to be clear, while CEA makes the final call on the grant, unless there’s a good reason not to (see the ‘Caveats and Limitations’ section on the EA.org Lotteries page) we’ll do our best to follow a donor’s recommendation, even if it’s to a recipient that wouldn’t normally be thought of as a strictly EA.
What happens if a non-EA wins?
It’s worth pointing out that one’s motivation to enter the lottery should be to win the lottery, not to put money into a pot that you in fact hope will be won and allocated by someone else better-qualified to do the research than you are. If there are people entering the lottery who you think will make better decisions than you (even in the event that you won), then you should either donate on their behalf (i.e. agree with them in advance that they can research and make the recommendation if you win), or wait for the lottery draw, and then follow their recommendation if they win.
(not implying that this necessarily is your motivation, just that “I’ll donate hoping for someone else to win” is a meme that I’ve noticed comes up a lot when talking about the lottery and I wanted to address it)
These are all great suggestions William, thanks for providing them. I’ll take them into account as we’re making future updates to the platform – no promises on a timeframe re current tech capacity constraints unfortunately, but I think they’re all very sensible ideas and would constitute significant improvements.