Thanks for all ur help.

BTW, ECDA (particularly secp256k1 that is for bitcoin) ...is there any good tutorial that I can read and study about?
I've googled, and I see several tutorials, but there is not much for a beginner though...

If you know any of resources for the ECDA that explains easier and with some implementation code, please let me know.

Thanks,

Ok..let me make sure I understood correctly.

Say this is an example..

483045022100a3658e7cedeab2800add38516aa711de2f98259df55319a92a2fa73cbaf15d94022 049ed36b8c83b386e2ae4bef82328848d06e8f0a783a25203b573942f7a5c8c48012102296038d0 cba420126d7dc75fe7edc8f5604a5ef6874b034ac65b761a73faf503

0x48 -> 72 bytes
So 3045022100a3658e7cedeab2800add38516aa711de2f98259df55319a92a2fa73cbaf15d9402204 9ed36b8c83b386e2ae4bef82328848d06e8f0a783a25203b573942f7a5c8c4801
-> This is DER encoded signature.
0x21 -> 33 bytes
So 02296038d0cba420126d7dc75fe7edc8f5604a5ef6874b034ac65b761a73faf503
-> This is public key. In this case, it starts 02..so this is compressed state of the public key.

My understanding is correct, isn't it?

Thanks,

I also have seen someone starts 0x47.....Any difference?
BTW, Is there any technical detailed doc about this signature encoding/decoding so I can take look at?

Thanks,

Ok...my question was...
Here is my understanding, BTW,

According to https://developer.bitcoin.org/devguide/transactions.html,

"As illustrated in the figure above, 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.

After putting his signature and public key in the signature script..."

So basically, in this case,

Bob.Sign(txID + output index of the previous transaction + previous pubkey script + next pubkey script + amount to spend to next one .., I believe like it says above ..the entire transaction ).....so...one that I am using is to return base64 encoded signed message.(say this stored in BobSigned variable)..then somehow I guess....I would like to create a function named scriptSig so that it should return scriptSig hex value..so..like... scriptSig(BobSigned,BobPublicKey) should return something like....."483045022100a3658e7cedeab2800add38516aa711de2f98259df55319a92a2fa73cbaf15d94022 049ed36b8c83b386e2ae4bef82328848d06e8f0a783a25203b573942f7a5c8c48012102296038d0 cba420126d7dc75fe7edc8f5604a5ef6874b034ac65b761a73faf503" .....

Is this just simply ToHex(ToByes((BobSigned + BobPubicKey)))?? I don't think so though...

Thanks,

Hello,

When the coin is spent of P2PKH, signature and public key is stored in scriptSig...if I am not mistaken. I looked at this field of payload...there r asm and hex ... It looks like signature and public key r encoded to store here...

Once u have signature and public key, then what kinds of encoding is used to get that hex one?

Thanks

Just out of curiosity...

Let's say A user bitcoin address is abcd who has 10 bitcoins...
Say...Luckily, B user got exactly same bitcoin address, which is abcd....let's just ASSUME that...In this case, both A and B user would see 10 bitcoins balances in their screen?
Then I guess whoever spends that money first would be their money then?

Thanks,

"The message is actually verified against your Bitcoin address as that is one of the three elements given to the person verifying it. Due to the unique characteristic of ECDSA, it is possible to derive the possible ECDSA public key from the signature itself. It is converted into the corresponding Bitcoin addresses during verification and then verified against the address given by the other party."

This is the KEY. I realized that this is the way how Bitcoin could verify the signature. Awesome. BTW, I found some examples that a public key is recovered from a signature using Javascript. However, I am looking for some example how this can be done with Org.BouncyCastle library. Do you know by any chance where I could get that information to recover the public key from a signature using that specific library?

Thanks,

> getaddressinfo mBlahblhbblh(this is my bitcoin address, which is base58 encoded)
it returns pub key ...this was compressed one... in order to know the uncompressed one as well, do I need do it programmatically by my own or any way I can do this as well in the console?

