Db is right. We should not expect people to generate on a net loss. I don't doubt that there will be people willing to do so. But I think we should aim more than that, otherwise the difficulty factor would be much lower than what it could be.

And this is a problem that could be partially solved by an automatic adjustment of the block size limit, as I argue on the other thread.

If this rule is defined and documented while we still can, it would become a "protocol-rule". Generators would know it, and know how to adapt to it in order not to lose their blocks.

Generators must bear whatever the network demands. If we ever reach a "professional" level of hundreds of transactions per minute, generators will have to bear that.


That's why an automatic adjustment would be important. Not to allow "too high" or "too low" limits for a long time.

You do realize that if this limit is a constant, it will be really hard to change it when needed, right?


Yes, like the difficulty adjustment, there might be periods where it's not that precise. But it'd be much better than a constant value, wouldn't it?

No, not really. It's related to the difficulty factor only.

Hello all,

Recently I just posted on another thread to express my concern about this subject, but I thought it might deserve a topic of its own.

This block size rule is something really "dangerous" to the protocol. Rules like that are almost impossible to change once there are many clients implementing the protocol. Take SMTP as an example. Several improvements could be done to it, but how? It's impractical to synchronize the change.

And, well, if we ever want to scale, such limit will have to grow. I really think we should address this problem while there is only one client used by everyone, and changes in the protocol are still feasible, because in the future we may not be able to.

As far as I understand, one of the purposes of this block size limit was to avoid flooding. Another purpose as well, as mentioned here, is to keep the transaction fees not "too small" in order to create an incentive for block generation once the coin production isn't that interesting anymore. (if only a limited number of transactions can enter a block, those with the smallest fees won't be quickly processed...)

So, if we really need a block size limit, and if we also need it to scale, why not making such limit so that it adjusts itself to the transaction rate, as the difficulty of generation adjust itself to the generation rate?

Some of the smart guys in this forum could come up with an adjustment formula, taking in consideration the total size of all transactions in the latest X blocks, and calculating which should be the block size limit for the next X blocks. Just like the difficulty factor.This way we avoid this "dangerous" constant in the protocol.
One of the things the smart guys would have to decide is how rigorous will the adjustment be. Should the adjustment be done in order to always leave enough room to all transactions in the next block, or should blocks be "tight" enough to make sure that some transactions will have to wait, thus pushing up the transaction fees?

Okay, I do realize that it would allow flooders to slowly increase the limit, but, what for? As long as generators aren't accepting 0-fee transactions, a flooder would have to pay to perform his attack.

So, what do you think?

I think db has a point. If the block reward isn't profitable, that does look like a tragedy of the commons. It's true that if it happens the least efficient miners will give up, what will decrease the difficulty for the most efficient... but a lower difficulty is bad for the network...

Only recently I learned about this block size limit.

I understand not putting any limit might allow flooding. On the other hand, the smaller your block, the faster it will propagate to network (I suppose.. or is there "I've got a block!" sort of message sent before the entire content of the block?), so miners do have an interest on not producing large blocks.

I'm very uncomfortable with this block size limit rule. This is a "protocol-rule" (not a "client-rule"), what makes it almost impossible to change once you have enough different softwares running the protocol. Take SMTP as an example... it's unchangeable.

I think we should schedule a large increase in the block size limit right now while the protocol rules are easier to change. Maybe even schedule an infinite series of increases, as we can't really predict how many transactions there will be 50 years from now.

Honestly, I'd like to get rid of such rule. I find it dangerous. But I can't think of an easy way to stop flooding without it, though.

Nothing. Actually, as far as I understand, a miner has no obligation whatsoever to include any transaction in the blocks he produces.

Now, if you want to talk about what's the incentive for a miner to add transactions, well, it's mainly the fees. If a miner stipulates a high fee, people wouldn't pay it, and he would lose the opportunity of grabbing the lower fees that would go for the miner which accepts them.
On the other hand, there aren't much incentives to accept "feeless" transactions... today, as the client doesn't give you the option to add a fee to each transaction, custom miners have a strong incentive to accept such feeless transactions because otherwise they would be screwing the whole bitcoin network, what end up being bad for themselves. But as soon as there is a client that allows the user to specify how much to pay on fees, I don't see why accepting feeless transactions.



No, there ought not.
I am strongly against such thing.
What you are suggesting is price fixing. The whole bitcoin idea is to have sound money, government-proof. If that's what we want to create, how come we are going to try to fix prices on the protocol itself? That's contradictory with the sound economic principles behind Bitcoin.



You sound like those people who want to prevent merchants from proposing very different prices, otherwise is too "chaotic".

Producing a block and storing transactions in it is a service somebody is performing for bitcoin users. It's up to s/he to choose how much to charge.
And anyway, think about it, there is a strong incentive for accepting any transaction with any positive transaction fee in it. Otherwise you'll just be letting it to the next guy who is less restrictive than you.


This limit is client-based, not protocol-based. I suppose (actually, I hope!) that if a custom miner accepts transactions of less than 0,01 BTC, the default client won't reject those blocks. It's just that the miner that comes with the default client has this policy of charging 0,01 fee for <0,01 transactions.

So, this is not a problem at all, and can be changed at any moment by those in charge for the client.

I really think it's important that the protocol does not enforce any minimum transaction fee rule. A block should be accepted on the chain regardless of its transaction fees.
Trying to come with an arbitrary rule like that is like trying to arbitrarily fix price limits. We cannot predict what is the correct minimum fee.

Miners, yes, they should be free to set those rules for the blocks they generate. So, if those in charge of the main client decide to follow a minimum-fee rule for the blocks generate by the main client, so be it. But never reject a block generated by another miner that doesn't follow the same fee rules.

And, as I said, if the client just gives the option to the user of configuring minimum transaction fees, I don't see why people would keep accepting transactions with no fees on their blocks. That would be a sort of "charity", but towards people you don't even know.
If the custom GPU miners are not charging fees right now it's probably because the main client doesn't easily give you the option of embedding fees to your transactions.

Disagree.
I don't like "hard" rules like this.
Miners should be free to charge how much they want as transaction fee for including your transaction in the blocks they produce. If someone wants to include them freely, fine.

By the way, this would be a nice improvement to the default client. The possibility of

• Specifying a minimum transaction fee for the transactions to be included in blocks generated. The minimum value could be absolute, relative to the transaction amount, or relative to the transaction data size as today.
• A way to voluntarily add transaction fee when doing a payment. Again, the value to add could be absolute, relative etc...

Yes, I got it, I just don't see why such a large time interval. Why not daily, for example? It would be much more precise...

I'd still put seasteading before in this priority list. 

I think it's too early yet. 0,01BTC is still quite an insignificant amount.
And there is no need to try to predict the future by setting this change to happen automatically at block X. We can wait for the value to raise before performing such change. It's not like 1BTC will suddenly reach U$10,00 value.

By the way, I also think it's better to display with 1mBTC than 0,001BTC.

There's another topic talking about this too.

The difficulty factor is updated only at each 2016 blocks if I'm not mistaken (why such a high number, anybody knows?). When it's updated, the new difficulty factor is calculated based on the average value that would be necessary to keep the 6 blocks per hour rate.
But if the computing power in the network keeps raising, even after the update the new difficulty will be to small to keep that rate, since it was calculated with the average of the last 2016 blocks.

And the computing power has been raising a lot with all these GPU miners.

If the file is always encrypted I don't see why running on a not-so-secure-system would be a problem...

That's why I think the client should handle built-in encryption.

The video is well done, the music is fine... but I found the way they pass the message too "leftist" to my taste. It looks like they're criticizing people consuming choices.

You can protect your wallet.dat from hacking by encrypting it (using a password-protected key).

To be really safe, keep at least 3 copies of the file in different medias. Encrypted copies by the way.

To all: I think it's really imperative that the client has built-in encryption and backup features before a 1.0 release could be done... I hope I'm not the only one to think this! (and sorry, but no, I don't know enough C++ to help you...)

Impressive how people are so concerned about "backing" money with something... you're missing the point.

And by the way, nothing has inherent value.

I know about bitcoinexchange, I've already used their service. I thought the problem was in the US, but according to what you say, there is no problem...

Cheer up man, 200BTC is a good bid...
If you take 1BTC = 0.3USD that makes 60 dollars. Even if you take 1BTC = 0.25USD, that makes you 50 dollars.
According to goldprice.org, the current price for 1g is around 44 dollars.