The difference is the cost it imposes for an individual to monopolize the chain (and degrade everyone else’s experience.) While it’s certainly necessary for node and wallet software to be able to function properly under a maximum-load scenario, IMO currently there’s an externalized cost - a cost to both miners and users of the chain - that’s not being paid for in fees.
2 Likes
If this is verifiably one node executing many txs and not a group of nodes executing a few txs individually, like 1 per block, then I suppose but can you confirm that? And if so, and we implement these measures, what prevents the one person or such from splitting up their operation like mentioned? (Or am I off base here?)
If it were possible to determine the origination of a transaction or group of transactions, that would be a security flaw itself.
Storage is cheap, a poor ux is not. For instance, a 4tb hdd costs ~ 1 zec right now. Cloud storage is ~0.002 usd per gb/month. Zcash has chosen a fixed block time & size. Budget for 2 gb a day.
An average user running average equipment should be able to use zcash at its peak transaction throughput. The lightwalletd wallet pattern is intended to accommodate this. I run one node and connect to it with light wallets. If my node or lightwallet cannot keep up with the chain under peak conditions, it is an engineering problem to solve not a financial game to try and discurage use.
4 Likes
There’s some additional information in this github issue: Rescanning wallets on mainnet is slower after height 1,700,000 · Issue #6052 · zcash/zcash · GitHub
You can see from the graphs here that someone initially was sending small numbers of large Orchard transactions, then switched to sending small numbers of large Sapling transactions (containing > 1800 outputs per tx, each of which must be trial-decrypted by every wallet). Since transactions all currently
pay the same fee irrespective of size, it’s possible to fill a block with just two transactions and pay only 0.00002000 ZEC in fees. I don’t object to anyone using the chain for any purpose, but I don’t think that a 2000-output tx should cost the same as a 2-output tx, given that the former imposes 1000x the cost on all participants in the network.
It’s very important that fees not leak information. A fee-per-input-or-output mechanism leaks no information, but does require that users of the chain pay costs proportional to their usage.
6 Likes
What would be the impact on the protocol if transactions were limited to fewer outputs?
I wonder about what the use case for a transaction with 2000 outputs is, other than spam.
1 Like
I think there are actually some really good use cases for transactions with large numbers of outputs - I’ve elsewhere described a proposal that allows wallets to import viewing keys for opt-in advertising/patronage systems. But such use cases aside, I think that fixed-cap mechanisms don’t scale properly, whereas market-oriented mechanisms can do so.
Another possible use of large numbers of outputs is revenue sharing (full disclosure; this is a side-project of mine.) And also, using large numbers of outputs can be interesting if we at some point decouple memos from outputs as described in Consider decoupling memos from transaction outputs. · Issue #627 · zcash/zips · GitHub.
1 Like
That’s true. AFAIK, any deterministic function of publicly revealed data (e.g. size, num outputs) should work. One can even include blockchain data outside the transaction, e.g., how full were the past N blocks. (Note that this does not alter privacy re: eclipse attacks because shielded transactions already choose the Merkle tree anchor depending on public on-chain data.)
How about a concrete soft-fork proposal:
min_fee = 0.00001 + 0.00001 * max(0, #nullifiers + #shielded outputs - 3)
That is, the fee is fixed 0.00001 ZEC per transaction plus additional 0.00001 per each shielded input/output with first three being free. Thus, this proposal changes nothing for the common 1-in 1-out, 2-in 1-out, and 1-in 2-out transactions. If we want to make large # outputs cheaper we can adjust the second constant.
15 Likes
This looks like a good idea to me (again, not speaking for ECC). And this doesn’t even constitute a fork; it is just changing the fee policy for what miners choose to include in their blocks - the fee amounts are not checked by consensus. Now, this does have an effect on the network relay policy, but that’s also not a consensus change; however, the min relay fee should also be considered.
7 Likes
That’s true, there is no need to do a consensus-critical change.
1 Like
Paying for the input/output makes sense to me. It would encourage merging notes as well. The only use I can think of for so many outputs is attempting a dust attack or something normal users would not do accidentally.
1 Like
One thing to note: using 3 items (inputs or outputs) as the floor would mean that an Orchard transaction always pays double, since each action consists of both an input and an output, and we always pad to two actions. So that constant should be 4.
2 Likes
I dont know if inputs and outputs should cost the same if mergeing notes has isnt free. I can’t control the number of notes some one pays me with, and someone could pay me 1000 zec in .001 notes. its their option to decide to do this and pay for the transaction. The receiver would be unable to realize the full value of the transaction because it would be devoured by fees when sending.
3 Likes
Thank you to everyone who commented. Please review and provide feedback on the proposed ZIP here:
4 Likes
This would have to be a somewhat motivated malicious person to pay you 1000 zec in 0.001 notes, both in terms of the computational cost that they would incur to construct the thousands of transactions required to do this, and because they would be paying equivalent fees to construct those transactions as you would to spend the resulting notes.
4 Likes
Inputs and outputs are differently expensive. Outputs occur costs for scanning and for appending to the note commitment tree (including updating witnesses for held notes). Inputs incur costs for spend auth signature verification and nullifier checks. Of course in Orchard and Sprout, the number of inputs and outputs are always the same.
3 Likes