Distributed ledgers open up a new world of possibilities and opportunities. From Bitcoin to Ethereum to Qtum, each offers a unique platform to solve different problems. Qtum was born to allow distributed applications to be built on a foundation similar to Ethereum, but using the Bitcoin UTXO model to add more stable features.
As mentioned in the previous article, Jordan Earls, co-founder and lead developer of Qtum Quantum Chain, recently published a proposal for free UTXO generation on Qtum quantum chain. In this article, we will cover more implementation details.
This technical proposal will help global DAPP users to use DAPP services without holding tokens, and attract more users to experience decentralized applications without being bound by fees
”
The Qtum team found that the implementation of functionality on blockchains that use the account model, such as Ethereum, is very complex and, to this day, has not been found on other chains. On Qtum, full-featured development is implemented as a Qtum extension tool.
Where does the fee come from?
Previously, transaction fees had to be paid by the owner of the address where the message was broadcast. Suppose an organization is running a DApp on a chain that distributes some form of identity to get proof of identity, and they need to call the smart contract through a transaction so that it can register the address to the user, who has to pay a fee to call the smart contract that distributes the ID.
But what if the user doesn’t have any cryptocurrencies and doesn’t want to buy something for a single transaction? With the third-party payment fee feature, users can still call contracts that issue ids without having to own any cryptocurrency. Now the escrow agency can bear the transaction costs, even though it does not actually own the transaction.
The overall process is: first build the original transaction, then swap with the third party, and sign the swap agreement, and finally broadcast. The seemingly simple function of agency payment has corresponding operation requirements for the operator’s blockchain code, and this function is still in internal testing. We will fully support all DAPP applications on Qtum when it is developed.
Technology demonstration
Before reading on, check out this guide for the basics of the original trade. (bitcoin.org/en/develope… This guide applies to bitcoin, but since Qtum is built as a branch of Bitcoin, you can use Qtum qcli docker regtest because the commands are the same)
Use the qCLI command createrawTransaction to generate the initial transaction. Here are the inputs that need to be provided:
Arguments:
1. “inputs” (string, required) A JSON array of JSON objects [ { “txid”:”id”, (string, required) The transaction id “vout”:n, (numeric, required) The output number “sequence”:n (numeric, optional) The sequence number } ,… ] 2. “outputs” (string, required) a JSON object with outputs { “address”: x.xxx, (numeric or string, required) The key is the qtum address, the numeric value (can be string) is the QTUM amount “data”: “hex” (string, required) The key is “data”, the value is hex encoded data ,… } 3. locktime (numeric, optional, default=0) Raw locktime. Non-0 value also locktime-activates inputs Result: “transaction” (string) hex string of the transaction
We provide the following information:
createrawtransaction ”’
[
{
“txid”: “0000000000000000000000000000000000000000000000000000000000000000”,
“vout”: “0”
}
]
”’ ”’
{
“data”:
“0000000000000000000000000000000000000000000000000000000000000000”
}”’
Setting ‘txID’ to 0 still works, but without giving it a valid UTXO ID to collect fees, there is not enough money to accept the transaction.
In the “data” field, you actually specify the hexadecimal encoded data as the contract call to be made. In this example, 0 (nullData) is only used for demonstration purposes. The output will be a hexadecimal string that you can decode with the qCLI command ‘decoderawTransaction’ to retrieve the original transaction. We get the following original deal:
{ “txid”: “09e0bdb5d819827d7aecfd7d5dcaecc84e240078d9e86a72c8348b3d0b5931f5”, “hash”: “09e0bdb5d819827d7aecfd7d5dcaecc84e240078d9e86a72c8348b3d0b5931f5”, “size”: 94, “vsize”: 94, “version”: 2, “locktime”: 0, “vin”: [ { “txid”: “0000000000000000000000000000000000000000000000000000000000000000”, “vout”: 0, “scriptSig”: {” asm “:” “, and “hex” : “”},” sequence “: [{4294967295}],” vout “:” value “: 0.00000000,” n “: 0,” scriptPubKey “: {” asm” : “OP_RETURN 0000000000000000000000000000000000000000000000000000000000000000”, “hex”: “6a200000000000000000000000000000000000000000000000000000000000000000”, “type”: “nulldata” } } ] }
Now we need to add some opcodes to ‘vin’ :
SIGHASH_ANYONECANPAY | SIGHASH_SINGLE
These opcodes will make this use case possible, and they basically allow anyone else to pay for the transaction, not just the owner of the transaction. The original transaction should now look like this:
{ “txid”: “09e0bdb5d819827d7aecfd7d5dcaecc84e240078d9e86a72c8348b3d0b5931f5”, “hash”: “09e0bdb5d819827d7aecfd7d5dcaecc84e240078d9e86a72c8348b3d0b5931f5”, “size”: 94, “vsize”: 94, “version”: 2, “locktime”: 0, “vin”: [ { “txid”: “0000000000000000000000000000000000000000000000000000000000000000”, “vout”: 0, “scriptSig”: { “asm”: “SIGHASH_ANYONECANPAY | SIGHASH_SINGLE”, “hex”: “” }, “sequence”: 4294967295 } ], “vout”: [ { “value”: 0.00000000, “n”: 0, “scriptPubKey”: “OP_RETURN 0000000000000000000000000000000000000000000000000000000000000000”, “hex”: “6a200000000000000000000000000000000000000000000000000000000000000000”, “type”: “nulldata” } } ] }
We now have a valid deal. Because we can’t pay the fee, the blockchain can’t accept the transaction yet. You can now send the original transaction (off-chain) to a third party. The third party then creates another standard original transaction where a ‘txID’ with a valid UTXO can have enough funds to pay the fee and sign. They then send you the transaction’s signature “VIN” (again off the chain), which looks something like this:
{ “txid”: “7087daa5c9859a0118a125285f2040c738e5f4d3caaf4d0840da3b183d64fdff”, “vout”: 0, “scriptSig”: { “asm”: “304402204155babf1390197b070cb92e9bf6ec88906e294c7921cb3a76bdbee5f6651058022016e13949dbecdb70eb99d50e7f6e388963cef104a4d 769113d661b488532f9b6[ALL]”, “hex”: “47304402204155babf1390197b070cb92e9bf6ec88906e294c7921cb3a76bdbee5f6651058022016e13949dbecdb70eb99d50e7f6e388963cef104a 4d769113d661b488532f9b601” }, “sequence”: 4294967295 }
Now we need to add the signed “vin” to the list of Vins in the original transaction we are processing:
{ “txid”: “09e0bdb5d819827d7aecfd7d5dcaecc84e240078d9e86a72c8348b3d0b5931f5”, “hash”: “09e0bdb5d819827d7aecfd7d5dcaecc84e240078d9e86a72c8348b3d0b5931f5”, “size”: 94, “vsize”: 94, “version”: 2, “locktime”: 0, “vin”: [ { “txid”: “0000000000000000000000000000000000000000000000000000000000000000”, “vout”: 0, “scriptSig”: { “asm”: “SIGHASH_ANYONECANPAY | SIGHASH_SINGLE”, “hex”: “” }, “sequence”: 4294967295 }, { “txid”: “7087daa5c9859a0118a125285f2040c738e5f4d3caaf4d0840da3b183d64fdff”, “vout”: 0, “scriptSig”: { “asm”: “304402204155babf1390197b070cb92e9bf6ec88906e294c7921cb3a76bdbee5f6651058022016e13949dbecdb70eb99d50e7f6e388963cef104a4d 769113d661b488532f9b6[ALL]”, “hex”: “47304402204155babf1390197b070cb92e9bf6ec88906e294c7921cb3a76bdbee5f6651058022016e13949dbecdb70eb99d50e7f6e388963cef104a 4 d769113d661b488532f9b601 “}, “sequence” : 4294967295}], “vout” : [{” value “: 0.00000000,” n “: 0,” scriptPubKey “: { “asm”: “OP_RETURN 0000000000000000000000000000000000000000000000000000000000000000”, “hex”: “6a200000000000000000000000000000000000000000000000000000000000000000”, “type”: “nulldata” } } ] }
This transaction now has the original “vin”, where “TXID” is 0, and the signature “vin” from the third party has a valid UTXO “TXID”, which is used to pay the transaction fee. ‘vout ‘contains the information for invoking the smart contract. All that remains is to sign the transaction one last time and be ready to broadcast it to the blockchain. After that, the contract is successfully invoked and the fee is paid by a third party.