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

HEAT Forum

September 18, 2019, 04:57:47 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.

Messages - verymuchso

Pages: 1 [2] 3
16
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

17
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.

18
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

19
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.

20
Copied that reply for later use.
Spot on  ;)

21
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

22
HEAT Server issues / Re: HEAT Technical Progress
« on: December 27, 2016, 03:40:25 PM »
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.

23
HEAT Wallet discussion / Re: Chance for trading bot in default client?
« on: December 09, 2016, 05:53:33 PM »
Wow, that looks pretty nice!

A leg up for javascript programmers!  Any chance some smart bot code finds its way to the community so anybody can run bots, if they desire?

Microservices are npm packages, the idea being that people will publish their js code on npmjs.org.
So yes, the fact that code can be shared and re-used is a major part of microservices success.

24
HEAT Wallet discussion / Re: Chance for trading bot in default client?
« on: December 08, 2016, 08:10:34 PM »
Anyone will be able to code his trading bot (and a lot more) using nothing but HEAT microservices, you'll need to code your bot in javascript and put it in a folder inside your heat installation. Your microservice javascript code will run in the HEAT java scripting engine and gives access to all blockchain events in realtime.

You can send payments/assets/make-cancel orders etc.. all from your javascript project. Microservices are npm compatible which means you can use a good amount of the nodejs packages at https://www.npmjs.com.

Progress can be followed here.. https://github.com/Heat-Ledger-Ltd/heat-microservice
Npm package: https://www.npmjs.com/package/heat-microservice

To get an idea on how its supposed to be used: http://paste.ubuntu.com/23595093/ (thats supposed to do BTC payments from your microservice, just to get an idea).

I've always liked this idea .. a lot .. mentioned it for the first time over a year ago https://nxtforum.org/general-discussion/price-speculation/msg207782/#msg207782 really happy to see it become reality after all this time.

25
Jobs / rewards / Re: [BOUNTY 0.25 BTC] Comparison of HEAT vs. competitors
« on: December 06, 2016, 05:25:06 PM »
"API based on standard ..." could also be a good one.
Would come down to NONE, OPENAPI or https://apiblueprint.org/ (dont know any other).

HEAT does openapi, afaik waves also should be openapi compatible although not sure if operational/completed.

26
Jobs / rewards / Re: [BOUNTY 0.25 BTC] Comparison of HEAT vs. competitors
« on: December 06, 2016, 05:15:28 PM »
Seems a lot that is not on any of those charts is going on in heat.
What comes to mind.

  • Architecture ready to scale in size (no limit to blockchain size)
  • Ready to scale in speed (give it enough RAM/CPU and it will eventually [needs further optimizations - but possible] do 50,000+ tx/s)
  • Asset exchange that does asset-to-asset, issue more assets, private assets with custom rules
  • Support for javascript based micro services that run in the heat core
  • Asynchronous networking (akka) and 2nd generation (smart) p2p network
  • Perhaps also a comparison of block/acocunt/txn storage (heat has a custom built - specifically for crypto storage solution)
  • Not sure how to compare replication? Seems most other coins dont have that functionality defined as such and made it a reusable feature for 3rd party developers
  • Highly modular/reusable client framework (some/most crypto clients/ui are true pieces of crap)
  • etc..

Btw. with micro services i'm talking about the Decentralized Services concept mentioned in the whitepaper.
Somehow it seems micro service is a much better term https://smartbear.com/learn/api-design/what-are-microservices/

27
HEAT Server issues / Re: HEAT Technical Progress
« on: December 05, 2016, 03:09:17 PM »
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

28
HEAT Server issues / Re: HEAT Technical Progress
« on: November 07, 2016, 02:07:12 PM »
Wouldn't this open up the possibility of having old data still reside in the objects?

Yes it does. Extra care is required because of this.

But the pay-off also is very big, during normal operations there is lots and lots of iteration over transactions and blocks going on all the time. Since those are stored in chronicle-map persisted maps and those in turn offer off-heap (no java mem) data access, re-populating (and not holding on to) blocks and transactions during iterations pay of in a big way.

Are any of the outstanding NXT redemption transfers going to be completed so NXT users can claim their HEAT?  I'm still waiting... I have a zero balance so I can't just use my own NXT to claim the ICO funds.
http://heatledger.net/index.php?topic=20.msg245#msg245

Best to contact Svante for such questions.
There also is a built-in live support widget in the ico claim part of the client.

29
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.

30
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] 3