Hello! Sorry we’ve let these questions languish.
Two groups of people maintain the list. This is part of the DHT’s ‘fast push, slow heal’ strategy.
- On initial publish (fast push), the author spams the authority neighbourhood of the entry. This means that, if they aren’t in the authority neighbourhood themselves, they need to collect the addresses of at least R authorities from the neighbourhood. Then they contact each of them directly and collect the validation certificates. This becomes the initial ‘validation bundle’, which happens to include the mean validation time from the authorities they contacted (which may be useful for validation of future entries). After that, I’m not sure if the author just keeps the validation bundle or republishes it to all of the authorities. I think republishing isn’t necessary because…
- During gossiping between authorities (slow heal), they also share their own validation receipts with each other. Eventual consistency means there’s never guaranteed to be a single, authoritative list of validation receipts, especially in a DHT that’s always changing. But the important thing is that, from the perspective of each authority (and the perspective of each node requesting data from that authority), they’ve collected enough information to convince themselves that the data is indeed valid.
So to answer your question, yes the signature aggregation is updated frequently as a natural result of the DHT adapting to current conditions. Each event that causes an authority to give a new piece of data to a neighbour (either by push or by pull) causes that neighbour to produce a validation receipt, which is then gossiped to the original authority and all the other neighbours. FWIU the author won’t get those follow-up receipts, though I could be wrong!
This isn’t included in the TestFuel design, due out for release as I’m speaking, but in the future the validation rules will also say something like “if an agent has spent x amount of HoloFuel without paying x * current_txn_fee to the infrastructure provider account, subsequent transactions are invalid”. Or something like that; it may just be a simple accrual threshhold. So all honest agents will do the validation for Holo, relieving us of the need to snoop into other people’s lives unduly. Yes, it is possible that the majority of hosts could decide to run a forked version of HoloFuel that doesn’t involve transaction fees, but they’re kind of killing the goose that lays the golden eggs at that point.
For making sure hosts and app providers are actually transacting, the situation is similar but different. Again, Holo doesn’t want to go snooping into others’ business, but it is a party to every HTTP request because we run the proxy/router between hosts and web users. And it does facilitate the initial introduction between host and user, because it has to know who’s hosting what hApp. I don’t think we can snoop the individual requests to see what hApp they’re for, because they pass TLS-encrypted through our router, but we do know which host it’s being routed to. Anyhow, maybe we’ll be able to run periodic fraud detection on initial host allocation and host routing based on the little we do know, combined with public service logs from each host. But I don’t see how we could build this into validation rules without it becoming pretty heavy.
[EDIT] Oh, I see your later message about Art answering your first question in the AMA. Sorry, just working from the top down! 
Hopefully others can read this and gain some benefit from it.
This would be up to the CEX’s developers doing the integration. The way I see it, it would be automatic, managed by a script that the CEX has created and run on their server. (A Holochain DNA doesn’t care who’s talking to it – UI or script is fine, as long as it can talk HTTP, is running on the same machine as the DNA, and has the right credentials.) And yes, I imagine finality time would be longer with large-value transactions split between multiple microtransactions. But in my opinion that reflects the risk and value involved. I can’t speak for traders and whether they’d tolerate that, but HF’s main use case is of course regularly cleared, small value transactions.
HoloFuel’s DNA is currently designed to permit the initiation of multiple pending transactions at the same time. Sort of like a credit card authorize/capture, where funds are held but not withdrawn until the merchant confirms. But as Art says, there is a bottleneck in which each transaction has to be finalised sequentially. I don’t know if the final HoloFuel design will still have that feature, but I don’t think it has much of an impact on finality speed, especially in a CEX where this is likely to be handled automatically.