I have technical questions for Dennis.
Re:
instant tx confirmations through websockets and replication layerWebsockets and replication are fine technologies for network and data access layers. But, I don’t understand how this can provide safe instant tx confirmations on the blockchain. The p2p consensus comes from NXT, which suggests 10 block confirmations.
Early discussions about instant tx from NXT first developers. I don't think it ever got implemented:
https://bitcointalksearch.org/topic/nxt-instant-transactions-with-guaranteed-confirmation-316104
https://bitcointalksearch.org/topic/transparent-mining-or-what-makes-nxt-a-2nd-generation-currency-364218How does the HEAT protocol protect against double-spends while simultaneously providing instant confirmations?Re:
Optimized for speed and instant high frequency tradingSame concerns as above, plus another. Some decentralized exchanges can be susceptible to order front running by miners/forgers. If HEAT usage ever approaches the scale of the HFT engine you describe, it could be a very savory target for this type of attack.
Does the HEAT trading engine protect against order front running by forgers?Hi,
Thank you for the constructive question, I'll try and answer as clear as I can.
First this one.
instant tx confirmations through websockets and replication layerAfter looking at both posts you link to you clearly are referring to a different kind of instant confirmation, I see the confusion.
What we are referring to is the confirmation the user (or basically all users in the world) get the second/milliseconds anyone places an order, anywhere on the network.
They'll instantly see their balance change, other orders will be eaten, charts will be updated, generated trades can be displayed.
The data we use to build our real-time view of the state of all orders is made up of both all transactions in all the blocks plus all the transactions in the unconfirmed pool, in real-time.
This data is subject to change, albeit very very unlikely, it can change since there can be blockchain reorganizations, transactions can timeout etc all this was taken into account and when such happens all orders, trades etc will instantly reflect this new reality.
But this doesn't mean you can't pretty much predict what the state of the blockchain will be when the next block is forged.
The mechanism is very much like when you send BTC and you watch your balance on blockchain.info or you pay for your pizza online and get an instant confirmation of your transaction in the payment app of your favorite pizza website.
You click send from blockchain.info and almost instantly the website says
thank you for your payment, same principle.
But ours is not just about payments, we match all order books and even generate trades and chart data which all becomes available from the MySQL DB which in turn powers the trader site, the backend API so bots/developers can listen in and the websocket connections to sites/mobile apps etc.
The thing we have been struggling with is how to do as accurate a prediction of future blockchain state as possible, already NXT comes with transaction-index tracking this can ensure the order of transaction execution (since this is the important part) to a high degree.
I'm very skeptical if its even possible to find a fully cryptographic mechanism to enforce network wide transaction ordering consensus (referring to the links you posted).
But I'm just a simple developer, so what do i know, some brilliant mind - those of the levels that came up with POS or POW in the first place - might invent such in the future.
But now it doesn't exist.
However looking at all the tools available in our crypto arsenal (basically all tricks from all currencies all combined) and using some common sense, there are many more less 'elegant' solutions but solutions that just work.
One thing we came up with, and this is a dead simple one, is just have each order signed by one single account.
This is something you could automate, and make provably fair (with a hash chain for instance), that one account can then co-sign each order and by co-signing it (using the full power of his private key) giving it an ordering that is guaranteed to stay the same right from its first broadcast to network straight until the transaction lands in the block.
If we did that the chance of false instant confirmations drops again to a much lower level.
And with this mechanism you can even fall-back to how we now have transaction-indexes in case such an optional higher-level dpos'kinda proof is missing.
I can imagine if a commercial party uses HEAT as its in-house private chain, it would be perfectly happy with just one single powerful server on its network which is dedicated for this job.
If you want to do this in a decentralized manner you can adopt a DPOS type of structure where randomly another delegate is appointed as the order co-signer.
How does the HEAT protocol protect against double-spends while simultaneously providing instant confirmations?
Same way NXT protocol does.
We are not touching any of the fundamental POS rules, those rules have been constructed through a process where very smart people all looked at it and discussed it over many years now and made to the thing it is now.
I'd be a fool to think I know better than all those smart people.
But after working closely with NXT source code since it's conception basically I do now understand how all those rules are applied into the basic architecture we started from.
Re: Optimized for speed and instant high frequency trading
Same concerns as above, plus another. Some decentralized exchanges can be susceptible to order front running by miners/forgers. If HEAT usage ever approaches the scale of the HFT engine you describe, it could be a very savory target for this type of attack.
Does the HEAT trading engine protect against order front running by forgers?
100% preventing front-running in a fully decentralized consensus network is as its now impossible.
Without introducing the two step process of having one (optionally rule bound but random) node that does the co-signing and which works as the single gate all orders must pass through.
I believe that by making that ordering optional and having a fallback to standard transaction -index we can safely introduce a ordering at the block level where if an evil forger starts to re-order his transactions that the rest of the network simply will not accept that block.