QIP-2: Allow free UTXO creation

[Earlz]

Abstract

With this QIP, it would be possible for a user without coins to sign and prove their identity via a UTXO created from "nothing." This would primarily be useful only to contracts so that msg.sender can be set to an address that owns no coins or UTXOs

Motivation

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.

Specification

In order to allow UTXOs to be created out of nothing, a vin of txid 0 and vout number 0 can be spent infinite times and will have a value of 0. The vout script of this txid 0 and vout 0 is empty.

A new opcode is added named OP_VOUTSCRIPT. This opcode is only valid in the context of a scriptSig script for a vin of txid 0 and vout 0. When a vin of txid/vout 0 is encountered, the contents of the script after OP_VOUTSCRIPT will be used as the vout script of the txid/vout 0 vin for checking spendability.

Example:

4
OP_VOUTSCRIPT
2
OP_ADD
6
OP_EQUAL

In this case, the virtual vout script (which would be signed etc) would be

2
OP_ADD
6
OP_EQUAL

And the scriptSig would effectively be shortened to just "4". A more complicated example would be using a pubkeyhash script

PUSH <sig>
PUSH <pubKey>
OP_VOUTSCRIPT
OP_DUP
OP_HASH160
PUSH <pubKeyHash>
OP_EQUALVERIFY
OP_CHECKSIG

This would be signed etc just like a pay-to-pubkeyhash script. Specifically, referencing this diagram: https://en.bitcoin.it/wiki/File:Bitcoin_OpCheckSig_InDetail.png then everything would be the same, except for all of the script contents after OP_VOUTSCRIPT would become the "subscript" that is hashed and signed as part of txCopy. --- It seems like it'd be safe even without this mechanic (just treating it as no-op and leaving subscript empty) for pay-to-pubkeyhash.. is it safe for pay-to-scripthash and other common transaction types?

The account abstraction layer must be improved to detect these transactions and to properly detect the addresses used in them. When this is used to prove the ownership of address A for instance, msg.sender in Solidity should be A. (assuming the txid/vout 0 vin was the first input in the transaction). With x86 this concept must be extended to handle multisig and segwit addresses as well.

A number of restrictions are needed to keep this secure:

• Only SIGHASH_ALL signatures are allowed. Other types of signatures could be duplicated, compromising the security of the address, since anyone can copy that input and put it into their own transaction
• All transactions with a vin of txid/vout 0 must also have a valid normal vin. Otherwise this transaction would be valid and capable of being put into the blockchain multiple times, destroying the rule that each txid must be published only once and can not be duplicated.
• Only one OP_VOUTSCRIPT is allowed per script execution to simplify things and prevent edge cases
• OP_CALL and other contract executions are not valid in this (they are valid as vouts in such a transaction, but OP_CALL etc can not be placed in the scriptSig)
• Although this implies actual UTXO creation, it is still impossible to actually create a 0 value UTXO and send it to yourself. This rather allows for a special case of an infinitely spendable UTXO that is valid for any address that can be proven

Rationale

This method was chosen for the following reasons:

• Least likely to affect consensus, since the functionality is greatly restrained to a particular scenario
• This could potentially be possible without OP_VOUTSCRIPT, but would be considerably more complicated to do arbitrary pattern matching on scripts.
• This keeps the same transaction format and script functionality (OP_VOUTSCRIPT can be treated as a no-op for evaluation)
• This is backwards compatible to the EVM and of course can work much more seemlessly in x86 since in x86 it will be possible to use an array of msg.senders, rather than just one

Strategy

This would require a hardfork and could potentially be bundled into the x86 hardfork in 2019.

[JB395]

I like this proposal. For those DApps where the user wants to have the security and control of their own private key, this approach would allow them to sign a message, send that data out of band to the DApp server, which could create a transaction, paying the fee, to publish a UTXO on the blockchain for that user.

This would be a very good feature because it can be disconcerting to use a DApp which has no transactions seen on the Explorer for your address. It would let the user claim and verify their “account” on the blockchain (and trustless, decentralized) without having a UTXO or even owning any QTUM.

[Earlz]

Closed in favor of #6