I just tried it. Didn't help.

I did a cat of the (very small) block data file, and it looked like it maybe even consists of only the genesis block.

Unthinkingbit, might it be that, as I long ago worried when initially making the genesis block then not mining constantly thereafter, some kind of check of how long has elapsed between blocks might be rejecting the very first block after the genesis block due to we waited too long to actually start adding blocks to it?

It didn't used to be a problem, it seemed you could create a genesis block then go weeks without mining, but maybe something in the time travel exploit fixes or something is nowadays a lot less forgiving of the whole chain having not been mined for too long or something?

I recall with groupcoin this was part of my argument why we should keep mining steadily; I was always concerned that it is a bit silly to have a genesis block claiming we started on a certain date then not actually start until days or even weeks later.

Could the delay between creating genesis block and actually starting to mine for real be biting us on the backside now?

-MarkM-

EDIT: It has got to be a bug in the -qt version, something not the same, probably in last change/update, as what I put into the devcoind, because if I simply change devcoin-qt to devcoind in same shell script and run it, presto I get good blocks, it starts getting the blockchain.

So I guess I need to go back into PMs to find the changes I was told to make for latest release and check I did them exactly the same way in the -qt as in the devcoind, which presumably/probably I did not. I must have missed something or typo'd something or somesuch. The -qt is broken, the devcoind is not.

Did you try adding the IPs of the three amazon-based nodes as my shell script does as I mentioned earlier?

Unthinkingbit had me add al lthe receiver files to the realse thinking that woudl fix some problem windows people were having but maybe that doesn't actually fix their problem... Oh wait, you tried Ubunto too. Hmm. I guess I should try starting from scratch under a different user than the one that normally runs the thing... Annoying having to use only one machine nowadays (landlord didn't like electric bill), I'll have to stop mining to try this.

Hmm, it got a bunch of orphan blocks then end connection.

Unthinkingbit, could it be that somehow the changes for various adaptations of difficulty and so on have somehow get it to the point where the early part of the blockchain is no longer able to compute as valid anymore or something like that?

-MarkM-

I am not sure a p2p stock exchange makes a lot of sense unless there first exist p2p entities whose stocks would be traded.

Otherwise you basically just have a smokescreen p2p system potentially causing customers to forget that ultimately the stocks they are buying are centralised entities they still ultimately have to trust.

Since ultimately it is the specific entites issuing shares that you have to resort to to get your share of whatever it is the shares are of, and whom you have to depend on to issue any dividends that might get paid, this whole p2p overlay on top of it seems like potentially jsut another clever scam/smokescreen allowing issuers to pretty much do like bitcoin itself did: issue tokens they have no intention of actually backing but that might nonetheless get seen as having some value due to there being plenty of suckers out there who will in-effect "back it" by buying it.

It will be like hey, mining costs more than issuing a bunch of shares does, so instead of mining a bunch of whatever kind of coins (bitcoins, scamcoins, whatever) lets just issue a bunch of shares. In either case we have no intention of backing them, perish forbid. Any value they end up having will be from other people buying them. All we do is mine them (or in this case, issue them, even less work than mining maybe) and put them out there for suckers to buy.

So maybe a distributed p2p corporation system would be a good foundation, so that we have actual p2p entities whose shares we could then worry about issuing.

Maybe that would be quite a similar system but start with the assumption that the whole system itself is one p2p corporation, and the shares offered are shares of itself. Then instead of arbitrary non-p2p entities issuing shares just because they decide to, there could be a whole voting process on whether the system as a whole even wants to risk sullying its repution by entertaining the notion of handling company X's proposed shares. Do a majority of the token-holders think the company applying to do an IPO with us is legit? Is it a business of a kind we wish to be associated with? Are our armed forces or police or whatever in a position to seize their assets if they default on something? Whatever the criteria, at least a basic vote by the shareholders (token holders?) of the exchange system itself might be appropriate before willy-nilly becoming an accomplice to the latest new Enron scam by agreeing to do the new Enron's IPO on our network?

-MarkM-

I still do not understand how a client checks the validy of a block that claims to be validaded by some block mined on some other chain, using merged mining.

For example suppose someone uses bitcoin or namecoin as parent to merged mine, maybe namecoin as parent due to they are already using bitcoin as the parent for the namecoin.

My I0Coin client downloads a block that is not valid by normal standards, instead claiming that some other chain has a block that proves work was done.

How will my client even know how to get access to the parent chain? Chances are if I have a copy of that chain at all I have it under another username so that this chain's software cannot mess around with the other chain's wallet.

So how is the validation even possible?

-MarkM-

Is something wrong with DevTome.org's outgoing email?

I signed up there figuring I could put some stuff on the wiki, but have not received the confirmation email and don't seem able to edit pages, which might be because my email has not yet been confirmed...

-MarkM-

If someone does use IXcoin as "an auxilliary" chain to mine, how can clients validate the blocks?

For example suppose one day I decide to use IXcoin as auxilliary and GRPcoin as main.

Next day I figure okay, that seemed to work, today I'll use DEVcoin as the parent chain.

Meanwhile someone else has been using Namecoin as parent chain.

When someone's client wants to determine for itself whether a block is valid, how does it even know which chain the miner chose to use as parent chain for that block, let alone how to find a blockchain of whatever chain it happened to be, and how to find the proof in that parent chain?

-MarkM-

Mine is currently in alpha testing, see https://bitcointalk.org/index.php?topic=53329.0

No fiat currencies, it is only about digital stuff, not just blockchain based coins but also game units of account, commodities, real estate, whatever.

The fact that some or even most of the blockchain-based coins have places elsehwere that offer to change them into various kinds of fiat is an externality, dealing with fiat is a pain that I prefer to try to avoid.

-MarkM-

I am using Open Transactions myself. S0 far it does not include voting nor automated sharing out of dividends but those on the roadmap and meanwhile it seems it ought to work fine for "preferred shares" type of shares (no vote, no necessity for dividends).

As work on the libraries continued though, voting and dividends will presumably be implemented somewhere along the line.

It is not p2p though.

-MarkM-

Must these secure exchanges happen using p2p only?

-MarkM-

The vote tickets could be blinded cash, so the issuer can tick off that a ticket has been used to prevent its being re-used but cannot tell which issued ticket it was that just got ticked off.

Thinking about Laws of Form's representation where the default/empty space is take as or, compared to your NOT and AND system (NAND), I wonder if your representation would basically have space be taken as AND.

A possible advantage of OR over AND might be that if the nearby data for the OR is true, you don't care about the far away part, you can proceed in the knowledge that regardless of what the far away part says, the OR evaluates to TRUE, so you can go ahead without waiting to hear what the actual value of the far away part is.

With AND, if your nearby data input for it is FALSE you know the whole thing is FALSE, but unless your goal is to pursue falseness in preference to pursuing truth, that might not be as useful as being able to proceed on the basis of TRUTH.

That might end up with everyone having to pose all important questions to your universal machine in terms that make FALSE be the important result they are hoping for / pursuing.

Basically just a semantic thing but I think aesthetically a system designed to optimise the pursuit of truth might sound more appealing than a system that optimises the pursuit of falseness?

Hey, maybe run two universal turing machines, one built the Laws of Form way to pursue truth, another built your way to check the results / error-correct by pursuing falseness?

Maybe its all just semantic, afterall one could just reverse true and false any time one displays values/results to humans? Hmm...

Maybe space taken as OR and space taken as AND differ in "timelike versus spacelike" way(s)?

-MarkM-

It was a mishmash'd mess, first I did fork iaanw's "bitcoin-qt", but then after downloading Unthinkingbit's stant on groupcoin or devcoin I basically ended up working from a downloaded, not forked or even pulled, version of bitcoin each time I started making a newer version of all the various alt chains I was working on.

For britcoin, botcoin, canadian digital notes, czech bitcash etc etc I pretty much remembered the few places on needed to change to make them from a normal bitcoin with minimal necessary hacks.

As I would start from latest fresh fixed bitcoin each time, I kept the hacks to a minimum, so one would even compile them as bitcoind then just change the name of the binary and tell it on the commandline what datadir and config file name to use (even those I didn't change in the code).

Groupcoin I am a little less sure what changes ended up in it.

Devcoin even more so, it has a whole header file of stuff only it uses, and hacks all over the place to change the magnitude of the default fees and so on. Each change made in bitcoin to make devcoind would have to be repeated in bitcoin-qt to make devcoin-qt, plus the devcoin-qt also tries to actually say devcoin in any user-visible places where it used to say bitcoin.

Now that bitcoin pretty much *is* bitcoin-qt instead of having all that nasty xwidgets stuff in it, hopefully there won't be need next time to duplicate the changes in two different things. And this time make a context diff or something so we know exactly what all the changes in total actually are.

Doing a diff of devcoind against a bitcoind source from back in the era it came from and also doing a diff of devcoin-qt against a bitcoint-qt from just before bitcoiin itself assimilated the -qt stuff should hopefully get a pretty good idea of what changes are the core devcoin stuff that went into both to turn them into devcoin versions. The -qt side will also have bunch of "cosmetic" changes chainging names that user sees, and also has stuff to turn off mining as the qthreads just would not let us mine it seemed.

Having another set of eyes do such diffs is probably a good idea anyway, in case somewhere along the line I managed to put something into just one of them that belongs in both.

I should probably delete the *coin repos I have under knotwork name on github, I don't use them and at I think one of them was Unthinkingbit's old original start towards trying to make a groupcoin or devcoin so isn't even really what its name would seem to imply it to be. Or maybe that was the one under his name and I used it straight from his repo not from any copy under my name. I think basically when I really made a release I used real bitcoin-qt from its author and real bitcoin from gavin, not any repo under my name or Unthinkingbit's.

I didn't learn until much later that with github one is expected to make a fork on their end to have something to push to, even when I did try clone instead of just downloading entire tarball I still used to just clone directly from author's repo thus later learn I could not push, any commit I did would be purely local to my own local machine.

Thus I gave up on pulling and just grabbed full tarball of what I wanted to work from.

I think I now have better idea how github is intended to be used / to work. But now one no longer needs two projects, one for the daemon and one for the -qt, presumably, if one starts from the latest bitcoin.

So maybe the thing to do is delete or ignore all the *coin repos from under my name on github, fork latest bitcoin, and start putting into it all the changes that are the same in both the daemon and the -qt version of the devcoin releases.

As I recall one problem I had with github is I did not see a way to tell it that I want to fork bitcoin BUT NAME THE FORK DEVCOIN.

I think at least one of the *coin repos under my name are misleading because of that, the name came from what I was using as original code from which to hack what I wanted to make. I never did find how to change its name so now cannot even remember which one that was. SO they all should go, I don't currently see offhand any potential use for them.

I now am down to just one machine, one of the 64bit Fedora 15 ones. The only bitcoin source I see on it is bitcoin-bitcoin-v0.3.24-0-gf087364.tar.gz so hopefully that is the one I last used as base from which to make the last set of updated altcoins.

Hmm on the other hand look at the dates:

drwxrwxr-x.  7 root root     4096 Jul  8 14:38 bitcoin-bitcoin-36aa6bd
-rw-r--r--.  1 root root   730076 Jul 20 04:47 bitcoin-bitcoin-v0.3.24-0-gf087364.tar.gz

Looks like maybe I actually used 36aa6bd, then later downloaded the gf087364 but didn't even untar it.

-MarkM-

It can already be done using the namecoin blockchain quite likely, since all you need from the blockchain is a way of owning names.

For example to issue shares you could just find a name that is still available, grab that name to use as name for the overall project the shares are to be associated, then grab names with -000 -001 -002 etc appended to that name to use as individual shares, which you'd then offer for sale.

-MarkM-

I wonder if maybe it is cycling from one person who has no incoming port to another or something?

You claimed it had three connections, are those incoming connections from people reaching out to it or does it have no incoming port through its firewall this maybe is connected to possibly the only three out there that do have an incoming port?

I wonder if there is some mode where it can claim to have a connection but the connection is in some sense not really working or maybe isn't even to a devcoin node.

Does the debug.log offer any hints? Usually that will show if attempts to connect are failing and stuff like that.

I notice I have

   -addnode=50.19.210.139 -addnode=107.20.209.11 \
   -addnode=107.20.228.112 \

in my startup shell-script, those are probably the three nodes someone set up on amazon virtual machines.

Are those the three connections you have, I wonder?

Maybe try putting them with -addnode like I do to make sure it tried them, see if that helps?

-MarkM-

I get the impression we are intended to deduce that even if iCoin, gCoin, PepsiCoin and so on are created identical to Bitcoin in all things other than who signed their genesis block and when, they will take off better than Bitcoin if only because they are more-famous brands than the bitcoin brand.

-MarkM-

Note that we deliberately made devcoin addresses look exactly like bitcoin addresses precisely so that you can use an address that is generated on a BITCOIN you run yourself if you don't yet run devcoin yourself. Then some day if/when you ever do get into devcoin, you can export that bitcoin address from your bitcoin wallet, import it into a devcoin wallet, and find your bounty devcoins waiting for you in the devcoin blockchain.

-MarkM-

THIRD PARTY ADDRESSES SHOULD NOT BE USED AS BENEFICIARY ADDRESSES IN THE DEVCOIN SYSTEM.

(THIRD PARTY AS IN WALLET SERVICE, EXCHANGE, ETC; ANY WALLET BELONGING TO SOMEONE OTHER THAN THE BENEFICIARY.)

Not only does it actually cause the coins generated to go to some third party who might or might not actually end up giving them to the person we are really trying to benefactor, but also apparently some problems can arise when/if the third party actually tries to figure out which of the addresses the account named "" (the default account; the account that creates new addresses for newly minted coins to be sent to) should properly belong to some other account based on the theory that different accounts in the wallet belong to different people.

-MarkM-

Just because some currencies my server supports are fictional doesn't make the ability to buy them using bitcoins any less real than if someone bought any other product or service using real bitcoins.

Furthermore NMC, I0C, IXC, and DVC, even if none or only some of the others so far supported, do not think of themselves as not being real world. They are real world blockchains, tracking real world tokens, which real world people can control by use of real world cryptographic keys.

Sure there can be a slippery slope of amount of real-ness, with bitcoins being easier to cash out to fiat currencies at various exchanges while some of the other supported tokens have no direct cash-out to fiat currencies, but that is itself a real world thing as it is legal and political aspects of the real world that require some things to be farther from direct cashability into fiat than others.

I would like to think that this current alpha test is an alpha test of real world applicability of Open Transactions, in fact. It would be a pity if politics/law prevents real world applicability and even more so if it prevents even mere testing-for-real of whether it is in fact real world applicable.

GPG apparently ships with 4096 bit key capability so it seems that gimping it down to only 1024 bits or even 2048 bits out of fear of some legal/political attempt to prevent real world application of 4096 bit encryption might be a bit of "living in the past". Testing some gimped-down pretend/play version of the thing maybe isn't really a valid test of real world applicability if in the real world 1024 or 2048 bits are no longer considered sufficient bits for real world applications.

Allowing exchanges even just between DVC and BTC should be a real world application. How is it not?

-MarkM-

EDIT: Maybe for the real world we should structure things such that our customer is the signer of the signed nym that that customer uses to prove to us a nym is one of their nyms. That way there can be a separation of powers between  a customer-knower agency that is our customer and the server, which does not need to know the customer-knowers private data about who its own customers are.

As long as we know who signed the certificate/nym, we can direct any enquiries as to on whose behalf that nym does its thing. From our perspective, it does it on their behalf.

TL;DR: If open transactions is a gamechanging advantage, already-established Gox,Hill etc will use it themselves.


I suspect that politics probably trumps technology, and politics plus mailing-list / members list (established userbase; "goodwill") trumps entry into established market.

I thought hey maybe we can set up a fundraising vehicle akin to an Initial Public Offering. But private of course as a public offering would be huge can of worms requiring a huge private offering first anyway just to raise enough funds for the public offering.

We raise the $100,000 or $2,000,000 or whatever it costs to get a license.

I believe Brian Marsden looked into licenses and found really its almost impossible to get a banking license from scratch, you basically have to buy a bank. He proposed to buy one for some $2,000,000 or so if I recall correctly, that is the asshat I pulled the above 2M figure out of. The $100,000 figure is one I heard thrown around when looking into getting a casino license in some offshore place that is a kind of online-casino-mill or something. Though maybe, it was thought, some folk had gotten one for only $50,000.

Meanwhile, are MtGox and TradeHill already licensed in some jurisdiction?

Wouldn't Open Transactions work on their hardware like on anyone else's?

Oh and I wonder if people have to go through the whole applying for pardons process to get all their childhood parking tickets and weed pecadillos removed from their records before they could get a license at any price?

So lets say finally we manage to pay all the bribes aka fees to actually get a license, why would anyone use the new startup, except maybe the people who put up the money to have jumping through hoops wheels properly greased?

This is so pathetic/stupid because it should simply be a standard *nix service, every system able to process transactions just like every system has open office on it.

(I do notice though, that open office doesn't seem to include what I guess must differentiate a mere office from an actual business, the normal business suite like General Ledger, Inventory, Payroll that I guess means we still need an Open Business suite of tools. All part of a conspiracy to keep people out of business or what?)

-MarkM-

EDIT I have an idea for "know your customer" that will be far far easier (politically) to set up and test for game nations than for real nations, in fact it will reject most real nations due to their not providing sufficient "know your sovereign nations" signature-trails proving that a particular server or customer acknowledges them to be sovereign - "over" them or even at all.

Each nation would have Signature of the Realm signing-nym. It would be signed by that of each nation that recognises them as sovereign.

That way a server can configure which national signature it operates under, and reject customers whose identity is signed by nations not recognised as sovereign by the nation the server recognises as sovereign and actually operates under the aegis of.

Each nation would retain its ability to deploy sock puppets aka secret agents by fabricating false identities, which, I would not be surprised to learn, might well be an important to them part of the whole know your customer thing. They won't want us to know their fake identity secret agents as not being as real as anyone else.

So we'd then have a trail back from each 'nym to some entity we recognise as sovereign, which could of course be ourself, it is up to us who or what we choose to regard as sovereign afterall. But the functionality would enable us to provide KYC trails for any nation that actually registers a signature of the realm for us to check potential customers against.

How micro do you mean by microtransactions?

Coins that are worth a thousanth of a bitcoin or less are pretty micro aren't they, and their fees tend to be a small fraction of a coin, so compared to bitcoin they are ridiculously micro. (Doesn't apply to DeVCoin, its fee was bmped up proportional to its coin precisely because it planned on being only a thousandth of a bitcoin yet still hoped to discourage spamming.)

So maybe just use a micro-value coin type?

-MarkM-

It looks like hardly anyone uses GRouPcoins lately, maybe they would suit your needs?

-MarkM-