Re: [bitcoin-dev] SIGHASH2 for version 1 witness programme

[Christian Decker via bitcoin-dev]

Johnson Lau  writes:

> Great, I’ll revise it.
>
> Follow-up questions:
>
> 1. Is there any useful case which one would like to use NOINPUT with
> scriptCode and/or scriptPubKey committed? (Note that with
> taproot/MAST, scriptCode and scriptPubKey are not
> interchangeable. scriptPubKey commits to all branches, and scriptCode
> is just one script branch). If yes, we could make this configurable.

There is the poor man's malleability fix that you get if you make only
the previous outpoint rewritable, but that use-case is better covered by
segwit already, and since both of our proposals would be for segwit
outputs only, I don't see a point in doing that.

> 2. Which of the following approaches is better?
> A) sign scriptPubKey in every cases except NOINPUT
> B) sign the type (P2SH-segwit vs. Native-segwit) of scriptPubKey in every 
> cases, including NOINPUT
> C) all of the above
> D) none of the above

What do we effectively gain by committing to the scriptPubkey type? Is
the concern here that we might run into ambiguity about whether this is
a MAST, P2SH, or similar output, allowing an attacker to sideload
unwanted effects?

> Option B is very easy to implement as SignatureHash() could
> distinguish the type by the size of scriptSig in TxTo. Option A is
> more complicated as GenericTransactionSignatureChecker needs to know
> the scriptPubKey.
>
> If the only reason for doing this is to allow hardware wallet to
> distinguish the segwit type, option B is probably enough. This is also
> compatible with eltoo.

Agreed on compatibility :-)

> Option A is useful when a hardware wallet reuses the same public key
> in different scripts, but it couldn’t be applied to NOINPUT
>
> 3. Is the proposed DUALOUTPUT somehow useful for eltoo? Eltoo use
> NOINPUT|SINGLE to allow fee pumping, since it is an
> one-input-one-output tx. This is not possible with the existing LN as
> the tx is one-input-two-output. If we had DUALOUTPUT which signs the
> matched and last output, fee-pumping would be possible in the existing
> LN.

That's a very strange concept, but it strongly relies on the structure
of the commitment, having two outputs. As soon as we have HTLCs included
in the commitment we no longer have 2 outputs (2 for the endpoints, and
1 as a base for the two-phase HTLC resolution), so this would be a
rather brittle fix or would require major restructuring of LN imho.

Cheers,
Christian
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] SIGHASH2 for version 1 witness programme

[Johnson Lau via bitcoin-dev]

Great, I’ll revise it.

Follow-up questions:

1. Is there any useful case which one would like to use NOINPUT with scriptCode 
and/or scriptPubKey committed? (Note that with taproot/MAST, scriptCode and 
scriptPubKey are not interchangeable. scriptPubKey commits to all branches, and 
scriptCode is just one script branch). If yes, we could make this configurable.

2. Which of the following approaches is better?
A) sign scriptPubKey in every cases except NOINPUT
B) sign the type (P2SH-segwit vs. Native-segwit) of scriptPubKey in every 
cases, including NOINPUT
C) all of the above
D) none of the above

Option B is very easy to implement as SignatureHash() could distinguish the 
type by the size of scriptSig in TxTo. Option A is more complicated as 
GenericTransactionSignatureChecker needs to know the scriptPubKey.

If the only reason for doing this is to allow hardware wallet to distinguish 
the segwit type, option B is probably enough. This is also compatible with 
eltoo.

Option A is useful when a hardware wallet reuses the same public key in 
different scripts, but it couldn’t be applied to NOINPUT

3. Is the proposed DUALOUTPUT somehow useful for eltoo? Eltoo use 
NOINPUT|SINGLE to allow fee pumping, since it is an one-input-one-output tx. 
This is not possible with the existing LN as the tx is one-input-two-output. If 
we had DUALOUTPUT which signs the matched and last output, fee-pumping would be 
possible in the existing LN.




> On 31 Aug 2018, at 4:51 AM, Christian Decker  
> wrote:
> 
> Thanks for the update Johnson, just wanted to give a really quick NACK
> on the SIGHASH_NOINPUT variant: the whole idea of BIP 118 is to have
> floating transactions that can be bound to predecessors, and still
> enforce some application logic. In eltoo's case this is the fact that
> the state number needs to be smaller than the state number of the
> transaction that is being rewritten. The state number that we bind to is
> part of the `scriptPubKey`, so we can't commit to the `scriptPubKey` in
> the signature since we don't know which output (and thus it's
> scriptPubKey`) is at the time we sign.
> 
> If we are committing to `scriptPubKey` this whole way of enforcing order
> in updates is no longer possible, and the only thing we actually get
> from this change is a (very weak) malleability fix. The same argument
> goes for `scriptCode`.
> 
> Cheers,
> Christian
> 
> Johnson Lau  writes:
>> After gathering some feedbacks I substantially revised the proposal. This 
>> version focus on improving security, and reduces the number of optional 
>> features.
>> 
>> Formatted BIP and sample code at:
>> https://github.com/jl2012/bips/blob/sighash2/bip-sighash2.mediawiki
>> https://github.com/jl2012/bitcoin/commits/sighash2
>> 
>> The major new features compared with BIP143:
>> 
>> 1. If signing all inputs, also sign all input value. BIP143 signature only 
>> covers the value of the same input. In some cases this may not be adequate 
>> for hardware wallet to determine the right amount of fees. Signing all input 
>> values will secure any possible case.
>> 2. Sign both scriptCode and previous scriptPubKey. In the original bitcoin 
>> design, previous scriptPubKey is signed as the scriptCode. However, this is 
>> not the case with P2SH and segwit. Explicitly committing to the scriptPubKey 
>> allows hardware wallet to confirm what it is actually signing (e.g. 
>> P2SH-segwit vs. Native-segwit).
>> 3. SIGHASH2_NOINPUT: basically same as BIP118, but the signature commits to 
>> both scriptCode and scriptPubKey. This prevents signature replay if the same 
>> public key is used in different scripts.
>> 4. SIGHASH2_MATCHOUTPUT (previously SIGHASH_SINGLE) disallows out-of-range 
>> case.
>> 5. SIGHASH2_LASTOUTPUT: signs only the highest index output.
>> 6. SIGHASH2_DUALOUTPUT: signs the matched output and the highest index 
>> output. Described by gmaxwell at 
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-July/016188.html
>>  
>> 
>> 7. Signing the amount of fees (optional, yes by default). In case of not 
>> signing all inputs or outputs, users may still want to commit to a specific 
>> fee amount.
>> 8. Signing the witness size (optional, yes by default). While segwit fixed 
>> txid malleability, it is not a fix of script malleability. It may cause some 
>> trouble if an attacker could bloat the witness and reduce the fee priority 
>> of a transaction. Although the witness size is not malleable for most simple 
>> scripts, this is not guaranteed for more complex ones. Such kind of size 
>> malleability could be avoided if signatures commit to the size of witness.
>> 
>> Any suggestions are welcomed. But I have the following questions:
>> 
>> 1. Should NOINPUT commit to scriptCode and/or scriptPubKey? I think it 
>> should, because that helps avoid signature replay in some cases, and also 
>> lets hardware wallets know what they are 

Re: [bitcoin-dev] SIGHASH2 for version 1 witness programme

[Christian Decker via bitcoin-dev]

Thanks for the update Johnson, just wanted to give a really quick NACK
on the SIGHASH_NOINPUT variant: the whole idea of BIP 118 is to have
floating transactions that can be bound to predecessors, and still
enforce some application logic. In eltoo's case this is the fact that
the state number needs to be smaller than the state number of the
transaction that is being rewritten. The state number that we bind to is
part of the `scriptPubKey`, so we can't commit to the `scriptPubKey` in
the signature since we don't know which output (and thus it's
scriptPubKey`) is at the time we sign.

If we are committing to `scriptPubKey` this whole way of enforcing order
in updates is no longer possible, and the only thing we actually get
from this change is a (very weak) malleability fix. The same argument
goes for `scriptCode`.

Cheers,
Christian

Johnson Lau  writes:
> After gathering some feedbacks I substantially revised the proposal. This 
> version focus on improving security, and reduces the number of optional 
> features.
>
> Formatted BIP and sample code at:
> https://github.com/jl2012/bips/blob/sighash2/bip-sighash2.mediawiki
> https://github.com/jl2012/bitcoin/commits/sighash2
>
> The major new features compared with BIP143:
>
> 1. If signing all inputs, also sign all input value. BIP143 signature only 
> covers the value of the same input. In some cases this may not be adequate 
> for hardware wallet to determine the right amount of fees. Signing all input 
> values will secure any possible case.
> 2. Sign both scriptCode and previous scriptPubKey. In the original bitcoin 
> design, previous scriptPubKey is signed as the scriptCode. However, this is 
> not the case with P2SH and segwit. Explicitly committing to the scriptPubKey 
> allows hardware wallet to confirm what it is actually signing (e.g. 
> P2SH-segwit vs. Native-segwit).
> 3. SIGHASH2_NOINPUT: basically same as BIP118, but the signature commits to 
> both scriptCode and scriptPubKey. This prevents signature replay if the same 
> public key is used in different scripts.
> 4. SIGHASH2_MATCHOUTPUT (previously SIGHASH_SINGLE) disallows out-of-range 
> case.
> 5. SIGHASH2_LASTOUTPUT: signs only the highest index output.
> 6. SIGHASH2_DUALOUTPUT: signs the matched output and the highest index 
> output. Described by gmaxwell at 
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-July/016188.html 
> 
> 7. Signing the amount of fees (optional, yes by default). In case of not 
> signing all inputs or outputs, users may still want to commit to a specific 
> fee amount.
> 8. Signing the witness size (optional, yes by default). While segwit fixed 
> txid malleability, it is not a fix of script malleability. It may cause some 
> trouble if an attacker could bloat the witness and reduce the fee priority of 
> a transaction. Although the witness size is not malleable for most simple 
> scripts, this is not guaranteed for more complex ones. Such kind of size 
> malleability could be avoided if signatures commit to the size of witness.
>
> Any suggestions are welcomed. But I have the following questions:
>
> 1. Should NOINPUT commit to scriptCode and/or scriptPubKey? I think it 
> should, because that helps avoid signature replay in some cases, and also 
> lets hardware wallets know what they are signing. I am asking this because 
> BIP118 proposes the opposite. I want to make sure I’m not missing something 
> here.
> 2. Do we want to add LASTOUTPUT and DUALOUTPUT? Suggested by gmaxwell, an 
> example use case is kickstarter, where individual supporters send money to 
> the last output for a kickstarter project, and send change to the matched 
> output. However, I doubt if this would be actually used this way, because the 
> kickstarter organiser could always take the money before the target is met, 
> by making up the difference with his own input. This is an inherent problem 
> for any anonymous kickstarter scheme. If these new SIGHASHs are not useful in 
> other applications, I am not sure if we should add them.
> 3. Instead of these restrictive MATCH/LAST/DUALOUTPUT, do we want a fully 
> flexible way to sign a subset of outputs? The indexes of signed outputs are 
> put at the end of the signature, and the signature won’t commit to these 
> index values. Therefore, a third party could collect all transactions of this 
> kind and merge them into one transaction. To limit the sighash cost, number 
> of signed outputs might not be more than 2 or 3. Some potential problems: a) 
> code complexity; b) 1-byte or 2-byte index: 1-byte will limit the number of 
> outputs to 256. 2-byte will use more space even for smaller txs; c) highly 
> variable signature size makes witness size estimation more difficult
> 4. Should we sign the exact witness size (as proposed), or an upper size 
> limit? Signing an upper limit will take up more space, as the limit has to be 
> explicitly shown 

Re: [bitcoin-dev] SIGHASH2 for version 1 witness programme

[Johnson Lau via bitcoin-dev]

After gathering some feedbacks I substantially revised the proposal. This 
version focus on improving security, and reduces the number of optional 
features.

Formatted BIP and sample code at:
https://github.com/jl2012/bips/blob/sighash2/bip-sighash2.mediawiki
https://github.com/jl2012/bitcoin/commits/sighash2

The major new features compared with BIP143:

1. If signing all inputs, also sign all input value. BIP143 signature only 
covers the value of the same input. In some cases this may not be adequate for 
hardware wallet to determine the right amount of fees. Signing all input values 
will secure any possible case.
2. Sign both scriptCode and previous scriptPubKey. In the original bitcoin 
design, previous scriptPubKey is signed as the scriptCode. However, this is not 
the case with P2SH and segwit. Explicitly committing to the scriptPubKey allows 
hardware wallet to confirm what it is actually signing (e.g. P2SH-segwit vs. 
Native-segwit).
3. SIGHASH2_NOINPUT: basically same as BIP118, but the signature commits to 
both scriptCode and scriptPubKey. This prevents signature replay if the same 
public key is used in different scripts.
4. SIGHASH2_MATCHOUTPUT (previously SIGHASH_SINGLE) disallows out-of-range case.
5. SIGHASH2_LASTOUTPUT: signs only the highest index output.
6. SIGHASH2_DUALOUTPUT: signs the matched output and the highest index output. 
Described by gmaxwell at 
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-July/016188.html 

7. Signing the amount of fees (optional, yes by default). In case of not 
signing all inputs or outputs, users may still want to commit to a specific fee 
amount.
8. Signing the witness size (optional, yes by default). While segwit fixed txid 
malleability, it is not a fix of script malleability. It may cause some trouble 
if an attacker could bloat the witness and reduce the fee priority of a 
transaction. Although the witness size is not malleable for most simple 
scripts, this is not guaranteed for more complex ones. Such kind of size 
malleability could be avoided if signatures commit to the size of witness.

Any suggestions are welcomed. But I have the following questions:

1. Should NOINPUT commit to scriptCode and/or scriptPubKey? I think it should, 
because that helps avoid signature replay in some cases, and also lets hardware 
wallets know what they are signing. I am asking this because BIP118 proposes 
the opposite. I want to make sure I’m not missing something here.
2. Do we want to add LASTOUTPUT and DUALOUTPUT? Suggested by gmaxwell, an 
example use case is kickstarter, where individual supporters send money to the 
last output for a kickstarter project, and send change to the matched output. 
However, I doubt if this would be actually used this way, because the 
kickstarter organiser could always take the money before the target is met, by 
making up the difference with his own input. This is an inherent problem for 
any anonymous kickstarter scheme. If these new SIGHASHs are not useful in other 
applications, I am not sure if we should add them.
3. Instead of these restrictive MATCH/LAST/DUALOUTPUT, do we want a fully 
flexible way to sign a subset of outputs? The indexes of signed outputs are put 
at the end of the signature, and the signature won’t commit to these index 
values. Therefore, a third party could collect all transactions of this kind 
and merge them into one transaction. To limit the sighash cost, number of 
signed outputs might not be more than 2 or 3. Some potential problems: a) code 
complexity; b) 1-byte or 2-byte index: 1-byte will limit the number of outputs 
to 256. 2-byte will use more space even for smaller txs; c) highly variable 
signature size makes witness size estimation more difficult
4. Should we sign the exact witness size (as proposed), or an upper size limit? 
Signing an upper limit will take up more space, as the limit has to be 
explicitly shown in the witness. The overhead could be avoided by showing the 
limit only if the actual witness size is not equal to the committed limit. 
However, I tend to keep it simple and sign the exact value. If in a multi-sig 
setup some signers are unable to accurately estimate the witness size, they 
should leave this responsibility to the last signer who should know the exact 
size.


