If and when miners start relying on transaction fees much more than block rewards, these transactions won't get confirmed as easily as they are now. So I'm thinking of another idea that doesn't require them.
I was also worrying about confirmation fees, but you came up with a smarter idea to address that than I did. I had simply been imagining a future scenario where the value of building your trust record is worth paying the incremental miner fees to "register" each transaction using the AudenX pattern, but that might be too optimistic if confirmation fees become significant.
Instead of making two new transactions to reflect the beginning of and subsequent satisfaction with a transaction X, put that information into an input in the next transaction N from an address known to belong to the same user who paid BTC in transaction X.
That seems like a step in the right direction. Not sure if this is exactly what you are describing, but after reading your response I started thinking the signaling pattern could be modified as follows. In addition to reducing cumulative confirmation fees, it eliminates the need for a "scorecard" address:
Alice (1AliceAudenXIdentityAddress) agrees to pay 1 BTC to Bob (1BobAudenXIdentityAddress) for a pair of alpaca socks. Both parties want the transaction to be reflected on their AudenX (1AudenXAddressOfRecord) trust histories.
Alice kicks off the AudenX process by creating a Bitcoin transaction. Let's call this transaction the "Alice-to-Bob-Open" signal.
INPUT: 1AliceAudenXIdentityAddress
OUTPUT1: 1BobPaymentAddress (1 BTC)
OUTPUT2: 1BobAudenXIdentityAddress (0.0001 BTC)
OUTPUT3: 1AudenXAddressOfRecord (0.00001 BTC)
Bob confirms that he's participating in this AudenX process by creating a Bitcoin transaction in response. Since he doesn't owe Alice any Bitcoin, he piggybacks his AudenX signal on top of a payment he owes to Wordpress. Let's call this transaction the "Bob-to-Alice-Open" signal.
INPUT: 1BobAudenXIdentityAddress
OUTPUT1: 1WordpressPaymentAddress (0.5 BTC)
OUTPUT2: 1AliceAudenXIdentityAddress (0.0001 BTC)
OUTPUT3: 1AudenXAddressOfRecord (0.00001 BTC)
AudenX, having received two payments, examines the associated transactions and can recognize the signals Alice-to-Bob-Open and Bob-to-Alice-Open. AudenX ignores any transaction outputs that don't fit the signaling pattern. Now AudenX knows that Alice and Bob have started a transaction. (Until AudenX sees the closing signals from Alice and Bob, the AudenX pattern is incomplete. Incomplete patterns can reflect negatively on an AudenX identity's trustworthiness, because it indicates that two parties haven't resolved their transaction, which might indicate a dispute, or the inability of one or both parties to signal correctly.)
When Alice and Bob complete their alpaca-socks-for-Bitcoin trade, they can indicate their satisfaction with the trade as being equal to, less than, or greater than the baseline score (which they each set at 0.0001 BTC in this example). Say Alice is 110% satisfied with the socks she's received, but Bob's a bit annoyed that Alice took so long to respond to his email requesting her shipping address, so he's just 90% satisfied.
To save on confirmation fees, the parties wait to send their final AudenX satisfaction scores until their next Bitcoin transaction. Then they create transactions like these:
"Alice-to-Bob-Close" signal (piggybacked on Alice's payment to the grocery store):
INPUT: 1AliceAudenXIdentityAddress
OUTPUT1: 1GroceryStorePayment (0.75 BTC)
OUTPUT2: 1BobAudenXIdentityAddress (0.000115 BTC) <-- 115% satisfied
OUTPUT3: 1AudenXAddressOfRecord (0.00001 BTC)
"Bob-to-Alice-Close" signal (piggybacked on top of Bob's dinner date tab):
INPUT: 1BobAudenXIdentityAddress
OUTPUT1: 1DinnerAndAMovieDate (1.10 BTC)
OUTPUT2: 1AliceAudenXIdentityAddress (0.000090 BTC) <-- 90% satisfied
OUTPUT3: 1AudenXAddressOfRecord (0.00001 BTC)
What do you think?