The old ANN thread for HORIZON (HZ) was https://bitcointalk.org/index.php?topic=823785.0 but it was locked.

As of this writing HZ is not listed on any exchanges as far as I know.

However the HORIZON network is still working and still in use, in particular it is in use by the Galactic Milieu.

As well as this new ANN thread, a Discussion thread for HORIZON (HZ) has been created at https://bitcointalk.org/index.php?topic=2197970

There are a few little glitches that have been discovered in the course of actually using HORIZON, those and the fixing of them will be discussed in the discussion thread.

In particular it has been observed that after creating a few currencies it became impossible to create the remaining items the Milieu needed as currencies so it was necessary to create them in the form of assets instead.

Then when we attempted to transfer some quantities of assets using the eight decimals the assets had been defined as having, it was discovered that the system did not recognise the values as numbers; it turns out that somehow the client ignores or changes the locale you run it under and wants a comma instead of a period as decimal-separator.

Please do not clutter this thread with posts about such things, the discussion thread has been created for that purpose.

I see the old announcement thread has been vandalised as well as locked; so you might want to join my site http://LFM.knotwork.com/ for links and/or downloads of the coin clients and servers I actually use, including the HORIZON that I am actually using.

-MarkM-

It may seem strange to list the Galactic Milieu under Micro Earnings since serious players deal in such large amounts of goods assets and currencies, but as long as we are still able to allow free signups through at least one of the "rabbitholes" that lead into the Milieu Micro Earnings will continue to be possible.

We build the Galactic Milieu from existing free open source software, but of course most existing systems tend to give starting players various startup gear, which in a reasonable economy has to come from somewhere.

Of course anything a player starts with has some value, even if small, so as long as we allow any free rabbitholes into the Milieu we are giving stuff away, even if that stuff consists only of the meat, organs and so on that a butcher can chop the player's character up into.

Thus even if we started new characters naked there would be "micro earnings" available even if only by killing starting characters, butchering them for their organs and such, and selling the parts of them to butcher shops or necromancers or whatever.

As it is, we are currently still allowing people to sign up free at our "CrossCiv" Crossfire RPG server, and even still have new characters start out with some gear.

If the ability to start new player-accounts and characters free is abused, of course, we will have to start charging if only to limit the amount of "spamming" of player-accounts and characters.

But as of this writing, the rabbithole known as CrossCiv is still open to free players.

Historically the integration of cryptocurrencies and fiat currencies has been through guilds, associations, clans and such (groups), with the provision of such services by the guild (or clan, etc) officers being a large part of why people join such groups. There has even been some work done on adding coin daemon access to the bartender NPCs in guild/clan/etc houses.

Recently we have created a currency, CCAMB to implement the trading of Amberium on the Horizon (NHZ) platform. Depending on how well that goes, we might also implement such a currency or asset on other such platforms (Burst? Next? Etc).

For years now we have maintained online tables of conversion rates between a number of the currencies and assets commonly used in the Milieu at http://galaxies.mygamesonline.org/digitalisassets.html but CCAMB is the first time we have attempted to integrate the built-in currency of the Crossfire RPG system into a trading platform. Bailing coins into and out of the system will, at least initially, be handled by guild/clan/etc (group) officers, so if you wish to move Amberium between the CrossCiv server and the Horizon platform you will for now continue to use your guild/clan/etc connections, affiliations, alliances etc just as you already do for various other financial services.

-MarkM-

A long time ago the page http://devtome.com/doku.php?id=hzcorp_prelaunch was created noting various ideas toward the implementation of a "Horizon Corp", HZCorp.

Over the last few days actual implementation has been ongoing, so just now I have updated the page to reflect progress.

Horizon Corp is the vehicle created by General Financial Corp to help organise the proposed migration or issuance of assets implemented on the Digitalis Open Transactions server to the Horizon platform.

-MarkM-

AXON is a re-named clone of AXIOM with default ports one port-number higher and one of the four "magic bytes" changed to prevent it connecting to AXIOM instances.

It has been created because a catastrophic fork happened in the AXIOM chain, leaving the players of the Galactic Milieu on a different fork that the one used by the only exchange that is not itself inside of the Milieu.

Thus the banks markets etc in the Milieu can go ahead using AXON where they had been using AXIOM and their accounting will still be in synch with the actual blockchain.

Otherwise they would have faced catastrophe.


AXON is at https://github.com/knotwork/axon


The addnode to use to synch blockchain with it is dvcstable01.dvcnode.org

Use your existing AXIOM wallets, and, if the fork of the AXIOM blockchain you are currently on is NOT the one used by Yobit exchange, you might actually already be on this chain but of course you are calling it axiom. If that is the case copying your .axiom directory over to the new name .axon would work fine, you'd be still on the same fork but be using the new name for it. If that works, you would then do a re-synch of axiom rather than of axon, as your task would be to get in synch with Yobit's fork of the axiom chain.

-MarkM-

See http://devtome.com/doku.php?id=hzcorp_prelaunch

-MarkM-

It constantly shocks me how many people hereabouts confuse "liquidity" with "volume".

VOLUME is transactions taking place, which in the case of each transaction means some LIQUIDITY was destroyed by the transaction.

LIQUIDITY is how much volume you COULD do IF you chose to. Each time someone chooses to, they burn up LIQUIDITY.


For example suppose you see a billion coins for sale at 4 satoshis, and an order to buy a billion coins at 3 satoshis.

That is a billion coins of liquidity in each direction, a billion coins you could buy or sell without moving the price.

If the volume is a billion coins bought/sold per day though, all that liquidity could evapourate in a day!

If the colume averages typically only a hundred coins per day though, a billion coins buyable or sellable is many many days wroth of liquidity, not some tiny little amount of liquidity that tycpialy could be gone overnight!


TL;DR volume is anti-liquidity, because each coin of volume consumes a coin of liquidity. Liquidity is how many coins you COULD buy or sell, not how many someone already did buy or sell.


Volume is the past, liquidity is the potential future. As one is supposed to constantly repeat in the invsting/forex field, past performance (volume) is no guarantee of futire performance (liquidity).

Liquidity is good, it says how many coins you could easily buy or sell without making major moves of price.

Volume can be bad, it says how much competition you have in your attempt to get in a buy or sell before the price moves.

Ideal, except if you are the exchange thus hope to gain fees on volume, is huge liquidity with tiny volume. That can mean a very stable price, so you can be surer that the price you see today will still apply some days down the line. It means huge volume could happen if anyone chose to move coins, but currently the price is so spot-on perfect that no-one sees any need to actually move any coins.

With huge liquidity compared to volume, banks can list conversion rates with some confidence, gas stations can list how much of one currency they accept in lieu of another (like stations close to the U.S. border are wont to do for USD and CDN), stores can quote prices in both currencies more easily and so on.

-MarkM-

Custmarily when I post offers on an exchange I do so "in depth", such as buy 100 at each satoshi of price from this price up or down; or 100 at each 5 satoshis of price from this price up or down.

So far I have not looked into many of the "distributed exhange" systems but what I have been seeing is I can place just one offer, at one price.

I think it might even cost me a fee to place the offer, which makes the custom of placing hundreds or thousands of offers somewhat un-feasible.

So I guess what I am looking for is no fee to place an offer, so I can place thousands of offers, or if there must be a fee to place an offer than a distributed offer, distributed over a range of prices at X number of coins per price, placed Y distance apart in price...

Do any of the distrubuted exchanges meet these needs?

-MarkM-

I noticed some FPGAs now had ability to mine Blake256, so thought I should check whether Klondike boards can do that yet?

-MarkM-

The Galactic Milieu seems to be facing a large platform-migration problem thanks to the fact that Open Transactions did eventually get around to making breaking changes in how it does things.

These changes in Open Transactions mean that all contracts (including server contracts and asset contracts), accounts and pseudonyms ("users") that we have been using for years are not going to work in the new version(s) of Open Transactions.

So it all has to migrate, even if sticking with Open Transactions.

Thus this seems like a good time to re-think whether in fact Open Transactions remains the ideal platform for our needs.

As you can see from the various links at http://galaxies.mygamesonline.org/digitalisassets.html there are a number of assets involved.

Those links show much of the relative-price history of the assets but luckily one of the features of Open Transactions is that it does not need history.

Once both parties to a transaction, and the notary server (Open Transactions server) sign off on a transaction, the past is no longer needed as all relevant parties have agreed, bindingly, upon the new balances involved. That is great for games because really, in games all we care about is what is in our pockets, not how long it has been there, who put it there, or why they put it there. (Nor even whether it is proceeds of crime, afterall some characters are probably intentionally criminals, thieves, etc, so what, what is in their pockets is in their pockets. ) Keeping years of historical records of who gave what to who is just not really very useful or relevant in games, and indeed could be undesirable.

One key feature of Open Transactions is that your balance cannot be changed unless you sign off on the change. Thus for any change of balance there is a signed, notarised receipt proving (cryptographically) that you agreed to the resulting balance. So basically, the players and the game-master agree, so what else matters, in a game?

Another nice feature is scaled markets. Markets exist not only by asset-pair but also by scale, so you can have egg markets for trading single eggs, hundred-egg-markets for trading boxes/bundles of 100 eggs, and so on. This is great for issuing large chunks of currency/assets to nations, megacorporations and other whales while leaving room for smaller scale asset/currency merchants to re-sell at retail prices to smaller folk.

(Like, you can offer blocks of 100,000 of a coin on a 100,000 scale market, at prices that allow your customers to re-sell each block of 100,000 they buy from you as blocks of 10,000 coins at a higher markup to their own customers.)

I have taken an initial look at Bitshares, NXT, NHZ (Horizon), but I expect I am missing other similar systems as once the annoucements got split off from the main altcoin discussion section I only recently got around to taking a look into the announcements section. (It moves so incredibly fast due to spammers bumping their coin ass a marketing technique that even if I had tried to follow that section I would have been constantly missing things as they popped to the top and got scrolled off the bottom so fast I missed their rise and fall...)

-MarkM-

NOTE: Also up for discussion is cloning something instead of using its existing network, such as making yet another NXT-clone to run this stuff instead of just putting it on an existing NXT-or-NXT-clone network.

NOTE2: Horizon looks interesting because all players/nations/guilds/etc who wish to could fire up nodes right now to start getting free NHZ to eventually use to pay transaction fees with for transacting on that network, so it could maybe be used as is instead of making our own clone network.)

How are folks mining altcoins that have block versions beyond the version numbers used by Bitcoin so far?

I just built cpuminer for example and its minerd program chokes on a coin thatminerd claims has a block version of 6.

I believe the block version 6 might be something to do with proof of stake? Some hybrid proof of work / proof of stake coins use that version number for their blocks?

What do people use to CPU-mine such coins?

(Please, no "the difficulty is too high for CPU mining" claims, not every such coin stays popular enough to keep ASIC and/or GPU folk mining it forever, and I am looking into purportedly-dead coins here so... )

(Also, authors of bitcoin miners are often, it seems, against alt-coins, so I will not be surprised if when I set up GPUs I find GPU mining programs have the same problem; I have no GPU machines running right now and have no scrypt ASICs and this particular coin happens to be scrypt so I cannot check whether ASIC-mining programs also have the same problem...)

-MarkM-

I have been finding my ancient wallets left over from trying out various altcoins over the years, building the corresponding altcoins and getting up to date with their blockchains to access any coins those wallets might contain.

This went fine until I happened upon a wallet that crashed the coin daemon, asking for a database recovery to be done.

db_recover utility for BDB wants you to have a log not just the database (wallet) itself, so that was no good.

So I grabbed pywallet, a newer version of it said to be better than the older one someone else had on github.

Doing just a dump of the wallet using pywallet resulted in huge private keys with long strings of FFFFFFFF in them.

So I tried pywallet's recover routine, as it can work on a file not just on disk drive. (It is intended for scouring a disk or part of a disk trying to recover keys from deleted wallets).

The problem I have now is that the recover routine will not let me give no password to the wallet it creates to put the recovered keys into.

It made me a file with 207 recovered keys in it, but I had to tell it a password to use to encrypt that wallet, so it is an encrypted wallet.

I did mention I am talking about ancient coins, right? Right. Well guess what, some ancient coins do not have encrypted wallet capability even in their latest incarnations.

So the coin daemon cannot use this nice shiny new, but encrypted, wallet.

I asked pywallet to dump the wallet, I even told it the password, but instead of dumping un-encrypted keys the dump has all the private keys encrypted. It told me at the top of the dump that the password was correct, if I tell it a wrong password it tells me it is incorrect. So it does know how to decrypt the keys, heck it probably decrypts them (or at least one of them) to check whether or not the password I give is correct. But the damn dump does not dump decrypted keys.

So I am still trying to find out how the heck to import the damn keys or, probably simplest really, decrypt the damn wallet and leave it decrypted.

I had to tell pywallet the exact address-version the coin in question uses to get it to do things right, so it does not seem likely I could just load it with some other coin deamon entirely, one that does support wallet encryption, then tell that to decrypt the thing.

(A brief look toward that idea actually leads me to think maybe the coins that do support wallet encryption do not offer a decryption option to turn them back into decrypted wallets anyway, so even if I convert the whole thing over to some other coin's address version byte style I maybe still could not use some more modern coin-daemon to decrypt the damn thing.)

Any insights/ideas/solutions?

(Hopefuly something faster than reverse-engineering pywallet to figure out how to hack it to allow not encrypting the recovered-keys wallet it creates. )

-MarkM-

BTER's scripts (they are used elsewhere also so this might apply to any exchange using those scripts) seem to be broken.

It will not let me cancel my highball sell orders.

The tables where it purports to be showing me my active orders only shows four of my sell orders, and those are the lowest ones, which are not the ones I want to cancel because, who knows, maybe someone might actually take me up on some of them.

But I spent a lot of tiem yesterday placing orders way way up high, step by step, and the pale blue shading on the order book that indicates prices at which at least part of the order is your own shows many of my orders must still be active, although that table too only shows some of them, maybe about halfway up through the range of orders that I placed.

Now I wanted to cancel a few of my highest sell-orders but they do not even appear on the list of active orders.

Is this just a temporary glitch or is that script "broken by design" or what?

I think the active orders list might also not be showing all of my buy orders either. It only shows four of my sell orders and the rest of what it shows are buy orders, but it is not showing many orders at all so I suspect quite likely the buy orders that it does show are only a few of what I actually placed.

-MarkM-

Either Vircurex's display of chain hashpower and difficulty is broken or they have decided to jioin the ranks of the scam-exchanges who sell garbage that has such pathetically tiny difficulty and hashpower that it is basically just a freebie give-away for anyone with a handful of banks of Jupiters block-eruptors to PWN.

How is a coin that doesn't even have a few hundred millions of difficulty, heck doesn't even have a few tens of millions of difficulty, not automatically de-listed as too vulnerable to remain on an exchange

WTF, once upon a time Vircurex seemed like it might actually be taking its business seriously, but if the figures it is showing for the difficulty and hashpower of the brand new scamcoin "DOGE" that they just listed today we'd better take all our money out of there since they obviously no longer care about security. Is there much likelihood at all that any of the coins they think they have in their wallet will still be there once the people trading DOGE to BTC and taking the BTC home with them release their alternative blockchain?

-MarkM-

I just got an email from a totally blind person, congratulating me (as the person he found by doing WHOIS lookup of devcoin.org) on the accessibility of the DeVCoin client.

as I have tried a large number of crypto coin
wallets and found they will not work at all with my screen reading program
on my computer.

So hmm, maybe the ancient code that we used to build DeVCoin has something going for it that newer code has lost?

Maybe I can get him into this thread to clarify so we can compare specific clients to find where they went wrong, and try to update latest bitcoin code to be more accessible if the latest bitcoin client is one of the ones he has trouble with...

-MarkM-

As you may be aware, Ixcoin is an experiment to see what will happen when no more coins are minted.

Unfortunately it is a "sudden death" experiment: Ixcoin will go on minting 96 coins per block until, one day in the not so far away future, suddenly there will be no coins minted per block.

That is maybe a little more radical than really necessary since most coins taper off their minting, so that by the time there is no minting at all the number of coins minted has declined over time.

Ixcoin, being a long-established merged-mined coin, has a difficulty that is quite respectable as alt-coin difficulties go, so it would be a pity if the sudden death of minting caused merged mining pools to drop it or miners who merged-mine privately to drop it from their merge.

So it would maybe be a nice idea to try to get some transaction volume going on the coin before minting stops.

The hope would be that if there is some reasonable volume of transactions there will be a corresponding reasonable quantity of transaction fees to entice miners into continuing to include Ixcoin in their merges.

Thus the thought has occurred to me that maybe the "CPU mining" concept could be of some use in this matter.

Hitherto the idea had been that that kind of "CPU mining" would typically be used as a means of distributing coins that either avoided the use of a blockchain (due to the huge expense/security problems that blockchains involve) or secured their blockchain by some other means. Maybe Ixcoin could be used as an example of a blockchain that is secured by some other means?

In other words, since the Ixcoin blockchain is already secured by means of merged SHA256-based mining, it could serve as a blockchain for the proposed type of "CPU mining" provided that some actual Ixcoins were available for such "CPU mining" to distribute.

The difference between using this kind of "CPU mining" for a new type of coin and using it for an already established coin such as Ixcoin lies, of course, in the fact that Ixcoin has already distributed a lot of its coins and its miners rightfully expect that the remaining coins it will mint up until the sudden death of minting will be distributed to them as usual.

Thus in order for this kind of "CPU mining" to work with Ixcoin, it would be necessary that Ixcoins somehow be available for this proposed kind of "mining" to distribute. That basically means that "mining" operations of the proposed kind are going to need "capital investment" of Ixcoins. That is, a capital sum of Ixcoins that can hopefully be used to establish steady streams of transactions on the Ixcoin blockchain. (As it would be better to use the "capital" to set up sustainable flows than to just spend it directly on transaction fees until it has all een consumed by transaction fees.)

This thus leads to the idea of sustainable "CPU mining" businesses that are able to sustainably conduct and attract fee-paying transactions on the Ixcoin blockchain.

Which in turn leads naturally enough to the idea that a business, in order to be sustainable, ultimately requires customers to "do business with".

Research, experiment and in the field practice of this concept of "CPU mining" so far has tended to lead to designs in which the server expenses are covered by annual account fees; usually these annual fees, the cost to participants of one account on the server, is about one BiTCoin per year. Annual fees have been found to be preferable over using shorter periods not only because of the administrative/book-keeping costs of subscriptions and the renewal of subscriptions increase the faster people have to renew but also because longer minimum subscription periods favour long term participants over "quitters", "tire-kickers" and such and might even also discourage "griefers" from subscribing on impulse just to "grief" other participants.

This Ixcoin proposal though differs from previous work in this field in that Ixcoins are not proposing to distribute "newly minted" coins in this way. With Ixcoin we do not have some vast number of coins being minted that we want or need to distribute. On the contrary, with Ixcoin the minting is going to die a sudden death in the not too distant future. So one may question whether the trivial subscription fees other deployments of "CPU mining" are using would suffice in the case of Ixcoin, by considering whether just those subscription fees alone could possibly provide enough Ixcoins to enable the project to generate enough on the blockchain transaction fees to keep SHA256 miners merged-mining Ixcoins.

Would it be useful to charge much higher subscription fees for accounts on the server than other deployments of this kind of "CPU mining" have thus far been charging, in order to generate more income in Ixcoins?

Or would it be better to incorporate some kind of "capital investment" scheme(s) in addition to subscription fees in order to come up with "enough" Ixcoins?

-MarkM-

Here is a really simple - maybe even "simplistic" - currency-backing bot strategy idea:

Suppose you have a currency, lets call it DeVCoin, for example, that you would like to have some value.

Suppose, further, that you have some kind of revenue-generator also, lets say for example a wiki with adsense ads on it. You could call it something like Devtome, for example.

Suppose even further that you know that 200,000,000 of your currency - lets call that 200 million DVC - is entering the market each month.

Finally, let us suppose that there exists an exchange where you can exchange the type of currency the ads bring in for your currency that you would like to make "valuable".

So, okay, each month you need to be prepared to buy 200 million DVC, so that none of the 200 million coins coming onto the market that month will seem "valueless".

Now we plug in the revenue from our ads. For example suppose your ads bring in, after all operating expenses, fifty somethings. Lets call them dollars, denoted with a $ sign.

Now we have a simple bit of arithmetic we can do: we have $50 available and 200 million DVC that need to be capable of being sold, in case someone turns out to want to sell them.

It would be really nice if the exchange used for this let you place offers that do not have a duration at which they auto-expire, so lets assume that once we place an offer it won't go away unless someone buys it all or we cancel whatever is left of it.

So, we place an order to buy 200 million DVC for $50.

Next month, we can simply do the same again. And just keep on doing so each month.

If we are really lucky, or really good at managing/operating our revenue generator, we might even find that over time we have more and more dollars available each month with which to try to buy the 200 million DVC that are entering the market each month. But if not, no worries, whatever offers we can afford to place will just sit there on the exchange year after year, decade after decade, until either someone does take us up on them or we launch another revenue-generator with which our first revenue-generator can team up to try to make, between them, offers high enough that folks do start taking us up on them. (In which case, maybe, not sure if its worth the bother, we could consider cancelling our old single-revenue-generator-based orders and replacing them with dual-revenue-generator-based orders?)

So far of course that seems like a pretty stupid bot, maybe a bit too simplistic to be practical.

So maybe we do need to make it at least a little bit more complicated.

Suppose, for example, that people snap up all our offers as fast as we make them. Would that be a problem? Surely if we had been doing all this from the original launch of our currency that would mean no one else but us actually has any of our currency, we have bought it all as fast as it was minted. Hmm.

Okay, suppose for some reason - even a really stupid reason - we somehow got butterfingers and allowed some of our currency to slip from our grasp. Like, maybe we paid our hosting bill with some or something like that. Oops, that month there was more than the normal 200 million DVC entering the market! There was 200 million plus our hosting bill!

Can we just plug that new/different "how many enter the market" value in as that month's amount entering the market and go on using the same formula? Simply offer our net revenue of the month in dollars for two million plus our hosting bill DVC on the exchange? Would that work?

-MarkM-

What would be required in order to power up gear - such as, say, USB block eruptors - as and when sufficient power becomes available, and shut down as power fades?

I am thinking that it could be nice to use solar panels for power but save on batteries by being able to use all the power when it is available.

I don't really have the option of hooking up to the power grid because doing so woudl require re-wiring a whole building, which would involve ripping out all the plaster inside so electrician can put wiring in the walls, then putting up gyprock drywall in place of the old antique plaster.

A bunch of gear is supposedly going to be too expensive to run one of these months because of the cost of electricity on the grid, solar using battiers gets pricey too because the batteries cost quite a bit, but I am thinking the old gear could be used to soak up excess power on bright days when the sun is pouring in more electricity than one has enough batteries to store.

Is there some kind of common rack of relays or chips or something one can get that turns things on in sequence as more and more power needs to be used, and back off as less and less power comes in?

-MarkM-

Looking at various sites about the relative profitability of the various coins, aren't they all making a fundamental error?

Isn't my profitability in real life the amount of fiat a given number of watt-hours brings in, minus the fiat cost of those watt-hours and amortised hardware?

It seems to me very likely that for any, many, or most coins that I would have to use a GPU or CPU to mine my profit per watt-hour is way the heck less than if I threw away or sold my GPUs and bought ASICs instead, maybe even block eruptors would be more profitable?

So that I would be better off mining all the merged mined SHA256 coins and using them to buy any other kinds of coins than I would mining those other kinds of coins directly?

-MarkM-

Why a galaxy far far away? (Essay)

I have started to try to clarify my thoughts about the relating of altcoins and other virtual-world currencies to this so-called "planet known as Earth as compared to various other planets, worlds and universes, virtual and otherwise.

As usual since it is a Devtome page please comment on it here or on its talk page, not by hacking at the page itself, despite Devtome happening to be implemented as a wiki.

-MarkM-

I have started an essay on Devtome...

Unlike most wiki sites, Devtome is not really about hacking away at other people's pages, so please to discuss the essay use this thread or its talk page rather than jumping into the essay itself to add your ideas or remove mine etc.

-MarkM-