Proposed solution for incorrectly entered BitCoin addresses

[Zerbie]

PROBLEM:  New user buys BitCoins and then starts spending them, but at one point does not copy and paste the full BitCoin address into the client, or copies the wrong BitCoin address into the client.  The result is that BitCoins are sent into the gutter, never to be retrieved.

SOLUTION: Wrap the send packet with the receiving BitCoin address, so only the receiving BitCoin client can un-encrypt  the packet and transmit the packet back out to the network.  Thus, the sender can be assured he is sending it to a real client.

EDIT: SECOND SOLUTION: Create client identifiers where a BitCoin receiver can "bill" a sender through the network or to a specific IP.

BONUS SOLUTION:

PROBLEM: A sender may wish to obscure where he is sending his packet from.  E.G. Someone sending a large sum to a Falun Gong website monitored by the Chinese government, wishes to hide the sending IP address.

SOLUTION: Similar to the Tor network, give each IP a public and private key.  Allow senders to multiply wrap their send packet with public keys and sending IP addresses.  The network can unwrap the packet as it is sent from IP to IP until it reaches it's destination.  (Add a random time delay and garbage packet buffer at each stop for more protection.)

[1713550254]

1713550254

[1713550254]

1713550254

[1713550254]

1713550254

[1713550254]

1713550254

[1713550254]

1713550254

[1713550254]

1713550254

[cbeast]

If you have your wallet backed up, you can just restore your backup wallet.dat. Since the last transaction is not verified, your bitcoins will not be spent.

[mikethebodacious]

I say if you don't know how to copy-paste correctly you deserve to lose your BTC 

[memvola]

SOLUTION: Wrap the send packet with the receiving BitCoin address, so only the receiving BitCoin client can un-encrypt  the packet and transmit the packet back out to the network.  Thus, the sender can be assured he is sending it to a real client.

If you don't require the receiver to be online, then this would add a level of complexity to the Bitcoin system. The transaction needs to persist somehow until the receiver gets online.

(EDIT: You probably want to define a TTL in any case. The coins need to be blocked for the duration of TTL, otherwise the wrapped packet will be invalid.)

If you have your wallet backed up, you can just restore your backup wallet.dat. Since the last transaction is not verified, your bitcoins will not be spent.

If you enter a broken address, there is a good chance that the transaction will not happen in the first place (because of the checksum). I think he's talking about cases where a transaction goes out, in which case it will surely get confirmed.

[Zerbie]

If you don't require the receiver to be online, then this would add a level of complexity to the Bitcoin system. The transaction needs to persist somehow until the receiver gets online.

Yes, that would be a requirement.  If the receiver is not online, then eventually, the sent packet simply falls off the network.

EDIT: Come to think of it, make the packet expire after say 10-30 minutes so the sender can safely assume the packet was not received.

[kjj]

PROBLEM:  New user buys BitCoins and then starts spending them, but at one point does not copy and paste the full BitCoin address into the client, or copies the wrong BitCoin address into the client.  The result is that BitCoins are sent into the gutter, never to be retrieved.

SOLUTION: Wrap the send packet with the receiving BitCoin address, so only the receiving BitCoin client can un-encrypt  the packet and transmit the packet back out to the network.  Thus, the sender can be assured he is sending it to a real client.

If you don't paste the full address, the checksum will stop it.  If you do paste a full address, but it isn't the address you intended to send to, won't the (wrong) receiver just decrypt the packet?

[Pieter Wuille]

The solution is an out of band protocol to negotiate the transaction, instead of trying to pack everything into a static string (address, URI, ...).

[memvola]

The solution is an out of band protocol to negotiate the transaction, instead of trying to pack everything into a static string (address, URI, ...).

I was thinking, we are able to put Bitcoin addresses in Namecoin and can refer to those addresses using names. So when I want to send money to Dummy, I just enter dummy to the wallet interface. Maybe even check if it's the right person/entity by inspecting other details of dummy through the confirmation window.

What can't be done this way is dynamic receiving addresses. But we can get a secure^* URI from Namecoin for an online tool to convert a certain code to an address and additional information (invoice, etc.). So, what I need from the shop is the shop's name and some kind of payment code (customer name, checkout number, etc.). This can also be delivered using the standard Bitcoin URI scheme. After the user enters the details (E.g. I'm sending money to my account on MtGox: mtgox, memvola), he inspects the response and then confirms the payment.

(*) We can get a certificate from Namecoin for secure http transfers. The URI can also identify a Tor or I2P resource, but the protocol would still be http/https.

EDIT: To support my idea, the advantages if this gets wide acceptance are:

• Almost impossible to make a wrong payment, you can get the sum you need to pay as a response from the shop's URI.
• For the example of MtGox, I don't even need to log in and get an address to send money.
• Perfectly decentralised, does not depend on third party services.
• No fear of man in the middle attacks and dependence on external certificate authorities.
• Easy to implement, though payment systems would need to run Namecoin alongside Bitcoin. This includes home users who want to be extra secure as well...
• You get a Namecoin installation as a bonus, now you can browse the web freely, and other things...

[Tulkas]

Why not just add a CRC at the end of the address?

[casascius]

There are already 32 bits of error detecting redundancy in every Bitcoin address, so the odds of a typo Bitcoin address being accepted as valid are 4 billion to one.  This is not a problem and never was.

In fact, that's almost overkill for error detection bits (not that I'm complaining).  It's enough that a program could actually correct one or two typos in an address all by itself with a very high degree of accuracy if it tried.

PROBLEM: A sender may wish to obscure where he is sending his packet from.  E.G. Someone sending a large sum to a Falun Gong website monitored by the Chinese government, wishes to hide the sending IP address.

This isn't a problem either, because a transaction can be sent to any peer and be relayed to all other peers.  Each node will only know the IP address of the peer that sent him the transaction, and won't have any way to distinguish a peer relaying it from the node that originated it.  Tor can be used, but is highly unnecessary.

[cbeast]

If you have your wallet backed up, you can just restore your backup wallet.dat. Since the last transaction is not verified, your bitcoins will not be spent.

If you enter a broken address, there is a good chance that the transaction will not happen in the first place (because of the checksum). I think he's talking about cases where a transaction goes out, in which case it will surely get confirmed.

I actually did send bitcoins (with no fee) to another wallet on a smartphone, but while the trasaction cleared the bitcoins from my pc wallet, it did not appear on my smartphone even after several minutes. I then recovered a backup and sent the same bitcoins to another address (MtGox) this time with a fee and they did move to MtGox. I suppose I double-spent them, but it worked.

[casascius]

I actually did send bitcoins (with no fee) to another wallet on a smartphone, but while the trasaction cleared the bitcoins from my pc wallet, it did not appear on my smartphone even after several minutes. I then recovered a backup and sent the same bitcoins to another address (MtGox) this time with a fee and they did move to MtGox. I suppose I double-spent them, but it worked.

This very likely means the network never heard about the first transaction.

If it did, the network would have coughed up the old transaction and cancelled the new. The network definitely would not have accepted the double spend.

[cbeast]

I actually did send bitcoins (with no fee) to another wallet on a smartphone, but while the trasaction cleared the bitcoins from my pc wallet, it did not appear on my smartphone even after several minutes. I then recovered a backup and sent the same bitcoins to another address (MtGox) this time with a fee and they did move to MtGox. I suppose I double-spent them, but it worked.

This very likely means the network never heard about the first transaction.

If it did, the network would have coughed up the old transaction and cancelled the new. The network definitely would not have accepted the double spend.

If the network did not hear of the first transaction, then that is a problem. The transaction did clear my wallet. I suspect there may be issues with non-fee vs fee transactions with the state of the network, but the smartphone client may have been a factor. This was a one time occurrence.

[JoelKatz]

I actually did send bitcoins (with no fee) to another wallet on a smartphone, but while the trasaction cleared the bitcoins from my pc wallet, it did not appear on my smartphone even after several minutes. I then recovered a backup and sent the same bitcoins to another address (MtGox) this time with a fee and they did move to MtGox. I suppose I double-spent them, but it worked.

Your client only sent the transaction to one other client, to better hide the origin point of the transaction. That client refused to relay the transaction because you didn't include a fee. So that transaction never got anywhere. Had you left the client running, it would likely have eventually sent the transaction to a node willing to relay it.

Once a transaction gets out broadly, the network will not accept a conflicting transaction. You'd need a conspiring miner to get the conflicting transaction into a block.

[cbeast]

I actually did send bitcoins (with no fee) to another wallet on a smartphone, but while the trasaction cleared the bitcoins from my pc wallet, it did not appear on my smartphone even after several minutes. I then recovered a backup and sent the same bitcoins to another address (MtGox) this time with a fee and they did move to MtGox. I suppose I double-spent them, but it worked.

Your client only sent the transaction to one other client, to better hide the origin point of the transaction. That client refused to relay the transaction because you didn't include a fee. So that transaction never got anywhere. Had you left the client running, it would likely have eventually sent the transaction to a node willing to relay it.

Once a transaction gets out broadly, the network will not accept a conflicting transaction. You'd need a conspiring miner to get the conflicting transaction into a block.

OK, so had I left the client running, it would have completed the transaction eventually and then would show up on my smartphone? Still, it concerned me that the bitcoin amount was debited from my client, but not immediately credited on my smartphone client.

[casascius]

OK, so had I left the client running, it would have completed the transaction eventually and then would show up on my smartphone? Still, it concerned me that the bitcoin amount was debited from my client, but not immediately credited on my smartphone client.

The "debit" was only in appearance: the client knows that a pending transaction is dependent on those funds and reserves them for good reason.  The client will keep pushing the transaction.  The funds aren't "gone" by any means, they are still technically on your side and the client is just denying you access to them... but this is by design.  It would be unreasonable for the client to make it seem like you are able to respend funds you have already spent and which you presumably intend for them to go to the person you paid.

This may be more significant: the client only tries to resend once about every half hour (it randomizes the interval) with no way to force it to retry manually.  Since I have been working with the code for the upcoming release, I believe that feature has been added.