Gold collapsing. Bitcoin UP.

[Bagatell]

I'm disappointed the bet didn't up McAfee's ante.

 

[Norway]

@Bagatell
I agree. 1 bitcoin is boring compared to the alternative, lol!

 

[79b79aa8]

1 BTC = ~ USD $2,750 + 1 BCC. That's pretty yummy.

 

[sickpig]

Bitcoin Unlimited Cash edition 1.1.0.0 has just been released:

https://www.reddit.com/r/btc/comments/6q4add/bitcoin_unlimited_cash_edition_1100_has_just_been/

 

[Norway]

@sickpig
Great news! 19 nodes already up and running:
https://bitnodes.21.co/nodes/?q=BUCash

 

[adamstgbit]

@Norway

Mining is a memoryless process. The next bitcoin block is aways expected 10 minutes from now. It's like a moving target. No matter how much you hash, you never get closer to the target, until -- just like seeing a shooting star -- you get lucky and solve the block.

Imagine that a block was just found. The next block is expected (as in the "expected value") 10 minutes from now. But then let's imagine 5 minutes have gone by without a solution. The block is still expected 10 minutes from now, which is 15 minutes from the starting point. Maybe another 5 minutes goes by, and still the next block is expected 10 minutes from now (20 minutes from the starting point).
[doublepost=1501241180][/doublepost]The reason the answer to the question is t = 15 minutes, is because it is stated that the selfish miner finds the solution to the next block (at height N) at t = 0. So this means then that the honest miners are still working on block N at this point. The haven't made any progress towards finding a solution because mining is memoryless. And so -- since they have 2/3rds the mining power -- the expect arrival time for a solution is t = 15 minutes.

i see your logic...
but for the same reason @Norway can say on AVG you'll wait ~5 mins to get included in the next block. the answer is 5mins.

sure the chances that 1 hash is the correct one is like 1/1000000000 and that doesn't change each time you hash. BUT the probability of finding a block increases with time, because after doing 1000 hashes the chances of one of these hashes being correct is now 1000/1000000000 .

CSW is right, 5mins is the answer

 

[adamstgbit]

@awemany wrote a python simulator to study this problem:

https://bitco.in/forum/threads/wright-or-wrong-lets-read-craig-wrights-selfish-miner-fallacy-paper-together-and-find-out.2426/page-2#post-41784

His simulator confirms that that answer is t = 15 minutes.

hahah for real?
hmmm the simulator is either broken, or a very good simulator.

i remain sceptical that chances for finding a block does not incress as work toward finding a block accumulates

 

[lunar]

Just copying an exchange between @Erik Beijnoff and @Mengerian from the slack channel here, so it doesn't get lost in the abyss.

@Erik Beijnoff said:

Hi folks, on vacation so have been pretty inactive the last few weeks, but need some advice on Bitcoin Cash for the upcoming fork so I figured I’d pop in here.
I converted some BTC to the ViaBTC BCC futures. Thinking about converting some more, but have some concerns and need to estimate the soundness of the split first.

1. What’s your take on the probability of the split happening at all?
I know that some miners have asserted they will divide their hashing power on basis of the price of the futures on ViaBTC. What I can’t understand about this is that as in the same way as with the UASF it does not make sense for any miner to be the first to switch. In all scenarios where the BCC fork is the minority fork value wise, all miners mining on that fork will loose money until the difficulty is brought down.
Does this mean that there are advantages of mining the minority chain that I’m not seeing? Mining on the minority chain being a hedge against the risk of wipe out of the majority chain (segwit2x)?

For clarity - I know that there’s an emergency diff adjustment if too little hash power joins the new branch. It’s good that it’s there, but I believe it will have major impact on the value of the fork if it’s needed, so what I’m really looking for is an answer for the viability of a split event with a sizeable amount of hashing power splitting off together with the branch.

2. Up until talk was raised about replay protection, I held the assumption that if Bitcoin Cash would become the most valuable branch it would probably be considered to be the real Bitcoin, due to that the blocksize limit arguably even isn’t a consensus rule, i.e. it would just be an upgrade of the protocol.
How is the replay protection implemented and do you consider this to make Bitcoin Cash a coin that isn’t compatible with the existing Bitcoin network, i.e. can it still *replace* the old branch, infrastructure intact, or will it increase the risk of having two Bitcoin networks?

