Your/Luke's suggestion seems to be doable, but non-trivial. Just out of my head, I expect these changes:
Step 1: - Interrupt receiving of "getheaders" at fork_height, similar to how it should already be implemented when passing the fast-catchup threshold. - Interrupt receiving of "getblocks" at fork_height. - At both interrupts, the bloom filter would need to be reconfigured (cleared). - Interrupt again at fork_height+1 to restore the bloom filter. Step 2: Once that is done, implement rules so that fork_height is only accepted into the chain if it's a full block, plus the 1M/2M rule on top. It would be nice to have this implemented in a flexible way, so that in future we won't need bitcoinj updates for these types of fork. I think step 1 could be a list of block heights that are forced to download as full blocks only. Step 2 could be validation rules to plug in for full blocks, maybe even unified with full validation mode. One problem is that there is very limited time left. The remaining month is imho not enough for implementing, properly testing and release + rollout. Especially the testing might turn out difficult: as far as I know there is no precedent for users wanting to stay on the minority chain, so this case is likely not covered with unit tests as much as we'd like. Alternative, probably easier to implement ideas: - Banning of certain block hashes (blacklist) - Affinity to certain block hashes (whitelist) Both can only be applied after the fork, because the hashes are only known by then. And they would need to applied before the capacity of the block store prevents reorgs. Lastly, the "almost equal hashpower" threat it nowhere new; it's not specifically related to the upcoming 1M/2M fork. On 10/14/2017 03:42 PM, Manfred Karrer wrote: > The risk the users get exposed if following the longest PoW chain is not > acceptable at least in the case for Bisq (P2P exchange using 2of3 > MultiSig to secure the trade). > If both chains have similar hash power and miners switch between chains > the longest PoW would change, leading to massive reorgs/wipeouts of past > transactions (and would render a trade in Bisq insecure). > > Using custom nodes to connect to might be one option to stick to one > chain, but that would render the P2P architecture pointless and BitcinJ > would become a federated server model. > Luke Dash Jr. suggested [1] to use Block 494784 [2] to let the light > wallet distinguish on which chain it is. > > Any thoughts on that? > Anyone interested to implement that in BitcoinJ? > > What are the strategies others are planning to use? > > Which projects/wallets are actually using BitconJ? > > I am aware of: > - Andoid wallet (Schildbach wallet) > - MultiBit > - Mycelium > - Bisq > > Br, > Manfred > > > > [1] https://twitter.com/LukeDashjr/status/919053114912727040 > [2] https://segwit2x.github.io/segwit2x-announce.html > > -- > You received this message because you are subscribed to the Google > Groups "bitcoinj" group. > To unsubscribe from this group and stop receiving emails from it, send > an email to bitcoinj+unsubscr...@googlegroups.com > <mailto:bitcoinj+unsubscr...@googlegroups.com>. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "bitcoinj" group. To unsubscribe from this group and stop receiving emails from it, send an email to bitcoinj+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
