That's what 0.8 followed but 0.7 didn't. |
|
|
|
The source code is the best specification. No documentation written in human language be complete and unanimous enough to be sure that everything is covered. You cannot compile Hemingway writings into executable code.
Bitcoin with connectivity difficulties would have problems with different Bitcoin clients, but will happily create disconnected network and all sorts of other nasty things.
Bitcoin have much more at stake than Gnutella warez download.
Source code which contains unknown cases isn't acceptable for system (to be) used as medium of exchange. Bitcoin does have much much more at stake than some filesharing network, which is why there should be spec to follow. For something that my life depend on, I want certainty that it's well understood and tested. I'm all for having a spec that allows an ecosystem of multiple compatible implementations to arise, but in this case it wouldn't have prevented this problem. No amount of examination of the Bitcoin source code would have revealed the limitation in BDB, and the resulting need for a configuration file to change the BDB default values. Unit tests might not have even caught the problem because they said that not all 0.7 nodes rejected the large block. This implies that different BDB versions and/or platforms have different default values so consequently not all of them would have exhibited the problem, possibly including the platform used to run the unit tests. |
|
|
|
I'm only voting for you because your posting style reminds me of this, so I almost crack up laughing every time I read one of your posts:  |
|
|
|
So what is the actual answer to the question?
https://en.bitcoin.it/wiki/Scalability#NetworkLet's assume an average rate of 2000tps, so just VISA. Transactions vary in size from about 0.2 kilobytes to over 1 kilobyte, but it's averaging half a kilobyte today.
That means that you need to keep up with around 8 megabits/second of transaction data (2000tps * 512 bytes) / 1024 bytes in a kilobyte / 1024 kilobytes in a megabyte = 0.97 megabytes per second * 8 = 7.8 megabits/second.
This sort of bandwidth is already common for even residential connections today, and is certainly at the low end of what colocation providers would expect to provide you with.
When blocks are solved, the current protocol will send the transactions again, even if a peer has already seen it at broadcast time. Fixing this to make blocks just list of hashes would resolve the issue and make the bandwidth needed for block broadcast negligable. So whilst this optimization isn't fully implemented today, we do not consider block transmission bandwidth here. |
|
|
|
|
A miner who publishes a block that propagates slowly risks an orphaned transaction. If another mines a block at about the same time, and if the second block propagates more quickly through the network, other miners will start working from the faster block before they see the slow block.
|
|
|
|
And it seems that by putting the soft limit back to 250kb, we will have have more unconfirmed transactions and this will cause the mem-pool to get overly big (if we keep seeing an increase in transactions), so there is some haste needed to solve the mem-pool issue it seems. That's what advocates of a fixed block size don't acknowledge. If the demand for transactions exceeds what the block space the miners are allowed to supply the excess gets left behind. Even if this causes users to pay higher fees, the increase in transaction fees does not reduce the number of transactions get left behind - it only alters which ones get left behind. |
|
|
|
In meme form:  |
|
|
|
Goals
In rough order of priority:
Create a self-regulating market for transaction fees between miners and merchants/users
Smoothly transition from the rules we currently have in place to the new rules; transactions from users running old versions of Bitcoin should get confirmed reasonably quickly under the new rules.
Make sure transaction spam is expensive for would-be spammers
Replace compiled-in constants with dynamic, market-determined values
Pre-emptive intervention as a design goal? This may be nitpicking, but I would have thought that in a market where "supply meets demand", transaction spam would no longer be relevant. Miners would tend to simply sign "winning bids for transactions" in order of profitability and the problem would sort itself out. (Supply and demand might be chaotic but it's not Voodoo.) If we want the network to be successful then what we want is not a specific outcome (high fees or low fees, big blocks or small blocks), but rather an efficient mechanism for price discovery. Nobody can calculate ahead of time how much hard drive space, bandwidth, and cpu time the miners, pool operators, and owners of full nodes are willing to devote to the network for a given amount of revenue. Likewise nobody can calculate the tradeoff between speed and fee percentage all the users of Bitcoin are willing to pay. Instead of attempting to calculate the incalculable and impose a central plan on the network, the best strategy is to design a market for transaction processing that will find the right answer on its own. |
|
|
|
Incorrect. The only question is who is willing to do it, and who is willing to support them.
I am willing to donate bitcoins, and to help test changes by compiling and running a node on testnet.
To quote here: <mircea_popescu> jurov anyway, the problem isn't as much the drama, but moreover that a single-source codebase is both non-bitcoiny and suspect.
<mircea_popescu> but i think if we can get one (or ideally multiple) people to summarize the code
<mircea_popescu> we can pretty much derive a spec from there.
<mircea_popescu> this wouldn't take much longer than a few weeks for a first draft, which can then be argued and refined
<mircea_popescu> in my experience any devteam resists such an effort like cats resist washing, because coders love to write but hate having to read code.
<mircea_popescu> hiowever, once it's complete there's a few day's worth of facepalming and going "wait, we are doing W?HAT ?!"
<mircea_popescu> after which everything's much better.
<mod6> this is a solid plan.
<mircea_popescu> mod6 in experience it tends to work.
<mircea_popescu> of course it has to first get the cat into the washing machine. There wouldn't really be need for much testnetting, at least originally (ie, for the first draft). What there's need for is people to sit down with a cup of coffee and a (preferably printed) copy of the code and just read it through. This can be done in bits as long as the bits aren't arbitrarily segmented (it's ok to summarize a procedure, it's not ok to summarize between lines 520 and 545). Once we have a few of these completed we're already very far down the road. Then the work of merging them into a spec emerges, where a lot of arguments will for sure be had ("no, it doesn't do that"/"yes it does") at which point there may be a need to whip out the testnets but not necessarily. Then a ton of drama and hurt feelers, and then that's it, once everyone is beaten into a pulp we have the spec. Ideally this would include people other than the current dev team, not because the current dev team is made of idiots (which mostly it is) but because people tend to read what they think should be there and in general skip over the unflattering bits. In fact this can be started today. Another approach is to write the spec while refactoring the reference implementation into something more documentable. Any superfluous functionality than can be removed from bitcoind and moved to the clients is less functionality a fully-compliant alternate implementation is required to implement. I've suggested this before but maybe it's worth mentioning again.
Split bitcoind and bitcoin-Qt into completely independent components. Bitcoind stores a local copy of the blockchain, connects to the p2p network, relays blocks and transactions, and serves blockchain information to clients only. Bitcoin-Qt is a client application only that connects to a trusted bitcoind node. The default installation would install them in a pair, with bitcoind running all the time as a unix daemon (Windows service) and Bitcoin-Qt started on demand. Only one instance of bitcoind is needed on a typical home LAN, all the clients can just connect to it.
Once this is done Bitcoin-Qt can just focus on being the best client it can be, while bitcoind can focus on the blockchain and p2p network. It should also be extended to serve MultiBit, Armory and Electrum. Once the reference implementation is fully refactored into a client/server application it should make any attempt to develop an alternate implementation easier.
I don't have enough programming skill to do this, but I'd donate to anyone who does.
This would definitely be the first step out of the current insanity and finally bring some layering into the code base client UI === depends on ==> bitcoind but zero backward pointing dependencies. This would be the first step on the long journey to the promised land of the BPS (Bitcoin Protocol Specification) |
|
|
|
Fair enough. There Shalt Be a Spec. That's all there is to it.
The only question is what kind of pressure needs to be brought to bare and where to expedite that process. Incorrect. The only question is who is willing to do it, and who is willing to support them. I am willing to donate bitcoins, and to help test changes by compiling and running a node on testnet. |
|
|
|
[As I currently understand it, the problem is thought to be a limit on the number of locks on the BDB database, which is in turn a function of the number of transactions in a block and/or the number of transactions referenced by a block, which is indirectly related to the size of a block.] There is some evidence from other threads that it might be possible to fixed old clients by adding a single configuration file, without requiring any code updates at all. |
|
|
|
The position of MPEx is that the current dev team should release no further versions until a. Bitcoin is specified and b. The codebase is cleaned up. Is MPEx going to do anything to help make this happen other than talk about it? |
|
|
|
this is fixable though
It is only fixable if fixed. Does MPEx prefer problem to be fixed, or remain unfixed? |
|
|
|
I've often wondered why these tax protesters can't just be honest and say "yes, the law says tax is owed - but I disagree with that law" and then accept that the state will in fact agree with the law and thus enforce it.
I'd personally have a lot more respect for someone with the guts to stand up in court and say "under the law i'm guilty as charged, but the law is immoral" than I would for someone who tries to argue that the law somehow agrees with them using bizarre arguments like these.
They literally believe in magic. They study definitions from law dictionaries, and pour over the exact wording of statutes in the belief that if they find the right combination of words it will change the behavior of the people who make up the state, exactly like casting a magic spell. That law doesn't work like that though. The people who control the apparatus of the state do what they can get away with and the law is just a tool used to intimidate the public into obedience. The reason we know this is because the law is only used to prosecute the peasants and never applies to the ruling class and apparatchik. An average middle class citizen bouncing a $20 check is Serious Business, but a primary dealer who launders half the GDP of Mexico for the drug cartels is an unfortunate misunderstanding that we should just put behind us. |
|
|
|
Right now there's no question that they deserve to be called idiots. What's happening now was easily preventable and shouldn't have ever happened under any circumstances.
It's actually fucking amazing that this is first MAJOR bug in 4 years. , as all critics ignore because they are clueless and it invalidates their criticism, the bug isn't in bitcoin at all! It is in some versions of BDB on some platforms. The developers wisely chose a better database for 0.8, but unfortunately the bug manifested itself in a bad way (it could have been worse, e.g. if the bug in BDB made remote code execution or altering old blocks possible) before almost all nodes had upgraded. I've seen at least one thread claiming that it's not a bug in BDB as much as a misconfiguration. |
|
|
|
I was naive enough to think this had been tested thoroughly. Why wasn't this released as 0.7.99 or something? It was clearly not ready for such an even version number.
The 0.7 series was the one that needed more testing. It wasn't ready to handle all types of valid blocks. |
|
|
|
Most miners will keep rejecting those "free bids"... until it's a 'rogue' miner's turn to discover a block. What do they do? They dip into the "infinite memory heap" where 80k transaction requests have accumulated, and they accept the lot! ...and his block promptly gets orphaned because most of the network is only including the transactions that make economic sense so theirs propagate faster. The single rogue miner doesn't find blocks fast enough to make a significant impact on the network unless he controls 50% of the hashing power, in which case it's game over anyway regardless of the block size limit. |
|
|
|
|
I've suggested this before but maybe it's worth mentioning again.
Split bitcoind and bitcoin-Qt into completely independent components. Bitcoind stores a local copy of the blockchain, connects to the p2p network, relays blocks and transactions, and serves blockchain information to clients only. Bitcoin-Qt is a client application only that connects to a trusted bitcoind node. The default installation would install them in a pair, with bitcoind running all the time as a unix daemon (Windows service) and Bitcoin-Qt started on demand. Only one instance of bitcoind is needed on a typical home LAN, all the clients can just connect to it.
Once this is done Bitcoin-Qt can just focus on being the best client it can be, while bitcoind can focus on the blockchain and p2p network. It should also be extended to serve MultiBit, Armory and Electrum. Once the reference implementation is fully refactored into a client/server application it should make any attempt to develop an alternate implementation easier.
I don't have enough programming skill to do this, but I'd donate to anyone who does.
|
|
|
|
|
Show Posts