And, is the replay protection bi-directional, i.e. are Bitcoin txes incompatible with Bitcoin Cash and vice versa or is it one direction only?
Personally I feel that a bi-directional replay protection greatly increases the risk of permanenting two different branches.

@Mengerian said:

Hey Erik,
Regarding 1), You are correct, if BCC is trading lower than BTC initially, then miners would make more money mining BTC. For the fork to survive, it requires at least some amount of short-term "irrational" mining.
A miner would have to to be motivated enough for the Bitcoin Cash chain to survive to be willing to spend money for a while until difficulty adjusts. I think it will take a couple hundreds of thousands of dollars of cost to so this (depends on relative bcc/btc price, as well as whether the difficulty adjustment gets activated)

2) Replay protection is bi-directional. This means all transactions on each chain are not valid on the other. There will be two "permanent" branches, but this would have been the case anyway due to the wipeout protection.

Replay protection has pros and cons. It means that the new chain is pretty much guaranteed to start in a minority position, and has to win in the market over time.

On the other hand, replay protection has the advantage that users of Bitcoin Cash don't have to worry about losing their coins when they transact in Bitcoin. Also, the new signature hashing scheme the Bitcoin Cash uses is just better than the current Bitcoin one. For example it solves the quadratic hashing problem, include input value signing which can make hardware wallets more secure, and it enables double-spend fraud proofs, which could make zero-conf transactions more secure.

 

[go1111111]

BUT the probability of finding a block increases with time, because after doing 1000 hashes the chances of one of these hashes being correct is now 1000/1000000000 .

This is wrong. After you do 999 hashes and don't find a block, the probability of your next hash being correct is 1/1000000000. You already know that the 999 earlier ones didn't work, so they don't help you at all in finding the next one.

Your model implies that on your second hash, you get "one free extra hash", on your third hash you get "two free extra hashes", on your 1000th hash, you get "999 free extra hashes." That's not how mining works.

 

[79b79aa8]

Pedantic quibble:

@Mengerian said:
On the other hand, replay protection has the advantage that users of Bitcoin Cash don't have to worry about losing their coins when they transact in Bitcoin.

Bitcoin Cash is nearer to the original than Bitcoin + SegWit, by any relevant measure. Bitcoin + SegWit might get to keep the BTC / XBT currency codes, but it should not be so easily be considered the sole referent of the appellative 'Bitcoin'.

 

[yrral86]

It's the classic paradox of probability. The law of large numbers tells us that if you flip a fair coin enough times, then heads will come up 50% and tails will come of 50%. But we all know that you can flip a fair coin (or use a provably fair RNG to erase any doubts about the coin) 10,000 times and get 4500 heads and 5500 tails. At this point, you know that if you keep going you'll approach 50/50, so doesn't that imply that heads are more likely than tails? Well, no, it is still 50/50.

There is a distinction to be made between "What is the probability that the next nonce I try finds a block?" vs "What is the probability that I have found a block given I've already tried 100000 nonces?".

 

[Mengerian]

@79b79aa8

Perhaps further in the future Bitcoin Cash will simply be referred to as "Cash"

 

[Norway]

@yrral86
Actually, I think we are talking about 3 different statistical scenarios:

1) You have a dice with 10 sides. One of the sides is red. You throw the dice until you get the red side up. This is not mining, but what mining is approaching.

2) You have a bag with ten balls. One ball is red. You take out balls until you find the red ball. If this was mining, it would make sense to not put the balls back after you looked at them. But this is the scenario that is most far from mining.

3) You have a bag with 10^8 balls. 10^7 of the balls are red. You take out balls until you find a red ball. You could improve your odds slightly by not putting the balls back in the bag, but it doesn't really matter because the improvement is so tiny. I think this is how mining works today. (But I don't know, never looked at the algos, lol!)
[doublepost=1501283996][/doublepost]@Mengerian We have come a long way when we call Bitcoin Cash "bitcoin". We are at the moon when we call it "cash". ┗(°0°)┛

 

