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 918D5B5F for ; Thu, 30 Mar 2017 10:19:35 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-yw0-f176.google.com (mail-yw0-f176.google.com [209.85.161.176]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 091B0D0 for ; Thu, 30 Mar 2017 10:19:34 +0000 (UTC) Received: by mail-yw0-f176.google.com with SMTP id v76so21957266ywg.0 for ; Thu, 30 Mar 2017 03:19:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=tCF7vxnCsa7xEjjq60D2HZ3y8ig2+qlu7TNPDA6EMvE=; b=EnGX5Vl1w4tDxbdOmVspnSjNYTXTuT6JlE0WQqIm7lyR86u/CsZX5QA0urQK0qA7pR 0XCiie2ohsillbg38p+57n5UmNSWfD+oZ8TkcHRVA0bUU40RVo0Wy0monZZ8ZsLfRINC GMhx+LCt5UgkEl85dhWg2ZfsTxbMQLkKM03aBKH+3XlSB8vvMeGPXYEt0F4o1WJ8Fph0 YiRhGlnTlFLh105HJEQCqK4bYTGKwz5RL+tzjBfpSsQWVTbR/wZga+h+Rdq8HiH6HCvx VfNo1FjvfHmw1cA/wSbp/HVn+gwPDqLnq6VtWf+oUXI6wNejcx8ZF46d82W+yfzIM3be rmMQ== 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=tCF7vxnCsa7xEjjq60D2HZ3y8ig2+qlu7TNPDA6EMvE=; b=ZLiIvn2eVfC6RW/5zzZBtOY66N5s0yYUgdz6JJdN9S3XYqC+v1o40WETV83gJB/sGV FGRgBSJ1QPe/M6aiqlmJiphGZACEixsET2cfTPlgOCxmiQmx+QwP9XoKKjXi494je0hX bMiEWRXOQrVNa2c29hDQvNJO8uCcHsr/TQpgb0TtgmMkjGcckcG6J2F+iV8LWGNxUiy4 /Pg67UlgdT5itPlzFODTTIaq0tQuhkMw+f++lXWkQcxeTUYAgKmEktehpK8nzh3ZrwgL cNZxNgGFr8Y+fQrxUu2/s6H3+qejQM/bvYWldHJPpdikRsIqf5ukmjUUqnb3jnaNBpfD MmFg== X-Gm-Message-State: AFeK/H1wVjrPEw7jBlKqApL++BbrsJecmeAXr0DeeQXjYvvhwv0rFzUWKOdW8lJSXkwyVtpAlCOf9hXrHDcIEA== X-Received: by 10.13.221.19 with SMTP id g19mr1597854ywe.21.1490869174114; Thu, 30 Mar 2017 03:19:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.123.135 with HTTP; Thu, 30 Mar 2017 03:19:33 -0700 (PDT) Received: by 10.37.123.135 with HTTP; Thu, 30 Mar 2017 03:19:33 -0700 (PDT) In-Reply-To: References: <201703301004.06489.luke@dashjr.org> From: Natanael Date: Thu, 30 Mar 2017 12:19:33 +0200 Message-ID: To: Luke Dashjr Content-Type: multipart/alternative; boundary=94eb2c064ed287a5f5054bf00764 X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE, RCVD_IN_SORBS_SPAM autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: Bitcoin Dev Subject: Re: [bitcoin-dev] Block size adjustment idea - expedience fees + difficulty scaling proportional to block size (+ fee pool) 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: Thu, 30 Mar 2017 10:19:35 -0000 --94eb2c064ed287a5f5054bf00764 Content-Type: text/plain; charset=UTF-8 Den 30 mars 2017 12:04 skrev "Luke Dashjr" : I don't see a purpose to this proposal. Miners always mine as if it's their *only* chance to get the fee, because if they don't, another miner will. Ie, after 1 block, the fee effectively drops to 0 already. I believe that with correctly configured incentives, you can make it more profitable to delay some transactions with lower fees but still include them in the next block then to include them all at once. This would smooth out the inclusion of transactions. This may require changing the difficulty scaling from using a simple logarithm to a function that first behaves like a logarithm up to some multiple of the standard block size, after which difficulty starts increasing faster and reaches a greater-than-linear ratio in expected required hash per mined bit. Perhaps tipping over at around a blocksize 3x the standard blocksize. Since the standard blocksize increases with continous load after retargeting, the blocksize at which this happens also increases. Also, together with the above the fee pool does slightly counteract what you say, as they'll get a share via the pool when there's less transactions available the next time they create a block (like insurance). For a user, what's the incentive to pay an individual miner the fee directly? --94eb2c064ed287a5f5054bf00764 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

=

Den 30 mars 2017 12:04 skrev "Luke Dashjr" <luke@dashjr.org>:

I don't see a purpose to this proposal. Miners always mine as if it'= ;s their
*only* chance to get the fee, because if they don't, another miner will= . Ie,
after 1 block, the fee effectively drops to 0 already.

I believe that with corre= ctly configured incentives, you can make it more profitable to delay some t= ransactions with lower fees but still include them in the next block then t= o include them all at once. This would smooth out the inclusion of transact= ions.=C2=A0

This may req= uire changing the difficulty scaling from using a simple logarithm to a fun= ction that first behaves like a logarithm up to some multiple of the standa= rd block size, after which difficulty starts increasing faster and reaches = a greater-than-linear ratio in expected required hash per mined bit. Perhap= s tipping over at around a blocksize 3x the standard blocksize. Since the s= tandard blocksize increases with continous load after retargeting, the bloc= ksize at which this happens also increases.=C2=A0
Also, together with the above the fee pool does s= lightly counteract what you say, as they'll get a share via the pool wh= en there's less transactions available the next time they create a bloc= k (like insurance).=C2=A0

For a user, what's the incentive to pay an individual miner the fee d= irectly?=C2=A0
--94eb2c064ed287a5f5054bf00764--