<unnamed>

Public Key

npub1xpryrka5nmn2vq9uum4qfjcvkfdne95l3ug4sxhdkcnndu4uu6eqrc6eq0

Profile Code

nprofile1qqsrq3jpmw6fae4xqz7wd6syevxtykeuj60c7y2crtkmvfek727wdvsprpmhxue69uhhyetvv9ujuumwdae8gtnnda3kjctvqy28wumn8ghj7un9d3shjtnyv9kh2uewd9hsra7zha

Publishing to

relay.snort.social

relay.damus.io

nos.lol

Last Notes

2023-06-07 02:26:36 UTC

- reply

📅 Original date posted:2011-09-15
🗒️ Summary of this message: A disagreement over the effectiveness of the -maxreceivebuffer option to deal with bandwidth DoS attacks in Bitcoin.
📝 Original message:On Sep 15, 2011 11:20 AM, "Gavin Andresen" <gavinandresen at gmail.com> wrote:
> I'm ignoring bandwidth DoS attacks-- we already have the
> -maxreceivebuffer option to deal with those.
I disagree with this comment. The way this is currently implemented is a mem
exhaustion dos in itself waiting to happen and does nothing to prevent
network flooding.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20110915/2706e88f/attachment.html>

2023-06-07 02:25:06 UTC

- reply

📅 Original date posted:2011-09-13
🗒️ Summary of this message: A professional warns against storing private keys on USB keys due to the difficulty of reliably deleting sensitive data.
📝 Original message:On Sep 13, 2011 11:40 AM, "Luke-Jr" <luke at dashjr.org> wrote:
> Once created, they must submit the
> transaction to a staff member with the proper authority to bring it to the
> offline transaction-signing wallet (on a USB key), where it is signed, and
> returned to this third wallet.
I agreed up to this point. Private keys should not be stored on nand. Please
look in to the data recovery clusterfuck nand creates when concerning
sensitive data.
It is close to impossible to reliably delete such data, moreso on usb keys
than ssd, short of absolute physical destruction and noone should be
recommending this. Ever.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20110913/b0a35ffa/attachment.html>

2023-06-07 02:17:51 UTC

- reply

📅 Original date posted:2011-08-24
🗒️ Summary of this message: Gavin Andresen requested open-source, patent-free, and thoroughly-tested code for DSA-key-splitting. A third-party solution was suggested for a more traditional escrow setup.
📝 Original message:On Aug 24, 2011 10:12 AM, "Gavin Andresen" <gavinandresen at gmail.com> wrote:
>
> If anybody has some open-source, patent-free, thoroughly-tested code
> that already does DSA-key-splitting, speak up please.
>
If the caveat of a trusted third party is acceptable and, as greg mentioned,
if there was a way to export unsigned transactions and then import/broadcast
after signing this becomes fairly trivial.
Shamir's + 3rd party to combine and sign means no protocol level changes.
Process could work something like this:
Parties agree to endpoint destination address and provide it to third party.
Third party generates key and provides shares to each party in the txn and
the resulting address to both as well.
Third party destroys (preferably, never stores) private key.
Sender sends to address.
Both parties after confirmation of reciept of goods or what have you provide
shares back to third party who uses the privkey to xfer inputs to the
previously agreed upon destination subtracting their fee.
This resembles more traditional escrow setups and relies on the trust of a
third party, which is not ideal, but would be fairly simple to implement
until the other proposals could be better investigated and implemented.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20110824/a6faa861/attachment.html>

2023-06-07 02:11:00 UTC

- reply

