Topic: Warning about block reorg? (Read 466 times)

I also don't like hard-coded/non-modifiable configuration, but we could use 3 (or higher) blocks as default value


Looks like we have different opinion/view in this case. IMO show no warning by default, but also can be enabled & configured from bitcoin-qt (GUI version) would be better.


You're right

For advance users, that's good idea (even though they would check news almost everyday). Maybe such option could be enabled/disabled for bitcoin-qt (GUI version) setting.


Obviously they won't be confused if they don't know something may be on-going, i thought we're talking about showing message/information/warning to all users

My poor English! I wanted to say absolutely the same! I do not know why you think that our opinions are different 

My first idea was that client (bitcoin-qt) should display this message immediately in case of
blockchain has been reorganized. But I do not like hardcoded voluntary assigned constants,
for example, 3 blocks for mainnet and 20 blocks for testnet. And we will spend too much time
discussing the message itself.

So, it would be better to configure this behaviour in command-line arguments or bincoin.conf
file and show no warning by default.

It would be much better if somebody with good English skills suggest this proposal to core developers.

Lol, you are outrailing your own topic 
He knows shit, transaction malleability is not the discovery of the century, bitcoin is more complicated than what junior hackers would imagine. Also by taking a course I meant an English course that might help reading more viable resources than yellow pages in social media.  cheers

read more about Alister Maclin and you would get that he knows about bitcoin much more than been written in courses  

Obviously the problem is bigger than just your English, or,  may be it is ... take a course and read more about bitcoin to understand how different nodes with different parameters diverge and do not agree on the same chain. Lesson 1: when nodes do not agree on the same chain, it is called chain split, in English.

your node will become isolated and worth shit in case of a re-write. Without such an event you have done nothing! bitcoin is not a joke or a toy, be more humble 

HAHAHAHAHAHA
This is only a warning message on the screen. How can it escalates anything? 
Is my English so bad? 

OK, I will do it myself for my local client.

OP!
Forget about this proposal, my advice.

Bitcoin doesn't support finality. It is what you want and a feature that bitcoin is known for NOT supporting it.  Your proposal about making it a command line option is void and dangerous and escalates network splits in legit chain re-write situations, like when a selfish miner with large hashpower exploits his longer chain temporarily but losses eventually after miners shuffle the lines by choosing faithfull pool operators that are resisting the attacker.

I think, proposing finality as a feature is not an action of good faith as it seems to be a backdoor to centralization especially when considering that it is mostly advocated by trojans in cryptocurrency ecosystem, people like Ethereum's Butterin.

https://bitcoin.org/en/development#code-review


I say PM gmaxwell : https://bitcointalksearch.org/user/gmaxwell-11425

Later,
ZZ

Fuck. My English is poor, seems to me that you do not understand me at all.
I do not speculate about prices, exchanges, victims, miners, attackers and so on.

I want to have an option in my program. Point.
I also do not want to code it myself. I can do it, but I am lazy.
I think that not only me will switch this option on. Let us talk - how
would it better to implement it and should we ask developers (pull request)
to make the changes in next release.

True , but most victims are discovered by the funds being missing in the exchange, usually after some complaints.
Many times in other coins that were double spend on, it was hours to weeks before they discovered the double spend.
In some cases the exchanges were hit with multiple double spends (days apart) before they noticed it.
I am unaware of any automated system that does the above in real time.

If there was an automated way to determine a 51% attack from a normal reorg,
I would think the exchanges would be implementing it as they are the main targets of 51% attacks,
but as many 51% attack that hit exchanges in other Coins , it is doubtful they can tell the difference until someone complains.

If there is a victim of it - the reorganization is attack. Point.
I also do not want to talk about terminology. I just propose an option, improvement.
Right now we just talking about do we need this functionality in reference client
If yes - then how to implement this better and simply.

Fair enough, then you need to devise a way to determine a normal reorganize from a 51% attack.
Hopefully someone has some insight on that to help you.

Later,
ZZ

And I want to been notified this second. Point.

I will be able to ignore "false positives"

I suggest this optionaly.

I do not want to speculate about economical reasons here and with anyone. This is technical question.

Up to you where you place the code,  


Because if your Local Node is on an orphan chain, your Local Node does not know it, until the Reorganize Happens.
The only way to know early is to compare your node blocks, with a block explorer, that way you know in ~real time.



I think you missed my earlier point , not all reorgs will be a 51% attack.
And it is doubtful core will add that to the client as it will just frighten newbies ,
that don't know the difference between a normal reorg which is no big deal from a 51% attack which is.

Chinese Miners have had the capability to 51% attack bitcoin for ~3 years now.
They don't do it for a very simple reason, it would make their bitcoins and millions dollars of investment into mining worthless overnight.
Oddly enough your bitcoins are safe from 51% attack because of the collusion of the Chinese mining majority which is over 51%.
BTC lost decentralization, but centralization collusion by the Chinese is protecting it from 51% attacks at the current time.


FYI: Other PoW Coins
51% Attack Double Spends normally target Exchanges
51% Attack blocking only new transactions from being entered into the blockchain ignore old transaction that already occurred.
Any successful 51% Attack wiping out a large part of the blockchain can be overturned ,(if the developers) release an updated program checkpoint and resyncing the blockchain up until the point where it was attacked.
The Danger is anything after the checkpoint is still fair game for a new attack and the damage to the public image of the coin.

Why not to have this code in client?
I can implement changes in my sources (forked from master), but I am not too familar
with code to make this task perfect. Anyway, why not to talk about these changes in
this forum? I think this topic matches the "Development & Technical Discussion"

Why on Earth should I use block-explorers if I have the full node?

Very easy question.
I want to be notified ASAP in case of attack-51

Open debug log and it show a history , you can search.

Any warning you build only monitoring your local node, will not know it is on an orphan chain , until it reorgs.

So exactly why do you think you need to monitor it 24x7 anyway?  Hmm?

 

FYI:
If you are a decent programmer,
write a separate program to monitor the debug log for the word reorganize at a specified time interval ,
and have it pop up an alert or email or call you on the fucking telephone if that is your goal.  


FYI2:
Only Way To know if you are on an orphan chain ,
you have to create a program that monitor multiple block explorers and constantly compares it to your node's blocks ,
and if the blocks don't match, you are running on an orphan chain.

Are you crazy? I do not spend my time watching log file 24/7

All you have to do is Monitor your Debug Log, and it reports any reorgs, even shows which blocks were reorg.

A reorg is not necessary a 51% attack. It is just your client just noticed a longer chain of blocks with a higher difficulty and switched to it.

Most reorgs are limited to a small group that for some reason just did not see the longer chain with higher difficulty,
maybe some segmentation on the internet.

Once a reorg occurs , your client automatically resend any coins , that were originally sent on the short fork,
it is only if you had blocked it from sending will a double spend occur and only if the person you were sending too, was also on the short fork at the same time.
Odds are they were not, so a double spend could not happen during normal reorgs, as most people are totally unaware of them until they are over.

51% attack is the miners rewriting the blockchain for all nodes,
most reorgs are limited to very few nodes at one time for a very brief time period.  
The blocks with lower difficulty are just Orphaned.
https://en.bitcoin.it/wiki/Orphan_Block