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?