So as the minority (core) chain is likely to make a PoW change, wouldn't this break SPV clients? I hope in such a case this chain would also add replay protection - people would have to install new clients anyway.
On Wednesday, March 22, 2017 at 10:14:39 PM UTC+1, Manfred Karrer wrote: > > When you talk about minority chain we should take in consideration that > this might change over time. So todays winning chain might be the loser of > tomorrow and so on. Might be pretty messy with re-orgs and double spends... > Also I would not count with what some people expect that the minority > chain will quickly die (or get killed). The ETH devs made that mistake and > underestimated ETC a lot. Mining resources and price are highly dynamic > factors making predictions much harder. Not to talk about the emotional and > political factors... > Also a PoW change is a very likely element in such a scenario... > > > Am Mittwoch, 22. März 2017 11:18:23 UTC-5 schrieb Andreas Schildbach: >> >> Maybe the recommendation should be: if you want to follow a minority >> chain, use the Peer API to connect to a trusted peer under your control. >> You can then run your desired full node implemention on the trusted peer >> and bitcoinj will follow. If the network between bitcoinj and the >> trusted peer is not to be trusted, use a VPN to secure that connection >> (the Bitcoin protocol itself lacks authentication). >> >> That would be far more reliable than a version string whitelist. In >> fact, frontending bitcoinj with bitcoind has always been a >> recommendation for centralized/web services, so if they followed that >> recommendation they should not have to change anything. >> >> >> On 03/22/2017 03:34 PM, Tobias B. wrote: >> > 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 >> > <manfred...@gmail.com> 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 >> > <manfred...@gmail.com> 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 >> bitcoinj+u...@googlegroups.com >> > > <mailto:bitcoinj+u...@googlegroups.com>. >> > > For more options, visit >> > https://groups.google.com/d/optout >> > <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+u...@googlegroups.com. >> > For more options, visit >> > https://groups.google.com/d/optout >> > <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+u...@googlegroups.com. >> > For more options, visit https://groups.google.com/d/optout >> > <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+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.
