new BIP: Self balancing between excessively low/high fees and block size

new BIP: Self balancing between excessively low/high fees and block size
2019-04-07 18:52 ` Natanael
                   ` (3 more replies)
  
From: simondev1 @ 2019-04-07  8:50 UTC (permalink / raw)
  To: bitcoin-dev

[-- Attachment #1: Type: text/html, Size: 2053 bytes --]

 permalink raw reply	[|nested]
2019-04-07 18:52 ` 
                   ` 
  
From: simondev1 @ 2019-04-07  8:50 UTC (permalink / raw)
  To: bitcoin-dev

[-- Attachment #1: Type: text/html, Size: 2053 bytes --]

 permalink raw reply	[|nested]
* 
  2019-04-07  8:50 [bitcoin-dev] new BIP: Self balancing between excessively low/high fees and block size simondev1

  2019-04-07 22:11 ` 
                   ` 
  3 siblings, 0 replies; 7+ messages in thread
From: Natanael @ 2019-04-07 18:52 UTC (permalink / raw)
  To: simondev1, Bitcoin Dev

[-- Attachment #1: Type: text/plain, Size: 2027 bytes --]

Related ideas previously submitted by me;

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

Title: Block size adjustment idea - expedience fees + difficulty scaling
proportional to block size (+ fee pool)

Den sön 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
>
> ==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: 3314 bytes --]

^ permalink raw reply	[|nested] 7+ messages in thread
2019-04-07  8:50 [bitcoin-dev] new BIP: Self balancing between excessively low/high fees and block size simondev1
  2019-04-07 18:52 ` Natanael
  2019-04-07 22:11 ` Bernd Jendrissek

  2019-04-12 15:49   ` simondev1
  2019-04-09  0:13 ` Omar Shibli
  
From: ZmnSCPxj @ 2019-04-08  0:55 UTC (permalink / raw)
  To: simondev1, Bitcoin Protocol Discussion

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
>




 permalink raw reply	[|nested]
2019-04-07  8:50 [bitcoin-dev] new BIP: Self balancing between excessively low/high fees and block size simondev1
                   ` (2 preceding siblings ...)
  2019-04-08  0:55 ` ZmnSCPxj

  
From: Omar Shibli @ 2019-04-09  0:13 UTC (permalink / raw)
  To: simondev1, Bitcoin Protocol Discussion

[-- 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 --]

 permalink raw reply	[|nested]
2019-04-07 22:11 ` Bernd Jendrissek

  
From: simondev1 @ 2019-04-12 15:45 UTC (permalink / raw)
  To: Bernd Jendrissek;  Bitcoin Protocol Discussion

[-- Attachment #1: Type: text/html, Size: 2157 bytes --]

 permalink raw reply	[|nested]
2019-04-08  0:55 ` ZmnSCPxj

  
From: simondev1 @ 2019-04-12 15:49 UTC (permalink / raw)
  To: ZmnSCPxj;  Bitcoin Protocol Discussion

[-- Attachment #1: Type: text/html, Size: 3725 bytes --]

 permalink raw reply	[|nested]