[Cryptography] IPFS spin locks !

[Henry Baker]

At 03:13 PM 5/10/2021, Jerry Leichter wrote:
>> The IPFS (Interplanetary File System) *addresses* blocks
>> that are 'stored' within it by producing a *hash* of the
>> (immutable) block itself as its 'address'.
>> 
>> Assuming that the hashing algorithm is publicly known,
>> anyone can now create a spin lock whose 'address' is the
>> hash of some not-yet-stored-in-IPFS random file, and this
>> random file is communicated to other processes who all
>> need to synchronize with one another....
>
>Heh.  This was (is?) a standard technique in the Linda programming model.  In Linda, communication occurs through tuple space, where tuple space is the holder of a multi-set of tuples of data of arbitrary types.  You can use out() to put a tuple into tuple space; in() to atomically pull a "matching" one out in an atomic operation; and rd() to atomically read the values in a "matching" tuple while leaving it alone.  in() and rd() have arguments that are tuples of values or wildcards; the values must match a tuple in tuple space while the wildcards get filled in and are available to the caller.  in() and rd() - in the basic definition of the model - are fully synchronous, waiting indefinitely for a tuple they can match to appear.  So a lock is just a pre-defined tuple that those wanting the lock can in().  Since the field types and values are arbitrary, this can be done securely by choosing an appropriate value - though security was not something really considered in the design of 
the model, which was intended for implementing cooperating components of a parallel/distributed program.
>
>One nice thing about the basic model is the symmetry of communication:  Programs can be written in which components doing out() have no idea who does in() or rd(), and vice-versa.  Further, the order in which these occur doesn't matter:  If in() occurs first, it simply waits for the corresponding out().  This avoids some common problems with locks that occur when you don't carefully ensure that the lock is actually there before someone tries to use it.
>
>There are extensions to the model that allow timeouts, which (in my opinion) greatly complicate the semantics and end up forcing you to design loops and fallbacks which often end up hurting more than they apparently help.

Supposing IPFS used SHA256 for 'addresses/hashes'; the following
address:

852dba5b321a0eb4800e4e2099faa2353e85ae4f3b181e4e7b4ee1dd161e0482

when finally read, yields "Climb Mount Niitaka\n".