You can't go faster than 41 ms with incredibly easy integration and privacy.
Also, just a tip: Are you going to take on the cost of double spending? If not, I'd suggest researching.
Topic: OnionPay - Gauging Interest for a new easy to use BTC no-fee payment processor! (Read 1083 times)
July 04, 2013, 08:20:27 AM
Example: https://inputs.io
You can't go faster than 41 ms with incredibly easy integration and privacy.
Also, just a tip: Are you going to take on the cost of double spending? If not, I'd suggest researching.
You can't go faster than 41 ms with incredibly easy integration and privacy.
Also, just a tip: Are you going to take on the cost of double spending? If not, I'd suggest researching.
July 03, 2013, 11:59:24 PM
There are already merchant solutions supporting instant offchain payments which are much much more anonymous and suitable for deepweb transactions.
Examples? These payments aren't off-chain, the advantage is mostly for speed of product delivery when it comes to virtual goods or services. July 03, 2013, 11:37:00 PM
There are already merchant solutions supporting instant offchain payments which are much much more anonymous and suitable for deepweb transactions.
July 03, 2013, 11:19:27 PM
Does this require the merchants (= people accepting payments) to trust the operator? An example would be that the BTC are sent first to the service and merchants receive only 1 transaction per day to their designated address.
I would recommend to let merchants submit a public BIP32 seed key so the service creates the addresses from that and never has access to the actual funds. It can still charge some fees (e.g. "pay the fees or we don't display any address or our own address and keep funds in escrow/cover fees from incoming payments") that way but would not need to have that much trust. Still (by displaying their own addresses) they can mess with their merchants of course.
It would require merchants to trust the operator to an extent, but the BTC are immediately going to be forwarded to the merchant.I would recommend to let merchants submit a public BIP32 seed key so the service creates the addresses from that and never has access to the actual funds. It can still charge some fees (e.g. "pay the fees or we don't display any address or our own address and keep funds in escrow/cover fees from incoming payments") that way but would not need to have that much trust. Still (by displaying their own addresses) they can mess with their merchants of course.
The seed key is a good idea. I'll look into it. The plan is to keep it fee free for the foreseeable future.
The main advantage of the service would be for digital items or sites that want users to pay for an account in bitcoin - things like that.
July 03, 2013, 05:22:16 PM
Does this require the merchants (= people accepting payments) to trust the operator? An example would be that the BTC are sent first to the service and merchants receive only 1 transaction per day to their designated address.
I would recommend to let merchants submit a public BIP32 seed key so the service creates the addresses from that and never has access to the actual funds. It can still charge some fees (e.g. "pay the fees or we don't display any address or our own address and keep funds in escrow/cover fees from incoming payments") that way but would not need to have that much trust. Still (by displaying their own addresses) they can mess with their merchants of course.
I would recommend to let merchants submit a public BIP32 seed key so the service creates the addresses from that and never has access to the actual funds. It can still charge some fees (e.g. "pay the fees or we don't display any address or our own address and keep funds in escrow/cover fees from incoming payments") that way but would not need to have that much trust. Still (by displaying their own addresses) they can mess with their merchants of course.
July 03, 2013, 10:43:14 AM
clever.
July 03, 2013, 03:14:03 AM
I'm starting work on a relatively simple payment processor for use on TOR. The concept is simple - you want to accept payments over the deep web for items and a ten second solution without any fees or hassles. OnionPay is meant to do that.
You visit the site. With one click, you generate your public payment address and your private key/password to log in for the future. Select some options, such as redirecting to your site upon payment completion. You hand out the public payment address or integrate it into your site.
When someone needs to pay, they see a unique address to send coins to. The coins then get sent your personal wallet. After they pay, they're redirected to your site where you can use the API to verify some information about the payment - or, if it's for a digital purchase, they can immediately receive the information or download the product.
Generate your payment address. Hand it out. Get paid.
You visit the site. With one click, you generate your public payment address and your private key/password to log in for the future. Select some options, such as redirecting to your site upon payment completion. You hand out the public payment address or integrate it into your site.
When someone needs to pay, they see a unique address to send coins to. The coins then get sent your personal wallet. After they pay, they're redirected to your site where you can use the API to verify some information about the payment - or, if it's for a digital purchase, they can immediately receive the information or download the product.
Generate your payment address. Hand it out. Get paid.
Jump to: