What does that mean?
Just that adding outputs bloats the blockchain with garbage for minimal cost.
I woulld not take it too lightly, and use a fee infra that prevents this like I have proposed above, for example.
But that only works with fixed fee rates, if I understand correctly. It doesnât apply to a dynamic fee market, where blocks are full and users have to compete with each other for block space.
With fees2 field, you can add the fee that you want when blocks are full, and it is dependent on nothing, just committed to in the message of the kernel (like fees1). I think it works, unless I miss something.
fees1 blocks the number of outputs/inputs you can have in the tx. As you mentioned there is indeed some sort of privacy leak, but any fee that depends on the number of inputs/outputs would have a similar privacy leak.
On the other hand, not controlling the number of inputs / outputs like fees1 does, would allow for unlimited spamming (appending) of inputs or outputs when the tx travels in the network
I would agree with this. So I guess if you realize your tx was unfairly aggregated, then you just fluff the original?
I think good luck with that, the âunfairlyâ aggregated tx is already fluffed before you may know it, sending garbage permanently on the blockchain.
Fluffed doesnât mean confirmed. If an attacker fluffs a transaction with 2 inputs, 3 outputs, and fee X, and I refluff the original with 2 inputs, 2 outputs, and the same X fee, miners will prefer the original.
Well it all depends if other txs were aggregated to your original tx in the meantime as well, adding some nice extra fees for the miner.
True, you would have to rely on the other party to refluff their tx as well. Itâs not a perfect solution.
Not necessarily. Adding 0-valued output O=r*G to a transaction tx will visibly change the tx offset by r. Anyone noticing this can broadcast a new tx with single input O, no outputs or kernel, and offset -r.
Assuming we allow such transactions to be fee-less, they will be cut-through with the altered tx to strip them of O and recover the original tx.
Note that this new tx is much smaller than the original, making this preferable to re-fluffing the original.
Ideally, this is combined with banning the malicious peer.
Sounds like mega-beautiful-rainbow-and-multi-color-poney-world solution to me 
There are many ways to make it un-noticed. This is ultra complicated and impractical to do that. keeping track of offsets, outputs, of unaggregated/aggregated txs. good luck, wishing the best ^
Especially that simple and practical solution exists 
(cf above)
Complication/infeasibility against simplicity
Iâll happily accept some complexity outside the consensus model if it keeps the consensus model simpler.
I donât think itâs possible to know which peer did this if it happens in the stem phase.
I disagree with that approach, especially when there is not really an added complexity, and that the non-consensus solution is not really feasible.
What would be the complexity added at consensus level here? is it the presence of a second fee field that is utilized when blocks are full? (we can keep it optional and no need to use it when blocks are not full).
The consensus solution looks quite clean, moreover, and easy to reason about.
Yeah, thatâs unfortunate.
Need some more time to ponder thisâŚ
1 Like
It seems the only clean solution is, like Kurt suggested, to have kernels sign for additional fee requirements.
This could be the minimum fee-per-weight of the tx (total fees divided by total weight).
Then weâd have clear criteria when two tx can be aggregated fee-wise, namely when the aggregate fee-per-weight satisfies all minima signed for in its kernels.
1 Like
If you do a linear formula for fees calculation, then no criteria will be needed to aggregate txs, which is both more simple and better for aggregation
If you keep something non-linear then it will be possible for people to spam with one or more outputs in the occasions where max(1,weight1) + max(1,weight2) is greater than max(1, weight1 + weight2). It was discussed on keybase and @vegycslol provided an example.
I dont see an issue with having a linear formula since wallets can always choose the right combination of outputs and inputs to have a satisfying fee. It is also better for privacy to not use all your utxos as tx inputs for a single tx.
At least I dont see an advantage to have something non-linear like we have currently.
Actually, I take this back. In the case where blocks are full and you refluff your original tx, miners will include it by itself if the stem-aggregated tx has too low of a fee.
When blocks arenât full, paying more than the minimum fee is a deliberate choice to pay for someone elseâs spam. When blocks are full, paying higher fee wonât hurt your chances of getting included in a block, as long as youâre willing to refluff in the case of spam being added to your tx.
Itâs worth noting though, what weâre calling âspamâ, others call decoy outputs. So choosing to combat spam is choosing to not allow decoys.
1 Like
I think we should keep in mind that kernels donât commit to inputs and outputs which means that a fluffed tx from the last node holding a stem tx could look different than what the previous nodes on the stem path saw - which could make it hard for the miner to know what needs to be replaced. There exists at least one possible strategy of achieving better privacy through the use of this property where transactions are changing their shape e.g. at each stem node, all the outputs get replaced with new ones. Iâve described one such example on the objective dandelion thread and I hope we donât write it off at least until we research if this might help improve the situation.