> On 1 Jun 2018, at 2:35 AM, Johnson Lau via bitcoin-dev 
>  wrote:
> 
> Since 2016, I have made a number of proposals for the next generation of 
> script. Since then, there has been a lot of exciting development on this 
> topic. The most notable ones are Taproot and Graftroot proposed by Maxwell. 
> It seems the most logical way is to implement MAST and other new script 
> functions inside Taproot and/or Graftroot. Therefore, I substantially 
> simplified my earlier proposal on SIGHASH2. It is a superset of the existing 
> SIGHASH and the BIP118 SIGHASH_NOINPUT, with further flexibility but not 
> being 

Re: [bitcoin-dev] SIGHASH2 for version 1 witness programme

[Gregory Maxwell via bitcoin-dev]

On Thu, May 31, 2018 at 6:35 PM, Johnson Lau via bitcoin-dev
 wrote:
> The bit 0 to 3 of hashtype denotes a value between 0 and 15:
>
> • If the value is 1, the signature is invalid.
> • If the value is 3 or below, hashPrevouts is the hash of all input, 
> same as defined in BIP143. Otherwise, it is 32-byte of 0x...
> • If the value is 7 or below, outpoint is the COutPoint of the 
> current input. Otherwise, it is 36-byte of 0x...
> • If the value is 0, hashSequence is the hash of all sequence, same 
> as defined in BIP143. Otherwise, it is 32-byte of 0x...
> • If the value is even (including 0), nSequence is the nSequence of 
> the current input. Otherwise, it is 0x.
> • If the value is 6, 7, 10, 11, 14, or 15, nInputIndex is 0x. 
> Otherwise, it is the index of the current input.
> • If the value is 11 or below, nAmount is the value of the current 
> input (same as BIP143). Otherwise, it is 0x.
>
> The bit 4 and 5 of hashtype denotes a value between 0 and 3:
>
> • If the value is 0, hashOutputs is same as the SIGHASH_ALL case in 
> BIP143 as a hash of all outputs.
> • If the value is 1, the signature is invalid.
> • If the value is 2, hashOutputs is same as the SIGHASH_SINGLE case 
> in BIP143 as a hash of the matching output. If a matching output does not 
> exist, hashOutputs is 32-byte of 0x...
> • If the value is 3, hashOutputs is 32-byte of 0x...
> If bit 6 is set (SIGHASH2_NOFEE), nFees is 0x. Otherwise, it 
> is the fee paid by the transaction.
> If bit 7 is set (SIGHASH2_NOLOCKTIME), nLockTime is 0x. Otherwise, it 
> is the transaction nLockTime.
>
> If bit 8 is set (SIGHASH2_NOVERSION), nVersion is 0x. Otherwise, it 
> is the transaction nVersion.
>
> If bit 9 is set (SIGHASH2_NOSCRIPTCODE), scriptCode is an empty script. 
> Otherwise, it is same as described in BIP143.
>
> Bits 10 to 15 are reserved and ignored, but the signature still commits to 
> their value as hashtype.
>
> hashtype of 0 is also known as SIGHASH2_ALL, which covers all the available 
> options. In this case the singnature MUST be exactly 64-byte.
>
> hashtype of 0x3ff is also known as SIGHASH2_NONE, which covers nothing and is 
> effectively forfeiting the right related to this public key to anyone.


This seems fairly complicated and yet-- if I don't misunderstand-- it
doesn't capture the one special output masking case that I've seen
actual applications want (which itself, is one out of the only two
special sighash cases I've seen applications want-- the other being
no-input).

The case I think this is missing is SIGHASH_SINGLE |
SIGHASH_LAST_OUTPUT   e.g. "Sign the matching output, and the last
output regardless of its index". The application for this style is
"kickstarter" joint-payment transactions where you wish to sign both
your change output (SIGHASH_SINGLE)  and the joint-payment output
(SIGHASH_LAST_OUTPUT).  Without it, this kind of usage requires
usually a chain of depth two for each input to split off the change.

I came back around to your post at Sipa's recommendation because I was
musing on is there a _simple_ set of enhanced sighash flags that
capture real useful behaviour without falling down a rathole of
specifying a totally general behaviour.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] SIGHASH2 for version 1 witness programme

[Johnson Lau via bitcoin-dev]

> On 2 Jun 2018, at 2:15 AM, Russell O'Connor  wrote:
> 
> 
> I prefer a different opcode for CHECKSIGFROMSTACK because I dislike opcodes 
> that pop a non-static number of elements off the stack.  Popping a dynamic 
> number of stack elements makes it more difficult to validate that a Script 
> pubkey doesn't allow any funny business.


Agreed. This is one of the reasons I think we should remove CHECKMULTISIG in 
the new script system___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] SIGHASH2 for version 1 witness programme

[Russell O'Connor via bitcoin-dev]

On Fri, Jun 1, 2018 at 1:03 PM, Johnson Lau  wrote:

> On 1 Jun 2018, at 11:03 PM, Russell O'Connor 
> wrote:
> On Thu, May 31, 2018 at 2:35 PM, Johnson Lau via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>>
>>   Double SHA256 of the serialization of:
>>
>
> Should we replace the Double SHA256 with a Single SHA256?  There is no
> possible length extension attack here.  Or are we speculating that there is
> a robustness of Double SHA256 in the presence of SHA256 breaking?
>
> I suggest putting `sigversion` at the beginning instead of the end of the
> format.  Because its value is constant, the beginning of the SHA-256
> computation could be pre-computed in advance.  Furthermore, if we make the
> `sigversion` exactly 64-bytes long then the entire first block of the
> SHA-256 compression function could be pre-computed.
>
> Can we add CHECKSIGFROMSTACK or do you think that would go into a separate
> BIP?
>
>
> I think it’s just a tradition to use double SHA256. One reason we might
> want to keep dSHA256 is a blind signature might be done by giving only the
> single SHA256 hash to the signer. At the same time, a non-Bitcoin signature
> scheme might use SHA512-SHA256. So a blind signer could distinguish the
> message type without learning the message.
>
> sigversion is a response to Peter Todd’s comments on BIP143:
> https://petertodd.org/2016/segwit-consensus-critical-code-review#bip143-
> transaction-signature-verification
>
> I make it a 0x0100 at the end of the message because the last 4 bytes
> has been the nHashType in the legacy/BIP143 protocol. Since the maximum
> legacy nHashType is 0xff, no collision could ever occur.
>
> Putting a 64-byte constant at the beginning should also work, since a
> collision means SHA256 is no longer preimage resistance. I don’t know much
> about SHA256 optimisation. How good it is as we put a 64-byte constant at
> the beginning, while we also make the message 64-byte longer?
>

In theory, having a fixed 64 byte constant at the beginning results in zero
overhead for those 64 bytes.  An implementation would just start the usual
SHA-256 algorithm with a different pre-computed and fixed initial value
than SHA-256's standard initial value.  The SHA-256 padding counter would
also need to start at 64*8 bits rather than starting at 0 bits.  In
practice, assuming a OpenSSL-like implementation of SHA-256, it should be
easy to implement this optimization. One would replace SHA256_Init call
with a variant that initializes the SHA256_CTX to this pre-computed value
and sets SHA256_CTX's num counter to the appropriate value.  Non-optimized
implementations can still just add the 64 byte prefix and use any SHA-256
implementation.

For CHECKSIGFROMSTACK (CSFS), I think the question is whether we want to
> make it as a separate opcode, or combine that with CHECKSIG. If it is a
> separate opcode, I think it should be a separate BIP. If it is combined
> with CHECKSIG, we could do something like this: If the bit 10 of SIGHASH2
> is set, CHECKSIG will pop one more item from stack, and serialize its
> content with the transaction digest. Any thought?
>

I prefer a different opcode for CHECKSIGFROMSTACK because I dislike opcodes
that pop a non-static number of elements off the stack.  Popping a dynamic
number of stack elements makes it more difficult to validate that a Script
pubkey doesn't allow any funny business.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] SIGHASH2 for version 1 witness programme

[Johnson Lau via bitcoin-dev]

> On 1 Jun 2018, at 11:03 PM, Russell O'Connor  wrote:
> 
> 
> 
> On Thu, May 31, 2018 at 2:35 PM, Johnson Lau via bitcoin-dev 
>  > wrote:
> 
>   Double SHA256 of the serialization of:
> 
> Should we replace the Double SHA256 with a Single SHA256?  There is no 
> possible length extension attack here.  Or are we speculating that there is a 
> robustness of Double SHA256 in the presence of SHA256 breaking?
> 
> I suggest putting `sigversion` at the beginning instead of the end of the 
> format.  Because its value is constant, the beginning of the SHA-256 
> computation could be pre-computed in advance.  Furthermore, if we make the 
> `sigversion` exactly 64-bytes long then the entire first block of the SHA-256 
> compression function could be pre-computed.
> 
> Can we add CHECKSIGFROMSTACK or do you think that would go into a separate 
> BIP?

I think it’s just a tradition to use double SHA256. One reason we might want to 
keep dSHA256 is a blind signature might be done by giving only the single 
SHA256 hash to the signer. At the same time, a non-Bitcoin signature scheme 
might use SHA512-SHA256. So a blind signer could distinguish the message type 
without learning the message.

sigversion is a response to Peter Todd’s comments on BIP143: 
https://petertodd.org/2016/segwit-consensus-critical-code-review#bip143-transaction-signature-verification
 


I make it a 0x0100 at the end of the message because the last 4 bytes has 
been the nHashType in the legacy/BIP143 protocol. Since the maximum legacy 
nHashType is 0xff, no collision could ever occur.

Putting a 64-byte constant at the beginning should also work, since a collision 
means SHA256 is no longer preimage resistance. I don’t know much about SHA256 
optimisation. How good it is as we put a 64-byte constant at the beginning, 
while we also make the message 64-byte longer?

For CHECKSIGFROMSTACK (CSFS), I think the question is whether we want to make 
it as a separate opcode, or combine that with CHECKSIG. If it is a separate 
opcode, I think it should be a separate BIP. If it is combined with CHECKSIG, 
we could do something like this: If the bit 10 of SIGHASH2 is set, CHECKSIG 
will pop one more item from stack, and serialize its content with the 
transaction digest. Any thought?


___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] SIGHASH2 for version 1 witness programme

[Russell O'Connor via bitcoin-dev]

On Thu, May 31, 2018 at 2:35 PM, Johnson Lau via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

>
>   Double SHA256 of the serialization of:
>

Should we replace the Double SHA256 with a Single SHA256?  There is no
possible length extension attack here.  Or are we speculating that there is
a robustness of Double SHA256 in the presence of SHA256 breaking?

I suggest putting `sigversion` at the beginning instead of the end of the
format.  Because its value is constant, the beginning of the SHA-256
computation could be pre-computed in advance.  Furthermore, if we make the
`sigversion` exactly 64-bytes long then the entire first block of the
SHA-256 compression function could be pre-computed.

Can we add CHECKSIGFROMSTACK or do you think that would go into a separate
BIP?
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev