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 > <javascript:>> 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 <javascript:>> 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 <javascript:>> 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+u...@googlegroups.com <javascript:> > >>>>>> <mailto:bitcoinj+u...@googlegroups.com <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 bitcoinj+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
