I agree that BIP148 is high risk and I also don't find it a good strategy, though support the basic motivation behind it.
Am Dienstag, 30. Mai 2017 19:19:10 UTC+2 schrieb Andreas Schildbach: > > Currently bitcoinj doesn't support BIP9, which of course is something we > should implement. > > On top of that (as separate PRs) we could support signalling/activation > for several BIPs (e.g. Segwit), similar to how the old signalling via > block versions is supported today. > > (Side note: I personally think UASF is a bad idea due to the risks > involved, but since the users of bitcoinj are devs who should know what > they're doing I would not object to optional BIP148 support.) > > > On 05/29/2017 01:34 PM, Manfred Karrer wrote: > > Similar to the BU fork risk scenario we will get troubles in Bitsquare > > if we mix connections to UASF nodes and non-UASF nodes. > > I am wondering what is the best way how to deal with it. > > One user at Reddit responded: > > "SPV wallets check block headers, which is enough to enforce BIP148 > > (i.e. rejecting non-segwit signalling block headers)." > > > https://www.reddit.com/r/Bitcoin/comments/6dxo7h/electrum_and_mycelium_now_publicly_support_uasf/di6h39y/?context=3 > > > > > Can anyone familiar with the BitcoinJ code confirm that? > > > > -- > > 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 [email protected] <javascript:> > > <mailto:[email protected] <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 [email protected]. For more options, visit https://groups.google.com/d/optout.
