Comment by nl
19 days ago
This thought pattern leads to crypto.
In that world there's a process called "staking" where you lock some tokens with a default lock expiry action and a method to unlock based on the signature from both participants.
It would work like this: Repo has a public key. Submitted uses a smart contract to sign the commit with along with the submission of a crypto. If the repo merges it then the smart contract returns the token to the submitter. Otherwise it goes to the repo.
It's technically quite elegant, and the infrastructure is all there (with some UX issues).
But don't do this!!!!
I did some work in crypto. It's made me realize that the love of money corrupts, and because crypto brings money so close to engineering it corrupts good product design.
The "money goes to the repo part" is the problem here, as it incentivizes maintainers to refuse legitimate pull requests.
Crypto has a perfect way to burn money, just send it to a nonexistent address from where it can never be recovered. I guess the trad fi equivalent are charitable donations.
The real problem here is the amount of work necessary to make this viable. I bet Visa and Mastercard would look at you funny if your business had such a high rate of voluntary transaction reversals, not to mention all the potential contributors that have no access to Visa/MC (we do want to encourage the youth to become involved with Open Source). This basically means crypto, and crypto has its own set of problems, particularly around all the annoying KYC/AML that a normie has to get through to use it.
> I bet Visa and Mastercard would look at you funny if your business had such a high rate of voluntary transaction reversals
Plenty of businesses do the “your credit card will be charged $1 and then reversed” as a verification method that I don’t think it would be a major issue. I do wonder how much those companies are paying for that, though… I am guessing they lose some of that $1.
You can reduce the transactions with payment providers. Instead of money exchanging from contributor to maintainer, have a token exchange. Contributors fund tokens with real money, and pull requests cost and refund tokens. Like an escrow account. But the money never goes to the target system. There are no perverse incentives to steal tokens. If you get a reputation of not refunding tokens (which have no value to a maintainer), then contributors will dry up.
"TrustTokens" or "EscrowTokens"
Probably just making it non refundable works almost as well (since time really is expended reading it), without the hassle of spinning up an intermediary layer blockchain.
> I bet Visa and Mastercard would look at you funny if your business had such a high rate of voluntary transaction reversals
…you might be right, but I do wonder if the situation would be different if “your business” was “Microsoft”. Obviously they would discuss this plan ahead of time.
> The "money goes to the repo part" is the problem here, as it incentivizes maintainers to refuse legitimate pull requests.
That's not true. The issue is that the system the comment you're replying to described is escrow. Escrow degenerates in the way that you describe. I explain it a bit more in this comment elsewhere on this post:
https://news.ycombinator.com/item?id=46938811
> all the annoying KYC/AML that a normie has to get through to use it.
There are always escape hatches. If your code is so great that people will want to pull it, then you don't pay to push. If it's not really that great, then what are we talking about? Maybe it disincentivizes mid code being pushed. So be it.
You can make friends, you can make a name for yourself, you can make a fork that's very successful and upstream will want to pull it in, you can exert social pressure / marketing to get your code merged in. Lots of options that do not involve KYC/AML.
For everyone else, I'd say KYC/AML are a good idea because of the increasing amount of supply chain exploits being pushed out into repos. If pushing by randos is gated by KYC/AML, then there's at least some method of chasing the perps down and taking them to justice.
That's a win-win-win-win situation. Less mid code, less exploits, earnings for maintainers, AI slop blocked. Absolutely amazing.
right, the ethereum gets spent whether the transaction is cancelled or not. and that's an issue
> because crypto brings money so close to engineering it corrupts good product design.
Amen.
It feels like the problem here comes from the reluctance to utilize a negative sum outcome for rejection. Instead of introducing accidental perverse incentives, if rejected your stake shouldn't go to the repo, 50% could be returned, and 50% deleted. If it times out or gets approved you get 100% back. If a repo rejects too often or is seen doing so unfairly reputation would balance participation.
No, the perverse incentive is that there will be RepoCoin, and the people involved will be incentivized to make the price of that as high as possible.
> No, the perverse incentive is that there will be RepoCoin, and the people involved will be incentivized to make the price of that as high as possible.
Isn't this problem unrelated to cryptocurrency?
There will be the US dollar, and the people involved will be incentivized to keep its value high, e.g. by pressuring or invading other countries to prevent them from switching to other currencies. Or they'll be incentivized to adopt policies that cause consumer and government debt to become unreasonably excessive to create a large enough pool of debts denominated in that currency that they can create an inordinate amount of it without crashing its value.
Or on the other side of the coin, there will be countries with currencies they knowingly devalue, either because they can force the people in that country to accept them anyway or because devaluing their currency makes their exports more competitive and simultaneously allows them to spend the currency they printed.
If anything cryptocurrency could hypothetically be better at reducing these perverse incentives, because if good rules are chosen at the outset and get ossified into the protocol then it's harder for bad actors to corrupt something that requires broad consensus to change.
5 replies →
But it could just be made a stablecoin.
4 replies →
Ahh, I see now the angle you were coming at it from, my wrong!
gitcoin lol
"It's made me realize that the love of money corrupts".
Yep. How about $1 per PR. The submitter gets to choose from a list of charities. No refund if the PR is accepted.
The goal is to get rid of junk PR's. This would work. There could be a central payment system, which any open source project can integrate with. It could accept payment in say India, of the Indian PPP of $1, so you aren't shutting out poorer developers.
I would not pay any amount of money, even a trivial one, for the privilege of being able to do free work for a project - and I don't think I'm an outlier here.
Another way to think of it is: paying $1 to have your pr and concerns elevated above the supermajority sea (that which will be ai driven contributions). For that cost, it's a steal of the deal.
Then, from the perspective of "it's a donation to a project you care about" it becomes even more rational. But the project itself getting the money has all the problems others have outlined already, so that idea's a bit bust.
3 replies →
Most of my PRs are drive-by PRs: I have an problem, maybe a bug or missing feature, that annoyed me enough to fix it. And because I want to use future versions without the work of maintaining a fork I instead invest the work to upstream the fix. A step that is sometimes more work than the fix itself. At that point I wouldn't mind paying $1 to get that PR looked at and merged.
But that is not the only type of PR. We clearly need escape hatches for people who engage with a project on a deeper level.
1 reply →
The money is going to a charity of your choice.
I think the core insight here is about incentives and friction, not crypto specifically.
I’m working on an open source CLI that experiments with this at a local, off-chain level. It lets maintainers introduce cost, review pressure, or reputation at submission time without tying anything to money or blockchains. The goal is to reduce low-quality contributions without financializing the workflow or creating new attack surfaces.
I see no advantage with this over real money transfers. At all. Just use some kind of escrow.
You don’t need a third party, or anybodies permission, nobody can censor you or block your transactions, you don’t need a bank account with everything that entails. The barrier of entry is the same as creating an SSH keypair. It works globally, fast, cheap. You do not need to trust anybody, all the code is open and the ledger is cryptographically verifiable by anyone. There are lots of advantages.
In this scenario, the repo owner can just merge the patch but still refuse to pay back the shitcoin. With escrow, the escrow entity would act as an arbiter
No. Just because you can use crypto for something doesn’t mean you should. In fact you almost never should.