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.
