Why have we not discouraged relaying of malleated transactions?

Holliday

legendary

Activity: 1120

Merit: 1012

Quote from: CanaryInTheMine on February 12, 2014, 12:02:03 AM

maybe this is in the wrong thread, but i have a tiny node running at my house, bitcoin-qt (0.8.6) on windows 7 serves about 60 connections at any given time...
what can I do to change it/update it to help with this issue?

I bit the bullet and learned how to build from git in order to run this patch on my node. I don't wish it upon anyone who has no idea what they are doing, there isn't a decent guide in existence (although I was not using Windows).

mb300sd

legendary

Activity: 1260

Merit: 1000

Drunk Posts

Quote from: CanaryInTheMine on February 12, 2014, 12:02:03 AM

maybe this is in the wrong thread, but i have a tiny node running at my house, bitcoin-qt (0.8.6) on windows 7 serves about 60 connections at any given time...
what can I do to change it/update it to help with this issue?

This build should be pretty close to the current git and contain the patch, if you are unable to build it yourself.

http://jenkins.bluematt.me/pull-tester/0542619d93811fdb73508abb5299b8fd77f47a0e/out/

phelix

legendary

Activity: 1708

Merit: 1020

Quote from: gmaxwell on February 11, 2014, 08:41:15 PM

We already block most forms which can be blocked, this was a change in bitcoin 0.8 (that was, in fact, causing withdraws delays for mtgox because they produced transactions with invalid encoding).

The recent flood of transactions use a pushdata change. A patch to block it was written in September 2013, but didn't make it into the codebase until today. If your node is running git bitcoin, just update and you'll have it.

This is good news. Also: Sipa is the best! Cheesy

CanaryInTheMine

donator

Activity: 2352

Merit: 1060

between a rock and a block!

maybe this is in the wrong thread, but i have a tiny node running at my house, bitcoin-qt (0.8.6) on windows 7 serves about 60 connections at any given time...
what can I do to change it/update it to help with this issue?

vokain

legendary

Activity: 1834

Merit: 1019

wonderful. thank you Mr. Maxwell!

mb300sd

legendary

Activity: 1260

Merit: 1000

Drunk Posts

Quote from: gmaxwell on February 11, 2014, 08:41:15 PM

We already block most forms which can be blocked, this was a change in bitcoin 0.8 (that was, in fact, causing withdraws delays for mtgox because they produced transactions with invalid encoding).

The recent flood of transactions use a pushdata change. A patch to block it was written in September 2013, but didn't make it into the codebase until today. If your node is running git bitcoin, just update and you'll have it.

All nodes updated

gmaxwell

staff

Activity: 4284

Merit: 8808

We already block most forms which can be blocked, this was a change in bitcoin 0.8 (that was, in fact, causing withdraws delays for mtgox because they produced transactions with invalid encoding).

The recent flood of transactions use a pushdata change. A patch to block it was written in September 2013, but didn't make it into the codebase until today. If your node is running git bitcoin, just update and you'll have it.

mb300sd

legendary

Activity: 1260

Merit: 1000

Drunk Posts

Quote from: ScripterRon on February 11, 2014, 06:29:22 PM

The ones that I have seen are caused by modifying the first push-data opcode in the input script, changing it from a 1-byte push-data opcode to a 3-byte push-data opcode. Since the same amount of data is pushed on to the stack, the script is still valid. It just changes the transaction hash.

Pieter has listed several things that need to be done. Canonical push-data scripts are just one of them. Some of the changes will require changes to all clients in order to implement them (such as fixing malleable signatures).

That said, I did change my node to not relay transactions with non-canonical push-data opcodes. It seems to be rejecting just the bad transactions, so I'm guessing that existing clients are OK with this change.

I'd been under the impression that changing the opcodes would require the privkey.

Would you mind posting your patch? I'd like to update my nodes as well. Would like to think my ~500 connections are worth something. The less well connected nodes that relay these, the more likely that the non-modified tx makes it to miners first.

ScripterRon

full member

Activity: 136

Merit: 120

The ones that I have seen are caused by modifying the first push-data opcode in the input script, changing it from a 1-byte push-data opcode to a 3-byte push-data opcode. Since the same amount of data is pushed on to the stack, the script is still valid. It just changes the transaction hash.

Pieter has listed several things that need to be done. Canonical push-data scripts are just one of them. Some of the changes will require changes to all clients in order to implement them (such as fixing malleable signatures).

That said, I did change my node to not relay transactions with non-canonical push-data opcodes. It seems to be rejecting just the bad transactions, so I'm guessing that existing clients are OK with this change.

mb300sd

legendary

Activity: 1260

Merit: 1000

Drunk Posts

It seems like the malleable transaction problem is caused only by the use of non-DER encoded signatures in the transaction. Can we discourage the relaying of these? If the standard client and all good implementations of the protocol are creating properly DER encoded signatures, it would be nice to have nodes prefer to relay the properly encoded signature if more than 1 is seen, as well as updating mempool so that the properly signed version is more likely to be mined.

I would make a pull request but ECDSA code tends to go over my head.

Someone tell me if I'm wrong...or if its already being discussed somewhere I'm not finding. Getting annoyed, impatient, and irritable as I watch my net worth decrease.

Topic: Why have we not discouraged relaying of malleated transactions? (Read 3071 times)