Please login or register.
Login with username, password and session length

HEAT Forum

January 19, 2018, 03:30:11 AM
News: 2017-10-10 Heatledger 2.0 with Heatwallet 2.2.0 released! NOTE: Balance leasing and hard fork at block 777777 https://github.com/Heat-Ledger-Ltd/heatwallet/releases

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Topics - verymuchso

Pages: [1] 2
1
General HEAT Discussion / HEATWALLET 2.4.0 | Windows+Linux Desktop edition
« on: December 28, 2017, 09:59:10 PM »
HEAT WALLET 2.4.0 | Windows and Linux desktop

This desktop wallet release embeds the 2.4.0 server version which is a mandatory update. If your wallet does not use the built in server (default behavior of the wallet is to connect to a remote API node) you could still use that but you'll lack the client side (UI) improvements.

Note

The virtual order matcher (instant asset exchange order feedback) is still disabled, we are enabling that in the next wallet update. Because of this you have to wait until the next block (30 seconds) to see your balances updated and to see orders matched and trades made.

When the virtual order matcher is enabled we'll update the web based wallet on https://heatwallet.com and put out a new wallet release.

About the HEAT LEDGER 2.4.0 server

This is a hard fork, a mandatory update of the HEAT network. This update fixes a bug introduced in 2.1.0.

The hard fork will take effect at block 956000.

Nodes below 2.4.0 can not be used to forge in the main HEAT chain.

API Information

https://heatwallet.com/api/#/

HEAT SDK

https://www.npmjs.com/package/heat-sdk

Changes

  • Updated default properties to always perform a scan and validation on every startup.
  • Set remaining balance limit of 0.01 HEAT for ask orders of HEAT due to large number of accidental account drainings and subsequent asset withdrawal incapacity

Get it here

https://github.com/Heat-Ledger-Ltd/heatwallet/releases/tag/v2.4.0

Mac release will follow.

2
General HEAT Discussion / SOFTWARE UPDATE - 2.3.2
« on: December 21, 2017, 10:06:17 PM »
 SERVER UPDATE

HEATLEDGER 2.3.2

We unfortunately introduced a bug in the previous 2.3.1 version basically making 2.3.1 incompatible with the last official guaranteed to work hard fork version 2.2.0 and its followup 2.3.0.

This version solves the problem where certain transactions could not be included in blocks forged by 2.3.1.

Apart from this fix we also fixed a bug in the display of transactions in the block explorer.

https://github.com/Heat-Ledger-Ltd/heatledger/releases/tag/v2.3.2

DESKTOP WINDOWS + LINUX UPDATE

HEAT WALLET 2.3.2

Contains heatledger server 2.3.2.

ABOUT HEATLEDGER 2.3.2

We unfortunately introduced a bug in the previous 2.3.1 version basically making 2.3.1 incompatible with the last official guaranteed to work hard fork version 2.2.0 and its followup 2.3.0.

This version solves the problem where certain transactions could not be included in blocks forged by 2.3.1.

Apart from this fix we also fixed a bug in the display of transactions in the block explorer.

We are working on an update that fully enables this great feature again, it will work even better and no longer interfere where it could cause forks to happen.

https://github.com/Heat-Ledger-Ltd/heatwallet/releases/tag/v2.3.2

3
HEAT LEDGER 2.3.0 - BUG FIX

Heatledger 2.3.0

This is an optional server upgrade meant for forging nodes.
This upgrade fixes a bug encountered when we combine the virtual order matchers and forging blocks on the same machine.

Nodes below 2.1.0 will automatically be blacklisted with this version.

On startup a scan and validation of the blockchain will be performed one time, this happens automatically.

Because of the nature of the bug and this version being meant for server forging use, we have disabled both the virtual order matcher and the virtual account balances.
What this means is that if you use this server version to power a HEAT client you will have to wait for the next block before you see things in the client like balance updates, orders, order quantity updates, order cancelled status.

The virtual features will return in a next release together with the option to completely disable this for servers that are not used to power a full client. This saves resources when disabled.

https://github.com/Heat-Ledger-Ltd/heatledger/releases/tag/v2.3.0

4
WE DID IT, 2000 transactions PER SECOND OVER THE NETWORK!!
proof will follow, test it for yourself from your browser

Hi fellow HEATers, please allow me to share a short development status update.

Some interesting and major milestones have been achieved over the past week. To list a few:

Blockchain-Event-Cache

Big steps have been made towards finalizing the Blockchain-Event-Cache, the event cache gave us some real hard challenges to solve. An example being how to store to disk the tip or last N events of a never ending stream of events, without running out of disk space! And do it in such a way that no matter if the HEAT server crashes or shuts down, that at all times the persisted state of the blockchain matches exactly with all persisted events.

The significance of the event cache really can't be overstated. It's workings and design are unique and as far as I know exclusive to HEAT. The event cache should be considered as an ordered list of events where most events map to a whole or part of a blockchain transaction. The event cache has a cursor which points to the current latest event and this cursor can move up and down the list of events.

Observers of the events (microservices listening to transactions for instance) will be notified when an event first arrives. HEAT being a decentralized consensus mechanism must account for the inevitable slowness of reaching full network wide consensus simply because nodes need time to talk to each other, the network speed determines this. The event cache is your friend that watches blocks come and go, switches to better forks and reorganizations of transactions, all the while giving you a normalized view of the transaction stream as if you observed centralized service.

When building business applications on top of HEAT using the blockchain as a place to transport and store your data having this 'normal' view of the transaction stream is of vital importance for any kind of application you build. 

High-speed-RPC-channel

What was probably the coolest part of the week was to fire up the new high speed RPC channel we added to HEAT core. From unit tests we could already see that HEAT has been very fast when it comes to processing transactions, we've seen numbers of well over 2000 transactions a second when feeding transactions directly from memory into HEAT.

What hasn't been achieved yet was to process such high numbers over a network, until now that is!!. Two major obstacles of feeding lots of transactions to a HEAT server over the network are:

  • Everything is encoded as JSON, parsing lots of JSON costs memory and downloading large blocks of JSON makes things slow
  • Every transaction broadcasted did so over its own unique and new HTTP connection

The data encoding issue has been something we've looked at for some time now. What we wanted is basically write out raw binary data which is as dense and optimized as possible, yet still be able to handle this new format somewhat easily and preferably portable so it could be used for instance with the https://www.npmjs.com/package/heat-sdk. We would be using such for:

  • Microservices user defined messaging protocols
  • P2P message encoding
  • To encode high speed RPC messages

We decided to go with https://avro.apache.org/ which is the data serialization stack from http://hadoop.apache.org/ [HADOOP=The Apache™ Hadoop® project develops open-source software for reliable, scalable, distributed computing.]. A major factor to choose AVRO is its support for JavaScript and the fact it supports versioning of schemas. When developing microservices those aspects are extremely important and allow service operators to easily declare their custom binary protocols which can be shared and used in a decentralized way where service users only ever need the public schema (hosted perhaps on the blockchain - since even the schemas can be efficiently encoded to binary data) in order to communicate with a microservice.
 
To solve the slowness of sending each transaction over a new connection we've added a new channel to the existing websocket handlers. You can now open a websocket connection and leave it open, not needing to connect again you can now send binary transactions over the already open connection. For now this channel supports only one operation, to broadcast a single transaction, but we expect this RPC mechanism to grow to support more methods in the future.

And the cool thing is you can use this super fast transport from everywhere where there is Websocket support, this includes everywhere the HEAT-SDK can be used (browser, mobile, nodeJS).

Playing around, we've already seen huge speeds. On my PC alone we could already reach over 2000 transactions a second for the duration of 500,000 transactions. This was done with 4 websocket connections and after pre-generating and signing the 500,000 transactions. That particular node was forging but with no connected peers, for that to be possible we need to update the P2P layer still.

Currently we are working on completing the RPC and AVRO binary data support to HEAT-SDK so that all this can be used simply by getting HEAT-SDK.
When that is ready we'll be hosting the custom HEAT server somewhere and we'll release some in-browser samples that people could use to fire transactions at the HEAT instance. Would be fun to see what numbers it can do, I know you guys like breaking things.  ;D

Thanks for sticking around! And let's make HEAT great again.

5
General HEAT Discussion / Heat server 2.2.0 - Mandatory update
« on: December 02, 2017, 11:59:40 PM »
Heatledger 2.2.0

This is a mandatory update, all nodes on the network need to run this version
or higher.

Nodes below 2.1.0 will automatically be blacklisted with this version.

UPGRADE INSTRUCTIONS [upgrade only, new installations can ignore]

This version will perform a full rescan of the blockchain upon first use, this
happens automatically.

API Documentation

Please look here for API docs https://heatwallet.com/api

List of updates/fixes/features.

- fixes bug involving the last hard fork and the way expired orders are handled

Download here:

https://github.com/Heat-Ledger-Ltd/heatledger/releases/tag/v2.2.0

6
General HEAT Discussion / Core development update
« on: December 01, 2017, 12:19:20 PM »
The reason we needed the hard fork so badly was because of a bug.

It turned out through a not so obvious coding error that when you'd send HEAT to yourself it would incorrectly affect your forging stake. Not your spendable balance, only the amount of stake considered by the protocol.

What went wrong was that where a transaction comes in and is first processed two objects where instantiated, one for the sender account and one for the recipient account. These objects are passed on to lower level operations where depending on the transaction types these account objects are updated and these updates are recorded to a versioning mechanism.

What happened was that when the objects where first created some initial balance info was kept in object memory and when we first saved the sender object and later the recipient object, it turned out that updates to the first where not available to the second.

Solution was to check if sender and recipient are equal and simply instantiate a single object.

The fork was kindof difficult since we could not foresee if anyone would trigger this in between us releasing the update and the fork height. To deal with this at the fork height we had to make a scan of the blockchain (which luckily can do that in about a second) to search for offending transactions and correct the account stake for those accounts.

All in all the effect has been that just some of these payments have occurred and always with low amounts, the single large transfer was reported to us and we did the fork within the week.

-------------

Apart from this work has been progressing on finalizing the microservices, lets call it version 2. The main difference being that the usage has been greatly simplified, the api as published in heat-dev-kit will remain the same for the most part but some of the more difficult aspects are handled by the heat platform now and dont need any work on the part of the microservice author.

Its hard to describe this in a few words, but I'll try anyway..

Because of the nature of a decentralized consensus network, basically being decentralized, it can happen that the order of transactions differ at different points in the network. Since microservices are invoked through transactions a microservice had to be aware of this fact. Another aspect of a blockchain is that blocks get generated and accepted at some point, while at a later moment a better block could come along which required the old one to be undone and the new one to be applied, this also had to be handled by your microservice.

These two things are handled now by a transaction cache solution which is at the heat core, this cache ensures transactions are reported to your microservice only once and in case the order of transactions changes only the transaction that has shifted position is reported to your microservice.

The cache is also persisted to disk so that when you redownload the blockchain or rescan it, your microservices are not invoked again.

Off to slush now for the second day in a snowy Helsinki.

7
HEAT Wallet discussion / New releases server 1.1.0, client 2.0.0
« on: June 30, 2017, 01:33:31 PM »
New client [2.0.0] and server [1.1.0] releases

Desktop version with server: https://github.com/Heat-Ledger-Ltd/heatwallet/releases/tag/v2.0.0
Desktop version with out server: https://github.com/Heat-Ledger-Ltd/heat-ui/releases/tag/v2.0.0
Server only: https://github.com/Heat-Ledger-Ltd/heatledger/releases/tag/v1.1.0


Heat Wallet 2.0.0

Includes Heat Server 1.1.0, see below for details.

The HEAT 2.0 client consist of a major rewrite/improvement of the core workings as well of a brand new look and feel in line with the newly developed Heat Ledger Ltd corporate styling.

Focus has been on improving usability as well as performance, security and application stability.

Some of the improvements are:

  • your registered email account id is displayed now instead of the numeric id
  • others can address you now by your email account id
  • when sending heat, assets or messages there now is search as you type auto complete support which makes finding other accounts a breeze
  • wallets can now be imported and exported from/to your browser or the desktop app
  • individual accounts can be imported and exported using just their secret phrase
  • block explorer search for accounts, transactions, blocks
  • block explorer data display improvements
  • display assets issued and held by any account
  • preview message and display of full message in account history
  • exchange order expiry time period picker
  • deposit and withdrawal buttons for Heat Ledger certified asset gateways
  • fixed asset launch time display
  • real-time chart ticker picks up trades as they occur
  • uncertified markets hidden by default, expandable through clicker
  • improved trollbox chat with cryptographic identity proof (click on name to inspect account in real time in block explorer)


Heatledger 1.1.0

While this version is backward compatible with previous versions when it comes to the p2p protocol level operations. To use the new 2.0 class of the HEAT clients you will need this upgraded version since those clients depend on extensions to the API not available in previous versions.

Focus for the 1.1.0 release has been on increasing system stability by hardening the existing code to better deal with multi threaded access to the core HEAT storage components (basically the blockchain itself).

In the upcoming versions of the HEAT server product focus will shift to replacing the peer 2 peer system inherited from HEAT's NXT origins (the p2p code is the last piece of original NXT code).

Now that this step was made, the core is ready to be used by the new intelligent and fast HEAT p2p protocol, the final bottle neck towards reaching transaction processing at lightning speeds.


8
Heat Ledger 1.0.0-b1 (server)

This is a mandatory update, every one must update to this version before we reach the block with height 232,000. At this height the protocol will start rewarding accounts that find a block again. Block 232,000 is expected in three days from the moment of this release.

This version comes with a new byte format for the central blockchain/blocks file which is basically the physical blockchain inside HEAT. Because of the nature of the HEAT blockchain being a flat (memory mapped) file (instead of a database) a migration from one to the other format proved difficult. An easier solution was if users delete their current chain and download a new one from the network.

When running this version for a first time we automatically delete and redownload blockchain/blocks, this happens only once.

To make this process as safe as possible we've added two full chain checkpoints at height 185,000 and one at height 221,250. While you download and you reach that height a digital finger print (SHA256) of all previous blocks is created and compared to the finger print we hard coded in the source code.

This release disables heat.forgingDelay and heat.forgingSpeedup configuration options, this should equalize forging changes.

Various other smaller bug fixes have been applied to this release.

Server version: https://github.com/Heat-Ledger-Ltd/heatledger/releases/tag/v1.0.0-b1
Desktop (windows or linux): https://github.com/Heat-Ledger-Ltd/heatwallet/releases/tag/v1.0.17

9
HEAT Wallet discussion / Heatserver 0.9.29 released.
« on: April 03, 2017, 11:24:29 PM »
Please update your servers. Mandatory update!

Heatledger 0.9.29 - The HEAT is on!

Heatledger 0.9.29

This is a mandatory update, all nodes on older versions must update.

While on [testnet](https://github.com/Heat-Ledger-Ltd/heatledger-test) 8 other releases have come and gone please refer to testnet repo for details on those.

This release fixes most if not all of the forking issues we experienced before plus it enables the new realtime websocket connectors already integrated in both the web and desktop clients.

Forging rewards stay disabled. When this release proves to be stable we will put out another release which will enable forging rewards. This is to be expected by Friday 7'th of April.

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

10
HEAT Wallet discussion / Heatwallet 1.0.13 and server 0.9.18
« on: March 07, 2017, 09:40:05 PM »
Server release

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

Desktop release

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


Mandatory update will do a hard fork at 105,000.

This release fixes several bugs and disables miner rewards at the fork height.

In order to provide a better download experience when downloading the blockchain you will only
download from the default wellknown peers, this way preventing you from ending on a fork again.
Once the chain is downloaded in full you will connect to all peers on the network.

A bug was fixed where unconfirmed bid order cancellations where not properly persisted to the data
storage, causing both the virtual balance to be wrong and allowing a secondary order cancellation
which would later not make it into a block but will mess with the replicator database model.
The client now properly shows if an order is cancelled even if the cancellation is still unconfirmed,
unconfirmed order cancellations are now shown with strike trough text until the next block fully
removes them.

11
HEAT Wallet discussion / Heatwallet 1.0.12 and server 0.9.16
« on: March 02, 2017, 09:08:43 PM »
Heatledger 0.9.16 & Heatwallet 1.0.12

Mandatory update, this release will blacklist nodes that are on a version below heatldeger 0.9.15.

Unconfirmed transactions in 0.9.15 and before (up to 0.9.14) where not removed properly when a block
was generated. This release will properly remove these transactions.

A bug some places referred to as the 50% bug was caused by this.
Please update your nodes, especially if you are mining blocks. It will take some time for all 50% bug transactions
to timeout before those are not seen anymore.

We have seen that sometimes (probably due to network state) your blockchain download halts, we've
found that if this is the case simply stopping and restarting will downloading the full chain.
We'll be fixing this issue for the next release.

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

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

12
HEAT Wallet discussion / Heatwallet 1.0.11 and server 0.9.15
« on: March 01, 2017, 01:20:08 PM »
Desktop release

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

Server release

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

Contains heatledger 0.9.15. This is a mandatory update. Nodes below 0.9.14 will be blacklisted.

We especially ask medium to large stake holders to switch to this version preferably also
downloading the chain from the network.

Heatledger server 0.9.15 will do a hard fork at block 87,000. The fork at 87,000 will change the way
block generators validate order cancellations, the previous way that was done, in some cases,
was a cause for forks.

We've also changed the way public keys for accounts are stored and versioned, this was the other
reason forks used to happen.

With these two fixes combined we hope to have concluded the final solution for our forking issues.

Given the expected stability of this version we also already have hard coded block height 100,000
at which forging rewards will start again.

Work planned for these coming days might cause us to release another version before that but that
will most likely be an optional release which only involves the replicator database parts. So installing
this version should be enough to be able to start collecting block rewards again at block 100,000 which
will be seen in about 5 days from now.

The windows installer was switched to NSIS installer platform, it is highly advised that you uninstall
any previous heat windows desktop software before installing this version.

13
HEAT Wallet discussion / Heatledger server 0.9.9 and desktop wallet 1.0.8
« on: February 16, 2017, 12:29:11 AM »
New server release.

Heatledger 0.9.9

This is a mandatory update, all nodes on or below 0.9.8 will be blacklisted.

This release fixes the issue with unconfirmed transactions not being accepted by other peers. Transactions can now be send and received over the network like before.

We've introduced the Upgrader internal component, this helper component allows us to place version specific one time upgrade tasks in new releases. Mostly this will help in you keeping your blockchain and not needing to download it again.

The upgrade function for this release will one time scan and validate your blockchain on startup. It could be you have been running 0.9.8 and are therefor blacklisted by other peers. This blacklisting should take no longer than 10 to 20 minutes.

Forging has not yet been enabled for this release, if all goes well we'll enable forging and rewards again in the coming days.

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

New desktop versions

Heatwallet 1.0.8 contains heatledger 0.9.9

New desktop release to accompany the server release.

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

14
HEAT Server issues / HEAT Technical Progress
« on: November 07, 2016, 12:03:49 AM »
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.

15
HEAT Wallet discussion / Release: heat-ui 0.1.1 [ALPHA] With ICO Claim
« on: October 18, 2016, 04:03:23 PM »
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-----

Pages: [1] 2