Make protected transactions mandatory on UAHF chain (and enforce SCRIPT_VERIFY_STRICTENC)

[ftrader]

This enforces the use of SIGHASH_FORKID and SCRIPT_VERIFY_STRICTENC on by UAHF-compatible clients once the fork has activated.

It makes the OP_RETURN protection obsolete, but it is not removed in order to avoid a hard fork change w.r.t. existing deployments.

The strengthening of replay protections is a feature requested by miners and exchanges to protect Bitcoin users from accidental loss and theft of their Bitcoin Cash.

[NiKiZe]

This means that no existing clients at all will be compatible with the fork? I've asked about this before and then got the clear answer that it will stay compatible.

[digitsu]

I don't think this should be mandatory. If you want to protect an outgoing txn then by all means do so. But forcing clients to do so excludes most hardware wallets from being used on BitcoinCash out of the box. Besides, a replayed legacy txn being received only has the effect of losing potential legacy BTC for the sender. As the onus is on the sender to not do something that can potentially lose them BTC (and not BitcoinCash as the comment implies) opt-in protection is sufficient.

[gandrewstone]

I disagree with this change. ETH/ETC replay made a momentary news splash and then it was no big deal. I am too busy working on code to enumerate all the reasons but I'm sure other people will do so.

And we are 8 days to the split and still contemplating design changes!?

[ftrader]

We have weighed this decision before making this change proposal, which I believe is in the interest of existing Bitcoin users. All this means is that businesses and users who have not upgraded their software and systems will be protected from replay ab initio.

We recognize that not everyone will be ready to support the new format on August 1 2017, but we believe that since the SIGHASH_FORKID protection is based on BIP143, a large number of clients can be adapted relatively soon to sign in a compatible way.

This means that no existing clients at all will be compatible with the fork?

Electrum Cash will support the protections already, and we are in touch with other client (and wallet) developers to ensure adoption.

[gandrewstone]

Who is "we"? I am concerned that there seems to be no formal decision making process here.

[deadalnix]

This has been an almost unanimous reaction from all market actors that talked to us. Miners, payment processors and merchants. This is obviously not 100% of the actors in the space, but I think it is fair to assume actors that reached to us are among the most aware of what's going on than average, so if this is a problem to them, this will be a bigger problem for others.

@digitsu as you mention hardware wallet, know that trezor has been open to add BCC support, and is also asking for replay protection. I think playing nicely with people like trezor is in the best interest of both parties.

@gandrewstone The change is made as a soft fork to avoid panic upgrade a few day before the date. It is why we are keeping the OP_RETURN protection as well, while it is not really needed anymore with this spec change. There is no need for a panic upgrade.

[gandrewstone]

I'm getting very concerned with the lack of transparency here. This is one of the major issues that many BUers had with Core, and yet here it is happening again. Let us create a decision making process before making major 11th hour decisions.

[digitsu]

There are more hardware wallets than JUST Trezor. You going to support Keepkey and Ledger as well? Did they explain why they want replay protection? I mean this is just for SENDING of new TXNs on BCC chain right?

It’s one thing to grant them their wish but only if it has been sufficiently explained and reasons understood. Not just because they ask for it.

On Jul 24, 2017, at 21:56, deadalnix notifications@github.com wrote:

This has been an almost unanimous reaction from all market actors that talked to us. Miners, payment processors and merchants. This is obviously not 100% of the actors in the space, but I think it is fair to assume actors that reached to us are among the most aware of what's going on than average, so if this is a problem to them, this will be a bigger problem for others.

@digitsu https://github.com/digitsu as you mention hardware wallet, know that trezor has been open to add BCC support, and is also asking for replay protection. I think playing nicely with people like trezor is in the best interest of both parties.

@gandrewstone https://github.com/gandrewstone The change is made as a soft fork to avoid panic upgrade a few day before the date. It is why we are keeping the OP_RETURN protection as well, while it is not really needed anymore with this spec change. There is no need for a panic upgrade.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Bitcoin-UAHF/spec/pull/17#issuecomment-317413976, or mute the thread https://github.com/notifications/unsubscribe-auth/ADo7S9ZO0Rro1RvW-UPqWbceTy_gFUgGks5sRJSEgaJpZM4OhFJ0.

[ftrader]

You going to support Keepkey and Ledger as well?

Yes, if they want to support Bitcoin Cash we absolutely will support them.

[digitsu]

Well that wasn’t what I meant. I mean if you implement mandatory script format change, then these wallets will not be able to use BCC out of the gates. And people with coins on them who want to use BCC will be unable to do so.

On Jul 24, 2017, at 22:36, freetrader notifications@github.com wrote:

You going to support Keepkey and Ledger as well?

Yes, if they want to support Bitcoin Cash we absolutely will support them.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Bitcoin-UAHF/spec/pull/17#issuecomment-317424525, or mute the thread https://github.com/notifications/unsubscribe-auth/ADo7S_ZmGnqbhVLil2UuQrt3psI4mXTRks5sRJ3lgaJpZM4OhFJ0.

[ftrader]

Better to have people wait a little while until their wallet provides an update, rather than losing their Bitcoin Cash because someone created a replayable transaction, whether by accident or intent.

[HostFat]

This can be already useful to extract private keys, offline, from many kind of seeds https://github.com/iancoleman/bip39

As I wrote on slack, I think that developing (forking already working project) a javascript offline signing tool will easily make it possible to already support a larger number of cases.

https://github.com/OutCast3k/coinbin

Maybe there are others.

This isn't strictly related to this issue, but if there is some trusty javascript dev that it is reading now, maybe he can do it.

[digitsu]

Sure but correct me if I’m wrong you can’t lose your Bitcoin Cash if you are using a bitcoin cash node or wallet. What you may lose is your segwitcoins.

The new signature format will keep a txn broadcast from your BitcoinCash wallet from being seen from the Segwitcoin chain, which means that if you managed to try to accidentally pay someone who is expecting Segwitcoin, then they most certainly won’t see the txn. But you have effectively lost your BitcoinCash because they are now sitting in a different address on the BCC chain.

So which scenario are you expecting this to be able to protect client Bitcoin Cash from being lost?

On Jul 24, 2017, at 23:01, freetrader notifications@github.com wrote:

Better to have people wait a little while until their wallet provides an update, rather than losing their Bitcoin Cash because someone created a replayable transaction, whether by accident or intent.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Bitcoin-UAHF/spec/pull/17#issuecomment-317431976, or mute the thread https://github.com/notifications/unsubscribe-auth/ADo7S2a-N1RRl_ZRSkKAuiSgGGWz5D-aks5sRKPVgaJpZM4OhFJ0.

[deadalnix]

Sure but correct me if I’m wrong you can’t lose your Bitcoin Cash if you are using a bitcoin cash node or wallet. What you may lose is your segwitcoins.

Same works both way. If you use a Segwit Coin compatible software, you can't lose your Segwit Coin, but you can lose your Bitcoin Cash. This is creating a lot of confusion in the space. We are getting a lot of traction, so we need to act professionally. Creating chaos is fun, but doesn't foster trust.

[digitsu]

So you are agreeing with me. The wording Freetrader used is incorrect.

I honestly don’t care if anyone loses segwitcoin. I do care if people lost BitcoinCash. There doesn’t seem to be anything we can do address that situation because you cannot lose BitcoinCash while using BitcoinCash.

So are you adding this replay protection in some hope that segwitcoin will reciprocate?

On Jul 24, 2017, at 23:22, deadalnix notifications@github.com wrote:

Sure but correct me if I’m wrong you can’t lose your Bitcoin Cash if you are using a bitcoin cash node or wallet. What you may lose is your segwitcoins.

Same works both way. If you use a Segwit Coin compatible software, you can't lose your Segwit Coin, but you can lose your Bitcoin Cash. This is creating a lot of confusion in the space. We are getting a lot of traction, so we need to act professionally. Creating chaos is fun, but doesn't foster trust.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Bitcoin-UAHF/spec/pull/17#issuecomment-317438241, or mute the thread https://github.com/notifications/unsubscribe-auth/ADo7S3K_2-lWClhcye-cnUzDhxTnwtRqks5sRKiXgaJpZM4OhFJ0.

[NiKiZe]

@deadalnix @ftrader If you merge this then it is a altcoin (and needs a port change) that can never become Bitcoin. Indeed a clarification on how to make sure you should construct your transaction for:

1. Spending only on BCC chain
2. Spending only on legacy chain
3. Spending the same transaction on both chains (this must be compatible with all existing clients, otherwise upgrading the network will take to long and cause unnecessary issues)

So better explanations and finalization is needed - not more confusion! On top of that the more tolls that can be created for all 3 of the above scenarios the better.

[deadalnix]

So are you adding this replay protection in some hope that segwitcoin will reciprocate?

No this protection is being added because there is demand for it. It has been explained already, if you are going to ignore these explanation then this discussion is not going to lead anywhere.

@NiKiZe If you think such clarification is useful (I do think it is) then I advice you start working on it. Arguing here is not helping the clarification to write itself.

[ftrader]

The wording Freetrader used is incorrect.

The wording I used was carefully chosen. Yes, people who lose their money because they had in in custody of third parties (who make mistakes or get defrauded) is a real possibility and one we'd like to eliminate by making replay impossible.

[prusnak]

It is in your coin's best interest to have replay protection. Implementing mandatory SIGHASH_FORKID in the hardware wallet firmware is very easy and we will release firmware update promptly.

Not having replay protection is much worse for Bitcoin Cash than it is for Bitcoin.

I honestly don’t care if anyone loses segwitcoin. I do care if people lost BitcoinCash.

@digitsu This is exactly what will happen if you do not implement proper replay protection.

[slush0]

Adding replay protection by using SIGHASH_FORKID is trivial for wallets, even for hardware wallets. We'll happily add it into firmware. But without proper replay protection, it will be complete mess and people will DO lose money on both chains. This will be definitely much worse problem for BCC than for BTC, because you'll be one to blame for this.

Please be responsible and use SIGHASH_FORKID. You'll make less enemies among developers, who'll otherwise need to spend huge effort to fix your poor architecture decisions on application level.

[bitcartel]

BIP148 has no replay protection. Why is UAHF held to a different standard?

[HostFat]

@bitcartel I think that this project can have higher standards than it :)

[roybadami]

Mandatory replay protection would make existing timelocked transactions unspendable on the BCC chain. I think that's enough reason not to do it.

[inaltoasinistra]

@digitsu What about make mandatory the SIGHASH_FORKID only for 1 month after the split?

So users can split their BCC and BTC makeing transactions with their legacy wallets for a while; and hardware wallets will work out of the box with Bitcoin Cash from September.

EDIT: also @roybadami issue is resolved if mandatory SIGHASH_FORKID is temporary

[digitsu]

I believe the onus on not losing BCC is on segwitchain is it not? Because regardless of whatever you do to make mandatory sending of BCC txns, there will ALWAYS be the risk that some third party custodian of BTC will just send the transaction away and effectively send both segwitcoin & BCC together. In that event the simplest solution is to ask the receiver to just refund the txn using their standard segwitcoin wallet OR BCC wallet. If you enforce mandatory replay protection, imagine the case where the receiver using a BCC wallet upon asked to refund the mistaken txn to the custodian, the behaviour is now different depending on whether the receiver is using a BCC wallet or a segwitcoin wallet! Segwitcoins are either going to be ‘stuck’ at the receiver (if he is using a BCC wallet), or both will be refunded (if he is using a segwitcoin wallet).

