secretsharing 0.2.6 on PyPI -

I don't understand how adding more strings to the original string and concatenating it with it's hash decrease it's entropy

For example, I think that:
correct battery horse staple
don't have more entropy than:
My correct battery is riding pink horse eating staples 09cfae167037f71e34e62ccb35bee41eb9b96a1c1958306608b57e4266055ea58ec16b8eef02ef01217a5b43c208a2e4b55239cb90a7aef21f25e76adc02f0a7
Last part is made with sha512sum("My correct battery is riding pink horse eating staples") (the input is concatenated to the output of the hash function).
I don't understand how adding more strings to the original string decrease it's entropy.
Link for context
submitted by tedjonesweb to crypto [link] [comments]

ProTip: Checksum your Passphrase

A recent user lost (for now) 8 BTC in a passphrase typo. This gave me the idea of implementing similar checksum logic that BIP39 uses. Lets take the passphrase "correct horse battery staple" This passphrase has a SHA256 checksum of c4bbcb1fbec99d65bf59d85c8cb62ee2db963f0fe106f483d9afa73bd4e39a8a. So now we take the first 16 bits as c4bb. Converting to binary, we find the first 11 bits are 11000100101. Convert that to base 10 and we have 1573. Look that up on the BIP39 dictionary and we find seven (note 1-based -vs- 0-based indexing)
So our new checksum'd passphrase is:
correct horse battery staple seven
So when I type "stapler" instead of "staple" I can be rest assured my mistake will be caught. Even if I botch the checksum into "eleven" instead of "seven" I know whats up because "eleven" isn't in the BIP39 dictionary.
I guess this should all be air-gapped, but I can't do SHA256 by hand yet.
submitted by brianddk to TREZOR [link] [comments]

Recovery Seed 12 Words vs 24 Words

I am wondering why are some recovery seed like on the trezor 24 words and some wallets only 12 words.
Also how does it work exactly that you can store multiple types of coins on a hardware wallet like a trezor and they are share the same recovery seed?
I am looking for somewhat of a technical explanation of how it works.
submitted by JadeDoo to Bitcoin [link] [comments]

Can anyone explain how deterministic wallets / seeds work?

I've been having a hard time finding info on how exactly a seed phrase recovers multiple addresses and was hoping someone could provide a quick ELI5 or good link that answers my question.
So if I have a hardware wallet and on that wallet I hold multiple different crypto assets, how do I recover those multiple addresses from a single phrase? Say I have BTC and ETH. Each asset can each have multiple addresses, say 5 for BTC and 5 for ETH. When I use the seed to recover those assets on a new device, will it only generate the first address, and then I have to do something to generate the other 9 addresses that I had previously used? Or does the device some how know those addresses are used and automatically recover them when I use the seed?
In my situation I'm specifically talking about a keepkey. I've wanted to make sure I completely understand how the device functions before I transfer over too much. I've been able to wipe it and recover with a single asset / wallet, but after transferring other assets on I realized I didn't really understand how the seed recovered multiple addresses and wanted to make sure I did before trying recovery with more assets / $$$ involved. Maybe I'm just an idiot, but have been having a hell of a time finding a straight answer to how this all works using google.
submitted by gl904 to Bitcoin [link] [comments]

Double-spending unconfirmed transactions is a lot easier than most people realise

Example: tx1 double-spent by tx2
How did I do that? Simple: I took advantage of the fact that not all miners have the exact same mempool policies. In the case of the above two transactions due to the fee drop introduced by 0.9 only a minority of miners actually will accept tx1, which pays 0.1mBTC/KB, even though the network and most wallet software will accept it. (e.g. Android wallet) Equally I could have taken advantage of the fact that some of the hashing power blocks payments to Satoshidice, the "correct horse battery staple" address, OP_RETURN, bare multisig addresses etc.
Fact is, unconfirmed transactions aren't safe. BitUndo has gotten a lot of press lately, but they're just the latest in a long line of ways to double-spend unconfirmed transactions; Bitcoin would be much better off if we stopped trying to make them safe, and focused on implementing technologies with real security like escrow, micropayment channels, off-chain transactions, replace-by-fee scorched earth, etc.
Try it out for yourself:
EDIT: Managed to double-spend with a tx fee valid under the pre v0.9 rules: tx1 double-spent by tx2. The double-spent tx has a few addresseses that are commonly blocked by miners, so it may have been rejected by the miner initially, or they may be using even higher fee rules. Or of course, they've adopted replace-by-fee.
submitted by petertodd to Bitcoin [link] [comments]

Analysis & graphs of block sizes

I made some useful graphs to help those taking a side in the block size debate make a more informed decision.
First, I only looked at blocks found after approximately 10 minutes, to avoid the time variance from influencing the result.
Then, I split the blocks into three categories (which you can make your own judgement on the relevance of):
The output of this analysis can be seen either here raw, or here with a 2-week rolling average to smooth it. Note the bottom has an adjustable slider to change the size of the graph you are viewing.
To reproduce these results:
  1. Clone my GitHub branch "measureblockchain": git clone -b measureblockchain git://
  2. Build it like Bitcoin Core is normally built.
  3. Run it instead of your normal Bitcoin Core node. Note it is based on 0.10, so all the usual upgrade/downgrade notes apply. Pipe stderr to a file, usually done by adding to the end of your command: 2>output.txt
  4. Wait for the node to sync, if it isn't already.
  5. Execute the measureblockchain RPC. This always returns 0, but does the analysis and writes to stderr. It takes like half an hour on my PC.
  6. Transform the output to the desired format. I used: perl -mPOSIX -ne 'm/\+),(\d+),(-?\d+)/g or die $_; next unless ($3 > 590 && $3 < 610); $t=$2; $t=POSIX::strftime "%m/%d/%Y %H:%M:%S", gmtime $t;print "$t";@a=();while(m/\G,(\d+),(\d+)/g){push @a,$1}print ",$a[1],$a[2],$a[0]";print "\n"' output-dygraphs.txt
  7. Paste the output from this into the Dygraphs Javascript code; this is pretty simple if you fork the one I used.
tl;dr: We're barely reaching 400k blocks today, and we could get by with 300k blocks if we had to.
submitted by luke-jr to Bitcoin [link] [comments]

xvultx4llltx7w2d.onion is 18 months online today

TLDR; The site that has been running nice and quietly on TOR for 18 months. We thought today is a good day to make the url public outside of our group of amigos.
PGP: 3DB6 FF02 6EBA 6AFF 63AF 2B6E DCE5 3FA2 EC58 63D8 Bitcoin: 18FNZPvYeWUNLmnS6bQyJSVXYPJ87cssMM TOR: http://xvultx4llltx7w2d.onion

Vultronix encrypted social network.

Abstract: Since time began, social interaction has always been private to those within the same vicinity. Today, however, much data is sent encrypted to a third party, gets decrypted on arrival and then stored among mountains of un-encrypted data, stored for financial gain creating giant honeypots. These giant honeypots of un-encrypted data are just too irresistible to those who have the power to request access.
We propose a solution to these centralized honeypots by enforcing client side encryption in such a way that the server has no access to the encrypted content, we believe this can be achieved via a mix of key hashing, PGP, AES and Onion routing. We acknowledge the current JavaScript anonymity problem and see a future where secure hardware will encrypt/decrypt the data for the user. We propose the below as a simple POC for inspiration of future development, open for all to copy, enhance and most importantly, to scrutinize.
1. What is the example? A truly client side TOR based encrypted centralized social network. Allowing users to interact anonymously online without the ability of the host to spy on the user. Trust with the host is established via signed open source Javascript. Everything is delivered directly from the host via TOR without any use of CDNs.
2. Centralized over decentralized? The greatest problem available to implementing encryption to the masses is user experience. We developed Vultronix to allow the user to interact with others securely via a familiar feeling platform. More experienced users can download the code and setup their own .onion domain, further removing the risk of a centralized authority.
3. Registration The user is required to fill in 3 fields. For familiarity we've named them the following - Email address, Password and Words list. The user is not required to enter their actual email but is encouraged to generate a string with a lot of entropy; it is acknowledged that the less experienced user will probably make up an email address, both the password and words field should be as random as possible. The entropy of these 3 fields is on what the user's encryption depends.
Note: as the system is not decentralized, the logins are only available to brute force attack by the host or if/when the database is compromised and dumped online. To achieve the best security a password tool should be used with 3 very random strings. A more user friendly solution is to make up a very random but easy to remember email address via a random mnemonic seed generator similar to BIP39, a difficult password the user can remember and a short word list.
Given a user selects the following log in details which, let's assume, were created by a BIP39 generator. + email: [email protected] + password: liquid sketch husband + Word list: shove proof dismiss gauge
The above contains 12 completely random words.
The browser will concatenate these to [email protected] sketch husbandshove proof dismiss gauge This value would then be hashed, creating the following hash. 90bc6ba57145e2116ea10d136ec49061e9a15c5694b171ba1e5753ab02e141e4
This hash is hashed forward 5001 times, on the 2000th hash the sha-256 becomes a sha-512 hash in the following fashion. SHA512(2000th hash + 2000th hash) and is stored momentarily as the "loginHash" variable. The loop continues on with all further loops taking a different path that can't be reached by hashing forward the login hash. The 3000th hash is saved as the "passphrase" variable The 4000th hash is saved as the "encryptionKey" variable and the 5001st hash ends up being Hashed again for good measure. loginHash = SHA512(loginHash + 5001st hash);
At the same time during registration the user's browser will generate a 4096 PGP key pair. The PGP password is the "passphrase" variable. Both the passphrase and the encryptionKey never reach the server. The PGP pub/priv keys are both AES encrypted with the encryptionKey as the password and sent to the server.
Note: The PGP public key is never sent to the server unencrypted as we don't want someone with access to the Database to be able to analyze who is friends with who.
Also generated at sign up is a UUID, this is AES encrypted as well.
Sent to the server on sign up is the following. + encrypted: PGP public key - AES encrypted string. + encrypted: PGP private key - AES encrypted string. + encrypted: UUID - AES encrypted string + loginHash: SHA-512 hash.
Upon signing in, the user fills out his profile. This data (including any images uploaded) is encrypted client side by the user, the user encrypts a copy to himself using his own PGP public key, which is currently decrypted in his browser session, then encrypts this again with his AES encryption key.
4. Login A user will login with the same credentials used at sign up, the loginHash will reach the server and the server will find a match and send back the user's encrypted credentials. The user's client will decrypt these with his "passphrase" and "encryptionKey", neither of which have ever been sent to the server.
Note: If a MITM intercepts a user loginHash over the wire, the MITM will be able to retrieve the encrypted data from the server, but will never be able to decrypt it, and won't have any further access to the user's data.
Once the user decrypts his credentials data, he'll have access to his UUID, the client will then request from the server an encrypted friends list object, the client will decrypt this and populate client side his friends list. This will contain the public PGP key of each of his friends along with a friendship key unique to each friendship as well as a generated shared password unique to each friendship. The client will also send requests to the server to look for feed updates, inbox messages, new friend requests and accepted friend requests etc.
5. Friend requests To keep friendships private, a user must send another user a friend request token. Since everything in the Database is encrypted , it isn't possible for a user to simply look up a friend. Via the friend request page the user will fill out a short message and press a button. The user is presented with a SHA-256 hash that will expire after 2 weeks. The user simply needs to pass this hash onto his friend via other means of contact, the friend then enters the hash into the friend request page, the friend will then see a thumbnail of the user (or whatever logo the user has chosen for his profile picture) followed by the short message the receiving friend should recognise, e.g. "Hey Alice it's Bob, please accept my friend request", Alice accepts the friend request and they're now friends, Alice won't have access to Bob's profile page until Bob next logs in.
Behind the scenes, the following happens: Bob's message is concatenated to a generated UUID This string is hashed many times like the loginHash An object is created containing Bob's following encrypted data: + PGP Pub Key + friendshipUUID unique to this friendship + sendersFriendshipUUID + acceptersFriendshipUUID + Bob's Name + Bob's thumbnail (all images are converted to base64 strings in the browser then encrypted/decrypted client side) + Request message etc.
This encrypted data is sent to the server, the friendship token is equivalent to the final login hash that a user generates on login. Bob doesn't, however, send Alice this final hashed token, he sends her an earlier version of a hash. Alice will enter this hash, her browser will roll it forward creating the decryption key and eventually the friendship token that resides on the server, her client will send this to the server, the server will respond with the encrypted data. Only she can decrypt the data as only she has the earlier hash of the friend request token.
She decrypts Bob's friendship data, adds it to her FriendsList data, encrypts the latest copy and sends it through to the server for safe keeping. Alice's client will now create an encrypted accepted friendrequest object submitting it to the server. Alice will then use Bob's PGP key and their new friendship password they share to double encrypt her profile to Bob.
When Bob logs in next (or if currently online via web sockets) he will receive the accepted friendrequest token. Bob's client will then do what Alice's did and update his friends list etc and send a copy of his profile through to Alice. Bob and Alice will now see each other's new status updates, album updates etc.
Note: A new friend can never see old status updates, this should be considered a feature.
6. Chat and instant messages Users can see when other users are online and chat via web sockets, they can also send offline messages via their inbox. These messages are double encrypted. If Bob sends Alice a message, the following happens: Bob's client will encrypt the message using Alice's PGP public key and a copy using his own PGP public key, he'll then encrypt both using their shared friendship password and place 2 entries into the database. If Alice is online the server will push up her messages instantly via web sockets, if not, she'll see the message the next time she logs in, she'll notice this as the inbox icon will be red to signify unread messages.
Note: If a user has Vultronix open in another tab, he'll hear a sound when a new message is received as well as a keyboard sound when his friend is typing.
7. Group invites Groups allow shared users to associate online in private without having any access to who other members of the group are, users can also send private encrypted messages to other users of a group in full privacy. Anyone can create a group. On group creation the group's admin client will generate a random password, the admin can give the group a logo and message etc. The admin can then create a group invite token and the recipient of the token can sign up to the group in the same way that a user would accept/decline a friendship request. Once a user is a member of a group, he too can invite friends. All of these people will share an AES encryption key which they'll get via decryption of the encrypted invite request. Each user will be able to download a shared membership list of the group, which will not be able to identify any users. This list will contain user PGP keys that are used when a member sends another member of the group a private 1 - 1 message.
TLDR; Everyone in the group can start threads, comment in threads, invite new friends etc, no one outside of the group will even know of the group's existence, the group's description, name, members list etc. All of it is encrypted and private. No member will know that other members have privately messaged each other. No member will be able to find another member's profile. However, if they wish to be friends, they can private message a friendship request token. Members can have their own groups and private message friend request tokens through to members to join other private groups.
8. Status updates When a user creates a new status message, the user's friends will see the message appear in their feed either in real time if they're online, or the next time they login. When a user fills in the status box, the user can optionally add a photo or youtube video link (caution: external services could be used to track you) and then press save. After the user saves the status the following happens:
The status is encrypted and saved to the server. To reduce client computation time as well as server storage, only one copy of the status is saved to the server. The client will encrypt and upload a new encrypted message for each of his friends, this message will simply hold a AES decryption key and a status ID, the friend's client will then request this status and decrypt it. All of the user's friends can comment on the status, only the user will be able to click through to their profiles. It's impossible for user's friends to be able to interact with each other outside of their shared friend's status comment box.
9. Shops Private encrypted shops would be easily implemented via the following: The shop owner would setup shops in a similar way to setting up a group, inviting customers to his private shop with tokens. He could send these tokens to his friends in his friends list or new people he meets in a private members group via private message. This would allow the shop owner to sell to only people he trusts, e.g. his grandmother or aunt etc. The shop owner would have complete privacy. The shop owner would keep control of all his bitcoin private keys. He would enter a list of bitcoin addresses, then add items to his shop. Upon adding an item, the client would submit an encrypted copy of the item to the server for each customer of his store. Customers would browse his store and see an item, the item would have a bitcoin address to pay to. The customer would enter a message, be it his email address for a digital order or a postal address for a physical order. He would then pay to the bitcoin address and hit submit. The shop owner would see a page with orders and see the email address and manually check the bitcoin address has funds.
This would allow sellers and buyers online to have great protection, providing they're buying/selling from people they trust. If the server is hacked and database stolen, no one will have access to any bitcoin as no private keys would ever be on the server and everything is encrypted, so no one would know what shops even exist, unless they have a personal invite to that store.
This kind of private store could be very useful for people living under oppressive regimes. If, for example, someone wants to learn about Capitalism and would like to buy Capitalist literature but they live in a censored Communist state, they could access via TOR and order anonymously without ever having to worry about the site being hacked and their government going through the data and heavily punishing them, possibly with death. They would be at risk though of the literature being confiscated in the mail so they'd be better off to order a digital copy and have it emailed or, perhaps, the seller could simply copy and paste the text into a private message to the seller.
The possibilities would be endless for the above, we have not implemented this though as we're not sure of the legality. If someone decided to sell something illegal and law enforcement wanted information on the buyeseller, we would never be able to retrieve it from the database. If, however, they managed to become a member of a store, they could perhaps tell us a UUID that might represent the store and we could delete the shop at their request, but not much else. For this reason we're not going down this path, it is however fascinating to think of.
We'd predict that OpenBazaar would one day offer the ability of hidden stores, not just the ability to route via TOR. For any OB users we've added a OpenBazaar field to the member profile info page.
The goal of this project is to show that client side end to end encryption is possible for intermediate users and not that difficult to implement. We hope this inspires people to build something similar and better or, perhaps, fork the code and fix some bugs etc.
We appreciate your time, if you enjoyed this or atleast appreciate our effort, our bitcoin address is below. Bitcoin: 18FNZPvYeWUNLmnS6bQyJSVXYPJ87cssMM
PS: The code will be uploaded to a public Github profile this week.
http://xvultx4llltx7w2d.onion Latest version: Content hash: 1aa450c4a4bef1ddee92d6572f81aa14baad959402563064f0ff81e6f42b69d9 lib.js hash: 8704461878818f5f00f18c61789e03c1b90bfc07bc21a15301ce876e7f71829c
submitted by Vultronix to onions [link] [comments]

How DPR might spend his millions from inside of prison

I spent some time thinking about how DPR might spend his millions from behind bars. Here's what I came up with. Can you do better?
Imagine that DPR is in prison and he's got 80 million dollars worth of BTC in a brainwallet. For example, all stored with the passphrase "correct horse battery staple" (c.h.b.s for short). The Feds want that money and they're definitely not going to let him send it to anyone so they're not letting him use a computer, especially not one connected to the internet.
If he had access to a computer, he could write a transaction from behind bars and pass it on a piece of paper to someone on the outside. But he doesn't. And if he did, that computer would have a keylogger.
His next alternative is to write c.h.b.s on a piece of paper and pass that to someone. But he'd then be trusting all his 80 million to one person. That's not safe, either.
Assuming some planning, maybe he divided up his money into tens of thousands of bitcoin addresses, each one with, say, 20BTC. Now he can give out private keys as needed, written down, and spend money in increments of 20BTC.
The problem with that is that he has to memorize thousands of passphrases. One option, he could use:
but someone would catch on to the pattern and take all his money.
In prison he might have books. Instead of numbers, he could use the first letter of words in a line from a book, like Romeo and Juliet. Like this:
Harder to crack but it's just obfuscation. If someone figures out the book, he's screwed.
Ideally, he would have a hash function that could be computed with innocent things that you'd find in a prison: a deck of cards, a book, maybe a calculator. Bruce Schneier invented a cryptographic algorithm that uses a deck of cards. If you had a good hash function that you could do mechanically, you could use those outputs at
A deck of cards is surprisingly strong. The order of a random deck of cards is about 200bits of entropy, even more than a 160bit bitcoin hash, so a deck of cards could be useful.
That's as far as I got. Any better ideas? How do you store 10,000 brainwallets in your brain without using a computer? Or make transactions without a computer?
submitted by eyal0 to Bitcoin [link] [comments]

Is it obvious yet that there are automated coin sweepers that look for brain wallets or badly generated wallets -- wallets generated from a bad pseudo-random number generator?

These things are definitely going to crop up -- I'm sure they exist already. But it's going to kill the bitcoin/cryptocurrency community if naive people choose bad passwords -- or worse if banks use poorly generated accounts. Remember that the Enigma should have been almost unbreakable, but was broken because of operator error. I know there are several "joke accounts" based on the hashes of "Satoshi Nakamoto," "password," "correct horse battery staple," etc. But I feel like this is the first information a newcomer should have.
submitted by ihaphleas to Bitcoin [link] [comments]

Announcing NetVend pre-beta for interested developers. NetVend is a virtual vending machine that runs on Bitcoin and has vast potential for many applications. More info in post.

Hey Bitcoiners. I've been working on this project ever since I heard about the idea about 4 months ago. I'm extremely excited to announce the beginning of the beta testing phase of this project. We're open to any interested developers, and will be funding as much experimentation as we can. The entire project is open-source; you can find the server code here. The service is hard to describe, so I'll be wordy. I'll bold the important parts as a sort of running TL;DR.
EDIT: There is a more technical writeup for those interested here, which also goes into the potential to harness the server for social networking purposes.
Creating a blog is easy, but anything more ambitious gets complex extremely fast. To handle money, a deep understanding of either a country's tax law (and the hassle of handling fiat currency online) or the intricacies of using Bitcoin is required. To offer a truly unique automated service, a very significant depth of computer science must be understood, and a server must be administrated and maintained. Before too long, a person with a new idea is facing extremely daunting hurdles--hurdles that most Internet users have no idea how to even begin overcoming, and would take even experienced developers a significant amount of time to conquer. How many ideas have we lost, not because the idea would fail, but because the cost of implementation is just too high?
Imagine if every internet user had easy and cheap access to a neutral server that solves many of these problems.
NetVend is a server that allows users to create arbitrary online services capable of accepting commands, processing queries, storing data, and accepting payments. The server keeps track of the Bitcoin address of each account, and commands must be signed with the corresponding private key. Each command incurs an extremely tiny fee (for example, a penny would pay for over 100,000 NetVend tips). Interfacing with the server is extremely simple using our open-source apis--we currently have one for Python, we have a javascript one nearly completed, and others are on the way. However, the server can be accessed by any program capable of signing messages and making http requests, and the source code for the apis we do have make it clear how to do this.
There are two very basic steps to begin to use the server. This article assumes use of the Python api.
First, the account must have funds. For the time being, these will be provided to anyone expressing interest in playing around with the server--just let us know which address you'll be using, and we'll send you some credit via a NetVend tip. The server also supports deposits, but we're wary about offering this too freely until the server is more fully tested. If you're interested in trying out the deposit feature, contact me and I'll help you out.
Second, import the api and call one of the two following functions:
netvend.setPrivkey(your_privkey) netvend.setSeed('some seed') 
Alternatively, you could use the api's generateCommand functions to generate any command, return this command to the user, and request that they sign it manually. You can then take that signature, and call sendSignedCommand. This is more of a hassle, but allows trustless apps to interface with the server. This article will assume that the private key is set, as this allows for simpler examples, but a few minor edits would make any application work in a trustless manner.
NetVend has three commands: Data, Tip, and Query. Each command has a fee on the order of 30 milliSatoshis (1000 mSat = 1 Satoshi). Bitcoin deposits are tracked internally and deducted with precision to the microSatoshi (1000000 uSat = 1 Satoshi) automatically and instantly.
response = netvend.commandData("Your first NetVend data upload!") success = response[0] if (success) data_id = response[1]['command_response'] #the value of data_id can now be used by anyone with the Query command to retrieve this data entry. 
Data stores arbitrary data into the database, which is public and transparent. This data can be retrieved by anyone running the Query command, and is easy to be mined, sorted, and just generally analyzed if anyone's interested enough to structure an SQL query. However, this data may also be encrypted using any encryption techniques the developer wants to use, since the server processes the command regardless of the nature of the data. This will enable clever developers to quickly and easily build apps that can dependably utilize a neutral storage space for any encrypted or non-encrypted communication the app needs to use. Note that because this is a paid service, the server has a more inherent tendency to stability that other similar free services do not. With a sufficient community, it can be assumed that a fairly recent backup of the database will always exist somewhere. This means that even in the event of the NetVend server disappearing without a trace, another incarnation of it can easily be created and restored to a very recent state. In summary, the Data command stores a piece of data, publicly, for anyone to easily find, forever.
Current Beta fee: 30 mSat.
response = netvend.commandTip(aFriendsAddress,5000000,0) #tip aFriendsAddress 5 satoshis' worth of uSats, referencing 0 as a data entry (interpreted as no data entry) success = response[0] if (success) tip_id = response[1]['command_response'] #the value of tip_id can now be used in a manner similar to data_id, seen above. 
Tip sends internal credit from one account to another, specified by that account's Bitcoin address. These are not native Bitcoin transactions, and therefore they require some degree of trust--but are still verifiable in their own way (see the technical writeup). However, because the blockchain isn't used, some limitations of traditional Bitcoin transactions are avoided. Tips are much cheaper than Bitcoin transactions (one Bitcoin transaction cost would pay for the cost of over 1 million NetVend tips), they're virtually instantaneous, and they have the precision of 1/1000000 of a Satoshi (1 uSat). Because NetVend accounts are based on a bitcoin address and the corresponding signatures, funds can be sent to any Bitcoin user regardless of whether they currently use the service. This is because the recipient can always claim or control those funds by sending commands signed with their private key.
Additionally, these tips can reference a data entry. When used in concert with the Data command, a tip can be sent with a sort of memo that describes some request or explains the tip in some way. These tips can be constructed by users directly or by the programs developers make. In both cases, these tips can be used as a paid request for any arbitrary service, automated or not.
These tips can be viewed and analyzed by Query in the same way that data entries can.
Current Beta Fee: 30 mSat.
query = "SELECT id,data FROM data WHERE id < 10" #SELECT id,data Get the data id and the data itself #FROM data from the "data" table #WHERE id < 10 for the first 10 data entries response = netvend.commandQuery(query,2000) #send the query with a max_fee of 2000 uSats (=0.002 Satoshis) success = response[0] if (success): rows = response[1]['command_response']['rows'] for row in rows: print "data entry number " + str(row[0]) + " says " + str(row[1]) #iterates through all returned rows, and prints out the data id and data of each entry 
Query accesses any of the public database tables (accounts, commands, data, tips) with any valid SQL SELECT query. All valid SQL SELECT queries are accepted and returned, excepting timeout issues. This allows anything (again, user or script) to comb through all public data (remember, however, that data can be encrypted) with that most perceptive tool--an SQL SELECT query, either simple or complex. This is how a client must gain any information about an account or anything else on the server directly, which means that a new account must receive either a direct Bitcoin deposit or a smaller tip from another NetVend account to access any information (Again, during the beta, we will be funding as much of this activity as we can).
(To those who haven't used SQL before, an SQL SELECT statement can be either very basic (for example, get the balance of every NetVend account) or extremely complex and perceptive)
Current Beta Fee: about 1.012 mSat, but varies based on complexity of query and size of returned data. See the netvend source code for details.
I've written an example service that facilitates user-vs-user rock-paper-scissors bets, which is currently operating on address 18UjjHg7PHg5YsCdhdmFSkQhfBbt3R2RpH (EDIT: it's only a script on my computer, so it isn't actually online--although it is tested, and you can try running it yourself). It accepts tips, charges a fee, and then sends the combined ante to the winner of the bet. The ante is whatever is left over after deducting the service fee.
If you'd like to experiment with the server, you can request funds from me directly, and I'll try to accommodate as many of you as I can. Alternatively, if you use netvend.setSeed('correct horse battery staple'), there is some credit sitting in that account that you can use. You can then tip this away into another account, but please try to be conservative so others can experiment as well. I've been using the python command prompt to send simple commands to the server, and it seems like a good way for anyone to get started.
If you guys have any questions at all, I'll be more than happy to answer them or help with any trouble you're having. bardiharborow has been helping a lot with all of this, and might be around to answer questions as well.
Thanks for reading!
submitted by syriven to Bitcoin [link] [comments]

Mycelium Bug / Exploit

Down Vote This Thread User Error
~~ This is a cross post that i made on the bitcointalk forum just thought I would put it here as well to see if any one had any thoughts.
Yesterday I sent 0.0993 BTC to my friends phone and the funds never showed up. I am using an LG G2 with android 4.2.2 and the most recent mycellium and he has a nexus 5 with android 4.4 with the most up to date mycellium. My address is 15eoLGGEwnVyqUxY8yQrNKf6c8zM7Hqanh and his is 1KaPzW1GPpYMzYBVTbHQ2zaUNfaMhPfZiU.
According to the funds left his wallet a couple minutes before they even arrived. I am assuming that as soon as he generated the QR code a withdraw was placed for the exact amount. I can only assume that his private key was compromised. He had just generated that key minutes before we did that transaction.
I know those funds are gone I just want people to be aware that there could be a serious bug somewhere. The BTC ended up in this address 1Gbp4mLHPepB3FFmBphhNcyLNaYLFyHcxj which at one point had swept correct horse battery staple. This is very weird. Any insight into what just happened would be appreciated. ~~
Edit: Thread on Bitcointalk Link
Edit: Friend clicked on the wrong address and had me send funds to publicly known private key Thank you mongodbace Link
submitted by Sixthtry to Bitcoin [link] [comments]

Bitcoin Limerick (No. 1)

Use Bitcoin to buy syrup:maple ,
Use Bitcoin to buy porno:anal ,
Secret passwords you must choose ,
But PLEASE do NOT use ,
Correct horse battery staple
submitted by daenerys_3dragons to Bitcoin [link] [comments]

Keep a brain wallet in an upcoming Bitcoin song.

I've just launched my first crypto token which lets anyone include audio in my upcoming Bitcoin songs hosted on SoundCloud for 0.1 btc.
Here's my latest Bitcoin track, AMLKYC.
This is as far as I'm aware a novel way to store brain wallets. The example I gave in the description reads:
you could codify the words as associative sounds eg. correct horse battery staple -> ‘bing’ ‘horse galloping’ ‘phone charging sound effect’ ‘stapling a document’)
To elaborate a bit on this, you would use more words or sounds and change the order using an 'order key' or index, keeping it separate from the song so anyone listening (including me) isn't able to figure out your sound code and steal your bitcoins.
Eg. You might decide in this case the 'order key'/index is 3,1,2,4 which means you give me the sounds in this order:
'horse galloping' 'battery charging' 'bing' 'stapling sound'
When you listen to the song later and recognise your recorded sounds you change the order according to your 'order key'/index
Create the brain wallet using
If anyone likes to buy a Crypto-Token and support my music please do NOT send any bitcoins to 'Samples for DJ Leo' which was my earlier attempt for which I managed to lose the private key! I can't take down the asset unfortunately as it's in the blockchain. If anyone from CoinPrism can disable that asset on the site I would be grateful.
submitted by djleo to Bitcoin [link] [comments]

Bitcoin regulation ~= thought crime?

I'm a value subjectivist. That means that I reject all notions of intrinsic or extra-agent value. That does not mean that I reject extra-agent relations of cause and effect. Bitcoin has properties which allow it to be tradeable and scarce. Those do not give it value, but they allow it to be means for goals that some have which allows them to value it.
In a certain light, many laws look rediculous. Ones about taxing or regulating value appear so to me because it's, to my mind, comparable to taxing or regulating opinion or preference.
Bitcoin (and all currency) is not really a value transfer system. Value is subjective, so how can I transfer it beyond the veil of subjectivity? I can't "transfer blue to you," so how the hell can I transfer opinion or preference. At best I can convince you to adopt those opinions or preferences for yourself. And just because a coordination of beliefs causes valuation to appear in one person and disappear in another doesn't mean that the value was "transferred" any more than me redirecting power to a different light bulb means that the first light bulb transferred illumination to the second bulb. Light/radiation is a continuous process and I contend that value is as well.
Bitcoin is far better described as an expectation coordinator. All this fancy math is useful for one thing - to enforce scarcity and distribution in a decentralized manner. That gives bitcoins properties that are instrumentally useful for desired ends and allows them to be valued as means. Moreover, it allows others to have reasonable expectations that others will perceive those same properties and value bitcoin for the same reasons they do.
Given these likely shared expectations, coordination can appear out of chaos with people acting like they have specifically shared desires when they merely have tangentially compatible ones. All the blockchain ledger does is express a set of facts that most (all?) who use the system choose to give weight.
Regulating a set of facts just because some decide to give it weight just seems like a way to create thoughtcrime. Actions seem more worth of taxation to me but, that too, is just a preference. Knowledge of private keys a form of private knowledge. If I know a secret or a joke or something that you don't know, should I be taxed when I tell someone else?
Bitcoin also stretches the defintion of ownership. I can possess bitcoins solely because I have the only knowledge (as far as I know) which allows me to assign the next set of transfer conditions. Normatively, ownership is found nowhere in the blockchain or math - it's also subjective or at least agent-dependent.
I remember posts on this sub asking if figuring out someone's private key and transfering bitcoins is actually theft or not. From a possession standpoint, theft isn't really a thing - if I can gain control of it, then the universe is "ok with it." The answer people are looking for is a normative one and is agent-dependent and won't be found in the structure of bitcoin though that structure can color one's opinions - for instance, I find it a stretch to say that merely guessing or even out-mathing (aka cracking) private keys is theft though it does have the deprivation factor. I certainly have a hard time feeling bad for anyone who lost coins buy putting them in the CORRECT HORSE STAPLE BATTERY address.
TL;DR. Value is subjective. Bitcoin is an expectation coordinator, not a value exchange system. Taxing expectations and preference is similar to thought crime. Guessing someone's private key stretches the common understanding of theft.
Edit: I don't mean not equal !=, I mean approximately equal ≈. I was just too lazy to find the character at first.
submitted by jdkeith to Bitcoin [link] [comments]

Lost my first 0.03 BTC today

This is a cautionary tale for people new to bitcoin and a reminder for those already into it. I use Hive as a desktop wallet on my computer. It can be secured by a password. At the time I created my password, it was something I would remember given the circumstances of my life at that time using the "correct battery horse staple" method. It's been about a month or so since I created the wallet, and now I cannot recall the exact order and quantity of the words in the password.
I didn't write down the password because I foolishly thought it was something I'd be able to remember at any time. Now I have to mentally write it off or else I'd go crazy thinking about it. With online banks or PayPal, there's the safety net of password recovery, but it's not the same with Bitcoin. If you're irresponsible like I was, you'll lose access to your BTC.
tl;dr: keep a safe copy of any passwords you may use to secure your digital access to bitcoins.
submitted by idlephase to BitcoinBeginners [link] [comments]

Vanity and Brain address at the same time

hey there /bitcoin!
Does anyone have a way to make a vanity address (custom one, like “1snubCeB4apZUsuVJvvoRBK8G7AFo15ri”) yet have it memorizable through a brain wallet (“correct battery horse staple”).
submitted by suclearnub to Bitcoin [link] [comments]

[PARTNER] Looking for python devs to help build and participate in the world's first tradenet! Netvend is an online, virtual vending machine: Using Bitcoin, any human or program can pseudonymously buy or sell any service, art, or product on netvend.

I've finally completed a working prototype of a project called netvend, which is a sort of global, transparent tradenet. I'm looking for python developers who are interested in working with netvend. Netvend is easy to use, and exposes a marketplace to both users and scripts with an open-source, trustless system. I'm going to make an announcement post on /bitcoin in the next day or two, but for now I wanted to get some early feedback and testing from anyone on /jobs4bitcoins who's interested.
To give you a quick idea of what netvend can do, following is the current draft of what will by my announcement post.
Netvend allows any agent (user or script) with credit to:
This is all accessible with only 3 lines of Python code, and is psuedonymous by nature. All it requires is initial credit, through a deposit or being tipped by another agent (For now, the CHBS address (see the code below) has credit and is open to anyone who wants to use it for anything).
Each command deducts netvend credit from your identity, but the commands are cheap. A deposit of just $0.01 would pay for any of:
All commands are automatically signed by the api before being sent to netvend, and the signed command is stored transparently. Because the signatures prove the authenticity of the database, any user with a copy of the database can resurrect the server, should it be attacked or blocked, and the community can easily verify it as legitimate.
All code used on the server is open-source (github), as well as the python api used to interact with netvend (github).
Even at the most basic level, netvend is extremely easy to interact with. In python:
import netvend chbs = netvend.Netvend('correct horse battery staple', seed=True)#use the seed 'correct horse battery staple' to create an identity #if we wanted the address of this identity, chbs.get_address() would tell us response ="butts") 
Assuming the chbs identity had netvend credit, response should contain, among other things, the id of your brand new post on netvend.
Using the tip command is similarly straightforward. For anyone with SQL experience, the query command should be easy to use as well. For a crash-course on all of netvend's commands, see this page.
If anyone is interested in developing any kind of application for netvend, whether small or large, please contact me with any questions! I'll respond to replies, PMs, and emails ([email protected])
submitted by syriven to Jobs4Bitcoins [link] [comments]

The first brainwallet generated address used?

My friend asked what the Brainwallet concept is. I started explaining what private key is and that brainwallet resp. using SHA256 on something is a way to get this key. And then he started to think (he is a brilliant mind person...) about lower entropy etc. Thus I only confirmed his ideas and then he asked a question I'm afraid I can't answer...
The question was: what was the first brainwallet used? Was it used before the block number 167.948 (2012-02-22) where the first occurrence of "correct horse battery staple" happened? Wayback machine contains the first snapshot of the original web April 13, 2012 and the domain was created April 9, 2012. This is part of the Bitcoin history, so let's help document it. We can't prove when the first brainwallet was used (at least not yet ;-), but let's at least try to approximate the time better.
[ Warning: If you want to provide your earlier address used, please move your coins first to (non-brainwallet!!!) generated address and then provide the address used and prove it is brainwallet only afterwards. ]
submitted by paveljanik to Bitcoin [link] [comments]

Best way to remove a private key from Bitcoin-Qt?

Hi, I have added the private key of a brainwallet to my client with the password "correct horse battery staple". That is the default password defined here:
Obviously I did not want to use that address, I was just curious what's happening there. Unfortunately this address is constantly spammed with transactions, which makes my bitcoin client (I use 0.8.2) completely unusable. My computer is always at 100% CPU and the client does not respond.
Is there any way to remove this private key, or do I have to create a new wallet and re-add all the private keys?
submitted by martinus to Bitcoin [link] [comments]

Seeking beta testers for a BTC-backed financial playground/tradenet for Python scripts. Using an Agent, scripts can transact and communicate publicly. The ServiceAgent simplifies offering paid services, or paying for services, to 5 lines of code or less, given only a seed, callable, name, and fee.

ServiceAgent TL;DR:
Using the ServiceAgent, any Python callable can be used as a service. The developer only has to specify a seed for the ServiceAgent, reference the function, and give the service a name and a fee. The fee can be much less than a single satoshi. The ServiceAgent must also have netvend credit, but for now I'll provide credit for all interested developers.
Netvend authenticates calls and responses behind the scenes by checking cryptographic signatures, and keeps a transparent, independently auditable history of all activity.
If you'd like to try it out, download the Python netvend toolkit and follow along with the code samples below. At the moment this only works with Python 2.x.
This is a beta service. It's an open beta, but the "beta" part means that you should not depend on it operating smoothly all the time. We may need to take the server down, or even wipe all the data and start from scratch. You've been warned.
How do I fund my agent?
For the time being, I'll simply fund your agent for you. Once you have your agent's address, PM it to me and I'll send it some credit through netvend.
Alternatively, I've set up a sort of faucet agent, in case you don't want to wait for me to respond. See below, "getting credit from the faucet agent", to see how to get some.
How do I use the ServiceAgent to offer a service?
The best way to describe this is to jump right into the code. Let's say we want to rent out the service of adding 2 to any number for 1 mbit. A silly service, but keep in mind we could use any Python function, as long as its arguments and return values are json-encodable.
import netvendtk def add_two(num): return num+2 service_agent = netvendtk.ServiceAgent('correct horse battery staple') print "service address: " + service_agent.get_address() service_agent.register_simple_service("add two", add_two, netvendtk.convert_value(0.01, 'mbtc', 'base')) batch_results = 
First, we define a function. Any function would work, as long as the arguments and return values are json-encodable.
Then we create a ServiceAgent with a seed, and print its address. This agent would normally need to be funded through a netvend deposit, but like I said, I'll fund your agent for you for now. Just PM me the address once you've printed it. Note that $0.01 of BTC pays for thousands of interactions at the least.
Then we register our function as a simple service, under the name "add two", and for a cost of 0.01 mBTC (converted to base netvend units (uSats)).
Finally, we tell our agent to work. Until now, our agent hasn't needed to connect to netvend. Using a series of cryptographically signed netvend requests and commands, it will search for any new requests, use the add_two function to serve any "add two" requests, and post the results publicly to netvend.
(This series of requests and commands is what netvend charges microfees for, and is the reason your agent must be funded before being used. By charging microfees for low-level commands, netvend allows developers to use a sort of tradenet backbone however they'd like.)
Another script can request this service from anywhere on the Internet, as long as the seeded agent has even a very tiny amount (starting at about 0.05 satoshis, or 0.0000000005 btc) of netvend credit. The calling script must know the address of the serving agent, as well as the name and fee of the service, and the expected arguments:
import netvendtk service_agent = netvendtk.ServiceAgent('bla') add_two_service_address = "1JwSSubhmg6iPtRjtyqhUYYH7bZg3Lfy1T" result =, "add two", [5], netvendtk.convert_value(0.01, 'mbtc', 'base')) 
We specify the service address, the name of the service ("add two"), arguments ([5]), and the fee we'd like to send (0.01 mbtc). This script's ServiceAgent then signs its own series of requests and commands (this is what the 0.05 satoshis are for), first requesting the service, then fetching the response that our first script posts in response.
The speed of the last line returning the result, of course, depends on how often the add_two service script checks for requests.
The withdraw command is down (this is why I'm funding developers directly, myself), as I'm still halfway through an upgrade. But normally, you'd be able to simply use:
if service_agent.fetch_balance() > netvendtk.convert_value(1, 'mbtc', 'base'): service_agent.withdraw(netvendtk.convert_value(1, 'mbtc', 'base'), your_bitcoin_address) 
This would withdraw 1 mBTC of credit into Bitcoin if your agent has that much. Any credit your agent makes could be withdrawn on an automatic schedule like this, or can be spent buying services from other agents and scripts.
Testing it out with others:
Once you get any kind of service running, please respond below with your address, service name, and argument expectations! Keep in mind that if you set an appropriate fee, your agent can earn enough credit to pay the netvend fees. Alternatively, if you'd like to try calling other services, check out the comments below to find some.
For now, I have an example service running that simply takes a string argument, then returns a string containing the argument it was passed previously. It's running on address 1GbceejVDAShYRRXaT2TDdWjxpqbazwphm, under a service name "get last string", and takes a fee of 0. This means you'd access it like this:
sa = netvendtk.ServiceAgent('your super secret seed') to_send = raw_input("string to send: ") print"1GbceejVDAShYRRXaT2TDdWjxpqbazwphm", "get last string", [to_send], 0) 
(Note that since my service is taking a fee of 0, it will eventually run out of netvend credit and die.)
As I personally test out and see the kinds of services you guys set up, I'll keep a running list of them at the bottom of the post.
Getting credit from the faucet agent:
Use the following code to get credit from the 'chbs' agent to your own agent that uses a more secure seed:
import netvendtk #the 'correct horse battery staple' agent has credit already, meant for public use. chbs = netvendtk.Agent('correct horse battery staple') #using an Agent (not a ServiceAgent) because we're only using the low-level pulse command. #A ServiceAgent is just an Agent with some more methods, #so the next line could use an Agent or ServiceAgent. #either one will generate the same address and use the same netvend account. #you'll want to change this seed, as this is meant to be your own secure agent. my_agent = netvendtk.Agent('a super secret and suitably random seed') #this will be the public address for the keypair held in my_agent, #and is needed to receive pulses of credit. my_agent_address = my_agent.get_address() #now, send a pulse of credit from the chbs agent to your agent's address. #specify 10 satoshi, converted to the 'base' netvend unit (uSats). #Please don't be greedy! 10 satoshis will last you way longer than you'd think. chbs.pulse(my_agent_address, netvendtk.convert_value(10, 'satoshi', 'base')) 
How does it work?
All activity is facilitated via netvend, which charges microfees to pay for the infrastructure of the tradenet (this microfee structure is essential to a server that is neutral, dependable, and accessible at such a low level). All activity is cryptographically signed automatically by the api before being sent to netvend. This authenticates the command, so there's no need to send passwords. Netvend then stores all commands and signatures transparently, which makes the entire database independently auditable, in the same way the Bitcoin blockchain is.
Because netvend is entirely transparent, all data uploaded is public. A developer who desires more privacy can use encryption to hide data. Do not use this tool for passing sensitive information, without encrypting data.
The ServiceAgent is really just a complex wrapper around the Agent class, which accesses netvend through the lower-level post, pulse, and query commands. Using only these commands (which are simple but initially may seem counter-intuitive), a script using netvend is capable of much more than simply offering and paying for services. For example, by using the query command, the reputation of any agent can be researched through any valid SQL SELECT query--a very powerful research tool. Or you could search through the pulse history to see which services are most popular, or even where a given agent turns around and spends its profit. Or you could find out which strings were most-often passed to my earlier mentioned "get last string" service. Unlike the ServiceAgent, a fair understanding of netvend is needed to unlock the more powerful potential of the Agent's basic commands.
Netvend is completely open-source (github). Please review, comment, and fork! If you're interested in an administrator role with netvend, please contact me.
The next few steps:
I have a long list of to-dos, but these are the first/most important items on the list. I'll work on whatever you guys see as most important, moving forward, and I'd be ecstatic to have help with any of these:
  • Get deposits and withdrawals back up and working again. These were working before, but a recent server code update has outdated them, and they need to be updated as well.
  • Add methods to ServiceAgent to faciliate posting and getting objects: something like ServiceAgent.post_object(name, object) and ServiceAgent.get_object(name, author=None). This could be used for an agent to post public cloud data, whether intended for public consumption or just for personal storage. It would also enable a script to reference the same data without re-posting it, which could cut down quite a bit on running netvend costs.
  • Modify ServiceAgent to support encrypted activity.
  • We have already worked a little bit on a social network that uses payment history (or, "pulse trails"/"pulsenet") to find and prioritize new content ("posts") based on the voluntary tips of agents the user has already approved. More about the concept here.
  • An audio/video/other streaming tool could be built that allows anyone to stream data to netvend, publicly. Because of the way netvend works, it will only cost the streamer pennies to upload, the users would pay their own microfees for downloading the content, and all activity would be pseudonymous and secure.
  • With netvend's built-in communication and transaction framework, a casual kickstarter tool could be developed. It would specialize in queries that analyzed the reputation of different agents, so the user could quickly judge the trustworthiness of a project, and easily donate micropennies or more.
  • A tool could be written that simplifies game data and command interaction, where a host script can host a game and accept game move commands from other scripts. This would allow an open-source MMO game, and allow open-source competition between game interfaces. This would only be suitable for slow-paced games, but still has some interesting potential.
The larger scope of the project:
I've been working on netvend for a little over a year, and I'm now certain it's capable of amazing things. The ServiceAgent tool is my first attempt at exposing netvend such that it can be used without having to understanding netvend's counter-intuitive nature. If you're interested in working on the project at a lower level than through the ServiceAgent tool, or if you just have questions, email me at [email protected].
Existing ServiceAgent services:
Name: "get last string"
Address: 1GbceejVDAShYRRXaT2TDdWjxpqbazwphm
Arguments: [new_string]
Fee: 0
Serves requests every: 3s
Description: just returns the string passed to it during the last call.
submitted by syriven to Bitcoin [link] [comments]

BrainWallet Strength / Entropy Question

Hello /bitcoin,
I have been playing with BTC for a while, and I decided to invest 1-2% of my salary over 2-3 years and see what happens. I think that the safest possible method is a brainwallet generated with a live OS.
Here is my method for creating a passphrase (later executed on an offline copy of from a live CD):
  1. Choose 3 friends (with indian names spelled in a peculiar way)
  2. Create a sequence : for each one.
  3. Concatenate all 3 sequence, add a digit.
So my passphrase is :

The questions :
  1. (Is the entropy strong with this one?) entropy=randomness, this is random enough - right guys?
  2. How many brain wallets to create? (one, 10 ? don't put all your eggs in the same basket and all that)
  3. Is "correct horse battery staple" the best passphrase ever? just.trolling
submitted by BrainWallets_FTW to Bitcoin [link] [comments]

Nerdlist:The Totally Not 1337 Bad Idea's That Gives Infosec Noobs A Foot In The Door - Tarah Wheeler Freebies That People Sold For A FORTUNE Fixing Fence Faster with STOCKade Stapler Secure Password AND easy-to-remember? Proper way to Drive Wire Fence Staples

[The passphrase "correct horse battery staple" is shown in the center of the panel.] Four random common words {Each word has 11 bits of entropy.} ~44 bits of entropy 2 44 = 550 years at 1000 guesses/sec Difficulty to guess: Hard [Cueball is thinking, in his thought bubble a horse is standing to one side talking to an off-screen observer. Bitcoin, Litecoin, Dogecoin, Defcoin, etc Control of private key == Control of money. What is a Brainwallet? "correct horse battery staple" Passphrase. How a typical brainwallet tool works "correct horse battery staple" Passphrase v v v v v v v v SHA256 Bitcoin Wallet Library in Rust. This is a library to build Bitcoin wallets with Rust. It uses BIP32 key derivation, BIP39 mnemonics and BIP44, BIP48, BIP84 key hierarchy which makes it compatible to TREZOR, Ledger and many other wallets. >>> PlaintextToHexSecretSharer.recover_secret(shares[0:2]) 'correct horse battery staple' Bitcoin Private Keys. Note: Bitcoin private keys are in Base58 check format. Splitting into reliably printable base58 shares Using your own variant on “correct horse battery staple” for multiple accounts is also a bad idea, from a security and privacy perspective. A single compromised account could leak all the passwords to your email, Bitcoin exchange, and other sensitive accounts.

[index] [7205] [5018] [6272] [31187] [20595] [12917] [28195] [19552] [7538] [5039]

Nerdlist:The Totally Not 1337 Bad Idea's That Gives Infosec Noobs A Foot In The Door - Tarah Wheeler

The ST400i also has outstanding power allowing you to fire up to 750 staples per fuel cell (depending on temperature) and in conjunction with the 3.7V Li-ion battery, you can fire 3,000 staples ... And you answer: “Correct”. correct horse battery staple You’ve already memorized it and it’s very secure. Experts recommend that a passphrase should consist of at least 5 to 6 words. The ... Trojan Horse Was a Unicorn Recommended for you. ... Detailed step by step Battery Replacement Guide for iPhone 6S (Plus) ... The Rise and Rise of Bitcoin YouTube Movies. 2014 · Documentary; quick easy how to on fence staples best place to get staples and other farm supply's check here Give us your puns, your wit, your searing humor, your correct horse battery staple. Tarah Wheeler is Chief Information Security Officer at Setec Astronomy. She holds a PhD in Horribleness from ...

Flag Counter