Gold collapsing. Bitcoin UP.

[yrral86]

Idea: should block 478559 be made a checkpoint?

Maybe, but first we need a block 478559 to be found...

 

[yrral86]

I know it's a little late, but looking at https://github.com/Bitcoin-UAHF/spec/blob/master/uahf-technical-spec.md#req-7-difficulty-adjustement-in-case-of-hashrate-drop
I don't think that the difficulty will adjust unless we mine 6 blocks first...

 

[adamstgbit]

i read somewhere that the dif will adjust on the first block, then if hashrate drops futher this other -25% dif adjustment thing can happen.

no idea if this is accurate, the github linked above does not say anything about the first block

 

[AdrianX]

this is exciting!
i wonder how much hash rate is looking for the first block.

Just took a look at existing hash and it hasn't dropped much.

 

[adamstgbit]

@AdrianX

do you have a good way to guesstimate hash rate?
[doublepost=1501605534][/doublepost]i can't resist

ARM THESE SHIELDS BOYS


WOOOOOOOOT!┗(°0°)┛

 

[yrral86]

@adamstgbit
There is no way to estimate hash rate until we have enough blocks to derive a meaningful average. You could look at the hashrate change on the other branch, but it is pretty much unchanged. We also don't know how much idle hardware there is that could be applied to BCH without taking away from BTC.

 

[AdrianX]

What @yrral86 said. I checked in on https://bitcoinwisdom.com/bitcoin/difficulty

ViaBTC is boasting 215 PH/s at old difficulty https://pool.viabtc.com/

 

[throwaway]

https://blockchair.com/bitcoin-cash/block/000000000000000000651ef99cb9fcbe0dadde1d424bd9f15ff20136191a5eec

http://blockdozer.com/insight/block/000000000000000000651ef99cb9fcbe0dadde1d424bd9f15ff20136191a5eec

Congratulations everybody!

 

[freetrader]

@throwaway : seems legit ;-)

Now, let's not count our chickens before they are well and truly hatched.

 

[throwaway]

Up to 478561 now... that's amazing.

 

[adamstgbit]

last block found by unknown.... not ViaBTC or Bitcoin.com?

this is good.

 

[Dusty]

New last block found by unknown.... not ViaBTC or Bitcoin.com?

2 more blocks in a row a few minutes apart, that's quite strange. What can it be?
1) Pure "luck"? That would seems unlikely to me.
2) wrong algorithm resetting difficulty?
3) Attack from other miners? By mining a couple blocks in rapid succession you avoid the resetting the difficulty, hence forcing a mining loss for other miners.

Thoughts?

 

[bluemoon]

Fourth block found!

 

[adamstgbit]

@Dusty

obviously there is a certain amount of luck involved, even with 100% of the bitcoin network, we would be expected to find a block every 10mins.

wrong dif? wouldn't that invalidate the block somehow? ( that would be bad news)

an Attack? its a rather expensive attack... if it is an attack to keep dif high, it'll be a short lived inconvenience for bitcoin cash, and it will show the world that "they" think bitcoin cash is WORTH attacking.

at this stage, i am assuming there is alot more hash power then anticipated most of it coming from a big minner who got very lucky.
[doublepost=1501615495,1501614713][/doublepost]price at viaBTC has corrected itself to match kraken. to be expected... i'm liking the volume that correction produced.

this might very well be a local bottom, i think we can see it go as high as 0.2 on kraken. I say this based on the idea that there is a lot more hash power then we thought there would be.

 

[adamstgbit]

another block found!

estimation of BCC hash rate based on 5 blocks in ~4-5 hours? is what like ~1/6th that of bitcoin?

might be under attack, but 1/6th kinda makes sense... i mean at one point there was >50% hashing with BU. so.... who knows.

 

[AdrianX]

WOW - first block had 6,985 transactions, and it did not break the internet. It's hard for some to understand the easiest way to include more transactions in a block is just to increase the transaction limit.

I think it is such a simple solution many thing it is a trick.

 

[sickpig]

Idea: should block 478559 be made a checkpoint?

https://github.com/Bitcoin-UAHF/spec/blob/master/uahf-technical-spec.md#req-3-fork-block-must-be--1mb

 

[79b79aa8]

@freetrader had it covered

 

[throwaway]

Couldn't an attack-reorg include both a new 478558 and a new bigger-than-1MB 478559?

My worry is not a reorg completely contained within the new chain, but a reorg that "dips" into the old chain.

Edit: man that Hennessy Road Wan Chai Hong Kong miner keeps going like there's no tomorrow!

 

[freetrader]

@freetrader had it covered

Nope, the >1MB fork block a.k.a. wipeout protection was not my idea. It was suggested in this form by miners, who generally know pretty damn well what they are doing.

---

One more thing:

CONTROVERSIAL HARD-FORKS CANNOT HAPPEN