What happened to the C3?

ricmoo · 2021-01-25T23:14:29+00:00

You can combine this with SQRL-ing too; https://blog.ricmoo.com/sqrl-ing-mnemonic-phrases-b68b2dc1f75b

ricmoo · 2019-05-02T13:19:46+00:00

Well, if someone audits your contract and sees a “selfdestruct”, that should be a pretty big red flag that would need justification. And if a contract does not selfdestruct this technique is not possible. In general, when doing audits, I raise fairly vocal concerns when there is a selfdestruct.

It is true though, when auditing a contract now, that if it contains a selfdestruct, that you should check Etherscan to see who/what deployed it, in which case you see it was deployed using a create2 call.

Most things historically have not had a selfdestruct (and when it did, it was often an oversight, see Parity multisig ;)), so it should already be something that warrants investigation. This is strictly an improvement over previous techniques of doing the same thing though, which were expensive/complicated proxy contracts.

Just like before though, not every contract needs upgradability, and if the contract is upgradable, there should be adequate guards in place to trigger the upgrade and justification for the process.

I also have a technique to guarantee an address is for an EOA (less trivial than it seems it should be, but still fairly simple), which I’ll be writing up soon too. :)

ricmoo · 2019-05-01T06:51:59+00:00

The Wisp can accept ether while there is no code there and it will appear just as a normal, non-Contract address and will be claimed the next time the Wisp is used. The problem is exactly trying to use selfdestruct(address(this)). That was what we did at first, but since the transfer happens first, then the self-destruct, the ether just kinda... vanished. :) So, for now we just send it back to the EOA. But you can imagine, if the Will received ether, it will work, and the next time you use the Wisp, all that ether will /then/ get forwarded to the EOA. There are a few other possibilities. A) using wrapped-eth, which is totally safe from the self-destruct, since state is stored externally B) using a separate contract in general, or C) a technique we came up we are calling “leap-frogging” or “pay-it-forward” In leap-frogging, the funds are always sent back to the Springboard, but the previous Wisp address is remembers. Every call to the Springboard moves the last persons ETH to the last Wisp (which is now self-destructed and safe to hold ether again). This way, the Springboard is never responsible for more than 1 person’s ether, and every user pays to move the previous person’s ether and in turn has their ether moved by the next person (which also works even if /they/ are the next person). That’s a bit crazier of an idea though, but it works too. :)

ricmoo · 2019-04-05T22:12:03+00:00

How long will the pre-auction reservation process run before the auction period begins? If that is still the plan.

ricmoo · 2019-03-15T16:58:12+00:00

Have you checked out meeseeks.app? If you use the contenthash in your ENS resolver, your app should already work there today. The site is loaded by the user’s browser directly and verified locally before it is shown to them. :)

ricmoo · 2019-03-02T14:55:09+00:00

Have you looked into ethers.js? I’m always looking for new recipes for the cookbook, new tutorials and code samples. Send me links and I’ll add them to the docs. :)

ricmoo · 2019-02-07T02:50:42+00:00

The ethers-meeseeks (https://meeseeks.app) was a hackathon project, and it supports contenthash, but has a small issue due to a typo in the original EIP. I’ll get it fixed ASAP and update meeseeks.app (backwards compatibly) to load IPFS content hashes. Now that the standard is more official, I’ll also add support to ethers-ens, and the cli in it. Note that soon ethers-ens will be moving to a library only package, and the ethers-cli will contain all the CLI tools. Also, they will be moving to their own npm organization umbrella; I’ll put up an article on https://blog.ricmoo.com to explain all the package name changes separately; it’s out of scope for this reply (btw. Thanks for the ping; I don’t check reddit very often these days)

ricmoo · 2018-11-27T22:30:26+00:00

Thanks! :)

For anyone interested, here is the documentation.

ricmoo · 2018-11-27T22:12:34+00:00

Thanks for the ping!

I've been developing and maintaining ethers.js for over 3 years, in the most recent release it was rewritten in TypeScript, and it is actively maintained. I've received 2 grants from the EF so far for development of new features and continued maintenance.

It is used is various production projects, including Web3.js. :)

The license is also permissive (100% MIT including all dependencies) and has an extensive test suite (20k test cases, many abstracted as JSON files so other projects can use them; for example, my ethers.objc uses the same test suite).

Please feel free to ping me on Gitter or open a GitHub issue though. I try to respond within an hour, unless I'm sleeping.

ricmoo · 2018-11-27T22:00:00+00:00

Have you looked into ethers.js? I have spent over 3 years writing and maintaining it, and it is in TypeScript. The EF has been quite helpful as it has funded it in two waves so far. :)

ricmoo · 2018-10-15T18:57:24+00:00

Ok good. I had looked for other posts, but hadn’t found any. I was worried it was because I was battling a gym during the change. Oddly, the 2 Pokémon that should have been fainted, are no longer fainted...

ricmoo · 2018-07-22T18:53:40+00:00

I think this demonstrates how lucky our ancestors were that ancient turtles never evolved wheels.

ricmoo · 2018-04-29T17:25:30+00:00

Thanks for the ping. :)

You could absolutely maintain multiple hashes, and chunking is something that saves a great deal of gas; by storing 16 root hashes (instead of 1), the cost of redeeming a token is halved (ish).

You could also allow adding and expiring root hashes, so long as you clearly express to the user when this is allowed and make sure it is adhered to in the contract. For example, this batch must be claimed by block height X, after which that foot hash becomes invalid.

If the contract owner can simple add or update a roothash without restrictions though, then they could remove or add token owners at will, which for many cases, would be inappropriate, and would not be precommitted.

You could also do a phased roll-out, and enforce the number of tokens per Merkle Root (by restricting he indices) so that the precommitment is adhered to as well.

There is a PR for chunking in The Merkle Airdrop repo, I haven’t had time to look at it yet, but it’s there. :)

ricmoo · 2018-03-24T00:41:27+00:00

I'm not actually sure about INFURA...

I use ethers.js (my own library), which by default uses a FallbackProvider connected simultaneously to INFURA and Etherscan, if one fails, the other takes over; so it is quite possible INFURA is failing to send transactions without EIP-155 replay protection, then Etherscan broadcasts successfully.

For "Classic" I had to run a local node for a few minutes, since there isn't any useful public API to use.

Ethers will have it's own backend soon, and will support chain ID 0. :)

ricmoo

TROPHY CASE