Coco should keep a separate table with proofs that should be received later, e.g. when online, or when there is enough proofs to maximize fee-efficiency.
Proofs to be received later:
Possible approach:
When encountering a p2pk or dust transaction, coco will look up the receive_later table for proofs from the same keyset, that can be combined for fee saving. If there are none coco will add the incoming proofs to the table. If there are any it will calculate the amounts required to reach the fee ceiling batch them.
input_fee_ppk: 100 -> Receiving 1 proofs = 1 sat, but receiving 10 = 1 sat too. -> we should wait with the receive until we have at least 10 proofs
Coco should keep a separate table with proofs that should be received later, e.g. when online, or when there is enough proofs to maximize fee-efficiency.
Proofs to be received later:
Possible approach:
When encountering a p2pk or dust transaction, coco will look up the receive_later table for proofs from the same keyset, that can be combined for fee saving. If there are none coco will add the incoming proofs to the table. If there are any it will calculate the amounts required to reach the fee ceiling batch them.
input_fee_ppk: 100 -> Receiving 1 proofs = 1 sat, but receiving 10 = 1 sat too. -> we should wait with the receive until we have at least 10 proofs