Not so much, in that the fee required to get into the mempool in the first place goes up as transactions are dropped out; at least with the limited mempool in 0.12.  To the extent that a bigger block makes spam attacks more expensive it's only really through the action of making it much cheaper to inflict additional storage-in-perpetuity on the network. So far, the non-trivially funded spam attacks that we've seen have not been successful in driving the feel levels required to bypass them above negligible cents per transaction levels (e.g. significantly cheaper than what credit card networks charge merchants per transaction).... though obviously this has limits.

Right now, measuring the differential time it takes for mining pools to switch the blocks they're working on vs block size suggests an effective transfer rate of 723kbit/sec (less shockingly slow when you consider how inefficient TCP is for bursty conditions across links with worldwide latency), This is the amount of time it took for a block to reach half the monitored public pool's stratum endpoints after reaching the first one vs blocksize:  https://people.xiph.org/~greg/sp2.png  (Matt more recently did a similar measurement of relay network behavior and reached a similar but somewhat lower throughput).   If you take that offset (2.491s) and data rate, and drop it into formula for subsidy income loss cost for the last byte of a megabyte block, the break-even feerate is 0.00045054 BTC/KB. So that suggests that at least lower hashrate miners are accepting transactions at a price low enough to be a net-loss currently. (It may not be the case; e.g. if the low hashrate miners are all fast. and the high hashrate miners are all slow, or low hashrate doesn't process as many transactions; and the data is all over the map... etc.)

Implemented in Bitcoin Core git master a couple months ago, will be in 0.12; along with many other resource control tools. Though if widely used it will further congest getting blocks to begin with. It's a good trade-off, but not without costs. None of this is magic: cutting down this source of traffic or that is mostly just constant factor reductions. To operate the system needs a safety margin, and we're bumping up against actual limits.