[adamstgbit]

This is wrong. After you do 999 hashes and don't find a block, the probability of your next hash being correct is 1/1000000000. You already know that the 999 earlier ones didn't work, so they don't help you at all in finding the next one.

Your model implies that on your second hash, you get "one free extra hash", on your third hash you get "two free extra hashes", on your 1000th hash, you get "999 free extra hashes." That's not how mining works.

right i was assuming previous hashes got miners closer to "solving the problem" by eliminating 1 possibility...

there MUST be a centrin amount of this at play tho, i mean the possibilities are not infinite, are they?

 

[solex]

@79b79aa8

Perhaps further in the future Bitcoin Cash will simply be referred to as "Cash"

"Cash" is closer to "Credit", which has often been mentioned as the currency of the future in books and film.

 

[AdrianX]

https://coin.dance/blocks

Segwit 141 just about locked in and Segwit2X down to just over 77% on the day I'm hoping this is just variance.

 

[AdrianX]

taking a second look at the NYA2X + segwit. The facts support a bait and switch.

BIP91 proposal - signal for segwit on Bit 4 with 80% activation 2017-05-22

Segwit2X proposal for segwit + 2MB hard fork on Bit 4 with 80% activation 2017-05-24

It looks like the 2X agreement is riding the back of BIP91 hoping to get a 2MB hard fork.

So the narrative supports the fact that there may not be enough hashing power to ratify the 2MB hard fork, and segwit was activated with no intention to support the Segwit2X NY agreement.

I think it is very important that anyone with connections to Coinbase of Bitpay or any of the companies who have committed to the 2X fork, make it clear that they intend to fork to 2MB.

 

[adamstgbit]

pretty sure most of the companies who are "onboard" with segwit2x are only onboard because they believe everyone else is. Its not because they LIKE the idea, they simply like the idea that everyone agrees. and so it's very fragile, just one or two poeple pull out of the agreement and others will pull out as well...

 

[yrral86]

right i was assuming previous hashes got miners closer to "solving the problem" by eliminating 1 possibility...

there MUST be a centrin amount of this at play tho, i mean the possibilities are not infinite, are they?

I'm not sure it isn't infinite, but I'm not sure it is either. It is close to Norway's scenario 3, but the bag has 2^32 balls (4 byte nonce), and there may or may not be a red ball. As transactions come in, you add them to the block, and then you get a new bag. You could ignore the new transactions and keep trying from the bag you already have, but then you give up the fees you could collect. And remember, you're not even sure if there is a red ball in that bag.

Maybe for that particular block header there is no nonce that gives you a small enough hash to pass the difficulty bar. As difficulty goes higher, it becomes more likely a given bag has no red ball. In fact, if you have a gigahash/s of hardware, every second you eliminate 23% of each bag (10^9/2^32). You'd have to check a lot of bags to find a red ball. Luckily, the block header includes a timestamp, so even without new transactions you can get a new bag every second.

For large miners, that still doesn't give them enough bags. They can also get a new bag by altering the coinbase script, which changes the merkle root. The script can be up to 100 bytes. Some is allocated for signaling mechanisms and such, but there is still enough room to produce enough bags to keep even the largest miner busy.

As for the question of infinity, if a bag of 2^32 balls can have no red balls, and there is no way to prove a bag has no red balls without taking out all the balls, there is no proof that red balls even exist until you find one. As an extreme case, try to find me an input that hashes to 256 0's. I can conjecture that such an input exists, but I can't prove it until I find one. I can try one byte inputs, two byte inputs, and so on, but I have no idea how many bytes I'll need and our sun may very well become a red giant before I find out. That said, bitcoin itself provides good data on how many bags of size 2^32 you have to check on average to get a particular number of 0's at the front of your hash output.

There are some interesting details on the structure of the data that is actually hashed here, although there seems to be a few arithmetic errors:
http://chimera.labs.oreilly.com/books/1234000001802/ch08.html#mining

 

[sickpig]

Bitcoin Unlimited - Bitcoin Cash edition - New Ubuntu PPA repository available