How was the recursive call vulnerability attack conducted via proposal #59 when there were no Yes votes?

Question

From Which split proposal was used to mount the recursive call vulnerability attack on The DAO?, proposal #59 is very likely the vector uses by the attacker to hack 3,641,694.241898506 Ether ($59,578,117.80) (from Is there any way to determine how long it took for the DAO attacker to deploy the attack?).

From my understanding only individuals voting Yes on the split proposals to be able to withdraw ETH from The DAO (see How to withdraw Ether from The DAO?).

Also from Deconstructing theDAO Attack: A Brief Code Tour:

The mechanism for doing so is to create a split proposal. Split proposals take 7 days to 'mature' and get participants in. Any participants voting "yes" in the split will be given the right to call splitDAO.

splitDAO will create the DAO child contract if it doesn't exist, send the ether controlled by the splitters into the childDAO, pay out any accrued 'reward' pro-rata to the splitters, and return. At least, that's the plan.

And from DAO.report you can see that no one voted Yes to proposal #59:

You can see the same information for proposal #59 in Which split proposal was used to mount the recursive call vulnerability attack on The DAO?.

From the source code for splitDAO(...) (from EtherScan.io - The DAO) there is a restriction !p.votedYes[msg.sender] that throws an error if the splitDAO(...) function call was called by a caller who has not voted Yes:

    function splitDAO(
        uint _proposalID,
        address _newCurator
    ) noEther onlyTokenholders returns (bool _success) {
 
        Proposal p = proposals[_proposalID];
 
        // Sanity check
 
        if (now < p.votingDeadline  // has the voting deadline arrived?
            //The request for a split expires XX days after the voting deadline
            || now > p.votingDeadline + splitExecutionPeriod
            // Does the new Curator address match?
            || p.recipient != _newCurator
            // Is it a new curator proposal?
            || !p.newCurator
            // Have you voted for this split?
            || !p.votedYes[msg.sender]
            // Did you already vote on another proposal?
            || (blocked[msg.sender] != _proposalID && blocked[msg.sender] != 0) )  {
 
            throw;
        }     

So, how was the attacker able to drain the ETH from The DAO when they did not vote Yes on proposal #59?

Was there another vector that was employed by the attacker?

Answer 1

User DTO in a DAOhub.org post How was the recursive call vulnerability attack conducted via proposal #59 when there were no Yes votes? pointed out:

There were two yes votes, just very low on tokens and are rounded down to zero:

0xc0ee9db1a9e07ca63e4ff0d5fb6f86bf68d47b89
0xf835a0247b0063c04ef22006ebe57c5f11977cc4

But both accounts have 0 The DAO tokens - the tokens may have been transferred away:

user@Kumquat:~$ theDAOVoter --listaccounts --account=0xc0ee9db1a9e07ca63e4ff0d5fb6f86bf68d47b89
  # Account                                                            ETH                        DAO The DAO transfer blocked by OPEN proposal?
--- ------------------------------------------ --------------------------- -------------------------- ------------------------------------------------------------
  0 0xc0ee9db1a9e07ca63e4ff0d5fb6f86bf68d47b89        0.000000645417097014         0.0000000000000000 
--- ------------------------------------------ --------------------------- -------------------------- ------------------------------------------------------------
  1 Total                                             0.000000645417097014         0.0000000000000000
user@Kumquat:~$ theDAOVoter --listaccounts --account=0xf835a0247b0063c04ef22006ebe57c5f11977cc4
  # Account                                                            ETH                        DAO The DAO transfer blocked by OPEN proposal?
--- ------------------------------------------ --------------------------- -------------------------- ------------------------------------------------------------
  0 0xf835a0247b0063c04ef22006ebe57c5f11977cc4        0.000000645417097014         0.0000000000000000 
--- ------------------------------------------ --------------------------- -------------------------- ------------------------------------------------------------
  1 Total                                             0.000000645417097014         0.0000000000000000

From the 0xc0ee9db1a9e07ca63e4ff0d5fb6f86bf68d47b89 transaction listing, there were many transfers of 25,805.6141471 DAOs up until 1 day 2 hrs ago (6/17/2016 12:27:23 PM), including a transfers from 0xf835a0247b0063c04ef22006ebe57c5f11977cc4. The last transfer was to 0xca04d260356d19f0d7255041542c9cbc866f2cb3.

And from 0xc0ee9db1a9e07ca63e4ff0d5fb6f86bf68d47b89 and 0xf835a0247b0063c04ef22006ebe57c5f11977cc4, you can see both accounts vote on both proposals #59 and #64.

Here's some data on proposal #64:

=======================================================================
Proposal 64. OPEN until Thu Jun 16 16:02:14 2016 [-2d 05h 59m 39s]
Votes       YEA 3069670 (99.99%) nay 250 (0.01%) Quorum 0.27% of 20%
Creator     0x547389052a8dc86365c46641b5184956ec22749d
Recipient   0x547389052a8dc86365c46641b5184956ec22749d
Deposit     0 ETH
Amount      0 ETH
New curator Y
-----------------------------------------------------------------------
0x54738 Split
=======================================================================

So proposal #64 could be another attack vector? (But I don't know what has stopped the attack via proposal #59).