Re: Any plans how to deal with a potential BU fork?

[Andreas Schildbach]

I think they will. Except maybe those who are not maintained any more,
but they will fade away like their predecessors¹.

¹ e.g. https://github.com/barmstrong/bitcoin-android


On 03/24/2017 04:55 PM, Tobias B. wrote:
> I totally agree that wallets should warn their users.
> 
> On Friday, March 24, 2017 at 4:50:35 PM UTC+1, Matt Corallo wrote:
> 
> I'm​ not claiming it's an attack or not. Simply, technically, the
> blocks generated are invalid according to the consensus rules
> enforced by the vast majority of those accepting Bitcoin for goods
> and fiat. Bitcoin was designed to ignore any changes to consensus
> rules unless everyone goes along with them. Because of the
> reduced-SPV model that some clients (especially those built on
> bitcoinj) use, this kind of change has massive ability to negatively
> impact users. Whether you agree with Bitcoin Unlimited and plan to
> switch to it or not, you cannot deny that wallets which do not at
> least warn their users, notifying them of which coin they will be
> using, are putting their users at significant risk.
> 
> On March 24, 2017 8:38:12 AM PDT, "Tobias B." 
> wrote:
> 
> I guess when you interpret a majority of miners running BU as an
> attack on the network then you can read that from the paper. I'd
> define an attack as someone spending money on mining to steal
> funds, double spend or harm the bitcoin network on purpose. I
> think here miners just disagree with Bitcoin Core on how to grow
> the bitcoin ecosystem.
> 
> On Friday, March 24, 2017 at 3:44:27 PM UTC+1, Matt Corallo wrote:
> 
> If you really want to get political, Satoshi never
> envisioned SPV the way it's implemented today. Satoshi
> described SPV repeatedly as clients which accept fraud
> proofs allowing them to, just like full nodes, reject any
> invalid chain. Bitcoin was never designed to follow an
> invalid chain, regardless of it's hashpower. The reason this
> doesn't exist is Bitcoin is not currently set up to allow
> for efficient/small fraud proofs, and getting it right is
> super, super hard.
> 
> On March 24, 2017 2:28:15 AM PDT, "Tobias B."
>  wrote:
> 
> Maybe this is so messy because bitcoin was simply never
> intended to follow a minority chain. Maybe the
> assumption was that it is more reliable to measure
> support from economically incentivized miners than
> economically incentivized developers.
> Maybe we shouldn't try to keep a minority chain alive in
> the first place and if it wan'ts to stay alive it has to
> change it's PoW and become an altcoin with the coin
> distribution starting from where bitcoin is at that
> point in time. But maybe I'm too political here. You
> just want to protect users, that's fine. But whatever
> change Bitcoinj implements, users who do not update
> their software will be in danger when there are two
> bitcoin chains that're using the same PoW. For me that's
> an argument to not support that scenario. If core really
> wants to ignore a majority decision of 80% of the miners
> then I think they're obligated to change the PoW to
> prevent this mess.
> 
> On Friday, March 24, 2017 at 12:34:45 AM UTC+1, Manfred
> Karrer wrote:
> 
> No I don't bet on it, just wanted to mention that it
> is a (very) possible further escalation scenario. If
> the minority chain gets attacked it seems to me also
> the most likely survival tactic. But I would not
> count on that of course.
> 
> So far I still have no satisfying solution how to
> deal with a HF in Bitsquare.
> Stopping the trading is hard in Bitsquare as it is
> decentralized. 
> Preventing users to use the wallet and become victim
> of unintended replays is impossible.
> Whitelist for BTC chain nodes helps only for
> confirmed txs but not unconfirmed. That would not
> risk loss of funds but the usability in the trade
> would get screwed.
> 
> So lets hope that BU does not escalate and we can
> spend time on more productive stuff.
> But at the end it demonstrates a very serious
> vulnerability with SPV mode. 
> I hope 

Re: Any plans how to deal with a potential BU fork?

[Tobias B.]

I totally agree that wallets should warn their users.

On Friday, March 24, 2017 at 4:50:35 PM UTC+1, Matt Corallo wrote:
>
> I'm​ not claiming it's an attack or not. Simply, technically, the blocks 
> generated are invalid according to the consensus rules enforced by the vast 
> majority of those accepting Bitcoin for goods and fiat. Bitcoin was 
> designed to ignore any changes to consensus rules unless everyone goes 
> along with them. Because of the reduced-SPV model that some clients 
> (especially those built on bitcoinj) use, this kind of change has massive 
> ability to negatively impact users. Whether you agree with Bitcoin 
> Unlimited and plan to switch to it or not, you cannot deny that wallets 
> which do not at least warn their users, notifying them of which coin they 
> will be using, are putting their users at significant risk.
>
> On March 24, 2017 8:38:12 AM PDT, "Tobias B."  > wrote:
>>
>> I guess when you interpret a majority of miners running BU as an attack 
>> on the network then you can read that from the paper. I'd define an attack 
>> as someone spending money on mining to steal funds, double spend or harm 
>> the bitcoin network on purpose. I think here miners just disagree with 
>> Bitcoin Core on how to grow the bitcoin ecosystem.
>>
>> On Friday, March 24, 2017 at 3:44:27 PM UTC+1, Matt Corallo wrote:
>>>
>>> If you really want to get political, Satoshi never envisioned SPV the 
>>> way it's implemented today. Satoshi described SPV repeatedly as clients 
>>> which accept fraud proofs allowing them to, just like full nodes, reject 
>>> any invalid chain. Bitcoin was never designed to follow an invalid chain, 
>>> regardless of it's hashpower. The reason this doesn't exist is Bitcoin is 
>>> not currently set up to allow for efficient/small fraud proofs, and getting 
>>> it right is super, super hard.
>>>
>>> On March 24, 2017 2:28:15 AM PDT, "Tobias B."  
>>> wrote:

 Maybe this is so messy because bitcoin was simply never intended to 
 follow a minority chain. Maybe the assumption was that it is more reliable 
 to measure support from economically incentivized miners than economically 
 incentivized developers.
 Maybe we shouldn't try to keep a minority chain alive in the first 
 place and if it wan'ts to stay alive it has to change it's PoW and become 
 an altcoin with the coin distribution starting from where bitcoin is at 
 that point in time. But maybe I'm too political here. You just want to 
 protect users, that's fine. But whatever change Bitcoinj implements, users 
 who do not update their software will be in danger when there are two 
 bitcoin chains that're using the same PoW. For me that's an argument to 
 not 
 support that scenario. If core really wants to ignore a majority decision 
 of 80% of the miners then I think they're obligated to change the PoW to 
 prevent this mess.

 On Friday, March 24, 2017 at 12:34:45 AM UTC+1, Manfred Karrer wrote:
>
> No I don't bet on it, just wanted to mention that it is a (very) 
> possible further escalation scenario. If the minority chain gets attacked 
> it seems to me also the most likely survival tactic. But I would not 
> count 
> on that of course.
>
> So far I still have no satisfying solution how to deal with a HF in 
> Bitsquare.
> Stopping the trading is hard in Bitsquare as it is decentralized. 
> Preventing users to use the wallet and become victim of unintended 
> replays is impossible.
> Whitelist for BTC chain nodes helps only for confirmed txs but not 
> unconfirmed. That would not risk loss of funds but the usability in the 
> trade would get screwed.
>
> So lets hope that BU does not escalate and we can spend time on more 
> productive stuff.
> But at the end it demonstrates a very serious vulnerability with SPV 
> mode. 
> I hope the work on Bitcoin Core SPV will become a viable alternative 
> soon. I consider midterm to move over to that model in Bitsquare. That 
> would solve the privacy issues with bloom filters as well.
>
>
> Am Donnerstag, 23. März 2017 10:46:51 UTC-5 schrieb Matt Corallo:
>>
>> I'm not sure you can bet on BTC having a PoW change, let alone make 
>> that bet and risk users getting completely screwed if it doesn't happen.
>>
>> On March 23, 2017 2:35:02 AM PDT, "Tobias B."  
>> wrote:
>>>
>>> So as the minority (core) chain is likely to make a PoW change, 
>>> wouldn't this break SPV clients? I hope in such a case this chain would 
>>> also add replay protection - people would have to install new clients 
>>> anyway.
>>>
>>> On Wednesday, March 22, 2017 at 10:14:39 PM UTC+1, Manfred Karrer 
>>> wrote:

 When you talk about minority chain we should take in consideration 
 

Re: Any plans how to deal with a potential BU fork?

[Tobias B.]

Maybe this is so messy because bitcoin was simply never intended to follow 
a minority chain. Maybe the assumption was that it is more reliable to 
measure support from economically incentivized miners than economically 
incentivized developers.
Maybe we shouldn't try to keep a minority chain alive in the first place 
and if it wan'ts to stay alive it has to change it's PoW and become an 
altcoin with the coin distribution starting from where bitcoin is at that 
point in time. But maybe I'm too political here. You just want to protect 
users, that's fine. But whatever change Bitcoinj implements, users who do 
not update their software will be in danger when there are two bitcoin 
chains that're using the same PoW. For me that's an argument to not support 
that scenario. If core really wants to ignore a majority decision of 80% of 
the miners then I think they're obligated to change the PoW to prevent this 
mess.

On Friday, March 24, 2017 at 12:34:45 AM UTC+1, Manfred Karrer wrote:
>
> No I don't bet on it, just wanted to mention that it is a (very) possible 
> further escalation scenario. If the minority chain gets attacked it seems 
> to me also the most likely survival tactic. But I would not count on that 
> of course.
>
> So far I still have no satisfying solution how to deal with a HF in 
> Bitsquare.
> Stopping the trading is hard in Bitsquare as it is decentralized. 
> Preventing users to use the wallet and become victim of unintended replays 
> is impossible.
> Whitelist for BTC chain nodes helps only for confirmed txs but not 
> unconfirmed. That would not risk loss of funds but the usability in the 
> trade would get screwed.
>
> So lets hope that BU does not escalate and we can spend time on more 
> productive stuff.
> But at the end it demonstrates a very serious vulnerability with SPV mode. 
> I hope the work on Bitcoin Core SPV will become a viable alternative soon. 
> I consider midterm to move over to that model in Bitsquare. That would 
> solve the privacy issues with bloom filters as well.
>
>
> Am Donnerstag, 23. März 2017 10:46:51 UTC-5 schrieb Matt Corallo:
>>
>> I'm not sure you can bet on BTC having a PoW change, let alone make that 
>> bet and risk users getting completely screwed if it doesn't happen.
>>
>> On March 23, 2017 2:35:02 AM PDT, "Tobias B."  wrote:
>>>
>>> So as the minority (core) chain is likely to make a PoW change, wouldn't 
>>> this break SPV clients? I hope in such a case this chain would also add 
>>> replay protection - people would have to install new clients anyway.
>>>
>>> On Wednesday, March 22, 2017 at 10:14:39 PM UTC+1, Manfred Karrer wrote:

 When you talk about minority chain we should take in consideration that 
 this might change over time. So todays winning chain might be the loser of 
 tomorrow and so on. Might be pretty messy with re-orgs and double spends...
 Also I would not count with what some people expect that the minority 
 chain will quickly die (or get killed). The ETH devs made that mistake and 
 underestimated ETC a lot. Mining resources and price are highly dynamic 
 factors making predictions much harder. Not to talk about the emotional 
 and 
 political factors... 
 Also a PoW change is a very likely element in such a scenario...


 Am Mittwoch, 22. März 2017 11:18:23 UTC-5 schrieb Andreas Schildbach:
>
> Maybe the recommendation should be: if you want to follow a minority 
> chain, use the Peer API to connect to a trusted peer under your 
> control. 
> You can then run your desired full node implemention on the trusted 
> peer 
> and bitcoinj will follow. If the network between bitcoinj and the 
> trusted peer is not to be trusted, use a VPN to secure that connection 
> (the Bitcoin protocol itself lacks authentication). 
>
> That would be far more reliable than a version string whitelist. In 
> fact, frontending bitcoinj with bitcoind has always been a 
> recommendation for centralized/web services, so if they followed that 
> recommendation they should not have to change anything. 
>
>
> On 03/22/2017 03:34 PM, Tobias B. wrote: 
> > Still maybe it adding an API call to go into "whitelist mode" and 
> then 
> > add certain node ips would be a compromise. Software building on 
> > bitcoinj could then offer the user to go into this mode and add 
> certain 
> > ips there. 
> > 
> > On Wednesday, March 22, 2017 at 3:25:15 PM UTC+1, Tobias B. wrote: 
> > 
> > A whitelist of nodes for me sounds highly conflicting with the 
> > decentralized nature of bitcoin. Also what if nodes switch their 
> > software? Not that unlikely in case they notice that their 
> minority 
> > chain is dying. 
> > 
> > On Wednesday, March 22, 2017 at 1:28:09 PM UTC+1, Jameson Lopp 
> wrote: 
> > 
> > 
> > 
> > 

Re: Any plans how to deal with a potential BU fork?

[Tobias B.]

So as the minority (core) chain is likely to make a PoW change, wouldn't 
this break SPV clients? I hope in such a case this chain would also add 
replay protection - people would have to install new clients anyway.

On Wednesday, March 22, 2017 at 10:14:39 PM UTC+1, Manfred Karrer wrote:
>
> When you talk about minority chain we should take in consideration that 
> this might change over time. So todays winning chain might be the loser of 
> tomorrow and so on. Might be pretty messy with re-orgs and double spends...
> Also I would not count with what some people expect that the minority 
> chain will quickly die (or get killed). The ETH devs made that mistake and 
> underestimated ETC a lot. Mining resources and price are highly dynamic 
> factors making predictions much harder. Not to talk about the emotional and 
> political factors... 
> Also a PoW change is a very likely element in such a scenario...
>
>
> Am Mittwoch, 22. März 2017 11:18:23 UTC-5 schrieb Andreas Schildbach:
>>
>> Maybe the recommendation should be: if you want to follow a minority 
>> chain, use the Peer API to connect to a trusted peer under your control. 
>> You can then run your desired full node implemention on the trusted peer 
>> and bitcoinj will follow. If the network between bitcoinj and the 
>> trusted peer is not to be trusted, use a VPN to secure that connection 
>> (the Bitcoin protocol itself lacks authentication). 
>>
>> That would be far more reliable than a version string whitelist. In 
>> fact, frontending bitcoinj with bitcoind has always been a 
>> recommendation for centralized/web services, so if they followed that 
>> recommendation they should not have to change anything. 
>>
>>
>> On 03/22/2017 03:34 PM, Tobias B. wrote: 
>> > Still maybe it adding an API call to go into "whitelist mode" and then 
>> > add certain node ips would be a compromise. Software building on 
>> > bitcoinj could then offer the user to go into this mode and add certain 
>> > ips there. 
>> > 
>> > On Wednesday, March 22, 2017 at 3:25:15 PM UTC+1, Tobias B. wrote: 
>> > 
>> > A whitelist of nodes for me sounds highly conflicting with the 
>> > decentralized nature of bitcoin. Also what if nodes switch their 
>> > software? Not that unlikely in case they notice that their minority 
>> > chain is dying. 
>> > 
>> > On Wednesday, March 22, 2017 at 1:28:09 PM UTC+1, Jameson Lopp 
>> wrote: 
>> > 
>> > 
>> > 
>> > On Wed, Mar 22, 2017 at 1:55 AM, Manfred Karrer 
>> >  wrote: 
>> > 
>> > A Bitcoin core node will not mine a transaction originated 
>> > in a >1 MB block (not sure if it would relay it). BitcoinJ 
>> > has no validation of that consensus rule, so it would 
>> accept 
>> > a tx from a BTU block. I think with a whitelist to connect 
>> > to BTC core nodes only (or better run your local node) you 
>> > should be safe against receiving txs from a  BTU block (> 
>> > 1MB or built on top of a >1MB block). If BTC core does not 
>> > check if a tx has inputs from a >1 MB block for replaying 
>> > then we need to take extra care of 0 confirmation txs. 
>> > Does anyone here know if that is the case? 
>> > 
>> > 
>> > If your software ignores all unconfirmed transactions then I 
>> > could see a slightly stronger argument for going the whitelist 
>> > route. My point was that unconfirmed transactions will get 
>> > relayed around the network by nodes on both chain forks. 
>> >   
>> > 
>> > Yes I agree on the protocol level it will be hard as the 
>> > nodes can easily lie. 
>> > 
>> > Sure wallet providers should not have to deal with it. But 
>> I 
>> > don't see much alternative. As pure wallet it might be 
>> > easier to tell the people just dont use yoru wallet for a 
>> > few days/week. But for Bitsquare as an exchange that is not 
>> > really an option, trading should not get stopped (and in 
>> > case of Bitsquare cannot really). 
>> > 
>> > Maybe 2015 people have not been so nervous about it because 
>> > it was before ETH demonstrated the risk and damage of a 
>> HF... 
>> > 
>> > Am Dienstag, 21. März 2017 21:42:07 UTC-5 schrieb Jameson 
>> Lopp: 
>> > 
>> > I don't think replay protection can be added at the 
>> > network level. Peers could lie about their software 
>> > version and/or switch it, plus it's highly likely that 
>> a 
>> > chain split won't result in a clean network partition. 
>> > Transactions will get relayed around the network 
>> > comprised of nodes on both chains and you can expect 
>> > that Core nodes would still relay transactions to you 
>> >

Re: Any plans how to deal with a potential BU fork?

[Matt Corallo]

His BIP is at 
https://github.com/luke-jr/bips/blob/bip-sizefp/bip-sizefp.mediawiki
He posted a link to it on the bitcoin-dev mailing list.

Matt

On March 22, 2017 2:09:13 PM PDT, Manfred Karrer  
wrote:
>Do you have a link to that discussion?
>
>Am Mittwoch, 22. März 2017 14:49:15 UTC-5 schrieb Matt Corallo:
>>
>> Luke made a good observation this morning that you can do (somewhat) 
>> compact fraud proofs of blocks > 1MB because of the structure of
>SHA256 
>> (you can provide a midstate + the last few bytes of the tx and have a
>
>> proof of each txn's length). Having a tor-based (or even public, if
>it 
>> must be) service which will provide fraud proofs for blocks as proof
>of 
>> which chain/currency its on is likely very doable (sadly getting
>nodes 
>> to upgrade to support it now is likely difficult). 
>>
>> At a minimum any wallet which is not going to do this should almost 
>> certainly have a popup warning their users that Bitcoin is likely 
>> splitting and they are going to be using BTU otherwise users will get
>
>> completely screwed trying to do localbitcoins and then sell on an 
>> exchange only to find they received a different coin. 
>>
>> Matt 
>>
>> On 03/22/17 16:18, Andreas Schildbach wrote: 
>> > Maybe the recommendation should be: if you want to follow a
>minority 
>> > chain, use the Peer API to connect to a trusted peer under your
>control. 
>> > You can then run your desired full node implemention on the trusted
>peer 
>> > and bitcoinj will follow. If the network between bitcoinj and the 
>> > trusted peer is not to be trusted, use a VPN to secure that
>connection 
>> > (the Bitcoin protocol itself lacks authentication). 
>> > 
>> > That would be far more reliable than a version string whitelist. In
>
>> > fact, frontending bitcoinj with bitcoind has always been a 
>> > recommendation for centralized/web services, so if they followed
>that 
>> > recommendation they should not have to change anything. 
>> > 
>> > 
>> > On 03/22/2017 03:34 PM, Tobias B. wrote: 
>> >> Still maybe it adding an API call to go into "whitelist mode" and
>then 
>> >> add certain node ips would be a compromise. Software building on 
>> >> bitcoinj could then offer the user to go into this mode and add
>certain 
>> >> ips there. 
>> >> 
>> >> On Wednesday, March 22, 2017 at 3:25:15 PM UTC+1, Tobias B. wrote:
>
>> >> 
>> >> A whitelist of nodes for me sounds highly conflicting with the
>
>> >> decentralized nature of bitcoin. Also what if nodes switch
>their 
>> >> software? Not that unlikely in case they notice that their
>minority 
>> >> chain is dying. 
>> >> 
>> >> On Wednesday, March 22, 2017 at 1:28:09 PM UTC+1, Jameson Lopp
>
>> wrote: 
>> >> 
>> >> 
>> >> 
>> >> On Wed, Mar 22, 2017 at 1:55 AM, Manfred Karrer 
>> >>  wrote: 
>> >> 
>> >> A Bitcoin core node will not mine a transaction
>originated 
>> >> in a >1 MB block (not sure if it would relay it).
>BitcoinJ 
>> >> has no validation of that consensus rule, so it would 
>> accept 
>> >> a tx from a BTU block. I think with a whitelist to
>connect 
>> >> to BTC core nodes only (or better run your local node)
>you 
>> >> should be safe against receiving txs from a  BTU block
>(> 
>> >> 1MB or built on top of a >1MB block). If BTC core does
>not 
>> >> check if a tx has inputs from a >1 MB block for
>replaying 
>> >> then we need to take extra care of 0 confirmation txs.
>
>> >> Does anyone here know if that is the case? 
>> >> 
>> >> 
>> >> If your software ignores all unconfirmed transactions then
>I 
>> >> could see a slightly stronger argument for going the
>whitelist 
>> >> route. My point was that unconfirmed transactions will get
>
>> >> relayed around the network by nodes on both chain forks. 
>> >>   
>> >> 
>> >> Yes I agree on the protocol level it will be hard as
>the 
>> >> nodes can easily lie. 
>> >> 
>> >> Sure wallet providers should not have to deal with it.
>But 
>> I 
>> >> don't see much alternative. As pure wallet it might be
>
>> >> easier to tell the people just dont use yoru wallet
>for a 
>> >> few days/week. But for Bitsquare as an exchange that
>is not 
>> >> really an option, trading should not get stopped (and
>in 
>> >> case of Bitsquare cannot really). 
>> >> 
>> >> Maybe 2015 people have not been so nervous about it
>because 
>> >> it was before ETH demonstrated the risk and damage of
>a 
>> HF... 
>> >> 
>> >> Am Dienstag, 21. März 2017 21:42:07 UTC-5 schrieb
>Jameson 
>> Lopp: 
>> >> 
>> >> I don't think replay protection can be added at
>the 
>> >> network level. Peers could lie about their
>software 
>> >> 

Re: Any plans how to deal with a potential BU fork?

[Manfred Karrer]

When you talk about minority chain we should take in consideration that 
this might change over time. So todays winning chain might be the loser of 
tomorrow and so on. Might be pretty messy with re-orgs and double spends...
Also I would not count with what some people expect that the minority chain 
will quickly die (or get killed). The ETH devs made that mistake and 
underestimated ETC a lot. Mining resources and price are highly dynamic 
factors making predictions much harder. Not to talk about the emotional and 
political factors... 
Also a PoW change is a very likely element in such a scenario...


Am Mittwoch, 22. März 2017 11:18:23 UTC-5 schrieb Andreas Schildbach:
>
> Maybe the recommendation should be: if you want to follow a minority 
> chain, use the Peer API to connect to a trusted peer under your control. 
> You can then run your desired full node implemention on the trusted peer 
> and bitcoinj will follow. If the network between bitcoinj and the 
> trusted peer is not to be trusted, use a VPN to secure that connection 
> (the Bitcoin protocol itself lacks authentication). 
>
> That would be far more reliable than a version string whitelist. In 
> fact, frontending bitcoinj with bitcoind has always been a 
> recommendation for centralized/web services, so if they followed that 
> recommendation they should not have to change anything. 
>
>
> On 03/22/2017 03:34 PM, Tobias B. wrote: 
> > Still maybe it adding an API call to go into "whitelist mode" and then 
> > add certain node ips would be a compromise. Software building on 
> > bitcoinj could then offer the user to go into this mode and add certain 
> > ips there. 
> > 
> > On Wednesday, March 22, 2017 at 3:25:15 PM UTC+1, Tobias B. wrote: 
> > 
> > A whitelist of nodes for me sounds highly conflicting with the 
> > decentralized nature of bitcoin. Also what if nodes switch their 
> > software? Not that unlikely in case they notice that their minority 
> > chain is dying. 
> > 
> > On Wednesday, March 22, 2017 at 1:28:09 PM UTC+1, Jameson Lopp 
> wrote: 
> > 
> > 
> > 
> > On Wed, Mar 22, 2017 at 1:55 AM, Manfred Karrer 
> >  wrote: 
> > 
> > A Bitcoin core node will not mine a transaction originated 
> > in a >1 MB block (not sure if it would relay it). BitcoinJ 
> > has no validation of that consensus rule, so it would accept 
> > a tx from a BTU block. I think with a whitelist to connect 
> > to BTC core nodes only (or better run your local node) you 
> > should be safe against receiving txs from a  BTU block (> 
> > 1MB or built on top of a >1MB block). If BTC core does not 
> > check if a tx has inputs from a >1 MB block for replaying 
> > then we need to take extra care of 0 confirmation txs. 
> > Does anyone here know if that is the case? 
> > 
> > 
> > If your software ignores all unconfirmed transactions then I 
> > could see a slightly stronger argument for going the whitelist 
> > route. My point was that unconfirmed transactions will get 
> > relayed around the network by nodes on both chain forks. 
> >   
> > 
> > Yes I agree on the protocol level it will be hard as the 
> > nodes can easily lie. 
> > 
> > Sure wallet providers should not have to deal with it. But I 
> > don't see much alternative. As pure wallet it might be 
> > easier to tell the people just dont use yoru wallet for a 
> > few days/week. But for Bitsquare as an exchange that is not 
> > really an option, trading should not get stopped (and in 
> > case of Bitsquare cannot really). 
> > 
> > Maybe 2015 people have not been so nervous about it because 
> > it was before ETH demonstrated the risk and damage of a 
> HF... 
> > 
> > Am Dienstag, 21. März 2017 21:42:07 UTC-5 schrieb Jameson 
> Lopp: 
> > 
> > I don't think replay protection can be added at the 
> > network level. Peers could lie about their software 
> > version and/or switch it, plus it's highly likely that a 
> > chain split won't result in a clean network partition. 
> > Transactions will get relayed around the network 
> > comprised of nodes on both chains and you can expect 
> > that Core nodes would still relay transactions to you 
> > that were originally broadcast by Unlimited nodes and 
> > vice versa. 
> > 
> > At a more philosophical level, I'm not so sure that the 
> > onus is on every wallet provider to implement protection 
> > against contentious hard forks. You could have made 
> > similar arguments that BitcoinJ should have added 

Re: Any plans how to deal with a potential BU fork?

[Manfred Karrer]

Do you have a link to that discussion?

Am Mittwoch, 22. März 2017 14:49:15 UTC-5 schrieb Matt Corallo:
>
> Luke made a good observation this morning that you can do (somewhat) 
> compact fraud proofs of blocks > 1MB because of the structure of SHA256 
> (you can provide a midstate + the last few bytes of the tx and have a 
> proof of each txn's length). Having a tor-based (or even public, if it 
> must be) service which will provide fraud proofs for blocks as proof of 
> which chain/currency its on is likely very doable (sadly getting nodes 
> to upgrade to support it now is likely difficult). 
>
> At a minimum any wallet which is not going to do this should almost 
> certainly have a popup warning their users that Bitcoin is likely 
> splitting and they are going to be using BTU otherwise users will get 
> completely screwed trying to do localbitcoins and then sell on an 
> exchange only to find they received a different coin. 
>
> Matt 
>
> On 03/22/17 16:18, Andreas Schildbach wrote: 
> > Maybe the recommendation should be: if you want to follow a minority 
> > chain, use the Peer API to connect to a trusted peer under your control. 
> > You can then run your desired full node implemention on the trusted peer 
> > and bitcoinj will follow. If the network between bitcoinj and the 
> > trusted peer is not to be trusted, use a VPN to secure that connection 
> > (the Bitcoin protocol itself lacks authentication). 
> > 
> > That would be far more reliable than a version string whitelist. In 
> > fact, frontending bitcoinj with bitcoind has always been a 
> > recommendation for centralized/web services, so if they followed that 
> > recommendation they should not have to change anything. 
> > 
> > 
> > On 03/22/2017 03:34 PM, Tobias B. wrote: 
> >> Still maybe it adding an API call to go into "whitelist mode" and then 
> >> add certain node ips would be a compromise. Software building on 
> >> bitcoinj could then offer the user to go into this mode and add certain 
> >> ips there. 
> >> 
> >> On Wednesday, March 22, 2017 at 3:25:15 PM UTC+1, Tobias B. wrote: 
> >> 
> >> A whitelist of nodes for me sounds highly conflicting with the 
> >> decentralized nature of bitcoin. Also what if nodes switch their 
> >> software? Not that unlikely in case they notice that their minority 
> >> chain is dying. 
> >> 
> >> On Wednesday, March 22, 2017 at 1:28:09 PM UTC+1, Jameson Lopp 
> wrote: 
> >> 
> >> 
> >> 
> >> On Wed, Mar 22, 2017 at 1:55 AM, Manfred Karrer 
> >>  wrote: 
> >> 
> >> A Bitcoin core node will not mine a transaction originated 
> >> in a >1 MB block (not sure if it would relay it). BitcoinJ 
> >> has no validation of that consensus rule, so it would 
> accept 
> >> a tx from a BTU block. I think with a whitelist to connect 
> >> to BTC core nodes only (or better run your local node) you 
> >> should be safe against receiving txs from a  BTU block (> 
> >> 1MB or built on top of a >1MB block). If BTC core does not 
> >> check if a tx has inputs from a >1 MB block for replaying 
> >> then we need to take extra care of 0 confirmation txs. 
> >> Does anyone here know if that is the case? 
> >> 
> >> 
> >> If your software ignores all unconfirmed transactions then I 
> >> could see a slightly stronger argument for going the whitelist 
> >> route. My point was that unconfirmed transactions will get 
> >> relayed around the network by nodes on both chain forks. 
> >>   
> >> 
> >> Yes I agree on the protocol level it will be hard as the 
> >> nodes can easily lie. 
> >> 
> >> Sure wallet providers should not have to deal with it. But 
> I 
> >> don't see much alternative. As pure wallet it might be 
> >> easier to tell the people just dont use yoru wallet for a 
> >> few days/week. But for Bitsquare as an exchange that is not 
> >> really an option, trading should not get stopped (and in 
> >> case of Bitsquare cannot really). 
> >> 
> >> Maybe 2015 people have not been so nervous about it because 
> >> it was before ETH demonstrated the risk and damage of a 
> HF... 
> >> 
> >> Am Dienstag, 21. März 2017 21:42:07 UTC-5 schrieb Jameson 
> Lopp: 
> >> 
> >> I don't think replay protection can be added at the 
> >> network level. Peers could lie about their software 
> >> version and/or switch it, plus it's highly likely that 
> a 
> >> chain split won't result in a clean network partition. 
> >> Transactions will get relayed around the network 
> >> comprised of nodes on both chains and you can expect 
> >> that Core nodes would still relay transactions to 

Re: Any plans how to deal with a potential BU fork?

[Matt Corallo]

Luke made a good observation this morning that you can do (somewhat)
compact fraud proofs of blocks > 1MB because of the structure of SHA256
(you can provide a midstate + the last few bytes of the tx and have a
proof of each txn's length). Having a tor-based (or even public, if it
must be) service which will provide fraud proofs for blocks as proof of
which chain/currency its on is likely very doable (sadly getting nodes
to upgrade to support it now is likely difficult).

At a minimum any wallet which is not going to do this should almost
certainly have a popup warning their users that Bitcoin is likely
splitting and they are going to be using BTU otherwise users will get
completely screwed trying to do localbitcoins and then sell on an
exchange only to find they received a different coin.

Matt

