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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gcbd-bitcoin-development@m.gmane.org>)
id 1V2sbU-00004z-R8 for bitcoin-development@lists.sourceforge.net;
Sat, 27 Jul 2013 00:43:24 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of m.gmane.org
designates 80.91.229.3 as permitted sender)
client-ip=80.91.229.3;
envelope-from=gcbd-bitcoin-development@m.gmane.org;
helo=plane.gmane.org;
Received: from plane.gmane.org ([80.91.229.3])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256)
(Exim 4.76) id 1V2sbR-00021J-WC
for bitcoin-development@lists.sourceforge.net;
Sat, 27 Jul 2013 00:43:24 +0000
Received: from list by plane.gmane.org with local (Exim 4.69)
(envelope-from <gcbd-bitcoin-development@m.gmane.org>)
id 1V2sbH-0001K5-Cc for bitcoin-development@lists.sourceforge.net;
Sat, 27 Jul 2013 02:43:11 +0200
Received: from linuxpal.mit.edu ([18.62.1.14])
by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
id 1AlnuQ-0007hv-00 for <bitcoin-development@lists.sourceforge.net>;
Sat, 27 Jul 2013 02:43:11 +0200
Received: from gdt by linuxpal.mit.edu with local (Gmexim 0.1 (Debian))
id 1AlnuQ-0007hv-00 for <bitcoin-development@lists.sourceforge.net>;
Sat, 27 Jul 2013 02:43:11 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: bitcoin-development@lists.sourceforge.net
From: Greg Troxel <gdt@work.lexort.com>
Date: Fri, 26 Jul 2013 20:43:00 -0400
Message-ID: <smuzjt8u92j.fsf@linuxpal.mit.edu>
References: <CANEZrP2GvgZP_1z3EoSs3p+db7tZB6JfEVAewLpGE5eRpGgR3w@mail.gmail.com>
<smumwpcg8sw.fsf@linuxpal.mit.edu>
<CAAS2fgTxU4fb6n+fHPomOVDkEY+uoepd7QTPMxbxALYm2Sf3kg@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Complaints-To: usenet@ger.gmane.org
X-Gmane-NNTP-Posting-Host: linuxpal.mit.edu
User-Agent: Gnus/5.130008 (Ma Gnus v0.8) Emacs/23.4 (berkeley-unix)
OpenPGP: id=098ED60E
Cancel-Lock: sha1:fOlTFObJXsfYtlyR50q66yZkUBY=
X-Spam-Score: -3.0 (---)
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 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,
no trust [80.91.229.3 listed in list.dnswl.org]
-0.0 SPF_HELO_PASS SPF: HELO matches SPF record
-0.0 SPF_PASS SPF: sender matches SPF record
-1.5 RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain
X-Headers-End: 1V2sbR-00021J-WC
Subject: Re: [Bitcoin-development] Linux packaging letter
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: Sat, 27 Jul 2013 00:43:25 -0000
Gregory Maxwell <gmaxwell@gmail.com> writes:
> It's "portable" to anything that can run the relevant VMs. Uh
> provided you don't mind cross compiling everything from an unbuntu VM.
> It certainly would be nice if the trusted-computing-base for gitian
> were a bit smaller, thats an area for long term improvement for sure.
Thanks - I'll look forward to this being portable someday. Right now it
sounds similar to "a windows binary but you can use wine" with
substitution of variables :-) People may want to look at the NetBSD
build system, which I think achieves bit-identical builds from different
hosts (but I haven't really checked), by having the toolchain be part of
the source and building cross-compilers from host to target and then
using those to build the system.
> Say Bitcoin used a backing database which had an unknown a bug where
> any item with a key that begins with 0xDEADBEEF returns not found when
> queried, even if its in the DB. Once discovered, any database library
> would want to fix that quickly and they'd fix it in a point release
> without reservation. They might not even release note that particular
> fix it if went along with some others, it could even be fixed
> accidentally.
>
> Now say that we have a state where half the Bitcoin network is running
> the old buggy version, and half is running the fixed version. Someone
> creates a transaction with ID 0xDEADBEEF... and then subsequently
> spends the output of that transaction. This could be by pure chance or
> it could be a malicious act.
>
> To half the network that spending transaction looks like someone
> spending coin from nowhere, a violation of the rules. The consensus
> would then fork, effectively partitioning the network. On each fork
> any coin could be spent twice, and the fork will only be resolvable by
> one side or the other abandoning their state (generally the more
> permissive side would need to be abandoned because the permissive one
> is tolerant of the restrictive one's behavior) by manually downgrading
> or patching software. As a result of this parties who believed some
> of their transactions were safely settled would find them reversed by
> people who exploited the inconsistent consensus.
Thanks for the explanation - that indeed makes sense.
>> multiple packages is difficult, and runs into A wants only n of C, while
>> B wants only m.
>
> My understanding is that gentoo is actually able to handle this (and
> does, for Bitcoin)— and really I presume just about everything else
> could with enough effort. I certainly wouldn't ask anyone else to do
> that. If you're really getting into the rathole of building separate
> libraries just for Bitcoin the value of packaging it goes away.
Well, if you insist on not having updates and bugfixes, then either it's
the included version or there's a special package just for you.
Typically packaging systems don't like included versions because often a
package will have a security bug fixed long before there are updates of
packages that bundle that fixed version. But given bitcoin's special
needs, that means you have to stay on top of these dependent included
packages and re-release if there are security fixes (that don't break
consensus).
> Running a complete set of tests is a start— though the unit tests are
> not and cannot be adequate. There is a full systems testing harnesses
> which should be used on new platforms. Even that though isn't really
> adequate, as it is currently infeasible to even achieve complete test
> coverage in things like cryptographic libraries and database
> environments.
It would be nice if the regression tests were installed and it were
normal culturallly for end-users to run them.
Thanks again for the explanation; I understand where you are coming from
now.
|
