New BIP: Logarithm of transaction fee limits block size

simondev1 commented at 4:20 pm on March 28, 2019: none

Update README.mediawiki d7397ff38c

Create bip-0323.mediawiki f342c240cb

Update bip-0323.mediawiki f2642a4aba

Update bip-0323.mediawiki a0cf2e3745

Update bip-0323.mediawiki 7e4536baa6

Update bip-0323.mediawiki f507d7e7e3

Update bip-0323.mediawiki 0d9a4a96dd

Update bip-0323.mediawiki e8d50a0580

Update bip-0323.mediawiki d59f48e29a

Update bip-0323.mediawiki 72f212b645

Update bip-0323.mediawiki 975d3beb73

Update bip-0323.mediawiki 70d05c43b8

Update bip-0323.mediawiki cd4227a3a9

Update bip-0323.mediawiki 788241d333

Update bip-0323.mediawiki 2f586e1659

Update bip-0323.mediawiki da60099934

Update bip-0323.mediawiki d86d2afddc

Update bip-0323.mediawiki 679cefe169

Update bip-0323.mediawiki 7be13ec6b1

Update bip-0323.mediawiki 673649b1ee

Update bip-0323.mediawiki e4818ae40b

Update README.mediawiki ff5ca07cbf

Update README.mediawiki a943d7576b

Update bip-0323.mediawiki af44b5ad39

Update README.mediawiki 18526ad437

Update bip-0323.mediawiki 71e5700075

Update README.mediawiki 9ee41aa913

Update README.mediawiki 650a6cea71

Update and rename bip-0323.mediawiki to bip-XXXX.mediawiki ba3b679e7b

luke-jr renamed this:
~~BIP323: Logarithm of transaction fee limits block size~~
New BIP: Logarithm of transaction fee limits block size
on Mar 29, 2019

luke-jr commented at 5:41 am on March 29, 2019: member

This is NOT BIP 323!

luke-jr added the label New BIP on Mar 29, 2019

luke-jr commented at 5:53 am on March 29, 2019: member

What is the subject of the bitcoin-dev mailing list discussion of this proposal?

Technical soundness: What prevents miners from providing inputs to coinjoin with for fake fees?

Backward compatibility: Talks about a hardfork if “everything applied”, but I don’t see that in the specification.

Update bip-XXXX.mediawiki 30075515d5

Update bip-XXXX.mediawiki 5f7f779725

simondev1 commented at 7:00 am on March 29, 2019: none

Changed to BIP-XXXX

Mailing List: Not yet sent. I just subscribed to the mailing list. Will do that the next few days.

Technical soundness: The same thing that prevents that today. (Not exactly sure though what you meant.) The incentive of miners is to fill the block only with transactions of largest fees, same as today, there is no incentive to put 1sat/byte transaction into the chain when the block can be filled with 30sat/byte transactions.

Backward compatibility: Improved Text

luke-jr commented at 7:11 am on March 29, 2019: member

Mailing List: For the future, please see BIP 2 - mailing list discussion comes before opening a PR or asking for a number assignment.

Technical soundness: Today, fees are not used in any consensus-critical checks, other than to allow the miner to claim them and no higher amount. So a miner giving himself a fee is simply a wash. With your proposal, however, miners now can game this new algorithm by giving themselves fees in others’ transactions.

luke-jr commented at 7:13 am on March 29, 2019: member

(BTW, it’s unclear how this works since there is not currently a block size limit, but only a block weight limit. eg, does your algorithm enforce against weight or size?)

simondev1 commented at 7:19 am on March 29, 2019: none

Fees come out of unspent satoshis in transactions. A miner cannot just increase fees of a transaction. Such a changed transaction would not be signed correctly. There is no change regarding this.

luke-jr commented at 7:32 am on March 29, 2019: member

They can with cooperation of the transaction sender(s) using a CoinJoin.

simondev1 commented at 8:01 am on March 29, 2019: none

Block weight vs block size: This is a good question. Some developer more familiar with this should decide that.

CoinJoin is not affected by this BIP. CoinJoin is just a transaction with a known fee. See https://en.bitcoin.it/wiki/CoinJoin

luke-jr commented at 8:17 am on March 29, 2019: member

But CoinJoins do break the assumptions of this BIP (that the fee amount can be known reliably).

Update bip-XXXX.mediawiki c22371084e

Update bip-XXXX.mediawiki 3212bfff5a

Update bip-XXXX.mediawiki 71301a5b12

Added comments from mails 67c917bd83

simondev1 commented at 8:31 am on April 13, 2019: none

Mailing list subject: “new BIP: Self balancing between excessively low/high fees and block size” See April thread

CoinJoin: That’s not the case. CoinJoin is not affected by this BIP. (We do not need know what CoinJoin user payed what part of the fee. But we know exactly the total fee of the transaction just like any normal transaction.)

