From: Justus Ranvier <justusranvier@riseup•net>
To: bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] alternate proposal opt-in miner takes double-spend (Re: replace-by-fee v0.10.0rc4)
Date: Sun, 22 Feb 2015 10:00:05 -0600 [thread overview]
Message-ID: <54E9FD05.3000807@localhost.local> (raw)
In-Reply-To: <2953246.T2DHreG0Tu@crushinator>
[-- Attachment #1: Type: text/plain, Size: 2013 bytes --]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 02/22/2015 07:50 AM, Matt Whitlock wrote:
> This happened to one of the merchants at the Bitcoin 2013
> conference in San Jose. They sold some T-shirts and accepted
> zero-confirmation transactions. The transactions depended on other
> unconfirmed transactions, which never confirmed, so this merchant
> never got their money.
>
> I keep telling people not to accept transactions with zero
> confirmations, but no one listens.
A better solution is to track the failure rate of zero confirmation
transactions, and adjust prices accordingly to cover the expected loss.
This is what every merchant *already does* since no payment method has
a 0% fraud rate.
Even physical cash has a probability of being counterfeit, and the
prices you pay for things at a convenience store already have that
risk priced in.
The idea that zero confirmation transactions require a 100% guarantee
is a strawman, especially since there exists no number of
confirmations the actually produce a 100% irreversibility guarantee.
Zero confirmation transactions can work as long as the risk of
reversal is measurable and reasonably stable.
-----BEGIN PGP SIGNATURE-----
iQIcBAEBAgAGBQJU6f0FAAoJECpf2nDq2eYjWJsP/3I6b9KL2tr7wEGUyiUJvn95
wR/DQw3jRoC6rP1OqZAHpePksboEtd1yTxhtnH9UEMzvzFrGeQwKaSgM0s6zbIIm
38BXH6uiTzxI2PUWxv8HDNsPvwAlj0l4EkV9E8DthK9MTDVAk5E/SFUlwgc4tdYB
QinntAYknjIJd7dKVXlIaBrXg0UmTaXDKq9yoQIBTl9SE8xYbbRM154XAjVmqVrZ
h88ZGkaIbpHbBEjbUpqVpPIKM/Ts4b6NwLSfloY7W+Mmvgn3p6EB4V6rt3HuV/wN
L5A0RPbAESGsg0MpRcIprpAq4aiO6Qt0p6wMrZ9x6a+cx1w/RuJx7Sb3zflDjBgk
FmEwqIKJJqWoTEtR2nCEkmDvwx48RJQQppEHJgdUCmxjELpJMKkvtz9Oc4CRP0ty
6JUnBmxNTHRJLL+0nn1sq5WAhTLIQaH3RcVn/SjNk2zjoUXUdx+1pIEyBaZnOckW
e54SraX0KEEZNpTXHA3xJV0d2gA068CChG/TFqMO9uhohWz9jz6NZl7jFLwdBjgb
Wmbid/V/bl6W/ehCiOwLDM/sOer/BDoZPqGt/j2cJZO9gP+wVdiRkojl3f97vd9k
qhGV3QUsc8uiseZNxeIv2hty34KzUPz2ISPM25ZnQMavIevg3Yg0l4O7Hwnk49oK
1nhyoqk+scfLpo7vd6Ke
=fVAx
-----END PGP SIGNATURE-----
[-- Attachment #2: 0xEAD9E623.asc --]
[-- Type: application/pgp-keys, Size: 17801 bytes --]
next prev parent reply other threads:[~2015-02-22 16:00 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-22 8:02 Adam Back
2015-02-22 12:34 ` Peter Todd
2015-02-22 13:29 ` Natanael
2015-02-22 13:50 ` Matt Whitlock
2015-02-22 14:07 ` Peter Todd
2015-02-22 16:00 ` Justus Ranvier [this message]
2015-02-22 16:17 ` Natanael
2015-02-22 16:25 ` Justus Ranvier
2015-02-22 16:36 ` Natanael
2015-02-23 11:03 ` Mike Hearn
2015-02-22 14:44 ` Natanael
2015-02-22 14:11 ` Adam Back
2015-02-22 14:25 ` Bryan Bishop
2015-02-22 14:33 ` Peter Todd
2015-02-22 15:18 ` joliver
2015-02-22 15:41 ` Peter Todd
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=54E9FD05.3000807@localhost.local \
--to=justusranvier@riseup$(echo .)net \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox