Do you have a link to that discussion? Am Mittwoch, 22. März 2017 14:49:15 UTC-5 schrieb Matt Corallo: > > Luke made a good observation this morning that you can do (somewhat) > compact fraud proofs of blocks > 1MB because of the structure of SHA256 > (you can provide a midstate + the last few bytes of the tx and have a > proof of each txn's length). Having a tor-based (or even public, if it > must be) service which will provide fraud proofs for blocks as proof of > which chain/currency its on is likely very doable (sadly getting nodes > to upgrade to support it now is likely difficult). > > At a minimum any wallet which is not going to do this should almost > certainly have a popup warning their users that Bitcoin is likely > splitting and they are going to be using BTU otherwise users will get > completely screwed trying to do localbitcoins and then sell on an > exchange only to find they received a different coin. > > Matt > > On 03/22/17 16:18, Andreas Schildbach wrote: > > 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>. > >> > >> > >> -- > >> 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>. > >> > >> > >> -- > >> 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>. > >> > >> > >> -- > >> 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] <javascript:> > >> <mailto:[email protected] <javascript:>>. > >> 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.
