Beside that Satoshi designed mining as vote per CPU and underestimated the issues with centralization in that area. What we have now is a monopoly (Bitmain) on mining hardware and the ability to apply that power for political reasons. If they do that or not is not relevant, just that they could do it is a problem. Miners today has monopolistic cartel structure not much different to classical one like the OPEC or Telkoms. So the original design got lost quite a lot in that area. Which for me personally is a signal that we should try to fix that as long it is not too late by changing PoW to a solution which give at least a higher level of decentralization (considering decentralization as scale not binary). But sorry don't want to derail that thread with politics.
So far I don't see any satisfying solution. Bad. Hope we don't need to deal with it. Bitsquare will try to move over to use Bitcoin Core SPV [1] midterm to avoid some of the issues from BitcoinJs broken SPV model (specially bloom filters privacy issues). [1] https://github.com/bitcoin/bitcoin/pull/9483 Am Freitag, 24. März 2017 10:38:13 UTC-5 schrieb Tobias B.: > > 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.
