Timeline for How can a DApp detect a fork or chain reorganization using web3.js or additional libraries?
Current License: CC BY-SA 3.0
5 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Oct 8, 2020 at 18:35 | comment | added | Dylan Kerler | What exactly does this mean? Say a there are 12 honest blocks but a malicious node mines 24 empty blocks secretly then publishes them at once and causes a 12 block fork - How will the transactions in the now 12 missing blocks be "replayed"? Do you mean to say that all of those transactions will be included within the next 12 blocks? | |
| Apr 8, 2016 at 19:04 | comment | added | Paul S | (and do the same thing with several different nodes of different implementations) | |
| Apr 8, 2016 at 17:11 | comment | added | Paul S | This assumes you trust your node local node. I think you should assume that nodes will get hacked. So in the end I think we need a more bitcoin-wallet style solution that you e.g. wait 16 blocks to be mined and verify the transaction hash is still good. | |
| Feb 9, 2016 at 8:38 | comment | added | eth♦ | Helpful answer that I've upvoted. I've heard of the replay & it would be helpful to see solutions that are available pre-Mist, as well as the Mist recommendation and usage of its APIs/events for dealing with it, since it appears Mist should at least provide events to the DApp that there was: 1) a reorg 2) the tx replay was successful (maybe replay may also fail for some reason). A DApp should still be aware of these events even if it silently does not show the user any changes (while it hopes for the replay to succeed). | |
| Feb 9, 2016 at 7:54 | history | answered | Maran | CC BY-SA 3.0 |