Topic: [IOTA] Крипто-токен для "интернета вещей" (Internet-of-Things) - page 105. (Read 227004 times)

Micah Zoltu [2017.06.14 10:06 PM]  
It seems that the Iota equilibrium requires the majority of participants behaving in a way that is "good for the network" rather than in a way that is purely selfish.  I did not believe that there would be a large enough share of non-selfish individuals to prevent selfish individuals from taking over the network while it seemed like others believe that being selfish was likely too hard for most people to bother.
My primary argument was that there exists a parent selection strategy that is as-good or better than the recommended parent selection strategy but hurts the network.  Because there is no selfish incentive to use the recommended strategy over this strategy, over time participants will tend towards the competing strategy, which will continually degrade network health to the point where those participating in the selfish strategy can take over the network and change the effective rules.
In particular, I believe the equilibrium is around large participants charging "transaction" fees to smaller participants for inclusion.
Thinking on it even more over the past few days, I'm concerned that this selfish strategy will actually reach the point where confirmation isn't possible because there are too many isolated sub-tangles that aren't merging regularly.
Sunny Aggarwal  [10:15 PM]  Yes.  Precisely.  @micah.zoltu’s point is exactly what I was trying to get at as well.  Those orphaned subtangles will only be able to merge back into the main tangle by paying computationally powerful actors to confirm them.
Sunny Aggarwal  [10:28 PM]  Furthermore, this is exacerbated by the fact that the selfish parent selection strategy doesn’t need to be dominant in the network overall.  It just has to be dominant amongst active users of the network at any given moment.
Chat-for-Ban [10:39 PM]  Give me example of selfish strategy.
Micah Zoltu [10:39 PM]  The selfish strategy I believe is to never choose a parent that isn't something you personally care about. There is no selfish incentive that I have seen to choose anything other than your own transaction as your parent.
Chat-for-Ban [10:41 PM]  We assume that 67% of _nodes_ stick to one of the good strategies
Micah Zoltu [10:41 PM]  :point_up: This is what I believe is hugely dangerous.
That requires 67% of participants (by _computing power_ - since one can simulate a node with computing power) to not be self interested and instead be altruistic participants to some degree.
Chat-for-Ban [10:44 PM]  This {to simulate a node with computing power} is a bold claim for IoT, are you familiar with LoRa? {mesh https://en.wikipedia.org/wiki/LPWAN}  
Chat-for-Ban [10:52 PM]  My words can be narrowed down to this phrase: _Omnipresence can't be achieved easily_
Micah Zoltu [10:53 PM]  I don't believe omnipresence is necessary for what I described above?
Chat-for-Ban [10:53 PM]  A lot of meshnets will go via classical internet, we probably even be unable to distinguish where IoT ends and classical Internet starts
I believe it's necessary because of mesh-like nature of the IOTA network. How would the network react to your attack in slow-motion?
...
Micah Zoltu [11:06 PM]  Unless you can prevent me from putting my supercomputer on the network, you can't prevent me from spoofing nodes.
Chat-for-Ban [11:06 PM]  At this point bandwidth starts playing role. I don't even need to, you can't connect to most of nodes
Chat-for-Ban [11:11 PM]  how can you spoof some node? you need to go to some spot on the earth and place your radiotransmitter, there are no wires going to some superhub
Micah Zoltu [11:12 PM]  Sure, I go to some spot on earth drop down a radio transmitter and a supercomputer.  I tell all my neighbors, "I'm connected to a billion neighbors behind me." No node can disprove that I am not actually connected to a billion neighbors.
Chat-for-Ban [11:12 PM]  You cannot do it physically. Because of bandwidth restrictions.
Micah Zoltu [11:13 PM]  So that means the network doesn't have enough bandwidth to actually support the network. A mesh network needs enough bandwidth to route everything.
Sunny Aggarwal  [11:33 PM]  Sure so any transactions that happen within that 1000-node cluster are “safe”.  But anything coming in from outside that cluster (through the 10 gateway nodes) are susceptible to the supercomputer
Chat-for-Ban [11:34 PM]  alright, now we need @micah.zoltu to agree with you and we will move to another attack scenario where supercomputer attacks other clusters
Micah Zoltu [11:34 PM]  agree with that statement
Chat-for-Ban [11:35 PM]  great, I was thinking you were going to attack transactions inside the cluster, this is what caused the misunderstanding, it seems.  so, 1000 nodes, 10 nodes on the edge, how would you attack transactions generated by other clusters?
Micah Zoltu [11:36 PM]  You don't attack transactions, you just run a supercomputer that is generating > 34% transactions.
Chat-for-Ban [11:40 PM]  you connected to 10 edge nodes and push a lot of txs?
Micah Zoltu [11:40 PM]  Yeah.
Chat-for-Ban [11:41 PM]  but these 10 nodes can't push your txs with the same rate. only 10% of your txs will be pushed thru
Micah Zoltu [11:41 PM]  That means that those 10 nodes can't support connecting to the network unless their sub-mesh makes up the majority of the network.
That 1000-node mesh network with 10 edges must be able to handle traffic from the rest of the network, which is very likely bigger than them. They need to be able to connect to the larger network as a whole.  They can't assume that their mesh is the largest part of the network.
Chat-for-Ban [11:49 PM]  you can connect to some part of cluster, start spamming, and bringing _several_ nodes down
Micah Zoltu [11:50 PM]  If they can't handle traffic from the global network, they aren't actually part of the network. Either your cluster can handle the traffic of the global network via its 10 edges or it can't.  If it can't, then it isn't part of the global Iota tangle and doesn't matter.  Its effectively running a fork of the network and we don't care about it. If it can keep up via those 10 edges then it is susceptible to supercomputer node simulation via those edges.
Micah Zoltu [2017.06.14 11:52 PM]  <-- https://iotatangle.slack.com/archives/C3V610ULS/p1497473569196293
* Isolated cluster of 1000 mesh nodes, 10 of which are edge nodes.
* Edge nodes connect to global Iota network over something like IP (or similar high bandwidth centralized route that anyone can get on).
* Cluster can handle bandwidth requirements of the global network via those edge nodes. <-- Either your cluster can handle the traffic of the global network via its 10 edges or it can't.  If it can't, then it isn't part of the global Iota tangle and doesn't matter.  Its effectively running a fork of the network and we don't care about it.
If it can keep up via those 10 edges then it is susceptible to supercomputer node simulation via those edges.
Sunny Aggarwal  [11:53 PM]  And the thing is, this itself in a way is the exact attack we were suggesting.  If the supercomputer can force a mesh into being isolated from the tangle, it can then start charging fees in order to allow it to communicate with the rest of the larger network
Chat-for-Ban [11:57 PM]  Guys, I need your both to say only AGREE or DISAGREE to https://iotatangle.slack.com/archives/C3V610ULS/p1497473775265357 :
  "Your attack works if our cluster can't cover 90% of the earth. Your attack does NOT work if our cluster can cover 90% of the reath." Agree?
Micah Zoltu [12:46 AM]  I have no intention of spending my time thinking about how Iota will function in the face of Unicorns. Either you can argue that Unicorns are real and if successful I will consider it, or we can just end the conversation, or we can discuss Iota in a world without unicorns.
Micah Zoltu [12:51 AM]  @Chat-for-Ban You are making the following logical fallacy: https://en.wikipedia.org/wiki/Existential_fallacy
Micah Zoltu [12:51 AM]  @Chat-for-Ban You are making the following logical fallacy: https://en.wikipedia.org/wiki/Existential_fallacy
Chat-for-Ban [12:52 AM]  @sunnya97 Do you remember I mentioned that we use manual tethering? The purpose of that tethering (instead of peer autodiscovery) was to get the same properties as IoT meshnets get
Micah Zoltu [12:54 AM]  What you are proposing is a global web of trust. "I will only peer with people I trust." The problem is, it only takes _one_ break in the entire global web of trust chain to undermine the trust network. All I need to do is get one other "edge" node to trust me and I can now simulate an entire network.
Chat-for-Ban [12:55 AM]  @sunnya97 apply the supercomputer attack on it, please. In mind of coz, not in reality. Will your attack be successful?
Sunny Aggarwal  [12:56 AM]  Essentially this is close to a permissioned system then.
David S?nsteb? [12:56 AM]  Can either of you just prove your attacks and collect major bug bounties? alternatively shut the fuck up? It's pretty simple; if you think you got an attack vector, then prove it
Micah Zoltu [2017.06.14 1:05 AM]  The whitepaper describes a _particular_ parent selection strategy and then defends a number of attacks based on that assumption.  I started the argument by asserting that the parent selection strategy would not be the dominant one because there are more selfish parent selection strategies available.
Kamal Mokeddem [1:07 AM]  I'm looking at how you secure the network against a denial of service attack. What prevents someone from only selecting their own tips and spamming the network with transactions such that the honest tips are orphaned?
Fahad Sheikh [1:18 AM]  @david @Chat-for-Ban there is no point publishing a white paper if it is not going to be defended. Asking for a physical manifestation is not a logical defense. Which is why many devs complain that IOTA dev just go hostile but don't give a proper argument in defense.
Dominik Schiener [1:40 AM]  if given the resources, who would feel comfortable in coming up with the attack? @micah.zoltu @sunnya97
Micah Zoltu [1:45 AM]  @dom I have way too many projects on my plate.. Though, the definition of the "attack" is simply: "every node selects its own transactions as parents only."
Alon Elmaliah [1:50 AM]  that's a dead-lock by design
Micah Zoltu [1:50 AM]  @alon.elmaliah Yeah, exactly.  But that is where things end up if actors behave selfishly. Avoiding the deadlock requires a significant amount of network resources (hashpower) to behave altruistically.
Micah Zoltu [2:01 AM]  If IOTA depends on people acting non-selfishly "for the greater good" then most of my arguments go away. I do not think that is a healthy assumption in a pseudoanonymous world though.
Micah Zoltu [2:15 AM]  TL;DR of the natural death of the network:
* Selfish client spams network with transactions.  These transactions have parents that are transactions this actor wants promoted.  They never promote anything that doesn't benefit them.
* Altruistic actors will randomly select parents (or MCMC or whatever).
* Given enough selfish actors, you end up with a situation where there are a bunch of heavy weight sub-tangles (which matters for confirmation) that include almost nothing else except the selfish actor's own transactions (and transactions where someone else sends them something).
* The altruistic actors are constantly trying to merge sub-tangles but they don't have enough weight to make it stick (confirm).
David S?nsteb? [2:24 AM]  I don't think you guys quite grasp the full vision of IOTA. IOTA enables streams of transactions (due to no fees). IOTA came about after considering the hardware environment, not the other way around IOTA exist soley due to hardware.
David S?nsteb? [2:38 AM]  Micah: if I offer you 10K to demontrate this, will you do it tomorrow? <-- https://iotatangle.slack.com/archives/C3V610ULS/p1497483482510115
Micah Zoltu [2:38 AM]  @david As I have said many times, I am way too busy to go and engineer a solution to your problem.  I came here trying to be helpful, not to actively attack your network. If I am going to engineer something it will be an actual attack against the network because that is worth way more than $10k.
David S?nsteb? [2:39 AM]  @micah.zoltu so essentially 10K is 'nothing to you', you want to be a malevolent actor and earn more? Ok, I am looking forward to it now that you admitted you're looking for a bigger pay out
Serguei Popov [2:47 AM] re:"By selecting your own transactions as parents, you increase the chances ..." - I doubt that "selecting your own transactions as parents" is a good strategy even for a "completely selfish" (whatever it means) node. Because (1) other selfish nodes won't reference your transactions because they owe nothing to you; (2) "honest" nodes won't reference your transactions because the random walk is very unlikely to choose them (see the "lazy tips" on figure 6 in the whitepaper). Therefore, if your goal is to get your transaction confirmed by the network, you should better do something that would cause at least the honest nodes to reference it. Because you'll reference tx's that are deep inside the tangle, and the RandomWalks's transition probabilities are chosen in such a way that it is extremely unlikely that the walker jumps from "deep inside" directly to a tip.
			re:"The altruistic actors are constantly trying to merge sub-tangles but they don't have enough weight to make it stick (confirm)." - "No! What will happen, is that the "altruistic" actors will build "their" subtangle, and all these "selfish" guys will selfishly fall to limbo.
Serguei Popov [2:48 AM]  Ah, and a concluding remark. Of course, it would be nice to have a proof that iota is secure. Believe me, I would really like to be able to obtain it. But I couldn't. Well, sometimes things get too complicated. So, all I have for now is my Markov chains' intuition, about which I humbly think it deserves some respect. Besides, do you realise that the entire modern public-key cryptography relies on unproven assumptions?! Should we stop using it until they prove that P?NP?"
Serguei Popov [2:50 AM] re:Chat-for-Ban's "We assume that 67% of nodes stick to one of the good strategies." - Don't think this assumption is necessary (I don't believe in "magic numbers"). Rather, the assumption is that "a good proportion of nodes follows a 'canonical' strategy", which is a perfectly reasonable assumption in the IoT environment, at least in the beginning.
			re: "I fear that everyone using a selfish strategy will result in the network falling apart. A tragedy of the commons." - At this point, I feel that some people try to apply intuition from Game Theory 101 to our situation, when quite a lot of (approximately) independent actors interact. Yes, it is true that, in general, if a system has unique stable state, it eventually gets there, and there remains. However, the time until it happens can be really large; things of this kinds are called metastability in the literature. Let us maybe consider a simple toy model. Assume that there are 100 nodes whose states can be 0 or 1; initially, there are 37 nodes in state 1, and 63 nodes in state 0. Then, at each (discrete) moment of time each node randomly chooses 50 other nodes, and (1) if at least one of these nodes is in state 1, then the state of our node will be 1 with probability 0.8 and 0 with probability 0.2, independently of the others; (2) if all these nodes are in state 0, then our node also becomes 0. This is an example of a metastable situation. The only stable state is obviously "all zeros". Eventually, it will be reached (after all, the state space of the system is finite). However, the time until it happens will be really huge. I'm too lazy to do the calculations, but I'm quite sure it will be much bigger than the lifetime of the Universe... Please, think about this example. That "slow heat-death" can be really slow  :slightly_smiling_face:
Micah Zoltu [2:51 AM]  You are asserting that random selection _is_ the selfish strategy.  Based on the whitepaper ("honest" nodes randomly choose n transactions from some time-window in the past and then walk randomly until they reach a tip.  Then the tips of the 2 "longest" paths are selected as parents.) I am unconvinced of this assertion and I would really like to focus on that. / Why honest nodes won't select my selfish transactions?
Serguei Popov [2:58 AM]  because we're assuming that you cannot outperform all the others in the number of tx's (this answers why they won't be chosen as a starting point of the walk. Or did you mean smth else?)
Micah Zoltu [2:59 AM]  Why do I need to outperform all others in number of transactions to be selected? Remember, we are talking about parent selection, not confirmation.
Serguei Popov [3:01 AM]  Are we talking about the selection of the starting point for the walk? Or its final point?
Micah Zoltu [3:11 AM]  So... with "longest-path-to-tip" walker pathing algorithm the insertion gets very expensive after a while. Anyway, I'm willing to glaze over the fact that pathfinding longest-path is hard and accept it since I don't think it matters. If path selection is longest-path, the selfish miner simply generates really long paths to optimize for inclusion by others.
Serguei Popov [3:12 AM]  re:"with "longest-path-to-tip" walker pathing algorithm" - No, it is not. It is the one described in the paper, with transition probabilities calculated using the cumulative weights (= sum of weights of the tx's that approve the given one, directly or indirectly).
Serguei Popov [3:16 AM]  Please, do listen to me. The algorithm is not "select the longest path". I'm just claiming that in "normal" situation it will select a long path (not necessarily the longest one). However, if you try to game it by producing a "long-path-of-yours", you'll fail.
Micah Zoltu [3:42 AM]  So.. We have a bucket of all transactions in the tangle.  Parent selection is based on a subset of that set, I'm calling this "eligible population".  You indicated that eligible population is based on height (trunk distance from genesis). So how the code decides where (at which tx) to place the walkers for parent selection process?
Alon Elmaliah [3:51 AM]  currently each tx has a given height. you can select the starting point based on height - which height is given by the user (using depth param)
Alon Elmaliah [3:52 AM]  height == max_trusted_height-depth.   you can set any address to give you a sense of height. you can also give a specific tx to start walking from.
Micah Zoltu [3:55 AM]  If you _have_ a selection algorithm, then that selection algorithm is what a selfish participant wants to target.

Chat-for-Ban [11:18 AM]  I'm not going to answer @micah.zoltu 's questions, now he is an example of my attitude towards those who don't have courage to admit when they lose a dispute.
Chat-for-Ban [8:10 PM]  @micah.zoltu you were caught on evading accepting losing in a dispute. At this point I treat you as a troll. Anything you want to tell as the last word before I ban you? I can wait for 5 mins.


Chat-for-Ban [11:49 AM]  System is protected via voting. Voting is shielded against Sybil attacks with help of resource-testing measures (done during attaching to tangle). If you imagine an attack as a swinging sword then network topology is the water. To swing with a sword being in the water you need much more strength to deliver the same blow.
As it was said numerous times: unlike other coins, in IOTA users don't do PoW all the time, so to do 34% attack you need to outpace only hashrate of active users. IoT environment increases leverage of the protection thus transforming 34% to 3400%.
Serguei Popov [3:21 PM]  re:"selfish is to get fast confirmation, so ppl will go to use that selfish client" - What he proposed so far as "selfish strategies" would actually lead to slower confirmation times for the one who uses them, not faster. The basic idea is: if you want to be accepted by others, do what they expect you to do. You know there is a complicated probability distribution on the set of tips, according to which the "honest" nodes choose their tips to reference. This probability distribution is effectively concentrated on "good tips", but there seem to be no way to discover which tips are (slightly) better other than running the MCRW many times. However, if a node is so selfish that he wants to really reference the tips whose weight (according to that distribution) is maximized, he would need to run MCRW really many times, and even then the gain would be marginal. However, running MCRW many times requires time/resources; after you spend some time on it, the state of the tangle will already change, so you'll have to start anew. In a way, it's like playing blitz in chess: if you want to win, you don't have to always play best moves; you need to play (reasonably) good moves, but fast ...

Serguei Popov [2017.06.08 2:46 AM] The idea of MCRW tip selection strategy: it should be (a) sufficiently random (otherwise too many "unlucky" tips would be left behind), and (b) resistant to attacks one can imagine
Micah Zoltu [2:48 AM] In the whitepaper it says the walkers should start "deep in the tangle".  How is deep defined?
Serguei Popov [2:48 AM] Don't know. As deep as possible, depending on practical viability
Micah Zoltu [2:49 AM] I mean, how are you defining "deep"? Far from all tips via all paths? (edited)
Serguei Popov [2:49 AM] yes
Micah Zoltu [2:49 AM] It seems that if you can answer the "what is deep" problem you don't actually need to walk at all? Or do you walk randomly backwards from known tips, then walk randomly forward from wherever you land? Or perhaps it just means "old" (e.g., transactions you saw come through a long time ago).
Serguei Popov [2:50 AM] well, you can just choose among all tx's that appeared between (say) 1 hour and 30 min ago
Micah Zoltu [2:50 AM] OK.  So you choose _old_ (but not necessarily deep) transactions.
Serguei Popov [2:51 AM] these are _likely_ to be also deep
Micah Zoltu [2:52 AM] Sure, though I think the paper should be updated to say "old" rather than "deep" because "deep" implies that the selection algorithm is based on depth, not on age. In reality, you select on age and then compute depth (sort of).
Serguei Popov [2:53 AM] well, I don't really know what is the "best" selection algorithm. we can probably think of many _reasonable_ ones
Micah Zoltu [2:53 AM] OK, so you choose `n` random old transactions then you walk forward from each of them randomly choosing a child at each step until you reach a tip.  Once you have done this for all `n` (or they have timed out) you then choose the lowest distancet two tips?
So this tells me that as a selfish actor _not_ following this strategy, the optimal strategy is to build on other of my transactions that I want to promote.
That is, any of my old transactions that are within the selection time window that have stuff built on top of them.  The more they have built on top of them, the less likely they are to be selected for (since they will have a long walk to a tip).
Serguei Popov [2:58 AM] time to tip shouln't be important. exit probabilities matter
Micah Zoltu [2:58 AM] from the white paper: "the two random walks that reach the tip set first will indicate our two tips to approve"
My goal as a selfish miner is to increase the probability as much as possible that average distance-to-tip for any one of my transactions in the starting point eligibility window is as short as possible.
Serguei Popov [3:00 AM] "My goal as a selfish miner is ..." <- You need to control the exit probabilities too.
Micah Zoltu [3:01 AM] If I understand your goal correctly, you are trying to achieve an parent selection strategy such that the optimal strategy in face of others following the same strategy is to similarly follow that strategy.
Serguei Popov [3:01 AM] the same or at least similar; to know which tips are likely to be selected by the others, you'll have to do MCRW anyway
!! Micah Zoltu [3:03 AM] I'm operating under the assumption that the cost of selection is marginal compared to other costs and it is relatively trivial for a selfish miner to pick the mathematically best parents to maximize their chances of being selected for in the future, without having to run any randomized simulations.
Serguei Popov [3:05 AM] "I'm operating under the assumption .." <- I'm not sure it's a reasonable assumption. How exactly the selfish miner would do that?
Micah Zoltu [3:05 AM] A selfish miner can track all live tips as well as track all of the transactions that are in the common selection window and the distance from each of those to all of their tips.
Serguei Popov [3:06 AM] I have to go, sorry.
...
Micah Zoltu [4:00 AM] I would _like_ to be convinced that following MCMC _is_ the optimal strategy for a selfish miner when all other miners are behaving the same way, but I don't see that as being the case at the moment.
So there is the question of whether the majority of IoT devices will include ASICs and burn electricity doing proof of work.  For that discussion I believe that in the long run that won't happen because that strategy is marginally more expensive than the alternative "do nothing" strategy and I don't see a campaign for social welfare of Iota winning out over a campaign for lower energy consumption/costs.
But its possible that with the right connections you can influence _enough_ big players and drive marginal costs down low enough that most people don't care.
Paul H [4:03 AM] I don't think that PoW locality is relevant to tip selection
Micah Zoltu [4:03 AM] Right, that was the first half of my discussion with Serguei.
The second half was tip selection strategy for a selfish miner.
Where in this case a selfish miner's goal is to make his tip _most-likely_ to be selected by others while also (if possible) not selecting anyone else's tips.
That is, the selfish actor wants others to select his tip while never selecting anyone else's tips.
The reason for not wanting to select anyone else's tips is because he recognizes that as someone with substantial hashing power, if he and other heavy-hashers follow the "don't help the network" strategy then they can change the market dynamics so that they can run their miners at a profit.  If others _don't_ join him in his strategy then at worst he simply is as well off (if not better) than using the default strategy. (edited)
So, the question is, is there a tip selection strategy that a miner can take such that he will bias tip selection of the common strategy actors towards his tips without having to include anyone else's tips in his selection.
Such a strategy would create a trustless conglomerate that could alter the market dynamics such that they can start charging inclusion fees.
e.g., someone could release such a client to high-hash-power individuals that would yield same rewards if no one else uses it, and _better_ rewards if others _do_ use it.
Paul H [4:09 AM] I'm probably about to lose wifi again, sorry (back on the road)
Micah Zoltu [4:09 AM] Finally, there is a third point of argument that I haven't really brought up yet which is total network hashing power will likely be _very_ low if there is no incentive to hash more than is minimally necessary to get included, since extra hashing costs money and without transaction fees there is no return on that investment.
projectShift (Ricardo) [4:10 AM] but why would that be a problem?
Micah Zoltu [4:10 AM] Looking at the selection strategy in the whitepaper, it doesn't appear that there is compelling reason to hash heavily since tip selection is random-ish.  The gains of hashing are marginal relative to the energy costs.
Well, it becomes a problem because it lowers the cost of a sybil attack.
e.g., if total hash power is small enough, a single entity could spin up a giant sub-tangle with enough hash power behind it and enough transactions in it that it dwarfs the main tangle.  That actor could double-spend (traditional double-spend with lots of power attack).
The entire point of doing PoW anything is to drive that price up.  But that only works if people are sufficiently incentivized to give away non-trivial amounts of hashing power.
e.g., if every transaction has 1 unit of hash power behind it and I can generate 1 gigaunits of hashing power per second, I can sipn up a complete isolated side-tangle, double spend, then merge it right at the optimal time (middle of the MCMW tip selection window).
projectShift (Ricardo) [4:11 AM] ah! (sybil) the ever present issue
Paul H [4:15 AM] This assumes that you have enough hash power to overcome the present hash rate of the network.
projectShift (Ricardo) [4:15 AM] his point was just that, the network would have low hash power because there is no incentive (edited)
Micah Zoltu [4:16 AM] Also, in the MCMW algorithm in the white paper it didn't see anywhere where weight actually came into the tip selection process significantly.
There was the weight range thing, but it seems incredibly gamable to ensure that you fall within that range. (just requires distributing your hashing power across an optimal amount of tangle, which the random selection people will not be doing). (edited)
projectShift (Ricardo) [4:17 AM] ^we played around with that in testnet, didn't really play as a factor of importance
Micah Zoltu [4:17 AM] Which?  The weight range thing?
projectShift (Ricardo) [4:18 AM] yeah, the range; we tried various intervals with spamming, it didn't amount to what was expected
projectShift (Ricardo) [4:18 AM] but that was 4 versions ago, ofc, may not stand like that anymore
Micah Zoltu [4:18 AM] So without weight playing in at all, hashing power is effectively meaningless and the strategy boils down to setting up the optimal sub-tangle such that it is incredibly likely to be chosen in a conflict.
Which means you _must_ have weight be a significant part of (tip) parent selection, but then it means someone with high hash power can bias selection towards their tangle because they are focusing their hashing power while everyone else is distributing it.
Paul H [4:21 AM] Currently, the own weight is not considered in the tip selection (all tx are counted as 1), but a tx rating for tip selection is the sum of its own weight and the cumulative weights of its approvers
Micah Zoltu [4:21 AM] ^ So at the moment, it sounds like (tip) parent selection is basically just "shortest path to tip" from random transaction within a given time window.
Paul H [4:24 AM] it's not shorest path, but weight-est path
tx with most tx packed on it is the one that becomes most likely to be selected starting from a tx somewhere in the past ( currently milestones )
Micah Zoltu [4:24 AM] According to the whitepaper: "the two random walks that reach the tip set first will indicate our two tips to approve"
Reaching tip first is shortest path since all walkers walk in lockstep, right?
My interpretation of the strategy based on whitepaper and earlier discussions is:
So choose `n` random transactions between `x` seconds ago and `y` seconds ago.  Randomly walk towards tips from each of those in lockstep with eachother (they all step simultaneously) until two have reached a tip.  Those two are selected as parents.
I suspect my interpretation is wrong since it doesn't include weight (hash power) at all.
Its effectively a "without burning too much resources on optimization, try to find the least connected transactions and connect them to each other.  Over time this should lead to a general merging of all known sub-tangles. (edited)
AFK (for reals this time).
projectShift (Ricardo) [4:29 AM] ^that is an important factor, so we can have one big Tangle ... but only one.
Matthew Niemerg [4:33 AM] How I read the WP with the MCMC method, you take `n` random walkers placed on `n` random transactions. They walk towards the tips independently.  Choice in which direction to go is weighted more towards a transaction with higher cumulative weight if you are deeper in the tangle and then as you get closer to the tips, this spreads out to more of a random walk.  Then, in order to determine what your transactions' confirmation threshold is, you take number of random walkers that reach a tip that directly or indirectly reference the transaction of interest and divide that by `n` to give you percentage.
So I don't understand why walkers would be in lockstep.  They all reach a tip at some point (finite path length) and are independent.  You just need to know how many walkers reference the transaction of interest to get a probability that you are 'good'.
And as Paul mentions, all weights of each transaction are 1, but cumulative weight of a transaction isn't the sum of the path length.  Cumulative weight is the sum of all direct or indirect references of other transactions (only counted once), as per the definition.
Micah Zoltu [5:53 AM] What you just described doesn't sound like (tip) parent selection, it sounds like confirmation probability calculation.
It _feels_ like an altruistic (tip) parent selection algorithm would want to choose the heaviest weight tip and combine it with the tip with the highest unique weight.  The goal of this altruistic miner would be to attempt to get all transactions to converge to a single tip.
Of course, this strategy doesn't do anything to defend against an attacker generating a larger subtangle, double-spending on it and the current dominant tangle, then introducing their subtangle into the network and convincing everyone to build off of it instead.
Matthew Niemerg [6:12 AM] No. Tip selection is still a random walk. You have walkers that are moving towards the tips. Hence the walkers land on tips and that is selection. Oh you mean, tip selection as in, new transaction picks transactions to refer to.
Micah Zoltu [6:13 AM] 
Right.  What I was describing above was "parent selection" selection, not confirmation calculation.