Fossil SCM

fossil-scm / www / blockchain.md
Source Blame History 478 lines
1ddb400… wyoung 1 # Is Fossil A Blockchain?
1ddb400… wyoung 2
1ddb400… wyoung 3 The Fossil version control system shares a lot of similarities with
1ddb400… wyoung 4 other blockchain based technologies, but it also differs from the more common
1ddb400… wyoung 5 sorts of blockchains. This document will discuss the term’s
1ddb400… wyoung 6 applicability, so you can decide whether applying the term to Fossil
1ddb400… wyoung 7 makes sense to you.
1ddb400… wyoung 8
1ddb400… wyoung 9
1ddb400… wyoung 10 ## The Dictionary Argument
1ddb400… wyoung 11
1ddb400… wyoung 12 The [Wikipedia definition of "blockchain"][bcwp] begins:
1ddb400… wyoung 13
1ddb400… wyoung 14 >
1ddb400… wyoung 15 "A blockchain…is a growing list of records, called blocks, which are linked using
c34ca62… wyoung 16 cryptography… Each block contains a cryptographic hash of the previous
1ddb400… wyoung 17 block, a timestamp, and transaction data (generally represented as a Merkle tree)."
1ddb400… wyoung 18
c34ca62… wyoung 19 Point-for-point, Fossil follows this partial definition.
c34ca62… wyoung 20 The blocks
1ddb400… wyoung 21 are Fossil’s ["manifest" artifacts](./fileformat.wiki#manifest). Each
1ddb400… wyoung 22 manifest has a cryptographically-strong [SHA-1] or [SHA-3] hash linking it to
1ddb400… wyoung 23 one or more “parent” blocks. The manifest also contains a timestamp and
c34ca62… wyoung 24 the transactional data needed to express a commit to the repository.
c34ca62… wyoung 25 To traverse the Fossil repository from the tips of its [DAG] to the
c34ca62… wyoung 26 root by following the parent hashes in each manifest is to traverse
c34ca62… wyoung 27 a Merkle tree.
1ddb400… wyoung 28 Every change in Fossil starts by adding one or more manifests to
c34ca62… wyoung 29 the repository, extending this Merkle tree.
1ddb400… wyoung 30
1ddb400… wyoung 31 [bcwp]: https://en.wikipedia.org/wiki/Blockchain
1ddb400… wyoung 32 [DAG]: https://en.wikipedia.org/wiki/Directed_acyclic_graph
1ddb400… wyoung 33 [SHA-1]: https://en.wikipedia.org/wiki/SHA-1
1ddb400… wyoung 34 [SHA-3]: https://en.wikipedia.org/wiki/SHA-3
1ddb400… wyoung 35
1ddb400… wyoung 36
1ddb400… wyoung 37
1ddb400… wyoung 38 <a id="currency"></a>
1ddb400… wyoung 39 ## Cryptocurrency
1ddb400… wyoung 40
1ddb400… wyoung 41 Because blockchain technology was first popularized as Bitcoin, many
1ddb400… wyoung 42 people associate the term with cryptocurrency. Fossil has nothing to do
1ddb400… wyoung 43 with cryptocurrency, so a claim that “Fossil is a blockchain” may fail
1ddb400… wyoung 44 to communicate the speaker’s concepts clearly due to conflation with
1ddb400… wyoung 45 cryptocurrency.
1ddb400… wyoung 46
1ddb400… wyoung 47 Cryptocurrency has several features and requirements that Fossil doesn’t
1ddb400… wyoung 48 provide, either because it doesn’t need them or because we haven’t
1ddb400… wyoung 49 gotten around to creating the feature. Whether these are essential to
1ddb400… wyoung 50 the definition of “blockchain” and thus disqualify Fossil as a blockchain
1ddb400… wyoung 51 is for you to decide.
1ddb400… wyoung 52
1ddb400… wyoung 53 Cryptocurrencies must prevent three separate types of fraud to be useful:
1ddb400… wyoung 54
1ddb400… wyoung 55 * **Type 1** is modification of existing currency. To draw an analogy
1ddb400… wyoung 56 to paper money, we wish to prevent someone from using green and
1ddb400… wyoung 57 black markers to draw extra zeroes on a US $10 bill so that it
26005b8… wyoung 58 claims to be a $100 bill.
70523a7… wyoung 59
70523a7… wyoung 60 * **Type 2** is creation of new fraudulent currency that will pass
70523a7… wyoung 61 in commerce. To extend our analogy, it is the creation of new
70523a7… wyoung 62 US $10 bills. There are two sub-types to this fraud. In terms of
70523a7… wyoung 63 our analogy, they are:
70523a7… wyoung 64
1fd407f… wyoung 65 * **Type 2a**: copying an existing legitimate $10 bill<br><br>
c34ca62… wyoung 66
70523a7… wyoung 67 * **Type 2b**: printing a new $10 bill that is unlike an existing
70523a7… wyoung 68 legitimate one, yet which will still pass in commerce
1ddb400… wyoung 69
1ddb400… wyoung 70 * **Type 3** is double-spending existing legitimate cryptocurrency.
1ddb400… wyoung 71 There is no analogy in paper money due to its physical form; it is a
1ddb400… wyoung 72 problem unique to digital currency due to its infinitely-copyable
26005b8… wyoung 73 nature.
1ddb400… wyoung 74
1ddb400… wyoung 75 How does all of this compare to Fossil?
1ddb400… wyoung 76
1ddb400… wyoung 77 1. <a id="signatures"></a>**Signatures.** Cryptocurrencies use a chain
1ddb400… wyoung 78 of [digital signatures][dsig] to prevent Type 1 and Type 3 frauds. This
1ddb400… wyoung 79 chain forms an additional link between the blocks, separate from the
1ddb400… wyoung 80 hash chain that applies an ordering and lookup scheme to the blocks.
1ddb400… wyoung 81 [_Blockchain: Simple Explanation_][bse] explains this “hash chain”
1ddb400… wyoung 82 vs. “block chain” distinction in more detail.
1ddb400… wyoung 83
26005b8… wyoung 84 These signatures prevent modification of the face value of each
e755561… danield 85 transaction (Type 1 fraud) by ensuring that only the one signing a
26005b8… wyoung 86 new block has the private signing key that could change an issued
26005b8… wyoung 87 block after the fact.
26005b8… wyoung 88
26005b8… wyoung 89 The fact that these signatures are also *chained* prevents Type
26005b8… wyoung 90 3 frauds by making the *prior* owner of a block sign it over to
26005b8… wyoung 91 the new owner. To avoid an O(n²) auditing problem as a result,
26005b8… wyoung 92 cryptocurrencies add a separate chain of hashes to make checking
26005b8… wyoung 93 for double-spending quick and easy.
26005b8… wyoung 94
1ddb400… wyoung 95 Fossil has [a disabled-by-default feature][cs] to call out to an
1ddb400… wyoung 96 external copy of [PGP] or [GPG] to sign commit manifests before
c34ca62… wyoung 97 inserting them into the repository. You can couple that with
1ddb400… wyoung 98 a server-side [after-receive hook][arh] to reject unsigned commits.
1ddb400… wyoung 99
1ddb400… wyoung 100 Although there are several distinctions you can draw between the way
1ddb400… wyoung 101 Fossil’s commit signing scheme works and the way block signing works
1ddb400… wyoung 102 in cryptocurrencies, only one is of material interest for our
1ddb400… wyoung 103 purposes here: Fossil commit signatures apply only to a single
1ddb400… wyoung 104 commit. Fossil does not sign one commit over to the next “owner” of
1ddb400… wyoung 105 that commit in the way that a blockchain-based cryptocurrency must
1ddb400… wyoung 106 when transferring currency from one user to another, beacuse there
1ddb400… wyoung 107 is no useful analog to the double-spending problem in Fossil. The
1ddb400… wyoung 108 closest you can come to this is double-insert of commits into the
1ddb400… wyoung 109 blockchain, which we’ll address shortly.
1ddb400… wyoung 110
1ddb400… wyoung 111 What Fossil commit signatures actually do is provide in-tree forgery
1ddb400… wyoung 112 prevention, both Type 1 and Type 2. You cannot modify existing
1ddb400… wyoung 113 commits (Type 1 forgery) because you do not have the original
1ddb400… wyoung 114 committer’s private signing key, and you cannot forge new commits
1ddb400… wyoung 115 attesting to come from some other trusted committer (Type 2) because
1ddb400… wyoung 116 you don’t have any of their private signing keys, either.
c34ca62… wyoung 117 Cryptocurrencies use the work problem to prevent Type 2
1ddb400… wyoung 118 forgeries, but the application of that to Fossil is a matter we get
1ddb400… wyoung 119 to [later](#work).
1ddb400… wyoung 120
1ddb400… wyoung 121 Although you have complete control over the contents of your local
1ddb400… wyoung 122 Fossil repository clone, you cannot perform Type 1 forgery on its
1ddb400… wyoung 123 contents short of executing a [preimage attack][prei] on the hash
e755561… danield 124 algorithm. ([SHA3-256][SHA-3] by default in the current version of
1ddb400… wyoung 125 Fossil.) Even if you could, Fossil’s sync protocol will prevent the
1ddb400… wyoung 126 modification from being pushed into another repository: the remote
1ddb400… wyoung 127 Fossil instance says, “I’ve already got that one, thanks,” and
1ddb400… wyoung 128 ignores the push. Thus, short of breaking into the remote server
c34ca62… wyoung 129 and modifying the repository in place, you couldn’t make use of
c34ca62… wyoung 130 a preimage attack even if you had that power. Further, that would be an attack on the
1ddb400… wyoung 131 server itself, not on Fossil’s data structures, so while it is
c34ca62… wyoung 132 useful to think through this problem, it is not helpful in answering
1ddb400… wyoung 133 our questions here.
1ddb400… wyoung 134
c34ca62… wyoung 135 The Fossil sync protocol’s duplication detection also prevents the closest analog to Type 3
1ddb400… wyoung 136 frauds in Fossil: copying a commit manifest in your local repo clone
1ddb400… wyoung 137 won’t result in a double-commit on sync.
1ddb400… wyoung 138
1ddb400… wyoung 139 In the absence of digital signatures, Fossil’s [RBAC system][caps]
1ddb400… wyoung 140 restricts Type 2 forgery to trusted committers. Thus once again
1ddb400… wyoung 141 we’re reduced to an infosec problem, not a data structure design
c34ca62… wyoung 142 question.
c34ca62… wyoung 143
c34ca62… wyoung 144 (Inversely, enabling commit clearsigning is a good idea
1ddb400… wyoung 145 if you have committers on your repo whom you don’t trust not to
1ddb400… wyoung 146 commit Type 2 frauds. But let us be clear: your choice of setting
1ddb400… wyoung 147 does not answer the question of whether Fossil is a blockchain.)
1ddb400… wyoung 148
70523a7… wyoung 149 If Fossil signatures prevent Type 1 and Type 2 frauds, you
70523a7… wyoung 150 may wonder why they are not enabled by default. It is because
70523a7… wyoung 151 they are defense-in-depth measures, not the minimum sufficient
70523a7… wyoung 152 measures needed to prevent repository fraud, unlike the equivalent
e755561… danield 153 protections in a cryptocurrency blockchain. Fossil provides its
70523a7… wyoung 154 primary protections through other means, so it doesn’t need to
70523a7… wyoung 155 mandate signatures.
70523a7… wyoung 156
70523a7… wyoung 157 Also, Fossil is not itself a [PKI], and there is no way for regular
70523a7… wyoung 158 users of Fossil to link it to a PKI, since doing so would likely
70523a7… wyoung 159 result in an unwanted [PII] disclosure. There is no email address
70523a7… wyoung 160 in a Fossil commit manifest that you could use to query one of the
70523a7… wyoung 161 public PGP keyservers, for example. It therefore becomes a local
70523a7… wyoung 162 policy matter as to whether you even *want* to have signatures,
70523a7… wyoung 163 because they’re not without their downsides.
70523a7… wyoung 164
70523a7… wyoung 165 2. <a id="work"></a>**Work Contests.** Cryptocurrencies prevent Type 2b forgeries
1ddb400… wyoung 166 by setting up some sort of contest that ensures that new coins can come
1ddb400… wyoung 167 into existence only by doing some difficult work task. This “mining”
1ddb400… wyoung 168 activity results in a coin that took considerable work to create,
1ddb400… wyoung 169 which thus has economic value by being a) difficult to re-create,
1ddb400… wyoung 170 and b) resistant to [debasement][dboc].
1ddb400… wyoung 171
1ddb400… wyoung 172 Fossil repositories are most often used to store the work product of
1ddb400… wyoung 173 individuals, rather than cryptocoin mining machines. There is
1ddb400… wyoung 174 generally no contest in trying to produce the most commits. There
1ddb400… wyoung 175 may be an implicit contest to produce the “best” commits, but that
1ddb400… wyoung 176 is a matter of project management, not something that can be
1ddb400… wyoung 177 automatically mediated through objective measures.
1ddb400… wyoung 178
1ddb400… wyoung 179 Incentives to commit to the repository come from outside of Fossil;
1ddb400… wyoung 180 they are not inherent to its nature, as with cryptocurrencies.
1ddb400… wyoung 181 Moreover, there is no useful sense in which we could say that one
1ddb400… wyoung 182 commit “re-creates” another. Commits are generally products of
1ddb400… wyoung 183 individual human intellect, thus necessarily unique in all but
1ddb400… wyoung 184 trivial cases. This is foundational to copyright law.
1ddb400… wyoung 185
1ddb400… wyoung 186 3. <a id="lcr"></a>**Longest Chain Rule.** Cryptocurrencies generally
1ddb400… wyoung 187 need some way to distinguish which blocks are legitimate and which
1ddb400… wyoung 188 not. They do this in part by identifying the linear chain with the
1ddb400… wyoung 189 greatest cumulative [work time](#work) as the legitimate chain. All
1ddb400… wyoung 190 blocks not on that linear chain are considered “orphans” and are
1ddb400… wyoung 191 ignored by the cryptocurrency software.
1ddb400… wyoung 192
70523a7… wyoung 193 Its inverse is sometimes called the “51% attack” because a single
1ddb400… wyoung 194 actor would have to do slightly more work than the entire rest of
1ddb400… wyoung 195 the community using a given cryptocurrency in order for their fork
1ddb400… wyoung 196 of the currency to be considered the legitimate fork. This argument
1ddb400… wyoung 197 soothes concerns that a single bad actor could take over the
1ddb400… wyoung 198 network.
1ddb400… wyoung 199
1ddb400… wyoung 200 The closest we can come to that notion in Fossil is the default
1ddb400… wyoung 201 “trunk” branch, but there’s nothing in Fossil that delegitimizes
1ddb400… wyoung 202 other branches just because they’re shorter, nor is there any way in
1ddb400… wyoung 203 Fossil to score the amount of work that went into a commit. Indeed,
1ddb400… wyoung 204 [forks and branches][fb] are *valuable and desirable* things in
1ddb400… wyoung 205 Fossil.
1ddb400… wyoung 206
1ddb400… wyoung 207 This much is certain: Fossil is definitely not a cryptocurrency. Whether
1ddb400… wyoung 208 this makes it “not a blockchain” is a subjective matter.
1ddb400… wyoung 209
1ddb400… wyoung 210 [arh]: ./hooks.md
1ddb400… wyoung 211 [bse]: https://www.researchgate.net/publication/311572122_What_is_Blockchain_a_Gentle_Introduction
1ddb400… wyoung 212 [caps]: ./caps/
c64f28d… drh 213 [cs]: /help/clearsign
1ddb400… wyoung 214 [dboc]: https://en.wikipedia.org/wiki/Debasement
1ddb400… wyoung 215 [dsig]: https://en.wikipedia.org/wiki/Digital_signature
1ddb400… wyoung 216 [fb]: ./branching.wiki
1ddb400… wyoung 217 [GPG]: https://gnupg.org/
1ddb400… wyoung 218 [PGP]: https://www.openpgp.org/
1ddb400… wyoung 219 [PII]: https://en.wikipedia.org/wiki/Personal_data
1ddb400… wyoung 220 [PKI]: https://en.wikipedia.org/wiki/Public_key_infrastructure
1ddb400… wyoung 221 [pow]: https://en.wikipedia.org/wiki/Proof_of_work
1ddb400… wyoung 222 [prei]: https://en.wikipedia.org/wiki/Preimage_attack
1ddb400… wyoung 223
1ddb400… wyoung 224
1ddb400… wyoung 225
1ddb400… wyoung 226 <a id="dlt"></a>
1ddb400… wyoung 227 ## Distributed Ledgers
1ddb400… wyoung 228
1ddb400… wyoung 229 Cryptocurrencies are an instance of [distributed ledger technology][dlt]. If
1ddb400… wyoung 230 we can convince ourselves that Fossil is also a distributed
1ddb400… wyoung 231 ledger, then we might think of Fossil as a peer technology,
1ddb400… wyoung 232 having at least some qualifications toward being considered a blockchain.
1ddb400… wyoung 233
1ddb400… wyoung 234 A key tenet of DLT is that records be unmodifiable after they’re
1ddb400… wyoung 235 committed to the ledger, which matches quite well with Fossil’s design
1ddb400… wyoung 236 and everyday use cases. Fossil puts up multiple barriers to prevent
1ddb400… wyoung 237 modification of existing records and injection of incorrect records.
1ddb400… wyoung 238
1ddb400… wyoung 239 Yet, Fossil also has [purge] and [shunning][shun]. Doesn’t that mean
1ddb400… wyoung 240 Fossil cannot be a distributed ledger?
1ddb400… wyoung 241
1ddb400… wyoung 242 These features only remove existing commits from the repository. If you want a
1ddb400… wyoung 243 currency analogy, they are ways to burn a paper bill or to melt a [fiat
1ddb400… wyoung 244 coin][fc] down to slag. In a cryptocurrency, you can erase your “wallet”
1ddb400… wyoung 245 file, effectively destroying money in a similar way. These features
1ddb400… wyoung 246 do not permit forgery of either type described above: you can’t use them
1ddb400… wyoung 247 to change the value of existing commits (Type 1) or add new commits to
1ddb400… wyoung 248 the repository (Type 2).
1ddb400… wyoung 249
1ddb400… wyoung 250 What if we removed those features from Fossil, creating an append-only
1ddb400… wyoung 251 Fossil variant? Is it a DLT then? Arguably still not, because [today’s Fossil
c34ca62… wyoung 252 is an AP-mode system][ctap], which means
1ddb400… wyoung 253 there can be no guaranteed consensus on the content of the ledger at any
c34ca62… wyoung 254 given time. An AP-mode accounts receivable system would allow
c34ca62… wyoung 255 different bottom-line totals at different sites, because you’ve
c34ca62… wyoung 256 cast away “C” to get AP-mode operation. (See the prior link or
c34ca62… wyoung 257 [Wikipedia’s article on the CAP theorem][cap] if you aren’t following
c34ca62… wyoung 258 this terminology.)
1ddb400… wyoung 259
c34ca62… wyoung 260 By the same token, you cannot guarantee that the command
c34ca62… wyoung 261 “`fossil info tip`” gives the same result everywhere. You would need to
c34ca62… wyoung 262 recast Fossil as a CA or CP-mode system to solve that.
c34ca62… wyoung 263 (Everyone not
1ddb400… wyoung 264 partitioned away from the majority of the network at any rate, in the CP
1ddb400… wyoung 265 case.)
1ddb400… wyoung 266
1ddb400… wyoung 267 What are the prospects for CA-mode or CP-mode Fossil? [We don’t want
1ddb400… wyoung 268 CA-mode Fossil][ctca], but [CP-mode could be useful][ctcp]. Until the latter
1ddb400… wyoung 269 exists, this author believes Fossil is not a distributed ledger in a
1ddb400… wyoung 270 technologically defensible sense.
1ddb400… wyoung 271
1ddb400… wyoung 272 The most common technologies answering to the label “blockchain” are all
1ddb400… wyoung 273 DLTs, so if Fossil is not a DLT, then it is not a blockchain in that
1ddb400… wyoung 274 sense.
1ddb400… wyoung 275
1ddb400… wyoung 276 [ctap]: ./cap-theorem.md#ap
1ddb400… wyoung 277 [ctca]: ./cap-theorem.md#ca
1ddb400… wyoung 278 [ctcp]: ./cap-theorem.md#cp
1ddb400… wyoung 279 [cap]: https://en.wikipedia.org/wiki/CAP_theorem
1ddb400… wyoung 280 [dlt]: https://en.wikipedia.org/wiki/Distributed_ledger
1ddb400… wyoung 281 [DVCS]: https://en.wikipedia.org/wiki/Distributed_version_control
1ddb400… wyoung 282 [fc]: https://en.wikipedia.org/wiki/Fiat_money
c64f28d… drh 283 [purge]: /help/purge
1ddb400… wyoung 284 [shun]: ./shunning.wiki
1ddb400… wyoung 285
1ddb400… wyoung 286
1ddb400… wyoung 287 <a id="dpc"></a>
1ddb400… wyoung 288 ## Distributed Partial Consensus
1ddb400… wyoung 289
1ddb400… wyoung 290 If we can’t get DLT, can we at least get some kind of distributed
1ddb400… wyoung 291 consensus at the level of individual Fossil’s commits?
1ddb400… wyoung 292
1ddb400… wyoung 293 Many blockchain based technologies have this property: given some
1ddb400… wyoung 294 element of the blockchain, you can make certain proofs that it either is
1ddb400… wyoung 295 a legitimate part of the whole blockchain, or it is not.
1ddb400… wyoung 296
1ddb400… wyoung 297 Unfortunately, this author doesn’t see a way to do that with Fossil.
1ddb400… wyoung 298 Given only one “block” in Fossil’s putative “blockchain” — a commit, in
1ddb400… wyoung 299 Fossil terminology — all you can prove is whether it is internally
1ddb400… wyoung 300 consistent, that it is not corrupt. That then points you at the parent(s) of that
1ddb400… wyoung 301 commit, which you can repeat the exercise on, back to the root of the
1ddb400… wyoung 302 DAG. This is what the enabled-by-default [`repo-cksum` setting][rcks]
1ddb400… wyoung 303 does.
1ddb400… wyoung 304
1ddb400… wyoung 305 If cryptocurrencies worked this way, you wouldn’t be able to prove that
1ddb400… wyoung 306 a given cryptocoin was legitimate without repeating the proof-of-work
1ddb400… wyoung 307 calculations for the entire cryptocurrency scheme! Instead, you only
1ddb400… wyoung 308 need to check a certain number of signatures and proofs-of-work in order
1ddb400… wyoung 309 to be reasonably certain that you are looking at a legitimate section of
1ddb400… wyoung 310 the whole blockchain.
1ddb400… wyoung 311
1ddb400… wyoung 312 What would it even mean to prove that a given Fossil commit “*belongs*”
1ddb400… wyoung 313 to the repository you’ve extracted it from? For a software project,
1ddb400… wyoung 314 isn’t that tantamount to automatic code review, where the server would
1ddb400… wyoung 315 be able to reliably accept or reject a commit based solely on its
1ddb400… wyoung 316 content? That sounds nice, but this author believes we’ll need to invent
1ddb400… wyoung 317 [AGI] first.
1ddb400… wyoung 318
1ddb400… wyoung 319 A better method to provide distributed consensus for Fossil would be to
1ddb400… wyoung 320 rely on the *natural* intelligence of its users: that is, distributed
1ddb400… wyoung 321 commit signing, so that a commit is accepted into the blockchain only
1ddb400… wyoung 322 once some number of users countersign it. This amounts to a code review
1ddb400… wyoung 323 feature, which Fossil doesn’t currently have.
1ddb400… wyoung 324
1ddb400… wyoung 325 Solving that problem basically requires solving the [PKI] problem first,
1ddb400… wyoung 326 since you can’t verify the proofs of these signatures if you can’t first
1ddb400… wyoung 327 prove that the provided signatures belong to people you trust. This is a
1ddb400… wyoung 328 notoriously hard problem in its own right.
1ddb400… wyoung 329
1ddb400… wyoung 330 A future version of Fossil could instead provide [consensus in the CAP
1ddb400… wyoung 331 sense][ctcp]. For instance, you could say that if a quorum of servers
1ddb400… wyoung 332 all have a given commit, it “belongs.” Fossil’s strong hashing tech
1ddb400… wyoung 333 would mean that querying whether a given commit is part of the
1ddb400… wyoung 334 “blockchain” would be as simple as going down the list of servers and
1ddb400… wyoung 335 sending each an HTTP GET `/info` query for the artifact ID, concluding
1ddb400… wyoung 336 that the commit is legitimate once you get enough HTTP 200 status codes back. All of this is
1ddb400… wyoung 337 hypothetical, because Fossil doesn’t do this today.
1ddb400… wyoung 338
1ddb400… wyoung 339 [AGI]: https://en.wikipedia.org/wiki/Artificial_general_intelligence
c64f28d… drh 340 [rcks]: /help/repo-cksum
1ddb400… wyoung 341
1ddb400… wyoung 342
1ddb400… wyoung 343
1ddb400… wyoung 344 <a id="anon"></a>
1ddb400… wyoung 345 ## Anonymity
1ddb400… wyoung 346
1ddb400… wyoung 347 Many blockchain based technologies go to extraordinary lengths to
1ddb400… wyoung 348 allow anonymous use of their service.
1ddb400… wyoung 349
1ddb400… wyoung 350 As typically configured, Fossil does not: commits synced between servers
1ddb400… wyoung 351 always at least have a user name associated with them, which the remote
1ddb400… wyoung 352 system must accept through its [RBAC system][caps]. That system can run
1ddb400… wyoung 353 without having the user’s email address, but it’s needed if [email
1ddb400… wyoung 354 alerts][alert] are enabled on the server. The remote server logs the IP
1ddb400… wyoung 355 address of the commit for security reasons. That coupled with the
1ddb400… wyoung 356 timestamp on the commit could sufficiently deanonymize users in many
1ddb400… wyoung 357 common situations.
1ddb400… wyoung 358
1ddb400… wyoung 359 It is possible to configure Fossil so it doesn’t do this:
1ddb400… wyoung 360
1ddb400… wyoung 361 * You can give [Write capability][capi] to user category “nobody,” so
1ddb400… wyoung 362 that anyone that can reach your server can push commits into its
1ddb400… wyoung 363 repository.
1ddb400… wyoung 364
1ddb400… wyoung 365 * You could give that capability to user category “anonymous” instead,
1ddb400… wyoung 366 which requires that the user log in with a CAPTCHA, but which doesn’t
1ddb400… wyoung 367 require that the user otherwise identify themselves.
1ddb400… wyoung 368
1ddb400… wyoung 369 * You could enable [the `self-register` setting][sreg] and choose not to
1ddb400… wyoung 370 enable [commit clear-signing][cs] so that anonymous users could push
1ddb400… wyoung 371 commits into your repository under any name they want.
1ddb400… wyoung 372
1ddb400… wyoung 373 On the server side, you can also [scrub] the logging that remembers
1ddb400… wyoung 374 where each commit came from.
1ddb400… wyoung 375
c34ca62… wyoung 376 Commit source info isn’t transmitted from the remote server on clone or pull:
c34ca62… wyoung 377 the size of the `rcvfrom` table after initial clone is 1, containing
c34ca62… wyoung 378 only the remote server’s IP address. On each pull containing new
1ddb400… wyoung 379 artifacts, your local `fossil` instance adds another entry to this
1ddb400… wyoung 380 table, likely with the same IP address unless the server has moved or
1ddb400… wyoung 381 you’re using [multiple remotes][mrep]. This table is far more
1ddb400… wyoung 382 interesting on the server side, containing the IP addresses of all
1ddb400… wyoung 383 contentful pushes; thus [the `scrub` command][scrub].
1ddb400… wyoung 384
1ddb400… wyoung 385 Because Fossil doesn’t
1ddb400… wyoung 386 remember IP addresses in commit manifests or require commit signing, it
1ddb400… wyoung 387 allows at least *pseudonymous* commits. When someone clones a remote
1ddb400… wyoung 388 repository, they don’t learn the email address, IP address, or any other
1ddb400… wyoung 389 sort of [PII] of prior committers, on purpose.
1ddb400… wyoung 390
1ddb400… wyoung 391 Some people say that private, permissioned blockchains (as you may
1ddb400… wyoung 392 imagine Fossil to be) are inherently problematic by the very reason that
1ddb400… wyoung 393 they don’t bake anonymous contribution into their core. The very
1ddb400… wyoung 394 existence of an RBAC is a moving piece that can break. Isn’t it better,
1ddb400… wyoung 395 the argument goes, to have a system that works even in the face of
1ddb400… wyoung 396 anonymous contribution, so that you don’t need an RBAC? Cryptocurrencies
1ddb400… wyoung 397 do this, for example: anyone can “mine” a new coin and push it into the
1ddb400… wyoung 398 blockchain, and there is no central authority restricting the transfer
1ddb400… wyoung 399 of cryptocurrency from one user to another.
1ddb400… wyoung 400
1ddb400… wyoung 401 We can draw an analogy to encryption, where an algorithm is
1ddb400… wyoung 402 considered inherently insecure if it depends on keeping any information
1ddb400… wyoung 403 from an attacker other than the key. Encryption schemes that do
1ddb400… wyoung 404 otherwise are derided as “security through obscurity.”
1ddb400… wyoung 405
1ddb400… wyoung 406 You may be wondering what any of this has to do with whether Fossil is a
1ddb400… wyoung 407 blockchain, but that is exactly the point: all of this is outside
1ddb400… wyoung 408 Fossil’s core hash-chained repository data structure. If you take the
1ddb400… wyoung 409 position that you don’t have a “blockchain” unless it allows anonymous
1ddb400… wyoung 410 contribution, with any needed restrictions provided only by the very
1ddb400… wyoung 411 structure of the managed data, then Fossil does not qualify.
1ddb400… wyoung 412
1ddb400… wyoung 413 Why do some people care about this distinction? Consider Bitcoin,
1ddb400… wyoung 414 wherein an anonymous user cannot spam the blockchain with bogus coins
1ddb400… wyoung 415 because its [proof-of-work][pow] protocol allows such coins to be
1ddb400… wyoung 416 rejected immediately. There is no equivalent in Fossil: it has no
1ddb400… wyoung 417 technology that allows the receiving server to look at the content of a
1ddb400… wyoung 418 commit and automatically judge it to be “good.” Fossil relies on its
1ddb400… wyoung 419 RBAC system to provide such distinctions: if you have a commit bit, your
1ddb400… wyoung 420 commits are *ipso facto* judged “good,” insofar as any human work
1ddb400… wyoung 421 product can be so judged by a blob of compiled C code. This takes us
1ddb400… wyoung 422 back to the [digital ledger question](#dlt), where we can talk about
1ddb400… wyoung 423 what it means to later correct a bad commit that got through the RBAC
1ddb400… wyoung 424 check.
1ddb400… wyoung 425
1ddb400… wyoung 426 We may be willing to accept pseudonymity, rather than full anonymity.
1ddb400… wyoung 427 If we configure Fossil as above, either bypassing the RBAC or abandoning
1ddb400… wyoung 428 human control over it, scrubbing IP addresses, etc., is it then a public
1ddb400… wyoung 429 permissionless blockchain in that sense?
1ddb400… wyoung 430
1ddb400… wyoung 431 We think not, because there is no [longest chain rule](#lcr) or anything
1ddb400… wyoung 432 like it in Fossil.
1ddb400… wyoung 433
1ddb400… wyoung 434 For a fair model of how a Fossil repository might behave under such
1ddb400… wyoung 435 conditions, consider GitHub: here one user can fork another’s repository
1ddb400… wyoung 436 and make an arbitrary number of commits to their public fork. Imagine
1ddb400… wyoung 437 this happens 10 times. How does someone come along later and
1ddb400… wyoung 438 *automatically* evaluate which of the 11 forks of the code (counting the
1ddb400… wyoung 439 original repository among their number) is the “best” one? For a
1ddb400… wyoung 440 computer software project, the best we could do to approximate this
1ddb400… wyoung 441 devolves to a [software project cost estimation problem][scost]. These
1ddb400… wyoung 442 methods are rather questionable in their own right, being mathematical
1ddb400… wyoung 443 judgement values on human work products, but even if we accept their
1ddb400… wyoung 444 usefulness, then we still cannot say which fork is better based solely
1ddb400… wyoung 445 on their scores under these metrics. We may well prefer to use the fork
1ddb400… wyoung 446 of a software program that took *less* effort, being smaller, more
1ddb400… wyoung 447 self-contained, and with a smaller attack surface.
1ddb400… wyoung 448
1ddb400… wyoung 449
1ddb400… wyoung 450 [alert]: ./alerts.md
1ddb400… wyoung 451 [capi]: ./caps/ref.html#i
c64f28d… drh 452 [mrep]: /help/remote
1ddb400… wyoung 453 [scost]: https://en.wikipedia.org/wiki/Software_development_effort_estimation
c64f28d… drh 454 [scrub]: /help/scrub
c64f28d… drh 455 [sreg]: /help/self-register
1ddb400… wyoung 456
1ddb400… wyoung 457
1ddb400… wyoung 458 # Conclusion
1ddb400… wyoung 459
1ddb400… wyoung 460 This author believes it is technologically indefensible to call Fossil a
1ddb400… wyoung 461 “blockchain” in any sense likely to be understood by a majority of those
c34ca62… wyoung 462 you’re communicating with. Using a term in a nonstandard way just because you can
c34ca62… wyoung 463 defend it means you’ve failed any goal that requires clear communication.
c34ca62… wyoung 464 The people you’re communicating your ideas to must have the
1ddb400… wyoung 465 same concept of the terms you use.
1ddb400… wyoung 466
1ddb400… wyoung 467 What term should you use instead? Fossil stores a DAG of hash-chained
1ddb400… wyoung 468 commits, so an indisputably correct term is a [Merkle tree][mt], named
1ddb400… wyoung 469 after [its inventor][drrm]. You could also use the more generic term
1ddb400… wyoung 470 “hash tree.”
1ddb400… wyoung 471
1ddb400… wyoung 472 Fossil is a technological peer to many common sorts of blockchain
1ddb400… wyoung 473 technology. There is a lot of overlap in concepts and implementation
1ddb400… wyoung 474 details, but when speaking of what most people understand as
1ddb400… wyoung 475 “blockchain,” Fossil is not that.
1ddb400… wyoung 476
1ddb400… wyoung 477 [drrm]: https://en.wikipedia.org/wiki/Ralph_Merkle
1ddb400… wyoung 478 [mt]: https://en.wikipedia.org/wiki/Merkle_tree

Keyboard Shortcuts

Open search /
Next entry (timeline) j
Previous entry (timeline) k
Open focused entry Enter
Show this help ?
Toggle theme Top nav button