Topic: SatoshiDice, lack of remedies, and poor ISP options are pushing me toward "Lite" - page 2. (Read 7374 times)

Wrong.

All bitcoin clients will reject a block above 1MB, regardless of what any miner produces.

Thus, it would take a hard fork to change the maximum block size.

No, they can't. The rules of Bitcoin are not based on voting, only the ordering of transactions is. The only way they could do that is by becoming the effective developers of the Bitcoin software that all the users and merchants, etc use.  As someone who mines a bit myself I _fully_ welcome them to try though! In fact, I'll gladly write the patch for any big miner that wants it.

I'm not sure if you can really call it a "hard" fork.  Some people could change the limit today without really effecting the network since we aren't really hitting the limit yet.  And it would make the most sense for us to change it now so by the time people start hitting the 1MB limit, it won't be an issue.

Regardless, it isn't really up to the core developers anymore.  The developers at slush or deepbit could change the limit today.  It'd be risky to try to propagate a block today over the limit, but if the larger miners got together and decided on a date to collectively change the limit, there'd be a higher success rate.  The incentives are there, its just a matter of time.

No doubt in my mind that artificially limiting the block size to increase miner fees will bring great success to the next cryptocurrency that does away with the block size limit.

I agree here: Limiting a block to 1MB feels strange and arbitrary.  More so given that 1MB is pretty much nothing for today's computers, and many times this transaction rate could be supported with no real problems other than removing the block size limit.


So if I understand what you're saying here, it's that any self-interested solo miner (not a cartel) will include transactions as long as it's profitable for him / her to do so.  Or rather, not unprofitable / loss making.  We see this now; miners include transactions with no fees, with no direct benefit to themselves.  Assuming no block size limit, the negative feedback loop would simply be processing cost to the miner vs. transaction fee, which would tend to make for very cheap transactions.

This is basically how it works now.  C+epsilon for each transaction included, with both C and epsilon equal to 0 in most transactions right now.  Right now what's determining effort into block publishing is the block reward, which overwhelms transaction fees, essentially subsidizing them.

The block reward will become negligible, but that's many years ahead of us.  Long before that, within a year or two, we're likely to start hitting block size limits somewhat regularly, and after that, perhaps constantly.


