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." <brand...@gmail.com > <javascript:>> 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." <brand...@gmail.com> >>> 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." <brand...@gmail.com> >>>>>> 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 >>>>>>>>> > <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.
