I am happy to confirm that Qeditas is now an IOHK project. The first post of this thread has been edited to reflect this. The code base can now be found on github: https://github.com/input-output-hk/qeditas. If you wish to collaborate on the Qeditas project, there is a contact page on the corresponding IOHK page: https://iohk.io/projects/qeditas/.

The current state of Qeditas is as follows:

A testnet version (not yet released) is able to connect with peers (on a local network for the moment) and share the most important information, e.g., block headers, block deltas, and so on. Each attempt to run it has resulted in a fork within roughly the first 200 blocks, so there are definitely bugs. The debugging process is tedious and it is difficult to estimate how long it will take. Perhaps I will simply stop giving updates on this thread until there is a version that seems to run locally without forking. If and when that time should come, my plan is to release another alpha version (0.0.2) so that interested people can try the testnet. During this initial trial phase the testnet will probably be reset on a weekly basis.

It is definitely better to find these kinds of issues earlier rather than later. Thank you for having a close look and finding the issue. Qeditas can definitely benefit from having more pairs of eyes looking into it.

Oh, now I think I see what you mean, and you are correct. You are describing a "stake grinding" attack. I opened Qeditas up to this attack when I reduced the maturation age of locked non-rewards to 8 blocks. To avoid this attack, no asset should be able to stake until at least 512 blocks after its creation.

This will make passing through the bootstrapping phase (the first 512 blocks) difficult since there will need to be at least 512 distinct assets from the initial distribution attempting to stake. I only have approximately 10 such assets myself. Realistically, if there aren't sufficient participants for 512 assets to stake, then I suppose the mainnet should be delayed until there are. If there never are sufficient participants, then perhaps Qeditas will simply remain as a Proof of Concept implementation others can learn from.

None of this will prevent starting a testnet. On the testnet, I have decided to permit "fake endorsements" using a private key I hold. In this way, I can reallocate arbitrary coins on the testnet. My plan is to use this to give away (testnet) coins corresponding to the early Bitcoin block rewards. (To be clear: this is only for the testnet. Satoshi's complete portion of the Qeditas distribution on the mainnet will be available for Satoshi to claim.) In this way, it will be easy to ensure that there are over 512 assets staking when the testnet starts. I am still hopeful that a Qeditas testnet can be started sometime reasonably soon, though not hopeful enough to give an estimate. Finding out about this grinding attack makes me even more reluctant to give estimated dates.

Currency units can be "locked" until a given block height for two reasons. First, block rewards should be unspendable for a certain amount of time, since a reorganization of the block chain might delete the reward. Second, locking assets allows people to trustlessly loan coins to be staked (since the "lock" in the obligation may have a different spending address than the address holding/staking the asset).

I considered only allowing locked assets to stake, but this presents a bootstrapping problem. At the beginning the ledger only has unlocked assets. This is why unlocked assets can stake. An alternative would be to only allow unlocked assets to stake if they are from the initial distribution.

The reason why locked rewards age slowly is that I noticed in simulations that block rewards can otherwise begin to quickly dominate the staking process.

Locked non-rewards are the main assets I expect to be staking. The short maturation time (8 blocks) and the fact that they immediately stake with their full coin-age reflects this intention. In effect, I expect the first few blocks to be staked by unlocked assets from the initial distribution and for these blocks to contain txs creating locked assets which should begin doing most of the staking at that point.

You are correct that the stake modifier is known for the next 256 blocks (and partially known for the 256 after that). I do not see an issue with locked assets. Even if the locked assets stake more often than other assets (as intended), the fact that they (and the resulting rewards) are locked for a significant number of future blocks should prevent attacks.

Thank you for your interest. Your "TrueCoin" idea does seem similar in spirit. One difference is that you describe TrueCoin as relying on the "useful Proof of Work" of proving mathematical theorems while Qeditas is planned to be (primarily) Proof of Stake. However, in Qeditas someone can increase their stake by proving theorems with bounties or by proving theorems others find useful (by collecting royalties). Perhaps this process can be seen as a simulation of a "useful Proof of Work."

The Qeditas White Paper provides an overview only. If you are interested in the details of the underlying logic (simple type theory), you can find those details in Chapter 7 of the Technical Documentation. The logic is the framework and users will need to publish a "theory" (primitives and axioms) to act as a mathematical foundation. (By default, the empty theory can be used, but this will have limited expressive power.)

The details of Proof of Stake are not fully described yet. Chapter 12 of the Technical Documentation should contain this information at some point, but even the single paragraph that currently comprises Chapter 12 is out-of-date and misleading. The best information can be found in the first half of Chapter 10. Also, Section 1.1 of Chapter 9 describes how coin-age is computed.

Here is a link to the Technical Documentation:

http://qeditas.org/qeditastechdoc.pdf

I hope this answers your questions. Honestly, it was not completely clear to me what you were asking, so please feel free to ask again if I have misinterpreted.

The work on the Qeditas code is progressing, though slowly again. I hope to give a more detailed update soon. Given the Ethereum hard fork today, I decided to make a statement regarding conditions under which Qeditas should (and more importantly should not) hard fork.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Today, July 20, 2016, the Ethereum community hard-forked in order to reverse the outcome of an ill-fated, buggy Ethereum program ("the DAO"). I play no role in the Ethereum community, but thought it would be an important opportunity to state, in advance, my position if something similar were to occur with Qeditas in the future.

It is quite likely that "buggy" propositions (and even "buggy" theories) will be published in the Qeditas block chain. For example, someone may formulate a conjecture they believe to be a formal version of The Riemann Hypothesis (or some other Millennium Problem). Under this belief, many people may contribute large bounties to encourage the resolution of the conjecture. Such bounties will encourage others to look more carefully at the conjecture, and someone may discover a flaw in the formulation. This flaw may mean that it is not a version of The Riemann Hypothesis, but instead is some other easily resolved conjecture. The person who discovers this can resolve the conjecture and claim the bounties.

This is, to be clear, part of the intended operation of the system. It is common for people to make mistakes when formalizing mathematics (just as programming mistakes are common). The only way these mistakes are found is by having intelligent people look very carefully at the formalization (or "code").

In such a case, it is conceivable that some of the people who contributed to the bounties would be disappointed, and might even suggest a hard fork to return the bounties to the contributors.

For my part, I would never support such an action in principle or in practice. If I were still actively developing Qeditas and such a hard fork were to occur, I would either support the original chain or abandon the project as a failure.

There are situations in which a hard fork might be needed. For example, if there were a bug in the consensus code or in the proof checker itself. Someone making use of the system as designed would never form a valid justification for a Qeditas hard fork.

Bill White
Qeditas Developer
July 20, 2016
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJXj9HIAAoJEBTKnDJBv3qSXCAP/34V+O3khxfdcrityOFrey0P
iSWoLfvCgWA6spLyjNv06IdyeaWPALToxgy8FISPmxobCMXrQ33fvM40v0+4BuqC
xplGHuQgxAEX7Z1dk2K4OzTDkblxDR2gglZy2/3Tox0TZ6l5FwA5KrnmU9AxLZhy
KKCAdouKYi072Ix3dxtIIRUN1Yt20+pjmOj+L+QdTEnw7e9lZr26KxAYRjxERLRE
n5Mtw/7oT66kdvryEy4QY5GVeXkSnwFsFH/5hr5GTu8Q+kigXaVhKYQJJ0BMs3ol
Ua6fwVZoYJijPyqEKpoBl0RTj9iPoqnyVWDgSzs8o3/EUqfqCMKulMSShNc6Cs2m
53M8jp9vTCHN8nQbMaji16aq6bp5D9RxhXJcYLNN4W4zZIJgo6Hh1+4lCzNIcLfO
p1GeEFxyT1R1yvFQNWaoXrKjklW/jfOXy+nw99kGRM8wbGZsHnf4NPSEqJIMve0P
YKbtn4iyoeS+pBfUvQVE78gtAsfT3JBvTRM69MQqfzMulJPiCSte0E6fgPgZnihy
wxmpaUlLdH++1ZEMDMldMtb/jCpqDBZ6SDEDSfolCj6tbi8Q1TxMwiu5Qc0ovzgB
p1yoYAIUrBTP/2BNYBnEWTGb+Jv4SejH6fUX/PTPjXuyllsxmxS6V5GC8ZHHQfzp
VvVU24vUicreUxxsV2d1
=BN1Z
-----END PGP SIGNATURE-----

I made two minor changes based on the comments above and tagged a "0.0.1" version. The source code is here:

http://qeditas.org/qeditas-0.0.1.tar.gz

The changes are:

1. There is now a check to see if the file "/dev/urandom" exists before attempting to open it. As gshumway noted, this file does not exist under Windows. The purpose was simply to create a nonce for the node (to prevent it from trying to connect to itself), so if "/dev/urandom" does not exist, then the current time is simply used as a nonce. This is a temporary solution. Hopefully Qeditas 0.0.1 will now compile and run under windows without modifying the source code.

2. I changed the behavior of "printassets" so that it prints the number of fraenks. If you had, for example, 0.1 bitcoins in an address at the time of the snapshot, then you have 0.1 fraenks at the corresponding Qeditas address. (More information about the currency units is in the white paper.)

---

I have been working on the staking and networking code. The next step will be to distribute a release candidate for 0.0.2. It should have the basic ability to connect and stake (all testnet, of course). My expectation is that we will restart from a new testnet genesis once a week or so a few times before trying to stake for longer periods.

In order to stake, users will need to import testnet endorsements. (Importing the appropriate private key would also work, but I do not recommend this.) Importing testnet endorsements is already possible in the current release (0.0.1).

Here is a brief explanation of how to create and import a testnet endorsement. This is only for practice, since the testnet addresses will have a different format starting with the next release.*

1. Create a fresh bitcoin private key. Qeditas cannot do this for you yet. Do not use a private key from your bitcoin wallet. As an example, I went to bitaddress.org and generated a paper wallet with bitcoin private key: KyPNZNdF7vRKJqFED2fuLMqAT8oq191TmeRyVEZdbgo3kGL9mq99

2. Start Qeditas and import this private key into your Qeditas (testnet) wallet:
The corresponding Qeditas address is QjTYZmD1HSKim9wTcnTVzD4kBhHFKkDY5r

3. Find a bitcoin address that had a balance at Block 350,000 (before the txs in this block were processed) for which you have the private key. An example for me is the address 1LvNDhCXmiWwQ3yeukjMLZYgW7HT9wCMru which had a balance of 0.0015 btc. There are 0.0015 fraenks at the corresponding Qeditas address. You can verify this by importing the address as a watch address in your wallet:
This means the corresponding Qeditas address is QgXMKzVExBPkqC4gL63qTqLK1NEAMsuzcq, and in the initial distribution it controls one asset, a currency asset with 0.0015 fraenks. The 40 character hex string
37cfcd67a77ded709ff0b03c1d80ed5fbed8b33f is the 20 byte asset id. The "0" in brackets means the asset was created at height 0 (the initial distribution).

4. Using the private key for the bitcoin address from Step 3, sign a message of the form "testnet:endorse ". For example, I could endorse QjTYZmD1HSKim9wTcnTVzD4kBhHFKkDY5r as a Qeditas address that can sign for the 0.0015 fraenks by signing the message


with the private key for 1LvNDhCXmiWwQ3yeukjMLZYgW7HT9wCMru. The signature will be a long base 64 encoded string (of roughly 90 characters). Since I have revealed the private key for this example address, I will not sign such an endorsement. Instead,


is a signature for


The private key for QgBfPc2jSS5JTe5sncpKoKUAmKQ9mTBCm5 is in my wallet, and was imported as in Step 1.

5. Import this endorsement into your wallet using "importendorsement" as "importendorsement ". In my case:


After importing the endorsement in my case, I can use the private key for QgBfPc2jSS5JTe5sncpKoKUAmKQ9mTBCm5 to sign for QgXMKzVExBPkqC4gL63qTqLK1NEAMsuzcq. In particular, I can use the asset above with 0.0015 fraenks for staking during the testnet.

These endorsements are only for the testnet. Endorsements on the mainnet will be signed messages without the "testnet:" prefix.

*Edit: The examples above work in 0.0.1, but will not work in future versions. In 0.0.1 testnet addresses are idential to mainnet addresses. This was an oversight which will be corrected in the next release.

The distribution is based on a snapshot of the Bitcoin balances as of block 350,000.

Qeditas is currently displaying the balances in terms of the lowest units ("cants"). An address that had 1 satoshi in the snapshot starts with 1000 cants in Qeditas. (In other words, Qeditas has 3 extra digits of precision.) Perhaps it would be a better idea to display the number of fraenks instead, since 1 fraenk corresponds to 1 bitcoin. It would be easier for people to check that the distribution is correct.

That is great to hear! Thank you for your work.

Regarding the call to /dev/urandom, this could be replaced by something giving random numbers that do not need to be cryptographically secure. However, in the end we will definitely need to be able to obtain cryptographically secure random numbers. In linux I can get these from /dev/random. There must be some way to obtain cryptographically secure random numbers in Windows, in a way that can be called from OCaml.

Thank you for trying under Windows. It isn't surprising that it does not work immediately.

If you are getting OCaml errors, feel free to post them here or send them to me in a private message. If I recognize the errors, I might be able to advise you.

One possibility is to use Cygwin: https://cygwin.com/. It is supposed to simulate a linux environment withing Windows.

I assume this is intended as a (humorous) reference to quesadillas. This is actually close to how I pronounce it, except there are three syllables with the stress on the first.

Here is an attempt to give the pronunciation using the IPA.

https://en.wikipedia.org/wiki/Help:IPA_for_English

quesadilla (/ˌkeɪsəˈdiːjə/)
qeditas (/ ˈ keɪ diː tɑːs /)

Thank you. If it turns out to work under Windows, I will be happily surprised. If it turns out to require some minor modifications to work under Windows, please let me know. In that case, I can do a new release with the modifications.

I have decided to do the first alpha release. Most of the important functionality is still missing, but at least this gives a chance for people to try to compile and run the code.  It will not connect to a network. At the moment, the main things a user can do is import addresses into a wallet and print the assets they have in the initial distribution.  (Again, the initial distribution was based on Bitcoin block height 350,000. This is fine for the testnet, but I am open to changing it for the mainnet when the time comes.)

You can download the release 0.0.1rc2 either from qeditas.org:

qeditas.org/qeditas-0.0.1rc2.tar.gz

or from mega.nz:

https://mega.nz/#!MhAUUA6S!cTe33Yd5P4p7WYU5fFuWAC-kmqKhzhfFIv0h4bRRLBU

If you want to verify the integrity, here is the sha256sum:

1a88b885f0e4dd5c663440326047ca1b316e5875c5697d3930deb314dbbd2773

There is a README.md file that explains how to compile and run Qeditas, as well as how to import (watch) addresses and print the assets held at those addresses.

(There are also commands for importing private keys. Just to be safe, I recommend no one tries this with private keys that held bitcoins. Importing as a watch address is sufficient for now. When the time comes to test staking, the assets in the initial distribution can be controlled via endorsements. You will never need to import a private key that held bitcoins.)

You will need OCaml to compile Qeditas.

If you want to print the assets in the initial distribution, you will need one version of the initial ledger tree. I have created and
uploaded three versions: one with the full ledger tree (656MB), one with only the p2pkh addresses (606MB) and one with only the p2sh addresses (39MB). These files are too big to download from qeditas.org, so they are at mega. (You only need one.) Here are the links and the sha256sum to verify the integrity.

qeditas-db-initdistr-full.tgz
https://mega.nz/#!Ap5ylL4C!WLy3bTvMWSwuIKVQvmW7BOT7t38WWLeU8bVlRxt7CtE
sha256sum: 6687d1f4bd4a6c2263276e83f6a27f3d7df465f8adfaa6322f950cb9ae58faf4

qeditas-db-initdistr-p2pkhonly.tgz
https://mega.nz/#!t5YnjJBZ!1LUVDNm9p7PYI51bA2__m323zwnBK3aG0r82_sGY7Qs
sha256sum: d48201961b2d2b904b1aad5911131d3f23714ac30d25daa085e9d45850afdded

qeditas-db-initdistr-p2shonly.tgz on mega:
https://mega.nz/#!NlpTSY5I!eg2MYZeKLF0W30yngBlXprqrMnmqfz_Mx3QKOtIrjO0
sha256sum: fc3c39f7b87de31f9c4b46dfce2eeec0e1691bb7863455311ec3e8a875f06134

The README.md file explains what to do with the file once you download it. (Again, you only need one. If you want to check both p2pkh and p2sh addresses, you'll need the full one.)

Here is a PGP signed copy of the links and hashes above, for those who are extra cautious. My PGP key is available at https://pgp.mit.edu/ (search for billwhite@bitmessage.ch).


Of course, I can imagine there may be problems. Feel free to post here about the problems and we can try to fix them. The purpose of this release is simply to get an initial idea of what issues to expect.

Here are two issues I can preemptively address:

Qeditas has only been tested under Linux. I would be surprised if it worked under Windows.  It probably works under Mac OSX, but this has not been tested.  Others are welcome to attempt to use Qeditas under Windows, but I can not imagine myself investing effort into a Windows version.

There is no GUI. When you run the executable you will be in a console in which you can give commands. I have no plans to build a GUI, but someone else is welcome to do so.

You can if you want, but it's probably better to wait. The earliest I can imagine the Qeditas network launching is in late 2016. It's likely that if someone wants a fresher snapshot, then they will want it to be nearer to the time of the launch than now. The user sfultong (earlier in this thread) did some work to help people create snapshots. I am not sure of the status of his work, but if you do decide to take a snapshot his work might help you.

Something that would be much more helpful (and probably easier) would be to integrate the Qeditas OCaml code with some standard library for persistent storage of key-value pairs, like leveldb. Trent Russell tried to do this, but encountered some difficulties. In the end, he implemented his own file based storage "database" module. I have recently finished documenting his database code in Chapter 6 of the Technical Documentation:

http://qeditas.org/qeditastechdoc.pdf

That code is in src/db.ml and src/db.mli in the dev branch.

Integrating with leveldb (or something similar) would almost certainly have better performance.

There is a chapter in the OCaml manual that explains how to call C functions:

http://caml.inria.fr/pub/docs/manual-ocaml/intfc.html

A similar task would be to have the Qeditas OCaml code call C functions to do the hashing (sha256 and ripemd160). There must be open source C implementations of these hashing functions, and I suspect calling C versions instead of the current OCaml versions would significantly improve performance.

After spending some time reviewing Trent Russell's code, I have merged it into the dev branch: http://qeditas.org/gitweb/?p=qeditas.git;a=log;h=refs/heads/dev

This gives all of us a common code base to branch off of, in case anyone wants to contribute.

The white paper had not been updated in over a year, so I spent some time bringing it into agreement with the current status and plan. For example, the white paper now discusses the plan to have claim windows during which the value of the unclaimed initial distribution will halve every 4 years after the first 5 years.

The latest draft of the white paper is here: http://qeditas.org/qeditas.pdf

One thing is worth explicitly discussing now. The snapshot from block 350,000 is now over a year old. While I am not opposed to using a more recent snapshot instead, I am opposed to taking such a snapshot myself. Taking and preparing such a snapshot is very tedious and time-consuming, and I have no interest in doing this again. If someone feels strongly that a more recent snapshot should be used, please prepare it for me. Otherwise, I will simply use the earlier snapshot. There are stronger arguments in favor of using the older snapshot, or perhaps combining the older snapshot with a newer one. For example, the earlier snapshot was announced in advance as the one on which the Qeditas distribution would be based. It may be considered unfair to change that now.

My next task is to update the technical documentation to reflect the changes in the code. Then I will create a version people can download, try to compile, and check their balances. To check a balance, people will need to also download the initial ledger tree, which is roughly 700MB. This data will be separate from the git repo.

This is good to hear. I do have some ideas how someone with C++ (or C) knowledge could improve Qeditas, and I will write more about this later.

Thank you for your interest.

Due to being busy with other things, I have not directly done any work on Qeditas since December. Nevertheless, I have been exchanging private messages with someone who has been experimenting with his own fork of the code. I must admit I haven't looked closely at his progress, but hope to spend some time reviewing it soon. Perhaps he will want to say more.

Generally speaking, anyone who wants to help bring Qeditas to reality is welcome. It turned out to be much more work than originally estimated. The idea of combining formalized mathematics with a cryptocurrency still appeals to me. I am certainly still interested in seeing the project completed, even if it takes years instead of months.

It's perhaps fair to say that your proposal hasn't generated controversy. I don't have a strong objection to slowly decreasing the amount of initial distribution that can be claimed. It's consistent with the Spin-Off idea, so long as there is sufficient time for everyone to claim their part of the distribution. Five years certainly seems like enough time to become aware of the project and make a judgment about it.

This change makes sense, and your code conforms to the style of the other serialization code. One issue worth noting is that two different serializations can deserialize to the same frame (one using sharing and one not), but this shouldn't be a problem.

I still haven't yet looked at the C++ qednet code, but hope to do so soon. Thank you for your efforts.