(draft) - GRIN CC security proofs (draft)

[MCM-Mike]

Description:

We the GRIN Community Council (CC) will provide on a quarterly basis a security proof. This security proof will provide a public statement, that we the CC are still in possession of all private key of the public Bitcoin address shown here https://github.com/grincc/finance/blob/main/addresses.md

Security proof process: Every three (3) month we will send an OP_RETURN message with a predetermined message as a hash-value (SHA256).

In order to send the OP_RETURN, all members of the GRIN CC need to sign this transaction, not only the lower threshold of the Bitcoin multi-sig address.

This HASH value will be sent in the OP-RETURN message, which we then will publish every 3 month publicly on the Bitcoin blockchain for everyone to verify.

Message to be hashed for OP-RETURN: "Date: dd.mm.yyyy GRIN CC"

How to publicly verify: We will publish the transaction ID of the OP_RETURN message on our https://github.com/grincc/security repository every 3 month. In order to be verifiable for everyone we came up with the following process:

1. Check Block Explorer: XXXX

[Anynomouss]

I think blockchair would be a good block explorer:

https://blockchair.com/bitcoin/address/bc1qmdhmgmhd6j89225hzdh7dxqgmen3y2q0g4vgpez0tw9tkp4ae39qsqvuyl

They automatically show the decrypted OP_RETURN statement so also non-technical users can directly verify the message. See an an example this statement of a baby that was born on the blockchain:

https://blockchair.com/bitcoin/transaction/9f07de305678adcc965a0856a2591c44236e09afefb03c4a43993519127a6697

In order to make it publicly viable it should be hexadecimal I think. The alternative, a hash is also nice since it keeps things more private.

[MCM-Mike]

In order to make it publicly viable it should be hexadecimal I think. The alternative, a hash is also nice since it keeps things more private.

We need to find a public Bitcoin Blockexplorer which can provide a JSON or CSV file for a certain transaction. Then we are going to write a small parser for the witness part of the transaction to proof how many keys signed the transaction.

[Anynomouss]

You are right, that would best. I have script that downloads transactions by transaction Id from blockchain.info (as JSON), not sure how to parse the witness part though, I have to check if the API also provides it. I could modify the script so a user can run:

python check_security_proof_transaction.py transaction ID

Output: message Output: signed by x/n keys

Alternatively I could just download all security proofs (OP_RETURN transactions to our address) so the user does not even need to enter the transaction Id:

python check_security_proof_CC.py

Output: message 1, signed by x/n keys Output: message 2 signed by x/n keys ...

I can make a start on that script, but it would be best to have a security proof transaction to test the code with.

[MCM-Mike]

Lets start with your script and iterate over it for better performance and reliability. But its a very good start to proof how many members signed a particular transaction.

[da2ce7]

Cross Post to Bitcoin Talk: https://bitcointalk.org/index.php?topic=5353221.0

[da2ce7]

@MCM-Mike and @Anynomouss

From the BitcoinTalk thread, the best solution is to make two transactions:

One with keys 1,2,3,4 and another with keys 1,2,5,6. This would be the most simple way to prove that the commitee has access to all the keys.

Credit to ETFbitcoin on BitcoinTalk: https://bitcointalk.org/index.php?topic=5353221.msg57646299#msg57646299

[MCM-Mike]

thank you very much @da2ce7 for helping here.

We are still following the two Bitcointalk threads [1] [2] , but we still struggling to automatically or semi-automatic distinguish the signatures and assign them to the different holders.

[Anynomouss]

To give an exact update on the bottleneck: -We have the signatures already, we parsed them from the Partially Signed Bitcoin Transaction (PSBT) text we exchanged when signing the transaction. These signatures can function as an alternative for making two transactions. -We do not have Python script yet to rebuild the raw transaction that is signed to, based on the transaction information requested from a json API. So what is needed, is: a) scripts to rebuild the raw transaction or getting the raw transaction directly from an API, b) a script to check the signatures against the individual Public keys in the Witness data. Actually it does not even need to be on individual public key signature level, even with a Python implementation of OP_CHECKMULTISIG or OP_CHECKMULTISIGVERIFY we can verify the transaction after replacing two signatures.

I found some information on how to build the raw transaction that is committed/signed to and how to do the signature checking in Python but did not manage yet to implement it yet: https://bitcoin.stackexchange.com/questions/62446/signature-verification-in-python#62468 https://bitcoin.stackexchange.com/questions/32305/how-does-the-ecdsa-verification-algorithm-work-during-transaction

[MCM-Mike]

Thank you everyone for the help and work you put into solving this problem.

Finding a correct solution might take another few more weeks or even months. Therefore I had a short meeting with John (@j01tz) about how we could solve this situation and proceed with the funding.

We agreed on the following possibility to proof we, the GRIN community council (CC), still has full access to all keys. We just move forward and produce threshold proof of spendability quarterly such that the keys rotate each time (so every 6 months all keys would have to produce a signature). from there we can always make improvements but it at least gets us started and over this hurdle.

Signing transaction over a period of a year:

Q1: Key1, Key2,Key3,Key4
Q2: Key5,Key6,Key{1..4},Key{1..4}
Q3: Key1, Key2,Key3,Key4
Q4: Key5,Key6,Key{1..4},Key{1..4}

in Q2 any key from 1,2,3,4 might be used additionally to the keys not beeing used in Q1

We don't have to spend every 3 month a transaction, we can just incorporate the scheme into our monthly payment schedule for GRIN projects and users.

We can always improve from this, but this is a start to get the CC funded in a timely manner.

Lets please have a vote on this on https://github.com/grincc/agenda/issues/9 @Anynomouss @davidtavarez @hendi, etc