Latest posts of: fabbit

Thanks for answer, I was reading about BIP-174 proposal..

Yes I understand this, but so the transaction should have at least two input, one for SIGHASH_ALL and the other for SIGHASH_NONE?
And if it is a Bob's transaction so we're talking about Bob's scriptSig, how Alice can put her sign (SIGHASH_ALL) in Bob's inputs?

I mean those kind of transactions look like as collaborative transaction because different parties are contributing in inputs and no as a standard transaction owned by a single 'people', I was reading about PSBT protocol for collaborative transactions.

Quote from: BrewMaster on January 21, 2020, 01:13:58 PM

then the other parties that are responsible for spending set the destination (like paying the employees each 0.01BTC) and provide at least one signature with SIGHASH_ALL.

Hey, I didn't understand this, why other parties provide one signature with SIGHASH_ALL?

A scriptPubKey is (invented):

Code:

"scriptPubKey" : {
 "asm" : "OP_DUP OP_HASH160 7d7\
 OP_EQUALVERIFY OP_CHECKSIG",
 "hex" : "fg8ad8a",
 "reqSigs" : 1,
 "type" : "pubkeyhash",
 "addresses" : [
 "d8d"
 ]

hash(7d7)==d8d ?

For SIGHASH_NONE I found this https://raghavsood.com/blog/2018/06/10/bitcoin-signature-types-sighash

Quote

This is mostly designed to be used in scenarios where more than one party is contributing inputs. At that point, such a signature essentially means “I agree to spend my money, provided all these other people spend their’s too”. It is expected that one of the other signers will then use SIGHASH_ALL to secure all the outputs of the transaction, and send the money to a mutually agreed output set.

Which are real scenario where HASHSIG_NONE and HASHSIG_SINGLE are used?

Yes, and there are other important properties?

Which are the most important properties of Bitcoin scripts?
I know:

turing incomplete
stack based
stateless

are there other?

But if a script will be executed the same way in every client, if my node verifies the script than all other nodes verify the script too, because the behaviour is the same in every node?

Thanks, but why the scriptSig is replaced with scriptPubKey?

Hi everyone,

I am reading an article about how HASHSIG works, but i don't understand this:

Before the signature is computed, several temporary changes are made to the transaction: The signature script of the currently signed input is replaced with the public key script, excluding all occurences of OP CODESEPARATOR in it, of the referenced transaction output.

I mean why the scriptSig is replaced with the scriptPubKey?

After reading this article (page 30): https://www.lopp.net/pdf/Bitcoin_Developer_Reference.pdf
it is clearer, but I don't understand point a).
I don't understand why the scriptSig is replaced with pubKeyScript and what OP_CODESEPARATOR does.

Thanks,

For example could you show me how SIGHASH works for this kind of transaction?

Thanks,

Mh I mean when a node received the broadcasted transaction why does the node check for transaction's validation? I mean the node should already known that the transaction is valid for stateless verification principle.

I don't understand this:

Quote

If your system verifies a script, you can be sure that every other system in the bitcoin network will also verify the script, meaning that a valid transaction is valid for everyone and everyone knows this.

If a transaction is valid for everyone and everyone knows, why is the transaction broadcasted?

Quote from: BitMaxz on January 15, 2020, 10:51:31 PM

You might need to read the "Mastering Bitcoin by Andreas M. Antonopoulos" from here below to get some idea.

- https://www.oreilly.com/library/view/mastering-bitcoin/9781491902639/ch05.html

Actually I read that part of the book but I didn't understand it very well

Because according to this:

Quote

the data Bob signs includes the txid and output index of the previous transaction, the previous output’s pubkey script, the pubkey script Bob creates which will let the next recipient spend this transaction’s output, and the amount of satoshis to spend to the next recipient. In essence, the entire transaction is signed except for any signature scripts, which hold the full public keys and secp256k1 signatures.

These are the parts that are signed in a transaction by default so using SIGHASH_ALL

Quote from: darosior on January 12, 2020, 05:48:35 PM

EDIT: For going further, you could give a look to SIGHASHes which dictates which parts of a transaction are signed, leaving some malleability/flexibility for some advanced usage.

I'm reading about this, but for example considering SIGHASH_SINGLE "This type of signature signs all inputs, and exactly one corresponding output", in a transaction like this A->B->C, B's unlocking script has the sign but does he signs A's outputs or new generated B's output?

What are the advantages of a stateless verification?

Thanks, it is much more clear now. But why do we need to do OP_EQUALVERIFY? I mean what are the security issues if we don't execute that operation?