Sjors Provoost [ARCHIVE] on Nostr: đź“… Original date posted:2017-12-21 đź“ť Original message:Just to clarify two ...
đź“… Original date posted:2017-12-21
đź“ť Original message:Just to clarify two points:
> The good part is that it does not have to be adopted by exchanges. If popular exchanges do not adopt it, it is trivial to make an adapter service which translate COX to whatever proprietary API of the exchange.
Be sure to elaborate on the difference in trust assumptions between a merchant running such an adapter on their own infrastructure vs. trusting a SAAS that sits in between the exchange and the merchants infrastructure.
In general adapters would create additional risks to think about, depending on how fine-tuned the API key permissions are. E.g. if API keys come with full permissions you don’t want to install an adaptor plugin if your shop is hosted on wordpress.com. PayPal and Stripe make sure their API keys can’t do too much damage in case the merchant shop hosting is compromised.
> > Can this be combined with an invoice mechanism similar to Lightning, e.g. where the exchange sends a pre-image to the users wallet (relayed via and retained by the web shop) upon receipt of the funds, which they can then present to the merchant in case something went wrong. Exchanges might be happy to support this protocol, but they don’t want the burden of dealing with user support requests, so having signed invoices could help with that.
>
> This protocol can be expanded later for lightning trivially, where the call to the address source uri also returns a lightning payment request. (BOLT11)
I didn’t mean adding Lightning support (though that would be cool), I mean adding an invoice system to your proposal that is similar to how Lightning invoices work. Right now if the customer pays and the merchant has a poorly functioning shopping cart system, which I’ve seen more often than not, the customer would have to email their transaction id to the merchant, who then needs to login to their exchange to check if that address indeed belongs to them. But a merchant shouldn’t give all their support staff such access, and support staff may not have the right training, or even permission, to assess whether a transaction is cleared (“computer says no").
So you’d want some sort of signed message as part of the protocol that says “if this transaction ID confirms, this order ID is paid for”. Although this specific example wouldn’t play well with RBF. So maybe “if the confirmed balance of this address is >= X, this order ID is paid for”, but then the exchange can’t sweep it. So maybe instead you need a callback from the exchange to just tell you when it’s (expected to be) confirmed. BitPay offers merchants various risk settings for this, so that might be worth looking into.
Sjors
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171221/a7167172/attachment.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171221/a7167172/attachment.sig>;
đź“ť Original message:Just to clarify two points:
> The good part is that it does not have to be adopted by exchanges. If popular exchanges do not adopt it, it is trivial to make an adapter service which translate COX to whatever proprietary API of the exchange.
Be sure to elaborate on the difference in trust assumptions between a merchant running such an adapter on their own infrastructure vs. trusting a SAAS that sits in between the exchange and the merchants infrastructure.
In general adapters would create additional risks to think about, depending on how fine-tuned the API key permissions are. E.g. if API keys come with full permissions you don’t want to install an adaptor plugin if your shop is hosted on wordpress.com. PayPal and Stripe make sure their API keys can’t do too much damage in case the merchant shop hosting is compromised.
> > Can this be combined with an invoice mechanism similar to Lightning, e.g. where the exchange sends a pre-image to the users wallet (relayed via and retained by the web shop) upon receipt of the funds, which they can then present to the merchant in case something went wrong. Exchanges might be happy to support this protocol, but they don’t want the burden of dealing with user support requests, so having signed invoices could help with that.
>
> This protocol can be expanded later for lightning trivially, where the call to the address source uri also returns a lightning payment request. (BOLT11)
I didn’t mean adding Lightning support (though that would be cool), I mean adding an invoice system to your proposal that is similar to how Lightning invoices work. Right now if the customer pays and the merchant has a poorly functioning shopping cart system, which I’ve seen more often than not, the customer would have to email their transaction id to the merchant, who then needs to login to their exchange to check if that address indeed belongs to them. But a merchant shouldn’t give all their support staff such access, and support staff may not have the right training, or even permission, to assess whether a transaction is cleared (“computer says no").
So you’d want some sort of signed message as part of the protocol that says “if this transaction ID confirms, this order ID is paid for”. Although this specific example wouldn’t play well with RBF. So maybe “if the confirmed balance of this address is >= X, this order ID is paid for”, but then the exchange can’t sweep it. So maybe instead you need a callback from the exchange to just tell you when it’s (expected to be) confirmed. BitPay offers merchants various risk settings for this, so that might be worth looking into.
Sjors
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171221/a7167172/attachment.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171221/a7167172/attachment.sig>;