But that is all it would take for Bitcoinj to have the choice on which 
chain to follow? I can't think of anything else (except which network nodes 
to connect too) that would need to be changed .

On Tuesday, 21 March 2017 16:35:18 UTC, Andreas Schildbach wrote:
>
> 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+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.

Reply via email to