Daniel F [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-09-23 to 2014-11-08
💬 Posted a total of 15 messages
📚 Participated in the following categories: Bitcoin-development, BIP 15
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 15:27:10

- reply

📅 Original date posted:2014-11-08
📝 Original message:> But I'd like to know what storage, RAM and bandwidth resources are
> needed. I guess that the problem is not the CPU.
Hi Francis,
Here are some rough guidelines for you, based on the statistics from my
node:
disk usage: about 30GB currently for the blockchain data. It'll only
keep growing from here, but relatively slowly.
cpu usage: pretty much nothing, after you have synced the blockchain.
ram usage: after it runs for a few months, my node gets up to using 1.5
GB of ram or so.
bandwidth usage: my node averages about 500GB of traffic per month, most
of it outgoing.
Hope that gives you a rough idea of what you can expect for running full
node.
Best,
Daniel

2023-06-07 15:09:43

- reply

📅 Original date posted:2013-11-14
📝 Original message:> This is a decentralized currency, and we should avoid centralizing
> decisions. This is something that impacts the community at large, and
> deserves input and discussion at every level.
>
> I would suggest posting on all possible forums "proposal: switch to
> uBTC, labelled as ISO prefers (XBT?)" and see what sort of discussion
> is generated. If the support is broad, it will be plain from the
> responses if there is a consensus. Perhaps everyone will agree it is
> the best course, and we can make an easy change.
>
> But we need less "core dev fiat" not more :)
>
this seems like such a paint-the-bikeshed problem that it's sure to
generate vast volumes of discussion, waste a lot of people's time, and
all for only a dubious (imo) gain. (case in point - here i am
contributing to it :) ).
i agree that we should avoid centralizing this. i'll go a step further
and note that the client already has a dropdown allowing individuals to
choose units. merchants are free to choose to price in different units.
exchanges are free to denominate trade in different units.
i suggest we just let the market do its thing and not get into trying to
'make a decision' of any sort.

2023-06-07 15:05:32

- reply

📅 Original date posted:2013-08-05
📝 Original message:If you want package authentication, you should at least throw in some
digital signing, not just a checksum. With a compromised host, both the
checksum and binaries can be changed undetectably, but if there's a
signature made by a key that is not kept on the host, there's no way to
fake a valid binary.
There may be other issues people would want to bring up, but surely just
a checksum is not sufficient.
on 08/05/2013 10:39 AM Wendell said the following:
> For usability purposes, we at Hive would like to have an
> auto-updater
in our wallet app.
>
> What is a safe way to do this? I understand that Bitcoin-QT lacks
> such
an updater for security reasons... Has been thought out in more detail
since that decision was made?
>
> We have been toying around with the idea of placing one server
> behind
a Tor hidden service, whose only function is to output a checksum of the
update package. The theory is that if it is well-secured, it will at
least be immune to tampering at the physical hosting level.
>
> Any thoughts or advice about any of this?
> -wendell
>
> grabhive.com | twitter.com/grabhive | gpg: 6C0C9411
>
>
>
> ------------------------------------------------------------------------------
> Get your SQL database under version control now!
> Version control is standard for application code, but databases havent
> caught up. So what steps can you take to put your SQL databases under
> version control? Why should you start doing it? Read more to find out.
> http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk
>
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

2023-06-07 15:04:29

- reply

📅 Original date posted:2013-07-09
📝 Original message:on 07/09/2013 10:28 AM Mike Hearn said the following:
> SourceForge has a horrible UI and blocks some countries. It also exposes
> us to a large and potentially hackable mirror network. Whilst we're not
> bandwidth constrained on our own servers, let's try and keep using them.
the point was just that "if need be" free capacity is available without
having to throw money at it. until there's no need, doesn't matter.
also hackability (and ui) should be irrelevant for the autoupdate
process (which i presume will do all kinds of checksum and sig
verification). and it's likely the autoupdates that will create very
lumpy download demand.

2023-06-07 15:04:28

- reply

📅 Original date posted:2013-07-09
📝 Original message:on 07/09/2013 06:56 AM Jim said the following:
> + it will bump up the MultiBit download from about 11MB to 30-40MB
> (I think). This drops the maximum copies of MultiBit the multibit.org
> server can deliver per day from around 90,000 to 30,000ish.
> The multibit.org server maxes out at 1 TB of bandwidth per day.
You could host your downloads on sourceforge and achieve virtually
unlimited capacity.

2023-06-07 10:21:52

- reply