On 03/22/17 16:18, Andreas Schildbach wrote:
> Maybe the recommendation should be: if you want to follow a minority
> chain, use the Peer API to connect to a trusted peer under your control.
> You can then run your desired full node implemention on the trusted peer
> and bitcoinj will follow. If the network between bitcoinj and the
> trusted peer is not to be trusted, use a VPN to secure that connection
> (the Bitcoin protocol itself lacks authentication).
> 
> That would be far more reliable than a version string whitelist. In
> fact, frontending bitcoinj with bitcoind has always been a
> recommendation for centralized/web services, so if they followed that
> recommendation they should not have to change anything.
> 
> 
> On 03/22/2017 03:34 PM, Tobias B. wrote:
>> Still maybe it adding an API call to go into "whitelist mode" and then
>> add certain node ips would be a compromise. Software building on
>> bitcoinj could then offer the user to go into this mode and add certain
>> ips there.
>>
>> On Wednesday, March 22, 2017 at 3:25:15 PM UTC+1, Tobias B. wrote:
>>
>> A whitelist of nodes for me sounds highly conflicting with the
>> decentralized nature of bitcoin. Also what if nodes switch their
>> software? Not that unlikely in case they notice that their minority
>> chain is dying.
>>
>> On Wednesday, March 22, 2017 at 1:28:09 PM UTC+1, Jameson Lopp wrote:
>>
>>
>>
>> On Wed, Mar 22, 2017 at 1:55 AM, Manfred Karrer
>>  wrote:
>>
>> A Bitcoin core node will not mine a transaction originated
>> in a >1 MB block (not sure if it would relay it). BitcoinJ
>> has no validation of that consensus rule, so it would accept
>> a tx from a BTU block. I think with a whitelist to connect
>> to BTC core nodes only (or better run your local node) you
>> should be safe against receiving txs from a  BTU block (>
>> 1MB or built on top of a >1MB block). If BTC core does not
>> check if a tx has inputs from a >1 MB block for replaying
>> then we need to take extra care of 0 confirmation txs. 
>> Does anyone here know if that is the case? 
>>
>>
>> If your software ignores all unconfirmed transactions then I
>> could see a slightly stronger argument for going the whitelist
>> route. My point was that unconfirmed transactions will get
>> relayed around the network by nodes on both chain forks.
>>  
>>
>> Yes I agree on the protocol level it will be hard as the
>> nodes can easily lie.
>>
>> Sure wallet providers should not have to deal with it. But I
>> don't see much alternative. As pure wallet it might be
>> easier to tell the people just dont use yoru wallet for a
>> few days/week. But for Bitsquare as an exchange that is not
>> really an option, trading should not get stopped (and in
>> case of Bitsquare cannot really).
>>
>> Maybe 2015 people have not been so nervous about it because
>> it was before ETH demonstrated the risk and damage of a HF... 
>>
>> Am Dienstag, 21. März 2017 21:42:07 UTC-5 schrieb Jameson Lopp:
>>
>> I don't think replay protection can be added at the
>> network level. Peers could lie about their software
>> version and/or switch it, plus it's highly likely that a
>> chain split won't result in a clean network partition.
>> Transactions will get relayed around the network
>> comprised of nodes on both chains and you can expect
>> that Core nodes would still relay transactions to you
>> that were originally broadcast by Unlimited nodes and
>> vice versa.
>>
>> At a more philosophical level, I'm not so sure that the
>> onus is on every wallet provider to implement protection
>> against contentious hard forks. You could have made
>> similar arguments that 

Re: Any plans how to deal with a potential BU fork?

[Tobias B.]

A whitelist of nodes for me sounds highly conflicting with the 
decentralized nature of bitcoin. Also what if nodes switch their software? 
Not that unlikely in case they notice that their minority chain is dying.

On Wednesday, March 22, 2017 at 1:28:09 PM UTC+1, Jameson Lopp wrote:
>
>
>
> On Wed, Mar 22, 2017 at 1:55 AM, Manfred Karrer  > wrote:
>
>> A Bitcoin core node will not mine a transaction originated in a >1 MB 
>> block (not sure if it would relay it). BitcoinJ has no validation of that 
>> consensus rule, so it would accept a tx from a BTU block. I think with a 
>> whitelist to connect to BTC core nodes only (or better run your local node) 
>> you should be safe against receiving txs from a  BTU block (> 1MB or built 
>> on top of a >1MB block). If BTC core does not check if a tx has inputs from 
>> a >1 MB block for replaying then we need to take extra care of 0 
>> confirmation txs. 
>> Does anyone here know if that is the case? 
>>
>>
> If your software ignores all unconfirmed transactions then I could see a 
> slightly stronger argument for going the whitelist route. My point was that 
> unconfirmed transactions will get relayed around the network by nodes on 
> both chain forks.
>  
>
>> Yes I agree on the protocol level it will be hard as the nodes can easily 
>> lie.
>>
>> Sure wallet providers should not have to deal with it. But I don't see 
>> much alternative. As pure wallet it might be easier to tell the people just 
>> dont use yoru wallet for a few days/week. But for Bitsquare as an exchange 
>> that is not really an option, trading should not get stopped (and in case 
>> of Bitsquare cannot really).
>>
>> Maybe 2015 people have not been so nervous about it because it was before 
>> ETH demonstrated the risk and damage of a HF... 
>>
>> Am Dienstag, 21. März 2017 21:42:07 UTC-5 schrieb Jameson Lopp:
>>>
>>> I don't think replay protection can be added at the network level. Peers 
>>> could lie about their software version and/or switch it, plus it's highly 
>>> likely that a chain split won't result in a clean network partition. 
>>> Transactions will get relayed around the network comprised of nodes on both 
>>> chains and you can expect that Core nodes would still relay transactions to 
>>> you that were originally broadcast by Unlimited nodes and vice versa.
>>>
>>> At a more philosophical level, I'm not so sure that the onus is on every 
>>> wallet provider to implement protection against contentious hard forks. You 
>>> could have made similar arguments that BitcoinJ should have added replay 
>>> protection when support for 8MB blocks was nearing 50% hashrate back in 
>>> 2015.
>>>
>>> On Tue, Mar 21, 2017 at 8:28 PM, Manfred Karrer  
>>> wrote:
>>>
 Btw. of course the whitelist can be set by the user himself, so if he 
 runs a full node he can use that. 
 But knowing that the majority of users are not running their own full 
 node we need alternative solutions as well.


 Am Dienstag, 21. März 2017 19:23:56 UTC-5 schrieb Manfred Karrer:
>
> Andreas, how are you planning to protect users of the Android wallet 
> agains replay attacks? 
> How does a user know if she/he can send his wallet coins to a peer who 
> accepts only BTC or BTU (e.g. exchange)? Otherwise he might end up pretty 
> frustrated to see outgoing transactions at this wallet but not 
> confirmation 
> of receipt at the receiver.
>
> You cannot assume that all your users are blindly following the 
> longest PoW chain as the only valid BTC chain and ignore the replay 
> attack 
> risks.
> There might be even legal issues connected to it (see ETH HF and 
> losses from replay attacks), probably less for a wallet provider than for 
> a 
> centralized exchange holding customers funds. But I am not sure if that 
> would not fall back to others as well (due diligence), at least people 
> could try to sue...
>
> One of the easiest solution I see is to deploy a whitelist of Bitcoin 
> Core nodes and use those for the P2P network connections. 
> You can give the user the choice to select between whitelist Bitcoin 
> Core nodes (if he wants BTC), whitelist BU nodes (i he wants BTU) or 
> public 
> network (if he thinks all plays out by itself and is aware of the 
> included 
> risk/mess).
> Of course a whitelist is not great as well but that would solve the 
> problem that we cannot know in advance the data which helps us to 
> distinguish between the chains (like blockID or certain transactions). 
> That 
> whitelist only need to be used as long the HF is messy, once things have 
> settled it can be removed or replaced by other distinguishing data 
> sources 
> like blockIds.
>
> If BTU implements a clean mechanism to make it easy to distinguish 
> that would be the best solution of course but 

Re: Any plans how to deal with a potential BU fork?

[Jameson Lopp]

On Wed, Mar 22, 2017 at 1:55 AM, Manfred Karrer 
wrote:

> A Bitcoin core node will not mine a transaction originated in a >1 MB
> block (not sure if it would relay it). BitcoinJ has no validation of that
> consensus rule, so it would accept a tx from a BTU block. I think with a
> whitelist to connect to BTC core nodes only (or better run your local node)
> you should be safe against receiving txs from a  BTU block (> 1MB or built
> on top of a >1MB block). If BTC core does not check if a tx has inputs from
> a >1 MB block for replaying then we need to take extra care of 0
> confirmation txs.
> Does anyone here know if that is the case?
>
>
If your software ignores all unconfirmed transactions then I could see a
slightly stronger argument for going the whitelist route. My point was that
unconfirmed transactions will get relayed around the network by nodes on
both chain forks.


> Yes I agree on the protocol level it will be hard as the nodes can easily
> lie.
>
> Sure wallet providers should not have to deal with it. But I don't see
> much alternative. As pure wallet it might be easier to tell the people just
> dont use yoru wallet for a few days/week. But for Bitsquare as an exchange
> that is not really an option, trading should not get stopped (and in case
> of Bitsquare cannot really).
>
> Maybe 2015 people have not been so nervous about it because it was before
> ETH demonstrated the risk and damage of a HF...
>
> Am Dienstag, 21. März 2017 21:42:07 UTC-5 schrieb Jameson Lopp:
>>
>> I don't think replay protection can be added at the network level. Peers
>> could lie about their software version and/or switch it, plus it's highly
>> likely that a chain split won't result in a clean network partition.
>> Transactions will get relayed around the network comprised of nodes on both
>> chains and you can expect that Core nodes would still relay transactions to
>> you that were originally broadcast by Unlimited nodes and vice versa.
>>
>> At a more philosophical level, I'm not so sure that the onus is on every
>> wallet provider to implement protection against contentious hard forks. You
>> could have made similar arguments that BitcoinJ should have added replay
>> protection when support for 8MB blocks was nearing 50% hashrate back in
>> 2015.
>>
>> On Tue, Mar 21, 2017 at 8:28 PM, Manfred Karrer 
>> wrote:
>>
>>> Btw. of course the whitelist can be set by the user himself, so if he
>>> runs a full node he can use that.
>>> But knowing that the majority of users are not running their own full
>>> node we need alternative solutions as well.
>>>
>>>
>>> Am Dienstag, 21. März 2017 19:23:56 UTC-5 schrieb Manfred Karrer:

 Andreas, how are you planning to protect users of the Android wallet
 agains replay attacks?
 How does a user know if she/he can send his wallet coins to a peer who
 accepts only BTC or BTU (e.g. exchange)? Otherwise he might end up pretty
 frustrated to see outgoing transactions at this wallet but not confirmation
 of receipt at the receiver.

 You cannot assume that all your users are blindly following the longest
 PoW chain as the only valid BTC chain and ignore the replay attack risks.
 There might be even legal issues connected to it (see ETH HF and losses
 from replay attacks), probably less for a wallet provider than for a
 centralized exchange holding customers funds. But I am not sure if that
 would not fall back to others as well (due diligence), at least people
 could try to sue...

 One of the easiest solution I see is to deploy a whitelist of Bitcoin
 Core nodes and use those for the P2P network connections.
 You can give the user the choice to select between whitelist Bitcoin
 Core nodes (if he wants BTC), whitelist BU nodes (i he wants BTU) or public
 network (if he thinks all plays out by itself and is aware of the included
 risk/mess).
 Of course a whitelist is not great as well but that would solve the
 problem that we cannot know in advance the data which helps us to
 distinguish between the chains (like blockID or certain transactions). That
 whitelist only need to be used as long the HF is messy, once things have
 settled it can be removed or replaced by other distinguishing data sources
 like blockIds.

 If BTU implements a clean mechanism to make it easy to distinguish that
 would be the best solution of course but I am not aware of any concrete
 plans for such.


 Am Mittwoch, 15. März 2017 06:08:55 UTC-5 schrieb Andreas Schildbach:
>
> 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:
> > 

Re: Any plans how to deal with a potential BU fork?

[Jameson Lopp]

I don't think replay protection can be added at the network level. Peers
could lie about their software version and/or switch it, plus it's highly
likely that a chain split won't result in a clean network partition.
Transactions will get relayed around the network comprised of nodes on both
chains and you can expect that Core nodes would still relay transactions to
you that were originally broadcast by Unlimited nodes and vice versa.

At a more philosophical level, I'm not so sure that the onus is on every
wallet provider to implement protection against contentious hard forks. You
could have made similar arguments that BitcoinJ should have added replay
protection when support for 8MB blocks was nearing 50% hashrate back in
2015.

On Tue, Mar 21, 2017 at 8:28 PM, Manfred Karrer 
wrote:

> Btw. of course the whitelist can be set by the user himself, so if he runs
> a full node he can use that.
> But knowing that the majority of users are not running their own full node
> we need alternative solutions as well.
>
>
> Am Dienstag, 21. März 2017 19:23:56 UTC-5 schrieb Manfred Karrer:
>>
>> Andreas, how are you planning to protect users of the Android wallet
>> agains replay attacks?
>> How does a user know if she/he can send his wallet coins to a peer who
>> accepts only BTC or BTU (e.g. exchange)? Otherwise he might end up pretty
>> frustrated to see outgoing transactions at this wallet but not confirmation
>> of receipt at the receiver.
>>
>> You cannot assume that all your users are blindly following the longest
>> PoW chain as the only valid BTC chain and ignore the replay attack risks.
>> There might be even legal issues connected to it (see ETH HF and losses
>> from replay attacks), probably less for a wallet provider than for a
>> centralized exchange holding customers funds. But I am not sure if that
>> would not fall back to others as well (due diligence), at least people
>> could try to sue...
>>
>> One of the easiest solution I see is to deploy a whitelist of Bitcoin
>> Core nodes and use those for the P2P network connections.
>> You can give the user the choice to select between whitelist Bitcoin
>> Core nodes (if he wants BTC), whitelist BU nodes (i he wants BTU) or public
>> network (if he thinks all plays out by itself and is aware of the included
>> risk/mess).
>> Of course a whitelist is not great as well but that would solve the
>> problem that we cannot know in advance the data which helps us to
>> distinguish between the chains (like blockID or certain transactions). That
>> whitelist only need to be used as long the HF is messy, once things have
>> settled it can be removed or replaced by other distinguishing data sources
>> like blockIds.
>>
>> If BTU implements a clean mechanism to make it easy to distinguish that
>> would be the best solution of course but I am not aware of any concrete
>> plans for such.
>>
>>
>> Am Mittwoch, 15. März 2017 06:08:55 UTC-5 schrieb Andreas Schildbach:
>>>
>>> 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
>>> > .
>>> > 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.
>

