-
Notifications
You must be signed in to change notification settings - Fork 58
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
protocol allows unlimited splitting on stake #82
Comments
Considering that the coinbase transaction adds to blocksize, and thus has a marginal cost on the network, might it make sense to allow arbitrary splits but enforce the same byte-based enforced fee as other transactions? EDIT: Of course, allowing zero sized outputs makes no sense whatsoever and needs some type of sanity check. |
The problem with enforcing a fee for large coinbase transactions is that the fee is paid to the person creating the coinbase - ie. themself. In other words there's no way of charging a fee for coinbase creation. Although I guess you could charge a fee for spending coinbases. |
Well, the thought was that in the near future fees might be incremented onto a fee pool, and then a portion of those fees awarded. That would eliminate the problem with any change in fee structure which would allow for stakers to avoid the fees via staking their own transactions. |
It would also provide stability to the subsidy. Unfortunately (fortunately?), a portion still needs to go directly to the block staker - to prevent the loss of incentive to include transactions in the first place. Otherwise, stakers would stake empty blocks for the propagation advantage, much the same as BTC is experiencing. |
See this transaction: http://khashier.com/tx/71f60ecbb97a69ead2722efb973aa3f8aaa4d22618ecccd2824de762f29c358a
I staked a 5 CLAM output into 6 separate 1 CLAM outputs and 4 0 CLAM outputs. There's no transaction fee for doing so. This could be abused to make arbitrarily large transactions up to the block size limit.
We'll need a hard fork to fix this.
I propose disallowing any output less than 1 CLAM in the staking transaction. So I can split a 5 CLAM input into 6 separate 1 CLAM outputs, but no more than that. Since the block reward is 1 CLAM, the total output will always be greater than 1 CLAM, since the input is always greater than 0.
This will prevent people from staking a 0.1 input into two 0.55 outputs, but I think that's fine.
Aside: maybe we should have a 'hardfork' label to collect all the hardforking issues together, so we can easily find them all when it comes to fork time.
The text was updated successfully, but these errors were encountered: