As far as I see, the basic idea of mining, is that we get piece of data, where we need to try all variants of 4 specific bytes = 2^32 variants, we hash this data using SHA256 and if we get value meeting our difficulty requirements we "win"(?)
I wonder how does this work on lower level:
1) How it's made that different clients does not work on the same variants?
2) How it is prevented that client who found solution would "steal" 50BTC, instead of submitting solution to the pool server?
3) How does pool software process this solution to get 50BTC and notify whole system that everyone (including other pools & individuals) need to work on next block?
4) Is that correct that all fees associated with newly generated solution are "payed" to the owner of this solution in the nearest minutes after it's generation?
Sorry for dumb questions, and thanks :-)
(1) There are 640 bits of input— the whole block header. It includes a version number, a timestamp, the hash of the prior block, the hash of the hashes of the the transactions, and the 32bit part you sweep (the nonce). Most work doesn't have any solutions at all. You can think of the whole process as throwing dice. (yes, the hash is deterministic, but no two throws will ever be the same). Inside the coinbase txn there is an extra nonce value where the creator of the block header can increment some more (e.g. if it needs more candidate blocks than the timestamp resolution * nonce space would allow for). (this is, e.g. why mining isn't a race, everyone is working on something completely different and someone else solving a block doesn't throw out the work you did, or prevent you from solving one) (2) The solution is bound to the identity of the key that gets paid the 50btc via the included hash. Change the payment address and you'd invalidate your solution. (3) Imagine you are throwing dice the pool has given you. The dice have the pools name written on them. You throw and throw. A throw of 1 solves the block. The pool asks you to report any throws you get <=3, you do this and it proves you are working. Sometimes your <=3 throw is a 1 and the pool announces it to the world. Everyone else can trivially see that the "throw" is the required value, so they treat that solution as good (by running the hash once) and continue building the next block in the chain after it. They simply announce it to all the bitcoin nodes they're talking to, who announce it to all their peers, and so on. (4) No. It's not award minutes after, it's 'awarded' either "instantly" or "after several hours" depending on how you want to look at it. When the block is formed all the transactions are groomed up, any time the inputs to a TXN are greater than their outputs in value the excess is the fee. The miner adds this fee to the 50BTC the network rules allow them to create out of thin air, and specify it in the coinbase transaction (called 'generated' in most software) that transaction specifies that the funds be paid to a key they hold. So it's an instant thing. Alternatively, the network won't let you spend from a generated txn until it is at least 100 blocks old— this is to avoid massive drama should their be a long chain split an the block not end up as part of the longest chain. If block ends up being excluded from the longest chain all spends originating in the coin made in that block would be invalidated. So the fees (and the reward) are only paid, or at least only available to be spent, until many hours later. |
|
|
|
But what if nobody find a block on 2 hours? Network goes to s**t?
No. You should read the code. It's much easier to read it than it is to come up with a legit attack... The constraint isn't 2 hours since the last block, it's two hours ahead of the the current network time, not the last block time. |
|
|
|
I know, it is much more critical the scenario where elliptic curve (EC) fails, but EC is somehow safe. The insecurity of EC does not depend on smart cryptanalysis, but in advances on mathematics and/or quantum computing.
Cryptanalysis _is_ advances on mathematics. It's also worth noting that EC based hashes were rejected as part of SHA3 (e.g. ECOH). |
|
|
|
The keyfile is mostly a file to help make your password more secure. A lot of people use crappy passwords. If they used the keyfile it would add lot's of random info to the password so if just the wallet is stolen they won't be able to brute force the password unless they also know the keyfile and have a copy. It's what truecrypt can use.
Strengthening probably addresses this better by making the bruteforce too slow to be effective against all but the dumbest passwords. Its important to keep in mind that, recent hysteria notwithstanding, the greater risk to most bitcoin users is coin _loss_ not coin theft. Security measures are important, but if they make you more likely to lose your coins or suffer data corruption then they are probably a net harm to the users overall. Basic wallet encryption is probably a net gain— widely used it should immunize the whole community against the creation of collection worms somewhat though it will cause some people to lose coins that wouldn't otherwise be lost. I doubt this is true for keyfile boosted encryption. Moreover, if you want that you can have it externally to bitcoin. |
|
|
|
So I hear a lot of talk about how Bcrypt is so much better in terms of it making it longer to crack each hashed password from a compromised database. So Is there really a huge difference in how long it will take to crack a SHA(256/512) in comparison to Bcrypt. and I know the answer is bcrypt but How much of a difference? are we talking years or just a couple of weeks difference? Please cite your sources if you have any, if not at least speak from your own experience and not other peoples experience's to sound all smart. Thanks  If you're interested in this area: scrypt is obviously superior to bcrypt for this purpose. In addition to being simply harder its design prevents someone with specialized hardware from getting an enormous attack cost advantage vs the user. http://www.tarsnap.com/scrypt/scrypt.pdf |
|
|
|
But the goal isn't to manipulate the transactions, the goal is to manipulate the difficulty so that more blocks could get mined so more rewards are available. Doesn't every miner have an incentive to set their clock slightly ahead, so that difficulty is slightly less, at least for the one difficulty adjustment period that they start doing this for? (And once they do, they need to keep on doing it to keep it from making up the adjustment later.)
I doubt there's a real "attack" here, but it should be understood by everyone that the timestamp in blocks is really only accurate to within whatever the acceptable window is.
No, but this is one of the reasons difficulty is adjusted only every 2016 blocks instead of e.g. every block. https://en.bitcoin.it/wiki/Protocol_rules block messages #5 "Block timestamp must not be more than two hours in the future" (compared to network time) So the most miners can advance the clock is two hours in a window of 2016 blocks... giving a maximum improvement of about half a percent when hashrate is stationary. Doing so will also bring about the reward halving earlier, so its even less attractive if you expect to have a greater share of hash power in the future. Network time ought to be hard to manipulate, though it isn't currently. But the most you can manipulate network time is -/+70 minutes of the nodes local clocks. |
|
|
|
Where is the source? This is very clearly a derivative of AMDOverdriveCtrl which is licensed under the GPLv2. |
|
|
|
We need nodes so payments can get processed!
Mining isn't everything. The more people have the Bitcoin client open, the easier it is to send/receive payments -- and that benefits EVERYONE, including YOU. You send/receive payments, don't you? (to cash in your Bitcoins, if nothing else)
It's important to forward the port (8333) if you do this. Nodes which don't listen can't connect to each other and contribute much less to the health of the network— especially with the influx of new users. Also make sure you're running .22 or (better) .23-rc1: the newer versions are more permissive about relaying low/no fee transactions. |
|
|
|
Votes aren't a good way to decide these issues. I suggest Matt just submit a pull req to enable it by default and let Gavin decide.
UPnP is a de-facto standard that's used by virtually all p2p software. The fact that it's even an option puts Bitcoin behind apps like Skype in terms of UI simplicity. It's definitely worth enabling it by default, at minimum.
Instead of talking about how great UPNP is it would be much more useful to tell everyone if you've tried it and if it worked. It's not a feature developers are likely to use — other than to test it. It would be pretty terrible if it turned out that it had a bug which occasionally crashed bitcoin and it got enabled by default. Also, looking at the implementation it appears that it tries to use UPNP even when its not required to get the port open. Thats probably somewhat less than optimal, since the upnp traffic might make network operators mistake bitcoin for filetrading applications in the same way IRC seed makes people mistake bitcoin for a botnet. |
|
|
|
100 blocks to mature eh? Everywhere I've read says it's 120. Has it always been that way? Do you have a reference I could refer to for more reading up on this?
It has always been that way. Everywhere says 120 because that's what the client says. The actual network limit is 100, though. Check the code: static const int COINBASE_MATURITY = 100; Use the -printblock switch to dump all blocks (including orphans) to debug.log, and then post the last few thousand blocks to pastebin or something so I can examine your block. I'm using a limit of 103 on namcoin. I was using just 100 for a while but had some weird behavior with getting a rejection notice when I did sends of coin right at 100 (thought it got sent and mined ::shrugs: I assume this was due to neighboring nodes not having the latest block yet then rejecting my txn. 20 is kinda nuts (especially on bitcoin) but I think having a buffer of a few is good. I haven't bothered making the same change for bitcoin because I'm not using new generations quickly there. |
|
|
|
At the moment addresses are used as fairly ephemeral things and the recommendation is to use a new receiving address for each payment. This limits the utility of vanity addresses and so I don't believe it's worth implementing. This may change in future however as new bitcoin services arise.
It can be implemented securely but the method touches on some issues I should currently keep confidential. However it's an elementary problem for any half-way decent cryptographer.
Indeed. I spent a while thinking about it and realized I was being stupid. The number of times the point was added initially (the private key) is unknown but you can keep adding it more without difficulty and get additional keys, then just add that value to the private key. |
|
|
|
Anyone else got this shit?
No, but I looked inside the binaries provided and two things are obvious: (1) The code has been through a java obfuscator (ProGuard), so it's hard to tell what it's doing. (2) The CL code, however, is unchanged from the normal diablominer. _Hopefully_ this just connects you to some other pool. But I am not even that optimistic. If you have run this on a computer with a wallet.dat I think you should treat that wallet as compromised. |
|
|
|
We may easily add other conditions to being a supernode, besides uptime and working incoming connections.
I would strongly recommend adding a blockheight check as well. Right now you can _easily_ form cliques of empty-headed nodes that talk only among themselves and have never seen the rest of the network. I'm not actually concerned with being able to provide the chain itself, but rather having the chain is evidence that you've been connected to the rest of the network before and therefore know some addresses that may get someone connected to it again. I'd personally use the highest checkpoint coded into the software, but really— it should probably be fine to use the earliest and thus allow nodes to begin seeding a bit faster. This measure also proxies for another thing: systems which are too overloaded or poorly connected to successfully download the blockchain should probably not get a bunch of leaf nodes connecting to them. Also, jrmithdobbs has a pull request someplace with some reasonable RFC1918/private IP detection logic. Separately, on IRC nodes which decide that they are successfully listening ought to join multiple random IRC channels. Two would be sufficient for making partitioning unlikely, but three might be better. (Not that this general proposal should depend on IRC— this should just be one part of its effect) |
|
|
|
|
I put in a sell order for 1 BTC on MTGOX at 1e120, just to see what the limit was. The system now reports I have an open order at 3.40282e+38.
This doesn't fill me with confidence. Might make some of the weird rounding on orders I've heard people complain about in IRC make more sense...
|
|
|
|
Thanks! But I'm not sure I get this... I've read about transaction fees on the wikiw: https://en.bitcoin.it/wiki/Transaction_fees and I understand that there is a mandatory fee on very small amounts, less than 0.01. But even if this has changed, the error message I get tells me that the amount I'm trying to send, 0.01 BTC, is over the size limit. What size limit? Does this refer to the "blocksize"? The wiki says "0.01 BTC fee per kilobyte of transaction, but: If the blocksize (size of all transactions currently waiting to be included in a block) is less than 27 kB, transactions are free." Have I come above 27 kB? How do I know the blocksize? Are other people able to send 0.01 BTC without paying fees? Yes, the message you're seeing is a bit confusing. As you read, TXN with parts less than 0.01 have a mandatory fee however the client enforces a fee in another case: When the transaction has very low priority (and may takes weeks to get processed). The priority of the transaction is computed based on txn_value * age_of_coins / tx_size_in_bytes. The age is how long they've been sitting in your wallet. If the priority is low enough that the rest of the network would handle your txn very slowly the client (though only version .21) will make you put a 0.01 fee on it, which fixes the priority. Normally, once you have a reasonably sized wallet with some reasonable aged coins, you'll not run into this issue. An upcoming version of the client reduces that fee to 0.0005, since 0.01 was getting a bit stupidly large. The reason for this system is to prevent a transaction denial of service attack— without it I could simply bounce 0.01 bitcoin between two wallets 1000 times per minute and clog up the whole system just to be a jerk. Regarding confirmation time, getting 6 confirmations in 11 minutes is unusually fast. The designed-in average rate of confirmations is 1 per 10 minutes. |
|
|
|
see also: http://forum.bitcoin.org/index.php?topic=11126.msg158368#msg158368and http://forum.bitcoin.org/index.php?topic=8894.msg158376#msg158376There was some discussion in #bitcoin-dev about signaling non-listening nodes too but the problem is that nodes can't currently tell if inbound connections work. Some logic can be added to request peers to try connecting before deciding that you're listening and announcing, but it's more than a few LOC... The general idea was that nodes would wait some amount of time (we only really care about high uptime nodes listening) then request some of their peers to connect to them. If it works then they advertise themselves as listening. This doesn't just matter for IRC but also for the peer requests over the p2p protocol. It didn't sound like anyone had committed to writing that yet. I think it sounds like all of these things (incl. DNS seed and the other stuff in the linked thread) need to happen eventually, but fixing the connection timeouts plus anything else is enough to meet the urgent need. |
|
|
|
The network is experiencing growing pains, sure, but cries of "Bitcoin doesn't work for new users" are just hyperbolic, considering this is an issue that has been present for years and bitcoin does seem to work for new users.
Unfortunately I can't go back in time and do careful testing a month ago. What I can tell you is that a month ago I brought up two firewalled nodes and immediately got connections... I was surprised a few weeks later when people started showing up in #bitcoin complaining of being stuck in 0 connections state. And I'm now finding that a configuration which clearly worked before (firewalled hosts) no longer starts up reliably. While the software hasn't changed in this regard, the composition of the network has. It's not hard to see how the old situation worked fine when most hosts were accepting connections, but with a super-majority not accepting connections it appears to be failing pretty much completely for a popular configuration. I don't think thats particularly hyperbolic… There isn't any particularly compelling reason for most users to upgrade right now, nor do these fixes have big network effects (e.g. a connect() timeout fixed node is still fixed regardless of what the rest of the network runs). So this not making it into .22 may not matter much ultimately, so long as a version with the fixes is quickly forthcoming. |
|
|
|
I think 0.3.22 should be delayed because the software basically does not work correctly for new nodes behind nat / w/o port forwarding. T The behavior a typical firewalled new users sees is that they start the software and they see 0 connected. The system may spend hours in this state. Restarting the client repeatedly may make it get connected, but it may not receive any blocks. Eventually if they are patient enough and/or restart enough they will probably get synced up to the network but it may take then 24 hours. The same problems exist in 0.21 but there are non-merged fixes available. If they addnode a working node, or forward the port then it will work pretty easily. But thats a lot more work to just get the software going. I think this gives users an initial impression that the bitcoin technology is unreliable and dampens interest and confidence in bitcoin. I've written more about this issue in http://forum.bitcoin.org/index.php?topic=11126.0Failing the delay of .22, I think a .22.1 update should be released quickly— the features planned for 0.4.0 include a number of potentially dangerous changes (like encrypted wallets) which ought not be rushed. |
|
|
|
The behavior a typical firewalled new users sees is that they start the software and they see 0 connected. The system may spend hours in this state. Restarting the client repeatedly may make it get connected, but it may not receive any blocks. Eventually if the operator is patient enough and/or restart enough they will probably get synced up to the network but it may take then 24 hours. I think this gives users an initial impression that the bitcoin technology is unreliable and dampens interest and confidence in bitcoin. After IRC discussion it seems that the problem seems to be the result of several interacting issues: (1) The connect() timeout behavior is unreasonable. Once the 8 slots are filled up with connections to unreachable hosts the node will just sit there idly. I think the OS will eventually give up— but only after 5 minutes or so. this is worsened by the fact that: (2) Most nodes on IRC are unreachable. We've had a large amount of newbie growth lately and lots of nodes are up behind firewalls without port forwarding. If you grab 8 nodes from IRC it is appears fairly likely that you get all 8 non-reachable. (3) addr.dat remembers nodes which you've never connected to (or only connected to long ago) and these non-working addresses are passed on to other nodes when you connect to them. So even when you do get a working network connection you'll likely get fed more addresses that make connect time out. (there also appears to be a DOS vulnerability here, since I could run a node that simply claims every IP is a bitcoin node) If they addnode a working node, or forward the port then it will work too (though addnoding after an addr.dat is full of junk seems less effective). But that is a lot of non-obvious work to just get the software going. This situation is severe enough that when I spun up eight totally new test nodes (behind a firewall), all eight were still sitting at zero connections five minutes later. I had another test node run for 20 hours and not get any blocks— though it did get connected, most likely because it ended up in an island of new nodes, so thats probably another issue. Fortunately this isn't terrible to fix: Issue (1) has a patch available https://github.com/phantomcircuit/bitcoin/tree/nonblockingconnectIssue (2) can be addressed by the use of DNSSeed (which checks that hosts are reachable before including them, and could also check to make sure they weren't islanded nodes) Issue (3) seems like a mostly straight forward fix though the security implications need to be thought through. Additionally, enabling UPNP by default would help by getting more nodes listening, but thats not sufficient without solutions to (1) and probably (2). But these fixes need to actually get into the software to be of any use. I don't think many long term bitcoin users are realizing the severity of this problem because they either have established nodes, public IPs, or port-forwards, and because the issue has become much worse in the last two weeks. (I didn't experience it personally due to forwarding the port, but a regular stream of people into #bitcoin asking inspired me to investigate some) |
|
|
|
I like how you move the goalposts. But really, you've already agreed with me.
I never said that we know nothing of the hash rate, over a long period of time. I said that we are not measuring the hash rate, and that our estimates of it aren't very accurate over short periods of time.
Kaji, you've evaded the clear points I raised about the nature of measurement only to continue asserting that what we have isn't one. Why should I even continue to discuss with you when you won't explain why you say that this isn't a measurement when e.g. using a scale (which is also not infinitely precise, and is subject to complicated biases and noise), taking a survey, or taking a census are all considered to be measurements. If you will say that there is no such thing as a measurement of a physical quantity then I will agree with you, given this definition of measurement, that we haven't made a measurement here. Otherwise, I fail to see what you're arguing— that the pool operators are liars when they said they went down— that the pool users were hallucinating when they saw their miners idle— that the rate didn't really go down and that the system was just really unlucky at the time of these lies and hallucinations? |
|
|
|
|
Show Posts
