Permalink
Browse files

Merge branch '2017_optin_replay' of git://github.com/jcansdale/bitcoi…

…n into 2017_optin_replay_jcansdale
  • Loading branch information...
jgarzik committed Oct 4, 2017
2 parents 28ebbdb + fdc49fb commit a3c41256984bf11d95a560ae89c0fcbadfbe73dc
View
@@ -157,6 +157,11 @@ bool IsStandardTx(const CTransaction& tx, std::string& reason, const bool witnes
return false;
}
if (tx.ReplayProtected()) {
reason = "replay-protected";
return false;
}
return true;
}
@@ -113,3 +113,18 @@ std::string CTransaction::ToString() const
str += " " + tx_out.ToString() + "\n";
return str;
}
bool CTransaction::ReplayProtected() const
{
// scriptAddress: 3Bit1xA4apyzgmFNT2k8Pvnd6zb6TnwcTi, scriptSig: 04148f33be, scriptPubKey: OP_HASH160 6e0b7d51f9f68ba28cc33a6844d41a1880c58a19 OP_EQUAL
static const CScript noReplay =
CScript() << OP_HASH160 << ParseHex("6e0b7d51f9f68ba28cc33a6844d41a1880c58a19") << OP_EQUAL;
for (const auto& txout : this->vout) {
if (txout.scriptPubKey == noReplay) {
return true;
}
}
return false;
}
@@ -347,6 +347,8 @@ class CTransaction
std::string ToString() const;
bool ReplayProtected() const;
bool HasWitness() const
{
for (size_t i = 0; i < vin.size(); i++) {
@@ -797,6 +797,28 @@ BOOST_AUTO_TEST_CASE(test_IsStandard)
t.vout[0].scriptPubKey = CScript() << OP_RETURN;
t.vout[1].scriptPubKey = CScript() << OP_RETURN;
BOOST_CHECK(!IsStandardTx(t, reason));
// scriptAddress: 3Bit1xA4apyzgmFNT2k8Pvnd6zb6TnwcTi, scriptSig: 04148f33be, scriptPubKey: OP_HASH160 6e0b7d51f9f68ba28cc33a6844d41a1880c58a19 OP_EQUAL
t.vout.resize(1);
t.vout[0].scriptPubKey = CScript() << OP_HASH160 << ParseHex("6e0b7d51f9f68ba28cc33a6844d41a1880c58a19") << OP_EQUAL;
BOOST_CHECK(!IsStandardTx(t, reason));
}
BOOST_AUTO_TEST_CASE(test_ReplayProtected)
{
CMutableTransaction t;
// scriptAddress: 3Bit1xA4apyzgmFNT2k8Pvnd6zb6TnwcTi, scriptSig: 04148f33be, scriptPubKey: OP_HASH160 6e0b7d51f9f68ba28cc33a6844d41a1880c58a19 OP_EQUAL
t.vout.resize(1);
t.vout[0].scriptPubKey = CScript() << OP_HASH160 << ParseHex("6e0b7d51f9f68ba28cc33a6844d41a1880c58a19") << OP_EQUAL;
CTransaction tx1(t);
BOOST_CHECK(tx1.ReplayProtected());
// scriptAddress: 3EZT2iZWYCpy1uXX6XtjX429TnsZ3vKvVV, scriptSig: 777777, scriptPubKey: OP_HASH160 8d2b43ea8081126af5bc392612b1471a0c4fe503 OP_EQUAL
t.vout.resize(1);
t.vout[0].scriptPubKey = CScript() << OP_HASH160 << ParseHex("8d2b43ea8081126af5bc392612b1471a0c4fe503") << OP_EQUAL;
CTransaction tx2(t);
BOOST_CHECK(!tx2.ReplayProtected());
}
BOOST_AUTO_TEST_SUITE_END()
View
@@ -3063,6 +3063,9 @@ static bool ContextualCheckBlock(const CBlock& block, CValidationState& state, c
for (const auto& tx : block.vtx)
{
nSigOps += GetLegacySigOpCount(*tx);
if (fSegwitSeasoned && tx->ReplayProtected())
return state.DoS(100, false, REJECT_INVALID, "bad-blk-rptx", false, "replay-protected tx in block");
}
if (nSigOps * WITNESS_SCALE_FACTOR > MaxBlockSigOpsCost(fSegwitSeasoned))
return state.DoS(100, false, REJECT_INVALID, "bad-blk-sigops", false, "out-of-bounds SigOpCount");
@@ -180,15 +180,23 @@ def run_test(self):
# Test hard fork at block 1583
assert_equal(self.height, 584)
b = [self.nodes[0].getblockhash(n) for n in range(1, 10)]
b = [self.nodes[0].getblockhash(n) for n in range(1, 11)]
txids = [self.nodes[0].getblock(h)['tx'][0] for h in b]
spend_tx = [FromHex(CTransaction(), self.nodes[0].getrawtransaction(txid)) for txid in txids]
for tx in spend_tx:
tx.rehash()
large_tx = [self.create_tx(t, 0, 1, length=500000) for t in spend_tx]
self.generate_blocks(998, 4)
spend_tx_extra = spend_tx[:1]
spend_tx_large = spend_tx[1:]
large_tx = [self.create_tx(t, 0, 1, length=500000) for t in spend_tx_large]
# P2SH: 3Bit1xA4apyzgmFNT2k8Pvnd6zb6TnwcTi
noreplay_tx = self.create_tx(spend_tx_extra[0], 0, 0, CScript([OP_HASH160, hex_str_to_bytes("6e0b7d51f9f68ba28cc33a6844d41a1880c58a19"), OP_EQUAL]))
self.generate_blocks(997, 4)
self.generate_blocks(1, 4, txs=[noreplay_tx]) # noreplay-tx is ok
self.generate_blocks(1, 4, "bad-blk-length", txs=[large_tx[0], large_tx[1]]) # block too large
self.generate_blocks(1, 4, txs=[large_tx[0]]) # large txs is ok
@@ -207,6 +215,7 @@ def run_test(self):
assert_equal(self.height, 6584)
self.generate_blocks(1, 4, txs=[large_tx[4], large_tx[5], large_tx[6]]) # large block ok
self.generate_blocks(1, 4, "bad-blk-rptx", txs=[noreplay_tx]) # noreplay-tx is invalid after the fork
def generate_blocks(self, number, version, error = None, txs = []):

37 comments on commit a3c4125

@ebliever

This comment has been minimized.

Show comment
Hide comment
@ebliever

ebliever Oct 4, 2017

If the intent is to force people onto the 2X chain I think this will backfire. News and social media will explain the process for opt-in replay protection, but bitcoin users will also learn how it could have been done, and how this method burdens the legacy chain with bloated UTXO. Users will not favor the chain that is bullying them. Please reconsider and provide automatic (not opt-in) replay protection that does not burden the legacy chain.

ebliever replied Oct 4, 2017

If the intent is to force people onto the 2X chain I think this will backfire. News and social media will explain the process for opt-in replay protection, but bitcoin users will also learn how it could have been done, and how this method burdens the legacy chain with bloated UTXO. Users will not favor the chain that is bullying them. Please reconsider and provide automatic (not opt-in) replay protection that does not burden the legacy chain.

@jgarzik

This comment has been minimized.

Show comment
Hide comment
@jgarzik

jgarzik replied Oct 4, 2017

@ebliever See #120

@mmgen

This comment has been minimized.

Show comment
Hide comment
@mmgen

mmgen Oct 4, 2017

A stupid, ugly hack that fills the Bitcoin blockchain with garbage.

mmgen replied Oct 4, 2017

A stupid, ugly hack that fills the Bitcoin blockchain with garbage.

@nukebloodaxe

This comment has been minimized.

Show comment
Hide comment
@nukebloodaxe

nukebloodaxe Oct 4, 2017

@jgarzik The patch described at #120 has some issues with future proofing, if this method is used as is your chain will need to add an ever-expanding set of version bits, as well as the current chain implementation.
These bits are not free and, eventually, something will break catastrophically due to Human error, allowing leakage between multiple implementations and chains. This is a reason why the incumbent chain implements replay protection so that we can avoid this situation; like BCH and the upcoming Oct 25th hard fork of BTG.

There is not enough time for the entire ecosystem to implement this feature as-is, nor would I expect it to. Furthermore, even if it is implemented it does not prevent the risk of partitioning in all network versions due to false version advertising by BTC1 nodes; which is reckless by anyone's standards, correct identification of a node is vitally important to the overall health of the network. Again, if you make this standard behavior then other incumbents will see this as a legitimate method of interaction with the resulting Segwit2X chain, as you will have set the standard.

nukebloodaxe replied Oct 4, 2017

@jgarzik The patch described at #120 has some issues with future proofing, if this method is used as is your chain will need to add an ever-expanding set of version bits, as well as the current chain implementation.
These bits are not free and, eventually, something will break catastrophically due to Human error, allowing leakage between multiple implementations and chains. This is a reason why the incumbent chain implements replay protection so that we can avoid this situation; like BCH and the upcoming Oct 25th hard fork of BTG.

There is not enough time for the entire ecosystem to implement this feature as-is, nor would I expect it to. Furthermore, even if it is implemented it does not prevent the risk of partitioning in all network versions due to false version advertising by BTC1 nodes; which is reckless by anyone's standards, correct identification of a node is vitally important to the overall health of the network. Again, if you make this standard behavior then other incumbents will see this as a legitimate method of interaction with the resulting Segwit2X chain, as you will have set the standard.

@zanza321

This comment has been minimized.

Show comment
Hide comment
@zanza321

zanza321 Oct 4, 2017

The 1x SegWit Core chain needs to add in some type of replay protection in order for safety of the network.

zanza321 replied Oct 4, 2017

The 1x SegWit Core chain needs to add in some type of replay protection in order for safety of the network.

@ebliever

This comment has been minimized.

Show comment
Hide comment
@ebliever

ebliever Oct 4, 2017

The burden should be on the innovator to provide total replay protection. Think about what precedent this sets. If this is allowed what objection can you put forth to every two-bit altcoin project in the future that forks off your chain and places the same burden on you? And if you don't comply, or your userbase fails to jump through the requisite hoops, they are subjected to replay attacks by opportunist scammers.

ebliever replied Oct 4, 2017

The burden should be on the innovator to provide total replay protection. Think about what precedent this sets. If this is allowed what objection can you put forth to every two-bit altcoin project in the future that forks off your chain and places the same burden on you? And if you don't comply, or your userbase fails to jump through the requisite hoops, they are subjected to replay attacks by opportunist scammers.

@lacksfish

This comment has been minimized.

Show comment
Hide comment
@lacksfish

lacksfish Oct 5, 2017

Who owns the private key to 3Bit1xA4apyzgmFNT2k8Pvnd6zb6TnwcTi?

lacksfish replied Oct 5, 2017

Who owns the private key to 3Bit1xA4apyzgmFNT2k8Pvnd6zb6TnwcTi?

@jheathco

This comment has been minimized.

Show comment
Hide comment
@jheathco

jheathco Oct 5, 2017

@lacksfish no one owns it. It's a P2SH using the following redeem script:

04148f33be

Miners will use this to clean up the UTXO dust.

jheathco replied Oct 5, 2017

@lacksfish no one owns it. It's a P2SH using the following redeem script:

04148f33be

Miners will use this to clean up the UTXO dust.

@JaredR26

This comment has been minimized.

Show comment
Hide comment
@JaredR26

JaredR26 Oct 5, 2017

@lacksfish it is a p2sh address, the scriptsig that matches it is in the code: 04148f33be

Anyone can spend the outputs with that data, so no one owns it. @jcansdale ran a script for several days grinding potential p2sh addresses to find ones that stood out visually; This was one of the least contentious and most obvious.

JaredR26 replied Oct 5, 2017

@lacksfish it is a p2sh address, the scriptsig that matches it is in the code: 04148f33be

Anyone can spend the outputs with that data, so no one owns it. @jcansdale ran a script for several days grinding potential p2sh addresses to find ones that stood out visually; This was one of the least contentious and most obvious.

@WuCris

This comment has been minimized.

Show comment
Hide comment
@WuCris

WuCris Oct 5, 2017

@ebliever

Please reconsider and provide automatic (not opt-in) replay protection that does not burden the legacy chain.

That would invalidate any pre-signed contracts. Segwit2x wouldn't be much an upgrade to Bitcoin if it breaks Bitcoin contracts. Opt-in replay is a much better option, you aren't forced to use a particular chain but you also aren't forced out of any funds because @ebliever wants Segwit2x to be an altcoin rather than an upgrade to Bitcoin.

WuCris replied Oct 5, 2017

@ebliever

Please reconsider and provide automatic (not opt-in) replay protection that does not burden the legacy chain.

That would invalidate any pre-signed contracts. Segwit2x wouldn't be much an upgrade to Bitcoin if it breaks Bitcoin contracts. Opt-in replay is a much better option, you aren't forced to use a particular chain but you also aren't forced out of any funds because @ebliever wants Segwit2x to be an altcoin rather than an upgrade to Bitcoin.

@SoftWarewolf

This comment has been minimized.

Show comment
Hide comment
@SoftWarewolf

SoftWarewolf Oct 5, 2017

I don't see any code for activation of this new consensus rule, how can you be sure it won't cause a chain split?

SoftWarewolf replied Oct 5, 2017

I don't see any code for activation of this new consensus rule, how can you be sure it won't cause a chain split?

@jcansdale

This comment has been minimized.

Show comment
Hide comment
@jcansdale

jcansdale Oct 5, 2017

@SoftWarewolf,

The 2x portion of Segwit2x is already a combined hard/soft-fork (both allowing larger blocks and requiring the first block to be large). This soft-forking replay protection rule is activated at the same block height.

It is however true that Bitcoin Unlimited/Classic will need to be aware of this rule, since they will follow the 2x chain. Since it would be a soft-fork, they risk having their blocks orphaned rather than a chain split.

jcansdale replied Oct 5, 2017

@SoftWarewolf,

The 2x portion of Segwit2x is already a combined hard/soft-fork (both allowing larger blocks and requiring the first block to be large). This soft-forking replay protection rule is activated at the same block height.

It is however true that Bitcoin Unlimited/Classic will need to be aware of this rule, since they will follow the 2x chain. Since it would be a soft-fork, they risk having their blocks orphaned rather than a chain split.

@SoftWarewolf

This comment has been minimized.

Show comment
Hide comment
@SoftWarewolf

SoftWarewolf Oct 5, 2017

It's an additional consensus rule which is not yet available in current clients. Looks risky with just over a month until activation. If majority of miners don't enforce these replay protection rules, it could lead to a chain split, not just orphaned blocks.

SoftWarewolf replied Oct 5, 2017

It's an additional consensus rule which is not yet available in current clients. Looks risky with just over a month until activation. If majority of miners don't enforce these replay protection rules, it could lead to a chain split, not just orphaned blocks.

@jcansdale

This comment has been minimized.

Show comment
Hide comment
@jcansdale

jcansdale Oct 5, 2017

If a majority of miners on the 2x chain don't enforce these replay protection rules, it would indeed lead to another chain split. We need to ensure that Bitcoin Unlimited/Classic are on the same page.

jcansdale replied Oct 5, 2017

If a majority of miners on the 2x chain don't enforce these replay protection rules, it would indeed lead to another chain split. We need to ensure that Bitcoin Unlimited/Classic are on the same page.

@jlopp

This comment has been minimized.

Show comment
Hide comment
@jlopp

jlopp Oct 5, 2017

This appears to be poorly implemented for a variety of reasons. Some that come to mind:

  1. It's a policy, not a consensus rule. Adversarial miners could still mine these replay protected transactions and thus break the replay protection. I stand corrected; it's consensus post-fork.
  2. It's inefficient to the point that I could see it being considered an attack on other chains. By requiring people to send to a P2SH address with a known redeem script, you're now incentivizing everyone else on a given chain fork that is trying to protect itself from replay attacks to spam the network with spends from this address. This was the same method used by spammers over a year ago, who created a ton of dust UTXOs and then released the private keys to them.
  3. It would be simpler and less disruptive to everyone involved to implement an OP_RETURN based (consensus) replay rule because OP_RETURNs are prunable from the UTXO set.

Given the side effects it will have upon the whole network, I don't see how I can recommend we implement this at BitGo. Even the hacky nLocktime and coinbase tainting methods seem to be less disruptive to the network than this method.

jlopp replied Oct 5, 2017

This appears to be poorly implemented for a variety of reasons. Some that come to mind:

  1. It's a policy, not a consensus rule. Adversarial miners could still mine these replay protected transactions and thus break the replay protection. I stand corrected; it's consensus post-fork.
  2. It's inefficient to the point that I could see it being considered an attack on other chains. By requiring people to send to a P2SH address with a known redeem script, you're now incentivizing everyone else on a given chain fork that is trying to protect itself from replay attacks to spam the network with spends from this address. This was the same method used by spammers over a year ago, who created a ton of dust UTXOs and then released the private keys to them.
  3. It would be simpler and less disruptive to everyone involved to implement an OP_RETURN based (consensus) replay rule because OP_RETURNs are prunable from the UTXO set.

Given the side effects it will have upon the whole network, I don't see how I can recommend we implement this at BitGo. Even the hacky nLocktime and coinbase tainting methods seem to be less disruptive to the network than this method.

@SoftWarewolf

This comment has been minimized.

Show comment
Hide comment
@SoftWarewolf

SoftWarewolf Oct 5, 2017

I believe the reason to have it as a standard output is to ensure compatibility with all wallets. Even clients that don't have a 'multiple send' feature could send 1 satoshi to that adr, and receive tainted/chain-split coins as change.

Using an OP_RETURN requires specifically implementing that feature in most wallets, which requires updating current software before it can be used.

SoftWarewolf replied Oct 5, 2017

I believe the reason to have it as a standard output is to ensure compatibility with all wallets. Even clients that don't have a 'multiple send' feature could send 1 satoshi to that adr, and receive tainted/chain-split coins as change.

Using an OP_RETURN requires specifically implementing that feature in most wallets, which requires updating current software before it can be used.

@jlopp

This comment has been minimized.

Show comment
Hide comment
@jlopp

jlopp Oct 5, 2017

If we're expecting users to manually use multi-send functionality to figure out their own replay protection, I'd expect a ton of them to screw it up and either forget to uses it in some cases or use it in other cases when it's not necessary. Any wallet that wants to implement an opt-in replay protection is going to have to add custom logic that determines whether or not a given UTXO now exists on a branch of UTXOs that has been successfully protected from replays so that it can determine whether or not a given sending transaction needs to be replay protected. I'd expect that particular logic to be more complex to implement than the actual output creation - any standard bitcoin library should support creation of both P2SH outputs and OP_RETURN outputs.

jlopp replied Oct 5, 2017

If we're expecting users to manually use multi-send functionality to figure out their own replay protection, I'd expect a ton of them to screw it up and either forget to uses it in some cases or use it in other cases when it's not necessary. Any wallet that wants to implement an opt-in replay protection is going to have to add custom logic that determines whether or not a given UTXO now exists on a branch of UTXOs that has been successfully protected from replays so that it can determine whether or not a given sending transaction needs to be replay protected. I'd expect that particular logic to be more complex to implement than the actual output creation - any standard bitcoin library should support creation of both P2SH outputs and OP_RETURN outputs.

@jcansdale

This comment has been minimized.

Show comment
Hide comment
@jcansdale

jcansdale Oct 5, 2017

It was a comment by Greg Maxwell that inspired me to try this technique:

Their 'opt-in' doesn't work because to make use of it requires replacing all existing software-- including signing code baked into hardware security modules-- and bloating up transactions users make on Bitcoin. Perhaps that would be viable if we were talking about a year of notice for it, rather than two months.

He's absolutely right that most replay protection would require replacing existing software. Updating signing software that's baked into hardware is particularly problematic. Also, it shouldn't be necessary to bloat up all transactions a user makes.

By using this P2SH technique, a user can replay protect their funds using any wallet software and two non-scary sends.

  1. Send the bitcoin they want to protect to a new address.
  2. Send 0.00002730 BTC to the to 3Bit1x... address (this is minimum dust amount) .

The change from that last tx will be replay protected on the 1x chain. The user is free to transact with their 1x coins without worrying about replays on the 2x chain.

TBH, I'm not sure how else would could do replay protection that would be compatible with hardware wallets. It's a bonus that this can be done without explicit wallet support.

jcansdale replied Oct 5, 2017

It was a comment by Greg Maxwell that inspired me to try this technique:

Their 'opt-in' doesn't work because to make use of it requires replacing all existing software-- including signing code baked into hardware security modules-- and bloating up transactions users make on Bitcoin. Perhaps that would be viable if we were talking about a year of notice for it, rather than two months.

He's absolutely right that most replay protection would require replacing existing software. Updating signing software that's baked into hardware is particularly problematic. Also, it shouldn't be necessary to bloat up all transactions a user makes.

By using this P2SH technique, a user can replay protect their funds using any wallet software and two non-scary sends.

  1. Send the bitcoin they want to protect to a new address.
  2. Send 0.00002730 BTC to the to 3Bit1x... address (this is minimum dust amount) .

The change from that last tx will be replay protected on the 1x chain. The user is free to transact with their 1x coins without worrying about replays on the 2x chain.

TBH, I'm not sure how else would could do replay protection that would be compatible with hardware wallets. It's a bonus that this can be done without explicit wallet support.

@jlopp

This comment has been minimized.

Show comment
Hide comment
@jlopp

jlopp Oct 5, 2017

David Harding pointed out an issue related to payment channels: https://0bin.net/paste/nQwqU76pQ3CW00ZV#TUB68SXcEn-fSIQAWkULnUEL0NaUK/5TzPrQWEFwWyg

jlopp replied Oct 5, 2017

David Harding pointed out an issue related to payment channels: https://0bin.net/paste/nQwqU76pQ3CW00ZV#TUB68SXcEn-fSIQAWkULnUEL0NaUK/5TzPrQWEFwWyg

@christophebiocca

This comment has been minimized.

Show comment
Hide comment
@christophebiocca

christophebiocca Oct 5, 2017

David Harding pointed out an issue related to payment channels: https://0bin.net/paste/nQwqU76pQ3CW00ZV#TUB68SXcEn-fSIQAWkULnUEL0NaUK/5TzPrQWEFwWyg

This seems inherent in uncommitted transactions being invalidated through soft-forks (or hard forks). Would apply to OP_RETURN-based replay protection. Would apply to opt-out replay protection for channels that remain open across the fork (except all channels would be affected, not just specially crafted ones). Heck this also applies to any non-replay-protection soft-fork that applies at the transaction level. Low-s rule for signatures, for example.

Anytime one's wallet enforces fewer rules than the majority of hashpower (which is unknowable, since a mining majority can enforce any additional rules they feel like anytime they want, without telling anyone about it), the only way to be reasonably sure a transaction will commit is to wait for confirmations of that transaction.

christophebiocca replied Oct 5, 2017

David Harding pointed out an issue related to payment channels: https://0bin.net/paste/nQwqU76pQ3CW00ZV#TUB68SXcEn-fSIQAWkULnUEL0NaUK/5TzPrQWEFwWyg

This seems inherent in uncommitted transactions being invalidated through soft-forks (or hard forks). Would apply to OP_RETURN-based replay protection. Would apply to opt-out replay protection for channels that remain open across the fork (except all channels would be affected, not just specially crafted ones). Heck this also applies to any non-replay-protection soft-fork that applies at the transaction level. Low-s rule for signatures, for example.

Anytime one's wallet enforces fewer rules than the majority of hashpower (which is unknowable, since a mining majority can enforce any additional rules they feel like anytime they want, without telling anyone about it), the only way to be reasonably sure a transaction will commit is to wait for confirmations of that transaction.

@SoftWarewolf

This comment has been minimized.

Show comment
Hide comment
@SoftWarewolf

SoftWarewolf Oct 5, 2017

@jcansdale The same logic applies to both methods. I don't doubt that libraries have the option, and i am sure it's easy to implement. I am just saying it won't be immediately available in the graphical (thin) clients that most people use.

I suppose both methods could be implemented simultaneously, but each method increase the technical debt, and removing them in the future would require a hard fork.

@jlopp This confirms that the technical debt is a big nuisance, every software that want to utilize payment channels would need to check that the adr isn't used.

Perhaps it's a better idea to skip the whole replay-protection thing? The upgrade locked in with, and still has supermajority hashrate support, so blocks not on the 2x chain aren't following consensus and will just be orphaned.

If both chains do end up surviving to the next difficulty adjustment, then replay protection can be added later to either chain as soft-fork, ensuring enforcement by utilizing bip9 activation f.ex

SoftWarewolf replied Oct 5, 2017

@jcansdale The same logic applies to both methods. I don't doubt that libraries have the option, and i am sure it's easy to implement. I am just saying it won't be immediately available in the graphical (thin) clients that most people use.

I suppose both methods could be implemented simultaneously, but each method increase the technical debt, and removing them in the future would require a hard fork.

@jlopp This confirms that the technical debt is a big nuisance, every software that want to utilize payment channels would need to check that the adr isn't used.

Perhaps it's a better idea to skip the whole replay-protection thing? The upgrade locked in with, and still has supermajority hashrate support, so blocks not on the 2x chain aren't following consensus and will just be orphaned.

If both chains do end up surviving to the next difficulty adjustment, then replay protection can be added later to either chain as soft-fork, ensuring enforcement by utilizing bip9 activation f.ex

@Sjors

This comment has been minimized.

Show comment
Hide comment
@Sjors

Sjors Oct 5, 2017

I noticed the check happens in ContextualCheckBlock, which I suppose is because you need to know the block height, but this does make it more risky for a user to depend on unconfirmed transactions.

Sjors replied Oct 5, 2017

I noticed the check happens in ContextualCheckBlock, which I suppose is because you need to know the block height, but this does make it more risky for a user to depend on unconfirmed transactions.

@jlopp

This comment has been minimized.

Show comment
Hide comment
@jlopp

jlopp Oct 5, 2017

Replay protection is not optional for any service that cares about protecting user funds. If there isn't a good simple option available at the protocol level, wallets will just have to implement their own using other functionality.

jlopp replied Oct 5, 2017

Replay protection is not optional for any service that cares about protecting user funds. If there isn't a good simple option available at the protocol level, wallets will just have to implement their own using other functionality.

@Sjors

This comment has been minimized.

Show comment
Hide comment
@Sjors

Sjors Oct 5, 2017

This would be non-trivial to put it mildly. Sprinkling some post-fork coinbase transactions on a wallet and then sending all funds to self might be the easiest way, but requires coordination to get these spread. Using time locked transactions requires monitoring two chains, including potential reorgs, which seems like a huge pain.

I'm also worried about privacy implications of consolidating wallet funds, which is concern with the method in this commit as well. The OP_RETURN approach doesn't have that problem.

Sjors replied Oct 5, 2017

This would be non-trivial to put it mildly. Sprinkling some post-fork coinbase transactions on a wallet and then sending all funds to self might be the easiest way, but requires coordination to get these spread. Using time locked transactions requires monitoring two chains, including potential reorgs, which seems like a huge pain.

I'm also worried about privacy implications of consolidating wallet funds, which is concern with the method in this commit as well. The OP_RETURN approach doesn't have that problem.

@jcansdale

This comment has been minimized.

Show comment
Hide comment
@jcansdale

jcansdale Oct 5, 2017

@jlopp,

It's inefficient to the point that I could see it being considered an attack on other chains. By requiring people to send to a P2SH address with a known redeem script, you're now incentivizing everyone else on a given chain fork that is trying to protect itself from replay attacks to spam the network with spends from this address. This was the same method used by spammers over a year ago, who created a ton of dust UTXOs and then released the private keys to them.

I did some very rough calculations here. #127 (comment)

It will only be economical for miners to sweep these outputs when fee levels are below ~48 satoshi / byte. I don't think the 1x chain is likely to be at this fee level again for a while. By the time it is, miners will have swept them all up so users won't have the opportunity to send speculative tx.

(the sums change a bit if you batch them, but you get the idea)

jcansdale replied Oct 5, 2017

@jlopp,

It's inefficient to the point that I could see it being considered an attack on other chains. By requiring people to send to a P2SH address with a known redeem script, you're now incentivizing everyone else on a given chain fork that is trying to protect itself from replay attacks to spam the network with spends from this address. This was the same method used by spammers over a year ago, who created a ton of dust UTXOs and then released the private keys to them.

I did some very rough calculations here. #127 (comment)

It will only be economical for miners to sweep these outputs when fee levels are below ~48 satoshi / byte. I don't think the 1x chain is likely to be at this fee level again for a while. By the time it is, miners will have swept them all up so users won't have the opportunity to send speculative tx.

(the sums change a bit if you batch them, but you get the idea)

@mk229797

This comment has been minimized.

Show comment
Hide comment
@mk229797

mk229797 Oct 5, 2017

Can blacklisted addresses be read from the file?

mk229797 replied Oct 5, 2017

Can blacklisted addresses be read from the file?

@lichtamberg

This comment has been minimized.

Show comment
Hide comment
@lichtamberg

lichtamberg Oct 5, 2017

It looks like the only reason for this "replay protection" is that people are losing their privacy due to merging all of their addresses in one transaction - and we all know that @jgarzik is involved in a blockchain analysis company. Maybe thats the whole point of this silly solution (which endangers 10M+ wallets) - to generate analysis data for his company.

lichtamberg replied Oct 5, 2017

It looks like the only reason for this "replay protection" is that people are losing their privacy due to merging all of their addresses in one transaction - and we all know that @jgarzik is involved in a blockchain analysis company. Maybe thats the whole point of this silly solution (which endangers 10M+ wallets) - to generate analysis data for his company.

@WuCris

This comment has been minimized.

Show comment
Hide comment
@WuCris

WuCris Oct 5, 2017

So judging from above statements this replay protection would cause a chain split if a miner mined a TX to 3Bit1xA4apyzgmFNT2k8Pvnd6zb6TnwcTi anyways?

Couldn't this potentially be very problematic. I don't believe NYA signatories necessarily signed up for opt-in replay and may of them may not even run BTC1 but use their own code base and modify it for larger blocks. If so sending coins to 3Bit1xA4apyzgmFNT2k8Pvnd6zb6TnwcTi could easily be used as a attack vector.

Wouldn't it make more sense to just have it so that BTC1 won't propagate a TX with replay protection but that it won't orphan a block if it's mined with a TX? This wouldn't result in full proof replay protection but it'd help prevent replay attacks as most nodes will likely be BTC1 and it'd prevent a transaction form accidentally being propagated across the Segwit2x chain if a user desires for it not to be. All the while it would prevent a chain split should some miner disagree.

WuCris replied Oct 5, 2017

So judging from above statements this replay protection would cause a chain split if a miner mined a TX to 3Bit1xA4apyzgmFNT2k8Pvnd6zb6TnwcTi anyways?

Couldn't this potentially be very problematic. I don't believe NYA signatories necessarily signed up for opt-in replay and may of them may not even run BTC1 but use their own code base and modify it for larger blocks. If so sending coins to 3Bit1xA4apyzgmFNT2k8Pvnd6zb6TnwcTi could easily be used as a attack vector.

Wouldn't it make more sense to just have it so that BTC1 won't propagate a TX with replay protection but that it won't orphan a block if it's mined with a TX? This wouldn't result in full proof replay protection but it'd help prevent replay attacks as most nodes will likely be BTC1 and it'd prevent a transaction form accidentally being propagated across the Segwit2x chain if a user desires for it not to be. All the while it would prevent a chain split should some miner disagree.

@JaredR26

This comment has been minimized.

Show comment
Hide comment
@JaredR26

JaredR26 Oct 5, 2017

It looks like the only reason for this "replay protection" is that people are losing their privacy due to merging all of their addresses in one transaction

Just send multiple transactions. This isn't hard, and it is a small number of bytes, less than 1/10th the average transaction size today. There's nothing about this entire approach, or 2x itself, that relates in any way to blockchain analysis.

Can blacklisted addresses be read from the file?

There are no blacklisted addresses. There is only one address, and it provides the opt-in replay protection. That protection will have a sunsetting clause in a final release and eventually removed from consensus rules entirely.

So judging from above statements this replay protection would cause a chain split if a miner mined a TX to 3Bit1xA4apyzgmFNT2k8Pvnd6zb6TnwcTi anyways?

No, this is not correct. Transactions to that address are will be considered invalid by 2x nodes & miners; A block containing them would be invalid and not be built upon.

but use their own code base and modify it for larger blocks.

Jeff is updating the specs to indicate the consensus rules regarding this, and this will be communicated to third party dependent software.

JaredR26 replied Oct 5, 2017

It looks like the only reason for this "replay protection" is that people are losing their privacy due to merging all of their addresses in one transaction

Just send multiple transactions. This isn't hard, and it is a small number of bytes, less than 1/10th the average transaction size today. There's nothing about this entire approach, or 2x itself, that relates in any way to blockchain analysis.

Can blacklisted addresses be read from the file?

There are no blacklisted addresses. There is only one address, and it provides the opt-in replay protection. That protection will have a sunsetting clause in a final release and eventually removed from consensus rules entirely.

So judging from above statements this replay protection would cause a chain split if a miner mined a TX to 3Bit1xA4apyzgmFNT2k8Pvnd6zb6TnwcTi anyways?

No, this is not correct. Transactions to that address are will be considered invalid by 2x nodes & miners; A block containing them would be invalid and not be built upon.

but use their own code base and modify it for larger blocks.

Jeff is updating the specs to indicate the consensus rules regarding this, and this will be communicated to third party dependent software.

@Lancelight

This comment has been minimized.

Show comment
Hide comment
@Lancelight

Lancelight Oct 6, 2017

Wow, this has to be the worst decision I've ever seen in a dev project before. When presented with "We're going to be secure by default or We're going to be insecure by default" type of question, what kind of project selects "We're going to be insecure by default"?!! I'll tell you what kind. One that is made up of hacking thieving bad people types looking to exploit anyone who DOESNT adhere to their extortion attempts thats what kind of project it is. Here is a real world analogy of this whole "Opt-In Protection" scheme as I see it:

You walk into a bank and the teller says hi Bob! How can I help you?
Bob: I want to withdraw some Cash.
Teller: Ok bob here you go! BTW, if you pay me 50 bux, I'll even re-close your vault so that no one steals whats left over!
Bob: WTF do you mean give you 50 bux?!
Teller: That's right Bob! You're banking at 1900-we-are-completely-insecure-bank-unless-u-pay-us bank!
Bob: Uhm. So let me get this straight, you're actually trying to extort money from me just because I have an account?
Teller: Yes thats right Bob! Because we're going to be the #1 bank bank in the world!
Bob: Well ya, no kidding, if you try to extort money from everyone, you very well might be rich but I'm going to just stop using you and forget you ever existed.
Teller: Thats ok Bob! We dont care because all other banks you visit will be garbage and when you come back to us, we will have already pillaged ALL your bank accounts for everything they are worth and you wont have anything to deposit anyway Muhahaha!

Wow, now that sounds like SUCH an awesome project that I'd want to get on board with!........ N O T.

Let me put it to you in non-technical terms so that your pea-brains can figure it out. There are 2 ways to secure things.

  1. The correct way. With a lock (This would be strong method, something wallets have to integrate)
  2. The incorrect way with extortion. (This would be opt-in, AKA you being f'ing lazy or more likely, underhanded with ulterior motives to exploit those who wont have a clue about this problem)

How much do you like your money (as you ask someone while pointing a 45 in their face). How many people do you think will give you the money, and more importantly WHY DO YOU THINK THEY WOULD GIVE YOU THE MONEY? If you cant properly answer that, then you now know if you're a punk ass hacker looking to make a quick buck by exploiting this or a real concerned open source advocate just out to help people and make things better.

I am not a crypto developer but I AM a developer none the less and if I werent, I never would have stumbled upon this issue if I didnt know any better than to research it. I am extremely disappointed in this crap as it had some real potential. But after learning about the Opt-In choice. You've lost an advocate. I look at things with an open mind and will go with the better choice no matter how long I have to wait. The average Joe finds out about this (and let me tell you, they will) and you'll have a full scale riot on your hands against your project regardless of how "good" it is.

This guy does a great job of laying it all out: https://www.youtube.com/watch?v=oxCWcGHqh20

Do it the right way and just be patient and wait for wallets to integrate your crap project (because that's exactly what it is if this is the type of mentality you use going into it no matter how superior it is to the old BTC). Use Strong methods and call it done. Period. End of story.

Lancelight replied Oct 6, 2017

Wow, this has to be the worst decision I've ever seen in a dev project before. When presented with "We're going to be secure by default or We're going to be insecure by default" type of question, what kind of project selects "We're going to be insecure by default"?!! I'll tell you what kind. One that is made up of hacking thieving bad people types looking to exploit anyone who DOESNT adhere to their extortion attempts thats what kind of project it is. Here is a real world analogy of this whole "Opt-In Protection" scheme as I see it:

You walk into a bank and the teller says hi Bob! How can I help you?
Bob: I want to withdraw some Cash.
Teller: Ok bob here you go! BTW, if you pay me 50 bux, I'll even re-close your vault so that no one steals whats left over!
Bob: WTF do you mean give you 50 bux?!
Teller: That's right Bob! You're banking at 1900-we-are-completely-insecure-bank-unless-u-pay-us bank!
Bob: Uhm. So let me get this straight, you're actually trying to extort money from me just because I have an account?
Teller: Yes thats right Bob! Because we're going to be the #1 bank bank in the world!
Bob: Well ya, no kidding, if you try to extort money from everyone, you very well might be rich but I'm going to just stop using you and forget you ever existed.
Teller: Thats ok Bob! We dont care because all other banks you visit will be garbage and when you come back to us, we will have already pillaged ALL your bank accounts for everything they are worth and you wont have anything to deposit anyway Muhahaha!

Wow, now that sounds like SUCH an awesome project that I'd want to get on board with!........ N O T.

Let me put it to you in non-technical terms so that your pea-brains can figure it out. There are 2 ways to secure things.

  1. The correct way. With a lock (This would be strong method, something wallets have to integrate)
  2. The incorrect way with extortion. (This would be opt-in, AKA you being f'ing lazy or more likely, underhanded with ulterior motives to exploit those who wont have a clue about this problem)

How much do you like your money (as you ask someone while pointing a 45 in their face). How many people do you think will give you the money, and more importantly WHY DO YOU THINK THEY WOULD GIVE YOU THE MONEY? If you cant properly answer that, then you now know if you're a punk ass hacker looking to make a quick buck by exploiting this or a real concerned open source advocate just out to help people and make things better.

I am not a crypto developer but I AM a developer none the less and if I werent, I never would have stumbled upon this issue if I didnt know any better than to research it. I am extremely disappointed in this crap as it had some real potential. But after learning about the Opt-In choice. You've lost an advocate. I look at things with an open mind and will go with the better choice no matter how long I have to wait. The average Joe finds out about this (and let me tell you, they will) and you'll have a full scale riot on your hands against your project regardless of how "good" it is.

This guy does a great job of laying it all out: https://www.youtube.com/watch?v=oxCWcGHqh20

Do it the right way and just be patient and wait for wallets to integrate your crap project (because that's exactly what it is if this is the type of mentality you use going into it no matter how superior it is to the old BTC). Use Strong methods and call it done. Period. End of story.

@SoftWarewolf

This comment has been minimized.

Show comment
Hide comment
@SoftWarewolf

SoftWarewolf Oct 7, 2017

Can we at least include a de-activation mechanism for this rule? It's unnecessary to permanently increase the technical debt of Bitcoin. It should be trivial to add that after block 500000 or january 1st 2018 or whatever, the rule no longer applies.

I still think it's reckless to roll out a consensus upgrade at this point, but many businesses will want to rely on this mechanism to split their coins shortly after the fork in the case that both chains survive.

But after a short amount of time enough tainted coins should be available to make this code obsolete. (or it may be obsolete straight away if only one chain survives)

Having a planned deactivation allows easy pruning of code, and prevents any potential or unknown issues that could occur because of this rule in the future.

SoftWarewolf replied Oct 7, 2017

Can we at least include a de-activation mechanism for this rule? It's unnecessary to permanently increase the technical debt of Bitcoin. It should be trivial to add that after block 500000 or january 1st 2018 or whatever, the rule no longer applies.

I still think it's reckless to roll out a consensus upgrade at this point, but many businesses will want to rely on this mechanism to split their coins shortly after the fork in the case that both chains survive.

But after a short amount of time enough tainted coins should be available to make this code obsolete. (or it may be obsolete straight away if only one chain survives)

Having a planned deactivation allows easy pruning of code, and prevents any potential or unknown issues that could occur because of this rule in the future.

@jgarzik

This comment has been minimized.

Show comment
Hide comment
@jgarzik

jgarzik Oct 7, 2017

Agree @SoftWarewolf

Posted last night to slack:

There's definitely been some good feedback on the P2SH replay protection method, that may warrant revisiting back to the OP_RETURN method. Vectors of consideration include

  • Difficulty (or ease) of ability to split funds with multi-send
  • Problems that might be encountered with multi-send
  • Impact on layer 2 systems like Lightning
  • Difficulty or ease of ability to execute with existing software, without modification.
  • Need a sunsetting mechanism

jgarzik replied Oct 7, 2017

Agree @SoftWarewolf

Posted last night to slack:

There's definitely been some good feedback on the P2SH replay protection method, that may warrant revisiting back to the OP_RETURN method. Vectors of consideration include

  • Difficulty (or ease) of ability to split funds with multi-send
  • Problems that might be encountered with multi-send
  • Impact on layer 2 systems like Lightning
  • Difficulty or ease of ability to execute with existing software, without modification.
  • Need a sunsetting mechanism
@Lancelight

This comment has been minimized.

Show comment
Hide comment
@Lancelight

Lancelight Oct 7, 2017

@jgarzik When can we expect the revert commit to appear and a new reasonable commit to replace it, the imposed deadline is fast approaching. Talking about a moot point of only 1 real viable solution isn't really the answer. The answer is clear when there is only 1 reasonable solution.

Personally I will only support upgrades/patches/splits of this projects magnitude if it has the following criteria:

  1. Transactions on base code are not affected (base code means the code you are forking from)

  2. Transactions on the base code cannot affect the new codebase (they shouldnt be able to affect the forked code)

Now one item I think may be up for grabs here is the competition for miner attention/support. It's my belief that this should be settled by investors/users of whichever codebase they want to support and it's not up to the codebase itself if the forked code is to use the same resource pool as the base code. That to me is healthy competition. Unhealthy competition is one where the forked code literally assaults the other by forcefully taking over resources. That just is not right nor is it healthy for anyone involved. It gives the new project a bad name and the old project is unable to continue so what happens is that BOTH projects die. Do you really want that? It could not only be bad for your project, but you personally as well as it will destroy your reputation as a developer which is the path you have already set in motion and frankly I think it's probably to late to repair that. At least in my book, I absolutely would never hire you or any company associated with you for a project. Ever. You are going to have to act extremely fast to change any opinions on this matter and not just waste time "revisiting" options. I want to see action, not more talking on a subject that's already been made crystal clear to you for months.

Fix it. And fast. That would change my opinion of you but only slightly. Have a few more good fixes and we can move the opinion slider even more back to the positive side.

I think the only thing we agree on is the ability to disagree which means a fork is necessary. I understand you propose changes that the btc core group disagrees with. That doesnt invalidate your idea but it does tell you that you need a clean fork and not something so disruptive that it is viewed as a tantrum and malicious. Take litecoin for example. Thats the road you should be taking. Lee correctly forked btc and it will probably replace btc somewhere in the future if he does things that the masses view as superior. Is it a fast process? No. Is it easy? No. And it sholdnt be anyway.

Lancelight replied Oct 7, 2017

@jgarzik When can we expect the revert commit to appear and a new reasonable commit to replace it, the imposed deadline is fast approaching. Talking about a moot point of only 1 real viable solution isn't really the answer. The answer is clear when there is only 1 reasonable solution.

Personally I will only support upgrades/patches/splits of this projects magnitude if it has the following criteria:

  1. Transactions on base code are not affected (base code means the code you are forking from)

  2. Transactions on the base code cannot affect the new codebase (they shouldnt be able to affect the forked code)

Now one item I think may be up for grabs here is the competition for miner attention/support. It's my belief that this should be settled by investors/users of whichever codebase they want to support and it's not up to the codebase itself if the forked code is to use the same resource pool as the base code. That to me is healthy competition. Unhealthy competition is one where the forked code literally assaults the other by forcefully taking over resources. That just is not right nor is it healthy for anyone involved. It gives the new project a bad name and the old project is unable to continue so what happens is that BOTH projects die. Do you really want that? It could not only be bad for your project, but you personally as well as it will destroy your reputation as a developer which is the path you have already set in motion and frankly I think it's probably to late to repair that. At least in my book, I absolutely would never hire you or any company associated with you for a project. Ever. You are going to have to act extremely fast to change any opinions on this matter and not just waste time "revisiting" options. I want to see action, not more talking on a subject that's already been made crystal clear to you for months.

Fix it. And fast. That would change my opinion of you but only slightly. Have a few more good fixes and we can move the opinion slider even more back to the positive side.

I think the only thing we agree on is the ability to disagree which means a fork is necessary. I understand you propose changes that the btc core group disagrees with. That doesnt invalidate your idea but it does tell you that you need a clean fork and not something so disruptive that it is viewed as a tantrum and malicious. Take litecoin for example. Thats the road you should be taking. Lee correctly forked btc and it will probably replace btc somewhere in the future if he does things that the masses view as superior. Is it a fast process? No. Is it easy? No. And it sholdnt be anyway.

@jheathco

This comment has been minimized.

Show comment
Hide comment
@jheathco

jheathco Oct 7, 2017

@Lancelight the condescending tone of your response is ridiculous and lacks much technical thought whatsoever. If you expect @jgarzik to give any weight to your feedback I'd suggest you speak to him with a bit more respect.

jheathco replied Oct 7, 2017

@Lancelight the condescending tone of your response is ridiculous and lacks much technical thought whatsoever. If you expect @jgarzik to give any weight to your feedback I'd suggest you speak to him with a bit more respect.

@Lancelight

This comment has been minimized.

Show comment
Hide comment
@Lancelight

Lancelight Oct 7, 2017

LMAO @jheathco He deserves as much "respect" as he has given to the BTC project.... which is absolute zero (read his other comments here in github as well as his Twitter and elsewhere). The only thing he understands is hostility. Period. 95% of the planet is AGAINST his proposed method of securing the segwit2x proposal (which is not the same as all the other proposed changes segwit2x has btw, my problem is with this commit specifically and nothing else). There are reasons beyond your understanding for that. I don't care if he forks but I do care that it would destroy both chains. See, unlike you I actually have investments over 750k in this chain and I absolutely am AGAINST anything that threatens it. Take your poor ass back to dogecoin and bother someone else while the big boys hash out a very real world problem.

Lancelight replied Oct 7, 2017

LMAO @jheathco He deserves as much "respect" as he has given to the BTC project.... which is absolute zero (read his other comments here in github as well as his Twitter and elsewhere). The only thing he understands is hostility. Period. 95% of the planet is AGAINST his proposed method of securing the segwit2x proposal (which is not the same as all the other proposed changes segwit2x has btw, my problem is with this commit specifically and nothing else). There are reasons beyond your understanding for that. I don't care if he forks but I do care that it would destroy both chains. See, unlike you I actually have investments over 750k in this chain and I absolutely am AGAINST anything that threatens it. Take your poor ass back to dogecoin and bother someone else while the big boys hash out a very real world problem.

@jheathco

This comment has been minimized.

Show comment
Hide comment
@jheathco

jheathco Oct 7, 2017

@Lancelight not at all surprised that your level of trolling would lack an identity associated with it.

jheathco replied Oct 7, 2017

@Lancelight not at all surprised that your level of trolling would lack an identity associated with it.

@Lancelight

This comment has been minimized.

Show comment
Hide comment
@Lancelight

Lancelight Oct 7, 2017

Lancelight replied Oct 7, 2017

Please sign in to comment.