📅 Original date posted:2011-08-03
🗒️ Summary of this message: The Bitcoin network is experiencing connectivity issues due to a lack of connectable slots. Sorting nodes by version could help resolve the problem.
📝 Original message:There's a bigger problem here honestly. The p2p network is just starved for
connectable slots.
You can start up a bitcoind, on a host with sufficient connectivity, with
-maxconnections=512 and they will fill in <15 minutes.
As to why sort by version: <=3.23 has problems serving the blocks from the
last 2 months. It can take days to weeks to get the whole chain if you're
connecting to those nodes.
--
Douglas Huff
On Aug 3, 2011 9:18 AM, "Rick Wesson" <rick at support-intelligence.com> wrote:
> Starting from bitcoinj, I have plenty of ways to publish DNS. Why sort
them
> by version? Ordering from highest to lowest?
>
> how about publishing addresses under version.example.com if you version
has
> a perfrence?
>
> -rick
>
>
> On Wed, Aug 3, 2011 at 7:10 AM, Mike Hearn <mike at plan99.net> wrote:
>
>> There's no project currently :-)
>>
>> Starting from Matts code is probably the way to go. It's written in PHP.
>> Alternatively, you could write a Java app for it, as there are drop-in
DNS
>> serving libraries you could link with BitCoinJ+sqlite. It probably
wouldn't
>> be that hard. You'd want to sort nodes by version, how long they've been
>> observed to exist, the last polling time, etc.
>>
>> On Wed, Aug 3, 2011 at 4:00 PM, Rick Wesson <
rick at support-intelligence.com
>> > wrote:
>>
>>> Mike,
>>>
>>> I think I can contribute to your DNS seeding project. Could you help
>>> define long-lived peers?
>>>
>>> -rick
>>>
>>>
>>> On Wed, Aug 3, 2011 at 3:04 AM, Mike Hearn <mike at plan99.net> wrote:
>>>
>>>> This is expected to happen from time to time of course as it's
inherently
>>>> racy, but there are a *lot* of bad nodes appearing in the DNS seeds.
>>>>
>>>> $ nmap -oG /tmp/x -p 8333 `dig +short bitseed.bitcoin.org.uk
>>>> dnsseed.bluematt.me bitseed.xf2.org`
>>>> ...
>>>> Nmap done: 48 IP addresses (25 hosts up) scanned in 9.80 seconds
>>>>
>>>> $ grep -c 'closed' /tmp/x
>>>> 6
>>>>
>>>> So of 48 IPs returned only 19 are actually usable. This is slowing down
>>>> peer bringup for the Android apps, which don't currently save the
addresses
>>>> of last-used peers (yes, I know we should fix this).
>>>>
>>>> I was talking to a friend a few days ago about Bitcoin, he seemed
>>>> interested. I'm hoping he might take on DNS seeding as a project. A
custom
>>>> DNS server that watches the network to find long-lived peers that run
the
>>>> latest version would be helpful for resolving this kind of thing.
>>>>
>>>>
>>>>
------------------------------------------------------------------------------
>>>> BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA
>>>> The must-attend event for mobile developers. Connect with experts.
>>>> Get tools for creating Super Apps. See the latest technologies.
>>>> Sessions, hands-on labs, demos & much more. Register early & save!
>>>> http://p.sf.net/sfu/rim-blackberry-1
>>>> _______________________________________________
>>>> Bitcoin-development mailing list
>>>> Bitcoin-development at lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>>
>>>>
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20110803/520f6d84/attachment.html>

2023-06-07 02:08:32 UTC

- reply

📅 Original date posted:2011-07-27
🗒️ Summary of this message: Discussion on implementing a separated-from-GitHub bounty system for Bitcoin development, with concerns raised about unpaid bounties and the need for escrow.
📝 Original message:Don't worry Luke will basically say that about anything not related to
a crazy base16 number representation system that no decent modern font
can display.
To contribute:
I think the separated-from-github bounty system would be great. BUT:
The bounties need to go into some form of escrow. There have been way
to many bounties that weren't paid since BTC broke the $1USD boundary.
On Wed, Jul 27, 2011 at 9:53 AM, John Smith <witchspace81 at gmail.com> wrote:
> On Wed, Jul 27, 2011 at 2:42 PM, Joel Joonatan Kaartinen <joel.kaartine
>
>> Although, if GitHub can't support the feature, it could be an argument
>> for setting up a bug tracker unrelated to GitHub.
>
> Well if signing up with github is such a big problem we could make a list of
> bounties on our own site with a trivial web application, and link from there
> to github issues (if neccesary) for a description. It really doesn't matter
> how it's implemented. I think it is useless to discuss technical details or
> GitHub TOS right now, let's discuss the merit of ideas...
>
> JS
>
>
> ------------------------------------------------------------------------------
> Got Input? Slashdot Needs You.
> Take our quick survey online. Come on, we don't ask for help often.
> Plus, you'll get a chance to win $100 to spend on ThinkGeek.
> http://p.sf.net/sfu/slashdot-survey
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

2023-06-07 02:01:49 UTC

- reply

📅 Original date posted:2011-07-02
🗒️ Summary of this message: Discussion on using cmake vs autotools for native build script generation. Autotools is more ubiquitous, but cmake is simpler and easier to debug.
📝 Original message:On Jul 2, 2011, at 12:31 PM, John Smith wrote:
> So, what about native build script generation for other platforms? autotools can only generate makefiles (with at least two intermediate code generation steps), which is quite limited.
This would be true if gmake didn't build/run basically everywhere; but, it does.
> IMO cmake is simple and elegant compared to the autotools monster. I don't see why it would be "just as bad". And I have quite some experience with both systems. Autotools is a hell to debug. cmake certainly isn't perfect, but at least it's a leap forward.
Don't get me wrong, I'm not defending autotools' design or implementation. It is; however, more ubiquitous and understood by a much wider audience.
> BTW for cmake there is "ccmake" which is even better than configure --help as it offers an interactive interface for configuration.
I would say that's actually a mark against cmake. If you need a gui to select build options because your cli doesn't have proper help output something is wrong.
If you're willing to setup and maintain a cmake build environment I wouldn't say it should be rejected outright. Speculating about it without an implementation to compare seems like a waste of time.
Especially when jaromil already has a mostly-functional autotools setup. It needs tweaking still and some changes to catch up and rebase, but it works. He also already did the tedious work to rearrange the source tree to make adding any auto-configuration tool for the build environment easy to drop in place. (Which is already merged.)
--
Douglas Huff
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 881 bytes
Desc: This is a digitally signed message part
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20110702/a842180a/attachment.sig>