-- 
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.

Re: Any plans how to deal with a potential BU fork?

[Manfred Karrer]

Btw. of course the whitelist can be set by the user himself, so if he runs 
a full node he can use that. 
But knowing that the majority of users are not running their own full node 
we need alternative solutions as well.


Am Dienstag, 21. März 2017 19:23:56 UTC-5 schrieb Manfred Karrer:
>
> Andreas, how are you planning to protect users of the Android wallet 
> agains replay attacks? 
> How does a user know if she/he can send his wallet coins to a peer who 
> accepts only BTC or BTU (e.g. exchange)? Otherwise he might end up pretty 
> frustrated to see outgoing transactions at this wallet but not confirmation 
> of receipt at the receiver.
>
> You cannot assume that all your users are blindly following the longest 
> PoW chain as the only valid BTC chain and ignore the replay attack risks.
> There might be even legal issues connected to it (see ETH HF and losses 
> from replay attacks), probably less for a wallet provider than for a 
> centralized exchange holding customers funds. But I am not sure if that 
> would not fall back to others as well (due diligence), at least people 
> could try to sue...
>
> One of the easiest solution I see is to deploy a whitelist of Bitcoin 
> Core nodes and use those for the P2P network connections. 
> You can give the user the choice to select between whitelist Bitcoin 
> Core nodes (if he wants BTC), whitelist BU nodes (i he wants BTU) or public 
> network (if he thinks all plays out by itself and is aware of the included 
> risk/mess).
> Of course a whitelist is not great as well but that would solve the 
> problem that we cannot know in advance the data which helps us to 
> distinguish between the chains (like blockID or certain transactions). That 
> whitelist only need to be used as long the HF is messy, once things have 
> settled it can be removed or replaced by other distinguishing data sources 
> like blockIds.
>
> If BTU implements a clean mechanism to make it easy to distinguish that 
> would be the best solution of course but I am not aware of any concrete 
> plans for such.
>
>
> Am Mittwoch, 15. März 2017 06:08:55 UTC-5 schrieb Andreas Schildbach:
>>
>> 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 
>> > . 
>> > 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.

Re: Any plans how to deal with a potential BU fork?

[Manfred Karrer]

Andreas, how are you planning to protect users of the Android wallet agains 
replay attacks? 
How does a user know if she/he can send his wallet coins to a peer who 
accepts only BTC or BTU (e.g. exchange)? Otherwise he might end up pretty 
frustrated to see outgoing transactions at this wallet but not confirmation 
of receipt at the receiver.

You cannot assume that all your users are blindly following the longest PoW 
chain as the only valid BTC chain and ignore the replay attack risks.
There might be even legal issues connected to it (see ETH HF and losses 
from replay attacks), probably less for a wallet provider than for a 
centralized exchange holding customers funds. But I am not sure if that 
would not fall back to others as well (due diligence), at least people 
could try to sue...

One of the easiest solution I see is to deploy a whitelist of Bitcoin 
Core nodes and use those for the P2P network connections. 
You can give the user the choice to select between whitelist Bitcoin 
Core nodes (if he wants BTC), whitelist BU nodes (i he wants BTU) or public 
network (if he thinks all plays out by itself and is aware of the included 
risk/mess).
Of course a whitelist is not great as well but that would solve the problem 
that we cannot know in advance the data which helps us to distinguish 
between the chains (like blockID or certain transactions). That whitelist 
only need to be used as long the HF is messy, once things have settled it 
can be removed or replaced by other distinguishing data sources like 
blockIds.

If BTU implements a clean mechanism to make it easy to distinguish that 
would be the best solution of course but I am not aware of any concrete 
plans for such.


Am Mittwoch, 15. März 2017 06:08:55 UTC-5 schrieb Andreas Schildbach:
>
> 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  
> > . 
> > 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.

Re: Any plans how to deal with a potential BU fork?

[Andreas Schildbach]

Yes, anything that is protected by the POW (aka "commitment"). So a
length header field would do, or a new version number (though version
numbers tend to cause conflicts between branches if they're not
hierarchical).


On 03/21/2017 05:40 PM, Patrick McCorry wrote:
> 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
> >  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
> > > 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
> > >>> 

Re: Any plans how to deal with a potential BU fork?

[Patrick McCorry]

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 
> >  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 
> > > 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 
> > >>>  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 

Re: Any plans how to deal with a potential BU fork?

[Andreas Schildbach]

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
>  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
> > 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
> >>>  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 

Re: Any plans how to deal with a potential BU fork?

[Andreas Schildbach]

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  
> 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
>>  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
>  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 

Re: Any plans how to deal with a potential BU fork?

[Matt Corallo]

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  
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
> 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
  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 

Re: Any plans how to deal with a potential BU fork?

[Andreas Schildbach]

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  
> 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
>>>  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
>>> > .
>>> > 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.
> 


-- 
You received this message because you are subscribed to the Google Groups 
"bitcoinj" group.
To unsubscribe from this group 

Re: Any plans how to deal with a potential BU fork?

[Andreas Schildbach]

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
>  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
> > .
> > 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.


-- 
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.

Re: Any plans how to deal with a potential BU fork?

[Manfred Karrer]

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  > 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 
>>> > . 
>>> > 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.

Re: Any plans how to deal with a potential BU fork?

[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  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  
>> > . 
>> > 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.

-- 
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.

Re: Any plans how to deal with a potential BU fork?

[Tobias B.]

Some crazy idea right here: How about following the chain with the most PoW 
;)

On Tuesday, March 14, 2017 at 6:07:52 PM UTC+1, 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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Any plans how to deal with a potential BU fork?

[Amitabh Saxena]

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  
> > . 
> > 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.

Re: Any plans how to deal with a potential BU fork?

[Andreas Schildbach]

I should add: In the default SPV mode...


On 03/15/2017 12:08 PM, 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+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.

Re: Any plans how to deal with a potential BU fork?

[Andreas Schildbach]

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+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.

Any plans how to deal with a potential BU fork?

[Manfred Karrer]

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