You weren't looking hard enough , it's called -maxuploadtarget   see also doc/reduce-traffic.md (though not all of the features are documented yet).   (amusingly, this was one of the relatively few PR's that Mike Hearn commented on-- opposing it.)

This was one of the big fallacies involved in the "crash landing" spin by Gavin and Hearn; this notion that Bitcoin would willfully commit suicide.  Cranking the scale ahead of addressing scaliablity is/was controversial (not just among the most technical, though it's nearly universal there); but if it were strongly _necessary_, and better than the harm of not; then it would no longer be. That we're not there now, shows it isn't. QED.  And there is a tone of activity gone on to improve scalablity at all levels of the system, from micro optimizations, to protocol design.

Nothing wrong for paying for coffee with Bitcoin or even the bitcoin network. But to whatever extent there is a choice between monetary sovereignty and direct blockchain small retail sales-- the latter can be replaced using a lot of different mechanisms (for coffee? even centralized ones, for godssakes!); and the former cannot...   I don't really think there is a fundamental mutual exclusion, but avoiding it will require being smarter, and not just cramming things in. Bitcoin: It's not a big truck.

Of more concern than "coffee" is transactions which have nothing to do with Bitcoin, transfer no Bitcoin value; and are just stuffing data into the bitcoin network because it's available; and some people have been going around selling the idea of ignoring the Bitcoin currency and saying that the system is just a big public database. This sort of stuff is out of scope for the Bitcoin system and endangers it survival when the cost of carting around a zillion 'stock transfer' zero value txouts overwhelms the public's interest in Bitcoin. ... and they've been a major driver for calls to remove Bitcoin's resource controls. I think totally separate assets need to have their own networks and fates, or otherwise one becomes an externalized cost on the other and can act as dead weight that removes the viability of the combined system.

Bitcoin also had a 250kb limit at the time, implemented as a soft-rule by miners rather than a hard protocol rule. If you take the current system with a 2010 client (and much less a circa 2010 computer) it will likely not keep up with the network (if you try, let me know in a month when you complete the initial block download... ). The limits then were already set in a forward looking manner and we have been scrambling to keep up with the network as it's grown into them.

This is ignorant of the total costs of operating a reliable production grade system in a commercial environment... including the need to be nowhere near capacity at any time even when run on underspeced/io-starved/misconfigured mystery-meat hosting in order to make sure that nothing especially clever or difficult is required so that you can employ commonly available ham-sandwiches as devops.

This may not be as true for businesses that really consider Bitcoin to be central to their business-- but, as a bitcoin-seriousness proxy, how many non-mining Bitcoin companies do you know of that mine and participate in the network consensus? (I know of only one, ahem; and it seems like in not to long the same may apply for running full nodes)... Ultimately if the system is only usable in a way that preserves its political and security properties by those who are those who are the "most serious" (and politically motivated) then it will not be a success as a decentralized system.  It's not good enough to be accessible to some, to achieve decentralization it has to be broadly accessible.

There are many factors standing in the way of that; including indifference and a lack of education but resource impacts absolutely play a part of it. You don't see people widely outsourcing their DHCP daemons, though they're incidental to their business. Why isn't a Bitcoin node as invisible as a DHCP server? Go show me a DHCP server that uses tens of gigs of storage, hundreds of gigs of transfer, gigabytes of ram, significant amounts of CPU, etc. and all these demands constantly growing.

One of the reasons I think that XT has been as much of a flop as it has, so quickly, is that many of the people persuaded by the eloquent rants of misleading simplicity went and actually ran a Bitcoin node; and encountered the same costs and annoyances that users have been complaining about heavily since the soft limits were cranked... and lost their conviction. I know this is true for some, but I wouldn't be surprised if it were a more general pattern.(I also suspect that many, though probably not all, the people complaining about DOS attacks weren't just seeing the ordinary load that every other node sees; including the "attack like" traffic from people trying to trace transaction origins-- even I thought someone was attacking Core nodes and changed to identify as XT and saw no difference in traffic)... plus the whole, "unlimited blocks are great, so long as someone else is paying the cost", which doesn't actually work...

Not so, the merchant can simply ignore the transaction until it is confirmed; as they already do for all manner of unusual, nonstandard, unconfirmed input transactions, etc. or otherwise their acceptance of zero conf is no more secure than RBF (if it ever is...) ... and doing this is relatively harmless, because Opt-in RBF transactions do not need to suffer significant confirmation delays.

You are making a strong and unjustified assumption about the skills and background of people maintaining Bitcoin Core. I think you may be making the fallacy of assuming that a group excellent in a particular area must necessarily be weak in another specific area. The community, even the most active segment, is fairly large and diverse in many ways-- much more so then, for example, the persons working on XT*. Beyond the expected CS and distributed systems PHDs, the community includes people with expertise in mathematics, economics, financial markets, ... Peter Todd has a fine arts degree. Skepticism about the viability of the Bitcoin system absent effective meaningful block size limits can be found in peer reviewed academic publications in economics venues. Negative effects on mining fairness are both predicted by simulation, and borne out in field trials on test networks.

[*As a  vague yardstick, there are ~19 contributors to Bitcoin core with individually more commit count activity in the last six months then all contributors to XT had in both XT and Core combined. Commit count is a crappy metric and you can figure that is off by a large factor in either direction; but this isn't really a comparable; and this is in spite of non-stop attacks that make working on Bitcoin really demoralizing]

And beyond the expertise, we're speaking about a question where in the absence of perfect knowledge we conducted the experiment: We raise the soft blocksize target from 250k to 750k and saw tremendously negative effects: substantial declines in node count (in spite large growths in userbase; and to brag, somewhat heroic efforts to increase software performance), substantial increases in mining centralization, substantial increases in Bitcoin businesses relying on third party APIs rather than running nodes (hugely magnifying systemic risks). We've seen the result and it isn't pretty. And yet this information is ruthlessly attacked whenever it is pointed out-- I am routinely called a "bitcoin bear" even though I have a significant portion of my net worth tied up in it, simply for beveling in Bitcoin enough to be frank about the problems and limitations in it. Many people less convinced about Bitcoin's power and value than I and much more interested in the short term pump are unwilling to tolerate any discussion of challenges; and this creates a poisonous atmosphere which undermines the system's ability to heal and improve.

And today we are left at a point where the bandwidth consumption of an ordinary Bitcoin node just barely fits within the 350GB/mo transfer cap of a high end, "best available in most of the US" broadband service. We cannot know to what degree the load increase was causative, but none of the metrics had positive outcomes; and this is a reason to proceed only with the greatest care and consideration. Especially against a backdrop where Bitcoin's fundamental utility as a money are being attacked by efforts to regulate people's ability to transact and to blacklist coins; efforts that critically depend on the existence of centralized choke-points which scale beyond the system's scalability necessarily creates.

You're right though that the question is substantially political: A fully centralized system could easily handle gigabyte blocks with the work we've do to make megabyte blocks barely viable in a highly decentralized world. Such a system could also happily institute excess inflation, censor transactions, and other moves "for the good of the system" and "to assure widest adoption". If Bitcoin is to survive in the long run we just stand by the principles we believe in, and which make the system valuable in the first place. -- Even against substantial coercive pressure.  Otherwise the transparent system of autonomously enforced rules risks devolving into another politically controlled trust-based instrument of expedience that we see with legacy monetary instruments.

We do not. CPFP has substantial complexities that prevent it from actually working on the network today; and using it has large overheads. It will be a good additional tool to have, but it does not replace RBF.

You can have a different perspective; but you cannot have your own facts. This is a question of objective fact. But you mistake my comment for an insult, it wasn't intended as one-- who am I to judge what someone else spends their time on? But rather an observation the it would have been surprising to see a contribution there.

An action which you could only contemplate due to the work of myself and others who believe that the BIP101 approach would be significantly damaging. I think it's likely that it will be increased in the future, but in a way only that preserves Bitcoin's properties as a decenteralized P2P electronic cash, rather than disregarding them or undermining them.

Mike and Gavin have not commented on Opt-in RBF as far as I am aware; you are confusing his comments on full RBF. But on what basis do you believe their expertise is greater than a dozen other parties?

Opt-in RBF is explained in some detail in the FAQ on Reddit, linked previously to you in this thread; you say that you are open to other views, but you seem to have made no effort to familiarize yourself with them.

I just checked his twitter feed and can find no comment on it in the last several months. As far as insight, Gavin is not very active in Bitcoin development and hasn't been for a significant time, before the recent blocksize drama. That he didn't comment on the PR was unsurprising on that basis, but he certainly was aware of it-- since he asked when the merge was being discussed in the weekly meeting if we'd talked to any other wallet vendors about it (though this also indicated he hadn't recently read the PR).

No it doesn't.

You should wait for confirmation if your risk model says you should. This is already the case, and many properties of a transaction (like low fee or spending unconfirmed inputs) will make most zero conf accepters wait (and still they frequently get ripped off; because the Bitcoin system itself does not provide security for unconfirmed transactions). Fortunately, Opt-In RBF at least means that there is no risk that the confirmation needs to take an excruciatingly long time.

If he is, he failed to speak up. Of the 19 people that commented on the PR in the nearly two months that it was open, none said anything negative.

There are no funds at that 'location'.  No funds are ever sent the revealed key P, funds are sent the the key P+Recipient_Pubkey, which only the recipient knows the private key for (and only after the private key for P is revealed).
 

The modern large miners are mostly not pools in the historic sense. They own most of their own or at least physically control most of hashpower (directly or through other companies with common ownership). Even to the extent that they are still 'pools', we've seen from experience that the participants have no influence-- e.g. Ghash.io used ~30% hashpower to perform a million dollar scale finney attack, and for months after their hashrate grew, ultimately reaching to 50%. Rather than moving their miners away, people criticized the victim for accepting unconfirmed transactions and moved their hashpower _to_ ghash.


Back to the "LULZ", the desperate attacks on Opt-in RBF (seems that some think they can use this easily misunderstood bit of technology as a proxy in their epic war On Bitcoin Core) have become so shark-jumping-crazy that they're chuckle worthy now: https://www.reddit.com/r/btc/comments/3ukc52/rbf_is_agaisnt_satoshis_vision_peter_todd_and/cxg8wj5?context=3

You appear to be conflating unlike things here,  the BIP101 threshold is "75%" hashpower, which right now means perhaps two or three people at the moment. Two or three people are not an "economic majority" by any definition.

Have you stopped beating your wife?

After careful consideration I believe that BIP 101 is a seriously poor proposal, and I doubt the system would survive in an interesting form with that in the long run: but I don't care to try to convince you of that; when it comes down to it I'm uninterested in being involved in any system implementing it, and so I won't be. If the Bitcoin goes along with it-- I'll just work on something else. And it's my own free choice and will to decide what I work on in my time, hopefully you agree? (mimicking your approach:) and if you think you can tell me what I can work on, how I can spend my time, and what thoughts or program I can publish on my own sites I will accuse you of tyranny and totalitarianism. Which one is it, person who feels comfortable throwing rocks while hiding behind a pseudonym, can you answer this question?

You mean writing things like,


-- oh wait, that's Mike Hearn.

But seriously, the people you're being critical have done tremendous work on making Bitcoin more scalable.

It's a shame you disrespect us so when your has depended on our (free) labor.  We are struggling to keep the system viable at the current load levels; and have done tremendous work to keep it from falling over or falling into total centralization.

No one I know that is working heavily on the technology believes the system can survive significantly increased scale without actually increasing scalability-- so that's what many people working on; rather than twiddling a knob which slashed the node count the time it was soft-increased previously. Doubly so with fungibility being at least as great a short term concern as scale (and a much greater long term one), as wide spread commercial tracking and coin blacklisting are becoming common; and fungibility improvements come with scaling tradeoffs so to the extent that we have extra headroom we may need it to keep Bitcoin a _money_ (on top of the need for resource headroom to survive attacks).

uh. Your response isn't making any sense to me. I think you've misunderstood the protocol, but I am not sure where-- nothing about the above exists to prevent double spending, the transactions are all confirmed before further action is taken. Please reread and if you still hold the same view write out a sequence diagram that shows your attack so I can understand it.

Here is a private atomic swap that doesn't need the multiphase "CoinSwap" transform, as I've come to call the generic protocol here that makes smart contracts private by hiding them from the blockchain.


B computes nonce x and  P = xG, P2 = P + H(P)G

B sends P to A

B pays to   if() {Apub+P2 CHECKSIG} else {CLTV Bpub CHECKSIG}

A pays  to   if() {Bpub2 CHECKSIG P2 FORCEDDISCLOSURECHECKSIG} else {CLTV Apub2}

What is a FORCEDDISCLOSURECHECKSIG? it's a signature construct that forces you to sign in such a way as to disclose the private key.

I am aware of two ways to get this construct in unmodified (no disabled opcodes) Bitcoin today.

One of them is: OP_SIZE 57 OP_LESSTHANOREQUAL OP_VERIFY <P> OP_CHECKSIGVERIFY

Actually, no, they've been having huge problems with it; with nodes crashing all over the place and such. Of course: Bitcoin Core nodes on testnet are unaffected: They're just ignoring the XT chain entirely, banning those peers, and continuing on as if they didn't exist.

Ordering is a free parameter, and can be a deterministic function. Other than the topological constrain for spending the order of transactions in a block is completely arbitrary and without effect. Nothing about _ordering_ promotes censorship and centralization.

Synchronization might well punish those with inconsistent policies; but mining centralization prevents brought about by slow propagation prevents their existence completely.

There are ways to mostly eliminate inconsistency costs using more advanced (pre-forwarding schemes).

If a block is mostly ordered as expected, but not quite; then the amount of information needed to transmit the difference is small in any case; there is no need to strongly bind the consensus rules to this.

You're asking about account "" but you imported the address in account "1GkktBuJ6Pr51WEJe5ZzyNvMYaMDFjwyDk".

The empty quotes were not optional, the account name field is missing in your example of trying it.

I am boggling at people making a big deal about this.

Exchanges and such getting priority handling is nothing new: MTGox was doing it in 2011 (giving hosting to eligius in exchange for priority handling); and many other miners do as well. I understand F2Pool even has a paid access API. Being able to directly prioritize transactions is one of the reasons to participate in mining.

If you google 'gmaxwell out of band fees' you'll find many examples of me pointing out this-- e.g. making sure that fee estimation code isn't confused by it.

This doesn't change anything about fee market behavior: a fee is a fee regardless of how you pay it, including if its paid with service or in-kind.  They'll be less need for this sort of thing once RBF is deployed with 0.12, because there will be a uniform mechanism for everyone to revise their fees.

Prioritizing transactions is also a maintained, documented and supported feature in Bitcoin Core, and has been for years:


prioritisetransaction <txid> <priority delta> <fee delta>
Accepts the transaction into mined blocks at a higher (or lower) priority

Arguments:
1. "txid"       (string, required) The transaction id.
2. priority delta (numeric, required) The priority to add or subtract.
                  The transaction selection algorithm considers the tx as it would have a higher priority.
                  (priority of a transaction is calculated: coinage * value_in_satoshis / txsize)
3. fee delta      (numeric, required) The fee value (in satoshis) to add (or subtract, if negative).
                  The fee is not actually paid, only the algorithm for selecting transactions into a block
                  considers the transaction as it would have paid a higher (or lower) fee.

Result
true              (boolean) Returns true

Examples:
> bitcoin-cli prioritisetransaction "txid" 0.0 10000
> curl --user myusername --data-binary '{"jsonrpc": "1.0", "id":"curltest", "method": "prioritisetransaction", "params": ["txid", 0.0, 10000] }' -H 'content-type: text/plain;' http://127.0.0.1:8332/


So effectively people are making a fuss about a miner using a feature of Bitcoin Core thats been around forever in entirely the expected way.  Weird.

What?  Miners have taken payments for prioritizing transactions for eons. MTGox was doing the same thing in _2011_ (it gave hosting to eligius in exchange for prioritizing transactions).  F2Pool apparently has an API that you can pay access too.

Google 'gmaxwell out of band fees' and you can find lots of posts where I'm schooling people about this possibility (and actuality)-- including pushing for fee estimator designs that don't get confused by it.

There is nothing all that interesting about it, in this case: In Bitcoin, a fee is pretty much a fee regardless of its paid in or out of band.

We even have a supported, documented, and maintained facility in Bitcoin Core for doing this, and have for years, written by the same people you seem to expect to be surprised by it:

prioritisetransaction <txid> <priority delta> <fee delta>
Accepts the transaction into mined blocks at a higher (or lower) priority

Arguments:
1. "txid"       (string, required) The transaction id.
2. priority delta (numeric, required) The priority to add or subtract.
                  The transaction selection algorithm considers the tx as it would have a higher priority.
                  (priority of a transaction is calculated: coinage * value_in_satoshis / txsize)
3. fee delta      (numeric, required) The fee value (in satoshis) to add (or subtract, if negative).
                  The fee is not actually paid, only the algorithm for selecting transactions into a block
                  considers the transaction as it would have paid a higher (or lower) fee.

Result
true              (boolean) Returns true

Examples:
> bitcoin-cli prioritisetransaction "txid" 0.0 10000
> curl --user myusername --data-binary '{"jsonrpc": "1.0", "id":"curltest", "method": "prioritisetransaction", "params": ["txid", 0.0, 10000] }' -H 'content-type: text/plain;' http://127.0.0.1:8332/


That it's surprising to /you/ only shows you weren't paying attention.    And maybe a little bit of desperation to infer something else to support an otherwise unsupportable position?   "Bitcoin Miner uses standard Bitcoin Core feature, Better drink my XT!"

In any case-- I suggest you stop thinking in terms of finding ways to "force" people to do things; it's unbecoming.