Unit 5: Alternative Coins and Smart Contracts - Subjective Questions

An altcoin, or alternative coin, is a cryptocurrency developed as an alternative to Bitcoin. Some altcoins are created by modifying Bitcoin's source code, while others use completely new blockchain architectures.

Reasons for introducing altcoins include:

• Technical experimentation: To test new consensus mechanisms, cryptographic techniques, and network structures.
• Faster transactions: Some altcoins reduce block-generation time to provide quicker confirmations.
• Greater scalability: Alternative designs may support higher transaction throughput.
• Improved privacy: Privacy-focused coins can hide transaction amounts, senders, or recipients.
• Different monetary policies: Altcoins may use different supply limits, issuance schedules, or inflation models.
• Programmability: Platforms such as Ethereum support general-purpose smart contracts.
• Specialized applications: Some coins are designed for governance, storage, gaming, payments, or decentralized finance.

Thus, altcoins extend the cryptocurrency ecosystem by addressing perceived Bitcoin limitations and introducing new features.

Altcoins generally rely on the same broad theoretical foundations as Bitcoin, although individual systems may modify them.

1. Cryptography

• Cryptographic hash functions provide integrity, block linking, and proof-of-work puzzles.
• Public-key cryptography allows users to sign transactions digitally.
• A digital signature proves authorization without revealing the private key.

2. Distributed systems

• Blockchain nodes communicate over a peer-to-peer network.
• Replication ensures that many nodes maintain a copy of the ledger.
• Consensus mechanisms enable nodes to agree on a valid ledger despite failures or malicious participants.

3. Byzantine fault tolerance

• A blockchain must continue operating even if some nodes behave dishonestly.
• Proof of Work, Proof of Stake, and related mechanisms provide different approaches to Byzantine agreement.

4. Game theory and incentives

• Block rewards, transaction fees, and penalties encourage rational participants to follow protocol rules.
• An effective system makes honest behavior more profitable than attacks.

5. Economic theory

• Scarcity, token issuance, inflation, demand, and network effects influence a coin's value.
• Tokenomics determines how tokens are created, distributed, used, and removed from circulation.

6. Data structures

• Blocks, hash pointers, Merkle trees, and authenticated state structures make tampering detectable.

An altcoin therefore combines cryptography, distributed consensus, economic incentives, and peer-to-peer networking to maintain a decentralized digital asset.

Mining difficulty represents how hard it is for a miner to find a block hash satisfying the network's Proof-of-Work target. A higher difficulty corresponds to a smaller acceptable target and therefore requires more hash attempts on average.

If is the target, a valid block normally requires:

Difficulty is commonly expressed relative to a reference target :

Suppose a protocol expects blocks to take a target period , but they actually take . A simplified retarget formula is:

Equivalently, the target can be adjusted as:

• If blocks are generated too quickly, then , so difficulty increases.
• If blocks are generated too slowly, then , so difficulty decreases.

For example, if blocks expected to take 14 days are produced in 7 days, the simplified calculation doubles the difficulty:

Real protocols also place limits on each adjustment to prevent extreme or manipulated changes.

Difficulty-retargeting algorithms seek to maintain a stable average block interval despite changes in network hash power.

Bitcoin's periodic retargeting

• Bitcoin recalculates difficulty after a fixed window of 2,016 blocks.
• The algorithm compares the actual time for the window with the expected time.
• Adjustments are bounded to avoid excessively large changes.
• It is relatively stable but reacts slowly to sudden changes in hash rate.

Per-block retargeting

• Difficulty is updated after every block or after a very short interval.
• It reacts quickly when miners enter or leave the network.
• It is useful for smaller altcoins with highly variable hash rates.
• Poorly designed versions may produce oscillations or be sensitive to timestamp manipulation.

Moving-average algorithms

• These use the average block time over a recent window.
• They smooth short-term randomness while reacting faster than Bitcoin's long window.
• Examples include simple and weighted moving averages.

Weighted or damped algorithms

• Recent blocks may be given greater weight than older blocks.
• Damping limits abrupt changes and reduces instability.

Major trade-offs

• Responsiveness versus stability: Short windows react quickly but may overreact to random block intervals.
• Security versus convenience: Timestamp dependence can expose a system to manipulation.
• Large versus small networks: Large networks can tolerate slow periodic adjustment, whereas small networks often need faster retargeting.

A sound algorithm must maintain predictable block production without allowing miners to exploit oscillations, timestamps, or rapid hash-rate migration.

Bitcoin was designed primarily as decentralized electronic money and has several practical and architectural limitations.

• Limited throughput: Only a restricted number of transactions can be recorded in each block, resulting in relatively low transactions per second.
• Confirmation delay: Bitcoin's average block interval is approximately ten minutes, and high-value transactions may require multiple confirmations.
• Fee variation: During congestion, users compete for block space by offering higher transaction fees.
• Energy consumption: Proof-of-Work mining requires significant computational power and electricity.
• Restricted programmability: Bitcoin Script intentionally supports a limited scripting model rather than general-purpose computation.
• Privacy limitations: Transactions are pseudonymous but publicly visible, allowing address and transaction analysis.
• Governance challenges: Protocol upgrades require broad social and technical agreement and may lead to forks.
• Scalability trade-offs: Increasing capacity directly on-chain can increase storage, bandwidth, and node-operation requirements.

These limitations motivated altcoins and layered protocols offering faster settlement, different consensus mechanisms, stronger privacy, smart contracts, and specialized use cases.

Extended protocols operate above or alongside Bitcoin and use its blockchain as a settlement, security, or timestamping layer.

Major approaches include:

• Layer-two payment channels: Users lock funds in an on-chain transaction and exchange many signed off-chain updates. Only opening and closing transactions normally reach the blockchain. The Lightning Network follows this approach.
• Sidechains: Assets are transferred or represented on a separate blockchain that supports different features. A mechanism links the sidechain asset with Bitcoin.
• Overlay or meta-protocols: Additional rules interpret specially formed Bitcoin transactions to represent tokens, assets, or application-specific messages.
• Atomic swaps: Hash locks and time locks permit peer-to-peer exchange between compatible blockchains without a centralized exchange.
• Timestamping and anchoring: A hash of external data or another ledger state is committed to Bitcoin, using Bitcoin's immutability as evidence that the data existed at a particular time.

Advantages include reduced main-chain load, faster transactions, and additional functionality. Limitations include greater protocol complexity, new trust assumptions, liquidity constraints, and possible security differences between the extension and Bitcoin itself.

The development of an altcoin involves technical, economic, security, and community decisions.

1. Define the purpose

• Identify the problem to be solved and determine whether a new coin is actually required.
• Specify intended users and use cases.

2. Select the architecture

• Fork an existing cryptocurrency, create an independent blockchain, or issue a token on an existing platform.
• Choose the consensus mechanism, networking model, block interval, and transaction structure.

3. Design tokenomics

• Determine maximum supply, issuance rate, rewards, fees, token allocation, and vesting.
• Analyze incentives for validators, users, and developers.

4. Implement the protocol

• Develop node software, wallets, APIs, smart contracts, and network tools.
• Publish clear technical documentation and, where appropriate, open-source code.

5. Test and audit

• Run unit, integration, testnet, performance, and adversarial tests.
• Commission independent security audits.

6. Determine distribution

• Choose fair launch, mining, airdrop, private sale, public sale, or another method.
• Avoid excessive concentration and disclose insider holdings.

7. Launch and maintain the network

• Release genesis parameters and bootstrap nodes.
• Monitor security, fix defects, coordinate upgrades, and support users.

8. Build governance and compliance

• Establish an upgrade process and treasury mechanism.
• Address applicable securities, taxation, consumer-protection, and anti-money-laundering requirements.

A successful launch requires more than code; it needs sound incentives, transparent governance, sufficient decentralization, security, and an active ecosystem.

• Coin: A native asset of an independent blockchain. It is commonly used for transaction fees, block rewards, and value transfer.
• Token: A digital asset issued through a smart contract or protocol on an existing blockchain. It does not necessarily operate its own consensus network.
• Stablecoin: A coin or token designed to maintain a relatively stable value, often relative to a fiat currency. Stability may be supported by reserves, crypto collateral, or algorithmic mechanisms.
• Privacy coin: A cryptocurrency designed to improve transaction confidentiality through techniques such as stealth addresses, ring signatures, or zero-knowledge proofs.
• Utility token: A token intended to provide access to a service, resource, application feature, or protocol function.

A token may belong to several categories simultaneously. For example, a stablecoin can also be a token issued on a smart-contract blockchain. The classifications describe architecture, price behavior, privacy, or economic function rather than mutually exclusive groups.

An Initial Coin Offering, or ICO, is a fundraising method in which a project sells newly created digital tokens to investors or users, commonly in exchange for cryptocurrency or fiat currency.

Typical ICO process:

1. Project proposal: The team identifies a blockchain-based product or protocol.
2. White paper publication: The project describes its problem, proposed solution, technology, roadmap, token utility, supply, allocation, and funding goals.
3. Token creation: Tokens are implemented on a blockchain, often through a standard smart-contract interface.
4. Legal and compliance review: The team evaluates securities law, identity verification, taxation, and jurisdictional restrictions.
5. Private or presale phase: Selected investors may purchase tokens before the public sale, sometimes at a discount.
6. Public sale: Participants send accepted funds to a designated address or sale contract and receive tokens.
7. Distribution and listing: Tokens are distributed and may later be listed on exchanges.
8. Project development: The raised funds are used to build the promised platform or service.

An ICO does not automatically give token holders company ownership. Their rights depend on the token's terms, technical design, and applicable law.

An ICO sells digital tokens, whereas an Initial Public Offering (IPO) generally sells regulated equity shares in a company.

Comparison

• Asset issued: ICO participants receive tokens; IPO investors receive shares representing ownership rights.
• Regulation: IPOs follow extensive securities registration, disclosure, auditing, and listing procedures. ICO regulation varies by jurisdiction and token characteristics.
• Intermediaries: IPOs normally involve underwriters, exchanges, auditors, and legal advisers. ICOs can be conducted directly using smart contracts, although professional and legal support is still advisable.
• Investor rights: Shares may provide voting, dividend, and residual ownership rights. ICO tokens may provide utility, governance, payment functions, or no enforceable rights.
• Market access: ICOs can reach a global online audience, while IPO participation is usually more structured and restricted.

Benefits of ICOs

• Rapid access to global capital.
• Programmable and transparent token distribution.
• Early formation of a user community.
• Potential reduction in fundraising intermediaries.
• Ability to fund open blockchain protocols that do not fit conventional equity models.

Risks of ICOs

• Fraud, false promises, and anonymous teams.
• Smart-contract vulnerabilities and theft.
• Extreme price volatility and limited liquidity.
• Weak governance and concentration of tokens.
• Regulatory action if the token constitutes an unregistered security.
• Failure to deliver the promised product.

Therefore, ICOs can support decentralized innovation but require due diligence, transparent disclosures, secure contracts, and legal compliance.

The concept of smart contracts predates modern blockchains.

• 1990s: Computer scientist and legal scholar Nick Szabo introduced the term smart contract. He described computerized transaction protocols that execute contractual conditions and used a vending machine as a simple analogy.
• Early digital commerce: Electronic data interchange, digital signatures, and digital rights-management systems demonstrated partial automation of agreements, but they usually depended on centralized operators.
• Bitcoin era: Bitcoin introduced a decentralized ledger and a limited scripting language. Its scripts support conditions such as digital-signature checks, multisignature authorization, hash locks, and time locks.
• Programmable blockchain era: Ethereum popularized general-purpose, stateful smart contracts executed by a decentralized virtual machine. Developers could create tokens, exchanges, voting systems, and decentralized applications.
• Modern development: Numerous platforms now support smart contracts using different languages, virtual machines, consensus methods, and execution models.

The key evolution was from centrally operated contractual software to deterministic programs whose state and execution are validated by a decentralized network.

A smart contract is a program deployed on a blockchain or distributed ledger that automatically updates digital state or enforces specified actions when its programmed conditions are satisfied.

Essential characteristics include:

• Determinism: Given the same inputs and state, validating nodes should obtain the same result.
• Automated execution: Contract functions perform actions according to encoded rules without requiring manual processing.
• Replicated state: Contract code and state are verified or stored across multiple network nodes.
• Tamper resistance: After deployment, unauthorized modification is difficult; changes must follow the contract's upgrade design and blockchain rules.
• Transparency: On public blockchains, code, transactions, and state may be inspectable.
• Cryptographic authorization: Users invoke functions through digitally signed transactions.
• Composability: One smart contract can interact with other contracts to build larger applications.
• Resource metering: Execution normally requires a fee, such as gas, to allocate computation and prevent abuse.

A smart contract is not necessarily a legally enforceable contract. It is primarily executable code, and its legal status depends on the agreement, jurisdiction, and surrounding circumstances.

Traditional legal contract

