When will we be able to withdraw coins other than BTC? IGNIS for example?
Thanks!
Topic: HEAT Discussion and Technical info - page 25. (Read 61463 times)
Heatlegendspool has changed the payout percentage effective from tomorrow. The original monthly ROI of 3.97% has been reduced to 3.81% as the last couple of weeks has shown it to be challenging to maintain that high of a percentage. Hopefully the lessors are happy with the service this far and keeps on leasing to the pool. The rules still stays the same, even in case of a mainnet failure the pool will guarantee a daily payout for any ongoing forging period during the network crash.
www.cryptocurrencies.fi/heatlegends-pool
www.cryptocurrencies.fi/heatlegends-pool
How do I enable the wallet to run as a full on forging HEAT node.
Wow.. Sounds really nice.
Newbies. Dont mind berry her life mission is spreading fud about heat. 3-4 diffrent accounts. < thats proven fact.
Newbies. Dont mind berry her life mission is spreading fud about heat. 3-4 diffrent accounts. < thats proven fact.
Back from the sun to the snow!
During the week's time off from office I visited Malta and met with an old business acquaintance with whom we've more recently been laying the base for a high profile ICO of a new fiat related token based on HEAT tech. Considerable progress from prior negotiations was achieved and though not certain, the co-op feels at this point probable. Potential is very high due to the ties to regulatory bodies in both Malta and Switzerland (both on the leading edge of blockchain friendly business environment) and top level financial connections our partner has been building for the most part of the past year.
These developments connect nicely to the long terms goals of Heat Ledger Ltd. Meanwhile, as Dennis' last update from a couple of days back indicated the tech development on other fronts is moving nicely. We should definitely have visible releases in a form or another in 1-2 weeks from now, and a more extensive sitrep around the first half of February. I'd like to make a habit of writing a monthly overview on Medium as our previously available Crypto Roundup hasn't been published for a good while. Let's see how that plays out!
During the week's time off from office I visited Malta and met with an old business acquaintance with whom we've more recently been laying the base for a high profile ICO of a new fiat related token based on HEAT tech. Considerable progress from prior negotiations was achieved and though not certain, the co-op feels at this point probable. Potential is very high due to the ties to regulatory bodies in both Malta and Switzerland (both on the leading edge of blockchain friendly business environment) and top level financial connections our partner has been building for the most part of the past year.
These developments connect nicely to the long terms goals of Heat Ledger Ltd. Meanwhile, as Dennis' last update from a couple of days back indicated the tech development on other fronts is moving nicely. We should definitely have visible releases in a form or another in 1-2 weeks from now, and a more extensive sitrep around the first half of February. I'd like to make a habit of writing a monthly overview on Medium as our previously available Crypto Roundup hasn't been published for a good while. Let's see how that plays out!
This is exciting to say the least.
Back from the sun to the snow!
During the week's time off from office I visited Malta and met with an old business acquaintance with whom we've more recently been laying the base for a high profile ICO of a new fiat related token based on HEAT tech. Considerable progress from prior negotiations was achieved and though not certain, the co-op feels at this point probable. Potential is very high due to the ties to regulatory bodies in both Malta and Switzerland (both on the leading edge of blockchain friendly business environment) and top level financial connections our partner has been building for the most part of the past year.
These developments connect nicely to the long terms goals of Heat Ledger Ltd. Meanwhile, as Dennis' last update from a couple of days back indicated the tech development on other fronts is moving nicely. We should definitely have visible releases in a form or another in 1-2 weeks from now, and a more extensive sitrep around the first half of February. I'd like to make a habit of writing a monthly overview on Medium as our previously available Crypto Roundup hasn't been published for a good while. Let's see how that plays out!
Cool, always glad to hear such great news. During the week's time off from office I visited Malta and met with an old business acquaintance with whom we've more recently been laying the base for a high profile ICO of a new fiat related token based on HEAT tech. Considerable progress from prior negotiations was achieved and though not certain, the co-op feels at this point probable. Potential is very high due to the ties to regulatory bodies in both Malta and Switzerland (both on the leading edge of blockchain friendly business environment) and top level financial connections our partner has been building for the most part of the past year.
These developments connect nicely to the long terms goals of Heat Ledger Ltd. Meanwhile, as Dennis' last update from a couple of days back indicated the tech development on other fronts is moving nicely. We should definitely have visible releases in a form or another in 1-2 weeks from now, and a more extensive sitrep around the first half of February. I'd like to make a habit of writing a monthly overview on Medium as our previously available Crypto Roundup hasn't been published for a good while. Let's see how that plays out!
Back from the sun to the snow!
During the week's time off from office I visited Malta and met with an old business acquaintance with whom we've more recently been laying the base for a high profile ICO of a new fiat related token based on HEAT tech. Considerable progress from prior negotiations was achieved and though not certain, the co-op feels at this point probable. Potential is very high due to the ties to regulatory bodies in both Malta and Switzerland (both on the leading edge of blockchain friendly business environment) and top level financial connections our partner has been building for the most part of the past year.
These developments connect nicely to the long terms goals of Heat Ledger Ltd. Meanwhile, as Dennis' last update from a couple of days back indicated the tech development on other fronts is moving nicely. We should definitely have visible releases in a form or another in 1-2 weeks from now, and a more extensive sitrep around the first half of February. I'd like to make a habit of writing a monthly overview on Medium as our previously available Crypto Roundup hasn't been published for a good while. Let's see how that plays out!
During the week's time off from office I visited Malta and met with an old business acquaintance with whom we've more recently been laying the base for a high profile ICO of a new fiat related token based on HEAT tech. Considerable progress from prior negotiations was achieved and though not certain, the co-op feels at this point probable. Potential is very high due to the ties to regulatory bodies in both Malta and Switzerland (both on the leading edge of blockchain friendly business environment) and top level financial connections our partner has been building for the most part of the past year.
These developments connect nicely to the long terms goals of Heat Ledger Ltd. Meanwhile, as Dennis' last update from a couple of days back indicated the tech development on other fronts is moving nicely. We should definitely have visible releases in a form or another in 1-2 weeks from now, and a more extensive sitrep around the first half of February. I'd like to make a habit of writing a monthly overview on Medium as our previously available Crypto Roundup hasn't been published for a good while. Let's see how that plays out!
Short dev update here.
Just to give you an idea of whats going on behind the scenes.
As we know Svante has been out on a trip this week taking some well deserved rest from the past hectic year, yet still combining that with meetings with potential future HEAT partners and customers.
We'll hopefully be hearing from our refreshed HEAT CEO soon.
Meanwhile while Svante was enjoying his trip, we have been working on other parts.
As mentioned before, in networking whether thats inter-machine (peer 2 peer) but also user to machine (HEAT API - broadcast transactions and lookup of blockchain state [most recent trade, order, etc]) probably the biggest bottle neck is the encoding and decoding of messages. In HEAT and in some form at least every other cyptocurrency these messages are almost exclusively in JSON, which is very flexible but also very costly to decode and encode.
So there is this dilemma, JSON is flexible and simple to use but bloated and slow to process. And on the other hand you have binary data which is the most optimal/minimal representation of data and the absolute fastest to both encode and decode, but its not flexible at all. Binary data consists of a list of bytes (8 fields each consisting of a 1 or a 0), each field in your message following the last one.
Such binary data is super efficient and can speed up processing and transfer costs hundred folds depending on the exact data of course.
However once we hard code our client, heat-sdk, microservice message or heat server to handle this one specific data structure in this highly optimized list of bytes, well thats where it ends. Dont try and update the structure (add one field, or change a fields type) since thats a nightmare. Also you would have to write hard to both write and maintain code for each separate app that handles these complicated binary data, on top you have to hand code how to both read and write that data.
For us it became clear what we need here. Which is of course the flexibility of JSON but as optimized as pure binary data.
This is especially important when we want to start using structured messages to send to microservices, but having to store them on chain.
So that and other things simply have to be done efficiently, while interoperability is almost as important.
Well we've made progress, we're happy to yesterday have committed both the heat server implementation and with heat-sdk the universal impl which runs on your server, browser and mobile and which gives us a cross language, cross device binary encoding solution with the flexibility that JSON gives you. The schemas you need to share among two end points in order to read and write each others structured binary messages is actually JSON itself.
To get an idea of how we define these data structures you can already look in the development branch on the public heat-sdk repo, https://github.com/Heat-Ledger-Ltd/heat-sdk/blob/avro/src/types.ts.
The whole commit for the full thing can be seen here https://github.com/Heat-Ledger-Ltd/heat-sdk/commit/6808cafdd2d6f0eb6dca161f474ee5a4e7d44316?diff=unified.
The server code update also involved a RPC solution where you can communicate with heat server over a websocket but using a binary transport.
As mentioned on the bitcointalk thread before we did a test where we used a binary always open websocket connection and a set of pre-generated binary representations of transactions to be broadcasted and we found that we could already do 2000 transactions per second that way. That finally showed our custom storage backend being put to good use.
Well now we've completed the server code and formalized the mechanism and added support for server, mobile and browser cross device but compatible binary message transport, all through our heat-sdk.
We are writing tests for heat-sdk and plan to release what will be version 0.10 already so we can get to the long awaited 2000tps public test which will run from your browser.
After that microservices are up for finalization where this schema based binary protocol will play a key role in how we abstract both microservice invocations and the automatic generation of UI/forms to interact with microservices.
--
Our binary schemas are based on https://en.wikipedia.org/wiki/Apache_Avro, while on the server side we use the official java libs. In heat-sdk we' ve rolled our own implementation in part by extracting just the encode/decode parts from avsc js lib while making that one run in both the browser and in nodejs.
Just to give you an idea of whats going on behind the scenes.
As we know Svante has been out on a trip this week taking some well deserved rest from the past hectic year, yet still combining that with meetings with potential future HEAT partners and customers.
We'll hopefully be hearing from our refreshed HEAT CEO soon.
Meanwhile while Svante was enjoying his trip, we have been working on other parts.
As mentioned before, in networking whether thats inter-machine (peer 2 peer) but also user to machine (HEAT API - broadcast transactions and lookup of blockchain state [most recent trade, order, etc]) probably the biggest bottle neck is the encoding and decoding of messages. In HEAT and in some form at least every other cyptocurrency these messages are almost exclusively in JSON, which is very flexible but also very costly to decode and encode.
So there is this dilemma, JSON is flexible and simple to use but bloated and slow to process. And on the other hand you have binary data which is the most optimal/minimal representation of data and the absolute fastest to both encode and decode, but its not flexible at all. Binary data consists of a list of bytes (8 fields each consisting of a 1 or a 0), each field in your message following the last one.
Such binary data is super efficient and can speed up processing and transfer costs hundred folds depending on the exact data of course.
However once we hard code our client, heat-sdk, microservice message or heat server to handle this one specific data structure in this highly optimized list of bytes, well thats where it ends. Dont try and update the structure (add one field, or change a fields type) since thats a nightmare. Also you would have to write hard to both write and maintain code for each separate app that handles these complicated binary data, on top you have to hand code how to both read and write that data.
For us it became clear what we need here. Which is of course the flexibility of JSON but as optimized as pure binary data.
This is especially important when we want to start using structured messages to send to microservices, but having to store them on chain.
So that and other things simply have to be done efficiently, while interoperability is almost as important.
Well we've made progress, we're happy to yesterday have committed both the heat server implementation and with heat-sdk the universal impl which runs on your server, browser and mobile and which gives us a cross language, cross device binary encoding solution with the flexibility that JSON gives you. The schemas you need to share among two end points in order to read and write each others structured binary messages is actually JSON itself.
To get an idea of how we define these data structures you can already look in the development branch on the public heat-sdk repo, https://github.com/Heat-Ledger-Ltd/heat-sdk/blob/avro/src/types.ts.
The whole commit for the full thing can be seen here https://github.com/Heat-Ledger-Ltd/heat-sdk/commit/6808cafdd2d6f0eb6dca161f474ee5a4e7d44316?diff=unified.
The server code update also involved a RPC solution where you can communicate with heat server over a websocket but using a binary transport.
As mentioned on the bitcointalk thread before we did a test where we used a binary always open websocket connection and a set of pre-generated binary representations of transactions to be broadcasted and we found that we could already do 2000 transactions per second that way. That finally showed our custom storage backend being put to good use.
Well now we've completed the server code and formalized the mechanism and added support for server, mobile and browser cross device but compatible binary message transport, all through our heat-sdk.
We are writing tests for heat-sdk and plan to release what will be version 0.10 already so we can get to the long awaited 2000tps public test which will run from your browser.
After that microservices are up for finalization where this schema based binary protocol will play a key role in how we abstract both microservice invocations and the automatic generation of UI/forms to interact with microservices.
--
Our binary schemas are based on https://en.wikipedia.org/wiki/Apache_Avro, while on the server side we use the official java libs. In heat-sdk we' ve rolled our own implementation in part by extracting just the encode/decode parts from avsc js lib while making that one run in both the browser and in nodejs.
Great work!
Short dev update here.
Just to give you an idea of whats going on behind the scenes.
As we know Svante has been out on a trip this week taking some well deserved rest from the past hectic year, yet still combining that with meetings with potential future HEAT partners and customers.
We'll hopefully be hearing from our refreshed HEAT CEO soon.
Meanwhile while Svante was enjoying his trip, we have been working on other parts.
As mentioned before, in networking whether thats inter-machine (peer 2 peer) but also user to machine (HEAT API - broadcast transactions and lookup of blockchain state [most recent trade, order, etc]) probably the biggest bottle neck is the encoding and decoding of messages. In HEAT and in some form at least every other cyptocurrency these messages are almost exclusively in JSON, which is very flexible but also very costly to decode and encode.
So there is this dilemma, JSON is flexible and simple to use but bloated and slow to process. And on the other hand you have binary data which is the most optimal/minimal representation of data and the absolute fastest to both encode and decode, but its not flexible at all. Binary data consists of a list of bytes (8 fields each consisting of a 1 or a 0), each field in your message following the last one.
Such binary data is super efficient and can speed up processing and transfer costs hundred folds depending on the exact data of course.
However once we hard code our client, heat-sdk, microservice message or heat server to handle this one specific data structure in this highly optimized list of bytes, well thats where it ends. Dont try and update the structure (add one field, or change a fields type) since thats a nightmare. Also you would have to write hard to both write and maintain code for each separate app that handles these complicated binary data, on top you have to hand code how to both read and write that data.
For us it became clear what we need here. Which is of course the flexibility of JSON but as optimized as pure binary data.
This is especially important when we want to start using structured messages to send to microservices, but having to store them on chain.
So that and other things simply have to be done efficiently, while interoperability is almost as important.
Well we've made progress, we're happy to yesterday have committed both the heat server implementation and with heat-sdk the universal impl which runs on your server, browser and mobile and which gives us a cross language, cross device binary encoding solution with the flexibility that JSON gives you. The schemas you need to share among two end points in order to read and write each others structured binary messages is actually JSON itself.
To get an idea of how we define these data structures you can already look in the development branch on the public heat-sdk repo, https://github.com/Heat-Ledger-Ltd/heat-sdk/blob/avro/src/types.ts.
The whole commit for the full thing can be seen here https://github.com/Heat-Ledger-Ltd/heat-sdk/commit/6808cafdd2d6f0eb6dca161f474ee5a4e7d44316?diff=unified.
The server code update also involved a RPC solution where you can communicate with heat server over a websocket but using a binary transport.
As mentioned on the bitcointalk thread before we did a test where we used a binary always open websocket connection and a set of pre-generated binary representations of transactions to be broadcasted and we found that we could already do 2000 transactions per second that way. That finally showed our custom storage backend being put to good use.
Well now we've completed the server code and formalized the mechanism and added support for server, mobile and browser cross device but compatible binary message transport, all through our heat-sdk.
We are writing tests for heat-sdk and plan to release what will be version 0.10 already so we can get to the long awaited 2000tps public test which will run from your browser.
After that microservices are up for finalization where this schema based binary protocol will play a key role in how we abstract both microservice invocations and the automatic generation of UI/forms to interact with microservices.
--
Our binary schemas are based on https://en.wikipedia.org/wiki/Apache_Avro, while on the server side we use the official java libs. In heat-sdk we' ve rolled our own implementation in part by extracting just the encode/decode parts from avsc js lib while making that one run in both the browser and in nodejs.
Just to give you an idea of whats going on behind the scenes.
As we know Svante has been out on a trip this week taking some well deserved rest from the past hectic year, yet still combining that with meetings with potential future HEAT partners and customers.
We'll hopefully be hearing from our refreshed HEAT CEO soon.
Meanwhile while Svante was enjoying his trip, we have been working on other parts.
As mentioned before, in networking whether thats inter-machine (peer 2 peer) but also user to machine (HEAT API - broadcast transactions and lookup of blockchain state [most recent trade, order, etc]) probably the biggest bottle neck is the encoding and decoding of messages. In HEAT and in some form at least every other cyptocurrency these messages are almost exclusively in JSON, which is very flexible but also very costly to decode and encode.
So there is this dilemma, JSON is flexible and simple to use but bloated and slow to process. And on the other hand you have binary data which is the most optimal/minimal representation of data and the absolute fastest to both encode and decode, but its not flexible at all. Binary data consists of a list of bytes (8 fields each consisting of a 1 or a 0), each field in your message following the last one.
Such binary data is super efficient and can speed up processing and transfer costs hundred folds depending on the exact data of course.
However once we hard code our client, heat-sdk, microservice message or heat server to handle this one specific data structure in this highly optimized list of bytes, well thats where it ends. Dont try and update the structure (add one field, or change a fields type) since thats a nightmare. Also you would have to write hard to both write and maintain code for each separate app that handles these complicated binary data, on top you have to hand code how to both read and write that data.
For us it became clear what we need here. Which is of course the flexibility of JSON but as optimized as pure binary data.
This is especially important when we want to start using structured messages to send to microservices, but having to store them on chain.
So that and other things simply have to be done efficiently, while interoperability is almost as important.
Well we've made progress, we're happy to yesterday have committed both the heat server implementation and with heat-sdk the universal impl which runs on your server, browser and mobile and which gives us a cross language, cross device binary encoding solution with the flexibility that JSON gives you. The schemas you need to share among two end points in order to read and write each others structured binary messages is actually JSON itself.
To get an idea of how we define these data structures you can already look in the development branch on the public heat-sdk repo, https://github.com/Heat-Ledger-Ltd/heat-sdk/blob/avro/src/types.ts.
The whole commit for the full thing can be seen here https://github.com/Heat-Ledger-Ltd/heat-sdk/commit/6808cafdd2d6f0eb6dca161f474ee5a4e7d44316?diff=unified.
The server code update also involved a RPC solution where you can communicate with heat server over a websocket but using a binary transport.
As mentioned on the bitcointalk thread before we did a test where we used a binary always open websocket connection and a set of pre-generated binary representations of transactions to be broadcasted and we found that we could already do 2000 transactions per second that way. That finally showed our custom storage backend being put to good use.
Well now we've completed the server code and formalized the mechanism and added support for server, mobile and browser cross device but compatible binary message transport, all through our heat-sdk.
We are writing tests for heat-sdk and plan to release what will be version 0.10 already so we can get to the long awaited 2000tps public test which will run from your browser.
After that microservices are up for finalization where this schema based binary protocol will play a key role in how we abstract both microservice invocations and the automatic generation of UI/forms to interact with microservices.
--
Our binary schemas are based on https://en.wikipedia.org/wiki/Apache_Avro, while on the server side we use the official java libs. In heat-sdk we' ve rolled our own implementation in part by extracting just the encode/decode parts from avsc js lib while making that one run in both the browser and in nodejs.
News flash ewery invest y make there is possibility loose money if y make stupid moves.
When y look Heat charts it really needs that to loose. Expesially if u are selling them away when the biggest crash is on. Just before big releases
R: investor who is wery happy to be Heat owner. And will be wery happy (rich) if they do ewen half what promised before summer.
When y look Heat charts it really needs that to loose. Expesially if u are selling them away when the biggest crash is on. Just before big releases
R: investor who is wery happy to be Heat owner. And will be wery happy (rich) if they do ewen half what promised before summer.
look at that! https://cointelegraph.com/news/bitcoin-cash-trading-pairs-open-at-cryptocurrency-exchange so if heat would really finished the bch pair that would be a huge advance right now. but heat devs failed and i lost some $ thank you for priceless experience. zero regrets selling
Anyone knowing 11883961337716096733? It seems I have been hacked and all my HEAT have been transferred to this account. Any suggestions what I can do now?
I wonder how this could happen. I was forging on my system at home. Incoming traffic to this machine was not allowed and I did not use the web wallet...
I wonder how this could happen. I was forging on my system at home. Incoming traffic to this machine was not allowed and I did not use the web wallet...
If your machine got hacked and it had your secretphrase you would normally have lost your HEAT, I say normally since this case seems special since its send to Cryptopia exchange which is controlled by a centralized entity... Cryptopia.
In your case I suggest you'd contact Cryptopia now and provide every detail you can in the hope that they freeze the thief his/her deposit and maybe even return it to you.
I've informed Eliphaz Fimk of your situation but since he's out of office we have to await his reply.
On a more general note:
HEAT private keys are not ever allowed out the client, there are stops in place that even prevent the secretphrase from ever being included in an API call.
Only exception here is when you call an API on the localhost address, only than can a secretphrase argument ever be included.
See here: https://github.com/Heat-Ledger-Ltd/heat-ui/blob/72c15acee4132ddef278eb9404e6bc860a0a8ca9/app/src/services/heat/HeatService.ts#L183
So there is 0% change the client ever send out your secretphrase.
From your comments it seems you have been using your secretphrase to mine HEAT on a VPS.
Now there are two ways of doing this [mining on a vps]
1. There is the 'old' (unsafe) way where you'd use 'real' secretphrase on your vps to call the startmining API command
2. There is the 'new' (safe) way where you one time lease your balance to a lease-only account and use the secretphrase for that leased account on your vps.
Now when someone gets access to that second secretphrase they cant touch the funds in the main account (sort of like a cold wallet)
I was using a VPS only running HEAT Wallet on it. It is no PC I am browsing the Internet with.
So the claim is someone deposited to Cryptopia from your account? Maybe you should take this up with them too and try to resolve it with their help. They have to know to whom the deposit went, and you can prove that you own the keys to that account.
Contact Crytopia immediately. Deposits to there must include id given by cryptopia so they must know to which account those are ended
Heat ledger can't do anything to it
I was using a VPS only running HEAT Wallet on it. It is no PC I am browsing the Internet with.
So the claim is someone deposited to Cryptopia from your account? Maybe you should take this up with them too and try to resolve it with their help. They have to know to whom the deposit went, and you can prove that you own the keys to that account.
I was using a VPS only running HEAT Wallet on it. It is no PC I am browsing the Internet with.
So the claim is someone deposited to Cryptopia from your account? Maybe you should take this up with them too and try to resolve it with their help. They have to know to whom the deposit went, and you can prove that you own the keys to that account.
I was using a VPS only running HEAT Wallet on it. It is no PC I am browsing the Internet with.
Maybe y should ask heat crew.
How much did y loose? Are y onlyone who knows passphrases and pins?
Any suggestions for the best contact to them? I lost more than 20k Heat and I was the only one knowing the PIN (and never saved it digitally).How much did y loose? Are y onlyone who knows passphrases and pins?
First thing is first, did you have anti-malware and anti-virus software installed? Also, browser protection such as AdBlock or uOrigin?
If not, then you most likely caught a case of malware.
Anyone knowing 11883961337716096733? It seems I have been hacked and all my HEAT have been transferred to this account. Any suggestions what I can do now?
I wonder how this could happen. I was forging on my system at home. Incoming traffic to this machine was not allowed and I did not use the web wallet...
I wonder how this could happen. I was forging on my system at home. Incoming traffic to this machine was not allowed and I did not use the web wallet...
That is cryptopia exchanges account... do you have account there?
Facebook chat or here private messages Just tried to put y private message.
Maybe y should ask heat crew.
How much did y loose? Are y onlyone who knows passphrases and pins?
Any suggestions for the best contact to them? I lost more than 20k Heat and I was the only one knowing the PIN (and never saved it digitally). How much did y loose? Are y onlyone who knows passphrases and pins?
Jump to: