If I understand correctly, the 1BTC private key is stored encrypted inside a SQL database and the encryption key is held by a user on their own device (not on the server).

As such, if an attacker is able to get into the server, even root access, full database dump, etc, they still will not be able to access the private key.

That's a good design, imho.  I wish all companies would do it.

So as far as this competition/bounty goes, I doubt anyone will obtain the 1BTC.

That said, the present scenario does not accurately reflect conditions in a production environment.

In production, you would have user records being created and updated.

In this scenario, if an attacker is able to get into your web server, they should be able to modify javascript sent to the client in such a way that the client sends data unencrypted to server (or another server controlled by attacker) when creating or updating a record.

As such, I would propose that for this test/bounty to actually be useful and meaningful, you should modify the test conditions with simulated users that are regularly creating/updating records that contain valid private keys.   This would probably require splitting the 1BTC into many smaller pieces.

A patient attacker with server access could sit and wait until they have collected some or all of it.


edit: or every user record modification could contain the private key for full 1BTC.  Then a single breach would result in full bounty.