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." <brandt....@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. -- 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.
