From: Omar Shibli <omarshib@gmail•com>
To: simondev1 <random@gmx•ch>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] new BIP: Self balancing between excessively low/high fees and block size
Date: Tue, 9 Apr 2019 03:13:21 +0300 [thread overview]
Message-ID: <CAE3EOfixRro2BpTLmjOd60e-wBA8ZkTUXYZgdjaYWmJ-cec7PQ@mail.gmail.com> (raw)
In-Reply-To: <trinity-9a1b0170-a250-4c06-a8e1-0f281499c4da-1554627046019@3c-app-gmx-bs53>
[-- Attachment #1: Type: text/plain, Size: 1946 bytes --]
Mining strategy is like HFT profitable strategy, you keep it close if it’s
interesting, and you talk about it with the whole world if it’s void. 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
>
> ==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
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
[-- Attachment #2: Type: text/html, Size: 3095 bytes --]
prev parent reply other threads:[~2019-04-09 0:13 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-07 8:50 simondev1
2019-04-07 18:52 ` Natanael
2019-04-07 22:11 ` Bernd Jendrissek
2019-04-12 15:45 ` simondev1
2019-04-08 0:55 ` ZmnSCPxj
2019-04-12 15:49 ` simondev1
2019-04-09 0:13 ` Omar Shibli [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAE3EOfixRro2BpTLmjOd60e-wBA8ZkTUXYZgdjaYWmJ-cec7PQ@mail.gmail.com \
--to=omarshib@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=random@gmx$(echo .)ch \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox