From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1VALgk-00049k-L1 for bitcoin-development@lists.sourceforge.net; Fri, 16 Aug 2013 15:11:42 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.219.53 as permitted sender) client-ip=209.85.219.53; envelope-from=mh.in.england@gmail.com; helo=mail-oa0-f53.google.com; Received: from mail-oa0-f53.google.com ([209.85.219.53]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1VALgi-0006ov-V5 for bitcoin-development@lists.sourceforge.net; Fri, 16 Aug 2013 15:11:42 +0000 Received: by mail-oa0-f53.google.com with SMTP id k18so2350569oag.40 for ; Fri, 16 Aug 2013 08:11:35 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.182.60.194 with SMTP id j2mr1709427obr.2.1376665895602; Fri, 16 Aug 2013 08:11:35 -0700 (PDT) Sender: mh.in.england@gmail.com Received: by 10.76.80.165 with HTTP; Fri, 16 Aug 2013 08:11:35 -0700 (PDT) In-Reply-To: <20130816145912.GA16533@petertodd.org> References: <20130816140116.GB16201@petertodd.org> <20130816141536.GD16201@petertodd.org> <20130816145912.GA16533@petertodd.org> Date: Fri, 16 Aug 2013 17:11:35 +0200 X-Google-Sender-Auth: M9vncR2bO1EQxpGoMykHPp7IR9E Message-ID: From: Mike Hearn To: Peter Todd Content-Type: multipart/alternative; boundary=089e01633baaae915204e41201bf X-Spam-Score: -0.5 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (mh.in.england[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1VALgi-0006ov-V5 Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Gavin's post-0.9 TODO list... X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2013 15:11:42 -0000 --089e01633baaae915204e41201bf Content-Type: text/plain; charset=UTF-8 On Fri, Aug 16, 2013 at 4:59 PM, Peter Todd 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. --089e01633baaae915204e41201bf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Aug 16, 2013 at 4:59 PM, Peter Todd <pete@petert= odd.org> wrote:
UPNP seems to work well for the reference client. What's the = situation
there on Android?

Not sure - it could b= e investigated. I think UPNP is an entirely userspace-implementable protoco= l, so in theory it could be done by a userspace library (even libminiupnp -= java is not a requirement on android)
=C2=A0
I leave my phone plugged in= and connected via wifi for most of the day;
lots of people do that.

I suspect you m= ean "I think lots of people do that". I'm not so sure. We cou= ld potentially run an experiment in the Android app to measure how many use= rs are in a position to contribute back, but just because you have wifi doe= sn't mean you can reconfigure it using UPnP. That helps a lot in home n= etworks, but at the office it doesn't help.

I'm wary of a ton of work being put in to achieve n= ot very much here. Satoshi's original vision was always that millions o= f 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-connectin= g, 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 it= s way through pending signature operations, they'd be prioritised lower= than checking blocks/broadcasts.

--089e01633baaae915204e41201bf--