Hi @amaclin

hi. i am here but what is the reason for?

Im checking your great answer bitcoin.stackexchange.com/questions/32628/…

If you have some time to clarify

this is not my answer

it is some kind of remake

the original answer was in bitcoin.stackexchange.com/questions/3374/…

I just made all the steps with the data provided by Wizard Of Ozzie

Sorry, my English is not perfect and sometimes I do not understand what am I asked for

So, what do you need?

OK. Bullet 5.

we need to create "message for signing"

So you have the input 0 and input 1 for example.

this message looks like the final transaction, but has some difference

These inputs need to be signed with private keys.

Input 0 comes from some output X, and Input 1 comes from some output Y

if we create the transaction with two inputs than we have to create two "messages for signing"

we fill the room for scriptsig with the scriptpub of output

and do not ask me why the things are so complicated :) ask satoshi

ok, I'll try to explain

we have transaction with 2 inputs

:)

Input 0 comes from output X, and Input 1 comes from output Y

first, we create a "template" where scriptSig0 is pubkey0 and scriptSig1 is empty

Output X is related to public key X and private key X and Output Y is related to public key Y and private key Y?

seconnd we create template where scriptSig0 is empty and scriptSig1 is scriptPub1

And pubkey0 is public key X?

0=X, 1=Y

sorry, not "pubkey0" but "scriptPub0"

let me rewrite with X and Y

first, we create a "template" where scriptSig0 is scriptPubX and scriptSig1 is empty

second we create template where scriptSig0 is empty and scriptSig1 is scriptPubY

OK

And scriptPubX is just copy of previous output script?

yes, byte-by-byte for p2pkh and p2pk outputs

OK, now you have 2 templates, then what

sorry, i do not remember exactly what to do with p2sh

np

then sign the first message with first private key and second message with second private key and fill the room for signatures with this values

first template* ?

yes. and sign ( sha256d ( template ) )

i did not have crypto education in my colledge, so i do not know how to say correct: do we sign a message/template, or we sign digest of this message calculated by sha256d

and then fill the scriptSig0 with sign(template0) and scriptSig1 with sign(template1)

I think we do not have digest in ECDSA only in RSA

You just sign something with ECDSA

sign function accepts 32-byte value, not a message itself afaik

I think it accepts the entire message

and this 32-byte value S.N. calculated as sha256d ( message )

Then internaly hashes I think

OK

i think that ecdsa and sha256d are not related at all. we can create an engine where use any other cryptosecure function e.g. scrypt ( ) with ecdsa. but current bitcoin and other bitcoin forks create digest as sha256d

(even litecoin)

ok, may be ECDSA can sign a message. i do not know. Satoshi signs sha256d ( template )

Yes you must hash it somehow.

So you fill scriptSig0 with sign(sha(template0)) and scriptSig1 with sign(sha(template1))

slow down :)

:D

we have DER-encoded signature. first concatenate it with hashType

this is full bulshit appending byte to standard representation !

but ask satoshi why

ok, you concatenated signature and a 0x01 byte

and the final scriptSig will be <push thissignature> <push publickey>

publicKey or scriptPubX?

btw you from Romania?

publickey

russia

Oh.

i thought i am more famous person :) motherboard.vice.com/en_us/article/pga7m9/i-broke-bitcoin

That is you?

me

You made some kind of attack on BTC?

that one was the most known

I agree that btc is ponzi at the moment.

It costs 10$ to send transaction.đ

natural cost

This is way to high, and when difficulty rises it will be even more, so no reason for btc to succede.

Lightning network could probably save btc

people do not understand the difference between natural cost and fee. the engine where natural cost is larger than the fee is always ponzi

no chances for LN

This signing is way to complicated.

I would just use like this, for each input use that input's TX hash and output index, and all the outputs, sign that and put the signature in that input's pubScript

Do that for each input.

in segwit transactions creating template is different

but still complicated. i used reverse-engeneering to understand it

But is my proposal here above enough

(you speak english perfectly btw, without any mistake)

sorry, what proposal?

Let's say you have input1 and input2 and output1 and output2.

i do some interesting things and sometimes lost in them :)

Now to sign input1, use input1's TX hash and its output index

and also all the outputs. Sign that and put into input1's scriptSig.

To sign input2, use input1's TX hash and its output index and also all the outputs. Sign that and put into input2's scriptSig.

this is another type of hashType. Satoshi put several different types how to create a template

So you want to say this template exist's

but 99.99% of transactions go with hashType=[ALL]

hashType meaning what is hashed before signing (that is template)?

yes

perfect understanding

ty

I'm making my own coin

In node.js core and javascript web based gui.

the last byte what was concatenated to signature means what was actually hashed and what we need to construct when verify

But you remove that prior to broadcasting. Bullet 19.

removed from template

we do not need the template now

No, you said you remove them from final transaction

i do not know why it was written in such urgly reuse-data style

Maybe in 16. "We construct the final scriptSig by concatenating: <One-byte script OPCODE containing the length of the DER-encoded signature plus the one-byte hash code type>|< The actual DER-encoded signature plus the one-byte hash code type>|< One-byte script OPCODE containing the length of the public key>|<The actual public key>"

'the one-byte hash code type' this is the hash type

we have a template. it is very close to final transaction. we have to do only two things: remove hashtype from the tail and fill the scriptSig fields

But the hashtype is re-added as part of the scriptSig

yes. the verifier proceed in opposite way: it takes last byte. depending on it it constructs template (6 variants exist today), hashes it with sha256d and executes verify ( pub, sig ) ecdsa method

backwards

But also why include public key in the scriptSig

public key can be found in redeemed output transaction, why duplicate it in this transaction.

because satoshi did not know that public key can be derived from signature and digest :)

no, there is no public key in output, only the hash160 of it

But not just that.

It can be found in previous output

no

Oh.

Why not put it there.

Instead in this scriptSig.

okay. it was there at first time

that type of output scripts was p2pk (pay-to-public-key)

but. this is not very good.

And p2pkh is pay to public key hash?

there are several reasons why p2pkh is better than p2pk

read wiki please

ok

i have to go, bye

Good night!

I read some data, and I think the reason to use p2pkh is: shorter address (like 20 bytes comparing to 33), and some additional security (in case ECDSA gets broken).

@amaclin But it uses more bytes bitcoin.stackexchange.com/questions/32639/…

So I don't see that much reason to use p2pkh.

But I see why you must include public key with the scriptSig when using p2pkh, and that you don't if you use p2pk.