Thanks. These sort of make sense if you have to conform to something like this.

I would argue things should just be "every 30 days" or "every 90 days," but I wouldn't be surprised if there are legitimate use cases for something like "on the 1st of every month," like trying to interface with an existing system like a rent contract.

Theoretically, there's no reason all the transactions can't be included in the same block. (They just need to be in order.) That said, I have no idea what logic various miners apply when deciding which transactions to include in which blocks. I've heard claims that in practice they do not appear to include multiple transactions from the same account in the same block.

If sending from multiple accounts is a possibility, that would certainly avoid this concern, but only you know whether that's a reasonable solution for what you're trying to do.

You only need to use indexed if you want that parameter to be indexed. The actual fix is to not use the name from. I assume it's a reserved keyword.

In your code, you switched to _from, which is a good fix. Events also need to be declared before global declaration and function definitions, so the Deposit event has to be moved to the top of the file.

There are two ways to assign a value to keyHash: setup() and update().

If the keyHash is initialized via setup(), then everyone knows the key. If it's initialized via update(), then no one knows the key (only the hash). Whichever one is called first wins. (The other is a then a no-op.)

So I assume that update() was called before setup() was. Etherscan doesn't show "internal transactions" that don't involve an ether transfer, so the trick is probably that update() was called by another contract, and thus the transaction doesn't show up. Because no one knows the key that will hash to the given value of keyHash (except presumably the contract's creator), no one can withdraw the balance.

Bitwise operations are very useful in Solidity, and I would recommend using them for the particular purpose outlined in the article, due to their simplicity.

With that being said, checking the 0/1 value of a prime number multiplication requires one modulo operation (5 gas). Checking the bit value of a uint with a corresponding bit field would use the following equation:

return uint8(self >> index & 1) ... which is equivalent to ... return uint8(self / 2**index & 1) ... which is unclear as to whether it has an equivalent gas cost for division (5), multiplication (5), and the and operator (3) for a total of (13). It's all negligible at that point, in my opinion.

In the uint8(self >> index & 1), you would need to pass through the Payment_Preference value as self, the index you want for a specific stablecoin, and perform the operation from there. You would not be able to precompute all values preemptively, unless you wrote 5 different modifiers for each index instead of using a modularized modifier that accepts parameters to retrieve the bit value at a specific index as desired.

This isn't correct. Transactions do have return values (you can see them on parity traces, for example) it's just Ethereum never exposes them, so without a trace you can't get them out. Note that even external transactions between solidity contracts do get return values, so external functions with a returns still make sense in many cases.

I think I would disagree, but this is purely a semantic issue at this point that doesn't really affect the issue at hand.

Speaking of semantics, I'd also quibble with the idea of "transactions between Solidity contracts." Such calls are not transactions. But yes, calling a function in another contract does give you a return value.

A fair criticism. We've tended on the blog to focus a lot on clarity and correctness of code, but it's also important to think about the gas requirements.

A little bit of math can easily get it down to 6 SSTOREs, and if we remove the ability of the seller to withdraw funds early, we could drop that calculation and get to 5 SSTOREs. We could squeeze together a few things into a single word (the high bidder and high bid) to get down to 4 SSTOREs or even 3 SSTOREs (by scaling time).

Any other suggestions for lowering the cost of the bid() function? We might do a follow-up blog post to show these optimizations.

Alice (off chain) does a double hash of the secret word: `keccak256(keccak256(secretWord))`, and gives the result to Bob.

Bob writes a smart contract that he initializes with

1 ETH

Alice's address stored as a contract variable

the double hash value stored as a contract variable

The contract also has a function that is only callable by Bob (`onlyOwner` type modifier). This function accepts a `bytes32` as an input parameter (call it `firstHash`). When called, the function does `keccak256(firstHash)` and compares the result (which is the "second hash") with the value that Bob initialized the contract with. If the values match, the 1 ETH is sent to Alice's address.

Only Bob can call the method, so Alice has to give the `secretWord` to Bob. Off chain Bob does the first `keccak256(secretWord)` to get the first hash, which he then sends into the contract to release the funds to Alice, all without putting the `secretWord` in a transaction.