"You enter the Bitcoin address so it should lookup your private key from your address. "

So this is basically what I was saying. You can't get private key from public key...however, in wallet, it keeps track of pair of private/public..so it can simply look up the private from the public then...basically.

One additional question.

Under File Menu, there sign message...

So it asks the bitcoin address and message to sign message...

I understand that here segwit address cannot be used..

Let's say I entered the legacy bitcoin address...and then message...

Actually to sign message, private key is needed...so when the legacy public address is generated in my wallet, it keeps track of the private key and public key...technically, we can't know the private key from the public key, but in the wallet, when they generate public key, internally, they keep track of pair of private key and public key...so...when they entered the legacy public address when signing message, then from the wallet behind, it looks up to find out the private key from the public key to sign the message...is my understanding correct? So they actually used the private key that is found from lookup table inside wallet data structure...Correct?

Then...that message will be verified with the public key..then..

Thanks,

Awesome guys!
Huge Thanks again!

Correct, don't want to override it..probably don't need it at all.. however, just was curious whether that would be something possible or not. Yes, once I received the back the difference to the system generated address, I could send back the difference to my desired address again, in this case ABC. However, another transaction means another fees as well. So I just was thinking that if we could specify the public address where we r supposed to receive back to, at the time of when we send it somehow, we could avoid another fees possibly...

 Say my public address "ABC"...say I have 10 bitcoins..then sent to 2 bitcoins to "XYZ"...then XYZ will receive 2 bitcoins...then 8 bitcoins will send back to my new public address (generated by the system), say, this is "FFF", which is linked and governed by a master key. First of all, I am not sure how to override that "FFF" to "ABC" manually in that Bitcoin Core though... In the Send window, only inputs I see is Pay TO(which should be "XYZ", Label(this is optional), and Amount(2 bitcoins)...Maybe in order to override this, I would have to use JSONRPC command to send money then?

"Multiple transactions to a single address are different outputs and would not be linked i.e, a single address can have multiple UTXOs." ... Could you possibly explain more easily with some examples so I could understand better?

Thanks,

some additional questions came up.

1. would that even possible to send money to the same public address?
    Say my public address is ABC....then sent some coin to ABC...like I observed, the bitcoin created new public address in my wallet to send back the difference...to new one, not ABC...but somehow any way possibly to send to that ABC?

2. Here is my reasonable thinking(?).. the way bitcoin works this way is that..because it needs to keep track of UTXO.... so it *must* generate new public address to receive in that way it can easily figure out transparently whether it is spent or unspent.... Is that somehow principal of design..am I pretty much in the right track of thinking?

Thanks,

Thanks a lot. That looks like the command I was looking for ....

I *guess* that a public addressed generated by *your wallet(system)* may be hidden because I *guess* that could confuse you more...

Here is what I noticed.

1. *You* created new receiving address by clicking the button. Say this address is "ABC"...This "ABC" will be shown up in the "Receiving addresses" window.
2. You sent 0.1BT to that address "ABC"
3. In the transaction payload, I noticed that *new public address*(Say this address is "DEF") was created by the system ..and sent back the difference to this "DEF".
4. "DEF" address I wasn't able to find from that "Receiving addresses" window. I thought that since the "DEF" was also my public address generated by the system, that should be shown up in that window, but it wasn't.

5. I used listreceivedbyaddress... what I noticed is that... I still didn't see "DEF" address,  but here is what I see...

{
    "address" : "ABC"
    "amount" : blahblah..
    ....

    "txids" :[
                   "c3123456...",
                   "48056789...."
    ]
}

One of transactions in txids indicated that the "DEF" was associated in the output.... Well I thought that there should be listed something like below...........but it wasn't.

{
  "address" : "DEF"
...
..

}


Well...my observation may be too much detail..maybe no one cares..but just would like to share for anyone may be interested for educational purpose............but be aware that I am extremely beginner so this may not be true totally ..:-)
Since I really get tons of help from this site, hope this observation also could help someone...I guess like p2p network propagation so eventually reach someone that needs this info!..:-)

BTW, I really appreciate all help you guys have given so far.

Thanks,

Yes..Right.. then "In the addresses tab", which one are you talking about? I guess you are talking about "Create new receiving address" button under receive tab. Yes. you can create new address and use this to receive. What I am asking is that I want to see ALL public addresses have been generated by my wallet. What is the rpc command for that?

Maybe something like *getalladdressinfo* ..maybe..don't know..? ...then..it shows all public addresses that associated with your wallet....Is there anything like that?

Hello,

I am currently testing with Bitcoin  Core Qt v.0.21.0

1. Is there any way I can see all my public addresses associated with my wallet? I quickly google...something came up..someone mentioned there is a command getaddress something with empty parameter that responds the list of public addresses that associated with my wallet..but it looks like this is no longer true in the latest version. Is there any command for that I can try to use the list of all my public addresses of my wallet?

2. I see there is a receiving addresses window showing all public addresses have been generated. However, I believe there could be more than what these are showing.
    Here is some interesting thing I noticed.....

    I tested to send my bitcoin to myself....

    Say here is my public bitcoin address generated, which is "abc"...
    I sent 0.001 bitcoin to "abc".....
    What I noticed is that bitcoin detects the "abc" belongs to my self..so it generated new public address automatically(which I noticed in the payload, ..let's say ..this new public address "def")... .... the thing is that the "def" public address generated I wasn't able to find in the receiving addresses window...

   So I guess the list of public addresses showing in the Receiving Addresses are something that you generated explicitly by yourself.

Thanks,

2. So once the IDB is done, then sync is pretty much instantly is done. Depending on the network latency, I could see the new block right away or probably next day then...

3. So in this case, say Block B has a transaction saying PA sent 10 bitcoin to PB. Then this will be invalid transaction..so PA will receive back that 10 bitcoin...then this PA user will eventually find out the bitcoin hasn't been sent..or PB found out he/she hasn't received it..then PA will need to send 10 bitcoins again eventually?

1. When bitcoin-qt started, full sync will be performed. Say I started my bitcoin-qt, then once the full sync is done, my blockchain is up-to-date, which means, my latest block height is highest number. Correct?

2. Each node has their own copy of the blockchain. Whenever sync is done, the blockchain in each node will be updated acoordingly. So when the sync is actually performing? Only at the startup? Whenever new block is submitted from a miner? Periodically?

3.I am not sure I fully understand here...so how the block height will be synced across nodes correctly? I mean...say..in A node, there r 5 blocks...and new block submitted to this node, and added in that chain, say the block height of this new block is 6...say in B node, there are 5 blocks as well...say new block submitted to this node, and added...then this block height is also 6... So..basically same block height number, but different  blocks... wouldn't that be necessary to resolve this somehow?

Thanks

 

Hello,

I've read couple of articles and books about P2P Network discovery...

Here is my question about addr and getaddr protocol.

Let's say there are two nodes. ( 1.2.3.4 and 5.6.7.8 )...Say 1.2.3.4 knows the 5.6.7.8 peer ip address.

1. Since 1.2.3.4 knows 5.6.7.8 as a peer, so 1.2.3.4 registers 5.6.7.8 as a peer.
2. 1.2.3.4 sends "addr" to 5.6.7.8 ..then 5.6.7.8 registers the 1.2.3.4 as peer. At this point, so 5.6.7.8 has only one peer, which is 1.2.3.4
3. 1.2.3.4 sends "getaddr" to 5.6.7.8 then 1.2.3.4 receives the peers of 5.6.7.8. At this point, 5.6.7.8 only sends 1.2.3.4, which has been registered in #2.
4. When 1.2.3.4 received the list of peer, which is 1.2.3.4..then it is the same node of current host, so it doesn't register as a peer, then skipped.
5. So at this point, 1.2.3.4 has one peer of 5.6.7.8 and 5.6.7.8 has one peer of 1.2.3.4

Is my understanding pretty much correct?

Thanks,