BFL_Josh posted on 3/29 about a giveaway of a Monarch 28nm miner on the BFL forum: https://forums.butterflylabs.com/announcements/8203-win-butterfly-labs-imperial-monarch.htmlIn exchange for spamming up this forum's trust system, he offers to give away hardware to entrants: Win a Butterfly Labs Imperial Monarch!
1. One entry per person, per day.
2. Entries will consist of 3 positive and 3 negative Trust entries on Bitcointalk.org to the accounts specified. (Listed below)
3. Entries will close the day we ship our first Monarch product to a paying customer. Entries will be accepted up to 23:59 UTC of that day.
4. The winner will be chosen at random via the next block on or after 00:00 (midnight) UTC the day after we begin shipping.
...
They have begun shipping: https://forums.butterflylabs.com/the-monarch-discussion/8758-now-they-shipping-whos-had-one-whats-deal-4.html#post85582 That poster shared his tracking info for a package sent 8/26. It is therefore past the date of #3 and #4. No list of final entrants has been published, which is required for openness before a blockchain-picked raffle. There has been no activity on the raffle giveaway thread for months. I do not have an account on that forum; I discovered the contest looking at backlinks to my site's pages with the raffle picker. I am just interested in keeping this contest and BFL honest for everyone that wasted their time entering. screenshot of complete raffle post for posterity: http://we.lovebitco.in/img/bflrafflescreenshot.png |
|
|
|
I guess I should have downgraded to lower drivers because my card broke last month. It should be coming back from repairs any day now.
My dad said it got repaired and now he can pick it up. Hopefully by this afternoon. Unfortunately I'm never going to be able to use this address miners because I don't want to risk it again Unless they come out with newer driver support. You aren't going to break video cards with drivers. You will break them by overheat though and lower the life running them at 100% usage (video cards run at a lower voltage and clock speed when they aren't doing work). The best advice is to keep them cool with lots of fans, and dust free by using case filters or regularly blowing or vacuuming the dust out of their heat sink fins. |
|
|
|
Be careful with only using 160 bits of entropy for private keys. The strength of ECDSA keys when the public key is known is half the key size. For full length key 256 bits length = 128 bits strength. So 160 bits mean 80 bit of strength. This is not beyond brute force. It may not be economical but brute forcing the private key from the public key is feasible.
That's a very good point I've glossed over, that when you spend, you are releasing more information that can be used to deduce the private key, worse if in conjunction with a weak random generator by the spending wallet. I was comparing directly the possible key size to possible address size. To simplify the brute force would require some information about how the simplified public key was encoded; here I just showed it was shortened by being a much smaller number, other discoverable encodings of small keys include SHA256 (brainwallet). Putting the small key through 777 rounds of Centrifuge and Lanarea, for example, makes the encoding more obscure and more costly to rainbow-table, but still is not security equivalent to using a full random key. The encoding technique also becomes one more thing to remember. I must add that I started the topic wanting to challenge people to memorize their own 55-letter random string, and remember it a day, a week, a month later, but the thesis changed as I was typing it. |
|
|
|
|
Can we memorize a full Bitcoin private key?
I added a base26 encoding to pybitcointools to simply things (normal addresses and wallet-import-format private keys are Base58, with hard-to-memorize upper-case letters and numbers). Let's make some private keys. With this encoding, they have a usual and maximum length of 55 characters:
>>>bitcoin.encode(random.randint(1,2**256-432420386565659656852420866394968145599L), 26)
'digiglqzmbsylezyvovztjincftnxmpvcmtkszwcqrzttkgizgwgsrs'
'crbifkrcyokrerdtvfbliynoyyvspncuhenzanzoesdaggzjjccedyo'
Or if we separated them, lets try four or five letter groups:
'digi-glqz-mbsy-lezy-vovz-tjin-cftn-xmpv-cmtk-szwc-qrzt-tkgi-zgwg-srs'
'crbif-krcyo-krerd-tvfbl-iynoy-yvspn-cuhen-zanzo-esdag-gzjjc-cedyo'
We'd better check mistypes, two more letters from a hash of the key, for a 99.85% chance we detect a mistake - for a final form:
'digi-glqz-mbsy-lezy-vovz-tjin-cftn-xmpv-cmtk-szwc-qrzt-tkgi-zgwg-srsc-a'
'crbif-krcyo-krerd-tvfbl-iynoy-yvspn-cuhen-zanzo-esdag-gzjjc-cedyo-bi'
Do you have the brain power to commit a full-strength private to memory?
A private key is much stronger than a bitcoin address though - a private key is 256 bits, but an address hash is only 160 bits; every address probably has about 79228162514264337593543950336 private keys that could spend its money. As crazy as it seems, maybe we could get by only using private keys starting with 0x000000000000000000000000h; let's generate the rest:
>>> bitcoin.encode(2**160, 26)
'bdonjydfhmonirbfouktjpxyqzilesiamaq'
That is the minimum size of a computer-generated "brainwallet" key or password required to give you near the same strength as a regular Bitcoin address - 35 letters. A gifted individual could apply themselves and commit this to memory, just as there are those that memorize 1000 digits of pi.
Electrum cheats - it makes a 128-bit deterministic seed, even smaller than this (although the generated bitcoin private keys are spread around the keyspace in a way hard to reverse).
If you take letters randomly chosen from pages of a book, you need more letters (due to the frequency of certain letters). If you try to use English words, you need about 20 of them, randomly chosen from the entire Oxford dictionary (not ones you picked). If you try to make up your own password...well, you see the point.
Don't use your brain to store bitcoins.
|
|
|
|
Anybody else get problem from this site? This BitBet.Us still operating normal, right?
Still operating, taking and paying out bets as they always have. http://bitbet.us/They also still operate exactly on the terms they lay out, which makes it a pretty nice place if you're actually interested in bets. You should read the first post before you consider sending your money. Don't place your bid according to their timeline, they'll just keep your money. |
|
|
|
This needs to be bumped, has anyone filed opposition to this? The "first used in commerce" in the application is a blatant lie. http://tmsearch.uspto.govWord Mark BITCOIN WALLET Goods and Services IC 036. US 100 101 102. G & S: Cash management namely facilitating and tracking transfers of electronic cash equivalents; virtual currency exchange transaction services for transferable electronic cash equivalent units having specified cash value. FIRST USE: 20140205. FIRST USE IN COMMERCE: 20140205 Standard Characters Claimed Mark Drawing Code (4) STANDARD CHARACTER MARK Serial Number 86185037 Filing Date February 5, 2014 Current Basis 1A Original Filing Basis 1A Owner (APPLICANT) ELTTES LLC LIMITED LIABILITY COMPANY UNITED STATES 7500 RIALTO BLVD STE 100 AUSTIN TEXAS 78735 Assignment Recorded ASSIGNMENT RECORDED Attorney of Record Adam Siddiqi Type of Mark SERVICE MARK Register PRINCIPAL Live/Dead Indicator LIVE Doing further searching, the application record is here: http://tsdr.uspto.gov/#caseNumber=86185037&caseType=SERIAL_NO&searchType=documentSearchthe last status update was May 13, 2014: A non-final Office action has been sent (issued) to the applicant. This is a letter from the examining attorney requiring additional information and/or making an initial refusal. The applicant must respond to this Office action. To view all documents in this file, click on the Trademark Document Retrieval link at the top of this page. But then I see: AUTOMATIC UPDATE OF ASSIGNMENT OF OWNERSHIP Jun. 18, 2014 and bitcoinwallet.com claims they have a trademark. But finally I see a refusal of Trademark letter: http://tsdr.uspto.gov/documentviewer?caseId=sn86185037&docId=OOA20140513184102#docIndex=0&page=1 |
|
|
|
"Intellectual Property"? What is this the dark ages?
Guess what if you put some information in the block chain I can read it and do whatever I like with that information.
Good for you, go ahead and read it, that's the whole idea. I doubt you would though; you didn't read anything else in this topic. |
|
|
|
|
A solid state drive as an OS drive is the single biggest improvement you will ever experience. I boot Ubuntu 14 in under 30 seconds on an otherwise seven-year-old computer. You do have to plan your data allocation, such as C:SSD 240GB and then D:HDD for multimedia. If your current hard drive is not just 250GB of free space, but is actually a 250GB drive, it is also 10-year-old tech (but with the benefit that you can just duplicate it to a new SSD).
I would only recommend Tier-1 SSD, such as Intel 530 or Samsung 840 EVO 250GB. You can get the latter at Best Buy or Newegg for $130.
|
|
|
|
|
You can do a few things to mitigate coin applications that cause problems:
1. Lower the CPU affinity and process priority. You can do this with task manager right-clicks in Windows if you are going to leave Bitcoin running, or you can make a .cmd file (batch file) to run with the start priority options. CPU is required to validate P2P transaction signatures, and someone could be targeting you specifically with attack transaction broadcasts.
2. If your rotating hard disk is fragmented, that means the disk heads will have to hunt all over the platter to find data, limiting the possible input-output operations per second. You can use defrag programs that completely move and defrag every file, but the new blocks every 10 minutes will again be fragmented. It would be best to give the Bitcoin datadir its own ~40gb disk partition to limit hunting. This problem is solved with a SSD - instead of a limit of 150 IOPS from moving heads, it's more like 40000 IOPS.
3. Monitor RAM usage. I'm not so sure this is an issue. I have Bitcoin Core and Namecoin both running. They use under 400MB each on a 8GB system, and don't impact anything else noticeably.
|
|
|
|
You don't have to do anything so convoluted. Namecoin allows arbitrary strings to be included in its blockchain, retrievable by methods currently available in the client and through blockchain explorer tools on the web. I could register a name ip/dc-invents-fire, and give the name the JSON: {"ipdocument-hash":"f196673ab59624b00c77c7f8e1764aa77665de6d44686d07d46650c9a61b4d1c"} Elsewhere I could state that my message is "I discovered fire", and the SHA256 of that message is in block 123456 of Namecoin, proving that I invented on or before that block (which is timestamped +/- 2 hrs of actual time, outside of my control). About the only thing quirky with Namecoin is that you have to pre-order your name 12 blocks ahead of actually registering the name with data. This little delay makes for some quirks: - If you have an IP idea now, you can't publish your proof until after ~2 hrs (unless you planned ahead). - Only the final registration can be considered the time proof, as someone could pre-order and have the pre-order waiting for the later "invention" or "discovery". Name registration procedures, if you need a refresher: https://wiki.namecoin.info/index.php?title=Register_and_Configure_.bit_Domains#2._Pre-order_a_domain_nameLooking up an example name with a block explorer website: https://dotbit.me/block_explorer/name/id/deepceleron |
|
|
|
Here is the exact address hash (with fake checksum) where addresses would change into 35 bytes of base58. Remember in Base58 that 2=1 and 1=0, so we want to find the network byte + 20 + 4 where addresses of that network byte start to have 35 character long addresses: >>> dice2key.changebase('21111111111111111111111111111111111', 58, 16)
'90248722fa0bf5a28a9dfee80227dc40a4d518272400000000'
>>> dice2key.changebase('90248722fa0bf5a28a9dfee80227dc40a4d518272400000000', 16, 58)
'21111111111111111111111111111111111'
>>> len('21111111111111111111111111111111111')
35
>>> That is a network byte of 90 (144 decimal). From the start of 35 byte addresses being 0x90 + 0x2487.... 9351/65536 = 85.7% of addresses using network byte 90 will be 35 digit. All network bytes above 0x90 will be 35 digit addresses starting with 2. This agrees with: https://en.bitcoin.it/wiki/List_of_address_prefixes |
|
|
|
|
Legendary ... wait for it.
|
|
|
|
If I have an old scrypt miner with a r9 290 GPU, would that be usable to generate my address? If so, would this be magnitudes faster than using a intel quadcore with hyperthread?
Sorry for the basic question, just started dabbing into vanity addresses.
GPU address searching is done with oclvanitygen. ocl = OpenCL = computing on your video card. However, that newer GPU will have a finicky setup, requiring a specific driver version and a modded version of this program. You might search this entire thread and the "lifeboat" vanitygen thread to see if anybody has gotten that particular GPU working, to discover their settings. |
|
|
|
Not a good idea at this time. Addresses should not be re-used.
To clarify what he actually means:Addresses should not be reused after they have spent money. Ideally all payments that contribute to the balance of an address should be spent all at once to empty the address balance. However this "should" is only theoretical, it would take a major cryptography breakthrough for it to matter, and if the Bitcoin crypto was found crackable, there would be a world-wide shitstorm from everything else that uses the same crypto. Explanation:Bitcoin addresses are a ECDSA public/private keypair. ECDSA is a signing algorithm - only the private keyholder can sign messages, but anyone given the corresponding public key can verify that a message was signed by the keyholder. Bitcoin uses this technology when creating transactions: the address-holder signs a message "I want to sent my Bitcoins to Joe" to prove they authorize the transfer. However, a Bitcoin address is not the public key. It has another security layer: an address is cryptographic hashes of the public key. When given a public key, you can determine it belongs to a Bitcoin address by hashing it yourself, however you cannot determine the public key by just having an address. This is done also because the hash is less data than a full key, making for shorter addresses. After the public key of an address is disclosed, the extra hash layer of a Bitcoin address is removed. Only the strength of ECDSA protects the Bitcoin funds. Two things disclose the public key: - Spending Bitcoins - the public key is included with the transaction so the authenticity can be determined
- Signing messages - another feature that allows Bitcoin users to prove any arbitrary message was sent by them
I can receive many payments without disclosing the public key. For example, I may have a cold-storage savings address (paper wallet) where I send money every month. Nothing about receiving many payments has reduced security. Regarding alias address discovery, here are my previous thoughts:
I've started thinking it through, and a self-published alias might be the easiest addition. It would seem best to lift Namecoin's style of address registration with fee. There would certainly be a landrush period, and you would want to discourage squatting, so a significant but diminishing cost would better ensure interested parties might still find their desired alias available (see post #10 above; I paid .55 BTC in fees just for some fun...). Implementation: You go into your address book, there is an option called "register label on network". You press this, it asks you to create an alias that other clients can see to send money to you. If you are not the first, you get an error that the alias is already taken. The alias is permanently included in the blockchain along with some bitcoins you donate as the fee, and then the address book will list all aliases registered to your address. Other Bitcoin clients would have a searchable database of all these aliases to find you as a recipient. However, I don't think anything like this should be included in Bitcoin. Although not any more dangerous than "firstbits", it would make it too easy to spoof people into sending money to an "amazon.com" that goes to a malicious squatter instead. It also hinders anonymity and the sender identification that comes with one-time-use addresses. First, Bitcoin will likely never be extended in such a way, it falls in the category of storing non-transaction data in the blockchain, which is against the grain of every position taken by developers and contributors. The obvious feature of aliases is to discover someone's address, by looking up other information such as a name. However looking up a name has fundamental problems. Any conceivable system apart from a centrally micro-managed repository would allow bad actors to create false aliases such as "Deep Celeron" "The REAL deepceleron", "deepce1eron", or anything else that might foil the system by making my real account unclear to senders. Someone might go create an alias with my email address before I do it myself. Address message signing is not a solution to this problem. You don't have my Bitcoin address yet, so it doesn't matter that an alias was signed by the address someone wants to fool you into using. Namecoin allows name storage in it's blockchain. There are many id/useralias entries now where the "info" field is someone's Bitcoin address. Again, the only reason why this has value is that I got it first. I could register id/Syke, and claim that that is the proof that I am Syke, and sign further messages with the address showing proof that "Syke" owns that address and name. Aliases would be useful in theory, but would be troubling in any implementation, and would only create another way for people to have Bitcoins stolen. |
|
|
|
How do you get your bitfinex quotes now?
It looks like the bitfinexUSD ticker has no data since Jul 23: http://bitcoincharts.com/charts/bitfinexUSDThis could be a change in the bitfinex API, where bitcoincharts can't get data any more (the same data source as sierrachartfeed uses). Of course if you notice something like this, you might message user tcatm on the forum or send a support email to bitcoincharts - they may not have any idea that there is a problem if it is not reported. |
|
|
|
|
It would be possible to execute Bitcoin daemon with various -wallet=<file> option, by calling it from another environment. However, it sounds like a good way to lose coins when you make a mistake.
|
|
|
|
|
A firewall distro should only be a firewall, it is not a good idea to install server software or services on it, even for internal use. They are hardened specifically to not present any attack surface of the firewall box to the outside network. If you want to use the machine for multiple things, you should virtualize the firewall and run other services as appliances. It's not even a bad idea to have a third network adapter so the server VMs have to go through an internal network switch instead of a virtualized one.
|
|
|
|
The way to do this is have one Bitcoin client for connecting to the public P2P network, where the external Bitcoin port is port forwarded to that NAT IP address. Then set all other Bitcoins to only connect to that machine's internal IP address using the -connect command line or config option. Source: Right now there isn't a port number setting to do that. It's a feature yet to be implemented. You can only set up your NAT to port-forward to one of the computers. (I said something earlier about NAT port translation, but that wouldn't work, other nodes wouldn't know to connect to that port)
If you want, as a small optimization, you could run the rest of your computers as:
bitcoin -connect=<the IP of the first computer>
so they get all their network communication from the first computer and don't all connect over the net individually for the same information. This saves bandwidth, although it doesn't use much bandwidth to begin with, so it wouldn't really matter unless you had tons of computers.
For redundancy in case the first computer goes down, you could have two that connect out and the rest connect to both of them. The first two are run normally, the rest are run like:
bitcoin -connect=<IP1> -connect=<IP2>
|
|
|
|
|
Show Posts
