If I pass the data back to the server in hexadecimal is there a way to test or get an answer if that was right? Did the server answert with something like "ok" or "bad data"?
It returns true or false. |
|
|
|
theymos, so miners can choose the tx's they want to include initially in the midstate or hash1 to form the Merkle root which is included in the header and then from there forward they can hash away with only the nonce changing until they undercut the target?
No. The transactions are already chosen when you get getwork. midstate and hash1 are used only to make hashing faster. |
|
|
|
00000001 version
3d9dcbbc2d120137c5b1cb1da96bd45b249fd1014ae2c2b40000151100000000 prev
9726fba001940ebb5c04adc4450bdc0c20b50db44951d9ca22fc5e75d51d501f root
4deec271 timestamp
1a1d932f target
00000000 **This is the nonce**
000000800000000000000000000000000000000000000000000000000000000000000000000000000000000080020000 |
|
|
|
|
In "look and layout settings", change your "time offset" to 0.
|
|
|
|
|
"midstate" and "hash1" are optionally used for a mining optimization. Some of the work doesn't need to be repeated for each attempt: this is the data that allows you to skip it.
"data" is what you're hashing. You hash this, modify the nonce in the data if the hash is not below the target, and repeat.
You only need to hash the header, which is the "data" getwork gives you. The block body is not hashed by miners. Bitcoin deals with this.
When you return a block, Bitcoin just checks to see if it's valid. It doesn't need to match anything.
I assume that you pass hexadecimal data back to getblock. I'm not sure.
|
|
|
|
|
It worked when I changed it. Maybe it's a problem with your browser.
|
|
|
|
No, not really. Having 51% of the total network hashing power only gives you about a half a percentage point of success, it just makes it possible. Even with 51%, a double spend is pretty hard to get away with.
Actually, with 51% you can stop all other generators from making blocks, which makes double-spending easy. I'm not too worried in this case, though. |
|
|
|
getwork is new for me! I googled it and wonder if you mean m0mchils patch? I patch the bitcoin client (or server?) with it and so I'm able to get block data and return it to the network if I find a block? That would be easier than I thought but not really a own miner implementation I guess?  It's an official RPC method now. Every recent version of Bitcoin has it. It allows miners to get the necessary data from Bitcoin. If I understand you right I could take only one of the new transactions and double SHA256 it with the concatenation of itself? Like SHA256(SHA256(hash + hash))?
So what I have then is a really small merkle root isn't it? I could use it for a valid block but I guess that isn't really good for the quality of the network!? "Keep doing this until you have only one hash left." If you have only one transaction in the block, then the hash of that transaction is the Merkle root. Is there nothing to ensure that as many transactions as possible will be putted in a new block? No. Only transaction fees. Only the longest chain is valid right? So there is a tie of two chains cause of two valid blocks and the next block for one of it decided that this on is the valid chain. But now there could be also been found a new
block for the other chain and after that one again one more new block. So now the other chain is longer than the first one! Is this one now the new valid?? That could happen, though it is unlikely. The ties will be broken eventually. Whoever gets the last block in the series of ties will decide it. |
|
|
|
You guys are nuts! BTC hasn't even quite reached $2. I predict a drop to $1 or less.
Anyone want to bet me that it won't go above $20?
Sure glad I didn't make that bet with anyone! |
|
|
|
The number has decreased a bit since then. The current number is 1,955,255.34766447 BTC controlled by the top 100 addresses. hash160 | balance
-------------------------------------------+-----------------
f783b20d88f026a18d865f80dab4b6a042ec436a | 297000.00000000
0b52d2bf8c2d52f71cc675eda2f82b532df0cc8c | 135140.00000000
a0b0d60e5991578ed37cbda2b17d8b2ce23ab295 | 79956.00100000
12ab8dc588ca9d5787dde7eb29569da63c3a238c | 75523.03100000
55f64292a5ac67092c02612e38e6176a72c28769 | 51116.30100000
863ec44fbf7c9ed0819b52f275006b22ba781794 | 50000.00000000
5ecec489d27713f8bc119529ffd411cebbaa8aa6 | 50000.00000000
c075d789bbcb43ad7dc4d1311d607b8c00ad3cee | 49511.44100000
496127e27d6eedf8e71950b0ea77a30564722340 | 49157.97000000
4ff9d8d6614b1da5b3e46ef51c61a544626bf6e5 | 38000.00000000
5fe963e6d08693fb8adf5813e9788a865aa60f5a | 33165.37148936
12d5a845f2b212ce0c3bd65a4035881d9219090e | 31000.00000000
3add0300fbe4f2f22c5971849fb505cca137ce2d | 30367.97000000
14c1ed72d09150b8e5f49d94d53070d2c1f1db36 | 28150.00000000
3379411ed78ad936eb9645c7476084195f2919f5 | 26354.16000000
fb8bd809c899d98ec6fbf45f4b29b560a1f98afd | 24738.91000000
595820bcf733aaac9bf4bc8206114e80e896d974 | 24638.45000000
1242a9c6ac1267fbd1b72a2bb7bc019cbac15968 | 23249.00000000
6dca3bdb31ad8563b42c923e4304b2d772627cfd | 22000.00000000
0eb9cd1cbf83c0dd5e6fe0196319284fbb5e680e | 20001.00000000
25a16581425de617c0b839856e4a54090d8b3550 | 20000.00000000
aaab00906d3d65232bb5cd6e70382955cf1f5361 | 20000.00000000
c3f5e1c3ff49d6a710617e0bbd31b9ec2f39b38d | 19901.47000000
f8753559cd673046044baf06725c7a94bcb8a592 | 19400.00000000
5ee9d53cebf714a5c27516e9c02f565e0c2871f9 | 18131.31000000
28b4a69ff958801b1289f6888671eba670dcf51d | 15849.24000000
2416dda31e4c5c9c09e0b37cb738a1bbe47efacb | 15000.00000000
cb24c764c73cefdae506160af6e15cd2bef42ca9 | 14250.00000000
23305d92c35165e847fddd45d3b61419bfbcbe7c | 13000.00000000
0b5af3dd8ef575853ef70f6cbf128d5bb54eb73c | 12950.00000000
6ddea8071439951115469d0d2e2b80ecbcdd48db | 12800.00000000
4cc112f80d571b95af213d14b6797b537c7b6e86 | 12500.00000000
239a84f046e82d2fa86dce6db8e9db5d437073e7 | 12200.00000000
6043fb30952b2876ed1627263f46447ed1704915 | 12167.79000000
4f09071a923997504898e74c9c65cbd5a96c3f23 | 12050.02000000
b56c40a3dbc4f8a8eef67eeb27e23cec5ca40da8 | 11300.00000000
1fef43aec46fe7de0db22c5a6cae94d17e012980 | 11211.11000000
a31ce48dee1d068f32ba91469c6f0fcd64c5a3bd | 10687.47000000
718f66473ce787b667f61e3e242e1ead28ce9e75 | 10672.08000000
2b6a52cd26a105a80b2f890dd26b1551d782f80b | 10500.00000000
f717fdfa4126000872db1d4f5f9835649cdba4b5 | 10391.81200000
c5f9b83bab9177a02a50379e3dfdf11e6e3f5927 | 10290.25000000
f790a54cc6094e7f8a6600299755e28233fd9951 | 10195.22000000
773aeb91dd78068271ca2764925d3c1d63f593fb | 10050.00000000
35abf7a634ad786894a473b8612551b75e0f8092 | 10008.18000000
af28dbe17a9f15264738d5147e215abd32a76489 | 10000.00000000
c44728c579f3cf29db4d373c57c77ad8e9b29ea4 | 10000.00000000
cc09aca7e05eb5a3519b535ece40cafc7157386e | 10000.00000000
6f711c825976d3e171f52d1255bf4729a5a786c2 | 10000.00000000
7ceee99631098c391869241768b354601be45201 | 10000.00000000
14adec07961b45af6b9b9a353d279d737047f4c1 | 10000.00000000
26d45a268d236f025aab79f69aa30fffcb2c623c | 10000.00000000
8d7894bbde47aa1ddb2edcbc498fcab7ec0067c9 | 10000.00000000
7c45a41deffc48e117376e123934fc826a883255 | 10000.00000000
09f349307b923b61145029efdc5c9ba5b7ebde52 | 10000.00000000
2867d85fbf0e4a634575c7b45a75d4dc22eb99a0 | 10000.00000000
0730733b14f38b9ffd71c7af91d5bd42f6f91eee | 10000.00000000
c10520e8fbdc808d33669574b409db55e5663321 | 10000.00000000
993929463df23528617ea0d8aa6664d97a21764e | 10000.00000000
f175606e5002520a4b8f34c9eebe2dec38e71cfd | 10000.00000000
11de35c5727122f4f58517a8d963b208442dc3a3 | 10000.00000000
21c42956d1797a70c6daf10ae0b562ba1729db78 | 10000.00000000
58692e7b59b1fc8eb58ee6f09c63905496784661 | 10000.00000000
ed33889b6753be90376aef06905f6e27a26c04a5 | 10000.00000000
ebd77d983fc7db5816540d05844c269d6ec4858e | 10000.00000000
86ee0c126632b436ebfaa6c2e11bf5b3334d8152 | 10000.00000000
d76e40c22e6629836c33954ab022de8afb15070b | 10000.00000000
e5b8f736464da3afb1a23491c2cf5f6c9a99fd1b | 9851.00000000
06232586eae88d66c230cc6ff812c4bafddabbab | 9672.63193511
a6d510056d2632097ddc94e4f7d4e74bee1e2e03 | 9478.77000000
39e87e1755dc10c0a5593160289a0f2fc66af6a1 | 9444.00000000
0703b54f51575ad4903a8dbfc87da7943f524472 | 9396.86000000
b346a3bce0e6f5e8d01b6a739c0501492dd5f5eb | 9260.00000000
128d539da005113582943913277040ee178c61e1 | 9067.32000000
722b7959135b3504687ab4a3999d351cff87a956 | 9000.00000000
051bd789eab2bfc3ab5b8035e9aa724b7e122116 | 8999.59000000
381642c97cbdcf66aa4b2d13f7e31468ef9c7437 | 8999.00000000
75fab6b73969851ebd7956572c1e77ed80ecb6e9 | 8500.00000000
e6612bbb60b49448bae08367f5ec4c50548db6d1 | 8458.00000000
de0fdebd40daee7ff91c46ccd6c45872099d1bfc | 8200.00000000
c5839180ab72a7740b2139f17b9e5e3f37631dd2 | 8007.05000000
fc3b79bed5f612f81e7627d954f3088b39e69bb3 | 8000.00000000
592fc3990026334c8c6fb2b9da457179cdb5c688 | 8000.00000000
9185f1f79e5edcc5dd35885377cc8515641a8744 | 8000.00000000
31f19a7d0379f56cb3be0761c21f1f0c9553a47f | 7941.06000000
591ecdb88e60d6ef49c95ce5d271f5607e0d9cc1 | 7799.00000000
ec9f0c1849c5fc200d4cef5ee0517c6514a96fb8 | 7500.00000000
51a4e740af16874a23d57e9c96fbb3ce630b1f4e | 7372.00000000
8648b7496dcbbfeda495bfa828d84d0a1c68f3d5 | 7000.00000000
8e8c77799661b09000df1985dacfe336d6389d80 | 7000.00000000
9cf513086124ba54448a0abcc1770e80eefdc6ec | 6999.00000000
7265bb0f0bf610545837184e1774932c48568ae0 | 6969.69000000
a9949114fb32f2df3181c9280dd68e3cf9fa9375 | 6828.15824000
581eacd2bcf02709a30907f2653984229bfd9014 | 6800.65000000
673218140922079f78e28a5e0df18ad4eca6b53e | 6705.00000000
68a6b725b529a2633557ab14c036b4761a826cf5 | 6511.96000000
e1ee58a6ed77021253b9b0e71064f0bb998d2841 | 6400.00000000
89008dfd301ad098e368693d8bf9bcdedf78bd6c | 6309.40000000
b072156738de266ff47a5397202455560707f58d | 6155.65000000
2f8e38cca3095579b29a1c77cf79d3891e64caf8 | 6054.00000000 Perhaps a more interesting figure is that 48924 generations are unspent. Three-fourths of these are before block #70,000. I can provide a complete list if someone wants to make a nice graph. |
|
|
|
Miners don't deal with that. Bitcoin does that stuff and returns the result to miners in getwork. Here's an example of a tree: https://en.bitcoin.it/wiki/Dump_format#CBlockIf you find the full hashes used here (search Bitcoin Block Explorer), you can try hashing them yourself. They will work. You take each pair of transaction hashes, concatenate them, and hash them twice with SHA-256. Keep doing this until you have only one hash left. When there is an odd number of hashes, concatenate the last hash with itself. So your example is correct if you double each hash. The top hash (Merkle root) is included in the block header. The transactions are in the block body. Intermediate hashes in the tree are not included in the block. Bitcoin has a database of all transactions, which lets it know which transactions are new. It also needs to check the validity of all transactions before including them. In the case of a tie, only one block will end up being accepted. Whoever ends up solving the next block will decide which one. Bitcoin gets transactions from the network. You're not forced to include any transactions, though in the future most of your income will come from transaction fees. So your block is still valid if you miss a transaction (or even all transactions). Again, nothing I described in this post is done by mining software. |
|
|
|
I would assume that the mention of a database means that accounts were drained from the database itself, not through individual account passwords. (ie; the bitcoins you had sitting there and the bitcoins I had sitting there weren't actually in separate places)
My password was changed, so it was more than just getting to the wallet. |
|
|
|
|
I'll look into this within the next few days.
|
|
|
|
My account was compromised...  It can't have been a brute-force attack. My password couldn't have been brute-forced. |
|
|
|
That is a quite negative view I think. This could easily be resolved by requiring that the list of peers being sent from a supernode is up-to-date (as in, the nodes are still online). When the client begins to connect to the list of peers received and hits a certain number of failed connections, block all updates from that supernode.
I suggested something like that earlier in the thread... I'm not saying the idea is bad. I'm just saying that not broadcasting your own IP will by itself not be very helpful in the long-term, and thinking only of that might lead down the wrong path. For example, if we know that supernodes will need to check peers, a new network command for "am I reachable?" will not be necessary. You can just see whether you appear in the addr lists of your peers (if their version is OK). |
|
|
|
Ah I just assumed since the software seems to list number of blocks instead of block number there would be a difference of one since the first block was number 0.
Both Bitcoin and BBE consider the genesis block to be block 0. Bitcoin's getblockcount is named very misleadingly (for historical reasons): it actually reports the block number instead of the block count. There's actually getblockcount+1 blocks if you count the genesis block. |
|
|
|
Blockexplorer will normally appear to be 1 block behind because their counting starts at 0 rather than 1.
Bitcoin Block Explorer counts the same way Bitcoin does. It just has a slight delay. |
|
|
|
sure, but that has very little to do with bitcoin, no? the same central signer could support paypal, wire transfers, etc., all at the same time.
i suppose what's novel with bitcoin plus a central signing service is that the signed tokens could be denominated in bitcoins, but that still seems to have little technically to do with bitcoin. in other words, it has about as much to do with the bitcoin protocol as otc trades of bitcoin balances on mt. gox.
It just seems to fit. Bitcoin and blinded tokens are cryptographic systems with swapped strengths and weaknesses. Auditing is easier with Bitcoin, since anyone can see the funds owned by the central authority. (Of course, proving that they have a full reserve is more difficult.) |
|
|
|
|
This seems unnecessary to me. I have not seen any posts that apply only to Canadian people, and even ones that are somehow related to Canada would not fill a page.
|
|
|
|
|
Show Posts
