>
> The proposed fix is to add a new rule on how
> fees are handled. Some amount of every fee should be considered as burned
> and can never be spent. I will propose 50% of the fee here, but there may
> be better numbers that can be discovered prior to putting this into place.
> If we'd like mine
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
On Tue, Jun 9, 2015 at 2:36 PM, Gavin Andresen
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 a
That does sound good on the surface, but how do we enforce #1 and #2? They
seem to be unenforceable, as a miner can adjust the size of the memory pool in
his local source.
From: Gavin Andresen
Sent: Tuesday, June 09, 2015 6:36 AM
To: Loi Luu
Cc: Raystonn . ; Bitcoin Dev
Subject: Re: [Bitcoin
On Tue, Jun 9, 2015 at 1:52 PM, Raystonn . wrote:
> That does sound good on the surface, but how do we enforce #1 and #2?
> They seem to be unenforceable, as a miner can adjust the size of the memory
> pool in his local source.
>
It doesn't have to be enforced. As long as a reasonable percenta
You are right of course. This will work. I like this idea more than my own
proposed fix, as it doesn’t make any big changes to the economics of the system
in the way that burning would have.
From: Gavin Andresen
Sent: Tuesday, June 09, 2015 11:25 AM
To: Raystonn .
Cc: Loi Luu ; Bitcoin Dev
On Mon, Jun 08, 2015 at 06:53:54PM -0400, Kristov Atlas wrote:
Two other things:
> On Sat, Jun 6, 2015 at 10:35 PM, Peter Todd wrote:
>
> > Why mention SIGHASH_SINGLE at all? Its use-case is highly specialized
> > protocols; you haven't taken into account the needs of those protocols.
> > For
Tier Nolan writes:
> What are the use cases for relative lock time verify? I have 1 and I think
> that is the kind of thing it is useful for.
>
> I think that most cases are just to guarantee that the other party has a
> chance to react. This means that 8191 blocks should be more than enough
> (
8 matches
Mail list logo
