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
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
|
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 <gronager@mac.com>) id 1SDwIw-0004SK-JR
for bitcoin-development@lists.sourceforge.net;
Sat, 31 Mar 2012 11:17:10 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of mac.com
designates 17.172.81.0 as permitted sender)
client-ip=17.172.81.0; envelope-from=gronager@mac.com;
helo=st11p00mm-asmtpout001.mac.com;
Received: from st11p00mm-asmtpout001.mac.com ([17.172.81.0])
by sog-mx-2.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1SDwIv-0005KR-Ce for bitcoin-development@lists.sourceforge.net;
Sat, 31 Mar 2012 11:17:10 +0000
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: text/plain; CHARSET=US-ASCII
Received: from [192.168.1.100] (78.156.214.17.bredband.3.dk [78.156.214.17])
by st11p00mm-asmtp001.mac.com
(Oracle Communications Messaging Exchange Server 7u4-22.01 64bit (built
Apr 21
2011)) with ESMTPSA id <0M1Q00BF8Y0AIW80@st11p00mm-asmtp001.mac.com>
for bitcoin-development@lists.sourceforge.net; Sat,
31 Mar 2012 11:17:03 +0000 (GMT)
X-Proofpoint-Virus-Version: vendor=fsecure
engine=2.50.10432:5.6.7498,1.0.260,0.0.0000
definitions=2012-03-31_01:2012-03-30, 2012-03-31,
1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0
ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0
classifier=spam
adjust=0 reason=mlx scancount=1 engine=6.0.2-1012030000
definitions=main-1203310064
From: =?iso-8859-1?Q?Michael_Gr=F8nager?= <gronager@mac.com>
In-reply-to: <20120331105401.GA14117@vps7135.xlshosting.net>
Date: Sat, 31 Mar 2012 13:16:56 +0200
Message-id: <FF86C935-B407-4983-BCB2-61A79DAF8DB8@mac.com>
References: <201203310003.18599.luke@dashjr.org>
<20120331105401.GA14117@vps7135.xlshosting.net>
To: Pieter Wuille <pieter.wuille@gmail.com>
X-Mailer: Apple Mail (2.1257)
X-Spam-Score: -1.5 (-)
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
(gronager[at]mac.com)
-0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain
-0.0 SPF_PASS SPF: sender matches SPF record
X-Headers-End: 1SDwIv-0005KR-Ce
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] 0.7 merge recommendations/status
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, 31 Mar 2012 11:17:10 -0000
If you are interested, I could push libcoin to bitcoin (e.g. bitcoin/libcoin) and then you could build bitcoind bitcoin-qt on libcoin.
libcoin solved most of the problems you list below. And if you worry about the copyright/license I am also willing to change that to make it fit.
libcoin have no global thread mutexes and and there is no blocking of the main thread due to rpc methods (except for a sendto), further, e.g. a reorganize only locks the main thread for a split second while the final commit is done.
The libcoin rpc supports keep_alive and pipelining, runs in its own thread (but can also run in the same thread as the node) and uses async operation. Ipv6 is easy to implement in libcoin as the CAddress/Endpoint class is implemented as a subclass of boost::endpoint, only thing holding back is deciding on an ipv6 format on IRC, and, I then I would really like to reverse the order of the last 12 bytes in the address db (they are opposite to boost).
Cheers,
Michael
On 31/03/2012, at 12:54, Pieter Wuille wrote:
> On Sat, Mar 31, 2012 at 12:03:17AM -0400, Luke-Jr wrote:
>> NOTE: I've been piecing this together for about a week now, and intended to
>> update it when 0.6.0 final was released, but with the timing of it, I just
>> won't get the time to update for a while, so here is my last draft...
>
> Nice summary, thanks.
>
>> It seems to me, there is potentially enough ready to merge into 0.7 to start
>> the RC process right away if someone wants to... except that the first merge
>> will probably require rebasing everything else ;)
>
> I think that's right - for several reasons, the time between 0.5 and 0.6 was
> over 4 months. I prefer more frequent releases, as it slows down development
> this way.
>
>> For similar reasons as CBlockStore, I feel multithreaded JSON-RPC with keep-
>> alive support (#568) should be merged sooner rather than later. It's long
>> overdue for bitcoind having had a lot of testing, and pretty much required for
>> any sort of high-volume bitcoind usage (such as solo mining). Some other
>> optimizations by Joel such as the optimized ToHex function (#562) and
>> FastGetWork (#565) have also had plenty of testing; all combined, these
>> optimizations more than double the performance of JSON-RPC.
>> Details: https://github.com/bitcoin/bitcoin/pull/565#issuecomment-3269334
>
> I'd rather see a decent encapsulation of wallet and blockchain data structures
> that allow us to make their mutexes private, and let only the code from the
> respective mutex take locks in it when necessary. That will automatically
> lead to multithreaded RPC, but in a safe way, without needing guesswork about
> which two calls may or may not be called simultaneously.
>
> Of course, that requires a lot more work, but at some point that will be needed
> anyway, imho.
>
>> Pieter's getalltransactions (#841) and my getblock_full (#886) provide what is
>> needed to completely replace Jeff's old dumpblock call with bitcoind's new
>> getblock. He also put together a -loadblock option (#883) which has proven
>> quite handy for development, and -walletupgrade (#974) seems like a good idea.
>
> I've used loadblocks often in my personal branches. At least on Linux it seems
> to work fine. The data scanning code is mostly Cish though, and there may be
> more preferrable to use boost or generic C++ solutions.
>
>> Finally, I don't know the status of Pieter's IPv6 support, but I hope it will
>> be ready for 0.7. Right now all I see submitted for this is support for
>> multiple local IPs (#829) though.
>
> I've already had a fully functional IPv6 node based on 0.3.24. Most of the changes
> there have since been incorported in netbase (#735), and because of a risk for DoS'es
> based on the much larger number of addresses an attacker could have under his control,
> addrman (#787) was necessary before IPv6 could be fully implemented. So, the technical
> part of supporting IPv6 seems mostly finished - right now, it's mostly just removing
> some (!IsIPv4()) checks and adding listen/connect code that is IPv6-compatible.
> I'll do a pullreq for that soon.
>
> There are a few other issues, though. For example: how will relaying work: will IPv4
> nodes relay IPv6 addresses? If not, the IPv6 bitcoin network will be completely
> separate from the IPv4 one, though both may overlap in some points. The opposite is
> also possible: allowing all nodes to relay IPv6 addresses, but only use them in case
> an IPv6-compatible interface is detected. Any opinions about this?
>
> Something else was suggested by Jeff: what if a node accidentally connects to itself?
> As we're moving towards multiple local addresses with IPv6, the chances for this
> become larger. Finally, there are always extra risks involved, as we could unknowingly
> be opening DoS or others vulnerabilities.
>
> Finally, supporting IPv6 in a somewhat general way would pave the way for bitcoin
> functioning for example as a Tor or I2P hidden service, by using onioncat-like
> tor-encoded-in-IPv6 addresses. This way, two bitcoin nodes could connect to eachother
> without the need for passing any exit node.
>
> --
> Pieter
>
> ------------------------------------------------------------------------------
> This SF email is sponsosred by:
> Try Windows Azure free for 90 days Click Here
> http://p.sf.net/sfu/sfd2d-msazure
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Michael Gronager, PhD
Director, Ceptacle
Jens Juels Gade 33
2100 Copenhagen E
Mobile: +45 31 45 14 01
E-mail: gronager@ceptacle.com
Web: http://www.ceptacle.com/
|