I’m simply questioning the wisdom of moving ahead with a change, at the eleventh hour because “businesses are demanding it” without actually asking them WHY. Do you know why? Can you elucidate the reasons and the precise failure mode they are trying to prevent. If not, it would be foolish to go ahead with a spec change. If there IS a good failure mode which is clearly defined, and found to be solved with this change, AND it outweighs the negative behaviours that I explained above, (along with the social connotations of BCC becoming an ‘altcoin’) then I would be okay with this change.

I’m simply asking for reasoning behind it and asking if simply due diligence on change request was done.

“because people asked for it” isn’t sufficient alone.

On Jul 25, 2017, at 01:43, freetrader notifications@github.com wrote:

The wording Freetrader used is incorrect.

The wording I used was carefully chosen. Yes, people who lose their money because they had in in custody of third parties (who make mistakes or get defrauded) is a real possibility and one we'd like to eliminate by making replay impossible.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Bitcoin-UAHF/spec/pull/17#issuecomment-317481957, or mute the thread https://github.com/notifications/unsubscribe-auth/ADo7SxGqXA-yQj8r2BYii60ZxjY-z6a5ks5sRMnJgaJpZM4OhFJ0.

[slush0]

@digitsu As you only care about BCC, there's obviously no reason to advocate such protection to you. Things are different for normal users, who, surprisingly, might want to handle both coins at the same time.

You may want to play nicely with people and businesses, if you want it to succeed. Accordingly, you may expect more or less friendly integration of your project to existing infrastructure, like wallets and exchanges.

If you don't care what people or businesses wants, you should not be surprised that those people and businesses won't care about your project and won't give you appropriate support.

Currently, optional replay protection requires non-trivial changes in wallets, to not let people screw with theirs BTC and BCC holdings. We may put some effort into it to make it work smoothly for your chain. That's your motivation to help us make it happen.

Take it or leave it.

[digitsu]

@slush0 While that was a very long and compelling appeal to compassion, I'm still waiting to hear what failure case you are trying to protect against. As you are clearly one of those businesses, would you mind please explaining the use case instead of making appeals to emotion?

On Tue, Jul 25, 2017 at 8:57 AM slush0 notifications@github.com wrote:

@digitsu https://github.com/digitsu As you only care about BCC, there's obviously no reason to advocate such protection for normal users, who, surprisingly, might want to handle both coins at the same time.

You may want to play with players nicely to people and businesses, if you want it to succeed. Accordingly, you may expect more or less friendly integration of your project to existing infrastructure, like wallets and exchanges.

If you don't care what people or businesses wants, you should not be surprised that those people and businesses won't care about your project and won't give you appropriate support.

Currently, optional replay protection requires non-trivial changes in wallets, to not let people screw with their's BTC and BCC holdings. We may put some effort into it to make it work smoothly for your chain. That's your motivation to help us make it happen.

Take it or leave it.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Bitcoin-UAHF/spec/pull/17#issuecomment-317588595, or mute the thread https://github.com/notifications/unsubscribe-auth/ADo7Swi1aBkhO2GPq09NRn4l6QfAynttks5sRS-AgaJpZM4OhFJ0 .

[jlopp]

As we have stated previously, strong 2-way replay protection is an important feature for BitGo with regard to supporting hard forks. https://blog.bitgo.com/bitgos-approach-to-handling-a-hard-fork-71e572506d7d

[JaredR26]

FYI, strong replay protection is absolutely necessary given BCC's different definition of anyone-can-spend. Without it, transactions that properly follow the rules of a different chain entirely will cause innocent users to lose BCC, simply for following the proper rules of that other chain. While I might not care enough to sell my BCC if it is a clean hardfork, if there's some way my normal, acceptable transactions on an unrelated chain can cause my BCC to be stolen, I'll simply sell my BCC to make sure that I gain something out of the farce. BCC needs to make sure that this cannot be done - even if someone manually modifies transactions by hand - or else it is only going to cannibalize its own value by taking coins from innocent potential adopters.

[junderw]

I do care if people lost BitcoinCash.

Let's say Bob is a BitcoinCash supporter, and he wants to send his "Segwit Coin" to an exchange so he can sell it to buy more BitcoinCash.

Bob doesn't understand much about replay protection or whatnot, he is a simple fellow.

The exchange he uses has already upgraded to SegWit. Bob goes to deposit his Segwit Coin and unintentionally also deposits his BitcoinCash. OOPS! Oh well, the exchange was nice and watches for BitcoinCash as well, so he is currently waiting for confirmations on Segwit Coin and BitcoinCash. No biggie, just withdraw the Bitcoin Cash along with the extra that he buys when he sells Segwit Coin! Yay for him!

But wait, someone on BitcoinCash side sees the Segwit output of Bob's replayable transaction, and since it is ANYONE_CAN_PAY on BitcoinCash, Bob's deposit is soon stolen by someone who saw it (anyone really).

The exchange realizes that Bob's deposit of BitcoinCash was stolen, and since their official stance is "well, if you don't split it yourself before depositing, we don't take any responsibility if your coins get stolen on BitcoinCash" Bob's out of luck.

I would say that a complete two-way replay protection as suggested in this PR will help protect BitcoinCash supporters' BitcoinCash coins from seedy individuals who would try to trick non-technical users into sending BitcoinCash/SegWit merged UTXOs to them.

Leaving this hole open will leave many BitcoinCash supporters vulnerable to scams and theft, and only serve to give businesses and exchanges a big headache.

ACK

[HostFat]

From the point of view of a BCC supporter, I think that we can agree that it is possible to upgrade a cryptocurrency with hard forks. Hard forks means that with every upgrade there is a high, and mostly certainly, probability to cut the "old network" from the new. If we agree on both things (upgrading with hard forks and so cutting the old network), then I don't see a huge problem with this kind of modification, it is part of the roadmap that we are already supporting, I guess....

[digitsu]

Jon Underwood:

Sounds like you just described a reason why exchanges should not accept Segwit txns for deposits, as they will suffer fungibility problems on other chains (not just BCC, but any other forks you may or may not know about). And you are asking others to make up for the vulnerabilities to the protocol that Segwit has itself introduced, by making other protocols abide by the segwit ruleset. I expect you may succeed in convincing a couple of projects to comply, but given the decentralized nature of open source, I sense your quest will be ultimately in vain.

BTW, I think it's ANYONE_CAN_SPEND not ANYONE_CAN_PAY.

