Dear bitcoin developers,

New BIP: https://github.com/bitcoin/bips/pull/774

==Abstract==

Logarithm of transaction fee limits block size.

==Motivation==

Keep block space small.
Waste less with spam transactions.
Auto balance Fees: Increase very low fees, Descrease very high fees.
Allow larger size when sender pays a lot.
Allow wallets to calculate/display how much average free block space there is for each fee price.
Allow senders to have more control about how the fee/priority of their transaction will behave, especially in the case of increased adoption in the future.

==Specification==

Every transaction has to fit into the following block space:

Input variable 'FeeInSatoshiPerByte': Must be positive or 0
type: double
unit: Satishi per byte
Output:
type: uint
unit: bytes
Formula:
floor( log10( 1.1 + FeeInSatoshiPerByte ) * 1024 * 1024 )

==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.

==Backward compatibility==

Soft fork: If applied AND old hardcoded block size limit is kept.

Hard fork: If applied AND old hardcoded block size limit is removed.

Regards, simondev1

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 ADC0DC7D for ; Sun, 7 Apr 2019 18:52:49 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ed1-f49.google.com (mail-ed1-f49.google.com [209.85.208.49]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id EEB1A709 for ; Sun, 7 Apr 2019 18:52:48 +0000 (UTC) Received: by mail-ed1-f49.google.com with SMTP id q3so4321994edg.0 for ; Sun, 07 Apr 2019 11:52:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=4cdhOzSQ8RCBiFnpN9IOITJ5+oPZIYxB3Y26VZIQaF4=; b=B6V1pr5dnfXLCX1WTeRpiJyTKN3+DTmp3WlcBUdMF5GrDHloRsvpDW2fwdykreAN1z uC6v4ko4LyXoZ3qvgywoU6qgChpke9JICgSo3WwhpkB5b778aGKALRXy0+ffP0LMmzfk 2j2XI6x7NRZIp+PArklpWxe8kIWn05PkH2RGCmnsHb7oMNwI7TQdaZAq+dNMjME6zZyP 1U4pXzJK/FEV3X/nT/tvdMn1s2CIyct1FS100vLeO8L+pRigD1w8FLw8YXCbDwTtFoh8 e/XAed5/HHEYa6scqYUwP6t7WdwJgz8p9+334/kEKCSkZ8mBxMbOVGjbaKEU6isXxXv0 0OdA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=4cdhOzSQ8RCBiFnpN9IOITJ5+oPZIYxB3Y26VZIQaF4=; b=lue9vrdTTMXmaOb5QP6udErnh1Ty5RnLnAjuVpzqQlqYzI0dAdd/hEWQ+A74lafY44 EBm5Bx6Czy2MxhbXmz3l7U0KB1Db/upS/z5/+3624W1Q+hobhfs091/OrETKM531KivE X8u35hzyeL5ZHclXW6xMl2/j0ZPMmBkLzTElljuBw4v7PrA7rvYDANfha2ruIRd14fPW EGc3L0N+go7BB36Nx3JsNJcz8qxlwgW+/avrjUyQ3HuhEM4atFz7O80GiOCLJZb4kAlt uFFKAm4/KNUmURYA2+eHWrGx89PwTna1C9y04YemKPxkEVzsElt1woSvsLtB/XpyabZA pnKg== X-Gm-Message-State: APjAAAWWImRsgArAgJ9x6QrBIj70K7p2ITGslYoD03b3C4cxYp+uXXRt E23oJDiamOZmUq7BuLNtHb3gepNBM+eCAakkovA= X-Google-Smtp-Source: APXvYqwpn3bnwiF/WLNh5KlWIm1sln2r1nvEBO5MCv7kjigfjtJqqdeYEpLd0MbzI2qgxuOgQ0lu/RCah55BekW6tFM= X-Received: by 2002:aa7:d294:: with SMTP id w20mr16387267edq.253.1554663167541; Sun, 07 Apr 2019 11:52:47 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Natanael Date: Sun, 7 Apr 2019 20:52:30 +0200 Message-ID: To: simondev1 , Bitcoin Dev Content-Type: multipart/alternative; boundary="000000000000d8c62c0585f539b3" X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE 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: Mon, 08 Apr 2019 01:50:15 +0000 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: Sun, 07 Apr 2019 18:52:49 -0000 --000000000000d8c62c0585f539b3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Related ideas previously submitted by me; https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-March/013885.h= tml Title: Block size adjustment idea - expedience fees + difficulty scaling proportional to block size (+ fee pool) Den s=C3=B6n 7 apr. 2019 17:45simondev1 via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> skrev: > Dear bitcoin developers, > > New BIP: https://github.com/bitcoin/bips/pull/774 > > =3D=3DAbstract=3D=3D > Logarithm of transaction fee limits block size. > > =3D=3DMotivation=3D=3D > Keep block space small. > Waste less with spam transactions. > Auto balance Fees: Increase very low fees, Descrease very high fees. > Allow larger size when sender pays a lot. > Allow wallets to calculate/display how much average free block space ther= e > is for each fee price. > Allow senders to have more control about how the fee/priority of their > transaction will behave, especially in the case of increased adoption in > the future. > > =3D=3DSpecification=3D=3D > Every transaction has to fit into the following block space: > Input variable 'FeeInSatoshiPerByte': Must be positive or 0 > type: double > unit: Satishi per byte > Output: > type: uint > unit: bytes > Formula: > floor( log10( 1.1 + FeeInSatoshiPerByte ) * 1024 * 1024 ) > > =3D=3DImplementation=3D=3D > 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. > > =3D=3DBackward compatibility=3D=3D > Soft fork: If applied AND old hardcoded block size limit is kept. > Hard fork: If applied AND old hardcoded block size limit is removed. > > Regards, simondev1 > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --000000000000d8c62c0585f539b3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Related ideas previously submitted by me;

https://lists.linuxfoundation= .org/pipermail/bitcoin-dev/2017-March/013885.html

Title: Block size adjustment idea - exped= ience fees + difficulty scaling proportional to block size (+ fee pool)=C2= =A0

Den s=C3=B6n 7 apr. 2019 17:45simondev1 via bitcoin-dev <bitcoin-dev@lists.linuxf= oundation.org> skrev:

<= div style=3D"font-family:Verdana;font-size:12.0px">

Dear bitcoin developers,

=C2=A0

New BIP: https://github.com/bitcoin/bips/pull/774=

=C2=A0

=3D=3DAbstract=3D=3D

Logarithm of transaction fee limits block size.

=C2=A0

=3D=3DMotivation=3D=3D

Keep block space small.
Waste less with spam transactions.
Auto balance Fees: Increase very low fees, Descrease very high fees.
Allow larger size when sender pays a lot.
Allow wallets to calculate/display how much average free block space there = is for each fee price.
Allow senders to have more control about how the fee/priority of their tran= saction will behave, especially in the case of increased adoption in the fu= ture.

=C2=A0

=3D=3DSpecification=3D=3D

Every transaction has to fit into the following block space:

Input variable 'FeeInSatoshiPerByte': Must be positive or 0 type: double
unit: Satishi per byte
Output:
type: uint
unit: bytes
Formula:
floor( log10( 1.1 + FeeInSatoshiPerByte ) * 1024 * 1024 )

=C2=A0

=3D=3DImplementation=3D=3D

Sort transactions by FeeInSatoshiPerByte (lowest first)
For each transaction starting from lowest FeeInSatoshiPerByte: Sum up the b= ytes 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.

=C2=A0

=3D=3DBackward compatibility=3D=3D

Soft fork: If applied AND old hardcoded block size limit is kept.
Hard fork: If applied AND old hardcoded block size limit is removed.

Regards, simondev1

=C2=A0

_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundati= on.org/mailman/listinfo/bitcoin-dev

--000000000000d8c62c0585f539b3-- 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 287F8AF0 for ; Sun, 7 Apr 2019 22:12:09 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-vs1-f49.google.com (mail-vs1-f49.google.com [209.85.217.49]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 49CA7709 for ; Sun, 7 Apr 2019 22:12:08 +0000 (UTC) Received: by mail-vs1-f49.google.com with SMTP id g127so6470287vsd.6 for ; Sun, 07 Apr 2019 15:12:08 -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:references:in-reply-to:from:date :message-id:subject:to; bh=A+26WiGQOOSD4WI3uV8g/Q6lffYhjAl2KwoQYXUQOak=; b=Amm3q4Id68Ogbp28grSfXqU4/SFAA8IBDW3hfL78Tg7syCono2bo0A2ByNJURsrwYn a9ZfOo2Gt2VHMK6YLFr1MxhPXInlr2JcD2k0SsOMovDM8E+72gEq4aT/d0WJGWXmIcao iEX6aTe0G4epF0BMPfiFdrRS3m+ywJ4KOuBT0sJABHFzwOHzFvROMIYaWc52+AK12M9s yddZxFzX18w2RdqXjZhCTnaZ72tVjeKHCC75seuzq2LwNF8ZkyInG2k9ZfjUdhwHHPA8 D29t/7S4DgTbH+SX4eEmoN9ASWVgNOZnlkDHt4JQBWiUf/3QQYfgNCzRQhoFwN5KRmI2 Ss3w== X-Gm-Message-State: APjAAAXnFwVLGf0UqspDb3oCxjTSKbbAGCpVd4GH/HAsmF7f2OE2GUiX CojZfXEF92YuXzREKKEjCoEWsLN3yTv/OhO9oI4= X-Google-Smtp-Source: APXvYqyE4raYwjWgQMOTHFKStsQSCNQmAx4mCAUrL7auJt3wG5nf+cc9Bz8GSsixPIZ2RrhoZ9HUSGHGZ4DBGCDEU8s= X-Received: by 2002:a67:ff11:: with SMTP id v17mr14595920vsp.108.1554675127423; Sun, 07 Apr 2019 15:12:07 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Bernd Jendrissek Date: Mon, 8 Apr 2019 00:11:55 +0200 Message-ID: To: simondev1 , Bitcoin Protocol Discussion Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE 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: Mon, 08 Apr 2019 01:50:39 +0000 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: Sun, 07 Apr 2019 22:12:09 -0000 On Sun, 7 Apr 2019 at 17:45, simondev1 via bitcoin-dev 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.) 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 8FC50415 for ; Mon, 8 Apr 2019 00:55:24 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-40135.protonmail.ch (mail-40135.protonmail.ch [185.70.40.135]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C7D3A623 for ; Mon, 8 Apr 2019 00:55:23 +0000 (UTC) Date: Mon, 08 Apr 2019 00:55:18 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1554684921; bh=v/1T2wqz9dZVQ5ErUUJrrV+5mWn8S+FlKaS3Hw1/uKY=; h=Date:To:From:Reply-To:Subject:In-Reply-To:References:Feedback-ID: From; b=xGMBKnrWdWSE0PNW6+a3V8tjYVdmOrfsLrFvMr6o/AWJDIq9GM70zQMcqZvTHWPmV fs3P9beFv+hsmaV/82itBsXP1oq+NqUHfS7mYR1gYrryVAEdtEimK+jz1h2YHGD9yc 84XJLFKowR+8DRSEoUonZeKiI6QD7U/bWl4t8twQ= To: simondev1 , Bitcoin Protocol Discussion From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: In-Reply-To: References: Feedback-ID: el4j0RWPRERue64lIQeq9Y2FP-mdB86tFqjmrJyEPR9VAtMovPEo9tvgA0CrTsSHJeeyPXqnoAu6DN-R04uJUg==:Ext:ProtonMail MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, FROM_LOCAL_NOVOWEL, RCVD_IN_DNSWL_LOW 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: Mon, 08 Apr 2019 01:50:47 +0000 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: Mon, 08 Apr 2019 00:55:24 -0000 Good morning simondev1, It seems the algorithm would greatly increase validation time. In particular, if the current limit is removed (as in hardforked proposal) = then a 1Tb block can be used to attack the network, since sorting would req= uire looking through the entire block. Thus, validation time would still limit the practical block sizes that can = be deployed with this. Regards, ZmnSCPxj Sent with ProtonMail Secure Email. =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original Me= ssage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 On Sunday, April 7, 2019 4:50 PM, simondev1 via bitcoin-dev wrote: > Dear bitcoin developers, > =C2=A0 > New BIP: https://github.com/bitcoin/bips/pull/774 > =C2=A0 > =3D=3DAbstract=3D=3D > Logarithm of transaction fee limits block size. > =C2=A0 > =3D=3DMotivation=3D=3D > Keep block space small. > Waste less with spam transactions. > Auto balance Fees: Increase very low fees, Descrease very high fees. > Allow larger size when sender pays a lot. > Allow wallets to calculate/display how much average free block space ther= e is for each fee price. > Allow senders to have more control about how the fee/priority of their tr= ansaction will behave, especially in the case of increased adoption in the = future. > =C2=A0 > =3D=3DSpecification=3D=3D > Every transaction has to fit into the following block space: > Input variable 'FeeInSatoshiPerByte': Must be positive or 0 > type: double > unit: Satishi per byte > Output: > type: uint > unit: bytes > Formula: > floor( log10( 1.1 + FeeInSatoshiPerByte ) * 1024 * 1024 ) > =C2=A0 > =3D=3DImplementation=3D=3D > 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. > =C2=A0 > =3D=3DBackward compatibility=3D=3D > Soft fork: If applied AND old hardcoded block size limit is kept. > Hard fork: If applied AND old hardcoded block size limit is removed. > > Regards, simondev1 > 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 DCE47CC9 for ; Tue, 9 Apr 2019 00:13:33 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-it1-f180.google.com (mail-it1-f180.google.com [209.85.166.180]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 574DBF4 for ; Tue, 9 Apr 2019 00:13:33 +0000 (UTC) Received: by mail-it1-f180.google.com with SMTP id y134so2089712itc.5 for ; Mon, 08 Apr 2019 17:13:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=UYbzxeXwemzIefQoAQxvL8RDe34T0T89CBD50+g8pgA=; b=ps9V+qU27yzpeWmuNATUvFKNcKhn8q+N8YZjUbiNeWQ3dHp1xz06iD4Ml0bn2l3/iN E4eiw6HpNX5DTKWyvicvoxF2I3Z010UIZeZxx3R3cDKJFD7u4NCWh9pQn6KvlnWDU5P3 sg8jPYHGp1xbkE24kdMHinq8Hse1jhhXyq/lHY9I0ShatE0Hf9zO2Ior5uncUwXBvL1S z/0hqeKC1krD7amlQYwMXbhPXYiyQnwMjvqNnHIlwY0hSJaBNH2Qm5lpvPvuS1bN2MR0 dyMIX2n6+W64wjjbPYT2jxY3q+oZi9leBkdVA0DBfjdYtpc0V2qnt53wLqTn/bsmO84l +xmA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=UYbzxeXwemzIefQoAQxvL8RDe34T0T89CBD50+g8pgA=; b=Mn8LdGfZfZhI1g9NLdAnndVxP2Ti0BsmX6EJJwJdQJSFPx+YA9/vUMwL304oaCi4Zi k3aN2XEL6DM9cKOQPhslQbPclukUQ5Us9yUMR9p12qsNpiYExlBLmpwmygOTrnba1FCV jt2ou3Cwak5NeL2d53WAQg9hV/hFEjLmzWAVJP65VGruWcBoUX534/QyJfx7VV085mEK wHqLZiJth2SuIAw9lrcXW/AzA3Ju+urppU2ogseyXYdHNRjC7jyaeuqqIzMaVhYh+sve iAPFFvBoOp+DSK9KE2lZCjxf/VxilmO7oBvFMQ5rUWaU+lDADVYPuqb5ScREO2UQ+NWv zcYA== X-Gm-Message-State: APjAAAXa2Hr2s72ggAZ7DJHGvdIYn5DBjrQnDOSFyVc4anATZY3xBXYt UG4W6nCMPAc5mGx8kzR7QCopukz4tS5DrJi9pDuQoByIiQk= X-Google-Smtp-Source: APXvYqxOYYnwffUOXY7AJWr4UMt2vuf8rcusUbClcfFYeSSMMkDJ9Shrx0UaVVZlFdc1jM5QMFQ31rWBjtAM06B0BUg= X-Received: by 2002:a05:660c:202:: with SMTP id y2mr24813265itj.0.1554768812640; Mon, 08 Apr 2019 17:13:32 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Omar Shibli Date: Tue, 9 Apr 2019 03:13:21 +0300 Message-ID: To: simondev1 , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="000000000000c9127505860dd207" X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE 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 Apr 2019 01:26:32 +0000 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: Tue, 09 Apr 2019 00:13:34 -0000 --000000000000c9127505860dd207 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Mining strategy is like HFT profitable strategy, you keep it close if it= =E2=80=99s interesting, and you talk about it with the whole world if it=E2=80=99s voi= d. gl. On Sun, Apr 7, 2019 at 6:45 PM simondev1 via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Dear bitcoin developers, > > New BIP: https://github.com/bitcoin/bips/pull/774 > > =3D=3DAbstract=3D=3D > Logarithm of transaction fee limits block size. > > =3D=3DMotivation=3D=3D > Keep block space small. > Waste less with spam transactions. > Auto balance Fees: Increase very low fees, Descrease very high fees. > Allow larger size when sender pays a lot. > Allow wallets to calculate/display how much average free block space ther= e > is for each fee price. > Allow senders to have more control about how the fee/priority of their > transaction will behave, especially in the case of increased adoption in > the future. > > =3D=3DSpecification=3D=3D > Every transaction has to fit into the following block space: > Input variable 'FeeInSatoshiPerByte': Must be positive or 0 > type: double > unit: Satishi per byte > Output: > type: uint > unit: bytes > Formula: > floor( log10( 1.1 + FeeInSatoshiPerByte ) * 1024 * 1024 ) > > =3D=3DImplementation=3D=3D > 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. > > =3D=3DBackward compatibility=3D=3D > Soft fork: If applied AND old hardcoded block size limit is kept. > Hard fork: If applied AND old hardcoded block size limit is removed. > > Regards, simondev1 > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --000000000000c9127505860dd207 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

=C2=A0Mining strategy is like HFT profita= ble strategy, you keep it close if it=E2=80=99s interesting, and you talk a= bout it with the whole world if it=E2=80=99s void. gl.

<= div class=3D"gmail_quote">

On Sun, Apr= 7, 2019 at 6:45 PM simondev1 via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org&g= t; wrote:

Dear bitcoin developers,

=C2=A0

New BIP: https://github.com/bitcoin/bips/pull/774

=C2=A0

=3D=3DAbstract=3D=3D

Logarithm of transaction fee limits block size.

=C2=A0

=3D=3DMotivation=3D=3D

Keep block space small.
Waste less with spam transactions.
Auto balance Fees: Increase very low fees, Descrease very high fees.
Allow larger size when sender pays a lot.
Allow wallets to calculate/display how much average free block space there = is for each fee price.
Allow senders to have more control about how the fee/priority of their tran= saction will behave, especially in the case of increased adoption in the fu= ture.

=C2=A0

=3D=3DSpecification=3D=3D

Every transaction has to fit into the following block space:

Input variable 'FeeInSatoshiPerByte': Must be positive or 0 type: double
unit: Satishi per byte
Output:
type: uint
unit: bytes
Formula:
floor( log10( 1.1 + FeeInSatoshiPerByte ) * 1024 * 1024 )

=C2=A0

=3D=3DImplementation=3D=3D

Sort transactions by FeeInSatoshiPerByte (lowest first)
For each transaction starting from lowest FeeInSatoshiPerByte: Sum up the b= ytes 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.

=C2=A0

=3D=3DBackward compatibility=3D=3D

Soft fork: If applied AND old hardcoded block size limit is kept.
Hard fork: If applied AND old hardcoded block size limit is removed.

Regards, simondev1

=C2=A0

_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev

--000000000000c9127505860dd207-- 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 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.)

X-UI-Message-Type: mail X-Priority: 3 X-Provags-ID: V03:K1:BvcUnXTgLNd+ZacqKupnEbSp3Ds4EKjctL2q7KcocyopEqFP0TLa1b0Gq2XfvaYhkjZBq lGo4c4xekPkTFKYL8Un+oiwp6ji/5V5TTed4sCu9hUqnsqg8Cv0aSKB/muKm1rEXoHlOOWK9ghTT Qr+oDfvAgd5Rn9htlkCIZRB7KwEWgZXQGbUZ6xWaOI3PYEpsbR63X/KVFCCqFVSbrDVJEmn09h/k nw1Gt0wmZZZW3wSUPFxhdUWqnNaQ3QCLKNqr0l9rtMLS+meSQZwRT/ybZJUNeWvlQevRQY6lPeVq V0= X-UI-Out-Filterresults: notjunk:1;V03:K0:aQRO3Jbc2MA=:oRK1HQh+hsEqrrAXHpugsU F9eFw/jrca3hV5E7uHeuIFGFfJFoXwGGtICjdmaS5XyJOf3b0k8ye8tOgN5+whOZQUe33ddSg WWjXps/ZdV5ZQYc7NhuGHprHV9E+6hpRNI/SKKue1+hJMgdzSDF08NBc+n41cptFZaHmXwByp 8/DsTmO0dhHmXD+ZbFvOTONB8JADnWt+nUdQmVqweznk/IgK1MvGVBP7/eRBvF+vOlIvVS6c3 Cfl1VnR15Bi5/uFVVzODx9/l8QDhlxny9aOo4IFaKRKRfSH1tA3DcM21z6FeEmllkwPIHvxCw Ij0LpVp1FmZ36slDxBc78WuOvciTummhj6v4Iixk4V0qEv21qg/P8lvrWlni3lInUmtF3oWMS U/iwtm2i9+dC6cwayBjMCmWmq2kYjuMzPLYBBuIulFEMkjZkwcWeQt7w5DbYOh32RPZ2Ap2SE rOSefWlDIQXi1LFy4pB7n9O4OllTGMQD/Jr2Ju0CQQTQ2EiJ5qcf4aLCazDWhpppz2sRHgyzq SE8h2+/PhB3jBwQFLBXrQQbGXpVnCM+6/PEEi1iL88tntysAFIx/RaPKv4qKnPtQgj9mR45CK jSNdky5+dKYsk= 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:50:04 -0000

True in case of hardfork to remove the current limit we still need a limit of lets say 8 Mbyte. To achive a valid 8MB block with this formula, the block would need to contain about 8 million btc fees. This will never happen. So probably a hard limit of 8MB would be good to avoid 1TB attacks.

Regards,

Gesendet: Montag, 08. April 2019 um 02:55 Uhr
Von: "ZmnSCPxj" <ZmnSCPxj@protonmail.com>
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

Good morning simondev1,

It seems the algorithm would greatly increase validation time.
In particular, if the current limit is removed (as in hardforked proposal) then a 1Tb block can be used to attack the network, since sorting would require looking through the entire block.
Thus, validation time would still limit the practical block sizes that can be deployed with this.

Regards,
ZmnSCPxj

Sent with ProtonMail Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Sunday, April 7, 2019 4:50 PM, simondev1 via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:

> Dear bitcoin developers,
>
> New BIP: https://github.com/bitcoin/bips/pull/774
>
> ==Abstract==
> Logarithm of transaction fee limits block size.
>
> ==Motivation==
> Keep block space small.
> Waste less with spam transactions.
> Auto balance Fees: Increase very low fees, Descrease very high fees.
> Allow larger size when sender pays a lot.
> Allow wallets to calculate/display how much average free block space there is for each fee price.
> Allow senders to have more control about how the fee/priority of their transaction will behave, especially in the case of increased adoption in the future.
>
> ==Specification==
> Every transaction has to fit into the following block space:
> Input variable 'FeeInSatoshiPerByte': Must be positive or 0
> type: double
> unit: Satishi per byte
> Output:
> type: uint
> unit: bytes
> Formula:
> floor( log10( 1.1 + FeeInSatoshiPerByte ) * 1024 * 1024 )
>
> ==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.
>
> ==Backward compatibility==
> Soft fork: If applied AND old hardcoded block size limit is kept.
> Hard fork: If applied AND old hardcoded block size limit is removed.
>
> Regards, simondev1
>