Set up a self-hosted wallet which will immediately forward to other wallets

[wannesd]

Hi,

me and my friends have a shared mining account at an undisclosed cloud mining site (undisclosed as it's not relevant to the question).

I would like for all profits to be sent to a wallet hosted on my server, which would then automatically and immediately split the profits into predetermined percentages, and send them to the addresses they should go.

Basically I'm trying to recreate exactly what coinsplit.io does, but on my own server.

The reason I'm hesitant to continue to use coinsplit.io (yes, I'm using it right now), is because of the fact that I believe the security for the site is not what it should be, and anyone who gains access to my account can change the forwarding address for all my schemes.

I was hoping there is some sort of wallet I can run on my server (OS doesn't matter, it's a hypervisor) which would allow me to do just that.

Anyone have an insight?

[cr1776]

You might try the local version of their site:

https://github.com/limpbrains/coinsplit-local

[wannesd]

You might try the local version of their site:

https://github.com/limpbrains/coinsplit-local

That seems like it will do the job, because, as I said, coinsplit does exactly what I need. I just don't want to trust them or their security.

However, that github link offers no documentation at all... Do you know of a place where I can find more information?

[cr1776]

Hi,
I don't know where there is any documentation for it, perhaps someone else has an idea.  :-)

[Cryptowatch.com]

This is an interesting project.

From what I understand, you require the following:

- The ability to receive bitcoins to a certain address.
- Once the bitcoins are received and confirmed, they
  should be split into predetermined percentages and
  then distributed to the involved parties.

Further, I understand you have:

- Access to a host where you could run a server of your chosing.
- The desire to run it on your own hosted setup.

Since you are security conscious, this might be relevant. (TL;DR: is "Don't use virtual servers where you share the same metal with other customers.")

In that regard, using exclusive hw (dedicated server in a data-center), or your own hw at your own physical location might be the best. However, the practical danger of such an attack being successful, I assume is very low, so it might be an acceptable risk.

Anyhow, on a more technical level, this is how the issues could be solved:

- A server running a linux OS with at least bitcoin core running, using mysql would be a good addition.
- Incoming bitcoin transactions are detected, and relevant info is written to a database. (walletnotify and blocknotify events are used)
- Once the transaction is confirmed, it's ready to be paid out to the parties involved, this could be done with a cronjob or a daemon process.
- The configuration could be done manually over ssh on the server in text-files, or in a database, or an admin-interface could've been made to facilitate this to avoid having to deal with the config-files directly.

A plain text config file could look something like this:

[SPLITPAY]
RECEIVEADDRESS = 16Do2HCJXDDoSQnjkqB7Kh2MkPsjnCugf5

USER1 = joe@joefactory.com
PAYADR_USER1 = 1AFZZqP3zHYuuc7ULvd7uy15RziFNYRdgu
SHARE_USER1 = 40

USER2 = jack@joefactory.com
PAYADR_USER2 = 1BFZZqP3zHYuuc7ULvd7uy15RziFNYRdgu
SHARE_USER2 = 40

USER3 = knut@gmx.com
PAYADR_USER3 = 1CFZZqP3zHYuuc7ULvd7uy15RziFNYRdgu
SHARE_USER3 = 20

Once coins are received at 16Do2HCJXDDoSQnjkqB7Kh2MkPsjnCugf5, the amount will be split into the shares, 40,40,20 respectively. Addresses for users 1,2 and 3 would receive their coins once incoming transactions to RECEIVEADDRESS is confirmed (usually 1 confirmation is required in bitcoin core, before funds could be forwarded)

The users would probably be interested in some easy access to stats about the transactions, so a webpage displaying said stats could be a good idea - this would be locked down to only be displayable to the relevant parties. It would also be possible to have simple settings pages for each user, and an administrative interface.

Once a solution like this is up and running, the maintenance is very low. Security upgrades for the OS, and the occasional update of the bitcoin core software could be a good idea.

The benefit of running it on a system you control yourself is increased security, as the risk of the operator running the 3rd party service you depend on, or hackers attacking that service and gaining access will now be eliminated. If you run a hardened system, the chance of any security breach is rather low. It would be possible to for example only connect to one or a few trusted nodes, to minimize the networks knowledge of your node. If you also opted to close down all irrelevant services and close all irrelevant ports, it would not be easy to pinpoint your running system for a random attacker and it would also be very hard to compromise it. Ssh-access could further be limited to admins with the correct ssh-keys.

