BU ... It's totally irrelevant to this next round of clashes.
As the data shows, it has the largest signaling support. Ergo, it is quite central to the ongoing debates. Fine, believe what you want and I'll chalk it up to faith and put you back on ignore. |
|
|
|
Same old mistake everyone keeps making. Variance. Exactly the same pools are signalling/flagging/fapping, whatever you want to call it, that have been for months now.
Variance? The one week figure has significant variance? Really? Why not take another look right now and see for yourself?  One-week variance dropped from 42.1% to 41.3. Insignificant change confirmed. Correct and it's been sitting at 38-41% for ages. You showed the pic showing 48% daily rate making it look like it was climbing. The daily rate has even peaked over 50% in the past. |
|
|
|
|
People use the term bitcoin mining indiscriminately for mining any bullshit coin. There is no way in hell anyone can meaningfully mine bitcoin currently with a GPU let alone CPU. Additionally since there are very few how to get started guides in the modern era, people are reading stuff from 5 years ago thinking it's still relevant today. Make no mistake, one can only realistically mine bitcoin with ASICs and even then only the most efficient models are worth mining with.
|
|
|
|
Same old mistake everyone keeps making. Variance. Exactly the same pools are signalling/flagging/fapping, whatever you want to call it, that have been for months now.
Variance? The one week figure has significant variance? Really? Why not take another look right now and see for yourself? |
|
|
|
|
You heard wrong, it does not have good BITCOIN mining capabilities. Let me help you by moving you to the right area.
|
|
|
|
Is it wrong that there's a part of me that wants to get blocks and hashrate just to see the code and that it works as expected?  #g33k Absolutely not, that's obviously exactly how I feel. If it makes you feel any better, no one has invested as much in this pool as I have so I have a lot on the line myself. |
|
|
|
The lack of code is probably a good thing at this juncture. I have been following this dispute only recently but the strong impression I get is that the only possible path to consensus on something like the miner agreement is if the code is ultimately produced and vetted and shipped by the core developers.
The miner agreement at this stage is simply a proposal. That proposal must now be vetted by the rest of the community to determine if a grudging consensus can be built around it.
Hopefully such a consensus will be possible. It strikes me as a far healthier path forward then stagnation forever in the current state or a civil war leading to a split into two coins.
That sounds good in principle but alas the miner agreement does a lot wrong that core can't condone. If they were to run with core's segwit implementation and a 2MB hard fork it would be different (as already proposed on the mailing list), but the agreement goes to great pains to say that segwit will be on a different bit implementation and be activated concurrently with a hardfork. Core can't agree to something that undoes the existing implementation which won't expire till November to adopt their more radical approach. If core agrees to do segwit followed by 2MB HF, it has to be with their existing implementation or they lose the next 6 months' opportunity to activate the heavily tested prepared segwit component already. The mining consortium has to ease their stance to meet them or we do nothing for another 6 months again or fork galore or risk an outside provided code base to work off. BU proved that's not a safe option with their incredibly unstable implementation of just one feature. The miner agreement is one by people who appear to not even know what they're agreeing to and ignores - or doesn't understand - what is realistically doable in a safe manner. The halfway point is core agreeing to their current segwit implementation AND a 2MB base blocksize hard fork that they implement - it's my gut feeling that's what we'll end up with but there needs to be a lot of rhetoric, chest thumping and circle jerking in the interim. |
|
|
|
|
Wannacry has done that already.
|
|
|
|
OK, someone set me straight...
"BU is dead", "BU is nothing", "BU is irrelevant"...
BU is still well above 1/3 of the hashrate signal (AntPool-16.77 %,BTC.TOP-10.06 %,ViaBTC-4.19 %, etc).
Bitmain, who supposedly signed this agreement, is still signaling the same as they have been.
It actually takes time and effort to make pools signal something different. Pools, being the conservative entities that they are, will only change when they have a clear thing to change to. Their miner agreement clusterfuck has yet to produce any code for them to use to signal with so they'll just leave everything as is for now. |
|
|
|
Hmm, i didn't saw any discussion about BU not a singel time... BU is even more dead than i thought Even Roger Ver is part of the coup attempt by miners WITH segwit. BU was a distraction and should be forgotten. It's totally irrelevant to this next round of clashes. ooorrr maybe not. Just now:  Same old mistake everyone keeps making. Variance. Exactly the same pools are signalling/flagging/fapping, whatever you want to call it, that have been for months now. |
|
|
|
...
I muted who over what?
LOL no. edonkey has me on iggy (he doesn't like my opinion that miner settings should produce a positive ROI). Hah, well we don't see eye to eye on everything either but you hash at my pools so all is forgiven  |
|
|
|
The "workers" stats URL form doesn't seem to be working any more...I apologize if this has already been covered. But I searched this thread and didn't see any recent mention of this issue.
...Userstats are now formatted for easier reading.
User and workers now show lastshare time instead of last update.
Per worker stats are now deprecated, please monitor workers from within the users page....
 Edit: Oh, wait, he muted me over the S9 thread; someone wanna repost this for him? I muted who over what? |
|
|
|
It still has another 10 months to go before the activation period is up.
~5 Months. |
|
|
|
For now I ask, why not activate Core's Segwit via soft fork now and then have new rounds of talks again for a hard fork to bigger block sizes? It would be better to do things conservatively than risk splitting the blockchain in 2.
What you are proposing is what core has been offering all along... |
|
|
|
so is this ASICBOOST proof then? if so, why did Bitmain agree?
If they wish to replace the existing soft fork implementation of segwit with their hard fork implementation then it will still allow covert asicboost to work. Of course this isn't evidence that they are using it or plan to but it certainly doesn't help suspicions... |
|
|
|
This is a great post. Has anyone repost it to reddit? do i have a permission to do it with the link of the original post and ofcourse your name credit for it?
Sure, go right ahead. |
|
|
|
Btw, Satoshi warned against miner centralization back in 2010. He asked people not to mine with GPUs, since he had intended to distribute the mining power. How do you think he would have responded to ASICs and CVE-2017-9230? By handing more power over to the miners?
This is true, he warned against it but also said it was to be expected. He basically asked politely that people hold off doing so for as long as possible, but expected it was inevitable. He also anticipated some degree of centralisation - his comment wasn't clear whether he meant nodes or miners or node miners, it sounded most like he expected full nodes to be miners. |
|
|
|
Hmm, i didn't saw any discussion about BU not a singel time... BU is even more dead than i thought Even Roger Ver is part of the coup attempt by miners WITH segwit. BU was a distraction and should be forgotten. It's totally irrelevant to this next round of clashes. |
|
|
|
Actually maximum transaction size and maximum block size ARE connected. There are currently no limits on transaction size which means one transaction can be the size of the whole block. To actually restrict it to 1MB requires a fork that makes it part of the consensus rules.[...]
I don't have an opinion either way since I don't know how realistic the long term requirement for a >1MB transaction is. Perhaps it could be the collective transactions for one massive company for a day or something, not sure...
Interesting, thanks. Would there be a way to restrict only legacy (P2PKH/P2SH) transactions? In this case, we could leave the way open for Segwit-style transactions with more than 1 MB. Anything can be set into rules with a consensus change and fork of some kind. The issue with restrictive changes - as we've seen with 1MB blocks - is that in the future it becomes far harder to undo them again if they proved to be a bad choice and real world use cases change. |
|
|
|
|
Show Posts
