Fossil SCM
Edit pass on the blockchain doc: mainly clarity improvements, but also some typo and grammar fixes.
Commit
c34ca6299f09515db286d791997464bca9be5ae090064631a63029c725895d4b
Parent
701c6dc284c2c4f…
1 file changed
+35
-34
+35
-34
| --- www/blockchain.md | ||
| +++ www/blockchain.md | ||
| @@ -11,25 +11,24 @@ | ||
| 11 | 11 | |
| 12 | 12 | The [Wikipedia definition of "blockchain"][bcwp] begins: |
| 13 | 13 | |
| 14 | 14 | > |
| 15 | 15 | "A blockchain…is a growing list of records, called blocks, which are linked using |
| 16 | - cryptography. Each block contains a cryptographic hash of the previous | |
| 16 | + cryptography… Each block contains a cryptographic hash of the previous | |
| 17 | 17 | block, a timestamp, and transaction data (generally represented as a Merkle tree)." |
| 18 | 18 | |
| 19 | - | |
| 20 | -By that partial definition, Fossil is indeed a blockchain. The blocks | |
| 19 | +Point-for-point, Fossil follows this partial definition. | |
| 20 | +The blocks | |
| 21 | 21 | are Fossil’s ["manifest" artifacts](./fileformat.wiki#manifest). Each |
| 22 | 22 | manifest has a cryptographically-strong [SHA-1] or [SHA-3] hash linking it to |
| 23 | 23 | one or more “parent” blocks. The manifest also contains a timestamp and |
| 24 | -the transactional data needed to express a commit to the repository. If | |
| 25 | -you traverse the Fossil repository from the tips of its [DAG] to the | |
| 26 | -root by following the parent hashes in each manifest, you will then have | |
| 27 | -a Merkle tree. Point-for-point, Fossil follows that definition. | |
| 28 | - | |
| 24 | +the transactional data needed to express a commit to the repository. | |
| 25 | +To traverse the Fossil repository from the tips of its [DAG] to the | |
| 26 | +root by following the parent hashes in each manifest is to traverse | |
| 27 | +a Merkle tree. | |
| 29 | 28 | Every change in Fossil starts by adding one or more manifests to |
| 30 | -the repository, extending this tree. | |
| 29 | +the repository, extending this Merkle tree. | |
| 31 | 30 | |
| 32 | 31 | [bcwp]: https://en.wikipedia.org/wiki/Blockchain |
| 33 | 32 | [DAG]: https://en.wikipedia.org/wiki/Directed_acyclic_graph |
| 34 | 33 | [SHA-1]: https://en.wikipedia.org/wiki/SHA-1 |
| 35 | 34 | [SHA-3]: https://en.wikipedia.org/wiki/SHA-3 |
| @@ -61,11 +60,12 @@ | ||
| 61 | 60 | * **Type 2** is creation of new fraudulent currency that will pass |
| 62 | 61 | in commerce. To extend our analogy, it is the creation of new |
| 63 | 62 | US $10 bills. There are two sub-types to this fraud. In terms of |
| 64 | 63 | our analogy, they are: |
| 65 | 64 | |
| 66 | - * **Type 2a**: copying of an existing legitimate $10 bill | |
| 65 | + * **Type 2a**: copying an existing legitimate $10 bill<p> | |
| 66 | + | |
| 67 | 67 | * **Type 2b**: printing a new $10 bill that is unlike an existing |
| 68 | 68 | legitimate one, yet which will still pass in commerce |
| 69 | 69 | |
| 70 | 70 | * **Type 3** is double-spending existing legitimate cryptocurrency. |
| 71 | 71 | There is no analogy in paper money due to its physical form; it is a |
| @@ -92,11 +92,11 @@ | ||
| 92 | 92 | cryptocurrencies add a separate chain of hashes to make checking |
| 93 | 93 | for double-spending quick and easy. |
| 94 | 94 | |
| 95 | 95 | Fossil has [a disabled-by-default feature][cs] to call out to an |
| 96 | 96 | external copy of [PGP] or [GPG] to sign commit manifests before |
| 97 | - inserting them into the repository. You may wish to couple that with | |
| 97 | + inserting them into the repository. You can couple that with | |
| 98 | 98 | a server-side [after-receive hook][arh] to reject unsigned commits. |
| 99 | 99 | |
| 100 | 100 | Although there are several distinctions you can draw between the way |
| 101 | 101 | Fossil’s commit signing scheme works and the way block signing works |
| 102 | 102 | in cryptocurrencies, only one is of material interest for our |
| @@ -112,11 +112,11 @@ | ||
| 112 | 112 | prevention, both Type 1 and Type 2. You cannot modify existing |
| 113 | 113 | commits (Type 1 forgery) because you do not have the original |
| 114 | 114 | committer’s private signing key, and you cannot forge new commits |
| 115 | 115 | attesting to come from some other trusted committer (Type 2) because |
| 116 | 116 | you don’t have any of their private signing keys, either. |
| 117 | - Cyrptocurrencies also use the work problem to prevent Type 2 | |
| 117 | + Cryptocurrencies use the work problem to prevent Type 2 | |
| 118 | 118 | forgeries, but the application of that to Fossil is a matter we get |
| 119 | 119 | to [later](#work). |
| 120 | 120 | |
| 121 | 121 | Although you have complete control over the contents of your local |
| 122 | 122 | Fossil repository clone, you cannot perform Type 1 forgery on its |
| @@ -124,24 +124,26 @@ | ||
| 124 | 124 | algorithm. ([SHA3-256][SHA-3] by default in the current version of |
| 125 | 125 | Fossil.) Even if you could, Fossil’s sync protocol will prevent the |
| 126 | 126 | modification from being pushed into another repository: the remote |
| 127 | 127 | Fossil instance says, “I’ve already got that one, thanks,” and |
| 128 | 128 | ignores the push. Thus, short of breaking into the remote server |
| 129 | - and modifying the repository in place, you couldn’t even make use of | |
| 130 | - a preimage attack if you had that power. This is an attack on the | |
| 129 | + and modifying the repository in place, you couldn’t make use of | |
| 130 | + a preimage attack even if you had that power. Further, that would be an attack on the | |
| 131 | 131 | server itself, not on Fossil’s data structures, so while it is |
| 132 | - useful to think through this problem, it is not helpful to answering | |
| 132 | + useful to think through this problem, it is not helpful in answering | |
| 133 | 133 | our questions here. |
| 134 | 134 | |
| 135 | - The Fossil sync protocol also prevents the closest analog to Type 3 | |
| 135 | + The Fossil sync protocol’s duplication detection also prevents the closest analog to Type 3 | |
| 136 | 136 | frauds in Fossil: copying a commit manifest in your local repo clone |
| 137 | 137 | won’t result in a double-commit on sync. |
| 138 | 138 | |
| 139 | 139 | In the absence of digital signatures, Fossil’s [RBAC system][caps] |
| 140 | 140 | restricts Type 2 forgery to trusted committers. Thus once again |
| 141 | 141 | we’re reduced to an infosec problem, not a data structure design |
| 142 | - question. (Inversely, enabling commit clearsigning is a good idea | |
| 142 | + question. | |
| 143 | + | |
| 144 | + (Inversely, enabling commit clearsigning is a good idea | |
| 143 | 145 | if you have committers on your repo whom you don’t trust not to |
| 144 | 146 | commit Type 2 frauds. But let us be clear: your choice of setting |
| 145 | 147 | does not answer the question of whether Fossil is a blockchain.) |
| 146 | 148 | |
| 147 | 149 | If Fossil signatures prevent Type 1 and Type 2 frauds, you |
| @@ -245,19 +247,22 @@ | ||
| 245 | 247 | to change the value of existing commits (Type 1) or add new commits to |
| 246 | 248 | the repository (Type 2). |
| 247 | 249 | |
| 248 | 250 | What if we removed those features from Fossil, creating an append-only |
| 249 | 251 | Fossil variant? Is it a DLT then? Arguably still not, because [today’s Fossil |
| 250 | -is an AP-mode system][ctap] in the [CAP theorem][cap] sense, which means | |
| 252 | +is an AP-mode system][ctap], which means | |
| 251 | 253 | there can be no guaranteed consensus on the content of the ledger at any |
| 252 | -given time. If you had an AP-mode accounts receivable system, it could | |
| 253 | -have different bottom-line totals at different sites, because you’ve | |
| 254 | -cast away “C” to get AP-mode operation. | |
| 254 | +given time. An AP-mode accounts receivable system would allow | |
| 255 | +different bottom-line totals at different sites, because you’ve | |
| 256 | +cast away “C” to get AP-mode operation. (See the prior link or | |
| 257 | +[Wikipedia’s article on the CAP theorem][cap] if you aren’t following | |
| 258 | +this terminology.) | |
| 255 | 259 | |
| 256 | -Because of this, you could still not guarantee that the command | |
| 257 | -“`fossil info tip`” gives the same result everywhere. A CA or CP-mode Fossil | |
| 258 | -variant would guarantee that everyone got the same result. (Everyone not | |
| 260 | +By the same token, you cannot guarantee that the command | |
| 261 | +“`fossil info tip`” gives the same result everywhere. You would need to | |
| 262 | +recast Fossil as a CA or CP-mode system to solve that. | |
| 263 | +(Everyone not | |
| 259 | 264 | partitioned away from the majority of the network at any rate, in the CP |
| 260 | 265 | case.) |
| 261 | 266 | |
| 262 | 267 | What are the prospects for CA-mode or CP-mode Fossil? [We don’t want |
| 263 | 268 | CA-mode Fossil][ctca], but [CP-mode could be useful][ctcp]. Until the latter |
| @@ -366,13 +371,13 @@ | ||
| 366 | 371 | commits into your repository under any name they want. |
| 367 | 372 | |
| 368 | 373 | On the server side, you can also [scrub] the logging that remembers |
| 369 | 374 | where each commit came from. |
| 370 | 375 | |
| 371 | -That info isn’t transmitted from the remote server on clone or pull. | |
| 372 | -Instead, the size of the `rcvfrom` table after initial clone is 1: it | |
| 373 | -contains the remote server’s IP address. On each pull containing new | |
| 376 | +Commit source info isn’t transmitted from the remote server on clone or pull: | |
| 377 | +the size of the `rcvfrom` table after initial clone is 1, containing | |
| 378 | +only the remote server’s IP address. On each pull containing new | |
| 374 | 379 | artifacts, your local `fossil` instance adds another entry to this |
| 375 | 380 | table, likely with the same IP address unless the server has moved or |
| 376 | 381 | you’re using [multiple remotes][mrep]. This table is far more |
| 377 | 382 | interesting on the server side, containing the IP addresses of all |
| 378 | 383 | contentful pushes; thus [the `scrub` command][scrub]. |
| @@ -452,18 +457,14 @@ | ||
| 452 | 457 | |
| 453 | 458 | # Conclusion |
| 454 | 459 | |
| 455 | 460 | This author believes it is technologically indefensible to call Fossil a |
| 456 | 461 | “blockchain” in any sense likely to be understood by a majority of those |
| 457 | -you’re communicating with. | |
| 458 | - | |
| 459 | -Within a certain narrow scope, you can defend this usage, but if you do | |
| 460 | -that, you’ve failed any goal that requires clear communication: it | |
| 461 | -doesn’t work to use a term in a nonstandard way just because you can | |
| 462 | -defend it. The people you’re communicating your ideas to must have the | |
| 462 | +you’re communicating with. Using a term in a nonstandard way just because you can | |
| 463 | +defend it means you’ve failed any goal that requires clear communication. | |
| 464 | +The people you’re communicating your ideas to must have the | |
| 463 | 465 | same concept of the terms you use. |
| 464 | - | |
| 465 | 466 | |
| 466 | 467 | What term should you use instead? Fossil stores a DAG of hash-chained |
| 467 | 468 | commits, so an indisputably correct term is a [Merkle tree][mt], named |
| 468 | 469 | after [its inventor][drrm]. You could also use the more generic term |
| 469 | 470 | “hash tree.” |
| 470 | 471 |
| --- www/blockchain.md | |
| +++ www/blockchain.md | |
| @@ -11,25 +11,24 @@ | |
| 11 | |
| 12 | The [Wikipedia definition of "blockchain"][bcwp] begins: |
| 13 | |
| 14 | > |
| 15 | "A blockchain…is a growing list of records, called blocks, which are linked using |
| 16 | cryptography. Each block contains a cryptographic hash of the previous |
| 17 | block, a timestamp, and transaction data (generally represented as a Merkle tree)." |
| 18 | |
| 19 | |
| 20 | By that partial definition, Fossil is indeed a blockchain. The blocks |
| 21 | are Fossil’s ["manifest" artifacts](./fileformat.wiki#manifest). Each |
| 22 | manifest has a cryptographically-strong [SHA-1] or [SHA-3] hash linking it to |
| 23 | one or more “parent” blocks. The manifest also contains a timestamp and |
| 24 | the transactional data needed to express a commit to the repository. If |
| 25 | you traverse the Fossil repository from the tips of its [DAG] to the |
| 26 | root by following the parent hashes in each manifest, you will then have |
| 27 | a Merkle tree. Point-for-point, Fossil follows that definition. |
| 28 | |
| 29 | Every change in Fossil starts by adding one or more manifests to |
| 30 | the repository, extending this tree. |
| 31 | |
| 32 | [bcwp]: https://en.wikipedia.org/wiki/Blockchain |
| 33 | [DAG]: https://en.wikipedia.org/wiki/Directed_acyclic_graph |
| 34 | [SHA-1]: https://en.wikipedia.org/wiki/SHA-1 |
| 35 | [SHA-3]: https://en.wikipedia.org/wiki/SHA-3 |
| @@ -61,11 +60,12 @@ | |
| 61 | * **Type 2** is creation of new fraudulent currency that will pass |
| 62 | in commerce. To extend our analogy, it is the creation of new |
| 63 | US $10 bills. There are two sub-types to this fraud. In terms of |
| 64 | our analogy, they are: |
| 65 | |
| 66 | * **Type 2a**: copying of an existing legitimate $10 bill |
| 67 | * **Type 2b**: printing a new $10 bill that is unlike an existing |
| 68 | legitimate one, yet which will still pass in commerce |
| 69 | |
| 70 | * **Type 3** is double-spending existing legitimate cryptocurrency. |
| 71 | There is no analogy in paper money due to its physical form; it is a |
| @@ -92,11 +92,11 @@ | |
| 92 | cryptocurrencies add a separate chain of hashes to make checking |
| 93 | for double-spending quick and easy. |
| 94 | |
| 95 | Fossil has [a disabled-by-default feature][cs] to call out to an |
| 96 | external copy of [PGP] or [GPG] to sign commit manifests before |
| 97 | inserting them into the repository. You may wish to couple that with |
| 98 | a server-side [after-receive hook][arh] to reject unsigned commits. |
| 99 | |
| 100 | Although there are several distinctions you can draw between the way |
| 101 | Fossil’s commit signing scheme works and the way block signing works |
| 102 | in cryptocurrencies, only one is of material interest for our |
| @@ -112,11 +112,11 @@ | |
| 112 | prevention, both Type 1 and Type 2. You cannot modify existing |
| 113 | commits (Type 1 forgery) because you do not have the original |
| 114 | committer’s private signing key, and you cannot forge new commits |
| 115 | attesting to come from some other trusted committer (Type 2) because |
| 116 | you don’t have any of their private signing keys, either. |
| 117 | Cyrptocurrencies also use the work problem to prevent Type 2 |
| 118 | forgeries, but the application of that to Fossil is a matter we get |
| 119 | to [later](#work). |
| 120 | |
| 121 | Although you have complete control over the contents of your local |
| 122 | Fossil repository clone, you cannot perform Type 1 forgery on its |
| @@ -124,24 +124,26 @@ | |
| 124 | algorithm. ([SHA3-256][SHA-3] by default in the current version of |
| 125 | Fossil.) Even if you could, Fossil’s sync protocol will prevent the |
| 126 | modification from being pushed into another repository: the remote |
| 127 | Fossil instance says, “I’ve already got that one, thanks,” and |
| 128 | ignores the push. Thus, short of breaking into the remote server |
| 129 | and modifying the repository in place, you couldn’t even make use of |
| 130 | a preimage attack if you had that power. This is an attack on the |
| 131 | server itself, not on Fossil’s data structures, so while it is |
| 132 | useful to think through this problem, it is not helpful to answering |
| 133 | our questions here. |
| 134 | |
| 135 | The Fossil sync protocol also prevents the closest analog to Type 3 |
| 136 | frauds in Fossil: copying a commit manifest in your local repo clone |
| 137 | won’t result in a double-commit on sync. |
| 138 | |
| 139 | In the absence of digital signatures, Fossil’s [RBAC system][caps] |
| 140 | restricts Type 2 forgery to trusted committers. Thus once again |
| 141 | we’re reduced to an infosec problem, not a data structure design |
| 142 | question. (Inversely, enabling commit clearsigning is a good idea |
| 143 | if you have committers on your repo whom you don’t trust not to |
| 144 | commit Type 2 frauds. But let us be clear: your choice of setting |
| 145 | does not answer the question of whether Fossil is a blockchain.) |
| 146 | |
| 147 | If Fossil signatures prevent Type 1 and Type 2 frauds, you |
| @@ -245,19 +247,22 @@ | |
| 245 | to change the value of existing commits (Type 1) or add new commits to |
| 246 | the repository (Type 2). |
| 247 | |
| 248 | What if we removed those features from Fossil, creating an append-only |
| 249 | Fossil variant? Is it a DLT then? Arguably still not, because [today’s Fossil |
| 250 | is an AP-mode system][ctap] in the [CAP theorem][cap] sense, which means |
| 251 | there can be no guaranteed consensus on the content of the ledger at any |
| 252 | given time. If you had an AP-mode accounts receivable system, it could |
| 253 | have different bottom-line totals at different sites, because you’ve |
| 254 | cast away “C” to get AP-mode operation. |
| 255 | |
| 256 | Because of this, you could still not guarantee that the command |
| 257 | “`fossil info tip`” gives the same result everywhere. A CA or CP-mode Fossil |
| 258 | variant would guarantee that everyone got the same result. (Everyone not |
| 259 | partitioned away from the majority of the network at any rate, in the CP |
| 260 | case.) |
| 261 | |
| 262 | What are the prospects for CA-mode or CP-mode Fossil? [We don’t want |
| 263 | CA-mode Fossil][ctca], but [CP-mode could be useful][ctcp]. Until the latter |
| @@ -366,13 +371,13 @@ | |
| 366 | commits into your repository under any name they want. |
| 367 | |
| 368 | On the server side, you can also [scrub] the logging that remembers |
| 369 | where each commit came from. |
| 370 | |
| 371 | That info isn’t transmitted from the remote server on clone or pull. |
| 372 | Instead, the size of the `rcvfrom` table after initial clone is 1: it |
| 373 | contains the remote server’s IP address. On each pull containing new |
| 374 | artifacts, your local `fossil` instance adds another entry to this |
| 375 | table, likely with the same IP address unless the server has moved or |
| 376 | you’re using [multiple remotes][mrep]. This table is far more |
| 377 | interesting on the server side, containing the IP addresses of all |
| 378 | contentful pushes; thus [the `scrub` command][scrub]. |
| @@ -452,18 +457,14 @@ | |
| 452 | |
| 453 | # Conclusion |
| 454 | |
| 455 | This author believes it is technologically indefensible to call Fossil a |
| 456 | “blockchain” in any sense likely to be understood by a majority of those |
| 457 | you’re communicating with. |
| 458 | |
| 459 | Within a certain narrow scope, you can defend this usage, but if you do |
| 460 | that, you’ve failed any goal that requires clear communication: it |
| 461 | doesn’t work to use a term in a nonstandard way just because you can |
| 462 | defend it. The people you’re communicating your ideas to must have the |
| 463 | same concept of the terms you use. |
| 464 | |
| 465 | |
| 466 | What term should you use instead? Fossil stores a DAG of hash-chained |
| 467 | commits, so an indisputably correct term is a [Merkle tree][mt], named |
| 468 | after [its inventor][drrm]. You could also use the more generic term |
| 469 | “hash tree.” |
| 470 |
| --- www/blockchain.md | |
| +++ www/blockchain.md | |
| @@ -11,25 +11,24 @@ | |
| 11 | |
| 12 | The [Wikipedia definition of "blockchain"][bcwp] begins: |
| 13 | |
| 14 | > |
| 15 | "A blockchain…is a growing list of records, called blocks, which are linked using |
| 16 | cryptography… Each block contains a cryptographic hash of the previous |
| 17 | block, a timestamp, and transaction data (generally represented as a Merkle tree)." |
| 18 | |
| 19 | Point-for-point, Fossil follows this partial definition. |
| 20 | The blocks |
| 21 | are Fossil’s ["manifest" artifacts](./fileformat.wiki#manifest). Each |
| 22 | manifest has a cryptographically-strong [SHA-1] or [SHA-3] hash linking it to |
| 23 | one or more “parent” blocks. The manifest also contains a timestamp and |
| 24 | the transactional data needed to express a commit to the repository. |
| 25 | To traverse the Fossil repository from the tips of its [DAG] to the |
| 26 | root by following the parent hashes in each manifest is to traverse |
| 27 | a Merkle tree. |
| 28 | Every change in Fossil starts by adding one or more manifests to |
| 29 | the repository, extending this Merkle tree. |
| 30 | |
| 31 | [bcwp]: https://en.wikipedia.org/wiki/Blockchain |
| 32 | [DAG]: https://en.wikipedia.org/wiki/Directed_acyclic_graph |
| 33 | [SHA-1]: https://en.wikipedia.org/wiki/SHA-1 |
| 34 | [SHA-3]: https://en.wikipedia.org/wiki/SHA-3 |
| @@ -61,11 +60,12 @@ | |
| 60 | * **Type 2** is creation of new fraudulent currency that will pass |
| 61 | in commerce. To extend our analogy, it is the creation of new |
| 62 | US $10 bills. There are two sub-types to this fraud. In terms of |
| 63 | our analogy, they are: |
| 64 | |
| 65 | * **Type 2a**: copying an existing legitimate $10 bill<p> |
| 66 | |
| 67 | * **Type 2b**: printing a new $10 bill that is unlike an existing |
| 68 | legitimate one, yet which will still pass in commerce |
| 69 | |
| 70 | * **Type 3** is double-spending existing legitimate cryptocurrency. |
| 71 | There is no analogy in paper money due to its physical form; it is a |
| @@ -92,11 +92,11 @@ | |
| 92 | cryptocurrencies add a separate chain of hashes to make checking |
| 93 | for double-spending quick and easy. |
| 94 | |
| 95 | Fossil has [a disabled-by-default feature][cs] to call out to an |
| 96 | external copy of [PGP] or [GPG] to sign commit manifests before |
| 97 | inserting them into the repository. You can couple that with |
| 98 | a server-side [after-receive hook][arh] to reject unsigned commits. |
| 99 | |
| 100 | Although there are several distinctions you can draw between the way |
| 101 | Fossil’s commit signing scheme works and the way block signing works |
| 102 | in cryptocurrencies, only one is of material interest for our |
| @@ -112,11 +112,11 @@ | |
| 112 | prevention, both Type 1 and Type 2. You cannot modify existing |
| 113 | commits (Type 1 forgery) because you do not have the original |
| 114 | committer’s private signing key, and you cannot forge new commits |
| 115 | attesting to come from some other trusted committer (Type 2) because |
| 116 | you don’t have any of their private signing keys, either. |
| 117 | Cryptocurrencies use the work problem to prevent Type 2 |
| 118 | forgeries, but the application of that to Fossil is a matter we get |
| 119 | to [later](#work). |
| 120 | |
| 121 | Although you have complete control over the contents of your local |
| 122 | Fossil repository clone, you cannot perform Type 1 forgery on its |
| @@ -124,24 +124,26 @@ | |
| 124 | algorithm. ([SHA3-256][SHA-3] by default in the current version of |
| 125 | Fossil.) Even if you could, Fossil’s sync protocol will prevent the |
| 126 | modification from being pushed into another repository: the remote |
| 127 | Fossil instance says, “I’ve already got that one, thanks,” and |
| 128 | ignores the push. Thus, short of breaking into the remote server |
| 129 | and modifying the repository in place, you couldn’t make use of |
| 130 | a preimage attack even if you had that power. Further, that would be an attack on the |
| 131 | server itself, not on Fossil’s data structures, so while it is |
| 132 | useful to think through this problem, it is not helpful in answering |
| 133 | our questions here. |
| 134 | |
| 135 | The Fossil sync protocol’s duplication detection also prevents the closest analog to Type 3 |
| 136 | frauds in Fossil: copying a commit manifest in your local repo clone |
| 137 | won’t result in a double-commit on sync. |
| 138 | |
| 139 | In the absence of digital signatures, Fossil’s [RBAC system][caps] |
| 140 | restricts Type 2 forgery to trusted committers. Thus once again |
| 141 | we’re reduced to an infosec problem, not a data structure design |
| 142 | question. |
| 143 | |
| 144 | (Inversely, enabling commit clearsigning is a good idea |
| 145 | if you have committers on your repo whom you don’t trust not to |
| 146 | commit Type 2 frauds. But let us be clear: your choice of setting |
| 147 | does not answer the question of whether Fossil is a blockchain.) |
| 148 | |
| 149 | If Fossil signatures prevent Type 1 and Type 2 frauds, you |
| @@ -245,19 +247,22 @@ | |
| 247 | to change the value of existing commits (Type 1) or add new commits to |
| 248 | the repository (Type 2). |
| 249 | |
| 250 | What if we removed those features from Fossil, creating an append-only |
| 251 | Fossil variant? Is it a DLT then? Arguably still not, because [today’s Fossil |
| 252 | is an AP-mode system][ctap], which means |
| 253 | there can be no guaranteed consensus on the content of the ledger at any |
| 254 | given time. An AP-mode accounts receivable system would allow |
| 255 | different bottom-line totals at different sites, because you’ve |
| 256 | cast away “C” to get AP-mode operation. (See the prior link or |
| 257 | [Wikipedia’s article on the CAP theorem][cap] if you aren’t following |
| 258 | this terminology.) |
| 259 | |
| 260 | By the same token, you cannot guarantee that the command |
| 261 | “`fossil info tip`” gives the same result everywhere. You would need to |
| 262 | recast Fossil as a CA or CP-mode system to solve that. |
| 263 | (Everyone not |
| 264 | partitioned away from the majority of the network at any rate, in the CP |
| 265 | case.) |
| 266 | |
| 267 | What are the prospects for CA-mode or CP-mode Fossil? [We don’t want |
| 268 | CA-mode Fossil][ctca], but [CP-mode could be useful][ctcp]. Until the latter |
| @@ -366,13 +371,13 @@ | |
| 371 | commits into your repository under any name they want. |
| 372 | |
| 373 | On the server side, you can also [scrub] the logging that remembers |
| 374 | where each commit came from. |
| 375 | |
| 376 | Commit source info isn’t transmitted from the remote server on clone or pull: |
| 377 | the size of the `rcvfrom` table after initial clone is 1, containing |
| 378 | only the remote server’s IP address. On each pull containing new |
| 379 | artifacts, your local `fossil` instance adds another entry to this |
| 380 | table, likely with the same IP address unless the server has moved or |
| 381 | you’re using [multiple remotes][mrep]. This table is far more |
| 382 | interesting on the server side, containing the IP addresses of all |
| 383 | contentful pushes; thus [the `scrub` command][scrub]. |
| @@ -452,18 +457,14 @@ | |
| 457 | |
| 458 | # Conclusion |
| 459 | |
| 460 | This author believes it is technologically indefensible to call Fossil a |
| 461 | “blockchain” in any sense likely to be understood by a majority of those |
| 462 | you’re communicating with. Using a term in a nonstandard way just because you can |
| 463 | defend it means you’ve failed any goal that requires clear communication. |
| 464 | The people you’re communicating your ideas to must have the |
| 465 | same concept of the terms you use. |
| 466 | |
| 467 | What term should you use instead? Fossil stores a DAG of hash-chained |
| 468 | commits, so an indisputably correct term is a [Merkle tree][mt], named |
| 469 | after [its inventor][drrm]. You could also use the more generic term |
| 470 | “hash tree.” |
| 471 |