John Smith [ARCHIVE] / is on Nostr

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

Last Notes

2023-06-07 02:34:24

- reply

📅 Original date posted:2011-10-23
🗒️ Summary of this message: A scope issue in the Bitcoin code was reported by Dean Gores, but it is in a disabled feature and may not be significant.
📝 Original message:FYI
It's in a disabled feature (replacement), so I'm not sure how important this
is, but it doesn't look good.
---------- Forwarded message ----------
From: Dean Gores <dmgores at gmail.com>
Date: Sun, Oct 23, 2011 at 11:15 AM
Subject: bitcoin scope issue in main.cpp
To: laanwj at gmail.com
You have "i" and "output" declared in the same scope in "main.cpp",
AcceptToMemoryPool. Below is the offending code.
for (int i = 0; i < vin.size(); i++)
{
COutPoint outpoint = vin[i].prevout;
if (!mapNextTx.count(outpoint) ||
mapNextTx[outpoint].ptx != ptxOld)
return false;
}
Cheers,
Dean Gores
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20111023/ef8e48b1/attachment.html>

2023-06-07 02:30:04

- reply

📅 Original date posted:2011-09-29
🗒️ Summary of this message: A proposal to simplify the internal reference miner by removing dependencies on cryptopp and calculating getwork "midstate" from the blockheader.
📝 Original message:Nils,
Sounds good. I'm also doubtful of depending on two crypto libraries when
OpenSSL does perfectly well.
However, losing compatibility with miners is not very nice. Is there really
not a way to compute midstate with OpenSSL?
JS
On Mon, Sep 26, 2011 at 7:42 PM, Nils Schneider <nils at nilsschneider.net>wrote:
> Hey,
>
> I'd like to simplify the internal reference miner and remove all
> dependencies on cryptopp (it's the only place we use cryptopp instead of
> OpenSSL).
>
> Unfortunately, cryptopp is also used to calculate getwork "midstate".
> This field is redundant and the miner could easily calculate it from the
> blockheader so I'd like to remove it.
>
> Any thoughts? Where should such a change should be announced so all
> miners can be upgraded?
>
>
> ------------------------------------------------------------------------------
> 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/20110929/5081cf92/attachment.html>

2023-06-07 02:23:32

- reply

📅 Original date posted:2011-09-08
🗒️ Summary of this message: The Bitcoin alert system is not a cause for concern as even if the private key was compromised, the worst that could happen is spam messages.
📝 Original message:There is a lot of complaining about this alert system, but I really don't
see the problem.
As others have already said, it's just a message. Even if someone managed to
compromise the private key, the most they could do is spam graffiti messages
or try phishing. There are much worse things that could happen to the
network (in which case an alert system could come in very handy). It's just
not worth worrying about.
JS
On Thu, Sep 8, 2011 at 4:20 PM, Pieter Wuille <pieter.wuille at gmail.com>wrote:
> On Thu, Sep 08, 2011 at 09:09:12AM -0700, David Perry wrote:
> > @Steve re "Who knows, it might be the only way we'll ever hear from
> Satoshi
> > again."
> >
> > That brings up a good point... Does anyone aside from Satoshi actually
> have
> > the ability to send such an alert? Should we at the very least change the
> > alert system to give such privileges to current devs and ensure that that
> if
> > the missing Mr. Satoshi has had his key compromised we don't see an
> > authoritative-looking alert come up from a malicious source?
>
> Yes, Satoshi transferred the key to Gavin when he "left". I agree we should
> keep it, btw. There have been suggestions before on this list to use the
> alert system to ask people to upgrade to recent versions of the client (eg.
> the disconnect issue 0.3.20-0.3.23 had). I feel there may come a moment
> when
> we really need to use it for that purpose.
>
> --
> Pieter
>
>
> ------------------------------------------------------------------------------
> Doing More with Less: The Next Generation Virtual Desktop
> What are the key obstacles that have prevented many mid-market businesses
> from deploying virtual desktops? How do next-generation virtual desktops
> provide companies an easier-to-deploy, easier-to-manage and more affordable
> virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/
> _______________________________________________
> 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/20110908/8fe4ee50/attachment.html>

