Reading through 
the whitepaper now.
Could you help me wrap my brain around the concepts?  Here's what I think I understand so far:
--
1. When a new transaction is broadcast to become a 
tip, it must 
approve two existing transactions.  What does it mean to 
approve an existing transaction?  Is it similar in concept to generating a block hash in Bitcoin?
2. Section 2 indicates that a node may invest a variable amount of 
work into creating the transaction (ultimately resulting in an 
own weight value that is equal to a power of 3).  What is the nature of the 
work?  Again using Bitcoin concepts, would this be similar to voluntarily using a higher/lower difficulty when computing the block hash?
3. Each transaction has 2 different weights and a height:
  a. Its 
own weight, which is determined by the amount of 
work that was invested into creating it (see question 2 above).
  b. Its 
cumulative weight, which is determined by summing the 
own weights of all of the transactions 
that approve it, plus the 
own weight of the transaction itself.  Conceptually, you could think of this like tracing all of the paths from that transaction to the tips and adding up all of the 
own weights of the transactions that you encounter along the way.
  c. Its 
height, which is determined by summing up the 
own weights of all the transactions 
that it approves, plus the 
own weight of the transaction itself.  Conceptually, you could think of this like tracing all of the paths from that transaction all the way to the genesis block and adding up the 
own weights of the transactions that you encounter along the way.
4. A new 
tip is allowed to approve 
any two existing transactions at any 
height(s), but it is more valuable to the network if incoming transactions approve other 
tips with the highest possible height, in order to ensure that new transactions get confirmed, correct?  Is that the problem being addressed in section 3?
5. Unlike, say, Bitcoin, you don't try to entice the network to include your transaction by including a transaction fee; instead you try to ensure that your transaction's 
height is within the top xx% of all 
tips in the network, so that it is more likely that other nodes will prefer to approve your transaction.
6. If your transaction's 
height isn't enough, you could try to increase it by generating empty transaction(s) that approve it.
  a. The new transaction(s) have a larger height than the original one, and if they also approve another 
tip with a large 
height (recall that each transaction must approve exactly 2 others), then that could be enough to bump the new transaction into the coveted "top xx%" subset.
  b. If more 
work is invested into the empty transaction(s), this also increases their 
height values (because the transaction's 
own weight is included in its 
height).
7. A double spend could theoretically be carried out against the network in one of two ways:
  a. An attacker spams the network with a massive number of new transactions approving the double-spend transaction and not the legitimate transaction (even indirectly).
  b. An attacker submits a new transaction with a huge 
own weight (by investing lots of 
work into it) that approves the double-spend transaction and not the legitimate transaction.
If either attack succeeds, the network builds on the transactions from the double-spend, orphaning the the part of the DAG where the legitimate transaction resides.
It is not clear to me, though, what that actually looks like.  Does the DAG get pruned?  Do transactions have inputs and outputs similar to Bitcoin, and in the event that two transactions reference the same inputs, the one with the larger 
cumulative weight wins?