PS. A interesting side note and FOOD FOR THOUGHT: in your story when the exchange actually "withdraws the BitcoinCash for poor old Bob", THEY are actually taking advantage of ANYONE_CAN_SPEND themselves, the same 'exploit' that you attribute to the bad 'thieves' who supposedly steal the BCC after wards (which of course cannot happen, as it will already be 'stolen' by the exchange. I think it would be productive to try to remove emotionally charged verbiage such as "steal". If you send a segwit txn, then you are literally saying that for ANY chain that doesn't recognize segwit, you are DONATING your coins to whoever else can spend it first.

The more meaningful example is if Bob funded his account with a regular non-segwit txn. Then the exchange simply recognizes both and credits his accounts in both. Same goes for hardware wallets like trezor. If a txn is not specifically BCC (via SEGHASH_FORKID) or Segwit (via the special OP_RETURN code) then credit BOTH balances. Because that is what the sender intends, OR the sender doesn't care, in which case they don't care and the UXTO should move ownership to whoever the next person is, and maybe they may care about BCC or maybe not. That isn't for the protocol to judge.

Let's take a counter argument. Bob wants to send his bitcoins into an exchange to split his coins and sell off his Segwitcoin to buy more BCC. He doesn't know the exchange is running segwit nor does he care. His wallet is upgraded to segwit already and then sends the exchange his BTC. The exchange is also watching both chains as in your example. But as replay protection on BCC will block any txns from non-BCC wallets, this means the exchange expects either BTC or Segwitcoin(already split) to show up on the Segwit Chain. The exchange cannot act as the splitting agent for Bob. The exchange tells Bob, sorry, if you want to be able to access your BCC, you will need to install a new wallet, import the seed from your other wallet (assuming its compatible) and send the BCCs to us specifically, good luck on figuring out how to do that Bob!

As Bob didn't know whether his BTC holdings have been split already (accidentally by way of someone sending him some SegwitCoin to the same address), he wants to 'just let the exchange fix it' for him by sending the exchange all his BTC and let the exchange split his BCC balances for him. But they can't if replay protection is enforced. Bob just gives up trying to use BCC.

If the exchange has done its homework (as all good bitcoin businesses should) and keeping with the policy of protecting client funds, they will NOT use segwit addresses for deposits so that potential coins can be safely and easily split by the exchange. (or anyone else watching both chains for that matter)

NACK

On Tue, Jul 25, 2017 at 12:05 PM Jonathan Underwood < notifications@github.com> wrote:

I do care if people lost BitcoinCash.

Let's say Bob is a BitcoinCash supporter, and he wants to send his "Segwit Coin" to an exchange so he can sell it to buy more BitcoinCash.

Bob doesn't understand much about replay protection or whatnot, he is a simple fellow.

The exchange he uses has already upgraded to SegWit. Bob goes to deposit his Segwit Coin and unintentionally also deposits his BitcoinCash. OOPS! Oh well, the exchange was nice and watches for BitcoinCash as well, so he is currently waiting for confirmations on Segwit Coin and BitcoinCash. No biggie, just withdraw the Bitcoin Cash along with the extra that he buys when he sells Segwit Coin! Yay for him!

But wait, someone on BitcoinCash side sees the Segwit output of Bob's replayable transaction, and since it is ANYONE_CAN_PAY on BitcoinCash, Bob's deposit is soon stolen by someone who saw it (anyone really).

The exchange realizes that Bob's deposit of BitcoinCash was stolen, and since their official stance is "well, if you don't split it yourself before depositing, we don't take any responsibility if your coins get stolen on BitcoinCash" Bob's out of luck.

I would say that a complete two-way replay protection as suggested in this PR will help protect BitcoinCash supporters' BitcoinCash coins from seedy individuals who would try to trick non-technical users into sending BitcoinCash/SegWit merged UTXOs to them.

Leaving this hole open will leave many BitcoinCash supporters vulnerable to scams and theft, and only serve to give businesses and exchanges a big headache.

ACK

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Bitcoin-UAHF/spec/pull/17#issuecomment-317615424, or mute the thread https://github.com/notifications/unsubscribe-auth/ADo7S9F8V1exv7BkfpLzXtZ7J853cDiXks5sRVtjgaJpZM4OhFJ0 .

[digitsu]

Will HSMs not be able to opt-in to the OP_RETURN method for making their non-BCC transactions unrepeatable? If that is the case, then it would have been good to hear that reason from the get go. If the OP_RETURN hashcode method for non-BCC HSM wallets cannot be reasonably implemented in time, then that is a sufficient rational reason to ask for strong replay protection, which is, from the start, what I'm asking for in this discussion.

Is that the case?

On Tue, Jul 25, 2017 at 2:27 PM alpha-coineng notifications@github.com wrote:

The vulnerability in BCC being discussed on this ticket has nothing to do with segwit and still happens if segwit isn't used and would still apply even if segwit did not exist at all.

We get a request from a customer to withdraw coins on the original Bitcoin network. We create a transaction using the HSMs that manage our keys and send it to the network. An attacker copies that transaction to the BCC network and because the BCC network has been programmed by to to also make modifications to its ledger when it sees non-BCC signatures, we then lose the coins.

The same is true with and without segwit and it happens because even though BCC has a new signature type which is intentionally incompatible it still obeys commands from the Bitcoin network as soon as an attacker copies them across. There is little to no legitimate purpose for this. It mostly increases technical debt by forcing BCC to support the old style signatures and enables attacks like this. (Isn't the old signature type also responsible for the "quadratic" bug?).

This attack exists because even though BCC transactions have a new signature type that identifies the correct network the software still contains legacy code to apply Bitcoin changes to this ledger and fails to disable it after the fork.

For many businesses with established security procedures and equipment we will be unable to prevent these losses which your protocol appears to be specifically designed to create.

If BCC is launched with this vulnerability it will be important for us to make sure BCC is not a commercial success in order to reduce our own liability related to these losses. Please demonstrate some professionalism here.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Bitcoin-UAHF/spec/pull/17#issuecomment-317633182, or mute the thread https://github.com/notifications/unsubscribe-auth/ADo7S6apgxIYKRcdUVjDBqRutIg0ooZGks5sRXyqgaJpZM4OhFJ0 .

[HostFat]

What do you think about OP_RETURN method working as opposite way? So that any normal "legacy tx" will work on BCC only IF THERE IS some kind of OP_RETURN text?

On this way, adding support for BCC on wallets/projects will be even easier/faster.

[junderw]

@digitsu How would the user be able to discern if an exchange is using segwit or not if the exchange uses P2SH? Many exchanges already use P2SH for deposits (for multisig) and if they switched to Segwit behind P2SH the user could not possibly know.

You would rather that all BitcoinCash users not use exchanges that utilize multi-sig? Only use exchanges that have P2PKH deposit addresses like Bitstamp did when they got hacked?

BitcoinCash is not usable if every user is required to ask exchanges to reveal the redeemscript before they can rest easy depositing funds.

@HostFat Very good idea. Require the new sighash algorithm UNLESS a specific OP_RETURN is included... hmmm, how about a short magic number (maybe 4 bytes) instead of an unnecessarily long string, while we're at it.

[HostFat]

@junderw I would prefer something like "bitcoincash.org" but I'm sure that someone will be probably against this :D

[junderw]

@HostFat There's no reason for any more than a 4 byte magic number tbh. Anything longer would need to serve another purpose.

[HostFat]

@junderw There are some javascript tools as https://github.com/OutCast3k/coinbin that gives the possibility to sign offline even with OP_RETURN, so even if it short, it must be some "text" that the common user can easily enter on the interface.

[NiKiZe]

If full replay protection is implemented there is a few things that still needs to be supported... existing nLock transactions, and existing wallets which for some reason can't be upgraded (which have funds in them that would be lost if one transaction wasn't accepted on both chains)

[junderw]

@HostFat 4 characters of a-zA-Z0-9 would give over 14 million possibilities, so should be sufficient for a magic number, as long as the 4 characters weren't a common word. 3cPx or something should be fine. Also avoid using only 0-9a-fA-F because some OP_RETURN parsers would view that as 2 bytes instead of 4 ASCII bytes.

@NiKiZe Perhaps only transactions with a non-zero nLocktime are replayable. Seems like a good compromise which doesn't require an extra OP_RETURN.

[ftrader]

@deadalnix : please have a look at my reformulation of 6-2 (based on your review comment)

[inaltoasinistra]

@junderw Some wallets (at least GreenAddress and Electrum) use nLockTime in all the transactions

[kanzure]

Strong replay protection would demonstrate that the BCC maintainers are interested in maintaining a minimum level of security for transactions. It also has the benefit of making a bunch of exchanges quite more willing to participate, and also it signals to your community that hard-forks will be used to loosen rules but not in any sort of way as to encourage money loss against BCC users or potential BCC users.

I am not sure if any of you will find this useful but let's say that strong (on-by-default) replay protection isn't on its own convincing.... so how about also considering an explicit signaling mechanism in transactions for users to opt-out of the on-by-default strong replay protection? In this scenario, users would modify their transactions (to add some signaling detail) and explicitly opt-out of the default replay protection mechanisms. For example, (and I have not evaluated this specific proposal) it could be something like SIGHASH_FORKID requirement unless OP_RETURN specifying a choice to opt-out of replay protection).

