Bitcoin Forum
June 29, 2024, 01:07:28 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: [1]
1  Bitcoin / Development & Technical Discussion / Re: high-level Bitcoin transaction understanding on: August 14, 2014, 12:36:49 AM
Thank-you all for our contributions! Over the last few days of studying, I [think that I] understand all of the basics of transactions now! I truly appreciate it.

I'm not starting to familiarize myself with the scripting process. I understand that the scriptPubKey sets conditions to be solved by the scriptSig. I also understand that there are different ways to do it. Here is the standard one I found on the wiki: https://en.bitcoin.it/wiki/Script#Standard_Generation_Transaction_.28pay-to-pubkey.29

The one before it, P2PKH seems much more complicated. https://en.bitcoin.it/wiki/Script#Standard_Transaction_to_Bitcoin_address_.28pay-to-pubkey-hash.29

My question is, is there an advantage that P2PKH offers over Standard in terms of security? If I were trying to implement my own transaction, which one should I follow? Thanks in advanced for any help!
2  Bitcoin / Development & Technical Discussion / Re: high-level Bitcoin transaction understanding on: August 08, 2014, 11:47:59 PM
azeteki, thanks for simplifying it for me. I appreciate your consistently detailed replies  Smiley
I was kind of lost when I initially tried to read that page. So basically, the scriptPubKey was provided by Alice as an output from tx1, and Bob, wanting to spend it, must provide his scriptSig as a input in tx2 (to the third man - Charlie).

amaclin, thanks for chiming in and helping. So from what I understand, you are saying that Bob sees Alice's transaction to him initially, but sees it again when it becomes "official" when included in the block (the transaction block in the block chain I assume?). Bob's real proof comes when he's trying to send it to Charlie - through means of providing his scriptSig to the input (corresponding to output of his transaction with Alice)?

Thanks again to the both of you.
3  Bitcoin / Development & Technical Discussion / Re: high-level Bitcoin transaction understanding on: August 07, 2014, 11:30:41 PM
So in tx2, Bob is creating a signature (scriptSig), which is based off of his private key. The scriptSig can be used to sign inputs, as well as the entire transaction (as in the whole transaction block? Or other elements of that block?).

Alice has already created scriptPubKey from tx1, containing Bob's public key (or it's pubkeyhash).

In tx2, Bob's scriptSig must produce a value verifiable by pubkeyHash (of tx1). On a lower level, is his signature is being compared to his public key from pubkeyhash?

Also, when you stated: "The outputs must included within the signature too (with the correct key as described in the input) because otherwise an attacker could re-use Bob's input signature and change the outputs."
Outputs (I'm assuming are large numbers, similar to addresses), are embedded into the scriptSig as well? But I'm guessing there is a signature part of scriptSig that signs the transaction?

So generally, outputs to Bob contain a scriptPubKey from the sender (Alice). To be used as inputs and used, the receiver (Bob) must have produce the scriptSig that satisfies the scriptPubKey. So in the context of him spending to a third man, he would have to attach a new scriptPubKey to that input (to become an output in tx2)? And the third man would have to produce sigScript3rd to be able to spend it?


Thanks for all your help once again. I apologize if this may seem a bit slow.
4  Bitcoin / Development & Technical Discussion / Re: high-level Bitcoin transaction understanding on: August 07, 2014, 08:42:55 PM
Thank you for replying azeteki,

From what I understand of what you said, basically because Alice (sender) appended Bob's (receiver) address (and therefore public key) to the outputs. If he can then, sign the outputs (now considered inputs for his next transaction) with his public key, then he will be able to spend it? I was under the assumption that you can only sign with your private key?

The inputs (relative to Bob's spending transaction with someone else) are solved by Alice (as outputs of their exchange)?

Lastly, in your opinion, if I am just trying implement a function to create a transaction, would p2pkh be the simplest way of creating a valid transaction? Thanks again! I truly appreciate any help!
5  Bitcoin / Development & Technical Discussion / high-level Bitcoin transaction understanding on: August 07, 2014, 07:08:37 PM
Hi all,

I recently got into the Bitcoin development scene and am trying very hard to understand transactions as a start. I've been using the Bitcoin wiki, as well as the following guide to familiarize myself: https://bitcoin.org/en/developer-guide#transactions

I was wondering if anybody could help me go through my logic (below), and point out any misunderstandings I may have. Any help is appreciated!

For the sake of understanding, let's assume the sender is Alice, and the receiver is Bob.

1) The receiver (Bob) must generate a private key, and therefore public key, and therefore a Bitcoin address (which is the pubkeyhash?). He sends it to Alice (the sender).

2) Alice must sign her UTXOs (unspent outputs) with her private key (using ECDSA to sign?) and append her signature (from what I understand, the signature is made from P2SH or P2PKH scripts, but what does "append" mean?).

3) She also appends Bob's address to her outputs given to him (again, what does "append" mean technically?).

4) She broadcasts this to the Bitcoin network and once a miner verifies that it was indeed her UTXO to use, the transaction itself is verified.

5) Bob now has his UXTO to spend. This is where I get confused. How does Bob prove that it is his UTXO now? Since it was Alice who signed it, how does he prove it?

I apologize if this may seem trivial to some of you, but to me, a newcomer, this is all very confusing. I would appreciate any help that you guys can spare. Thanks in advanced!
Pages: [1]
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!