This thread is here to house a discussion about KIP9 and our approach to mitigating UTXO bloat using quadratic costs via local constraints. This is to house discussions both about KIP9 and the research paper (which would be linked here as soon as the preprint is published).
4 Likes
Hello,
Thank you for the great work in (and writeup of) KIP9. The formulas look so “simple” but I am sure a whole lot of thinking and considerations went into this work.
However my question is more legalese/practical. It concerns this section of KIP9: " The downside to this solution is that the merchant must constantly have a hot wallet available and cooperate with the customer to create a mutually signed transaction. In a following KIP, we will specify auto-compounding wallet addresses, where UTXOs owned by such addresses will allow anyone to add to their balance without the owner of the UTXO having to sign it. Among other applications, this mechanism will allow the millionaire to purchase ice cream as described above, using her wallet alone."
Would the merchant be able to set limits on people (addresses) that can append to their hot wallet? For example, let us say there is an address widely known to be associated with an hacker or some rogue organization. I would imagine that it needs to be possible for a merchant to prevent that hacker/organization from spending their ill-gotten gains at my crypto-based business. Or another case, someone steals 1 million tokens/coins and in a fit of sudden generosity, she/he distributes the tainted cash to as many hot wallets (owned by innocent merchants) as possible. Now those merchants are roped into potential AML, criminal …investigations.
I have lost my train of thought on this. I suppose this line of thinking is asking crypto to do more (enforce) than is possible with cash. If I have a tomato stand and a customer comes in, it is not always possible for me to know that they got their cash from an armed robbery, embezzlement or whatever. There are also anti-discrimination laws that could prevent me from denying them service. However,
Like any other cryptocurrency, also in Kaspa, one can send funds to any address without getting any kind of “permission” from the receiver. This has nothing to do with this suggestion.
The new thing here is that the payer can spend a UTXO owned by the payee, as long as the transaction creates a corresponding output UTXO with a larger amount going to the same payee address. The concern with such an approach would be the ability of spammers to interfere with ongoing payments by spending the same UTXOs. The KIP will circumvent this by allowing the address owner to specify a minimum increment value.
Other intermediate designs are possible: for instance such addresses can require a semi-sig which requires knowing some secret (which is not the full private key only known to the owner). This way the seller can only share the secret with trusted customers.
1 Like
Thank you, Michael, for this clarification. Really appreciate it.
1 Like
Hi,
Seems like the main point is to reject transactions with a very small but multiple/a lot of outputs
And the KIP proposes a formula to figure out what tx are of this type
Now the question,
The proposed formula naturally rejects tx with very small outputs
But since those tx might be legal it also proposes a way to send them anyway, by letting a wallet to find a right path for this
Doesn’t the fact that this path exists contradicts the very purpose of blocking those transactions for the first place?
i.e. the attacker can prepare the needed inputs using his own wallet and then sends the dust
That’s exactly the point, the path exists, but it’s costly. While the cost is tolerable for a single point to point payment, it will become intolerable for an attacker wishing to create thousands or millions of such entries. Additionally, for a real genuine user wishing to make a micropayment we also analyze and suggest the costless mutual transaction method
1 Like
I would say that the entire principle behind the solution is that transactions are not rejected (In practice they are, for several reasons, e.g. P2P policies or block mass limits, but the validity of the solution does not rely on this limit). Rejecting transactions means setting thresholds, and thresholds are generally bad, because they are arbitrary and usually based on ephemeral metrics such as the current Kaspa price, the current average fee, etc…
The idea here is to allow any transaction, but choosing a smart policy for pricing these transactions. The path exists, and if you want to use it even though it is less than optimal, that’s your prerogative. The pricing is set in such a way that you couldn’t do meaningful damage without spending huge resources. So it isn’t about legal/illegal, it is about having to pay for your decisions.
2 Likes
Thank you guys for the response
I was thinking - the KIP is trying to adjust the price of the tx alone
This make sense since it makes the calculation stateless and thus cheaper.
However,
Why not make it stateful by i.e. counting the number of total “mass” in last period of time and adjust the price/rules based on that.
This imitates the real world more precise - if there is a congestion in the network you get higher fees.
It is also free from the downside of complicating micropayments in “normal” circumstances.
Using dependence has extremely high costs in terms of the ability of the network to scale, and I am not sure I see any benefit. Obtaining such strong guarantees using only local calculation is a magical property one should have an exceptionally good reason to concede.
Hi. Maybe i am a little late on this topic, but let me ask something: If I am a very famous merchant of automated microservices that accepts kaspa. My address will have some UTXO with spend script that anyone of my millions clients to use to spend sending me the same ammount plus the service fee. What about the concurrency in this case? Won’t even I be blocked to spend this UTXO competing with my own clients to use it?
- The final design implemented here is actually more broad and allows designs such as using secondary secrets, limited one time borrows, and so on, see examples.
- A merchant with such millions of clients still has a natural concurrency limit. For instance 1k clients online making concurrent payments within timeframes of 1-5 seconds. Such a merchant should manage ~1k additive addresses (each with 1 or more UTXOs) which are distributed and managed tightly between the current clients. If tight management is undesired, he can manage a pool of 100k (>> 1k) addresses and rely on randomness to reduce collisions to be negligible. My main point is – with threshold additive addresses we’re in the realm of engineering creativity.
1 Like