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:25:11 -0600 [thread overview]
Message-ID: <54EA02E7.8060708@localhost.local> (raw)
In-Reply-To: <CAAt2M19u6AsULxUov9Z6JP+ByJRCaj3s5hQfe3TT-zfKgCuyxA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2889 bytes --]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 02/22/2015 10:17 AM, Natanael wrote:
> The problem with this approach is that it is worthless as a
> predictor. We aren't dealing with traffic safety and road design -
> we are dealing with adaptive attackers and malicious miners and
> pools.
>
> Anything which does not invalidate blocks carrying doublespends
> WILL allow malicious miners and pools to conspire with thieves to
> steal money. The probability of being hit will then be (their
> proliferation in your business area) * (their fraction of the
> mining power).
>
> That might seem to give small numbers for most sets of reasonable
> assumptions. But the problem is that's only an average, and the
> people being hit might have small profit margins - one successful
> attack can place hundreds of merchants in red numbers and force
> them to shut down.
>
> You should never expose yourself to attacks which you can't defend
> against and which can be fatal. In particular not if there's
> nothing in the environment that is capable of limiting the size or
> numbers of any attacks. And there's no such thing today in
> Bitcoin.
>
> This is why I sketched out the multisignature notary approach, and
> why some decided to extend that approach with collateral
> (NoRiskWallet) to further reduce trust in the notary. This is the
> single most practical approach I know of today to achieve ACTUAL
> SECURITY for unconfirmed transactions.
>
> Don't like it? See if you can do better!
>
> Just don't rely on zero-confirmation transactions!
You just disproved your own argument.
It is possible to predict risk, and therefore to price the risk.
You also noted that for some Bitcoin users, the price of that risk is
too high for the types of transactions in which wish to engage.
In what way does that translated into a universal requirement for
everybody to use multisignature notaries?
Surely the users who can afford the risk can use zero conf if they
like, and those who can't can use multisig notaries?
-----BEGIN PGP SIGNATURE-----
iQIcBAEBAgAGBQJU6gLmAAoJECpf2nDq2eYj8/AQAJfMtBqjo1Z2Z0A7OhE9iaYD
PqWXdRaCFwyV49RSDrRROrB9Vc7CENQsweHBSnNEmSj6la/YfjyobmaR5BMtTq73
ZaXOFYSGVa9S0j+1qTvz2MorBd6ocxckdunfN7N/uVb4NQRYTHUT8N7AyJgRFYO9
ElQU/8TcNCSRqSQc3z8rnUc8eN1+DgqkMDHM754huOgA0fz0OlxnLCddcCvLr0t7
ZPCtZI94FWQSWhzTK2oa41hh01xG+Eg5GhqGzM7WBqM6+d/CgNcUVeMnVOkkhgav
AmlE81Km9R4AlrsGT/CcGgaC+FvBhqmDYHAGOUG3hLP+MXMe4qA5TRoRKHFvq4Gw
nF6q+leI7z/TkKeiDcyEKKen5cU01SnZlVRnncccIxsjzNjCiBdXOTP6o0pTd34j
5VJQ04mF4sla5AaaSDtsbkZuMdqIZDMn1tWxbmXRQ2cUbCGoi4yYiUlqjetrs4e1
i7NopccLNVDwjGRRnaSs4KkpuW7s23XwKm6WVehrP7S9s1Bqc+84C/rL1G4IF3Ul
vOz+dfxpS+yeGdEDOxb92voKo+fvL/N1sH2+cqTemuYWArDOn1kK/qKdaEfnl9p2
VcPJWuik6Ywomg4fCWmTQWcDxbWiUT/Gb/niONOYQ6iJG7mU4SH9LFBDd8qV+ljN
RqUYrOBf/PaMneNxwJp+
=w36r
-----END PGP SIGNATURE-----
[-- Attachment #2: 0xEAD9E623.asc --]
[-- Type: application/pgp-keys, Size: 17801 bytes --]
next prev parent reply other threads:[~2015-02-22 16:25 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
2015-02-22 16:17 ` Natanael
2015-02-22 16:25 ` Justus Ranvier [this message]
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=54EA02E7.8060708@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