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 ...
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 sighash type conditions what is part of the digest which is eventually signed for the transaction to be valid.
Some sighash types allow to either include (commit to) part --or none-- of the outputs of the transaction in the digest. Using these far less common sighash types introduce some malleability for a transaction, which usually allow more ...
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 ...
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 ...
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.
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
When creating a Bitcoin transaction, each input explicitly states which unspent transaction output (UTXO) is consumed (via an outpoint consisting of txid:vout) and then proves the spender's authority to use this unspent. For the standard output format such a proof is a signature created by the private key corresponding to the public key the funds were ...
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.
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 signature is applied to the input being signed by default, so you don't really pick the input.
You have two options:
SIGHASH_SINGLE - All inputs are signed, and a single output with the same vout index as your vin index is signed. That is to say, if you have a tx with 5 inputs, out of which your input is the second one, and 4 outputs, all five inputs and ...
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,...