Yeah, why not!
Seriously though I'm inclined to agree here as well -- I bet removing the size limit wouldn't kill bitcoin.  But here's the thing-- while we're debating these issues on bitcointalk.org (and sorry if this is an old / tired debate -- it certainly isn't to me however) people are building new bitcoin businesses and investments and all sorts of stuff.  And the blockchain is growing, and miners are mining, and the average transactions / sec and block size are going up.  If we all came to a unanimous decision about a protocol change, it would still be a big pain to switch / fork.  But since we can't even agree, and developers are saying basically "we'll see what happens", to me that means the 1MB limit is going to be with us for quite a while, for good or bad.

So I'm still trying to figure out myself if "artificially" constrained block sizes is "good" or "bad" for bitcoin.  My feeling is that either with the 1MB limit, or without a hard limit, the system will work, but it will work for somewhat different purposes. 

But would you all agree that regardless of desirability, we will see blocks really hitting that limit hard, and stuff really affected by it, before any protocol change occurs? (If it ever does.)

But I pointed out this isn't true.  Including the transaction increases block size and therefore storage costs, increases time to propagate, and increases the chance of some other relay not liking it.

I'm disagreeing with the fundamental assumption you're making that it's "pure profit".

It's not clear to me, as I've tried to explain.  Just like producing widgets - if someone can't do it profitably, that isn't a reason to seek out a central authority (here the arbitrary block size limit) to "solve" the problem (by specifying a minimum price in the case of the widget, or maximum block size for a block).  They just go bust.

This is even the case now - clearly block size is not a constraint at the moment, it might as well be infinite, as most blocks are way below the limit, and not even at the point where the reference client makes it "more expensive" to take up more space.  And yet the network isn't suffering, and also not every transaction is getting accepted in the immediately next block.  Because there are costs, lags, and delays, and that is their way of being expressed.  Some people moan, but they're the ones who will stop trying to do it (including qt client users who aren't adding much to the network).  If the "market" wants those users to keep doing it, the market will pay a higher fee to ensure they find it worthwhile.

By hashing, I was talking about the cost of rebuilding and rehashing the merkle tree, not the cost of hashing the block.  Sorry for any confusion; I feel that may have led you to misunderstand my argument.

I'm not certain an unconstrained block size can work.  But I think it's highly likely it can, and I've not read anything to persuade me otherwise.
If the market wants something (here, more hashing power) it will pay for it, like anything else.

So why not give it a go?  If it's a disaster, there will be no problem getting the 50% consensus to put one back, right?

I will say again. Block data size is one cost (storing the data, downloading and uploading it, and it also correlates with number of signature verifications required). Hashing is a completely different cost which is independent of the block size. There is no way to reasonably discuss this without clearly understanding the distinction.

Sponsoring the resources required to handling block size is a TotC problem in itself (the fee for including a tx is given to the miner which included it; the burden on the network is placed on all nodes). Which is why I earlier suggested some block size limit (or something equivalent) remains. But I'll be generous and assume the marginal resource cost finds a way to fund itself efficiently (e.g., "grassroots" rejection of large blocks).

This leaves the problem of sponsoring hashing. If the marginal cost of a transaction is C, including a transaction with fee C+epsilon is pure profit. There is no reason for a small miner not to include it. This means epsilon will tend to 0 and total revenue from txs will be equal to the resource cost needed to handle them, leaving no revenue to sponsor the very expensive hashing.

It works when there's no TotC (meaning, the business pays for any externalities). When there is one (as we can clearly identify in this case), some method to resolve it is needed.

For the marginal cost of handling transactions, the externality is network burden, and one solution is to limit network burden per block.
For the amortized cost of hashing, the externality is dissolving the bargaining power of hashers. One solution is to limit the bitcoins transferred per block. (So miners can still have bargaining power against big senders willing to pay a large fee to have their tx included).

Hashing is an artificially difficult problem and thus has an additional degree of freedom. Most things aren't artificially difficult; e.g., energy generation really is difficult, and if a more efficient method can be found to do it, people can enjoy cheaper energy. But if a more efficient way to hash is found, it favors attackers and the honest network equally.

The degree of freedom is exactly as you described: If there's not enough profit, miners will quit. Which is exactly what I'm worried about; with less miners the network will be more vulnerable to hashrate attacks. I want to make sure there is enough revenue to fund the amount of hashing required to secure the network; and I argue that left to itself, the TotC problem will create a race to the bottom with little total revenue and low network hashrate.

There are several suggested solutions. I'm not saying none of them can work, I'm saying the problem shouldn't be swept under the carpet.

Why do you believe this (that small self-interested miners will survive)?  Why must this be a tragedy of the commons?  What is special about bitcoin mining that makes block space the only scarce resource that cannot find a price?  Removing the limit doesn't make it a non-scarce resource, as precisely the fact it is a scarce resource is what is apparently scaring so many commenters.

My gut feeling is that the block size limit should be removed, and let the free market reign.  It works elsewhere, why not for transaction processing?

You're effectively claiming that some miner can survive and be profitable / just eat the cost by being selfish and adding all transactions no matter how small the fee.  Good for her!  She must be more efficient than everyone else.  If you can't stand the competition, stop trying to compete and get out of the race.  If mining is not profitable, miners will drop out until it is profitable, just like happens now.  Everyone will benefit from the competition towards more efficient mining setups and lower transaction fees. 

The argument that block size must be limited seems to me to ignore that:

- every node is free to not relay "spam" blocks, in the same way they are free to not relay spam transactions now, for whatever definition of spam that node sees as fit.
- hashing transactions into blocks has a cost, as does relaying large blocks.  If your block is "too big", for some technology and market-determined definition of big - then you will be beaten to the relaying race by a smaller, lighter, more network-acceptable block.
- a real feedback loop exists here to determine the right pricing and policies, "on average"
- every node is free to implement whatever policy on this stuff they want.
- if sufficient hashing power believes a certain miner or pool is an anti-social PITA, they can put "social pressure" on them by not relaying their stuff.

Remove the block size limit entirely I say.  Ultimately it is effectively just another indirect input to block difficulty, and we let all the other inputs such as CPU/GPU/ASIC technology advances float, and so we should do the same for block size.

That's hard to quantify, especially without empirical data on how much users are willing to pay to get their transactions included faster. But about 40% is the hashrate a cartel needs to perform a profit-boosting attack, so I'd say it might be the overall ballpark for the hashrate needed by a group of miners with an unwritten agreement to reject low-fee txs in order to keep the pressure up. But that's assuming the immediate-profit-maximizers are individually small; if there are only 10 miners with 10% hashrate each, it's probable they will converge to rejecting low-fee txs even if they did not originally intend to.

The same argument could be applied to block size.  Competition creates an environment where tx fees = mining costs.  Right now tx fees + block reward = mining costs.  Block reward is high, so tx fees are low.  Once the block limit starts to become a problem, it will be increased or removed.  It's a win-win for everyone.  More transaction fees per block & faster confirmations.  The only downside is a larger blockchain, but I don't think we're even close to limiting transactions based on bandwidth and/or storage concerns.

Keeping the block size limit may increase tx fees in short term, but long term it will be more harmful than good to the miners.  People will be annoyed by the long confirmation times & high fees and start using a different cryptocurrency.  Now the miners have hurt themselves by transferring value out of the bitcoin economy.

Meni.  What is the degree of this TotC problem?  That is to say what percentage of self-interested miners (or I suppose successful blocks solves) would sufficiently degrade the position of a loose affiliation of miners enforcing a sustainable tx fee?

 

It doesn't really work this way. It costs nothing to include a transaction so a small, self-interested miner will include every fee-paying transaction, even a small fee. In so doing, he sells out the bargaining power of miners; users will see that low-fee txs are included, and will pay less fees in the future. The damage thus done is shared by all miners, but the profit from including the transaction is all his own. This is a tragedy of the commons problem. The common resource here is the bargaining power of miners, which the individual miner will consume at others' expense.

This will be alleviated if mining is highly centralized (which we don't want), or if there are other factors such as assurance contract funding or a limit on total bitcoins transferred per block.

Limiting block space isn't the only way to increase mining fees.  Removing/reducing the block reward has the same effect.  Once the reward is less than the cost to mine, most miners will require a tx fee.  Given this incentive, there's really no reason to limit the block size.  It is in the miners best interest to set the limit as high as possible so they can receive the maximum amount of tx fees possible.  For this reason alone I foresee the block limit rising significantly.

Someone could try to disrupt the network with an extremely large block that contains millions of satoshi transactions, but it wouldn't be worth the effort.  Not to mention, miners could set their own size limits (for just this reason) & the consensus could be to orphan the block.

It only saves you 32 bytes per txin, so more something like 20%. That said, yes, that would be a very welcome change.


In the format used by the current git head of the reference client (which will become 0.8 ), it's about 122 MiB now. Together with indexes and other overhead added by LevelDB, it's 143 MiB. Unpacked in RAM it's probably close to 5x as much (though there is little reason to have the entire database unpacked in memory).

Actually a lot of them are not really "used for wagering", they're (ab)used as a way to send messages to the client the wagerers are using. Part of the point of the payment protocol work is to give sites like SatoshiDice a messaging system that doesn't require assigning meaning to magic quantities of money.

By the way, SatoshiDice is (afaik) not using compressed pubkeys. That's because bitcoinj doesn't use them. SatoshiDice is open source, it uses a fork of the library. We can probably halve the amount of data it generates just by fixing that.


I fully agree we will reach the block size limits at some point, if only because people will come up with uses for micropayments beyond wagering. I think expecting a quadrupling of tx volume is optimistic, but hey, we're on the same side here. This is why I want to see the block size limit float.


Your calculations are useful if my "mainstream thing" you mean "one world currency used for everything", which could only conceivably occur in some Star Trek future. If that does occur then yottabyte storage - for a few parties at least - is hardly inconceivable. I mean there was a time when "hold the web in RAM" sounded absurd yet multiple companies do it today. You don't need many parties to store the entire block chain because all other nodes can prune and only have to handle the working set size.


It's on the order of a couple hundred megs. I forgot the exact size. Perfectly feasible to hold entirely in RAM for now.


You're right, I guess everyone should just do what I say instead. That's far more efficient. Good to hear you'll be on my side when the time comes

Obviously for a hard forking change it's economic majority that matters, not miner majority. That's why I said maybe transaction version numbers should be adjusted instead/as well. For the majority of participants who have no opinion one way or another, they will just upgrade to whatever their client developers deem best.


This will shortly cease to be the case because SPV clients are going to start receiving filtered blocks, so cannot check their size. Sooner or later the majority of all users will be on SPV clients. Whether this equates to the majority of economic activity is still uncertain - I'd hope most merchants run their own full node, but I honestly don't know what the makeup of Bitcoin-using merchants will look like over time.


If all economic actors except some miners want the change then it's just equivalent to a 51% "attack" - if you can get a majority of hash power to agree, then the rest of the miners have to go along with it or see no income at all.

However, I think in the presence of a working alternative funding model most miners would accept larger blocks. I don't think there's any advantage to artificially throttling Bitcoins scalability if funding is not obtained via user-levied fees. I know gmaxwell argues strongly that allowing Bitcoin to scale would destroy its decentralization, but again I disagree.

Anyway, these are old, tired debates. The answers will become clear nearer the time.

In case it's not clear, the advance planning is done in software. That is, if we decide right now it should be changed, we add the line "if blockheight > 270000 then sizelimit = 10MB" to the upcoming software version. Then anyone who upgrades his client within the next half year will automatically switch when the time comes.

A limit on the data size of a block isn't the only or even the most efficient way to keep demand for transactions high. The marginal cost of handling the tx size is expected to be much lower than the amortized cost of hashing to secure it, so artificial scarcity in the former to sponsor the latter creates perverse incentives.

I favor a structured fee solution that takes into consideration the different costs. A component for storing and broadcasting data (e.g. data size limit); a component for signature verifications (e.g. limit on the number of signatures); and a (much more significant) component for miners' bargaining power in demanding payment for their hashing (e.g. limit on the total amount of bitcoins transferred).


Even in case data size limit remains as a rough approximation to encompass all three: Sure, at some point increasing the supply of transaction room will greatly reduce the price and the total revenue. But miners will also understand that if the limit is too low, the usability of the Bitcoin system at large is reduced, which will harm growth and potential total revenues.

If a majority cartel of miners decides anyway to reject all blocks with increased size limit, despite this being the new protocol agreed by the economic majority, this is none other than a >50% DoS attack. Whatever tools we come up with to handle that (e.g., moving to a block DAG structure) will apply.

So how do you call the hard fork that occured after a fix to the integer overflow issue?

https://en.bitcoin.it/wiki/Common_Vulnerabilities_and_Exposures#CVE-2010-5139

There has never been a hardforking change of the blockchain protocol rules.

There has however, been a 'hardforking' change of the on-the-wire P2P gossip protocol. A checkvalue was added all messages (negotiated, so compatible) but the negotiation itself got a checkvalue too after a two year time delay (and all nodes switched to the new new negotiation at a hard coded time). It caused a few minor issues but no major disruption.

We've also made softforking changes— changes which strictly reduced the set of acceptable things, so they need some coordination of mining to prevent the formation of forks but don't require a 100% upgrade— and there is one going on right now: https://en.bitcoin.it/wiki/BIP_0034

There are ways you could make increasing the blocksize technically soft-forking change (by having an auxblock committed in the block, and once coin is moved by the auxblock it may never be spent in the real blocks) but it would be hideous and pretextual.  But along those lines, it would also be technically possible to integrate a lower security high volume payment blockchain as a pure softfork.  The idea is that txn would be send to an address on the rapid payment blockchain using an output script that looks like an anyone can spend to old nodes.  New nodes would require that some evidence be presented (via some channel) before accepting a transaction that moves those coins back into the bitcoin network (perhaps a SPV like fragment proving the merge mined federated system agreed with the change?).  (Perhaps by admitting this possibility I can get people to stop obsessing over the block size?  There are a lot of possible things to do here, I personally prefer generally isolated systems because I think that people should have a choice. But even if you demand that it must be part of "bitcoin" that doesn't mean we have to increase the block size)

Oh, and welcome to the forum!

This is one of the most interesting threads I've seen here -- made an account to reply.

A lot of people have different ideas about the importance of this block size limit, and I think it's useful to separate opinions about what "should" happen, and more objective analysis of what "will" happen.

And thinking about it, to me it looks like the 1MB block size is here to stay.  I'm not really sure what that means for bitcoin, if it's "good" or "bad", but here's why I think it's permanent.

First, it's a hard fork.  Every node right now, to my knowledge, will reject any block coming in at over 1MB.  Miners included.  ANY kind of hard fork is going to be really hard to implement due to the size of the network.  But if a hard fork does benefit everyone, or almost everyone, it could be planned in advance and switched to at some date.  As long as most (substantially more than 51%) of nodes switch to the new protocol in a coordinated way, a hard fork change could work. (BTW, has this ever happened?  I haven't heard of it but maybe it has?)

But in the case of removing the 1MB limit, I don't think the agents involved here will agree.  Specifically, the miners.  SatoshiDice would certainly be on board for 1GB blocks, as would BitPay, Gox, and I'd imagine most end users.  But I think miners have incentive to maintain the 1MB limit.  The limit creates an (artificial?) scarcity for what they are providing / selling: inclusion in the block chain.  If there's only room for ~4K transactions per block, thus only ~1M transactions a day, a spot in that blockchain is going to be quite valuable if millions of people want in.  Transaction fees could be quite high, making only large transfers feasible.

A transition to larger block sizes would thus be resisted by miners.  While you might say, "Well, at 10MB / block there's potential for 10X as many transactions, thus 10X the fees" I don't think it would work that way.  But in fact, I don't think this will ever be tested; all you need is miners to resist this change due to uncertainty.  Some miners might like to increase the size limit, but many won't.  Having large groups of miners disagreeing on fundamental protocol aspects sounds like a disaster for bitcoin.  Basically, to me, the network of miners IS bitcoin; they provide the power to run the network, and are compensated to do so.  If the miners aren't 100% for it, it's just not going to happen.

So I'd like to hear from people who agree, but mostly who disagree with me; how do you think this modification of the protocol could play out?  How would the miners get on board?  Do you think miners would in fact want bigger blocks, and why?  This seems like a very relevant discussion to have right now.  We could be hitting 1MB blocks in a matter of months.

The current blockchain size is about 4.5G. If we prune all spent outputs, what the size would be?

Yes. The longer we maintain unworldly policies like relaying zero fee transactions and dust the faster this will happen.

What we might choose is if the "Banks" will be the old ones or we provide funding to some arising out of this new community. The first step for the second alternative is to reduce funding dependency on inflation by enforcing fees.

The same applies to funding innovation that ensures the decentralized nature of the system is preserved to the extent possible.