Topic: locktime, recurring payments and security (Read 908 times)
Duh. So the only thing I could do today with locktime is to create transactions that will be confirmed "delayed"? No way of cancelling or changing, and also not possible to "override" by issuing new transactions without locktime using the same inputs?
Locktime in its current implementation is not very useful. I thought it over once here: https://bitcointalksearch.org/topic/m.1289807. Transaction Replacement would have to be enabled for it to be useful.
Also, transactions with locktime can't be included in blockchain. So the receiver only could verify, that the locked transaction was broadcasted. The update with a new output-address would theoretically work, but as the transaction can't be replaced in the memory pool (once it is broadcasted), in practice this is (currently) not possible.
Also, transactions with locktime can't be included in blockchain. So the receiver only could verify, that the locked transaction was broadcasted. The update with a new output-address would theoretically work, but as the transaction can't be replaced in the memory pool (once it is broadcasted), in practice this is (currently) not possible.
Quote
You shouldn't have any hot wallets, if your doing recurring payments that can be handled completely off the site. I would have a cold storage wallet, that would be used one time day like at night, to send all payments, and have a database with bitcoin addresses, to hand out, then maybe every other day, check to see if the databases is at a limit, then generate more.
Yes, I am also thinking about this option. But it would introduce a whole new set of dependencies and complexity. To make it right and fully decouple the offsite wallet, communication should be one-way only - The off-site bitcoind service would regularly pull from the site the current "jobs" and needs to push any status change (balance, transactionIDs, confirmations etc.). Implementing this in a fail-safe and clean way is a huge effort, not including administrative overhead to keep multiple servers up and running, backed up etc. etc. That's the reason i started tossing ideas around about different approaches with less complexity but still high security.
I am thinking about possibilities for implementing recurring payments service with as little risk and user-interaction as possible.
Goals:
-> Keep the site's hot wallet balance as low as possible to make it unattractive for robbing
-> Allow the user to "pre-pay" for as long as he wants.
-> Allow the user to always cancel not-yet-paid payments
Scenario:
Let's say user wants to pay 1 BTC each week to an address.
User goes to service website, enters information "pay 1 BTC/week to Address X".
User sends 10 BTC to website.
Website splits these 10 BTC into 10 transactions of 1 BTC, each with a locktime one week further in the future.
=> User is done
=> Receiver gets 1 BTC/week
=> Receiver literally can see in the blockchain that payments to him are really planned (of course this is just for information - unlocked payments could be cancelled anytime)
=> Few days before the last pay date is reached site sends a reminder mail to user if he wants to continue the recurring payment he has to send funds.
=> Happiness
Now let's say the user wants to cancel the not-yet-paid transactions:
-> User goes to site, says to stop all payments
-> Site updates the unlocked transactions with a new Outpoint (The users address).
=> Q: Can the user get back his coins immediately? Can the locktime be modified also at this place, so the user gets his coins back right away? Or does he still have to wait for the locktime to be reached? Or could the site generate just a new normal transaction with all unlocked transaction's inputs as inputs that "overrides" the waiting transactions?
Now assume the site gets robbed and an attacker obtains the wallet.dat:
What is the actual balance of the wallet? If all incoming payments from Users are immediately broadcast with according locktime to the recipients - Would the wallet appear to the robber as "empty"? What additional information would he need to change all existing unlocked transactions to point to his address?
In general: Would this approach give any security boost over a classical "pay from hot wallet via cronjob"-approach?
Goals:
-> Keep the site's hot wallet balance as low as possible to make it unattractive for robbing
-> Allow the user to "pre-pay" for as long as he wants.
-> Allow the user to always cancel not-yet-paid payments
Scenario:
Let's say user wants to pay 1 BTC each week to an address.
User goes to service website, enters information "pay 1 BTC/week to Address X".
User sends 10 BTC to website.
Website splits these 10 BTC into 10 transactions of 1 BTC, each with a locktime one week further in the future.
=> User is done
=> Receiver gets 1 BTC/week
=> Receiver literally can see in the blockchain that payments to him are really planned (of course this is just for information - unlocked payments could be cancelled anytime)
=> Few days before the last pay date is reached site sends a reminder mail to user if he wants to continue the recurring payment he has to send funds.
=> Happiness
Now let's say the user wants to cancel the not-yet-paid transactions:
-> User goes to site, says to stop all payments
-> Site updates the unlocked transactions with a new Outpoint (The users address).
=> Q: Can the user get back his coins immediately? Can the locktime be modified also at this place, so the user gets his coins back right away? Or does he still have to wait for the locktime to be reached? Or could the site generate just a new normal transaction with all unlocked transaction's inputs as inputs that "overrides" the waiting transactions?
Now assume the site gets robbed and an attacker obtains the wallet.dat:
What is the actual balance of the wallet? If all incoming payments from Users are immediately broadcast with according locktime to the recipients - Would the wallet appear to the robber as "empty"? What additional information would he need to change all existing unlocked transactions to point to his address?
In general: Would this approach give any security boost over a classical "pay from hot wallet via cronjob"-approach?
Jump to: