Unfortunately 0confirmation transactions are used in Bitsquare (there is no risk for double spend as the relevant MultiSig tx requires a confirmation). So if txs get relayed from both chains I have a problem in Bitsquare ;-(... Damn BU, would love to spend time on more productive stuff....
Am Mittwoch, 22. März 2017 07:28:09 UTC-5 schrieb Jameson Lopp: > > > > On Wed, Mar 22, 2017 at 1:55 AM, Manfred Karrer <[email protected] > <javascript:>> 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. >>>>>> >>>>>> >>>>>> -- >>>> 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. >>>> >>> >>> -- >> 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:>. >> 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.
