Am Montag, 16. Oktober 2017 09:55:39 UTC-5 schrieb Andreas Schildbach: > > 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. >
Yes agree, to keep that flexible will be good to protect for future hard fork attempts. Seems to be en vogue to use that strategy to give "free coins" to existing BTC users instead starting a new altcoin from scratch. Chain analysis companies will love those attempts when users are merging their coins to cash out some free altcoins and sacrifying their privacy. In fact they might sponsor or operate such forks to gain more analytic data. Would be reasonable at least from their perspective. > 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. > Yes that is unfortunate. > > > 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. Yes that sounds like an easier change. > And they would need to applied before the capacity of the > block store prevents reorgs. > I don't understand that. But thats probably some implementation detail. I am not very familiar with BitcoinJ internals... > > > Lastly, the "almost equal hashpower" threat it nowhere new; it's not > specifically related to the upcoming 1M/2M fork. > Yes then it is even more important to finally get an additional protection in cases where the "follow majority PoW chain" rule is vulnerable. I don't assume that B2X will get substantial hash power to become a real threat but we have to prepare for the worst case. I think it would be really good if BitcoinJ gets some proper protection mechanism against that attack scenario, even if it will not be ready for the November event. We might see more of such in future... Br, Manfred > > > 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+u...@googlegroups.com <javascript:> > > <mailto:bitcoinj+u...@googlegroups.com <javascript:>>. > > 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.
