Gold collapsing. Bitcoin UP.

[cypherdoc]

I just love all the spam that clutters this thread.

 

[Roy Badami]

This summary of Vin Armani's recent comments on Twitter might be of interest to those (like me) who don't generally follow Twitter.

https://www.reddit.com/r/btc/comments/9tvj26/game_theory_vin_armani_on_the_machinations_of/

 

[witly]

I agree with the last sentence "After BCH, their next target will be BTC."

 

[cypherdoc]

i'm still not seeing any large BCH miner generated 32MB blocks designed to fork off all small miners in a bald faced attempt to take control of the network. why is that?

 

[cypherdoc]

this looks terrible too:

[doublepost=1541342645][/doublepost]Since November 1, the volume of BCH has grown from less than $200 million to $980 million.

https://cryptoupdate.ca/bitcoin-cash-continues-to-skyrocket-15-to-535-volume-quintuples/

otoh, this is just pathetic:

 

[Norway]

@Peter R should take @lunar's bet and make a quick buck.

 

[Peter R]

@lunar:

OK I'll take your bet. But just to be clear: what happens if neither the new ABC nor the new SV rulesets are adopted? By my reading of the terms, I think I would win. Do you agree?

Please respond to "execute" this bet with me.

/cc @Norway

 

[cypherdoc]

lemme get this straight. i assume at fork time, ABC is going to use it's SighashForkID method used the last two times for replay protection against the old (current) ABC chain. this also prevents any replaying of tx's against the resulting SV chain too, right?

 

[Roy Badami]

I agree with the last sentence "After BCH, their next target will be BTC."

BTC is very different from BCH (and indeed all other PoW coins) in one important aspect:

The vast majority of hardware on the planet capable of mining BTC is already mining BTC. No other PoW coin that I'm aware of has this property.

There is literally nowhere from which to quickly draft in significant additional SHA256 hash power to help win a hash war in BTC, except from BCH, which is relatively modest in terms of hash rate.

So yes, they might try. But the tactics will have to be very different.

 

[Dusty]

lemme get this straight. i assume at fork time, ABC is going to use it's SighashForkID method used the last two times for replay protection against the old (current) ABC chain. this also prevents any replaying of tx's against the resulting SV chain too, right?

Speaking of that, I'm unable to correctly decode this paragraph:

When the median time past [2] of the most recent 11 blocks (MTP-11) is less than UNIX timestamp 1557921600 (May 2019 upgrade) Bitcoin Cash full nodes MUST enforce the following rule:

• forkid [5] to be equal to 0.

When the median time past [1] of the most recent 11 blocks (MTP-11) is greater than or equal to UNIX timestamp 1557921600 (May 2019 upgrade) Bitcoin Cash full nodes implementing the November 2018 consensus rules SHOULD enforce the following change:

• Update forkid [5] to be equal to 0xFF0001. ForkIDs beginning with 0xFF will be reserved for future protocol upgrades.

This particular consensus rule MUST NOT be implemented by Bitcoin Cash wallet software. Wallets that follow the upgrade should not have to change anything.

For what I know the forkid is used while signing a transaction, so how can it be that the consensus changes without wallets having to upgrade?

I'll be grateful to anybody that can enlighten me on the subject, thanks

 

[Roy Badami]

Wallets have to upgrade every time BCH hard forks. This is no different from any other coin that performs regular hard fork upgrades.

 

[Dusty]

What you say directly contradicts the last sentence taken from the November fork specification: https://github.com/bitcoincashorg/bitcoincash.org/blob/master/spec/2018-nov-upgrade.md

This particular consensus rule MUST NOT be implemented by Bitcoin Cash wallet software. Wallets that follow the upgrade should not have to change anything.

(emphasis added)

 

[freetrader]

lemme get this straight. i assume at fork time, ABC is going to use it's SighashForkID method used the last two times for replay protection against the old (current) ABC chain. this also prevents any replaying of tx's against the resulting SV chain too, right?

Wallets have to upgrade every time BCH hard forks. This is no different from any other coin that performs regular hard fork upgrades.

