Topic: . - page 13. (Read 491757 times)

It's: nhzforgingpool.redirectme.net

Seems that Horizon is sleeping.........................

Ring!!!!!  Ring!!!!!  Many coins want give anything to get be listed on POLO. It is there.   

Does anyone know the url for HoizonPool? I'd like to know what fees they charge, etc, and not sure where to find that info.

You should not use nhznode right now, it already has too much mining power and you will do the opposite of securing the network.
Currently a better choice would be HorizonPool (NHZ-3R7E-HK6Z-9AM8-BUP9L)

Best to check the forgers chart on the explorer and select a small pool to spread mining power

Hi community members. If you've got some HZ just lying around and you don't want to forge yourself atpit (at this point in time) then its a good idea to lease your balance to another account. You can still trade with your balance (amount may change during leasing - not a problem) and it stays under your control.

I didn't know who to lease to but inspired by Sakura I have joined her and others in leasing to NHznode to help secure the network.  


EDIT: vvv Oops sorry, I didn't even look at forgers chart. Jeez NHznode is really quite large atm.

Repost ... because it slipped through the thread relatively unnoticed, in rather busy days.

Great service, and also for HZ !

Wow I like this. It's permanent. Thanks. 

Wow, great. My brand new RaspberryPi3 got delivered the other day. ~52 euros for Rpi+SD+prettyTransparentCase. Will be using my (~15 euros) strong AC/DC adapter from my old one; and HDMI cables are usually lying around in your tech box ;-) So for ~750,000 HZ, you can have a 2nd computer, to keep your currencies safer.

Will report what I find out, when I have found the time to try it.

Thanks a LOT for all those explanations.


Good that we discussed this - Because now a concept condensed in me how to solve it:

A simple script which YOU run on your computer, which knows (*) your secret key - but as you run it yourself on your machine, that would not be a big problem, unless your computer gets infected.


That script does a rather primitive 3 step thingy:

(a) downloads all your orders, for (a1) some specific assets, or (a2) for all assets,
(b) compares the order submission datetime, and thus can filter all those which are older than 24 hours.
(c) and cancels all those old orders (*)

Automagically. You run that script as a cron job, or windows scheduled task.
And no extra DB necessary, the HZ blockchain is the database.


Extension 01: Global ... lifetime choice (24h, 48h, 1 week, ...)
Extension 02: Per asset ... choice of lifetime (same)
Extension 03: Per order ... choice of lifetime. A bit more coding, because a nice frontend would help, with tickboxes.
Extension 04: your ideas ...



Concept ready :-)  Implementation is easy now.

--> altsheets.ddns.net/give

:-)

ROKOS v6 Magic Flavors
Final tests done, to be released in the next days as soon as packing its done.

Permanent Integrated Coin: Horizon

Learn more about Horizon at: http://rokos.space/cryptocurrencies.html

ROKOS Github:  https://github.com/okcashpro/ROKOS-OK-Bitcoin-Fullnode

*** Please raise an issue over github when releasing a new wallet so it can be updated in ROKOS.
(If no official notice/issue wallets are not updated)  - For control and security.

Same way, communities/devs can now push commits to update/improve specifics over the included config file
at your cryptocurrency folder over: https://github.com/okcashpro/ROKOS-OK-Bitcoin-Fullnode/tree/master/clients-nodes/rokos-Pi2-Pi3

Horizon

The values of assets are provided in an include-file, for example http://galaxies.mygamesonline.org/latestrates.inc

The asset whose value is shown as 1.00000000 is, obviously (or hopefully obviously) the asset in terms of which the values are being given in the particular case.

What used to happen, using the Open Transactions platform, was each of the "big seven" had scripts that would have three scales for each trading pair, with slightly different markups / markdowns from the include-file-given values for each scale.

For example the Brits might offer to buy Canadian Digital Notes using United Kingdom Britcoin at the 1000 coin scale, the 10000 coin scale and the 100000 coin scale, and also to sell United Kingdom Britcoin for Canadian Digital Notes at those same three scales.

(Scales seem to be unique to Open Transactions; the idea is that often commodities will be cheaper in bulk than at small scales.)

The offers might be, say, 3%, 2% and 1% above the include-file values for sell and 3%, 2% and 1% below the given values for buy, so people trading with them would get better prices at larger scales.

(The idea there was that for smaller trades, market-makers could buy bulk directly from the governments or corps and sell in bulk directly to the governments or corps, with a margin allowing them to handle smaller scale markets such as buys and sells on a one coin scale or ten coin scale or hundred coin scale making a profit doing so. Similar to how banks buy currencies for sale over the counter to customers, or how money-exchangers near airports might do so.)

So as you hopefully see there is no strategic comparison here to other "current rates" that applied on other days. The scripts just take the base values as given (by head office or wherever, basically just include a file from a URL or somewhere on disk) and place offers computed from those values.

That could mean gains or losses, the scripts do not care, their purpose is simply to make sure that it is always possible to buy or to sell three "lots" at each of three "scales" basically all the time.

So for example you could always buy three batches of 100,000 UKB using CDN, and could always sell up to three batches of 10,000 UKB for CDN, or, since the Canucks would also have such a script, you could always buy up to three batches of 100,000 CDN using UKB, or sell up to three batches of 100,000 CDN for UKB and so on.

Using the scales also gave a way to get more granularity in pricing, since all assets were integers there were only so many integer prices you could have for one coin at a time, but trading at a scale of ten thousand coins you got five times as much price-granularity as the price would be per 10,000 coins not per coin.

The thing is, the details of how Open Transactions executed trades made it un-necessary to cancel yesterday's orders/prices because the default lifetime of all orders was one day so they died automagically, and for those times when you run the script again before a full 24 hours have gone by you did not need to worry about buying from yourself or selling to yourself because if a buy order was about to eat into a sell order the sell order was automatically cancelled and vice versa. So basically your new offers would stand and if old ones would have gotten in their way or eaten into them the old ones conveniently vanished.

This was awesome as it made the scripting very simple, just put in your markup and markdown from given current purported values and post your offers. No remembering required at all.

Basically the scripts were not bots, they were just blindly posting offers based on purported prices given from on high.

-MarkM-

Correct me if I am wrong

... you want to keep track of your past offers, and
depending on price evolution and your own profit goals...

... cancel, raise, or lower your orders - right?
... keeps track of your past gains, and losses - right?

So you hope to define your parameters, and then only want
to infrequently check - if everything is working like planned.

As HZ assets are the tradeable things here inside the system,
you mean orders for buy/sell HZ assets - right?



Minimum needs:
* a small DB with your choices (trigger prices, loss limits etc.), and past tx ids;
* (perhaps a user-friendly frontend to change them or:) a config file
* a short sequence of several HZ API calls.
* someone coding it.
* - i.e. salary/crowdfund/angel/asset, to be able to realize the project

A first iteration of that does not sound like a terribly difficult task.
And an automated trading engine might raise interest from people.


And yes - one outcome could be a command line tool that is automated as a cron job.

As I said - LEGO. Not Playmobil - you don't buy an unchangeable toy - but
many new toys can be assembled from the given parts. Figuratively speaking.


Do you see what I am aiming at, above?

Perhaps if I have not understood your exact application,
then you could layout a concrete detailed example case;
with conditional paths -depending on what the market can do-
that would make it easier for anyone who'd be coding that.

Hope that helps
:-)

Well the commandline is the common denominator that everything can access if given permission.

For example the MUD client tinyfugue can make commandline calls, so a character in a MUD who wants to buy or sell something in the MUD could trigger on receipt of something in the MUD a call-out to a commandline program that will send assets or check whether assets were received or whatever.

Basically if you have shell scripts you can then use them from inside all kinds of things, IRC bots, MUD clients, other shell scripts, CGI behind web-pages, whatever.

Also run them every day automatically using the cron daemon, which is probably how most day to market-making would be done.

But if one had to try to "remember" one's previous offers the whole thing gets horribly more complicated.

With offers that expire in a day you can just post new offers without worrying about what prices were yesterday, since yesterday's offers would be expiring automagically.

For a lot of people just including today's values from an include-file and posting various offers based on markups and markdowns on those values probably seems complex enough to daunt most of them.

But its not something people can be expected to do manually, having to log into something every day and post offers would get tiresome really fast, it needs to be done from the cron daemon.

-MarkM-

I am not sure that I have understood what you are planning
to achieve, but to me it sounds as if you can create your own app
that will do what you are wishing for - by using the HZ API functions.
"It is like LEGO" someone famous said, long ago, about this system.



Almost everything that can be done via the HTML wallet
... can also be done by querying the API of HZ.

That is done by http GET and POST requests, not commandline.
i.e. to build a commandline tool would not be impossible, but is also not needed.


I suggest you start studying the functions on http://localhost:7776/test

The wiki manual is very good, see http://wiki.nxtcrypto.org/wiki/The_Nxt_API
But beware: When NXT adds new functions (NXT is v1.8.2) and they edit the wiki,
they sometimes forget to update the version version number at the top. Anyways,
you can go back in time with the wiki history
http://wiki.nxtcrypto.org/mediawiki/index.php?title=The_Nxt_API&action=history
I think HZ is based on NXT 1.5.15 (?), perhaps a HZ dev
can point us to the most appropriate historical wikipage there.

But ... using the API functions is pretty straightforward, if you know HZ a bit already.


Later, for better inspecting your API results, I suggest you get a RESTclient. See
https://twitter.com/altsheets/status/725286587853070336

Have fun with it. The API is a pretty amazing system, really.

Has anyone else noticed that minting is broken?

Turn it on, come back a few days later to find it is turned off?

Also, is there some kind of command-line tool one can use to place offers?

In order to do market-making each of the "big seven" currencies for Open Transactions a bunch of bash-scripts that would include the currenct rates include-file for current values of assets and put together offers at three different scales to buy and sell against each of the oter big seven currencies and some of the other currencies.

For example the Brits would put buys and sells on the 1000-scale, 10000-scale and 100000 scale markets to sell at a 3%, 2% and 1% markup respectively and to buy at 1%, 2% and 3% discount respectively.

Also, what happens if your buy price today exceeds your sell price from yesterday? Will your sell offer cancel itself automatically when you go to buy at a price that would otherwise have bought some of your own sell offer?

In Open Transactions the default lifetme of an offer was only 24 hours so as long as you waited longer than that before running your market-maker scripts there was no risk of such overlap, but as soon as it was realised such overlaps could happen if you ran the scripts more often the server code was fixed to prevent buying your own sells or selling to your own buy ofers by simply cancelling any offer of your own that a new offer of your own would have eaten into. But is that the case in HoriZon?

If the default lifespan of an offer is longer than 24 hours, is there an option to specify the lifespan you want? Because trying to regularly place market-making offers at current valuation would be massively harder if you had to somehow figure out, or even somehow actually remember, your existing offers and cancel them to place new offers.

(The automatic cancelling by the server of offers that cross each other though helps a lot with that, since some folk don't so much mind their old-prices offers standing so long as it doesn't mean they end up buying from or selling to themselves, which in any case no one wants to have happen since it makes false volume without even requiring the person creating the false volume use two separate accounts to do it.)

Still I think for the most part folks will want to know their previous offers have died when they place their new offers or will die when the new offers are placed.

-MarkM-

I have put on Devtome a proposal for a "Corp" to be known as HZCorp (HoriZonCorp; HZC):

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

I also created a thread in this section of this forum on the topic:

https://bitcointalksearch.org/topic/hzcorp-horizoncorp-hzc-prelaunch-1453389

-MarkM-

Apache crashed. Thanks for the notice!

What happened to Horizon web resources?

https://horizonplatform.io/ - down
https://explorer.horizonplatform.io/ - down
https://slack.horizonplatform.io/ - down
http://nhzcrypto.org/ - down

 

Hi,

Is there any relation between bitland and HZ?