Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 3EECCCA0 for ; Fri, 12 Apr 2019 15:45:32 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 2F34386E for ; Fri, 12 Apr 2019 15:45:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1555083925; bh=3/bU/tOXAwcLuOXfEm1twA9CtkaTgzdH7zh7v9TYdaU=; h=X-UI-Sender-Class:From:To:Cc:Subject:Date:In-Reply-To:References; b=ZjvCVOgrPGrjphK80KZbWpV4lLgpiTeVPKcN2uQwpiiC0G4ZV6CqrSWk6Cj8UHLmv T4vShNki1K6uzd5V05+cTsHl6Mxf/bwAqRR2s84xm4iD3CsCCpn5cMpbGDdNozJVMd KBFkYalNaf3+zvGjCt/UVlC1VskDhiCaDDelEeDQ= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [77.56.41.160] ([77.56.41.160]) by web-mail.gmx.net (3c-app-gmx-bs77.server.lan [172.19.170.225]) (via HTTP); Fri, 12 Apr 2019 17:45:25 +0200 MIME-Version: 1.0 Message-ID: From: simondev1 To: "Bernd Jendrissek" Content-Type: text/html; charset=UTF-8 Date: Fri, 12 Apr 2019 17:45:25 +0200 Importance: normal Sensitivity: Normal In-Reply-To: References:

X-UI-Message-Type: mail X-Priority: 3 X-Provags-ID: V03:K1:M+Wczg6xibChkLBlZ6jBHM09ldnrlDSgvBMUuHNHA/PWgN+QoD8RSVsJEkBI5yM36V/6W CZu0Yv897NYZoDuwI0MXz+7cJplQsNdhZrSpYQpFSCpHhp2WE7YxO8I0rQo8GqzgOY2+OYg9fEKL wSb/HTf4Qymq6uZ+Md8W+sUkz9mMZ9kOxnuAVgyu1v9FKd2zVcr2T2w9O3rH7s/I0B7UHfCD6fZN pN1wDFToi5b60JFqqJPS6qC3BWCrbxzT6EqD2gzivK0LkJSldo6c3TdN970FXaRd/cAFomxnx9Gp +s= X-UI-Out-Filterresults: notjunk:1;V03:K0:jDAs3t6XeIA=:2xLh4udxdHSjgri5VBdHH9 6KOPKEDDBFmi5JmhK3qPLQJiAFh6Zp5MOQA5uaJv0bO1927kL6DF5TRmWJI4iDFC3W9nLO2FC HmanJ8Cly4fPsIlVpDYd9pG0Dy3gAQIwK2o79YYKqXF/nVPWVVqiI5Jv2hLU9aPlaKThcK4X7 PblsAFXFvFnMVJDLIT1FzzP2WsyzkDExQ0zHp9J7DzSYNEoDHCARHVwjujXh2lEIfjU/TQ/Q2 v275auxw/nd0jqySCxa6toJjcZfGWYzlrpCjyUdB+XMza9IbFdC2v/jpMqOz3pfGrCHfiNQdq jnCqOTz/Rg1SIfDM2zxSPPii2kaPlXA8G9w4kTSDYDjOaGkZmy7Q10MlP17mJao5JIOQssEXw bK1ceDn1J/3xoCs9jOF/aPXhUHivQDldGMEXXO1fuujCTOZsUYsjvOm88A4YVzko2e0C28NR/ KkPyzWKuAfk8Jd7tz+WNhKNUNlAKrJ/uu3K1TqeYwQRP67Nkm0NKzemcRoM8ftbdnUr47S9Ot HhpYm0K7pp41PmVzHx8GMkBHNEyUZcRzfjJR7SnelZRmrHaExo8LWlgBcxOrwT9KWoP8N86J/ aD/YOsitqjiKI= X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, FREEMAIL_FROM, HTML_MESSAGE, MIME_HTML_ONLY, RCVD_IN_DNSWL_LOW autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Sun, 14 Apr 2019 12:59:16 +0000 Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] new BIP: Self balancing between excessively low/high fees and block size 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: Fri, 12 Apr 2019 15:45:32 -0000

Under the assumption that 41kb space for transaction with zero fee should be enough, it does not break CPFP: The miner can throw out other transactions to make space for all parent transactions he needs. Please note: The incentive for miners is not to have 41kb filled with zero fees. The incentive is to fill all space with highest possible fee per byte transactions. (if necessary we could change the constant in the formula from 1.1 to 1.2 that would modify the space for zero fee transactions to 79kb)

Regards,

Gesendet: Montag, 08. April 2019 um 00:11 Uhr
Von: "Bernd Jendrissek" <bitcoin@bpj-code.co.za>
An: simondev1 <random@gmx.ch>, "Bitcoin Protocol Discussion" <bitcoin-dev@lists.linuxfoundation.org>
Betreff: Re: [bitcoin-dev] new BIP: Self balancing between excessively low/high fees and block size

On Sun, 7 Apr 2019 at 17:45, simondev1 via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> ==Implementation==
> Sort transactions by FeeInSatoshiPerByte (lowest first)
> For each transaction starting from lowest FeeInSatoshiPerByte: Sum up the bytes of space used so far. Check if summed up bytes of space used so far is smaller or equal than the formula result.
> If this is valid for each transaction then the blocksize is valid.

Doesn't this break CPFP? I think to avoid that you'll need to rework
your proposed algorithm to treat chains of transactions as a group.
(And note that you could have multiple transactions in one block that
depend on the same "parent" transaction, also in the same block.)