Re: [Electrum-discuss] To slush, about Stratum

[slush <sl...@ce...>]

On Wed, Aug 15, 2012 at 6:05 PM, Amir Taaki <zg...@ya...> wrote:

> Slush asked me about the problems with Stratum (namely starvation attacks).
>
> I thought I'd just enumerate them here.
>
> Basically each request (like get_history) is too large. If you imagine
> that on the backend that it is composed of many smaller requests. Therefore
> requesting the history for 1VayNert or some other address means a huge
> amount of backend operations.
>
>
Yes, that's what I was worry since the beginning. get_history is too
complex and simple polling of get_history is also the easiest way for
client developers, so there's the rist that some of them will overload the
servers even more than is necessary.

My proposal is to change get_history call (or provide another method) which
allows pagination. The most use cases are that clients need only recent
transactions, not thousands of them years ago, so this will effectively
reduce both cpu load and network bandwidth.

Ideal implementation should introduce some token (maybe tx hash?) which
will represent the last transaction returned by previous get_history call.
It is much easier to implement than traditional pagnation using indexes,
when you think about possible race condition when new transaction arrive
between two get_history calls.

I believe the correct way to resolve this is by having each request split
> into many smaller requests. Thomas disagrees and thinks you just need
> better DoS protection on the backend. I'm not so sure that's the entire
> solution and see it more as a band-aid around a deeper problem.
>
>
Problem is that the request to 1VayNert is completely valid. So no "DoS
protection" will help if you don't want to filter out "big addresses".


> Also I don't like that the server stores state. Ideally everything should
> be stateless (see BIP 33).
>
>
Completely agree. This goes hand in hand with my pagination proposal, with
tokens. You can obtain token from one connection and use it in another
connection, it's completely stateless.


> Lastly line delimited TCP is not secure as Patrick pointed out.
>

I don't see big problem there. It's not problem of protocol specification,
it's problem of implementation in Electrum. Basically there's no difference
if you lost part of the line (missing \n) or you get corrupted packet.


> Part of the issue is that Thomas told me that the constraint for mobile
> devices is not computational resources, but bandwidth. I'm starting to
> think the way to resolve this would be by having a Spinner type protocol on
> top of the underlying Stratum one. This would sacrifice privacy for
> mobiles, but I think that's OK.
>
>
I'm strongly against this, we should put more effort to specification which
will handle both cases, than fragment the effort and maintain more
implementations for only slightly different use cases.

slush