Afaik no. On 03/21/2017 05:20 PM, Patrick McCorry wrote: > Are there plans in BU to update the version number of the block header > and transactions? > > If so, then that should be able to indicate whether Bitcoinj is > following BTC or BTU? > > Maybe i'm overlooking something? > > On Tuesday, 21 March 2017 16:14:03 UTC, 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 > <and...@schildbach.de> 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 > ><and...@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 > >>> <and...@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> > >>>>>> <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+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.
