Would this make sense as a smart contract application? Trying to understand features and limitations

Question

I'm starting to read up on Ethereum and smart contracts and some questions are popping up in my mind.

I can understand that smart contracts can be used, for example, to make a bet for/against the case that it'll be snowing in Cambridge on a specific day, and I can easily imagine how a smart contract like that would work.

However, let's imagine a more complex case.

1. Company has a bug bounty program.
2. User finds a bug and reports it to Company, and wants to make sure Company will pay him once the bug has been fixed.
3. Company pays User with a digital token on the Ethereum blockchain.

Does this mean that we need to code and create a new smart contract signed by both parties for every bug every user reports? If this was the case, would it be too onerous to publish a new contract on the blockchain for every bug report?

Or does it mean that we need to create a more generic smart contract that could get transaction sent to it, where each transaction has an attached bug report?

(I'm not trying to actually do this, just to understand. So let's imagine that we can code a generic function isBugFixed(bug) that returns true or false for every bug we pass to it)

Furthermore, it looks like that the user would have to pay to submit a new bug report, either to create a new contract or to send a new transaction. Am I correct to say that this cannot be avoided without a centralized figure that acts as a middle man and publishes reports on the blockchain, thus reducing decentralization (what if two users report the same bug at the same time? there would be no thing similar as "the consensus on the longest chain" but the middleman would make the decision).

Do you think that the best decision in such a case would be to rely on a central authority that verifies reports and bugs and use the blockchain only for token transfers or could the whole thing be built as a decentralized app?

Thank you

Answer 1

Furthermore, it looks like that the user would have to pay to submit a new bug report, either to create a new contract or to send a new transaction.

Sure.

Am I correct to say that this cannot be avoided without a centralized figure that acts as a middle man and publishes reports on the blockchain, thus reducing decentralization (what if two users report the same bug at the same time? there would be no thing similar as "the consensus on the longest chain" but the middleman would make the decision).

First, there should be a very big number of reports in case we are talking that it will happen often. On the other hand, it might happen, and we can resolve it pretty easy.

1. not a fact that 2 reports will get in the same block, so their timestamp will be different
2. you can have another smart contract, that receives reports and sorts them with some algorithm before it actually posts bug report somewhere(ie to a web page of the dapp)
3. anyway, bugs will be fixed by a human-programmers, who will actually decide was it a bug or not

---

Conclusion: your scenario can be decentralized, but yet not fully. But may be one day AI will change it. Hence

Does this mean that we need to code and create a new smart contract signed by both parties for every bug every user reports?

yes, it does.