There is no mining in the -qt, it is just for being a pretty client for GUI-users.


The devcoind is necessary for mining. Boost or Qt threads just would not handle mining, we had to disable mining for that reason.

The devcoind actually has the old wxwidgets stuff in it too, but we don't bother with that GUI so I do not even know if it compiles or works, it is just what came in the old bitcoin we hacked with minimum necessary hacks to make devcoind.

By minimum I mean even the names aren't changed, you make -f makefile.platform bitcoind then strip it and rename it as devcoind, and its default config file and maybe even data directory also still say bitcoin I think. I use shell scripts to invoke all the coin-daemons so my shell-script passes the directory and config file names to the commandline.

Even running devcoin-qt I still passed everything on the commandline so never actually tried just setting stuff in the config file.

Config probably works though its just the there is no generate in the -qt one.

I don't know why it isn't synchronising though. I used to find first time I run it it dies of no directory yet makes the directory then second time I run it it works. I don't know though whether the percent downloaded estimator even works, maybe it just stays at 0% until it gets to 100%, no idea really. I always already had blockchain from using the daemon when I ran the -qt and never ran it much at all.

Does the debug.log give any clues? I wonder if somewhere among the changes to the difficulty changes and so on it might have ended up leaving initial downloads thinking dofficulty is wrong or something maybe it is piling all the blocks into the orphans pile or outright rejecting them or something.

-MarkM-

Because DeVCoin gives out 50,000 coins per block as compared to BiTCoin's 50, it also has 1000 times as much transaction fee. So the amount over 5000 you see in the award to the miner is quite possibly largely composed of transaction fees.

(Largely of the ones it considers mandatory. The trivial amounts also there might be voluntary ("donationed" as it were) transaction fees. Obviosly all over the 5000 ought to be composed entirely of "transaction fees" technically.)

-MarkM-

Social engineering seemed like a reasonable way to start propagating, I have some code started at my latest GitHub project.

-MarkM- (Oh the project? Galactic Milieu of course.)

I do not think it is ready until root can install it system-wide for each user to be able to use it without each having to have their own copy of the blockchain.

The blockchain(s) should go in /var/spool/blockchains or something like that, where all users can access it or each daemon (main net and test net even if not considering alternate blockchain-based applications) can get at it to provide each user an interface that doesn't involve having access to other users' accounts.

-MarkM-

Well it seems to me I would not want to run my whole server in cash-only mode just because some of the currences or shares or stocks or bonds or commodities supported choose to be cash-only instruments.

So the cash-only setting should be a per-currency setting, I think.

-MarkM-

I have just issued the GMC contract onto my Open Transactions server, so we now have the first DeVCoin stock-exchange, in that you can buy/sell General Mining Corp for DeVCoin (among other currencies).

Next I will be adding General Retirement Corp, then start figuring out how the Initial Public Offering (IPO) process for inauguration of new types of shares will be structured.

Currently only Preferred Shares are really suitable, because the planned voting systems are not yet in the code, nor does the code have routines for automatically distributing dividends.

GMC and GRF fit this nicely, as they have always been more like a currency than a share, in that they never planned to pay dividends they always planned that instead of paying out dividends they would simply increase their holdings of useful/valuable collateral and capital equipment and so on, providing holders of the scrip / currency with increased value per coin instead of dividences of more coin of that or some other type.

Possibly they might not quite really be what a properly DeVCoin Stock-Exchange would be using?

Maybe to have a properly DeVCoin stock-exchange we would mean that stocks denominated in some sense in DeVCoin would be issued?

It might be interesting to figure out quite what we would mean by "a DeVCoin stock exchange" ?

But if we merely mean one in which we can trade DeVCoin for stocks and bonds and such, I think maybe I might be able to qualify?

-MarkM-

If separation of powers is used, where the issuer of a currency is spearate from the operator of a transactions server, then publishing of all receipts is the usual way to provide the issuer assurance that no more of their currency is being issued than they authorised.

By making these public, the public can also check that they all add up and thus that the issuer of the currency is not issuing more of their currency than they claim to have issued.

I am not sure where the Fed's list of all the serial numbers of bills it has printed and which ones are still outstanding is, nor even of the total amount printed in any given fiscal period. Hmm....

Publishing all receipts challenges users' pseudonymity as everyone can see exactly which accounts sent how much of what to which other accounts, so would probably increase the price those who do want to try to obscure their trail will need to pay. For example they could generate hundreds or thousands of wild goose chase accounts to spew transfers between and generally try to create vast amounts of actrivity by innocent sockpuppets in an attempt to make the actions they are trying hide amongst the crowd possibly a little harder to pick out.

It is maybe a bit of a trade-off, do you want to use an issue that publishes all receipts or one that does not? Different strokes for different folks?

-MarkM-

Open Transactions "nyms" (pseudonyms) also are hashes, so are similarly just un-memorable gobbledegook to humans. Server and currency contract IDs similarly.

Thus it could be useful to have namespaces in namecoin to allow looking up a server or currency or nym's ID using a memorable name.

This could also help a little against spoofing of currencies that become popular; instead of relying upon some random website somewhere that tells you to import some contract from their site, expecting it to be the contract of some well known well reputed currency, and just trusting it, you could look up the currency by its famous name (careful here though of fonts that fool you by using characters that look similar to other characters) in a currency ID namespace in namecoin to find its ID as recorded in namecoin by, one might hope, the actual issuer/signer of its actual correct contract.

In other news, my Open Transactions server, still in alpha testing stage, now supports bitcoins (BTC), britcoins (UKB), botcoins (MBC), and devcoins (DVC) in addition to namecoins (NMC), enabling trading among them all. (The bottleneck of course is I only want to issue the corresponding digital tokens in numbers no greater than the number of secured by hardcoded checkpoint in clients coins I have as reserves.

That means one cannot simply send me coins and I issue tokens, because the coins you send me will not be secure enough to be a good secure reserve to back tokens with until after the release of clients that have hardcoded checkpoints protecting the block you sent those coins in from attackers trying to unravel the blockchain.

How long it typically takes for more than half of the hashing power of a blockchain to update to code that includes such updated hardcoded checkpoints probably varies from chain to chain. SO this will proably have to be a slow-growing exchange. Hopefully though it will be all the more secure for taking its time in this way.

-MarkM-

I have put a binary for Fedora Core 15, built on a 64-bit machine, on the sourceforge downloads site.

I have also added more currencies and still have more to add, will keep plugging away at that.

-MarkM-

Question, what resources doe a permanent node need (# connections, memory, CPU load)?
[/quote]

The important one is 24/7 incoming port open. Most people do not have a port open in their router for other nodes to connect to them, they reach out to connect to others. Most of those others cannot be reached out to. Default number of connections to try to have even for those who cannot be reached out to is 8, but there do not seem to be 8 nodes yet that can be reached out to. The three connections I have might well just be the three amazon virtual machines one person set up. It would be nice if one could not only attain 8 connections but also have them all be controlled by different actual people.

They need not mine, so CPU load should be quite minimal/reasonable. They can have many connections. I believe the level of virtual machine that amazon offers free to people who have a credit card can handle it no problem at the current level of load and size of blockchain. (I just don't happen to have a credit card currently, bah humbug.)

-MarkM-

Nice exposition, thanks.

If you can find G. Spencer Brown's "Laws of Form" see if you can read it and make sense of it.

It is an excellent extremely minimalistic "form" that treats the empty page as "or" and "the mark" (the label, the distinction, that which makes distinguishable marks upon the page, that which is distinguishable from the emptiness that is take as "or") is taken as "not".

Thus if we use "being in parentheses" as "the mark", (a) (b) would represent (not a) or (not b).

He proves that all lemmas can be stated in forms not more than two deep, such as ((a)(b)).

It is a very useful notation because you can cancel things out very easily, and all that remains is the solution to the lemma.

It uses not and or instead of not and and so I guess would be using nor gates instead of nand gates, but any two such primitives suffices, its like whether to use one or zero as true or false, or whether to use NPN or PNP transistors maybe in a way. Anything that can be represented using one can also be represented using the other.

Its a pretty small book but very amazing contents, I expect you will find it quite interesting if it is not already part of the bread and butter that got your this far already.

-MarkM-

I am glad I did this as "alpha test", wow, getting this "whitespace problem" squashed has been a marathon.

The full set of fixes are in the smartcontracts branch of FellowTraveler's GitHub repo, not yet merged back into the master branch.

I have generated new certificates, used them to create a new nym to serve as admin/signing nym for a new server, and used that nym to sign a new DigitalisOTserver.otc which I have uploaded to the galactic milieu files download directory on SourceForge.

I have also created a sample/example "empty" ~/.ot directory for clients, it has no nyms no currencies no accounts but does have my new server-contract and uploaded it to SourceForge as dot-ot-empty.client.tgz

I have lots of currency contracts to write and sign using the latest fixed versions of the OT server and client, as I create those I will put the .otc files of the contracts on SourceForge and also start putting a dot-ot-clean.client.tgz that will have the main currencies my server intends to work with as well as my server's contract.

We are still in alpha; FellowTraveler intends to check that my contracts work on his installed client and so on tomorrow.

However, even in alpha it is worth being aware that although Open Transactions is not totally married to its past with merkle trees like blockchains are, there is some one thing building upon another involved. So if at any point you feel ready to create some nym or contract or account that might make you not want to totally delete your ~/.ot and start over again from a fresh new dot-ot-empty.client.tgz or dot-ot-clean.client.tgz that is the moment when you should seriously consider the stuff that is in ~/.ot/client_data/certs/special.

In there we have placed a certificate authority (ca.crt) and a certificate signed by that authority (client.pem).

You will probably not want to use those distributed ones for creating any mission-critical nyms, nor presumably any nyms created using them for any mission-critical accounts and especially not for signing any mission-critical contracts.

I am right now going through everything on my side making sure they are not the same ones my server's client_data has nor the same ones my personal ~/.ot has.

Well actually, the ca.crt seems to stay the same, as it is not part of what gets generated when you do the make in the source code's ssl directory to generate new certs for the client and server. So I am not yet sure who the certificate authority actually is or was. But the rest of the special stuff does get made fresh. (In sourcs dir, do cd ssl then touch *.cnf or actually tailor the .cnf files to your needs, then make).

If you have a "real" certificate for your http website or whatever, then maybe you might want to use that for creating your website's client_data so signing things relating to your website using OT will have some kind of actual back-trail all the way back to the root cert that signed the certs of the cert authority that issued you your website cert.

-MarkM-

EDIT: When you "make" OT, it does NOT currently at time of writing use your fresh new ./ssl stuff to create fresh new sample data. We probably should add to OT's make the making of a frsh newdot-ot-yours or somesuch, I don't think (tho not positive) that the ~/.ot make install creates for the user who runs make install (usually root, since it tries to install binary executables into /usr/local/bin) uses fresh new ./ssl date you maybe created, either.

Some of the files in the ./ssl look like they might be intended for use as, or for making, a ca.crt, but I am not clear what exactly is going on there so thus far I have only been copying a newly made fresh client.pem from there into the ~/.ot/client_data/certs/special directory. So possibly I am not actually ending up with a ca.crt that matches the client.pem. All this will have to be thoroughly checked out to figure out exactly what one should end up putting there, especially in cases where you have real certs signed by a real authority (such as yourself heh. )

This kind of thing is why bitcoin and all its derivatives need the ability to run more than one daemon on the same blockchain with different wallets or the ability in the daemon to speficy which PRC login/password pairs are to be permitted to do what with which "account".

You should have been able to run the pool as a totally different user from you, with no access to your wallet.

But having umpteen users each with an entire copy of the blackchain of each type of coin that user wants to play with is silly.

-MarkM-

Fixed typo for you.

Would it be cool enough to be worth picking up the domains I mentioned for use in such a project?

I somehow failed to notice what the avatar was showing, instead mention of Egyptian deities caught my eye.

Upon investigating I thought hmm, that peek inside thing is nice, and i2p is already p2p, why use a gitr repo to distribute data to nodes?

Well of course just because people use git doesn't mean the also use p2p, so maybe knowing they have git one could use git to deliver p2p, not everyone need be coming from p2p out into the universe where git seems mostly to live, maybe some people might be persuaded to let git get them tooled up to do i2p and who knows, maybe they too will encounter egyptian deities osmewhere on one side or the other of the veil behind which what goes on speculation may run rampant but maybe only such deities know for sure...

(If even they do, heh heh.)

-MarkM- (So, wanna actually do it, then?)

Hmm how about lines 38 through 46 of https://github.com/knotwork/galacticmilieu/blob/master/PURPOSE ...

Surely is it obvious at a glance that the purpose is to
take control of your computer, or at least one user on your
computer.

It is all part of Tux and Tuxette's implementation of
their part in carrying out the Grand Plan of Linus (GPL):
taking over the world.

The rest is mere implementation details.

-MarkM-

I just now got to the part of my new GitHub project where I pushed a LIMITATIONS file for it when it struck me, having just basically suggested that at least some nodes of the project should run git repos not just (like most nodes) git clients, that maybe no-one had snapped up gitcoin,com, gitcoin,org and gitcoin.net yet.

Well it turns out that GoDaddy has, but no one seems to be actually using, GitCoin.com (GoDaddy is trying to sell it it looks like, before who-ever isn't using it lets it expire even maybe, and likely for more than they normally charge for a dot-com domain) but gitcoin.org and gitcoin.net seem to be available.

I haven't yet got to the part of the project in which "would you prefer to run all the alt chains' daemons yourself, or just use Open Transactions as generic gateway to coins in general and currencies in general" part of the configuration process usrs aka admins using the project will need to go through to configure what exactly their node will be up to and how it will implent getting up to it, but *coins are definitely implicated in the overall project.

Maybe if someone likes the idea of using *coins to help lubricate the operations of such a project, such as by rewarding nodes that do choose to host git repos, they might consider whether gitcoin might be a useful term for bundling all coin-based reward schemes independent of which types of coins are used / supported / preferred by which nodes into a general "this is about coins in regard to git" term.

Services such as GitHub cater to open data, and are not as p2p-ish as people running repos themselves on their own machines. They are not good for things like putting data intended for specific entities or groups, in encrypted form only the target entity or group can decode, out where who actually pulls it might not be very controlled/restricted.

Anyway, just thought I'd throw the name out here in case it interests anyone. Maybe even enough to think about starting yet another blockchain to mint actual Gitcoins, who knows?

-MarkM- ( My new GitHub project? GitHub-only portion of Galactic Milieu project )

Why pay ten million bucks to secure a network on which you want to make payments smaller than Bitcoin's minimum/default transaction fee, for things only worth such small amounts?

An attacker who has 2 CPUs to your 1 could maybe make as much or more selling you routing of transactions or verifiable glimpses of a verifiable blockchain than trying to buy something off of you and double-spending.

In fact the entity with the two cores to your one core might even tend on average to be more likely to have stuff to sell to you than any interesting buying things from you.

(Not sure of that; one theory has it that the rich buy stuff from the poor since the rich have more to buy stuff with; another theory imagines they get rich by selling something or having ancestors who used to sell something; how does balance out in random samples of okay in this cafe count the processing power of each person in the cafe and compare it to which ones are vendors of something to the others and which are buyers of something from others? Does the owner of the venue often turn out to be the richest / most powerful? Or does that depend of whether clientele is upscale or downscale compared to the proprietor?)

Maybe trivially inexpensive coins might be great for tiny stuff where you for example buy a couple of minutes of wifi access for some almost-disposable-coin the vendor sells on some exchange/market as instantly as possible, almost throwing it away as worthless for some tiny fraction of a bitcoin, but will cash out in bitcoins some day if they ever have enough value in their bitcoin account at that exchange/market to bother paying bitcoin's minimum/default transaction fee or thereabouts to cash it out?

o some people might do a double-spend, losing me my tiny pay for some tiny number of minutes I gave them wifi access for. Big deal. Leaving the cafe with the cup I served them their coffee in would cost me orders of magnitude more...

-MarkM-

The novel "When H.A.R.L.I.E. was one" by David Gerrold seems very relevant to where this has been going.

18,000 stacked feet of printout for the board members to read in preparation for the upcoming board-meeting detailed the proposal for how "Human Analogue Robot Logic Induction Engine" could be useful (thus shouldn't have its plug pulled) by programming faster/better than human programmers predictive programs taking into account every verifiable fact ever verified, basically. (And of course proceeding on from that to every verifiable fact that ever will be verified, when it will be verified, who by, and what would that cause, etc etc the usual.)

Was there a "catch"? Read the novel and see...

-MarkM-

My Open Transactions server is only in "alpha testing" phase. The momeny a third party tried to inport a contract, connect, and use the thing we found glaring awful gotcha that had hardly been noticed by people testing only on machines they set up and doing their copy-paste routines themselves using habitual details of how the habitually perform such operations. (Do you usually copy/paste that the file's last line of text ends, or do you prefer to make sure you only copy-paste up to but not including the end of the last line (the invisible end, not the last non-whitespace character...)

All is currently waiting for release of a whitespace fix that hopefully will prevent different people's customs of how files end versus how/whether the last line of text in the file ever ends and whether the file starts with the first non-whitespace or may contain some initial whitespace.

This tiny detail can cause every contract-ID you compute do be different from the contract-ID everyone else out there computes.

I might have to discover a completely different ID for DigiI0coins, thus making all accounts that used to be about such coins to no longer be about the new "real correct" ID-identified DigiI0coins and so on.

Very alpha. Not quite the first time anyone tried using a client on one machine to talk to a server on a completely other machine out over the real internet, but possibly the first, probably among the first, test of completely different people trying to get one's client to work across the internet with someone else's server.

The test has shown that Open Transactions really does look good for the proposed tasks, we do right away though have to fix this ghastly stupid little whitespace gotcha to protect against different habits of copy-paste users so we can have everyone actually agree as to what the ID of a given contract should be / correctly is.


As to the initial distribution and the inflation due to minting not being complete yet stuff, my big problem all along with these alternates, and with BTC itself too, is the whole "lets not back them at all" approach.

I am going to try to convince the folks who wanted their own chains, such as GMC, GRF, UKB, CZB, NKL, etc etc etc, to just use Open Transactions for now to issue DigiGMC, DigiGRF, DigiUKB DigiCZB etc etc etc so as to get the currency into use in spite of blockchain vulnerability of low hash power chains problems and to get the value their coins/currency is to represent as widely distributed as possible so that come a day when they do go to a blockchain format/implementation they will already have people/entities to distribute the initial coins to and how much to distribute to each, They will thus be able to simply mint all their coins in the first or second block, distribute them in accordance with how many Digitokens representing their eventual coins various entities have, and presto, initial distribution is already solved before even creating the genesis block and before even solving how to merge mine all these many many alternate chains, *and* meanwhile they can actually *back* their currency since they need not worry that huge mining comglomerates willturn in millions of them foor redemption without having provided anything with which to back them aka something to redeem them *with*.

For i0coins, this could mean that DigiI0coins might be free to become more valuable than "actual I0coins"...

...Like so: I only have maybe about 7000 "actual I0coins" that are old enough most clients checkpoints would fail if my coins were somehow caused to appear to be in an orphaned part of the blockchain.

So I can only "safely" issue about 7000 DigiI0coins.

Could competition to have some of that limited number of DigiI0coins that will be available to trade on the exchange drive up the value of such DIgicoins? Not sure, but in theory/principle maybe it could...

-MarkM-

Didn't the Soviets have laws about what people are allowed to buy with Rubles, maybe even what goods and services one is allowed to offer to people in Soviet territory and/or in return for Rubles?

How swimmingly did that work out?

What does the U.S. tell itself as it emulates such wonderful Soviet traditions?

"we are preserving what was actually good about that system" ?

-MarkM-