Title: SIGHASH_LIST proposal Post by: jackjack on May 21, 2013, 11:27:54 PM 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:
However, SI and L are not be signed Here's what its description (https://en.bitcoin.it/wiki/OP_CHECKSIG#Procedure_for_Hashtype_SIGHASH_SINGLE) would look like: Quote Procedure for Hashtype SIGHASH_LIST
Let's make a transaction with that. I redeem 4 BTC from the following transaction:
I want to send 1 BTC to each of the following outputs:
The signed data would be: Code: 01000000 The transaction itself: Code: 01000000 Title: Re: SIGHASH_LIST proposal Post by: Remember remember the 5th of November on May 21, 2013, 11:47:00 PM This solves what exactly?
Title: Re: SIGHASH_LIST proposal Post by: jackjack on May 22, 2013, 07:28:13 AM 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_contracts2. 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? Title: Re: SIGHASH_LIST proposal Post by: gmaxwell on May 22, 2013, 08:01:08 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. Title: Re: SIGHASH_LIST proposal Post by: jackjack on May 22, 2013, 09:54:12 AM 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 Title: Re: SIGHASH_LIST proposal Post by: gmaxwell on May 22, 2013, 03:23:52 PM 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.
Title: Re: SIGHASH_LIST proposal Post by: jl2012 on July 19, 2013, 02:42:58 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://bitcointalk.org/index.php?topic=255145.msg2757327#msg2757327). So we just need a OP_CHECKSIG2 that will recognize the new rules. |