I don't think it will be much of a performance hit to make the mining client keep their counter in a non-native byte ordering. If their native byte ordering is messed up, they will just have to use an 8 bit counter for the inner loop, and have a tiny bit of logic for incrementing and checking the rest when it overflows every 256 hashes.
Even if the conversion from network order to native order took as much work as a full (double) SHA256 hash, the performance it would be under 0.4%. In practice, it will be MUCH less overhead. On an Intel, it won't even take an extra register.
Just make sure that all of your range boundaries are multiples of 256.
Except that AIUI, GPUs don't iterate. They run them all at once... No, they still iterate. They just use larger increments. Unless there is a chip out there with 4 billion ALUs that I don't know about. |
|
|
|
Then what is the disconnect? Have you read the white paper? If so, are you sure that you understood it? Bitcoin has a lot of moving parts, really. The possibility of a blockchain attack doing any lasting harm is directly addressed in Satoshi's white paper, and what I think that you guys are describing isn't possible with less than a majority hashing power.
The disconnect here is that you're talking about "lasting harm" in the context of the network. If I get one confirm, give you the keys to my car, you drive off and the blockchain reorganizes so your payment goes someplace else (due to double spending on another branch)— lasting harm was done by any sane measure. If you wait long enough then you can make the risk arbitrarily small, though the buyers risk starts increasing with too much delay and large delay aren't always tolerable. If the network is more concentrated (lower latency, longer block intervals) then it is less likely for someone to pull off an uncertain low depth attack because there will be fewer instances of multiple forks with a non-trivial survival chance. Escrow. |
|
|
|
|
Eh, I wouldn't. Spending will have race conditions at the very least, and possibly worse. And if you don't need to spend from both, there are better ways to convey balance information around than to calculate it all in both places.
|
|
|
|
|
I don't think it will be much of a performance hit to make the mining client keep their counter in a non-native byte ordering. If their native byte ordering is messed up, they will just have to use an 8 bit counter for the inner loop, and have a tiny bit of logic for incrementing and checking the rest when it overflows every 256 hashes.
Even if the conversion from network order to native order took as much work as a full (double) SHA256 hash, the performance it would be under 0.4%. In practice, it will be MUCH less overhead. On an Intel, it won't even take an extra register.
Just make sure that all of your range boundaries are multiples of 256.
|
|
|
|
The weak spot in Bitcoin is the size of the blockchain.
with trimming we only need to store about 30% of the total chain. yes it will get big, but storage sizes will go up with it. 5 years ago 500gb was big, these days 3tb drives are a avalable. just because it is available does not mean most people have it. most people these days. 31% of steam users have a harddrive from 250-500gigs. although you can see that 750gig+ builds are growing fairly fast. with 1tb+ over 25% give it 2 years and id guess 1-1.5TB will be around 30% with 2tb+ being 20-25% I predict that a client for casual users that stores as little of the chain as possible will be in widespread use at least one full year before the size of the block chain database file grows to the size that would take up 1% of the average (mean) hard drive size of typical home PCs. |
|
|
|
Wow. That article is amazing. He seems to think that the problem is fraudulent bitcoin transactions being converted to dollars, when the real issue, as far as I can tell, is fraudulent bank transactions being converted to bitcoins. A quick quote to illustrate what I'm talking about. Someone obviously figured out how to game it.
That poses a lot of questions I don’t have answers for. If someone steals the bananas you buy at the store. What do you do?
Let me rewrite that in a way that reflects reality: Someone obviously figured out how to game Dwolla.
That poses a lot of questions I should have answers for, but don't. If someone steals from Dwolla and then launders the gains through an irreversible system, what does Dwolla do?
|
|
|
|
Is it intentional that under the current rules depositing more money reduces your chances of getting selected randomly? If you wanted it the other way around, try this: SELECT MemberId FROM bpMember ORDER BY (fromWallet+1)*rand() DESC LIMIT 1;
Both algorithms are correct and favor members who deposited more. I tried both of them 100000 times and here are the results. Which one would you choose?  Ahh, my bad. The sorting order got me. As I was working it all out, my head got stuck thinking higher = better. |
|
|
|
1) You are double counting. There is no measurement of hashing speed, just an estimate. Stale shares (the end result of latency) are already not factored into the speed estimates.
I don't see the relevance here. It's not like I'm scoring the pools based on their estimated hash rate and deducting points for stales. If anything, stales are just an indication of what I mean, just that I'm talking about a particular stale -> the winning share that became stale/invalid. 2) Your argument is circular. You have no knowledge about the distribution of hashing rates within the pools, but you assume that bigger pools have higher average speeds, and then you count that assumption as a confirmation.
Claiming every MHash is equal is also making assumptions, assumptions about each individual miner's network speed, each pool's network speed being equal. When working with large enough numbers, things tend to follow a similar distribution so usually assumptions are made. As long as the assumptions are reasonable and applied equally, then it's a valid basis until proven wrong. Since this is a hypothesis, I wouldn't be surprised to be wrong in either the hypothesis or assumptions leading to it but you've got to at least put some data on the table to convince me otherwise you know  You are the one making the claim. The burden of proof is on you. I'm just poking holes in it, I have to prove nothing. Let me try it another way. You are saying that 10 miners doing 500 Mhash/sec each are better than 100 miners doing 50 Mhash/sec each. As evidence in support of your hypothesis, you say that the big pools are getting more blocks than you would expect based purely on their (estimated) fraction of the (estimated) global hashing power. The problem is that you don't have any idea on the composition of the miners inside the pools. Let me give you an example. BTC Guild is reporting about 2.3 THash/sec now, but it provides no data on the number or speed of the miners that make that number. Could be 9000 miners turning in ~260 Mhash/sec each, or it could be 15,000 miners doing ~150 Mhash/sec each. Could be anything, really. So, you aren't actually providing any evidence to support your claim. Unless you have some reason to believe that the distribution of miners in the larger pools is unusual in some way, the whole topic of pools is an unrelated distraction. |
|
|
|
Is it intentional that under the current rules depositing more money reduces your chances of getting selected randomly? If you wanted it the other way around, try this: SELECT MemberId FROM bpMember ORDER BY (fromWallet+1)*rand() DESC LIMIT 1;
|
|
|
|
I'm going to say that it matters because of latencies.
A worker requests for a few pieces of work per getwork by default, let's say 6. If it takes a 100MH/s miner 10 seconds on the average to finish 1 share and the winning work was number 6, it would be 1 minute before the worker sends back a what should be the winning share.
If the 1 GH/s miner got the same set of work, it would be 6 seconds before it finds the winning block.
So although on pure hash rate alone, a network with 100x 0.1GH/s workers should have the same chance as 10x 1GH/s user, the latencies gives the pool with faster average workers a slight edge.
I'm testing this hypothesis by checking the blocks found since the past 85 hours or so. The top few pools has about 81% of the network hash rate but account for 91% of found blocks. If probability of finding a block is equal per MHash holds true, then we should see 81% of hashrate finding around 81% of blocks. But as it is, it's a significant 10% gap.
You don't see any flaws in your analysis? Here are two that are instantly obvious to me. 1) You are double counting. There is no measurement of hashing speed, just an estimate. Stale shares (the end result of latency) are already not factored into the speed estimates. 2) Your argument is circular. You have no knowledge about the distribution of hashing rates within the pools, but you assume that bigger pools have higher average speeds, and then you count that assumption as a confirmation. |
|
|
|
Allow me to elaborate, and see if my math is correct. With 51% hash power, a peer has 51% chance of producing a block before anyone else does. The chance of producing two blocks before anyone else does is .51^2, or 26%. With 40% hash power, the same calculation (0.4^2) is 16%. Thus with 51% hash power your odds of being able to produce two blocks before anyone else produces one is only 10% better than with only 40% hash power. Of course you are continually attempting to produce two blocks so your chances of producing two blocks before any one else can be expressed as a function of the number of blocks that you've been trying to do this for. | 1 | 2 | 3 | 4 | 5 | 6 | | 51% | 26% | 45.3% | 59.5% | 70% | 77.9% | 83.6% | | 40% | 16% | 29.5% | 40.8% | 50.3% | 58.2% | 64.9% |
Your math only applies if the attacker is going about the attack in real time. There is another type of attack where the attack chain is kept secret until it is long enough to overturn a deeply buried transaction. |
|
|
|
the blockchain right now is not 600mb, its more like 400, excluding the index files. and that can be compressed to at least 80% of the original size. and. 16 gigs should be good for a linux install and 2 more years worth of blockchain worst case. It is my understanding that the nodes save multiple copies of the block-chain in case of a split or one of the block-chains becomes the "longest" one. I have had a test-node running since June 9, 2011 (0.2.22 and 0.2.23) for a total of 55 days. It ran out of disk space today; consuming 5.8 GB. That works out to 105MB per day. Disk usage dropped to 4.9GB when the client exited. The client had 125 connections during peak times. No, it doesn't save multiple copies. When there is a fork, it keeps both blocks, but it doesn't need to make a copy of the rest of the chain to do it. Check to see if you have a debug.log. If I don't clear mine often it gets huge. Currently around 1.5 GB. |
|
|
|
The block chain is not very compressible, since most of it is hashes. I got 21% space savings with gzip and 22% savings with bzip2. (436690683 vs. 345345519 vs. 341013976 bytes) The real magic comes in when you realize that you can prune old transactions. Since any transaction in the chain can be the input for at most one new transaction, you can delete any transaction that was spent more than X blocks ago, with no ill effects. Someone wrote a tool for that, and if I recall, he reported that something like 70% of the chain can be pruned already. All non-miner clients need are block headers and access to a trusted node that has the transactions cached.
Ah, no. All a non miner client needs is a prototcol talking to atrusted server. No need to store anything except addresses and private keys. You can send signed transactions to the server and get balacnes and new transfers from the server. Stick it THIN - so you dont need to sync anything. Laptop open, check, finished. The trusted server part is currently difficult, so I expect a medium-weight client to pop up and be useful sooner than a fully stripped lightweight client. That is, unless one of the 3 or more people/groups working on hardware wallets makes some big progress before a serious smartphone developer gets the itch to code up a medium client. |
|
|
|
|
The exact shapes of lightweight clients and protocols are not yet known, but lots of people are thinking about / working on them.
|
|
|
|
What exactly is the luck part about?
Mining is really a lottery. Each hash calculated has a 1 in 7.26 quadrillion chance of winning (right now). BTC Guild is currently running around 2.4 billion hashes per second, so it should expect a win every 3000 seconds or so, which is around 50 minutes. But since it is a lottery, there is no promise of winning. A block may be found after a minute, or after several hours. The deviation away from the statistical expectation is the "luck". |
|
|
|
...uBTC... Use 'μ' (mu) instead of 'u', please. Please do accept u if it ever comes up for input. |
|
|
|
|
In Zeno's paradox, the tortoise has a head start, say 100 meters, but Achilles runs 10 times faster. By the time Achilles reaches the place where the tortoise started, the tortoise is 10 meters down the course. When Achilles reaches that point, the tortoise will be a meter further. And then 10 centimeters, then 1 centimeter, and so on. Achilles can never win. He can't even catch the tortoise because every time he reaches where the tortoise has been, the tortoise has moved a tiny bit forward.
We now understand this problem in terms of the limit of the infinite sequence. Even though the sequence is infinite, the limit is not.
In the same way, a borrower can pay back a loan of more than 21 million BTC, even if the loan has interest, and the total amount paid can be finite.
|
|
|
|
If there are 21 Million bitcoins potentially and someone lends someone 1 million bitcoins with .5% interest, 20,000 bitcoins are the interest. In fiat currency the interest would be stolen off, in bitcoins, it cannot really be taken anywhere, so the question is semi-redundant and a joke in fact. It's a trick question of sorts.
The situation you describe is not a problem at all. Even (taking this to absurdity) if you borrowed all 21 million bitcoins at 5% interest and had to pay back 22,050,000 bitcoins, more than there exist, this would not be a fundamental problem for the monetary system. You would just have to present goods and services to holder(s) of Bitcoins at an agreed upon value of BTC22,050,000. I'm having difficulty following your logic. In your example, you hold all $21MM Bitcoins. There are no other holders of Bitcoin. You're it. How do you "present goods and services to holder(s) of Bitcoins" when none of them exist? Further why would anyone agree to pay something knowing that they can never collect on those 1,050,000BTC's that exceed the limit? Unless the loan has some sort of silly provision requiring the entire payment to be atomic, the loan holder could easily pay part of it, then buy some bitcoins back from you to pay off the rest. But what if that amount costs you interest? The solution to Zeno's Paradox of Achilles and the Tortoise has been known for centuries now. The answer is calculus. |
|
|
|
If there are 21 Million bitcoins potentially and someone lends someone 1 million bitcoins with .5% interest, 20,000 bitcoins are the interest. In fiat currency the interest would be stolen off, in bitcoins, it cannot really be taken anywhere, so the question is semi-redundant and a joke in fact. It's a trick question of sorts.
The situation you describe is not a problem at all. Even (taking this to absurdity) if you borrowed all 21 million bitcoins at 5% interest and had to pay back 22,050,000 bitcoins, more than there exist, this would not be a fundamental problem for the monetary system. You would just have to present goods and services to holder(s) of Bitcoins at an agreed upon value of BTC22,050,000. I'm having difficulty following your logic. In your example, you hold all $21MM Bitcoins. There are no other holders of Bitcoin. You're it. How do you "present goods and services to holder(s) of Bitcoins" when none of them exist? Further why would anyone agree to pay something knowing that they can never collect on those 1,050,000BTC's that exceed the limit? Unless the loan has some sort of silly provision requiring the entire payment to be atomic, the loan holder could easily pay part of it, then buy some bitcoins back from you to pay off the rest. |
|
|
|
|
Show Posts
