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

Oh awesome thanks for the help.

They will be split among the people that bought coins.

Sorry if it's been asked but what happens to the coins that are not sold in the event they are not?

Can't invest!! 

The openledger site says:

"Application initialization issues"

Anyone else having this problem? I'm running on Android 5

And still it has raised a pretty good amount of BTC so far.
But I do agree that the thread is pretty quiet.

this ICO has to be the least noticed ... not many  know

Nice video.

Under his definition, Bitshares might qualify as 3rd generation then.  I'm not expert on it, but they seem to have advanced blockchain voting functions, with workers, committees, and witnesses (their block producers).

Real use of Bitshares voting shown here:
https://cryptofresh.com/ballots

I think HEAT uses a different definition for 3rd generation.  One that eliminates blockchain bloat and improves scalability to massive levels (among all the other niceties).

An example of why a better governance model is needed is mentioned in the video.
Look at all the accusations flying back and forth between the ETH and ETC community right now. Both sides are accusing the other side of having ulterior motives. There is no way of proving if any of the accusations are right and it is damaging both communities.

Interesting video! Clearly, 3rd generation can mean many things.

Can mean a next technological level
Can mean a better/decentralized governmental process

But what exactly can be gained with such 'better governmental process'?

The video talks about changes to the network protocol or consensus protocol, but what does that mean? Sure seems like an interesting theoretical or technical problem. But what kind of real world use is there for it? Any examples?

Here you go!

     Price stage    HEAT price    Exchange / BTC    1 BTC worth    HEAT per 1 BTC equiv
BTC            2       0.00013        1.00000000         1.0000        7692.3077
FIMK           3            50        0.00000210    476190.4762        9523.8095
NXT            2             4        0.00004009     24943.8763        6235.9691
ETH            1        0.0065        0.01967240        50.8326        7820.4059

What do all these solutions have in common?

- segregated witness
- sharding
- blockchain pruning
- lightning network

 

They all solve the inherent problem that each crypto-currency or blockchain network faces..

Which is the inability to keep around all transactions since genesis till now, no machine in the world exists that allows that.
_{Let alone cheap machines required to run a world wide decentralized network - operated by normal people - not multi-million dollar banks!}

But why keep those transactions around in the first place?
Why do crypto currencies need access to all past transactions?

Why can't the decentralized consensus mechanism function with access to balances alone (and some past transactions - but not all of them).

The real reason most currencies can't function without access to that data....

Is since they are designed from the ground up to have to have access to that data for their consensus algo's to function.
But can we blame them?

Did they know what scale crypto-currencies  could reach one day?

No! Of course not. But it is a problem non-the-less.

If there is anything that HEAT adds to this, it's that we designed HEAT from the ground up to not depend on past transactions.

This comes at a cost (initially ... but will be solved eventually).

- we can't do referenced transactions like NXT does (doesn't scale)
- we can't do ETH contracts in the form Ethereum does them (doesn't scale)
- we can't do Bitcoin multi-sig in the form Bitcoin does it (doesn't scale)

Does this mean we can't have smart contracts? multi-sig? or conditional transactions?

By no means, the answer is we can support those things.
But extreme care has to be applied to not lock the HEAT blockchain into promising functionality that later needs to be disabled or rolled back.

Simply since it doesn't scale anymore!

In part... I believe this is what HEAT is about.


Kudos back  

Read 1st post       

Its still in ICO on a few exchanges... C-cex is where i got my steaming pile of HEAT    (Not an insult, just seemed appropriate and comical)

As an early investor, somewhat of a crypto-vet, and an IT professional - I have to say, good feels come from the info that has been communicated here - Shout out to LiskEnterprises for asking those questions of the dev. And kudos to the dev for providing a bunch of info back.

Its in the OP

where we can get heat ?

Some progress on the unconfirmed transaction (or mem-) pool

[This is one of the last BIG problems we had to solve..]

The previous post turned out not to be the solution, it simply wouldn't scale.

Happy to say we now 'really' have a working solution.

Trick was to construct the pool as a linked list and to use smart on demand sorting on addition.
This also solves our need that during block apply-ing valid and applied transactions can be removed very fast during iteration.
And allows for filtered iteration to kick out expired transactions.
And allows to put a max size on the pool so the expulsion algorithm can kick out transactions overflowing the maximum allowed (to mitigate DDOS attacks).

Finally we now have hooks to persist transactions to disk (have to do that ourselves since the database was removed).
And it supports transactional operations required to rollback in case of validation errors or to recover from system crashes.

The list itself, with active on-demand sort as you insert, has shown to do 12,000,000 operations a second (most likely double or triple that on a decent server).
This was tested with the default pool size of 600,000 transactions that fit in the HEAT mem-pool.
With real transactions this will become slightly slower because of the need to persist data to the memory mapped data store.

But the most important thing... the mem-pool will not be slower than any other part of the HEAT framework.
Which was the main goal.

For the nerds: HeatSortedLinkedList.java
[tip of the day! if you ever need to do a standard datastructure, look in the actual JVM source code for samples!]


I'm a bit behind on schedule because of the mentioned difficulties.
I'll get back to this later.

In regards to qualifying HEAT as a 3rd Generation platform, here is an interesting video with a 3rd generation definition. Mainly first ten minutes..

https://www.youtube.com/watch?v=6zP4Chk8g7A

Yet it does focus on the tech as being important the focus is on using the tech to form governance for decision making and the statements of the platform being laid down well so that clients really know what they are joining.

I guess this definition of 3rd Gen gets us out of experimental phase and into a percise governmental phase that would prevent issues like what ETH has right now.

Can you compare how you are presenting the 3rd gen platofrm in HEAT to how Input/Output suggests it should be focusing on?

Great thread so far and full of true information.

The tech is great the plan is great and the philosophy is now my basis of these questions..

A white paper on a blockchain designed for governance.

https://tezos.com/position_paper.pdf

https://tezos.com/white_paper.pdf

https://tezos.com/language.txt

Regards/

What is the core difference between a back and front end programmer and a crypto programmer.

What are the main programming themes that make crypto possible that a reasonable programmer should focus on to participate in HEAT either to help the core or to start their own HEAT Blockchain Cloud based business?

Enjoying the details thanks..

No idea really if any of them Lisk Dapps is allowed to touch any parts of the NodeJS standard-lib, probably not, I guess it's more likely they compile and run those in a sandbox.
If they are allowed to touch NodeJS a full framework rewrite and porting does become slightly harder.

HEAT runs it's Dapps (Distributed Services is what we call them) in the Nashorn engine that comes with Java, which is really fast btw!
Nashorn has not reached V8 levels, yet, but huge improvements are planned for future Java versions.

But in HEAT it really doesn't matter if Dapps run in 5 milliseconds or in half a millisecond, experience will be the same.

Have not looked at Lisk Dapp capabilities in detail yet but based on the lack of any really useful Dapp till now.

My guess is either the concept is not that powerful in the first place or Dapps in Lisk are really hard to make (or both).

With HEAT Distributed Services (our dapps flavor) you will very soon see very usable solutions.

- Decentralized Shapeshift is a good example
- Shopping with any currency (HEAT, EUR, BTC, ETC etc etc) on Amazon without an Amazon account is another
- All kinds of security additions (2FA over email, phone, smoke signals  )

No.

Never understood the choice of javascript to create a crypto framework.
But if it becomes a success they could always do a complete re-write, protocol would stay the same.

Being a JS guy, are you a fan of Lisk?