What is the best way to prove to a title agency that a particular bitcoin transaction has occurred and that the addresses do indeed belong to the parties exchanging the title?
Things to prove:
- Address A belongs to Person 1
- Person 1 controls the private key allowing spending from Address A
- Address B belongs to Person 2
- Person 2 controls the private key allowing spending from Address B
- Address A belongs to Person 1
- Transaction T transferring an amount from Address A to Address B
- was transmitted
- was accepted
- was confirmed
- was included in a block
- the block is a part of the longest chain, the blockchain.
Proving ownership of an address
Ownership is significantly easier to prove, provided that judge (to whom all this is proven), accepts either: economic activity or digital signature as proof of control of a private key.
Unfortunately, there is time and/or value cost to proving economic activity.
The judge could
- ask each prover to reproduce the transaction at a given time, but at a negligible amount: 1 satoshi plus a sufficient transaction fee. That the original transaction could be reproduced with only the amount changing, and a reverse of the transaction executed as well, should suffice to demonstrate that each Person controls the private key sufficiently to engage in economic activity.
- ask each prover to send 2 satoshi plus double the sufficient transaction fee to the same address: an address supplied by the judge, who then returns half of what was sent to demonstrate their own control of the address to which the 2 satoshi transaction was sent. This demonstrates that Person 1, Person 2, and the judge all control the addresses they say they do sufficient to engage in economic activity.
The costs of either of these are obvious, but generally sufficiently negligible as not to be a significant burden on any party involved. The transaction fees could be omitted, provided the transferred amount is sufficiently large to be both processed without transaction fee and trusted to be returned by the recipient.
The trust of these transactions could be increased by the judge assigning a random two-digit amount of satoshis to each transaction, or basing that random amount on an agreed-upon, yet-to-happen event with an expected time period within which the proving transactions must be transmitted to the judge. An example of a yet-to-happen event would be a newspaper headline or simply the leftmost two numbers in the 10th oldest block at a certain date and time.
Another, more convoluted yet more humanly trustworthy way would be for the judge to provide a private key to each prover. The prover then transmits an amount to an address controllable by that private key, then immediately returns that same amount using the provided private key. The judge has temporary control, though, so trust in the judge is necessary.
This method is infeasible if the parties are unable to broadcast the transactions to the network or the time necessary for transaction confirmation is too long.
If the judge is familiar with how digital signatures work, or can be convinced of their validity, then this is an option. Some effort might be worth it, as this option is without economic expenditure and does not require the time necessary for the proving transactions described above to be confirmed by the network.
The judge provides a unique text to each prover. This phrase can be something sensible or randomly generated. Random is probably better, largely because it would take less time to generate. Alternatively, basing that text on an agreed-upon, yet-to-happen event with an expected time period within which the signature must be transmitted to the judge. An example of a yet-to-happen event would be a newspaper headline or simply the leftmost two numbers in the 10th oldest block at a certain date and time.
The signatures should be sent among all parties, so that all adversarial parties can verify the signature.
Remember that the point of this exercise is to demonstrate control of the private key. A downside of this is that not all wallet softwares support signing data, most commonly because the private keys backing the wallet are not exposed to the user in anyway except for the purposes of signing transactions. If a prover claims that their software does not have this functionality, this method is infeasible. The prover could be convinced to use another software, but that could compromise their position if they could be tricked into using malicious software, if a false positive proof of control is undesirable.
A combination of the two
Each of these methods has strengths and weaknesses, so a combination of the two would likely provide the most confidence proving control of a private key, and thus control of an address.
Proving that a transaction occurred
The easiest way for a judge to verify that any given transaction occurred is to use a trusted blockchain explorer program, since few wallet programs expose functionality enabling the user to search the blockchain by address, transaction, or block.
The judge can use the explorer verify the activity of each address in question, as well as the transaction itself. It is up to the judge to verify that the transaction has been a part of the longest chain for a permissible number of blocks. One block depth is sufficiently secure against most attacks that would cancel the transaction, but each additional block depth further solidifies the transaction.
This does not necessarily require network connectivity if the transaction occurred sufficiently far in the past that the judge's own copy of the blockchain can be explored.
If the judge does not have access to a copy of the blockchain, the desired proof cannot be surely obtained. Given the raw transaction, the judge can use the digital signature method to verify that Person 1 has control of Address A, as the raw transaction will contain a verifiable signature. However, the raw transaction itself contains nothing that would enable to the judge to verify Person 2's control of Address B.