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 <andr...@schildbach.de> 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 ><andr...@schildbach.de> 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 >>>> <amita...@gmail.com> 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 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+unsubscr...@googlegroups.com >>>> <mailto: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.
