SIGHASH_LIST proposal | Bitcointalksearch.org

jl2012

legendary

Activity: 1792

Merit: 1087

Quote from: gmaxwell on May 22, 2013, 04:01:08 AM

Quote from: jackjack on May 22, 2013, 03:28:13 AM

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://bitcointalksearch.org/topic/m.2757327). So we just need a OP_CHECKSIG2 that will recognize the new rules.

gmaxwell

staff

Activity: 4172

Merit: 8419

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.

jackjack

legendary

Activity: 1176

Merit: 1233

May Bitcoin be touched by his Noodly Appendage

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

staff

Activity: 4172

Merit: 8419

Quote from: jackjack on May 22, 2013, 03:28:13 AM

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

legendary

Activity: 1176

Merit: 1233

May Bitcoin be touched by his Noodly Appendage

1. Solves this:

Quote

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?

Remember remember the 5th of November

legendary

Activity: 1862

Merit: 1011

Reverse engineer from time to time

This solves what exactly?

jackjack

legendary

Activity: 1176

Merit: 1233

May Bitcoin be touched by his Noodly Appendage

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:

Quote

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

Topic: SIGHASH_LIST proposal (Read 1093 times)