Mike Hearn [ARCHIVE] on Nostr: 📅 Original date posted:2014-06-16 📝 Original message:> > Mike Hearn, why don't ...
📅 Original date posted:2014-06-16
📝 Original message:>
> Mike Hearn, why don't we just have all nodes report attempted double
> spends through the node network.
>
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.
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 :-)
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140616/87a73c6c/attachment.html>;
📝 Original message:>
> Mike Hearn, why don't we just have all nodes report attempted double
> spends through the node network.
>
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.
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 :-)
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140616/87a73c6c/attachment.html>;