Lawrence Nahum [ARCHIVE] on Nostr: 📅 Original date posted:2014-06-16 📝 Original message:Mike Hearn <mike <at> ...
📅 Original date posted:2014-06-16
📝 Original message:Mike Hearn <mike <at> plan99.net> writes:
> Please see https://github.com/bitcoin/bitcoin/pull/3883 which implements
this exact scheme. It can solve some kinds of double spends (probably), but
others - like ones done by corrupt miners (see bitundo) - can't be solved
this way.
I read the comments on the PR. I mean no disrespect but this patch can't
prevent double spends minutes apart and a solution is as good as it's
weakest link.
It also seems to suffer from potential ddos and otherwise may provide a
false sense of security. I wouldn't call it a solution in sight just yet.
> Lawrence's motivation for this BIP is essentially to act as a backup in
case the Bitcoin native double spending protections end up being too weak to
be useful. It reintroduces a notion of centralised trust as a layer on top
of the Bitcoin protocol, but only for cases where the seller/recipient feels
it'd be useful. In this way it gives us slack: if someone is able to
reliably double spend and the merchants losses due to payment fraud go up,
we can fall back to TTPs for a while until someone finds a solution for
Bitcoin, or we just give up on the Bitcoin experiment, but hey - at least we
now have a better intermediary protocol than SWIFT
I wouldn't put it just like that. Sure, it's a backup to the double spend
solution in case we don't reach one - but also, even if you reach some
reasonable compromise I assume it won't be instant and instant confirmation
between exchanges can create huge arbitrage opportunities and as such
liquidity.
It's not really aimed at the merchant but more at service providers and
payment processors - or simply, between users that don't know each other in
local traders environments/squares, assuming they are ok trusting a
known/respected/reputable third party.
> In practice of course this is something payment processors like Bitpay and
Coinbase will think about. Individual cafes etc who are just using mobile
wallets won't be able to deal with this complexity: if we can't make native
Bitcoin work well enough there, we're most likely to just lose that market
or watch it become entirely centralised around a handful of payment
processing companies.
What do you expect for e-commerce and escrow to happen? Don't you think the
market will naturally converge to a handful of hubs that will helps with
refunds and things like that? Or do you expect to just 'trust' all people on
online markets and smaller unknown online shops?
I mean, the beauty of Bitcoin is that it brings much more transparency and
the tools to build such things without huge barriers to entry and without
using closed protocols - not that it solves _every_ problem.
📝 Original message:Mike Hearn <mike <at> plan99.net> writes:
> Please see https://github.com/bitcoin/bitcoin/pull/3883 which implements
this exact scheme. It can solve some kinds of double spends (probably), but
others - like ones done by corrupt miners (see bitundo) - can't be solved
this way.
I read the comments on the PR. I mean no disrespect but this patch can't
prevent double spends minutes apart and a solution is as good as it's
weakest link.
It also seems to suffer from potential ddos and otherwise may provide a
false sense of security. I wouldn't call it a solution in sight just yet.
> Lawrence's motivation for this BIP is essentially to act as a backup in
case the Bitcoin native double spending protections end up being too weak to
be useful. It reintroduces a notion of centralised trust as a layer on top
of the Bitcoin protocol, but only for cases where the seller/recipient feels
it'd be useful. In this way it gives us slack: if someone is able to
reliably double spend and the merchants losses due to payment fraud go up,
we can fall back to TTPs for a while until someone finds a solution for
Bitcoin, or we just give up on the Bitcoin experiment, but hey - at least we
now have a better intermediary protocol than SWIFT
I wouldn't put it just like that. Sure, it's a backup to the double spend
solution in case we don't reach one - but also, even if you reach some
reasonable compromise I assume it won't be instant and instant confirmation
between exchanges can create huge arbitrage opportunities and as such
liquidity.
It's not really aimed at the merchant but more at service providers and
payment processors - or simply, between users that don't know each other in
local traders environments/squares, assuming they are ok trusting a
known/respected/reputable third party.
> In practice of course this is something payment processors like Bitpay and
Coinbase will think about. Individual cafes etc who are just using mobile
wallets won't be able to deal with this complexity: if we can't make native
Bitcoin work well enough there, we're most likely to just lose that market
or watch it become entirely centralised around a handful of payment
processing companies.
What do you expect for e-commerce and escrow to happen? Don't you think the
market will naturally converge to a handful of hubs that will helps with
refunds and things like that? Or do you expect to just 'trust' all people on
online markets and smaller unknown online shops?
I mean, the beauty of Bitcoin is that it brings much more transparency and
the tools to build such things without huge barriers to entry and without
using closed protocols - not that it solves _every_ problem.