These BCH are now recoverable; please read the update at the end of the post!

 
 

Background

In the short while since segwit activated on the BTC network and segwit addresses even-more-recently became the default for receiving BTC in the Trezor wallet - and perhaps other wallets too (soon?) - people have started accidentally sending their BCH to BTC-segwit addresses.
 
Due to the fact(s) that...
a) the BCH network supports P2SH (i.e. addresses starting with 3), but not segwit
... and ...
b) the sending wallets thus have no way of knowing that P2SH-wrapped segwit addresses really are "hiding" a segwit redeemscript
... people are losing access to their BCH, there's currently no way to prevent this, and it will continue happening.
 

Examples

(These are just the ones that I've noticed, but I'm sure there are many more that go straight to the various wallet service providers' support teams instead of via Reddit.)

• https://np.reddit.com/TREZOcomments/70a48q/accidentally_sent_bch_to_a_btc_address_is_there/
• https://np.reddit.com/TREZOcomments/6zsz6t/help_i_sent_bitcoincash_to_my_bitcoin_wallet/
• https://np.reddit.com/TREZOcomments/6zlagx/noob_needs_helpby_mistake_send_bitcoin_cash_bch/
• https://np.reddit.com/TREZOcomments/6wm3re/sent_bch_to_wrong_address_help/
• https://np.reddit.com/TREZOcomments/6wuufp/i_sent_bch_to_a_btc_address_by_mistake/
• https://np.reddit.com/TREZOcomments/6wz4ft/how_to_recover_bitcoin_cash_which_are_wrongly/
• https://np.reddit.com/TREZOcomments/6y5juv/sent_bch_to_btc_wallet_by_accident_help/
• https://np.reddit.com/TREZOcomments/6y2ili/transferred_bcc_to_btc_wallet_how_to_cancel/
• https://np.reddit.com/TREZOcomments/6y0643/newbie_mistake_send_bch_to_btc_trezor_address/
• https://np.reddit.com/TREZOcomments/6xzng0/imanidiot_sent_bitcoin_cash_to_bitcoin_address/
• https://np.reddit.com/Bitcoincash/comments/6szojj/bitcoincash_accidentally_sent_to/
• https://np.reddit.com/Bitcoin/comments/6sfnl2/segwit_has_been_locked_in_congratulations_everyone/dlvkhsi/

 
To add insult to injury, the unlucky BCH owners are routinely told that there's no way to recover the coins (including by myself at the start) due to BCH not supporting segwit. And while that's currently true, it is ultimately only a half-truth.
After all, segwit opponents have often said that the satoshis in segwit addresses would be "anyone-can-spend" if the miners didn't enforce the segwit rules (i.e. ensuring that there's a proper witness/signature in the "segregated" part of the txs).
And on the BCH network the segwit rules aren't being enforced!
 

A Partial Solution

So I did some digging (e.g. in the segwit documentation and P2SH specification, BIP16) and came to the conclusion, which I'm sure that many have before me, that in order to spend money sent to a P2SH-wrapped segwit address, you only need to know the public key of the address (or more precisely: the RIPEMD160 hash of the SHA256 hash of a the public key).
Yes, a hash derived from the public key, not the private key.
Luckily, the 3-addresses don't by themselves reveal this public key hash, or anyone could've made "signed" txs from these "BCH-segwit" addresses - and someone probably already would have.
 

More Problems

So, given that it's relatively easy (for a technically inclined person, anyway) to get the public key corresponding to an address from their BIP39 mnemonic (aka wallet recovery seed), why aren't people re-claiming their BCH from these addresses?
Well, the "signature" that's needed isn't really a digital signature in the normal sense. Regular cryptocurrency transactions include a digital signature that doesn't reveal the private key that was used to make the signature in question. What's needed to "sign" for BCH-segwit addresses, however, is just literally including the public key hash that was mentioned above instead of a proper digital signature.
This means that anyone who sees such a transaction can just extract the public key hash from it - and then go on to create a conflicting transaction, using the same public key hash, that sends the same money elsewhere (to themselves, I would presume).
Technically, the second transaction would be a double-spend of the original and, as with all double-spends, it's the miners that would be the final arbiters of which transaction gets recorded in the block chain.
Additionally, a malicious miner could just create their own version of the transaction, either overtly redirecting the money to themselves, or covertly by changing the transaction to have no monetary outputs (i.e. all the money would go to the miner as "fee").
But the problems don't stop there. These segwit-spending transactions would be non-standard and as such wouldn't be relayed to the miners in the first place, nor would it be mined by miners even if it reached them (provided that the nodes and miners run with the default policy of ignoring non-standard txs, that is).
 

Suggested Solution

What we need is one or more trustworthy (yes, trust would unfortunately be required) miners to step up and make a BCH Segwit-Recovery Service for this particular purpose, in a somewhat similar way that they provided acceleration services for the BTC network (example1 and example2).
 
So... Does anyone know if a) miners are already working on this or b) know how to get in touch with them about this?
Or are there any benevolent miners here, that would like to:

• get good publicity and community goodwill by helping with these "segwit casualties"
• earn a decent fee for this service (e.g. 10 %, but this can be announced and enforced by the service itself - it only needs the public key (or its hash) to generate and mine a transaction, including a ToS-compliant fee)
• improve confidence in BCH by giving more security to the end-users

 
/btc users, feel free to notify any miner contacts you may have - let's make this happen!
 
 

Update 1 (2017-09-11)

I made a proof-of-concept frontend to "show" what I'm envisioning such a service would look like for the end users (obviously it's ugly and needs to include javascript for key/hash/address validation, etc., but it should get the intention across), here:
https://btctroubadour.github.io/bch-recovery.html

Update 2 (2017-11-21)

It looks like some greyhat/vigilante, working with an unknown miner, was able to unilaterally claim some of the BCH that were "stuck" in BTC-segwit addresses (namely, the ones for which the public keys were revealed by the owners spending BTC from the same addresses), as explained in this post and comments: https://np.reddit.com/Bitcoin/comments/7eixcu/recovering_bch_sent_to_segwit_addresses/
For those that are affected by this, it means you no longer control your BCH (they were "stolen" by the greyhat), but he seems to be offering to give them back if you agree to letting him keep 30 % for his service (or "service", however you look at it). Either way, and given the alternative (100 % loss), you should certainly check if you're affected and decide how you want to proceed. As if that wasn't enough to deal with, there seems to be a ~2 week deadline, until "December 5th, 2017 at 23:59:59 UTC", after which it seems he's decided he's entitled to keep your money. :(

Update 3 (2017-11-28)

It looks like the greyhat has turned white! He's now offering to give back, for free, any and all BCH that were transferred to him (yes, 100 %!). Read his new update post and check if you were affected by this transfer.

Update 4 (2017-12-05)

Benevolent BCH miner finally found! The good people at btc.com have announced an automated BCH-segwit-recovery service, just as I outlined in my original post. Thanks a lot to Stellaluna19 for bringing it to my attention.
Here are links to btc.com's Twitter announcement as well as the recovery service itself:
https://twitter.com/btccom_official/status/933682190424199169
https://bch.btc.com/docs/help/bch_segwit_recovery
(Note that SatoshiLabs/Trezor developer, and well-known whitehat, -johoe have suggested some improvements to secure the process outlined by btc.com. You can read his suggestions in the last paragraph of this post - or in this one.)

shaolinfry on Mar 12 2017:
I recently posted about so called "user activated soft forks" and received a lot of feedback. Much of this was how such methodologies could be applied to segwit which appears to have fallen under the miner veto category I explained in my original proposal, where there is apparently a lot of support for the proposal from the economy, but a few mining pools are vetoing the activation.
It turns out Bitcoin already used flag day activation for P2SH[1], a soft fork which is remarkably similar to segwit. The disadvantage of a UASF for segwit is there is an existing deployment. A UASF would require another wide upgrade cycle (from what I can see, around 80% of existing nodes have upgraded from pre-witness, to NODE_WITNESS capability[2][3]. While absolute node count is meaningless, the uprgrade trend from version to version seems significant.
Also it is quite clear a substantial portion of the ecosystem industry has put in time and resources into segwit adoption, in the form of upgrading wallet code, updating libraries and various other integration work that requires significant time and money. Further more, others have built systems that rely on segwit, having put significant engineering resources into developing systems that require segwit - such as several lightning network system. This is much more significant social proof than running a node.
The delayed activation of segwit is also holding back a raft protocol of innovations such as MAST, Covenants, Schnorr signature schemes and signature aggregation and other script innovations of which, much of the development work is already done.
A better option would be to release code that causes the existing segwit deployment to activate without requiring a completely new deployment nor subject to hash power veto. This could be achieved if the economic majority agree to run code that rejects non-signalling segwit blocks. Then from the perspective of all existing witness nodes, miners trigger the BIP9 activation. Such a rule could come into effect 4-6 weeks before the BIP9 timeout. If a large part of the economic majority publicly say that they will adopt this new client, miners will have to signal bip9 segwit activation in order for their blocks to be valid.
I have drafted a BIP proposal so the community may discuss https://gist.github.com/shaolinfry/743157b0b1ee14e1ddc95031f1057e4c (full text below).
References:
Proposal text:
BIP: bip-segwit-flagday Title: Flag day activation for segwit deployment Author: Shaolin Fry Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-???? Status: Draft Type: Informational Created: 2017-03-12 License: BSD-3-Clause CC0-1.0 ==Abstract== This document specifies a BIP16 like soft fork flag day activation of the segregated witness BIP9 deployment known as "segwit". ==Definitions== "existing segwit deployment" refer to the BIP9 "segwit" deployment using bit 1, between November 15th 2016 and November 15th 2017 to activate BIP141, BIP143 and BIP147. ==Motivation== Cause the mandatory activation of the existing segwit deployment before the end of midnight November 15th 2017. ==Specification== All times are specified according to median past time. This BIP will be activate between midnight October 1st 2017 (epoch time 1538352000) and midnight November 15th 2017 (epoch time 1510704000) if the existing segwit deployment is not activated before epoch time 1538352000. This BIP will cease to be active when the existing segwit deployment activates. While this BIP is active, all blocks must set the nVersion header top 3 bits to 001 together with bit field (1<<1) (according to the existing segwit deployment). Blocks that do not signal as required will be rejected. === Reference implementation === // mandatory segwit activation between Oct 1st 2017 and Nov 15th 2017 inclusive if (pindex->GetMedianTimePast() >= 1538352000 && pindex->GetMedianTimePast() <= 1510704000 && !IsWitnessEnabled(pindex->pprev, chainparams.GetConsensus())) { if (!((pindex->nVersion & VERSIONBITS_TOP_MASK) == VERSIONBITS_TOP_BITS) && (pindex->nVersion & VersionBitsMask(params, Consensus::DEPLOYMENT_SEGWIT)) != 0) { return state.DoS(2, error("ConnectBlock(): relayed block must signal for segwit, please upgrade"), REJECT_INVALID, "bad-no-segwit"); } } ==Backwards Compatibility== This deployment is compatible with the existing "segwit" bit 1 deployment scheduled between midnight November 15th, 2016 and midnight November 15th, 2017. ==Rationale== Historically, the P2SH soft fork (BIP16) was activated using a predetermined flag day where nodes began enforcing the new rules. P2SH was successfully activated with relatively few issues By orphaning non-signalling blocks during the last month of the BIP9 bit 1 "segwit" deployment, this BIP can cause the existing "segwit" deployment to activate without needing to release a new deployment. ==References== [https://github.com/bitcoin/bitcoin/blob/v0.6.0/src/main.cpp#L1281-L1283 P2SH flag day activation]. ==Copyright== This document is placed in the public domain.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170312/6e8cc65a/attachment-0001.html
original: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-March/013714.html

I'll get straight to the point. This recent bad luck has been draining the buffer pretty hard. I'm not sure if it is just normal 'Bad' luck, or if it's a problem with the Bip16 patches. Mainly the vinced mm patch.
A month ago, when the voting for Bip16 was going on, I was working with Gavin, testing his patches, but they where throwing errors on some solved shares.
I've been watching the logs live for the past week, and haven't seen any errors but still not exactly sure If I trust the patches. I've decided to temporarily disable Merged Mining (So no Namecoin mining) to run against the latest bitcoind. Your nmc balance will still be there, payouts will still work.
After the outage last month, I've convinced our host to give us 2 months rent free. This is a small burden off the server costs but won't last forever. If you can spare a few bitcoin, any little bit helps, it would be most appreciated.
As Always Thanks, RR

Luke Dashjr on Apr 04 2017:
Recently there has been some discussion of an apparent work-in-progress
extension block proposal by Christopher Jeffrey, Joseph Poon, Fedor Indutny,
and Steven Pair. Since this hasn't been formally posted on the ML yet, perhaps
it is still in pre-draft stages and not quite ready for review, but in light
of public interest, I think it is appropriate to open it to discussion, and
toward this end, I have reviewed the current revision.
For reference, the WIP proposal itself is here:

https://github.com/tothemoon-org/extension-blocks 

==Overall analysis & comparison==
This is a relatively complicated proposal, creating a lot of additional
technical debt and complexity in comparison to both BIP 141 and hardforks. It
offers no actual benefits beyond BIP 141 or hardforks, so seems irrational to
consider at face value. In fact, it fits much better the inaccurate criticisms
made by segwit detractors against BIP 141.
That being said, this proposal is very interesting in construction and is for
the most part technically sound. While ill-fit to merely making blocks larger,
it may be an ideal fit for fundamentally different block designs such as
Rootstock and MimbleWimble in absence of decentralised non-integrated
sidechains (extension blocks are fundamentally sidechains tied into Bitcoin
directly).
==Fundamental problem==
Extension blocks are a risk of creating two classes of "full nodes": those
which verify the full block (and are therefore truly full nodes), and those
which only verify the "base" block. However, because the extension is
consensus-critical, the latter are in fact not full nodes at all, and are left
insecure like pseudo-SPV (not even real SPV) nodes. This technical nature is
of course true of a softfork as well, but softforks are intentionally designed
such that all nodes are capable of trivially upgrading, and there is no
expectation for anyone to run with pre-softfork rules.
In general, hardforks can provide the same benefits of an extension block, but
without the false expectation and pointless complexity.
==Other problems & questions==

These outpoints may not be spent inside the mempool (they must be redeemed

from the next resolution txid in reality).
This breaks the ability to spend unconfirmed funds in the same block (as is
required for CPFP).
The extension block's transaction count is not cryptographically committed-to
anywhere. (This is an outstanding bug in Bitcoin today, but impractical to
exploit in practice; however, exploiting it in an extension block may not be
as impractical, and it should be fixed given the opportunity.)

The merkle root is to be calculated as a merkle tree with all extension

block txids and wtxids as the leaves.
This needs to elaborate how the merkle tree is constructed. Are all the txids
followed by all the wtxids (tx hashes)? Are they alternated? Are txid and
wtxid trees built independently and merged at the tip?

Output script code aside from witness programs, p2pkh or p2sh is considered

invalid in extension blocks.
Why? This prevents extblock users from sending to bare multisig or other
various possible destinations. (While static address forms do not exist for
other types, they can all be used by the payment protocol.)
Additionally, this forbids datacarrier (OP_RETURN), and forces spam to create
unprovably-unspendable UTXOs. Is that intentional?

The maximum extension size should be intentionally high.

This has the same "attacks can do more damage than ordinary benefit" issue as
BIP141, but even more extreme since it is planned to be used for future size
increases.

Witness key hash v0 shall be worth 1 point, multiplied by a factor of 8.

What is a "point"? What does it mean multiplied by a factor of 8? Why not just
say "8 points"?

Witness script hash v0 shall be worth the number of accurately counted

sigops in the redeem script, multiplied by a factor of 8.
Please define "accurately counted" here. Is this using BIP16 static counting,
or accurately counting sigops during execution?

To reduce the chance of having redeem scripts which simply allow for garbage

data in the witness vector, every 73 bytes in the serialized witness vector is
worth 1 additional point.
Is the size rounded up or down? If down, 72-byte scripts will carry 0
points...)
==Trivial & process==
BIPs must be in MediaWiki format, not Markdown. They should be submitted for
discussion to the bitcoin-dev mailing list, not social media and news.

Layer: Consensus (soft-fork)

Extension blocks are more of a hard-fork IMO.

License: Public Domain

BIPs may not be "public domain" due to non-recognition in some jurisdictions.
Can you agree on one or more of these?
https://github.com/bitcoin/bips/blob/mastebip-0002.mediawiki#Recommended_licenses

Abstract

This specification defines a method of increasing bitcoin transaction

throughput without altering any existing consensus rules.
This is inaccurate. Even softforks alter consensus rules.

Motivation

Bitcoin retargetting ensures that the time in between mined blocks will be

roughly 10 minutes. It is not possible to change this rule. There has been
great debate regarding other ways of increasing transaction throughput, with
no proposed consensus-layer solutions that have proven themselves to be
particularly safe.
Block time seems entirely unrelated to this spec. Motivation is unclear.

Extension blocks leverage several features of BIP141, BIP143, and BIP144 for

transaction opt-in, serialization, verification, and network services, and as
such, extension block activation entails BIP141 activation.
As stated in the next paragraph, the rules in BIP 141 are fundamentally
incompatible with this one, so saying BIP 141 is activated is confusingly
incorrect.

This specification should be considered an extension and modification to

these BIPs. Extension blocks are not compatible with BIP141 in its current
form, and will require a few minor additional rules.
Extension blocks should be compatible with BIP 141, there doesn’t appear to be
any justification for not making them compatible.

This specification prescribes a way of fooling non-upgraded nodes into

believing the existing UTXO set is still behaving as they would expect.
The UTXO set behaves fundamentally different to old nodes with this proposal,
albeit in a mostly compatible manner.

Note that canonical blocks containing entering outputs MUST contain an

extension block commitment (all zeroes if nothing is present in the extension
block).
Please explain why in Rationale.

Coinbase outputs MUST NOT contain witness programs, as they cannot be

sweeped by the resolution transaction due to previously existing consensus
rules.
Seems like an annoying technical debt. I wonder if it can be avoided.

The genesis resolution transaction MAY also include a 1-100 byte pushdata in

the first input script, allowing the miner of the genesis resolution to add a
special message. The pushdata MUST be castable to a true boolean.
Why? Unlike the coinbase, this seems to create additional technical debt with
no apparent purpose. Better to just have a consensus rule every input must be
null.

The resolution transaction's version MUST be set to the uint32 max (`2³² -

1`).
Transaction versions are signed, so I assume this is actually simply -1.
(While signed transaction versions seemed silly to me, using it for special
cases like this actually makes sense.)

Exiting the extension block

Should specify that spending such an exit must use the resolution txid, not
the extblock's txid.

On the policy layer, transaction fees may be calculated by transaction cost

as well as additional size/legacy-sigops added to the canonical block due to
entering or exiting outputs.
BIPs should not specify policy at all. Perhaps prefix "For the avoidance of
doubt:" to be clear that miners may perform any fee logic they like.

Transactions within the extended transaction vector MAY include a witness

vector using BIP141 transaction serialization.
Since extblock transactions are all required to be segwit, why wouldn't this
be mandatory?

• BIP141's nested P2SH feature is no longer available, and no longer a

consensus rule.
Note this makes adoption slower: wallets cannot use the extblock until the
economy has updated to support segwit-native addresses.

To reduce the chance of having redeem scripts which simply allow for garbage

data in the witness vector, every 73 bytes in the serialized witness vector is
worth 1 additional point.
Please explain why 73 bytes in Rationale.

This leaves room for 7 future soft-fork upgrades to relax DoS limits.

How so? Please explain.

A consensus dust threshold is now enforced within the extension block.

Why?

If the second highest transaction version bit (30th bit) is set to to 1

within an extension block transaction, an extra 700-bytes is reserved on the
transaction space used up in the block.
Why wouldn't users set this on all transactions?

default_witness_commitment has been renamed to

default_extension_commitment and includes the extension block commitment
script.
default_witness_commitment was never part of the GBT spec. At least describe
what this new key is.

• Deployment name: extblk (appears as !extblk in GBT).

Should be just extblk if backward compatibility is supported (and !extblk
when not).

The "deactivation" deployment'...[message truncated here by reddit bot]...

original: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-April/013981.html