Btw. of course the whitelist can be set by the user himself, so if he runs a full node he can use that. But knowing that the majority of users are not running their own full node we need alternative solutions as well.
Am Dienstag, 21. März 2017 19:23:56 UTC-5 schrieb Manfred Karrer: > > Andreas, how are you planning to protect users of the Android wallet > agains replay attacks? > How does a user know if she/he can send his wallet coins to a peer who > accepts only BTC or BTU (e.g. exchange)? Otherwise he might end up pretty > frustrated to see outgoing transactions at this wallet but not confirmation > of receipt at the receiver. > > You cannot assume that all your users are blindly following the longest > PoW chain as the only valid BTC chain and ignore the replay attack risks. > There might be even legal issues connected to it (see ETH HF and losses > from replay attacks), probably less for a wallet provider than for a > centralized exchange holding customers funds. But I am not sure if that > would not fall back to others as well (due diligence), at least people > could try to sue... > > One of the easiest solution I see is to deploy a whitelist of Bitcoin > Core nodes and use those for the P2P network connections. > You can give the user the choice to select between whitelist Bitcoin > Core nodes (if he wants BTC), whitelist BU nodes (i he wants BTU) or public > network (if he thinks all plays out by itself and is aware of the included > risk/mess). > Of course a whitelist is not great as well but that would solve the > problem that we cannot know in advance the data which helps us to > distinguish between the chains (like blockID or certain transactions). That > whitelist only need to be used as long the HF is messy, once things have > settled it can be removed or replaced by other distinguishing data sources > like blockIds. > > If BTU implements a clean mechanism to make it easy to distinguish that > would be the best solution of course but I am not aware of any concrete > plans for such. > > > Am Mittwoch, 15. März 2017 06:08:55 UTC-5 schrieb Andreas Schildbach: >> >> As long as a fork does not change the proof of work rules, bitcoinj >> makes no assumptions about forks. It will always select the chain with >> the most work. >> >> What do you mean by "requesting an UTXO" and what do you want to achieve >> by that? >> >> >> On 03/14/2017 06:07 PM, Manfred Karrer wrote: >> > If there would happen really a BU fork SPV wallets could get a >> > connection to a majority of BU nodes and so a different view to the >> network. >> > Any plans or ideas how to deal with that? >> > >> > One idea would be to use a UTXO which is known to exist on only 1 chain >> > request that and use that as a check to see which chain the node is >> > operated on. >> > If it is not the chain the wallet supports the node gets disconnected. >> > >> > Br, >> > Manfred >> > >> > -- >> > 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 >> > <mailto:bitcoinj+u...@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.
