The proof of work is not a hash of the entire block then?
Or is it an indirect hash of something in the header which is itself a hash to all transactions? Even if it's that, wouldn't such header have to be retransmitted each time a new transaction is propagated?
It is a hash of the header which contains the Merkle Root of all transactions in the block plus the hash of the last block. That is how the "chain" is efficiently created. If you know a previous block is valid and each block contains the hash of the prior block in the current block then you know the current block is valid by following the chain from the genesis block. Every transaction in the current block is confirmed because the merkle root is the hash that contains all the hashes of the transaction in the block. If an extra transaction was added or one taken away the merkle root hash would be invalid. https://en.bitcoin.it/wiki/Block_hashing_algorithmAll together the only thing that is hashed is the header which is 80 bytes. The nonce is determined by the miner so the pool actually only transmits 76 bytes. The miner then tries all nonces from 0 to 2^32 -1 (roughly 4 billion attempted hashes). A shares is 2^32 hashes so 1 share ~= 1 header transmitted. Since nonce only has 2^32 possibilities the pool server needs to provide a new header (containing extra nonnce) after every 4 billion hashes. Thus bandwidth requirement (without any overhead) is ~ 72 bytes every 4 GH (the same header can be used for 4 billion hashes) of hashing power that the miner has. Even a 40GH miner wouldn't require very much bandwidth. It would require 10 headers per second and would produce 10 shares (lower difficulty solutions) per second. The headers would require ~800 bps inbound and the outgoing shares would require ~2kbps outbound. Now for the server that bandwidth requirement can be larger as they will have significantly more aggregate traffic. A 5TH/s mining pool would need to issue 23,283 headers per second but even that is only 1.8Mbps. Still bandwidth is really a non-issue. As difficulty rise and the pool gets larger the computational load on server becomes the larger bottleneck. Every 2^32 hashes a miner will need a new header and that requires the pool to change the generation transaction and thus requires a new hash and that changes the merkle root which requires a new hash. If it ever became a problem where pools simply couldn't handle the load, changing the size of the nonce could make the problem more manageable. The Nonce is only 32 bit and is the only element a pool miner changes thus every pool miner needs a new header ever 4 billion hashes. A 100MH/s miner needs a new header every 40 seconds. A 4GH/s miner needs a new header every second. If the nonce value was larger more hashes could be attempted without changing the header. For example if nonce value was 64bit a 4GH miner would only need a ONE header every 17 minutes instead of one every second (unless a block was found). Most miners would never change headers except when a block is found. The load on pool server could be cut by a factor of billions. This would also slow transactions, and/or not decrease traffic by nearly as much as you expect. The mining pool node is constantly updating its Merkle tree, so a new getwork request includes not just a different coinbase with a new extranonce, but also a different set of transactions, some new. A 64 bit nonce would roughly triple the average transaction confirmation time, unless the node trips the long polling system, which makes extra traffic. |
|
|
|
That's the opposite of independence. It means that the same party needs to do both CPU and GPU to validate their block. So end users can't mine because they don't have GPUs. And there's no way to adjust difficulty separately since you don't have separate blocks to count.
No it wouldn't. It would simply be a public double signing. Two algorithms lets call them C & G (for obvious reasons). A pool of G miners find a hash below their target and sign the block and publish it to all other nodes in network. The block is now half signed. A pool of C miners then take the half signed block and look for a hash that meets their independent target. The block is now fully signed. Simply adjust the rules for a valid block then for those half signing they can only generate a reward half the size + half transaction fees. The second half does the same. So the G miner (or pool) who half signs the block gets 25BTC + 1/2 transaction fees, the C miners would complete the half signed block get the other 25 BTC + 1/2 the transaction fees. A block isn't considered confirmed until both halves of the hash pair are complete and published. If you want block signing to take 10 minutes of average adjust the difficulty for each half so that average solution takes 5 minutes for half signed block. While I doubt any dual algorithm solution is needed it makes more sense to have both keys required otherwise bitcoin becomes vulnerable to the weaker of either algorithm (which is worse than having single algorithm). There are subtle, er, issues with this idea. I think they are actually problems, but I haven't worked through all the details yet, so I'm not confident enough to use that label yet. Think carefully about the coinbase transactions, and how those are included (or not) in the half signatures. I'm pretty sure that this system ends up being no better than just the second half system, but it could be modified to be as good as whichever system was slower at the moment. |
|
|
|
Unless I'm seriously misunderstanding, no one is discussing asymmetric adjustments here..
You are. This is exactly what is under discussion. From the OP: “It would (as I said) be an up or down adjustment test, not just for downward adjustments.” Maybe I'm misunderstanding what you mean by asymmetric? EDIT: Regarding ArtForz's attack (the one you linked to), it was against against an off-by-one error in the implementation of bitcoin. That sort of thing is really orthogonal to the discussion here. Unless there is another attack he published that I'm not aware of? If the difficulty adjustment takes fewer blocks in certain circumstances, that is what I mean by asymmetric. And it can be gamed. |
|
|
|
Fine, then ponder this for a while: https://bitcointalk.org/index.php?topic=42417.msg517020#msg517020Executive summary: asymmetric difficulty adjustments and adjustments based on time are really, really hard to get correct. I haven't thought about it hard, but I trust ArtForz when he says he thinks it is IMPOSSIBLE to get it right. Well that's a link back to around when he first pointed out the issue. So your saying his fix that even he proposed doesn't work? (yes I haven't looked at his fix - I guess I was silly to trust ArtForz's comments about there being a fix  ) Anyway, there's a 144 block buffer in my suggestion already (the 12 block test can only re-diff once before the buffer hits again) My reasoning for the buffer was to avoid statistical variance after a re-diff - but it seems to help with the time problem also. The 'ArtForz' takeover requires 51% which really is a non issue for the main block chain. If we suddenly fall low enough for someone to do a 51% takeover (other than a company like MS or google or a large government who could do it now anyway) then with the current software everyone will just ride it straight to the ground anyway due to no re-diff happening ever again. * kano ... wanders off to read up about the problems with the time fix and who actually implemented it ... I'm of the opinion that if there is ever a huge sudden decline in the hashing power, there won't be a system to worry about. But, since your scenario is about what to do in exactly that situation, you can't hide behind the "but bitcoin is huge" thing any more, because 51% isn't a big deal at that scale. At any rate, the big problem is that it aligns the incentives in a bad way. With an asymmetric system, each miner has a personal incentive to join the cabal. The current system is careful about keeping the interests of each participant aligned with the interests of the system as a whole. |
|
|
|
I wouldn't read too much into gas prices. They've been damn strange since 2008. In my opinion, gas prices have been about 50 cents too high for the last year or so. I keep my eyes on TWIP. We've been above the average range on crude stockpiles for a whole year now. Gasoline stocks have been mostly quite high, not counting the exaggerated spring dip. Also, notice how flat the 2009-2010 retail prices were. It is hard to say if the current decline in gas prices are the usual annual fall drop, a correction long overdue from 2008, or another sign of the strengthening dollar. |
|
|
|
Unless I'm seriously misunderstanding, no one is discussing asymmetric adjustments here..
You are. This is exactly what is under discussion. |
|
|
|
|
Allowing asymmetric adjustments can lead to security problems. Artforz described a few when this came up on alternate chains.
|
|
|
|
No evidence but it really is kind of obvious if you think about it.
Lots of things are obvious when you think about it. That's kinda why people ask for proof. |
|
|
|
Bad. Very bad actually. The throughput is in Mbps. A hash is based on 512 byte message. A bitcoin solution takes 2 hashes. Thus Mbps/1024 ~= MH/s. For their example FPGA it is in the ballpark of ~1Mbps. The FPGA developers on this forum have achieved far more. It is even worse than you think. All commercial SHA coprocessors are built for streaming, which doesn't work for bitcoin. |
|
|
|
|
Hmm. Slogans for Occupy <X> protests.
How about these?
"I'm pissed at my dad, but he isn't here, so I'm going to antagonize some cops instead!"
"I have $100,000 in student loans for my sociology degree, and I don't want to accept responsibility for my poor decisions!"
"It isn't fair that other people became successful while I was wasting my life!"
I dislike our current monetary system as much as the next guy (actually, more than most, I'd say), but these protests aren't about that, and even if they were, they wouldn't accomplish anything anyway. If you can create a few new bitcoin enthusiasts, great. Or if you can pick up a naive coed by showing her that you care about "the issues", that's fine too. But don't fool yourself into thinking that these events are anything but group displays of social posturing.
|
|
|
|
Any minute now, I expect to hear a large cracking noise from when her cranial pressure, which has been increasing this past month, finally breaks through her skull and Raytheon realizes that maybe this is a life-threatening medical emergency. Hell, they have the ability, the rescue plan, the weather is fine, and the cost of a rescue is expensive, but is built into the cost of doing business at the south pole and getting paid shittons of federal grant money to run the place. That's where the story ends, poorly. The last part is real. There really is a woman who had a stroke and is stuck at the South Pole because of bureaucracy and greed, waiting patiently either for her brain to swell up and kill her or for this to actually be classified as a medical emergency. http://scienceblogs.com/gregladen/2011/09/stroke_victim_not_evacuated_fr.phphttp://www.reddit.com/r/reddit.com/comments/kw9uc/a_friend_of_a_friend_who_is_a_scientist_in/Oh well. It's not like a massive military contractor ever gave a flying fuck about people's lives when money is to be had. Read the comments on those links you posted. Getting in and out of Antarctica in the winter (roughly March through October) isn't trivial, and the evacuate/wait decision isn't taken lightly. Raytheon isn't run by a an emotionless computer program somewhere, there are real people making the decisions, and they weighed the risk to her against the risk to the dozen or so people that would have to fly in to the harshest environment on the planet in conditions well outside the operational envelope of even the toughest aircraft in the world. |
|
|
|
If it's buying as much as it's selling how is the price trending lower?
It will continue to undercut on sells to force the price down, while lowering it's buys, and selling to fulfill buy orders that are higher than it's own. Thus, forcing the price lower.  |
|
|
|
So, I think if I were working on this, I'd start with the goal of running a bitcoin instance without a local block chain available and make it communicate with another instance of bitcoin whenever portions of the block chain were needed.
See the todo link in my sig. |
|
|
|
|
Things seem to be drifting very slowly in this direction. The problem is that nodes and wallets are much more tightly coupled than you'd expect. But we'll get there eventually.
|
|
|
|
|
Everyone has different ideas about what should be filtered. Best to leave that function to the endpoint.
|
|
|
|
|
Just be warned, speculating isn't easy. If you don't know what you are doing, you will get burned.
|
|
|
|
|
I just did a withdrawal from mtgox to Dwolla. Took about 10 minutes to go through and confirm.
Then again, I'm not a raving anti-mtgox conspiracy nut, which pretty much makes me a paid shill by the standards of this thread. So I don't expect anyone to believe me, nor to try it with their own account.
|
|
|
|
That's like saying the world will end after the last minutes of December 31st, that's the end of the calendar...
Actually their calender ends at Dec 21. But it isn't a arbitrary date either like our calender "after Jesus Christ" but rather calculated to coincide with unique constellations of the solar system. In a manner of speaking it is the ultimate Astrology... if you believe in that  That's why McKennas I'Ching stuff (Timewave Zero) happens to end at the same moment as the Mayan Calender. Ahem. It is really a lot more like the transition from 1999 to 2000 in our calendar. They just didn't bother to publish tables more than a few hundred years into the future, so it appears to end there. And no matter how hard I try, I am unable to figure out any possible meaning in the phrase "unique constellations of the solar system". |
|
|
|
Coin destruction certainly exists, but it isn't a problem. So far, no one but you seems to have taken any offense to it. Why do you think it is a problem?
Because a) it's good to know exactly how many coins will be/are in circulation b) the number of bitcoins has a hard capped limit and if enough are destroyed it will make it difficult to function properly as a currency. Why are you so against fixing the issue? a) true, but so what? Also, impossible. b) false, so long as destroyed < 100% It is a pointless change. Yes, I said change. Not a problem. Not an issue. A change. Do you understand the value now?
You could do this fairly easily with Shamir's secret sharing algorithm. Just generate 4 shares of a single SHA256 private key with 2 shares required for reconstruction. You keep one, the bank keeps one and two go in the vault. Or even more straight forward just code this type of transaction into the client. Yes you will need to update, but i expect the scripting will require updates as well. At the moment not even the main bitcoin client has all the script operands enabled, Bitcoinj only supports 7. As different clients become more popular it will be difficult to ensure scripts are fully supported. Yes, this one example can be done in many ways. But I think you missed the key point of my previous post. I'll repeat it here: All of this can be done using the scripting system, and without anyone in the entire network having to update their client to allow it specifically
The scripts allow anyone, anywhere to devise their own systems without seeking permission from the rest of the world. I guess if you don't see that as a useful feature, I'm not going to waste any time trying to convince you. But then again, I don't need to either. You are the one asking the world to change. By the way, these two topics have been discussed to death on these forums. Search for "demurrage" and "script". |
|
|
|
|
Show Posts
