Topic: [CLOSED] btcrelay.com (alpha): one address for a weighted list of recipients (Read 5144 times)
February 27, 2015, 03:13:19 PM
~2.5 btc ?
February 17, 2015, 07:36:41 PM
~5 btc? 
February 15, 2015, 07:19:12 AM
Thanks for your questions. It is running on LAMP + bitcoind.
This service was rarely used. You can see most of the paylists here: http://btcrelay.com/paylist . I haven't been developing neither promoting it for years. Not sure if anybody wants to buy it but I'd like to sell it for ~10 btc or to auction it if nobody makes a good enough offer.
This service was rarely used. You can see most of the paylists here: http://btcrelay.com/paylist . I haven't been developing neither promoting it for years. Not sure if anybody wants to buy it but I'd like to sell it for ~10 btc or to auction it if nobody makes a good enough offer.
February 15, 2015, 03:22:19 AM
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?
February 12, 2015, 08:49:44 PM
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?
March 16, 2012, 02:08:06 PM
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:
- https://bitcointalksearch.org/topic/--24784
March 16, 2012, 10:52:35 AM
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://bitcointalksearch.org/topic/m.803875
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.
March 15, 2012, 07:52:59 PM
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://bitcointalksearch.org/topic/m.803875
March 13, 2012, 08:19:01 PM
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?
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.
March 13, 2012, 06:30:07 PM
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?
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?
February 11, 2012, 04:25:13 PM
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)
January 27, 2012, 11:49:31 PM
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: 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, you can easily get amount of bitcoins deposited by each user in JSON format:
Send funds:
1. Create or generate CSV-file with 2 columns:, on your web-server
2. Feed URL of that script to btcrelay and send funds to the provided address
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=?&description=
(where 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
Quote
Send funds:
1. Create or generate CSV-file with 2 columns:
2. Feed URL of that script to btcrelay and send funds to the provided address
January 25, 2012, 05:30:25 AM
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
January 24, 2012, 09:51:47 AM
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.
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 :-).
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 :-).
January 23, 2012, 08:33:44 PM
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.
. 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.
January 23, 2012, 12:16:21 AM
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!
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.
[/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
. 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. January 22, 2012, 11:48:17 PM
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)
January 22, 2012, 08:19:07 PM
Any chance to *not* list paylists on the site and show paylist details only on some private URL?
January 22, 2012, 02:37:11 AM
- 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
January 22, 2012, 01:12:59 AM
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
Jump to: