Peter Todd [ARCHIVE] on Nostr: š Original date posted:2013-08-16 š Original message:On Fri, Aug 16, 2013 at ...
š
Original date posted:2013-08-16
š Original message:On Fri, Aug 16, 2013 at 05:11:35PM +0200, Mike Hearn wrote:
> On Fri, Aug 16, 2013 at 4:59 PM, Peter Todd <pete at 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)
Do find out.
> > 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.
Also worth finding out.
> 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.
Appeal to authority.
Stop bringing up Satoshi's "vision" - our understanding of
crypto-currencies has improved in the 4.5 years since Bitcoin was
released. Satoshi didn't even forsee pool mining, which says a lot about
his economic judgement.
> 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.
Right, so you're giving priority to peers that have been around for
awhile. You've succeeded in forcing attackers to wait a bit.
A) What's the definition of a peer? What stops me from pretending to be
100 peers?
B) Given an attacker willing to wait, what's your plan?
--
'peter'[:-1]@petertodd.org
000000000000004a52a297d9ae8ecde2ba62b681cc5a4cfbf7636032fc78e7d0
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130816/e4b89d0d/attachment.sig>;
š Original message:On Fri, Aug 16, 2013 at 05:11:35PM +0200, Mike Hearn wrote:
> On Fri, Aug 16, 2013 at 4:59 PM, Peter Todd <pete at 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)
Do find out.
> > 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.
Also worth finding out.
> 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.
Appeal to authority.
Stop bringing up Satoshi's "vision" - our understanding of
crypto-currencies has improved in the 4.5 years since Bitcoin was
released. Satoshi didn't even forsee pool mining, which says a lot about
his economic judgement.
> 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.
Right, so you're giving priority to peers that have been around for
awhile. You've succeeded in forcing attackers to wait a bit.
A) What's the definition of a peer? What stops me from pretending to be
100 peers?
B) Given an attacker willing to wait, what's your plan?
--
'peter'[:-1]@petertodd.org
000000000000004a52a297d9ae8ecde2ba62b681cc5a4cfbf7636032fc78e7d0
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130816/e4b89d0d/attachment.sig>;