Why not reverse the number 1st before indexing. This way you move all the zeros to the other end and the tree will balance perfectly.
Holy shit! That is a damn good idea. Ooh, how about this though? Just take the bits in the proper order from the far end. That way, the tree lookup is just nextChunkID = ((needle >> (depth *9)) & 0x1F) *4; |
|
|
|
|
From the chatter in IRC, it sounds like Piuk already found and fixed the bug. I'm pretty sure he is running a modified client to feed his website's database and gmaxwell fed it directly to that node (because no other client would relay it).
|
|
|
|
gmaxwell has pointer out that to me that there are some fields that are passed to the bitforce hardware. They are:
- timestamp
- difficulty target
Any one of them can be used code a "time bomb".
I would have been better if Hash(Hash(Header-without-nonce) || nonce) would be chosen for PoW instead of Hash(header) for Bitcoin.
Ouch, you are right, the ASIC producers really could create timebomb chips. Nice catch. If we ever figure out who Satoshi is, we'll have to give him a little crap for missing that potential attack. But honestly, who could have seen that one coming? The good news is that there are several ASIC designs ongoing, and they will presumably all come out of different fabs, so in the long run, the diversity of the network should provide some safety. Maybe we should put this on the hardfork wishlist. Changing the hashing method entirely would be, well, bad. But we could accept two different hashing methods, the old way and the new safer way that doesn't leak any information to the hashing device. That way we aren't breaking the large investment into current ASICs, while allowing miners the option of safer hashing when they expand/replace their gear. (Verification would be trivial, wouldn't even need a new block version. If the normal hash attempt doesn't work, try it again with the header's nonce field set to zero and the external nonce value set to whatever was in the block.) Amusingly, on IRC we were talking about chips that could accept the entire header as their input rather than the midstate. This way, ASIC designers could build their chips to refuse to participate in certain kinds of attacks, which would reduce the amount of trust that miners need to have in the pools they use. I'm curious how the mining world would balance these two concerns with contradictory solutions. |
|
|
|
But that is less than 10 minutes, well inside the range to be "not a jump". A timestamp discontinuity isn't "more than the last few blocks", it is "more than the rules say".
Perhaps you need to speak more concretely then. What rule? Any rule you can imagine could be met by a natural block gap. E.g. you set it to two hours. Then a natural two hour gap happens, and an attacker can create a chain killer fork that covers that gap. Sorry, I thought that I had been quite clear about it. The rule that I suggested was "not more than X hours newer than the deep block with the same height", where X is >=3. Keep in mind that this is only for deep replacement, that is important. As in, I'm currently on block # 197,710. I get a new block claiming to be # 193,001. The timestamp on the new block is from yesterday, which is ~2.5 million seconds later than the block # 193,001 that I already have, thus I conclude that the new block is bogus and drop it. However, if there was a natural network gap of more than X hours, and an attacker presented a chain during that time, that chain wouldn't really be an attack, it would be the chain. |
|
|
|
He would cut back one week, and create a fork with a bunch of consecutive timestamps. e.g. 1 1 1 1 1 1 2 2 2 2 2 2 3 3 3 ....
Then a new bootstrapping node would startup and see "1 1 1 1 1 1 2 2 2 2 2 2 3 3 3". Then it would hear the valid chain, and see "1 600 1200..." and think that it jumped.
But that is less than 10 minutes, well inside the range to be "not a jump". A timestamp discontinuity isn't "more than the last few blocks", it is "more than the rules say". which would be a de facto protocol change.
Then any bugfix that changes the typical network behavior is a 'protocol change'. Not really a useful distinction, in my view. We're just arguing over defintions, which is a waste of time. The important point is that a fixed node is fixed without upgrading any of its peers. Call that whatever you like.  The nodes that do not use your algorithm would still be flooding the network (or at least each other) with BS blocks. The only way to prevent that is to force nodes to switch to your algorithm, which would be a protocol change. Currently, they are allowed to do it however they want, as long as the end result is the same. The difference is subtle today, but I think it will be less so as the network outgrows the current homogeneous period. If there's no central distribution list for these and it's up to miners/merchants to invoke the RPC by hand
Of course there would be, otherwise it would be a config option and not an RPC. We do not have any 'dynamic risk' "last resort" mechanisms anymore: no safemode alerts. Checkpoints only get changed by updating the software. Maybe we could implement the idea of dynamic checkpoints (Gavin) but only if they come signed by the Alert signing key ...
Or even we could create a special Alert message that comes with a new checkpoint embedded.
This would be a mid point between Gavin and gmaxwell positions.
0_o I don't consider that a midpoint at all. We'd first have to rename Gavin "Bitcoin Bernanke", but fortunately I know he's smart enough to not accept that job. +1 |
|
|
|
I don't know where to post this, so here it is :
are there any concerns about something like Y2K syndrome ?
are miners supposed to change something in their code ?
will the number of btc per block be the only thing that will change ?
Everything is taken care of already by Satoshi. It's in the rules. A block with number > 210,000 giving a coinbase transaction of greater than 25 BTC will be invalid and rejected by honest miners. Afaik that's all that will change (it will not really change, the rule has been there all the time, just didn't take effect because block numbers have been < 210,000 so far. There might theoretically be a bug, but I'm sure a lot of devs and others have checked. int64 static GetBlockValue(int nHeight, int64 nFees)
{
int64 nSubsidy = 50 * COIN;
// Subsidy is cut in half every 210000 blocks, which will occur approximately every 4 years
nSubsidy >>= (nHeight / 210000);
return nSubsidy + nFees;
}
Not many places for bugs to hide in that code. |
|
|
|
Damm hope it comes to the EU. Might buy one or two  It is made in Austria. I'd be surprised if EU folks can't get it first. |
|
|
|
You understand that insurance is inherently fraudulent, right? It can't exist without force, fraud, and eventual state backing. If you pay for Bitcoin "insurance", the insurer is going to use your payments to set up ways to track you and all of your transactions. You understand that, right?
I mean, people here just got done losing a whole bunch of Bitcoins in a fairly obvious ponzi scheme, so I feel obligated to point this out.
HuH? How is insurance inherently fraudulent? Yes, many insurance companies are the scum of the Earth because states let them get away with a lot of bullshit, but that doesn't mean it is inherently fraudulent. Basically, in the long run it is impossible to both cover worst-case losses and turn a profit. The only way it works in the real world is via the fraud of fiat currency and the force of government backing. Bitcoin has neither, thankfully. Insurance is older than central banking money-from-nothing. Policies have limits for the exact reason you are talking about. |
|
|
|
Newly mined coins aren't valid until 100 blocks have passed
...
Also, you end up with a race if the reorg goes back to before the script would have become valid, which might only be two or three blocks, which happen on a regular basis already when there is no practical way to profit from them. So, theoretically, couldn't the same limit be placed on spending the output of a time locked transaction, to prevent this? Right now, you can validate a block with no prior knowledge of any of the transactions in it. If you are thinking what I think you are thinking, it would require that every node have perfect knowledge of all transactions on the network before it could be sure a block was valid. Or maybe you are thinking something else, I'm not sure. |
|
|
|
No, there is no way to get the block number in a script. People keep asking for it, but it wasn't left out by accident, it is missing for a reason. (Please think about how the network handles block reorgs for a while before you ask...)
Pardon my ignorance, but all I know about reorgs is that the block that loses the race gets ignored. Its transactions are not valid anymore and must be included in another block. Why does that makes it impossible to get the block number, or other block header data, in a script? I mean, I understand it might be complicated and perhaps not worthwhile doing. But it's not impossible, is it? We put a lot of effort into avoiding the possibility of invalidating a chain of transactions. Newly mined coins aren't valid until 100 blocks have passed (120 in practice, but the hard requirement is only 100). If not for that requirement, a miner could create some coins, spend them, the recipient could spend them, etc, and then a shallow reorg would invalidate the coinbase, and break the whole chain. People should wait for sufficient confirmations to avoid the problem, but they don't, so the network makes it impossible. Now, what happens when scripts can be either valid or invalid depending on which block they are in? The same whole mess that we were trying to avoid. The invalidated transactions might not be valid for inclusion in the next block, and the transactions that spent them are also possibly invalid. And yes, I know that we could maybe come up with yet another special case in the script system so that the block height can only be checked with a greater than operation, but ugh. Also, you end up with a race if the reorg goes back to before the script would have become valid, which might only be two or three blocks, which happen on a regular basis already when there is no practical way to profit from them. You create a transaction that will not be valid for a month (whatever) and broadcast it. Then an attacker gets in and steals the private key for that address. They can create a new transaction that sends the money to their own address. Honest nodes will consider that a double spend and refuse to relay it.
No... honest nodes should consider the legit owner is cancelling the transaction. nLockTime shouldn't be used to protect against private key loss. Since you'll have to secure the target key of the transaction anyway, why don't you secure the current key the same way? I might be remembering it wrong, it's been a while since I looked into nLockTime. Either way, we both come to the same conclusion: timelocking can't work. |
|
|
|
Unrelated to your algorithm, say that the attacker did have 51% of the network power, which I think is silly, but try it anyway. The current rules allow him to rewrite history, and blatantly tell everyone that he is doing it (by using correct timestamps). Why not force him to make fake timestamps back to his chosen fork point, and then accept the difficulty adjustment consequences of doing so? The amount of extra work for the attacker would in some cases be non-trivial.
And my philosophical objection still stands. Why should the network accept a block today, with a timestamp of today, as a candidate to start a fork days or weeks or months in the past? Inertia doesn't seem to be a good answer to that question.
You're imagining a honest shorter chain, and a dishonest longer fork that has a big timestamp gap. Lets reverse that: Imagine the network is following your rules. There is an honest longest chain. Now I construct a dishonest fork timestamped such that the true longest chain looks like it jumped forward in time relative to to my fork. Either the whole network now rejects the honest chain on seeing my fork (bad), or they only apply your rule only one way on reorg decision (e.g. only demand it when switching from a 'better timestamped' shorter fork to a longer fork) which would mean that a newly bootstraped node's chain decision depends on which chain he heard first (because the dishonest fork may have been the longest from his perspective until he heard the longer one) and as a result network can't reliably converge (bad). How would an attacker re-write the timestamps in the blocks that everyone already has? The original chain has a sequence of blocks with (more or less) evenly spaced timestamps, and there is no possible way for an attacker to make that look like it has a jump in it. The best the attacker could do would be to pile up the timestamps, one after another, in his attack chain. He can't go backwards to make a jump. Essentially, if we are looking at a possible fork from, say, a month ago, the first block in the newly presented fork really should have a timestamp from a month ago too. I'm skeptical about the extra work comment... The amount of work needed to overtake the longest chain from a given cut point is _constant_: its the amount of work in the longest chain after that cut. Difficulty doesn't come into play. Ignoring the timewarp issue, there isn't much advantage that can be gained by lying about the timestamps, and most you could get 4x per 8 weeks you cut. Go too far back and you need a really significant super majority to get ahead in a reasonable time... and the advantage is just the inflation you could create for as a factor of log4(your rate/network rate) from undercorrection with your correct timestamps during the point where your chain is 'catching up'.
Good point on the constant work amount. Whatever he gains by messing with the old timestamps, he'll lose when his fork is putting out blocks more often than usual and he'll end up in the same place. When I initially read your message I misread it as asserting that sufficiently old stamped blocks should not be considered. I realize now I misread it, but since someone else might have:Because unless you will accept old timestamps any partition would result in a perpetually unresolvable hardfork— you start with a worldwide Bitcoin, a cable gets cut and a a little bit later you have north american bitcoin vs everyone else, and everyones bitcoin is now double spendable (once in each partition).
Worse, an attacker could intentionally produce these kinds splits by creating slightly longer fork and then announcing it to half the world right at the edge of whatever criteria you impose for 'too old a rewrite', so that half would accept it and the other half would hear about it too late.
Yup, that idea would have some issues. I occasionally suggest using an exponential difficulty difference for triggering deep reorgs (or rather for avoiding them), and people make similar objections to that proposal too. Also, it doesn't help that we are wandering around two different issues, a 51% attack and a BS blockspam annoyance. Your algorithm would kill the blockspam problem, but only if every client uses your algorithm, which would be a de facto protocol change. |
|
|
|
Yes, thank you, my entire point was that the code as written today allows this case. I'm suggesting that it might maybe be a good idea to change that. Did you even read my posts? I was trying to draw attention to the fact that all the suggested fixes here involve allowing permanent forks. But yeah I misread some tenses. I'm not sure that my suggestion actually allows for permanent forks, at least not honest ones. In an honest fork, the timestamps in both branches will follow the rules, allowing an isolated network to rejoin. |
|
|
|
The problem is that when you look at a block by itself, you don't know if that block is eventually going to be part of a chain with more difficulty than what you already have or not. The timewarp won't give the attacker a longer (more difficult) chain, but it can allow him to create a ton of blocks that look valid enough by
Please do me the respect of reading my message above where (in the last paragraph) I explain how to solve this, in a way which isn't a fork or a rule change at all... just a minor difference in the order of operations when fetching and checking a chain. While I didn't include an actual implementation, I provided pseudocode of the algorithm detailed enough to propose attacks against. Heh, I did read it. It seems like a good system for usability/performance. I wouldn't classify that as a "minor" change in client behavior exactly, but it does have the advantage of not changing the timestamp rules. Something about it bothers me, but I'm not sure what. I think it might be that it only protects clients that use that algorithm for fetching blocks, leaving the rest of the network open to the attack. The same could probably be said about changes to the timestamp rules, at least right now while the network is fairly homogeneous. I will ponder on it some more. Unrelated to your algorithm, say that the attacker did have 51% of the network power, which I think is silly, but try it anyway. The current rules allow him to rewrite history, and blatantly tell everyone that he is doing it (by using correct timestamps). Why not force him to make fake timestamps back to his chosen fork point, and then accept the difficulty adjustment consequences of doing so? The amount of extra work for the attacker would in some cases be non-trivial. And my philosophical objection still stands. Why should the network accept a block today, with a timestamp of today, as a candidate to start a fork days or weeks or months in the past? Inertia doesn't seem to be a good answer to that question. |
|
|
|
Right now, an attacker doesn't even need to create much of a chain. He can just generate enough blocks to trigger the difficulty adjustment a few times, and then keep generating the lowest difficulty block over and over again.
Right. Because of the timewarp attack an attacker who cuts >2 weeks back (more is better, of course) can make a chain with interleaved past timestamps which reduces in difficulty no matter how much hashpower he's throwing at it (if anyone is interested in this attack, I performed it on testnet3). Of course, if he doesn't have a majority of the hashpower his chain won't be the longest; so it's moot except as a flooding DOS against nodes with the full block sync behavior. It's possible to do a little more aggressive timestamp sanity checking to largely close that behavior... but it's hardly an attack if nodes first check header difficulty before pulling a chain. The problem is that when you look at a block by itself, you don't know if that block is eventually going to be part of a chain with more difficulty than what you already have or not. The timewarp won't give the attacker a longer (more difficult) chain, but it can allow him to create a ton of blocks that look valid enough by themselves that we have to keep them around anyway. This is a potential DOS vector, not necessarily a Finney. I know that a ton of work is currently underway on the block storing and indexing parts of the client, so presumably a node will be able to purge BS blocks like this sooner or later, but why even assist the attacker by letting the network relay them? |
|
|
|
|
What would be really handy would be a block hash or height number to tell it to rescan starting from there instead of from the genesis block. Is there an easy way to turn either of the human-visible block identifiers into a CBlockIndex pointer?
|
|
|
|
The miner timestamp. We already enforce rules on the miner-provided timestamps, No, the rule is enforced between blocks strung together, not the blocks on their own. Block 2 can not be more than 2 hours before block 1 or whatever the rule is. If another whole chain of blocks come along from a common point, as long as they follow that one rule about block X+1 being less than 2 hours before block X, then it is valid. In main.cpp, the two rules are: CBlock::CheckBlock ensures that a block's timestamp is no more than 2 hours into the future at the time it is first seen by a node. CBlock::AcceptBlock ensures that a block's timestamp is greater than the median of the timestamps of the 11 blocks before it. AcceptBlock is called before a block is written to disk, CheckBlock is called earlier. In practice, this gives you about 3 hours of wiggle room. Read his attack again, it depends on timestamp manipulation to multiply the amount of DOS-blocks generated by a factor of 16 (per month). It does not depend on timestamp manipulation, it depends on creating a chain with a very low difficulty with the intent to spam the network. I don't think Sergio's specific example works because of the 2016 block requirement for changing difficulty though. By starting from the latest checkpoint and waiting a month, he is able to generate 16 times as many blocks as he would otherwise be able to generate. The amount of blockspam is directly connected to the interval between the block chosen for his starting point (typically the latest checkpoint), and today. There is absolutely no reason why the network should consider a block mined today, with a timestamp from today, as a candidate to create a month-old fork. Well perhaps you should check the code then, because it is perfectly valid. The only thing preventing this is hard-coded checkpoints. Yes, thank you, my entire point was that the code as written today allows this case. I'm suggesting that it might maybe be a good idea to change that. Did you even read my posts? Right now, an attacker doesn't even need to create much of a chain. He can just generate enough blocks to trigger the difficulty adjustment a few times, and then keep generating the lowest difficulty block over and over again. |
|
|
|
* This suggests a potentially useful patch. I haven't checked, maybe something like this is already implemented. If you get a block that could potentially replace block N, but the new block's timestamp is more than X hours after the timestamp in block N, refuse to relay it. Besides the fact that timestamps are added by the miner creating the block, if you mean the time when the blocks are received this breaks the "unified vision" of one block chain. Forks can exist permanently without users or miners having done anything wrong. But this is also along the same lines of what Gavin suggested. This is mostly in the case of a network split though which I think is pretty unlikely and shouldn't be guarded against when it leaves the network open to certain types of more important attacks. If there is a permanent fork, then leave it up to the users and the community to decide which chain is the correct one. In the case of a network split where one country's internet is cut off or something, it is obvious. The miner timestamp. We already enforce rules on the miner-provided timestamps, this is just one more. It shouldn't cause any problems for honest forks, even when X is pretty low. Read his attack again, it depends on timestamp manipulation to multiply the amount of DOS-blocks generated by a factor of 16 (per month). There is absolutely no reason why the network should consider a block mined today, with a timestamp from today, as a candidate to create a month-old fork. The only legitimate reason to allow this is for cases like the infamous overflow bugfix. I doubt that such a fix would work the same way today as it did back then, but if that is a concern, setting X to something high, like 168, should provide plenty of time. |
|
|
|
I just don't see any part of this working. First, a million dollars won't do it because a million dollars worth of available ASICs don't exist. I guess the million could be spent stealing (or developing) a clone, but that is just an argument in favor of getting ASIC miners into peoples' hands ASAP. Second, the attack chain would be laughably invalid. Currently, I think you might be right about the DOS potential here, but only from flooding the network with blocks that can never be connected. See * below for mitigation. Third, what gets passed to the device is the midstate. The device has no idea what the current block height is, nor does it have access to any sort of keys. (See here for an example of what exactly gets sent to the device.) * This suggests a potentially useful patch. I haven't checked, maybe something like this is already implemented. If you get a block that could potentially replace block N, but the new block's timestamp is more than X hours after the timestamp in block N, refuse to relay it. X=3 fits with the currently allowed amount of clock skew in the network, but X=6, X=12 or X=24 would be more conservative, and any of them would work. |
|
|
|
|
An easy way to mine is included in the default client. Check out the RPC calls "getgenerate" and "setgenerate".
|
|
|
|
|
Show Posts