Update bip-XXXX.mediawiki 678564e90a

Generated exact table ed1c7c6d04

Improve naming in code b171666146

Update bip-XXXX.mediawiki 50e184e719

Update bip-XXXX.mediawiki 0900449f44

luke-jr commented at 7:05 pm on June 1, 2020: member

This still has a technical soundness problem (miners fudging fees via CoinJoin) to address before it can be assigned a number, and needs a copyright notice/license.

Update bip-XXXX.mediawiki 0fd25726ad

Added Incentive/technical soundness, improved math 53a73243bc

junderw commented at 1:58 pm on July 11, 2020: contributor

How is it “staking BTC for a larger block?”

It’s not staking if they have nothing to lose.

simondev1 commented at 4:36 pm on July 11, 2020: none

Yes true. Didn’t know how to describe it better.

Removed a sentence about staking 4ae17d530e

in bip-XXXX.mediawiki:419 in 0fd25726ad outdated

415@@ -415,18 +416,21 @@ The first part of the table shows how spam is reduced. The part where total sum
416 
417 ==Backward compatibility==
418 
419-Soft fork: If applied AND old hardcoded block size limit is kept.
420+Soft fork: If applied AND old hardcoded block size limit is kept. (Note: This BIP will most probably not establish itself as softfork among miners, because their money driven incentive is to create a max sized block instead a smaller one.)

luke-jr commented at 0:17 am on August 1, 2020:

Miners don’t have a say in softforks.
This isn’t true.

simondev1 commented at 9:28 am on November 15, 2020:

1. Miners don't have a say in softforks.

2. This isn't true.

Disagree.

luke-jr commented at 0:19 am on August 1, 2020: member

Didn’t know how to describe it better.

It’s a fundamental flaw in your proposal…

simondev1 commented at 9:40 am on November 15, 2020: none

Didn’t know how to describe it better.

It’s a fundamental flaw in your proposal…

Disagree.

simondev1 commented at 4:14 pm on February 8, 2023: none

I think this proposal still is a good idea.

in bip-XXXX.mediawiki:17 in 4ae17d530e

12+
13+==Abstract==
14+
15+Logarithm of transaction fee limits block size.
16+
17+If a sender is willing to pay a large fee, then a transaction may be allowed in a block even if blocksize for lower fee-transactions is full. Yet the blocksize is limited harshly by a formula.

murchandamus commented at 7:19 pm on April 30, 2024:

The abstract is concise, but does not sufficiently describe either the solution or the technical issue being addressed.

in bip-XXXX.mediawiki:26 in 4ae17d530e

21+# Keep block space small.
22+# Waste less with spam transactions.
23+# Auto balance Fees: Increase very low fees, Descrease very high fees.
24+# Allow larger size when sender pays a lot.
25+# Allow wallets to calculate/display how much average free block space there is for each fee price bucket.
26+# 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.

murchandamus commented at 7:21 pm on April 30, 2024:

The motivation falls short in describing what inadequacies of the existing protocol are being addressed by this BIP.

in bip-XXXX.mediawiki:30 in 4ae17d530e

25+# Allow wallets to calculate/display how much average free block space there is for each fee price bucket.
26+# 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.
27+
28+==Specification==
29+
30+Every transaction has to fit into the following block space:

murchandamus commented at 7:22 pm on April 30, 2024:

Please describe in detail the syntax and semantics of your proposal.

in bip-XXXX.mediawiki:36 in 4ae17d530e

31+    Input variable 'transactionFee':
32+      type: integer
33+      unit: Satoshi
34+    Input variable 'transactionSize':
35+      type: integer
36+      unit: bytes

murchandamus commented at 7:24 pm on April 30, 2024:

Transaction size was retired as a limit to blocks with the activation of segwit. Transactions today are limited by weight. Please update your proposal to clarify which properties of transactions are relevant to your proposal.

murchandamus changes_requested

murchandamus commented at 7:51 pm on April 30, 2024: contributor

Hello Simon,

at this time your draft does not meet the requirements for a BIP. In my review I noticed that the document does not fulfill the standards described in BIP2, e.g. some headers in the preamble and relevant sections are missing, and the content falls short of fully communicating the solution and addressed issue.

If you are still working on this, I would recommend substantially expanding the explanation of your idea. Possibly a more comprehensive description to the mailing list could garner interest of potential collaborators.

If this submission is no longer being worked on, or substantial improvements are not to be expected, I would recommending closing this PR, as I do not anticipate the proposal being issued a number or merged in its current state.

murchandamus added the label PR Author action required on May 8, 2024

murchandamus commented at 8:09 pm on November 14, 2024: contributor

I am closing this pull request, because it has not made progress in over four years, and my review has been left unanswered for over six months. If you are still working on this, please request reopening or open another pull request.

murchandamus closed this on Nov 14, 2024

New BIP: Logarithm of transaction fee limits block size #774