Gold collapsing. Bitcoin UP.

theZerg

Moderator
Staff member
Aug 28, 2015
1,012
2,327
Everybody bashes Greg Maxwell for misunderstanding in economics, but check this statement out which is right in his "core competency", his bread and butter if you will, crypto and computer science:


He's putting the cart before the horse... if you must send N pieces of unrelated data then from a theoretical standpoint that takes more information then sending N-M pieces (where 0 < M < N of course). I think that is the "theoretical perspective" he is arguing from.

However, this is not the situation here. The information he wants removed is not pieces of unrelated data but information on how the bytes in the data stream are related. If we can remove that data, then the predictability of the data stream is reduced. This must necessarily result in a larger minimum data size.

Think about it from an information compression perspective. If you have a white image it can be compressed into a very small file because there is a simple relationship between all the data (every pixel is the same as the first one). Images of trees, people, etc still are compressible, but less then that of a white image, based on how predictable their content is. However, if you have an image of random colors it cannot be compressed at all -- the data stream size cannot be reduced.

Now let's create a reversible mathematical function that transforms the white image (or any image) into pseudo-random colors. If I do that, the relationship between all the pixels will be obfuscated, and the resulting image file will be incompressible -- that is, larger than the original. The same should be true for Bitcoin transaction streams. Any function that transforms the data in such a way as to obfuscate its inter-relationships must necessarily be less compressible than the original data.

I mean its basic cryptography. If I encrypt the message "11111111111111111111111111111" (obfuscating the message), I'll get an incompressible random-looking result. One of the most basic and effective approaches in cryptanalysis is to analyse the data stream and find out how it is not random. The original Enigma cypher had a fatal flaw which is that it never allowed a letter to be encrypted into itself. This tiny piece of predictability was used to crack it (along with other data). Anyway I digress, this obfuscation is why Bitcoin transactions and block don't compress well.


Anyway, I'm posting here not there because I don't have time for a pissing contest... and instructing the opposition is rarely valuable :) unless you think it will change their minds about the point under contention.
 
Last edited:

Zarathustra

Well-Known Member
Aug 28, 2015
1,439
3,797
Are you guys beginning to get it now? Do you see why strong consensus is required? Do you see why strong consensus only applies to such a tiny set of possible changes? Do you see why it is based on maths/game theory rather than stupid irrational ideology?
No, we are not beginning to get your perverted strong consensus bullshit. The hardest of all possible forks is already happening, slowly but steadily into the altcoins, because more and more libertarians and cypherpunks don't want to stay in an environment that is dominated by totalitarian psychopaths and those who support that disgusting behavior.

https://www.reddit.com/r/btc/comments/4v4mjl/how_have_censorship_problems_affected_you_in/
 

jonny1000

Active Member
Nov 11, 2015
380
101
Jonathan Vaage said:
Why spend all this time arguing for extreme consensus if your criticism really boiled down to a missing software feature?
I am arguing for strong consensus to a tiny narrow subset of changes to the system (e.g. Bitcoin Classic). Then somebody on this forum replies with a comment about how stupid "extreme consensus" is for changes, then I reply again and again, being as clear as I can that it only applies to a tiny narrow subset of changes. I then explain with reasons why its a narrow subset. But this gets ignored again and again, and my apparent stupid irrational ideological desire from "extreme" consensus is attacked. People even ask why is RBF ok without consensus again and again...

So to repeat again:
  • Hardforks like Classic require strong consensus across the entire community or they will lose
  • Softforks like Segregated witness require Nakamoto consensus
  • RBF requires no kind of consensus at all, nor is it relevant to talk about consensus for RBF
@Jonathan Vaage
The facts are clear, if you get rid of the massive powerful status quo advantage that Core has, which I keep explaining, then you no longer require "perverted strong consensus bullshit" to beat it.
 
Last edited:

Tomothy

Active Member
Mar 14, 2016
130
317
I am arguing for strong consensus to a tiny narrow subset of changes to the system (e.g. Bitcoin Classic). Then somebody on this forum replies with a comment about how stupid "extreme consensus" is for changes, then I reply again and again, being as clear as I can that it only applies to a tiny narrow subset of changes. I then explain with reasons why its a narrow subset. But this gets ignored again and again, and my apparent stupid irrational ideological desire from "extreme" consensus is attacked. People even ask why is RBF ok without consensus again and again...

So to repeat again:
  • Hardforks like Classic require strong consensus across the entire community or they will lose
  • Softforks like Segregated witness require Nakamoto consensus
  • RBF requires no kind of consensus at all, nor is it relevant to talk about consensus for RBF
@Jonathan Vaage
The facts are clear, if you get rid of the massive powerful status quo advantage that Core has, which I keep explaining, then you no longer require "perverted strong consensus bullshit" to beat it.

I'm sorry, but your argument is nonsensical. Of course you can hardfork bitcoin so that you have one chain with 1mb and one chain of 2mb. They would be separate chains; it's not like they're going to magically combine to form a 3mb chain. This can be done with code. In a similar fashion, if adopted, the 1mb chain could also change from Sha256 to something else. The only thing immutable about bitcoin is the ledger, everything else is changeable yet subject to entropy. In such a situation, nodes would need to determine what chain they're going to support along with what users, wallets, and exchanges would support. Ultimately you would be left with two forms of BTC with an Eth chain and an Etc chain. This would be an irrevocable split and transactions would not be identifiable between the two chains. You might not want this to happen and this might not be viewed as good for the community, but that doesn't mean it can't occur. Maybe it should occur.
 

Justus Ranvier

Active Member
Aug 28, 2015
875
3,746
What debunking?
  • Blocks produced as part of a hard fork are invalid from the point of view of nodes whose operators have not chosen to switch to software that recognizes the new rules.
  • Bitcoin nodes have no difficulty whatsoever rejecting invalid blocks, and so are not affected by the emergence of a hard fork.
  • Since a hard fork only affects the people who choose to use it, they can't be dangerous.

    Any definition of harm you try to formulate which would act as a counterexample to the above is going to invoke the claim that you have the right to dictate which currencies other people are allowed to hold and/or dictate what people who own hashing hardware are allowed to do with it.
 

jonny1000

Active Member
Nov 11, 2015
380
101
Tomothy said:
I'm sorry, but your argument is nonsensical. Of course you can hardfork bitcoin so that you have one chain with 1mb and one chain of 2mb. They would be separate chains; it's not like they're going to magically combine to form a 3mb chain.
If the 1MB chain got the lead, at any point ever, the 2MB chain would cease to exist and disappear. Investors would then lose their funds. Therefore, if there was not "perverted strong consensus bullshit" in the first place:
  • 2MB chain miners would worry about being unlucky and losing their lead, then the 2MB would vanish, therefore due to this fear they would not mine on the 2MB chain
  • 2MB chain investors would worry that if the 1MB chain had a higher price at any moment, the miners would switch to the 1MB chain, then the 2MB coins would vanish, therefore due to this fear they would not invest in the 2MB chain
This is of course not like the Eth chain and an Etc chain, as if ETC becomes the most work chain, ETH clients will still ignore it.

I know the above is not consistent with what you want to be true or how you think miners should act, but that is exactly how Classic nodes behave and exactly why the Classic hardfork requires "perverted strong consensus bullshit" in order to succeed.
 
Nov 27, 2015
80
370
@jonny1000:

Answer this simple question directly:

Would extreme consensus still be required if the hard-forking clients included a software feature that ignores all chains that do not include blocks over 1 MB if and only if the client detects a valid chain that include any blocks over 1 MB.

If so, explain why this feature doesn't eliminate the "asymmetric" advantage a status quo chain has. I will argue that it does.
 

jonny1000

Active Member
Nov 11, 2015
380
101
Jonathan Vaage said:
Would extreme consensus still be required if the hard-forking clients included a software feature that ignores all chains that do not include blocks over 1 MB if and only if the client detects a valid chain that includes blocks over 1 MB.
Extreme consensus is never required, I use the term strong consensus.

I consider the example you cite as being outside of the scope of consensus systems. If you have a rule where clients jump from a less than 1MB chain to a more the 1MB chain, just because they hear about it, even if it has much less work, that is not a longest valid chain proof of work consensus system. This also opens the nodes up to double spend attacks. Just one greater than 1MB block can undo 100,000 confirmations and years of history. This sounds like the BU idea. This will fail whether there is strong consensus or not, in my view. Please think carefully about suggesting ideas where the users funds can just disappear.

If you asked the alternative question:

Would [strong] consensus still be required if the hard-forking clients included a software feature that ignores all chains that do not include [at least one] block over 1 MB?

Then I would say no, the chain could survive without strong consensus.
 
Last edited:

albin

Active Member
Nov 8, 2015
931
4,008
I am beginning to think that our very own resident troll is starting to feel emboldened (by cypherdoc's hiss-fit?) .... what with the increasingly strong language (by his own appeal to the lurkers' tact). That, or being the end of July this is a desperate last throw of the dice.
He argues like several of my ex-girlfriends. Incredible preoccupation with semantics and how things are being said instead of directly addressing substance, and extreme micromanagement of every aspect of how you react to what he's saying. This is not how anyone actually confident in their position argues.
 

Tomothy

Active Member
Mar 14, 2016
130
317
What does longest chain matter when you have two separate chains that have, in essence, become two separate and distinct coins. Now you have BTC 1mb coin and BTC 2mb coin and adoptions will determine which of these holds what value and is an altcoin. This is an irrevocable fork.
 

Justus Ranvier

Active Member
Aug 28, 2015
875
3,746
@Tomothy It is true that there is some asymmetry to a block size limit hard fork because the small blocks are still valid large blocks.

If the small block fork produces more proof of work than the large block fork, then all clients will follow the fork, even the large block clients.

This means the the large block fork can't happen with out a bare majority of the hashing power, and the closer to at 50/50 split there is when the first >1 MB blockfork is mined the more short-term turbulence will be experienced.
 

Justus Ranvier

Active Member
Aug 28, 2015
875
3,746
The practical implication is that the separation between the two chains isn't really finished until the large block chain has a sufficient lead in terms of blocks to make a reorg extremely unlikely.

100 blocks is a good number to choose (coin maturation time), and you can calculate for yourselves how likely it is for a 25%/75% split to result in the 25% miners getting 100 blocks in a row.
[doublepost=1469808743][/doublepost]@Jonathan Vaage That modification is entirely unnecessary for clients, assuming a majority of hash power behind the fork.

Only the miners would need to do so, and only temporarily until they establish a sufficient lead over the minority chain.
 

Tomothy

Active Member
Mar 14, 2016
130
317
Justus - Absent the LUTHER schism, wouldn't there always be the potential, as insisted upon by Johnny, that the minority chain could somehow catch up to and overtake the minority chain? Hence the need for the Luther chain...
 

Justus Ranvier

Active Member
Aug 28, 2015
875
3,746
@Tomothy You can calculate those odds yourself. How likely is it for a 25% miner to get 100 blocks in a row?

I would say that anybody who doesn't think the majority chain will always retain >50% of the hashing power shouldn't use it.

If you do think that the majority of the mining power will always be in favour of >1 MB blocks then there's really nothing to worry about.