<p>Transactions are chained in a way that when Alice spend funds, she has to provide two pieces of information, the first one is a proof that the money was sent to her  and the other is a challenge for whomever wants to spend the coins she is sending, so when Alice received her coins she provided an Address, I.E the challenge, or a hash of the challenge to be more precise.</p>

<p>When Bobs gives his address he is doing the same, he is providing the challenge that needs to be solved in order to spend the coins.</p>

<p>When Bob generates an address what he is doing is generating a key pair, the private key he keeps secret to use when he wants to spend funds, and the public key is hashed twice and encoded in a special format, (Base58Check), and is that encoded hashed value what he shares with Alice. </p>

<p>So when Alice pays to Bob, she creates a new transaction, that refers to the old transaction from which she is spending, that old transaction has the hash of Alice's PublicKey, it pays to whomever can demonstrate that owns the ECDSA private key that generated Alice address. That is easy to check, because Alice provides the public key that hashes to that address and she signs the spending transaction with the private key and adds the signature to the transaction that spends the funds.</p>

<p>It means that she needs not only to prove that she has the private key, but she must also prove that having the private key she approves the spending by signing the transaction that spends her funds.</p>

CC BY-SA 4.0
2018-05-31T02:28:43.587Z
I am wondering what keeps another actor, Charlie, from copying Alices's announcement when Alice wants to transfer her coins? So if Alice accidentally only announces her proof that she may spend the funds to Charlie, can Charlie use this information to spend the coins?
HRSE
CC BY-SA 4.0
2018-06-06T19:55:21.020Z
Well, all the data is provided in one transaction, if you separate the proof from the spending then you'll need Alice to sign the new spend again, and for that you need Alice to collaborate, which renders the attack useless.
galileopy
CC BY-SA 4.0
2018-06-07T05:35:56.973Z
Thank you for your answer. I was unclear. I meant: what if Alice announces her entire transaction (with Bob as recipient) only to Charlie, but nobody else. Why can Charlie not use that information to spend Alice's coins?
HRSE
CC BY-SA 4.0
2018-06-08T13:03:08.033Z
the moment he changes any input, or output he has to sign the entire transaction with Alice's key, the maximum he can do is censor Alice, but Bob will notice that and he could ask Alice for the signed transaction so he can broadcast it. This concept is what allows Lightning Channels to work.
galileopy
CC BY-SA 3.0
2016-03-21T23:39:40.350Z
2016-03-21T23:44:56.447Z
2016-03-21T23:44:56.447Z
galileopy
<p>How are bitcoins reassigned, that is, what about a transaction makes a "coin" no longer usable by the sender, and makes it usable by the recipient?</p>

<p>Alice wants to send bitcoins to Bob. Alice's wallet gathers transactions originally sent to Alice so that the monetary amount of said transactions is at least the amount that Alice wants to send Bob. The transaction is basically a message, so a little bit of ECDSA on top of that and boom, there's a transaction: only Alice could have created that particular transaction (message), and anyone can verify Alice's signature for that transaction.</p>

<p>Now Bob "receives" the money. Why can he use it? (Indeed, why could Alice use the money above...) Digital signatures of themselves don't solve this problem, i.e. the transaction/message along with its signature doesn't "transfer" anything, there's gotta be some other ingredient involved, but what is it? I can't see, or at least not understand, the answer in the various sources I've read.</p>

