[CLOSED] btcrelay.com (alpha): one address for a weighted list of recipients

[arsenische]

Hi again!

I just developed a new bitcoin-related service: http://btcrelay.com

It doesn't have unique design (sorry about it), but it solves the problem of automatic redistribution of payments to the supplied list or recipients.

The simplified algorithm is the following:

• You supply the list of recipients, the system generates permanent deposit address for it.
• When somebody sends bitcoins to that address, btcrelay redistributes them among correspondent recipients.

You can also supply a weighted list (in that case each recipient has integer weight and receives payments with respect to it).

There are 2 methods to supply your list:

• to enter the list of recipients in textarea (in that case it will be static).
• to supply the read-only URL which points to the list of recipients (in this case it can be changed or even generated upon request).

I use the latter method to enable payments for clicks and impressions at Anonymous Ads.

I hope it could be useful to you too. For example, you could use it on your sites like this:

Code:

<a target='_blank' href='http://btcrelay.com/paylist?url=<url of your paylist>&description=<optional description>'>Pay to my weighted list of recipients</a>

(if paylist with that URL doesn't yet exist, it will be created after the captcha is entered; if paylist exists, its deposit address will be shown; when bitcoins arrive to that address and hit the threshold, paylist data will be fetched from specified url and money will be sent to the recipients).

Warning: both btcrelay.com and anonymousads.com are in alpha stage yet, so there is some risk involved and I would be grateful for bug reports and feedback.

Update 2015-02-13: Since I don't have time to develop this service and didn't touch it for a while, I am searching for anybody who would like to buy it (or participate in its development in exchange for a share). Anyone interested?

Update 2015-11-20: Since nobody is using the service, I am closing it

[slush]

Nice, I'm going to test this service soon. I see this useful for miners. If they want to save x% of their mining profits and sell immediately 100-x% on the market, this is pretty nice way how to automate it without any additional scripting...

[slush]

arsenische, what happen when payment is received and downloading of CSV file failed (404, corrupted file format, whatever)? Do you cache previously downloaded CSV? Or will it queue processing and wait until CSV will be available again?

[arsenische]

arsenische, what happen when payment is received and downloading of CSV file failed (404, corrupted file format, whatever)? Do you cache previously downloaded CSV? Or will it queue processing and wait until CSV will be available again?

Upon each deposit the system downloads CSV and saves it to the brDeposit table (but mainly for debugging and reporting purposes). It doesn't use old cached version of CSV to avoid sending money to outdated list of recipients.

If new CSV can't be downloaded or parsed, the deposited money will be left unspent until new deposit (of any amount) happens. So user will need to send at least one satoshi to initiate new attempt.

It is implemented this way because I do not want the server to be busy fetching broken links and parsing broken documents all the time. Need to test it though

[Stephen Gornick]

• to supply the read-only URL which points to the list of recipients (in this case it can be changed or even generated upon request).

Awesome!  This gives the ability for me to give out a static address yet at any time change the redirect!

Though I wouldn't use an external hosting service for storing the CSV for any addresses that I suspect there might be more than a trivial amount of bitcoins ever sent, Pastebin can host this.  You need to use a registered account in order to edit a Paste previously created by that account but Pastebin will work:

e.g., the url containing the CSV paste: 
  http://pastebin.com/raw.php?i=xxxxxxxxxx

[slush]

Any chance to *not* list paylists on the site and show paylist details only on some private URL?

[arsenische]

Any chance to *not* list paylists on the site and show paylist details only on some private URL?

I think I can set up a hidden btcrelay version on the subdomain. Database backups and list of paylists won't show up on the hidden site. Paylists will be identified only by random id. Would it be good enough?

Update: Or maybe there is no sense in publishing database backups and list of paylists at all? (then no need in subdomain)

[slush]

I think I can set up a hidden btcrelay version on the subdomain. Database backups and list of paylists won't show up on the hidden site. Paylists will be identified only by random id. Would it be good enough?
[/qupte]

It would be great!

Or maybe there is no sense in publishing database backups and list of paylists at all?

Not sure what's the main use case of public paylists. Well, the most of the information can be found in the blockchain anyway, but I mostly care about public CSV's URL. Maybe hiding the CSV URL would be enough to make the service more private.

About backing up database: I think that the most ultimate solution is to provide private key of deposit address instead of database backup . In this way user can use your service as he wants, but if the service disappear, he'll still have an access to his funds. However I'm not sure if your implementation allows such feature.

[arsenische]

Well, the most of the information can be found in the blockchain anyway, but I mostly care about public CSV's URL. Maybe hiding the CSV URL would be enough to make the service more private.

It might be not that easy to deduce info from the blockchain since each bitcoin transaction potentially contains recipients from different paylists, and each paylists' withdrawal can be executed in several transactions.

Now you have an option to hide paylist upon creation. If this option is enabled, paylist won't appear in the list of paylists and it won't be listed on the withdrawals page (I converted couple existing paylists into the hidden ones).

Hidden paylist is still accessible by its numeric id, but the CSV url won't show up unless it is passed via GET or POST parameter. However if you already know url and pass it to the page, then it will be visible, and you'll also be able to see correspondent withdrawals.

About backing up database: I think that the most ultimate solution is to provide private key of deposit address instead of database backup . In this way user can use your service as he wants, but if the service disappear, he'll still have an access to his funds. However I'm not sure if your implementation allows such feature.

I think public database backups are good for transparency, but not required since transaction info is available from the withdrawals page. So I removed them.

I really like your idea about private key of deposit address, but my current implementation doesn't allow it. I use standard means of working with wallet and I don't have control over the secret keys. I don't even know about how transaction inputs are being selected

Btw, Slush, thank you very much for your precious feedback and ideas, I appreciate it.

[slush]

Excellent, hidden paylist and hidden URL is exactly what I wanted :-).

One more (and probably last) feature request: Send email when coins are deposited and/or withdrawn. In this way it will work as simple payment notification when user does not have running bitcoin client all the time. In the email there should be also the link to the playlist and link for cancellation of email notifications for this playlist.

but my current implementation doesn't allow it.

You're using standard bitcoin client, so you're unable to choose which inputs will be used in the transaction, so you cannot control balance of any particular address, right? I'm working on Stratum server (stratum.bitcoin.cz) which will allow easy development of applications with features like this, but it isn't ready at this moment. However I'll tell you when the platform will be ready enough, maybe you will be interested :-).

[arsenische]

Send email when coins are deposited and/or withdrawn. In this way it will work as simple payment notification when user does not have running bitcoin client all the time. In the email there should be also the link to the playlist and link for cancellation of email notifications for this playlist.

I've implemented it. If user specifies email address upon paylist creation, he/she will be notified when deposits are confirmed. If he/she unsubscribes, then email address will be irreversibly deleted from the database record associated with that paylist.

I'm working on Stratum server (stratum.bitcoin.cz) which will allow easy development of applications with features like this, but it isn't ready at this moment. However I'll tell you when the platform will be ready enough, maybe you will be interested :-).

Great, thanks! Sometimes it is quite frustrating not to have enough control over wallet and transactions

[arsenische]

New feature: paylist info in json format.

Yet another way to organize payment reception and withdrawals without having bitcoind and the list of pregenerated bitcoin addresses on your web server.

Receive funds:

1. Create a text file with your bitcoin address (or addresses) on your web-server
2. Add "Pay" button to your website, which should open in new browser window URL of the following form:

http://btcrelay.com/paylist?url=<url of that text file>?<some id>&description=<message for your user>

(where <some id> will be used to distinguish your users, don't forget to save it somewhere; you can also use  "&hide=1" to make the paylist hidden by default)

Thus your users will be able to generate a deposit address and to send funds to it.  Once payments are confirmed, you receive them to your bitcoin address (or addresses) specified at step 1.

Since you know <some id>, you can easily get amount of bitcoins deposited by each user in JSON format:

http://btcrelay.com/paylist?url=<url of that text file>?<some id>&json

Send funds:

1. Create or generate CSV-file with 2 columns: <withdrawal address>, <amount of satoshies to be sent> on your web-server
2. Feed URL of that script to btcrelay and send funds to the provided address

[arsenische]

New features:

• Min withdrawal - withdrawals won't be done if unspent amount is less than this value
• Max withdrawal & Withdrawal interval - schedule periodic withdrawals
• Callback Url - your script will be called when new bitcoins arrive
• API and php-example of organizing payment reception without bitcoind and pre-generated list of bitcoin addresses (btcrelay generates bitcoin addresses for you)

[Stephen Gornick]

Just to confirm, the "withdrawal" transaction has inputs that are not associated with the Deposit address used in the relay, correct?

i.e., there is no direct association between the funds sent to the relay Deposit address against the funds sent (withdrawn automatically) six confirmations later.  (other than the total being the same minus 0.0005 BTC per Paylist entry).

and in an example:
Alice creates a BTC Relay with two entries in the Paylist and then sends 1.0 BTC from her wallet to the relay's Deposit address.
The relay will, after six confirmations, pay out as a withdrawal 0.4995 to each of the Paylist entries but those funds will likely come from other addresses, such as prior transactions by Bill and Bob.

Additionally, that would mean that should the recipient of the withdraw happen to "return" the funds by sending an amount to one of the inputs of the withdraw, then those funds would go to some lucky person (Bill or Bob, using the example from above), and not likely to the person who funded the payment to the BTC relay Deposit address (Alice, using the example from above).

Correct?

[arsenische]

Just to confirm, the "withdrawal" transaction has inputs that are not associated with the Deposit address used in the relay, correct?

I believe it is correct, but sometimes it might be not. I have no control over this process, bitcoind chooses inputs for the transaction.

Additionally, that would mean that should the recipient of the withdraw happen to "return" the funds by sending an amount to one of the inputs of the withdraw, then those funds would go to some lucky person (Bill or Bob, using the example from above), and not likely to the person who funded the payment to the BTC relay Deposit address (Alice, using the example from above).

Correct?

Yes, I believe in most cases it is correct. But I can't guarantee it: bitcoind might choose some internal addresses as inputs for the transaction, in that case those money will probably remain in my wallet unnoticed by the system.

[Stephen Gornick]

Yes, I believe in most cases it is correct. But I can't guarantee it: bitcoind might choose some internal addresses as inputs for the transaction, in that case those money will probably remain in my wallet unnoticed by the system.

Hmm.  There is the need for a BTC Relay type of system except where the coins used for inputs in the relay needs to be tied to the funder's account.  Specifically, BitLotto tickets can only be purchased one at a time.  BTC Relay doesn't work for this for two reasons. 

1.) The way BitLotto works is that it will only use for the payout the return address (the bitcoin address used as an input on the winning ticket).   
and
2.) BTC Relay would combine multiple entries in the PayList into a single transaction.    BitLotto needs each ticket to have its own transaction hash as that is what is used to pick the winning entry.

BTC Relay is pretty close.  Would there be any interest in adding options (or offering a similar service) so that people who either use an e-wallet and those multi-ticket buyers could use this service?

There is a person willing to do a 100 BTC wager on BitLotto if there were such a service that solved this problem.
 - https://bitcointalk.org/index.php?topic=34007.msg803875#msg803875

[arsenische]

Yes, I believe in most cases it is correct. But I can't guarantee it: bitcoind might choose some internal addresses as inputs for the transaction, in that case those money will probably remain in my wallet unnoticed by the system.

Hmm.  There is the need for a BTC Relay type of system except where the coins used for inputs in the relay needs to be tied to the funder's account.  Specifically, BitLotto tickets can only be purchased one at a time.  BTC Relay doesn't work for this for two reasons.  

1.) The way BitLotto works is that it will only use for the payout the return address (the bitcoin address used as an input on the winning ticket).  
and
2.) BTC Relay would combine multiple entries in the PayList into a single transaction.    BitLotto needs each ticket to have its own transaction hash as that is what is used to pick the winning entry.

BTC Relay is pretty close.  Would there be any interest in adding options (or offering a similar service) so that people who either use an e-wallet and those multi-ticket buyers could use this service?

There is a person willing to do a 100 BTC wager on BitLotto if there were such a service that solved this problem.
 - https://bitcointalk.org/index.php?topic=34007.msg803875#msg803875

I like the idea, but I don't know an easy & reliable way to implement it. As I said, bitcoind doesn't give much control over bitcoin addresses. If there is some simple & reliable tool compatible with bitcoind that allows doing it, I would definitely consider implementing this feature.

[Stephen Gornick]

I like the idea, but I don't know an easy & reliable way to implement it. As I said, bitcoind doesn't give much control over bitcoin addresses. If there is some simple & reliable tool compatible with bitcoind that allows doing it, I would definitely consider implementing this feature.

There is a patch to bitcoin that allows full control over the bitcoin addresses chosen for use as inputs:
 - http://bitcointalk.org/index.php?topic=24784.msg804314#msg804314

[arsenische]

Since I don't have time to develop this service and didn't touch it for a while, I am searching for anybody who would like to buy it (or participate in its development in exchange for a share). Anyone interested?

[bitspill]

Since I don't have time to develop this service and didn't touch it for a while, I am searching for anybody who would like to buy it (or participate in its development in exchange for a share). Anyone interested?

What software stack (bitcoind, BC.I api, php, rails, etc.) is this running on, was it ever actually used, and roughly what price are you looking for?