T.E.T.O - trustless total order for transactions in a DAG based cryptocurrency

[monsterer2]

Hi everyone,

I'm posting this draft I worked on last year in the hope that it will inspire some debate. It's based on the work of Max Kaye (https://bitcointalk.org/index.php?topic=1057342.0), and proposes a blockless consensus mechanism for achieving an eventual total ordering of all transactions in a DAG based cryptocurrency.

The novel aspects are that it is the first system I am aware of that attempt to achieve a trustless, total ordering for all transactions.

It's an incomplete draft, all of the proofs are missing and there is an open question related to the claim about miners being incentivised to reference uncle transactions in their own new transactions, which is somewhat key to overall convergence.

https://github.com/wildbunny/docs/blob/master/T.E.T.O-draft.pdf

edit: points of interest:

* Permits a mining reward
* Deterministic global state
* Eliminates mining pools
* Maximum possible decentralisation
* Enables safe-to-accept-transaction-as-confirmed metric
* Instant transactions

Anyway, happy reading!

Cheers, Paul.

[hv_]

Hi monsterer, wellcome back.

I ' m not sure I can do the analysis here, but might start reading once you worked on my last input there...

https://bitcointalk.org/index.php?topic=1392578.msg14202640#msg14202640

 

[Claude Crypto]

I enjoyed reading the paper!   I am glad someone is working on solutions for DAG networks.  I feel DAG tech is superior to blockchain tech, although it is still very new as a cryptocurrency solution. IOTA really has a lot of pressure on it to be the successor of bitcoin, and Byteball is very underfunded in comparison.  Both of them need to gain more traction before they implode.  I just hope a real solution comes from all this work.  After all, we just want decentralized, p2p, open, trustless, systems that scale well.  Everyone in crypto can agree on that.

I would suggest coding a basic project to apply what you have explained in the paper.  Javascript seems to be the most commonly used for blockchain-less projects, Byteball being mostly written in node.js.  You need a proof of concept that actually shows TETO as an interactive, working, system.  This https://medium.com/@lhartikk/a-blockchain-in-200-lines-of-code-963cc1cc0e54" is a great introduction to what is actually happening in a blockchain, all in very well-documented, javascript code.  I believe if u made a similar example it would help TETO get the recognition it deserves.

I have been running an IOTA full node for a few days, and the pairing of IP address, creating "mutual tethers" was very underdeveloped, as is the p2p code for that example in the link above. Using a Slack channel to find other nodes is just not user friendly.  Giving your IP address to a stranger in exchange for their IP address, ends up feeling more like a drug deal than a promising new technology.  Overall, the pairing of nodes to form mutual tethers is another area that really needs some improvement.  I am not great with js otherwise I would code such a project myself: maybe TETO client, with a mongoDB server, hosting a list of addresses for the pairing of mutual tethers.  Let me know if that is something you would like to work on and thanks for thinking outside the box with this, uncharted, cutting-edge, new tech!

  

[monsterer2]

I have been running an IOTA full node for a few days, and the pairing of IP address, creating "mutual tethers" was very underdeveloped, as is the p2p code for that example in the link above. Using a Slack channel to find other nodes is just not user friendly.  Giving your IP address to a stranger in exchange for their IP address, ends up feeling more like a drug deal than a promising new technology.  Overall, the pairing of nodes to form mutual tethers is another area that really needs some improvement.  I am not great with js otherwise I would code such a project myself: maybe TETO client, with a mongoDB server, hosting a list of addresses for the pairing of mutual tethers.  Let me know if that is something you would like to work on and thanks for thinking outside the box with this, uncharted, cutting-edge, new tech!

Thanks for reading - really this first posting of the draft paper is supposed to generate debate; I'm basically waiting for someone to tell me what I have overlooked in the design and the various reasons why it cannot work in practice.

...Although it seems the active and knowledgeable users with experience in consensus design have long since left this forum.

[hv_]

Nice reading - yes definitely

But could you think of an double -> infinity times spending attack, that will spam the DAG in such a way that any verifying work will crash the nodes in terms of mem or processing time / both ?

IMO it could be way too hard work to find out what is the allowed TX under a multi branched DAG having lots of double spending TX to be skipped.

[monsterer2]

Nice reading - yes definitely

But could you think of an double -> infinity times spending attack, that will spam the DAG in such a way that any verifying work will crash the nodes in terms of mem or processing time / both ?

I don't think so, because sending a transaction requires a minimum PoW difficulty, so spamming will cost the attacker a lot.

IMO it could be way too hard work to find out what is the allowed TX under a multi branched DAG having lots of double spending TX to be skipped.

The system totally orders all transactions in sequence, so the first spend in the sequence is always the legitimate spend.

[Marcel Beliveau]

DAG with POW is the future i guess.

I guess you read SPECTRE DAGLabs white paper. (DAG with POW also - smart contracts are also possible...but they can't have clean txs ordering)

About IOTA  : The validation of Tx is performed in probabilistic manner. The protection against Sybil Attack is relying on the fact that many wallets are "half connected to the internet" (either periodically or continuously with low bandwidth : IOT). These half connected wallets are representing a throughput of tx/sec which is preventing from this attack (*). But this troughput of Tx/sec must represent a significant amount of all the Txs/sec ("significant" ? nobody did the maths behind but I think above 20% (50%?)). So let's wait for adoption in IOT world....but long will be the way.

(*) preventing from this attack because these txs from IOT are considered as honnest and so during attack time they are continuously not approving the attacker txs. So the attacker is alone to increase the cumulative weight of its own txs.

Do you plan to launch something ?

[monsterer2]

(*) preventing from this attack because these txs from IOT are considered as honnest and so during attack time they are continuously not approving the attacker txs. So the attacker is alone to increase the cumulative weight of its own txs.

It won't be enough. The overall hash rate of the iota network is impossible to measure since any attacker worth his salt will just sit idle not doing anything with his hashing power until sees an opportunity. Because there is no competition to mine, and iota is designed for tiny, low cpu hardware, it will be trivial to acquire enough hashing power to outpace the rest of the network.

TETO solves this problem completely due to the mining incentive.

Do you plan to launch something ?

I have no plans at this time.

[Marcel Beliveau]

I fully agree with you.

I wait for update of the whitepaper...Maybe the validation of the Txs will not only rely on the Monte Carlo Random Walk...I hope so for them....

[RNC]

I just don't get DAG and I can see that they keep pushing nodes onto a stack and use examples of A-Z
but what makes node 'B' a neighbor of 'A' and is this stack passed from node to node with the results all being
send back to participating node.

Whats stops node 'Z' from having a direct connection to node 'B' because I don't understand how the
order is created for flow control if nodes "N,O,P" join the network at a later date.

Feels like I am missing something that maybe useful here and even if the order was based on
converting a public key to a Bigint to give direction then new connections would need to be created
and old ones removed at a huge rate of speed

Sorry, it's just not sinking in.