Douglas Huff [ARCHIVE] on Nostr: 📅 Original date posted:2011-07-01 🗒️ Summary of this message: Bitcoin ...
📅 Original date posted:2011-07-01
🗒️ Summary of this message: Bitcoin developers discuss the need for a 0.3.24 release due to flood control limits and the urgency of getting more listening nodes.
📝 Original message:-----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 at gmail.com> wrote:
>On Thu, Jun 30, 2011 at 8:07 PM, Matt Corallo
><bitcoin-list at 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 at 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-----
🗒️ Summary of this message: Bitcoin developers discuss the need for a 0.3.24 release due to flood control limits and the urgency of getting more listening nodes.
📝 Original message:-----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 at gmail.com> wrote:
>On Thu, Jun 30, 2011 at 8:07 PM, Matt Corallo
><bitcoin-list at 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 at 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-----