Topic: HEAT Discussion and Technical info - page 40. (Read 61463 times)

Thanks! Much appreciated.

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

We are sorry for the inconvenience but the most recent hard fork introduced a bug which is now fixed.

This means https://heatwallet.com/#/explorer is back in business and fully functional.

We will be releasing a new server, version 2.2.0 which is a mandatory update.

The release of the new server version is expected in 1 hour to be precise at 23.00 CET.

We will update you here with the download location.

Desktop versions with the new 2.2.0 version embedded will follow at a later time.

We are currently running 2.2.0 on the company servers and are mining blocks initially with a company account, we will donate the forger rewards to a goal to be decided upon with the community. When enough forgers are mining blocks again on version 2.2.0 we will stop mining blocks with the company account.

https://heatwallet.com/api/#!/Tools/encode

Can't read from server. It may not have the appropriate access-control-origin settings.

hallmark creation doesn't work

since ever its executed nicely.

117 USD - 24hr Volume.

As long as this coin is not on a big exchange like Bittrex and Binance, none is gonna care about the tech you are developing...................................

Unconfirmed transactions on the wallet that don't go through to blocks due to a race condition etc. should be timed out within 24 hours from initiation. We're investigating whether the current circumstances of unconfirmed lingering around is a coincidence (unlikely) or something else that needs more attention. Valid transactions not related to the unaccepted ones are propagated fine, but of course almost nobody dares to put in any orders under the current state of things on the exchange easily looking worse than it is.

the wallet does not work.

HEAT seems to be a highly profitable coin to mine... does anyone know of other coins like this? ive honestly never come across a coin link HEAT when it comes to mining. im not interested in mining other coins, id rather put my funds into HEAT to increase my rewards. just wondering how rare an opportunity like this is.

i absolutely cannot believe how much i am making through mining, it feels too good to be true.

Hey all!

Could someone advise with the below?

I cancelled a buy order for BTC-Bismuth on the Heat Ledger exchange about 6 hours ago.

The buy order has been "crossed out" but the BTC has not yet become available in my BTC wallet.

Under my transactions, the order is still processing ("..." under the "height column")

When I cancelled a buy order previously it was instantaneous.

Strange that it's taking so long for the cancellation to come through... has anyone else run into this issue?

Thank you!

Spizike

Whoever runs https://heatbrowser.com/report.html can you please upgrade.

Thanks for the updates, HEAT is indeed running very stable here!

Looking forward to whatever might come out of the Slush connections!

Respect to the team for coping with seemingly complex technical stuff and also explaining it.

It looks like HEAT is getting more and more into shape recently.

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.

I second that idea. Lets all migrate. Slack is becoming a little bit..... slack. lol.

http://prntscr.com/hhlr21

* 10823382892610793695 :   179,618 HEAT :  13 blocks :    52 pos :    52 pop :   104 HEAT :   8,815 HEAT/mo :  4.91 %/mo :  0.2742 BTC/mo :  2,703.00 $/mo :        :
  13746537426497637824 :   147,698 HEAT :   4 blocks :    16 pos :    16 pop :    32 HEAT :   2,712 HEAT/mo :  1.84 %/mo :  0.0844 BTC/mo :    831.69 $/mo :  2.1.0 : 67.207.80.42
   1163728317732161150 :   132,147 HEAT :   3 blocks :    12 pos :    12 pop :    24 HEAT :   2,034 HEAT/mo :  1.54 %/mo :  0.0633 BTC/mo :    623.77 $/mo :  2.1.0 : 163.172.182.157
* 13598124706310095065 :   106,874 HEAT :   6 blocks :    24 pos :    24 pop :    48 HEAT :   4,069 HEAT/mo :  3.81 %/mo :  0.1266 BTC/mo :  1,247.54 $/mo :        :
*  8216795573170774625 :    95,175 HEAT :   8 blocks :    32 pos :    32 pop :    64 HEAT :   5,425 HEAT/mo :  5.70 %/mo :  0.1688 BTC/mo :  1,663.38 $/mo :        :
 
I am trying to understand how heat forging rewards are distributed and calculated, however, I am unable to comprehend that A/c# 13746537426497637824 with 147,698 HEAT forged only 4 blocks while

* 13598124706310095065 :   106,874 HEAT :   6 blocks
*  8216795573170774625 :    95,175 HEAT :   8 blocks

as well as

* 10823382892610793695 :   179,618 HEAT :  13 blocks

Am I missing something? or is it genesis account get more forging blocks or what else am I missing? why the person have less/low heat is forging more blocks then the one having more than 50% heat balance is forging barely half blocks?

any insights on heat forging reward optimizations ?

Greetings from Slush.org!

This year the HEAT team has strong unofficial presence with both founders and two advisors sourcing new contacts and probing interest for ICO / ITO arrangements on HEAT. The legal and regulatory infrastructure is constantly moving forward and later this year we expect to be able to launch the first ITOs, starting with Heat Ledger's own shares sale.

We're attending the event until it ends early hours Saturday morning.
The HEAT Slack group is indeed currently experiencing trouble adding new users. Solution is being worked on.

Maybe let's move to telegram

still on my watchlist.
Good things take time lol