From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 03ED17A4 for ; Tue, 9 May 2017 01:15:55 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mo.garage.hdemail.jp (mo.garage.hdemail.jp [46.51.242.127]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 2FDD712C for ; Tue, 9 May 2017 01:15:51 +0000 (UTC) Received: from ip-10-217-1-36.ap-northeast-1.compute.internal (localhost.localdomain [127.0.0.1]) by mo.garage.hdemail.jp (hde-mf-postfix) with SMTP id 3C2F114C0BD for ; Tue, 9 May 2017 10:15:50 +0900 (JST) (envelope-from karljohan-alm@garage.co.jp) X-Received: from unknown (HELO mo.garage.hdemail.jp) (127.0.0.1) by 0 with SMTP; 9 May 2017 10:15:50 +0900 X-Received: from mo.garage.hdemail.jp (localhost.localdomain [127.0.0.1]) by mo.garage.hdemail.jp (hde-ma-postfix) with ESMTP id 2FA474C082 for ; Tue, 9 May 2017 10:15:50 +0900 (JST) (envelope-from karljohan-alm@garage.co.jp) Received: from gw21.oz.hdemail.jp (ip-10-172-186-126.ap-northeast-1.compute.internal [10.172.186.126]) by mo.garage.hdemail.jp (hde-mf-postfix) with ESMTP id 2D08114C0BD for ; Tue, 9 May 2017 10:15:50 +0900 (JST) (envelope-from karljohan-alm@garage.co.jp) X-Durian-MailFrom: karljohan-alm@garage.co.jp X-Durian-RcptTo: bitcoin-dev@lists.linuxfoundation.org Received: from gw21.oz.hdemail.jp (gw21.oz.hdemail.jp [127.0.0.1]) by gw21.oz.hdemail.jp (gw21.oz.hdemail.jp [127.0.0.1]); Tue, 9 May 2017 10:15:48 +0900 X-Received: from mail-qt0-f200.google.com (lb1.oz.lo.hdemail.jp [54.248.222.53]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by gw21.oz.hdemail.jp (Postfix) with ESMTP id 995DD148C0EE for ; Tue, 9 May 2017 10:15:47 +0900 (JST) X-Received: by mail-qt0-f200.google.com with SMTP id j58so13360152qtc.2 for ; Mon, 08 May 2017 18:15:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=002gYJcYJGfT3xuQSd2Wtwk/uNn7fWSGleSZ/wVlNe4=; b=N4aEhqO0uLdJzDXObO296IZi0O/TgSOBRQovje/fD3h/FcA1Yg/w60YGqHwP2eoGzH ErM57YKN+SSWpBxmhlBWD4O456in0RVDRvSEgZY+2tCW3J8H1eJMBdpVsUxAdMGUQhM4 WQpRdWTY027gELEZ7LB8/RyTtCYHJonEsHxG8owaYgaTVuX0KSjDgaXtrtN2/qDpKJvX FaizKVxDtV2iq36F7d3EbyZSyHWEf7Sp41c5/8zKrBuqtXRdiI7OTyIOLoVUZJszBXDa S+33CKFUCwtXuGQc2b3i//F9+0D9OdCQdFSloSl7cuAB6hP3pHSFjDaLgkamaRMhpy05 0nXA== X-Gm-Message-State: AODbwcCzpGQW1DjlYcbJCgGPMxP0amVWaUj2UTQfRthNgG1eDfFpgwY1 2uNSoPJ8+b80n5UHKddYFAvU7dobbpjA88H83a0f7UDpSuvTUEIk7EOW2WGGhlr8C07678/7HBA WvtbkNrL9x8YyTO2Xhk7nS08gTdSMe1uCdBEzjRmOAYgmqA== X-Received: by 10.237.61.35 with SMTP id g32mr23025730qtf.60.1494292545599; Mon, 08 May 2017 18:15:45 -0700 (PDT) X-Received: by 10.237.61.35 with SMTP id g32mr23025716qtf.60.1494292545382; Mon, 08 May 2017 18:15:45 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.12.137.38 with HTTP; Mon, 8 May 2017 18:15:25 -0700 (PDT) In-Reply-To: References: From: Karl Johan Alm Date: Tue, 9 May 2017 10:15:25 +0900 Message-ID: To: Erik Aronesty Content-Type: text/plain; charset=UTF-8 X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Tue, 09 May 2017 01:26:16 +0000 Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] BIP Proposal: Rate Limiting with server specified Proof of Work challenges X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 May 2017 01:15:55 -0000 Erik, On Tue, May 9, 2017 at 3:58 AM, Erik Aronesty 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).