To add custom nodes is part of the BitcoinJ API as far I know, at least in Bitsquare that is supported. Of course provided whitelist nodes are always problematic, best if the user runs his own nodes. But it the question of what hurst less if there is no perfect solution.
Am Mittwoch, 22. März 2017 09:34:34 UTC-5 schrieb Tobias B.: > > Still maybe it adding an API call to go into "whitelist mode" and then add > certain node ips would be a compromise. Software building on bitcoinj could > then offer the user to go into this mode and add certain ips there. > > On Wednesday, March 22, 2017 at 3:25:15 PM UTC+1, Tobias B. wrote: >> >> A whitelist of nodes for me sounds highly conflicting with the >> decentralized nature of bitcoin. Also what if nodes switch their software? >> Not that unlikely in case they notice that their minority chain is dying. >> >> On Wednesday, March 22, 2017 at 1:28:09 PM UTC+1, Jameson Lopp wrote: >>> >>> >>> >>> On Wed, Mar 22, 2017 at 1:55 AM, Manfred Karrer <[email protected]> >>> wrote: >>> >>>> A Bitcoin core node will not mine a transaction originated in a >1 MB >>>> block (not sure if it would relay it). BitcoinJ has no validation of that >>>> consensus rule, so it would accept a tx from a BTU block. I think with a >>>> whitelist to connect to BTC core nodes only (or better run your local >>>> node) >>>> you should be safe against receiving txs from a BTU block (> 1MB or built >>>> on top of a >1MB block). If BTC core does not check if a tx has inputs >>>> from >>>> a >1 MB block for replaying then we need to take extra care of 0 >>>> confirmation txs. >>>> Does anyone here know if that is the case? >>>> >>>> >>> If your software ignores all unconfirmed transactions then I could see a >>> slightly stronger argument for going the whitelist route. My point was that >>> unconfirmed transactions will get relayed around the network by nodes on >>> both chain forks. >>> >>> >>>> Yes I agree on the protocol level it will be hard as the nodes can >>>> easily lie. >>>> >>>> Sure wallet providers should not have to deal with it. But I don't see >>>> much alternative. As pure wallet it might be easier to tell the people >>>> just >>>> dont use yoru wallet for a few days/week. But for Bitsquare as an exchange >>>> that is not really an option, trading should not get stopped (and in case >>>> of Bitsquare cannot really). >>>> >>>> Maybe 2015 people have not been so nervous about it because it was >>>> before ETH demonstrated the risk and damage of a HF... >>>> >>>> Am Dienstag, 21. März 2017 21:42:07 UTC-5 schrieb Jameson Lopp: >>>>> >>>>> I don't think replay protection can be added at the network level. >>>>> Peers could lie about their software version and/or switch it, plus it's >>>>> highly likely that a chain split won't result in a clean network >>>>> partition. >>>>> Transactions will get relayed around the network comprised of nodes on >>>>> both >>>>> chains and you can expect that Core nodes would still relay transactions >>>>> to >>>>> you that were originally broadcast by Unlimited nodes and vice versa. >>>>> >>>>> At a more philosophical level, I'm not so sure that the onus is on >>>>> every wallet provider to implement protection against contentious hard >>>>> forks. You could have made similar arguments that BitcoinJ should have >>>>> added replay protection when support for 8MB blocks was nearing 50% >>>>> hashrate back in 2015. >>>>> >>>>> On Tue, Mar 21, 2017 at 8:28 PM, Manfred Karrer <[email protected]> >>>>> wrote: >>>>> >>>>>> 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 [email protected] >>>>>>>> > <mailto:[email protected]>. >>>>>>>> > 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. >>>>>> >>>>> >>>>> -- >>>> 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. >>>> >>> >>> -- 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.
