Gold collapsing. Bitcoin UP.

AdrianX

Well-Known Member
Aug 28, 2015
2,097
5,797
bitco.in
I agree but I find surprising that the whole market understand this. To me it should be a realization just for the happy fews for now.
I think a few players affect the market as a whole. This dog has a small brain and a massive tail. Lots of the volume is wash trading for a better word, traders stabilizing the market creating liquidity.

From what I've learned no commodity-like market has ever existed for a commodity with such an inelastic supply, we are in unprecedented territory. New coins flow in, and liquidity dries up very quickly as the market makers go into hodl mode. The same happens on the demand side.
 
  • Like
Reactions: Norway

cypherdoc

Well-Known Member
Aug 26, 2015
5,257
12,994
he's going to regret that. but par for the course from a lead dev who doesn't understand the incentive structure behind Bitcoin. when i first heard rumors of this, i honestly thought it was a joke, given everything i've already posted about checkpoints in BTC and it's history with Solidcoin. this is a great example of centralized decision making in ABC in a vain paranoid attempt to avoid reorg. ABC isn't Bitcoin with this.
 
Last edited:

cypherdoc

Well-Known Member
Aug 26, 2015
5,257
12,994
tbh, you could see this type of behavior in Amaury months ago.
[doublepost=1542769913,1542769277][/doublepost]https://bitcoin.stackexchange.com/questions/75733/why-does-bitcoin-no-longer-have-checkpoints/75735#75735

Proof of work (PoW)'s assumption is that the majority of the hashrate will cooperate and converge on a single chain, because it is most financially advantageous thing to do. When that is no longer the case, PoW is broken and we should just move to something else - not to try to fix it up.


You might think that adding checkpoints helps to improve this situation, but consider this:


  • Either the checkpoints are created for old blocks (weeks or months old), in which case there is clearly nothing being prevented. A week-deep reorganization would utterly destroy the currency and the trust in it, and not be prevented by this.
  • Or the checkpoints are created for recent blocks (days or hours perhaps), in which case they may indeed affect what chain is accepted on the network during certain circumstances, but at the same time it is effectively replacing PoW based consensus with "developers-decide" consensus... something that doesn't need a complex peer to peer protocol at all, as effectively developers need to run systems to keep the system in check.

So, either checkpoints have an effect - and change the security assumptions into an uninteresting one, or they don't - and they don't matter.


To answer your question: the primary reason for removing checkpoints is due to the confusion they create. They make people think they're part of the system's security model (like your question shows). It does not. It was introduced as a necessity for implementing an optimization (skipping script validation) and an unrelated denial-of-service attack (the disk of a new node being filled with low-difficulty blocks during synchronization). Since some changes in the P2P protocol (headers based synchronization) we no longer need checkpoints to do these things safely.
 

cypherdoc

Well-Known Member
Aug 26, 2015
5,257
12,994
we aren't the one's panicking. you and the ABC devs are; which is why you use tactics like this. looks like SV is the one playing 4D chess with a bunch of kids.
 

cypherdoc

Well-Known Member
Aug 26, 2015
5,257
12,994
try to use your head dude. rolling 10 block checkpoints? how'd Amaury even get it into the code? oh, he decreed it! and what of PoW? oh, it's not needed if you can create your own ledger! talk about moral hazard. as pwuille outllined:

The issue is that you assume a majority attack is an attack that can be prevented. It is not. It is a fundamental breakdown of the security assumptions.


Proof of work (PoW)'s assumption is that the majority of the hashrate will cooperate and converge on a single chain, because it is most financially advantageous thing to do. When that is no longer the case, PoW is broken and we should just move to something else - not to try to fix it up.


You might think that adding checkpoints helps to improve this situation, but consider this:


  • Either the checkpoints are created for old blocks (weeks or months old), in which case there is clearly nothing being prevented. A week-deep reorganization would utterly destroy the currency and the trust in it, and not be prevented by this.
  • Or the checkpoints are created for recent blocks (days or hours perhaps), in which case they may indeed affect what chain is accepted on the network during certain circumstances, but at the same time it is effectively replacing PoW based consensus with "developers-decide" consensus... something that doesn't need a complex peer to peer protocol at all, as effectively developers need to run systems to keep the system in check.

So, either checkpoints have an effect - and change the security assumptions into an uninteresting one, or they don't - and they don't matter.


To answer your question: the primary reason for removing checkpoints is due to the confusion they create. They make people think they're part of the system's security model (like your question shows). It does not. It was introduced as a necessity for implementing an optimization (skipping script validation) and an unrelated denial-of-service attack (the disk of a new node being filled with low-difficulty blocks during synchronization). Since some changes in the P2P protocol (headers based synchronization) we no longer need checkpoints to do these things safely.
 

Norway

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

I think @Peter R is assuming that a long reorg is done by a small fraction of the hashpower here. That doesn't make any sense to me.
 

cypherdoc

Well-Known Member
Aug 26, 2015
5,257
12,994
is CSW playing 4D chess? all his thunder and bluster about attacking ABC in various ways pre-fork. post-fork? absolutely nothing. just honest mining. meanwhile ABC is stumbling/tripping all over itself with blunder after blunder subverting several critical and historical Bitcoin concepts via centralized dictatorial dev decision making. it's going to be fatal. well played.
 
Nov 27, 2015
80
370
Would I be wrong thinking it's possible to send a sequence of headers demonstrating the potential for a re-org via private side channels as a credible threat?

"We dare you to add another checkpoint."
 

cypherdoc

Well-Known Member
Aug 26, 2015
5,257
12,994
no assistance needed. ABC is destroying itself.
 
  • Like
Reactions: sgbett and Norway

Zarathustra

Well-Known Member
Aug 28, 2015
1,439
3,797
I'm not. For once we could go as up as 64MB or even 128MB now w/o incurring in the problems SV is experiencing.
Yes, we should have set the default to 128MB. That was exactly @shadders point. Raise the limit before all implementations are ready. Force them to implement/copy the optimizations that make them ready.
Instead we followed the silly arguments of the ABC/BTC lords and shitlords.
 

cypherblock

Active Member
Nov 18, 2015
163
182
Doesn't that make the Selfish Mining algorithm (Eyal, Sirer) much more effective? In other words, if mining nodes use || validation, and they start mining on the first to validate block, and then they don't switch over to mining on the first seen block when it is done, then it increases the ability of a SM to win a block race.

@Peter R is this handled properly in the BU code? Switch over to first seen block when it is done validating? Thoughts?