Re: [Bitcoin-development] Block Size Increase Requirements

2015-05-30 Thread Matt Corallo
On 05/29/15 23:48, Gavin Andresen wrote: On Fri, May 29, 2015 at 7:25 PM, Matt Corallo bitcoin-l...@bluematt.me mailto:bitcoin-l...@bluematt.me wrote: Sadly, this is very far from the whole story. The issue of miners optimizing for returns has been discussed several times during

Re: [Bitcoin-development] Block Size Increase Requirements

2015-05-29 Thread Matt Corallo
On 05/29/15 22:36, Gavin Andresen wrote: Matt brought this up on Twitter, I have no idea why I didn't respond weeks ago (busy writing blog posts, probably): On Thu, May 7, 2015 at 6:02 PM, Matt Corallo bitcoin-l...@bluematt.me mailto:bitcoin-l...@bluematt.me wrote: * Though

Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread Matt Corallo
On 05/07/15 11:29, Mike Hearn wrote: Can you please elaborate on what terrible things will happen if we don't increase the block size by winter this year? I was referring to winter next year. 0.12 isn't scheduled until the end of the year, according to Wladimir. I explained where

Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread Matt Corallo
Replies inline. On 05/07/15 17:43, Mike Hearn wrote: The only answer to this that anyone with a clue should give is it will very, very likely be able to support at least 1MB blocks roughly every 10 minutes on average for the next eleven years, and it seems likely that a block

[Bitcoin-development] Block Size Increase Requirements

2015-05-07 Thread Matt Corallo
. On 05/07/15 19:13, Jeff Garzik wrote: On Thu, May 7, 2015 at 3:03 PM, Matt Corallo bitcoin-l...@bluematt.me mailto:bitcoin-l...@bluematt.me wrote: -snip- If, instead, there had been an intro on the list as I think we should do the blocksize increase soon, what do people think?, the response

Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread Matt Corallo
On 05/07/15 19:34, Mike Hearn wrote: The appropriate method of doing any fork, that we seem to have been following for a long time, is to get consensus here and on IRC and on github and *then* go pitch to the general public So your concern is just about the ordering and

Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread Matt Corallo
On 05/07/15 14:52, Gavin Andresen wrote: For reference: the blog post that (re)-started this debate, and which links to individual issues, is here: http://gavinandresen.ninja/time-to-roll-out-bigger-blocks In it, I asked people to email me objections I might have missed. I would still

[Bitcoin-development] Block Size Increase

2015-05-06 Thread Matt Corallo
Recently there has been a flurry of posts by Gavin at http://gavinandresen.svbtle.com/ which advocate strongly for increasing the maximum block size. However, there hasnt been any discussion on this mailing list in several years as far as I can tell. Block size is a question to which there is no

Re: [Bitcoin-development] Block Size Increase

2015-05-06 Thread Matt Corallo
For now, lets leave the discussion to JUST the block size increase. If it helps - everyone should assume that their pet feature is included in a hard fork or, if you prefer, that no other features are included in a hard fork. On 05/06/15 23:11, Matt Whitlock wrote: I'm not so much opposed to a

Re: [Bitcoin-development] Block Size Increase

2015-05-06 Thread Matt Corallo
Replies inline. On 05/06/15 22:44, Tier Nolan wrote: On Wed, May 6, 2015 at 11:12 PM, Matt Corallo bitcoin-l...@bluematt.me mailto:bitcoin-l...@bluematt.me wrote: Personally, I'm rather strongly against any commitment to a block size increase in the near future. -snip- The question

Re: [Bitcoin-development] Relative CHECKLOCKTIMEVERIFY (was CLTV proposal)

2015-05-03 Thread Matt Corallo
On 04/21/15 07:59, Peter Todd wrote: On Mon, Mar 16, 2015 at 10:22:13PM +, Matt Corallo wrote: In building some CLTV-based contracts, it is often also useful to have a method of requiring, instead of locktime-is-at-least-N, locktime-is-at-least-N-plus-the-height-of-my-input. ie you could

[Bitcoin-development] Relative CHECKLOCKTIMEVERIFY (was CLTV proposal)

2015-03-16 Thread Matt Corallo
In building some CLTV-based contracts, it is often also useful to have a method of requiring, instead of locktime-is-at-least-N, locktime-is-at-least-N-plus-the-height-of-my-input. ie you could imagine an OP_RELATIVECHECKLOCKTIMEVERIFY that reads (does not pop) the top stack element, adds the

Re: [Bitcoin-development] Area of Focus

2014-12-20 Thread Matt Corallo
There was recently some discussion around dnsseeds. Currently some dnsseeds are getting blocked by ISPs because the hosts they pick up (which run bitcoin core nodes) often run rather web servers alongside which serve malware or whatever else and thus end up on IP-based malware blacklists. Of

Re: [Bitcoin-development] Area of Focus

2014-12-20 Thread Matt Corallo
perfectly good nodes will get caught in the crossfire. Hiding what actual IPs we're returning in the results seems much cleaner, despite being an ugly hack. On 12/20/14 11:14, Jeremy Spilman wrote: On Sat, Dec 20, 2014 at 08:57:53AM +, Matt Corallo wrote: There was recently some discussion around

Re: [Bitcoin-development] ACK NACK utACK Concept ACK

2014-12-09 Thread Matt Corallo
Also utACK (untested ack) and tested ack when people are being explicit. On 12/09/14 21:14, Sergio Lerner wrote: Is that the full terminology or are there more acronyms? Is this documented somewhere? Best regards, Sergio.

Re: [Bitcoin-development] The difficulty of writing consensus critical code: the SIGHASH_SINGLE bug

2014-11-06 Thread Matt Corallo
Depends, without BIP62 a /lot/ of the even basic contracts that people want to use today (or wanted to use 18 months ago) are unusable, in fact, without BIP62, the atomic swaps suggested as important for sidechains are not secure. While redoing Bitcoin in a hardfork is nice, its a very long-term

Re: [Bitcoin-development] DS Deprecation Window

2014-10-27 Thread Matt Corallo
It is a very bad idea to delay relaying/accepting blocks based on information which is only local to your node (ie would create the ability for people to split the network by sending out lots of double-spends to different parts of the network at the same time). Thus, miners are incentivized to go

Re: [Bitcoin-development] Proposed BIP status changes

2014-10-15 Thread Matt Corallo
On 10/15/14 08:47, Wladimir wrote: These BIPs should go to Final state - they are implemented all over the place, and are thus entirely fixed in place now. Any changes would require a new BIP as amandment: - BIP 14 (BIP Protocol Version and User Agent) - BIP 21 (URI Scheme) ACK. -

Re: [Bitcoin-development] Fwd: [Bug 24444] Named Curve Registry (adding secp256k1)

2014-10-13 Thread Matt Corallo
See-also: this related bug on Curve25519 and some MS Research curves that generated far more discussion. https://www.w3.org/Bugs/Public/show_bug.cgi?id=25839 Matt On 10/13/14 10:01, Melvin Carvalho wrote: FYI: This is an issue I filed related to adding secp256k1 into Web Crypto API which

Re: [Bitcoin-development] Decreasing block propagation time

2014-10-01 Thread Matt Corallo
It already is https://bitcointalk.org/index.php?topic=766190.0;all. Well, ok, a variation on the idea is. Matt On 10/02/14 04:39, Rebroad (sourceforge) wrote: https://bitcointalk.org/index.php?topic=145066.0 The idea proposed in the above article seemed like an excellent idea. What is

[Bitcoin-development] RIP Hal Finney

2014-08-28 Thread Matt Corallo
I'm sure many of you have already seen this, but Hal Finney passed away on Tuesday. While his body is being cryogenically preserved, we should all take a moment to thank Hal for everything he did for the cypherpunk community, specifically helping hugely in the early days of Bitcoin as well as PGP.

Re: [Bitcoin-development] [ANN] High-speed Bitcoin Relay Network

2014-08-02 Thread Matt Corallo
and a relay node at http://bitcoin.ninja/RelayNodeClient.jar and the source for the whole thing at https://github.com/TheBlueMatt/RelayNode. Matt On 11/06/13 05:50, Matt Corallo wrote: Recently, there has been a reasonable amount of discussion about the continued fragility of the public Bitcoin

Re: [Bitcoin-development] Policy for DNS seeds

2014-07-22 Thread Matt Corallo
Absolutely not. Time and time again we've seen anonymized data sets that dont work out so well. I'm sure its possible to do but there are too many factors and we dont want to succumb to this. Also, these generally look good (and essentially the same as what had been a gentleman's agreement for

Re: [Bitcoin-development] DNS seeds unstable

2014-05-16 Thread Matt Corallo
This is very strange...when did you run this test and can anyone else reproduce this? Matt On 05/15/14 11:50, Andreas Schildbach wrote: testnet-seed.bluematt.me OK (but only returns one node) -- Accelerate

Re: [Bitcoin-development] DNS seeds unstable

2014-05-16 Thread Matt Corallo
Oops, missed the lost On May 16, 2014 3:04:40 PM EDT, Matt Corallo bitcoin-l...@bluematt.me wrote: Oh, I missed that this was the testnet seed. Yea, that one never got set up properly and was just pointing to a static seed node (that is now down...). The mainnet seed actually works. On 05/16/14

Re: [Bitcoin-development] Ubuntu LTS Packaging?

2014-04-12 Thread Matt Corallo
Hmm? It's up to date... 0.9.1 doesn't change anything for dynamically-linked-to-openssl builds. Matt On April 12, 2014 10:26:07 AM EDT, Oliver Egginger bitc...@olivere.de wrote: Hello, so far, nothing yet? See: https://launchpad.net/~bitcoin/ I'm developing currently a LiveCD for hot/cold

Re: [Bitcoin-development] Finite monetary supply for Bitcoin

2014-04-01 Thread Matt Corallo
I disagree with this proposal both in spirit and in practice. We all know satoshi was the best programmer like no one ever was. Clearly he intended this monetary supply from the beginning, who are we but mere mortals to go against satoshi's will? Also, should we really do this with a soft fork

Re: [Bitcoin-development] Finite monetary supply for Bitcoin

2014-04-01 Thread Matt Corallo
I move to reclaim bip 42 as reserved for a bip containing either a reference to musical dolphins or towels in the name. Matt On April 1, 2014 5:47:34 PM EDT, Gregory Maxwell gmaxw...@gmail.com wrote: On Tue, Apr 1, 2014 at 1:53 PM, Pieter Wuille pieter.wui...@gmail.com wrote: In case there are

Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?

2013-12-31 Thread Matt Corallo
We already have a wonderful system for secure updating - gitian-downloader. We just neither use it not bother making actual gitian releases so anyone can use it to verify signatures of downloads. Jeremy Spilman jer...@taplink.co wrote: I didn't know about the dedicated server meltdown, it

Re: [Bitcoin-development] Looking for GREAT C++ developer for exciting opportunity in bitcoin space

2013-12-29 Thread Matt Corallo
I'm not sure where you got the idea that Bitcoin-development was ideal for hiring scamcoin developers, but it's not. Most of the people on this list are smart enough to realize posts like this are dumb ideas backed by greedy entrepreneurs who don't understand the system they're trying to

Re: [Bitcoin-development] Bitcoin difficulty sanity check suggestion

2013-12-24 Thread Matt Corallo
An attacker with some small hashpower isolates you (as an individual) from the network by MITMing your network. You just switch the the attackers chain as if nothing happened because of the network rule that defines it as OK. Today, you will see that you're behind and warn the user. Was it really

Re: [Bitcoin-development] Who or what is /Satoshi:0.8.99/Gangnam Style:2.1/ ?

2013-11-21 Thread Matt Corallo
No, mine identifies as BitcoinJ, RelayNode, version string On 11/21/2013 10:27 AM, Jeff Garzik wrote: Is that Matt's relay, which has reduced validity checking? On Thu, Nov 21, 2013 at 8:48 AM, Mike Hearn m...@plan99.net wrote: I added some additional logging to my node and ran it for a

Re: [Bitcoin-development] [ANN] High-speed Bitcoin Relay Network

2013-11-13 Thread Matt Corallo
On 11/08/13 06:46, Mike Hearn wrote: I took a brief look at the code - it's looking very reasonable. You can replace any construct like try { Thread.sleep(1000); } catch (InterruptedException e) { throw new RuntimeException(e); } which is quite verbose, just with

Re: [Bitcoin-development] [ANN] High-speed Bitcoin Relay Network

2013-11-13 Thread Matt Corallo
In the short-term, maybe. Keep in mind that the code for tx relay is fairly different and the bandwidth for transaction relay on these nodes is already lower than it is for blocks (by design). That said, I'd like to look into doing tx-less block relays for transactions that peers already have to

[Bitcoin-development] [ANN] High-speed Bitcoin Relay Network

2013-11-05 Thread Matt Corallo
Recently, there has been a reasonable amount of discussion about the continued fragility of the public Bitcoin network on IRC and elsewhere (1). To this extent, I'm organizing a system of peering between nodes in the network by creating a system of high-speed relay nodes for miners and

Re: [Bitcoin-development] More appropriate XDG menu category for bitcoin-qt

2013-09-15 Thread Matt Corallo
(Finally) got around to this, sorry for the delay. 0.8.5 has the new category and pull request is at https://github.com/bitcoin/bitcoin/pull/2999 Matt On Fri, 2013-08-02 at 12:08 -0700, Kip Warner wrote: Hey list, Currently the bitcoin-qt application's XDG desktop integration on some

Re: [Bitcoin-development] limits of network hacking/netsplits (was: Discovery/addr packets)

2013-05-07 Thread Matt Corallo
I really beg to differ on this one. If you're an Ubuntu user who is behind only one distro (quantal) you're stuck on version 0.6.2 with no updates since 2012 (yes, that means on May 15th you'll be lost). For those still on Debian Squeeze (ie barely out of date), you get 0.3.24! Yes, 0.3.24

[Bitcoin-development] [RFC] Fees/Minimum Priorities based on Mempool and Memory-Limited Mempool

2013-04-24 Thread Matt Corallo
I hacked together a new min fee/prio calculator and memory-limited mempool a while back and figured Id post the code here to get some comments. Its more of a discussion-starter than a strict proposal and has a few obvious holes (hence posting here instead of pull-requesting). It works as such

Re: [Bitcoin-development] Integration testing for BitCoin

2013-04-05 Thread Matt Corallo
These tests are run on each pull requests and on each new commit to master. They arent very complete, but they do test a lot of block acceptance rules. https://github.com/TheBlueMatt/test-scripts Matt On Fri, 2013-04-05 at 12:24 -0500, Adam Ritter wrote: Hey guys, I just bought some

Re: [Bitcoin-development] Draft BIP for Bloom filtering

2013-01-16 Thread Matt Corallo
Actually, there is one more minor algorithmic change I would like to make to the way the hash function is computed really quick before it gets merged, I'll have that finished up by the end of today. Matt On Wed, 2013-01-16 at 11:43 +0100, Mike Hearn wrote: Matts latest code has been tested by

Re: [Bitcoin-development] Draft BIP for Bloom filtering

2013-01-10 Thread Matt Corallo
On Thu, 2013-01-10 at 16:21 +0100, Mike Hearn wrote: Here's a quick update on where we're up to. Thanks to Matts excellent work, I was able to test his bitcoinj and bitcoin-qt work together today. There are a few minor tweaks needed, but I feel like we're maybe a week away from having all

Re: [Bitcoin-development] Draft BIP for Bloom filtering

2012-11-21 Thread Matt Corallo
On Wed, 2012-11-21 at 16:15 +0100, Pieter Wuille wrote: On Wed, Oct 24, 2012 at 05:56:07PM +0200, Mike Hearn wrote: I've written a draft BIP describing the bloom filtering protocol extension developed by myself and Matt. https://en.bitcoin.it/wiki/BIP_0037 Two comments I made on the

Re: [Bitcoin-development] Draft BIP for Bloom filtering

2012-10-24 Thread Matt Corallo
On Wed, 2012-10-24 at 14:54 -0400, Gavin Andresen wrote: RE: sharing parts of the merkle branches when returning a 'merkleblock' : I think I agree that complicating the BIP for what should be a very rare case (more than a handful of transactions in a block match the transactions in your

Re: [Bitcoin-development] Bitcoin Testing Project

2012-09-25 Thread Matt Corallo
Although Jenkins may not be the best system, we already have jenkins and pull-tester (which is a dumb python script I wrote to test all incoming pull requests from github). They both run the same set of scripts, namely those at https://github.com/TheBlueMatt/test-scripts (its pretty basic right

Re: [Bitcoin-development] Segmented Block Relaying BIP draft.

2012-09-10 Thread Matt Corallo
I actually implemented parts of the header+ vtx stuff in a branch with my bloom filter stuff, you can see it here: https://github.com/TheBlueMatt/bitcoin/commits/bloom%2Brelayblock Its pretty stupid and would be pretty easy to DoS/get it stuck/etc, but in theory it works. I don't see much reason

Re: [Bitcoin-development] Segmented Block Relaying BIP draft.

2012-09-10 Thread Matt Corallo
It seems to me the whole idea of segmenting blocks would add very little (to nothing) with any sane block size. Sure, if a block were to be 10GB, it may make sense. However, even in that case, it would be easier to relay a list of tx hashes (which may be a bit expensive) and txes separately

[Bitcoin-development] Warning to rawtx creators: bug in SIGHASH_SINGLE

2012-08-20 Thread Matt Corallo
If you are playing around with the current rawtx API, be careful using SIGHASH_SINGLE: When parsing a transaction input, which uses a SIGHASH_SINGLE signature, and the given input's index is = the total number of outputs in the current transaction, bitcoind doesn't sign anything useful, it signs

[Bitcoin-development] Bloom Filter Implementation

2012-08-14 Thread Matt Corallo
I spend some time implementing some of the changes discussed in the previous thread New P2P commands for diagnostics, SPV clients, and wanted to field comments before I write up a BIP. I have implemented a simple bloom filter that works on transactions as well as a new block relay type which

Re: [Bitcoin-development] script tests - invalid script in script_valid.json?

2012-07-31 Thread Matt Corallo
On Sun, 2012-07-29 at 20:52 -0400, Gavin Andresen wrote: Is there interest to port more tests (P2SH, checksig, checkmultisig, block verification, maybe even DoS rules) into data-driven format? It might be something that I'd like to help with if pull requests in that direction are welcome.

Re: [Bitcoin-development] Coinbase script parse failures

2012-07-23 Thread Matt Corallo
I mentioned this on IRC a week or so ago, noticing that though they are not executed and required to be well-formed, we still count any sigops that appear in them (which I guessed may be an interesting attack if you could get a miner to put a byte in there that is the equivalent of OP_CHECKSIG

Re: [Bitcoin-development] New P2P commands for diagnostics, SPV clients

2012-07-23 Thread Matt Corallo
On Mon, 2012-07-23 at 09:54 +0200, Andreas Petersson wrote: Some concerns regarding Bloom Filters. I talked with Stefan Thomas on the Hackathon Berlin about this. I tried to follow the discussion closely but i have not taken a look at the code yet (is there already an implementation?) so

Re: [Bitcoin-development] New P2P commands for diagnostics, SPV clients

2012-06-15 Thread Matt Corallo
On Thu, 2012-06-14 at 13:52 +0200, Mike Hearn wrote: filterinit(false positive rate, number of elements): initialize filterload(data): input a serialized bloom filter table metadata and data. Why not combine these two? I believe its because it allows the node which will have to use the

Re: [Bitcoin-development] New P2P commands for diagnostics, SPV clients

2012-06-15 Thread Matt Corallo
On Fri, 2012-06-15 at 15:23 +0200, Mike Hearn wrote: Why not combine these two? I believe its because it allows the node which will have to use the bloom filter to scan transactions to chose how much effort it wants to put into each transaction on behalf of the SPV client. If that's

Re: [Bitcoin-development] New P2P commands for diagnostics, SPV clients

2012-06-15 Thread Matt Corallo
On Fri, 2012-06-15 at 15:43 +0200, Mike Hearn wrote: Yes, the format is something that must be hashed out (no pun intended). Need input from potential users about what information they might need. Matts point that a branch-per-transaction may duplicate data is well made, that said, I

Re: [Bitcoin-development] Near-term scalability

2012-06-15 Thread Matt Corallo
On Fri, 2012-06-15 at 15:34 +0200, Mike Hearn wrote: The idea can be more generalized in that there are many cases where the generator of a transaction doesn't care about confirmation times, and would really be willing to make their transaction lower priority than other 0-fee transactions.

Re: [Bitcoin-development] New P2P commands for diagnostics, SPV clients

2012-06-15 Thread Matt Corallo
On Fri, 2012-06-15 at 11:32 -0400, Jeff Garzik wrote: As for full nodes... I like the organic growth and random nature of the mempools. On the fence, WRT full node mempool sync at startup. I dont particularly care either way, but I have a feeling miners will really want that so that they can

Re: [Bitcoin-development] Adding callback hooks to the satoshi client

2012-03-21 Thread Matt Corallo
I spent some time changing the internal bitcoin code to use callback hooks, but its far from complete (or even really usable from anything other than the code in the satoshi client itself, it doesnt even have any deregister methods!). As it sits now, it is likely to get more eyeballs and merged

Re: [Bitcoin-development] Adding a pong message

2012-03-13 Thread Matt Corallo
On Tue, 2012-03-13 at 14:45 -0400, Luke-Jr wrote: On Tuesday, March 13, 2012 2:06:38 PM Mike Hearn wrote: https://github.com/bitcoin/bitcoin/pull/932 adds a pong message that echoes back a 64 bit nonce contained in the ping, if the protocol version is new enough. The goal of this is to

Re: [Bitcoin-development] BIP 20 Rejected, process for BIP 21N

2012-02-04 Thread Matt Corallo
I changed the description of the message parameter to be a bit more descriptive, however, I dont want to change the name of the parameter because some clients have already implemented that and I really prefer to make as minor of changes as possible to this BIP even if it is officially only a

Re: [Bitcoin-development] BIP 20 Rejected, process for BIP 21N

2012-01-31 Thread Matt Corallo
On Tue, 2012-01-31 at 06:27 -0800, Amir Taaki wrote: BIP 20 really has no support among implementations such as Bitcoin-Qt, Electrum, MultiBit or Bitcoin-JS. As the most active and visible user facing GUI projects (all with some form of URI Scheme), their opinion carries the most weight. To

Re: [Bitcoin-development] BIP 20 Rejected, process for BIP 21N

2012-01-31 Thread Matt Corallo
implementation). Matt On Tue, 2012-01-31 at 11:04 -0500, Matt Corallo wrote: On Tue, 2012-01-31 at 06:27 -0800, Amir Taaki wrote: BIP 20 really has no support among implementations such as Bitcoin-Qt, Electrum, MultiBit or Bitcoin-JS. As the most active and visible user facing GUI projects (all

Re: [Bitcoin-development] BIP 20 Rejected, process for BIP 21N

2012-01-31 Thread Matt Corallo
(to avoid any localization concerns). Matt On Tue, 2012-01-31 at 20:02 +0100, Wladimir wrote: On Tue, Jan 31, 2012 at 7:22 PM, Matt Corallo bitcoin-l...@bluematt.me wrote: All that said, I dont think its an ideal solution, depending on the names of variables

Re: [Bitcoin-development] Meeting 21:00 UTC #bitcoin-dev Freenode IRC

2012-01-02 Thread Matt Corallo
Because many made the mistake and it isnt specified in this email, this meeting is tomorrow (not 30 minutes ago). On Mon, 2012-01-02 at 08:04 -0800, Amir Taaki wrote: This meeting is to discuss the new OP_EVAL changes coming to bitcoin. A good summary of the past discussion so far by justmoon

Re: [Bitcoin-development] upnp isnt working

2011-12-30 Thread Matt Corallo
On Fri, 2011-12-30 at 00:57 -0800, Amir Taaki wrote: hey, so sipa/gmaxwell proposed on irc that maybe upnp is not working anymore but there isnt any way to test. well i made an alternate chain, and ran the daemon on my vps. sometimes it accepts connections, sometimes not. It's all very

Re: [Bitcoin-development] [BIP 15] Aliases

2011-12-15 Thread Matt Corallo
On Thu, 2011-12-15 at 13:59 -0600, theymos wrote: Bitcoin already has code and a protocol for transactions to IP addresses. Why not reuse that for dynamic address lookup? Just a few changes are necessary to enable complete u...@server.com handling: I'm not against this, but I think its way

Re: [Bitcoin-development] 0.4rc1 known bugs

2011-09-03 Thread Matt Corallo
On Sat, 2011-09-03 at 20:13 -0400, Gavin Andresen wrote: Quick status update on 0.4; I probably won't have time to tackle these properly before Tuesday: + sipa found what looks like a deadlock between the addr-handling and IRC-join-handling code. + UukGoblin reports a deadlock problem on a