So the wiring and communication between MCU and NRF seem to be ok. 
I would lose the
// put your setup code here, to run once:
// put your main code here, to run repeatedly:
Noob lines.
The baud rate is ancient, I use 115200 (only because it is the highest rate that the
version of the new IDE I use supports for the serial monitor).
If you want to use more than two pipes, two addresses have to share the uppermost 4 bytes.
So, while your pipe "00001" is absolutely correct,
it will lead you in a wrong direction if you add more pipes.
The logical (IMHO) second pipe would be "00002", if you use pipe 0 and 1 it will work as expected.
A valid third pipe on the other hand, could not be "00003", but has to be something like
"10001" or "10002", depending on which address you select for pipe 1.
Using more than one pipe can be useful, each pipe can be configured differently.
This is 12 byte 'meaningful' data and 20 bytes zeros,
which is slower than sending only the useful part and has a bigger collision chance.
radio.enableDynamicPayloads() allows you to automatically adjust the packets.
radio.getPayloadSize() allows the receiver to access the length of a received packet.
Why are you not interested in the outcome of the send?
It checks the acknowledgement that is sent back from the receiver,
useful information in a test setup,
and allows for packet repeats for more than the automatic number of retries,
error messages or something else in a production sketch.
Even for a test program, don't use delay. Buttons can be very useful for testing.