60% Transaction Compression using OP_CODESEPARATOR without hard forks

[Sergio_Demian_Lerner]

In this thread (https://bitcointalk.org/index.php?topic=164072.0) I showed a strange feature of Bitcoin signature checks. This "feature" can be used to compress transactions while being transferred (more than 95% in some extreme cases)

The idea is to create a new pseudo opcode OP_COPY_SCRIPTSIG. OP_COPY_SCRIPTSIG has a single argument which is the index of the input whose signature script must be copied.
OP_COPY_SCRIPTSIG must be interpreted by the Satoshi client and must be replaced by the exact signature when the Tx is received. so it's transparent to the script verification routines. When the transaction needs to be forwarded, it's compressed again. The use of this pseudo-opcode does not change any transaction verification rule nor it implies a hard fork.

How does it work?

Suppose Alice wish to compress her transactions. She asks the users who send her bitcoins to send her money with a trailing OP_CODESEPARATOR in the output scripts. The Satoshi client is modified to consider this scripts as standard.

Now if she wants to collect a hundred unspent outputs, she just sign the first input scriptSig and fill the remaining scriptSigs with { OP_COPY_SCRIPTSIG,0 }. The same signature can be used in every input, as long as all of them were sent to the same address and have a trailing  OP_CODESEPARATOR in their output scripts.

Since each scriptSig uses normally about 100 bytes, she uses two bytes instead for almost all of them, saving 98% of the scriptSig space.

The output script normally used for "change" can also be compressed, but with lost of anonymity. The idea is to use the pseudo-opcode OP_COPY_SCRIPTPUB that copies the script of one of the output scripts of the previns.  

E.g: A transaction with two inputs and two outputs (one is  returned to the sender as change) looks like this:

Input 0: Previous tx: f5d8ee39a430901c91a5917b9f2dc19d6d1a0e9cea205b009ca73dd04470b9a6, Index: 0,  
  scriptSig: 304502206e21798a42fae0e854281abd38bacd1aeed3ee3738d9e1446618c4571d1
  90db022100e2ac980643b0b82c0e88ffdfec6b64e3e6ba35e7ba5fdd7d5d6cc8d25c6b241501

Input 1: Previous tx:e2ac980643b0b82c0e88ffdfec6b64e2ac980643b0b82c0e88ffdfec6b649f2dc, Index: 0,  
  scriptSig:  { OP_COPY_SCRIPTSIG,0 }.

Output 0:
  Value: 5000000000
  scriptPubKey: OP_DUP OP_HASH160 404371705fa9bd789a2fcd52d2c580b65d35549d OP_EQUALVERIFY OP_CHECKSIG

Output 1:
  Value: 134
  scriptPubKey: { OP_COPY_SCRIPTPUB,0 }.


Best regards, Sergio.

[Sergio_Demian_Lerner]

For example, the 465k transaction:

https://blockchain.info/tx/659135664894e50040830edb516a76f704fd2be409ecd8d1ea9916c002ab28a2

Would end up using about 150 Kbytes on the wire.

[CIYAM]

An interesting idea - do have an estimate of the % of tx's that this approach would be applicable to?

[jackjack]

The main problem is that when a client reads a block/transaction and encounters that op code, it will have to check each previous script to find the one to use

[gmaxwell]

This only helps when people use the system in a poor way that screws up the privacy design... and the opcodes and such are unnecessary: a pair of nodes can community however they agree to communicate— deflate encoding if they like— and whatever alternative transport you want could compress things.

We'd be unlikely to merge anything in the reference that improve efficiency only for cases where users give up privacy. Privacy is an essential part of any financial transaction system, and the privacy of Bitcoin users is unusually fragile.

[Sergio_Demian_Lerner]

This only helps when people use the system in a poor way that screws up the privacy design... and the opcodes and such are unnecessary: a pair of nodes can community however they agree to communicate— deflate encoding if they like— and whatever alternative transport you want could compress things.

We'd be unlikely to merge anything in the reference that improve efficiency only for cases where users give up privacy. Privacy is an essential part of any financial transaction system, and the privacy of Bitcoin users is unusually fragile.

No.  OP_COPY_SCRIPTSIG does not degrade anonymity, since generally (but not always) a single transaction means that all the previns are owned by the same person.

On the contrary OP_COPY_SCRIPTPUB does degrade anonymity, but why not let the users choose the level of anonymity they want?

So we just implement OP_COPY_SCRIPTSIG and make a trailing OP_CODESEPARATOR standard.

[etotheipi]

This only helps when people use the system in a poor way that screws up the privacy design... and the opcodes and such are unnecessary: a pair of nodes can community however they agree to communicate— deflate encoding if they like— and whatever alternative transport you want could compress things.

We'd be unlikely to merge anything in the reference that improve efficiency only for cases where users give up privacy. Privacy is an essential part of any financial transaction system, and the privacy of Bitcoin users is unusually fragile.

No.  OP_COPY_SCRIPTSIG does not degrade anonymity, since generally (but not always) a single transaction means that all the previns are owned by the same person.

On the contrary OP_COPY_SCRIPTPUB does degrade anonymity, but why not let the users choose the level of anonymity they want?

So we just implement OP_COPY_SCRIPTSIG and make a trailing OP_CODESEPARATOR standard.

gmaxwell's point was that for OP_COPY_SCRIPTSIG to actually be useful, you must have massive amounts of address reuse.  While some people do, it's not a "standard" usage of the network, and doing so degrades anonymity.  Therefore, for this script code to be useful, you'd have to have a large number of people using the network in a non-anonymous way.  In fact, if it saves them a fee because the transaction is smaller, then they are actually encouraged to reuse addresses.

[Sergio_Demian_Lerner]

It's interesting that generally anonymity requires a lot of additional resources. Goes against space, performance, bandwidth.