* [Bitcoin-development] 0.3.24 @ 2011-07-01 0:07 Matt Corallo 2011-07-01 2:07 ` Gregory Maxwell 2011-07-01 8:00 ` Pieter Wuille 0 siblings, 2 replies; 26+ messages in thread From: Matt Corallo @ 2011-07-01 0:07 UTC (permalink / raw) To: bitcoin-development [-- 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 --] ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [Bitcoin-development] 0.3.24 2011-07-01 0:07 [Bitcoin-development] 0.3.24 Matt Corallo @ 2011-07-01 2:07 ` Gregory Maxwell 2011-07-01 2:44 ` Douglas Huff 2011-07-01 12:41 ` Douglas Huff 2011-07-01 8:00 ` Pieter Wuille 1 sibling, 2 replies; 26+ messages in thread From: Gregory Maxwell @ 2011-07-01 2:07 UTC (permalink / raw) To: Matt Corallo; +Cc: bitcoin-development 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. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [Bitcoin-development] 0.3.24 2011-07-01 2:07 ` Gregory Maxwell @ 2011-07-01 2:44 ` Douglas Huff 2011-07-01 12:41 ` Douglas Huff 1 sibling, 0 replies; 26+ messages in thread From: Douglas Huff @ 2011-07-01 2:44 UTC (permalink / raw) To: Gregory Maxwell, Matt Corallo; +Cc: bitcoin-development -----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----- ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [Bitcoin-development] 0.3.24 2011-07-01 2:07 ` Gregory Maxwell 2011-07-01 2:44 ` Douglas Huff @ 2011-07-01 12:41 ` Douglas Huff 1 sibling, 0 replies; 26+ messages in thread From: Douglas Huff @ 2011-07-01 12:41 UTC (permalink / raw) To: Gregory Maxwell, Matt Corallo; +Cc: bitcoin-development -----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----- ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [Bitcoin-development] 0.3.24 2011-07-01 0:07 [Bitcoin-development] 0.3.24 Matt Corallo 2011-07-01 2:07 ` Gregory Maxwell @ 2011-07-01 8:00 ` Pieter Wuille 2011-07-01 8:39 ` Jeff Garzik 1 sibling, 1 reply; 26+ messages in thread From: Pieter Wuille @ 2011-07-01 8:00 UTC (permalink / raw) To: Matt Corallo; +Cc: bitcoin-development 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [Bitcoin-development] 0.3.24 2011-07-01 8:00 ` Pieter Wuille @ 2011-07-01 8:39 ` Jeff Garzik 2011-07-01 12:31 ` Gavin Andresen 0 siblings, 1 reply; 26+ messages in thread From: Jeff Garzik @ 2011-07-01 8:39 UTC (permalink / raw) To: Pieter Wuille; +Cc: bitcoin-development 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [Bitcoin-development] 0.3.24 2011-07-01 8:39 ` Jeff Garzik @ 2011-07-01 12:31 ` Gavin Andresen 2011-07-01 12:40 ` Matt Corallo 0 siblings, 1 reply; 26+ messages in thread From: Gavin Andresen @ 2011-07-01 12:31 UTC (permalink / raw) To: bitcoin-development 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [Bitcoin-development] 0.3.24 2011-07-01 12:31 ` Gavin Andresen @ 2011-07-01 12:40 ` Matt Corallo 2011-07-01 15:06 ` Gavin Andresen 0 siblings, 1 reply; 26+ messages in thread From: Matt Corallo @ 2011-07-01 12:40 UTC (permalink / raw) To: bitcoin-development [-- 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 --] ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [Bitcoin-development] 0.3.24 2011-07-01 12:40 ` Matt Corallo @ 2011-07-01 15:06 ` Gavin Andresen 2011-07-01 16:35 ` jan 2011-07-01 23:42 ` Jeff Garzik 0 siblings, 2 replies; 26+ messages in thread From: Gavin Andresen @ 2011-07-01 15:06 UTC (permalink / raw) To: Matt Corallo; +Cc: bitcoin-development > 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [Bitcoin-development] 0.3.24 2011-07-01 15:06 ` Gavin Andresen @ 2011-07-01 16:35 ` jan 2011-07-01 16:47 ` Robert McKay ` (2 more replies) 2011-07-01 23:42 ` Jeff Garzik 1 sibling, 3 replies; 26+ messages in thread From: jan @ 2011-07-01 16:35 UTC (permalink / raw) To: bitcoin-development 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [Bitcoin-development] 0.3.24 2011-07-01 16:35 ` jan @ 2011-07-01 16:47 ` Robert McKay 2011-07-01 17:47 ` Douglas Huff 2011-07-01 17:59 ` Gregory Maxwell 2 siblings, 0 replies; 26+ messages in thread From: Robert McKay @ 2011-07-01 16:47 UTC (permalink / raw) To: jan; +Cc: bitcoin-development [-- 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 --] ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [Bitcoin-development] 0.3.24 2011-07-01 16:35 ` jan 2011-07-01 16:47 ` Robert McKay @ 2011-07-01 17:47 ` Douglas Huff 2011-07-01 17:50 ` Matt Corallo 2011-07-01 17:59 ` Gregory Maxwell 2 siblings, 1 reply; 26+ messages in thread From: Douglas Huff @ 2011-07-01 17:47 UTC (permalink / raw) To: jan; +Cc: bitcoin-development [-- 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 --] ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [Bitcoin-development] 0.3.24 2011-07-01 17:47 ` Douglas Huff @ 2011-07-01 17:50 ` Matt Corallo 2011-07-01 17:52 ` Douglas Huff 2011-07-01 22:03 ` Matt Corallo 0 siblings, 2 replies; 26+ messages in thread From: Matt Corallo @ 2011-07-01 17:50 UTC (permalink / raw) To: bitcoin-development [-- 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 --] ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [Bitcoin-development] 0.3.24 2011-07-01 17:50 ` Matt Corallo @ 2011-07-01 17:52 ` Douglas Huff 2011-07-01 22:03 ` Matt Corallo 1 sibling, 0 replies; 26+ messages in thread From: Douglas Huff @ 2011-07-01 17:52 UTC (permalink / raw) To: Matt Corallo; +Cc: bitcoin-development [-- 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 --] ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [Bitcoin-development] 0.3.24 2011-07-01 17:50 ` Matt Corallo 2011-07-01 17:52 ` Douglas Huff @ 2011-07-01 22:03 ` Matt Corallo 2011-07-01 22:07 ` Douglas Huff 1 sibling, 1 reply; 26+ messages in thread From: Matt Corallo @ 2011-07-01 22:03 UTC (permalink / raw) To: bitcoin-development [-- 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 --] ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [Bitcoin-development] 0.3.24 2011-07-01 22:03 ` Matt Corallo @ 2011-07-01 22:07 ` Douglas Huff 0 siblings, 0 replies; 26+ messages in thread From: Douglas Huff @ 2011-07-01 22:07 UTC (permalink / raw) To: Matt Corallo, bitcoin-development -----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----- ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [Bitcoin-development] 0.3.24 2011-07-01 16:35 ` jan 2011-07-01 16:47 ` Robert McKay 2011-07-01 17:47 ` Douglas Huff @ 2011-07-01 17:59 ` Gregory Maxwell 2 siblings, 0 replies; 26+ messages in thread From: Gregory Maxwell @ 2011-07-01 17:59 UTC (permalink / raw) To: jan; +Cc: bitcoin-development 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. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [Bitcoin-development] 0.3.24 2011-07-01 15:06 ` Gavin Andresen 2011-07-01 16:35 ` jan @ 2011-07-01 23:42 ` Jeff Garzik 2011-07-02 0:37 ` Jeff Garzik 1 sibling, 1 reply; 26+ messages in thread From: Jeff Garzik @ 2011-07-01 23:42 UTC (permalink / raw) To: Gavin Andresen; +Cc: bitcoin-development 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [Bitcoin-development] 0.3.24 2011-07-01 23:42 ` Jeff Garzik @ 2011-07-02 0:37 ` Jeff Garzik 2011-07-02 0:46 ` Matt Corallo 0 siblings, 1 reply; 26+ messages in thread From: Jeff Garzik @ 2011-07-02 0:37 UTC (permalink / raw) To: Gavin Andresen; +Cc: bitcoin-development 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [Bitcoin-development] 0.3.24 2011-07-02 0:37 ` Jeff Garzik @ 2011-07-02 0:46 ` Matt Corallo 2011-07-02 0:51 ` Gregory Maxwell 2011-07-02 1:05 ` Douglas Huff 0 siblings, 2 replies; 26+ messages in thread From: Matt Corallo @ 2011-07-02 0:46 UTC (permalink / raw) To: bitcoin-development [-- 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 --] ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [Bitcoin-development] 0.3.24 2011-07-02 0:46 ` Matt Corallo @ 2011-07-02 0:51 ` Gregory Maxwell 2011-07-02 1:05 ` Douglas Huff 1 sibling, 0 replies; 26+ messages in thread From: Gregory Maxwell @ 2011-07-02 0:51 UTC (permalink / raw) To: Matt Corallo; +Cc: bitcoin-development 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. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [Bitcoin-development] 0.3.24 2011-07-02 0:46 ` Matt Corallo 2011-07-02 0:51 ` Gregory Maxwell @ 2011-07-02 1:05 ` Douglas Huff 2011-07-02 1:12 ` Matt Corallo 1 sibling, 1 reply; 26+ messages in thread From: Douglas Huff @ 2011-07-02 1:05 UTC (permalink / raw) To: Matt Corallo, bitcoin-development -----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----- ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [Bitcoin-development] 0.3.24 2011-07-02 1:05 ` Douglas Huff @ 2011-07-02 1:12 ` Matt Corallo 2011-07-02 2:05 ` Gavin Andresen 0 siblings, 1 reply; 26+ messages in thread From: Matt Corallo @ 2011-07-02 1:12 UTC (permalink / raw) To: bitcoin-development [-- 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 --] ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [Bitcoin-development] 0.3.24 2011-07-02 1:12 ` Matt Corallo @ 2011-07-02 2:05 ` Gavin Andresen 2011-07-02 21:07 ` Jeff Garzik 0 siblings, 1 reply; 26+ messages in thread From: Gavin Andresen @ 2011-07-02 2:05 UTC (permalink / raw) To: bitcoin-development 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [Bitcoin-development] 0.3.24 2011-07-02 2:05 ` Gavin Andresen @ 2011-07-02 21:07 ` Jeff Garzik 2011-07-03 1:58 ` Matt Corallo 0 siblings, 1 reply; 26+ messages in thread From: Jeff Garzik @ 2011-07-02 21:07 UTC (permalink / raw) To: Gavin Andresen; +Cc: bitcoin-development 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [Bitcoin-development] 0.3.24 2011-07-02 21:07 ` Jeff Garzik @ 2011-07-03 1:58 ` Matt Corallo 0 siblings, 0 replies; 26+ messages in thread From: Matt Corallo @ 2011-07-03 1:58 UTC (permalink / raw) To: bitcoin-development [-- 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 --] ^ permalink raw reply [flat|nested] 26+ messages in thread
end of thread, other threads:[~2011-07-03 1:59 UTC | newest] Thread overview: 26+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2011-07-01 0:07 [Bitcoin-development] 0.3.24 Matt Corallo 2011-07-01 2:07 ` Gregory Maxwell 2011-07-01 2:44 ` Douglas Huff 2011-07-01 12:41 ` Douglas Huff 2011-07-01 8:00 ` Pieter Wuille 2011-07-01 8:39 ` Jeff Garzik 2011-07-01 12:31 ` Gavin Andresen 2011-07-01 12:40 ` Matt Corallo 2011-07-01 15:06 ` Gavin Andresen 2011-07-01 16:35 ` jan 2011-07-01 16:47 ` Robert McKay 2011-07-01 17:47 ` Douglas Huff 2011-07-01 17:50 ` Matt Corallo 2011-07-01 17:52 ` Douglas Huff 2011-07-01 22:03 ` Matt Corallo 2011-07-01 22:07 ` Douglas Huff 2011-07-01 17:59 ` Gregory Maxwell 2011-07-01 23:42 ` Jeff Garzik 2011-07-02 0:37 ` Jeff Garzik 2011-07-02 0:46 ` Matt Corallo 2011-07-02 0:51 ` Gregory Maxwell 2011-07-02 1:05 ` Douglas Huff 2011-07-02 1:12 ` Matt Corallo 2011-07-02 2:05 ` Gavin Andresen 2011-07-02 21:07 ` Jeff Garzik 2011-07-03 1:58 ` Matt Corallo
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox