A censorship resistant deadman's switch
killcord.io
A censorship resistant deadman's switch
1–10 of 69 posts
Re: A censorship resistant deadman's switch
#2Censorship resistant, until someone takes down the “publisher tool meant to run autonomously on a trusted system”.
Re: A censorship resistant deadman's switch
#3Censorship resistant, until someone takes down the “publisher tool meant to run autonomously on a trusted system”.
Water resistant vs water proof
Re: A censorship resistant deadman's switch
#4Censorship resistant, until someone takes down the “publisher tool meant to run autonomously on a trusted system”.
And a landing page that omits this fact (but contains download and instructions for a command line tool). If you're thinking "wait, I can't put a self-publishing secret on the Ethereum blockchain, how does this even work?", the landing page leaves you hanging.
Re: A censorship resistant deadman's switch
#5This is interesting, but runs contrary to my understanding of how Etherium works. I'm clearly missing something, any chance you (or anyone else) could elaborate more?
My understanding was that the decentralization of Etherium would mean that everyone watching the contract would need a copy of the decryption key. If that's the case, what prevents someone from publishing keys early? Or is it that the key isn't stored in Etherium, and Etherium is only being used as the consent to publish?
If the key is being stored somewhere else and just waiting for the contract to validate, how do we prevent a censor from just attacking that system?
If the key is being stored somewhere else and just waiting for the contract to validate, why not also store the contract on the same machine and do checkins directly into that? Would that be significantly less secure/reliable?
Re: A censorship resistant deadman's switch
#6This is interesting, but runs contrary to my understanding of how Etherium works. I'm clearly missing something, any chance you (or anyone else) could elaborate more? My understanding was that the decentralization of Etherium would mean that everyone watching the contract would need a copy of the decryption key. If that's the case, what prevents someone from publishing keys early? Or is it that the key isn't stored i…
Quick browse seems to be like so:
1. Client generates necessary files (including keys and payloads).
2. Encrypted payload is placed on IPFS.
3. Keys are placed on a trusted published (potentially single point of failure).
4. A smart contract running on the EVM continuously checks for pings from clients. If client doesn't check in over some pre-defined policy, then trusted published will be aware and publish keys to the smart contract, visible to everyone.
Re: A censorship resistant deadman's switch
#7What if the miners deny check-in transactions to force the killcord to execute?
Re: A censorship resistant deadman's switch
#8Censorship resistant, until someone takes down the “publisher tool meant to run autonomously on a trusted system”.
Even if the web front end is taken down, the contract is still on-chain so it can be accessed via a web3 browser, a client or even in etherscan in the "read contract" tab.
Re: A censorship resistant deadman's switch
#9This is interesting, but runs contrary to my understanding of how Etherium works. I'm clearly missing something, any chance you (or anyone else) could elaborate more? My understanding was that the decentralization of Etherium would mean that everyone watching the contract would need a copy of the decryption key. If that's the case, what prevents someone from publishing keys early? Or is it that the key isn't stored i…
Quick browse seems to be like so: 1. Client generates necessary files (including keys and payloads). 2. Encrypted payload is placed on IPFS. 3. Keys are placed on a trusted published (potentially single point of failure). 4. A smart contract running on the EVM continuously checks for pings from clients. If client doesn't check in over some pre-defined policy, then trusted published will be aware and publish keys to t…
Is that... good? I mean, I understand that security isn't black and white, and really you're just trying to make it harder for someone to attack you, not impossible. But how much do you gain by decentralizing just the trigger?
Since the trigger logic fundamentally relies on you doing something, it seems like that logic could be local to machine, your machine could query any number of public websites/platforms/IPs and it would still be pretty difficult for anyone to censor you.
It also seems like a party that wanted to force you to publish early would not be hampered in any significant way by Etherium. In either scenario, all they have to do is incapacitate you or block the IPs that your machine is looking at.
I still feel like I'm missing something. Would anyone be willing to break down a (fictional or real) scenario where adding Etherium to this equation blocks an attack?
Re: A censorship resistant deadman's switch
#10Earlier quoted context omitted.
Quick browse seems to be like so: 1. Client generates necessary files (including keys and payloads). 2. Encrypted payload is placed on IPFS. 3. Keys are placed on a trusted published (potentially single point of failure). 4. A smart contract running on the EVM continuously checks for pings from clients. If client doesn't check in over some pre-defined policy, then trusted published will be aware and publish keys to t…
Is that... good? I mean, I understand that security isn't black and white, and really you're just trying to make it harder for someone to attack you, not impossible. But how much do you gain by decentralizing just the trigger? Since the trigger logic fundamentally relies on you doing something, it seems like that logic could be local to machine, your machine could query any number of public websites/platforms/IPs and…
If your machine is within range of your enemy, then they could simply destroy or disable it before publishing (a single point of failure).