015 11:25 AM
> *To:* Raystonn .
> *Cc:* Loi Luu ; Bitcoin Dev
>
> *Subject:* Re: [Bitcoin-development] New attack identified and potential
> solution described: Dropped-transaction spam attack against the block size
> limit
>
> On Tue, Jun 9, 2015 at 1:52 PM, Raystonn .
Subject: Re: [Bitcoin-development] New attack identified and potential solution
described: Dropped-transaction spam attack against the block size limit
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
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
: [Bitcoin-development] New attack identified and potential solution
described: Dropped-transaction spam attack against the block size limit
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
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
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
>
> 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
On Mon, Jun 08, 2015 at 06:06:00PM -0400, Bob McElrath wrote:
> There was this wonderful technology invented a few years ago to deal with
> spam. It's called Hashcash. All these hacky heuristics like block size are
> just dancing around the problem, and the natural solution is already present
>
On Mon, Jun 08, 2015 at 10:13:10PM +, Patrick Mccorry (PGR) wrote:
> With the 0.01mBTC/KB minimum
> relay fee and $230 USD/BTC that works out to about $2.3kUSD/GB of ram
>
> IIRC, the fee is 0.1mBTC, so it's $23/MB (assuming 1,000 tx * 2.3 cents) and
> $23k/GB (assuming $23 * 1000, as each $2
There was this wonderful technology invented a few years ago to deal with spam.
It's called Hashcash. All these hacky heuristics like block size are just
dancing around the problem, and the natural solution is already present in
bitcoin: smaller blocks, (down to the point of individual transacti
On Mon, Jun 08, 2015 at 02:33:54PM -0700, Raystonn . wrote:
> > the attack would be expensive.
>
> For attacks being waged to destroy Bitcoin by filling all blocks with spam
> transactions, the attack succeeds when the attacker is well funded. This
> gives well-funded private and/or public enti
ing.
From: Patrick Mccorry (PGR)
Sent: Monday, June 08, 2015 2:21 PM
To: Raystonn .
Cc: Bitcoin Dev
Subject: Re: [Bitcoin-development] New attack identified and potential solution
described: Dropped-transaction spam attack against the block size limit
If I were a miner under this attack, I wo
On Mon, Jun 08, 2015 at 02:14:01PM -0700, Raystonn . wrote:
> > there is no memory pool cap currently
>
> Real hardware does not have an infinite amount of RAM. Memory pool sizes
> cannot grow unbounded. Some transactions with insufficient fees do get
> dropped today after many hours.
Actuall
To: Raystonn .
Cc: Bitcoin Dev
Subject: Re: [Bitcoin-development] New attack identified and potential
solution described: Dropped-transaction spam attack against the block size
limit
Please correct me if I'm wrong (hopefully understood it). I don't think
normal users would need to pay a hi
When implemented, the block size limit was put in place to prevent the
potential for a massive block to be used as an attack to benefit the miner
of that block. The theory goes that such a massive block would enrich its
miner by delaying other miners who are now busy downloading and validating
15 matches
Mail list logo
