Bitcoin Forum
March 28, 2024, 05:23:55 PM *
News: Latest Bitcoin Core release: 26.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: 60% Transaction Compression using OP_CODESEPARATOR without hard forks  (Read 1298 times)
Sergio_Demian_Lerner (OP)
Hero Member
*****
expert
Offline Offline

Activity: 549
Merit: 608


View Profile WWW
April 02, 2013, 05:17:52 AM
 #1

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.
1711646635
Hero Member
*
Offline Offline

Posts: 1711646635

View Profile Personal Message (Offline)

Ignore
1711646635
Reply with quote  #2

1711646635
Report to moderator
The grue lurks in the darkest places of the earth. Its favorite diet is adventurers, but its insatiable appetite is tempered by its fear of light. No grue has ever been seen by the light of day, and few have survived its fearsome jaws to tell the tale.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1711646635
Hero Member
*
Offline Offline

Posts: 1711646635

View Profile Personal Message (Offline)

Ignore
1711646635
Reply with quote  #2

1711646635
Report to moderator
1711646635
Hero Member
*
Offline Offline

Posts: 1711646635

View Profile Personal Message (Offline)

Ignore
1711646635
Reply with quote  #2

1711646635
Report to moderator
Sergio_Demian_Lerner (OP)
Hero Member
*****
expert
Offline Offline

Activity: 549
Merit: 608


View Profile WWW
April 02, 2013, 05:29:25 AM
 #2

For example, the 465k transaction:

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

Would end up using about 150 Kbytes on the wire.
CIYAM
Legendary
*
Offline Offline

Activity: 1890
Merit: 1072


Ian Knowles - CIYAM Lead Developer


View Profile WWW
April 02, 2013, 05:31:28 AM
 #3

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

With CIYAM anyone can create 100% generated C++ web applications in literally minutes.

GPG Public Key | 1ciyam3htJit1feGa26p2wQ4aw6KFTejU
jackjack
Legendary
*
Offline Offline

Activity: 1176
Merit: 1233


May Bitcoin be touched by his Noodly Appendage


View Profile
April 02, 2013, 07:19:29 AM
 #4

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

Own address: 19QkqAza7BHFTuoz9N8UQkryP4E9jHo4N3 - Pywallet support: 1AQDfx22pKGgXnUZFL1e4UKos3QqvRzNh5 - Bitcointalk++ script support: 1Pxeccscj1ygseTdSV1qUqQCanp2B2NMM2
Pywallet: instructions. Encrypted wallet support, export/import keys/addresses, backup wallets, export/import CSV data from/into wallet, merge wallets, delete/import addresses and transactions, recover altcoins sent to bitcoin addresses, sign/verify messages and files with Bitcoin addresses, recover deleted wallets, etc.
gmaxwell
Moderator
Legendary
*
expert
Offline Offline

Activity: 4158
Merit: 8343



View Profile WWW
April 02, 2013, 08:09:55 AM
 #5

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 (OP)
Hero Member
*****
expert
Offline Offline

Activity: 549
Merit: 608


View Profile WWW
April 02, 2013, 01:22:01 PM
 #6

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
Legendary
*
expert
Offline Offline

Activity: 1428
Merit: 1093


Core Armory Developer


View Profile WWW
April 02, 2013, 04:54:09 PM
 #7

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.

Founder and CEO of Armory Technologies, Inc.
Armory Bitcoin Wallet: Bringing cold storage to the average user!
Only use Armory software signed by the Armory Offline Signing Key (0x98832223)

Please donate to the Armory project by clicking here!    (or donate directly via 1QBDLYTDFHHZAABYSKGKPWKLSXZWCCJQBX -- yes, it's a real address!)
Sergio_Demian_Lerner (OP)
Hero Member
*****
expert
Offline Offline

Activity: 549
Merit: 608


View Profile WWW
April 02, 2013, 06:46:37 PM
Merited by darosior (1)
 #8

It's interesting that generally anonymity requires a lot of additional resources. Goes against space, performance, bandwidth.
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!