I think they will. Except maybe those who are not maintained any more, but they will fade away like their predecessors¹.
¹ e.g. https://github.com/barmstrong/bitcoin-android On 03/24/2017 04:55 PM, Tobias B. wrote: > I totally agree that wallets should warn their users. > > On Friday, March 24, 2017 at 4:50:35 PM UTC+1, Matt Corallo wrote: > > I'm not claiming it's an attack or not. Simply, technically, the > blocks generated are invalid according to the consensus rules > enforced by the vast majority of those accepting Bitcoin for goods > and fiat. Bitcoin was designed to ignore any changes to consensus > rules unless everyone goes along with them. Because of the > reduced-SPV model that some clients (especially those built on > bitcoinj) use, this kind of change has massive ability to negatively > impact users. Whether you agree with Bitcoin Unlimited and plan to > switch to it or not, you cannot deny that wallets which do not at > least warn their users, notifying them of which coin they will be > using, are putting their users at significant risk. > > On March 24, 2017 8:38:12 AM PDT, "Tobias B." <[email protected]> > wrote: > > I guess when you interpret a majority of miners running BU as an > attack on the network then you can read that from the paper. I'd > define an attack as someone spending money on mining to steal > funds, double spend or harm the bitcoin network on purpose. I > think here miners just disagree with Bitcoin Core on how to grow > the bitcoin ecosystem. > > On Friday, March 24, 2017 at 3:44:27 PM UTC+1, Matt Corallo wrote: > > If you really want to get political, Satoshi never > envisioned SPV the way it's implemented today. Satoshi > described SPV repeatedly as clients which accept fraud > proofs allowing them to, just like full nodes, reject any > invalid chain. Bitcoin was never designed to follow an > invalid chain, regardless of it's hashpower. The reason this > doesn't exist is Bitcoin is not currently set up to allow > for efficient/small fraud proofs, and getting it right is > super, super hard. > > On March 24, 2017 2:28:15 AM PDT, "Tobias B." > <[email protected]> wrote: > > Maybe this is so messy because bitcoin was simply never > intended to follow a minority chain. Maybe the > assumption was that it is more reliable to measure > support from economically incentivized miners than > economically incentivized developers. > Maybe we shouldn't try to keep a minority chain alive in > the first place and if it wan'ts to stay alive it has to > change it's PoW and become an altcoin with the coin > distribution starting from where bitcoin is at that > point in time. But maybe I'm too political here. You > just want to protect users, that's fine. But whatever > change Bitcoinj implements, users who do not update > their software will be in danger when there are two > bitcoin chains that're using the same PoW. For me that's > an argument to not support that scenario. If core really > wants to ignore a majority decision of 80% of the miners > then I think they're obligated to change the PoW to > prevent this mess. > > On Friday, March 24, 2017 at 12:34:45 AM UTC+1, Manfred > Karrer wrote: > > No I don't bet on it, just wanted to mention that it > is a (very) possible further escalation scenario. If > the minority chain gets attacked it seems to me also > the most likely survival tactic. But I would not > count on that of course. > > So far I still have no satisfying solution how to > deal with a HF in Bitsquare. > Stopping the trading is hard in Bitsquare as it is > decentralized. > Preventing users to use the wallet and become victim > of unintended replays is impossible. > Whitelist for BTC chain nodes helps only for > confirmed txs but not unconfirmed. That would not > risk loss of funds but the usability in the trade > would get screwed. > > So lets hope that BU does not escalate and we can > spend time on more productive stuff. > But at the end it demonstrates a very serious > vulnerability with SPV mode. > I hope the work on Bitcoin Core SPV will become a > viable alternative soon. I consider midterm to move > over to that model in Bitsquare. That would solve > the privacy issues with bloom filters as well. > > > Am Donnerstag, 23. März 2017 10:46:51 UTC-5 schrieb > Matt Corallo: > > I'm not sure you can bet on BTC having a PoW > change, let alone make that bet and risk users > getting completely screwed if it doesn't happen. > > On March 23, 2017 2:35:02 AM PDT, "Tobias B." > <[email protected]> wrote: > > 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 > > <[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 > <https://groups.google.com/d/optout> > > > <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 > > > [email protected]. > > For more > options, visit > > > https://groups.google.com/d/optout > <https://groups.google.com/d/optout> > > > <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 [email protected]. > > For more options, > visit > https://groups.google.com/d/optout > <https://groups.google.com/d/optout> > > > <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 > [email protected] > > > <mailto:[email protected]>. > > > 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 [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.
