From: "Odinn Cyberguerrilla" <odinn.cyberguerrilla@riseup•net>
To: "Mike Hearn" <mike@plan99•net>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Fee drop
Date: Tue, 25 Feb 2014 14:43:58 -0800 [thread overview]
Message-ID: <4aa09921d781ac54695325935fa36920.squirrel@fulvetta.riseup.net> (raw)
In-Reply-To: <CANEZrP0pDjHr3v2w_zKnME+6GjVdvV5HYjrLH7xthbNdBniK4g@mail.gmail.com>
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 acted on in any way shape or form. Thanks for this
discussion, things to think about.... am watching, listening (...)
> 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 and the orphan costs
> go
> down. Nodes that are encountering memory pressure can increase their min
> relay fee locally until their usage fits inside their resources. It's
> annoying to do this by hand but by no means infeasible.
>
> The other is that the total value of transactions even with the lower fee
> is not outweighed by orphan costs. The value of a transaction is higher
> than its simple monetary value - the fact that Bitcoin is useful, growing
> and considered cheap also has a value which is impossible to calculate,
> but
> we know it's there (because Bitcoin does not exist in a vacuum and has
> competitors). In this case miners stop including lots of useful
> transactions that represent desired economic activity and are put under
> pressure by the community to change their policies. If all miners do this
> and making small blocks is considered errant behaviour, then we're back to
> the same situation we're in today.
>
> The possibility you're worried about - that someone does a DoS attack by
> flooding the network with small transactions - is only an issue in the
> first situation, and it is by no means the easiest or cheapest way to DoS
> Bitcoin. We all want to see more DoS resistance but basically any change
> to
> Bitcoin can be objected to on anti-DoS grounds at the moment, and this
> will
> remain the case until someone steps up to spend significant time on
> resource scheduling and code audits.
>
next prev parent reply other threads:[~2014-02-25 22:44 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-25 4:41 Peter Todd
2014-02-25 7:34 ` naman naman
2014-02-25 12:40 ` Odinn Cyberguerrilla
2014-02-25 12:55 ` Mike Hearn
2014-02-25 14:49 ` Peter Todd
2014-02-25 16:55 ` Mike Hearn
2014-02-25 17:13 ` Peter Todd
2014-02-25 18:09 ` Jeremy Spilman
2014-02-28 11:18 ` Peter Todd
2014-02-25 22:43 ` Odinn Cyberguerrilla [this message]
2014-02-26 22:51 ` Jeff Garzik
2014-02-28 4:50 ` Troy Benjegerdes
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4aa09921d781ac54695325935fa36920.squirrel@fulvetta.riseup.net \
--to=odinn.cyberguerrilla@riseup$(echo .)net \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=mike@plan99$(echo .)net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox