[SilverBirch]

A massive problem that crypto faces right now is that there's basically a whole army of hackers going around every single crypto project and figuring out how to smash their way in and steal all the cyrpto. So whilst this idea is of rewarding productive contributions to open source (which btw, I'm not sure this solves), what it's actually doing is putting a massive fucking target on the back of any open source project that adopts this.

It basically says "here's a pointer to a pot of money, smash up this git repo to get it". What's more likely to happen, contributors spend a tonne of effort contributing to open source for a tiny share of the money in the wallet? Or hackers break into your github account, open an issue, allocating all the money in the wallet to it, merge the PR and sign off on draining the wallet?

I know what I'd bet on.

[DomMac]

By breaking into a github account hackers won't be able to drain any founds, this is not something that is handled by github authentication. Founds are stored in a multisig Safe wallet, transactions must be approved by the multisig owners.

Apart from that, you are practically saying "hey there are hackers out there, stop building tools".

[SilverBirch]

If the payments aren't integrated into the github merge system, then what is this system doing at all. Why not just put a message in the merge commit saying "Hey, please send me eth at this address"?

[jjranalli]

TLDR; Compromising Merge to earn projects is not worth for an attacker as it requires:

- satisfying multiple hard requirements,

- yields low rewards, and

- can be easily and quickly mitigated by project owners.

Full answer:

---

What you describe is actually not possible for a number of reasons.

In order for an attack on a Merge to earn project to have success, an attacker needs to obtain:

- Access as owner / maintainer to the Github repo, and

- The private keys of the wallets of enough safe owners to autonomously execute transactions. The general rule for multisigs is, the higher the quorum, the higher the safety.

In absence of both conditions, project maintainers have plenty of time to get control of the situation, and the attacker couldn't do anything. In fact, even if a Github account is compromised and fake PRs are merged to give themselves fat rewards, nothing happens until multisig owners actually execute the malicious transactions.

But, even though extremely improbable, let's assume an attacker manages to do that and the worst possible scenario happens. What then?

Due to how slicers are designed, the attacker wouldn't be able to get money received until that point out of the slicer, but only what has been received after he gained control. The Slice protocol has been designed to safeguard against these kind of attacks and malicious usage.

On the contrary, to mitigate an attack, project owners just need to reinitialize MTE for their repo with a new slicer and multisig, distribute ownership to contributors as it was before the attack, and redirect any new income and donations to the new slicer. This is technically trivial and can be done in minutes.

[SilverBirch]

There seems to be a fundamental problem here - which is that either this system automatically processes transactions as conditioned by github merges. In which case you're basically saying my github credentials need to be as secure as my bank account, even if you think multisig means that we need to hack a couple of accounts rather than just one.

>Due to how slicers are designed, the attacker wouldn't be able to get money received until that point out of the slicer,

How does a normal person get money out of a slicer? That's how the hacker will.

>On the contrary, to mitigate an attack, project owners just need to reinitialize MTE for their repo with a new slicer and multisig,

You're saying that you foresee people starting a new pot of money to be stolen in the immediate aftermath of their old MTE money being stolen?