Lecture3.pptx
Transcript
Nonce is like a number used in the process of proof-of-work. It is a part of the data that miners can modify. Miners repeatedly change the nonce value to get the hash that satisfies the puzzle. Hash cash is a system that prevents email spamming by making email senders perform a small amount of compu...
Nonce is like a number used in the process of proof-of-work. It is a part of the data that miners can modify. Miners repeatedly change the nonce value to get the hash that satisfies the puzzle. Hash cash is a system that prevents email spamming by making email senders perform a small amount of computational work to send an email. The nonce acts as a counter in hash cash, usually starting from zero. The sender increments the nonce value and combines it with the email content (a specific string) to calculate a hash. Attempt 1: "Hello, this is my email content. 0" -> Hash -> "000a1b2c3d..." Attempt 2: "Hello, this is my email content. 1" -> Hash -> "00e4f5g6h7..."... Attempt N: "Hello, this is my email content. N" -> Hash -> "000xyz1234..." The payload is the actual data or transactions you want to store in a block (like sending money or recording information). A blockchain includes – Nonce “Summary of payload” that contains a hash value of payload and other information This enables to check the validity of the new block using headers of block How can block chain resolve disagreements? By using Proof-of-work and the longest chain rule. When chain forks, Blockchain takes the fork with most work (i.e. longest chain). When there’s a tie, Blockchian keeps working until one of the chains has the most work. Proof-of-word (Summary) Miners don’t trust or know each other. Each miner is motivated by self-interest, aiming to earn rewards and transaction fees by successfully adding a new block to the blockchain. When a miner successfully mines a new block, they first verify the transactions within that block to ensure they are valid. Once verified, the miner spreads the newly created block to the rest of the network. Each node needs to verify the new block before they start mining. Miners are rewarded with newly created bitcoins for successfully mining a new block. (12BTC and then 6.25 bitcoins, this value will halve every 210,000 blocks) They have spent a significant amount of investment in Bitcoin so they tend to secure it from getting attacked. This works because Bitcoin is all about moving money around. Therefore, it’s easy to build payoffs into the protocol. Bitcoin Block Structure it's the sender who signs the transaction to prove ownership of the funds being transferred. An accountbased ledger (not Bitcoin) Need to scan backwards to check validity of new block A transactionbased ledger (Bitcoin) Merging value Joint payments Transaction = Output (first) + Input (then) Input: a reference to an output from a previous transaction. (where bitcoin comes from) Multiple inputs are often listed in a transaction. All new transaction's input values are added up. Previous tx is a hash of a previous transaction. Index is the specific output in the referenced transaction (0 or 1). ScriptSig is the first half of a script. Output: Instruction for sending bitcoins. There can be more than one output, and they share the combined value of the inputs. Value is the number of Satoshi (1 BTC = 100,000,000 Satoshi). This output will be worth when claimed. ScriptPubKey is the second half of a script. Bitcoin Script is a simple, stack-based programming language that is used to define the conditions under which a certain transaction output can be spent (in the future). namely, verify the validity of spending. The script contains two components: ScriptSig: a signature in Input generated by the spender (match previous output) ScriptPubKey: a public key of the recipient in Output. The public key (in the current transaction) must match the hash given in the script of the redeemed output (previous transaction). The public key is used to verify the signature of the redeemer. It, combined with the public key, proves the transaction was created by the real owner of the address in question. UTXO (Unspent Transaction outputs) : the amount of digital currency someone has left remaining in their wallet after Pay-to-public-key(P2PK) In Bitcoin, everyone has a pair of cryptographic keys: a public key (like an address where you receive mail) and a private key (like the key to unlock your mailbox). The public key is shared openly and is associated with your Bitcoin address. When someone sends you Bitcoin using the "Pay-to-Public-Key" method, they're essentially saying, "I'm sending this Bitcoin to the specific public key associated with your Bitcoin address.“ In technical terms, the sender creates a script (a small program) in the transaction output that specifies the conditions for spending the sent Bitcoin. For a "Pay-to-Public-Key" transaction, the script essentially says, "To spend this Bitcoin, someone needs to provide a signature that matches the public key.“ To spend the Bitcoin in the future, you (the recipient) need to use your private key to create a digital signature. When you want to spend the received Bitcoin, the Bitcoin network checks if your signature matches the public key specified in the transaction output. The "Pay-to-Public-Key" method simplifies the process by directly linking the received Bitcoin to your public key. It relies on the cryptographic security of public and private key pairs to ensure that only the rightful owner (possessing the private key) can spend the received funds. Pay-to-pubkey-hash (P2PKH) A Bitcoin address (of the recipient) is only a hash, so the sender can’t provide a full public key (of recipient) in scriptPubKey. When redeeming coins that have been sent to a Bitcoin address, the recipient (want to spend the coin) should provide both the signature and the public key. The script verifies that the provided public key does hash to the hash in scriptPubKey, and then it also checks the signature against the public key. Proof-of-burn : The primary purpose is to send coins to a burn account which cannot spend or redeem the coins sent to it. Pay-to-script-hash: enhance the flexibility and security of Bitcoin transactions. It was implemented to address certain limitations in the scripting language of Bitcoin transactions and to enable more complex spending conditions. Pay-to-multi signature: offers the users the capability to lock coins with a requirement for multiple parties to sign the scriptSig before coins can be spent. when a node hears about a new block and decides to relay it, it means that the node considers the block valid. Relay a new block when you hear it if: Block meets the hash target Block has all valid transactions Run all scripts, even if you wouldn’t relay Block builds on current longest chain Avoid forks Fully-validating nodes: Permanently connected Store entire block chain Hear and forward every node/transaction Lightweight nodes : Most nodes in Bitcoin network are lightweight nodes. These differ from fully validating nodes in that they don’t store the entire block chain. They only store the pieces that they need to verify specific transactions that they care about. Store block headers – verify the puzzle was solved correctly but cannot verify every transaction in each block! A hard fork is like a big, irreversible change in the rules of a blockchain. It's like saying, "From now on, we're doing things differently, and everyone has to follow the new rules.“ Hard forks create two distinct blockchains, one following the old rules and one with the new rules. A soft fork is like a more subtle, backward-compatible change in the rules. It's saying, "We're adjusting a few things, but everyone can still play along whether they upgrade or not.“ Soft forks maintain a single blockchain, and participants who haven't upgraded can still interact with those who have. Key Differences: 1. Outcome: Hard Fork: Creates two separate blockchains with different rules. Soft Fork: Maintains a single blockchain with backward-compatible rule changes. 2. Reversibility: Hard Fork: Irreversible; once the split happens, it's permanent. Soft Fork: Reversible; participants can still interact without upgrading. 3. Level of Agreement: Hard Fork: Requires a majority of the network to agree on the new rules. Soft Fork: Can be implemented with a majority, but non-upgraded nodes can still participate.
