Create account

Metalbrushes_Tattoo
replied 573d
Sk8eM dUb
I believe your recalling incorrectly. Amaury Sachet specifically referred to this issue needing to be resolved as priority in his recent interview with CoinSpice a week or two ago.
Sk8eM dUb
replied 573d
After three or four attempts at propogating a block, most miners will ignore that pools blocks and keep mining the previous one until they verify the garbage block. Orphan rate moons.
Metalbrushes_Tattoo
replied 572d
“Orphan rate moons”
You don’t see this as being a priority issue that should be resolved before increasing the blocksize well beyond what is needed right now?
Sk8eM dUb
replied 572d
What do you think happens when a pool's orphan rate goes up significantly in a short period of time?
Metalbrushes_Tattoo
replied 572d
Exactly why the 22mb bottleneck issue needs to be fixed first.
Sk8eM dUb
replied 572d
To my knowledge that was a mempool relay issue that has nothing to do with pools/solo miners losing blocks due to size.
Sk8eM dUb
replied 573d
A 22 meg garbage block is not a threat. Especially if it's intentionally invalid. Pools won't burn repeated blocks. Pools WILL start ignoring blocks from miners who try it.
Metalbrushes_Tattoo
replied 573d
If there are problems that crap out the mining process at 22mb then what is the urgency of 128mb? Especially since 32mb provides PayPal level transactions anyways.
replied 573d
There are other uses than just PayPaling money.
Metalbrushes_Tattoo
replied 572d
That’s not the point. PayPal was only the transaction level comparison that I used in describing how much transactions BCH can currently handle at 32MB
replied 572d
Of course this is the point. Uses other than tx take a lot more blockchain space.
replied 573d
Because there are businesses out there that could use 1GB blocks at a hefty fee, and won't even start developing their apps.
Metalbrushes_Tattoo
replied 572d
If the system craps out at 22mb because of bottleneck issues then increasing to 128 doesn’t resolve that. Fix the bottleneck then increase to 128 in 6 months is logical & safe.
replied 572d
Actually it would only be 4 months because the next upgrade would be March.
Metalbrushes_Tattoo
replied 572d
Oh really? For some reason I thought the next upgrade was in May 2019 🤔
That’s even better then ☺️
replied 572d
Metalbrushes_Tattoo
replied 572d
How do you think those businesses will react when the blocks start crapping out anytime they reach 22mb? Bad experience=bad business. Issues need to be resolved while there is less tx.
replied 572d
Metalbrushes_Tattoo
replied 571d
32mb blocks faked by SV. The transactions weren’t broadcasted to network
https://www.reddit.com/r/btc/comments/9vxsep/psa_bitcoin_sv_engaging_in_social_media/?st=JOBYS6Z9&sh=b41f90eb
replied 571d
Valid questions in reddit comments that are never answered. Sounds like propaganda to me.
Metalbrushes_Tattoo
replied 571d
Lmao
And faked 32mb mined blocks don’t sound like propaganda? lolololol
Common
replied 572d
No such thing. Gigablocks will be sent miner to miner flawlessly, timely.
replied 572d
A little advice - you should propably do a little more research.
replied 572d
I did, but I lost 16 hours of mp3's from that conference, can you find them?
replied 572d
Take a look at this. This is ABC and BU dev meeting/discussion. No technobabble. Real stuff. https://www.reddit.com/r/btc/comments/9voqg1/not_sure_who_to_support_in_the_upcoming_fork/
replied 572d
Is it relevant to my point:

Businesses voiced their need to see higher block sizes before starting years long software development on the BCH chain.
replied 572d
Yes, and they will get that with ABC along with the neccesseary optimizations to achieve gigabyte blocks. SV offers no concrete info on how they will fix the bottlenecks.
replied 572d
Ok so you have that info right in your link. Businesses need a clear pathway to higher blocksizes. 128Mb is kind of small but it may do for now. At least showing some progress.