Any "sum of transaction fees" reduces to miners picking whatever they want, since miners can stuff blocks with 'fake' transaction fees, with only the moderate risk of them getting sniped in the next block.

In any case, this thread fails on the ground that the starting criteria doesn't mention keeping Bitcoin a _decenteralized_ system. If you don't have that as a primary goal, then you can just drop this block-chain consensus stuff and use open transactions and get _vastly_ better scaling.

All those fixed parameters in the 'proposals' are stinking handwaving.  If you only care about preventing the fee race to the bottom, you make the change in maximum block size be half the change in difficulty on the upside, 100% of the change on the downside, clamped to be at least some minimum.  Doing so eliminates the fee collapse entirely by forcing miners to spend real resources (more hashpower) drive the size up.  ... but it doesn't do anything to prevent the loss of decentralization, so I don't know that it solves anything.

You are, apparently, blogging about technology you do not understand. Please stop. Miners cannot "raise the limit"— that isn't how Bitcoin works. That precisely the same as saying that when the subsidy halved from 50 to 25 miners would continue on mining 50 because they prefer the greater income. They may have wanted to— but the system doesn't permit it, and the miners can't change the system. Darn good that they can't because otherwise all our expectations about the rules that make Bitcoin valuable would be worthless— subject to the whim of a small pool of anonymous interests.

Who says you need more than one currency?

The cluelessness in this thread astounds me. How do people manage to keep repeating the same factually incorrect claims after they've refuted in allcaps?

Most of the insertion slowness is probably the recursive IsFromMe / IsConfirmed checks in coin selection for unspent change in coin selection, as IsConfrimed recursively does that along the whole input tree with no-memoization. Commenting out lines 607 to 616 in wallet.cpp and I expect spending unconfirmed coins will become much faster.

Yup. A non-trivial (more than a few percent on each side) mutually exclusive fork is the worst possible outcome for bitcoin. From one currency is two, and all older coins can be spent twice.  There are enormous incentives to achieve universal consensus one way or another.

Whats low? Any idea what number they started on?

In any case, I'm pretty sure they haven't shipped (meaning released to a major shipper) mine— and so I'm doubtful they've shipped anyone elses.

