|
Yeah, just put it in the JSON request. I don't think anyone anywhere is doing validation that would reject it because of extra fields.
Leave the meta-channel for information/negotiation about the channel.
|
|
|
|
|
There are exactly 2^160 possible addresses as long as we keep using RIPE-MD160.
2^160 is 1,461,501,637,330,902,918,203,684,832,716,283,019,655,932,542,976.
|
|
|
|
What would be the best/easiest way to issue a hard reboot if the kernel appears to be having I/O errors or other issue?
A networked UPS or power strip is the best way, but not the easiest. |
|
|
|
Under Centos 5.5 when compiling pushpool 0.5 I get this errrors:
/root/pushpool05/pushpool-0.5/msg.c:562: undefined reference to `htole32'
server.o: In function `cli_send_hdronly':
/root/pushpool05/pushpool-0.5/server.c:328: undefined reference to `htole32'
server.o: In function `cjson_encode':
/root/pushpool05/pushpool-0.5/server.c:231: undefined reference to `htole32'
/root/pushpool05/pushpool-0.5/server.c:234: undefined reference to `htole32'
server.o: In function `cjson_decode':
/root/pushpool05/pushpool-0.5/server.c:167: undefined reference to `le32toh'
server.o: In function `cli_read_hdr':
/root/pushpool05/pushpool-0.5/server.c:468: undefined reference to `le32toh'
collect2: ld returned 1 exit status
make[1]: *** [pushpoold] Error 1
Can someone define htole32 and le32toh since they are not part of ansi C, and therefore fail to compile under Centos 5.5 using gcc 4.1.2
The answer is way back on page 3. |
|
|
|
Yes, it matters. A lot. Salted means you have to crack each password individually. You have to run through the entire list of candidates (until a match) for each and every salted password (given unique salts). With unsalted passwords you can run through the wordlist once, and get all matching passwords with a single MD5 run for each word in your wordlist. It doesn't matter for one single password, but for 60000 salting means 60000 times more work. And salting renders rainbow tables useless, because you'd have to build one rainbow table for each possible salt.
Thanks for this explanation. For implementation purposes, how would a website use a unique salt? For example, when the username types in a password it must be joined to the salt and then an MD5 algorithm ran over the product to compare with the database stored hash. Somewhere then the salt must be stored, right? Random, and yes, it is stored. If the hash started with $, it follows this format: $<scheme, always 1 here>$<salt>$<hash>. Scheme 1 means about 1001 rounds of MD5 with complex combinations of the previous round, the password, and the salt. Other schemes are available for SHA, blowfish, and (try not to laugh) NT. If it doesn't start with $, it is just a simple unsalted MD5 hash of the input. |
|
|
|
Anyone seriously interested in this topic should familiarize themselves with a whole lot of Steve Keen's research. |
|
|
|
|
Nodes do not accept blocks with difficulty below what they are expecting.
|
|
|
|
|
The stock client is much more useful as a network node than as a wallet. It just isn't obvious yet because almost no one has ever used an alternative client.
|
|
|
|
|
Oh, and physical cash and coins are purchased by the bank from the regional reserve, and I think they pay a slight premium for it, so they try to recycle as much as possible.
|
|
|
|
|
I check each coin that comes into my possession. Been doing it for about 10 years now, and I have found 3 silver quarters and 2 silver dimes. Oh, and maybe about 20 bicentennials, and a few wheat pennies.
People actually do coin mining on a larger scale too. Check the kitco forums, survival forums or other places with a lot of metal enthusiasts, and you'll find posts from people that pick up boxes of rolls of coins from their local banks every day and check them all.
|
|
|
|
|
Interbank clearing is done by the ACH system in conjunction with the regional Federal Reserve banks. Each bank has a checking account in the Federal Reserve system, and these accounts are used to transfer money from bank to bank just like we use our checking accounts to transfer money from person to person.
When I deposit a check, my bank tells ACH about it. ACH attempts to net them out as much as possible, but periodically, it has to balance things out by instructing the local Fed to transfer some dollars from bank A's fed account to bank B's fed account.
|
|
|
|
|
Appears that the window is now closed.
|
|
|
|
|
The network doesn't require that a block be newer than the previous block, just that it be newer than the median time of the last several blocks.
|
|
|
|
Ideally, there would be some kind of incentive to reduce the total number of active transactions. The recommended fee could be lower for transactions that combined lots of low value coins into high value coins.
Minimum fees based on the size of the transaction already mean that tiny coins have less value than larger coins.
Right now the default client enforces some limits on transaction fees, mostly to stop transaction spam. Over time, those will go away, and each network node and miner will be able to set their own rules for accepting and relaying transactions, which means that there will be a market of sorts for fees. But, when there are a lot of transactions to process, the miners will evaluate them in the terms that make sense to them. That mostly means that they will want a high ratio of fee to work. Each input to a transaction involves a certain amount of work, so there is no possible way to provide incentives to miners for consolidation transactions. So, while consolidation may be useful to other parts of the network, it will not be prioritized by the group capable of making it actually happen. |
|
|
|
Say the first transaction is X+Y in and A+B out, with no fee so that X+Y == A+B. If it doesn't get picked up quickly enough, the user tried a second one with X+Y in and A+(B-F) out so that F is the fee.
It would make it easier to require an absolute match, since transaction data management is potentially a big overhead for miners. We could also make the rule that the output getting reduced, B, has to have the same address as one of the inputs.
Currently, the default client doesn't send anything back to the original address. What was the reason for that? Was it to create a psuedo mix-net? I'm not sure if this is a good road to go down or not, but if we do decide that a double spend is acceptable in this circumstance, at least it is recognizable, and somewhat safe.
I think the idea that it must go back to the same address as the input would fix the issue anyway. Most of the mixing could be preserved if only a small portion of the money was placed in the "reserve". However, the hardening of bitcoins is incorporation into the main chain. Some miners will accept transactions being sent directly to them. Ahh. The reason is probably because reusing keys is a bad idea, in general. Many cryptosystems have are weak when an attacker is able to collect many cyphertexts all using the same key. I don't know how much of a problem it is when using ECDSA, but all the textbooks since WWII have said not to do it unnecessarily. The client could reduce this problem by keeping track of the addresses getting change, and chaining them into the following spend on the changeless side. In this X+Y==A+(B-F) example, B is the change. The next transaction the client does would be B+Z==C+D, or C+(D-F). Then the next would be D+W, and so on. |
|
|
|
- since nano is not possible, calling them satoshi's (sBTC?) - not my idea, but thats the most commonly used term I see used so far
Could you explain why nano is not possible? nano is 10x^-9 Bitcoins only got to 10^-8 You can still mention nanoBTC. You just can't deal with them in groups smaller than 10 nBTC yet. |
|
|
|
It might also be a good idea to alter the spend behavior to include a little change in the input even when not strictly necessary, so that the resend attempt doesn't need to add a new input.
That is only needed if transactions are only cancelled by identical ones. This is just to make it easy for nodes to recognize replacement spends. Say the first transaction is X+Y in and A+B out, with no fee so that X+Y == A+B. If it doesn't get picked up quickly enough, the user tried a second one with X+Y in and A+(B-F) out so that F is the fee. We could also make the rule that the output getting reduced, B, has to have the same address as one of the inputs. That way we know it is the change getting reduced, and not the spend. Vendors that don't wait for even a single confirmation could get burned otherwise (but if they don't wait, they are asking to get burned anyway). I'm not sure if this is a good road to go down or not, but if we do decide that a double spend is acceptable in this circumstance, at least it is recognizable, and somewhat safe. |
|
|
|
I do not believe that enough useful GPUs exist in the world, in purchasable form, right now for any entity to take over the network. It would require a door to door search and confiscation in at least one major western country. If you wanted to do it with CPUs, it would take about 150,000 quad core Xeon E7450s. But that is the top end CPU, and it certainly doesn't exist in that quantity worldwide. Go down a tier, and you need about 300,000 of them. For reference, google had about 150,000 CPUs back in 2007. They've probably grown considerably, and might have 300,000 CPUs total by now. But they will be a mix of CPUs from the last few years, probably none were ever top of the line at time of purchase. If you operation is massively parallel, you don't need the fastest CPUs, you need the ones that give the best bang for the buck. And google is using whatever CPUs they have to make money hand over fist already, so it seems unlikely that they would want to shut down their search operations to take on bitcoin in a big way. |
|
|
|
Liberty Dollar != Bitcoin
Bernard von NotHaus was arrested because he was stupid, not because he was libertarian.
He was arrested because he was running an alternative currency that was starting to take hold. Nothing else. He was trying to get people to pass off his currency as US currency to unknowing and unwilling victims. |
|
|
|
|
Show Posts
