Luke-Jr & gmaxwell, would you like to raise these concerns on GitHub too? The lawyers should get email notifications, I think.
I sent a copy of mine to the lawyers' emails. |
|
|
|
My review/concerns: - "The bitcoin network thrives on anonymity" is wrong. Bitcoin is not anonymous, nor intended to be. When bitcoin experts come across people making this claim, they correct them. Was this premise presented to the lawyers, or established by them somehow?
- The section "Never just send bitcoins back to someone you don’t know." implies one can be criminally liable for sending bitcoins to someone who has ulterior motives for the coins, despite having no knowledge of that intent. This seems absurd, as it would make nearly all transacting in bitcoins impractical.
- This does not seem to clearly cover the case of accidental transaction fees. The argument that the bitcoins were not lost does not seem to apply in that case. An accidental transaction fee is merely forgetting to include a change output in your transaction. The loser has not explicitly set any destination for the lost bitcoins.
I gladly defer legal matters to the lawyers, but it would be nice if they would comment on the above concerns. |
|
|
|
Ambiguous limit like 48xx or a varying limit due to a bug is unacceptable. That's why a new limit (4500) was added. This is a NEW rule. Aren't we talking about the fork (when the bug (your so-called "rule") placed a limit at 48xx)? Yes, the unacceptable nature of that rule is why we created a new rule as soon as we learned about it. Pretending it was never a rule is just distorting the facts. Also, note that in most cases the 48xx is an exact (unknown) number. It just wasn't worth anyone's time to figure out what it was. |
|
|
|
Ambiguous limit like 48xx or a varying limit due to a bug is unacceptable. That's why a new limit (4500) was added. |
|
|
|
https://en.bitcoin.it/wiki/BIP_0050A rule should be something agreed to every nodes. However, according to BIP0050: This would be an issue even if the entire network was running version 0.7.2. It is theoretically possible for one 0.7.2 node to create a block that others are unable to validate, or for 0.7.2 nodes to create block re-orgs that peers cannot validate, because the contents of each node's blkindex.dat database is not identical, and the number of locks required depends on the exact arrangement of the blkindex.dat on disk (locks are acquired per-page). As there is no consensus even among the same version (unless you can prove the otherwise), this is absolutely a bug, not a rule. There is indeed a bug in pre-0.8 versions, but part of that bug was also a protocol rule. Which part is you referring to? Please elaborate. A rule should be something reproducible in every single node of the same version. (e.g. the CHECKMULTISIG bug could be considered as a rule) "No more than 48xx unique transaction references per block" The exact number was never identified (a new limit of 4500 was added to be safer), and in some edge cases (due to the bug) could vary, but in no circumstance except a 50% attack would cause a blockchain fork. |
|
|
|
https://en.bitcoin.it/wiki/BIP_0050A rule should be something agreed to every nodes. However, according to BIP0050: This would be an issue even if the entire network was running version 0.7.2. It is theoretically possible for one 0.7.2 node to create a block that others are unable to validate, or for 0.7.2 nodes to create block re-orgs that peers cannot validate, because the contents of each node's blkindex.dat database is not identical, and the number of locks required depends on the exact arrangement of the blkindex.dat on disk (locks are acquired per-page). As there is no consensus even among the same version (unless you can prove the otherwise), this is absolutely a bug, not a rule. There is indeed a bug in pre-0.8 versions, but part of that bug was also a protocol rule. |
|
|
|
Miners have no incentive to employ monitoring of the blockchain via multiple clients like Eligius did to avoid mining any blocks on the invalid chain, if they're just going to be reimbursed anyway.
Except that in this case 0.8 miners were technically mining on a good chain and it was quite hard to detect that there was a problem. My pool has been always checking if it has the same blockchain as some other nodes, obviously this cannot cover all possible cases. No, you mined an invalid block (under the standing Bitcoin rules) and other 0.8 miners were building on top of an invalid chain. If you were testing against multiple implementations, you could have caught the problem as Eligius did. (Not to say you are at fault for the hardfork, but these are the reality of it) You are really crazy. Yes, start off with an ad hominem. Fits your post pretty well. Slush was creating blocks with "official" client and following the dev's advise to increase the block size. There is no such thing as official, and I already agreed he isn't at fault for the problem. The block is accepted by every 0.8 nodes. What do you mean by "an invalid block under the standing Bitcoin rules"?
EDIT: If a bug could be considered a "rule", should we all move back to v0.1 as it represents the "orthodox" bitcoin rules? There was a hardfork around the move to 0.3, so that is the oldest that would work to any extent with the standing Bitcoin rules. Changes in rules require advance planning and notification, and the consent of the economic majority (note, not the mining majority). Nobody had any notice of 0.8's rule change (because nobody knew about the rule), and the majority of Bitcoin users (including the economic majority) enforced the standing rules. 0.8 was the "odd man out" disagreeing over the network rules. All* the other clients agreed the block was invalid. The objective way to look at the situation is to pretend 0.8 was a completely new client with unknown source/origin introduced to the network by an unknown party. * The only other exception I am aware of was Coinbase's proprietary node, which I think can be agreed does not make a difference on its own. |
|
|
|
No, you mined an invalid block (under the standing Bitcoin rules) and other 0.8 miners were building on top of an invalid chain.
Eh, what? Can you point me to the rule which has been known at time of the fork, which has been violated by the pool? You *know* that no known bitcoin rule has been violated and that it was a bug of previous implementations. Tell me why are you spreading new FUD. Excuse me, but I'll ignore any your reaction. I'm just bored with your kind of communication. Nobody ever said the rule was known, and that's why I made a clear point that you weren't at fault. I'm sorry you have a problem with the truth being presented accurately when you don't like the facts. |
|
|
|
Miners have no incentive to employ monitoring of the blockchain via multiple clients like Eligius did to avoid mining any blocks on the invalid chain, if they're just going to be reimbursed anyway.
Except that in this case 0.8 miners were technically mining on a good chain and it was quite hard to detect that there was a problem. My pool has been always checking if it has the same blockchain as some other nodes, obviously this cannot cover all possible cases. No, you mined an invalid block (under the standing Bitcoin rules) and other 0.8 miners were building on top of an invalid chain. If you were testing against multiple implementations, you could have caught the problem as Eligius did. (Not to say you are at fault for the hardfork, but these are the reality of it) To be clear: the 'donor' was the EFF, and their only request was that the Bitcoins be given back to the bitcoin community. This indeed makes a difference, since those funds were unable to be used for their intended purpose (EFF legal work). Thanks for clarifying. |
|
|
|
The only minor concern is that the 0.7 chain was restored at 07:30 UTC, which means 6 blocks in the 0.8 orphan fork were mined AFTER the issue should have been resolved if running a standard bitcoind (as far as I'm aware). However, if the decision was made to pay out the orphan chain, it would seem unfair to withhold that compensation on certain blocks in the chain. Hmm, so by that logic miners should be okay to continue mining on the 0.8 chain now... the line has to be drawn somewhere. The problems I see with this (and why I think it was a bad idea): - Miners have no incentive to employ monitoring of the blockchain via multiple clients like Eligius did to avoid mining any blocks on the invalid chain, if they're just going to be reimbursed anyway.
- Gavin can do what he wants with his personal bitcoins, but those funds were donated to the Bitcoin Faucet with the understanding that they would be distributed to new Bitcoin users, not as a bailout for miners.
Edit: That said, what's done is done, and arguing over it isn't going to get anywhere. |
|
|
|
Thanks, I think I got them swapped to the correct order now with --gpu-map 0:1,1:0
I am guessing the REST issue is the card shutting down due to the overclocking and/or intensity level set to 5 on a computer that I actually use constantly. Weird that it's been fine for almost a year until now.
The REST was because it saw the temperature too high and was trying to cool it off - but since it had the mapping wrong, it actually shut off the wrong card, and the overheating one never cooled... |
|
|
|
Been seeing this problem come up a couple times per day for a couple months now. Either one of my cards will get stuck in a "REST" state and seemingly won't come out of it until I restart the miner. Any idea what's going on here? Also, why does the card opposite of the one in REST mode have the idle temperature?  This suggests an ADL mapping problem. Check out README. |
|
|
|
The best attack I can come up with right now is this: - Create two wallets (or two addresses)
- Buy some bitcoin into one wallet
- Transfer bitcoin back and forth as fast as possible to flood the network.
Set up as many machines as possible doing this. Somebody already tried this. Yeah - I was going to point out that such an attack will work as much to strengthen the bitcoin economy as it will to weaken it, and that site is a good example. ... except it doesn't strengthen Bicoin at all. |
|
|
|
p2pool stratum for ltc uses difficulty based on btc difficulty. Unfortunately the defacto standard as used by many pools using ltc stratum now set difficulty according to the base ltc difficulty (65536 times larger) meaning p2pool is at odds with what everyone else is doing and thus is asking for way too low difficulties making cgminer submit shares of much lower difficulty than p2pool is expecting. As there is a precedent with other pools setting the defacto standard prior to p2pool, unfortunately the onus is on p2pool to come in line with the rest.
This is really a bug in litecoin pools and *gminer. p2pool handles it more sanely. The protocol/miner only cares about algorithm, not network. The original bug is in stratum, for specifying a network-related variable unit for difficulty, instead of the actual target. But as long as stratum is specifying target as a fuzzy bdiff, pools using litecoin-diff instead are merely violating the spec. |
|
|
|
I think you've missed the point of quantum computing (at least the theory anyway)
It is not about brute force decryption and a quantum computer is able to consider multiple instances at the same time. Liken this to being able to trace backwards the encryption algorithm used to encrypt the data...if every point down the road can be simultaneously compared, the last point that lead to the previous point can be discovered. IF quantum computing ever becomes a reality even a basic quantum computer able to compare a handful of instances simultaneously would make quick work of any encryption sequence generated by a binary computer.
Make no doubt about it...if quantum computers become a reality Bitcoin and the security of any computations done on conventional computers will break down in a hurry.
Bitcoin does not use any encryption. It does use cryptographic signatures, which are in this case vulnerable to quantum computers, but the hashing algorithm is not. Any quantum upgrades will likely continue to use SHA256d as their proof-of-work. |
|
|
|
[troll]
Let me get that [ignore] for you. And yes, the SHA256 fork (this original one) will always be compatible. So if someone hacks SHA256 (not in our lifetimes) these current BITCOIN ASICs will be worthless. Seeing as SHA1 has already been compromised I expect we'll live to see SHA256 compromised, that if unless you happen to be 80+. It could take 10 years, or 10 minutes but I'm quite convinced I'll live to see it. You need to compromise SHA256d, not just SHA256. If anyone ever makes a quantum computer hash functions like the SHA series will be obsolete immediately. Either that or a vulnerability is found or rainbow tables are generated. A lot of things can happen in 10 years, especially in computers. Believe me when I say that Bitcoin is not going to work long-term without major changes to the system to keep up with technology on a regular basis. There is, at present, no reason to think quantum computers break SHA-2. |
|
|
|
I just found out there is a minimum payout ... switching back to p2pool - I am too small for eligius too. May be later  Technically speaking, there is a minimum payout with p2pool also, due to higher difficulty. I'm waiting for eligius and other pools to start setting the global minimum difficulty above 1.0... FWIW, the latest BFGMiner (git at least) has a --request-diff option. |
|
|
|
Hi Folks, I'm not sure if this is an issue or not. I get a lot of "Stratum from pool 0 requested work restart" when on us.ozco.in:3333. Here's a screen: http://imgur.com/b6p3NKN I'm using a ATI 6770 @ .95 volts, reduced engine and memory to keep my temp around 68C. BFGminer is a wonderful tool, but I'm not sure I am using it correctly. Does anyone have any input? Thanks! Perfectly normal on sratum pools |
|
|
|
I think I'll post a detailed guide about p2pool in the following days in order to promote it's adoption (my configuration is giving me satisfaction and I see many people who don't get as good results as mine).
There are some things hard to find by searching the forums and some urban legend to address too. There are cases where p2pool isn't a good solution that should be clearly reminded (BFL singles, some network setups, ...) so that people don't waste time with it when they'll clearly lose income instead of gaining some vs ordinary pools.
Don't forget to mention that p2pool was basically broken by all this :p |
|
|
|
|
Show Posts
