Gold collapsing. Bitcoin UP.

[hodl]

>And yet the hashpower did not support a fork without replay protection.

@freetrader you were in the middle of that. did @Jihan insist on that before the BCH fork?

 

[hodl]

maybe you guys will find this interesting.

i'm a big fan of 200DMA's. since we don't yet have 200 days into BCH history, i decided to go down to my next longest favorite timeframe, the hourly, to plot/analyze the 200HMA (hourly moving avg) to try and gauge the relative strength of the latest BCH/BTC ramp that we just had compared to the last and only other one since the top that started around 1/6/18. the first set of arrows on the left show the time btwn the bottom on 1/6/18 and the turning up of the 200HMA on 1/10/18: it took 106 hours or btwn 4-5 days. this last one, indicated by the two arrows over on the right of the chart, took 26 hours, or just over 1 day.

this current move was a strong one guys, that yanked the 200HMA up almost immediately in a V-like bottom while also pushing price back above the 200HMA. that's not easy to do unless there was alot of fiat or BTC hanging out on the sidelines waiting for an opportunity to pounce on this latest dip to exchange for BCH, BCH's. it's bullish afaic:

 

[freetrader]

>And yet the hashpower did not support a fork without replay protection.

@freetrader you were in the middle of that. did @Jihan insist on that before the BCH fork?

Jihan didn't comment a whole lot on the matter in conversations I saw, but when he did speak out, it was to support replay protection, for which he presented the argument that opponents of the fork would do significant damage to smaller exchanges, who were ill prepared to take the technical measures otherwise needed.

I know it wasn't a unanimously popular decision to add it, but I'm still convinced that lacking replay protection would have resulted in dramatized customer losses, reputational damage for the fork, maybe legal hassles for its supporters (exchanges, wallets and other service providers) and likely slower uptake.

 

[hodl]

maybe this is really why Satoshi said this:

"I don't believe a second, compatible implementation of Bitcoin will ever be a good idea. So much of the design depends on all nodes getting exactly identical results in lockstep that a second implementation would be a menace to the network."


"this is why BCH employed replay protection; to avoid the menace and chaos. within BCH though, there is no confusion or menace. all nodes are in sync. now it's time to decide which blockchain adheres more closely to the original Bitcoin; i believe it is BCH."

 

[hodl]

i think there is a coordinated attempt from TPTB to discredit the space in general. there is probably a hint of truth to some of the complaints that gets amplified by trolls. Hitbtc is being slammed by a bunch of new acct concern trolling:

https://www.reddit.com/r/hitbtc/comments/7wo1h9/account_verification_has_anyone_had_account/

i had mentioned i first detected this a few months ago as we see cc providers banning crypto users, banks doing the same, exchanges and miners being forced out of China, etc. i don't think it will have any long term effects but this is what i'm seeing.

 

[Justus Ranvier]

"I don't believe a second, compatible implementation of Bitcoin will ever be a good idea. So much of the design depends on all nodes getting exactly identical results in lockstep that a second implementation would be a menace to the network."

That just shows that Satoshi didn't think things through very well, or else was just lazy.

The BDB lock bug proved that restricting nodes to a single implementation was not capable of ensuring that all nodes would agree on chain state.

The things you have to do to prove that a single implementation can maintain consensus with itself is exactly the same as what you have to do to prove that multiple implementations can maintain consensus between each other.

If you care about strict consensus between all nodes on the network the same work has to be done regardless of how many implementations are running.

 

[rocks]

"I don't believe a second, compatible implementation of Bitcoin will ever be a good idea. So much of the design depends on all nodes getting exactly identical results in lockstep that a second implementation would be a menace to the network."

Justus, Satoshi's quote seems perfectly accurate to me. 2 different implementations cannot exist on the same chain. The simple proof of this is once there is a single disagreement between implementations on what constitutes a valid block, a chain split will happen at that point.

If you have two very similar implementations that only disagree slightly (for example on block limit but agreed on all other rules), they could potentially co-exist on the same peer-to-peer network with a common UTXO set for awhile and validate those transactions on different chains. Here valid transactions would confirm on both chains and the two chains would be mostly similar with a similar transaction set.

The problem however is once you have separate chains, you also have separate block rewards, and any transaction that depends on a block reward (post split) in their history is no longer valid in both chains. Initially since there are only a few block rewards post split the two networks can stay mostly in sync, however they will continuously diverge over time and after awhile separate.

Without replay protection BCH would have followed the scenario outlined above, it would have mostly stayed in sync for awhile, but eventually the two networks would fully diverge since there were two separate chains with separate block rewards. At least that is what I saw with the trail forks ran in 2016.

As far as I can see there is no way to get around this eventual divergence, either implementations fully agree on rules, or they will eventually be on separate networks with separate chains.

 

[Justus Ranvier]

@rocks Your post conflates two entirely different concepts:
1. Multiple software implementations that are attempting to adhere to the same rules.
2. Multiple software implementations that intentionally recognize different rules.

Satoshi was talking about 1 but you're talking about 2.

 

[hodl]

yeah, it depends on how you define "implementation". certainly btcd, libbitcoin, & bitcoinJ proved beyond a doubt that different implementations of the core code could be kept compatible and in sync.

now, is ABC an "implementation" of core?

 

[hodl]

a day for celebration. sure, i knew several if not many of the key devs like Greg and Matt had left Blockstream, but Rick is calling them dead. that may be a bit of a stretch yet but still; this battle has taken almost 4 years:


