[geofft]

The term "blockchain" is ill-defined (and often is used to mean just "Merkle tree"), but in the sense of the 2008 Nakamoto paper, a blockchain derives its security from having more computational power participate in the security of the system than the unused and available computational power in the world, and specifically from having financial incentives (mining) to make this be the case. In other words, the data structure is specifically about money and corruption, by design.

[andrenth]

Why corruption?

[skybrian]

Money attracts thieves. Especially combined with irreversible transactions and at least partial anonymity.

[andrenth]

But isn’t this an argument both against (any) currency and privacy?

[geofft]

Basically yes - if your application needs neither currency nor privacy (e.g., signing Go packages), linking it to a data structure that inherently deals with both would be a mistake. Currency and privacy are both difficult, so avoid bringing in dependencies on them if you don't need them.

(Again, the Bitcoin paper is specific in how the data structure is only secure because the consensus algorithm creates financial incentives that hopefully outweigh the incentive to misbehave. If you drop that from a blockchain, it isn't secure any more.)

[skybrian]

It's an argument for being cautious about handling money and avoiding it if you can. Of course, Internet commerce deals with it a lot, but sometimes it's an unnecessary dependency and removing it simplifies the problem.