I'm working with stuff like this every day, so in the event you'd like me to help out, get in touch and we'd discuss the issues further. It should not take long to get a working version of this deployed. Naturally a working demo using bitcoin testnet would be provided as soon as possible to demonstrate that the functionality actually works as promised, also written elaborate instructions as to how to use the system would be possible to provide. Since security is an issue, I propose that source code be provided with good documentation, so the code could be reviewed by cr1776 or any other interested party and even compiled directly on the relevant server. Hence, there would be no need to put any unreasonable trust in a 3rd party, not even in a developer like me. As this is not very sophisticated software, with good documentation, even a non-coder should be able to understand it and check the validity of the system. In addition, bitcoin core used should be verified against downloaded sha256-signatures signed by core dev. This cr1776 could do himself to verify the process is accurate and legit.

Usage could be as simple as this:

1. Edit the config file as shown earlier in this post.
2. Start daemon and read default config file:
./paydist start
3. Show daemon status:
(This could show for instance the active config loaded, and other stats - running time and/or other stats for example)
./paydist status
4. Shut down daemon
./paydist stop

By saving relevant data to a database table or logfile it would be easy later on to use that data to provide various stats and reports if so desired.
./paydist stop

Note: Since running a webserver on the same server as a bitcoin core daemon could be a security risk, it would be fully possible to only provide admin access over ssh, and then provide the stats-pages on a separate web-server that gets info directly from the blockchain.

I would also be available in the future, if additions to the system would be requested.

[jonnybravo0311]

OP wouldn't really need the blocknotify event... just the walletnotify.  That event happens twice - first time is when the transaction hits your wallet.  Second happens when the transaction appears in a block (i.e. it's got the first confirmation and becomes spendable coin).

Also, keep in mind that you want to ensure your script is pretty simplistic as each wallet notify event spawns it's own process.  Of course if you're only getting (or expecting) a few transactions a day, that's not a big deal.

Anyway, just some food for thought...

[Cryptowatch.com]

OP wouldn't really need the blocknotify event... just the walletnotify.  That event happens twice - first time is when the transaction hits your wallet.  Second happens when the transaction appears in a block (i.e. it's got the first confirmation and becomes spendable coin).

Well spotted.

Also, keep in mind that you want to ensure your script is pretty simplistic as each wallet notify event spawns it's own process.  Of course if you're only getting (or expecting) a few transactions a day, that's not a big deal.

I would reckon mining proceeds are not paid that frequently, so efficiency in regards to handling the transactions is not of paramount importance, as the difference would be of an academic nature.

[jonnybravo0311]

OP wouldn't really need the blocknotify event... just the walletnotify.  That event happens twice - first time is when the transaction hits your wallet.  Second happens when the transaction appears in a block (i.e. it's got the first confirmation and becomes spendable coin).

Well spotted.

Also, keep in mind that you want to ensure your script is pretty simplistic as each wallet notify event spawns it's own process.  Of course if you're only getting (or expecting) a few transactions a day, that's not a big deal.

I would reckon mining proceeds are not paid that frequently, so efficiency in regards to handling the transactions is not of paramount importance, as the difference would be of an academic nature.

I agree, but just wanted to point out that if he's got a boatload of transactions hitting his wallet, each time wallet notify fires off it spawns its own process.  As you stated, pretty much an academic point if all he's got coming in are mining proceeds.

[wannesd]

This is an interesting project.

From what I understand, you require the following:

- The ability to receive bitcoins to a certain address.
- Once the bitcoins are received and confirmed, they
  should be split into predetermined percentages and
  then distributed to the involved parties.

That is entirely correct, perhaps the added option of fixed values too?
For example: send 1 btc/day to address A, if that quota is filled, send the rest to address B.
But mostly percentages, yes.

Further, I understand you have:

- Access to a host where you could run a server of your chosing.
- The desire to run it on your own hosted setup.

Since you are security conscious, this might be relevant. (TL;DR: is "Don't use virtual servers where you share the same metal with other customers.")

