Sorry, I simply don't understand what you mean. To me, this looks like a recursive definition:
"The fork is caused by the hard fork being contentious" On 03/21/2017 05:13 PM, Matt Corallo wrote: > The fork is caused by the hard fork being contentious, and many wishing to > stay on the old chain. The EC stuff has nothing to do with the fork, aside > from BU generally relaxing consensus rules, making it a HF. > > On March 21, 2017 9:02:37 AM PDT, Andreas Schildbach <[email protected]> > wrote: >> 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.
