Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Canary Interface ERC #801
The canary can e.g. be used as a warrant canary.
Solves the following problems with current (warrant) canaries:
Signing a news headline is more work and less secure than using Ethereum for this task. The effort it takes to sign a news headline also leads to organisations not going this route at all and e.g. just adding a signal to twitter or some other site - which is way less secure and brittle.
ERC-801 could be the standard to solve this problem
in the same post:
The immutability of Ethereum can also help here.
Makes it also possible to keep the canaries alive with hardware wallets and improve security this way.
I think there should be a uint256 "lifespan" variable rather than the TTL implementation, defined as a block number. If the lifespan block number is less than or equal to the current block number, the canary is dead.
feed() would take a duration parameter that is added to the current lifespan.
addFeeder() should have additional parameter maxLife that functions as a cap to the amount feeder's can add to the lifespan.
Valuable effects would include:
• large enough negative values to feed() potentially replace poison(), and other (smaller) negative values allow for reducing canary lifespan without killing it (useful if the canary user knows there is an impending warrant and wants to provide notice sooner, but is unable to update it themselves to immediately kill the canary)
• allowing feeders to extend lifespan by varying amounts (useful for when somebody knows they will be unable to feed for a period of time greater than the TTL, but doesn't expect a warrant to be served in the mean time)
• disallowing certain feeders from being able to increase the lifespan (kill only if maxLife is a large enough negative value assigned to a certain feeder, one reason why lifespan should be defined as a block numer)
Thanks for the feedback! Like the ideas and will most likely change the proposal to address most of them - just not sure about timespan per feeder yet - have to think about this a bit. But am glad I did not yet implement as otherwise I would have to throw away code to fit the new API
I would urge not to include a permission management interface (the
Consider a Canary whose only feeder account has been compromised. If it is possible to transfer its permissions to another account, that is in full control of the attacker; then revoking or destroying the initial compromised feeder (disbanding a multisig, deleting a proxy contract, whatever other additional means might have been used) would do nothing for the Canary. It can still be fed by an attacker.
Including an interface is proposing people use it; and suggesting that it is sufficient.
Making an interface optional for concrete implementations - or for people to use - is asking for a systemic edge case, where interpretation of the result isn't binary.
I think some of the ambiguity can be left open, but it's better to do so explicitly, like,
"implementations can choose the authentication method of this function freely."
It's when you want to give limited abilities (kill only), or have tighter control over the lifespan of the canary (reduce time until it expires, extend the time in varying amounts), that adding additional feeders becomes useful.
The worst-case scenario should be that the canary contract owner PK is compromised, and the owner must redeploy another contract and push some updates to their website or other platforms that display info on the canary to make the original one irrelevant. I don't think this would cause significant harm if it were to happen.
I don't think it's the contract's responsibility to protect the owner's private key. That should be assumed.
@pirapira Was also thinking yesterday there is already too much implementation detail in here and split things up. And already a lot of new ideas came up in the comments here. So I was thinking what really defines the Canary? And in the end it might be just:
Then other ERC might specify different types of canaries (getType()?) - like SimpleCanary, MultipleFeedersCanary, AutomaticContractTriggerCanary, NegativeFoodCanary, ..
Guess my thoughts match with the previous two comments, except arriving at a similar conclusion by different path.
Below tangent to the PR; sorry.
I beg to differ!
If we consider "push some updates to their website" as a valid escape from a "feeder PKs compromised" scenario, then the purpose of using a blockchain is moot.
My concern is not for a human being browsing a website (even an IPFS/Swarm one), where an update can be pushed without warning.
My concern is for an automated agent, for whom the canary may be the only source of truth.
The only acceptable outcome on "feeder PK compromise" - or any other failure that is likely to lead to disaster - should be death of the original canary. It must not be allowed to linger!
This brings in the question of how exactly was the key compromised - and there are many scenarios for this one. My first comment briefly describes one where, even if the original feeder's keys are destroyed, the canary stays alive.
This is made possible by including an interface that's not essential for the basic purpose of the contract. It might as well be implemented elsewhere (and I argued that it should).
Which brings up the second point:
Let's not assume a particular use, e.g. "I haven't been served a subpoena".
For example, EAC used a canary to indicate service availability. So, although the canaries themselves did not hold funds for anyone but the service operator, it was certainly not safe to use the service if the canary was dead.
In short: when speaking of the canary's security, it is not (only) the canary itself that is being protected, but (also) what the canary represents.
Something that occurred to me - this contract probably wouldn't require much modification to be used as a way to release funds in the case of losing control of a private key (loss/death/capture).
If the contract isn't pinged with a feed()-like transaction regularly, it automatically releases stored funds to a specific address or ENS name. Personally, I would use something like this and set the interval to be something like 1 year between feed() calls.
Would this be a new ERC or something integrated into this contract?
Have you given thought to integrating with Ethereum Alarm Clock for the RIP event / the Dead Man's Switch?
@hyperfekt sounds reasonable - but I like KISS in the beginning and getting complicated later
@hyperfekt I just wrote an updated canary contract for the ethereum alarm clock that is similar to what I think you're proposing. It schedules a transaction to itself every two hours and if one of the transactions fails it dies. It implements the
As to your point about event notifications in the alarm clock I'm not really sure what you mean. If you'd like to join us on the Gitter chat , we are currently making some changes to the contracts and are open to ideas