Interesting....
-
@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
-
@Lexicon True, but increased block size only solves the problem temporarily. At some point in the future, we'll just need to increase it again. I'd like to see a solution that automatically scales up or down to consume all pending TXs each round.
Can you explain what you mean about the 'extra work to have more than one chain running'? To clarify, I am not suggesting that we have multiple blockchains running concurrently in order to have multi-block rounds. Instead, the person with the highest deadline would win the primary block as normal, along with the minted coins and first 255 TXs. The miner with the second highest deadline would get the next 255 TX fees (no minted coins), and so on down the line until there is less than a block of TXs left or some time limit is reached (30 minutes?), at which point the next round would start. The entire mini-chain of blocks for that round would then get added to the blockchain as if it were a single block.
-
@Lexicon indeed the wallet would need to be open (or in my case script running). Unless i find a way to get it on blockchain :p
-
@sevencardz a variable size would work. some kind of calculation that says 44kb is the minimum. then after that a calculation that counts the amount of uncofirmed transactions and works off that value to increasee the blockchain size would be perfect. this would be scale-able
@LithStud yeah thats probably harder than it sounds. adding a field into the api for the time and date you want the transaction send would be ideal. that way you can queue them all up and it should be all left in the wallet. but as with most things there could be hidden issues with it. and a fix like this might have to be a hard fork
-
I would be in favor of a hard fork if the following could happen.
- Allow for a truncated DB that only has accounts with balance (or roll ups) Similar to PASC.
- Allow for a larger block size, being dynamic it only consumes what is used.
- DO NOT allow for an unlimited block size, maybe double the current size
- Fractional transaction fees, I know were working in whole numbers right now but on a typical day a 1.1Fee would prioritize most people.
** Potential other ideas**
- Compressing data in the blocks? Are we padding empty space today or dynamically shrinking trans that have null fields like, the message box?
It is correct to say we are having the same problem that BTC is having and that our problem is synthetically created by Adams rain; however with the adoption of Burst growing it's a problem we were going to have to address anyways. It's better to address it now with a single user performing tons of transactions than in the future with tons of users each performing a single transaction.
-IceBurst
-
@Lexicon time on blockchain is of no use :) you schedule it by block number ;) moght have seen it somewhere else and thus thought its in burst. Still it is possible to do "manually" managing when transactions goes out (albeit not the most fun thing) anyways this just gonna go as another thing to add :) currently got other stuff to write :)
-
@LithStud indeed personally its not something i would work on as leaving a wallet open for some people isnt an option as theres to many factors to go wrong. such as accidentally cancelling your dividends mid send by closing your wallet. also if you lose internet connection whilst this is running id imagine that cuasing issues as well. lol to many things that could go wrong.
scheduling by block number is an idea but i could imagine similar issues arising from this method as well. e.g. my wallets froze or i lost signal. suddenly catches up but fires all transactions at once cause we are now 20 blocks ahead of what we were when we sent the tx
-
@Lexicon scheduling isnt ment to solve these problems :p its ment to delay transaction nothing more nothing less
-
@IceBurst said in Interesting....:
It is correct to say we are having the same problem that BTC is having and that our problem is synthetically created by Adams rain; however with the adoption of Burst growing it's a problem we were going to have to address anyways. It's better to address it now with a single user performing tons of transactions than in the future with tons of users each performing a single transaction.
Couldn't agree more if I wanted to.
-
blocks seem to take a long time today