📅 Original date posted:2012-07-13
📝 Original message:This discussion is quite bikesheddy, but (or thus? :) ) I will put in my
2c.
The main thing to think about, I think, is "what would be best for the
users". To that end, I suggest the following:
* I do think a page on bitcoin.org listing relatively major, and
relatively vetted, clients is a good idea. Removing it completely and
relegating it to a wiki page, which is likely to contain all sorts of
marginal crufty clients, would likely be a disservice to the users.
* Randomized order is likely also a disservice to the users. We should
list clients in order of "goodness", as determined by whoever(s) we
decide to put in charge of the page. This "goodness" should likely to be
some kind of weighted average of features, security, goodness for
bitcoin network, etc. [1]
** If randomized order is after all chosen, it should be done in
javascript client-side, rather than doing daily page reorgs. If people
without JS don't see random, it's not material at all.
* Prose vs. feature matrix: both have their good and bad points, as
discussed upthread. I think the users will be best served by a
combination of both:
** Prose descriptions of clients should deliberately include negative
points, not just let the user infer them by lack of corresponding
positive mention. (e.g. "This client has fast startup time. That means
you're completely trusting the server operator with your money.") This
task is left up to the person(s) in charge.
** A feature matrix, with carefully chosen and /well defined/
categories, /in addition to prose/ would likely also be of service to
the users. That could be left to the wiki though. The current wiki
clients page seems to be having a good go at it.[2]
** If we are targeting people who "don't know what they're doing", it
may be a good idea to have a 'decision assistant' type setup, where
users are asked several questions and are recommended clients based on
these answers. (This could be done in a static way by having a matrix of
questions.)
Finally - I'd say we're spending disproportionate developer resources on
this question, and if it were completely up to me, I'd resolve this
situation in the following quick-and-painless way: leave page as is, add
negative points to prose, link to wiki clients list. Estimated time to
completion: 1 hour (to think through which negative points to add).
[1] Meehl, 1954, clinical versus statistical prediction... (see also
Grove and Meehl, 1996; Sawyer, 1966) (and yes, despite the age of some
of this research, the conclusions have been surprisingly robust and
timeproof.)
[2] https://en.bitcoin.it/w/index.php?title=Clients&oldid=28615
-nanotube
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20120713/7bf3ec40/attachment.sig>

2023-06-07 02:46:09

- reply

📅 Original date posted:2011-12-13
🗒️ Summary of this message: Amir Taaki argues that FirstBits is useless due to the exponential rise in resources needed as the number of participants in the network grows linearly. He proposes a shared naming scheme between bitcoin implementations.
📝 Original message:On Mon, Dec 12, 2011 at 9:37 PM, Amir Taaki <zgenjix at yahoo.com> wrote:
> lol, way to miss the point nanotube.
>
> FirstBits *is* useless, but not for the reasons you specified. But simply because the resources it needs rises exponentially as the number of participants in the network grows linearly.
>
> The point is that if FirstBits were built into the implementation, that would allow me to simply send to 1brmlab. The proposal here is not for a website where people can lookup bitcoin addresses, but a shared naming scheme between bitcoin implementations. Here's the story again:
well, it's easy to miss the point when the example you use doesn't
make the point you think you're making. :D
but ok, yes, it would be nice to send directly to something like
1brmlab from the client. i suppose figuring out how to make sure that
1brmlab actually does send to whom you think it sends, is left to the
details of implementation, but that's a separate question.

2023-06-07 02:36:09

- reply

📅 Original date posted:2011-10-27
🗒️ Summary of this message: Proposal to use a git repo or something more redundant for Bitcoin Improvement Proposals (BIPs) due to the unreliability of the wiki.
📝 Original message:+1 on git. not necessarily as replacement, but at least as backup.
could possibly use markdown and github pages, which automagically
pushes git commits out to the website (uses markdown syntax, iirc)
On Thu, Oct 27, 2011 at 11:22 AM, Nils Schneider <nils at nilsschneider.net> wrote:
> Can we use a git repo or something more redundant for BIPs? They're
> rather important and the wiki has been unreliable before.
>
> On 27.10.2011 17:15, Amir Taaki wrote:
>> Anybody know how to contact MT about getting it back online? I still
>> haven't finished copy-editing the BIPs and need access to them since
>> there's a new one to be added.
>>
>>
>> ------------------------------------------------------------------------------
>> The demand for IT networking professionals continues to grow, and the
>> demand for specialized networking skills is growing even more rapidly.
>> Take a complimentary Learning at Cisco Self-Assessment and learn
>> about Cisco certifications, training, and career opportunities.
>> http://p.sf.net/sfu/cisco-dev2dev
>>
>>
>>
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
> ------------------------------------------------------------------------------
> The demand for IT networking professionals continues to grow, and the
> demand for specialized networking skills is growing even more rapidly.
> Take a complimentary Learning at Cisco Self-Assessment and learn
> about Cisco certifications, training, and career opportunities.
> http://p.sf.net/sfu/cisco-dev2dev
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>