Create account

Metalbrushes_Tattoo
replied 567d
You sound like your talking about CW not ABC to be honest 😬
Sk8eM dUb
replied 567d
Entitled means you don't have the work to back up your expected position. ABC devs have hardly any BCH or mining equipment. Neither does Peter Rizun or Emin Gun Sirer.
Metalbrushes_Tattoo
replied 566d
That entire statement is all assumption unless you have a factual source you would like to provide for it.
Sk8eM dUb
replied 567d
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 566d
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 566d
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 566d
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 566d
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 566d
“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 565d
What do you think happens when a pool's orphan rate goes up significantly in a short period of time?
Metalbrushes_Tattoo
replied 565d
Exactly why the 22mb bottleneck issue needs to be fixed first.
Sk8eM dUb
replied 565d
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 566d
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 566d
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 566d
There are other uses than just PayPaling money.
Metalbrushes_Tattoo
replied 566d
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 566d
Of course this is the point. Uses other than tx take a lot more blockchain space.
replied 566d
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 566d
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 565d
Actually it would only be 4 months because the next upgrade would be March.
Metalbrushes_Tattoo
replied 565d
Oh really? For some reason I thought the next upgrade was in May 2019 🤔
That’s even better then ☺️
replied 566d
Metalbrushes_Tattoo
replied 565d
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 565d
Metalbrushes_Tattoo
replied 565d
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 565d
Valid questions in reddit comments that are never answered. Sounds like propaganda to me.
Metalbrushes_Tattoo
replied 565d
Lmao
And faked 32mb mined blocks don’t sound like propaganda? lolololol
Common
replied 565d
No such thing. Gigablocks will be sent miner to miner flawlessly, timely.
replied 565d
A little advice - you should propably do a little more research.
replied 565d
I did, but I lost 16 hours of mp3's from that conference, can you find them?
replied 565d
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 565d
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 565d
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 565d
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 566d
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 566d
Please repeat more talking points. I haven't heard them enough times yet.
Metalbrushes_Tattoo
replied 566d
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 566d
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 566d
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 566d
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 566d
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 565d
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 565d
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 565d
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 565d
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 565d
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 565d
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 564d
So this is no longer true because it's two weeks old?
Metalbrushes_Tattoo
replied 564d
🤦🏻‍♀️🤦🏻‍♂️🤦🏻‍♀️🤦🏻‍♂️🤦🏻‍♀️🤦🏻‍♂️🤦🏻‍♀️🤦🏻‍♂️ Omg 😒😒😒😒
jim
replied 564d
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 565d
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 565d
During the entire video there was no talk of the so called “boogie men” and ABC never once mentioned anything about mining centralization issues.