So you had 2 PSUs hooked up at the same time ?
I always wondered if that would work.
Can you post a photo of the damage ?
Two PSU's shouldn't be an issue. I think quite a few people who've OC'd their box are using two, me included. Two power supplies can be bad mojo if you ever happen to have one powered on and not the other. Sometimes a power supply in the off state will short +12V to GND. If this happens while the other is trying to keep things at 12V, bad things will obviously happen. can someone else also confirm this? adding another 600w psu is clearly cheaper than replacing with one 1000w+.. i wonder why they didnt make the avalons on proliant hot swap psu.. http://m.ebay.com/itm/300976711130 35 euro and 1000w also hot swap.. Could you not perhaps wire both PSU's to the same switch. I used to run a shitload of hard drives in RAID on a cheap computer. Think 15-slot plywood drive cage with a dedicated power supply, 120mm fans blowing through the drive slots, and 36 inch IDE cables in a unholy mess to tie back to the main computer. I built a box with a relay to trigger the power_on signal to the slave power supply when the master power supply was on. Radio Shack should have a suitable relay, either 5v or 12v DC trigger, negligible output current. Cut an ATX extension cable to connect to the slave supply, and cut any 4-pin molex accessory (splitter, fan power, SATA converter, etc) for the input. Bond the power supply cases together, either by rigidly mounting them in a shared metal frame, or by using a copper wire (and an appropriate crimp-on spade terminal if you aren't a savage). For connecting the relay, you have several options. Bonus points if you etch and drill a PCB. This is an easy build, you can draw if freehand with a sharpie and the Radio Shack PCB kit. Second best choice is to use a socketed relay. Automotive relays are commonly available with pigtail sockets, from there it is just a few wire nuts to get everything together. Third is QC connectors. Forth is soldering directly to the relay. |
|
|
|
The process size instead refers to the standard half-pitch of a memory cell. That doesn't really apply to a SHA256 ASIC, but it is a measure of how small the process can reliably make things.
This is typically called the "minimum feature size". It has a bunch of other names too, like "critical dimension", etc, but I feel that "feature size" gives the best immediate understanding. |
|
|
|
Is anyone concerned about root authority, now that it is being discussed that NSA may have access to them with sealed orders like the Verizon records?
That has been a concern since before day 1. The problem is that despite SSL's many, many, many flaws, it is still vastly superior to everything else. |
|
|
|
Are you asking if colored coins are a good idea? (I say yes)
Or making a more specific query about how they could be traded?
It does the job of colored coins. But it has some differences from normal colored coin ideas. For starters, my idea can actually work.  I've pondered this idea on and off for the last year. I'm pretty sure that it will work, and I'm pretty sure how it will work. What I'm looking for now is peer review. Have I fooled myself? Are there problems I haven't seen? Are there better approaches to the problem? |
|
|
|
In light of the BTCT news, jgarzik reposted his idea for a decentralized exchange. How about this: make it possible for users to create their own decentralized exchange. - Register a bitcoin address for each shareholder, if not already. This enables the ability to authenticate cryptographically signed digital messages. See this stackexchange answer for a guide. Most bitcoin clients support signing messages. Registering a GPG key for each shareholder is an alternative, though that requires additional software beyond a bitcoin client.
- Publicly declare a bitcoin address and GPG key for official ASICMINER messages.
- Publicly declare an email address for emailing ASICMINER robot
- At the end of every day, ASICMINER robot produces a message listing all shareholders, by key and share count. Attach bitcoin and GPG digital signatures.
- To trade ASICMINER shares, the seller sends a digitally-signed message "transfer N shares to bitcoin address FOO" to the ASICMINER robot.
That is all that is needed on the ASICMINER side: maintain a shareholder registry. changes to the shareholder registry may be both pseudonymous and secure. Then anyone may build an exchange that trades shares. Anyone may trade ASICMINER shares at any time, using this method. Re-posting via quote, given today's BTCT business. Having a publicly auditable share registry is important. This strikes me as being yet another example of a ledgerbook system. You don't own anything, you just have your name in a book somewhere. MPEX operates the same way. They provide signed receipts, but ultimately, MPEX is just a ledger book. A more robust ledger book than GLBSE, BTCT, etc, but still... Jeff's idea amounts to moving the ledger book from the brokerage/exchange to the asset issuer. Since the asset issuer already has the ability to default entirely, it would appear that letting them hold the registry of share owners too is a good idea. Certainly, we've removed one potential point of catastrophic failure from the system. What powers does as asset issuer hold in the ledger book system? Should they hold those powers? Can we do better? I believe that we can. Thanks to bitcoin, we know how to build globally distributed peer to peer networks that allow direct transactions between parties. Thanks to namecoin, we know how to use such a system for arbitrary assets, and we know how to utilize the hashing power of the bitcoin network to provide extra security. I'm thinking of an altchain for recording securities (stocks and bonds). For now, I'm thinking it should be called securitycoin, or S-coin, or STC.
Say we add a payload field to the TxOut structure. (It'll likely be a blob of DER)
If you want to create a new stock, you encode a bunch of information (the name of the issue, the number of shares, some other stuff and a hash of the prospectus) and call it the issue. Then you hash the issue along with a secret and call that a registration. Then you create a payload including the registration and burn a few S-coins in fees to embed it in the chain. Then, when you feel it is deep enough, you redeem the transaction with the registration to create a new transaction with the issue as a payload (also the secret, to prove that it was you. This is anti-front running stuff).
Now you can redeem the issue with a send to a bunch of brokers. The brokers can redeem those as usual, and send the shares to clients. Clients can redeem their transactions and send them to other people, if they so desire. *
Once the issue is done, every share has a provable owner, and the owner owns the shares, not the issuer, not the broker, and not some exchange. Even better, if we use regular bitcoin addresses on this network, the issuer can query the chain and get a list of addresses and holdings to send dividends to (on the bitcoin chain).
The system could even handle splits, merges and votes. The only trick there is to encode the payload in a way that the network can validate the payload cheaply. For example, in addition to enforcing coin_out < coin_in, it also needs to verify that shares_out = shares_in (paying network fees with shares seems silly, but replace the = with < and it can happen).
Since this system isn't for buying packs of gum at the store, we could slow the network down, maybe to 1 block per hour, to keep the size small. And we could keep the value of the coins high-ish, giving an incentive for people to merge-mine it, by charging high fees for things like registrations, issues and vote requests, and small fees (or none) for sends and votes.
* I don't think it is possible to take the brokers out of the system. I don't see any obvious way to make a pair of transactions on different chains that redeem each other. If there is such a thing, you and your broker could create such a contract and make the trade atomic. Until then, one of you needs to trust the other. Then again, if we are using the same keys in both places, maybe multi-sig can do it, don't know. At worst, it is no worse than any other bitcoin/world interaction, and you still get the benefits of recording stock ownership in the chain.
Neat idea.
One general comment RE: "we could keep the value of of the coins high-ish" :
I think NameCoin should not have combined the "it is a currency" function with "it is a name-tracking system" function.
And I think S-Coin should avoid that mistake. If I want to buy a stock, I don't want to have to FIRST buy some wacky currency just so I can buy the stock, I want to use bitcoins (or dollars, currency you use should be irrelevant).
Piggy-backing on the bitcoin blockchain to get a canonical, time-ordered list of trades makes sense, but doing that doesn't require full merge-mining.
Legally, it scares the pants off me, and isn't a project that I'd touch with a ten-foot pole. They sent Martha-frickin-Stewart to jail for violating securities laws!
In my opinion, if this catches on, the importance of this chain would rival or exceed the importance of the main chain. How strong would namecoin be if they didn't have exchange value? A quick look at the relative difficulty shows that even when mining is totally free (merged), 60% of the world doesn't bother doing it. Namecoin doesn't have enough value to get most people even to that minimal bar. Namecoin is LOL-cheap because registering names and changing metadata doesn't cost much. Which is fine for namecoin, because namecoin is mostly about asserting priority. And you wouldn't need to buy S-coins if you want to buy a stock, just if you want to issue a new stock. Presumably, if you are doing an IPO, you can afford to buy some coins in the stock chain to enable you to do so. When sending a stock from one random guy to another, there isn't a reason why fees would be necessary, and having coins certainly wouldn't be needed to receive them It is more than just a global list of trades, it is distributed ownership and control too. It is your stocks protected by your secret keys. I suppose we could embed the payload as a fake signature in a 1-of-2 P2SH transaction, but then the network isn't validating the payload. It really seems to require a new chain. Good call on the Martha Stewart thing, but she didn't go to jail for violating securities laws, she went to jail for lying to the feds (about something that would have been totally legal even if she had done it). And I'm not sure that the things going through this chain wouldn't actually qualify as securities under existing law, even if we call them that. And you wouldn't need to buy S-coins if you want to buy a stock, just if you want to issue a new stock. The purpose of a currency is to have value because it is scarce. If you make "issuing stock" tied to currency, then you're saying "issuing stock" aught to be a (somewhat) rare, (somewhat) costly event. Why? That, in my opinion, is the same mistake NameCoin made. Why should claiming a new domain name be rare or costly? If you want your system to be a success, then it seems to me you want issuing stock to be easy and as close to free as possible. I can't really disagree with any of what you are saying. There is no reason to treat this like a currency, no reason for it to have value, no reason why operations should cost anything. Except that namecoin has 40% of the security of bitcoin, when it should be closer to 90% or more because it is so easy to do. If S-coin has even less cash value, or none at all, why bother with running the node? It seems to me that having to buy coins to do stuff is the only way to make it so that people can sell coins, which is the only way to make it so that people will mine coins. I will ponder on it some more, but it seems to me that artificial scarcity is the only way to make the system work. We had a brief discussion on IRC about this today. Some parties felt that since the system cannot prevent an asset issuer from defaulting entirely, the whole thing was pointless. I disagree. Because shares trade peer to peer in this system, the issuer cannot be sure who is holding shares, making selective default (paying some holders, but not others) far less attractive. The issuer also cannot block transfers in this system, which keeps shares more fungible. The issuer could also be prevented from diluting shares by issuing more, or could be constrained to only dilute in response to a vote verified by the entire network. So, my question to you, the bitcoin community... Is this an idea worth development? Are there other ways to do this that may be better? |
|
|
|
I couldn't find a way to make blockchain.info make a compressed address, so I just made a new address in bitcoin-qt, exported the key from that, then importied it into blockchain.info, and I get this: Compressed private keys are currently not supported using the Android app, iPhone app or Merchant API. If you import a compressed private key directly you will not be able to spend the funds at that address using the previously listed devices. Kinda scary if I'm doing things in a way in which some people can't get my coins.
Type "compressed" into the search box from the Dev & Tech page. You won't be disappointed.
Thanks for the pointer, but I can't figure out what you mean, there's no Dev & Tech page on the wiki or forums. In case its not obvious, I'm a noob, so sorry if this is a really dumb thing to not know about. The forum that this thread is in is "Development & Technical Discussion". |
|
|
|
|
Your byte order is wrong in the 16 and 32 bit words. Try Cn and CN.
|
|
|
|
TIL there's such a thing as compressed addresses. Is there any good docs on this? I can't find anything that explains it on the bitcoin.it wiki, maybe its called something else. The only mention is on this page https://en.bitcoin.it/wiki/Private_key where it says you can tell if a private key is for a compressed key because it starts with an L or K. From what I've read in random places, compressed are 34 characters (including the 1), right? Every one of my public keys are that long, and I used the normal oclvanitygen to make them, so how much shorter would a compressed public key be? Type "compressed" into the search box from the Dev & Tech page. You won't be disappointed. |
|
|
|
You can hash anything, a photo is just another stream of bits. It would be like keeping your private key in an unencrypted ascii file, it's just more obscured.
It doesn't have to be unencrypted. You could use HMAC-SHA1 on the {image file,password} pair. |
|
|
|
|
And the bot to download, hash, addressify and check every image on the internet launches in 3...2...
|
|
|
|
|
If you are using vanitypool, each address request has an associated secret. The people working don't have access to the secret, but it is a factor in the resulting address, so you can only look for one at a time.
|
|
|
|
|
Actually, it is possible. There are pools that operate that way, including p2pool.
|
|
|
|
|
In init.cpp, search for pszP2SH. That will show you exactly what you need to do to put custom tags in your coinbase.
|
|
|
|
The reference client has supported multisig for a while now.
'supported' is a bit generous IMO. There is the bare bones tools to create a multi-sig transaction but everything else which would make them usable is sadly lacking. No, 'supported' is exactly the right word. The reference client "supports" multisig operations. The "everything else which would make them usable" is a whole security infrastructure, typically involving a second computer, policies and practices, etc. This is, naturally, outside of the scope of the client. At risk of belaboring the metaphor, you can build such an infrastructure on top of bitcoind, because bitcoind 'supports' multisig. |
|
|
|
Lol if seals have used your password to login into your online wallet but didn't steal from your account on their website to not expose the scam.
Use multiple levels of passwords:
Level 1 - 15 random characters/letters/numbers - Swiss bank/local bank/Paypal/Bitcoin offline wallets
Level 2 - 12 random characters/letters/numbers - Online wallets/important email accounts etc
Level 3 - 8 random characters/letters/numbers - Crappy casinos, spam websites, WoW accounts, Apple MacIGiveACrap and whatever.
Why? A password safe can store 15 characters just as easily as it can 8. Use 16+ random characters for everything. Only use shorter passwords when the authenticator does not allow the full length, and seriously consider simply not using anything that doesn't allow at least 12 characters. Oh, and never, ever, ever use the same password more than once. If you can remember a password, it is probably insecure. If you can remember several of them, it is a certainty. |
|
|
|
|
Decentralized does not mean "evenly distributed". It means "no one can stop you".
Don't like the reference software? No one can stop you from writing your own.
Don't like the current mining devices? No one can stop you from designing and building your own.
Don't like how mining is being done today? No one can stop you from starting your own farm/pool/whatever.
Note that these choices aren't necessarily wise. Some or all of them may be unprofitable. But no one on the entire planet has the ability to prevent you from doing them.
|
|
|
|
|
ASIC = Application Specific Integrated Circuit
The application of block header hashing is not even remotely similar to the application of EC point multiplication.
So, while the literal answer to your question is that yes, you can use ASICs for vanity address searching, the answer that you are really looking for is that no, the specific ASICs you already have are not suitable.
|
|
|
|
The main choke point of blockchain sync speed is your hdd not your internet speed. If you have a solid state drive and/or a RAID array it will dramatically decrease your blockchain sync time. You can also add dbcache="number_of_mb_of_RAM_to_use" to bitcoin.conf to decrease the strain on your hdd while syncing.
P.S. Default value for dbcache is 25 and a good value for a computer with 4gb ram is 3000, assuming you aren't doing anything RAM intensive.
The box I am using has 512MB of ram, :-) I found it on the street and was curious to see how bare-bones a node could run. Pentium duel core. I'll get more stats when it's finished and I check out the bios. I didn't know however that RAM influenced the download, but now I see. After the initial verification, it should be fine. Well, fine-ish. I have two nodes running on an old Athlon XP 1800+ with 883 MB reported memory. It runs fine most of the time, but bogs down a bit when the network is growing quickly and blocks come too fast, or when feeding a newly started node. A single node, or even a dual that disallows incoming connections, would probably be fine. While the bottleneck is certainly in your machine, the speed of your first peer can also be a factor for faster machines. I also run some diskless nodes that maintain the entire datadir in a RAM drive. While I haven't done any scientific measurements, just by watching the logs it is obvious how much faster the RAMdisk node is when feeding a new node's initial block download. |
|
|
|
If you go around disallowing a bunch of K values then you're decreasing security not increasing it... Though I would agree that this specific test is perhaps mildly useful as a "RNG fatally broken, do not pass go" check.
I don't see why K==d is more indicative of a faulty RNG than the infamous K==11 ? Are you seriously suggesting that we should test here whether we're dealing with RNG that always returns the same value, or is there something else that I'm missing? Actually, I suggested it. If you test for a single value of k, that test will never ever trip because the odds of drawing that one k is zero (approximately). It doesn't matter if the value under test is D or a constant. The exception is when your RNG is broken, perhaps XCKD-style. |
|
|
|
The nonce is only 32 bits; could there come a day with the difficulty is high enough that no nonce works?
That day was back in like 2009 or 2010. A difficulty of 1 corresponds to an average of 1 valid block per nonce range. At difficulty 2, you expect to find one valid block per 2 full iterations through the range (on average). Oh, I see. How does one change the block contents after a full iteration fails to find a suitable hash? The traditional method is to increment extraNonce, an optional "field" in the coinbase garbage string, which changes the generate transaction, which changes the merkle tree root, which changes the header. You can also fudge the timestamp. |
|
|
|
|
Show Posts
