The SIGHASH type is serialized as a single byte and then simply appended to the DER-encoded signature.
Example of a typical P2PKH scriptSig:
The lightning network as is is working without SIGHASH_NOINPUT. Thus in its current form it is not needed.
However Christian Decker came up with the eltoo payment channel construction. In a nutshell this would get rid of the penalty based construction we use right now and reduce a lot of overhead for maintaining channel state as the state becomes ...
Varying the signature per input helps prevents some attacks during multi-party transaction construction.
Consider a coinjoin involving Alice and Bob. Alice selects one of her UTXOs for the coinjoin. Bob chooses a UTXO for his input, but he actually selects ones of Alice's other UTXOs that reuse the same address as the one she selected. Alice does not ...
This struct appears to describe the SIGHASH flags:
/** Signature hash types/flags */
SIGHASH_ALL = 1,
SIGHASH_NONE = 2,
SIGHASH_SINGLE = 3,
SIGHASH_ANYONECANPAY = 0x80,
and it's encoded as the last byte. Note that SIGHASH_ANYONECANPAY can appear in conjunction with any of the three previous flags.
SIGHASH_NONE implies that Input 2 will only spend if Input 1 is included in the transaction.
This is false.
Input 2 is essentially a blank check. SIGHASH_NONE signs none of the outputs (I don't care where the BTC goes), and SIGHASH_ANYONECANPAY signs only input 2 (I don't care who else is participating in the tx. This essentially creates an input, which if ...
I'm just guessing, but by having the transaction commit to the scriptCode, we ensure that the signer knows what script they're signing for. A hardware wallet, for example, can only be certain that outpoint 1234...cdef:0 pays a particular script if we give it the transaction that created that outpoint (so that it can hash that transaction, verify the txid, ...
I'd been wondering about this for quite a long time, since it was the reason behind the quadratic hashing problem. The best answer I found so far is the one given by Pieter Wuille in the Bitcoin talk forum. The answers is most likely not going to be satisfying though.
Do I understand correctly that both inputs are to be signed
So first, we sign the first one, then the second one. To sign an input
we replace scriptSig for this input with the scriptPubKey, that locks
this input. ScriptSig for the other one remains blank. It this
But in both threads in step 13 something is appended at the end ...
No, this is not possible - once an outpoint is consumed by a transaction, it is considered spent, including within the same transaction.
Your only option here would be to have an intermediary transaction splitting A (or using another input), and then using the two outputs from that as inputs along with SIGHASH_SINGLE | SIGHASH_ANYONECANPAY for your flags.
After some additional research and helpful information found here, I was able to conclude the following:
Transactions encoded on 0.12.X bitcoin and then broadcast on 0.15 bitcoin may encounter "mandatory-script-verify-flag-failed (signature must be zero for failed check(multi)sig operation)"
This problem can be solved by doing the following:
Signing your 0....
In this particular case, the parameter script code refers to a public key script.
Usually, the function SignatureHash is invoked to either sign a transaction or to verify a signature. Thus it refers to a transaction input (this is either the transaction input for which we want to generate the signature that will then be placed in the signature script or ...
You are signing a specially modified version of the transaction itself. The modified transaction involves replacing the scriptSig field temporarily with the scriptPubKey from the transaction output being spent, and leaving all other inputs' scriptSigs empty, and then appending a 4 byte signature type code. The transaction is then hashed twice with SHA256 and ...