• Expressed mainly in natural language.
• Interpreted using law, context, intent, and judicial precedent.
• Performance may require manual action by the parties or intermediaries.
• Breach is usually addressed through negotiation, arbitration, or courts.
• Ambiguity can sometimes provide flexibility for unforeseen circumstances.

Smart contract

• Expressed wholly or partly as executable program code.
• Executes deterministically according to encoded logic.
• Can transfer digital assets or update blockchain state automatically.
• Enforcement within the blockchain may occur without a conventional intermediary.
• Coding errors can produce unintended results even when the parties intended something else.

Relationship between them

A smart contract can automate part of a legal agreement, but code alone may not capture capacity, consent, illegality, force majeure, jurisdiction, or equitable remedies. A robust arrangement may combine legal prose, machine-readable parameters, digital signatures, and dispute-resolution provisions.

A Ricardian contract is a digitally signed document that records an agreement in a form understandable to humans while also being identifiable and processable by computer systems. The idea is associated with Ian Grigg.

Main components:

• Human-readable legal prose: States the rights, duties, terms, and conditions of the agreement.
• Machine-readable fields: Contains structured information such as parties, asset type, quantity, dates, or identifiers.
• Digital signatures: Authenticate the issuer or agreeing parties and help establish integrity and consent.
• Cryptographic hash: Creates a unique fingerprint of the document. Transactions can refer to this hash rather than reproducing the entire agreement.
• Link to transactions: The document defines the meaning of a digital asset or transaction recorded by a system.

Its purpose is to connect legal meaning with digital processing. Unlike a purely executable program, a Ricardian contract preserves a readable legal record that can be examined by users, auditors, and courts.

Ricardian contracts and smart contracts both support digital agreements, but they emphasize different aspects.

Ricardian contract

• Primarily represents the legal meaning of an agreement.
• Contains human-readable prose and machine-readable data.
• Uses hashes and digital signatures to provide identity and integrity.
• Can serve as evidence for interpretation by parties, auditors, arbitrators, or courts.
• Does not necessarily execute its terms automatically.

Smart contract

• Primarily represents executable logic.
• Automatically changes blockchain state when programmed conditions are met.
• Must be deterministic for decentralized validation.
• May not fully express legal intent or deal effectively with ambiguous real-world events.
• Can hold and transfer digital assets directly.

Combined use

A hybrid system can hash a Ricardian legal document and store the hash in a smart contract. The smart contract automates measurable obligations, while the Ricardian document explains the legal relationship, exceptional cases, governing law, and dispute resolution. This combination improves both operational automation and legal clarity.

A smart contract template is a reusable framework that combines standardized legal clauses, structured parameters, and executable logic. Instead of writing every agreement and program from the beginning, parties select a tested template and fill in values such as names, dates, prices, interest rates, and asset identifiers.

Typical elements include:

• Standard legal wording.
• Variables or parameters for transaction-specific details.
• Machine-readable representations of obligations.
• Smart-contract code linked to selected clauses.
• Interfaces for signatures, payments, or oracle data.

Advantages:

• Consistency: Similar transactions use uniform terms and logic.
• Reduced development cost: Reusable components avoid repeated drafting and coding.
• Improved security: Widely reviewed templates may contain fewer defects than newly written code.
• Faster deployment: Parties configure known components rather than creating an entire contract.
• Auditability: Standard structures are easier for lawyers, auditors, and software tools to examine.
• Interoperability: Common data formats facilitate interaction across organizations and systems.

Templates must still be configured carefully. Incorrect parameters, unsuitable legal clauses, insecure dependencies, or changes in law can make a standardized template inappropriate.

An oracle is a mechanism that supplies a smart contract with data or outcomes that are not natively available on the blockchain. Examples include market prices, weather observations, sports results, shipment status, and random values.

The oracle problem arises because blockchains can verify on-chain data deterministically but cannot independently confirm whether external information is true. If a contract trusts one external source, that source can become a centralized point of failure. Incorrect or manipulated data can cause correct code to produce an incorrect real-world outcome.

Types of oracles:

• Software oracles: Obtain information from websites, databases, or APIs.
• Hardware oracles: Collect physical-world data from sensors, scanners, or trusted devices.
• Inbound oracles: Deliver external data to a blockchain.
• Outbound oracles: transmit blockchain events or instructions to external systems.
• Centralized oracles: Depend on one provider and are simple but introduce concentrated trust.
• Decentralized oracles: Aggregate responses from multiple independent providers.
• Human oracles: Rely on recognized experts or adjudicators to report an outcome.

Risk-reduction methods include source diversity, median or weighted aggregation, cryptographic proofs, trusted execution environments, staking and slashing, delayed settlement, and dispute mechanisms. Oracles reduce but cannot completely remove the need to trust the connection between blockchain code and the external world.

A disciplined smart-contract deployment process contains the following stages:

1. Requirements analysis

• Define participants, assets, permissions, state transitions, failure cases, and legal obligations.
• Decide which operations should occur on-chain and which should remain off-chain.

2. Architecture and design

• Select the blockchain, programming language, contract structure, data model, and access-control system.
• Determine whether the contract will be immutable or upgradeable.

3. Implementation

• Write contract code using secure patterns and reviewed libraries.
• Minimize unnecessary storage and computation because execution incurs fees.

4. Testing

• Perform unit, integration, property-based, fuzz, and adversarial tests.
• Test boundaries, authorization failures, reentrancy scenarios, arithmetic behavior, and oracle failures.

5. Audit and verification

• Conduct peer review and independent security audits.
• Use static analysis, symbolic execution, or formal verification where appropriate.

6. Testnet deployment

• Deploy in a realistic test environment and validate user interfaces, scripts, events, and external integrations.

7. Mainnet deployment

• Compile the code, submit a signed deployment transaction, and pay the required fee.
• The resulting blockchain address identifies the deployed contract.

8. Verification and initialization

• Publish or verify source code, initialize parameters, allocate roles, and confirm ownership settings.

9. Operation and monitoring

• Monitor transactions, balances, events, abnormal behavior, and oracle performance.
• Maintain incident-response, pause, upgrade, or migration procedures when the design permits them.

Smart contracts may directly control valuable assets, and blockchain immutability can make defects difficult to repair.

Major risks:

• Reentrancy: An external call re-enters a function before the original state update is complete.
• Access-control errors: Sensitive functions are callable by unauthorized accounts.
• Oracle manipulation: Attackers influence external prices or outcomes used by the contract.
• Front-running and transaction ordering: An observer submits a competing transaction with a higher fee after seeing a pending transaction.
• Denial of service: Expensive loops, failed external calls, or deliberate state growth can prevent normal operation.
• Logic and economic flaws: Correctly executing code may still create exploitable incentives.
• Arithmetic or precision errors: Rounding, unit mismatches, and unsafe arithmetic can corrupt calculations.
• Upgrade vulnerabilities: Proxy administration or initialization errors may permit contract takeover.
• Private-key compromise: Stolen administrator keys can bypass otherwise secure logic.

Precautions:

• Follow checks-effects-interactions and least-privilege principles.
• Use established libraries and explicit access controls.
• Avoid unnecessary external calls and unbounded loops.
• Test with fuzzing, static analysis, and adversarial simulations.
• Obtain independent audits and consider formal verification for critical properties.
• Use multisignature wallets, time locks, withdrawal limits, and secure key management.
• Design oracle aggregation and manipulation resistance.
• Monitor deployed contracts and maintain a documented incident-response plan.

Security must cover code, economics, governance, users, administrators, and external dependencies rather than code alone.

The DAO was a decentralized investment organization launched on Ethereum in 2016. Participants contributed ether and received DAO tokens, which were intended to support voting on proposed investments and project funding. It became one of the largest crowdfunding efforts of its time.

The attack

• The DAO included a mechanism through which a participant could separate from the main organization and recover funds.
• Its contract made an external transfer before fully updating the sender's internal balance.
• An attacker used a reentrancy technique to call the withdrawal logic repeatedly before the previous execution completed.
• A large quantity of ether was moved into a child DAO structure.
• The incident was primarily caused by a smart-contract logic vulnerability rather than a failure of Ethereum's underlying cryptography.

Response

• The Ethereum community debated whether blockchain history should remain unchanged under the principle often summarized as \"code is law\".
• A hard fork was adopted to return the affected funds through a recovery mechanism.
• Nodes rejecting the reversal continued the original chain, which became Ethereum Classic, while the forked chain retained the Ethereum name.

Significance

• Demonstrated the danger of reentrancy and unchecked external calls.
• Showed that decentralized systems still depend on social governance.
• Raised questions about immutability, investor protection, and legal responsibility.
• Encouraged stronger auditing, safer coding patterns, formal verification, emergency controls, and staged deployment.
• Illustrated that contract behavior may differ from the creators' intentions even when the blockchain executes the code exactly as written.