Create account

Sk8eM dUb
replied 573d
Metalbrushes_Tattoo
ABC minions are literally celebrating exchanges picking a side. It's a minority hash softfork - aka a hijack of BCH. But CSW is mean so that justifies it. 🙄
Metalbrushes_Tattoo
replied 572d
32mb is more than we can fill at the moment anyways. At 22mb blocks it has already been found that there are issues once that size block is mined. That issue should be priority to fix.
Sk8eM dUb
replied 572d
If I recall correctly, that was a relay issue that's been fixed. Also if this 22mb thing really is a physical limit then the supposed "garbage block attack" is not an issue regardless.
Metalbrushes_Tattoo
replied 572d
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 572d
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 571d
“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 571d
What do you think happens when a pool's orphan rate goes up significantly in a short period of time?
Metalbrushes_Tattoo
replied 571d
Exactly why the 22mb bottleneck issue needs to be fixed first.
Sk8eM dUb
replied 571d
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 572d
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 572d
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 572d
There are other uses than just PayPaling money.
Metalbrushes_Tattoo
replied 571d
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 571d
Of course this is the point. Uses other than tx take a lot more blockchain space.
replied 572d
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 571d
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 571d
Actually it would only be 4 months because the next upgrade would be March.
Metalbrushes_Tattoo
replied 571d
Oh really? For some reason I thought the next upgrade was in May 2019 🤔
That’s even better then ☺️
replied 571d
Metalbrushes_Tattoo
replied 571d
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 571d
Metalbrushes_Tattoo
replied 570d
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 570d
Valid questions in reddit comments that are never answered. Sounds like propaganda to me.
Metalbrushes_Tattoo
replied 570d
Lmao
And faked 32mb mined blocks don’t sound like propaganda? lolololol
Common
replied 571d
No such thing. Gigablocks will be sent miner to miner flawlessly, timely.
replied 571d
A little advice - you should propably do a little more research.
replied 571d
I did, but I lost 16 hours of mp3's from that conference, can you find them?
replied 571d
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 571d
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 571d
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 571d
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.
Metalbrushes_Tattoo
replied 572d
Possibly but on the other side of the story, the blocksize doesn’t need to be increased to 128 right now. The more difficult bottleneck problem really should be resolved first.
Sk8eM dUb
replied 572d
Please repeat more talking points. I haven't heard them enough times yet.
Metalbrushes_Tattoo
replied 572d
Ok no problem. I thought you were looking for an open minded conversation. My mistake. I’ll leave you to your own beliefs. Have a good night.
Sk8eM dUb
replied 572d
lol you're the one who's parroting a narrative unwilling to look at the forest for the trees. Tell me something I haven't read a thousand times and I'll be interested.
Metalbrushes_Tattoo
replied 572d
I stated a fact. I’m sorry that it was something you have heard before. I suppose that the bottleneck issue is something that is mentioned often cause it’s a priority issue.
Sk8eM dUb
replied 572d
Problem is that they're "fixing" bottlenecks that don't exist and ignoring ones that DO exist. Like the damn blocksize limit itself.
Metalbrushes_Tattoo
replied 571d
I would encourage you to do more research. All due respect. What your saying is simply false. I just posted a Q&A video with Bitcoin ABC that should clear up a lot of your confusion.
Sk8eM dUb
replied 571d
When someone says "we can't increase the blocksize because mining will become too centralized" I start heaving in convulsions and breaking out in hives.
Metalbrushes_Tattoo
replied 571d
No one said that. The 128mb blocksize increase was already said by ABC to be in the plan for the May upgrade in 2019.
First fix the 22mb bottleneck then upgrade to 128mb.
Sk8eM dUb
replied 571d
DSV and CTOR have nothing to do with that 22mb bottleneck. CTOR s all about preventing large pools from doing slow block and garbage block attacks because they might get to 51%.
Metalbrushes_Tattoo
replied 571d
The way your talking confirms that you didn’t watch the video I referred you to. Please DYOR because you seem to have been misguided somewhere along the line
Sk8eM dUb
replied 571d
I'm only going off what I've previously heard Aumary and J Toomin say. If the narrative has changed in your video tat would also be suspicious.
Metalbrushes_Tattoo
replied 571d
The video is 2 months old and the most recent CoinSpice debate is a couple weeks old. Neither are saying what you have been describing.
Sk8eM dUb
replied 570d
So this is no longer true because it's two weeks old?
Metalbrushes_Tattoo
replied 570d
🤦🏻‍♀️🤦🏻‍♂️🤦🏻‍♀️🤦🏻‍♂️🤦🏻‍♀️🤦🏻‍♂️🤦🏻‍♀️🤦🏻‍♂️ Omg 😒😒😒😒
jim
replied 570d
in crypto 2 weeks old is same as 2 years old in real life.
in a hashwar 2 weeks old is same as 2 centuries ago, perhaps longer.
Sk8eM dUb
replied 571d
I'm going to watch it but I'd like to point out that all the boogeymen that ABC warns about are not transaction bottlenecks, they're all just possible mining centralization issues.
Metalbrushes_Tattoo
replied 571d
During the entire video there was no talk of the so called “boogie men” and ABC never once mentioned anything about mining centralization issues.