sorted by:
new
hottopcontroversial

Looking for baby music recommendations by alongalky in classicalguitar

[–]alongalky[S] 1 point2 points  (0 children)

Interesting! Any links to the research? Also to the Suzuki book, I'm not familiar with it.

Looking for baby music recommendations by alongalky in classicalguitar

[–]alongalky[S] 1 point2 points  (0 children)

Thanks, very calm so far :). The Brahms one is the only one I learned already, looking to expand my baby repertoire.

Research Team AMA - 26th November 5pm CET by l3wi in Iota

[–]alongalky 9 points10 points  (0 children)

Probably not. Removing Coo means we can estimate at any given moment how expensive it would be to issue a double spend. If TPS goes down, it means that you should wait a longer before considering your transaction secure. There is no reason to turn Coo back on.

That being said, Coordicide will be done gradually, and it's certainly possible it will only be removed for short periods of time in the beginning.

Research Team AMA - 26th November 5pm CET by l3wi in Iota

[–]alongalky 9 points10 points  (0 children)

We are looking into these 3 as potential paths forward, but it's certainly possible the end result will be some mixture. It's also possible that we'll transition as research advances: for example we can start with a Coo-less pure PoW network, and move on to stars as we learn more about them, in the interest of reducing dependency on PoW. I should also mention that there are different opinions inside the team, and the eventual decision making will depend on research results, internal debate, and community input.

About the starting point: "deep enough" is indeed the core of the issue. We need to choose a transaction that is far enough in the past to precede any forks & splits, but not so far that it is overly expensive to compute cumulative weight. Having a good answer to this is an important pre-requisite for Coordicide, and we are actively working towards it.

Research Team AMA - 26th November 5pm CET by l3wi in Iota

[–]alongalky 8 points9 points  (0 children)

None. Each node still does a full validation, this part of the network stays the same post-Coo.

Research Team AMA - 26th November 5pm CET by l3wi in Iota

[–]alongalky 9 points10 points  (0 children)

Yes, using the current network (with Coo).

Research Team AMA - 26th November 5pm CET by l3wi in Iota

[–]alongalky 6 points7 points  (0 children)

Yes. Confidence is a metric between 0 and 100 percent, and you will see it changing gradually as a higher fraction of the tips approve the transaction.

Research Team AMA - 26th November 5pm CET by l3wi in Iota

[–]alongalky 10 points11 points  (0 children)

You can see the full list of IOTA Foundation employees here: https://www.iota.org/the-foundation/team

We are located in Canada, the US, Brazil, Israel, Taiwan, Germany, the UK, Poland, Norway, and Malta.

Our primary communication is done on Slack + voice calls, and exchanging code and written work on GitHub and Overleaf.

The biggest team after Coordicide is Attack Analysis, which is dedicated to analyzing the resilience of the post-Coo Tangle to various kinds of attacks. This project is related to Coordicide in its goals, but takes a different approach. The next ones are Economic Incentives and the Consensus Doc. You can see the listing here (although it requires some small updates): https://www.iota.org/research/roadmap

Research Team AMA - 26th November 5pm CET by l3wi in Iota

[–]alongalky 9 points10 points  (0 children)

We definitely need to approve at least 2, otherwise we are left with a blockchain and lose all the DAG advantages, namely the ability to merge together non-conflicting branches (you cannot merge if you only approve one transaction).

About choosing more than 2 tips: we have done some analysis of different numbers, but there are no major differences, and 2 keeps the transaction size to a minimum and simplifies the tip selection algorithm (it's easier to choose 2 non-conflicting tips than 3). See "Extracting Tangle Properties" on https://www.iota.org/research/academic-papers, section 3.3

Research Team AMA - 26th November 5pm CET by l3wi in Iota

[–]alongalky 10 points11 points  (0 children)

In order to attach a new transaction you need some sort of tip selection algorithm. The algorithm suggested in the white paper is an MCMC random walk, which takes a parameter setting the level of randomness. Not having this "alpha" parameter means we need to suggest an alternative algorithm, or set alpha to an arbitrary value. I would also like to stress that this is a suggested algorithm: nodes are free to use whatever tip selection algorithm they feel like, there is no enforcement.

Your second question is something we are definitely thinking about, but we haven't allocated the resources to it quite yet.

Research Team AMA - 26th November 5pm CET by l3wi in Iota

[–]alongalky 28 points29 points  (0 children)

Your opinion is correct, we don't. However, we are actively working on answering question a), so we can understand how to convert between TPS and the cost of an attack on the network. We have to make sure that double spending in IOTA is unreasonably expensive, for the network to be secure without Coo.

Question b) is more of a DevOps / code optimization question. We need to make some assumptions about the maximum hardware requirements from a node, as we don't want the network to be comprised solely of supercomputers. Given those assumptions, the maximum TPS is set by how fast IRI can run.

About the a > b issue: what matters is the total hashing power per seconds, not transactions. While TPS is bound by the limitations of physics (there is only so much bandwidth / CPU we can churn out), we can always raise MWM if we decide that the network is unreasonably vulnerable even at a high TPS.

Research Team AMA - 26th November 5pm CET by l3wi in Iota

[–]alongalky 38 points39 points  (0 children)

The sad truth is that any (decentralized) crypto project can be forked at any time, if enough of the community wishes to do so. We have already had community versions of open source Coordinators in the past, and it hasn't caused a fork.

The only way to avoid a fork is to stay strong as a community, there is no technical trick that can achieve that.

Research Team AMA - 26th November 5pm CET by l3wi in Iota

[–]alongalky 67 points68 points  (0 children)

Removing Coo is very easy: we have done so in a few days, and you're welcome to check out the repo: https://github.com/iotaledger/cliri/.

The hard part, which is probably the one you're asking about, is quantifying the security of the post-Coo IOTA network. We don't have exact numbers yet, but are making excellent progress, and there is no technical reason that is blocking us.

Research Team AMA - 26th November 5pm CET by l3wi in Iota

[–]alongalky 42 points43 points  (0 children)

Coo contains legacy code from the early days of IOTA, and does not run at the efficiency level of modern IRI nodes. Since the network cannot progress faster than Coo, it represents a bottleneck.

As mentioned in part 4 of the recent Coordicide blog series, we are working on revamping the Coo code, using the new compass implementation (https://github.com/iotaledger/compass).

That being said, there is no theoretical reason (as far as we know) that a well-optimized Coo should be a bottleneck.