SIGHASH_LIST proposal

[jackjack]

I don't find anything about this, sorry if this was already proposed.
I know this would induce a hard fork so it will not be implemented soon anyway. Thus, I'm just collecting opinions/criticisms for now.

As you may have understood, SIGHASH_LIST would sign a list of contiguous outputs.
It requires two values to work:

• the index of the first output signed, SI
• the number of signed outputs, L

Those two values would be concatenated after SIGHASH in the scriptSig: DER-sig | SIGHASH_LIST | VarInt(SI) | VarInt(L)
However, SI and L are not be signed


Here's what its description would look like:

Procedure for Hashtype SIGHASH_LIST

• The first SI output elements of txCopy are deleted.
• The output of txCopy is resized to L.
• All other txCopy inputs aside from the current input are set to have an nSequence index of zero.

Think of this as "sign some outputs-- I don't care where the other outputs go".

Let's make a transaction with that.
I redeem 4 BTC from the following transaction:

• hash=aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
• index=7
• recipient=1EHNa6Q4Jz2uvNExL497mE43ikXhwF6kZm (hash160=91b24bf9f5288532960ac687abb035127b1d28a5, private key=1)

I want to send 1 BTC to each of the following outputs:

• 2 OP_NUMEQUAL
• 3 OP_NUMEQUAL

And I don't care where other 2 BTC goes


The signed data would be:

Code:

01000000
=Input=
01
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
07000000
1976a91491b24bf9f5288532960ac687abb035127b1d28a588ac   #scriptpubkey
ffffffff

=Outputs=
02

00e1f50500000000
02519c

00e1f50500000000
02529c

00000000
04000000   #SIGHASH_LIST

Only output 1 and output 2 are signed

The transaction itself:

Code:

01000000

= Input =

01
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
07000000
8e     # length of scriptsig
 4b    # length of signature (SI, L included)
  30   # startDER-sig
   46
    022100b4ae4464627d4c04c862f2cd63c41ff0e9ec4e0613c968c370c5a67cffef0710
    022100a09d30bcc1b8104da1e46006aac445027de82be79d5090a452a1436d2476b3b8
  04   # SIGHASH_LIST
  01   # SI
  02   # L

41   # len(pubkey), etc...
04  
79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798
483ada7726a3c4655da4fbfc0e1108a8fd17b448a68554199c47d08ffb10d4b8
ffffffff

= Outputs =

04

00e1f50500000000  # amount 0
02509c            # scriptpubkey 0

00e1f50500000000  # amount 1
02519c            # scriptpubkey 1

00e1f50500000000  # amount 2
02529c            # scriptpubkey 2

00e1f50500000000  # amount 3
02539c            # scriptpubkey 3

00000000

[Remember remember the 5th of November]

This solves what exactly?

[jackjack]

1. Solves this:

there cannot be any change. If you don’t have any outputs of the right size, you must create one first by spending to one of your own addresses.

from https://en.bitcoin.it/wiki/Contracts#Example_3:_Assurance_contracts

2. Allows assurance contracts to more than one recipient

3. Provide flexibility: SIGHASH_LIST'd input can have an index > number of outputs

4. Space efficiency: SIGHASH_SINGLE imposes puting as many outputs as inputs even if they are all the same

5. Does this really have to solve anything to be discussed?

[gmaxwell]

5. Does this really have to solve anything to be discussed?

Yes, unfortunately, it does.  At this stage in its existence no non-trivial hard-forking change can be undertaken to Bitcoin without considerable cost and risk. These costs may be justified in some cases, but you have to — you know— actually point it out.  Otherwise the discussion should probable be in the altcoin subforum.

That admonishment aside, I too have wished that sighash single took a range or a bitmap, it seems somewhat annoyingly artificial that it doesn't. At the same time— I wasn't actually able to come up with a single example use case that required it, at least if I permitted one or two extra transactions, and in some cases some output bloat.

[jackjack]

I do understand the cost of a hard fork. However, I don't get why that would make this be discussed in the altcoin subforum: I'd like to know what people think about making this possible into Bitcoin, even if it will not implemented in the following months/years
Also, such a discussion is the way for people to state the cases that would justify that fork. I wrote the ones I had in mind, but maybe someone will find a great possible improvement coming with SIGHASH_LIST creation

Maybe it's not really a 'proposal' but rather a discussion/debate/other

[gmaxwell]

Because it will not even be considered without some argument that it's a major improvement for some application.  I mean, okay, you're free to post it. I'm just saying that it won't go anywhere— including getting the technicalities fleshed out by the more bitcoin clueful people— until it appears that there is a useful application.

[jl2012]

5. Does this really have to solve anything to be discussed?

Yes, unfortunately, it does.  At this stage in its existence no non-trivial hard-forking change can be undertaken to Bitcoin without considerable cost and risk. These costs may be justified in some cases, but you have to — you know— actually point it out.  Otherwise the discussion should probable be in the altcoin subforum.

That admonishment aside, I too have wished that sighash single took a range or a bitmap, it seems somewhat annoyingly artificial that it doesn't. At the same time— I wasn't actually able to come up with a single example use case that required it, at least if I permitted one or two extra transactions, and in some cases some output bloat.

I just realize that it could be a soft-fork. Actually, any new OP code could be soft-fork (https://bitcointalk.org/index.php?topic=255145.msg2757327#msg2757327). So we just need a OP_CHECKSIG2 that will recognize the new rules.