IOTA

[luckykitty]

so, when will launch?

[1713523482]

1713523482

[1713523482]

1713523482

[1713523482]

1713523482

[1713523482]

1713523482

[1713523482]

1713523482

[iotatoken]

so, when will launch?

We aim for development being done by Christmas;)

[freemind1]

Watching. Really it looks interesting.

[Timeline]

so, when will launch?

We aim for development being done by Christmas;)

There are a acouple of interesting altoins coming soon and IOTA is one of them 

[Ratatosk]

I read this interesting thread, but did not find this info, maybe I did not see it sorry :

What is the speed of on/off-tangle payments ?

I mean the total maximum time for an operation to be 100% accepted/confirmed by the system ?
Are we speaking of 5-10 seconds, 1-30 minutes or hours ?

[Come-from-Beyond]

I read this interesting thread, but did not find this info, maybe I did not see it sorry :

What is the speed of on/off-tangle payments ?

I mean the total maximum time for an operation to be 100% accepted/confirmed by the system ?
Are we speaking of 5-10 seconds, 1-30 minutes or hours ?

On-tangle payment speed depends on a lot of factors which numerical values are unknown yet. Off-tangle payment speed is around 1 second.

[Jimmy2011]

To "hire" miners for the race, can one send IOTA tokens to himself(the same address) or from one address to the other address he owns? To avoid double spending, tx weight cap will be set, so is the cap as small as possible? It seems that the cap is related to the tx flow rate, tx network topology and maybe other things, so is there any principle to set the cap manually or is it hard coded in the software?

Cap is set manually, each nodes decides if it wants to approve this transaction or not depending on its weight, too low and too high values will be filtered.

Thanks. Wait for how the code "thinks" low and high.

[Come-from-Beyond]

Thanks. Wait for how the code "thinks" low and high.

It's just a parameter set by the user.

[TPTB_need_war]

Well, in iota you cannot say anything like "cumulative weight of X is enough for a tx to be considered confirmed", since the time enters the story. For the system to be secure on its own (i.e., without additional checkpoints or smth), the ability of the attacker to issue tx's must be much less than the "natural" flow of tx's in the system.  So, what you have in iota is rather statements like "if a tx got cumulative weight X by time T, then the probability that this tx can be annihilated is at most p, provided that the potential attacker's hashing power is at most h and the natural tx's flow in the system is at least m", see examples in the bottom of page 14 in the paper. In that "6 blocks confirmation rule" of Bitcoin there are some implicit assumptions as well, by the way.

Please translate that general math to some concrete examples for us, so we can compare likely confirmation delays.

Did you see the examples on p. 14 ?

Okay so qualitatively we just need to wait for some chain of subsequent TXs to reference the DAG node for our TX, and as long as the attacker's capacity to generate TXs is sufficiently low (perhaps similar to Bitcoin at less than 25 - 33% for selfish mining), then the double-spend probability will also be practically very low for tangles consensus. Indeed Bitcoin has similar probabilistic risk of double-spend:

https://bitcoil.co.il/Doublespend.pdf

Three observations:

• Confirmation is not instant, as it can be in other designs such as Lightning Networks (and also my design). Yet it will also be much faster then Bitcoin's block period. You are probably estimating at a few seconds at most assuming attacker's power is sufficiently low?
• The attacker's power is given by his ability to incur TX fees relative to the total TX fees being paid for TXs. This is qualitatively different situation than PoW block chains, because in a tangle every payer has to incur the cost of security by paying higher TX fees (which I assume be burned so the coin is deflationary to 0 supply, unless you burn PoW hashes instead which is what I would advise). In Bitcoin all users pay the cost of mining security as well though either through debasement or TX fees, so it seems about the same. A potential advantage for a tangle is if you burn PoW hashes as I suggest, then every user is mining, unless they delegate this hash to a server. However appears neither tangle nor traditional PoW block chain can be immune to a 51% attack, whereas in my block chain scaling design I do claim this immunity (sorry to plug my work here but is necessary in order to point out relative strengths and weaknesses of all designs available to the crypto community).
• No way to prevent double-spends in partitions of the network (no fault tolerance to network partitioning). I claim to solve this in my design and I think perhaps Lightning Network is also.

So overall I think this DAG stuff is an improvement over traditional PoW block chains in general, not just for IoT. But I do think I may have a superior design, but I am still analyzing to see what attributes the DAG might have that are superior. The elimination of the blocks and the aliasing error of chain reorganizations perhaps, but seems there are analogous issues in the DAG.

Please do not take my post as desiring to rain on your thread. I won't belabor my points. I am just trying to see where for example we might even collaborate if at all. Looking with an open mind. Cheers.

P.S. to the mathematician, kudos on working out all that math. I haven't made a decision to wrap my head around it yet. So pressed for time.

[mthcl]

Confirmation is not instant, as it can be in other designs such as Lightning Networks (and also my design). Yet it will also be much faster then Bitcoin's block period. You are probably estimating at a few seconds at most assuming attacker's power is sufficiently low?

Probably yes, should be matter of seconds (in the regime where there is a reasonable flow of tx's already).

The attacker's power is given by his ability to incur TX fees relative to the total TX fees being paid for TXs. This is qualitatively different situation than PoW block chains, because in a tangle every payer has to incur the cost of security by paying higher TX fees (which I assume be burned so the coin is deflationary to 0 supply, unless you burn PoW hashes instead which is what I would advise). In Bitcoin all users pay the cost of mining security as well though either through debasement or TX fees, so it seems about the same. A potential advantage for a tangle is if you burn PoW hashes as I suggest, then every user is mining, unless they delegate this hash to a server. However appears neither tangle nor traditional PoW block chain can be immune to a 51% attack, whereas in my block chain scaling design I do claim this immunity (sorry to plug my work here but is necessary in order to point out relative strengths and weaknesses of all designs available to the crypto community).

As far as I remember, there are no tx fees (CfB?..). The nodes invest only PoW.

No way to prevent double-spends in partitions of the network (no fault tolerance to network partitioning). I claim to solve this in my design and I think perhaps Lightning Network is also.

In the event when the attacker's node is the only one who sees that two branches, yes.  I'm not sure that would be a recurrent situation, though.

[Come-from-Beyond]

As far as I remember, there are no tx fees (CfB?..). The nodes invest only PoW.

Correct.

[stdset]

So don't buy a fridge that is smarter than you. It's really that simple.

No, it is not that simple. It's impossible for example to buy a new smartphone not equipped with a camera nowadays.

[stdset]

A question on the whitepaper.
Why does h - the average time a device needs to do the calculations necessary to issue a transaction depend on L - the total number of tips and N - the total number of transactions? That "total number of transactions" is it the total number of transactions incorporated in the DAG (probably unknown to the device) or what?

[Come-from-Beyond]

A question on the whitepaper.
Why does h - the average time a device needs to do the calculations necessary to issue a transaction depend on L - the total number of tips and N - the total number of transactions? That "total number of transactions" is it the total number of transactions incorporated in the DAG (probably unknown to the device) or what?

It's a general case analysis, a special case (for a particular implementation) may give average time not dependent on some or all these parameters.

[iotatoken]

So don't buy a fridge that is smarter than you. It's really that simple.

No, it is not that simple. It's impossible for example to buy a new smartphone not equipped with a camera nowadays.

But it's not impossible to buy an older one without, wait for project ara or worst case scenario: crush the camera lens.

If there is a genuine demand in the future for 'dumb fridges', then they will still be produced.

[Come-from-Beyond]

https://medium.com/quantum-bits/how-secure-will-our-data-be-in-the-post-quantum-era-6a7f444ce7d5

[Timeline]

https://medium.com/quantum-bits/how-secure-will-our-data-be-in-the-post-quantum-era-6a7f444ce7d5

Thanks for the link, reading it now.

[gioma]

https://medium.com/quantum-bits/how-secure-will-our-data-be-in-the-post-quantum-era-6a7f444ce7d5

Need some time to read this but I will follow, legendary dev's ftw

[TPTB_need_war]

Does Iota (DAG tangles) need to be only for IoT applications?

What advantage does it have over a normal block chain? Only the faster confirmation time (yet to be quantified) and not needing large blocks (yet all "full" nodes still pretty much need to see all transactions so that aspect of scaling isn't changed from Bitcoin)?

Iota can be used outside of IoT too.

Some advantages are listed here (that thread may be interesting) - https://bitcointalk.org/index.php?topic=1177633.msg12492916#msg12492916

...

So overall I think this DAG stuff is an improvement over traditional PoW block chains in general, not just for IoT. But I do think I may have a superior design, but I am still analyzing to see what attributes the DAG might have that are superior. The elimination of the blocks and the aliasing error of chain reorganizations perhaps, but seems there are analogous issues in the DAG.

Please do not take my post as desiring to rain on your thread. I won't belabor my points. I am just trying to see where for example we might even collaborate if at all. Looking with an open mind. Cheers.

...

They key advantage I see for DAG tangle form of consensus versus a block chain, my ClickzSync design, and Lightning Networks, is that appending your transaction into the DAG tangle is autonomous and permission-less (notwithstanding you probably want to see as much of the breadth of the tree as possible thus need a reasonably powerful server and internet connection, or delegate to one)! That is a very profound distinction!

This means that any user can append their transaction to the consensus network and can't be censored per se. Now their transaction might not get included in any other branches of the tree if there is 100% censorship of that transaction, but this isn't very likely. It isn't a 51% all-or-nothing control as in Bitcoin and the conceptual reason is because a DAG tangle has multiple branches of consensus! And even if the probability of double-spend is high on a transaction that has been censored by a large % of the network (not included in their branches), the transaction still has a record in the DAG tangle and so the recipient can still accept the funds if they so choose to take that risk. In other words, the consensus network can multifurcate to route around censorship.

Having said this, the most optimum design for block scaling is not DAG tangles alone, but integrated with my ClickzSync design. And then also supporting the necessary opcodes so LN can also run on the system (because LN has the least overhead but has some drawbacks that an Iota+ClickzSync design would offer alternatives to). In other words, these 3 designs all address a slightly different aspect of the consensus scaling network optimization. The Iota design is going to need some tweaking any way, because I see some issues.

Thus I will open private discussions with the Iota team (apparently mthcl and Come-from-Beyond only?) now to see if they are interested in collaborating.

We are at a momentous point where (if I am not mistaken on the myriad of technical details) Iota+ClickzSync could radically overhaul crypto consensus network scaling, security, and TX/s. I hope they are interested to attempt it along with me if the parameters work for both of us.

I have some optimism because Come-from-Beyond is apparently programming to the Java Virtual Machine as I am as well. We seemed to have (very limited) amicable and agreeable forum discussion in the recent month or so.

[Come-from-Beyond]

Thus I will open private discussions with the Iota team (apparently mthcl and Come-from-Beyond only?) now to see if they are interested in collaborating.

Contact iotatoken instead of me, please. I'm just a programmer who happened to know some stuff because of necessity to implement it in the code.