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
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <john.dillon892@googlemail.com>) id 1UaFB8-0005jy-O5
for bitcoin-development@lists.sourceforge.net;
Thu, 09 May 2013 00:57:50 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of googlemail.com
designates 209.85.215.170 as permitted sender)
client-ip=209.85.215.170;
envelope-from=john.dillon892@googlemail.com;
helo=mail-ea0-f170.google.com;
Received: from mail-ea0-f170.google.com ([209.85.215.170])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1UaFB6-00046m-QV
for bitcoin-development@lists.sourceforge.net;
Thu, 09 May 2013 00:57:50 +0000
Received: by mail-ea0-f170.google.com with SMTP id q16so741462ead.1
for <bitcoin-development@lists.sourceforge.net>;
Wed, 08 May 2013 17:57:42 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.14.102.9 with SMTP id c9mr410528eeg.29.1368061062479; Wed,
08 May 2013 17:57:42 -0700 (PDT)
Received: by 10.223.101.82 with HTTP; Wed, 8 May 2013 17:57:42 -0700 (PDT)
In-Reply-To: <CANEZrP2TTcBJX86T+aRULDb7h9=MmoQa5U4cW0Z5ka8QAe_6Jg@mail.gmail.com>
References: <CANEZrP1YFCLmasOrdxdKDP1=x8nKuy06kGRqZwpnmnhe3-AroA@mail.gmail.com>
<20130506161216.GA5193@petertodd.org>
<CA+8xBpfdY7GsQiyrHuOG-MqXon0RGShpg2Yv-KeAXQ-503kAsA@mail.gmail.com>
<20130506163732.GB5193@petertodd.org>
<CANEZrP2WqXZVRJp6ag=RC4mSkt+a6qTYYpvE=DW_0Rdr=_BBHA@mail.gmail.com>
<20130506171943.GA22505@petertodd.org>
<CANEZrP2TTcBJX86T+aRULDb7h9=MmoQa5U4cW0Z5ka8QAe_6Jg@mail.gmail.com>
Date: Thu, 9 May 2013 00:57:42 +0000
Message-ID: <CAPaL=UWJZ2d2TSChM12Lg=1VDbKMAb2O2z2t0ts8CY0gb-yiMg@mail.gmail.com>
From: John Dillon <john.dillon892@googlemail.com>
To: Mike Hearn <mike@plan99.net>
Content-Type: text/plain; charset=ISO-8859-1
X-Spam-Score: -1.4 (-)
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
(john.dillon892[at]googlemail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
0.2 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in
digit (john.dillon892[at]googlemail.com)
-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: 1UaFB6-00046m-QV
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Discovery/addr packets (was: Service bits
for pruned nodes)
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: Thu, 09 May 2013 00:57:50 -0000
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
> > You mean scam you with a zero-conf transaction that hasn't actually been
> > broadcast?
>
> Yeah. Or just scam you at all. It's hard to imagine an organisation as
> a big as a mobile carrier engaging in financial scamming (roaming fees
> excepted).
Unless the government told them too.
> I've said this before, but I think it's worth repeating. The
> double-spend protection the block chain gives you has a sweet spot
> where it's really, really valuable (essential even) and then there are
> lots of kinds of transactions on either side of that sweet spot that
> don't really benefit from it.
>
> Obvious/trivial case where you don't need a block chain - Facebook
> buys Instagram for a gajillion coins. The legal system is plenty good
> enough to ensure the payments are honoured. Another example, when my
> employer pays me my salary. They aren't going to double spend this
> except through some horrible accident that we can get sorted out some
> other way.
The employer example actually shows something important: between a worker and
an employer double-spending already irrelevant. People get paid after they work
their two weeks not before, so the double-spend is already irrelevant.
However when your employer pays you on the blockchain until the transaction
confirms for someone else to accept funds from that payment they not only have
to trust you, but also the employer. Sure they could take it as "you said you
would apy me so it is your responsibility to make that happen" but that brings
a whole new level of complexity.
A scheme where you vouch for your payments with your identity can benifit from
being able to follow that chain all the way back to the last confirmed
transaction, although actually implementing this may be too complex to be
worthwhile, especially initially.
> Another case, very small payments. This is Satoshi's bag of crisps
> example. If the cost/complexity of double spending is higher than what
> the payment is worth, again, you don't really need the block chain.
> That's why it's worth optimising unconfirmed transactions to be harder
> to double spend, it optimises (pushes up) that lower bar.
Yes. But the issue is how are you going to optmize it? By adding yet more
restrictions and limitations on those who chose to run a node or mining
operation, or by actually fixing the trust issue? We know you can do the
latter, so do not sacrifice Bitcoin's core layer in silly attempts to make
double-spends harder. Fundementally Bitcoin has exactly one way of achieving
consensus, and that is the blockchain.
It must be your right to chose what transactins you chose to mine and chose to
relay. End of story. Bitcoin is not about imposing regulation on those who
choose to use it.
> Place where you really want the chain - largeish sums of money are
> moving around, but not large enough to justify expensive
> cross-jurisdictional legal action, or where the cost of identity
> verification and all the associated paperwork is just too high. I
> guess most online transactions fall into this bucket today.
Indeed. Especially for the most popular use of Bitcoin as a payment system:
buying things PayPal won't let you. In that circumstance the only leverage you
have is the protections of the blockchain and the damage you can do to the
other (often anonymous) parties reputation.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQEcBAEBCAAGBQJRivRcAAoJEEWCsU4mNhiPoJcIAL7T/x5gipsCNn/w3EfhZhKo
iukP0Kc3cni/Kb6gJrOlXufIxDrX8QxEhbIIrypFbyg+xHPK8NzSd13ScKNtLgjM
w2uOI/IkgUh7VLIEZADqLO3TM5S5VDZ/A42yzTIq8MeWxaTBD1JulOc/RbljGu8V
UrF6ptxu2UXTc0eXcor1lHfJRVteTJAAba5Awa1EAHX8f2c/1FhdrnOZwfLVJIfK
/nnUgqGKc8l08knC6NnAlP39zbk/FHiZF/keWIFIzhiyXTnqKnqD096tIx6MpPci
LGafjCoXACpr1XeiSufER/z6WxTvOvCbWRw4MYrbyRkmChqMtc8a7RMEPLXhaMQ=
=Oh/p
-----END PGP SIGNATURE-----
|
