Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
QIP-5: Signature proofs within vout scripts for contract transactions #6
This is written as a counter proposal to QIP-2.
With this QIP, it would be possible for a user to sign and prove their identity to a contract without owning any UTXOs/coins owned. This would primarily be useful only to contracts so that msg.sender can be set to an address that owns no coins or UTXOs. This would not allow free transactions, someone else must still pay for the transaction to be placed into the blockchain
The way contracts figure out who sent the message (and authenticate it) is to check “ok, did this person spend a UTXO in this transaction” (even if they merely spent it and sent all the funds back to themselves). This sounds a bit wasteful, but the worse problem is that without a UTXO it’s impossible to authenticate that you’re sending a message to the contract. Even if someone else pays the fees and everything else for you, you still need a UTXO to really do anything with most contracts. This issue commonly comes up in other cases as well. Your wallet has multiple addresses and each address has it’s own set of UTXOs. The blockchain is incapable of knowing that those addresses belong to the same wallet. So, what happens when you choose to send QRC20 tokens to some certain address, but then find out that address has no UTXOs. You will be incapable of spending the QRC20 tokens, since you have no way of proving to the contract that you are that certain address. The official workaround for this problem is to simply send that certain address any amount of coins (even 1 satoshi) so that it has a UTXO, and then you can withdraw your QRC20 tokens or whatever. Later, Qtum Core will (by default) make sure to use change addresses to ensure that address always has a UTXO.
This is wasteful of precious UTXO set space, but most of all it’s incredibly annoying for user experience of both Dapps and Qtum users.
A new opcode named
OP_SENDER will cause an internal script execution. It will fail if the end result is not 1. For this example, it would look like so:
The serialized scriptSig would be treated the same as if it were a normal scriptSig for validation purposes. If the end result evaluates to 0, the transaction is invalid and can not be included in a block. For pay-to-scripthash senders, the scriptSig would be treated the same as normally, with the script being executed twice. First, to check the hash is the same as the scripthash, and then again to execute the redeemScript for spending P2SH outputs.
The actual data to be signed will be a special case. Normally in Bitcoin and Qtum, only scriptSig scripts within the vin contains signatures, thus it is easy to come up with a signing scheme to avoid the "signing signed data" problem. However, this scheme breaks that assumption by having signatures inside of vout scripts. In order to avoid breaking existing Bitcoin based paradigms, signing will thus be split into two separate steps:
The vin signing process will be untouched, and thus signatures within the vouts will be signed by vin signatures. This is suboptimal, but is much safer and less complex.
The vouts will be signed as normally done for vins, but with the OP_SPENDER scriptSig changed to a zero size value. See https://en.bitcoin.it/wiki/OP_CHECKSIG for the signature signing schemes. The following modifications must be made however:
This method supports all of the features of the previous iteration of this proposal while including the following improvements:
However, it does carry the following downsides:
This would require a hardfork and could potentially be bundled into the x86 hardfork in 2019.