COMP90088: Cryptocurrencies and decentralised ledgers Semester 1 2022
Tutorial Sheet, Week 6/7
For tutorials on April 8, 2022 and April 12-14, 2022
1. Pre-mines: Many altcoins launch with a lockup period for pre-mined tokens, where they cannot be traded for a certain period of time (and often gradually become tradable after a vesting schedule). Remember that pre-mined coins are often allocated to founders and a foundation to support development:
Copyright By PowCoder代写 加微信 powcoder
a. What is the advantage of having a lockup period?
The lockup period is designed to prevent the founders from selling all of their coins and abandoning the coin soon after it launches (pump-and-dump). They will have an incentive to keep the project valuable until all of their coins have vested.
b. What might go wrong if the lockup period is too long or too short?
A lockup period that is too short might not prevent pump-and-dump, or might not keep founders and developers supporting the project long enough for it to grow. A lockup period that is too long may similarly have a discouraging effect: if founders don¡¯t think they will ever get to profit they might give up.
2. Atomic swaps: Imagine that there are two chains, PancakeChain and WaffleChain, and Alice and Bob want to perform an atomic swap between the chains. Consider pseudocode for a simpler variant of the symmetric atomic swap function described in class. Unlike the version in class, this requires only one transaction on each chain:
Transaction 1 (on PancakeCoin Chain)
Transaction 2 (on WaffleCoin Chain)
Before time T_1:
¡ñ SignaturebyK_A
¡ñ xsuchthatH(x)=y After time T_1:
¡ñ SignaturebyK_B
Before time T_2:
¡ñ SignaturebyK_B
¡ñ xsuchthatH(x)=y After time T_2:
¡ñ Signature by K_A
a. This version was not possible with the original Bitcoin script mechanics. What feature was added which made this simpler version possible?
The if branch with time stamps requires CHECKLOCKTIME_VERIFY, which was added in 2015 by the BIP65 soft fork but was not available previously.
b. Given the scripts above, does Alice originally hold PancakeCoins or WaffleCoins?
Alice holds WaffleCoins. Notice that after the time out (in case the transaction fails) Alice can cash out WaffleCoins, implying that this was the original status.
c. Which transaction should be posted first? What happens if the order is swapped?
This depends on which party picks x! If Bob picks x, then we want Transaction 1 to be posted first. Otherwise, Bob can spend Transaction 2 right away and refuse to post Transaction 1, keeping both coins.
Symmetrically, if Alice picks x, then Transaction 2 must be posted first.
Note that whichever transaction is posted ¡°first¡± should be confirmed before the other is posted.
d. How should T_1 and T_2 be selected?
This also depends on which party picks x. If Bob picks x, then we want T_1 > T_2. If T_1 < T_2 and Bob knows x, then after T_1 but before T_2 Bob could first claim the PancakeCoins using the timeout and also claim the WaffleCoins by revealing x. If T_1 > T_2 then this isn¡¯t possible (there is no after T_1 but before T_2).
Symmetrically, if Alice picks x then we want T_1 < T_2.
e. In practice, how should Alice and Bob select the magnitude of the difference |T_1 - T_2|? What can go wrong if this value is too small? What can go wrong if this value is too large?
Suppose for simplicity that Bob picks x and T_1 > T_2. Bob might claim the WaffleCoins (by revealing x) very close to the deadline T_2. To ensure she gets her PancakeCoins, Alice will need to see Bob¡¯s transaction on the WaffleCoin chain (learning x) and get a transaction confirmed on the PancakeCoin chain using x to claim the PancakeCoins. Thus, the time difference should be at least the expected length of time to confirm a transaction, plus some reasonable reaction time for Alice to prepare a transaction, plus some safety margin. For Bitcoin this means the time difference should be at least several hours to ensure a transaction can be confirmed if 6 blocks confirmation is considered high confidence.
If the time window is too small, Bob (or whichever party chooses x) might race to get transactions on both chains before the other party, violating security of the protocol.
If the time window is too long it becomes inconvenient for the other party to wait in case the protocol fails.
f. What can go wrong if the same value x is used for multiple runs of the protocol?
This would mean the protocol is totally insecure since both parties know x. So whichever party posts first, the other party can immediately take the coins.
3. Solidity modifiers: Consider the following Solidity function: address owner;
function withdraw() public owner_only {
payable(msg.sender).transfer(this.value);
a. Does the withdraw function need to be marked payable?
No, it should not be because no money needs to be sent to this function.
b. Can the withdraw function be marked as view and/or pure?
No, these modifiers would prevent sending out money (which modifies the contract¡¯s
c. What visibility level (public/private/internal/external) should be applied to the member variable owner?
Any of them would work. Private or internal are probably the most appropriate, though marking the address public would not be a security problem by itself as it couldn¡¯t be directly overwritten without some public function implementing that.
d. Finally, consider the following implementations of the owner_only modifier. Which will actually be secure? Which is best practice?
Versions (iii) and (v) are insecure. They won¡¯t prevent the money from being sent (they will only return after the damage is done). The others are all okay in this example, though (ii) and (vi) are not recommended either as they don¡¯t revert, making them harder to reason about. (iv) reverts, but after running code, which can waste some gas. (i) is the best practice.
i. modifier owner_only {
require(msg.sender == owner_address);
ii. modifier owner_only {
if (msg.sender != owner_address)
iii. modifier owner_only {
vi. modifier owner_only {
if (msg.sender != owner_address)
iv. modifier owner_only { _;
require (msg.sender == owner_address)
v. modifier owner_only {
if (msg.sender != owner_address)
return; _;
if(msg.sender == owner_address)
程序代写 CS代考 加微信: powcoder QQ: 1823890830 Email: powcoder@163.com