Geek Credit policy.

This policy is the technical foundation of the Geek Credit system. The target audience for this document is developers of the software based on Geek Credit and users who require in-depth understanding of the system design. Please see the Geek Credit manual for more user oriented document.

Geek Credit community is a number of people who agreed to receive payment in Geek Credits for some services and goods within a community. New member may join a community as long as there is anybody who trust this member enough to accept the Geek Credit signed or issued by the newcomer.

Geek Credit is an ASCII text that contains the ID of the issuer, community number and other supplementary data. Anybody can issue a Geek Credit when there is someone who is willing to accept it as a payment. When Geek Credit enters circulation, it becomes a note that may be used as a payment within a community. When the Geek Credit is paid back to the issuer, the issuer redeems it.

Geek Credit is an ASCII text that has the fields described below, each starting from a new line.

  1. Header: "Geek Credit 0.3 " + Geek Credit ID + " " + Community ID
    1 or more of the blocks 2-5:
  2. Holder ID
  3. Next User ID
  4. Transaction time and date
  5. Digital signature (GnuPG) of the fields above made using the key corresponding to the holder ID

Geek Credit ID is the big (9 decimal signs) random dumber that is uniq for the issuer.

The community ID is 32 bit positive integer.
0 is test community
1 is global Geek Credit community.
Please send me your community numbers, I will add it to this page.

User ID and Holder ID are the GnuPG IDs used in GnuPG keys of the corresponding users.

Digital signature is made on the SHA1 hash of all contents of 1-4, including all previous signatures, if any.

Line feed is either Windows, or Linux or MacOS style, it MUST be converted to "\n" before signing and verifying signatures.

There is no "value" field in the Geek Credit. When payment involves multiple Geek Credits (almost always), each is processed separately.

The MAY, SHOULD and MUST below have the same meaning as in RFC2119

  1. User MUST read and accept policy #1, #2 before accepting and issuing Geek Credits. User MUST also read and accept policy #3-#7 or use the tool that complies with this policy.
  2. User MUST have the public key for the key used for signing Geek Credits available to everybody, i.e published at the key server.
  3. User MUST accept and redeem own Geek Credit as a part of the agreed payment, unless there is an evidence that the credit is counterfeited.
  4. User SHOULD pay using Geek Credits issued by as many different users as possible. User SHOULD pay with immediately redeemable Geek Credits first.
  5. User SHOULD keep the archive of issued and redempted Geek Credits to track possible counterfeit (Geek Credits with same ID but different paths).
  6. User who is accepting the Geek Credit SHOULD verify payer and issuer signatures. User SHOULD also check the archives for the Geek Credit being accepted. User MAY also verify other signatures in this Geek Credit.
  7. If signature verification has failed or if checking the archive revealed the counterfeit, user SHOULD refuse to accept the Geek Credit involved. In this case user MAY update ratings database and MAY ask payer to pay using the Geek Credit issued by another user, e.g payer. User MAY refuse to accept the Geek Credit issued by not trusted user.

Comments on the policy

The Geek Credit pocket software complies with this policy. Any one may write Geek Credit software, modify Geek Credit pocket or even process Geek Credits manually (this is not very difficult, GnuPG and regexps/text editor is sufficient)

The Geek Credit system is designed so that if someone fails to comply with this policy, he will either loose credits, or (if he attacks the system) others will receive an evidence digitally signed by the attacker.

This is pointless not to redeem the Geek Credit because passing it further will require signing it again and for the issuer it means the same as issuing another Geek Credit. If signer had signed the credit more than once, he failed to comply with this policy.

If one fails to properly check signatures, he will face a risk of receiving a bad credit that nobody will accept from him.

If user does not keep the archive and does not check the tickets being redempted there is a risk to provide more service than it was committed.

Changed at Mon Apr 19 23:59:11 MSD 2004

Back to Geek Credit page

Valid XHTML 1.0!