there isn’t a need but it is a smart advertisement 
We can decrease it again at any time.
What should impress us is, that here in this forum you wouldn’t have needed to write the next parapgraph to make people grasp your intention
1 Like
I was 99% sure, just wanted to be absolutely sure 
2 Likes
You could have banned the 1% people complaining about that until they had proved to have parked 10 NBT for 4 weeks at 0% 
People, besides making bitcoin community look like a bunch of amateurs, the OP wasn’t about raising block size now. It is a strategy to raise it, which is perfectly fine to discuss now.
Great. A complete blocksize strategy includes both raising and decreasing aspects.
Variable block size in Nu 3.0! Vote it in now! Way better than just snubbing bitcoin!
3 Likes
And variable fee based on block fill level!
2 Likes
I like the idea of variable block size. Further, we can tell people that Nu has solved this issue every time the block size debate is mentioned.
One convenient aspect of a bounded block size is it helps establish a model around the a node’s compute, storage, and network needs. It gives a developer something to design for and a node operator something to procure for.
As an example: with a 2 mbyte block, a node with 100 connections could need about 27 mbits/sec sustained bandwidth. This is out of the realm of most consumer broadband connections – especially on the upstream side. Unbounded demands could easily drive centralization. In a worst case, an unbounded block size could open a potential point of attack.
If my math is right, at 2 mbytes/block a node needs to process 140 transactions per second – or 12 million per day. Storage would grow by 1 Terabyte per year (though the B&C launch has proven a way to ‘garbage-collect’ the blockchain).
What would these design and operations parameters be in a variable block size?
But surely you aren’t suggesting that hardware is made specifically with running the Nu network in mind? If we vote on block size, you can be assured that these concerns are precisely what we will be thinking about. These concerns are indeed the only thing shareholders should think about when voting on block size.
A fee like I’ve laid out would basically ensure that the blocks are never full except in an ongoing spam attempt. Thereby, increased demand for txn volume would directly increase the fees, rather than pushing on us to increase the blocksize. This allows shareholders to concern themselves solely with hardware capabilities when voting on the block size.
By voting on a block size, I think you’ll find that the block size (and therefore the hardware demands) will decrease in the short term because we all know the blocks aren’t filling right now.
Perhaps hardware not created specifically for Nu, but Nu shareholders identify the hardware to put to use for the purpose of running the net.
In other words, should the Nu network run on Raspberry Pi level hardware, commodity desktop hardware, enterprise-class servers? What amount of connectivity should we require of a Nu shareholder?
Presently some Nu shareholders are minting off a Raspberry Pi. At scale even with a 1 megabyte block (with 10x the ‘transaction’ capacity of Bitcoin per day due to the 1-minute interval vs 10 minutes), I do not think the Raspberry Pi’s would keep up, and these Nu shareholders would be excluded from participating in the network. This would eliminate their ability to mint and therefore vote.
Also from the standpoint of architecture – such as database layer tuning / implementation – these are things that the devs would have to engineer to.
Nu client memory usage and database performance showed itself to be a problem already, and has required developer work. The impact has been significant. It has delayed development effort on B&C and other features that the shareholders have already approved.
This is assuredly not a question for the devs, but a question for the shareholders. Why would we ask the devs to answer this question for us? Clearly the shareholders are the only ones who can make a statement regarding this.
A 1 megabyte block does not mean that every block is 1 megabyte. On the contrary, I’ve been speaking of a filling target of 25%.
We currently have 1 megabyte blocks. Are these shareholders excluded now? In that case, why would voting on an increase to 2 megabytes not steamroll them just as much as voting on literally any number? If your statement is that we cannot vote on a block size, then there is no mechanism by which we can change the block size other than dev dictatorship. On the other hand, if we allow shareholders to continuously vote on block size they will intelligently look at the number of nodes and pick block sizes that will keep the system healthy.
What I’m saying is that things like segwit and better hardware and other methods of dealing with higher Txn volumes will happen independent of our network. We can respond to them intelligently, such that as hardware capacity grows in its staggered unpredictable fashion we can lift the blocksize at will without an additional hardfork.
In my opinion, continuously voting on block size is in fact the only fair thing we can do with regards to shareholder hardware capabilities.
It would be great to get developer input based on professional experience and any testing that has been done. i.e.: hardware of capacity X can perform to a level Y. I suspect that a RasPi would be CPU-limited first, then disk, then network. A desktop-class machine with spinning disk could be disk-limited first, then network, then CPU. With an SSD, it may be network-limited (assuming a residential connection).
There are other factors, too, such as simply downloading and validating the blockchain. i.e.: if the lowest common denominator is a RasPi and it can only do 10 tps, perhaps we can only run the network at 5, so that a node actually has the ability to “catch up” and be able to mint in the first place.
I feel that the risk for them to be excluded exists, yes. Shareholders running on RasPi should be aware. I will be prepared to bring sufficient hardware and connectivity to keep minting up to the design capacity of the protocol. I do foresee the need to invest in an array of SSD’s to keep up with the I/O needs, as well as needing to get business-grade connectivity.
Can you educate me on this 25% fill idea further?
I concur that this is another responsibility that the shareholders have, and perhaps this is bringing larger awareness to that.
I think the difference is in how it is implemented. It sounds as if you are advocating a new type of voting that is part of the protocol, whereas I was advocating more of a ‘step’ function that would be implemented thru code. Once any change is implemented once by a senior developer, I would think it be straightforward for a junior developer to see the code diff and compile a new client.
You make a good point, that hardforks are easy for Nu. However, what about client adoption? Are we to be known as the project where you have to update your client every time a new piece of hardware comes out?
The idea is that the shareholders pick the blocksize, most likely forming consensus around developer opinion, then make the fee sensitive to the block filling. If the blocks fill, increase the fee. If they’re empty, decrease the fee down to the minimum. Aim for 25%, good for DOS protection.
How long until the voting starts?
Id like a response from devs if possible. It’s a two step process, one for variable block size, the other for automatic fees. Id like to hear the developers comment on the technical possibility for variable block size at least.
Or i guess you meant the 2 mb vote. I personally wont vote for that because i dont think we need it and i think it makes our spam protection worse. I realize it’s political, but i just think we should keep our bite bigger than our bark.
I consider the variable fee based on fill level more important.
The voting for 2 MB maximum block size can easily be understood outside Nu.
Implementing it isn’t even important to show that Nu is able to form consensus by motion - in difference to so many other crypto currency projects.
It’s a corporation and the owners are allowed to decide!
So are you asking me to vote for something i dont actually want to see implemented?
(Not like you or me directly or whatever, the royal you and me)
Short version: yes.
Extended version: I don’t see need to have it implemented soon.
I see need for both the variable fee and the block size increase.
I consider the variable fee more important than the block size increase.
I want to provide the world outside with an example of Nu’s superior consensus mechanism.
Or another tack: we vote to affirm the current the 60 megabytes per hour of block capacity as “sufficient in the near term given the growth patterns seen on the Nu network in particular and trends seen in the cryptocoin space in general” and that it will be "regularly reviewed by Nu shareholders, including interim discussions on variable block scaling and fees for spam transaction protection. "
An additional note that this is is 10x Bitcoin’s capacity of 6 megabytes per hour would be good, even though both are based on 1 megabyte blocks, and that average transaction volume of NuBits is growing at approximately 100% year-on-year.
3 Likes