[doublepost=1518389003,1518388210][/doublepost]volatility damping down. big move coming:

 

[hodl]

bwahahaha:

Rick: "next weeks episode is on the LN. and WOW, is there alot to say about the LN".

 

[rocks]

@rocks Your post conflates two entirely different concepts:
1. Multiple software implementations that are attempting to adhere to the same rules.
2. Multiple software implementations that intentionally recognize different rules.

Satoshi was talking about 1 but you're talking about 2.

OK, I misunderstood then, yes agree multiple implementations of the same rules can work.

The original problem if I remember it correctly is that the "rules" were never defined. They were whatever bitcoind did and included any of its idiosyncrasies at the edges to be the definition of Bitcoin's rules. Bitcoind's C code becomes the rule contract. This of course makes it next to impossible to get another implementation exactly right, which is why it was probably never fixed.

To have multiple implements a better approach is to have the definition of "rules" to exist in plain language outside of the code. This defines behavior other implementations can match, but more importantly it defines behavior that test frameworks can be designed for and each implementation can test against to show compatibility. I vaguely remember this being discussed in the original GCBU thread, has any movement been made on this?

 

[Justus Ranvier]

The original problem if I remember it correctly is that the "rules" were never defined. They were whatever bitcoind did and included any of its idiosyncrasies at the edges to be the definition of Bitcoin's rules. Bitcoind's C code becomes the rule contract. This of course makes it next to impossible to get another implementation exactly right, which is why it was probably never fixed.

Yes, it's a difficult problem to turn a prototype into an implementation of a formal specification. That's why I suspect a degree of laziness on Satoshi's part motivating that quote.

As far as I know any movement toward formal specification of the protocol was been actively suppressed well enough that no progress was ever made.

 

[hodl]

formal specs were shot down years ago by core devs. probably out of laziness but also out of a desire to define it the way they wanted to when they had to.

 

[freetrader]

Re: formal spec of the protocol:

https://lists.linuxfoundation.org/pipermail/bitcoin-ml/2018-January/000639.html

 

[solex]

The recent conversation deserves one of the more compelling slides from the first Satoshi's Vision Conference, San Francisco, September 2016. Justus' presentation was: Risk Management with Multiple Full-Node Implementations.

The risk is never zero that even one implementation can remain consistent across all mining nodes. The solution is to have many implementations so that, in the event of an accidental blockchain fork, then miners (and users) can migrate to one of the implementations on the majority fork, removing the need for emergency dev & miner centralized "consensus", like we saw in March 2013.
ETH is way ahead of Bitcoin in this respect.

 

[lunar]

Just leaving this here for the record.

Authorities should be prepared to act on cryptocurrencies: Carstens
6 February 2018

Press release
Authorities must be prepared to act against the invasive spread of cryptocurrencies to protect consumers and investors, Bank for International Settlements (BIS) General Manager Agustín Carstens said.

In a lecture "Money in the digital age: what role for central banks?", Mr Carstens said that for money to keep its value, it must be backed by accountable institutions which enjoy public trust. Here, central banks are key.

"The meteoric rise of cryptocurrencies should not make us forget the important role central banks play as stewards of public trust," Mr Carstens said in the lecture in Frankfurt, organised by Sustainable Architecture for Finance in Europe (SAFE), the Center for Financial Studies and the Deutsche Bundesbank. "Private digital tokens masquerading as currencies must not subvert this trust."

New technologies hold great promise, for example in making payment systems more efficient. But new currencies are not required for that promise to be realised. Authorities have a duty to make sure technological advances are not used to legitimise the profits from illegal activities, and to educate and protect investors and consumers, Mr Carstens said. They must also ensure cryptocurrencies do not become entrenched and pose a risk to financial stability.

"Novel technology is not the same as better technology or better economics," Mr Carstens said.

"That is clearly the case with Bitcoin: while perhaps intended as an alternative payment system with no government involvement, it has become a combination of a bubble, a Ponzi scheme and an environmental disaster."

Large price swings, high transaction costs and a lack of consumer and investor protection make cryptocurrencies unsafe and unsuited to fill money's role as a shared means of payment, store of value and unit of account, he said.

Central banks and financial authorities should pay particular attention to the ties linking cryptocurrencies to real currencies, and ensure they do not become parasites on the institutional infrastructure of the wider financial system. To ensure a level playing field for all participants in financial markets, access to legitimate banking and payment services should be limited to those exchanges and products that meet accepted high standards, Mr Carstens said.

"This means 'same risk, same regulation'. And no exceptions allowed," he said.

 

[hodl]

Yep, the fight has entered a new stage.
[doublepost=1518449525,1518448891][/doublepost]but i also think i'm seeing a coordinated attempt to discredit and jam up liquidity of many major crypto exchanges thru FUD and concern trolling by TPTB. it's pretty serious by my estimation.
[doublepost=1518450393][/doublepost]it kinda warms my heart that all the historically Bcore supporting pools have been smashed down to small players (f2pool, Bitfury, BTCC, BitClub) Slush being the exception. Kinda like what's happening to Blockstream. Winning:

 

[awemany]

... it has become a combination of a bubble, a Ponzi scheme and an environmental disaster.

Yes, if I look at the office towers of Manhattan or "Mainhattan" I sometimes do get that impression.

 

[hodl]

http://www.freeingenergy.com/the-market-has-spoken-clean-energy-just-became-the-cheapest-source-of-electricity/