UkoeHB
UkoeHB
> As for @UkoeHB's proposal. I have a question, what if the zero-decoy input actually pre-selects decoy outputs, including outputs within the Since all Monero transactions must have at least...
> It seems like reducing the available outputs for decoy selection would have some effect on the effectiveness of ring signatures -- can we quantify it? My intuition is reducing...
This is what issue #84 is doing for the floating offset, while the other bin members have fixed index. Basically to do what you are proposing for all ring members...
It can technically be done, but I don't know how practical it would be.
*Background* There is some intricacy to when additional transaction public keys are used (see code path transfer_selected_rct() → construct_tx_and_get_tx_key() → construct_tx_with_tx_key() → generate_output_ephemeral_keys() and classify_addresses()) surrounding change outputs where the...
Also, our fee algorithm sort of assumes transactions are added to the blockchain soon after being constructed. Multisig requires multiple rounds of communication, so many multisig tx are doomed to...
I don't believe the solution I offered is entirely adequate in the case of a surge environment. Block weights need to rapidly adjust when transaction volume suddenly changes, which means...
The problem Im describing doesn't have to be calamitous, I just say that to really emphasize what's going on. Minor falls in tx volume of 5% could have the same...
> However, these transactions have already been broadcast and are in the txpool of the miner. Thus, it is the miners prerogative to include them in a block if the...