<p>I think it would be helpful for you to identify your service here, so that I can encourage people to not do business with you.</p>

<p>Users generally have no idea if this will work safely or not, so a notice will not be sufficient. If you send users funds to addresses they did not supply you should be prepared to pay them out when they report the funds have gone missing or find yourself on the losing side of a lawsuit-- and there would be no shortages of experts willing to testify on behalf of someone you failed to pay due to this.</p>

<blockquote>
  <p>Yet each incoming transaction has its own list of incoming transactions with its own outputs sent to various "destination addresses", therefore the notion of their being no "from address" is not valid. </p>
</blockquote>

<p>Sorry, that simply is not correct.</p>

<p>Coins have a history from which you could derive prior "To" addresses, that much is correct. But a prior "To" is not a "from".  For example,  if you ordered a produce from amazon, received it, then inspect the parcel with a magic wand that told you the last place the parcel was shipped you might find it was last sent to a reshipment center in Oregon.  But that is just some shipper, not the source (amazon) and if you attempted to "return" the package by simply shipping it there it would likely end up lost.</p>

<p>Your order "from" amazon may have gone through dozens of steps or indirection before reaching you, and the last hop may have only the thinnest of relationships to the actual origin.</p>

<p>Even if the "from" is correct the user may simply no longer have access to the keys. With no more use for them they simply may have discarded them (e.g. a 'paper wallet' or other token). Users can setup persistent donation addresses intentionally taking due care to preserve the key material, and for donations the security/privacy implications are reduced because of the very nature of the payments (the donation addresses are public and the funds aren't provided in exchange for any consideration). And when access isn't lost completely, the keys in question may not be readily accessible, but stored in a safe deposit box or time lock safe.  The funds could have also been spliced out of a payment channel and the prior-to could be inaccessible to the user without significant software modification or the help of a third party.</p>

<blockquote>
  <p>What privacy? Bitcoin doesn't provide any privacy...</p>
</blockquote>

<p>Bitcoin does provide privacy and has since day one. It is specifically called out as a top level section in the Bitcoin whitepaper. The privacy Bitcoin provides isn't perfect for sure, but one of the biggest things that damages privacy is address reuse because it creates co-input linkage, causing otherwise completely independent spends to be obviously linked.  Mixing "services" are frequently scams that steal user funds.</p>

<p>Your self-described "rant" seems to have also ignored the largest practical consideration: A great many wallets (perhaps the largest in total user count) are thoroughly incompatible with your intended behavior.  If a user pays you from a hosted wallet and you "refund" to one of the apparent prior-to addresses, the funds will be delivered to some other random user (who will probably promptly withdraw their windfall, never to be heard from again).</p>

CC BY-SA 4.0
2019-03-21T18:52:31.507Z
your amazon analogy is incorrect because the intermediate shipping facility has no claim of **exclusive** ownership over the shipment.  Exclusive ownership rights are first owned by amazon, and then the customer, from->to, a direct ownership transfer.  The bitcoin white paper states that `coins [are] made from digital signatures, which provides strong control of ownership` the digital signature provides the EXCLUSIVE ownership rights.
user3338098
CC BY-SA 4.0
2019-03-21T19:10:31.207Z
`a notice will not be sufficient`, I was not aware of this... are you saying that satoshidice.com is at risk of lawsuits from any customer who fails to understand their
notice `IMPORTANT: Only use wallets that allow you to receive Bitcoin from the same address you sent from.` ???
user3338098
CC BY-SA 4.0
2019-03-21T19:11:28.720Z
`the user may simply no longer have access to the keys` which is the their wallets fault (I would be doing immediate refunds), therefore I ask the question "how many wallets fail to support address reuse?".
user3338098
CC BY-SA 4.0
2019-03-21T19:12:41.723Z
`the funds will be delivered to some other random user` which I reiterate probably violates the white papers statement that `digital signatures [provide] strong control of ownership` and so unexpectedly transferring ownership of a private-key in my opinion violates this principle.
user3338098
CC BY-SA 4.0
2021-06-11T22:03:07.893Z
Reviewing your answer and my comments, I have to ask... Why did you even post an answer?  Your answer does not even address the question... in fact it ignores the bulk of the question...
user3338098
CC BY-SA 4.0
2021-06-11T22:11:22.780Z
Since no one else answered I ended up offering the customer the ability to specify an automatic refund address, it was a waist of time, but without knowledge of how many clients are defective I had to resort to the worst possible implementation to pander to incompetent bitcoin wallet developers.  Thanks for nothing.
user3338098
CC BY-SA 4.0
2021-06-11T22:13:31.703Z
Since I no longer care about an answer, I will be deleting this question.  Again, thanks for nothing.  You wasted my time, congratulations!
user3338098
CC BY-SA 4.0
2019-03-19T03:40:26.283Z
2019-03-19T03:40:26.283Z
G. Maxwell
<p>I have implemented an automated bitcoin refund function that sends funds back to the address that was used to sign the incoming transaction.  How many wallets fail to support address reuse/refunds?  If it's just a few wallets or only shared e-wallets then I am content with a notice on my site explaining the situation.</p>

<h1>Responses to common objections (i.e. rant)</h1>

<ul>
<li><strong>There is no "from address"</strong></li>
</ul>

<p>Yet each incoming transaction has its own list of incoming transactions with its own outputs sent to various <strong>"destination addresses"</strong>, therefore the notion of their being no "from address" is not valid.  (note I'm not concerned with uncommon transactions such as coinbase transactions which truly can't be refunded automatically...  I am content to handle refunds for these uncommon transactions on a manual basis if needed.)</p>

<ul>
<li><strong>address reuse hurts privacy</strong></li>
</ul>

<p>What privacy?  Bitcoin doesn't provide <em>any</em> privacy... the transaction graph is open to the <strong>public</strong> and your silly if you think social graph networking algorithms can't link these transactions together with high probability.  if you wan't privacy use a mixing service... if you can't then there is very little privacy for your transaction.</p>

<ul>
<li><strong>address reuse is not secure</strong></li>
</ul>

<p>Bad implementation does not equal bad security protocol.  Just because <a href="https://stackoverflow.com/questions/17008967/securerandom-self-seeding#comment97198180_17011591">a few wallets used to implement cryptographic algorithms incorrectly</a> doesn't mean I should forever believe that the same cryptographic protocol is insecure for wallets that are correctly designed.</p>

<ul>
<li><strong>addresses are intended for one-time use</strong></li>
</ul>

<p>really? then why are donation addresses valid for years???</p>

<address-reuse>
How many wallets don't support address reuse? (for refunds)
user3338098
# How many wallets don't support address reuse? (for refunds)

(Asked by: username_0 on 2019-03-19)

I have implemented an automated bitcoin refund function that sends funds back to the address that was used to sign the incoming transaction. How many wallets fail to support address reuse/refunds? If it's just a few wallets or only shared e-wallets then I am content with a notice on my site explaining the situation.

# Responses to common objections (i.e. rant)

* **There is no "from address"**

Yet each incoming transaction has its own list of incoming transactions with its own outputs sent to various **"destination addresses"**, therefore the notion of their being no "from address" is not valid. (note I'm not concerned with uncommon transactions such as coinbase transactions which truly can't be refunded automatically... I am content to handle refunds for these uncommon transactions on a manual basis if needed.)

* **address reuse hurts privacy**

What privacy? Bitcoin doesn't provide *any* privacy... the transaction graph is open to the **public** and your silly if you think social graph networking algorithms can't link these transactions together with high probability. if you wan't privacy use a mixing service... if you can't then there is very little privacy for your transaction.

* **address reuse is not secure**

Bad implementation does not equal bad security protocol. Just because [a few wallets used to implement cryptographic algorithms incorrectly](https://stackoverflow.com/questions/17008967/securerandom-self-seeding#comment97198180_17011591) doesn't mean I should forever believe that the same cryptographic protocol is insecure for wallets that are correctly designed.

* **addresses are intended for one-time use**

really? then why are donation addresses valid for years???

**Tags:** address-reuse


---

## 1 answers

### Answer by username_1 on 2019-03-19. Score: 5

I think it would be helpful for you to identify your service here, so that I can encourage people to not do business with you.

Users generally have no idea if this will work safely or not, so a notice will not be sufficient. If you send users funds to addresses they did not supply you should be prepared to pay them out when they report the funds have gone missing or find yourself on the losing side of a lawsuit-- and there would be no shortages of experts willing to testify on behalf of someone you failed to pay due to this.

> Yet each incoming transaction has its own list of incoming transactions with its own outputs sent to various "destination addresses", therefore the notion of their being no "from address" is not valid.

Sorry, that simply is not correct.

Coins have a history from which you could derive prior "To" addresses, that much is correct. But a prior "To" is not a "from". For example, if you ordered a produce from amazon, received it, then inspect the parcel with a magic wand that told you the last place the parcel was shipped you might find it was last sent to a reshipment center in Oregon. But that is just some shipper, not the source (amazon) and if you attempted to "return" the package by simply shipping it there it would likely end up lost.

Your order "from" amazon may have gone through dozens of steps or indirection before reaching you, and the last hop may have only the thinnest of relationships to the actual origin.

Even if the "from" is correct the user may simply no longer have access to the keys. With no more use for them they simply may have discarded them (e.g. a 'paper wallet' or other token). Users can setup persistent donation addresses intentionally taking due care to preserve the key material, and for donations the security/privacy implications are reduced because of the very nature of the payments (the donation addresses are public and the funds aren't provided in exchange for any consideration). And when access isn't lost completely, the keys in question may not be readily accessible, but stored in a safe deposit box or time lock safe. The funds could have also been spliced out of a payment channel and the prior-to could be inaccessible to the user without significant software modification or the help of a third party.

> What privacy? Bitcoin doesn't provide any privacy...

Bitcoin does provide privacy and has since day one. It is specifically called out as a top level section in the Bitcoin whitepaper. The privacy Bitcoin provides isn't perfect for sure, but one of the biggest things that damages privacy is address reuse because it creates co-input linkage, causing otherwise completely independent spends to be obviously linked. Mixing "services" are frequently scams that steal user funds.

Your self-described "rant" seems to have also ignored the largest practical consideration: A great many wallets (perhaps the largest in total user count) are thoroughly incompatible with your intended behavior. If a user pays you from a hosted wallet and you "refund" to one of the apparent prior-to addresses, the funds will be delivered to some other random user (who will probably promptly withdraw their windfall, never to be heard from again).

> **Comments:**
> **username_0**: your amazon analogy is incorrect because the intermediate shipping facility has no claim of **exclusive** ownership over the shipment.  Exclusive ownership rights are first owned by amazon, and then the customer, from->to, a direct ownership transfer.  The bitcoin white paper states that `coins [are] made from digital signatures, which provides strong control of ownership` the digital signature provides the EXCLUSIVE ownership rights.  
> **username_0**: `a notice will not be sufficient`, I was not aware of this... are you saying that satoshidice.com is at risk of lawsuits from any customer who fails to understand their notice `IMPORTANT: Only use wallets that allow you to receive Bitcoin from the same address you sent from.` ???  
> **username_0**: `the user may simply no longer have access to the keys` which is the their wallets fault (I would be doing immediate refunds), therefore I ask the question "how many wallets fail to support address reuse?".  
> **username_0**: `the funds will be delivered to some other random user` which I reiterate probably violates the white papers statement that `digital signatures [provide] strong control of ownership` and so unexpectedly transferring ownership of a private-key in my opinion violates this principle.  
> **username_0**: Reviewing your answer and my comments, I have to ask... Why did you even post an answer?  Your answer does not even address the question... in fact it ignores the bulk of the question...  
> **username_0**: Since no one else answered I ended up offering the customer the ability to specify an automatic refund address, it was a waist of time, but without knowledge of how many clients are defective I had to resort to the worst possible implementation to pander to incompetent bitcoin wallet developers.  Thanks for nothing.  
> **username_0**: Since I no longer care about an answer, I will be deleting this question.  Again, thanks for nothing.  You wasted my time, congratulations!  

---

