This would have been a huge boon to small businesses and individuals who might have used it to raise needed capital. Instead they will have to continue to rely on old outdated systems that are less efficient and can expose them to JBTs unnecessarily. Apparently some key people involved with Bitcoin see this as a desirable outcome. |
|
|
|
Is there a way to configure 0.8 to not increase the block size over the limit? The default settings won't produce problematic bugs. Probably. Because the bug (can't handle blocks over a certain size limit) isn't in 0.8 its in 0.7, and the bug cannot be resolved unless the entire network abandons 0.7 and earlier. The bug is that in all versions of bitcoin prior to 0.8 the maximum number of transactions that can fit in a block is not universally definable, because the limit varies based on the exact hardware and software configuration a particular node happens to be running. It's possible for 0.7 nodes to produce valid blocks that other 0.7 nodes can't process. |
|
|
|
Unfortunately quite some people have a bad association with math. What about "In Numbers We Trust"? It's all conjecture unless we test it with focus group studies, but I don't think people have negative associations with math itself as much as that have negative associations with studying math. People don't use phrases like "mathematical precision" in order to evoke negative associations. That tells me that people trust and value math, but hate doing it themselves. The first thing that comes to mind when I think about "In Numbers We Trust" is Mark Twain's quote about statistics. |
|
|
|
So, a regular user who isn't mining should simply have waited a couple of hours and the issue of the fork would be resolved by the network... fine, great...
But what about miners? How is this going to be resolved for miners going forward?
Reddit said that BTCGuild and their ilk have changed back to 0.7, that's great for them but what about people using p2pool? p2pool interfaces with your BC client and as such it would mean everyone with p2pool has to downgrade to 0.7...
Are there plans for a 0.8.1 which resolves this or what?
Anyone knows the answer? Miners can still use 0.8 as long as they don't create problematic blocks. People running p2pool can stay on 0.8 as long as the don't increase the soft block size limit too high. |
|
|
|
|
I'm pretty sure "In Math We Trust" would work better than "In Crypto We Trust" because the average person doesn't know what crypto is, but already associates math with concepts like reliability, correctness, and objectivity.
|
|
|
|
EVERYONE who was around for the 2011 crash had a sinking feeling in the pit of their stomach a few nights ago. Only because I didn't have any dollars sitting in my account at Mt Gox. |
|
|
|
Why not contribute, get the matching, and then do an early withdrawal (10% fine)? It's free money! Because the circumstances under which one can do an early withdrawal are problematic in my case. If I could have done so I already would have. |
|
|
|
|
I hold my savings in Bitcoins because they are unique in their resistance to being remotely seized or frozen, as well as their resistance to physical confiscation.
I didn't pay attention to the financial markets prior to 2008, but since I've learned how they work I have zero confidence in any of the alternatives to Bitcoin.
That's not to say I have 100% confidence in Bitcoin, but anything at all is better than 0%.
|
|
|
|
Ill be honest, I managed to use pgp to access the OTC but I still have no idea how to sign an email.
The best solution is to use Thunderbird with the Enigmail plugin to read and send email, or perhaps I should say the "least suboptimal" solution since "best" doesn't accurately describe the situation. |
|
|
|
Yeah, I don't get it, why didn't everyone just get forced to switch to 0.8 since it didn't have the BDB limit on number of transactions that 0.7 has? Why was it the other way around? Based on what I've read my guess is that many significant non-mining businesses are still on 0.7 and couldn't upgrade quickly enough. |
|
|
|
|
Personally I assume that my 401k will be taxed away, seized, devalued, forcibly converted into US Treasuries, or otherwise be unavailable before I get old enough to need it. I don't contribute to it any more.
|
|
|
|
The <= 0.7 Satoshi implementation wasn't capable of dealing with such blocks. It's worse than that. If < 0.8 implementations all behaved the exact same way you could call their behavior a de facto standard, but since their behavior was not consistent between nodes of the exact same version you can't even say that. The behavior of all implementations prior to 0.8 with regards to the protocol is non-deterministic. |
|
|
|
If it gets big enough, it could cause a soft-fork. But that's a much different/smaller problem than a hardfork, and unlikely to occur (since miners would presumably get their act together before it got to this point). If half the network decides that blocks containing SD transactions are valid, and the other half decide they are invalid it would indeed be a hard fork. There's no guarantee that it would go your way either. The majority of the network might just continue processing those transactions and ignore your blocks until you get your act together. |
|
|
|
If miners refuse to do their job in filtering, there's no reason to leave it up to miners.
Regular participating nodes can refuse to relay blocks with (eg) more than 50% Dice spam. Let me get this straight: a blockchain fork caused by the fixing of an unknown bug should be fixed ASAP. On the other hand the blockchain should be deliberately forked because not all miners agree with you? This topic has nothing to do with blockchain forking, period. One faction in the network refusing to relay valid blocks has no potential to cause a fork? |
|
|
|
If miners refuse to do their job in filtering, there's no reason to leave it up to miners.
Regular participating nodes can refuse to relay blocks with (eg) more than 50% Dice spam. Let me get this straight: a blockchain fork caused by the fixing of an unknown bug should be fixed ASAP. On the other hand the blockchain should be deliberately forked because not all miners agree with you? |
|
|
|
Completely wrong. 0.8 had the bug, since it didn't imperilment the protocol as defined by the 0.7 clients. The fact that the limitation in the 0.7 clients was unknown and undocumented is besides the point. If it's true the BDB limit was actually based on the block size of the underlying device, it's not true that previous versions followed an unknown or undocumented protocol - they actually followed no protocol at all in this area. The same version of the client would have different behavior based on the hardware it was installed on. There is no way for 0.8 to maintain "bug for bug" compatibility with non-deterministic behavior. |
|
|
|
Is there any point behind that fact Bitcoin client supplied with two executables "bitcoin" and "bitcoind"? Why it could not be single module with both functionality? Technically it seems possible. User then could see output either on server's desktop or via RPC. It would be better to have more separation, not less. Only one instance of bitcoind is needed per LAN and it should run all the time as a daemon. For shared machines it shouldn't matter which user is logged on, or if anyone is logged in. Clients, on the other hand, only need to run when you want to use them and should not be shared. If Bitcoin-Qt was stripped of the networking and blockchain functions and just became a SPV client that connects to bitcoind, and bitcoind was stripped of all wallet management functionality it would be easier to define a protocol spec and develop alternate implementations. |
|
|
|
|
Show Posts
