Include ordering account address in on-demand order placed event

[eskimor]

This should make it easier for parachains to reimburse the right account. This should address @bkchr concern mentioned here:

One thing for sure is that if I buy a slot for my collator, I also want to be able to be the only one sending the data.

While this alone would not prevent someone else from sending the data, it makes sure the one placing the order gets reimbursed. Any additional rewards might still go to the other node sending the data, but this is not any different than for bulk parachains and can be prevented by the parachain itself, by limiting the legitimate block authors at a particular point in time.

This works better than trying to prevent others from sending the data (collation). First of all we eventually want that providing nodes are not necessarily the block producer, second with the current backing group design it would be very difficult to effectively enforce any such restriction. With asynchronous backing we can have two upcoming cores for a particular parachain. Let's assume one is restricted to just a particular node A, while the other is not. Then we have to accept any collations, not just As because of the other core that is in scope. We could limit by amount: E.g. we only accept one collation not by A, but given that we have multiple backers, this does not work either (without a consensus system in backing).

Either way, I believe providing the means, so that the account ordering a core, is also the one that is going to be rewarded should already do the trick.

[burdges]

I've previously suggested this field not be an address but instead be arbitrary data interpreted by the parachain itself, perhaps during the parablock which recognizes the purchase. This gives parachains more options.

Also, there is no reason for a parachain's authority keys to be an account key recognized by polkadot, or for the purchase to come from an account instead of a message.

[bkchr]

Either way, I believe providing the means, so that the account ordering a core, is also the one that is going to be rewarded should already do the trick.

What prevents anyone from sending junk data to "burn" your reward?

[eskimor]

Fair point! Severity of this would at least be greatly reduced by implementing this. In particular by making use of the described "seeding" a collator can protect itself.

This is not as good as only accepting a collation from a particular collator in the first place. On the flip side, for reserved parachains we don't have such a protection either. Also with asynchronous backing the attack becomes harder as there is more time for the collator to get a valid collation through.

TL;DR: The issue is not unique to on-demand. It might feel worse, because you paid for a particular core and not for a lot of them in bulk. But the fundamental issue is the same: Someone is preventing you from using a core you paid for. Therefore I would strive for a solution that works for both, bulk and on-demand.