Topic: valid assumption?: scriptSig can be used to return coins to sender? (Read 1243 times)

I'm sorry, but you're just coming off as rude and unhelpful. The first thing on the page not part of the template itself says, "This is an unclaimed Bitcoin address". It's even styled/colored differently than the "This Bitcoin address is published!" message. The API also reflects this information through the `status` field.

Anyhow, an email was dispatched to [email protected], explaining how to publish their own bitcoin address and receive any bitcoins held. If that were to happen, the page text would update to reflect that, in which case it would be AMAZING.



If I find a wallet on the ground, I'm going to mail it back to the address on the ID card. Maybe they moved, but I have no way of knowing that.

I load paythru.to.

I type [email protected]

The site returns "[email protected] can be sent bitcoins at 1NCbXKdyo9xhwN9EhLc6jKgtDSFQZ1MAUj"

And you're telling me this isn't an address that you control, but instead it's really a key controlled by the president? AMAZING.

And that if I send coins there, they'll actually be received by he president for sure, and not end up in a black hole or "refunded" to some random address of mine, where I'll never figure out it was a refund vs someone else donating to me? AMAZING.

... In any case, this was all on the OPs topic: You can try to infer out working addresses that way, but its unreliable. And at least several people believe that doing so smacks of the kind of irresponsible behavior that goes along with the moral hazard of handling third party money without enforcement or regulation stronger than reputation.

PAYTHRU don't want people's bitcoins, so you're absolutely right that you shouldn't trust the service.

But also, I think it's fairly clear that you don't have a grasp on what PAYTHRU actually attempts to do, so perhaps we can stick to OP's topic instead of making personal attacks.

I really wish more people would take this into consideration before using services like this.

Your service strips control away from users— by sending funds back to random addresses. When they have funds randomly show up how will they know where they came from?  Is it the prior person that they gave that address to— the only person in the world they gave that address to— paying them again (and so should they ship out some more product as a result?)  is it one of your payto's refunding? Should they want to send the funds another way, how do they know which payto was refunded?

As I have said several times here, shared wallet services are not the only case where your service will cause funds to be lost (though they're currently the most common one). It's hostile to good key management retiring old keys, and it's hostile to wallets anonymizing payments by making joint transactions. Worst of all, it makes the users private wallet management practices— which should be their own personal business— constrained by you.  It degrades coin fungibility because the user may have coins they can pay you with (ones that were sent to convenient addresses they can receive more payments with) and ones they can't.

You are already taking a twitter-to address, just take a refund address as part of the same URL. Whats the big deal?

Is your own service even compatible with its own practices?  What happens if a paythru user releases their funds to an exchange using the same practices as your site (fortunately none currently do) which does an emergency shutdown and refunds all coins using the same algorithm you use? I assume you'll just uselessly loop at that point.

The impression I'm getting here is that I wouldn't personally trust you with my money. You seem to be somewhat blasé about putting other peoples funds at risk.

It is in the FAQ:

A trap would be just keeping the money, like the shared wallet services do.

In any case, back to the question of returning to scriptSig... as you can see, some people hate it. Satoshi Dice made a fortune off of it.

This is extremely IRRESPONSIBLE. You don't even warn people for not to use a shared wallet in the FAQ. This is just a TRAP

There is no user-supplied data except the entity which you're trying to look up, so I'm not sure where you're seeing "prompting". An example via cURL:


Now, because that call results in the the address claimed by that Twitter account (status = 2), PAYTHRUto never touches the bitcoins--the entire transaction is handled by the wallet.

Because I have no way of knowing if a URI has a published Bitcoin address before a request is made, there's no sane way for me to conditionally collect a refund address beforehand. Perhaps I could collect a refund address as a parameter, i.e. `?refund=1ThisisARefundAddressSuppliedByTheUser`, but it's clunky and requires the user to tell me something extra even if they're not actually sending anything. So make it optional? Then we're right back to square 1.


Spending from addresses of private keys you don't own with a bunch of other people is a "best practice"? That's almost laughable since it suggests stripping control away from the user is a good thing.

You don't need an account at all.  You're already prompting for a destination email address before giving the user an address to pay to. Prompt for a return address at the same time, it's as trivial as that. This is the standard, widely adopted, best practice in industry right now.

A failure to do that makes your service available to fewer customers, risks customer confusion/dissatisfaction and funds loss (when not if), and reduces Bitcoin user's autonomy over their own wallet management practices.

It isn't just a matter of accepting, those funds may go to other people, they may go to keys that no longer exist. When the returned funds show up the recipient may have no idea which transaction they were being refunded for and may, as a result, double pay (or improperly credit someone else). There may not even be a service involved, but regardless shared wallet services have been a common feature of the Bitcoin ecosystem system 2010. They are common well supported and within best practices. What you are doing is not.

If you can describe a better way to provide refund ability in the current ecosystem without asking a user to register for any sort of account, I'll implement it.

I relied on scriptSig, because there doesn't appear to be a better solution available today.

Edit: If they're using a shared wallet service that doesn't accept funds from sending addresses, that's their service's fault, not mine.

Please don't be irresponsible. Do you plan on compensating people out of pocket for funds lost due to your practices?

No one was telling you to wait for anything.

It's possible, but people will tell you to wait for 0.9 features.

I'm not keen on waiting on other people when I can help myself, so I did it anyway to implement refunds on http://paythru.to

If the protocol landscape changes, I'll update my app in due time, but asking developers not to develop is ridiculous.

This is not a safe assumption. The previous places that coins were sent to may have nothing to do with the rightful recipient of returned coins, in common cases like shared wallets or in less common cases like various transaction privacy mechanisms. It's also incompatible with privacy preserving practices like using an address only once, and accounting practices (you may end up sending funds to some offline key of the senders or some key they've destroyed). Many wallets will also not recognize a pay to pubkey transaction as their own. The assumption that you can infer a working return address has observably caused people to lose funds in the past.

Fixing yourself on receiving only particular transaction types is also hostile to the ecosystem, since it denies people autonomy in how they manage their own wallets.  If you may need a refund, you should be collecting a refund address before you provide a pay to address.

The new payment protocol stuff handles that atomically.

Hi guys,

Trying to work out if I can use the pubKey part of scriptSig in an transaction VIN, to hash in order to generate a valid return address for the sender of the transaction, for plain pay to pub key transaction types?

Cheers, Paul.