On Tue, Feb 25, 2014 at 10:09:23AM -0800, Jeremy Spilman wrote:
> If I understand correctly, the risk here is this would open a
> historically large discrepancy between MIN_RELAY and the expected
> minimum fee to actually obtain block inclusion. I don't know if
> that's true, but I think that's wha
On Mon, Feb 24, 2014 at 11:41:16PM -0500, Peter Todd wrote:
> So, just to be clear, we're adding, say, a memory limited mempool or
> something prior to release so this fee drop doesn't open up an obvious
> low-risk DDoS exploit right? As we all know, the network bandwidth
> DoS attack mitigatio
Just pushed out a mempool janitor change to
https://github.com/bitcoin/bitcoin/pull/3753 The goal was to create
a simple bolt-on change, and /not/ rewrite the mempool code.
I'll be running some metrics on what does and does not get into the
mempools of my public nodes for 48 hours, ending Friday
Am suggesting a (possible) mitigation of [possible flooding, etc], via
some kind of discussion (potentially process BIP, related to bundling and
/ or randomization) not now, but down the road. However, needs more
thought and analysis (you mentioned code audit?) before it could be
floated around or
If I understand correctly, the risk here is this would open a historically large discrepancy between MIN_RELAY and the expected minimum fee to actually obtain block inclusion. I don't know if that's true, but I think that's what Peter is saying makes it different this time. The relay network does
On Tue, Feb 25, 2014 at 10:25:58PM +0530, Mike Hearn wrote:
Well, I've done my responsible disclosure, and I've got better things to
do than argue with wishful thinking.
> There are two possibilities.
>
> One is that the value of transactions with the new lower fee is outweighed
> by increased o
There are two possibilities.
One is that the value of transactions with the new lower fee is outweighed
by increased orphan costs and miners refuse to include them en-masse.
Wallet authors lose the staring match and go back to setting higher fees
until such a time as block propagation is optimised
On Tue, Feb 25, 2014 at 06:25:18PM +0530, Mike Hearn wrote:
> Given that the fee drop puts fees in "real" (i.e. dollar) terms back to
> where they were some months ago, it seems odd to claim this is creating
> vulnerabilities that didn't exist in the previous version. The cost of an
> attack would
Given that the fee drop puts fees in "real" (i.e. dollar) terms back to
where they were some months ago, it seems odd to claim this is creating
vulnerabilities that didn't exist in the previous version. The cost of an
attack would be the same as before.
-
> So, just to be clear, we're adding, say, a memory limited mempool or
> something prior to release so this fee drop doesn't open up an obvious
> low-risk DDoS exploit right? As we all know, the network bandwidth
> DoS attack mitigation strategy relies on transactions we accept to
> mempools ge
I quite agree with Peter, anything that can be exploited will be exploited,
just like malleability was.
On Tue, Feb 25, 2014 at 10:11 AM, Peter Todd wrote:
> So, just to be clear, we're adding, say, a memory limited mempool or
> something prior to release so this fee drop doesn't open up an obv
So, just to be clear, we're adding, say, a memory limited mempool or
something prior to release so this fee drop doesn't open up an obvious
low-risk DDoS exploit right? As we all know, the network bandwidth
DoS attack mitigation strategy relies on transactions we accept to
mempools getting mine
12 matches
Mail list logo
