Pages:
Author

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

legendary
Activity: 2870
Merit: 7490
Crypto Swap Exchange
December 02, 2018, 12:07:00 PM
#28
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.

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

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

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.

And we will spend too much time
discussing the message itself.

--snip--

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

You're right Tongue
legendary
Activity: 2870
Merit: 7490
Crypto Swap Exchange
December 02, 2018, 11:16:58 AM
#26
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

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.

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

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 Huh
sr. member
Activity: 770
Merit: 305
December 02, 2018, 12:41:15 PM
#25
Looks like we have different opinion/view in this case.
My poor English! I wanted to say absolutely the same! I do not know why you think that our opinions are different  Grin
sr. member
Activity: 770
Merit: 305
December 02, 2018, 11:40:10 AM
#24
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 Huh

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.
legendary
Activity: 1456
Merit: 1176
Always remember the cause!
December 02, 2018, 10:50:29 AM
#23
take a course and read more about bitcoin
read more about Alister Maclin and you would get that he knows about bitcoin much more than been written in courses  Grin
Lol, you are outrailing your own topic  Tongue
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
sr. member
Activity: 770
Merit: 305
December 02, 2018, 09:09:36 AM
#22
take a course and read more about bitcoin
read more about Alister Maclin and you would get that he knows about bitcoin much more than been written in courses  Grin


legendary
Activity: 1456
Merit: 1176
Always remember the cause!
December 02, 2018, 09:05:30 AM
#21
Quote
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?  Grin
Is my English so bad?  Shocked
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. Cheesy

Quote
OK, I will do it myself for my local client.
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  Wink
sr. member
Activity: 770
Merit: 305
December 02, 2018, 08:42:50 AM
#20
Quote
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?  Grin
Is my English so bad?  Shocked

OK, I will do it myself for my local client.
legendary
Activity: 1456
Merit: 1176
Always remember the cause!
December 02, 2018, 08:34:11 AM
#19
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.
member
Activity: 364
Merit: 13
Killing Lightning Network with a 51% Ignore attack
December 02, 2018, 03:48:10 AM
#18
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

Quote
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://bitcointalksearch.org/user/gmaxwell-11425

Later,
ZZ
sr. member
Activity: 770
Merit: 305
December 02, 2018, 03:37:24 AM
#17
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.
member
Activity: 364
Merit: 13
Killing Lightning Network with a 51% Ignore attack
December 02, 2018, 03:30:36 AM
#16
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.



sr. member
Activity: 770
Merit: 305
December 02, 2018, 03:13:48 AM
#15
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.
member
Activity: 364
Merit: 13
Killing Lightning Network with a 51% Ignore attack
December 02, 2018, 03:00:31 AM
#14
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.

Quote
I think you missed my earlier point , not all reorgs will be a 51% attack.
I will be able to ignore "false positives" Smiley

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

sr. member
Activity: 770
Merit: 305
December 02, 2018, 02:53:55 AM
#13
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.

Quote
I think you missed my earlier point , not all reorgs will be a 51% attack.
I will be able to ignore "false positives" Smiley

Quote
And it is doubtful core will add that to the client as it will just frighten newbies ,
I suggest this optionaly.

Quote
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.
member
Activity: 364
Merit: 13
Killing Lightning Network with a 51% Ignore attack
December 02, 2018, 02:34:03 AM
#12
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.  Cheesy
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,  Smiley

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.


sr. member
Activity: 770
Merit: 305
December 02, 2018, 02:23:08 AM
#11
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.  Cheesy
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?

Quote
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
member
Activity: 364
Merit: 13
Killing Lightning Network with a 51% Ignore attack
December 02, 2018, 02:06:33 AM
#10
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?

 Cool

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.  Cheesy


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.
sr. member
Activity: 770
Merit: 305
December 02, 2018, 01:59:53 AM
#9
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
member
Activity: 364
Merit: 13
Killing Lightning Network with a 51% Ignore attack
December 02, 2018, 01:44:02 AM
#8
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.
Quote
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.  Smiley
The blocks with lower difficulty are just Orphaned.
https://en.bitcoin.it/wiki/Orphan_Block


Pages:
Jump to: