Jeff Garzik [ARCHIVE] on Nostr: đź“… Original date posted:2015-06-21 đź“ť Original message:On Sun, Jun 21, 2015 at ...
đź“… Original date posted:2015-06-21
đź“ť Original message:On Sun, Jun 21, 2015 at 12:42 AM, Eric Lombrozo <elombrozo at gmail.com> wrote:
> Thanks for asking *the* question, Jeff. We often get caught up in these
> philosophical debates…but at the end of the day we need something concrete.
>
> Even more important than the specific software you’re using is the
> security policy.
>
> If you must accept zero confirmation transactions, there are a few
> concrete things you can do to reduce your exposure:
>
> 1) limit the transaction amounts for zero confirmation transactions - do
> not accept them for very high priced goods…especially if they require
> physical shipping.
> 2) limit the total amount of unconfirmed revenue you’ll tolerate at any
> given moment - if the amount is exceeded, require confirmations.
> 3) give merchants of subscription services (i.e. servers, hosting, etc…)
> the ability to shut the user out if a double-spend is detected.
>
Already done -- BitPay merchants choose their level of transaction
security. Level of confirmations is directly exposed to merchants, so that
they choose the level of risk for themselves.
Physically shipped orders and subscriptions are actually the easy cases and
are already handled. These can accept 0-conf for an initial order phase,
then have the luxury of time to wait for confirmations before shipping /
canceling a subscription.
Electronic goods instantly delivered are the toughest use case. Even
there, merchants choose their level of risk.
> 4) collect legal information on purchasers (or have the merchants collect
> this information) so you have someone to go after if they try to screw you
>
The system requests this information on orders yes. Merchants also collect
this info as their needs dictate.
> 5) create a risk profile for users…and flag suspicious behavior (i.e.
> someone trying to purchase a bunch of stuff that totally doesn’t fit into
> their purchasing habits).
> 6) get insurance (although right now reasonably-priced insurance is
> probably pretty hard to obtain since statistics are generally of little
> use…we’re entering uncharted territory).
> 7) set up a warning system and a “panic” button so that if you start to
> see an attack you can immediately disable all zero confirmation
> transactions system-wide.
> 8) independently verify all inbound transactions and connect to multiple
> network nodes…check them against one another.
>
Definitely looking at or have implemented this sort of stuff. I cannot get
into detail in public...
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150621/8d925c35/attachment.html>;
đź“ť Original message:On Sun, Jun 21, 2015 at 12:42 AM, Eric Lombrozo <elombrozo at gmail.com> wrote:
> Thanks for asking *the* question, Jeff. We often get caught up in these
> philosophical debates…but at the end of the day we need something concrete.
>
> Even more important than the specific software you’re using is the
> security policy.
>
> If you must accept zero confirmation transactions, there are a few
> concrete things you can do to reduce your exposure:
>
> 1) limit the transaction amounts for zero confirmation transactions - do
> not accept them for very high priced goods…especially if they require
> physical shipping.
> 2) limit the total amount of unconfirmed revenue you’ll tolerate at any
> given moment - if the amount is exceeded, require confirmations.
> 3) give merchants of subscription services (i.e. servers, hosting, etc…)
> the ability to shut the user out if a double-spend is detected.
>
Already done -- BitPay merchants choose their level of transaction
security. Level of confirmations is directly exposed to merchants, so that
they choose the level of risk for themselves.
Physically shipped orders and subscriptions are actually the easy cases and
are already handled. These can accept 0-conf for an initial order phase,
then have the luxury of time to wait for confirmations before shipping /
canceling a subscription.
Electronic goods instantly delivered are the toughest use case. Even
there, merchants choose their level of risk.
> 4) collect legal information on purchasers (or have the merchants collect
> this information) so you have someone to go after if they try to screw you
>
The system requests this information on orders yes. Merchants also collect
this info as their needs dictate.
> 5) create a risk profile for users…and flag suspicious behavior (i.e.
> someone trying to purchase a bunch of stuff that totally doesn’t fit into
> their purchasing habits).
> 6) get insurance (although right now reasonably-priced insurance is
> probably pretty hard to obtain since statistics are generally of little
> use…we’re entering uncharted territory).
> 7) set up a warning system and a “panic” button so that if you start to
> see an attack you can immediately disable all zero confirmation
> transactions system-wide.
> 8) independently verify all inbound transactions and connect to multiple
> network nodes…check them against one another.
>
Definitely looking at or have implemented this sort of stuff. I cannot get
into detail in public...
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150621/8d925c35/attachment.html>;