currently running on keybase @kbhonest
a fun (for me) combo of a few of my favorite things. It is
I really like that the Keybase security model includes pinning data to Bitcoin. It's an elegant solution to a very specific security issue (what if the Keybase servers collude with, for example, someone who has stolen your recently revoked device) that makes for a compelling, non-monetary use of the blockchain. Timestamping in general is interesting, but anchoring the security of an application platform to guarantee no one is missing any updates they need is just
.
If my running bot is the only instance of anything posting these proofs, and if the Keybase servers know it's happening, then they could just withhold these messages from you, which would admittedly defeat the purpose. On the other hand, if multiple people were running it, they would have a harder time identifying all of them. Better yet, if you ran the bot inside a private team (i.e. all of the messages were sent to a channel that could only be read by team members), then the members of the team could check against the published proofs for their own private guarantee.
If you want to peep my work (which would be super cool of you), I definitely recommend skimming my code to make sure it's doing what you think, especially all the PGP and hashing stuff (which is in merkle_root.py
). Suggestions welcome.
If you want to use the ots
CLI to see these proofs in action, here's some shell commands to do that. If you have a Bitcoin node and Keybase running locally, then it would look something like this:
# fetch the contents of my most recent `VERIFIABLE` proof
keybase chat api -m '{"method": "read", "params": {"options": {"channel": {"name": "kbhonest", "public": true}, "pagination": {"num":20}}}}' | jq '.result.messages | map(.msg.content.edit.body) | map(select(. != null)) | map(fromjson | select(.status=="VERIFIABLE"))[0]' > msg.json
# pluck out and decode the data that was timestamped
cat msg.json | jq -r '.root.b64stamped' | base64 --decode > ./sighash.dat
# pluck out and decode the OTS data
cat msg.json | jq -r '.ots' | base64 --decode > ./sighash.dat.ots
# do the ots verification
ots verify ./sighash.dat.ots
If you aren't running Bitcoin on this machine and you don't want to wire up an RPC connection, you could do this instead of the default verify
:
ots --no-bitcoin verify ./sig_hash.dat.ots
ots info ./sig_hash.dat.ots
And you'll see the Merkle path and block height.
ots stamp
with those bytes. This creates a "preliminary" timestamp proof, and submits it to a bunch of calendar servers. It's not actually in the Bitcoin blockchain yet though.PRELIMINARY
or VERIFIABLE
)PRELIMINARY
status) so everyone in the world can read it.PRELIMINARY
messages.ots upgrade
them. If it works (i.e. the OTS proof has made it to the blockchain), edit the keybase message's JSON to have the new OTS proof, and change the status to VERIFIABLE
.It's a dockerized python3 chatbot using pykeybasebot.
./env_file
make
, so if you're wondering how something works, I suggest starting there.brew install pipenv
KEYBASE_USERNAME
and KEYBASE_PAPERKEY
.
cp ./env_file.example ./env_file
code/*.py
with your preferred logic.make run
to spin it up locally. make kill
from another shell will bring it down.make shell
to get a bash terminal inside the container with your keybase user logged in. This is extremely useful when developing a keybase chat bot.make shell
) by running keybase chat delete-history $KEYBASE_USERNAME --public
env_file
. You probably also need a ~/.aws
. honestly just look at the fargate cli stuff.make setup
will create everything you need in AWS. You need to run this once. And you can undo it by running make destroy
.make deploy
will push the artifacts and scale it up to 1 running instance. make pause
will scale it down to 0 instances, allowing you not to have to repeat make setup
.