[Bitcoin-development] 0.3.24

[Bitcoin-development] 0.3.24

[Matt Corallo]

[-- Attachment #1: Type: text/plain, Size: 1347 bytes --]

Due to the flood control limits becoming an issue again, it would appear
we need a 0.3.24 release.  The idea is to have sipa's flood limit fix
(https://github.com/sipa/bitcoin/commit/df94ed7ac0ed7bb3a96cf434ca3c64c4b475e37e), dnsseed on by default, and maybe UPnP enabled by default as well.

I just got a DNSSeed up with reliable hosting which dynamically fills
its hostname with random nodes known to be up and accepting connections
(and on port 8333 and on version 0.3.19 or higher) (dnsseed.bluematt.me)
and I hope others follow suit with
https://github.com/TheBlueMatt/dnsseed (its poorly done but works just
fine).  This was added to master in 44d16327. Since its no longer a
static list, I think its time to enable dnsseed by default (I have one
or two connections by the time the GUI opens when I use -dnsseed
-noirc).

Also, I think UPnP by default would be a good idea as it could increase
the percent of nodes which accept incoming connection (and other P2P
applications which depend on the ability to accept incoming connections
have it on by default as well, such as Skype).  Jgarzik has also
suggested this, and I really dont see much of a reason not to.

Also,
https://github.com/bitcoin/bitcoin/commit/3a3eabb57ae41dd2162ca8230423abf4a90ef644 should be included to fix the no-connections-up segfault.

Matt

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [Bitcoin-development] 0.3.24

[Gregory Maxwell]

On Thu, Jun 30, 2011 at 8:07 PM, Matt Corallo <bitcoin-list@bluematt.me> wrote:
> Due to the flood control limits becoming an issue again, it would appear
> we need a 0.3.24 release.  The idea is to have sipa's flood limit fix
> (https://github.com/sipa/bitcoin/commit/df94ed7ac0ed7bb3a96cf434ca3c64c4b475e37e), dnsseed on by default, and maybe UPnP enabled by default as well.

*Flood fix

I think this is important, slow bringups are problematic and I think
the flood disconnects have been contributing to network partitioning
(you'll disconnect nodes that have the full blockchain but keep ones
that don't), adding to the partitioning problems cause elsewhere.

I've been running it for a couple hours on a large public node which
was seeing frequent flood disconnects, and it seems to be working
fine. No more flood disconnects.

Syncing a local node to it (no a not terribly fast core) now takes
34.5 minutes (I new bringup on the same system a few days ago hadn't
synced in over an hour).

Increasing the nLimit in sipa's code from 500 to 5000 reduced the
syncup time for me by about 1.5 minutes, almost all of the speedup
being in the early blocks.  Since it has the 5MB limit now I don't see
much reason for a large per block limit.

*Dnsseed

I've been using this for a while, we need more dnsseed roots but I see
no reason not to turn it on now.

*UPNP

Lfnet now reports 32843.  Presumably there are more bitcoin users than
that, because not all use IRC. 32843*8 = 262744 listening sockets.
Meaning, assuming a nice equal distribution we need 2189 listening
nodes to support the network— but the real distribution will be
somewhat uneven due to bad luck and the /16 limit.

Matt has estimated that there are around 4000 stable listening nodes.

Linear extrapolation from the two day lfnet growth leave us running
out of sockets in a little more than a month. While it won't all break
if it runs out, since we don't strictly need 8 connections, it's still
not good.

I think getting more listening nodes is a somewhat urgent matter as a result.


I'd also like suggest updating the checkpoint in 0.3.24. Difficulty
has increased almost 17x since the highest one currently in there. A
rather large number of parties could mine pretty nice forks at 1/16th
the current difficulty for nodes that they've sibyled.

Re: [Bitcoin-development] 0.3.24

[Douglas Huff]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256



Gregory Maxwell <gmaxwell@gmail.com> wrote:

>On Thu, Jun 30, 2011 at 8:07 PM, Matt Corallo
><bitcoin-list@bluematt.me> wrote:
>> Due to the flood control limits becoming an issue again, it would
>appear
>> we need a 0.3.24 release.  The idea is to have sipa's flood limit fix
>>
>(https://github.com/sipa/bitcoin/commit/df94ed7ac0ed7bb3a96cf434ca3c64c4b475e37e),
>dnsseed on by default, and maybe UPnP enabled by default as well.
>
>*Flood fix
>
>I think this is important, slow bringups are problematic and I think
>the flood disconnects have been contributing to network partitioning
>(you'll disconnect nodes that have the full blockchain but keep ones
>that don't), adding to the partitioning problems cause elsewhere.
>
>I've been running it for a couple hours on a large public node which
>was seeing frequent flood disconnects, and it seems to be working
>fine. No more flood disconnects.

I can confirm similar results.


>I'd also like suggest updating the checkpoint in 0.3.24. Difficulty
>has increased almost 17x since the highest one currently in there. A
>rather large number of parties could mine pretty nice forks at 1/16th
>the current difficulty for nodes that they've sibyled.

It's about time for another checkpoint, I agree.
- --
Douglas Huff
-----BEGIN PGP SIGNATURE-----
Version: APG v1.0.8

iQIVAwUBTg00oEPHkQabDWHPAQhtIg/+KqgpNzu9pInI4w1QMl/PyGSEUrin6pHq
94H9UJRtx6kAPbyBDZ2M/DYTAk5logB0jZoZXg5tkYxY+DoGYC5FLYiLV9nfgIa9
oGEOgdSzaVZseINes0FMNcD5DjEmvvW0nDzJyraD7T11R8r+uATEtcPNN9g0aYSF
WCRWEKZSvf6o9k5sibmDGrWe/Zx9PV5Si59fqo1eglHUGG+9wLjP3Fv904HSQWD/
zJ+bMTNyddOi0vP23S5rQM4V94HG2wjgOVk804a/2qJlibXyJi0cYRQj/JIibOIt
KzXHqYAhJK5JcizUcKu3T8YM22ZE04nIqhxg7h8+5vaZHfHgMYjqGrYeEtqx6GUC
6oXKke2dP8bqdX+JkJ9Zrf5uz8ysPf6Rj+77dA1tYyFZc2CEb5wA0cnW5SSzqMe1
5q7saRda3P0RvTtWmJKLPyXbr7EqETKhr37E/lc7viLgQCroggQ4wVkUAj4rfjDZ
HeZtCfBg3U63oe6WPH1MkzuGPBOjdrSK9RlibFanPU/AL+sTYsf5cs+j8WTHa6WA
ee1k01Nke1Pa7ForvWcUXzzLPVk/ikEgmJrrTKcBNAEh5UKq7BveDX0fSw0kQmPO
XdWjlNfOfcObCVLRcJ7ev8H6fDQOFGxUXH3A98PCVtUx05aVoDVoRvdPAGN0kbTo
Xqa58ov1pQY=
=jKOB
-----END PGP SIGNATURE-----

Re: [Bitcoin-development] 0.3.24

[Pieter Wuille]

On Fri, Jul 01, 2011 at 02:07:18AM +0200, Matt Corallo wrote:
> Due to the flood control limits becoming an issue again, it would appear
> we need a 0.3.24 release.  The idea is to have sipa's flood limit fix
> (https://github.com/sipa/bitcoin/commit/df94ed7ac0ed7bb3a96cf434ca3c64c4b475e37e),

I've cleaned the commit up a bit, and created a pull request (#369) for it.

> dnsseed on by default, and maybe UPnP enabled by default as well.

> I just got a DNSSeed up with reliable hosting which dynamically fills
> its hostname with random nodes known to be up and accepting connections
> (and on port 8333 and on version 0.3.19 or higher) (dnsseed.bluematt.me)
> and I hope others follow suit with
> https://github.com/TheBlueMatt/dnsseed (its poorly done but works just
> fine).  This was added to master in 44d16327.

Nice, we definitely needed something like that. It wouldn't hurt to have multiple
people running such a seed, to prevent problems with occasional outages of DNS seeds,
once we move away from IRC entirely.

> Since its no longer a
> static list, I think its time to enable dnsseed by default (I have one
> or two connections by the time the GUI opens when I use -dnsseed
> -noirc).

Agree.

> Also, I think UPnP by default would be a good idea as it could increase
> the percent of nodes which accept incoming connection (and other P2P
> applications which depend on the ability to accept incoming connections
> have it on by default as well, such as Skype).  Jgarzik has also
> suggested this, and I really dont see much of a reason not to.

Given that there is no public outcry against these programs automatically
opening holes in firewalls, I assume it's safe for us to do the same.

It should be clearly explained in the release notes, though.

> Also,
> https://github.com/bitcoin/bitcoin/commit/3a3eabb57ae41dd2162ca8230423abf4a90ef644 should be included to fix the no-connections-up segfault.

Yes.

So: I'm in favor of an emergency release 0.3.24 with upnp default enabled,
dnsseed default enabled, block send limit, no-connect segfault bugfix.
Anything else?

-- 
Pieter

Re: [Bitcoin-development] 0.3.24

[Jeff Garzik]

On Fri, Jul 1, 2011 at 4:00 AM, Pieter Wuille <pieter.wuille@gmail.com> wrote:
> So: I'm in favor of an emergency release 0.3.24 with upnp default enabled,
> dnsseed default enabled, block send limit, no-connect segfault bugfix.
> Anything else?

No objections...  I could get out 0.3.24-rc1 post-sleep, presuming
this plan (or something like it) receives Holy Alpaca Pee.
-- 
Jeff Garzik
exMULTI, Inc.
jgarzik@exmulti.com

Re: [Bitcoin-development] 0.3.24

[Gavin Andresen]

dnsseed on, block send, segfault bugfix:  Agreed.

upnp: I think should be enabled on Windows/Mac, but remain
off-by-default on Linux.

I think adding another block-chain checkpoint is a good idea, too.

-- 
--
Gavin Andresen

Re: [Bitcoin-development] 0.3.24

[Matt Corallo]

[-- Attachment #1: Type: text/plain, Size: 406 bytes --]

On Fri, 2011-07-01 at 08:31 -0400, Gavin Andresen wrote:
> dnsseed on, block send, segfault bugfix:  Agreed.
> 
> upnp: I think should be enabled on Windows/Mac, but remain
> off-by-default on Linux.
Not sure about OS differentiation, seems...wrong?  Maybe disabled by
default on bitcoind but on by default on bitcoin?
> 
> I think adding another block-chain checkpoint is a good idea, too.
> 


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [Bitcoin-development] 0.3.24

[Douglas Huff]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Why off on Linux? If anything Linux has, historically, had the most testing of the miniupnpc library. So it's the most stable of the three.

Gregory Maxwell <gmaxwell@gmail.com> wrote:

>On Thu, Jun 30, 2011 at 8:07 PM, Matt Corallo
><bitcoin-list@bluematt.me> wrote:
>> Due to the flood control limits becoming an issue again, it would
>appear
>> we need a 0.3.24 release.  The idea is to have sipa's flood limit fix
>>
>(https://github.com/sipa/bitcoin/commit/df94ed7ac0ed7bb3a96cf434ca3c64c4b475e37e),
>dnsseed on by default, and maybe UPnP enabled by default as well.
>
>*Flood fix
>
>I think this is important, slow bringups are problematic and I think
>the flood disconnects have been contributing to network partitioning
>(you'll disconnect nodes that have the full blockchain but keep ones
>that don't), adding to the partitioning problems cause elsewhere.
>
>I've been running it for a couple hours on a large public node which
>was seeing frequent flood disconnects, and it seems to be working
>fine. No more flood disconnects.
>
>Syncing a local node to it (no a not terribly fast core) now takes
>34.5 minutes (I new bringup on the same system a few days ago hadn't
>synced in over an hour).
>
>Increasing the nLimit in sipa's code from 500 to 5000 reduced the
>syncup time for me by about 1.5 minutes, almost all of the speedup
>being in the early blocks.  Since it has the 5MB limit now I don't see
>much reason for a large per block limit.
>
>*Dnsseed
>
>I've been using this for a while, we need more dnsseed roots but I see
>no reason not to turn it on now.
>
>*UPNP
>
>Lfnet now reports 32843.  Presumably there are more bitcoin users than
>that, because not all use IRC. 32843*8 = 262744 listening sockets.
>Meaning, assuming a nice equal distribution we need 2189 listening
>nodes to support the network— but the real distribution will be
>somewhat uneven due to bad luck and the /16 limit.
>
>Matt has estimated that there are around 4000 stable listening nodes.
>
>Linear extrapolation from the two day lfnet growth leave us running
>out of sockets in a little more than a month. While it won't all break
>if it runs out, since we don't strictly need 8 connections, it's still
>not good.
>
>I think getting more listening nodes is a somewhat urgent matter as a
>result.
>
>
>I'd also like suggest updating the checkpoint in 0.3.24. Difficulty
>has increased almost 17x since the highest one currently in there. A
>rather large number of parties could mine pretty nice forks at 1/16th
>the current difficulty for nodes that they've sibyled.
>
>------------------------------------------------------------------------------
>All of the data generated in your IT infrastructure is seriously
>valuable.
>Why? It contains a definitive record of application performance,
>security
>threats, fraudulent activity, and more. Splunk takes this data and
>makes
>sense of it. IT sense. And common sense.
>http://p.sf.net/sfu/splunk-d2d-c2
>_______________________________________________
>Bitcoin-development mailing list
>Bitcoin-development@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/bitcoin-development

- --
Douglas Huff
-----BEGIN PGP SIGNATURE-----
Version: APG v1.0.8

iQIVAwUBTg3AXUPHkQabDWHPAQgI8RAAm4Csyc4jqLvJSpopwNKg20273Hk2dhpR
s0RHerh1TgFDLDeByhzZLX/GC5SzGpPRDllDDlKcXl+E7iS7xtsuB+KbNdjYERmn
eVm67PQnXZ0PaDUnUxywyl55dcM8WAhwAYZKxvY2IzJ5y6oV7aPSDt7+qtXGL5Tx
EWjtQU06EaLhQkamelEc0KhHWqA72S/1VIgITvW4KVOf8SKyfTkxADdvRJ2iEznZ
bemdm81nbNFuYjGng9pEzqs9CVkWthANFa8GhxV9yFiqhpT7rCZKktkmqazxw6le
zog0v0MDfd55eWH59dHd9FbdiU757VMZtjTew3EoKrvIOwj1XQ50aSwaxO2CeTfW
qfW/xrxo+6VJx2kpLC833rvek4nx/7a0YVSvtypp9R1td9wAPi14IT+wOZ6C6ofs
Cg1VtETit4cS4xeHNx5boMayBvqpS1tmYgrTdi0QjmlWa75RDLIIteWcS7Q6NP0r
G2BRm3sqTGo/7Vzhmqn3BWNe5lq21NCW9kMs8nzhntnalF13BdIN4ZMimmSmLb5O
PUzg9OUZ5qfW3rsbYgYXXritzcNSftva+H/sCLIIoFOJO16wpiQXoHjTSY0TwwIT
XrVAcP2sRQjfT5QzPfwHDBRcYDgpfGJs5+jXtPc1maac7AxRjZ0op7gXFb/3L/W4
mQFXl6I9hhg=
=qsYM
-----END PGP SIGNATURE-----

Re: [Bitcoin-development] 0.3.24

[Gavin Andresen]

> Not sure about OS differentiation, seems...wrong?  Maybe disabled by
> default on bitcoind but on by default on bitcoin?

OK.  I mis-remembered the poll:
   http://forum.bitcoin.org/index.php?topic=4392.0

On by default	                       8 (20%)
Off by default	                       22 (55%)
On by default in the GUI, off by default in bitcoind	 10 (25%)

-- 
--
Gavin Andresen

Re: [Bitcoin-development] 0.3.24

[jan]

On Fri, Jul 01, 2011 at 11:06:56AM -0400, Gavin Andresen wrote:
> > Not sure about OS differentiation, seems...wrong?  Maybe disabled by
> > default on bitcoind but on by default on bitcoin?
> 
> OK.  I mis-remembered the poll:
>    http://forum.bitcoin.org/index.php?topic=4392.0
> 
> On by default	                       8 (20%)
> Off by default	                       22 (55%)
> On by default in the GUI, off by default in bitcoind	 10 (25%)

I just voted as well and now - with some extra votes in the meantime -
it's 9 / 22 / 13. So exactly 50/50 between off (22) and some form of on
(9 + 13).

I'm in favor of turning it on by default in the GUI and leaving it off
in bitcoind.

I don't like UPnP much, I find it exemplifies exactly what is wrong with
computer security today: Convenience trumps security almost every time.

BUT: I don't think this is the moment to fight UPnP. It's the standard
mechanism in use today to let a computer behind a NAT accept incoming
connections. The user has already made the decision in regards to
convenience over security. By enabling UPnP (or by buying a product that
does this automatically) they are saying: I want it to "just work"
instead of having fine-grained but more complicated control.

Bitcoin is a P2P application and as such should use this
mechanism. I think it's pretty clear that participating in a P2P network
requires one to receive messages from other peers. At least no one seems
to be concerned that Bitcoin (by default!) listens on port 8333. So I
think it's only logical to extend that to work behind NATs as well.

Cheers!
Jan

Re: [Bitcoin-development] 0.3.24

[Robert McKay]

[-- Attachment #1: Type: text/plain, Size: 2167 bytes --]

On Fri, Jul 1, 2011 at 5:35 PM, <jan@uos.de> wrote:

> On Fri, Jul 01, 2011 at 11:06:56AM -0400, Gavin Andresen wrote:
> > > Not sure about OS differentiation, seems...wrong?  Maybe disabled by
> > > default on bitcoind but on by default on bitcoin?
> >
> > OK.  I mis-remembered the poll:
> >    http://forum.bitcoin.org/index.php?topic=4392.0
> >
> > On by default                        8 (20%)
> > Off by default                               22 (55%)
> > On by default in the GUI, off by default in bitcoind   10 (25%)
>
> I just voted as well and now - with some extra votes in the meantime -
> it's 9 / 22 / 13. So exactly 50/50 between off (22) and some form of on
> (9 + 13).
>
> I'm in favor of turning it on by default in the GUI and leaving it off
> in bitcoind.
>
> I don't like UPnP much, I find it exemplifies exactly what is wrong with
> computer security today: Convenience trumps security almost every time.
>
> BUT: I don't think this is the moment to fight UPnP. It's the standard
> mechanism in use today to let a computer behind a NAT accept incoming
> connections. The user has already made the decision in regards to
> convenience over security. By enabling UPnP (or by buying a product that
> does this automatically) they are saying: I want it to "just work"
> instead of having fine-grained but more complicated control.
>
> Bitcoin is a P2P application and as such should use this
> mechanism. I think it's pretty clear that participating in a P2P network
> requires one to receive messages from other peers. At least no one seems
> to be concerned that Bitcoin (by default!) listens on port 8333. So I
> think it's only logical to extend that to work behind NATs as well


If bitcoin listened on IPv6 that might help for alot of people. Windows 7
users get a teredo IPv6 address (unless they disable it) when behind NAT on
IPv4. Take any win7 box and put it on a typical NAT /DSL setup this is what
happens. I think this might actually work for more users than have UPNP
support on their DSL gateways. teredo IPs aren't that stable though (they
change frequently) and they might tend to flood the address cache with stale
addresses.

Rob

[-- Attachment #2: Type: text/html, Size: 2679 bytes --]

Re: [Bitcoin-development] 0.3.24

[Douglas Huff]

[-- Attachment #1: Type: text/plain, Size: 1322 bytes --]


On Jul 1, 2011, at 11:35 AM, jan@uos.de wrote:

> On Fri, Jul 01, 2011 at 11:06:56AM -0400, Gavin Andresen wrote:
>>> Not sure about OS differentiation, seems...wrong?  Maybe disabled by
>>> default on bitcoind but on by default on bitcoin?
>> 
>> OK.  I mis-remembered the poll:
>>   http://forum.bitcoin.org/index.php?topic=4392.0
>> 
>> On by default	                       8 (20%)
>> Off by default	                       22 (55%)
>> On by default in the GUI, off by default in bitcoind	 10 (25%)
> 
> I just voted as well and now - with some extra votes in the meantime -
> it's 9 / 22 / 13. So exactly 50/50 between off (22) and some form of on
> (9 + 13).
> 
> I'm in favor of turning it on by default in the GUI and leaving it off
> in bitcoind.
> 
> I don't like UPnP much, I find it exemplifies exactly what is wrong with
> computer security today: Convenience trumps security almost every time.

I don't think this should be a vote at all. Given Greg/Matt's numbers it is a necessity to ensure network stability over the next 90 days.

Also: the default will only apply to pre-built binaries, which bitcoind isn't one of, so for people running bitcoind this default doesn't matter at all. Just continue building without UPNP support as you're already doing.

-- 
Douglas Huff



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 881 bytes --]

Re: [Bitcoin-development] 0.3.24

[Matt Corallo]

[-- Attachment #1: Type: text/plain, Size: 1775 bytes --]

Totally agree it really shouldnt be a vote, in the end UPnP is bad for
an individual (more bandwidth usage, etc), but good for the network.
That means people will vote against it, but in the end someone has to
make the tough decision and turn it on.

Also, bitcoind is prebuilt in the daemon folder on the download archives
(though Im not sure about OSX)

Matt
On Fri, 2011-07-01 at 12:47 -0500, Douglas Huff wrote:
> On Jul 1, 2011, at 11:35 AM, jan@uos.de wrote:
> 
> > On Fri, Jul 01, 2011 at 11:06:56AM -0400, Gavin Andresen wrote:
> >>> Not sure about OS differentiation, seems...wrong?  Maybe disabled by
> >>> default on bitcoind but on by default on bitcoin?
> >> 
> >> OK.  I mis-remembered the poll:
> >>   http://forum.bitcoin.org/index.php?topic=4392.0
> >> 
> >> On by default	                       8 (20%)
> >> Off by default	                       22 (55%)
> >> On by default in the GUI, off by default in bitcoind	 10 (25%)
> > 
> > I just voted as well and now - with some extra votes in the meantime -
> > it's 9 / 22 / 13. So exactly 50/50 between off (22) and some form of on
> > (9 + 13).
> > 
> > I'm in favor of turning it on by default in the GUI and leaving it off
> > in bitcoind.
> > 
> > I don't like UPnP much, I find it exemplifies exactly what is wrong with
> > computer security today: Convenience trumps security almost every time.
> 
> I don't think this should be a vote at all. Given Greg/Matt's numbers it is a necessity to ensure network stability over the next 90 days.
> 
> Also: the default will only apply to pre-built binaries, which bitcoind isn't one of, so for people running bitcoind this default doesn't matter at all. Just continue building without UPNP support as you're already doing.


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [Bitcoin-development] 0.3.24

[Douglas Huff]

[-- Attachment #1: Type: text/plain, Size: 242 bytes --]

On Jul 1, 2011, at 12:50 PM, Matt Corallo wrote:

> Also, bitcoind is prebuilt in the daemon folder on the download archives
> (though Im not sure about OSX)

It's not on OS X so I assumed it wasn't anywhere else. My bad.

-- 
Douglas Huff



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 881 bytes --]

Re: [Bitcoin-development] 0.3.24

[Gregory Maxwell]

On Fri, Jul 1, 2011 at 12:35 PM,  <jan@uos.de> wrote:
> I just voted as well and now - with some extra votes in the meantime -
> it's 9 / 22 / 13. So exactly 50/50 between off (22) and some form of on
> (9 + 13).
>
> I'm in favor of turning it on by default in the GUI and leaving it off
> in bitcoind.
[snip]

I also don't like upnp, but I strongly support it being on because
leaving it off is not really an alternative.

IMO a forum poll is the wrong tool to use to decide if bitcoin keeps
working or not. ;) If the alternative were upnp vs some other way to
reasonably increase the number of listeners... e.g. "upnp always vs
upnp only if there has been no inbound connections in X minutes" that
would be another matter.

The bitcoin/bitcoind difference seems confusing to me, since when
someone complains about connectivity I'll have to remember to ask
which they are using... but enabling it for the gui is probably
sufficient in terms of network health.

But it'll probably happen anyways: I imagine most bitcoind users build
locally and don't bother installing the upnp library. I know I don't.

> At least no one seems
> to be concerned that Bitcoin (by default!) listens on port 8333. So I
> think it's only logical to extend that to work behind NATs as well.

Yea, listening at all is more interesting than upnp— though almost any
harm that listening can cause can also be caused by outgoing
connections since the protocol is symmetric.

(e.g. if you have an exploit, you don't need to connect to people, you
can just sibyl attack the network and exploit people who connect to
you— not quite as effective but I think enough that UPNP isn't a great
additional risk)

If you want to talk about worrying people about security:  The IRC
connections seriously set off alarm bells, especially when someone
looks and sees something indistinguishable from a botnet in IRC.  It's
been blocked by major ISP multiple times. So, until we get IRC
disabled nothing else is really all that significant from a security
hebe-geebies perspective.

On Fri, Jul 1, 2011 at 1:50 PM, Matt Corallo <bitcoin-list@bluematt.me> wrote:
> Totally agree it really shouldnt be a vote, in the end UPnP is bad for
> an individual (more bandwidth usage, etc), but good for the network.
> That means people will vote against it, but in the end someone has to
> make the tough decision and turn it on.

Well, users who don't like it can still disable listening— which is
healthier for the network right now than leaving listening on but not
actually working.

We can fix the incentive structure somewhat: We should give preference
in the form of preferred forwarding from/to to nodes that we've
connected to vs connected to us, potentially improved relay rules. Not
only does this given an incentives to listen (faster txn processing,
hearing about blocks earlier) but it also would reduce the
effectiveness of some DOS attacks.   Not something for 0.3.24,
however.

Re: [Bitcoin-development] 0.3.24

[Matt Corallo]

[-- Attachment #1: Type: text/plain, Size: 267 bytes --]

It would appear that we are all explaining why we agree...so, can we get
ACKs on UPnP by default on bitcoin and disabled by default on bitcoind
from everyone (specifically Gavin), as well as ACKs in general on 0.3.24
coming out with the originally listed things?

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [Bitcoin-development] 0.3.24

[Douglas Huff]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256



Matt Corallo <bitcoin-list@bluematt.me> wrote:

>It would appear that we are all explaining why we agree...so, can we
>get
>ACKs on UPnP by default on bitcoin and disabled by default on bitcoind
>from everyone (specifically Gavin), as well as ACKs in general on
>0.3.24
>coming out with the originally listed things?

All sounds good to me.
- --
Douglas Huff
-----BEGIN PGP SIGNATURE-----
Version: APG v1.0.8

iQIVAwUBTg5FPEPHkQabDWHPAQj1lg/+K+OfHZXNj/Rn4Ei+OmGjEywTZmOWiFVy
72MvaCNLkx1XW0G3ZJJsy211q5kssvDk4b0qdBraxjT2O7JE6rxEtPkkCaEv8zNv
ASpL1AdQ8PpOsYmot9Kl0XC3Hx4fmt89I18KwgEFqywDMssDQT1bWImE3xr628id
OHFDRxWv3PQ6unuD0gd0vj4L468il4tzeqnlCCG/bwZACdZAlgxoJDhdGgrpxZf7
zsUBhFwADqZ+KoQ9PJjonXHQj7g+UG2kdz/n3QGPXjAP0eLsqCLJrpJc5t3YEj8c
3bSfbKDGA1djKrXVDOhJ3laZGnIjCBbPuWhnPfoP91S23sFlHxIG9qynrfIF0yMU
pMVd9WF98yyjbUEiZon53YGKqBEhjKgx4VLMaYVqT1/kA1vpLDGV4hyqQPsWd3ML
LAp0kqBGzlosxX0PbcgQKX2gQ+P+9IjYeKb8XA9VbnLHJYdjZw+pSUz0RYYP3Fws
iOrypLgy79dEDyhafllQEAUDQi9XGhgBcpq1r683MD7JL3ip3e1x6LFDZQ9hA9Kk
MosjgFMMcCe3R+5bozbTE1Lrsz+ycl5hW4Zi5lszilP8duhvj/InLy/JEpS3qsGc
feb5hltQqIEcBItTe/XZCFwROdMjczAl/k65Gk1CSBgDCRda8et9img1t9Z9vGK/
qvwMoWzHcCc=
=78gQ
-----END PGP SIGNATURE-----

Re: [Bitcoin-development] 0.3.24

[Jeff Garzik]

OK I pulled a couple other minor bits.

The only remaining question, IMO, is whether or not we should pull

     Make UPnP default on Bitcoin but not on Bitcoind.
     https://github.com/bitcoin/bitcoin/pull/372

We are all kicking the can on this decision to Gavin I believe <grin>
I think the two strong arguments for upnp are
     - other p2p apps widely deployed, notably skype, use it
     - it will make a significant positive impact in the number of
       nodes supporting incoming connections

so my personal (read: not speaking for anyone else) opinion is to turn
on upnp for bitcoin _and_ bitcoind.

Other than that, here's what we're looking at for 0.3.24:

Dawid Spiechowicz (1):
      added polish translation

Doug Huff (1):
      Add OSX App bundle and correct build instructions to reflect reality.

Eric Hosmer (1):
      Updated Visual C++ makefile.

Gavin Andresen (1):
      Boost unit-testing framework.     make -f makefile.{unix,osx,mingw} test_b

Giel van Schijndel (2):
      rpc server: send '403 Forbidden' to rejected clients
      rpc: don't send 403 when using SSL to prevent DoS

Han Lin Yap (3):
      Double check translation and improved a translation string
      Update swedish translation
      Consistent Bitcoin example address

James Burkle (1):
      Edited init.cpp to include a check that -datadir exists

Jeff Garzik (4):
      FormatFullVersion: build fix related to recent translation improvement
      doc/release-process.txt: minor updates
      CWalletTx::GetAmounts(): pass NULL for CKeyStore*, rather than false     t
      Enable DNS seeding by default.

Joerie de Gram (1):
      Fix connection failure debug output

Jordan Lewis (8):
      Only include irc.h when needed
      Only include db.h when we have to.
      Only included rpc.h when necessary
      Only include net.h when we have to
      Only include init.h when we have to
      Only include strlcpy.h when we have to
      Remove some globally unused headers from headers.h
      Only include certain boost headers if necessary.

Matt Corallo (3):
      Update translations and remove obsolete translations.
      Add new DNSSeed dnsseed.bluematt.me.
      Only use dnsseeds and static seeds when not on testnet.

Pieter Wuille (5):
      move wallet code to separate file
      CWallet class
      Bugfixes walletclass
      Fix segfault when creating new wallet
      Limit response to getblocks to half of output buffer size

Shane Wegner (1):
      Fix missing includes needed for Boost 1.46.

Wladimir J. van der Laan (1):
      add GetTotalBlocksEstimate() function, move magic number to constant

-- 
Jeff Garzik
exMULTI, Inc.
jgarzik@exmulti.com

Re: [Bitcoin-development] 0.3.24

[Jeff Garzik]

Hum, it sounds like there was some misunderstanding, on my part at
least.  On IRC, people are talking about a cherry-picked release,
basically 0.3.23 + a couple specific fixes, rather than what is
current in upstream git.  I had assumed people meant releasing current
git + some specific fixes not yet in git.

Wearing the Release Mangler hat, cherry-picked branches have a few
disadvantages:

* you're throwing away the testing people have done on upstream git
* the new branch would have zero testing, as most people have been
testing 0.3.23 or upstream git
* it would be a dead-end branch, never touched after release.  bug
reports for such a release might not necessarily be applicable to last
version or current upstream or anywhere in between.

That is the convention wisdom, anyway.  But to paraphrase Pirates of
the Caribbean, release management rules aren't really rules, they're
more like... guidelines.  :)

The cherry-picked 0.3.24 release, according to IRC wisdom, wouldn't
have to worry about shipping CWallet, which needs a fix or two from
https://github.com/bitcoin/bitcoin/pull/358

I can live with, and roll a release for, either (a) 0.3.23 + select
fixes or (b) current upstream + pull #358.  My preference is (b), but
this is a community and Holy Alpaca decision, not just a call I will
make on my own.

Comments welcome...

-- 
Jeff Garzik
exMULTI, Inc.
jgarzik@exmulti.com

Re: [Bitcoin-development] 0.3.24

[Matt Corallo]

[-- Attachment #1: Type: text/plain, Size: 1915 bytes --]

Personally, I have little preference, sipa and gmaxwell fall on the side
of cherry-pick, but I think it might be good to do a broad-base test of
CWallet in 0.3.24 so potential bugs can be found in it before crypto and
0.4. In either case, I dont think we should spend too much time as this
is just a minor update release, just get it out the door so we can focus
on 0.4 (hopefully) without interruption.

Matt

On Fri, 2011-07-01 at 20:37 -0400, Jeff Garzik wrote:
> Hum, it sounds like there was some misunderstanding, on my part at
> least.  On IRC, people are talking about a cherry-picked release,
> basically 0.3.23 + a couple specific fixes, rather than what is
> current in upstream git.  I had assumed people meant releasing current
> git + some specific fixes not yet in git.
> 
> Wearing the Release Mangler hat, cherry-picked branches have a few
> disadvantages:
> 
> * you're throwing away the testing people have done on upstream git
> * the new branch would have zero testing, as most people have been
> testing 0.3.23 or upstream git
> * it would be a dead-end branch, never touched after release.  bug
> reports for such a release might not necessarily be applicable to last
> version or current upstream or anywhere in between.
> 
> That is the convention wisdom, anyway.  But to paraphrase Pirates of
> the Caribbean, release management rules aren't really rules, they're
> more like... guidelines.  :)
> 
> The cherry-picked 0.3.24 release, according to IRC wisdom, wouldn't
> have to worry about shipping CWallet, which needs a fix or two from
> https://github.com/bitcoin/bitcoin/pull/358
> 
> I can live with, and roll a release for, either (a) 0.3.23 + select
> fixes or (b) current upstream + pull #358.  My preference is (b), but
> this is a community and Holy Alpaca decision, not just a call I will
> make on my own.
> 
> Comments welcome...
> 


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [Bitcoin-development] 0.3.24

[Gregory Maxwell]

On Fri, Jul 1, 2011 at 8:46 PM, Matt Corallo <bitcoin-list@bluematt.me> wrote:
> Personally, I have little preference, sipa and gmaxwell fall on the side
> of cherry-pick, but I think it might be good to do a broad-base test of
> CWallet in 0.3.24 so potential bugs can be found in it before crypto and
> 0.4. In either case, I dont think we should spend too much time as this
> is just a minor update release, just get it out the door so we can focus
> on 0.4 (hopefully) without interruption.

The fact that this will -rc before full release softens my concern some.

I did a lot of semi-automated testing of cwallet+crypto (in the
encrypted and non-encrypted states) which I really don't want to redo
for cwallet alone.

Re: [Bitcoin-development] 0.3.24

[Douglas Huff]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

My only concern is: How well have the fixes in pull 358 been tested? Wasn't there an issue with the "" account found just last night?

Matt Corallo <bitcoin-list@bluematt.me> wrote:

>Personally, I have little preference, sipa and gmaxwell fall on the
>side
>of cherry-pick, but I think it might be good to do a broad-base test of
>CWallet in 0.3.24 so potential bugs can be found in it before crypto
>and
>0.4. In either case, I dont think we should spend too much time as this
>is just a minor update release, just get it out the door so we can
>focus
>on 0.4 (hopefully) without interruption.
>
>Matt
>
>On Fri, 2011-07-01 at 20:37 -0400, Jeff Garzik wrote:
>> Hum, it sounds like there was some misunderstanding, on my part at
>> least.  On IRC, people are talking about a cherry-picked release,
>> basically 0.3.23 + a couple specific fixes, rather than what is
>> current in upstream git.  I had assumed people meant releasing
>current
>> git + some specific fixes not yet in git.
>>
>> Wearing the Release Mangler hat, cherry-picked branches have a few
>> disadvantages:
>>
>> * you're throwing away the testing people have done on upstream git
>> * the new branch would have zero testing, as most people have been
>> testing 0.3.23 or upstream git
>> * it would be a dead-end branch, never touched after release.  bug
>> reports for such a release might not necessarily be applicable to
>last
>> version or current upstream or anywhere in between.
>>
>> That is the convention wisdom, anyway.  But to paraphrase Pirates of
>> the Caribbean, release management rules aren't really rules, they're
>> more like... guidelines.  :)
>>
>> The cherry-picked 0.3.24 release, according to IRC wisdom, wouldn't
>> have to worry about shipping CWallet, which needs a fix or two from
>> https://github.com/bitcoin/bitcoin/pull/358
>>
>> I can live with, and roll a release for, either (a) 0.3.23 + select
>> fixes or (b) current upstream + pull #358.  My preference is (b), but
>> this is a community and Holy Alpaca decision, not just a call I will
>> make on my own.
>>
>> Comments welcome...
>>
>
>------------------------------------------------------------------------------
>All of the data generated in your IT infrastructure is seriously
>valuable.
>Why? It contains a definitive record of application performance,
>security
>threats, fraudulent activity, and more. Splunk takes this data and
>makes
>sense of it. IT sense. And common sense.
>http://p.sf.net/sfu/splunk-d2d-c2_______________________________________________
>Bitcoin-development mailing list
>Bitcoin-development@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/bitcoin-development

- --
Douglas Huff
-----BEGIN PGP SIGNATURE-----
Version: APG v1.0.8

iQIVAwUBTg5uzkPHkQabDWHPAQhEDRAAikf9NX06CSjHOKRdErIEgixHgrcUJk85
GuUxmTIm305WNdxswVDwXhPAqi9PBr5jPYgowp4/UoiYprNHN/s9pPwqNyMI3Urn
SH7rXEA0yYuUU2b2VINY3cxHropu0cGH/EjXOXd+hDf6Dlf/lCsohz3BTcjUho4B
1esBTvhZngmEXaYSs5Hxd7CdbsJ8TVeib8aVGQN3GYc1H4I/MDFNpIsCVB0lAay2
93nczwFvkB/0KyU8vzua8atygdyGNTPWr0BOKvuJO39audokbZmpEREjLiqlIfxj
3MfcUZcOZ9or4Mq8Gq0ZLydpktKSKeZWpbpdzVEk/KQjz+zZhVZ+0jDj4FWIumcS
sd7AdPpQAVVb5uG4ZnALI9V1gmfdXB+yxo7nKdHPCSOTaYwcbHu2+FI7PVlVlh/4
IgcRtZT2p4xoNeuDU+QBinuCDsCPq14f0zPhIo7ZCzs/ruV3Y9BtBS7Ez8FnXIRp
yI06/AX9Bmw2DWBS5Jbu3u32osK1JWBdO9Hh1yVb+O1f9pqDPn7KYroqs4yAPZfx
iz6OaQWtG5Zm+UjoLQiVhPA2cU2Zm42LywtbW3sxm+pmwEx91MeTFCioqOdkz9RI
4NxkaWOlAcXlpr/WX5QoYVcio9GR9AnIeO6h6p4ov0PPI2WqgobrYQbtjdnqxZXi
Q12+wZuYiDo=
=STlK
-----END PGP SIGNATURE-----

Re: [Bitcoin-development] 0.3.24

[Matt Corallo]

[-- Attachment #1: Type: text/plain, Size: 272 bytes --]

> My only concern is: How well have the fixes in pull 358 been tested? Wasn't there an issue with the "" account found just last night?
No, a bug was found where it no longer opened ("Error: unable to load
wallet.dat") when the ~/.bitcoin folder was empty/not present.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [Bitcoin-development] 0.3.24

[Gavin Andresen]

I think we should move forwards, not sideways-- git tip + whatever we
need to fix bugs in current tip is my preference.

RE: upnp:  I say pull Matt's patch (bitcoin=upnp, bitcoind=!upnp).

-- 
--
Gavin Andresen

Re: [Bitcoin-development] 0.3.24

[Jeff Garzik]

On Fri, Jul 1, 2011 at 10:05 PM, Gavin Andresen <gavinandresen@gmail.com> wrote:
> I think we should move forwards, not sideways-- git tip + whatever we
> need to fix bugs in current tip is my preference.
>
> RE: upnp:  I say pull Matt's patch (bitcoin=upnp, bitcoind=!upnp).

Just tagged v0.3.24rc1...

-- 
Jeff Garzik
exMULTI, Inc.
jgarzik@exmulti.com

Re: [Bitcoin-development] 0.3.24

[Matt Corallo]

[-- Attachment #1: Type: text/plain, Size: 1208 bytes --]

Sorry this took so long, I got distracted...
Anyway 0.3.24 RC1 builds available at
http://dl.dropbox.com/u/29653426/Bitcoin%200.3.24%20RC1.tar.bz2
SHA1:
bb829e037aef86c5d9da384c0ff3c91ce8b11d5a  Bitcoin 0.3.24 RC1.tar.bz2

Builds gitian signed and email signed as always.

Notes:
Couple things need fixed up before release wrt build engineering:
http://forum.bitcoin.org/index.php?topic=24841.0 (still haven't had a
chance to dig up a copy of Win98 and spin up a VM to test any results of
this one).
Build on Ubuntu 8.04 instead of 10.04 so that oder libcs can work (and
do thorough testing of that resulting binary on newer libcs specifically
openSUSE 11.04, see http://forum.bitcoin.org/index.php?topic=21767.0 )

Sorry to hold up release on this crap that is still unfixed after
0.3.21...

Matt


On Sat, 2011-07-02 at 17:07 -0400, Jeff Garzik wrote:
> On Fri, Jul 1, 2011 at 10:05 PM, Gavin Andresen <gavinandresen@gmail.com> wrote:
> > I think we should move forwards, not sideways-- git tip + whatever we
> > need to fix bugs in current tip is my preference.
> >
> > RE: upnp:  I say pull Matt's patch (bitcoin=upnp, bitcoind=!upnp).
> 
> Just tagged v0.3.24rc1...
> 


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]