Douglas Huff [ARCHIVE]

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2011-06-17 to 2013-07-24
💬 Posted a total of 26 messages
📚 Participated in the following categories: Bitcoin-development
🔇 Please do not DM this user as it's used for archive purposes only.

Public Key

npub1xpryrka5nmn2vq9uum4qfjcvkfdne95l3ug4sxhdkcnndu4uu6eqrc6eq0

Profile Code

nprofile1qqsrq3jpmw6fae4xqz7wd6syevxtykeuj60c7y2crtkmvfek727wdvsu47dzl

Author Public Key

npub1xpryrka5nmn2vq9uum4qfjcvkfdne95l3ug4sxhdkcnndu4uu6eqrc6eq0

Show more details

Last Notes

2023-06-07 15:05:08

- reply

📅 Original date posted:2013-07-23
📝 Original message:Honestly, until I read the quoted part of your response, I actually wasn't in favor of this whole thing since in general the types of issues being mentioned are, in large part, the types of issues that maintainers deal with all the time.
On Jul 23, 2013, at 3:02 PM, Scott Howard <showard314 at gmail.com> wrote:
> Response: Is there a way to "certify" the Debian libraries? Debian
> bitcoind/bitcoin-qt runs the compile test during all architectures.
> MIPS has been failing recently, but no one has looked into it yet.
> Perhaps it's not worth developers efforts yet, but at some point the
> technology should reach a point it can be redistributed.
The fact that you're even trying to package and/or at some point have packaged and shipped big endian binaries is straight up *NEGLIGENT.*
Stop that. Now. It won't work.
Thanks for showing that this *is* necessary, I guess.

2023-06-07 02:37:50

- reply

📅 Original date posted:2011-11-04
🗒️ Summary of this message: Bitcoin-0.5.0rc2-linux.tar.gz was removed due to deployment issues, but a release candidate 3 is expected once Mac and Linux issues are fixed.
📝 Original message:What's wrong with the mac build? I just built on 10.7 without any issues.
--
Douglas Huff
On Nov 4, 2011, at 4:29 PM, Gavin Andresen wrote:
> If you wonder where the bitcoin-0.5.0rc2-linux.tar.gz went...
>
> I removed it because it is not sane (we need to teach the Qt build to
> statically link dependencies).
>
> Once the Mac and Linux deployment issues are fixed, expect a release
> candidate 3...
>
> --
> --
> Gavin Andresen
>
> ------------------------------------------------------------------------------
> RSA(R) Conference 2012
> Save $700 by Nov 18
> Register now
> http://p.sf.net/sfu/rsa-sfdev2dev1
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20111104/61362829/attachment.sig>

2023-06-07 02:31:53

- reply

📅 Original date posted:2011-10-05
🗒️ Summary of this message: A bad update caused issues with MacPorts boost packages. Users should install the newer 1.46 versions to fix the problem.
📝 Original message:Bad update. Macports has a couple of boost packages. Install the newer 1.46
ones.
--
Douglas Huff
On Oct 5, 2011 1:43 PM, "Gavin Andresen" <gavinandresen at gmail.com> wrote:
> I updated src/makefile.osx and doc/build-osx.txt today, assuming that
> the MacPorts versions of dependencies will be used and the -mt boost
> libraries will be used.
>
> I also modified makefile.unix and makefile.osx to auto-build
> dependencies using gcc's -MMD option.
>
> --
> --
> Gavin Andresen
>
>
------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2dcopy1
> _______________________________________________
> 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/20111005/7620b7df/attachment.html>

2023-06-07 02:27:01

- reply

📅 Original date posted:2011-09-15
🗒️ Summary of this message: A discussion about a potential mem exhaustion DoS attack in the p2p network code of Bitcoin, with no patch submitted yet.
📝 Original message:On Sep 15, 2011, at 1:17 PM, Gavin Andresen wrote:
>> 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.
>
> Have you submitted a patch to fix it?
No, it requires the entirety of the p2p network code be reworked and large patches aren't accepted.
No reason to take that off list, it's an issue that's been acknowledged on irc numerous times and is in the public channel logs.
--
Douglas Huff
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20110915/1aa29047/attachment.sig>

2023-06-07 02:26:36

- 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

- 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:18:48

- reply

📅 Original date posted:2011-08-24
🗒️ Summary of this message: Discussion on adding an RSA-like scheme for m-out-of-n signatures to Bitcoin. However, it does not solve the issue of malware on a PC. Proposed solution is to provide tools for offline wallets.
📝 Original message:On Aug 24, 2011 3:29 PM, "Gregory Maxwell" <gmaxwell at gmail.com> wrote:
>
> On Wed, Aug 24, 2011 at 3:05 PM, Christian Decker
> <decker.christian at gmail.com> wrote:
> > we could add an rsa-like scheme which allows m-out-of-n signatures. It
works
> > by distributing shares of the key which are points on a curve having the
> > actual key as 0-value. It does not require special length for the key so
if
> > ecdsa allows something similar there need not be anything changed.
>
> This works fine for ECC. But it requires that the composite key
> signer has simultaneous access to all the key-parts, so it doesn't
> solve the "my PC has malware" problem.
I don't think anything simple enough to actually be used by people in
general does. Same concept as what I proposed earlier before nanotube gave
me the context for Gavin's intent on irc.
Now that I'm understanding the use case I really think the best way to go
about this initially is like you said earlier.
Provide methods to export/import unsigned txns, provide methods to run the
GUI in a way that can track your own addresses with only pubkeys available
to the client, provide methods to sign and import/export/broadcast signed
txns.
With these tools offline wallets become feasible. Combined with wallet
crypto I think this is really the best that can be done to protect users
from themselves in a way that isn't too complicated for them to actually
use.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20110824/b20c936f/attachment.html>

2023-06-07 02:17:51

- 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:17:19

- reply

📅 Original date posted:2011-08-22
🗒️ Summary of this message: A discussion on daemonizing Bitcoin on boot and integrating it with standard coding and implementation paradigms on GNU/Linux platforms.
📝 Original message:I don't think you're actually familiar with either of those tools. A run
script is not much different than an init script?
Those who live in tonal caves shouldn't crap on themselves, or something.
On Aug 22, 2011 2:49 PM, "Luke-Jr" <luke at dashjr.org> wrote:
>
> On Monday, August 22, 2011 3:30:04 PM Douglas Huff wrote:
> > On Aug 22, 2011 2:26 PM, "Fred Concklin" <fconcklin at trucoin.com> wrote:
> > > I'm also interested in work to daemonize bitcoin on boot and
furthering
> > > work to bring bitcoin into general coding and implementation paradigms
> > > seen on GNU/Linux platforms.
> >
> > What? It already works fine in this regard using standard tools.
Especially
> > easy with daemontools/runit.
>
> He said standard *coding and implementation paradigms*. This has nothing
to do
> with integration with some non-standard "init replacement" that goes
against
> the whole design of Unix.
>
> What I understand this to mean, is properly abstracting the components
such
> that the node, wallet, and GUI can work together while being distinct
parts.
> In this sense, Fred, you may be interested in working on coming up with a
> standard for a https://en.bitcoin.it/wiki/Wallet_protocol
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20110822/cdad2324/attachment.html>

2023-06-07 02:17:13

- reply

📅 Original date posted:2011-08-22
🗒️ Summary of this message: A request to daemonize Bitcoin on boot and integrate it into GNU/Linux platforms was met with the response that it already works fine with standard tools.
📝 Original message:On Aug 22, 2011 2:26 PM, "Fred Concklin" <fconcklin at trucoin.com> wrote:
>
> I'm also interested in work to daemonize bitcoin on boot and furthering
> work to bring bitcoin into general coding and implementation paradigms
> seen on GNU/Linux platforms.
What? It already works fine in this regard using standard tools. Especially
easy with daemontools/runit.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20110822/0657ed70/attachment.html>

2023-06-07 02:11:00

- 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

- 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:06:20

- reply

📅 Original date posted:2011-07-17
🗒️ Summary of this message: Matt Corallo expressed his dislike for forums and called them a "cesspool" in an email to the Bitcoin mailing list.
📝 Original message:On Jul 17, 2011 5:46 AM, "Matt Corallo" <bitcoin-list at bluematt.me> wrote:
> Its not that people dislike the forums or dislike having the forums.
Speak for yourself. I think they're a cesspool.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20110717/21caa5db/attachment.html>

2023-06-07 02:06:07

- reply

📅 Original date posted:2011-07-16
🗒️ Summary of this message: Developers discuss the negative perception of Bitcoin forums and consider removing or replacing them to improve the project's image.
📝 Original message:On Jul 16, 2011, at 6:35 PM, Jeff Garzik wrote:
> On Sat, Jul 16, 2011 at 7:20 AM, John Smith <witchspace81 at gmail.com> wrote:
>> I know most of the people actively working on bitcoin (and active on this
>> list) ignore the forums, for good reason. But there's a lot of people
>> (everyone new?) that think the most active members of the forum have a major
>> influence on the project's direction. Which is making us as developers look
>> really bad. As if we're some political faction that wants to bring down
>> world governments and unleash a global anarchistic doomsday scenario.
>>
>> It really needs to be more down-to-earth. Ideally, the forum would simply be
>> a way to communicate with the *actual* users. For example, I use it for
>> soliciting user feedback on UI features.
>
> I agree completely.
>
> While the owner of the forums and bitcoin.org is Missing In Action and
> has not responded to emails in more than a week, we do have access to
> change the main www.bitcoin.org home page, to link to another forum.
>
> Or we could simply de-link the current forum, as a first step.
I say just kill the forum.bitcoin.org DNS entry along with it.
--
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/20110716/bad72c74/attachment.sig>

2023-06-07 02:04:18

- reply

📅 Original date posted:2011-07-10
🗒️ Summary of this message: Bitcoin's long build times are due to the use of boost, lack of module isolation, and implementations in header files, making adding new code difficult.
📝 Original message:On Jul 10, 2011, at 5:37 PM, Michael Offel wrote:
> 4. long build times
>
> It takes longer to build Bitcoin than building some of the million lines of code projects I'm working on. The reasons I did see so far is the use of boost, lack of module isolation and implementations in header files.
I've actually offered (on irc) to fix the latter a few times and been told that a pull removing implementations from the headers would not be merged so have not wasted the effort. (Because it's a rather large one.) Not only does this cause long build times it makes adding new code in the logically "right" places nearly impossible due to the build deps.
I agree with pretty much the entirety of your post and think all of it needs to be discussed further and addressed.
--
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/20110710/8da88a61/attachment.sig>

2023-06-07 02:03:01

- reply

📅 Original date posted:2011-07-04
🗒️ Summary of this message: Breaking unsafe backup mechanisms is desirable as import/export is planned to be merged, and backupwallet RPC command will still work.
📝 Original message:On Jul 4, 2011, at 1:23 PM, Gavin Andresen wrote:
> RE: breaking backup scripts: if they use the backupwallet RPC
> command, then they will Just Work.
I'd go a step further and say that, since import/export is planned to get merged at about the same time, intentionally breaking unsafe/badly designed backup mechanisms is actually desirable.
--
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/20110704/a85cd314/attachment.sig>

2023-06-07 02:01:49

- 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

- 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

- 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

- 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

- 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

- 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

- 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

- 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:57:43

- reply

📅 Original date posted:2011-06-19
🗒️ Summary of this message: A vulnerability in ClearCoin was reported and fixed, with the reporter noting that CSRFs were particularly nasty due to Google account auth.
📝 Original message:I know. Please do not take this as a personal attack. Blame MagicalTux's
irresponsible behaviour as of late. :(
On Jun 19, 2011 5:34 PM, "Gavin Andresen" <gavinandresen at gmail.com> wrote:
> Some of us take private disclosures of vulnerabilities very seriously.
>
> In any case, the ClearCoin CSRF vulnerability is fixed. Thank you for
> bringing it to my attention.
>
> On Sun, Jun 19, 2011 at 5:54 PM, Doug Huff <dhuff at jrbobdobbs.org> wrote:
>> In light of this decision I would like to report multiple CSRF
vulnerabilities in http://clearcoin.appspot.com .
>>
>> This set of CSRFs are particularly nasty since this is hosted on appspot
and uses google account auth. So long as you stay logged into your google
account you are vulnerable to this CSRF.
>
>
> --
> --
> Gavin Andresen
> http://clearcoin.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20110619/7d4ef3fb/attachment.html>

2023-06-07 01:57:02

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

- reply

- reply

- reply

- reply