Re: [bitcoin-dev] new BIP: Self balancing between excessively low/high fees and block size
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" An: simondev1 , "Bitcoin Protocol Discussion" 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 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
Re: [bitcoin-dev] new BIP: Self balancing between excessively low/high fees and block size
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" An: simondev1 , "Bitcoin Protocol Discussion" 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 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.) ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] new BIP: Self balancing between excessively low/high fees and block size
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 > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
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 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.) ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
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 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
Re: [bitcoin-dev] new BIP: Self balancing between excessively low/high fees and block size
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 > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] new BIP: Self balancing between excessively low/high fees and block size
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
