Gold collapsing. Bitcoin UP.

cypherdoc

Well-Known Member
Aug 26, 2015
5,257
12,994
I just love all the spam that clutters this thread.
 
  • Like
Reactions: lunar

cypherdoc

Well-Known Member
Aug 26, 2015
5,257
12,994
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

Well-Known Member
Aug 26, 2015
5,257
12,994

cypherdoc

Well-Known Member
Aug 26, 2015
5,257
12,994
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

Active Member
Dec 27, 2015
140
203
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

Active Member
Mar 14, 2016
362
1,172
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

Active Member
Dec 27, 2015
140
203
Wallets have to upgrade every time BCH hard forks. This is no different from any other coin that performs regular hard fork upgrades.
 

freetrader

Moderator
Staff member
Dec 16, 2015
2,806
6,088
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

Active Member
Aug 28, 2015
144
775
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.
 
Last edited:

kyuupichan

Member
Oct 3, 2015
95
348
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

Well-Known Member
Sep 29, 2015
2,424
6,410

@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.
 
  • Like
Reactions: bitsko

Roy Badami

Active Member
Dec 27, 2015
140
203
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.
 
Last edited:

Roy Badami

Active Member
Dec 27, 2015
140
203
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?
 
  • Like
Reactions: Dusty and cypherdoc