Why will nodes not relay non-standard txs?

[Wolf0]

NaN.

[TierNolan]

It's like, "look at all the cool shit you can do with Bitcoin!" Then, wait, they pull the rug out from underneath you. What's the point of having script if 90% of it won't be relayed or accepted into blocks? Unless Eligius mines it, of course.

Security concerns (and possible bugs in the code).

Since Eligius will include non-standard transactions, the main network has to be able to check non-standard transactions anyway

Pools which use the reference client for block generation are less likely to accidentally produce invalid blocks.

[TierNolan]

Then you may as well vastly simplify Bitcoin and do away with the whole script thing. If you're not going to let people use it, then why have it?

You can use it.  Old clients will accept blocks with script transactions.

I think as time passes, more opcodes will be "unlocked".  It is a pity that they disabled some of them.  They might as well not exist now, since only a hard fork can bring them back .

[telepatheic]

It is a pity that they disabled some of them.  They might as well not exist now, since only a hard fork can bring them back .

Don't confuse those that are permanently disabled (multiplication, division, bitwise operations, string operations) with those that are not relayed (flow operations, stack operations, addition, subtraction, crypto functions).

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.

[TierNolan]

Don't confuse those that are permanently disabled (multiplication, division, bitwise operations, string operations) with those that are not relayed (flow operations, stack operations, addition, subtraction, crypto functions).

I understand the difference.

They should have temporarily disabled them.  For example, they could have disabled them for 50000 blocks (1 year).  That would give them time to test for any bugs.  They could extend the deadline via a soft fork later.

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.

I think progressive enabling of opcodes would be safest.

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.

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.

Disabling them was zero risk.

[TierNolan]

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".

[telepatheic]

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]

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]

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://bitcointalk.org/index.php?topic=599396.0

[TierNolan]

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]

Good catch, I'm wrong! I opened a new thread to discuss the BIP https://bitcointalk.org/index.php?topic=599396.0

[gmaxwell]

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.

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.

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.

[Peter Todd]

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/bitcoin-development@lists.sourceforge.net/msg05153.html

[gmaxwell]

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.

[jl2012]

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?

[edmundedgar]

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.

[TierNolan]

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]

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]

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 <hash(x)> OP_EQUALVERIFY <public-key> 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]

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...