[h0jeZvgoxFepBQ2C]

I honestly don’t care if anyone loses segwitcoin.

I can really not understand how someone with this opinion is still allowed to comment here. Such a behaviour is totally unprofessional and shows that some contributors are completely unaware about the risks of their own actions.

If you don't want the hardfork to look like a joke, you should implement replay protection asap and take care that these destructive opinions won't be part of this project anymore - otherwise I can guarantee that this HF is DOA and it would be better for you to not waste your time here and go fishing instead.

Also multiple announcements from exchanges about the non-support of BCC in the last hours are clearly showing that the current way of development is not accepted by the community and I urge you to take the appropriate consequences.

[deadalnix]

@lichtamberg please calm down. People can disagree with each other without considering the other camp evil or retarded or declaring thing DOA. This attitude is stopping right now, one way or another.

[zander]

I didn't realize so many people have a strong opinion on this.

First of all, Github is not a forum. It is for reviews, so people that feel they are not being listened to are probably better off going to an actual forum. Use IRC, email or slack or reddit or something that actually is a forum.

All indications are that companies and long time professionals in the industry are all behind the idea of strong replay protection. So many companies that work with people and Bitcoin payments have stated the same opinion.

People that are interested in the reasons; the utterly simple and straight forward one is this. It makes things clear and easy to people that don't care about technical details, that don't have the level of knowledge to triple check it actually is secure. Because without this replay protection people paying BCC to vendors can loose their BTC. And vice versa, people paying BTC can loose their BCC.
And just as important, people paying SW tx on the BTC chain can loose their coins on BCC to miners which honestly doesn't reflect well on BCC. I don't want to stand behind a coin that steals other peoples coins, if you feel BCC should be allowed to steal coins, I am not your friend.

I fully support the ideas behind this PR and we should have this replay protection in place already as an option, we just have to make it mandatory.

[rubensayshi]

the length of the opreturn is a problem imo,
46 bytes is a significant amount of bytes (~+30% for 1 input, 2 output tx, ~+12% for a 1 input 2 output 2of3 p2sh tx) that needs to be paid for in fees

others have already pointed out that a 4 byte value would be sufficient, hell, make it 8 if you're paranoid, but 46 is a huge overkill!

[deadalnix]

I don't care much about the fact that the anyonecanspend used by segwit is now a problem. People have been warning about this for ages and it was ignored. Some wanted segwit, now they got it, with anyonecanspend, as specified.

I don't care much either about the fee in the OP_RETURN . Bitcoin leadership wanted a fee market, no they got it. If someone is dissatisfied about this situation, here is the wrong place to complain. We are splitting away because stupid decision have been made and this whole fee market story is one of them. There is a good reason the value is big: to avoid colliding with other legit uses of OP_RETURN, of which there are many.

There is no point in repeating both of these arguments. They simply show failure of Bitcoin's leadership and are no concerns to Bitcoin Cash.

My concern is more for average joe, who is going to lose BTC or BCC because he/she doesn't use replay protected txns. Making it mandatory also has the added benefit that it fixes quadratic hashing once and for all, and add signature cover value on all transaction, which is also good to take. Making it mandatory at one point in the future was always on ABC's roadmap. We are just talking about doing it at fork point, which seems to solve numerous concerns from users and businesses.

[zander]

Thanks!

[ftrader]

Thanks for all your input.