Sukrim, welcome and thanks for your comments!
What do you do when the pool has still ~500 BTC in outstanding shares but the block reward cuts in half?!
In this case, it would take more good luck for the backlog of outstanding shares to be fully paid. Transaction fees would also help to pay for these older shares over time.
The system you're using is RSMPPS, as far as I see it (interestingly with custom share difficulty, probably to keep pool load lower).
The Delayed PPS model was developed independently, but does bear close resemblance to RSMPPS. Since the way that the pool credit buffer is distributed may differ somewhat from what is implied by RSMPPS, I've chosen to use a different name and to explain the details. The general idea, however, is the same.
What I find strange is the "shares never expire" part - this would mean it's intelligent to fetch a few shares if difficulty goes down and solve them later in the future if difficulty goes up. This also means you'll have to track every share in the pool forever...?!
While earned shares do not expire, getworks become stale normally and prevent this issue from arising.
Also:
"BitPenny can safely support over 50% of the network without the pool operator being able to execute double-spend attacks"
is not true, as no miner can choose which transactions get included in the block he's mining without having access to the source code. I really like the fact though that you're displaying all current transactions in the current block on a page (yes, it could be faked, but it's a great start!).
Each client submits winning blocks directly to the bitcoin network. Blocks are verified against a local copy of the block chain using the standard ProcessBlock function, and any attempt by the server to double-spend or fork the chain would result in a block rejected by the client.
You can monitor the transactions locally as they come in by setting setprintblocks to true and observing the debug.log file:
bitpenny@BitPenny3:~$ ./c.sh setprintblocks true
bitpenny@BitPenny3:~$ tail -f .bitpenny/debug.log
The code will be opened up when BitPenny's hashing power gets big enough to be of concern, and miners will have the ability to implement finer controls at that point.
What's the 3% pool fee used for? Users host their own modified bitcoind-VM. I guess there's still an central element that collects the transactions + shares, but as there are other *PPS (not pure PPS) pools out there with lower fees, you'll need some very compelling reasons to use your system (and clog up some HDD space with a VM + complete blockchain I guess).
All the best with your pool anyways, it surely seems like an interesting concept.
The fees go towards paying for servers and bandwidth, development, and support. Even though getworks are local, BitPenny uses a significant amount of bandwidth to push data to its nodes. We also offer a perfect solution for CPU farms and similar users who may not be welcome in other pools due to high getwork/submission ratios. BitPenny is an unusual pool in many ways, and the best way to see what sets it apart is to give it a try.