Idea: Reject payment system

[sebastian]

Got a new idea, that would actually build on the current bitcoin network, but still allow users to reject payments. (Not forcefully, but informative).

Simple put: A person who want to send payment, to a adress, simply first, broadcasts a message with amount and adress, asking if receiver want to accept this payment
When receiver see it, it will simply say yes or no to that payment, signed with receiver's private key.
If receiver says yes, then bitcoin client will send the payment, if receiver says no, a message in bitcoin client (or if its a casino or similiar - the server side client will forward this to the end user) that tells that the receiver won't accept bitcoins for this adress.

The bitcoin client will simply respect this.
If no one replies to the message in 1 hour, the message will become stale and not relayed.
Reply to the message will also stay in the network for max 1 hour.

This will NOT prevent anyone from "forcing Money into someones wallet" by simply not asking politely.
Anyone can still send payments into a wallet without asking.

Rather, its more a informative decision, to prevent anyone from accidentially sending in bitcoins in "spent" one-time use bitcoin adresses (for example tied with a already-paid order), or have bitcoin casinos avoid sending Money into sender adresses from web wallets (that wont "accept" incoming Money and such Money will be lost) - because if both casino and webwallet follows this standard, then casino will ask the sender adress if they are willing to take a payment, web wallet says no because they can't tie the Money to a user, and casino then displays on the web page: "Hey, we are unable to send you your payout to the adress which sent in the bet, please specify a bitcoin adress that can receive Money: "

In other Words, such a change can be implemented like the "reject" messages update, where old clients will not ask and ignore other client's messages, and new clients will ask and reply to other client's messages.

Servers that accept payments will simply implement the receiver checking on their own, tying it with order system or similiar.
GUI end user clients can implement this receiver checking by having a checkbox next to a user's own adress telling "Accept payments into this adress", where checked = the client will sign "yes" to anyone asking about that adress, and unchecked = the client will sign "no" to anyone asking about that adress.

[1714596270]

1714596270

[1714596270]

1714596270

[1714596270]

1714596270

[1714596270]

1714596270

[1714596270]

1714596270

[capsqrl]

It feels like this addresses a use case that's already addressed by the Payment protocol, don't you think?

[sebastian]

Yes, as long as receiver is actively using the payment protocol.
The problem is that the receiver can't know if the sender is supporting it, so the receiver has to supply both methods.

Take a example: Many bitcoin casinos send back the coins to the sender. If the player bets using a web wallet with one single sending adress for all of its users, the player's win will go lost if he win since the web wallet will receive "unknown" Money.

Im talking about a scheme that will be built into the core of the bitcoin (as a extension of the protocol) so updated bitcoind's will automatically avoid to send payments to adresses that are declared being unable to receive payment.
So for example that bitcoin casino, then their bitcoind will ask sender adress, and if sender is using latest bitcoind, then webwallet will respond with "no", and then the bitcoind will not send Money there.

[andytoshi]

Sebastian, the problem is that those casinos misunderstand the structure of transactions and believe in "from addresses". No amount of patching will correct the moral failing here, which is that they are doing payment processing without understanding the network or protocol they are using to do it. I have a document which discusses "from addresses" and surrounding misunderstandings.

To make transactions which require a recipient's signature would require a soft-fork (to introduce the new transaction type), and would add an extra signature verification to the process of validating transactions. Since transaction validation is done by unpaid nodes, you would need a strong usecase (and this is not one, unfortunately) to justify the added load on them, since Bitcoin's centralization depends on these nodes operating freely and diversely.

Edit: Here is a similar idea: suppose that instead of signing every output, you sign only your change output as well as a recipient's key. Then the recipient sees the transaction and chooses her own outputs, which she signs, and the transaction is invalid (i.e. not minable) until she does so. This gets the recipient cooperation that you want, but also allows the recipient to choose her own outputs (for merge avoidance) and also choose her own fee (because presumably she cares more than the sender that the transaction actually gets confirmed).

This is still a forking change of course, but it gives you some extra usecases so I figured I'd mention it.