When $1 was exchanged for 1,300 bitcoins, Why was this done at the time?
Did you mean to say when someone bought 1 bitcoin with 1300$? |
|
|
|
|
Are there any solutions which prevent a 51% attack from working?
I searched for it and only found old threads where nobody was able to say there is a technical reason why it would be prevented. I am hoping that in the years that passed since those threads were made that the problem was solved...
|
|
|
|
I'm sure every american breaks at least 10 laws every day of the week,
American freedom is a joke, we have more laws than liberties. I'm sure my ancestors who fought for our Independence would be appalled if alive today. Its true but if we don't have that many laws there would be people taking advantage of other people and that would suck no body would trust other people Nonsense, we could stop that with a tiny miniscule fraction of the laws we have. |
|
|
|
So... how come everyone is ignoring the 51% attack issue? Not a single refutation for it yet, I reraised it in an earlier post and that was ignored. The endless printing of money is the fuel they need to bribe politicians and to enslave most of humanity by providing them jobs that require them to spent most of their time at a job they hate, being controlled by a manager they don't like. The 1% easily controls pretty much everyone because when you own pretty much all corporations, you control pretty much everyone. Simple math shows that its more like 0.001%. Cronyism is a huge problem, and its nice that we got over the stupid "hurr hurr the top 10% of income earners are ALL EVILLLLL!L!!L" but replacing that 10% rhetoric drek with 1% is not better. It isn't how much wealth you have its how you get it. Some get it via being a creator who makes something people want. Others get it by being parasites associated with a government. Those parasitic robbber barons who are getting fat on the blood they suck from the common man via taxation and redistribution are the ones who invented and spout that rhetoric about the so called "1%" and their so called "punish the rich" schemes are actually "suck more blood of the middle class to make us even richer." To make Bitcoin illegal, USA need to bomb some of their civilians again. message tv and say that terract was paid with bitcoin and we cant track who did it, that is all. thats is the way for big countries to achieve what they want..
Please tell me you aren't referring to the nonsense 9-11 conspiracy theory that the USA was behind the bombing of the twin towers? |
|
|
|
|
I don't understand what destructibility has to do with the tulip bulb bubble. That was simply a case of a fashion item based bubble.
|
|
|
|
|
So, I have seen all the OP's points refuted except for 2.
1. Tyrant hostility & centralization because tyrants hate to lose power (he titled it "decentralized currency"). The history of seizures and shutdowns of companies like egold is proof of their willingness to do so. The way the EU is centralizing their power over bitcoin is also very worrying.
2. 51% attack. The latter is especially worrying with the fact ASICs have ruined the decentralized nature of the currency. What is to stop the NSA from threatening the people in butterfly labs into stopping public production and manufacturing just for them until they have enough? Or heck, just have armed blue clad thugs seize the factories, blueprints, and all existing unsold product. OR just commissioning boing and some other military contractor to manufacture a ton of ASICs for them?
Honestly I don't understand why everyone didn't abandon bitcoin for litecoin already when ASIC problem became an issue
|
|
|
|
|
I started on client 0.7, rock stable. Upgraded to 0.8 rock stable. Upgraded to 0.8.1 and it crashes a few hours after I start running it with a random error.
Last one was "failed to write block".
Is it just me or does everyone have it? (I want to know if I need to troubleshoot my machine or downgrade or what)
|
|
|
|
Of for... I can't believe this is still being argued. look, bitcoin is for free market capitalists. if you are a communist there IS a crypto currency for you called: http://freico.in/Its exactly like bitcoin except: 1. Built in penalty on being rich (its like a tax except its not collected by anyone, the richer you are the more of your money just evaporates every month). 2. Built it tax for redistribution. |
|
|
|
Ok, so I think you're agreeing and being nitpicky. I like that! So I'll join you: "not by the government and not via coercion" is redundant. That being said, redundancy is important, especially in the bitcoin world!  Yes on all counts  The redundancy parts especially. |
|
|
|
Ultimately, I think centralization is not the essence of what those of us who want to avoid it actually loathe. We loathe coercion. After all, for whatever reason, we have violated directive #3 (I think - right? That was Stephen's example, right?) because, through some centralization, the community was able to reason with miners and thereby convince enough of them to switch to a broken client in order to save the masses of bitcoiners still on that version, unable to validate the good block that forked them over. There is a kind of coercion in that, but it depended on the cooperation of the miners and isn't something I would call coercion because no rights of anyone were violated or threatened to be violated. That is semantics. Centralization explicitly refers to the centralization of power in the hands of governments through legal coercion. That being said, semantics are important... That being said, the whole concept of p2pool is to further avoid "centralization" of power done not by the government and not via coercion. |
|
|
|
Just a question - what would happen if the split was catched too late, allowing to get 100 confirmation for split-mined block to mature? Does it play any role, or just even larger reorg, like several hundred blocks, is still doable (with not too harsh consequences)?
Someone correct me if I am wrong, but AFAIK transactions are not lost, they would be duplicated on both sides of the fork. Its just that whomever mines on the losing fork ends up losing all their mining work. Transactions could appear delayed for a few hours though. |
|
|
|
That was my point actually. I was not accusing the developers of negligence I was saying that his platitudes are a form of "I could have done it better then them if I was them and could see the future". Well, he isn't them and they didn't see the future.
Then we are in violent agreement! Hooray! If the network ditches 0.7 then there is no problem.
As long as the network is predominantly 0.7 this would result in you creating a single orphaned block rather then a fork. While certainly a waste, this could happen while using 0.7 to mine as well (for a different reason).
All true, but I suspect you underestimate the, uh, conservatism that makes "the network ditching 0.7" non-trivial. That may end up being the chosen way out, and Deepbit, Eligius, etc., will plan to upgrade at an appointed time. Or another solution may emerge. We've waited months for 0.8, and we can afford to wait a few more days or weeks, though the newly discovered 0.7 bug adds a reason to move. In retrospect you are right. The best solution would be to make a new release that does both A and B concurrently. That is, make a version of 0.8.1 that: A. Has a block rejection algorithm that will reject non 0.7 compatible blocks - must be programmed first as such a thing does not exist B. Is configured to not generate non 0.7 compatible blocks - functionality exists, it just needs to be configured. Both of those can be set to expire after a certain date. This would make v0.8.1 superior for mining than 0.7 because even though it rejects the same blocks 0.7 does, it has the advantage of not ever generating such blocks (which would be orphaned). Mining on 0.7 is thus more risky as there is a chance that you will generate a block that will be incompatible and orphaned. |
|
|
|
The programmers who made 0.8 didn't consider this forking scenario. This platitude is thus entirely without merit
Pipe down, I am sure the developers thought long and hard about ways that 0.8 might cause a fork. One slipped through, because accidents happen. That was my point actually. I was not accusing the developers of negligence I was saying that his platitudes are a form of "I could have done it better then them if I was them and could see the future". Well, he isn't them and they didn't see the future. someone could start a fork the same way as just happened. Do you see? It's the all part that makes us reject your proposal B in the short term. Neither A nor B is workable as of now. Block generators are advised to use 0.7 or earlier. As long as most do, we (probably) avoid this kind of a fork. If the network ditches 0.7 then there is no problem. As long as the network is predominantly 0.7 this would result in you creating a single orphaned block rather then a fork. While certainly a waste, this could happen while using 0.7 to mine as well (for a different reason). |
|
|
|
The blocks being rejected by 0.7 are:
1. Possible to generate with 0.7 as well as 0.8
2. Perfectly valid blocks according to standard.
3. Being rejected because of a bug in 0.7
It will never, ever matter which blocks can be generated in regard to forking. What matters is what blocks are accepted and what blocks are rejected. Whether you: a. force 0.8 to reject valid blocks which it predicts 0.7 cannot process - currently cannot be done b. force 0.8 to not generate blocks which it predicts 0.7 cannot process - currently can be done The result is the same, you avoid a fork. The issue is that option A is stupid and not doable. You would need to create a new version with a special block rejection engine to arbitrarily reject valid blocks predicted to be rejected by the bugged v0.7. While for option B you simply have to alter the configuration of 0.8 And keep in mind that in reality you will see a mixed environment of 0.7, 0.8 unmodified, 0.8 with option B. Bitcoin is without central authority and with people voting by implementing whatever solution they want, if any (meaning there are going to be many people who implement NEITHER solution) As a miner, using 0.8 with option B gives you the lowest chance to generate an orphan block. followed by using 0.7 and then by option A With bank accounts, consistency in transactions is far more important than avoiding minor bugs in implementing the specifications that don't affect the consistency or correctness of the transactions. This is a hindsight analysis of what you would have done differently had you been one of the programmers working on 0.8 and had known about this possible issue in advance. The programmers who made 0.8 didn't consider this forking scenario. This platitude is thus entirely without merit This is why they made the decision to switch the mining pools to 0.7 for now. This gives the vast majority of hashing power to a universally-consistent chain. That was merely emergency measure to resolve the fork I remember reading not every 0.7 node rejected the block, and the behavior was not even consistent within a same node; some nodes would accept the block after being restarted after initially rejecting it.
That would mean that 0.7 nodes are capable of producing blocks that other nodes of the exact same version may or may not accept, depending on factors which are hard to predict.
That would mean continuing to use 0.7 is an even bigger issue. |
|
|
|
the problem is 0.7 and earlier reject valid blocks due to a bug in 0.7 and earlier. The reason the fork happened is because the 0.8 clients accepted blocks that the 0.7 clients rejected. The blocks being rejected by 0.7 are: 1. Possible to generate with 0.7 as well as 0.8
2. Perfectly valid blocks according to standard. 3. Being rejected because of a bug in 0.7 Is that so? so why didn't it happen ever before? it obviously did, but with the entire network rejecting said blocks they caused orphans instead of a fork. |
|
|
|
the problem is 0.7 and earlier reject valid blocks due to a bug in 0.7 and earlier. The reason the fork happened is because the 0.8 clients accepted blocks that the 0.7 clients rejected. The blocks being rejected by 0.7 are: 1. Possible to generate with 0.7 as well as 0.8 2. Perfectly valid blocks according to standard. 3. Being rejected because of a bug in 0.7 |
|
|
|
Always use a miner able to switch to backup pools. cgminer is my favorite, by default it will detect specific P2Pool error conditions (like a bitcoind crash) when P2Pool starts rejecting shares repeatedly, switching to the backups and saving you income. Can you make cgminer in that sentence a hyperlink? |
|
|
|
.. and 0.8 won't make a block by default that is rejected by 0.7. Miners had to explicitly raise their -blockmaxsize, which is what happened. It was suggested on a thread in the miners forum and a few folks tried it out. And we saw what happened. Now we are getting somewhere. All our disagreement can be distilled into this one single "fact" that the two of us disagreed on and only now that you posted this do I find out what that "fact" is. So, can anyone point me at evidence for or against that? as far as I knew there was no manual raising by miners and that 0.8 can, by default, generate blocks that 0.7- will reject. |
|
|
|
|
Show Posts
