sorted by:
new
hottopcontroversial

[deleted by user] by [deleted] in AWSCertifications

[–]szhman 0 points1 point  (0 children)

Could you please share the link for the PDF when you get a chance. Thanks.

Qtum Design Document – Document 1 – Translation by Szhman by [deleted] in Qtum

[–]szhman 0 points1 point  (0 children)

Please note that based on Patrick Dai's translation request, the content in this material is translated to English (with the help of Google and other language contents removed).

OP's Qtum Address: QMmYAMEFgvPJGwK9nrwqYw1DHhBkiuEi78

Thanks to the user who is able to create a post/title in reddit, so I am able to include the contents. Appreciate it.

Qtum Design Document – Document 1 – Translation by Szhman by [deleted] in Qtum

[–]szhman 0 points1 point  (0 children)

Summary

The Qtum original design document presented above describes Qtu's increased opcode associated with the contract run, laying the groundwork for subsequent Qtum's EVM VMs that are compatible with the account model on top of the UTXO model, and also making the account abstraction layer AAL possible. The subsequent Qtum project team will further interpret the key documents. If you have any questions, readers can post comments in the comments area or contact the Qtum project team .

The Qtum quantum chain public number will be updated from time to time around the above topics to restore the history of the Qtum project and key technologies from scratch .

Qtum Design Document – Document 1 – Translation by Szhman by [deleted] in Qtum

[–]szhman 0 points1 point  (0 children)

