Proof of prespecified endpoints in medical research with the bitcoin blockchain

by

Introduction

The gerrymandering of endpoints or analytic strategies in medical research is a serious ethical issue. “Fishing expeditions” for statistically significant relationships among trial data or meta-analytic samples can confound proper inference by statistical multiplicity. This may undermine the validity of research findings, and even threaten a favourable balance of patient risk and benefit in certain clinical trials. “Changing the goalposts” for a clinical trial or a meta-analysis when a desired endpoint is not reached is another troubling example of a potential scientific fraud that is possible when endpoints are not specified in advance.

Pre-specifying endpoints

Choosing endpoints to be measured and analyses to be performed in advance of conducting a study is a hallmark of good research practice. However, if a protocol is published on an author’s own web site, it is trivial for an author to retroactively alter her own “pre-specified” goals to align with the objectives pursued in the final publication. Even a researcher who is acting in good faith may find it less than compelling to tell her readers that endpoints were pre-specified, with only her word as a guarantee.

Advising a researcher to publish her protocol in an independent venue such as a journal or a clinical trial registry in advance of conducting research does not solve this problem, and even creates some new ones. Publishing a methods paper is a lengthy and costly process with no guarantee of success—it may not be possible to find a journal interested in publishing your protocol.

Pre-specifying endpoints in a clinical trial registry may be feasible for clinical trials, but these registries are not open to meta-analytic projects. Further, clinical trial registry entries may be changed, and it is much more difficult (although still possible) to download previous versions of trial registries than it is to retrieve the current one. For example, there is still no way to automate downloading of XML-formatted historical trial data from www.clinicaltrials.gov in the same way that the current version of trial data can be automatically downloaded and processed. Burying clinical trial data in the “history” of a registry is not a difficult task.

Publishing analyses to be performed prior to executing the research itself potentially sets up a researcher to have her project “scooped” by a faster or better-funded rival research group who finds her question interesting.

Using the bitcoin blockchain to prove a document’s existence at a certain time

Bitcoin uses a distributed, permanent, timestamped, public ledger of all transactions (called a “blockchain”) to establish which addresses have been credited with how many bitcoins. The blockchain indirectly provides a method for establishing the existence of a document at particular time that can be independently verified by any interested party, without relying on a medical researcher’s moral character or the authority (or longevity) of a central registry. Even in the case that the NIH’s servers were destroyed by a natural disaster, if there were any full bitcoin nodes left running in the world, the method described below could be used to confirm that a paper’s analytic method was established at the time the authors claim.

Method

  1. Prepare a document containing the protocol, including explicitly pre-specified endpoints and all prospectively planned analyses. I recommend using a non-proprietary document format (e.g. an unformatted text file or a LaTeX source file).
  2. Calculate the document’s SHA256 digest and convert it to a bitcoin private key.
  3. Import this private key into a bitcoin wallet, and send an arbitrary amount of bitcoin to its corresponding public address. After the transaction is complete, I recommend emptying the bitcoin from that address to another address that only you control, as anyone given the document prepared in (1) will have the ability to generate the private key and spend the funds you just sent to it.

Result

The incorporation into the blockchain of the first transaction using the address generated from the SHA256 digest of the document provides an undeniably timestamped record that the research protocol prepared in (1) is at least as old as the transaction in question. Care must be taken not to accidentally modify the protocol after this point, since only an exact copy of the original protocol will generate an identical SHA256 digest. Even the alteration of a single character will make the document fail an authentication test.

To prove a document’s existence at a certain point in time, a researcher need only provide the document in question. Any computer would be able to calculate its SHA256 digest and convert to a private key with its corresponding public address. Anyone can search for transactions on the blockchain that involve this address, and check the date when the transaction happened, proving that the document must have existed at least as early as that date.

Discussion

This strategy would prevent a researcher from retroactively changing an endpoint or adding / excluding analyses after seeing the results of her study. It is simple, economical, trustless, non-proprietary, independently verifiable, and provides no opportunity for other researchers to steal the methods or goals of a project before its completion.

Unfortunately, this method would not prevent a malicious team of researchers from preparing multiple such documents in advance, in anticipation of a need to defraud the medical research establishment. To be clear, under a system as described above, retroactively changing endpoints would no longer be a question of simply deleting a paragraph in a Word document or in a trial registry. This level of dishonesty would require planning in advance (in some cases months or years), detailed anticipation of multiple contingencies, and in many cases, the cooperation of multiple members of a research team. At that point, it would probably be easier to just fake the numbers than it would be to have a folder full of blockchain-timestamped protocols with different endpoints, ready in case the endpoints need to be changed.

Further, keeping a folder of blockchain-timestamped protocols would be a very risky pursuit—all it would take is a single honest researcher in the lab to find those protocols, and she would have a permanent, undeniable and independently verifiable proof of the scientific fraud.

Conclusion

Fraud in scientific methods erodes confidence in the medical research establishment, which is essential to it performing its function—generating new scientific knowledge, and cases where pre-specified endpoints are retroactively changed casts doubt on the rest of medical research. A method by which anyone can verify the existence of a particular detailed protocol prior to research would lend support to the credibility of medical research, and be one less thing about which researchers have to say, “trust me.”

BibTeX

@online{bgcarlisle2014-4232,
    title = {Proof of prespecified endpoints in medical research with the bitcoin blockchain},
    journaltitle = {The Grey Literature},
    author = {Benjamin Gregory Carlisle},
    address = {Montreal, Canada},
    date = 2014-08-25,
    url = {https://www.bgcarlisle.com/blog/2014/08/25/proof-of-prespecified-endpoints-in-medical-research-with-the-bitcoin-blockchain/}
}

MLA

Carlisle, Benjamin Gregory. "Proof of prespecified endpoints in medical research with the bitcoin blockchain" Web blog post. The Grey Literature. 25 Aug 2014. Web. 22 Nov 2017. <https://www.bgcarlisle.com/blog/2014/08/25/proof-of-prespecified-endpoints-in-medical-research-with-the-bitcoin-blockchain/>

APA

Carlisle, Benjamin Gregory. (2014, Aug 25). Proof of prespecified endpoints in medical research with the bitcoin blockchain [Web log post]. Retrieved from https://www.bgcarlisle.com/blog/2014/08/25/proof-of-prespecified-endpoints-in-medical-research-with-the-bitcoin-blockchain/


“Toward a bitcoin authenticator” or “getting rid of usernames and passwords, redux”

by

I make it no secret that I hate passwords. I hate them so much. I have even previously written on the subject, suggesting an algorithmic way of generating login credentials would be preferable.

Turns out, this method is already being used in some places, kinda

There already exists a fairly widely accepted manner of confirming identity that’s pseudonymous and persistent, and already installed on a fairly large number of computers—namely, bitcoin. If you download a bitcoin wallet or make a web wallet, you can generate as many bitcoin addresses as you like. It doesn’t cost anything, and no one else will have the same address as you.

Much ink has been spilled over the potential of bitcoin as an alternative currency, but a little-remarked-upon feature of bitcoin addresses is that you can use them to cryptographically sign a message, which other people can use to verify that the address in question is indeed yours. If you want to try it out, in Bitcoin-Qt, click File > Verify message … and you will see a window for signing and verifying messages. You can enter whatever text you like, and sign it with your bitcoin address.

So if Alice wanted Bob to prove that he owned a particular bitcoin address, Alice could choose a random string of letters and numbers and tell Bob to sign it with his address. Bob could send back the signature, which Alice could use to confirm that the message was signed by the address in question. This is pretty nifty, but it’s not super-useful, unless you’re very interested in confirming that someone has the means to pay for something in bitcoin.

That’s until you realise that …

This whole process could be automated and used as a web service’s login credentials

So imagine you were running some sort of web-based service where you wanted to have users log in. Right now, the normal way to log in is by having users provide choose a username and password. The weakness of this process is of course, the password, although the use of email addresses to restore forgotten passwords is also pretty insecure.

As far as passwords go, there are weaknesses on the user side, the transmission of the credentials, and the storage of credentials on the server side. Altogether, there are lots of ways that passwords can be stolen. There is no need to go into detail about how passwords are bad here.

An alternative might be to use a bitcoin address as your username. This would eliminate the need to choose a password at all.

Similarly to the case of Alice and Bob above, if Bob was going to log into Alice’s website, Bob would indicate that his identity is his bitcoin address, 1HYDtPQueJRa8tdxXqkKa8peZEJN1iKi57, and then Alice’s website could automatically generate text like the following:

[Log in 1HYDtPQueJRa8tdxXqkKa8peZEJN1iKi57 to www.alicewebsite.com valid until 2014-01-29 20:00 +0:00 GMT]

Bob could sign that message with his bitcoin address, giving him the following signature:

HJ0ToGqYok6PodXzkykjPE4JcoHEVSRa0hUmk/ZxEbJflrC7EbPDB18FXoVR0YA45yPEupkQCwLY3cnJhDNnip4=

You can check yourself that the message was properly signed with the given address using most bitcoin wallet software and on a number of web-based apps as well. Alice’s website could check that Bob’s signature was correct, and allow him to log in with the bitcoin address as his identity. Alice’s website could be programmed to recognise that signed message only once and only for only a few minutes.

In fact, this authentication process is already in use by some bitcoin mining pools. Eligius, for example, has no user names other than the bitcoin address used to send payouts for mining. Whenever a miner wants to make changes to her account, the service generates a code to be signed, and when it is properly signed, the changes are accepted. This means that there is no password list on the Eligius server to steal, and none to remember for its miners. It’s pretty clever, really.

There are a lot of good reasons why even non-bitcoin-related web services might want to adopt this method of authentication

The system is pretty simple. You just have to remember which address you used as your account.

The upside to using bitcoin addresses for login credentials are many. There are no passwords to be stolen / forgotten / recycled by users, and no list of passwords on the server. A system like this also protects one against the case in which Alice, the person running the web service is maliciously collecting user passwords.

Not only that, but a lot of people already have a bitcoin wallet. The algorithm for signing messages is standard, and the software is free and open-source.

There are some downsides to a bitcoin authenticator too

The first thing that people notice about bitcoin addresses is that they’re long and seemingly random strings of letters and numbers, which can be off-putting. We’re used to human-readable usernames, so that we can log in to our accounts on strange computers, with passwords that we also remember.

There isn’t really a way around this. This system is designed to prevent login credentials from being simple enough to be remembered by a human. That said, there’s nothing preventing a web service from allowing you to have a “handle” or a “real name” associated with your bitcoin address that could be human readable.

As far as logging in on multiple devices go, this might present a bit of a challenge, since a bitcoin address’ private keys are usually only kept on one device—the wallet on your computer, or in an app on your phone. A well designed web service could allow for a user to associate multiple bitcoin addresses together, so that she could log in to the same account on different devices that have different bitcoin addresses on them.

If you lose the private keys for your bitcoin address, there’s nothing anyone can ever do to recover them. You can see this as a bug or a feature. If you want to close an account on a web service forever, just trash the private keys for that bitcoin address, and no one can ever open it again. But if you have a hard drive crash, and you didn’t think to make a backup, or if you lose all your backups simultaneously, then there’s nothing that can be done for you.

Private keys, like anything digital, can be stolen—either by a person with a USB drive who’s physically at your computer, or by malware. Then again, this is also true of your encrypted password lists, and I think it would make the situation no worse than what we currently have with the username/password paradigm.

What’s next

MediaWiki is free and open source software. It is most famously used as the software that Wikipedia runs on. Because it is free software, anyone can take the source code and make a fork of the project, in which she adds her own new features. Same thing goes for WordPress. There’s part of me that’s very strongly tempted to fork both of these projects such that they allow bitcoin addresses for authentication, and then lobby to have it merged back into the main project.

But then the holdup for projects like these is always one of acceptance, rather than just the technical re-programming of the software. Anyone have contacts at MediaWiki or WordPress or other free/open-source projects, who would be open to this kind of suggestion?

Table 1: Levels of security for bitcoin wallets and analogues in user authentication

Bitcoins Passwords
Cloud Web-wallets
“Like letting a stranger hold a wad of cash for you”
E.g. Blockchain.info
Cloud-based password managers
“A million times better than what most people do”
e.g. LastPass
Local Locally stored bitcoin wallet
“At least it’s not a web wallet”
E.g. Bitcoin-qt, with encryption not enabled
List of passwords on local computer only
“At least you’re not using the same password for everything”
E.g. Excel spreadsheet on desktop
Local, encrypted Locally stored and encrypted bitcoin wallet
“Not the worst, but don’t keep your life savings there”
E.g. Pretty much any wallet has encryption by default
Locally stored and encrypted password list
“This is what most users would aspire to”
E.g. Keychain Access on the Mac
Offline Paper wallet or private keys on offline computer only
“The gold standard for bitcoin wallet security”
E.g. Bitcoin Armory paper wallet
?

(Edit 2014 Jan 29: Added Table 1 to aid in responding to Morty’s comment below.)

BibTeX

@online{bgcarlisle2014-3935,
    title = {“Toward a bitcoin authenticator” or “getting rid of usernames and passwords, redux”},
    journaltitle = {The Grey Literature},
    author = {Benjamin Gregory Carlisle},
    address = {Montreal, Canada},
    date = 2014-01-29,
    url = {https://www.bgcarlisle.com/blog/2014/01/29/toward-a-bitcoin-authenticator-or-getting-rid-of-usernames-and-passwords-redux/}
}

MLA

Carlisle, Benjamin Gregory. "“Toward a bitcoin authenticator” or “getting rid of usernames and passwords, redux”" Web blog post. The Grey Literature. 29 Jan 2014. Web. 22 Nov 2017. <https://www.bgcarlisle.com/blog/2014/01/29/toward-a-bitcoin-authenticator-or-getting-rid-of-usernames-and-passwords-redux/>

APA

Carlisle, Benjamin Gregory. (2014, Jan 29). “Toward a bitcoin authenticator” or “getting rid of usernames and passwords, redux” [Web log post]. Retrieved from https://www.bgcarlisle.com/blog/2014/01/29/toward-a-bitcoin-authenticator-or-getting-rid-of-usernames-and-passwords-redux/


Search

A word from our sponsors

Tag bag

Recent comments

Old posts

All content © Benjamin Carlisle