(I'm going to take a totally WAG— pure speculation— that to resolve the costly shipping they put the units they shipped out on a cargo ship, and at some point they land at a port in the US and get handed off to a carrier)

rHs4j8RLTdgGiF3cBGv28tjVA5yfSi5C2L

Such a transaction can't be written in Bitcoin, it something you can't even express. Perhaps you'll find it fun to figure out why for yourself? I won't ruin it for you.

They have tiny fees, which likely don't pay for the marginal increase in the odds that the block gets orphaned due to its increase propagation/validation time.

Those transactions are insanely inefficient— half of them are pure messaging and not really a monetary transaction— they make it much more costly to run a Bitcoin node— they're burning up our technical startup capital without adding new users to the bitcoin economy (or at least not many). The bitdust outputs they create will likely never be rational to spend and are rapidly inflating the UTXO set— unprunable data. Across the board they're bad they're bad for the ecosystem... and they're ever so easily blocked, basically a one line patch.  So, even if it wasn't net-profitable to block them I'm sure some would.

It's purely hypothetical— basically just used to track things, and so when someone come up yet again repeating the same idea for the Nth time they can just be pointed to a list where its been suggested before— also a little bit because some people find the almost complete lack of innovation in altcoins depressing, and the page can give them some useful ideas.

Indeed, and I wasn't actually able to tell you what the exact threshold is— since it doesn't even appear to be documented!

One of the reasons they have to do this is that its really really easy to double spend against SD because some pools will not mine transactions paying them. So you can make a bet, if it loses, make a double spend to a non-sd address and give it to miners that ignore SD transactions. They may not solve the next block— but it still makes your expected return positive.  Another variation is to make the txn paying SD have an input that is part of a really long unconfirmed chain which will take a long time to confirm... and double spend that, giving more time for the conflict to get confirmed. etc.

The maximum growth rate is limited to 52GBytes/yr by the rules embedded in the system— meaning a $100 1TB HDD can store around 20 years of Bitcoin history..  The users of bitcoin would be foolish indeed to change the Bitcoin protocol to permit more size than that until computers and storage are advanced enough that the increased burden wouldn't be problematic.

Bitcoin isn't an anti-censorship system— it's trivial to block.

If you're concerned about bitcoin being blocked setup and maintain a Bitcoin node on a tor hidden service (see doc/Tor.txt), we could use some more of them.

They wait for 1 confirmation on bets over a couple BTC. This has been discussed before, and a variation (that doesn't require hash power) of it performed in the past.

It's not like a San Jose poll would be terribly representative of Bitcoin users.  A lot of the tech startups have big booming enthusiasm far outpacing their basic technical and economic competence, and I expect them to be well represented there. It takes all kinds, sure, but if you ask people who have been presenting these crazy double exponential graphs to VCs all week if they want there to be MOAR TRANSACTIONS, of course they're going to say "YES. IF WE NEED MILLIONS FOR ANOTHER VALIDATING NODE, I KNOW JUST THE VC TO CALL"   (And these folks and their opinions are, of course, quite important... but that doesn't mean that a poll is a grant way to get a thoughtful response that reflects their real interest)

Because basically no one was interested in doing even the most basic maintenance on the GUI and the code that was submitted wasn't really mergable without work. We added the bare minimum for a sufficiently technical user to do it on their own (or for someone to roll an external GUI for it).

The screenshots look pretty interesting! This seems like a MAJOR improvement over the old stuff.  I'm more inclined to merge something like this than Jeff is sounding, assuming that the author is willing to endure the requisite hoop jumping and shed painting... not just because it's useful, but because its a feature that can help increase technical understanding of the Bitcoin system.

Yea, two forks of my risk doomsday saying are "dorking with the rules will (rightfully) undermine confidence"  and "if the limit is lifted without enough txn we'll destroy the fees market", both of those go away if size is only increased in response to a situation where the necessity is obvious.

Though part of that also means that if we're to really reason about it in the future we get to have this debate every time it comes up so that we don't create an expectation that it must be increased even absent a need.

PEEK (DC08)

I noticed them taking up a bunch of slots on my own nodes (e.g. 6 total sockets, across multiple) and blocked them.  Nice casual privacy increase too. ... and their behavior strikes me as a bit unethical too— wastes your resources, in order to compromise your privacy, which you can get back using a service they sell you.  Lame.

So, yes, sure. It wastes resources but it's not a major concern unless its replicated by more parties.

The motivation you describe doesn't follow— any sane large miner does their mining from a shielded node with low degree— connecting only to their own nodes, other known miners and major nodes, and they separately run large public nodes.

Something which is currently prohibited by the rules embodied in every bitcoin node can not be easily described as inevitable.

A fair amount of debuking this has already happened in the thread. There are sound fundamental technical reasons why Bitcoin cannot be fully successful without external (decenteralized if you like) transaction handling. Once you have that, there isn't obviosuly a need for an extreme capacity (beyond millions/day) in bitcoin itself.

Kind of an odd comment. A rasberry pi— significantly less powerful than most current smartphones— can keep up with the blockchain with current software. Modulo software bugs and inadequacies the computing hardware and storage I already own would be adequate for a hundred years of the current maximum rate of Bitcoin (though I tend to be a bit overpowered).  

There are about 20k IPv4 _listening_ nodes enumerated in the seeds database, but it's impossible to know how many full nodes there are, though its very likely that its substantially more than the number we can see listening.

The cost of running a node relative to the value to the Bitcoin economy isn't actually a factor in decenteralization. The problem is that no matter how valuable the bitcoin economy is you can always save the cost of validating it by letting (hoping) someone else handles it.  What matters is the absolute cost relative to current technology and keeping it low enough that you get diversity and decentralization through indifference and altruism.  If you depend on profit motives you end up with a tragedy of the commons because its easier to freeload, or easier to monetize dishonest behavior. The system doesn't have any real incentives for honestly validating except the vague "if no one does a good job of it, the whole house of cards collapses".

Great. Agreed! But that is why some people here are saying that being conservative with Bitcoin itself and keeping the costs low and decentearlization a top priority is the right path: we can have both scale and decenteralization through the use of off-chain trading and keeping the chain small... but if we bloat up the chain so that only some ten thousand central banks validate it, we'll lose decentralization.