Warning about block reorg?

[amaclin1]

Is there a warning in case of successful attack-51 block reorganization in Bitcoin Core?

[aliashraf]

No, there is not such thing.

[bones261]

This is not standard for the Bitcoin core implementation. You will probably have to find a program that monitors the blockchain and warns you if a reorg takes place. I believe several exchanges implement such warning systems in order to mitigate the damage already done by a double spend attack.

[amaclin1]

This is not standard for the Bitcoin core implementation.

I can write such program myself.
But why not to have a warning message in reference client?
I think such feature would be useful... Hmm.. would be interesting?
No. Pleasant? Doubt. My English is poor. I can not properly define my feelings.

Do you think we need such warning in reference client? I vote for it.

[bones261]

Do you think we need such warning in reference client? I vote for it.

If we can think message which won't confuse user or make user panic, then i don't have reason to disagree.
Otherwise, such warning should only be shown for bitcoin-cli users or on debug window.

Additionally, re-org doesn't mean 51% attack is happening. There's chance it's done intentionally for good non-hostile due to accidental hard-fork (just like after qt 0.8 release in 2013) or some nodes mines/runs on invalid blocks (such as overflow bug in 2010).

Well, it could clue someone in that something may be going on. Even if the reorg is benign, the node user may discover sooner that they should update their software. Plus, since it just your software indicating a reorg took place, it cannot be as open to attack like the alert system was.

[amaclin1]

If we can think message which won't confuse user or make user panic,

It will be too late for panic
And of course it will confuse 99% users
But I think that we should have it in client.

[amaclin1]

You're right, but we should find correct message which don't confuse user. For example,

What if we just pass optional command-line argument(s) / conf-file parameter(s) to a client?
Something like (this is just example)

Code:

-reorgwarnblocks=3                  # how many blocks have been reorganized         
-reorgmessage="Alert. Reorg!"       # for me it will be more than enough
-reorgcommand=somethng.sh           # command to run in case of

Most of users with default parameters (no warning and actions by default) will not be confused at all.

[Zin-Zang]

Is there a warning in case of successful attack-51 block reorganization in Bitcoin Core?

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

REORGANIZE
REORGANIZE: Disconnect 1 blocks; abbf58ed9574e5c686fe..80fcae8fac3d8df7280f
REORGANIZE: Connect 2 blocks; abbf58ed9574e5c686fe..d3912153810ff7b496c2
REORGANIZE: done

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

[amaclin1]

all you have to do is Monitor your Debug Log, and it reports any reorgs,

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

[Zin-Zang]

all you have to do is Monitor your Debug Log, and it reports any reorgs,

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

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.

[amaclin1]

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.  

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"

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 running on an orphan chain.

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

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

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

[Zin-Zang]

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.  

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"

Up to you where you place the code,  

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 running on an orphan chain.

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

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.

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

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

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.

[amaclin1]

Because if your Local Node is on an orphan chain, your Local Node does not know it, until the Reorganize Happens.

And I want to been notified this second. Point.

I think you missed my earlier point , not all reorgs will be a 51% attack.

I will be able to ignore "false positives"

And it is doubtful core will add that to the client as it will just frighten newbies ,

I suggest this optionaly.

They don't do it for a very simple reason, it would make their bitcoins and millions dollars of investment into mining worthless overnight.

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

[Zin-Zang]

Because if your Local Node is on an orphan chain, your Local Node does not know it, until the Reorganize Happens.

And I want to been notified this second. Point.

I think you missed my earlier point , not all reorgs will be a 51% attack.

I will be able to ignore "false positives"

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

[amaclin1]

Fair enough, then you need to devise a way to determine a normal reorganize from a 51% attack.

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.

[Zin-Zang]

Fair enough, then you need to devise a way to determine a normal reorganize from a 51% attack.

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.

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.

[amaclin1]

I am unaware of an automated system that does the above in real time.

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.

[Zin-Zang]

I am unaware of an automated system that does the above in real time.

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.

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

Development discussion takes place on GitHub and the bitcoin-dev mailing list.
Less formal development discussion happens on irc.freenode.net #bitcoin-core-dev (web interface, logs).

I say PM gmaxwell : https://bitcointalk.org/index.php?action=profile;u=11425

Later,
ZZ

[aliashraf]

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.

[amaclin1]

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.

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.