2023-06-07 02:01:33 UTC

- reply

📅 Original date posted:2011-07-02
🗒️ Summary of this message: Cmake is not better than autotools, it just has a different syntax and requires an additional dependency. Autotools is still the preferred choice.
📝 Original message:Cmake is just as bad as autotools, just with a different syntax and more "buzz" behind it right this second. I don't see any advantage to it over autotools unless you're not familiar with either and even then I wouldn't really call it an advantage. It's just different.
It also requires a dependency that isn't installed by default anywhere, as already mentioned, and is less known outside of some obscure qt/kde circles and so finding people who are familiar with it and are willing to maintain it is more difficult.
Autotools is the devil you know.
You'll probably throw out that mysql and compiz have switched to it, but really, those projects aren't something that should be emulated by anyone. Ever.
On Jul 2, 2011, at 11:50 AM, John Smith wrote:
> On Sat, Jul 2, 2011 at 2:50 PM, Luke-Jr <luke at dashjr.org> wrote:
> On Saturday, July 02, 2011 3:29:04 AM John Smith wrote:
> > Why again did we choose for autotools as future build system instead of
> > cmake?
>
> I don't really care much either way, but cmake doesn't follow the standard
> build procedure (./configure && make && make install), though I imagine
> ./configure could be emulated with some script.
>
> It would change the sequence to
>
> cmake . && make && make install
>
> So a shell script named 'configure' that starts 'cmake .' is the most easy case :-) Probably it'd also need to pass through some command line args, for example --prefix.
>
> JS
>
> ------------------------------------------------------------------------------
> 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

2023-06-07 02:00:22 UTC

- reply

📅 Original date posted:2011-07-01
🗒️ Summary of this message: Discussion on the release of Bitcoin version 0.3.24, with debate over whether to cherry-pick specific fixes or release current upstream.
📝 Original message:-----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 at 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 at 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-----

2023-06-07 02:00:03 UTC

- reply

📅 Original date posted:2011-07-01
🗒️ Summary of this message: Bitcoin developers are requesting ACKs on UPnP by default on bitcoin and disabled by default on bitcoind, as well as ACKs on 0.3.24 release.
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Matt Corallo <bitcoin-list at 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-----

2023-06-07 01:59:57 UTC

- reply

📅 Original date posted:2011-07-01
🗒️ Summary of this message: Bitcoind is prebuilt in the daemon folder on download archives, but not on OSX. This was clarified in an email exchange.
📝 Original message: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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 881 bytes
Desc: This is a digitally signed message part
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20110701/26d588a7/attachment.sig>

2023-06-07 01:59:50 UTC

- reply

📅 Original date posted:2011-07-01
🗒️ Summary of this message: A discussion on whether to turn on UPnP by default in Bitcoin's GUI, with some in favor and others against due to security concerns.
📝 Original message:On Jul 1, 2011, at 11:35 AM, jan at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 881 bytes
Desc: This is a digitally signed message part
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20110701/945335ad/attachment.sig>

2023-06-07 01:59:25 UTC

- reply

📅 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-----

2023-06-07 01:59:22 UTC

- reply

📅 Original date posted:2011-06-30
🗒️ Summary of this message: Bitcoin developers are planning to release version 0.3.24 to fix flood control limits and enable UPnP by default. They also suggest updating the checkpoint.
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
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.
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-----

2023-06-07 01:21:46 UTC

- reply

📅 Original date posted:2011-06-17
🗒️ Summary of this message: Merge Qt code for better GUI improvements, as more people are willing to work on it than on wx code. No harm in merging if code is ready.
📝 Original message:Agreed. The sooner qt gets merged the sooner real GUI improvements will be
made.
On Jun 17, 2011 8:30 AM, "Luke-Jr" <luke at dashjr.org> wrote:
> On Friday, June 17, 2011 6:31:25 AM Pieter Wuille wrote:
>> The only disadvantage of another GUI is that the (necessary) cleanup of
>> RPC/GUI code will now need makes changes in 3 places instead of 2, but as
>> I understand it, there are much more people willing to work on Qt code
>> than on wx code?
>
> I'm not sure the Wallet protocol implementation needs to touch the GUI
code at
> all, except when porting the GUI to use it. Therefore, if the code is
already
> written, I don't see any harm in merging it.
>
>
------------------------------------------------------------------------------
> EditLive Enterprise is the world's most technically advanced content
> authoring tool. Experience the power of Track Changes, Inline Image
> Editing and ensure content is compliant with Accessibility Checking.
> http://p.sf.net/sfu/ephox-dev2dev
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20110617/0ec9e113/attachment.html>