In that regard, using exclusive hw (dedicated server in a data-center), or your own hw at your own physical location might be the best. However, the practical danger of such an attack being successful, I assume is very low, so it might be an acceptable risk.

I have a bare metal hypervisor running here at home, which hosts a couple of vm's: my firewall, windows server 2012, NVR, and a xbmc VM with vga passthrough.
Adding another VM is no problem at all, is Lubuntu good enough?

Anyhow, on a more technical level, this is how the issues could be solved:

- A server running a linux OS with at least bitcoin core running, using mysql would be a good addition.
- Incoming bitcoin transactions are detected, and relevant info is written to a database. (walletnotify and blocknotify events are used)
- Once the transaction is confirmed, it's ready to be paid out to the parties involved, this could be done with a cronjob or a daemon process.
- The configuration could be done manually over ssh on the server in text-files, or in a database, or an admin-interface could've been made to facilitate this to avoid having to deal with the config-files directly.

A plain text config file could look something like this:

[SPLITPAY]
RECEIVEADDRESS = 16Do2HCJXDDoSQnjkqB7Kh2MkPsjnCugf5

USER1 = joe@joefactory.com
PAYADR_USER1 = 1AFZZqP3zHYuuc7ULvd7uy15RziFNYRdgu
SHARE_USER1 = 40

USER2 = jack@joefactory.com
PAYADR_USER2 = 1BFZZqP3zHYuuc7ULvd7uy15RziFNYRdgu
SHARE_USER2 = 40

USER3 = knut@gmx.com
PAYADR_USER3 = 1CFZZqP3zHYuuc7ULvd7uy15RziFNYRdgu
SHARE_USER3 = 20

Once coins are received at 16Do2HCJXDDoSQnjkqB7Kh2MkPsjnCugf5, the amount will be split into the shares, 40,40,20 respectively. Addresses for users 1,2 and 3 would receive their coins once incoming transactions to RECEIVEADDRESS is confirmed (usually 1 confirmation is required in bitcoin core, before funds could be forwarded)

Looks perfect to me!

The users would probably be interested in some easy access to stats about the transactions, so a webpage displaying said stats could be a good idea - this would be locked down to only be displayable to the relevant parties. It would also be possible to have simple settings pages for each user, and an administrative interface.

Not really necessary, a simple mail to the involved parties would be more than enough, stating how many btc was transferred.

Once a solution like this is up and running, the maintenance is very low. Security upgrades for the OS, and the occasional update of the bitcoin core software could be a good idea.

The benefit of running it on a system you control yourself is increased security, as the risk of the operator running the 3rd party service you depend on, or hackers attacking that service and gaining access will now be eliminated. If you run a hardened system, the chance of any security breach is rather low. It would be possible to for example only connect to one or a few trusted nodes, to minimize the networks knowledge of your node. If you also opted to close down all irrelevant services and close all irrelevant ports, it would not be easy to pinpoint your running system for a random attacker and it would also be very hard to compromise it. Ssh-access could further be limited to admins with the correct ssh-keys.

I'm working with stuff like this every day, so in the event you'd like me to help out, get in touch and we'd discuss the issues further. It should not take long to get a working version of this deployed. Naturally a working demo using bitcoin testnet would be provided as soon as possible to demonstrate that the functionality actually works as promised, also written elaborate instructions as to how to use the system would be possible to provide. Since security is an issue, I propose that source code be provided with good documentation, so the code could be reviewed by cr1776 or any other interested party and even compiled directly on the relevant server. Hence, there would be no need to put any unreasonable trust in a 3rd party, not even in a developer like me. As this is not very sophisticated software, with good documentation, even a non-coder should be able to understand it and check the validity of the system. In addition, bitcoin core used should be verified against downloaded sha256-signatures signed by core dev. This cr1776 could do himself to verify the process is accurate and legit.

Usage could be as simple as this:

1. Edit the config file as shown earlier in this post.
2. Start daemon and read default config file:
./paydist start
3. Show daemon status:
(This could show for instance the active config loaded, and other stats - running time and/or other stats for example)
./paydist status
4. Shut down daemon
./paydist stop

By saving relevant data to a database table or logfile it would be easy later on to use that data to provide various stats and reports if so desired.
./paydist stop

Note: Since running a webserver on the same server as a bitcoin core daemon could be a security risk, it would be fully possible to only provide admin access over ssh, and then provide the stats-pages on a separate web-server that gets info directly from the blockchain.

I would also be available in the future, if additions to the system would be requested.

It all sounds exactly the way I would like it, thanks for your help and time!
Just to clarify: is there the possibility to filter by receiving address?
Let's say receiving address A forwards to C and D, and receiving address B forwards to E, F and G, ... and so forth.

edit:
I installed Lubuntu 14.04 in a new VM, and bitcoin-qt is synchronizing with the network as we speak.

[wannesd]

OP wouldn't really need the blocknotify event... just the walletnotify.  That event happens twice - first time is when the transaction hits your wallet.  Second happens when the transaction appears in a block (i.e. it's got the first confirmation and becomes spendable coin).

Well spotted.

Also, keep in mind that you want to ensure your script is pretty simplistic as each wallet notify event spawns it's own process.  Of course if you're only getting (or expecting) a few transactions a day, that's not a big deal.

I would reckon mining proceeds are not paid that frequently, so efficiency in regards to handling the transactions is not of paramount importance, as the difference would be of an academic nature.

Payouts are initiated from a script I run on my server, and happen every 12 hours, to 3 different addresses, which should all be split.

[Cryptowatch.com]

This is an interesting project.

From what I understand, you require the following:

- The ability to receive bitcoins to a certain address.
- Once the bitcoins are received and confirmed, they
  should be split into predetermined percentages and
  then distributed to the involved parties.

That is entirely correct, perhaps the added option of fixed values too?
For example: send 1 btc/day to address A, if that quota is filled, send the rest to address B.
But mostly percentages, yes.

Such an added option of fixed values too, is indeed possible to make.

Further, I understand you have:

- Access to a host where you could run a server of your chosing.
- The desire to run it on your own hosted setup.

Since you are security conscious, this might be relevant. (TL;DR: is "Don't use virtual servers where you share the same metal with other customers.")

In that regard, using exclusive hw (dedicated server in a data-center), or your own hw at your own physical location might be the best. However, the practical danger of such an attack being successful, I assume is very low, so it might be an acceptable risk.

I have a bare metal hypervisor running here at home, which hosts a couple of vm's: my firewall, windows server 2012, NVR, and a xbmc VM with vga passthrough.
Adding another VM is no problem at all, is Lubuntu good enough?

Lubuntu would absolutely cut it.

Anyhow, on a more technical level, this is how the issues could be solved:

- A server running a linux OS with at least bitcoin core running, using mysql would be a good addition.
- Incoming bitcoin transactions are detected, and relevant info is written to a database. (walletnotify and blocknotify events are used)
- Once the transaction is confirmed, it's ready to be paid out to the parties involved, this could be done with a cronjob or a daemon process.
- The configuration could be done manually over ssh on the server in text-files, or in a database, or an admin-interface could've been made to facilitate this to avoid having to deal with the config-files directly.

A plain text config file could look something like this:

[SPLITPAY]
RECEIVEADDRESS = 16Do2HCJXDDoSQnjkqB7Kh2MkPsjnCugf5

USER1 = joe@joefactory.com
PAYADR_USER1 = 1AFZZqP3zHYuuc7ULvd7uy15RziFNYRdgu
SHARE_USER1 = 40

USER2 = jack@joefactory.com
PAYADR_USER2 = 1BFZZqP3zHYuuc7ULvd7uy15RziFNYRdgu
SHARE_USER2 = 40

USER3 = knut@gmx.com
PAYADR_USER3 = 1CFZZqP3zHYuuc7ULvd7uy15RziFNYRdgu
SHARE_USER3 = 20

Once coins are received at 16Do2HCJXDDoSQnjkqB7Kh2MkPsjnCugf5, the amount will be split into the shares, 40,40,20 respectively. Addresses for users 1,2 and 3 would receive their coins once incoming transactions to RECEIVEADDRESS is confirmed (usually 1 confirmation is required in bitcoin core, before funds could be forwarded)

Looks perfect to me!

It would solve your problem for sure.

The users would probably be interested in some easy access to stats about the transactions, so a webpage displaying said stats could be a good idea - this would be locked down to only be displayable to the relevant parties. It would also be possible to have simple settings pages for each user, and an administrative interface.

Not really necessary, a simple mail to the involved parties would be more than enough, stating how many btc was transferred.

Yes, that would be sufficient. Speaking of keeping it real simple, just your friends monitoring their addresses would also reveal how much btc were sent, so strictly speaking, getting a notice of sent coins is not mandatory to inform the friends about the coins received. However, implementing something like that is fairly easy, so if they prefer to have an e-mail, then that is perfectly doable.

...

It all sounds exactly the way I would like it, thanks for your help and time!
Just to clarify: is there the possibility to filter by receiving address?
Let's say receiving address A forwards to C and D, and receiving address B forwards to E, F and G, ... and so forth.

Yes, that is absolutely doable, either by config-files or database-tables to hold the settings, then the daemon would simply read the settings and apply the logic.

edit:
I installed Lubuntu 14.04 in a new VM, and bitcoin-qt is synchronizing with the network as we speak.

Very good. As for making this happen, I've layed out how it could be done, and I'm ready to code it for you, however I could not do it for free. If you're good at figuring out things and have enough time on your hands, I'm sure you could hack together a solution yourself that would do what you require, of which this thread would be a good starting point for you. If you chose to do it on your own, make sure you do the testing on bitcoin testnet (apply -testnet swith when running bitcoind and bitcoin-cli. That way you won't lose any coins if you mess up, and you won't pollute the blockchain with test transactions.

On the other hand, if you just want the ready solution in your hands in a few days, you could get in touch with me over pm, and we could negotiate a deal whereby I do the coding according to specs we agree on, and we make a brief contract outlining the details of this mini project. It could be done at a fixed cost, and with a "no cure, no pay" guarantee.

I wouldn't mind if some others chimed in and solved it for free, or if you did it yourself if you want to prioritize solving the task yourself, but if you want help, I'm willing and able to do so at a moderate fee. As for further details which need not be public, we could discuss that on pm. Let me know if you're interested, then I can start right away, and I can solve this issue for you asap. I assume you want this fixed quickly.

I would be very responsive throughout the entire process, so the task could be solved 100% to your satisfaction. Once, if you agree on the deal, then we will make a brief functional requirement specification. If you're unfamiliar with it, then you have a explanation here: http://en.wikipedia.org/wiki/Functional_specification

Excessive time and effort would not be put into making that specification, but the reason it is good to have is that both the dev and the customer would have a set of specs that outlined what the system would do, thereby avoiding mistakes and confusion. I would make the draft for the functional spec, and sent it to you, and you could comment or modify it, and once it's done, we would have a roadmap for what the mini project should cover. A spec is not written in stone however, and could always be changed. But extensive changes are work intensive (like adding sophisticated graphs and perhaps a responsive admin-interface or similar..) and would come at an additional cost.

Despite this wall of text, don't worry though, as I'm just thorough and appreciate the value of planning ahead, then the coding is more efficient and the entire process more streamlined. The most important thing for me, is for you to be happy with the solution, so if this is of interest, please let me know. Thanks.

[Abdussamad]

OP this is much easier to do using a hosted API. See chain.com or blocktrail.com.

Also you don't want to immediately split any receipts but wait for a minimum amount to be reached.

[xingming]

Hi,

me and my friends have a shared mining account at an undisclosed cloud mining site (undisclosed as it's not relevant to the question).

I would like for all profits to be sent to a wallet hosted on my server, which would then automatically and immediately split the profits into predetermined percentages, and send them to the addresses they should go.

Basically I'm trying to recreate exactly what coinsplit.io does, but on my own server.

The reason I'm hesitant to continue to use coinsplit.io (yes, I'm using it right now), is because of the fact that I believe the security for the site is not what it should be, and anyone who gains access to my account can change the forwarding address for all my schemes.

I was hoping there is some sort of wallet I can run on my server (OS doesn't matter, it's a hypervisor) which would allow me to do just that.

Anyone have an insight?

This is very easy just create an account in blockchain.info then choose the library for the language you use like php ,
then make a database for every address part ,,,, then just use it , to run a bitcoind you must have a VPS .

Xin Ming .