Day 7. Duck Hunt has been suspended until further notice.

https://i.redd.it/jlck843j4fwd1.jpeg

Bitcoin vs ETF, clarification?

hey all, excuse the possibly silly questions but I just wanted to get more clarification if possible: I have been looking at Bitcoin ETF and my understanding is it's basically the same as buying the coin on say an exchange, but you dont own the keys, it's still owned (held?) by the platform you trade on, but you are entitled to it like stock (shares).

so the advantage of buying it from exchange and then storing it yourself is you have control over it, you owned the keys, but that also means you can lose it, and a non-btc-versed partner or family may have no idea how to get it

if on the other hand you get the ETF, it's still reasonably safe, you dont have to store it yourself, and your partner or family will get access to it like your other assets in the event you are unable to

does that sound like a reasonable simple summary? happy to be corrected

MINTING DREAM, NOT MINING BITCOIN

❌MINTING DREAM, NOT MINING BITCOIN

[DREAM TO EARN SMART CONTRACT]

https://bscscan.com/token/0x89b6418dde467351b962d5edd7c7eaa43518d732?a=0xc346ef0bcaeada20485696f370a376b5df2fdd35#code

[APPLIED TO “Bitcoin Mining: Crypto Miner” APP]

https://apps.apple.com/us/app/bitcoin-mining-crypto-miner/id646831332

[ACCORDING TO TERMS & CONDITIONS]

https://cloudminecrypto.com/terms_and_conditions.html

“…if you have any complaints or comments regarding DREAM”.

[DREAMTOEARN SECURITY FLAWS]

https://bscscan.com/code-reader?a=0x89b6418dde467351b962d5edd7c7eaa43518d732

1. “Lack of reentrancy protection: The contract does not use any reentrancy protection mechanism to prevent an attacker from calling functions in a contract that will call functions back on the previous caller. An attacker could exploit the lack of reentrancy protection to repeatedly mint or burn tokens, manipulating the total supply by repeatedly calling a function before the initial execution is complete.

For example, the _transfer function is vulnerable to a potential reentrancy attack, since it first checks for balances, then calls increment which executes before the check, and if it fails, it backtracks and aborts:

solidity function _transfer(address from, address to, uint256 amount) internal virtual { require(from != address(0), "ERC20: transfer from the zero address"); require(to != address(0), "ERC20: transfer to the zero address"); _beforeTokenTransfer(from, to, amount); uint256 fromBalance = _balances[from]; require(fromBalance >= amount, "ERC20: transfer amount exceeds balance"); unchecked { _balances[from] = fromBalance - amount; // Overflow not possible: the sum of all balances is capped by totalSupply, and the sum is preserved by // decrementing then incrementing. _balances[to] += amount; } emit Transfer(from, to, amount); _afterTokenTransfer(from, to, amount); // If the initial call was successful // In case the decrement was reverted, call the decrement again // and abort on the subsequent attempt if(fromBalance - amount != fromBalance && toBalance() != _balances[to] && amount != amount) // overflow revert("Transfer failure"); } } 2. No burn cap: The contract does not have any limit on the total number of tokens that can be burned. This could be used to manipulate the token supply, burning an excessive number of tokens to artificially reduce the supply and increase the value of remaining tokens.

The part of the code that indicates there is no tracking of burning and mining or limit is the _burn function, which does not require the token balance of the account from which tokens are being burned to be available before the transfer is executed.

```solidity function _burn(address account, uint256 amount) internal virtual { require(account != address(0), "ERC20: burn from the zero address"); _beforeTokenTransfer(account, address(0), amount); uint256 accountBalance = _balances[account]; require(accountBalance >= amount, "ERC20: burn amount exceeds balance"); // not needed here unchecked { _balances[account] = accountBalance - amount; // Overflow not possible: amount <= accountBalance <= totalSupply. _totalSupply -= amount; } emit Transfer(account, address(0), amount); _afterTokenTransfer(account, address(0), amount); }

1. Lack of audit trails: The contract does not have any audit trails to keep track of significant events such as token transfers, burns, or audits. This lack of transparency can hide fraudulent activities, making it difficult to detect and investigate unauthorized transactions or manipulations in the token supply.

2. No checks for decimals overflow: The contract does not have any checks for decimals overflow in the '_mint function, which may lead to incorrect token amounts being minted. This could lead to an inflated or deflated token supply, potentially being exploited to mint incorrect amounts of tokens, more tokens than intended.

The part of the contract that indicates there is no control of decimal overflow can be found in the _transfer, _mint, and _burn functions of the ERC20 contract. Specifically, in the _transfer, _mint, and _burn functions, the following lines of code:

solidity unchecked { _balances[from] = fromBalance - amount; _balances[to] += amount; _totalSupply += amount; _balances[account] += amount; } and

solidity unchecked { _balances[from] = fromBalance - amount; _totalSupply -= amount; } and

solidity unchecked { _balances[from] = fromBalance - amount; _balances[account] += amount; } do not check for overflow before performing the subtraction and addition operations. This means that if the result exceeds the maximum value that can be stored in the variable, the result will wrap around and overflow, potentially leading to incorrect behavior.”

[CONCLUSION]

Author OpenZepplin has written smart contracts for nearly a decade. OpenZepplin knows how to write contracts satisfying all of the above vulnerabilities. Therefore, he wrote the contract exactly how he was told. Therefore, the deployer of the contract specifically told the author to write the contract with the above vulnerabilities so that they could be exploited. The DREAM token is explicitly controlled by the developer & the deployer. Nobody knows how many are in existence. There’s nothing keeping track.

The developer applied the DreamToEarn contract to the bitcoin mining app. DREAM is in the bitcoin mining app TERMS & CONDITIONS. Therefore, the deployer is using the power of the downloaders & users to MINT DREAM tokens for themselves. How else could the DreamToEarn smart contract be applied to the bitcoin mining app? It can’t! The bitcoin mining users don’t actually see DREAM. They see pennies in BTC to make them think they are mining Bitcoin.

🚨CLOUDMINECRYPTO IS 100% PHISHING!

1. CFAA (Computer Fraud and Abuse Act) - 18 U.S.C. § 1030: Unauthorized access to computer systems and networks, including fraud and related activities involving computers.

2. FTCA (Federal Trade Commission Act) - 15 U.S.C. §§ 41-58: Prohibits unfair or deceptive acts or practices in commerce, aiming to protect consumers from false advertising and fraudulent business practices.

3. SEC (Securities and Exchange Commission): The Securities Act of 1933 and the Securities Exchange Act of 1934 regulate the securities industry, requiring accurate disclosure of information to protect investors and maintain fair and efficient markets.

4. Wire Fraud - 18 U.S.C. § 1343: Addresses fraud conducted via electronic communications or wire transfers, such as using the internet or phone lines to carry out fraudulent schemes.