public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
* [bitcoin-dev] BIP Proposal: Rate Limiting with server specified Proof of Work challenges
@ 2017-05-08  2:48 Karl Johan Alm
  2017-05-08 18:58 ` Erik Aronesty
  2017-05-19  4:09 ` Karl Johan Alm
  0 siblings, 2 replies; 4+ messages in thread
From: Karl Johan Alm @ 2017-05-08  2:48 UTC (permalink / raw)
  To: Bitcoin Protocol Discussion

Hello,

I am proposing a new feature for rate limiting purposes where nodes
can make and solve arbitrary PoW challenges in return for connection
slots (to be expanded to cover e.g. bloom filters or other DoS risky
services).

The BIP currently includes two proofs of work (sha256 and
cuckoo-cycle) which can be combined (e.g. sha256(cuckoo-cycle) or
sha256(sha256(sha256)), etc).

Link: https://github.com/kallewoof/bips/blob/pow-connection-slots/bip-rate-limiting-via-pow.mediawiki

Feedback welcome.


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [bitcoin-dev] BIP Proposal: Rate Limiting with server specified Proof of Work challenges
  2017-05-08  2:48 [bitcoin-dev] BIP Proposal: Rate Limiting with server specified Proof of Work challenges Karl Johan Alm
@ 2017-05-08 18:58 ` Erik Aronesty
  2017-05-09  1:15   ` Karl Johan Alm
  2017-05-19  4:09 ` Karl Johan Alm
  1 sibling, 1 reply; 4+ messages in thread
From: Erik Aronesty @ 2017-05-08 18:58 UTC (permalink / raw)
  To: Karl Johan Alm; +Cc: Bitcoin Protocol Discussion

[-- Attachment #1: Type: text/plain, Size: 1204 bytes --]

- It would be cool if any rate-limiting POW was specified as bytecode ...
so nodes can plug in as many "machine-captcha" things as they please, and
solvers can choose to solve... or just say "nope too hard".

- Alternately, it would be a lot nicer if you just required people to pay a
nanobit .... that could prevent DDOS even better, and generate a revenue
stream for nodes.


On Sun, May 7, 2017 at 10:48 PM, Karl Johan Alm via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:

> Hello,
>
> I am proposing a new feature for rate limiting purposes where nodes
> can make and solve arbitrary PoW challenges in return for connection
> slots (to be expanded to cover e.g. bloom filters or other DoS risky
> services).
>
> The BIP currently includes two proofs of work (sha256 and
> cuckoo-cycle) which can be combined (e.g. sha256(cuckoo-cycle) or
> sha256(sha256(sha256)), etc).
>
> Link: https://github.com/kallewoof/bips/blob/pow-connection-
> slots/bip-rate-limiting-via-pow.mediawiki
>
> Feedback welcome.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 1970 bytes --]

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [bitcoin-dev] BIP Proposal: Rate Limiting with server specified Proof of Work challenges
  2017-05-08 18:58 ` Erik Aronesty
@ 2017-05-09  1:15   ` Karl Johan Alm
  0 siblings, 0 replies; 4+ messages in thread
From: Karl Johan Alm @ 2017-05-09  1:15 UTC (permalink / raw)
  To: Erik Aronesty; +Cc: Bitcoin Protocol Discussion

Erik,

On Tue, May 9, 2017 at 3:58 AM, Erik Aronesty <erik@q32•com> wrote:
> - It would be cool if any rate-limiting POW was specified as bytecode ... so
> nodes can plug in as many "machine-captcha" things as they please, and
> solvers can choose to solve... or just say "nope too hard".

I'm not entirely sure what you mean, but right now you can make an
arbitrary chain of challenges, and the BIP includes methods for
determining an approximate time to solve (nodes will, at the very
least, discard any challenge which will on average take longer time to
solve than the expiration of the challenge itself, for example, i.e.
the "nope too hard" part).

> - Alternately, it would be a lot nicer if you just required people to pay a
> nanobit .... that could prevent DDOS even better, and generate a revenue
> stream for nodes.

Others mentioned this approach. I haven't given it much thought.
Admittedly it would be an effective way to prevent DoS but it also has
some unwanted side effects that need to be cleared up (e.g. in a
no-gains scenario like the BIP proposes, the node requesting PoW done
doesn't *gain* anything from lying to the node performing the work).


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [bitcoin-dev] BIP Proposal: Rate Limiting with server specified Proof of Work challenges
  2017-05-08  2:48 [bitcoin-dev] BIP Proposal: Rate Limiting with server specified Proof of Work challenges Karl Johan Alm
  2017-05-08 18:58 ` Erik Aronesty
@ 2017-05-19  4:09 ` Karl Johan Alm
  1 sibling, 0 replies; 4+ messages in thread
From: Karl Johan Alm @ 2017-05-19  4:09 UTC (permalink / raw)
  To: Bitcoin Protocol Discussion

Hello,

Some time has passed since this was initially posted, and I have not
received any negative feedback. If no objections are raised, I would
like to have a BIP number assigned.

On Mon, May 8, 2017 at 11:48 AM, Karl Johan Alm
<karljohan-alm@garage•co.jp> wrote:
> Hello,
>
> I am proposing a new feature for rate limiting purposes where nodes
> can make and solve arbitrary PoW challenges in return for connection
> slots (to be expanded to cover e.g. bloom filters or other DoS risky
> services).
>
> The BIP currently includes two proofs of work (sha256 and
> cuckoo-cycle) which can be combined (e.g. sha256(cuckoo-cycle) or
> sha256(sha256(sha256)), etc).
>
> Link: https://github.com/kallewoof/bips/blob/pow-connection-slots/bip-rate-limiting-via-pow.mediawiki
>
> Feedback welcome.


^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2017-05-19  4:09 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-05-08  2:48 [bitcoin-dev] BIP Proposal: Rate Limiting with server specified Proof of Work challenges Karl Johan Alm
2017-05-08 18:58 ` Erik Aronesty
2017-05-09  1:15   ` Karl Johan Alm
2017-05-19  4:09 ` Karl Johan Alm

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox