And while we are at it, how about facilities for setting up contracts and future payments?
http://forum.bitcoin.org/index.php?topic=8821.0
The so called "Dead mans Handle". This is a truly awesome piece of functionality.
I would also like to be able to set up standing orders.
Topic: CLIENT FEATURES REQUEST (Read 755 times)
Well, you have to factor in the 10-20 min+ time lag for business transactions, unless the parties trust each other.
Basically, you pay when you order, then it is verified by the time you finish eating.
Tips truly would be anonymous (for us and tipping areas), so waitresses would have more difficulty profiling.
Basically, you pay when you order, then it is verified by the time you finish eating.
Tips truly would be anonymous (for us and tipping areas), so waitresses would have more difficulty profiling.
I think the multi-wallet thing is really important. As well as "bitcoin pro" I'd like to see a vendor version, with multi-terminal support.
I imagine a pub or restaurant with many waitresses and several terminals. A group of people walk in, sit down and waitress1 sets up an account for them and brings their first order, noting it down on the orders page, what they had, how many etc. A second waitress at a second terminal brings up the page for table3 (or whatever) and adds additional items to it. Lastly they ask for "the check" and the waitress brings them a printed bill with a bitcoin address to pay, this should be able to receive several payments if the bill is "split" be able to receive a tip, and be able to be re-opened if, having paid, another order is made. Perhaps some people leave and pay their part of the bill, the others buy more items. Once fully paid a receipt can be printed. Lastly a completely new account can be started at table3 when a new group of people walk in. Orders should have the time and date against them as should payments. Something similar could be used by a mail order company, although in this case the customerid is not reused and may store additional info like mailing address as well. Or not as the case may be.
It is worth mentioning that most of this does not have to be "in the client", it can be implemented using the existing client hooks as a seperate application. But some form of multi wallet support in the client would be really helpful for this. But it could be a new client using the existing client code for the bitcoin part of this.
I think that a receive only switch would be useful too. After all, we dont want those waitresses siphoning off bitcoins to their home account do we. (As they would!!)
And perhaps a facility for maintaining separate tip accounts for each waitress.
I imagine a pub or restaurant with many waitresses and several terminals. A group of people walk in, sit down and waitress1 sets up an account for them and brings their first order, noting it down on the orders page, what they had, how many etc. A second waitress at a second terminal brings up the page for table3 (or whatever) and adds additional items to it. Lastly they ask for "the check" and the waitress brings them a printed bill with a bitcoin address to pay, this should be able to receive several payments if the bill is "split" be able to receive a tip, and be able to be re-opened if, having paid, another order is made. Perhaps some people leave and pay their part of the bill, the others buy more items. Once fully paid a receipt can be printed. Lastly a completely new account can be started at table3 when a new group of people walk in. Orders should have the time and date against them as should payments. Something similar could be used by a mail order company, although in this case the customerid is not reused and may store additional info like mailing address as well. Or not as the case may be.
It is worth mentioning that most of this does not have to be "in the client", it can be implemented using the existing client hooks as a seperate application. But some form of multi wallet support in the client would be really helpful for this. But it could be a new client using the existing client code for the bitcoin part of this.
I think that a receive only switch would be useful too. After all, we dont want those waitresses siphoning off bitcoins to their home account do we. (As they would!!)
And perhaps a facility for maintaining separate tip accounts for each waitress.
I'd like to have more options available in the clients, maybe "Bitcoin Pro" or something.
On the macro level
- Multi-wallet support, or at least ability to switch wallets between program loads (i.e.load alternate wallet file)
On the micro level
- ability to see the mean/median/mode fees that the nodes charged for the last few blocks
- ability to adjust fee below (i.e. ignore) the .0005 level / tax or any future level tax, as a personal judgement, possibly to one of preset values (described above) (adding an additional field above or below send amount on the send popup screen seems the best interface to allow fee choices)
- showing each public address balance separately from the total private wallet balance (i.e. 3rd column in address book for balance *and* additional tab for public address balances)
- ability to manually choose which public addresses are sending BTC instead of the client choosing (extra option for public address to debit, best is ability to choose from all public address balances in any increments up to that accounts balance.
e.g. send screen reads:
"DEBIT AMOUNT ______ BTC FROM _____ ACCOUNT" <---filling both entries here opens an additional line
"DEBIT AMOUNT ______ BTC FROM _____ ACCOUNT" etc.
Drop down menus preferred but use of address book feature would work, showing balances as above.
- ability to pay multiple accounts at once. Similar to above,
"CREDIT AMOUNT _______ BTC TO _______ ACCOUNT" <---filling both entries here opens an additional line
"CREDIT AMOUNT _______ BTC TO _______ ACCOUNT" etc.
I know several pools have some of these these features, not sure if there's end-user interface though.
Name your price/s, although I suspect there are many other users who would enjoy these features.
On the macro level
- Multi-wallet support, or at least ability to switch wallets between program loads (i.e.load alternate wallet file)
On the micro level
- ability to see the mean/median/mode fees that the nodes charged for the last few blocks
- ability to adjust fee below (i.e. ignore) the .0005 level / tax or any future level tax, as a personal judgement, possibly to one of preset values (described above) (adding an additional field above or below send amount on the send popup screen seems the best interface to allow fee choices)
- showing each public address balance separately from the total private wallet balance (i.e. 3rd column in address book for balance *and* additional tab for public address balances)
- ability to manually choose which public addresses are sending BTC instead of the client choosing (extra option for public address to debit, best is ability to choose from all public address balances in any increments up to that accounts balance.
e.g. send screen reads:
"DEBIT AMOUNT ______ BTC FROM _____ ACCOUNT" <---filling both entries here opens an additional line
"DEBIT AMOUNT ______ BTC FROM _____ ACCOUNT" etc.
Drop down menus preferred but use of address book feature would work, showing balances as above.
- ability to pay multiple accounts at once. Similar to above,
"CREDIT AMOUNT _______ BTC TO _______ ACCOUNT" <---filling both entries here opens an additional line
"CREDIT AMOUNT _______ BTC TO _______ ACCOUNT" etc.
I know several pools have some of these these features, not sure if there's end-user interface though.
Name your price/s, although I suspect there are many other users who would enjoy these features.
Jump to: