From adc0dcb270b829bd73e9d8632856d52fa8790328 Mon Sep 17 00:00:00 2001
From: infogulch
Date: Fri, 9 Jul 2021 01:00:39 +0000
Subject: [PATCH] Add security section
---
2021-07-07-Merklist.ipynb | 24 +++++++++++++++++-------
1 file changed, 17 insertions(+), 7 deletions(-)
diff --git a/2021-07-07-Merklist.ipynb b/2021-07-07-Merklist.ipynb
index 4ee43ce..c12fcc9 100644
--- a/2021-07-07-Merklist.ipynb
+++ b/2021-07-07-Merklist.ipynb
@@ -6,7 +6,7 @@
"metadata": {},
"source": [
"# Merklist\n",
- "> A definition for the hash of a list that is robust to arbitrary partitioning\n",
+ "> An associative definition for the hash of an ordered sequence of elements\n",
"\n",
"- toc: true\n",
"- categories: [merklist]"
@@ -636,12 +636,22 @@
},
{
"cell_type": "markdown",
- "id": "6cc30cb3-8079-4f8a-9b7c-a3b4f7e384a3",
+ "id": "624d5cb8-01cb-4c6d-b80a-4b2079e4ad54",
"metadata": {},
"source": [
- "# Unknowns\n",
+ "## Security\n",
"\n",
- "This appears to me to be a reasonable way to define the hash of a list. The mathematical definition of a list aligns very nicely with the properties offered by matrix multiplication. But is it appropriate to use for the same things that a Merkle Tree would be? The big questions are related to the valuable properties of hash functions:\n",
+ "The security of the design of merklist leans on existing cryptographic hash function by the requiring that values that go into the final list digest came from some real hashed preimage, and any implementation can require that the primage of every element must be provided. This means that it's not possible to choose an *arbitrary* element hash as an input to the reduction operation, limiting the blast radius that any specific element can have on the final list digest to the bit fixing that is possible by asic bitcoin miners today. So then the question is if bit fixing is enough to degrade the preimage resistance of the merklist design, and if that is impossible to overcome. (Challenges anyone?)"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "id": "9515603f-f8b5-482a-ae1b-ed504358b860",
+ "metadata": {},
+ "source": [
+ "## Unknowns\n",
+ "\n",
+ "This appears to me to be a reasonable way to define the hash of a list. The mathematical description of a list aligns very nicely with the properties offered by matrix multiplication. But is it appropriate to use for the same things that a Merkle Tree would be? The big questions are related to the valuable properties of hash functions:\n",
"\n",
"* Given a merklist summary but not the elements, is it possible to produce a different list of elements that hash to the same summary? (~preimage resistance)\n",
"* Given a merklist summary or sublist summaries of it, can you derive the hashes of elements or their order?\n",
@@ -651,7 +661,7 @@
"* Is there a better choice of reduction function that still retains associativity+non-commutativity than simple matmul?\n",
"* Is there a more appropriate size than an 8x8 matrix / 64 bytes to represent merklist summaries?\n",
"\n",
- "Matrixes are well-studied objects, perhaps such information is already known. If *you* know something about deriving the preimage of the multiplication of a [matrix ring](https://en.wikipedia.org/wiki/Matrix_ring), $R_{256}^{8×8}$, I would be very interested to know."
+ "Matrixes are well-studied objects, perhaps some of these questions already have an answer. If *you* know something about deriving a preimage of a [matrix ring](https://en.wikipedia.org/wiki/Matrix_ring) $R_{256}^{8×8}$ using just multiplication, I would be very interested to know. Given the simplicity of the definition, I wouldn't be surprised if there was already a big wrench in the cogs here."
]
},
{
@@ -659,9 +669,9 @@
"id": "4c4d4a83-8e2e-46d7-b2e3-2d59ba9c9e8c",
"metadata": {},
"source": [
- "# What's next?\n",
+ "## What's next?\n",
"\n",
- "***If** this construction has the appropriate security properties*, it seems to be a better merkle tree in all respects. Any use of a merkle tree could be replaced with this, and it could enable use-cases where merkle trees aren't useful. Some examples of what I think might be possible:\n",
+ "*If this construction has appropriate security properties*, it seems to be a better merkle tree in all respects. Any use of a merkle tree could be replaced with this, and it could enable use-cases where merkle trees aren't useful. Some examples of what I think might be possible:\n",
"\n",
"* Using a Merklist with a sublist summary tree structure enables creating a $O(1)$-sized 'Merklist Proof' that can verify the addition and subtraction of any number of elements at any single point in the list using only $O(log(N))$ time and $O(log(N))$ static space. As a bonus the proof generator and verifier can have totally different tree structures and can still communicate the proof successfully.\n",
"* Using a Merklist summary tree you can create a consistent hash of any ordered key-value store (like a btree) that can be maintained incrementally inline with regular node updates, e.g. as part of a [LSM-tree](https://en.wikipedia.org/wiki/Log-structured_merge-tree). This could facilitate verification and sync between database replicas.\n",