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

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

> --
> You received this message because you are subscribed to the Google
> Groups "bitcoinj" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to bitcoinj+u...@googlegroups.com
> <mailto:bitcoinj+u...@googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout.

[Andreas Schildbach]

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

[Amitabh Saxena]

Will bitcoinj reject larger blocks?

[Tobias B.]

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

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

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

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

> <https://groups.google.com/d/optout>.

[Matt Corallo]

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

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

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

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

[Matt Corallo]

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.

[Patrick McCorry]

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? 

[Andreas Schildbach]

Sorry, I simply don't understand what you mean. To me, this looks like a
recursive definition:

"The fork is caused by the hard fork being contentious"

[Andreas Schildbach]

Afaik no.

[Matt Corallo]

I dont see how that is recursive? Not all hard forks are contentious?

The real concern here is less that there are a few people who may stay
on the old chain, but that exchanges and major merchants are going to
continue to refer to the old chain as BTC, with the new chain getting a
ticker symbol. This rejection of a hashrate-driven hardfork means that
any SPV clients need to provide users an option to select their currency
or will likely lead to users being very confused.

Matt

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

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

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

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

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

To unsubscribe from this group and stop receiving emails from it, send an email to bitcoinj+unsubscribe@googlegroups.com.

[Manfred Karrer]

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? 

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

To unsubscribe from this group and stop receiving emails from it, send an email to bitcoinj+u...@googlegroups.com.

[Andreas Schildbach]

As a start, I've tried to describe the status quo on the limitations page:

https://bitcoinj.github.io/limitations#consensus

Honestly I think protection from replays would need to be built into the
consensus rules. At network level, e.g. dropping nodes based on version
string, I agree with Jameson in that it will be very unreliable.

One option that hasn't been mentioned is using a low fee. As capacity
will shrink drastically on the minority chain, low fee transactions will
likely stay unconfirmed for a long time. However, the winning chain also
will loose some capacity (unless the nature of the fork is increasing
block size of course), so it will be difficult to hit the spot. For this
reason, I don't think this option is reliable either. But at least it
doesn't require any changes to bitcoinj.

IMHO: I don't think the ETH/ETC split can repeat on the Bitcoin
blockchain. The long difficulty intervals, combined with already full
blocks will cause the Bitcoin minority chain die off *much* quicker.

> <https://groups.google.com/d/optout>.

>
>
> --
> You received this message because you are subscribed to the
> Google Groups "bitcoinj" group.
> To unsubscribe from this group and stop receiving emails from
> it, send an email to bitcoinj+u...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout

> <https://groups.google.com/d/optout>.

[Jameson Lopp]

On Wed, Mar 22, 2017 at 1:55 AM, Manfred Karrer <manfred...@gmail.com> 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.

 

To unsubscribe from this group and stop receiving emails from it, send an email to bitcoinj+unsubscribe@googlegroups.com.

[Manfred Karrer]

Unfortunately 0confirmation transactions are used in Bitsquare (there is no risk for double spend as the relevant MultiSig tx requires a confirmation).

So if txs get relayed from both chains I have a problem in Bitsquare ;-(... Damn BU, would love to spend time on more productive stuff....

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

[Tobias B.]

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.

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

> <https://groups.google.com/d/optout>.

>
>
> --
> You received this message because you are subscribed
> to the Google Groups "bitcoinj" group.
> To unsubscribe from this group and stop receiving
> emails from it, send an email to
> bitcoinj+u...@googlegroups.com.
> For more options, visit
> https://groups.google.com/d/optout

> <https://groups.google.com/d/optout>.

>
>
> --
> You received this message because you are subscribed to the
> Google Groups "bitcoinj" group.
> To unsubscribe from this group and stop receiving emails
> from it, send an email to bitcoinj+u...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout

> <https://groups.google.com/d/optout>.

[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

[Manfred Karrer]

To add custom nodes is part of the BitcoinJ API as far I know, at least in Bitsquare that is supported. 

Of course provided whitelist nodes are always problematic, best if the user runs his own nodes. But it the question of what hurst less if there is no perfect solution.

[Manfred Karrer]

Do you have a link to that discussion?

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

[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

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

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

[Manfred Karrer]

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.

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

[Matt Corallo]

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.

[Tobias B.]

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.

[Matt Corallo]

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.

[Tobias B.]

I totally agree that wallets should warn their users.

[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

[Manfred Karrer]

Beside that Satoshi designed mining as vote per CPU and underestimated the issues with centralization in that area. What we have now is a monopoly (Bitmain) on mining hardware and the ability to apply that power for political reasons. If they do that or not is not relevant, just that they could do it is a problem.

Miners today has monopolistic cartel structure not much different to classical one like the OPEC or Telkoms.

So the original design got lost quite a lot in that area. Which for me personally is a signal that we should try to fix that as long it is not too late by changing PoW to a solution which give at least a higher level of decentralization (considering decentralization as scale not binary).

But sorry don't want to derail that thread with politics.

So far I don't see any satisfying solution. Bad. Hope we don't need to deal with it.

Bitsquare will try to move over to use Bitcoin Core SPV [1] midterm to avoid some of the issues from BitcoinJs broken SPV model (specially bloom filters privacy issues). 

[1] https://github.com/bitcoin/bitcoin/pull/9483