Skip to content
This repository has been archived by the owner on Oct 9, 2019. It is now read-only.

Commit

Permalink
Merge branch '2017_optin_replay' of git://github.com/jcansdale/bitcoi…
Browse files Browse the repository at this point in the history
…n into 2017_optin_replay_jcansdale
  • Loading branch information
jgarzik committed Oct 4, 2017
2 parents 28ebbdb + fdc49fb commit a3c4125
Show file tree
Hide file tree
Showing 6 changed files with 59 additions and 3 deletions.
5 changes: 5 additions & 0 deletions src/policy/policy.cpp
Original file line number Diff line number Diff line change
Expand Up @@ -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;
}

Expand Down
15 changes: 15 additions & 0 deletions src/primitives/transaction.cpp
Original file line number Diff line number Diff line change
Expand Up @@ -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;
}

2 changes: 2 additions & 0 deletions src/primitives/transaction.h
Original file line number Diff line number Diff line change
Expand Up @@ -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++) {
Expand Down
22 changes: 22 additions & 0 deletions src/test/transaction_tests.cpp
Original file line number Diff line number Diff line change
Expand Up @@ -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()
3 changes: 3 additions & 0 deletions src/validation.cpp
Original file line number Diff line number Diff line change
Expand Up @@ -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");
Expand Down
15 changes: 12 additions & 3 deletions test/functional/fork-large-block.py
Original file line number Diff line number Diff line change
Expand Up @@ -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

Expand All @@ -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 = []):
Expand Down

36 comments on commit a3c4125

@ebliever
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Author

@jgarzik jgarzik commented on a3c4125 Oct 4, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mmgen
Copy link

@mmgen mmgen commented on a3c4125 Oct 4, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@nukebloodaxe
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@ebliever
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Who owns the private key to 3Bit1xA4apyzgmFNT2k8Pvnd6zb6TnwcTi?

@jheathco
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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
Copy link

@WuCris WuCris commented on a3c4125 Oct 5, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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
Copy link

@SoftWarewolf SoftWarewolf commented on a3c4125 Oct 5, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@jcansdale jcansdale commented on a3c4125 Oct 5, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@jlopp jlopp commented on a3c4125 Oct 5, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@jlopp jlopp commented on a3c4125 Oct 5, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@jlopp jlopp commented on a3c4125 Oct 5, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@christophebiocca
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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
Copy link

@Sjors Sjors commented on a3c4125 Oct 5, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@jlopp jlopp commented on a3c4125 Oct 5, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@Sjors Sjors commented on a3c4125 Oct 5, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@h0jeZvgoxFepBQ2C
Copy link

@h0jeZvgoxFepBQ2C h0jeZvgoxFepBQ2C commented on a3c4125 Oct 5, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@WuCris WuCris commented on a3c4125 Oct 5, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@JaredR26 JaredR26 commented on a3c4125 Oct 5, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@Lancelight Lancelight commented on a3c4125 Oct 6, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@SoftWarewolf SoftWarewolf commented on a3c4125 Oct 7, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Author

@jgarzik jgarzik commented on a3c4125 Oct 7, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@Lancelight Lancelight commented on a3c4125 Oct 7, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@Lancelight
Copy link

@Lancelight Lancelight commented on a3c4125 Oct 7, 2017 via email

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please sign in to comment.