Tier Nolan [ARCHIVE] on Nostr: 📅 Original date posted:2015-06-09 📝 Original message:On Tue, Jun 9, 2015 at ...
📅 Original date posted:2015-06-09
📝 Original message:On Tue, Jun 9, 2015 at 2:36 PM, Gavin Andresen <gavinandresen at gmail.com>
wrote:
> How about this for mitigating this potential attack:
>
> 1. Limit the memory pool to some reasonable number of blocks-worth of
> transactions (e.g. 11)
> 2. If evicting transactions from the memory pool, prefer to evict
> transactions that are part of long chains of unconfirmed transactions.
> 3. Allow blocks to grow in size in times of high transaction demand.
>
>
I think 2 should just be fee per kB. If the pool is full and a transaction
arrives, it has to have a fee per kB that is higher than the lowest
transaction in the pool.
The effect is that the fee per kB threshold for getting a transaction into
the memory pool increases as the attack proceeds. This means that the cost
to maintain the attack increases.
With replace by fee, the new transaction would have to have a fee that is
more than a fixed amount more than the lowest already in the pool. I think
the replace by fee code already does this. This prevents transactions with
fees that increase by 1 Satoshi at a time being relayed.
For allowing large blocks when block space is in high demand, you could
limit the average block size.
If the average was set to 1MB, the rule could be that blocks must be 2MB or
lower and the total size of the a block and the previous 99 must be 100MB
or lower. This gives an average of 1MB per block, but allows bursts.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150609/5034b5a7/attachment.html>;
📝 Original message:On Tue, Jun 9, 2015 at 2:36 PM, Gavin Andresen <gavinandresen at gmail.com>
wrote:
> How about this for mitigating this potential attack:
>
> 1. Limit the memory pool to some reasonable number of blocks-worth of
> transactions (e.g. 11)
> 2. If evicting transactions from the memory pool, prefer to evict
> transactions that are part of long chains of unconfirmed transactions.
> 3. Allow blocks to grow in size in times of high transaction demand.
>
>
I think 2 should just be fee per kB. If the pool is full and a transaction
arrives, it has to have a fee per kB that is higher than the lowest
transaction in the pool.
The effect is that the fee per kB threshold for getting a transaction into
the memory pool increases as the attack proceeds. This means that the cost
to maintain the attack increases.
With replace by fee, the new transaction would have to have a fee that is
more than a fixed amount more than the lowest already in the pool. I think
the replace by fee code already does this. This prevents transactions with
fees that increase by 1 Satoshi at a time being relayed.
For allowing large blocks when block space is in high demand, you could
limit the average block size.
If the average was set to 1MB, the rule could be that blocks must be 2MB or
lower and the total size of the a block and the previous 99 must be 100MB
or lower. This gives an average of 1MB per block, but allows bursts.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150609/5034b5a7/attachment.html>;