diff --git a/TrickleMessages.md b/TrickleMessages.md
index 0ada4f4..79314b5 100644
--- a/TrickleMessages.md
+++ b/TrickleMessages.md
@@ -1,4 +1,6 @@
-*Trickle messages* let applications communicate with the server during the execution of a workunit.
+# Trickle messages
+
+**Trickle messages** let applications communicate with the server during the execution of a workunit.
 Messages are XML documents, and they may go from client to server or vice-versa.
 Trickle messages are asynchronous, ordered, and reliable.
 Since they are conveyed in scheduler RPC messages, they may not be delivered immediately after being generated.
@@ -7,17 +9,17 @@ See [the APIs for sending and handling trickle messages](TrickleApi).
 
 # Trickle-up messages
 
-*Trickle-up* messages go from application to server.
+**Trickle-up** messages go from application to server.
 By default they are sent to the project's scheduler;
 you can optionally [replicate them to other schedulers as well](TrickleApi#Replicatedtrickle-upmessages).
 
-They are handled by *trickle handler daemons* running on the server.
+They are handled by **trickle handler daemons** running on the server.
 Each message is tagged with a 'variety' (a character string).
 Each daemon handles messages of a particular variety.
 (This is used, typically, to distinguish different applications.) Example uses:
 * The application sends a trickle-up message containing its current runtime,
    so that users can be granted credit incrementally (rather than waiting until the end of the work unit).
-   BOINC supplies [a trickle handler for this purpose](CreditAlt).
+   BOINC supplies [a trickle handler for this purpose](CreditOptions).
 * The application sends a trickle-up message containing a summary of the computational state,
    so that server logic can decide if the computation should be aborted.
 
@@ -27,7 +29,7 @@ Add an entry in your [config.xml](ProjectConfigFile) to run this program as a da
 
 # Trickle-down messages
 
-*Trickle-down* messages go from server to application.
+**Trickle-down** messages go from server to application.
 Each one is addressed to a particular host,
 and must include an element <result_name> identifying the result to which the message is addressed.
 If that result is still running on the host, it is delivered to it. Example uses: