1 - The double-spend problem is dealt with in the same way as it is with the current bitcoin network: The longer (computationally difficult) the block chain gets, the more secure previous transactions become. 2 - Short-interval blocks will not be good for blockchain storage, and it's even worse due to multi-pathing. However, less transactions per block will leads to significantly smaller blocks. Finally, most miners/users can drop old information (and only keep a couple months of data recorded). Same as with standard Bitcoin, it would scale with use. It will definitely be a manageable size. – Kent – 2014-08-07T04:11:50.070

@Builder_K Since you still need to wait for sufficient proof of work before you can consider a transaction to be confirmed, what's the benefit? All you've done is generate blocks really fast. Why is that good? – David Schwartz – 2014-08-08T00:26:28.223

The whole point, is that if a transaction is in two blocks, which are then merged into a third block, the computational difficulty of forcing a double spend is the added sum of all parts, in this case, the added sum of all three blocks' difficulties. In order to force a double spend, an attacker would need to outpace all of these blocks. In this way, an attacker is forced to work against to processing power of the entire weave, instead of only outpacing a singly-linked block chain. – Kent – 2014-08-08T00:45:41.110

Also, since the weave can split & merge as needed, distant nodes do not need to be immediately aware of each other's activities, allowing for a much faster block generation rate (Without the network constantly dropping invalid side chains). The whole purpose here is to combine the processing of the network against attackers, rather than allowing the winner's block to make choices for the entire network. This more quickly locks out the possibility of attackers catching up to the network, allowing for extremely fast and secure transactions. – Kent – 2014-08-08T00:48:23.353

1 second is not enough -> See note 3 towards the end. Runner ups are not well defined -> The runner-ups don't need to be well defined, each node chooses the highest-cost blocks that if knows about, and merges them into the new block. Block rewards are assigned by... -> As time passes, and the chains are merged back together, it can be determined which path took the most work to generate, only the highest-cost path generates coins. Going back in time, create sidechain -> the sidechain would have a lower creation cost than the master, so it could never force an invalid transaction. – Kent – 2014-08-07T21:29:42.533

Never getting two blocks that do not conflict -> Transactions are the only thing that can conflict, and (as described in the document) these conflicting transactions are dealt with as the blocks are merged together, by simply choosing the most-verified (i.e. highest computation-cost-to-verify) version. If a transaction is in both blocks, there is no conflict. – Kent – 2014-08-07T21:35:59.570

Any modification, i.e., removing conflicting transactions, invalidates the proof-of-work that made the runner up a block, hence making a purged block indistinguishable from something that does not meet the proof-of-work requirements. – cdecker – 2014-08-08T10:11:53.080

No, the invalid transaction is not removed from the block. it is simply noted in the new block which of the two competing transactions is the real one. This was, only a single side of a single competing transaction pair is invalidated, not the entire block. – Kent – 2014-08-08T22:23:01.393