It's a point that is easily misunderstood.

This "replay protection change" in the spec (which is optional, and not implemented by BU, XT or SV clients) means that after the *next* HF date passes, old clients will apply a different forkid which will make them incompatible with existing wallets.

So the wallets DON'T change - it forces the *node clients* to disarm this change by hard forking (extending the deadline or removing the automatic change altogether).

I don't like this scheme (as I've said before).

 

[majamalu]

While reading this interview I remembered something cypherdoc used to say back in 2011: "nerds do not understand what they have created" (or something like that):

https://www.ofnumbers.com/2018/10/01/interview-with-ray-dillinger/

Observe how Ray Dillinger begins to say the most staggering nonsense as he approaches economic issues (example: according to him, the fall of Rome was due to the hoarding of gold coins). Note that this guy claims to have been deeply interested in reinventing money most of his life.

cypherdoc was right: you can have a stratospheric IQ, and be a cryptographer worthy of a Nobel prize, while remaining blind to what may be obvious to any attentive reader of Hayek's work.

Bitcoin's Manifest Destiny is only apparent to those who understand the peculiarities of complex systems, the ubiquity of a spontaneous order - as well as the reasons why it can never be entirely suppressed -, the concept of emergent property, the principles of praxeology, etc.; in other words, to those who treasure a deep understanding of the nature of the market and the nature of the state.

 

[Zarathustra]

@Peter R should take @lunar's bet and make a quick buck.

That's an interesting statement. Calvin and Craig are the first miners who understand, but @shadders and @Otaci are too incompetent to transform their knowledge into code. Maybe then they are even more motivated to prove the opposite.

 

[kyuupichan]

CSW has already shown how to do atomic swaps with simple scripts and no new codes. I've not read all the pages here, but was that missed? That's the kind of thing we should have implemented in more advanced wallets

 

[Norway]

@Peter R didn't get the memo that the two main cases for CHECKDATASIG, oracle bets and cross chain atomic swaps, can be done with the current protocol with short scripts.

 

[Roy Badami]

It's a point that is easily misunderstood.

This "replay protection change" in the spec (which is optional, and not implemented by BU, XT or SV clients) means that after the *next* HF date passes, old clients will apply a different forkid which will make them incompatible with existing wallets.

So the wallets DON'T change - it forces the *node clients* to disarm this change by hard forking (extending the deadline or removing the automatic change altogether).

I don't like this scheme (as I've said before).

What you say directly contradicts the last sentence taken from the November fork specification: https://github.com/bitcoincashorg/bitcoincash.org/blob/master/spec/2018-nov-upgrade.md


(emphasis added)

You're right, it does say that, and I'm not sure I agree it's a good idea to recommend that wallets don't enforce the full consensus rules - indeed I'm pretty sure it's a very bad idea. I wonder how many wallets will actually follow that recommendation (and despite the MUST in the text, it must be just a recommendation - there's no way anyone can force a wallet not to fully validate transactions).

Notwithstanding that odd comment, wallets have to change, to recognise the new opcodes as valid. I can only imagine that the intent is that in the event that the fork is called off at the last minute, wallets will continue to follow the chain - but frankly trying to introduce a distinction between wallet nodes and non-wallet nodes is crazy (IMHO).

EDIT: Reading @freetrader 's comment, I realise I know don't understand this at all. This is a change that only comes in in May 2019. How can the November 2018 fork document define a change that will happen in May 2019?

Nonetheless, I stand by my original statement: every coin that has regular scheduled hard forks (including BCH) requires wallets (and nodes) to regularly upgrade.

 

[cypherblock]

@Peter R didn't get the memo that the two main cases for CHECKDATASIG, oracle bets and cross chain atomic swaps, can be done with the current protocol with short scripts.

What is the problem with the existing cross chain swap techniques?

 

[Roy Badami]

I don't understand this disctinction between wallets and nodes - some wallets *are* nodes - and those that aren't *use* nodes. It makes no sense to me.

Can you point me to an explanation as to how this is supposed to work?