DDD: one bounded context or two?

Suppose I've built a system for my client that allow gamblers to maintain a portfolio of bets and track their gains/losses over time. This system supports a lot of complex domain logic - bets on different sports, rolling over wins to other bets etc.

Next my client wants to support the idea of tipsters. The tipsters do not actually gamble, instead they create "tip sheets", which are their tips on what bets to place. The tip sheets can be of different kinds - some can include tips on any bettable event, others only offer tips on horse racing, and so on. My client wants the system to track the performance of tipsters in the same way as it tracks the performance of gamblers, with the additional twist of being able to compare performance within and across different kinds of tipster (e.g. who is the best horse racing tipster? do they in general perform better than football tipsters?)

Now, the domain language is completely different between gamblers and tipsters, and there is the additional categorisation of tip sheets that doesn't exist for gamblers' portfolios. This suggests these are separate bounded contexts. However, there is a lot of shared logic as they both track performance over time.

So my questions are:

Are these really separate bounded contexts? I'm wary of adding categorisation to the gamblers context (feels like a slippery slope).
If they are distinct contexts, should I:
- Share performance tracking logic between them (i.e. share DLLs, jars etc)? This creates a tight implementation coupling between the contexts which feels wrong.
- Leave the performance tracking logic in the gambling bounded context, place the categorisation logic in the tipster bounder context, and have it ask the gambling context to track performance? In this case, it seems like the tipster context will send commands to the gambling context, which again feels wrong (I'm more comfortable with events).
- Do something else...some kind of composition layer that communicates and correlates between both contexts?

Clarification

A gambler's portfolio and a tipster's tip sheet are almost identical - the only difference is that the tip sheet can be categorised (e.g. horse racing, football etc).

Performance tracking is about measuring the profit/loss of the portfolio/tip sheet.

Solution

I'd probably agree with Mike that Performance Tracking sounds like a Bounded Context on his own. This looks like the more evident boundary.

Betters and Tipsters might act on different aggregates of the same bounded context or different bounded contexts. I'd be inclined to choose the latter, according to what you say about the language, and about project evolution.