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

HEAT Forum

December 15, 2017, 06:18:23 AM
News: 2017-10-10 Heatledger 2.0 with Heatwallet 2.2.0 released! NOTE: Balance leasing and hard fork at block 777777

Recent Posts

Pages: [1] 2 3 ... 10
HEAT Markets and trading / Re: My FIMK didn't show up after deposit
« Last post by xartifex on December 14, 2017, 07:12:10 PM »
HEAT Server issues / Re: Another stuck BTC withdrawal
« Last post by ragtag on December 13, 2017, 07:20:46 PM »
this is resolved..just took some time as mentioned in popup
General HEAT Discussion / HEAT clocking in at 2000 t/s - Over the network !!
« Last post by verymuchso on December 13, 2017, 06:13:42 PM »
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:


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. 


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 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 which is the data serialization stack from [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.
HEAT Server issues / Another stuck BTC withdrawal
« Last post by ragtag on December 12, 2017, 10:40:35 PM »
hi Eliphaz,

 I have another withdrawal stuck. Could you please take a look?

signature: "9540ace23d790eca2d143befdeee3e533592ba892975d2b23127602b8b17b000dfe2e5956ee5d75e031152d09f7909d965b55ac4d5d9690a50cdfa59fcbb6550"
fee:  "1000000"
transactionIndex: -1
type: 2
ecBlockId:  "13534631514896190578"
signatureHash: "84caca8c03e8fce7cd3107511c70abf29d9ab16d1e9d5cfb49e54be93d4115b2"
 attachment: Object
messageIsEncrypted: true
subtype: 2
messageIsText: true
block:  "0"
blockTimestamp: -1
deadline: 1440
timestamp: 127811044
height: 912766
senderPublicKey: "4a96dce5375a8f4e0ab12f1625da0d0e32690ab1630d123ac7337e1eb6437e05"
amount:  "0"
messageBytes: "467a2fd34130babbf61da8f41778a734be2dd7b9ca8a354e3f2c6aeec4cecb033489e9b942ce12607b974cb36739ba43ec4485a77bde1088582f499a2ee7c14f39ed82702cb86aa23bb5a6bdcdb44ea396f8c27c76c7bc68784afe2efcb48a8e259ebee039c68a632194286c2ac13f87"
recipientPublicKey: "2eb8137e3caefb6b14088107e96f02752b8e0ee685afea280587867119dff14d"
confirmations: 3
fullHash: "63688957b3d6bc3df9855262122f4586dd68a74efd8ac734b7af8c3d59c6224a"
version: 1
recipientPublicName:  "Heat Ledger Ltd"
sender:  "3618719189254554333"
recipient:  "9583431768758058558"
ecBlockHeight: 912744
senderPublicName: null
transaction:  "4448666597691320419"
time:  "2017-12-12 13:04:04"
heightDisplay: 912766
renderedInfo: "<b>TRANSFER ASSET</b> <b>BTC</b> from <a href="#/explorer-account/3618719189254554333/transactions">3618719189254554333</a> to <a href="#/explorer-account/9583431768758058558/transactions">Heat Ledger Ltd</a> amount <span>0.16783188 </span>"
messageText:  "1C4AcsQhComfx1d85pgV81rVGABd47DVXB"
messagePreview:  "1C4AcsQhComfx1d85pgV81rVGABd47DVXB"
HEAT Server issues / Re: Insufficient funds
« Last post by VonGraff on December 12, 2017, 10:31:03 PM »
Guess I was the one helping you out as well via the trollbox, nice coincidence! Glad you can continue!
HEAT Server issues / Re: Insufficient funds
« Last post by ragtag on December 12, 2017, 04:47:09 PM »
thank you VonGraff. Will keep that in mind
HEAT Server issues / Re: Insufficient funds
« Last post by VonGraff on December 12, 2017, 08:11:55 AM »
You need hear for every transaction in the wallet, 0.01 heat is the fee per action. You can ask for a minor deposit on the trollbox with your acc number.

Never sell ALL your heat.
General HEAT Discussion / Re: OrgiOrg Leasing Pool
« Last post by OrgiOrg on December 11, 2017, 10:15:19 PM »
yes! 1842674054425679153 .... sorry ... i fixed it!
HEAT Server issues / Insufficient funds
« Last post by ragtag on December 11, 2017, 05:31:28 PM »

This maybe a bug. I am trying to withdraw and it shows the below and then i click submit, it says insufficient funds. How do I resolve?

Amount (BTC)
You will receive

Heat left in account : 0.00834162


General HEAT Discussion / Re: OrgiOrg Leasing Pool
« Last post by loylyaLissee on December 09, 2017, 08:19:58 AM »
i changed my pool offer ... 0% fees till the end of march 2018; offer exists for every account

Lease you HEAT to:  1842674054425679153

***** OFFER TILL THE END OF 2018-03-31 *****

! 0% fee ... payouts will be done automatically in the first april week of 2018 !

*** **** *** **** *** **** *** ****

Just 1% fee for keeping server online and manage funds

To claim your earnings, simply send a message via HEAT wallet to the pool account 9634482525377050118 and after this message has 1440 comfirmations, your confirmed earnings will be sent to you, minus 1% management fee + heat standard fee.

Happy Earnings!

Old pool address in the quote (9634482525377050118), should be 1842674054425679153?
Pages: [1] 2 3 ... 10