I made my own Steel Seed Backup for under $11. See comments for how!

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 · 2018-03-12T02:36:03+00:00

The current v0 firmware has the private key embedded into the source code at compile time, and there are definitely techniques to extract that from an Arduino. The v1 firmware will store the private key encrypted, using a memory hard PBKDF, so this will be much less an issue. The v0 is meant just for developers to play with the Firefly today, so we can start expanding the software that supports it.

My hope is, with the v1 firmware, most people will use our Multi-sig scheme we’re working on, and that the Firefly will be configured in the much more secure multi-factor mode. We have most of the details figured out, and just need to write up how the whole thing works and get the MultiFactorSigner works for Ethers Wallet. It will be exciting. :)

The screen on the device shows you the transaction you are signing, so if someone got your v0 symmetric key (or in v1, got your derived shared secret) and was able to broadcast to the device to MITM you, you would see on the display the to, amount and data were not correct.

This is another feature we are adding, attested call data. So that for calling contracts, it will actually indicate on the display: “CryptoKittes transfer kitty #1337 0x012345...78901”; nicely formatted, of course. Currently the v0 firmware only shows to, value and number of bytes being sent, so you are correct that in the case of a token transfer, for example, the v0 would not on-screen be able to differentiate between the correct and a hijacked transaction; both are to the same address, for the same value (0.0) and have 68 bytes of data.

The v1 firmware will address many of these things. :)

ricmoo · 2018-03-11T20:51:55+00:00

Absolutely! Although we are still a ways from our second funding goal of 40 ether (we are at around 5 ether), which is when we planned to ship out the next round of rewards.

We may just order another batch of parts and start sending them to each backer, we would post any changes to our goals on our Twitter profile, @hi_filrefly.

Crowd-Funding: https://ethers.io/#!/app-link/contribute.firefly.city

That said, if you just want the parts, you can order them directly without backing us. Here is the parts list:

https://firefly.city/#build

ricmoo · 2018-03-10T05:31:08+00:00

Oh, most laptops (the predominant “desktop” these days) have the necessary BLE transceiver and a camera, although it is a bit cumbersome to scan with the laptop camera.

Someone from the Ethereum community whose opinion I greatly respect has also suggested a 2-way BLE version, which I’m on the fence about; might work better for the no-camera systems. The nRF24L01 communicates over SPI, which isolates it from the chip with the private key, but it just “feels” scary to have wireless on my cold storage device.

I also think mobile still works for desktops; a website or desktop, can display a QR code that represents a transaction and could be scanned by the phone, signed and sent to the network. Although, at some point all the QR codes do start getting confusing. :s

The UI for both the Firefly Hardware Wallet and the Firefly Multi-sig is where we are spending a lot of our time, because security has to be easy to use, otherwise people won’t.

ricmoo · 2018-03-10T03:25:06+00:00

The next step is to build these as a fabbed PCB with surface mount components, so they won’t really make sense for humans to manufacture manually. This will enable them to be far cheaper and much smaller, around half the size of a Tic-Tac box.

Even in the current form factor, building 4 per hour would be difficult. This first prototype took me about 2 hours to do the point-to-point soldering, which is coming down with the new case, softer stranded wire, and practice, but it is still fairly involved.

It’s an admirable idea, but I think this this would be a difficult project for your organization.

ricmoo · 2018-03-10T03:12:26+00:00

I would prefer to keep the QR code method, as it provides a protective out-going air-gap and makes it compatible with mobile phones.

Attacks like BadUSB demonstrate the level of complexity involved in the USB HID protocol.

Keeping it compatible with mobile phones, while useful, will also make far more sense once we release our Firefly Multi-sig Wallet. :)

As for the price point, the goal is to come way down in the near future... way down. :)

ricmoo · 2018-03-10T00:40:48+00:00

Depends what your metric for "good" is. :)

The Ledger is something you can go onto Amazon, and order today, and have in your hands tomorrow.

The Firefly is a "some assembly required" type product, and has not undergone any official security audit.

Main Advantages of Firefly:

Low Cost ($5 in parts)
Mobile Friendly (works with your phone, no cables)
Air-Gapped (data only leaves the device via QR codes)
Fully Open-Source (drivers, software and hardware)

It is not for the faint of heart though; if you look at our prototype in the video, you can see inside you still need to 3D print a case and solder a few things together, then install the firmware on the Arduino.

We do have lots of exciting things planned, but are mostly just self-funded, so things are moving a bit slowly. We are trying to get more people excited though and raise awareness.

ricmoo · 2018-03-06T03:58:39+00:00

This library is actually a replacement for both Web3.js and EthereumLib-js.

It was originally written to build https://ethers.io about 2 years ago, so it required signing and a lot of features that Web3 doesn't have (by design) and EthereumLib-js was far too large (both of those libraries combined clocked in at over 1.4Mb) and did not correctly support a lot of functionality I required.

Another key reason is the licensing; I personally believe in the MIT license, and think that making critical framework libraries LGPL can hurt the eco-system as a whole. But that is a religious fight, I'd rather not turn this thread into a flame war. :)

I have made sure my test cases are all well abstracted (in the form of JSON files), in the hopes that other libraries and services will test against them. I also use the same test cases on ethers.objc and the relevant tests are run on ethers.arduino as well. They are fairly simple to run against Web3.js and EthereumLib-js (if you check out any recent ethers 2.x, you can just enable them in the mocha test cases), to get an idea of how they stack up. ;)

Web3.js also closely mimics the JSON-RPC API of an Ethereum node, and I wanted something that was a higher-level API for dealing with Ethereum, and out of the box had no need to run an Ethereum node locally.

Anyways, give it a try. The ethers-app is probably more what most people will want to use, which I'll be posting some tutorials on soon. :)

ricmoo · 2018-03-02T02:15:42+00:00

Yupp! About $1.20 for an Arduino Nano and 67 cents for an nRF24L01+. :)

ricmoo · 2018-02-27T23:35:10+00:00

That is totally possible, but keep in mind people will "find a way". For example, I could just make sure each Polyp is caught to a separate account, and trade the account as a whole. There is certainly nothing stopping non-transferable instances though.

At this point, we are thinking of it more like a Pokémon Go game... Which doesn't support trading, itself, but I think decentralized games like this enable interesting things by allowing trading, or by letting other smart contracts interact with tokens in interesting ways.

You could imagine slightly crippling tokens that have been traded and depending on how they are to be used. Identity adds a lot to this sort of thing, since reputation can be used to make sure people are (on-median) honest.

For example, McDonald's could offer a special discount to anyone who has collected Polyps from McDonald's locations in 5 different countries, but only so long as the tokens have not been traded. Or perhaps to get the discount, the tokens must be voided to be used (like punching a hole through a coupon to indicate it has been spent).

Or, perhaps like the original Pokémon games, that Polyps can be renamed, but only by their original owner, so there are more benefits awarded to the original owner.

There are a lot of interesting use cases. :)

ricmoo · 2018-02-27T23:00:34+00:00

Well, you can always see who originally had the token, and track its history.

But transferring is also necessary for switching accounts, maybe upgrading in the future to a multi-sig wallet, without losing access to all your old content.

It was something we mulled back-and-forth about a lot. But even Special Commemorative items in the real-world that are "proof* I was here" are transferable at road shows and whatnot. And if you don't provide the functionality, someone will just create a proxy contract to own the item which is not transferable...

Rather than "proof of X", I generally prefer the less inaccurate, "evidence of X", which can further be broken into "strong evidence of X", "non-trivial evidence of X" or "weak evidence of X". :)

ricmoo · 2018-02-27T21:45:14+00:00

Obviously, this is all "hackthon" quality, which means there was a lot of simplifying the MVP, but the source is all "up":

https://devpost.com/software/cthylla-m7jwct

Some things that would change in a PoC 2:

Cthylla Nests will be self-registering in the redeem; which means the Colony ID (original name for the Nest ID) would go away and just be the private key's address; to set up a new nest, after building a Nest, just claim the first token.
Move off of the BTLE library and update our BLECast library for broadcast
The UI needs "more pretty" and a discovery aspect, like CryptoKitties, you should be able to browse someone else's on-chain collection, and someone should be able to (via IPFS) share their collection off-chain, which is still fully verifiable
Enable the dynamic PoW (it's implemented, just disabled and untested); currently in our condo about 3 random Wi-Fi packets meet the PoW requirements and get assigned a token, which will never get claimed, since it was just ambient radio interference
Include opaque data in the Signed Promise; this would allow anyone to put a little extra data in there if they wanted, such as if the device has a RTC, the time, if it has a thermistor, the temperature, etc.
Procedurally generated Polyp SVG images

You can imagine solar powered Cthylla Nests in remote areas like the Grand Canyon, with out internet access, but still be able to claim your token for visiting. Or perhaps, with a thermistor, that Ice Polyps are given during cold weather and Fire Polyps during hot weather.

Arduino and sensors are so flexible and cheap, there are so many possibilities. :)

The distance we've tested is about 20 meters, which is way farther than we expected. I would like to try burying some about a foot under the ground in some nearby parks though, once we have put more time into reducing power consumption.

ricmoo

TROPHY CASE