Bitcoin Forum
December 09, 2016, 11:45:25 PM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: [1] 2 »  All
  Print  
Author Topic: [CLOSED] btcrelay.com (alpha): one address for a weighted list of recipients  (Read 4736 times)
arsenische
Legendary
*
Offline Offline

Activity: 1116


View Profile
January 21, 2012, 10:23:51 PM
 #1

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

Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
slush
Legendary
*
Offline Offline

Activity: 1358



View Profile WWW
January 21, 2012, 11:44:22 PM
 #2

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
Legendary
*
Offline Offline

Activity: 1358



View Profile WWW
January 22, 2012, 03:46:24 AM
 #3

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
Legendary
*
Offline Offline

Activity: 1116


View Profile
January 22, 2012, 05:12:59 AM
 #4

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 Smiley

Stephen Gornick
Legendary
*
Offline Offline

Activity: 2002



View Profile
January 22, 2012, 06:37:11 AM
 #5

  • 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
Legendary
*
Offline Offline

Activity: 1358



View Profile WWW
January 23, 2012, 12:19:07 AM
 #6

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

arsenische
Legendary
*
Offline Offline

Activity: 1116


View Profile
January 23, 2012, 03:48:17 AM
 #7

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
Legendary
*
Offline Offline

Activity: 1358



View Profile WWW
January 23, 2012, 04:16:21 AM
 #8

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!

Quote
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 Smiley. 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
Legendary
*
Offline Offline

Activity: 1116


View Profile
January 24, 2012, 12:33:44 AM
 #9

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 Smiley. 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 Smiley

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

slush
Legendary
*
Offline Offline

Activity: 1358



View Profile WWW
January 24, 2012, 01:51:47 PM
 #10

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.

Quote
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
Legendary
*
Offline Offline

Activity: 1116


View Profile
January 25, 2012, 09:30:25 AM
 #11

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.

Quote
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 Smiley

arsenische
Legendary
*
Offline Offline

Activity: 1116


View Profile
January 28, 2012, 03:49:31 AM
 #12

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:
Quote
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:
Quote
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
Legendary
*
Offline Offline

Activity: 1116


View Profile
February 11, 2012, 08:25:13 PM
 #13

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
Legendary
*
Offline Offline

Activity: 2002



View Profile
March 13, 2012, 10:30:07 PM
 #14

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
Legendary
*
Offline Offline

Activity: 1116


View Profile
March 14, 2012, 12:19:01 AM
 #15

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.

Quote
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
Legendary
*
Offline Offline

Activity: 2002



View Profile
March 15, 2012, 11:52:59 PM
 #16

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
Legendary
*
Offline Offline

Activity: 1116


View Profile
March 16, 2012, 02:52:35 PM
 #17

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
Legendary
*
Offline Offline

Activity: 2002



View Profile
March 16, 2012, 06:08:06 PM
 #18

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
Legendary
*
Offline Offline

Activity: 1116


View Profile
February 13, 2015, 12:49:44 AM
 #19

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
Legendary
*
Offline Offline

Activity: 1176



View Profile
February 15, 2015, 07:22:19 AM
 #20

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?

Pages: [1] 2 »  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!