Topic: [ANN] HEAT: 3.0 crypto*multisig fiat*a2a hft*1000tps*DSA*PoS+PoP*e2ee chat* - page 221. (Read 418460 times)

BTC: 608.45 (stage 2)
ETH: 16,124.99 (stage 2)
FIMK: 255,621,021 (stage 4)
NXT: 6,220,425 (stage 2)
ETC 16,124
ARDR 6,220,425

-------------------------------
BTC 608 x 935 = $568,480

ETH 16,124 x $7 = $112,868

NXT 6,220,425 x .006c = $37,322

ETC 16,124 x $1 = $16,124
 
ARDR 6,220,425 x .012c = $74,645

total $809,439 USD received in the ICO

Now you know you have twice the money you thought you had can you hire some developers and marketing communications people?
PS IT WAS VERY CLOSE TO 1 MILLION DOLLARS.


"The amount definitely was nowhere near $1 million dollars worth of crypto. The amount is difficult to calculate because of high volatility and oftentimes lacking liquidity as in the case of FIMK. Using current, realized rates the amount raised in the first funding round of Heat Ledger Ltd lands somewhere between $300k and $400k"

lol, you misspelled scumbagging

I think they had to pay a lot of taxes. Since they are a real company, they have to abide by the tax law. Dunno how much you pay in Finland, though.

You are a sad person.

http://heatledger.ghost.io/

I quote:"HEAT Weekly crypto roundup"

Last Entry: Crypto Roundup 15 - 11 December 2016

Entry before that: Crypto Roundup 14 - 27 November 2016

It is so ridiculous, you just can't make this shit up!

It was in the OP itself, saying the release will be on 5th of September  

Not exactly IOU. They could just fork any clone coin and replace it when ever they r ready. Because of many reasons and BTC rally if people want to sell/buy then they should be able to. This assuming the DEVs are really coding

PS: I was also thinking they would release everything right after the ICO. unfortunately I can not remember where I read this. If anybody knows the source of this, please tell me!

IOU seems like a feasible idea except the prices would be non-realistic for several reasons one of them being that surrogate shittoken is not reflective of the real value carried by the native currency of the platform. IOU is a surrogate whose purpose is to be tradable several weeks away from the official release of a HEAT token. That being said, if u surf through whitepaper and take a decision to buy in on IOU, and then something goes wrong with the fundamentals, or even worse, the release date is delayed, IOU prices might tumble thereby u might exchange IOU for HEAT coins at lesser ratio than what u bought them at.

I doubt that genius part very much, if he would be the great genius you are emphazing on everytime you talk about him, then we maybe would have had a finished product already and maybe he would upload stuff on github. Github is there to upload your code yo know?


You couldn't be more of a condescending cunt to answer this question in your high nosed dickhead manner instead of focusing on other important questions.

You condescending cunt. Okay so you have been working part times? Well what exactly have YOU done, yes YOU and not Dennis? Dennis is coding something in the basement and is not able to show any of his "genius code", okay, this sucks but I get that. But what exactly have YOU done, the one next besides Dennis?? Because from you I have seen nothing so far, absolutely no work! There is more work involved in any of my posts on this thread than in all of your nonsense bullshit posts you stupid twat!

You gotta be fucking kidding me?! The coin will not be opensource? This is ridiculous! I will not even start your fucking client if it is not opensource and I can't compile it on my own! We are talking about a decentralized coin here and you think it is a good idea to make it closed source?! Why, because of competition and the price would go down? If the sourcecode is not open, nobody will EVER buy this crap, because nobody knows what they are buying because they can not verify it! And don't think anybody with half a brain trust in what you morons tell people what this is, because until now you couldn't care less about your investors than you showed you did!

Oh yeah your project is so ambitious that it needs a lot more work and everything and that is why we have to wait and delays are normal... You knew that from the beginning! And still you only have one developer and one guy who nobody knows what he is doing!

WOW!! just WOW!! You condescending cunt! This is an absolute shitshow! Is there anything that you want to do about is? Or are you just noticing that you don't give a shit about your investors. Wait you say note taken, which means that you don't necessarily agree about it. I am speechless!

No you did not! And you should answer to my questions! And don't be such a condescending cunt and weazel your way out of this by saying something like: No I will not answer your questions because you use foul language!
I dare you!
I really don't think a nice f2f chat is what he meant!


ALSO I DEMAND A PROOF WHERE YOU SHOW THAT YOU ARE STILL IN OSESSION OF THE INVESTORS FUNDS! YES CRYPTOGRAPHIC PROOF AND NO I WILL NOT TAKE YOUR WORD FOR IT!



PS: I was also thinking they would release everything right after the ICO. unfortunately I can not remember where I read this. If anybody knows the source of this, please tell me!

Because otherwise he won't give one of course. He's a coder and genius at that, but not very adept in handling public relations. Just like me, but even worse

What's happening is development, mixed with family handling and holiday season to put it frankly.

FWIK he's been working part time during the Christmas days, taking care of family where possible, the exact same that I've been doing myself. If you have a family to take care of, you'd know there are quite a few modes of existence between being sick and working 24/7 month after month

The code is on company premises where development happens, and needs to be cleaned before being deployed to Github. Also the server code needs to be edited or mostly removed from the public release because we're not going open source at launch time because of the obvious hazards of losing IPR and competitive advantage just like that. Client and some important parts will be open sourced, however there hasn't been reason to do that yet as HEAT core development is ongoing.

Of course we are. It needs to be reminded HEAT is a fintech business project, involving a lot of aspects that most crypto-only coins aren't bothered with in the slightest. Thus the execution of our business is also different from what you're used to - causing the delays in the first place as everything needs to be coordinated from technical features, applications and extending to the readiness to support partnership setups.

Six months - it's of little use to exaggerate, more like 4 and half months. No communication - I don't get that part but note taken
.

I hope I answered that to your satisfaction. Normal life and development, so nothing spectacular there to grow FUD on.

We're here and we're responsible whenever you'd like to have a chat f2f about which part of the company's crypto funding round you might have misunderstood, or any other similar issue there may be.

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 "[email protected]", yet not leaving a trace on the blockchain. Yet when some other user sends a payment to "[email protected]" 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.

why not fork some coin and release a temporary chain/wallet so that people can trade until the HEAT core is developed ? If people want to sell/buy then they should be able to. Waves did a similar thing but i wouldn't advice a centralized chain anyway.