Interesting....
-
@socal increasing size need hardfork
-
@Gibsalot what about a variable block size? (255 to 65025) that would allow the system to handle spikes.
-
@socal like @LithStud stated any change to the way blocks work would be a hard fork, witch means the whole network has to switch to the new chain, or risk a split in the community and burst becoming two coins. @iKnow0 that would be a def contender in my book no idea what it would take to code somthing like that im sure its possible.
-
@Gibsalot I know it would take a hardfork and now that I think about it I know Adam and his goons would fight it just because it's an issue he is causing and the solution came from us
-
@socal i dont think he would fight aginsed a hard fork , hes a smart guy and he knows that for burst to get as big as he says it will a change will have to happen , i see him more fighting over witch solution is best vs no fix at all.
-
I hope that doesn't happen..
-
I'm pretty sure Adam has his reasons for doing whatever he's doing. From what I know he's a huge Burst supporter so I'm sure everything he does is to help the community or the coin in any kind of way.
-
@shbour Feel free to explain how the community being unable to use the coin is good for either the community or the coin.
-
@iKnow0 a variable blocksize is the way to go in my opinion but not to handle spikes, to handle real growth of transactions volume. This is the exact opposite. If someone wants to fill up the blocks with dust, he has to pay the price for it.
@Gibsalot The problem I see today is that the Wallet GUI doesn't check and recommend you to increase the fee during high load times for an instant transaction. This fix is only in the graphical interface and solves the problem.
Increasing the block size will just lead to more spam, because it will get cheaper. Miners will earn less and we additionally have the worst situation ever to face a hard fork. Hard forks should only be done when there is a technical problem in the protocol and everybody agrees on fixing it.
Better send some Burst in @LithStud 's direction, so he is motivated to implement the solution I mentioned above. -> BURST-S94A-Z3T5-TDZT-AK6NB
-
@iKnow0 block size isnt limited by amount of transactions but rather than size. we have a limit of 44kb per block now if that was varriable. we would be onto a winner
-
@Lexicon What was the logic in having a fixed limit of 44kb per block? Would there be any downside to increasing it?
-
@iKnow0 downside to increasing it is a block chain that can grow bigger in size faster. however as it only stores what it uses making it 250kb would only make it so it can use up to 250kb. during normal operation it will probably stay below 44kb.
-
@haitch Like I said "From what I know"... I didn't take in consideration the small size of the blocks and how big was the issue cased by Adam. With that taken in consideration, I agree that it's not a good thing to do and that now Burst has the same issue Bitcoin is having by having the blockchain overflowing by transactions.
-
@shbour Bitcoin is having it happen due to natural growth, Burst is having it happen because of the actions of one individual deliberately making the blockchain unusable at time.
-
@Lexicon A good written mass transaction sending program could also fill the blocks only with 80% max block capacity to increase acceptance in the meantime.
-
@daWallet indeed theres no real fix for this issue because its not really an issue. increasing the max size for a block would at least allow the transactions to clear faster letting everyone elses transactions go through faster. and that would be ideal for a mass tx app im a little unsure on how someone would determine the size of x amount of transactions.
it could be written easily for max transactions but the size is a difficult one cause it always varies depending on whether it has a message or the amount of burst.
another question is does the dividend section of the wallet have this functionality or does that do the same where it sends them all out in one go. atm asset's generally dont have more than 200 addresses to send to but when this gets to lets say 2000 it starts to become like adam's rain app
-
@Lexicon good thing you mentioned, i will need to add in delayed transactions (i think i have seen an easy way in API, but if i am wrong gonna be a bit tougher but oh well)
Talking about my own script :)
-
@LithStud when i took a look i couldnt find an easy way i the api to delay the transactions, it has other things like transaction deadline but this feature i dont think was one of them unless its an AT so im guessing it will probably need to be achieved with manual coding.
once this code is in theres another gotcha.
would someone need to leave their wallet open until its finished sending. as now rather than send and close the wallet users will have to wait for all of their transactions to get confirmed because if they close it only the transactions up until the current block will go through
-
@Lexicon What do you think about multi-block rounds? As you pointed out in another thread, this could deplete the total Burstcoin available to mine faster, but what if the extra blocks didn't mint any more coins and only rewarded TX fees? Granted, we'd still have the ever growing blockchain problem, but it would only grow as needed and we'd have the benefit of no arbitrary limits on TX throughput.
-
@sevencardz if we do that we might as well just increase the max cap on block size cause it does pretty much the same thing but without a load of extra work to have more than one chain running simultaneously