<p>It has to be something about Bob's private key, but I can't see how it's used to "unlock" the money he received from Alice. I don't know what transactions look like exactly, but suppose they're basically of the form tx_1 = (Alice's public key)+amount+(Bob's public key) - would Bob's wallet basically be saying "reproduce Bob's public key and you can access tx_1"? I guess that would do the trick, but then again Bob was already "logged on" to his wallet so he's already proven the ability to reproduce Bob's public key.</p>

<p>Ok I think I'm getting ahead of myself. Anyway, received transactions, how are they "unlocked"? Thanks.</p>

<p>(Yes, I have tried finding an answer on BSE and elsewhere already.)</p>

CC BY-SA 3.0
2016-03-22T21:46:00.740Z
Simply put, Alice provides the key to the lock that currently holds the funds, and a new lock (that she got from Bob somehow) to put on the funds. Bob has to give Alice a lock he has the key to -- which is what a Bitcoin address is.
David Schwartz
<transactions>
How are bitcoins reassigned?
Erik Vesterlund
# How are bitcoins reassigned?

(Asked by: username_0 on 2016-03-21)

How are bitcoins reassigned, that is, what about a transaction makes a "coin" no longer usable by the sender, and makes it usable by the recipient?

Alice wants to send bitcoins to Bob. Alice's wallet gathers transactions originally sent to Alice so that the monetary amount of said transactions is at least the amount that Alice wants to send Bob. The transaction is basically a message, so a little bit of ECDSA on top of that and boom, there's a transaction: only Alice could have created that particular transaction (message), and anyone can verify Alice's signature for that transaction.

Now Bob "receives" the money. Why can he use it? (Indeed, why could Alice use the money above...) Digital signatures of themselves don't solve this problem, i.e. the transaction/message along with its signature doesn't "transfer" anything, there's gotta be some other ingredient involved, but what is it? I can't see, or at least not understand, the answer in the various sources I've read.

It has to be something about Bob's private key, but I can't see how it's used to "unlock" the money he received from Alice. I don't know what transactions look like exactly, but suppose they're basically of the form tx\_1 = (Alice's public key)+amount+(Bob's public key) - would Bob's wallet basically be saying "reproduce Bob's public key and you can access tx\_1"? I guess that would do the trick, but then again Bob was already "logged on" to his wallet so he's already proven the ability to reproduce Bob's public key.

Ok I think I'm getting ahead of myself. Anyway, received transactions, how are they "unlocked"? Thanks.

(Yes, I have tried finding an answer on BSE and elsewhere already.)

**Tags:** transactions

> **Comments:**
> **username_1**: Simply put, Alice provides the key to the lock that currently holds the funds, and a new lock (that she got from Bob somehow) to put on the funds. Bob has to give Alice a lock he has the key to -- which is what a Bitcoin address is.  

---

## 1 answers

### Answer by username_2 on 2016-03-21. Score: 3 | Accepted answer

Transactions are chained in a way that when Alice spend funds, she has to provide two pieces of information, the first one is a proof that the money was sent to her and the other is a challenge for whomever wants to spend the coins she is sending, so when Alice received her coins she provided an Address, I.E the challenge, or a hash of the challenge to be more precise.

When Bobs gives his address he is doing the same, he is providing the challenge that needs to be solved in order to spend the coins.

When Bob generates an address what he is doing is generating a key pair, the private key he keeps secret to use when he wants to spend funds, and the public key is hashed twice and encoded in a special format, (Base58Check), and is that encoded hashed value what he shares with Alice.

So when Alice pays to Bob, she creates a new transaction, that refers to the old transaction from which she is spending, that old transaction has the hash of Alice's PublicKey, it pays to whomever can demonstrate that owns the ECDSA private key that generated Alice address. That is easy to check, because Alice provides the public key that hashes to that address and she signs the spending transaction with the private key and adds the signature to the transaction that spends the funds.

It means that she needs not only to prove that she has the private key, but she must also prove that having the private key she approves the spending by signing the transaction that spends her funds.

> **Comments:**
> **username_3**: I am wondering what keeps another actor, Charlie, from copying Alices's announcement when Alice wants to transfer her coins? So if Alice accidentally only announces her proof that she may spend the funds to Charlie, can Charlie use this information to spend the coins?  
> **username_2**: Well, all the data is provided in one transaction, if you separate the proof from the spending then you'll need Alice to sign the new spend again, and for that you need Alice to collaborate, which renders the attack useless.  
> **username_3**: Thank you for your answer. I was unclear. I meant: what if Alice announces her entire transaction (with Bob as recipient) only to Charlie, but nobody else. Why can Charlie not use that information to spend Alice's coins?  
> **username_2**: the moment he changes any input, or output he has to sign the entire transaction with Alice's key, the maximum he can do is censor Alice, but Bob will notice that and he could ask Alice for the signed transaction so he can broadcast it. This concept is what allows Lightning Channels to work.  

---

