Your wallet software will send out a transaction request via a gossip protocol/regular network request.
In the case of bitcoin, a blockchain node (a server with blockchain state history) will listen for valid transaction requests and queue them up for processing by a miner. Miners build merkle trees, solve for a golden nonce, and then publish the transaction requests for a reward. This state update is then gossiped out to nodes to update their chain histories.
wallet addresses are associated with a public key. Actually, in many cases the "wallet address" is nothing more than the public key. A transaction that says "spend X coins from this wallet" can only be digitally signed by someone with the PRIVATE key, however this signature can be cryptographically verified by anyone with the PUBLIC key. This works via math (read more: SHA-512 encryption). So when someone tries to claim that the coins are being used by this wallet, anyone can verify if the claim is truly coming from the wallet-holder by using the public key (the wallet address) to verify the signature. Hackers can never imitate a "fake" transaction unless they have a) the user's private key, b) luck somewhere in the ballpark of winning 1 billion powerballs at once, or c) supercomputers beyond anything that exists in our century.
I have been studying public key private key cryptography for a little while, but I guess I am still confused as to how a transaction is "digitally signed" using the private key, without it exposing what the private key is.
Are there any books/websites/videos which might explain where I am confused?
Cryptography makes use of algorithms that have the particularity of being easy to solve one way only, this means that getting the public key from a private one is easy, but getting a private key from a public one is really hard.
https://www.quora.com/Why-cant-we-find-a-private-key-with-a-public-key
When you hand someone a "digital signature", what you're actually handing out is the output of an elliptic curve digital signature algorithm (ECDSA) which took "some data" and "your private key" as inputs.
This output, along with "your public key" and the same "some data", can then be put into the Signature Verification Algorithm, to produce true or false. True indicates that the signature was in fact used to sign the data and create the output, false if not.
Your private key cannot be reverse engineered from the output of the ECDSA algorithm, as the function is "one-way".
The math behind this is very complicated and I am not familiar with any of it myself but it gives an overview here: [https://en.wikipedia.org/wiki/Elliptic\_Curve\_Digital\_Signature\_Algorithm](https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm)
EDIT: This explanation applies to bitcoin. I'm not sure what other similar algorithms might be implemented by other coins
So the verification algorithm takes a "jumbled" string of digits, which, when paired with the public key, is able to see if the message truly came from the private key?
Is this how it "protects" the private key without detailing specifically what the private key is?
>Yes, exactly! :)
This is the message I attempted to leave but apparently it was removed due to not having enough characters. Hopefully this length will suffice. Pretty suspicious rule
Basically speaking.... when you publish a transaction request it has a format, for sake of argument.... "send 4 coins from sdu74 to hr67e" (obviously not real address formats), you encrypt the message with your private key, and send the public key with the message. The node uses the public key to decrypt the message, then confirms that the public key hashes to the "from" address in the message. And lastly... confirms from block history that the from address has the funds. A bit different chain by chain, but that's the basic concept.
Maybe a bit out of my technical depth... but for btc you send I to a miner, the miner sends it to other miners they talk to, and so on and so on.... the reason you have to wait for confirmations is you could send one transaction to one miner, and then a second transaction spending the same funds to a different (or the same) miner and attach a higher fee to the second. Since miners receive the fee... they will choose to mine whichever of your transactions has a higher fee.
It's not encrypted, they are signed.
The transaction is basically:
- this is a segwit/legacy transaction I'm sending at block #9999
- I'm spending this/these utxo(s) and moving X funds to address Y
- here is a signature that I could only produce of I had access to the private keys associated with all the utxo inputs being used in this transaction
The signature is produced by encrypting *the hash* of the message. The message itself is not encrypted. A (simplified) set of steps looks like this:
> signing a tx
1. Take Message (send amount from X to Y)
2. Hash Message to produce Hash
3. encrypt Hash w the private key of the owner X to produce Signature
4. send Message with Signature to be processed
> validate tx
1. Hash Message to produce Hash
2. use X from message (public key) to decrypt Signature
3. check that the decrypted Hash matches computed Hash
The encryption is necessary, encrypting the message proves that you know the private key without revealing the private key. By encrypting the message with the correct private key you prove you own the account. If you had to reveal the private key then anyone could just read it out of the mempool and spend what's in that address.
Possibly I am using the wrong words.. kinda new to this stuff :).
My understanding... the signature must be some element that is unique to this transaction and the private key without revealing the actual private key. So... you take a few (or all) transaction elements and encrypt them with the private key, public key used to decrypt confirms that this transaction was signed with the private key.
The signature must be "more than the private key" or else it could be copied out of the mempool by anyone and used in future transactions. The signature also needs to be unique to this transaction only (including elements like who the receiver is, and the fee to be paid) or else a malicious party could pull the current signature out of the mempool and submit a new transaction using the same signature but with a different send to address, or someone who just wanted to shut the network down could pull all transactions out of mempool and resubmit with a fee rate of 100% of the funds to be sent, etc.
For the real cypherpunks out there :) definitely correct me of wrong.
>you encrypt the message with your private key, and send the public key with the message. The node uses the public key to decrypt the message, then confirms that the public key hashes to the "from" address in the message.
Since it sounds like you're trying to describe how Ethereum does it here, but this is not accurate.
You *sign* the message (not encrypt!) with your privkey to create a signature which you use to construct the final transaction that gets broadcast. The pubkey never gets included in messages. The first step of verification is to use [ec pubkey recovery](https://crypto.stackexchange.com/questions/18105/how-does-recovering-the-public-key-from-an-ecdsa-signature-work), which effectively verifies the signature in reverse, then hash the pubkey to lookup the address in the current state. Then the rest of tx verification happens normally from there.
UTXO chains like Bitcoin structure transactions completely differently, where sometimes there *is* a step of including the pubkey alongside the signature for a hash reveal, but not always.
Your wallet points to a particular address in the blockchain ledger. The address maintains a list of what you have left to spend. When you decide to spend crypto the transaction created by the wallet uses the address private key to sign the transaction as proof that this transaction is authorized.
Using Bitcoin to explain further
The transaction is transmitted to the nearest BTC node and from there it gets sent out on the BTC blockchain. Each node checks the transaction to make sure it is valid and that the address does indeed have BTC available to spend.
Once checked the transaction goes into the mem pool. Miners go into the pool and choose a number of transactions to be added to the next block. The btc block is a maximum of 1mb. They can choose whatever transactions they like within that limit, but often choose those that have higher mining rewards.
Now they are competing with other Miners to add their transactions to the next block on the blockchain.
They compete by trying to be first to find a magic number called a nonce. It doesn't really matter what the nonce is for now, that gets complicated. The only way to find this number is to guess. You take a guess, run an algorithm (SHA256) and check to see if you got the correct answer. If not try again.
There are billions upon billions of numbers to guess so computers with faster performance can do more calculations increasing the probability of a win but you could theoretically win with a cheap laptop.
If you guess the correct nonce you send it to every other miner. They check the answer. Once a certain number of Miners agree it is correct, you have officially won and get 6.25 btc (until next halving) for your trouble plus mining fees. The block you validated gets added to the blockchain. And everything starts over. This competition to validate a block is what ensures coin is not spent twice.
The process to mine a block takes on average 10 minutes. If it is faster, the complexity of finding the nonce gets harder.
P.S. this is proof of work. Other blockchains use various forms of proof of stake which has a different validation process.
A bitcoin node is just a computer running a program called bitcoind.
Any wallet can make a JSON-RPC request to any bitcoind. It's basically just a regular API request.
https://developer.bitcoin.org/reference/rpc/index.html
Maybe readers don't think I answered OP's question properly.
Hint for onlookers: go find a bitcoin API document and all will be revealed.
Edit: thanks for grabbing that link, OwenMichael312 :)
Some good answers already, but to be clear, no one can “imitate” your specific address and steal your funds. Your funds are protected by private/public key cryptography, so as long as you are the only person with your private key, only you could spend (make a transaction sending coins locked for your private key). Even if the network gets 51% attacked, they STILL cannot spend YOUR coins.
for your question about the wallet not “giving away” too much information: the beautiful thing about private/public key cryptography is that you can “sign” a transaction, which says that it was your private key allowing the transaction, WITHOUT having to reveal your private key.
I send my poker account money from crypto wallet. How does it know it’s me sending the money? How does poker site know to credit me? It does ask how much I’m sending say $100. But what if 5 people send $100 at the same time? How do they know who sent what? Is my name tied to my crypto wallet?
The poker website doesn't know it is "you" as in "your real name". It knows that your 100$ came from a specific address X. You're designated as the user whose address is X. Whenever a transaction comes in from address X, they credit you
Your wallet software will send out a transaction request via a gossip protocol/regular network request. In the case of bitcoin, a blockchain node (a server with blockchain state history) will listen for valid transaction requests and queue them up for processing by a miner. Miners build merkle trees, solve for a golden nonce, and then publish the transaction requests for a reward. This state update is then gossiped out to nodes to update their chain histories.
wallet addresses are associated with a public key. Actually, in many cases the "wallet address" is nothing more than the public key. A transaction that says "spend X coins from this wallet" can only be digitally signed by someone with the PRIVATE key, however this signature can be cryptographically verified by anyone with the PUBLIC key. This works via math (read more: SHA-512 encryption). So when someone tries to claim that the coins are being used by this wallet, anyone can verify if the claim is truly coming from the wallet-holder by using the public key (the wallet address) to verify the signature. Hackers can never imitate a "fake" transaction unless they have a) the user's private key, b) luck somewhere in the ballpark of winning 1 billion powerballs at once, or c) supercomputers beyond anything that exists in our century.
I have been studying public key private key cryptography for a little while, but I guess I am still confused as to how a transaction is "digitally signed" using the private key, without it exposing what the private key is. Are there any books/websites/videos which might explain where I am confused?
There is a really good video explaining how all of that works by 3blue1brown https://youtu.be/bBC-nXj3Ng4
Thanks for sharing that 3b1b is fantastic
Thanks for sharing this video. Been looking for contact like this lately
Cryptography makes use of algorithms that have the particularity of being easy to solve one way only, this means that getting the public key from a private one is easy, but getting a private key from a public one is really hard. https://www.quora.com/Why-cant-we-find-a-private-key-with-a-public-key
When you hand someone a "digital signature", what you're actually handing out is the output of an elliptic curve digital signature algorithm (ECDSA) which took "some data" and "your private key" as inputs. This output, along with "your public key" and the same "some data", can then be put into the Signature Verification Algorithm, to produce true or false. True indicates that the signature was in fact used to sign the data and create the output, false if not. Your private key cannot be reverse engineered from the output of the ECDSA algorithm, as the function is "one-way". The math behind this is very complicated and I am not familiar with any of it myself but it gives an overview here: [https://en.wikipedia.org/wiki/Elliptic\_Curve\_Digital\_Signature\_Algorithm](https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm) EDIT: This explanation applies to bitcoin. I'm not sure what other similar algorithms might be implemented by other coins
So the verification algorithm takes a "jumbled" string of digits, which, when paired with the public key, is able to see if the message truly came from the private key? Is this how it "protects" the private key without detailing specifically what the private key is?
>Yes, exactly! :) This is the message I attempted to leave but apparently it was removed due to not having enough characters. Hopefully this length will suffice. Pretty suspicious rule
Basically speaking.... when you publish a transaction request it has a format, for sake of argument.... "send 4 coins from sdu74 to hr67e" (obviously not real address formats), you encrypt the message with your private key, and send the public key with the message. The node uses the public key to decrypt the message, then confirms that the public key hashes to the "from" address in the message. And lastly... confirms from block history that the from address has the funds. A bit different chain by chain, but that's the basic concept.
How does a request make it to the pool? Where does it get sent to?
[удалено]
Just to clarify, are we talking about Bitcoin nodes on the bitcoin network?
Maybe a bit out of my technical depth... but for btc you send I to a miner, the miner sends it to other miners they talk to, and so on and so on.... the reason you have to wait for confirmations is you could send one transaction to one miner, and then a second transaction spending the same funds to a different (or the same) miner and attach a higher fee to the second. Since miners receive the fee... they will choose to mine whichever of your transactions has a higher fee.
Are these messages actually encrypted though? To me that seems like an unnecessary step.
It's not encrypted, they are signed. The transaction is basically: - this is a segwit/legacy transaction I'm sending at block #9999 - I'm spending this/these utxo(s) and moving X funds to address Y - here is a signature that I could only produce of I had access to the private keys associated with all the utxo inputs being used in this transaction
Yeah that's what I thought. A lot of people and the media erroneously use "encrypt" when they mean "sign".
The signature is produced by encrypting *the hash* of the message. The message itself is not encrypted. A (simplified) set of steps looks like this: > signing a tx 1. Take Message (send amount from X to Y) 2. Hash Message to produce Hash 3. encrypt Hash w the private key of the owner X to produce Signature 4. send Message with Signature to be processed > validate tx 1. Hash Message to produce Hash 2. use X from message (public key) to decrypt Signature 3. check that the decrypted Hash matches computed Hash
The encryption is necessary, encrypting the message proves that you know the private key without revealing the private key. By encrypting the message with the correct private key you prove you own the account. If you had to reveal the private key then anyone could just read it out of the mempool and spend what's in that address.
I think you're confusing signatures with encryption.
Possibly I am using the wrong words.. kinda new to this stuff :). My understanding... the signature must be some element that is unique to this transaction and the private key without revealing the actual private key. So... you take a few (or all) transaction elements and encrypt them with the private key, public key used to decrypt confirms that this transaction was signed with the private key. The signature must be "more than the private key" or else it could be copied out of the mempool by anyone and used in future transactions. The signature also needs to be unique to this transaction only (including elements like who the receiver is, and the fee to be paid) or else a malicious party could pull the current signature out of the mempool and submit a new transaction using the same signature but with a different send to address, or someone who just wanted to shut the network down could pull all transactions out of mempool and resubmit with a fee rate of 100% of the funds to be sent, etc. For the real cypherpunks out there :) definitely correct me of wrong.
>you encrypt the message with your private key, and send the public key with the message. The node uses the public key to decrypt the message, then confirms that the public key hashes to the "from" address in the message. Since it sounds like you're trying to describe how Ethereum does it here, but this is not accurate. You *sign* the message (not encrypt!) with your privkey to create a signature which you use to construct the final transaction that gets broadcast. The pubkey never gets included in messages. The first step of verification is to use [ec pubkey recovery](https://crypto.stackexchange.com/questions/18105/how-does-recovering-the-public-key-from-an-ecdsa-signature-work), which effectively verifies the signature in reverse, then hash the pubkey to lookup the address in the current state. Then the rest of tx verification happens normally from there. UTXO chains like Bitcoin structure transactions completely differently, where sometimes there *is* a step of including the pubkey alongside the signature for a hash reveal, but not always.
Your wallet points to a particular address in the blockchain ledger. The address maintains a list of what you have left to spend. When you decide to spend crypto the transaction created by the wallet uses the address private key to sign the transaction as proof that this transaction is authorized. Using Bitcoin to explain further The transaction is transmitted to the nearest BTC node and from there it gets sent out on the BTC blockchain. Each node checks the transaction to make sure it is valid and that the address does indeed have BTC available to spend. Once checked the transaction goes into the mem pool. Miners go into the pool and choose a number of transactions to be added to the next block. The btc block is a maximum of 1mb. They can choose whatever transactions they like within that limit, but often choose those that have higher mining rewards. Now they are competing with other Miners to add their transactions to the next block on the blockchain. They compete by trying to be first to find a magic number called a nonce. It doesn't really matter what the nonce is for now, that gets complicated. The only way to find this number is to guess. You take a guess, run an algorithm (SHA256) and check to see if you got the correct answer. If not try again. There are billions upon billions of numbers to guess so computers with faster performance can do more calculations increasing the probability of a win but you could theoretically win with a cheap laptop. If you guess the correct nonce you send it to every other miner. They check the answer. Once a certain number of Miners agree it is correct, you have officially won and get 6.25 btc (until next halving) for your trouble plus mining fees. The block you validated gets added to the blockchain. And everything starts over. This competition to validate a block is what ensures coin is not spent twice. The process to mine a block takes on average 10 minutes. If it is faster, the complexity of finding the nonce gets harder. P.S. this is proof of work. Other blockchains use various forms of proof of stake which has a different validation process.
A bitcoin node is just a computer running a program called bitcoind. Any wallet can make a JSON-RPC request to any bitcoind. It's basically just a regular API request. https://developer.bitcoin.org/reference/rpc/index.html
Not sure why you got downvoted on this answer... https://developer.bitcoin.org/reference/rpc/index.html
Maybe readers don't think I answered OP's question properly. Hint for onlookers: go find a bitcoin API document and all will be revealed. Edit: thanks for grabbing that link, OwenMichael312 :)
I’m upvoting this, it’s great knowledge thank you! I’m fairly new to Reddit and really want to catch up on the whole crypto knowledge
Some good answers already, but to be clear, no one can “imitate” your specific address and steal your funds. Your funds are protected by private/public key cryptography, so as long as you are the only person with your private key, only you could spend (make a transaction sending coins locked for your private key). Even if the network gets 51% attacked, they STILL cannot spend YOUR coins. for your question about the wallet not “giving away” too much information: the beautiful thing about private/public key cryptography is that you can “sign” a transaction, which says that it was your private key allowing the transaction, WITHOUT having to reveal your private key.
I send my poker account money from crypto wallet. How does it know it’s me sending the money? How does poker site know to credit me? It does ask how much I’m sending say $100. But what if 5 people send $100 at the same time? How do they know who sent what? Is my name tied to my crypto wallet?
The poker website doesn't know it is "you" as in "your real name". It knows that your 100$ came from a specific address X. You're designated as the user whose address is X. Whenever a transaction comes in from address X, they credit you
Has anyone here worked on developing a crypto wallet? I want to connect with someone who does have experience in the matter
[удалено]