Order outputs by amount and not in buckets to keep and send

[callebtc]

For privacy reasons, the outputs should be ordered in a deterministic fashion so that the mint can not deduce what amount we are trying to send or keep.

See the note in NUT-06:

Note: In order to preserve privacy around the amount that a client might want to send to another user and keep the rest as change, the client SHOULD ensure that the list of BlindedMessages is ordered by amount in ascending order. As an example of what to avoid, a request for tokens expressed like so: [16, 8, 2, 64, 8] might imply the client is building a payment for 26 sat; the client should instead order the list like so: [2, 8, 8, 16, 64] to mitigate this privacy leak to the mint.

The following piece of code in CashuWallet.ts and especially this.createSplitPayload should return an Array of blindedMessages that is sorted by amount and a boolean vector of which ones to keep and which ones to send so that we don't have to do the sum at the end of the block but simply filter the returned proofs by this vector.

if (amount < amountAvailable || preference) {
	const { amountKeep, amountSend } = this.splitReceive(amount, amountAvailable);
	const { payload, blindedMessages } = this.createSplitPayload(amountSend, proofsToSend, preference);
	const { promises } = await this.mint.split(payload);
	const proofs = dhke.constructProofs(
		promises,
		blindedMessages.rs,
		blindedMessages.secrets,
		await this.getKeys(promises)
	);
	// sum up proofs until amount2 is reached
	const splitProofsToKeep: Array<Proof> = [];
	const splitProofsToSend: Array<Proof> = [];
	let amountSendCounter = 0;
	proofs.forEach((proof) => {
		if (amountSendCounter >= amountSend) {
			splitProofsToKeep.push(proof);
			return;
		}
		amountSendCounter = amountSendCounter + proof.amount;
		splitProofsToSend.push(proof);
	});
	return {
		returnChange: [...splitProofsToKeep, ...proofsToKeep],
		send: splitProofsToSend,
		newKeys: await this.changedKeys([...(promises || [])])
	};
}

[Egge21M]

@callebtc started implementing this in #100

Is this what you had in mind?