Today's Progress: experiments with transfer() v selfdestruct(); further signature testing and code cleanups
Today's Progress: revising simple escrow and related tests, block.timestamp specifics, other signature param experimenting
Today's Progress: timelock and selfdestruct edits, further reading on signature concatenation and bytes
Today's Progress: experimenting with signature parameters and offchain signatures (per EIP-762 using web3.js and Metamask; selfdestruct()
Today's Progress: override v. virtual and interface contracts, article here, experimenting with NFT contract
Today's Progress: further bytes testing, begin experimenting with wrapped NFTs
Today's Progress: working with bytes, tests and samczsun Escaping the Dark Forest examples
Today's Progress: review transfer() and related issues (reentrancy-safe if it is the last call in a function and state already changed, as well as v0.7.0 changes ("now" deprecated for block.timestamp, visibility not needed in constructors, etc.). Will want to look more into micropayment channels (ex. this example and Sablier streaming)
Today's Progress: math in Solidity, coding simple timelock escrow contract
Today's Progress: revisit float issues and mappings, work with libraries and upgradeability, NFT standard differences
Today's Progress: review libraries and globally available variables including msg.sig, gasleft()
Today's Progress: revisit upgradeability in solidity, private v. internal considerations and gas, more review of solidity keywords
Today's Progress: revise index process in escrow.sol, review Solidity keyword index and interfaces
Today's Progress: work with events, revising escrow.sol to clean up array issues, reviewing lexlocker
Today's Progress: further multi-mappings tests, permit() replacement, bytes32 efficiencies; drafting lexdao substack article
Today's Progress: testing Arbitrum Rollups on Kovan and token bridges/interop considerations; reviewing mappings
Today's Progress: WETH contract and double mappings, wad syntax, permit() replacement for approve txs: https://github.com/wETH-v2/wETH-v2/blob/54615bbfad5079f513955df335997996829e0932/contracts/WETH10.sol
Today's Progress: code review and gas tests with arrays, reading on security audit best practices and upgradeable contracts
Today's Progress: more calldata and other type gas tests, upgradeable.sol; lexdao code reviews and summaries
Today's Progress: reading on upgradeable contracts, further calldata testing, reviewing audius code
Today's Progress: testing with calldata, including efficiencies and gas savings; updated advancerequirement.sol, will look through existing contracts for more efficiencies.
Thoughts: by changing one function input to calldata & external, and one other function to external, I saved 1277879 -> 1259170 gas in constructor transaction cost and 926135 -> 912122 gas in execution cost. Simple change for some efficiency, but will need to ensure there are no tradeoffs.
Today's Progress: comparing addresses and more intricate modifers; editing escrow.sol for expiration termiation
Today's Progress: bytes32 and randomness testing, edits to Lottery.sol in string to bytes32 conversion
Today's Progress: revising expirationdate.sol and escrow.sol to streamline and return the calendar days remaining until expiry
Today's Progress: work an expiration date concept into escrow.sol by adapting expirationdate.sol, will need some testing, including as to events and whether a separate Expired() event is necessary.
Thoughts: escrow.sol is quite bulky, can look into streamlining some of the functions and removing the "factory" as it's likely unnecessary. Better for risk management to use a new contract for each escrow anyway.
Today's Progress: review and replicate various codebases including yearn, lexDAO, API3; inherit issues and type explicitness
Today's Progress: further coding and testing expirationdate.sol, including events and emits. Calendar days currently the best implementation, may work into Escrow.sol directly.
Today's Progress: coding expirationdate.sol, which bools to true after inputted number of days until expiration (in seconds after constructed)
Today's Progress: experimenting with bytes32, reading on ufixed8x1 and other fixed point library adaptations such as this fixed library
Today's Progress: further bytes32 testing and gas considerations, safemath testing
Today's Progress: txn tests, nonce customizations for cancels, further escrow tests on kovan
Today's Progress: successful tests of escrow.sol on Kovan, using $ deposit/price input parameters and conversion to wei
Thoughts: need to look into best practices for math on converting dollars to wei-- floats are rounded off so it results in an imprecise wei calculation
Today's Progress: revamp vote.sol to take a string input for candidate names, will need to translate the bytes32 inputs for the other functions and limit to one vote per address
Today's Progress: create Vote.sol to experiment with bytes32 -- having issues encoding inputs but may be a Remix issue.
Today's Progress: change price feed in escrow.sol to Kovan for testing, still unable to construct, might be gas error but unsure
Today's Progress: reviewing override and virtual functions, random numbers. Ropsten still down for escrow.sol testing
Today's Progress: coded ToDoList.sol to create simple ToDo list, client-side uncompleted
Today's Progress: escrow.sol successfully deployed and terminated on Ropsten but not properly translating price from USD to ETH because of floats; issues with deployment on Ropsten (may be a Ropsten issue)
Today's Progress: continue working on including USD-ETH price coverter into escrow.sol
Today's Progress: update FAAToken for uint256 and require statements, test gas efficiencies, review lexDAO's LiteERC20
Today's Progress: tests using USDConvert for escrow.sol, unsuccessful. Might be a bug or gas management
Today's Progress: review ChainlinkClient.sol and create Offchain.sol for first oracle contract tests, first will be ETH/USD price convert for escrow contract
Today's Progress: revamp events in escrow.sol, revisit ethernaut, reading on bytes32
Today's Progress: add events to escrow.sol, fixing terminateDeal() to return funds to buyer (if a different address than agent as assigned via sendFunds()), otherwise return to agent
Today's Progress: fix transfer functions to use escrowAddress.balance and testing transfer and errors
Thoughts: it appears terminateDeal() did not properly return the deposit to agent, will need fixing
Today's Progress: reviewing permission in escrow.sol, require failures, further tests of errors; need to revisit .transfer functions as closeDeal() is still not working properly
Today's Progress: successfully fixed escrows[] and the constructor, succesfully completed a basic test of manual confirmation of closeDeal()
Thoughts: next, check .transfer for closeDeal and terminateDeal; explain all require statement failures for user
Today's Progress: fix require() statements in sendFunds() to require input of the funding amount and msg.value to be >=; DAO structures and revisit some basics on interfaces
Thoughts: next is fixing the escrows array and closeDeal/terminateDeal, also need to revising events and learn about bytes32
Today's Progress: revising Escrow.sol for agent to specify funds recipient and fix escrow deposit mechanic
Thoughts: still having issues with sendFunds() and whether sendEscrow() is necessary; also investigate whether .transfer() is the proper method
Today's Progress: revising Sale Agreement md for proper address references, commenting practices including in escrow contract
Today's Progress: reviewing DAO constructs and legal framings, reviewing yearn code and DeFi implementations as examples
Today's Progress: coding return purchase price - deposit to buyer if deal terminated and hard coding buyer as funds sender in escrow.sol, will need to test
Today's Progress: revising Escrow.sol to return deposit to agent and allow agent to approve parties in standalone function
Thoughts: need to sort out the address payable issues in Factory and provide mechanism for funds to be returned to sender if deal terminated
Today's Progress: revising Escrow.sol to properly increment parties and bool approvers
Thoughts: in addition to thoughts below, need to initiate Escrow contract with Escrow Factory deposit payment
Today's Progress: coding Escrow.sol, adapting Campaign.sol to an escrow contract initiated with a deposit amount, with mechanisms for approval by parties and release of funds once all approvals received
Thoughts: next steps are to prevent any msg.sender from becoming a "party" if sending enough value-- perhaps change to agent's decision? also need to code a return deposit scenario
Today's Progress: deployment considerations (creating factory within contract) and creating CampaignFactory.sol to mitigate security risks of creator tampering with Campaign.sol
Thoughts: more deprecations from Udemy course- typecasting address of the created campaign as follows: "address newCampaign = address(new Campaign(minimum, msg.sender));"
Today's Progress: local memory structs and mappings to clean up code
Thoughts: cleaning up AdvanceRequirement and other arrays of structs will be a useful exercise
Today's Progress: Struct initialization and mappings in campaign.sol
Today's Progress: coding spendingRequest, continue storage v. memory and mapping as gas saver
Thoughts: mappings as key-value pairs are similar to objects in javascript, constant time search is important
Today's Progress: storage v. memory considerations, structs continued, other campaign.sol edits
Today's Progress: mapping out "campaign" kickstarter contract, defining structs, note translations for escrow purpose
Thoughts: going forward, note methods for voting on funds release from escrow and constructed minimum escrow amount
Today's Progress: reading through OpenZeppelin learn and OpenZeppelin CLI regarding upgradeable contracts
Today's Progress: NFT minting with cargo.build: https://alpha.cargo.build/dashboard/showcase/5f120c4073ca94140d75c084, migrating aircraft sale agreement from OpenLaw
Thoughts: very easy to mint NFTs with details, pictures, etc. Will need to test public visibility and whether another frontend can be used
Today's Progress: Ethereum app architecture and intro to React
Thoughts: React will bypass difficult javascript
Today's Progress: contract testing via javascript/git over my head and seemingly unnecessary for now-- will test manually for near future
Today's Progress: Udemy course and receiving/sending value, cleanup of AircraftToken, read RNG docs
Thoughts: Chainlink's VRF is a good goal implementation both for a random generator and generally as a first oracle implementation
Today's Progress: completed lottery contract with pickWinner, modifier, view array, transfer balance, and create new players array upon winner picked
Thoughts: the 'payable(players[index]).transfer(address(this).balance);' line of code is useful for emptying an escrow to the chosen address ('index') in array BUT apparently transfer is deprecated for call? will need to investigate
Today's Progress: pseudo-random number generator for lottery contract, edits to AircraftToken, use pseudo-rand number modulus players array length to choose lottery winner
Thoughts: would be interesting to try and include chainlink's VRF here, will attempt later
Today's Progress: solidity array issues: nested arrays do not port over, etc., continuing lottery contract
Thoughts: important to realize strings are represented as dynamic arrays in solidity, so cannot transfer arrays of strings to javascript
Today's Progress: burn function and other tuneups to AircraftToken.sol, Udemy course lessons on data structures
Thoughts: some more finishing touches to put on the AircraftToken code before publishing, including removing aircraft details after token burned
Today's Progress: global variables and start Lottery.sol in udemy course, review data and msg intricacies
Thoughts: back to basics for refresher, next overview on arrays will be good review for AircraftToken.sol
Today's Progress: AircraftToken.sol now functional, token/aircraft details returnable by incrementing "i" number and pulling the "i"th Aircraft struct in the aircraft array of Aircraft structs, but searcher must input the "i" number which is not ideal. This can likely be solved either by several arrays or off-chain databases (public database storage of i numbers isn't a decentralization threat, just allows cheaper access to helpful search terms). tokenId/newAircraftId returns owner, which can be used to find the other information
Thoughts: eventually I would like to flesh out how to make tokens searchable by each attribute, but will re-focus on Udemy course and eventual escrow contract
Today's Progress: newAircraftId now has unique value based on owner's regId and MSN of applicable aircraft, but still need to figure out how to pull token data/array info
Thoughts: more ERC721 learning to do-- tokenURI (uniform resource identifier) may be the answer. URIs are defined in RFC 3986
Today's Progress: aircraft NFT implementation seems to be working, tokensupply increments, but need to fix aircraftDetails function to return token info
Thoughts: need to look into how to pull details of a given ERC721 token, create a unique ID for newAircraftId, and learn more about calldata
Today's Progress: continue aircraft NFT implementation, intro to Git, ERC721 minting
Thoughts: look into intricacies of mint v. safeMint function, need to make a practice of charting out function flow and matrixes, etc.
Today's Progress: successfully compiled AircraftToken.sol with receive() fix and minimum ETH payment, able to enter one aircraft
Thoughts: the fallback() v. receive() issue was strictly a version deprecation, need to be mindful of these. Next is tying info to actual NFT To Do: tie aircraft info to actual NFT-- will likely need to have buyRegToken then invoke createAircraft, which will be an internal function returning newAircraftID
Today's Progress: dev AircraftToken.sol, including payable / fee for creation. Interaction of ERC721 and underlying structs
Thoughts: need to focus on how to return token details and maybe down the line, how to return a token's details given one of its parameters To Do: resolve AircraftToken's "this contract has a payable fallback function, but no receive ether function, consider adding one"
Today's Progress: more work on CreateAircraft.sol, now fully using OZ's ERC721 code, will need several-day overhaul
Thoughts: better to use widely vetted code than reinventing the wheel wherever possible-- will consider the same for AircraftOwnership
Today's Progress: revise CreateAircraft.sol, review Moloch code and potential divisibility uses for lexDAO's dripDrop
Thoughts: skipping next unit of Udemy course to prevent stasis from lack of javascript background
Today's Progress: analyze/replicate LexToken and other parts of lexDAO codebase, other review
Thoughts: taking a breather due to an overly busy workweek, but will use the Udemy course to stay up on concepts
Today's Progress: experiment with dynamic array limitations, explore chainlink's dynamic NFTs for potential asset representation with native attributes and valuation
Thoughts: will refocus on specific solidity concepts, such as using structs
Today's Progress: explore 0x ERC721 implementation, including ERC-721JSON metadata file (https://github.com/0xcert/ethereum-erc721)
Thoughts: will be useful to understand differences in audited ERC721 implementations, and how they can have dynamic attributes
Today's Progress: start CreateAircraft.sol and NFT considerations for FAA aircraft registry token, SafeMath
Thoughts: need to hone in on exact params and data types for the Aircraft ER721-- initially based on FAA registry attributes (i.e. no engines). Project is starting to take shape: escrow dApp that takes inputs of aircraft details, AdvanceRequirement satisfaction, and external data from oracles
Today's Progress: Continue ERC721 portions of cryptozombies and map out intended NFT details
Thoughts: need to dive in deep to the implications of the transferTo v. approve standard, for owner to initiate transfer v. recipient requesting and owner approving
Today's Progress: revisit ERC721 portions of cryptozombies; continued background on web3 pack; review DMM code
Thoughts: begin to assemble components and params for an aircraft NFT; keeping momentum on the solidity side and will handle front end/web3 on the latter half of the challenge
Today's Progress: address array events; begin basic understanding of web3 pack
Thoughts: will likely eschew granular web3 concepts for viable nocode or prebuilt solutions so as not to be overwhelmed/inundated at first
Today's Progress: more practice with events and emit; seems event inputs need to match corresponding function params, clean up comments in AdvanceRequirement.sol
Thoughts: still looking for good documentation on events and their restrictions, need to test structs
Today's Progress: exploring Mocha and javascript environments
Thoughts: looking for the most streamlined dev environment, the Udemy course recs may be outdated. May also be a viable nocode solution here
Today's Progress: deploying contracts and ETH infrastructure; Udemy course; more event examples
Thoughts: would like to explore alternatives to the heavily used tools like truffle, infura, remix, for curiosity
Today's Progress: trial and error with strings- event and emit; Udemy course
Thoughts: an event is probably better for the whitelist array, but I'm not sure why entered strings can't be used as events
Today's Progress: Udemy course-- function calls and details, editing/finalizing AdvanceRequirement.sol
Thoughts: as I learn about Solidity's unique function and storage considerations, I'll seek to minimize gas to the extent possible
Today's Progress: Udemy course-- unique function considerations in Solidity including gas, editing AdvanceRequirement pull request
Thoughts: I should explore more efficient workflows on github, beyond just opening PRs on my own contracts
Today's Progress: experimenting with whitelisting in Remix; Udemy course-- deployment and running functions considerations
Thoughts: need to learn how to check if an address exists in an array, and whether it is more efficient to (i) use boolean to decide whether to input an address in an array, or create a struct of addresses with their boolean status-- I think the former.
To Do: decide whether to keep AdvanceRequirement streamlined (msg.sender or hardcoded address can mark as satisfied) and do the whitelisting in a separate contract or merge the PR
Today's Progress: experimenting with string input and memory/gas considerations in Remix; start Udemy course
Thoughts: having some issues with a "one time" input string, there is likely a simpler solution. Could also leave as a clause to be incorporated directly into an OpenLaw template, so the context is merely a reference.
To Do: map the address of the favored party for AdvanceRequirement.sol and state change for the condition string, consider also triggering ERC721 transferTo
Today's Progress: ERC721 Transfer standard and mappings, finish cryptozombies lesson 5: tokens, libraries (safemath)
Thoughts: the transferTo v. approve standard is important if I want (i) owner to initiate transfer or (ii) recipient to request and owner to approve (two steps). The former seems more relevant for ERC721 representing title, an interest, and/or permissioned access, latter perhaps for auctions
Today's Progress: trial and error with strings in AdvanceRequirement.sol, start Udemy course and cryptozombies lesson 5: tokens
Thoughts: need to figure out how to have a whitelisted address input a string once that cannot be subsequently altered (even by that address);
Today's Progress: create AdvanceRequirement.sol, finish cryptozombies lesson 4: random numbers, modifiers, if/else
Thoughts: important to keep track of the various instances where modifiers streamline, will need to look into other random number solutions (like chainlink's VRF)
To Do: add a function to store the address of the favored party for AdvanceRequirement.sol and either hash the text of the requirement or input a description and section reference | edit: done, Day 8, but need to restrict via require()
Today's Progress: Cryptozombies Lesson 4: for loops, payable, withdraws
Thoughts: payable introduces some unique commercial and legal questions, in requiring a certain payment to the contract in order to execute a function in a single call (what if no performance? offer/acceptance issues?) require(msg.value == 0.001 ether); transferThing(msg.sender); js front-end: OnlineStore.buySomething({from: web3.eth.defaultAccount, value: web3.utils.toWei(0.001)})
Today's Progress: Cryptozombies Lesson 3 re-review: custom modifiers (onlyOwner, etc.) and declaring arrays; LexDAO hack call and discussing empty modifier call with @Ro5s, bool syntax
Thoughts: Shame contract: https://etherscan.io/address/0xee4550f61da479274a08e2396684cda7a8295a6e#code and tweet: https://twitter.com/r_ross_campbell/status/1267999654890876928?s=20
Today's Progress: Cryptozombies Lesson 3: external dependencies, ownable, modifiers, gas considerations, declaring arrays, for loops
Thoughts: Solidity has some unique considerations for gas, such as keeping as much in memory (instead of storage) as possible. I'll need a lot more practice with passing structs as arguments, declaring arrays, and modifiers. Visibility modifiers are imperative for confidentiality, security, IP, and many other considerations: private means it's only callable from other functions inside the contract; internal is like private but can also be called by contracts that inherit from this one; external can only be called outside the contract; and public can be called anywhere, both internally and externally
Today's Progress: Cryptozombies Lesson 2: interacting with other contracts, If statements, internal/external, storage/memory, require(), msg.sender
Thoughts: I'm going to need to emphasize the basic logic flow of arrays, interfaces, modifiers.