1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <natanael.l@gmail.com>) id 1YPZWQ-0004vf-Oi
for bitcoin-development@lists.sourceforge.net;
Sun, 22 Feb 2015 16:36:46 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 74.125.82.52 as permitted sender)
client-ip=74.125.82.52; envelope-from=natanael.l@gmail.com;
helo=mail-wg0-f52.google.com;
Received: from mail-wg0-f52.google.com ([74.125.82.52])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YPZWP-0008Mo-Ll
for bitcoin-development@lists.sourceforge.net;
Sun, 22 Feb 2015 16:36:46 +0000
Received: by mail-wg0-f52.google.com with SMTP id x12so21463407wgg.11
for <bitcoin-development@lists.sourceforge.net>;
Sun, 22 Feb 2015 08:36:39 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.180.198.44 with SMTP id iz12mr12775465wic.36.1424622999715;
Sun, 22 Feb 2015 08:36:39 -0800 (PST)
Received: by 10.194.28.170 with HTTP; Sun, 22 Feb 2015 08:36:39 -0800 (PST)
Received: by 10.194.28.170 with HTTP; Sun, 22 Feb 2015 08:36:39 -0800 (PST)
In-Reply-To: <54EA02E7.8060708@localhost.local>
References: <CALqxMTGBVdMX2RkuXNhkJ38XRM6DgAj+OmQTfHWuVF=emD-06Q@mail.gmail.com>
<20150222123428.GA6570@savin.petertodd.org>
<CAAt2M18fPgYOsfdebmU1Tk6ATnndPBn0k2PN-4fUJs1iTBTqnQ@mail.gmail.com>
<2953246.T2DHreG0Tu@crushinator> <54E9FD05.3000807@localhost.local>
<CAAt2M19u6AsULxUov9Z6JP+ByJRCaj3s5hQfe3TT-zfKgCuyxA@mail.gmail.com>
<54EA02E7.8060708@localhost.local>
Date: Sun, 22 Feb 2015 17:36:39 +0100
Message-ID: <CAAt2M1-DbpqsYZcng+SJyHMxyt-_POSo5DEsUXz_LzmJud5WaA@mail.gmail.com>
From: Natanael <natanael.l@gmail.com>
To: Justus Ranvier <justusranvier@riseup.net>
Content-Type: multipart/alternative; boundary=047d7b624dfed64572050fafe340
X-Spam-Score: -0.6 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(natanael.l[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1YPZWP-0008Mo-Ll
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] alternate proposal opt-in miner takes
double-spend (Re: replace-by-fee v0.10.0rc4)
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Sun, 22 Feb 2015 16:36:46 -0000
--047d7b624dfed64572050fafe340
Content-Type: text/plain; charset=UTF-8
- Sent from my tablet
Den 22 feb 2015 17:25 skrev "Justus Ranvier" <justusranvier@riseup.net>:
>
> You just disproved your own argument.
>
> It is possible to predict risk, and therefore to price the risk.
Your fault is that you assume the predictions can be reliable and
trustable.
They can not be.
The data you have available has none of the indicators you actually NEED to
make predictions. You're making extrapolations from the past, not
calculations based on recent trends and behavior globally.
> 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?
It isn't universal. It is just the most practical solution if you need
instant confirmation for high value transactions with customers you don't
yet trust.
> Surely the users who can afford the risk can use zero conf if they
> like, and those who can't can use multisig notaries?
Use whatever you want. I don't care. I will warn you about the risks and
make suggestions, but I won't force you to do anything differently.
--047d7b624dfed64572050fafe340
Content-Type: text/html; charset=UTF-8
<p dir="ltr"></p>
<p dir="ltr">- Sent from my tablet<br>
Den 22 feb 2015 17:25 skrev "Justus Ranvier" <<a href="mailto:justusranvier@riseup.net">justusranvier@riseup.net</a>>:<br>
><br>
> You just disproved your own argument.<br>
><br>
> It is possible to predict risk, and therefore to price the risk.</p>
<p dir="ltr">Your fault is that you assume the predictions can be reliable and trustable. </p>
<p dir="ltr">They can not be. </p>
<p dir="ltr">The data you have available has none of the indicators you actually NEED to make predictions. You're making extrapolations from the past, not calculations based on recent trends and behavior globally. </p>
<p dir="ltr">> You also noted that for some Bitcoin users, the price of that risk is<br>
> too high for the types of transactions in which wish to engage.<br>
><br>
> In what way does that translated into a universal requirement for<br>
> everybody to use multisignature notaries?</p>
<p dir="ltr">It isn't universal. It is just the most practical solution if you need instant confirmation for high value transactions with customers you don't yet trust. </p>
<p dir="ltr">> Surely the users who can afford the risk can use zero conf if they<br>
> like, and those who can't can use multisig notaries?</p>
<p dir="ltr">Use whatever you want. I don't care. I will warn you about the risks and make suggestions, but I won't force you to do anything differently.<br>
</p>
--047d7b624dfed64572050fafe340--
|