2023-06-07 02:20:00

- reply

📅 Original date posted:2011-08-31
🗒️ Summary of this message: Luke-Jr asks how to set build options with qmake. You can put assignments on the command line, and these variables can be used for conditionally enabling/disabling libraries or other options in the .pro file.
📝 Original message:On Thu, Sep 1, 2011 at 2:13 AM, Luke-Jr <luke at dashjr.org> wrote:
> On Wednesday, August 31, 2011 10:20:48 AM John Smith wrote:
> > The project builds on Windows, MacOSX and Linux using qmake.
>
> How do you set build options with qmake?
>
You can put assignments on the commandline; for example,
qmake "CONFIG+=test" test.pro
Like in plain make, these variables can be used for conditionally
enabling/disabling libraries or other options in the .pro file.
http://doc.qt.nokia.com/latest/qmake-manual.html
(reminds me that I still need to add the USE_UPNP option)
Note that qmake is a pretty simple tool, optimized for conveniently building
Qt applications in a cross-platform way; it in no way compares to
cmake/autotools or another "full" build system. But it's enough for building
bitcoin-qt on the supported target architectures so that's good enough for
me... For "bitcoind" and "bitcoin-wx" you probably want to keep around the
makefile.
JS
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20110901/b7a21c59/attachment.html>

2023-06-07 02:19:54

- reply

📅 Original date posted:2011-08-31
🗒️ Summary of this message: Qt translations can be reused for Bitcoin Core, but files need to be converted from Wx's line-based format to Qt's XML-based format. Translations can be added later.
📝 Original message:Would it be possible to port some of the existing translations?
>
Well, the strings in the core can be reused one-on-one as the _ function is
mapped to the Qt translation function.
And some of the UI texts probably can be reused as well, at least for a
rough approximation.
The files will have to be converted, as Qt uses an XML-based format whereas
Wx uses a line-based one. Also, Qt translations have a "context"
(file/object) defined whereas in Wx the "msgid" is only the English text.
Nah, nothing that a bit of Python hacking can't solve.
Though IMHO its not a huge deal if qt is merged without all the
> translations as IMHO it should be merged soon and then not the default
> release GUI until its in tree for a bit (like one release) and some
> translations can be built up.
>
Exactly... if there is some time between Qt being merged and Wx being phased
out, translations can be added. The Qt translation tool (Qt Linguist) is
user friendly enough to be used by anyone.
>
> > So IMO, it is ready to be merged.
> IMHO it should be merged right after 0.4 is pushed.
>
Sounds fine with me,
JS
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20110901/e5fb7740/attachment.html>

2023-06-07 02:14:00

- reply

📅 Original date posted:2011-08-10
🗒️ Summary of this message: Gavin Andresen is against splitting off the "send commands to a running bitcoin" as it would force developers to tweak their code.
📝 Original message:On Wed, Aug 10, 2011 at 4:49 PM, Gavin Andresen <gavinandresen at gmail.com>wrote:
> RE: splitting off the "send commands to a running bitcoin" :
>
> I'm mildly against it. It would be less confusing for newbies, at the
> cost of forcing everybody who has already written backup scripts or
> other interact-with-running-bitcoin tools to tweak their code. The
> coding will be easy, but do you really want to spend the time to
> answer all the "I installed Bitcoin X.Y and now my backup script
> doesn't work" questions and modify the wiki pages and ...
>
As the project is still in "experimental" phase I suppose people can expect
changes like this? And the change is pretty much trivial, and it makes sense
for a future direction (UI<->Wallet in separate processes for security
concerns).
To be honest I feel a bit like every change that I (and I've also heard this
from others) propose is shot down, no matter how well formulated. This is
actively discouraging developers from joining this project.
Of course it makes sense to be a careful, but the project is not on life
support is it? Satoshi did a great job making the program, but his work was
not perfect, and it makes sense to look ahead a bit.
I think it would be better to switch to two branches, like most other open
source projects I've worked with:
0.3.x -> small, compatible changes, bugfixes, like now
0.4.x -> trunk, more impactful changes, refactorings, eventual major release
Both will obviously be fully compatible on the P2P-level.
> I'd rather that time be spent working on any remaining build issues so
> we can switch to bitcoin-qt. I don't care if it is autotools or qmake
> or QT creator, I just care that it works on Windows and Linux under
> gitian and has clear instructions so I can build it on my Mac.
>
I could do the Gitian stuff but not the Mac instructions, as I don't have a
Mac...
JS
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20110810/199e8a3e/attachment.html>

2023-06-07 02:13:44

- reply

📅 Original date posted:2011-08-10
🗒️ Summary of this message: The proposal suggests separating the headless daemon from the UI executable, making it possible to build the command line RPC client without building the server or UI.
📝 Original message:On Wed, Aug 10, 2011 at 10:14 AM, Matt Corallo <bitcoin-list at bluematt.me>wrote:
> I would argue its less clear for the user. Instead of opening either
> bitcoind or bitcoin to get RPC or GUI, now you have to open bitcoin and
> bitcoind or bitcoincl and bitcoind. Now, obviously bitcoin and
> bitcoincl can open bitcoind for you, but I think adding more executables
> complicates things for little clear advantage.
>
UI would obviously still have RPC functionality with -server. I don't mean
dropping that. The UI links both the UI and the network code (for now, until
this is separated out and the preferred UI<->core communication method is
through RPC).
I just mean that the *headless* daemon is separate from the UI executable,
which is the case for any other sane client/server-based program in
existence, from bittorrent nodes to game servers.
It would also make it possible to build the command line RPC client
(bitcoin-cl) *without* building the server or UI. Useful if you want to
remotely control a Bitcoin daemon but not want to build it locally.
JS
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20110810/891241ae/attachment.html>

2023-06-07 02:11:46

- reply

📅 Original date posted:2011-08-05
🗒️ Summary of this message: Re-broadcasting Bitcoin transactions could potentially allow for the identification of both the sender and recipient's IP addresses.
📝 Original message:> 3) The recipient re-broadcasts transactions (is Theymos right here?),
> allowing both the sender and recipient to be found
>
Hm this would potentially allow getting the IP for any recipient Bitcoin
address, given that a client with the private key connects to the network
once in a while.
Send them a transaction that is guaranteed to not be written into a block by
a miner, then monitor who rebroadcasts it over a few days/weeks.
I guess this could also be used to find out who has the stolen coins.
JS
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20110805/26b73de3/attachment.html>

2023-06-07 02:08:58

- reply

📅 Original date posted:2011-07-28
🗒️ Summary of this message: The idea of offering bounties to fix bugs in Bitcoin's codebase is discussed, with some arguing it would motivate people to fix bugs, while others suggest it may only encourage quick fixes rather than long-term contributions. The importance of attracting new developers to the project is also highlighted.
📝 Original message:On Wed, Jul 27, 2011 at 11:07 PM, Matt Corallo <bitcoin-list at bluematt.me>wrote:
> On Thu, 2011-07-28 at 08:45 +1000, Gavin Andresen wrote:
> > "A couple of bitcoins to fix a bug" sounds to me like nothing but
> > trouble for whoever is in charge of awarding the bounties, but maybe
> > I'm just anti-bounty because spending 2 or 3 hours and getting $30
> > worth of bitcoins for fixing a bug wouldn't motivate me.
>
> I do think it would motivate some people to fix a bug or two, though I
> would say it wouldn't encourage long-term contributors, just a bunch of
> hacked together patches which "fix" a bug.
>
Which, in many cases, is enough. Many times, fixing a bug is a few hours of
debugging, then fixing three lines of codes.
Sometimes it just takes a monkey to sit behind a PC and bash on it frantic
enough (with a debugger) to find and fix bugs :-) Competition to fix bugs is
(up to a certain level) good, it gets people off their ass. But I think the
competition problem is very hypothetical. It assumes there will suddenly be
*a lot* of people that want to fix the same bug. That's unrealistic...
Writing a few test-cases (which is better than the 0 we have now) also won't
take a Linus-level developer to work on it full time. A reasonable dev just
needs to put some time into it.
That leaves the more difficult work to the lead devs.
For a distributed currency I must say there is very little belief here in a
distributed process. Yes, you can also start a company and hire people to
work on it full time, but then they'll be working on helping customer not
solving bugs of the issue tracker (which might have an overlap, but not
necessarily). And it also isn't clear whether changes are contributed back
to the project.
You should not underestimate the open source community. There's a lot of
smart students eager to work on interesting, high-impact projects. Bitcoin
certainly fits that description, but the problem is that Bitcoin isn't
really that known yet with devs, and they need a little push to get
involved. And to work on the current code-base, because usually they will
look at the code and decide it's a piece of crap and want to rewrite it (new
people syndrome).
Yes, there might be one-time-and-run-off flakes, but hey that's life... you
only need to gain a few (semi)dedicated devs from it anyway, not recruit an
army of loyal minions.
I'm not saying this push has to be bounties. It could be a nice page, for
example just posting the bounties on the forum is a start, but certainly not
enough. They just get buried in troll poop, and a lot of the forum users are
... *psychological analysis removed*. You really want to reach out somehow.
It should at least have a nice page that attracts people on the
bitcoin.orgsite, and explains why you should work on Bitcoin (because
the project is so
awesome and fun) and some form of attribution (not just a mention in the
gitlog, but bounties is only one option) if you do manage to fix a bug.
Heck a scoreboard with "number of bugs squished" could be a start :-) We
need to be creative here...
JS
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20110728/88846e1b/attachment.html>

2023-06-07 02:08:42

- reply

📅 Original date posted:2011-07-27
🗒️ Summary of this message: Offering bounties for developers to fix bugs in Bitcoin software could increase its value, but should be a symbolic gesture rather than a full-time salary.
📝 Original message:On Wed, Jul 27, 2011 at 4:07 PM, Rick Wesson
<rick at support-intelligence.com>wrote:
> personally, if the software works better (less bugs) then btc will be more
> valuable. offering bounty is orthorginal to finding the right technical lead
> that will hurd the effort.
>
> put a bounty (salary) on the person to lead the effort, not the bugs
>
Bounties would be much less than a developer salary. The idea is not to pay
for people full time, but it would be more of a symbolic gesture to attract
developers and get them some coins. People with coins are also more
motivated to make the project more valuable, otherwise you have a "tragedy
of the commons" problem.
Not that I don't agree Gavin with getting a salary but that's a completely
independent issue :)
JS
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20110727/339660fb/attachment.html>

2023-06-07 02:08:29

- reply

📅 Original date posted:2011-07-27
🗒️ Summary of this message: The discussion is about whether to use GitHub for bug tracking or set up a separate bug tracker, with a suggestion to create a list of bounties on a separate site.
📝 Original message: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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20110727/2552af74/attachment.html>

2023-06-07 02:07:34

- reply

📅 Original date posted:2011-07-26
🗒️ Summary of this message: Use email-like addresses for consistency in formatting, regardless of the underlying protocol, as foo.bar.net and foo@bar.net differ.
📝 Original message:> I only meant that foo.bar.net is not the same formatting.
> foo at bar.net would be.
>
Yes please use email-like addresses, whatever is decided on the underlying
protocol.
JS
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20110726/2f7cf73c/attachment.html>

2023-06-07 02:06:01

- reply

📅 Original date posted:2011-07-16
🗒️ Summary of this message: Bitcoin developers ignore forums, but new users think forum members influence project direction, making developers look bad. Forums should be for user feedback.
📝 Original message: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.
JS
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20110716/064ef97b/attachment.html>

2023-06-07 02:05:58

- reply

📅 Original date posted:2011-07-16
🗒️ Summary of this message: Matt Corallo suggests creating a simpler forum with two categories: Technical Support and Development, which can be replicated per language.
📝 Original message:On Sat, Jul 16, 2011 at 10:54 AM, Matt Corallo <bitcoin-list at bluematt.me>wrote:
> If we had the moding power, yes, but we don't have nearly enough people
> who could mod such a forum.
>
I think a simpler forum would also be easier to moderate. Main criterion: is
it helpful to users? If not, lock/remove it.
Two categories: Technical Support, Development (which can be split up
between client work, and other software/websites integrating bitcoin).
Those two can be replicated per language if a large enough group exists in
that country that is also willing to maintain order.
I have no problems with volunteering some time moderating, but not on the
current forums.
If this is really a capacity issue then IMO we should simply remove the link
and come up with an alternative medium to address user issues (such as a
moderated mailing list). But I don't really believe this. There's a ton of
successful forums that did pick the right structure and helpful moderators,
and a lot of them are volunteer-driven.
JS
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20110716/75d09834/attachment.html>

2023-06-07 02:01:46

- reply

📅 Original date posted:2011-07-07
🗒️ Summary of this message: A developer is willing to write a cmake configuration for Bitcoin, but currently sticking with qmake as it works well for a small project.
📝 Original message:Hello Pieter,
Other opinions? Someone actually interested in writing a cmake configuration
> for bitcoin?
>
I'm willing to do it, but the priority is not that high.
I'm currently sticking with qmake, as apart from boost library name
auto-detection, I had no problems with it and it works well enough for a
relatively small project such as bitcoin.
JS
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20110707/61f47a76/attachment.html>

2023-06-07 02:01:27

- reply

📅 Original date posted:2011-07-02
🗒️ Summary of this message: A discussion about the use of autotools versus cmake as a build system for a project, with concerns raised about cmake not following the standard build procedure.
📝 Original message: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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20110702/e5aef2ef/attachment.html>

2023-06-07 01:22:41

- reply

📅 Original date posted:2011-06-24
🗒️ Summary of this message: Jan is seeking advice on how to improve the speed of "getbalance" in Instawallet; a suggestion is made to scan the wallet every time a block comes in.
📝 Original message:Jan,
On Thu, Jun 23, 2011 at 9:51 PM, <jan at uos.de> wrote:
> Hi there!
>
> Instawallet has enjoyed steady growth and I'm running into a bottleneck
> now with "getbalance <someaccounthere>" taking quite some time to
> complete. My understanding is, that this is because bitcoind runs
> through all relevant transactions each time anew to compute the balance.
> I was hoping the list could give me some pointers/ideas on how I can
> improve this.
>
I think the easiest way to speed this up would be to scan the wallet every
time a block comes in or something else changes in the block chain (or, if
you prefer, some pre-set interval of N minutes). Then go over the entire
wallet and the accumulate balances for all accounts. This could be done in
amortized linear time using a hash_map.
1) This reduces the time the API takes to return the balance for an account
to a predictable, very short time. Just the time to look up the balance in
the hash table (and return 0 on miss). The number crunching happens in the
network thread, not while you're waiting on the API.
2) Less bug-prone than "incremental caching" as you propose, and doesn't
require determining which accounts are influenced by a new block
3) Block chain reorgs are no problem.
JS
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20110624/3762c70c/attachment.html>

2023-06-07 01:21:33

- reply

📅 Original date posted:2011-06-17
🗒️ Summary of this message: Developer requests information on when the autotools build system will be included to support multiple GUIs in the upcoming 0.4.0 release.
📝 Original message:Hello,
I think my Qt GUI is pretty much ready for merging. I've been using it for a
while and all functionality works.
What is the current roadmap for including the autotools build system, so
that it will be possible to support multiple GUIs? 0.4.0?
JS
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20110617/f52640b9/attachment.html>