summaryrefslogtreecommitdiff
path: root/71/fa2d839e753a6c9712bc53fba4cfa71572e47f
blob: 3c621381c318dc3bb9e88de6cc7a7e884caf3a39 (plain)
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
149
150
151
152
Return-Path: <lloyd.fourn@gmail.com>
Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 4E0E6C0175;
 Tue,  5 May 2020 15:16:29 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by fraxinus.osuosl.org (Postfix) with ESMTP id 3D6B1868EF;
 Tue,  5 May 2020 15:16:29 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from fraxinus.osuosl.org ([127.0.0.1])
 by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id g3IKYftW_L4s; Tue,  5 May 2020 15:16:28 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-io1-f66.google.com (mail-io1-f66.google.com
 [209.85.166.66])
 by fraxinus.osuosl.org (Postfix) with ESMTPS id 82BA186813;
 Tue,  5 May 2020 15:16:28 +0000 (UTC)
Received: by mail-io1-f66.google.com with SMTP id c2so2315226iow.7;
 Tue, 05 May 2020 08:16:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=8aOl/cmPgmnj38IvdJS80un10dnq6/S8AD4yLsCrq6Q=;
 b=enIvD5nHS7o/gLmfDEsKfWYqDKyWO2Ey9WbcbrQgZ+MxsOQWWn1q7+OSoXaPBv/L47
 wIiDe/rkKdQiQtpO+Lro4967aKHPOom3tSyMLDYOLeArzmxXkZ4Mv5AvgD9SbndfNy5L
 Jml8pD3+Jm3auTwGQfoAw0vk4FTseXYtgHjAGG9U0HGMaOx2jcBsPjL70r56QeF/gR9C
 d6THYN+lYJ+TrlojCBCgro0UrOikIYQWsKxYeXbkOyNU75syoLAohxba6S8hVNen3J1a
 h1YVuH4sjSncLLH+qM7Z9jC1/KMT8u8tWd91pN1mO/UEGJihx+3Eafyy5mrwrpWkBokf
 JF0Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=8aOl/cmPgmnj38IvdJS80un10dnq6/S8AD4yLsCrq6Q=;
 b=BGtc3/VWrqozEGj9hqd75DwBxNAlYNFa6zMWpLKSKqS/5CxBRsZP6WcpUDMNQ3et1U
 pAy5C+GcQh1BwnE3OMCssBo1k/uZIES1Ra0l8XQh2tq2mSPaVEtVz44ehBA55RWV+vG0
 1WukAQEDPg2nbm91kAAXaqQOTjS2AA+mT3rkOXTLF3jNUrl0+0/1H+GPCtdIrZWiJ2n9
 20P22oOk/f1vUCufbdnksBG3iSZs6VhG2DrPugviSsnAh496AjjMEhHi5R5Q7TASc1HK
 oEBX0Q48sRBC1+XiexymlHfPR2CF/6d6pcz0QHQTF6foXeM28xBRnpQCqYMW+fOgCHZR
 dUIg==
X-Gm-Message-State: AGi0PuYdgCarvy1kpDjyavhFQ0pVJ1Sxbv4uq2KNGTFL0GblJ/UsWOEz
 wagiD/hinIf0tFAS5MEHwDC0j72CPOfl2Jfbvws=
X-Google-Smtp-Source: APiQypISjB/PzMOwjHAAWiqsHix83FxsnSPFDBuKlvDTTAQYaycpMgpGrm9Krz2j/FWhLFXWuqXCJ39CAddQqGYWK34=
X-Received: by 2002:a6b:ec10:: with SMTP id c16mr3854628ioh.162.1588691787757; 
 Tue, 05 May 2020 08:16:27 -0700 (PDT)
MIME-Version: 1.0
References: <CALZpt+GBPbf+Pgctm5NViNons50aQs1RPQkEo3FW5RM4fL9ztA@mail.gmail.com>
 <202005051300.38836.luke@dashjr.org>
In-Reply-To: <202005051300.38836.luke@dashjr.org>
From: Lloyd Fournier <lloyd.fourn@gmail.com>
Date: Tue, 5 May 2020 23:16:01 +0800
Message-ID: <CAH5Bsr27rN1SE166ON_q49=MNti0v7Vyn6s6T5R3=LC69K2QdQ@mail.gmail.com>
To: Luke Dashjr <luke@dashjr.org>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000aabc3405a4e82181"
X-Mailman-Approved-At: Tue, 05 May 2020 15:18:53 +0000
Cc: "lightning-dev\\\\@lists.linuxfoundation.org"
 <lightning-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] On the scalability issues of onboarding millions
 of LN mobile clients
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Tue, 05 May 2020 15:16:29 -0000

--000000000000aabc3405a4e82181
Content-Type: text/plain; charset="UTF-8"

On Tue, May 5, 2020 at 9:01 PM Luke Dashjr via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Tuesday 05 May 2020 10:17:37 Antoine Riard via bitcoin-dev wrote:
> > Trust-minimization of Bitcoin security model has always relied first and
> > above on running a full-node. This current paradigm may be shifted by LN
> > where fast, affordable, confidential, censorship-resistant payment
> services
> > may attract a lot of adoption without users running a full-node.
>
> No, it cannot be shifted. This would compromise Bitcoin itself, which for
> security depends on the assumption that a supermajority of the economy is
> verifying their incoming transactions using their own full node.
>

Hi Luke,

I have heard this claim made several times but have never understood the
argument behind it. The question I always have is: If I get scammed by not
verifying my incoming transactions properly how can this affect anyone
else? It's very unintuative.  I've been scammed several times in my life in
fiat currency transactions but as far as I could tell it never negatively
affected the currency overall!

The links you point and from what I've seen you say before refer to "miner
control" as the culprit. My only thought is that this is because a light
client could follow a dishonest majority of hash power chain. But this just
brings me back to the question. If, instead of BTC, I get a payment in some
miner scamcoin on their dishonest fork (but I think it's BTC because I'm
running a light client) that still seems to only to damage me. Where does
the side effect onto others on the network come from?

Cheers,

LL

--000000000000aabc3405a4e82181
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">On Tue, May 5, 2020 at 9:01 PM Luke Dashj=
r via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.o=
rg">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><div clas=
s=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px=
 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Tues=
day 05 May 2020 10:17:37 Antoine Riard via bitcoin-dev wrote:<br>
&gt; Trust-minimization of Bitcoin security model has always relied first a=
nd<br>
&gt; above on running a full-node. This current paradigm may be shifted by =
LN<br>
&gt; where fast, affordable, confidential, censorship-resistant payment ser=
vices<br>
&gt; may attract a lot of adoption without users running a full-node.<br>
<br>
No, it cannot be shifted. This would compromise Bitcoin itself, which for <=
br>
security depends on the assumption that a supermajority of the economy is <=
br>
verifying their incoming transactions using their own full node.<br></block=
quote><div><br></div><div>Hi Luke,</div><div><br></div><div>I have heard th=
is claim made several times but have never understood the argument behind i=
t. The question I always have is: If I=C2=A0get scammed by not verifying my=
 incoming transactions properly how can this affect anyone else? It&#39;s v=
ery unintuative.=C2=A0 I&#39;ve been scammed several times in my life in fi=
at currency transactions but as far as I could tell it never negatively aff=
ected the currency overall!</div><div><br></div><div>The links you point an=
d from what I&#39;ve seen you say before refer=C2=A0to &quot;miner control&=
quot; as the culprit. My only thought is that this is because a light clien=
t could follow a dishonest majority of hash power chain. But this just brin=
gs me back to the question. If, instead of BTC, I get a payment in some min=
er scamcoin on their dishonest fork (but I think it&#39;s BTC because I&#39=
;m running a light client) that still seems to only to damage me. Where doe=
s the side effect onto others on the network come from?</div><div><br>Cheer=
s,</div><div><br></div><div>LL</div></div></div>

--000000000000aabc3405a4e82181--