Bitcoin Forum
June 26, 2017, 07:34:41 AM *
News: Latest stable version of Bitcoin Core: 0.14.2  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 3 4 5 6 7 [8]  All
  Print  
Author Topic: [PRE-ANN] Qeditas: A Formal Library as a Bitcoin Spin-Off  (Read 13503 times)
This is a self-moderated topic. If you do not want to be moderated by the person who started this topic, create a new topic.
gshumway
Newbie
*
Offline Offline

Activity: 7


View Profile
June 14, 2016, 09:55:34 PM
 #141

At the end of the day I've managed to build and start it under the Windows,  and it works correctly.)

The only problem is src/qeditas.ml,  line 331:
Code:
    let dur = open_in_bin "/dev/urandom" in (*** this is to compute a nonce for the node to prevent self conns; it doesn't need to be cryptographically secure ***)

I've used a real file with real path instead of the "/dev/urandom" as a simplest workaround, I need more OCaml knowledge to fix it correctly, I can't do it right now.

I'll share Windows build instructions later, after I test it on clear Windows installation and choose the simplest way to build the project.
1498462481
Hero Member
*
Offline Offline

Posts: 1498462481

View Profile Personal Message (Offline)

Ignore
1498462481
Reply with quote  #2

1498462481
Report to moderator
1498462481
Hero Member
*
Offline Offline

Posts: 1498462481

View Profile Personal Message (Offline)

Ignore
1498462481
Reply with quote  #2

1498462481
Report to moderator
POLONIEX TRADING SIGNALS
+50% Profit and more via TELEGRAM
ALTCOINTRADER.CO
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1498462481
Hero Member
*
Offline Offline

Posts: 1498462481

View Profile Personal Message (Offline)

Ignore
1498462481
Reply with quote  #2

1498462481
Report to moderator
1498462481
Hero Member
*
Offline Offline

Posts: 1498462481

View Profile Personal Message (Offline)

Ignore
1498462481
Reply with quote  #2

1498462481
Report to moderator
1498462481
Hero Member
*
Offline Offline

Posts: 1498462481

View Profile Personal Message (Offline)

Ignore
1498462481
Reply with quote  #2

1498462481
Report to moderator
Bill White
Member
**
Offline Offline

Activity: 118

Qeditas: A Formal Library as a Bitcoin Spin-Off


View Profile WWW
June 15, 2016, 07:53:15 PM
 #142

At the end of the day I've managed to build and start it under the Windows,  and it works correctly.)

The only problem is src/qeditas.ml,  line 331:
Code:
    let dur = open_in_bin "/dev/urandom" in (*** this is to compute a nonce for the node to prevent self conns; it doesn't need to be cryptographically secure ***)

I've used a real file with real path instead of the "/dev/urandom" as a simplest workaround, I need more OCaml knowledge to fix it correctly, I can't do it right now.

I'll share Windows build instructions later, after I test it on clear Windows installation and choose the simplest way to build the project.

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.

gshumway
Newbie
*
Offline Offline

Activity: 7


View Profile
June 15, 2016, 08:10:27 PM
 #143

It seams that main Windows build problem was because of the big number of the C++ compilers installed on my PC.) All is simple and working without big problems on clear Windows installation:
 1. Install MinGW with MSYS (http://mingw.org/,  use 64bit toolchain)
 2. Install OCPWin (https://www.typerex.org/ocpwin.html,  use compiled with mingw package)
 3. Add OCPWin bin directory to system PATH environment variable.
 4. Open MSYS and navigate to qeditas sources
 5. Fix the problem in sources,  mentioned in previous post,  for example change "/dev/urandom" to "urandom" and place non-empty file with name urandom near the qeditas.exe in the future.
 6. Use usual configure & make to build qeditas.exe (set install and data directory in configure args)

That's all.

Now I'm trying to build Trent Russel's branch with leveldb.

What about dev/urandom: I hope to find universal way to get random numbers in OCaml,  if there is no such way (it would be surprising) we can add C-based module to generate such numbers that will work on any platform.
mishra1994u
Full Member
***
Offline Offline

Activity: 196



View Profile
June 15, 2016, 08:11:24 PM
 #144

How was the distribution balances calculated?
Are these balances in lowest unit forms?
Bill White
Member
**
Offline Offline

Activity: 118

Qeditas: A Formal Library as a Bitcoin Spin-Off


View Profile WWW
June 15, 2016, 09:08:32 PM
 #145

How was the distribution balances calculated?
Are these balances in lowest unit forms?

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.

Bill White
Member
**
Offline Offline

Activity: 118

Qeditas: A Formal Library as a Bitcoin Spin-Off


View Profile WWW
June 19, 2016, 04:27:37 PM
 #146

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:
Code:
./bin/qeditas -testnet
> importbtcprivkey KyPNZNdF7vRKJqFED2fuLMqAT8oq191TmeRyVEZdbgo3kGL9mq99
Imported key for address QjTYZmD1HSKim9wTcnTVzD4kBhHFKkDY5r
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:
Code:
> importwatchbtcaddr 1LvNDhCXmiWwQ3yeukjMLZYgW7HT9wCMru
Importing as Qeditas address QgXMKzVExBPkqC4gL63qTqLK1NEAMsuzcq
> printassets
Assets in ledger with root 66c029f4c29b351785c0480cedc9449b64332dfa:
...
Watched assets:
QgXMKzVExBPkqC4gL63qTqLK1NEAMsuzcq:
37cfcd67a77ded709ff0b03c1d80ed5fbed8b33f [0] Currency 0.0015 fraenks (150000000 cants)
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 <Qeditas Address>". For example, I could endorse QjTYZmD1HSKim9wTcnTVzD4kBhHFKkDY5r as a Qeditas address that can sign for the 0.0015 fraenks by signing the message

Code:
testnet:endorse QjTYZmD1HSKim9wTcnTVzD4kBhHFKkDY5r

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,

Code:
IKtfPT5fnrN2FmzGk+MY2fHARxtwJXDCqOo5Zk14RsGXHcYCRKRqY5ZsBNGckq631TRPWLj4NI69iMp4fNe9j3U=

is a signature for

Code:
testnet:endorse QgBfPc2jSS5JTe5sncpKoKUAmKQ9mTBCm5

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 <from address> <to address> <signature>". In my case:

Code:
> importendorsement QgXMKzVExBPkqC4gL63qTqLK1NEAMsuzcq QgBfPc2jSS5JTe5sncpKoKUAmKQ9mTBCm5 IKtfPT5fnrN2FmzGk+MY2fHARxtwJXDCqOo5Zk14RsGXHcYCRKRqY5ZsBNGckq631TRPWLj4NI69iMp4fNe9j3U=
just verified endorsement signature:
...
endorse QgBfPc2jSS5JTe5sncpKoKUAmKQ9mTBCm5

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.

Bill White
Member
**
Offline Offline

Activity: 118

Qeditas: A Formal Library as a Bitcoin Spin-Off


View Profile WWW
July 20, 2016, 07:39:30 PM
 #147

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-----

ldc73
Newbie
*
Offline Offline

Activity: 12


View Profile
July 21, 2016, 07:54:22 PM
 #148

I wanted to say That I like the project. I recently made a post about my idea for "TrueCoin" and someone pointed me to here.

https://bitcointalk.org/index.php?topic=1545852

as an idea it should do similar things

Reading the White Paper, but I am just not sure where I can find more Information about the logic or Foundation. also it there more Information about the proof of stake in Something?

Compared against "TrueCoin" do You think There is an argument that Qeditas issimilar?
Bill White
Member
**
Offline Offline

Activity: 118

Qeditas: A Formal Library as a Bitcoin Spin-Off


View Profile WWW
July 22, 2016, 07:19:30 PM
 #149

I wanted to say That I like the project. I recently made a post about my idea for "TrueCoin" and someone pointed me to here.

https://bitcointalk.org/index.php?topic=1545852

as an idea it should do similar things

Reading the White Paper, but I am just not sure where I can find more Information about the logic or Foundation. also it there more Information about the proof of stake in Something?

Compared against "TrueCoin" do You think There is an argument that Qeditas issimilar?

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.

ldc73
Newbie
*
Offline Offline

Activity: 12


View Profile
August 06, 2016, 07:29:09 PM
 #150

reading the kinds of possible explanations you pointed to moved me to have questions about stake:

Three types Of possessions that can stake emerge:

1. unlocked
2. locked up rewards
3. locked up non-rewards

one: can you say what This separated camps is for? these "locked up" are all complicated. and What is the reason rewards are different behavior?

two: in 9.1.1 it seems that camps 1 & 2 each age according to some laws ONce they become "mature" -- and they become "mature" after 512 blocks. is it correct though that camp 3 (locked up non-rewards) has it that it matures in some 8 blocks? can you give a clue what is the reason for this very fast becoming "mature" here?  It seems to lack stability in principle since you possibly can stake every 8 Blocks with the same locked up non-reward?

three: in 10.1 the idea of "stake modifier" is being discussed there. it seems that at each block the stake modifier for the next 256 blocks are known, as well the fact the next 256 part is known. I Can project a problem. the locked up non-reward can be used to stake 8 blocks next and I can known the stake modifier for this next 8 blocks. now how to solve this problem?
Bill White
Member
**
Offline Offline

Activity: 118

Qeditas: A Formal Library as a Bitcoin Spin-Off


View Profile WWW
August 07, 2016, 04:16:55 PM
 #151

reading the kinds of possible explanations you pointed to moved me to have questions about stake:

Three types Of possessions that can stake emerge:

1. unlocked
2. locked up rewards
3. locked up non-rewards

one: can you say what This separated camps is for? these "locked up" are all complicated. and What is the reason rewards are different behavior?

two: in 9.1.1 it seems that camps 1 & 2 each age according to some laws ONce they become "mature" -- and they become "mature" after 512 blocks. is it correct though that camp 3 (locked up non-rewards) has it that it matures in some 8 blocks? can you give a clue what is the reason for this very fast becoming "mature" here?  It seems to lack stability in principle since you possibly can stake every 8 Blocks with the same locked up non-reward?

three: in 10.1 the idea of "stake modifier" is being discussed there. it seems that at each block the stake modifier for the next 256 blocks are known, as well the fact the next 256 part is known. I Can project a problem. the locked up non-reward can be used to stake 8 blocks next and I can known the stake modifier for this next 8 blocks. now how to solve this problem?

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.

ldc73
Newbie
*
Offline Offline

Activity: 12


View Profile
August 09, 2016, 07:16:38 PM
 #152

three: in 10.1 the idea of "stake modifier" is being discussed there. it seems that at each block the stake modifier for the next 256 blocks are known, as well the fact the next 256 part is known. I Can project a problem. the locked up non-reward can be used to stake 8 blocks next and I can known the stake modifier for this next 8 blocks. now how to solve this problem?
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.
the problem I mean is not solved. It is not just from the locks to oppose trusted -- the problem is Now combination:

The fact in 8 blocks time it can stake.

The stake modifier in 8 blocks, given the explanation, is as known.

This all means someone can to test and to realize If creating an locked will allow him IN 8 blocks with (to the time) proposal. If locked pattern will not allow him to stake, they can test other possible (according to a different address, still by him) will allow him works. for he can try as many as he wants to he finds the outcome will stake. this should be a serious consideration
Bill White
Member
**
Offline Offline

Activity: 118

Qeditas: A Formal Library as a Bitcoin Spin-Off


View Profile WWW
August 10, 2016, 05:21:29 PM
 #153

the problem I mean is not solved. It is not just from the locks to oppose trusted -- the problem is Now combination:

The fact in 8 blocks time it can stake.

The stake modifier in 8 blocks, given the explanation, is as known.

This all means someone can to test and to realize If creating an locked will allow him IN 8 blocks with (to the time) proposal. If locked pattern will not allow him to stake, they can test other possible (according to a different address, still by him) will allow him works. for he can try as many as he wants to he finds the outcome will stake. this should be a serious consideration

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.

ldc73
Newbie
*
Offline Offline

Activity: 12


View Profile
August 12, 2016, 06:34:58 PM
 #154

interesting

I am happy when you've agreed on the problem with the attack.

I hope further it goes out as helped and gives hit and energy for fighting It not disappointed.
Bill White
Member
**
Offline Offline

Activity: 118

Qeditas: A Formal Library as a Bitcoin Spin-Off


View Profile WWW
August 13, 2016, 03:29:24 PM
 #155

interesting

I am happy when you've agreed on the problem with the attack.

I hope further it goes out as helped and gives hit and energy for fighting It not disappointed.

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.

Bill White
Member
**
Offline Offline

Activity: 118

Qeditas: A Formal Library as a Bitcoin Spin-Off


View Profile WWW
August 28, 2016, 06:35:51 PM
 #156

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.

ableorange
Member
**
Offline Offline

Activity: 100

All things bitcoin


View Profile
November 15, 2016, 12:29:34 PM
 #157

Project Qeditas (Bill White) is live on IOHK's website.
https://iohk.io/projects/qeditas/

Microsite here: http://qeditas.org & the old QED manifesto here: https://www.cs.ru.nl/~freek/qed/qed.html

Bitcoin is for money, Ethereum is for computation, Qeditas is for deduction
Qeditas is a project to apply block chain technology to support the construction of a library of formalized mathematics. It is intended to be a realization (or possibly revival) of the QED project, as described in the QED Manifesto.

In other news. Please take a look at the IOHK dash governance system (and-suggestions-for-improvement) paper in our new papers section here:

https://iohk.io/research/papers/dash-governance-system-analysis-and-suggestions-for-improvement/

Bill White
Member
**
Offline Offline

Activity: 118

Qeditas: A Formal Library as a Bitcoin Spin-Off


View Profile WWW
November 16, 2016, 07:57:02 PM
 #158

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/.

ldc73
Newbie
*
Offline Offline

Activity: 12


View Profile
March 16, 2017, 06:40:43 PM
 #159

there is a new thing for this? I do not a where to look for new   version.
Pages: « 1 2 3 4 5 6 7 [8]  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!