Why will nodes not relay non-standard txs?

Wolf0

member

Activity: 81

Merit: 1002

It was only the wind.

Quote from: edmundedgar on May 08, 2014, 08:02:18 AM

Quote from: TierNolan on May 08, 2014, 04:04:02 AM

I created a draft BIP (note: the numbering isn't actually allocated)

https://github.com/TierNolan/bips/blob/bip4x/bip-0046.mediawiki

Out of interest is there a reason for having a single branch-controlling flag for 1/2/3 then doing all this copying and dropping of the flag? Visually it feels simpler if you do something like:

Code:

OP_IF
 standard thing 1
OP_ELSE
 standard thing 2
OP_ENDIF

...and feed it a 1 or 0 as a flag, or for three-branch case:

Code:

OP_IF
  standard thing 1
OP_ELSE
 OP_IF
  standard thing 2
 OP_ELSE
  standard thing 3
 OP_ENDIF
OP_ENDIF

...which you would feed either 1 (for the outer first branch) or 0 (for the outer second branch) preceded by 1 or 0 (to pick the inner branch)

PS. Apologies to the OP for hijacking their thread...

It's fine, it sort of is on topic.

gmaxwell

staff

Activity: 4284

Merit: 8808

Quote from: edmundedgar on May 08, 2014, 10:09:32 PM

This thread's got me wondering whether, assuming core

I want to transition to a blacklist instead: inhibit the no-op opcodes, non-canonical pushes/signatures, oddball versions, and enforce sanity limits on size and checksig count... everything else relayed (assuming it's valid and meets whatever fee criteria is in use). I think this is also the goal of everyone else working on core in some timeframe or another: No one has any great affection for the whitelist approach afaik, it's just expedient and changing this is not a top priority compared to all the things which have a more urgent need.

edmundedgar

sr. member

Activity: 352

Merit: 250

https://www.realitykeys.com

This thread's got me wondering whether, assuming core want to stick with the standard pattern white-list and aren't going to be doing a thorough rethink of the whole thing, there might be a middle way between, "Patch your time-stamper to accept any damn thing" and "Only mine patterns that get permission from core devs, who need to be super-cautious".

If we had a reasonably well-supported patch expanding the standard transaction rules maintained by some generally sensible people, which still used a white-list but was a bit more open about including not-obviously-harmful patterns, are there miners out there apart from Luke-Jr who would be prepared to run it?

Obviously we don't usually want all kinds of weird versions of bitcoin doing their own thing floating around the place, but this seems like a special case where there's no disagreement about what's valid once it's in a block, we already have a decent proportion of hashing power (Eligius) applying its own rules, and you can get all kinds of things into blocks anyhow.

edmundedgar

sr. member

Activity: 352

Merit: 250

https://www.realitykeys.com

Quote from: TierNolan on May 08, 2014, 08:15:58 AM

You could just use a simple template match.

OK, that's an important consideration. There's not much point in proposing a standard transaction type and trying to persuade the core devs that it's clean and simple and isn't going to blow up anything up if it needs a load of gruesome, potentially buggy code to find out whether a transaction actually matches that type...

TierNolan

legendary

Activity: 1232

Merit: 1094

Quote from: edmundedgar on May 08, 2014, 08:02:18 AM

Out of interest is there a reason for having a single branch-controlling flag for 1/2/3 then doing all this copying and dropping of the flag? Visually it feels simpler if you do something like:

I felt it made it easier to describe. You could just use a simple template match.

In retrospect, your way is better, since the dups etc require space anyway.

edmundedgar

sr. member

Activity: 352

Merit: 250

https://www.realitykeys.com

Quote from: TierNolan on May 08, 2014, 04:04:02 AM

I created a draft BIP (note: the numbering isn't actually allocated)

https://github.com/TierNolan/bips/blob/bip4x/bip-0046.mediawiki

Out of interest is there a reason for having a single branch-controlling flag for 1/2/3 then doing all this copying and dropping of the flag? Visually it feels simpler if you do something like:

Code:

OP_IF
 standard thing 1
OP_ELSE
 standard thing 2
OP_ENDIF

...and feed it a 1 or 0 as a flag, or for three-branch case:

Code:

OP_IF
  standard thing 1
OP_ELSE
 OP_IF
  standard thing 2
 OP_ELSE
  standard thing 3
 OP_ENDIF
OP_ENDIF

...which you would feed either 1 (for the outer first branch) or 0 (for the outer second branch) preceded by 1 or 0 (to pick the inner branch)

PS. Apologies to the OP for hijacking their thread...

TierNolan

legendary

Activity: 1232

Merit: 1094

Quote from: edmundedgar on May 08, 2014, 06:32:08 AM

What do we reckon is the next move to get this stuff accepted? The cross-chain stuff is really important, and it seems a shame to be kludging around the oracle branching use-cases with multiple transactions or by torturing ECDSA keys in all kinds of unmentionable ways.

I have managed to get it down to 1 non-standard tx. This means that you can trade between 2 coins if at least one of them accepts non-standard transactions.

In theory, testnet coins could have value, just as an intermediary. More likely, an altcoin would see it as a marketing opportunity.

Even accepting

OP_HASH160 OP_EQUALVERIFY OP_CHECKSIG

would be enough.

That seems pretty low risk to me.

I think the 2 drafts have spurred some discussions. Parhaps isStandard() could have a whitelist of opcodes added.

On the other hand, I think adding the hash-locking template immediately and then looking into changes to isStandard() strategy would be best. Optimistically, the change would be in the release after the next one. Disccusions about isStandard() strategy would take longer than checking one new template.

edmundedgar

sr. member

Activity: 352

Merit: 250

https://www.realitykeys.com

Quote from: TierNolan on May 08, 2014, 04:04:02 AM

Quote from: edmundedgar on May 07, 2014, 11:14:23 PM

Yeah, it feels like there should be some patterns that you could reasonably convincingly argue don't have any additional DoS risk when used in P2SH.

I created a draft BIP (note: the numbering isn't actually allocated)

https://github.com/TierNolan/bips/blob/bip4x/bip-0046.mediawiki

and also one about hash releases

https://github.com/TierNolan/bips/blob/bip4x/bip-0045.mediawiki

The hash release one is more critical. You can do the if thing with multiple transactions.

What do we reckon is the next move to get this stuff accepted? The cross-chain stuff is really important, and it seems a shame to be kludging around the oracle branching use-cases with multiple transactions or by torturing ECDSA keys in all kinds of unmentionable ways.

TierNolan

legendary

Activity: 1232

Merit: 1094

Quote from: edmundedgar on May 07, 2014, 11:14:23 PM

Yeah, it feels like there should be some patterns that you could reasonably convincingly argue don't have any additional DoS risk when used in P2SH.

I created a draft BIP (note: the numbering isn't actually allocated)

https://github.com/TierNolan/bips/blob/bip4x/bip-0046.mediawiki

and also one about hash releases

https://github.com/TierNolan/bips/blob/bip4x/bip-0045.mediawiki

The hash release one is more critical. You can do the if thing with multiple transactions.

edmundedgar

sr. member

Activity: 352

Merit: 250

https://www.realitykeys.com

Quote from: TierNolan on May 07, 2014, 09:00:14 AM

OP_IF to allow multiple choice release and hash protection would be nice to have operations.

Yeah, it feels like there should be some patterns that you could reasonably convincingly argue don't have any additional DoS risk when used in P2SH.

For instance, if you're doing these branching transactions, like:

Code:

OP_IF
 some existing standard thing
OP_ELSE
 some other existing standard thing
OP_ENDIF

...you're doing a single true/false test then immediately throwing away everything except the content of one or other branch, leaving something you can already do as standard.

jl2012

legendary

Activity: 1792

Merit: 1111

Quote from: ?? on ??

You make a good point about the multiplication. I thought bugs meant a bug in the multiplication code itself, not malicious usage of it.

How could this not a bug if it allows a attacker to remotely crash all bitcoin nodes in the world?

gmaxwell

staff

Activity: 4284

Merit: 8808

Quote from: ?? on ??

You make a good point about the multiplication. I thought bugs meant a bug in the multiplication code itself, not malicious usage of it.

The possibility of malicious use is a bug. A script isn't something only the users system validates, the whole network must run it... they can't even just ignore scripts they don't like. So any possibility of malicious use is a severe bug.

Peter Todd

legendary

Activity: 1120

Merit: 1152

FWIW here's a proposal for replacing the IsStandard() script template whitelist with a much more generic opcode whitelist that preserves forward compatibility and doesn't allow for (more) mutability of transactions: http://www.mail-archive.com/[email protected]/msg05153.html

gmaxwell

staff

Activity: 4284

Merit: 8808

Quote from: telepatheic on May 07, 2014, 08:40:46 AM

Scripting doesn't really achieve very much, as I posted here enabling all the scripting operations only really allows more complex multi-signature transactions and proof of work in order to spend transactions.

There are a lot more uses than you've listed there. For example lottery transactions, and those puzzles you dismiss as "stupid" enable secure atomic cross chain trades, making payments that securely depend on an external zero knoweldge proof, and making highly private coin trades.

Quote from: ?? on ??

Yeah, I don't get why they permanently disabled multiplication. The explanation says it's because of possible bugs, but come on, it'd be pretty hard to fuck up a simple multiplication.

Because multiplication increases the size of the data. Load a 510 byte number, then keep DUPing and multiplying. Each operation doubles the storage, in relatively few operations all nodes are crashing because they've run out of memory. Your dismissive response shows an extreme carelessness which would virtually ensure the existence of vulnerabilities. Even the simplest operation is easy to make mistakes in. Fortunately the people working on the software are more considerate than that.

Quote from: Wolf0 on May 07, 2014, 07:22:10 AM

What's the point of having script

Because you can go and put new things to use without first requiring a risky network upgrade for everyone. Some of the non-standardness is also required to preserve forward compatibility so that new things can be safely and non-disruptively added in the future.

telepatheic

jr. member

Activity: 56

Merit: 1

Good catch, I'm wrong! I opened a new thread to discuss the BIP https://bitcointalksearch.org/topic/draft-bip-atomic-cross-chain-transfers-599396

TierNolan

legendary

Activity: 1232

Merit: 1094

Quote from: telepatheic on May 07, 2014, 11:02:46 AM

No they don't, signatures apply to the whole transaction but with the other inputs set to 0 see https://en.bitcoin.it/wiki/OP_CHECKSIG

As mentioned in another thread, transaction signing is weird, complicated and needs updating.

What is the process that Bob uses to break the system?

Bob wants to spend Bob.Payout

He has a signed version of Bob.Payout input 0, signed by Alice.

He can add his own signature to that, and input zero is signed.

Alice's signature refers to the entire transaction except the input scripts. It DOES include the tx-id and index number.

Bob cannot change what input 1 refers to. He has to sign Alice.Bail.In:1. That requires he reveals x.

telepatheic

jr. member

Activity: 56

Merit: 1

Quote from: TierNolan on May 07, 2014, 10:53:48 AM

Signatures apply to the entire transaction. There are options to only sign part of the transaction, but by default all outputs are signed.

No they don't, signatures apply to the whole transaction but with the other inputs set to 0 see https://en.bitcoin.it/wiki/OP_CHECKSIG

As mentioned in another thread, transaction signing is weird, complicated and needs updating.

Edit: discussion moved to a new thread https://bitcointalksearch.org/topic/draft-bip-atomic-cross-chain-transfers-599396

TierNolan

legendary

Activity: 1232

Merit: 1094

Quote from: telepatheic on May 07, 2014, 10:15:57 AM

The scheme in your draft BIP won't work because Alice only signs the first input of Bob.Payout, Bob is free to change the second input in order to not reveal x.

Thanks for looking at it.

Signatures apply to the entire transaction. There are options to only sign part of the transaction, but by default all outputs are signed.

Alice.Bail.In can only be added to the blockchain exactly as written.

There is a weakness where Bob can spend Alice.Bail.In:1 without participating in the protocol. It is assumed that fees are low enough that it doesn't matter. If he does spend it, then he has to release x, so Alice can spend his fee on his Bail in.

Alice should not release her Bail-in until Bob does first.

telepatheic

jr. member

Activity: 56

Merit: 1

Quote from: TierNolan on May 07, 2014, 09:00:14 AM

Atomic cross chain trading requires non-standard transactions. After giving it even more thought, I was able to squeeze it into a protocol that requires exactly one non-standard transaction.

OP_IF to allow multiple choice release and hash protection would be nice to have operations.

The scheme in your draft BIP won't work because Alice only signs the first input of Bob.Payout, Bob is free to change the second input in order to not reveal x.

TierNolan

legendary

Activity: 1232

Merit: 1094

Quote from: ?? on ??

It's also kind of ridiculous. I mean, sure, it's zero risk, but so is never leaving your house. You'd almost have to TRY to put a bug in a simple multiplication.

I think they found a potential problem with some opcodes in "live" code. Disabling them fixed it, guaranteed.

It was perfectly reasonable in an "emergency" situation. They could have made it temporary (at slightly increased risk).

This is the change on github "misc changes".

Topic: Why will nodes not relay non-standard txs? (Read 1603 times)