Not to nitpick, but, how useful is the private key without the public one?
ECDSA public keys are derived from the private keys using a formula. So including the public key is redundant. |
|
|
|
In terms of the API, the client would invoke listtransactionssince with the hash of the last known block. If found, the daemon would return the hash of the last confirmed block in the chain, together with all transactions which have occurred between the two blocks. And instead of a timestamp, the optional parameter indicating early breakout criteria would be the block number.
Good idea. This will work. The client can also keep a stack of block hashes if desired to reduce work in case of a reorg (which happens more often than you might think). It won't work for 0-confirmation transactions, of course. Bitcoin Block Explorer does something similar: it uses the current block number for ETag/If-None-Match caching on certain pages. |
|
|
|
transactions are timestamped, aren't they?
No, they're not. And if they were, the timestamp would be provided by the attacker... |
|
|
|
|
Bitcointools has the ability to analyze your addr.dat, which should contain nearly every node in the network if your client has been running for a while.
|
|
|
|
|
I originally made mine for an RPG character: Theymos Amastica. It was created without much thought, being only a minor adjustment of the "Thamior" and "Amastacia" names given as elven name examples in the D&D 3.5 Player's Handbook. I began using it for all of my online game accounts, as well, and then I used it even for non-game accounts so I wouldn't have to remember multiple usernames. (At this point most of my online accounts were game-related.)
I sometimes wish that I had chosen something better and more meaningful, though it is nicely unique: almost all Google results for "theymos" are related to me. It would be very difficult to change at this point, after using it for 5+ years.
|
|
|
|
Are these connection IPs hard-coded into the source?
No. You connect to an IRC channel to get a list of all active Bitcoin peers. Then you choose 8 at random (basically). You will also be listed on that channel, though peers won't be able to connect to you from the outside. I recommend running the miners with -connect=<IP of networked bitcoind>. This connects only to the specified IP, and it prevents you from being listed on IRC. Then you are well-connected, but you avoid wasting network resources. Not being well-connected is only a minor disadvantage. You can replicate some of the advantage by running the miners with -maxconnections=20, which will increase the number of outgoing connections to the specified amount. You might also do -maxconnections=4 and -noirc to decrease the number and stay off IRC (you'll bootstrap from your network node), and then use addnode to connect to your networked bitcoind: this decreases network load without relying completely on your networked computer. (Edit: I just discovered that maxconnections can't increase the number of connections from 8, as I always assumed.) |
|
|
|
You can often speed up transaction processing by including a 0.01 BTC fee. For practical purposes you don't really have to worry about it.
I wouldn't say that. Consider that ArtForz or slush could easily reverse a transaction with even 2 confirmations (maybe more). So if all miners were to suddenly stop mining all at once, how would this affect the bitcoin network? Will payments still go through?
Processing would become much slower. However, transaction fees would accumulate, constantly increasing the generation incentive. Eventually someone would want to generate. |
|
|
|
Why don't the excess fees just get returned as change to the originator of the transaction?
It would require creating a new transaction, which might have to have its own fees, which might have to have its own change transactions, etc. The refunded amount would also be at risk of changing in a reorganize, which would invalidate all future transactions based on that one. |
|
|
|
The way you're doing transactions is not secure. Anyone can monitor the public address and then automatically email you when they see a transaction to it. The real purchaser will have a hard time proving that they were the one who actually sent the coins. You must generate a unique address for each customer. I recommend just using MyBitcoin's merchant API to do the transaction processing. Bitcoin transactions are not encrypted, and it's likely that all transactions will require a small fee within a year or two. i didn't want to step in, but kiba, what does your first reply have anything to do with nickwit's original post about calipers???
Nickwit asked for feedback on his explanatory Bitcoin page. Kiba is responding to inaccuracies he perceives in the text. |
|
|
|
Minimum wage? I'll be happy to earn bitcoin at minimum wage. Anything for bitcoin, really.
I think he's saying that minimum wage laws make finding employment more difficult, since labor is more expensive than it should be. |
|
|
|
|
Possibly the "modem" supplied by your ISP also acts as a NAT device that requires its own port forwarding rules. Maybe your ISP blocks all incoming connections, or has you NATed with several other users. You should contact your ISP's support.
|
|
|
|
I still don't know the details of how BitCoins work, but here is a thought: couldn't you send BitCoins to somebody's email address by creating both the private and public key and sending them both to the email address? You can, but it allows the sender to double-spend, so you wouldn't want to accept the transaction until it appears in the block chain. That's not a big deal in this case, though. The email would also need to be encrypted. |
|
|
|
I have seen that latter though at least once I just can't remember where.
The Linux/Unix "default" behavior is to use crypt() to DES-encrypt a truncated password as you described. Probably almost all Linux distros modify this behavior to something more secure, though. |
|
|
|
|
It shouldn't be a problem if they truly do no transactions, though. (Generating 50 BTC for themselves would be a transaction.)
|
|
|
|
User credentials are passed along in clear text with GET method, not POST method.
That's sad man, anyone able to sniff the server traffic would have all the credentials.
POST is also easily-readable plaintext... GET is just visible in the URL. GET parameters are encrypted when using HTTPS. |
|
|
|
Note: Many off-topic posts about mining efficiency were moved here.
|
|
|
|
I split this topic from python OpenCL bitcoin miner because, as m0mchil pointed out, the posts were largely unrelated to poclbm. Is this title OK? |
|
|
|
This assumes there is only one answer per getwork. In some instances there are none, whereas in other instances there are multiple (for the sake of explanation we'll say there could be 5).
The boxes are getwork responses. I said: a single box may contain zero, one, or more winning tickets Also, you also have a fixed number of boxes, as there are only a fixed number of 2^32 chunks of a whole block, so I'll ignore your "endless number" logic. There are an unlimited number of unique getwork responses (nearly). |
|
|
|
|
My metaphor was flawed due to my attempt at simplicity, so I will expand it:
There are an endless number of boxes. Each contains 100 tickets. The entire endless set of boxes as a whole has 1 winning ticket for every 99 non-winning tickets, though a single box may contain zero, one, or more winning tickets. The chance of drawing a winning ticket from any box is therefore 1 in 100. It does not matter whether you draw continuously from one box or draw only one ticket from each box: the odds are still 1 in 100.
Completing an entire work is like emptying each box in order. Getting new work after finding something is like moving to the next box after finding a winning ticket. You could also move to the next box every few minutes. There is no concept of efficiency, however, as the chance is always 1 in 100.
Likewise, there are an endless number of works. The entire set as a whole has an exact chance per hash. It doesn't matter how many hashes you do per work: the chance is always the pre-set amount.
|
|
|
|
|
Show Posts
