[G]ossipd design document

This is an up-to-date draft specification for gossipd. It is up-to-date in the sense that it completely incorporatesi discussion in the forum on the topic. It is a specification in the sense that on its basis one could distinguish an item which is gossipd from an item which isn't gossipd. It is a draft both in the sense that the design is still open to discussion in many (though not all) points and in the sense that this particular statement is made by me, and as of yet hasn't been approved or corrected by others.

The item herein discussed started life almost two years ago as "a better ircd" (and of course independently throughout the minds composing our esteemed Republic). Ample discussion hence has muchly refined the concept and clarified its details to the point that original statement is no longer relevant to the discussion.

Throughout this text, as well as throughout discussion to date, "gossipd" ambiguously denotes the protocol as well as the implementation thereof. This is not because we don't comprehend the difference, through some sort of contagion from the original Bitcoin brainrot ; nor because "gossip" would have to get its final p uppercased or something to distinguish it from the common noun ; but because the discussion is yet young and the distinction is as of yet without much difference.

I. Gossipd will have access to a read-onlyii databaseiii of identitiesiv known to it.

II. Gossipd will perpetually run a RSA-key generation process ; and store the produced keys.v. The keys will be arbitrarily marked as usable and bogus by unspecified criteria. Usable keys will be used whenever a new key is required by gossipd operation - such as when introduced to a new peer. Bogus keys will not be used.vi

III. Gossipd will receive inbound connectionsvii from identified clientsviii and on the basis of that identification produce an encrypted challenge string, which constitutes its response. If the other party responds with the proper challenge string, the connection is established ; otherwise it is dropped.ix

For a functional example consider node A, whose "encryption" mechanism consists of sha256(string+"hurr"), and node B, whose encryption mechanism consists of sha256("durr"+string.).

A trying to establish a connection with B will send B

d99b584025792454dff2a0657a33ec71a2ae1334f65524aa10480112046a2be6

To which B will reply with

e8c3fb96cf946d7eef95ec7d04a3c15f72fa77bf39e2e764b55cc8dfd9a08907

To which A will reply with

325152dfbd94bf7d9fcb7d8200a48b83dd0dd5c2e22bd035be9098a4136fdef3

Thereby establishing the connection.x

Unsolicited challenge strings will also be sent, at intervals and to destinations specified by the operator. In general it is expected a mix of friends' keys, own bogus keys and own usable keys will be used for this purpose in varying proportions - the exact scheme used should be exposed as configurable to the operator of the gossipd node.

IV. Gossipd will maintain a list of messages it has received, in the form of

time, X, Y, text

with the meaning that it has received the text at local time from Y who claims the original source is X.

It is intentionally not specified how gossipd should behave in order to

resolve timestamp conflicts (eg, if Y reports text1 from X after text2 from X whereas Z reports text1 from X before text2 from X) ;

resolve content conflicts (eg, if user is connected to both X and Y, and Y reports a message to originate from X that X itself does not report ; or conversely ; etc)

because this resolution falls upon the operator. A good gossipd implementation would supply well chosen knobs to simplify these and other tasks, but the specification thereof would be premature.

V. Gossipd will forward the complete list of messagesxi it knows to any new client connected to it. This behaviour is within the hands of the operator - he may choose to forward only part of the history, or an altered or altogether fictitious history. There should probably be a provision for clients connecting that have connected before, so as to only exchange data from the point of the last connection forward (this could be accomplished perhaps through a mutual check of the "last line heard", which would of course require clients to keep permanent track of what they sent to whom - not altogether a bad idea).

VI. GUI and UX considerations are not in the scope of this design document.

VII. Rationale and advantages have been discussed qs in other places, and in any case are not in the scope of this design document.

Please add your comments below, either directly in the box or else via trackback from your own blog. There's a significant advantage to concentrating discussion on this topic here, so we don't have to fish through two hundred thousand lines of log next this item has to be revisited.

———Completely incorporates here means that all points brought have been considered, and on their merits included or not, in the original form or as they best serve altered. [↩]The database is to be populated, and maintained, by the operator - not by the program. [↩]Implementing this in the form of a plaintext file stands out as the height of sense. See also the Bitcoin wallet discussion. [↩]At the very least in the now familiar e, N, comment format.

As Republican software matures, and especially once G is delivered, this part of the specification will have to be expanded to accomodate scryptography, which is to say cryptography that exists as scripts operating on a standardized bignum machine.

Let it be mentioned to dispell possible confusion, that no user <-> identity bijection is contemplated here. It is this author's expectation that the average user will have shared on the order of hundreds of different keys with each of his friends, with an unspecified portion thereof shared among those friends. This means that a Dunbar-average fellow will have generated on the order of 10`000 RSA keypairs to use gossipd normally, (which means gossipd can not function without a proper RNG source - something I believe was implicit but now becomes explicit. [↩]A speed about similar to that of the Bitcoin network (about one key created each 6 minutes, for a total of ~240 per day) is contemplated here. Obviously this will vary by implementation and locale ; the magic number provided is not included in the spec but intended as mere guidance. [↩]Implementation may allow opperator to move keys that were used in the past into the bogus group ; but not out of the bogus group. [↩]The method is not yet established. Obviously, TCP is widely available ; but also obviously it has serious problems. This part of the spec is by far the vaguest, for which reason all implementations are in principle acceptable - without prototyping possible solutions it seems improbable we'll come to any sort of bridge here (and moreover, the "scandalosity" resulted in no small part from trying to give this issue time). [↩]Gossipd is a p2p protocol, so the client is exactly itself. [↩]It is by this spec not illegal for a client to send challenge strings to another client which has not solicited them. What the receiving client should do in this case is not specified but left at the discretion of the implementer. [↩]If you're not into fighting trapdoor functions, A says sha256("durr" + "This is A.") to which B replies with sha256("Is this A?" + "hurr") to which A replies in turn with sha256("durr" + "Is this A?"). The fact that A could decrypt a message encrypted to A's key proves to B that A is indeed A. If B has no key associated with A's claimed identity, the session can not continue. [↩]To point out the obvious : messages may consist of new keys for itself ; or for a third party (either in plaintext or encrypted for the destination ; either signed or unsigned). [↩]

« Industria Argentina, or my life among the tribal savages.

A complete theory of politics »

Category: Bitcoin

Friday, 09 September, Year 8 d.Tr.