DONT

Your phrase will be hacked. Its virtually impossible to manually make a strong enough key that cant be brute forced.
We are in the process of putting back the secret generator, it uses strong cryptographic truly random number generators, which you really need!

If in a hurry there are websites that offer this same functionality, one i know of is the web wallet for fimk.
In the 'advanced' part of the create account dialog (small link, located on the right bottom corner of that dialog) you can create strong secret keys.

Fimk web wallet is here https://lompsa.com/#/start.

For anyone not being able to come on the main fork (and start mining blocks) we've came up with a temporary solution (until we get the new release out in the coming days).
We're offering a zipped version of the blockchain that you can download and place in your blockchain folder, the downloadable chain is updated regularly.
After downloading make sure to set the following properties in a file that you need to create.

Create the file heatledger/conf/heat.properties, where heatledger is your main heat folder. In this file put the following two lines:

heat.forceValidate=false
heat.forceScan=false

Now after deleting all the contents in the heatledger/blockchain folder and having replaced them with the files in the zip you downloaded, you will get on the main fork after you start heat (bin/heatledger.bat on windows, bin/heatledger on mac/linux).

https://heatwallet.com/download/blockchain.zip (the file is just 8MB but it will unpack to approx 2.5GB).

We are sorry for the inconvenience.

Windows and linux desktop versions with 0.9.3 embedded.

https://github.com/Heat-Ledger-Ltd/heatwallet/releases/tag/v1.0.2

New release fixes forging issues people are having.

https://github.com/Heat-Ledger-Ltd/heatledger/releases/tag/v.0.9.3


In a few days we'll be doing a hardfork that fixes all this for good.

Heatledger 0.9.2

This is an optional update.

But highly recommended for network stability!

* Fixes a bug which made the full rescan and validation fail. Please at all
  times keep heat.forceScan and heat.forceValidate enabled at all times at
  during these early days.

* Improved log output to show blocks pushed and popped again.

* Raised `heat.numberOfForkConfirmations` in the default config back to 2.

* Unset the `heat.apiKey` in the default config, if you want to use the
  restricted apis (start forging, get peers etc..) you have to set it yourself

* Documented an existing feature in the config. `heat.startForging` it
  does exactly what it says, if you put your secret phrase there with out
  quotes and all on one line on startup your server will start forging with
  that account.
  A WORD OF CAUTION !! If used anyone of course knows where to look for
  your secret phrase. So use with caution, when balance leasing is up this
  can be used more responsibly.

https://github.com/Heat-Ledger-Ltd/heatledger/releases/tag/v0.9.2

We connect to the default peers in the config.
So if you leave those the default and leave on the forceScan and forceValidate flags in the config it should work.

You are correct that this is a debugging stage.

I am also using one of the dev bonus accounts to mine blocks in order to get the network in order, I was unaware of the horrific nature of doing this in order to get a properly functioning network. I would of course donate away all my forging awards. Pretty sure the community comes up with a good cause.


Investigating.


Set more fine grained log settings.

heatwallet.com was updated, now has the asset exchange whitelisting fixed.
This fix is why we need to hard fork among other things.


You dont need to enable the api server for pop, the pop script will run *inside* heat. A test case is in the scripts dir, scripts access the java core directly so no need for an api server is needed nor does the replicated databases need be enabled.

I'll try and release the heat-scripting-devkit in the coming days so everyone can start writing and running their own scripts.

We did update the old one since it was giving errors on some systems because of a too long CMD, something cmd.exe was upset about.
You could always edit our starting scripts to your liking, we dont mind that.

Please update your servers,

This update is mandatory nodes on 0.9.0 and lower will be blacklisted by the rest of the network.

https://github.com/Heat-Ledger-Ltd/heatledger/releases/tag/v0.9.1

We also have completed the windows and linux desktop versions and will publish these shortly.

1. Core status?

Core now also consists of asset-to-asset exchange, this was added recently on top of payments which were already functional.
Testing is done with a technique i call mirrorring, its very similar to how payments used to be tested. The tests for payments were not sufficient for testing orders, unconfirmed order matching and also supporting rollbacks and testing blockchain reorgs.
 
For this the test code really had to support some way that mimics the way the storage backend supports rollbacks to previous versions AND support transactional operations where either all or none of the changes during a storage transaction were commited to the data storage.
The mirroring mode can be switched on through the app configuration and has separate logic that keeps a one to one clone of the blockchain but in memory, all balances of accounts and assets and orders plus unconfirmed balances are kept track of. But with separate code that does all the calculations itself and does not rely on the code that does this for the main heat balances.

This way when you start heat mirrored and you do a transaction, the same changes to the sender and recipient account balance and unconfirmed balance that happen in the heat storage also are applied to the in memory balances. This supports rollbacks and any possible restores in case an error occurs and a transactional storage operation must be unwound. If you add to the mix that after each operation you compare the heat balance storage with the in memory clone of the balances - you can basically confirm that at least the heat balance updating logic and the code that does the same thing in the mirroring parts are actually in sync.

What remains now are two things. A. Find a way to throw as much and as different as possible transactions at heat while running in mirrored mode (the more difficult the better since you'd ensure all possible code paths are handled). B. Make sure to manually go over the code that does the mirroring analyse it as best as possible and make sure its sound. That last part is actually much easier as compared to manually going over the code that does the same balance handling for in the heat parts. That's because the mirrored code is just a fraction of the size of the code for heat balance tracking - only the most essential parts are there.

When changes are made to heat core code - new transactions added - new asset classes introduced - pop rewards get enabled etc.. We now have a built in diagnostics mechanism, not very much unlike ethereum uses several clients written in several languages that also perform their self-diagnostics.

To assist in sending as much and as different as possible transactions to heat we added the concept of apps which are javascript/nodejs/npm modules you can reference on the command line and have heat load those in the java js vm. Helper classes are injected into those scripts that allow you to easily send transactions, generate blocks, etc. Works really easy. Its not the same as microservices which are also scripts but meant to run and respond to events on the live network. Apps are run instead of the main blockchain, you can assign their own blockchain and configurations through their package.json file. Purpose of apps are either running tests or doing analisys of the blockchain, app scripts run from start to finish and shutdown. Microsservices keep running in the background for ever.

2. Asset exchange status?

The replication parts (detailed optional database model - kept in real-time sync) have been completed and operational. This involves all trade history and all order history which is not needed for consensus and thus has no part in heat core. These replicated parts are now also accessible from the api, use them to list trades and orders and search for them etc.


3. Email account identifiers

To support human readable account identifiers instead of forcing users to remember and exchange numerical account ids we have completed the account identifier parts. What we wanted is a mechanism where users can safely use their own private email addresses as their account identifiers - yet not have a trace of that actual email address on the blockchain. This comes down to user a registering id "user@user.com", yet not leaving a trace on the blockchain. Yet when some other user sends a payment to "user@user.com" the payment will go to the correct account. If you wish so you can register your account identifier to be public on the blockchain. It is also possible for another account to assign an identifier for your account - but only after you provide a signed messages, signed with your private key which the assigning account has to provide.

The storage of account ids happens not as actual textual identifiers but as 8 byte longs, very similar to how we generate numeric account ids from the much larger public keys. The range of unsigned 8 byte longs is 18,000,000,000,000,000,000 or 18 billion billion. Which we think is more than enough to support most users unique names yet have have very little to no false positives.

To be able to support account auto completion in the client the replication layer has functionality to store all non-private identifiers and make them searchable. Assigning or announcing names for accounts happens transparantly very similar to announcing public keys and can be done at no extra cost when sending a transaction.

For 3rd party developers:

HEAT OpenAPI spec can be found here http://alpha.heatledger.com:7733/api/v1/swagger.json
We'll be integrating client lib generation on code push into the build process but for now if you load it through swagger http://editor.swagger.io/?url=http://alpha.heatledger.com:7733/api/v1/swagger.json#/ and click "Generate Client" you already can get a nice collection of clients in different languages.



Image shows where those clients can be downloaded.
API is not final!

Well it's basically ready with some complex tests pending completion.
Strongly expecting launch in December.

Quite some changes have been applied since our last update.

The most significant probably being us dropping the original NXT based API server and replacing it with a completely new API implementation and server that is now compatible with the https://www.openapis.org/ standard. The compatibility to the openapi standard was achieved  by annotating all java API code and integrating the swagger/jersey libs into HEAT. Now when you run HEAT you can ask it for its API spec (which is an auto-generated JSON document) and which is understood by all tooling providers who adhere to the openapi standard.

There are two main purposes to being openapi compatible.

• provide detailed API documentation to 3rd party developers
• provide fully operational client libs in virtually any programming language available

To get an idea of whats that like please checkout an early draft of HEAT API documentation http://alpha.heatledger.com/api/ and our interactive HEAT playground which allows you to try out the full API straight from your browser which is here http://alpha.heatledger.com/interactive/.

The client libs are basically fully typed language specific wrappers around the HEAT API, we'll be hosting those on our developer section of our website and when downloaded allows any developer to use HEAT from their own project in their language of choice. As said the number of supported languages is very large, to name a few (.NET, Java, C++, Python, Node.JS etc etc) have look here to see the number of supported languages https://github.com/swagger-api/swagger-codegen/tree/master/modules/swagger-codegen/src/main/resources

Another large addition was replacing the asset exchange with our own implementation, the new asset exchange supports asset to asset and heat to asset orders, basically allowing anyone to create any trading pair they'd wish. A lot of thought had to be put into this to make it operate both at high speeds and to use very little memory (we succeeded in doing this). Not having a database in the HEAT core was not making things easier since it required us building a custom indexing solution so order matching can happen as fast as possible.

The problem with indexing (pre-sorting orders) was solved by making a hybrid data structure that only keeps the order ids in RAM, these ids are 8 byte identifiers and are kept in plain java arrays, while offloading all other data to the off-heap mmap disk based storage only requesting that on demand.
To give an impression of memory cost required imagine a moment in the future where we have 1,000,000 open orders on the blockchain. This would cost us 8MB of RAM which I believe is not that much. Even further down the road we should still be able to support 100 million open orders since this costs just 100 times more RAM or approx 800MB, still perfectly fine and still possible to run from most desktop PC's.

Our new asset exchange now also comes with the concept of instant order matching which is done by introducing the concept of an unconfirmed order balance. What this means is that instead of just matching orders when the new block comes in (this is how nxt does it) we now match orders when they come in as unconfirmed transactions. This basically allows for instant trades and updates of orders. Since such functionality makes little sense if we dont match unconfirmed orders against other unconfirmed orders and dont take into account that unconfirmed orders could be cancelled by unconfirmed order cancellations. There really was no use in re-using the nxt based asset exchange a rewrite was the only option here.

If HEAT would have been running in a controlled private chain environment with only dedicated and known miners the above exchange functionality would have been sufficient to fully rely on unconfirmed transactions only and present those to outside users as basically instantly confirmed. On the public HEAT chain this of course is not the case and there always remains the chance of one node having to re-adjust its internal state which was based of unconfirmed orders and having to bring it in line with the new block he/she just received with perhaps a slightly different ordering of orders which leads to different trades etc.
To bring this level of instant confirmation to the public chain I'm leaning strongly to creating a very different p2p networking and interop model, one that is smarter and one which uses strong cryptocraphic identities for all nodes, also one where each node on the network is in direct and constant contact to each other node on the network. Luckily this is possible and could be achieved when we switch from the jetty networking libs to http://akka.io/.

We already had the concept of replication in HEAT testnet and even in FIMK way before that, for anyone new to this replication is basically offering a powerful (detailed and indexed) SQL database model which allows you to inspect the blockchain contents. But make it optional to the consensus mechanism. This means that you could run a HEAT node and only use it for mining or POP participation and not bother with any of database inserts/indexing overhead (if you look here http://alpha.heatledger.com/api/ you'll notice the mention of "only available if replicator is enabled"). For HEAT testnet we had the replication logic in an external Scala app which updated a Mysql database which in turn holds the detailed blockchain data.

By rewriting the replication logic as a light weight (and making it support multiple databases) addition to the HEAT core and integrating it with the new API we believe we have a better maintainable solution. Also adding bundle based solutions has become much simpler and more maintainable. Bundles being binary messages attached to transactions and which are interpreted by the replication layer and applied to the database. One example of this is the HEAT keystore (basically the same functionality as ALIASES in nxt) the big difference here being that in the case with aliases all nodes around the world would have to carry all aliases and have them indexed and ready and that the consensus mechanism would not even function without everyone having access to all aliases ever created. (same goes for things like digital goods store). What we did with the bundle technology was basically introduce a light weight form of transaction that still offers the same security and decentralized aspects as an alias transaction would in nxt. But without the overhead cost of not being able to prune those away and forcing all nodes to keep those aliases around for ever. Keystore is an extremely simple example of this, all it supports are simple key+value combos (see http://alpha.heatledger.com/interactive/#!/KeyStore/keyStorePut and http://alpha.heatledger.com/api/#keystoreget for its API) but the same mechanism applies for much more complex and possibly multi-step inserts and updates giving us nothing less than the basis for a fully blockchain based database or basically any business backend.

To get an idea of how easy it is to use the replicator/bundle functionality have a look at the full KeyStore implementaion here com.heatledger.replicate.KeyStoreReplicator

Tried it and from here it seems to work (used chrome and firefox from a linux desktop)
Please contact support if this keeps up, support is available from the "contact us" live chat widget on all the ico claim pages in the client (right corner at the bottom).
Also make sure to use https instead of http. But it seems you did that already.

We have concluded all important parts that relate to the core. This includes the removal of the embedded database and replacing it with our own custom transactional and crash proof storage mechanism based on memory mapped files.

This storage layer in itself and especially the crash-recovery, transactional rollbacks and ability to rollback all storage to a version N blocks in the past was no small feat. It was further optimized to use as little memory allocations as needed, we achieved this by re-using many of the application objects (accounts, transactions, blocks etc but also many of the raw byte arrays) and instead of recreating new objects while the app is running we try and re-use existing objects by repopulating their fields and data.

To fully ensure its correct workings we've opted for a testing scheme where we have the heat core test itself. Its much like doing a self diagnostics but we'd like to view as it 'extreme self diagnostics'.

The architecture of a blockchain application is perfectly suited for such a mechanism, add to that the lightweight operations of the heat system as a whole and combined we'll have the perfect through and through self-testing.

The self diagnostics works by generating an endless stream of transactions, blocks, but also causing exceptions in places where exceptions can occur and forcing the blockchain to be rolled back at pseudo random intervals. In short we replicate months of normal operations in a matter of minutes.

To ensure all is working correctly we have various verify'ers listening in on the events that come from the heat application and use those events to built a secondary derived blockchain model which holds all account balances, unconfirmed balances, blocks, transactions etc etc either in memory if the data permits this (simple accounts balances for instance) or we'll store smaller checksums that proof larger constructs like blocks and transactions actually match on disk what we have calculated in the secondary model.

We plan to use this same test in our continuous integrations systems which are in the process of being setup (we'll be using Jenkins and host the code on github, upon each commit Jenkins will run the full test suite).

Heat will not only be the fastest and most scalable crypto currency. It will also be a POS cryptocurrency that allows anyone to create a sidechain or private blockchain without writing any code at all, free of charge. At heat we believe that instead of making it a pain for anyone interested and willing to invest in our technology, we actually welcome and enable these users to get their private chain up and running as quick as possible.
Eventually, You not only dont need to write any code, you also can use the standard heat server and client software to operate your private chain. Users can opt to run just heat, just any other private chain or a combination thereof.

To achieve this instead of encoding the genesis block as an encrypted set of transaction and block signatures as is standard with previous POS crypto currencies, later this year we aim to include the code to actually create the genesis block into the heat core. This allows anyone to create a json file with a list of recipient public keys and genesis amounts. Et voila start heat and you'll have your fully functional private chain.

As soon as the decentralized services will be coming online those will work on heat and all private heat chains derived from that.

We are planning to release the heat genesis block in the coming days, and HEAT core software on github shortly after that, as well as setup the continuous integration and prepare all further dev-ops aspects to at least guarantee enough uptime. To ensure fast updates to the network we will be using the same auto-updating feature that we introduced in FIMK which allowed us to remotely disable and even shutdown servers that run versions that are not compatible with the master branch. This mechanism will be active during the start of heat but always will be an optional feature, if users wish so they can disable this feature in the light of decentralization.

For the health of the early network and to allow us to push new features at this early stage we of course discourage users to do this.

HEAT ICO CLAIM HAS STARTED !!

This release contains various smaller bug fixes, a new local storage solution, new and unread message notifications and a temporary ICO claim section for claiming your genesis HEAT.

User support/feedback functionality has also been added to the client, use it whenever you need help during the ICO claim process.

To claim your HEAT you could use both the web version and the desktop versions, it is however more secure to use the desktop version since you can verify it's origin in ways that are simply not possible with any website.

The ICO claim process will ask you to provide the address(es) from which you've sent your investment and will provide you with a confirmation address and a small payment to your ICO address (to cover the transaction costs).

You are then to send a payment from your ICO address to the confirmation address to confirm your ownership of that address. Confirmation is near instant and will be visible in the claim section.

Your HEAT-TEST account (the one you use in this client) will be your final *real* genesis account in the HEAT genesis block, so make sure you use a unique secret phrase. You can claim multiple ICO addresses and assign them all to your one single HEAT account.

The claim process helps you to properly backup your HEAT secret phrase (aka your super secret/super important master key).
Through the client UI you have the option to:

• Print your secret phrase directly from the app to your printer
• Save/download your secret phrase to a file on your computer
• Copy the secret phrase to your clipboard
• View the secret phrase and make a picture/hand written note/etc..

Release 0.1.1 can be found here: https://github.com/Heat-Ledger-Ltd/heat-ui/releases/tag/v0.1.0
Web version can be found here: https://alpha.heatledger.com


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Release 0.1.1 | 2016-10-18 | https://heatledger.com

██╗  ██╗███████╗ █████╗ ████████╗   ██╗   ██╗██╗
██║  ██║██╔════╝██╔══██╗╚══██╔══╝   ██║   ██║██║
███████║█████╗  ███████║   ██║█████╗██║   ██║██║
██╔══██║██╔══╝  ██╔══██║   ██║╚════╝██║   ██║██║
██║  ██║███████╗██║  ██║   ██║      ╚██████╔╝██║
╚═╝  ╚═╝╚══════╝╚═╝  ╚═╝   ╚═╝       ╚═════╝ ╚═╝

This release contains various smaller bug fixes, a new local storage solution,
new and unread message notifications and a temporary ICO claim section for
claiming your genesis HEAT.

User support/feedback functionality has also been added to the client, use it
whenever you need help during the ICO claim process.

To claim your HEAT you could use both the web version and the desktop versions,
it is however more secure to use the desktop version since you can verifify
it's origin in ways that are simply not possible with any website.

The ICO claim process will ask you to provide the address(es) from which you've
sent your investment and will provide you with a confirmation address and a
small payment to your ICO address (to cover the transaction costs).

You are then to send a payment from your ICO address to the confirmation address
to confirm your ownership of that address. Confirmation is near instant and will
be visible in the claim section.

Your HEAT-TEST account (the one you use in this client) will be your final *real*
genesis account in the HEAT genesis block, so make sure you use a unique
secret phrase. You can claim multiple ICO addresses and assign them all to your
one single HEAT account.

The claim process helps you to properly backup your HEAT secret phrase (aka your
super secret/super important master key). Through the client UI you have the
option to:

  1. Print your secret phrase directly from the app to your printer
  2. Save/download your secret phrase to a file on your computer
  3. Copy the secret phrase to your clipboard
  4. View the secret phrase and make a picture/hand written note/etc..

- ---------------------------------- Downloads ----------------------------------

https://github.com/Heat-Ledger-Ltd/heat-ui/releases/download/v0.1.1/Heat_Setup_0.1.1.exe
SHA256 69f10edd1558a188fa0e90968c24dea54fad4d3237d2b1028a92dd3d968b9ed4
MD5    817dd249e4d427547f74bf91c54e841e

https://github.com/Heat-Ledger-Ltd/heat-ui/releases/download/v0.1.1/Heat_Linux_0.1.1.zip
SHA256 8d3be49a1778aeefe0ee8a12d29e7c694fbb5c38f5e5875ae29a5d056ba8183d
MD5    a1ec7c2c205641853741189284de9596

https://github.com/Heat-Ledger-Ltd/heat-ui/releases/download/v0.1.1/Heat_MacOS_0.1.1.EXPERIMENTAL.zip
SHA256 4bf28a8f533f33e55c4664d71f01ac433d0d85535374bf63511359054a6dfe29
MD5    d1602dfbb0d420113b3eaacc7a9e584a

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJYBgfsAAoJEFrwWULwsJcFypUQAJ8PRvqJFwZkh05kW4Soh4Ii
QYwkjUbYTmpucZQEmeK25xII8ejDkG5FXejvbd6Uc5yvHILj8JSYTiyPS2V254x2
8jqwyIed7hazweYaaAu9/1v+FLyXXsE3B+qvsLyDURuFPgUz0ma8qfIOc3oSNpF5
1Lq0kVRzOGoWJUAXi2IY33Oty/sST+Z9+U6HMLYrase2l7ZQXbJLhEBqjKQU55Bf
sHJ5PI6Wr8Lan7mZC501FFnMHy+UgmDKBJBs9FF7qMG+DdAI0sCIC6ZnAOhQDgeE
iSRZ21KqxAd6+96SR5CjhWZJgEp1h7RyUEke28WTKs9l8MRQ+77XmPWyLjkDNX2l
tkZEhgqWWmJmL/FAIW6yz47B0RLAT4q2Yo/1vHrcj6ooP0U4VEibiLEx+o3OeO31
bFRiMw5zqd3lKdhZb5YQhwhHtfIFOyt1kJ0GmUwcMRRd7TGuHZP2ndvMQhgls0Nx
C/nNm9LiOT6JqAjPOdpMyDIWCVWhCdabiY3m9Paudnm+CUjvTohym9R95hy8jW5l
1qcc1FZWBgfRE0fzcffRsPCjQitgvJZ2XVwoR6fpiBuVBxFe45beoUz3IUEFntMR
8pYfF05wiH+p4A/QCX8T07MV+7Dbul2IsNIgfK/BhJZPxy5i+x/Nipbyeo8MxAeS
z1L7DMBFeMN5E4PXP6+7
=KLYf
-----END PGP SIGNATURE-----

We are happy to present to you the first ever heat-ui release.
Heat-ui is the client framework and part of the holy heat trinity that is made up of

• heat-ledger
• heat-ui
• heat-server

For users

We invite you to try out this release where and however you like.
The easiest way is to simply launch the app in your browser, works both on your desktop and your mobile device.

https://alpha.heatledger.com

There also are the install-able versions for Windows, Mac OS and Linux. Downloads can be found at the end of the changelog below or at our release page over github https://github.com/Heat-Ledger-Ltd/heat-ui/releases/tag/v0.1.0.

This release is to showcase and test our client framework and all its distributions, new users get free TEST HEAT. This client is connected to the HEAT TEST NETWORK. Please read down below for an extensive description.

For developers

Are you a front-end developer? Do you love new and exiting techniques?
Then head on over to our project page and you'll find we have some very cool tech and would love to work with you on that.

https://github.com/Heat-Ledger-Ltd/heat-ui



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Release 0.1.0 | 2016-09-21 | https://heatledger.com

██╗  ██╗███████╗ █████╗ ████████╗   ██╗   ██╗██╗
██║  ██║██╔════╝██╔══██╗╚══██╔══╝   ██║   ██║██║
███████║█████╗  ███████║   ██║█████╗██║   ██║██║
██╔══██║██╔══╝  ██╔══██║   ██║╚════╝██║   ██║██║
██║  ██║███████╗██║  ██║   ██║      ╚██████╔╝██║
╚═╝  ╚═╝╚══════╝╚═╝  ╚═╝   ╚═╝       ╚═════╝ ╚═╝

This is the initial Aplha release of the Heat Client Framework also known as
the heat-ui project.

Heat-ui already is a robust and extensible framework for building multi device,
cross OS crypto currency clients.

Out of the box heat-ui runs in your browser on your PC and on your mobile
devices through its use of responsive designed ui controls.

Heat-ui also comes as a Windows installable application, as a MacOS
application (although currently in experimental phase) and as a Linux desktop
application.

Pending target devices are Android and IPhone. All distributions for all
platforms use the same code base.

This Alpha release also is available online at https://alpha.heatledger.com as
a fully functional browser based version.

The goal of this Alpha release is to showcase and test the extensive framework
built by Heat Ledger Ltd.

This alpha version connects to Heat Test Net, we invite anyone to play around
and try it out. When creating a new account new users get 1.000 TEST HEAT for
free.

Functionality in this version consists of blockchain based instant messaging,
sending and receiving Test HEAT and a simple block explorer.

- ---------------------------------- Downloads ----------------------------------

https://github.com/Heat-Ledger-Ltd/heat-ui/releases/download/v0.1.0/Heat_Setup_0.1.0.exe
SHA256 3992ce20a2f3139c88d1b5c9c95a4eac37d72879112c7325bc78c4d3cff93176
MD5    67bd4d8325975ca94026c6a912645d20

https://github.com/Heat-Ledger-Ltd/heat-ui/releases/download/v0.1.0/Heat_Linux_0.1.0.zip
SHA256 7da3db5ad17f4cab45f8f01af9cea5f712f0dae8caf195a8d8ab31fdfa1a47e5
MD5    a417196048abc8bdc8ee3b4f821e8496

https://github.com/Heat-Ledger-Ltd/heat-ui/releases/download/v0.1.0/Heat_MacOS_0.1.0.EXPERIMENTAL.zip
SHA256 e479577d5811458f2fb4aa023b26315663d9dda3960de1aa7e588586dbab83b2
MD5    c6b248a2c414ebd6131259e3ecb78564

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJX4uXRAAoJEFrwWULwsJcFzboP+gMqCaJACHEvCvLFk2YK7+Sp
G8AA4q4mi1QeveNZyZk8X8xH9H5s5oWfF4AAn7E5iJE/sBoxRNNOKf96OOuQf3hS
2GPtRsCBdsfEIcdKEaYWwkpboqhd9/UlgLJtT8PzAm9rboZcLkypc2U/aBpCYb/g
VfU5WH/JyzjHSqj9ivrTehnmMbHOl8WAwiP0Po2kPGveu0eMIsSi2UmYU+STFtP+
VDLn7gemennwCympy1S+RnYVTUBm2X7WsRy0SjuQe5jajZ40rErPyfGdifvlrfMw
v54a+22p/0rpftB6//v1WZLxMf6FqEcrfRSKZhz4wjFc2rthoP5YmtZ+Satt0Uxp
m6VBn5E/FhJBL2kMuUQv4CBtdJUItxHC75d6Mo1UamfP0akzByMYSdhjkJsOn8nP
a5mct0cReMtgMHnZnPzssSMfAIv447vY0lS1SG4WAY9eUWXjWqxynHvp/nF8YHSL
zp5w18UHIiLDkz/Ujbvzw1+RbneKtUKkHWCpmfiSoyAKQCOLSjTb7xu7dYxfPjA/
fGiR5AzOv9f9uI5qIBPulIrNgWy78W51CQ8p08bYM74Amf/6xdzSmSutot9y3RNb
3aChbQjsinRm2ZwluE1CHXQJtJoJw27mPn/YdMJPZar3uRXe3BT6Pjw54wVAdKLQ
+UCYtYBuvOj0/tiohho0
=Mk7h
-----END PGP SIGNATURE-----

It's been awhile since my last post.
I've been working on HEAT probably like I've never worked for something in my life before.

I guess I can just focus better and get more done by shutting out any and all distractions - which unfortunately at this time (with the current amount of tasks) also includes this forum.

Apart from the work for HEAT directly I've also been working on getting side projects up and running that built on-top of HEAT and are set to be used by our Heat Ledger Ltd joint venture partners.

The HEAT code base now consists of 3 very large projects already which have been completed in large part this last month.
More recently we've worked our asses off for the HEAT ICO redemption part of the HEAT wallet online but unfortunately could not get it to work by tonight, I simply need a couple more days.

I'm sorry for that and I apologize for anyone who was counting on this to be ready today.
What we can release within the next few days along with the ICO redemption is no small thing either, it's actually the bulk of the core of the HEAT open source trinity, which is made up of:

• Heat Testnet
• The server (the real-time, internet scale window into the ledger)
• The client (the generic real-time, ready for mobile client framework that does everything from browser cryptography to real-time updates)

We do everything we can to get stuff online on Tuesday. I'm pretty exhausted and need rest now.

Hi,

Took some time away from the forum to be able to focus on HEAT coding.

Completing the asset to asset exchange at the moment which is mildly put `a brain teaser`.
I'm happy however that we have had all the difficult parts ready for some time now.

Happy to be able to reuse all those parts like `versioned storage backend` (we made that already -  does rollbacks, transactions, recover etc.)

No time to look at those links right now, will look at them (if you remind me) but not right now.
Lots to do 

They will be extremely cheap. HEAT is not NXT, we don't have to worry about getting full.