Block chain question and answer day4

Block chain question and answer day4

Why UTXO?

UTXO fully simulate the use of cash to spend and give change, except for every sum UTXO and the whereabouts of sources can all be traced.

Use UTXO also help to improve the anonymity, to receive and send UTXO can better protect your privacy by generating a large number of addresses.

Use UTXO compared to the balance system is also less likely to be tampered with, any illegal UTXO increases and decreases will lead to conflicts of books, unable to reach break even.

In the decentralized system, the account of creation and destruction can not be fully tracked, will significantly enhance the ability to compute node requirements, which would undermine the degree of decentralized systems.

To determine whether a sum of UTXO is consumed or determine whether the same transaction is repeatedly transaction (replay attack), in the center of the system need to design a unique identification (ID) let the server know that this is the same transaction. And there is no central server in such a decentralized system of uniform distribution ID, it must traverse back from the beginning of creation block to determine whether it is repeat business. Bitcoin put in all UTXO called UTXO set into the cache, greatly reducing the burden on the node.

Is calculated in the chain, the result is both proof of the transaction itself. Node can only verification is not required for transactions additional calculations, there is no additional state storage. Calculate the output UTXO of the transaction itself is completed in the wallet, the computational burden of such transactions to be undertaken exclusively by the wallet, chain reduces the burden to some extent.

UTXO What are the disadvantages?

  • UTXO stateless model will force the transaction contains status information, which makes the design contract is unnecessarily complicated.
  • We can not achieve some of the more complex logic, programmable poor.
  • Complexity UTXO will achieve even greater than the theoretical in actual use, such complexity is not necessary.

How transaction signature is constructed?

Signature process is the first to be signed to do a hash of information processing, and cryptographic operations for this hash value with the private key to obtain signature information. The sender information and the signature submitted with the original to the recipient, the recipient using the public key of the sender to decrypt the signature, the hash value is restored, then the authentication information through a hash algorithm hash value and the decrypted signature reduction scattered out column values ​​are the same, thereby identifying whether the information from the sender to verify information or tampering.

Tx are each transaction includes n input + m th output + LockTime. Due to enter a transaction may have multiple outputs, so the signature also has a variety of types.

  1. SIGHASH_ALL

    ** This signature type is the default type, is currently used in the vast majority of transactions. ** sign all transaction information, there are n inputs n signatures, meaning I recognize transactions in the input, output, and I agree that it takes my pen.

  2. SIGHASH_NONE

    ** This signature is only input and lock time signature, no signature output. ** mean I approved the deal in the input, and agreed to spend my expenses, as this money to whom it went, I do not care.

  3. SIGHASH_SINGLE

    ** This type of signature is only for their own input and output signature sequence and other fields blank. ** mean in this list, I agree that I spend that money, and I can only take the approved output, as the list of other inputs, outputs, I do not care.

  4. SIGHASH_NOINPUT

    This signature pattern used in lightning network

After configuration contains input, output, and lock time of the blank transaction, using ECDSA algorithm "hex" field blank to sign the transaction, when completed, will autograph signature values ​​into the blank field, resulting in a complete transaction. Finally, the transaction broadcast to the nodes in the network.

How to trade in the script work?

Trading ideas Bitcoin is as follows: the originator of the transaction reward of several Bitcoin, and posted a problem on the network, who has the solution to this problem is, who should reward it. Along the way, Alice transfers Bob to Alice can be understood as the one and only Bob can unlock the title sent to the network, Bob solve problems and took the reward. Then, "script" for each transaction data that appears in the title is reconciliation, "scripting language" is used to describe reconciliation tool problem.

In the transaction structure, we see a "vin" field and "vout" field in the "vin" field "scriptSig" in "asm" is a long list of characters, it is the public key and signature script strings in Bitcoin trading ideas, which is the sum of a long string of characters that is the solution UTXO output.

We can see there is a similar assembly language statement "vout" field, which is a bit currency trading ideas in question. In the problem-solving process, we will want to try solving the "scriptSig" and "scriptPubKey" to connect. Form "<Sig> <PublicKey> OP_DUP OP_HASH160 <PublicKeyHash> OP_EQUALVERIFY OP_CHECKSIG" script execution statement.

Means that the first recipient's signature and public key pushed onto the stack, then the recipient public key top of the stack. Copy reuse OP_DUP pushed onto the stack and then the stack, when the stack from top to bottom three elements PublicKey , PublicKey , Sig . Re-use of the top of the stack elements OP_HASH160 SHA256 hash, then the hash ripemd-160. The public key hash output script onto the stack (that is, I do not know the meaning of that string string). OP_EQUALVERIFY pop stack using two elements, are compared for equality, equal, proceed to the next command, not equal pressed false. Finally, the sign test operation, if the returns are equal success, otherwise fail.

How the transaction is to be verified?

After the newly created transaction, the transaction will be broadcast to the network nodes, each node receives transaction will authenticate transactions, to ensure that only valid transactions will be spread in the network.

When the transaction verification node will comply with a list of criteria, such as:

  • The syntax and structure of the transaction data must be correct
  • Input and output list can not be empty
  • Byte size of the transaction is less than blockmaxweight (bitcoin core 0.16.1 and above)
  • Each output value and the total amount must be within a predetermined value (greater than 0 and less than a coin 2x10⁶)
  • No hash is equal to 0, N-1 equal to the input (Coinbase transaction is not to be relayed)
  • nLockTime of less than or equal INT_MAX
  • Trade byte size is greater than or equal to 100
  • The number of signatures transactions should be less than the upper limit of the number of signatures operation
  • Scripts can be unlocked only digital pushed onto the stack, and lock the script must meet isStandard format (the non-standard format will reject the transaction)
  • Pool or in a transaction matching the main branch block must exist
  • For each input, if present in the reference output of any transaction pool, the transaction will be denied
  • For each input, the main branch and transaction pool looking output transaction reference. If anything is missing input output transaction, the transaction will be referred to an isolated transaction. If its matching transaction has not yet appeared in the pool, then the pool will be added to an isolated transaction.
  • For each input, the output is referenced must exist, and is not spent
  • For each input and output if the referenced transaction is a Coinbase output, the input must be at least COINBASE_MATURITY confirmation
  • Transaction using the output reference value input is obtained, and checks each input value and the total value is within a predetermined range (greater than 0 and less than a 2.1x10⁶ credits)
  • If the sum of the input values ​​is less than the sum of the output value, the transaction will be terminated
  • If the transaction costs too low to enter the empty block, the transaction will be rejected
  • Each script input unlock the lock must be verified based on the script corresponding output

These conditions change over time, in order to deal with new denial of service attacks, sometimes because of the type of transaction to diversify and to relax the rules.

After the node receives authenticate transactions, the transaction will establish a pool in the order received.

Guess you like

Origin www.cnblogs.com/nykuvl/p/12084704.html