The SIGHASH type is serialized as a single byte and then simply appended to the DER-encoded signature.
Example of a typical P2PKH scriptSig:
CoinJoin uses SIGHASH_ALL.
I initially found this confusing because I assumed the interface to CoinJoin a little less synchronized than it is. CoinJoin requires each participant to first specify a UTXO and a public key to pay out to.
Someone then constructs a partially complete transaction which makes use of those UTXOs and pays out to the public keys ...
I assume it is simply the result of lazyness.
In the original client source code (and still today), the sighash type is represented as an int. The serialization framework by default serializes ints as 4 little-endian bytes.
I assume Bitcoin's creator did not bother converting it to a single byte before serializing.
If there is any other reason, I'm afraid ...
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 ...
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 ...
If the ANYONECANPAY flag is not set, hashPrevouts is the double SHA256
of the serialization of all input outpoints;
Otherwise, hashPrevouts is a uint256 of 0x0000......0000.
All the details you need are in the BIP
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.
The purpose for "after certain time, set FORKID to 0xSMTHNG" is to keep the old chain alive but separate, in case of a bug in hard fork. After a Bitcoin Cash hardfork, let's say November 2018, if you're using an incompatible client, a client that complies with May 2018, it'll make transactions with a FORKID that starts with 0xFF00, and those transactions ...
However, the length bytes seem to make the entire process extremely
Not very complex. Here is a piece of my code for generating digest for standard non-segwit transactions and sighash_all inputs (I do not need and have not tested other hashtypes).
const MyKey32 Transaction::getDigest ( const int n, const QByteArray& scr ) const
A one input/one output tx signed with SIGHASH_SINGLE|SIGHASH_ANYONECANPAY can still be modified to include more inputs and outputs, as long as the original input and output are not modified.
A tx signed with SIGHASH_ALL cannot be modified at all, and no new inputs or outputs can be added.
Partial answer (not a new solution - I merely adapted the micropayment channel protocol):
if you allow for public key exchange, one solution seems to me to be:
t1: source funds an address A controlled by source and escrow
source partially signs transaction T spending A to destination. Then
she sends this partially signed transaction to escrow.
it is ...
First, it should be said it's not possible to enforce which sighash flags may be used in a P2SH address. Signing is a concern for only the parties to wish to spend funds. Their intent can be captured using SIGHASH flags when signing.
OP is right, and certainly can mix SIGHASH flags in an input script. Signatures in the same script are considered separately,...