From: Mike Hearn <mike@plan99•net>
To: Peter Todd <pete@petertodd•org>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Gavin's post-0.9 TODO list...
Date: Fri, 16 Aug 2013 17:11:35 +0200 [thread overview]
Message-ID: <CANEZrP3wzMi3oWcwCt-GEs1cXdNa0mzvso_d3htJxaahiewaYw@mail.gmail.com> (raw)
In-Reply-To: <20130816145912.GA16533@petertodd.org>
[-- Attachment #1: Type: text/plain, Size: 1506 bytes --]
On Fri, Aug 16, 2013 at 4:59 PM, Peter Todd <pete@petertodd•org> wrote:
> UPNP seems to work well for the reference client. What's the situation
> there on Android?
>
Not sure - it could be investigated. I think UPNP is an entirely
userspace-implementable protocol, so in theory it could be done by a
userspace library (even libminiupnp - java is not a requirement on android)
> I leave my phone plugged in and connected via wifi for most of the day;
> lots of people do that.
>
I suspect you mean "I think lots of people do that". I'm not so sure. We
could potentially run an experiment in the Android app to measure how many
users are in a position to contribute back, but just because you have wifi
doesn't mean you can reconfigure it using UPnP. That helps a lot in home
networks, but at the office it doesn't help.
I'm wary of a ton of work being put in to achieve not very much here.
Satoshi's original vision was always that millions of users were supported
by 100,000 or so nodes. I don't think that's unreasonable over the long
term.
Besides, prioritisation isn't very hard. Nodes can just hand clients a
signed timestamp which they remember. When re-connecting, the signed
timestamp is handed back to the node and it gives priority to those with
old timestamps. No state is required on the node side. Signing and checking
can be passed onto the general ECDSA thread pool that works its way through
pending signature operations, they'd be prioritised lower than checking
blocks/broadcasts.
[-- Attachment #2: Type: text/html, Size: 2159 bytes --]
next prev parent reply other threads:[~2013-08-16 15:11 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-16 1:00 Gavin Andresen
2013-08-16 4:06 ` Melvin Carvalho
2013-08-16 12:11 ` Mike Hearn
2013-08-16 12:24 ` Mike Hearn
2013-08-16 13:41 ` Warren Togami Jr.
2013-08-16 13:46 ` Mike Hearn
2013-08-16 13:53 ` Warren Togami Jr.
2013-08-16 14:06 ` Peter Todd
2013-08-16 14:56 ` Gregory Maxwell
2013-08-16 14:01 ` Peter Todd
2013-08-16 14:15 ` Peter Todd
2013-08-16 14:27 ` Warren Togami Jr.
2013-08-16 14:36 ` Mike Hearn
2013-08-16 14:59 ` Peter Todd
2013-08-16 15:06 ` Warren Togami Jr.
2013-08-16 15:11 ` Mike Hearn [this message]
2013-08-16 15:13 ` Mike Hearn
2013-08-16 15:59 ` Peter Todd
2013-08-17 0:08 ` Warren Togami Jr.
2013-08-17 12:35 ` Mike Hearn
2013-08-17 13:41 ` Jeff Garzik
2013-08-19 3:09 ` John Dillon
2013-08-19 3:17 ` Peter Todd
2013-08-19 5:00 ` John Dillon
2013-08-19 5:34 ` John Dillon
2013-08-19 5:11 ` Mark Friedenbach
2013-08-19 9:16 ` Mike Hearn
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CANEZrP3wzMi3oWcwCt-GEs1cXdNa0mzvso_d3htJxaahiewaYw@mail.gmail.com \
--to=mike@plan99$(echo .)net \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=pete@petertodd$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox