you see in ECDSA when you want to create a signature from an arbitrary length message you don't sign the message itself, instead you use a hash algorithm (double SHA256 in bitcoin) then use that result in the signing formula.
so the collector node could hash the message itself (the first step of signing) then send that hash to the node that has the private key locally and can sign it then send the signature back to the collector node.
since hash is a one-way function the receiving node can not know what the message was.
I can't do that, because the message that is to be multi-signed includes a list of all nodes that have sent a private key to the collector node. It's up to the nodes whether or not they want the collector node to include them in the list.
The purpose of this exercise is to implement a new consensus algorithm to replace proof-of-work. Let's call it proof-of-votes. I'm still working on the white paper. In this proof-of-votes-based chain, the chain with the cumulative highest amount of votes is the "valid" chain. Let's assume there are 10000 nodes participating in the network. In this proposed consensus algorithm, nodes cast votes by sending a one-time-use private key (m/n where n is the next block height) to the node they vote for (the collector node). The collector node then collects these keys and uses them to multi-sign the next block hash. The multi-sig is the proof-of-votes and is included in the block header, while all the nodes that voted for the collector node are included in the block body and receive coins. So up until the actual creation and signing of the block hash, the collector node doesn't even know which nodes will end up in the block body. The collector node doesn't just want to collect signatures from the nodes, because including all the signatures in the block header will make the block header balloon to unfeasible sizes. Broadcasting a multi-sig created with 5,000 private keys is feasible, but broadcasting 5,000 individual signatures is not.
When the new block is broadcasted, all the other nodes in the network need to be able to verify the multi-sig. So they take the xpubs of the 5,000 nodes included in the block body, derive the m/nth pubkey and validate the multi-sig.
So that's why I'm asking if there is a way to share a "throw-away" private key with one collector node, while at the same time having the xpub publicly available to allow all the other nodes to verify what the collector node has been doing with the private key. Without enabling the collector node to calculate the original xpriv.
Maybe BIP-32 isn't the right tool for this job. So now I wonder if there is something else that I could use to "shrink" multiple signatures into one tiny signature to implement this algorithm.