Gold collapsing. Bitcoin UP.

[Christoph Bergmann]

Thanks, guys. If it's just a few spam messages, use the report function, and I'll usually get to them within a day.

If it's a large bot attack like the one we had this morning, you can send me a PM and I'll prioritize it.

We had a similar case on coinforum.de, where I had the same spammer building several new accounts each day. In the end we had to close the registry / manualize it for some days to end the spam.

 

[satoshis_sockpuppet]

Bitcoin cash 50 % market cap of Ethereum.. holy shit.

I know, markets aren't always rational and even more so in a short timeframe. But imho this is all a very clear indicator, that all these altcoins exist with a recognizable market cap for one single reason: Bitcoins unwillingness to scale.

Ethereum's turing completeness or "rich statefullness" or whatever the banksters pulled out their ass to justify Ethereum's existence aren't interesting. Everything of interest can be done on Bitcoin.

Miners, get you fucking shit together. Kill the 1 MB chain and switch to SW2X. Your asics will raise in value like crazy.

 

[Windowly]

@satoshis_sockpuppet If the miners don't switch to SW2X and switch to Bitcoin Cash they can arguably get more profit -- much as Ryan X. Charles points out.

 

[singularity]

Just so you guys know, Core are talking about hardforking to a new DAA and possibly POW depending on how the S2X fork works out.

 

[Windowly]

Thanks for the heads up. In that case they will become Bitcoin Gold version 2?

 

[Peter R]

One good thing about the Seg2x vs Core fork is that because Core is apparently winning market cap war on the bitfinex futures markets, I'm seeing a lot of Core supporters embracing the market as a legitimate way to prove support.

My guess is that if you asked them before there was any market info supporting their position, they might have said market prices are too easily manipulable by big businesses. Now they're finally starting to believe that markets are hard to manipulate, which brings them closer to embracing market governance.

Carrying over our discussion from BTC1 slack:

The futures prices (assuming for a moment that the markets are liquid and the exchanges are trustworthy) do not represent the will of the majority, they represent a prediction of what will actually happen. People may want bigger blocks, but they may sell BT2 tokens because they think the upgrade won't happen and are worried about the BT2 tokens expiring worthless.

I think there are ways to fix this, however. For example, if the "block size limit" is the aspect of contention, then create a CST that pays out on the big block and small block chains, should a qualifying upgrade event happen (e.g., 72 blocks of regular PoW on the big-block chain). But if no upgrade happens, don't have one side of the CST expire worthless! Just keep rolling it forward. With this type of CST, I think a much different story would be told than what we see with the BT1 and BT2 tokens on Bitfinex.

 

[NewLiberty]

I think that the combination of the two different difficulty adjustment algorithms AND the timing of their implementation are just about perfect.

EDA had several effects.

1) Survived the fork.
2) Rewarded miners more during the first 3.5 months with the oscillations.
3) Got most miners and pools to use the BCH fork code at least once.

But downsides
4) Coin generation is faster, more emission, more inflation, noisy blocktimes will hit the halfing in 2020 sooner

So it had to end, but when and how?

New Difficulty Adjustment Algo has new effects

1) Retains effects of emergency adjustments for radical changes in hash rate, things like carrington effects, yellowstone caldera, war, new tech etc. All handled.
2) Rewards miners slightly less over time (because it adjust to new hash more rapidly, miners are affected by new hash online before waiting for 2 week.
3) It Slows coin generation by keeping closer to 10 minute schedule than Bitcoin SegWit does.

The result of this combination is a faster emission in the early days of the fork. The loyal and nimble miners are rewarded slightly more. BUT the long term effects off this are mitigated just in time because the 2020 fork should happen at just about the same time for both Bitcoin SegWit and Bitcoin Cash. Consider that if BTC block time is an average of 9.4 minutes and BCH is 10 minutes.
At 55 days ahead now, and 951 days to go.

Waiting longer would mean that BCH hits it first. Miners decided, devs complied, it feels rushed but there wasn't any more time to debate or test new ideas longer. If there is a better solution, it can be implemented afterward.

New ASICs may be coming and there may be much more investment in hashing and Bitcoin Segwit difficulty may end up rising to make it less than 9.4 min average, but with the facts of today and the historical data, now is the time and I am very happy with the results. And if a better solution is made later, it can be used instead.

This is just a technical position and does not speak to the communication issues. Much may be improved upon there.

 

[jbreher]

Fuck Ripple. Don't let the medal dais door hit you on the way out.


(I may have to eat these words at some point, but if so, I have faith it will only be temporary)

 

[solex]

@NewLiberty Great summary, and a very important point about the faster block rate on BTC drawing the chain heights closer to level at the next halving. The new DAA will be a real winner for Cash.

Another option for the next HF is to target 1 minute blocks with 0.1x rewards. This would help a lot with bricks-and-mortar retail usage effectively creating fractional confirmations viz-a-vis the historic 10 mins. Such a change would need to be announced at least six months ahead.

 

[NewLiberty]

I'm not a fan of faster blocks because I don't think they really provide any more security for the bricks-and-mortar retailers. It would take more confirmations for the same security is all. Double-spending is uneconomical for small purchases, and no RBF to watch out for means zero-conf are going to be fine for small retail purchases at point of sale. As a retail merchant, I would rather accept Bitcoin Cash than a credit card all day long.

 

[Peter R]

I'm not sure we need a block time target at all. Let miners mine at any difficulty for a proportionately lower reward. A market mechanism would emerge where miners converge on the best block time for network conditions and the demands of users (which I suspect would be less than 10 min).

 

[satoshis_sockpuppet]

New Just so you guys know, Core are talking about hardforking to a new DAA and possibly POW depending on how the S2X fork works out.

Source?

Another option for the next HF is to target 1 minute blocks with 0.1x rewards. This would help a lot with bricks-and-mortar retail usage effectively creating fractional confirmations viz-a-vis the historic 10 mins. Such a change would need to be announced at least six months ahead.

I'm not a fan of changing the target time. Again, Bitcoin worked pretty well for years and with a big enough block size, zero conf is secure enough.

If someone touched this, wouldn't Bitcoin NG be the more elegant and easy solution?

@Peter R
Interesting idea! But I'd like to change Bitcoin very conservatively.

 

[Justus Ranvier]

@NewLiberty How did it happen that so many people in Bitcoin have a room temperature IQ approach to risk management?

It's embarrassing that we even have to point out that there exist levels of assurance between zero and "heat death of the universe".

 

[Tom Zander]

This is just a technical position and does not speak to the communication issues. Much may be improved upon there.

I don't think anyone really had critical comments on the technical points, if only because there hasn't really been time to do a proper in-depth review of the algorithm.

Now, some days after the announcement, my investigation shows the chosen algo seems to have a consistent average-block time that is about 5% faster than 10min. Compare that to k-1 (Neils) algo that is about 2% slower than 10 min. After being too fast for so many months, I think this is a minus point to the new algo.

The point to take away here is that we at this time are absolutely not sure at all if it was the best solution. We just know it was better than what came before.

The critique has, again, not been about the actual algorithm. It is about the process that lead us to the details of the HF.

 

[NewLiberty]

@Peter R

Agree. Its a UI / UX issue primarily. It relates to Justus's point on risk management.

@Justus Ranvier

I blame myself. I hope to forgive the ones that don't know what they are doing, (and show them instead).

A competitive market should exist in wallets where risk assurance is provided to the merchants who may be innocent of any skills.

When they can set their price for goods in the way they are already most familiar doing,
then communicate the price effortlessly for agreement by the purchasers,
who upon agreeing convey their bitcoin to the merchant.
The merchant then does nothing more than wait for a green light to appear and say "Next please"..

We know how to do all of this. Its not even that hard. Just takes doing it.

 

[awemany]

Now, some days after the announcement, my investigation shows the chosen algo seems to have a consistent average-block time that is about 5% faster than 10min. Compare that to k-1 (Neils) algo that is about 2% slower than 10 min. After being too fast for so many months, I think this is a minus point to the new algo.

If so, I see that as a grave bug in Bitcoin Cash. You do not fuck with the emission schedule! And if something about the emission schedule was fucked involuntarily (for example the past and current EDA "joy"), it should be fixed, not confirmed in its broken state and socially made harder to change (a.k.a. "Well we fixed EDA already, didn't we, so why do you propose to do it again!?").

 

[albin]

Bad actors on the Core side are already laying down the groundwork to troll "Bitcoin Cash Classic".

Tard Vays already started saying insane things like fixing diff algo is "centralized economic planning to manage the inflation rate", and that this undermines "immutability".

 

[theZerg]

Without Amaury's / freetrader's ABC, there wouldn't exist a non-shitwit Bitcoin. BU and Classic would be segwit implementations. Without ABC, there wouldn't exist a DAA fork in time. There was nearly no effort to coordinate a decision, afaik.
Yes, lacking communication is bad. Banning lead developers of competing implementations from your slack channel is even more bad. If that indeed happened, it's a shame.

BU had active dev going on and we met the initial fork date. We were delayed because a contributor who agreed to lead the BU effort actually spent his time on ABC. It wasn't until after the TFOB conf that I was able to check in on progress and realized the situation.

 

[freetrader]

Oh convoluted history. If we delve deeply we would be surprised what we find.

---

Now, some days after the announcement, my investigation shows the chosen algo seems to have a consistent average-block time that is about 5% faster than 10min

@Tom Zander : That's a distressing finding. Could you please share detailed results so we can try reproduce this. Apologies if I missed a link.

I can't reproduce it offhand with Neil's simulator.
Below some data based on the common scenarios and the latest code where compute_cw_target is updated to use the sorting described by the UAHF spec. I've trimmed the output to include only the mean block time lines.

Not to say this is representative (more scenarios should probably be looked at, including historic hashrate ones), but in the difficulty-ramp (dr*) cases below, the algo is slightly slower than 600s on average, but less than 1% so. Even for the other scenarios it doesn't go far beyond that.

./mining.py --algo cw-144 -s default -n 1000
Starting seed 1509841218 for 1000 simuls
Mean block time(s) Range 599.3-613.3 Mean 604.3 Std Dev 2.4 Median 603.9

./mining.py --algo cw-144 -s dr50 -n 1000
Starting seed 1509841849 for 1000 simuls
Mean block time(s) Range 599.1-614.7 Mean 604.5 Std Dev 2.5 Median 604.1

./mining.py --algo cw-144 -s dr75 -n 1000
Starting seed 1509841867 for 1000 simuls
Mean block time(s) Range 599.4-618.8 Mean 605.3 Std Dev 2.9 Median 604.7

./mining.py --algo cw-144 -s dr100 -n 1000
Starting seed 1509841875 for 1000 simuls
Mean block time(s) Range 597.6-619.1 Mean 606.6 Std Dev 3.4 Median 605.9

./mining.py --algo cw-144 -s fxramp -n 1000
Starting seed 1509841887 for 1000 simuls
Mean block time(s) Range 596.5-613.6 Mean 603.4 Std Dev 3.2 Median 603.0

./mining.py --algo cw-144 -s ft100 -n 1000
Starting seed 1509841919 for 1000 simuls
Mean block time(s) Range 599.9-620.2 Mean 607.6 Std Dev 3.1 Median 607.3

 

[throwaway]

About "not fucking with the emission schedule" and half-joking but, even if the blocks were slightly faster than 10 minutes, wouldn't that accurately match the way bitcoin has behaved so far? The halvenings have always happened in less than 4 years.