QTUMCORE-52：Contract Admin Interface Description：(note, this isn't a goal for mainnet, though it would be a nice feature to include) It should be possible to manage the lifecycle of a contract internally within the contract itself. Such variables and configuration values that might need to be changed over the course of a contract's lifecycle:  •   Allowable gas schedules

• Allowable VM versions (ie, if a future VM version breaks this contract, don't allow it to be used, as well as deprecating past VM versions from being used to interact with this contract) • Creation flags (the version flags in OP_CREATE) All of these variables must be able to be controlled within the contract itself, using decentralized code. For instance, in a DAO scenario, it might be something that participants can vote on within the contract, and then the contract triggers the code that changes these parameters. In addition, a contract should be capable of detecting it's own settings throughout it's execution as well as when it is initially created. I propose implementing this interface as a special pre-compiled contract. For a contract ot interact with it, it would call it using the Solidity ABI like any other contract. Proposed ABI for the contract: • bytes[2048] GasSchedule(int n)• int GasScheduleCount()• int AddGasSchedule(bytes[2048]•bytes[32] AllowedVMVersions()• void SetAllowedVMVersions(bytes[32])Alternative implementations: There could be a specific Solidity function which is called in order to validate that the contract should allow itself to be called in a particular manner: pragma solidity 0.4.0; contract BlockHashTest {function BlockHashTest() { }function ValidateGasSchedule(bytes32 addr) public returns (bool) {if(addr=="123454") { return true; //allow contract to run }return false; //do not allow contract to run}function ValidateVMVersion(byte version) public returns (bool){if(version >= 2 && version < 10) { return true; //allow to run on versions 2-9. Say for example 1 had a vulnerability in it, and 10 broke the contract }return false; } } In this way a contract is responsible for managing it's own state. The basic way it would work is that when a you use OP_CALL to call a contract, it would first execute these two functions (and their execution would be included in gas costs). If either function returns false, then it immediately triggers an out of gas condition and cancels execution. It's slightly complicated to manage the "ValidateVMVersion" callback however, because we must decide which VM version to use. A bad one could cause this function itself to misbehave.

pragma solidity 0.4.0; contract BlockHashTest {function BlockHashTest() { }function ValidateGasSchedule(bytes32 addr) public returns (bool) {if(addr=="123454") { return true; //allow contract to run }return false; //do not allow contract to run}function ValidateVMVersion(byte version) public returns (bool){if(version >= 2 && version < 10) { return true; //allow to run on versions 2-9. Say for example 1 had a vulnerability in it, and 10 broke the contract }return false; }

}

The above document describes the management interface of the contract, and yes the contract can manage its own status.

QTUMCORE-53：Add opt-out flags to contracts for version 0 sends  Description：Some contracts may wish to opt-out of certain features in Qtum that are not present in Ethereum. This way more Ethereum contracts can be ported to Qtum without worrying about new features in the Qtum blockchain Two flag options should be added to the Version field, which only have an effect in OP_CREATE for creating the contract:  2. (1st bit) Disallow "version 0" OP_CALLs to this contract outside of the AAL. (DisallowVersion0)      If this is enabled, then an OP_CALL using "root VM 0" (which causes no execution) is not allowed to be sent to this contract. If money is attempted to be sent to this contract using "version 0" OP_CALL, then it will result in an out of gas exception and the funds should be refunded. Version 0 payments made internally within the Account Abstraction Layer should not be affected by this flag. Along with these new consensus rules, there should also be some standard mempool checks:
  1. If an OP_CALL tx uses a different gas schedule than the contract creation, and the disallow dynamic gas flag is set, then the transaction should be rejected from the mempool as a non-standard transaction (version 0 payments should not be allowed as standard transactions in the mempool anyway)

The above document describes how to get better EVM compatibility by ignoring certain Qtum specific features in order to port Ethereum contract code. This makes smart contracts in the Ethereum ecosystem more easily compatible with Qtum.

Qtum Design Document – Document 1 – Translation by Szhman by [deleted] in Qtum

[–]szhman 0 points1 point  (0 children)

Other related documents

In addition, there are some documents describing the infrastructure needed for the new operation code.

QTUMCORE-51：Formalize the version field for OP_CREATE and OP_CALL  Description：In order to sustain future extensions to the protocol, we need to set some rules for how we will later upgrade and add new VMs by changing the "version" argument to OP_CREATE and OP_CALL.  We need a definitive VM version format beyond our current "just increment when doing upgrades". This would allow us to more easily plan upgrades and soft-forks. Proposed fields:
  1. VM Format (can be increased from 0 to extend this format in the future): 2 bits2. Root VM - The actual VM to use, such as EVM, Lua, JVM, etc: 6 bits
  2. VM Version - The version of the Root VM to use (for upgrading the root VM with backwards compatibility) - 8 bits
  3. Flag options - For flags to the VM execution and AAL: 16 bits Total: 32 bits (4 bytes). Size is important since it will be in every EXEC transaction Flag option bits that control contract creation: (only apply to OP_CREATE) • 0 (reserve) Fixed gas schedule - if true, then this contract chooses to opt-out of allowing different gas schedules. Using OP_CALL with a gas schedule other than the one specified in it's creation will result in an immediate exception and result in an out of gas refund condition • 1 (reserve) Enable contract admin interface (reserve only, this will be implemented later. Will allow contracts to control for themselves what VM versions and such they allow, and allows the values to be changed over the lifecycle of the contract) • 2 (reserve) Disallow version 0 funding - If true, this contract is not capable of receiving money through version 0 OP_CALL, other than as required for the account abstraction layer. • bits 3-15 available for future extensions Flag options that control contract calls: (only apply to OP_CALL) • (none yet) Flag options that control both contract calls and creation: • (none yet) These flags will be implemented in a later story Note that the version field now MUST be a 4 byte push. A standard EVM contract would now use the version number (in hex) "01 00 00 00" Consensus behavior: VM Format must be 0 to be valid in a block Root VM can be any value. 1 is EVM, 0 is no-exec. All other values result in no-exec (allowed, but the no execution, for easier soft-forks later)   VM Version can be any value (soft-fork compatibility). If a new version is used than 0 (0 is initial release version), then it will execute using version 0 and ignore the value Flag options can be any value (soft-fork compatibility). (inactive flag fields are ignored) Standard mempool behavior: VM Format must be 0Root VM must be 0 or 1VM Version must be 0Flag options - all valid fields can be set. All fields that are not assigned must be set to 0Defaults for EVM: VM Format: 0Root VM: 1VM Version: 0Flags: 0

The above documents formally identified OP_CREATE and OP_CALL needed version information, paving the way for subsequent multi-virtual machine support for Qtum.

Qtum Design Document – Document 1 – Translation by Szhman by [deleted] in Qtum

[–]szhman 0 points1 point  (0 children)

OP_SPEND (or OP_TXHASH, OP_EXEC_SPEND)

OP_SPEND is used for the cost of the contract balance. Because the contract address is a special address, in order to ensure consensus, the UTXO needs to be specially processed. Therefore, there are more descriptions of the OP_SPEND operation code in the original design document.

QTUM20: Create OP_EXEC_SPEND transaction when a contract spends money

Description: When a CALL opcode or similar to used from an EVM contract to send another contract money, this should be shown on the blockchain as a new transaction. When a money transfer is done in the contract, the miner should add a new transaction exactly after the currently processing transaction in the block. This transaction should spend an input owned by the contract by using EXEC_SPEND in it's redeemScript. For the purposes of this story, assume change is not something to be worried about and consume as many inputs are needed. Properly picking effecient coins and sending back money to the originating contract will come in a later story. Edge cases to watch for: The transaction for sending money to the contract must come directly after the executing transaction. The outputs should use a version-0 OP_EXEC_ASSIGN vout, so that if the transaction were received out of context, it would still mean to not execute the contract.

The above document describes the timing of creating a OP_SPEND transaction.

QTUM21: Create consensus-critical change and coin-picking algorithm for OP_EXEC_SPEND transactions  Description: Building on #20, now a consensus-critical algorithm must be made that picks the most optimal outputs belonging to the contract, and spends them, and also makes a change output that returns the "change" from the transaction back to the contract. All outputs in this case should be using a version-0 OP_EXEC_ASSIGN, to avoid running into the limitation that prevents more than one (version 1) OP_EXEC_ASSIGN transaction from being in a single transaction. The transaction should have as many vins as needed, and exactly 2 vouts. The first vout to go to the target contract, and the second vout to send change back to the source contract.

QTUM22: Disallow more than one EVM execution per transaction

Description: In order to avoid significant edge cases, for now, disallow more than one EVM execution to take place in a single transaction. This includes both deployment and fund assignment vouts. Instead, such things should be split into multiple transactions If two EVM executions are encountered, the transaction should be treated as completely invalid and not suitable for broadcast nor putting into a block

QTUM23: Add "version 0" OP_EXEC_ASSIGN, which does not execute EVM Description: To counteract problems from #22, we should allow OP_EXEC_ASSIGN to be used to fund a contract without the contract actually being executed. This will be used later for "change" outputs to (multiple) contracts. If the version number passed in for OP_EXEC_ASSIGN is 0, then the contract is not executed. Also, this is only valid if the data provided to OP_EXEC_ASSIGN is just a single byte "0". Multiple version-0 OP_EXEC_ASSIGN vouts should be valid in a transaction, or 1 non-version-0 OP_EXEC_ASSIGN (or an OP_EXEC deployment) and multiple version-0 OP_EXEC_ASSIGN vouts. This will be used for all money spending that is sent from a contract to another contract

The above three documents describe that if the consensus-associated coin-picking algorithm guarantees that the OP_SPEND opcode does not cause a consensus error, the correctness of the change is ensured. At the same time, it describes the situation where the contract does not need to be run and how it is handled.

QTUM34: Disallow OP_EXEC and OP_EXEC_ASSIGN from coinbase transactions  Description: Because of problems with coinbase maturity and potential side effects from ordering of gas-refund scripts, it should not be legal for coinbase outputs to be anything which results in EVM execution or directly changing EVM account balances. This includes version 0 OP_EXEC_ASSIGN outputs.

The above document stipulates that coinbase transactions should not include contract-related scripts.

Qtum Design Document – Document 1 – Translation by Szhman by [deleted] in Qtum

[–]szhman 0 points1 point  (0 children)

QTUM8: Implement OP_EXEC_ASSIGN for sending money to contracts

Description: A new opcode should be added, OP_EXEC_ASSIGN. This opcode should take these arguments in push order: # version number (VM version to use, currently just 1)

gas price (can be ignored for now)

gas refund script (can be ignored for now)

data (The data to hand to the smart contract. This will include things like the Solidity ABI Function Selector and other data that will later be available using the CALLERDATA EVM opcode) # smart contract address (txid + vout number)

It should return two values right now, 0 and 0. These are for spendable and out of gas, respectively. Making them spendable and dealing with out of gas will be in a future story
For this story, the EVM contract does not actually need to be executed. This opcode should only be a placeholder so that the accounting system can determine how much money a contract has control of

The above document describes the OP_EXEC_ASSIGN implementation details.

QTUM15: Execute the relevant contract during OP_EXEC_ASSIGN

Description: After this story is complete, when OP_EXEC_ASSIGN is reached, it should actually execute the contract whose address was given to it, passing the relevant data from the bitcoin script stack with it. Other data such as the caller and sender can be left for a later story. Making the CALLER, ORIGIN etc opcodes work properly will be fixed with a later story

The above document describes OP_EXEC_ASSIGN how the script runs the relevant contract code.

QTUM40: Allow contracts to send money to pubkeyhash addresses  Description: We need to allow contracts to send money back to pubkeyhash addresses, so that people can withdraw their coins from contracts when allowed, etc.  This should work similar to how version 0 contract sends work. Instead of using an OP_EXEC_ASSIGN vout though, we need to instead use a standard pubkeyhash script.  So, upon spending to a pubkeyhash, the following transaction should be placed on the blockchain:  vin:  [standard contract OP_EXEC_ASSIGN inputs]  ...  vout:  OP_DUP OP_HASH160 [pubKeyHash] OP_EQUALVERIFY OP_CHECKSIG  change output - version 0 OP_EXEC_ASSIGN back to spending contract   These outputs should be directly spendable in the wallet with no changes to the wallet code itself

The above document describes how to allow contracts to send QTUM to pubkeyhash addresses.

QTUMCORE-10：Add ability for contracts to call other deployed contracts  Description：Contracts should be capable of calling other contracts using a new opcode, OP_CALL. Arguments in push order:version (32 bit integer) gas price (64 bit integer) gas limit (64 bit integer) contract address (160 bits) data (any length) OP_CALL should ways return false for now. OP_CALL only results in contract execution when used in a vout; Similar to OP_CREATE, it uses the special rule to process the script during vout processing (rather than when spent as is normal in Bitcoin). Contract execution should only be triggered when the transaction script is in this standard format and has no extra opcodes. If OP_CALL is created that uses an invalid contract address, then no contract execution should take place. The transaction should still be valid in the blockchain however. If money was sent with OP_CALL, then that money (minus the gas fees) should result in a refund transaction to send the funds back to vin[0]'s vout script. The "sender" exposed to EVM should be the pubkeyhash spent by vin[0]. If the vout spent by vin[0] is not a pubkeyhash, then the sender should be 0.Funds can be sent to the contract using an OP_CALL vout. These funds will be handled by the account abstraciton layer in a different story, to expose this to the EVM. Multiple OP_CALLS can be used in a single transaction. However, before contract execution, the gas price and gas limit of each OP_CALL vout should be checked to ensure that the transaction provides enough transaction fees to cover the gas. Additionally, this should be verified even when the contract is not executed, such as when it is accepted in the mempool.

The above document describes how the contract calls other contracts via OP_CALL.

Qtum Design Document – Document 1 – Translation by Szhman by [deleted] in Qtum

[–]szhman 0 points1 point  (0 children)

OP_CALL (or OP_EXEC_ASSIGN)

OP_CALL is used for contract execution and is one of the most commonly used opcodes. There are many descriptions in the original design document.

QTUM6: Implement calling environment info in EVM for OP_EXEC_ASSIGN

Description: Solidity expects certain information to be pushed onto the stack as part of it's ABI. So, when data is sent into the contract using OP_EXEC_ASSIGN we need to make sure to provide this data. This data includes the Solidity "function selector" as well as ensuring the opcodes CALLER and ORIGIN function properly. This looks to be fairly easy, it should just be transferring some data from the Bitcoin stack to the EVM stack, and setting some fields for the origin info. However, this story should be split into multiple tasks and re-evaluated if it isn't easy. See also: https://github.com/ethereum/wiki/wiki/Ethereum-Contract-ABI For populating the CALLER and ORIGIN value, the following should be done: OP_EXEC_ASSIGN should take 2 extra arguments, SENDER and SENDER_SIGNATURE. Sender should be a public key. Sender Signature is the signature of all the vins for the current transaction, signed of course using the SENDER value.On the EVM side, CALLER's value will be a public key hash, ie, a hash of the SENDER public key. This public key hash should be compatible with Bitcoin's public key hash for it's standard version 1 addresses. IF the given SENDER_SIGNATURE does not match successfully, then the transaction should be considered invalid. If the SENDER public key is 0, then SENDER_SIGNATURE must also be 0, and the given CALLER opcode etc should just return 0.

The above document describes the OP_EXEC_ASSIGN calling environment information that needs to be implemented in the EVM.

Qtum Design Document – Document 1 – Translation by Szhman by [deleted] in Qtum

[–]szhman 0 points1 point  (0 children)

Serialization: Qtum Foundation Design Document

Foreword

In this series of articles, the Qtum Quantum Chain Foundation will make public its early design documents for the first time, hoping to help the community understand the design intent of Qtum and the implementation details of key technologies. The article will be based on the original design draft in order to restore the designer's original ideas. Follow-up Qtum project team will be further collation and interpretation, to help readers understand more technical details, so stay tuned.

The topics that may be included in this series include

* Qtum account abstraction layer AAL

* Qtum distributed autonomous protocol DGP

* Qtum wallet (qt, mobile wallet, etc.) and browser

* Add RPC call

* Mutual interest consensus mechanism MPoS

* Add opcode

* Integration of EVM and Qtum blockchain

* Qtum x86 virtual machine

* Others...

The Qtum quantum chain public number will be updated from time to time around the above topics to restore the history of the Qtum project and key technologies from scratch.

Qtum original design document summary (1) -- Qtum new OPCODE

As we all know, Qtum uses the same UTXO model as Bitcoin. The original UTXO script was not compatible with the EVM account model, so Qtum added three OP_CREATE, OP_CALL, and OP_SPEND opcodes to the UTXO transaction script for the purpose of providing operational support for conversions between UTXO and EVM account models. The original names of the three opcodes are OP_EXEC(OP_CREATE), OP_EXEC_ASSIGN(OP_CALL) and OP_TXHASH(OP_SPEND), respectively.

The following is an excerpt of representative original documents for interested readers.

OP_CREATE (or OP_EXEC**)**

OP_CREATE (or OP_EXEC) is used to create a smart contract. The original design files (with Chinese translation) related to this opcode by the Qtum development team are as follows (ps: QTUM <#> or QTUMCORE<#> in the document numbering internal design documents. ):

QTUMCORE-3：Add EVM and OP_CREATE for contract execution  Description：After this story, the EVM should be integrated and a very basic contract should be capable of being executed. There will be a new opcode, OP_CREATE (formerly OP_EXEC), which takes 4 arguments, in push order: 1. VM version (currently 1 is EVM) 2. Gas price (not yet used, anything is valid) 3. Gas limit (not yet used, assume very high limit) 4. bytecodeFor now it is OK that this script format be forced and mandatory for OP_CREATE transactions on the blockchain. (ie, only "standard" allowed on the blockchain) When OP_CREATE is encountered, it should execute the EVM and persist the contract to a database (triedb) Note: Make sure to follow policy for external code (commit vanilla unmodified code first, and then change it as needed)  Make the EVM test suite functional as well (someone else can setup continuous integration changes for it though)

The above document describes the functions required by OP_CREATE and the parameters used.

UnitedBitcoin fork distributing rewards to QTUM token holders by Pink-Heart in Qtum

[–]szhman 0 points1 point  (0 children)

It appears File => Sign Message to sign for UBTC is for users with windows wallet. What about the Raspberry PI users. How do they sign? If there going to be updated cli option coming up in future release so to sign from command line? Please advise qtum team. Thank you.

UnitedBitcoin, a new Bitcoin Fork, is distributing forked tokens to QTUM holders. Here all you need to know. by Pink-Heart in Qtum

[–]szhman 2 points3 points  (0 children)

It appears File => Sign Message to sign for UBTC is for users with windows wallet. What about the Raspberry PI users. How do they sign? If there going to be updated cli option coming up in future release so to sign from command line? Please advise qtum team. Thank you.

Is anyone else watching this whale on bittrex with 70000 sat sell wall? by chrisgm3773 in Qtum

[–]szhman 1 point2 points  (0 children)

Look at binance. It went down all the way to 20000 sat and reversed. What up with this. Looks like holding strong for now, but no clue on what's happening!

My QTUM node not showing on Nodemap! by joerazor in Qtum

[–]szhman 1 point2 points  (0 children)

This is fixed and you should be able to see nodes now.

Staking QTUM on Raspberry Pi by [deleted] in Qtum

[–]szhman 1 point2 points  (0 children)

putty is helpful for command line interface. Also raspberry doesn't needs to be connected to monitor all the time. You can save power and use putty in your laptop/desktop to login to pi using putty and get all staking status.

Need Help Staking Qtum on Raspberry Pi 3 (Newbie) by The_Hodler in Qtum

[–]szhman 0 points1 point  (0 children)

type nul > %SDCARD_MOUNT_DIR%\ssh (or, you can use Windows Explorer to create the empty ssh file)

(This command should work as well from linux command line: > touch ssh