Motion RIPEMD160 hash: ae95fa181a040ebc12bd93346cc3a416d01efbeb
=##=##=##=##=##=## Motion hash starts with this line ##=##=##=##=##=##=
Volume dependent transaction fees, being a clear and long term source of profit for the network, are a high development priority. Shareholders will look favorably upon any motion estimating the cost for such development.
=##=##=##=##=##=## Motion hash ends with this line ##=##=##=##=##=##=
It would be helpful to have more specific information included in the motion. How should the implementation of value dependent transaction fees be prioritised relative to other development tasks, such as B&C Exchange?
While it is possible to leave the specifications to be determined later, it would be better to do it now, so that shareholders can understand something about the cost in NuBits and developer distraction to prioritise this.
This will require a new voting mechanism, chunking of outputs (which might be more complex than the way we chunk NSR in blocks of 10,000) as well as new code regarding fees, which is more complex than you might think. Without clear specifications, I would expect this to cost between 10,000 and 20,000 NBT to code, test and deploy.
I would like to add that chunking is something that can only be implmented at the level of the client, not the protocol. This means that we can’t make assumptions about chunking being implemented in clients other than the core one. What about Coinomi? NuDroid? Surely the list will grow beyond our ability to effectively influence as adoption grows. The problem may not be serious enough to not implement this fee structure, but shareholders should at least be aware of it. To illustrate the issue, suppose Electrum supports NuBits and a user is using the Electrum wallet. He transfers 50,000 NBT into his wallet in a single transaction. Next, he spends 100 NBT. Unless Electrum implements chunking, transaction fees will be paid on 50,000 NBT, not 100 NBT.
Lacking a clear NuDev roadmap, the only thing I know of on the developers’ plates is B&C Exchange. As B&C priority is not really NSR holders’ business, it’s the business of BKS holders, I’m unclear as to how to specify priority in a motion such as this.
I think NSR holders would say that that is a fine amount to pay and most likely would want this to take priority over all other NuDev projects that are not particularly time-sensitive. Any patches to keep Nu 2.0 running smoothly (for instance, memory consumption possibly?) would need to take precedence over this, of course. If you can help me phrase that in an appropriate way, I would have no problem changing the motion hash.
By the way, I wrote a possible alternative motion that spells everything out in detail here:
@TomJoad asked that I do it this way, by asking for priority.
Or Avatar mode. Also, if Electrum wasn’t completely unaware of the situation they could simply send a 100 NBT output to their own address and then send it out. That would cost a few cents and take a little time, but wouldn’t charge on the 50,000 NBT output. It’s essentially chunking just before sending, a last minute procedure costing a small bit of time and money for those who refuse to do anything else.
Nothing beyond 2.1 for Nu has been clearly defined. I doubt there will be another Nu release after that until B&C Exchange is working. 2.1 will be code complete soon enough that the new fee structure couldn’t be prioritised ahead of that.
Your point that B&C is another business is valid and relevant. I’m somewhat confused about what would be fair in the case that shareholders wanted it prioritised above an initial implementation of B&C Exchange. It would probably be reasonable to just say the team is already committed to B&C. But if shareholders wanted it prioritised just after B&C, then both sets of shareholders would be in agreement. I suspect Nu shareholders would prefer to have B&C prioritised, even from the selfish perspective of the Nu network.
I don’t think the motion content needs to be changed to include an estimate where it now appears early in the thread.
I had forgotten that you had defined the specification so completely in the thread referenced. Thank you.
Perhaps others could comment on how they think it should be prioritised relative to the first working B&C version and the other enhancements that have been discussed for B&C (such as CHECKLOCKTIMEVERIFY and an Android client). I would place it right after the first working B&C version. If that appears to be the consensus, then no change is needed. If there isn’t a clear consensus, then it will need to be decided by motion.
Assuming Nu shareholders vote this in, how would you feel about a BKS motion to decide prioritization regarding B&C?
We could make two motions. One has priority list:
The other has priority list:
I feel that NSR holders are well represented amongst BKS holders and that is a where a large portion of the funding will come from, so we should let them (the other us) decide.
Edit: Volume-Dependence wouldn’t be forkable the way I might want it to will it? Like, it won’t make B&C exchange fees volume dependent? Cause if that’s true, I can’t see BKS holders ever voting for the second motion over the first unless they own more NSR than BKS.
@CoinGame Can this be pinned for at least a little while? It has participation (and potential support) from both the founder and the proposing shareholder as well as 5 likes from independent community members. The motion itself has just barely been seen by the blockchain.
I need to think about it, but I’m tempted to vote for it as a starting point to show enthusiasm for the idea. More detailed motions will need to come later to determine relative priorities and costs.
I think it is important to set volume-dependent tx fees. Therefore I am in favor of such a motion.
Voted. It’s a great general declaration of our network’s enthusiasm for the idea. While further motions will be needed for specifics, I think this one is broad enough that it doesn’t place any direct demands on developers yet.
Adding this to my datafeed. Although agree that we need a better specification, this motion is only about prioritisation as I understand.
ae95fa181a040ebc12bd93346cc3a416d01efbeb voted.
ae95fa181a040ebc12bd93346cc3a416d01efbeb voted
This motion passed
This motion has passed. The motion is intentionally vague to allow some flexibility in how it is implemented. The primary responsibility for compliance falls on me, so I would like to explain a little about how I plan to comply to permit comment and discussion about the plan.
After what is planned for Nu 2.1 and the possible NSR denomination change, my priorities for Nu prior to the passage of this motion centered around developing data feed features. I hope to add more granularity to data feed selection by permitting distinct selections for different types of voting. I would also like to make alerts, upgrade notifications and other notifications (such as messages bringing attention to pending motions and custodial grants) available via data feeds. I haven’t discussed the details of this recently because I had intended to do it after B&C Exchange is operational, so it is too early to focus on it.
So, I believe a fair way to interpret this motion is to prioritise quantity based transaction fees before the data feed functionality I just described. I plan to prioritise it after Nu 2.1, the possible NSR denomination change and after the initial implementation of B&C Exchange. I believe B&C Exchange is more valuable to Nu shareholders than quantity based fees. The Nu and B&C dev teams are one and the same, and we are short staffed right now. We can’t develop Nu without delaying B&C Exchange.
I’m looking for comment on this interpretation of this intentionally vague motion.
Edit: Let’s target quantity based fees for inclusion in a Nu 3.0 release.