Afaik the currency code isn't part of any protocol, so I don't understand how BTC vs. BTU can cause a fork. To my understanding it is the (differing) EC that would cause the fork you're fearing. If this is not the case, can you please clarify what fork you mean?
On 03/21/2017 04:22 PM, Matt Corallo wrote: > Hmm? I'm not referring to EC, but to BTU/BTC - a fork that does seem at least > very possible. Because it's am SPV client I'm not sure what else could be > done...An upgrade for Bitcoin Wallet for Android could be pushed out to fetch > from a URL that will be updated with the fork block hash, which could be > downloaded, validated as >1MB, and then the user could be asked which > currency they wish to use. > > [Not to derail, but EC as implemented is horribly broken - the sticky gate > stuff the BU devs refused to remove opens the system up to all kinds of > attacks. Even they've admitted that the only way it works is if 51% of miners > select parameters and everyone else goes along with them, at which point I'm > really not sure why not just do blocksize voting on chain, but whatever.] > > On March 21, 2017 2:48:08 AM PDT, Andreas Schildbach <[email protected]> > wrote: >> Your proposal has the problem that block hashes are not known in >> advance. By the time you (manually?) added the hash to the blacklist >> most bitcoinj nodes will already have processed that block. You would >> need to have the blacklist cause re-orgs, too. Here is gets tricky I >> guess, both for the implementation and for the end-users. >> >> Personally I'm not happy about blacklist features in general. But I'd >> probably still review/merge a block blacklist feature if there is >> considerable demand from developers using bitcoinj. >> >> btw. Do you really think an EC fork will happen? Please correct me if >> I've got the math wrong, but AD6 means you'd have to mine 7 blocks in a >> row, for which you have to have about 91% of hashpower to make it >> economically feasible (0.91^7=0.51). Yes you can skew that number a bit >> by accepting losses, but still it feels EC is almost in the same boat >> as >> SegWit. >> >> >> On 03/21/2017 02:14 AM, Matt Corallo wrote: >>> Given the animosity (and the exchanges making public comments on it), >> I don't think it's worth risking users' safety on such a bet. The API >> should probably at least allow a simple "the block with hash X is >> invalid, ignore that chain" function. Might want to also have something >> similar for the Android wallet (or at least notify users that they are >> likely to end up using BTU and not BTC). >>> >>> On March 20, 2017 6:07:46 PM PDT, Andreas Schildbach >> <[email protected]> wrote: >>>> Forks happen every day. Every time the minority chain dies very >>>> quickly. >>>> Why should this be different? >>>> >>>> Afaik we'd need block a length commitment to be able to distinguish >> as >>>> an SPV/lite wallet. E.g. as a field in the block header. >>>> >>>> >>>> On 03/20/2017 05:04 PM, Manfred Karrer wrote: >>>>> Exactly. Also there are many people (including me) who will not >>>> consider >>>>> the longest PoW chain which follows a different consensus rule as >> the >>>>> valid Bitcoin version. >>>>> Beside that for a project like Bitsquare which is a wallet and >>>> exchange >>>>> there are many potential issues and risks (replay attacks). >>>>> I think BitcoinJ needs a feature to distinguish clearly which chain >>>> the >>>>> user is supporting. >>>>> >>>>> >>>>> Am Montag, 20. März 2017 10:25:49 UTC-5 schrieb Matt Corallo: >>>>> >>>>> Given it appears likely there will be two separate currencies, >> it >>>>> seems really bad to not have some ability for users to >>>> differentiate >>>>> between them. Users will end up highly confused when they do a >>>>> trade, receive BTU, and deposit it to an exchange only to find >> no >>>> BTC. >>>>> >>>>> >>>>> On March 19, 2017 6:42:57 PM PDT, Amitabh Saxena >>>>> <[email protected]> wrote: >>>>> >>>>> Will bitcoinj reject larger blocks? >>>>> >>>>> On Wednesday, March 15, 2017 at 4:38:55 PM UTC+5:30, >> Andreas >>>>> Schildbach wrote: >>>>> >>>>> 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] >>>>> <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.
