movrcx [8:31 PM]
joined tx-replay-prevention, and invited @smrtz, @finpunk, @blockops, @jane.hk, @lpsun, @iohk_carlo, @anarch3

smrtz [8:33 PM]
The current idea is to push an 'emergency' commit that implements OP_CHECKBLOCKATHEIGHT to prevent replay attacks by verifying that TXs are on the ZEN chain by confirming the block height.  Then get Bittrex and pool operators to update, and then try to get as many node operators to update too.

[8:33]
Correct?

movrcx [8:34 PM]
No. OP_CHECKBLOCKATHEIGHT was activated for 2 BIP9 periods (~4096 blocks). That's coming to an end soon and I'm not sure if Bittrex is mitigated sufficiently for when the period ends.

[8:35]
They can't even move their funds without assistance and I have to baby sit.

[8:35]
It's possible an attacker has already conducted the transactions already required on the zcl network and is waiting for the replay prevention to shutdown.

[8:36]
As of the current codebase nodes will reject non OP_CHECKBLOCKATHEIGHT transactions as non-standard but a miner can still forceably insert replayed transactions into the block.

smrtz [8:36 PM]
So we have to check blocks before adding them to the chain?

movrcx [8:37 PM]
No that's going to wreck consensus

[8:39]
1. Bittrex should put their ZCL wallet into maintenance mode soon.
2. Bittrex should move their ZEN before the transaction replay window ends.
3. Possibly create a custom daemon for Bittrex that applies OP_CHECKBLOCKATHEIGHT on the ZCL network (It hasn't been activated by softfork yet)
4. Get Supernova to run a custom daemon that accepts to mempool the non-standard OP_CHECKBLOCKATHEIGHT transactions until the softfork activates.

[8:39]
It would probably be useful if someone audited the ZCL blockchain for any suspicious activity that could be used for a replay attack on Zen.

[8:41]
I've updated the codebase earlier to enforce OP_CHECKBLOCKATHEIGHT indefinitely but that's just for mempool acceptance and doesn't include transactions inserted into blocks.

[8:42]
anyway i have to drive to ny in an hour

lukas
[8:42 PM]
joined tx-replay-prevention by invitation from @movrcx

smrtz [8:44 PM]
Does bittrex already know to put the ZCL wallets into maintenance mode?

movrcx [8:44 PM]
Huh?

[8:45]
They put wallets into maint mode all the time

[8:45]
Bittrex already sent us a list of their unspents so it might be worthwhile to parse the ZCL network against that to determine any suspicious activity.

[8:46]
All someone needs to do to execute the attack is withdraw ZCL into a wallet somewhere and then forceably insert that transaction into a Zen block.

[8:46]
OP_CHECKBLOCKATHEIGHT needs to be implemented soon on ZCL.

smrtz [8:47 PM]
But are they planning on putting them into maint mode soon?  Have we reached out to them yet?

movrcx [8:47 PM]
No

[8:48]
anyway i gotta get ready ttyl

smrtz [8:48 PM]
Have a safe drive.

blockops [8:49 PM]
sounds like this is something we have thought about, there is not a problem yet, but we can prevent a problem by pushing a ZCL softfork. Does that sound about right?

smrtz [8:50 PM]
That's my current understanding.

blockops [8:50 PM]
ok, so  informing bittrex and taking action wait until after movrcx vacation? He's been pushing hard and can probably use a break.

movrcx [8:50 PM]
We'll need to a hardfork I think

[8:51]
Ah I'm just heading to NY for BitDevs and doing some business

blockops [8:51 PM]
hardfork zen, zclassic, or both?

movrcx [8:51 PM]
hardfork on zcl

smrtz [8:51 PM]
ZCL.

movrcx [8:51 PM]
which i think people would support

blockops [8:51 PM]
sure - I agree. Thanks for the heads up

[8:51]
:smile:

movrcx [8:52 PM]
:slightly_smiling_face: I need to double check the alert system and make sure it's still implemented but it would be worthwhile to send a network alert out about the hardfork

[8:52]
I'm really worried about Bittrex because they have 80% of coins in circulation and getting Gox'd would kill the project

blockops [8:53 PM]
I'm sure if you present a problem and solution together they will be cool with it.

[8:53]
I think thye don't like surprises where they lose money without the devs telling them about it first

movrcx [8:53 PM]
agreed

blockops [8:53 PM]
ok, ttyl. Travel safe

movrcx [8:54 PM]
ok take care!

[8:55]
@smrtz i'm going push a commit in about 10 mins on the ZCL wallet and then i need to head out

smrtz [8:55 PM]
We have 500 blocks before this happens, so 20.833 hours.

[8:55]
@movrcx Ok.

movrcx [8:55 PM]
@smrtz the attack is executable now if the transactions are inserted into blocks

[8:56]
The 500 block period just prevents transcations from being relayed by nodes.

[8:56]
Putting it into a block circumvents that

smrtz [8:56 PM]
Ahh, great.

movrcx [8:57 PM]
What do you think you'd be able to help with btw @smrtz ?

smrtz [8:58 PM]
Not sure ATM.  I'm reading up on this now.

anarch3
[9:04 PM]
Im ok with a hard fork

movrcx [9:04 PM]
cool @anarch3 i think what i can do is just set the BIP9 period to something small like 50 blocks

[9:06]
As long as Bittrex is secured then everything should be good imo

anarch3
[9:06 PM]
The thing is I don't know if major pools like suprnova and @miningpoolhub support bip9

movrcx [9:06 PM]
hmm

[9:06]
the code was pushed but i dont think they updated

[9:07]
BIP9 might not be needed at all

anarch3
[9:08 PM]
Suprnova has 0x2000000 in it's version headers

movrcx [9:08 PM]
cool so they should be good then

anarch3
[9:08 PM]
http://node1.zenchain.info:8886

[9:08]
There's a few leagcy blocks though

movrcx [9:08 PM]
oh i mean hardfork on the zcl chain.. i didnt see any signaled blocks when i did `getblockchaininfo`

anarch3
[9:10 PM]
Well, it seems all blocks on zcl are 0x4

movrcx [9:10 PM]
nobody upgraded :confused: although testnet has `OP_CHECKBLOCKATHEIGHT` active

[9:11]
i'll just remove it from BIP9 and add it as part of 0x4 blocks then?


anarch3
[9:11 PM]
That may work

movrcx [9:23 PM]
ok pushing the code now as a PR

[9:23]
seems to work fine

[9:27]
Ok it's almost done @anarch3.... I'll let Bittrex know once you ACK it that they should update their wallet and put it into maintenance mode for 24 hours. If somebody could tell all the pools to upgrade that would be great too. Anyway I'm behind on time and I'm heading out soon. Message me if you need anything! (edited)

movrcx [9:37 PM]
Hmm it turns out disabling BIP9 is a bit more work than I anticipated... Since Supernova is already signaling BIP9 on Zen I'm hoping it's not an issue

[9:42]
Ready for review: https://github.com/z-classic/zclassic/pull/90
GitHub
Enable mandatory transaction replay countermeasures by joshuayabut · Pull Request #90 · z-classic/zclassic
zclassic - Zclassic is financial freedom.


anarch3
[9:54 PM]
@movrcx merged


movrcx [9:57 PM]
That's weird I think some people have `OP_CHECKBLOCKATHEIGHT` implemented but they aren't signaling for it... My anti-replay txs were successfully added into blocks...

[9:57]
 ```    {
      "value": 0.00080000,
      "n": 1,
      "scriptPubKey": {
        "asm": "OP_DUP OP_HASH160 4177acddaf9c3e1b3599c32648ac11f2e53adb38 OP_EQUALVERIFY OP_CHECKSIG f20d9de3f5cd43b6384f337d43e550c933736bc42428e08f2e44f00f03000000 120416 OP_CHECKBLOCKATHEIGHT",
        "hex": "76a9144177acddaf9c3e1b3599c32648ac11f2e53adb3888ac20f20d9de3f5cd43b6384f337d43e550c933736bc42428e08f2e44f00f030000000360d601b4",
        "reqSigs": 1,
        "type": "pubkeyhashreplay",
        "addresses": [
          "t1PqmHzDJZpwPh6dA3P2qN36QG9DYpzpjEP"
        ]
      }
    }
  ],
```

[9:57]
Either way that's a good thing :slightly_smiling_face: (edited)

blockops [10:00 PM]
I know I'm just catching up to you all but I want to make sure that if we need to @finpunk and I can explain this to people.

Would the potential form of the replay attack be that someone withdraw a large amount of Zen from bittrex or suprnova and then replay that attack on zclassic and successfully withdraw the same amount of zclassic as they did zen?

Or is there more to it?

smrtz [10:02 PM]
I believe they would inject a TX from ZCL into a ZEN block, and it would hit ZEN rather then ZCL.

movrcx [10:02 PM]
That's right^......they would just buy a ton of zclassic from Bittrex and then withdraw it somewhere and then the attacker would forceably insert those transactions into some blocks. They'd get free Zen that way.

[10:03]
The mitigation signs each transaction with the hash of a unique block from its original blockchain so if that hash doesn't match up the daemon knows the transaction is being replayed. (edited)

smrtz [10:03 PM]
effectively draining Bittrex (or whomever) of their ZEN supply.

blockops [10:05 PM]
So by mitigating zclassic it prevents it. No mitigation necessary for Zen code?

And did you make a determination if it needs to be a hard fork or soft fork for zclassic?

smrtz [10:05 PM]
I'm confused about why we should wait to inform bittrex if this attack is currently performable?

blockops [10:05 PM]
I'm sure bittrex and suprnova would hard fork.  I think they're making a lot of money on Zen right now.

movrcx [10:06 PM]
It was originally implemented as a temporary protection in Zen for 4096 blocks. That's coming to an end in about 20 hours.

[10:06]
But the Zen code has been updated to make it mandatory forever as of today.

smrtz [10:07 PM]
I vote hard fork.  If I'm understanding correctly then a single node could perform the attack and steal the ZEN.  Regardless of whether or not they'd be able to propagate it to the ZCL blockchain, the ZEN would still be moved.

movrcx [10:07 PM]
@smrtz bro.... no hardfork is necessary for ZCL

[10:07]
I just tested it on the live network.. people are running my implementation but aren't signaling it  for some reason

[10:07]
Either way it's good to go

[10:08]
Bittrex just needs to protect their transactions w/ the new ZCL daemon and then everyone should be good to go

blockops [10:10 PM]
Can Bittrex update their ZCL Damon at their convenience or should it be done as soon as possible?

If it can be done during one of their scheduled maintenance periods That would probably be better.

movrcx [10:11 PM]
Yup they can update at any time. I just sent them a message to update it within 20 hours.

blockops [10:11 PM]
Ok, sounds good. You've got my support with Bittrex if you need it.

movrcx [10:11 PM]
It should be done asap though

[10:11]
:+1:

smrtz [10:14 PM]
I thought you originally suggested a hard fork?
movrcx
We'll need to a hardfork I think
Posted in #tx-replay-preventionJune 6th at 8:50 PM

movrcx [10:14 PM]
There are miners that are accepting the transactions so it's not required.

[10:14]
It's not changing their consensus model.

[10:14]
They just aren't signaling that's all.

smrtz [10:15 PM]
Ok, I'm getting it now.  Thank's for spelling it out for me again.  :smile:

finpunk [11:18 PM]
Just to recap, after chatting with Josh, this is just a prudent precautionary mod to reduce replay risk post expiration of this next BIP9 cycle. There's no known attack, latest PR extends protection indefinitely on ZEN, and we've also advised Bittrex to both recompile and move ZEN from old ZCL addresses. These recommendations should permanently eliminate replay risk. There's no further action for us at this point.

movrcx [11:20 PM]
That's pretty accurate except that an attack is possible now if an adversary inserts the transactions within their own mined blocks. That would require custom code to execute though (the difficulty to execute this attack is low-moderate).

[11:22]
This all pretty much stems from `OP_CHECKBLOCKATHEIGHT` mitigations not being initiated on the ZCL network. I think some of the miners forced the block version to be 4 instead of signaling for the `OP_CHECKBLOCKATHEIGHT` soft fork.

[11:23]
So the ZCL network hasn't signaled for replay prevention to activate but most of the miners are running compliant code. There was an issue with Claymore's miner that prevented mining any blocks that weren't version 4. (edited)

[11:25]
Bittrex really needs to move their funds over to new addresses soon imo. It's such a liability to keep funds from a chainsplit in the same address.


----- Yesterday June 7th, 2017 -----
movrcx [9:30 AM]
Btw so far it looks like this issue applies to Bitcoin as well and an adversary could execute this during a 148/149 chainsplit.


[9:30]
Those guys are nuts if they think a chainsplit will end well.

finpunk [10:46 AM]
Anything else we can do to help with this @movrcx? Bittrex is informed, but hasn't responded yet; PR out there, need miners to update. Anything else? Great job identifying this and figuring out a quick path forward to mitigate :slightly_smiling_face:

lukas
[11:16 AM]
:+1:

smrtz [11:18 AM]
@finpunk The PR to zClassic has already been merged into master:  https://github.com/z-classic/zclassic/commit/867ad6cd05d2fb5c2950377eaf41aba7ae224fa9
GitHub
Merge pull request #90 from z-classic/transaction-replay · z-classic/zclassic@867ad6c
Enable mandatory transaction replay countermeasures



finpunk [11:43 AM]
Booyah, awesome @smrtz :slightly_smiling_face:

movrcx [11:44 AM]
That was merged last night...


lukas
[12:59 PM]
Hello, I would like to say thank you to all who participate to fix this issue. It looks like really huge threat.


blockops [3:13 PM]
@movrcx Bittrex Richie has responded on the bittrex slack and I'm trying to nicely tell him to do the upgrade today. So they at least know about it now.

smrtz [5:56 PM]
@blockops He seems active now. Has he said anything back?

blockops [6:01 PM]
I just messaged him again


smrtz [6:02 PM]
There are a few other bittrex-* people active in #customer-support.  Should I message one of them too?

blockops [6:04 PM]
Well, Richie responded. I think he gets to make the call on it. I would recommend not alerting others about it. I had also messaged two others about it this morning, Bill and Julian

smrtz [6:06 PM]
Ok, I was going to message Julian since he seems the most active right now.

[6:06]
Cool.

blockops [6:19 PM]
@smrtz I don't know if you should message Julian. I don't know their organization. @finpunk is more familiar

smrtz [6:19 PM]
Yeah, I haven't messaged anyone about it.  I agree about keeping quiet until the threat is resolved.

[6:20]
I'm just anxious to get it resolved.

finpunk [6:45 PM]
I agree, they clearly know already, so pinging them again won't add anything

[6:46]
Plus we want to keep this issue as narrowly known as possible until prevention measures implemented


----- Today June 8th, 2017 -----
movrcx [3:53 PM]
left tx-replay-prevention

blockops [3:53 PM]
@iohk_carlo this is the one. I think you were already part of it

iohk_carlo [3:55 PM]
Yes, thanks

smrtz [3:59 PM]
OP_CHECKBLOCKATHEIGHT was a custom implementation written by Josh based on BIP115:  https://github.com/bitcoin/bips/blob/master/bip-0115.mediawiki
GitHub
bitcoin/bips
bips - Bitcoin Improvement Proposals