And you are here why?

“ What happens after May 25th, 2018 to data on blockchains? ” The context being around Article 17, and the "right to be forgotten" . The answer, of course is some combination of “ It’s tricky ”, “ It depends ”, and “ It’s complicated ”. For the nonce, I’m going to ignore Personally Identifiable Information (PII) that’s actually placed on public blockchains. If you did that, or are doing that, well, good luck — you’re going to need it. On the private/permissioned blockchain side, there are a couple of options out there ( Note: By “private/permissioned”, I mean that the blockchains are deployed in an internal/controlled environment ) 1. Store PII elsewhere : This is the most obvious route, where you store PII in a separate database / storage / whatever, and you effectively do a JOIN on this data whenever you do blockchain stuff. The upside is that when you get an Article 17 request, you can nuke the data in this separate store and you’re done. The downside is, well ...

(Apologies, I couldn’t resist the image/pun). Regardless, you   know   that hash trees have been used to validate data ( since, well, 1979 I guess ) in all sorts of arena, from databases like Cassandra, Dynamo, and Riak, to version control systems like git and subversion, to a host of file systems. They weren’t invented just for Bitcoin   Anyhow, here’s another nifty use case — using merkle trees to do immutable deploys of websites at   Netlify . Why immutable deploys? A bunch-a reasons, including •   atomic deploys and instant rollbacks , • the ability to   accurately   preview deploys   (by dereferencing the name from the content, you just point the name at the new hash behind the scene), • split testing   (transparently routing requests to different versions of the site), and a whole bunch more. The way they do this is pretty nifty • They identify and store all files based on the hashes of the content (not the names!) • A de...

How do you  guarantee  that the data in your database is immutable? In particular, I’m talking about data that you  don’t want to change — things like call-records, historical data, transaction logs, etc. Of course, you could use something like  Datomic , or you could architect your application/data-structures/tables/… from the ground up to be immutable, but that could be … problematic. Especially problematic, in fact, given that I’m referring to your  existing  databases that have all this stuff in it — good luck trying to convince the business side of the house that you need to re-architect  everything ! Theoretically , this data should already be immutable, but, the reality is that there are  so many  attack vectors. 1. One of your developers could go in and tweak the data — you’d never know 2. Oh, only the DBA has access? What if  they  tweak it? 3. Worse, what if somebody hacks into your system? 4. Even worse, ...

You’ve heard of Luhn, right?   Hans Peter Luhn ? Dude who invented the Hashing Algorithm? Well, for those of you who weren’t paying attention somewhere really early in CompSci 101,   there is an excellent writeup on his legacy in IEEE Spectrum . In early 1953, Luhn had written an internal IBM memo in which he suggested putting information into “buckets” in order to speed up a search. Let’s say you wanted to look up a telephone number in a database and find out whom it belonged to. Given the 10-digit number 314–159–2652, a computer could simply search through the list one number at a time until it found the relevant entry. In a database of millions of numbers, though, this could take a while. Luhn’s idea was to assign each entry to a numbered bucket, as follows: The phone number’s digits were grouped into pairs (in this case, 31, 41, 59, 26, 52). The paired digits were then added together (4, 5, 14, 8, 7), from which a new number was generated, consisting of each single...

Say you want to set a canary trap (°°) in your #SecretSauceDocument. You could embed a bunch-a “invisible unicode” like zero width spaces, confusables (different versions of “l”, “a” etc) and track them. Or, you can use #steganos (°°°) a small library of tricks — called branchpoints — that swap out • single quotes for doubles, and vice-versa • words for numbers (ten vs 10) • contractions (won’t vs will not) and so on. With the above, you identify the specific version of the original document based, and hence the leaker 🙌 Adding these fingerprints to an immutable store for auditability and verifiability (maybe on some verification oriented  #blockchain  like  #Factom ) would be both awesome — and, frankly, somewhat frightening 😱 (°) There is also a unicode version available, but that’s less fun 😇 (°°) Canary Trap —  https://en.m.wikipedia.org/wiki/Canary_trap (°°°) steganos —  https://github.com/fastforwardlabs/steganos

Rolling Your Own Consensus  is clearly the blockchain version of  Rolling Your Own Crypto. Reasons for doing so that I have seen include, • I have a Better Way To Do Things  (No. You don’t.) • It shouldn’t be hard, therefore it isn’t  (Why? also, Yes, it is.) • What could possibly go wrong?  (Yup) • We’re on AWS, so net-splits aren’t a thing  (Oh yes they are) • Or outages  (Ha. ha. ha. ha. ha) • Who cares what the academics think, this is the real world  (Yikes) • We use redis for co-ordination  (Sigh) • Actually, redis-cluster  (Double sigh) Next time you’re faced with one of these, I recommend running away. Immediately. With vigor. Mind you, if you  can’t  run away, try asking some combination of 1) Is it proven? 2) Really? 3) With Math? 4) And peer-reviewed papers? For extra credit, ask if they redid Paxos or Raft,  without the un-necessary parts. And  then , run away. Immediately. With v...