Buying and Using Bitcoin Anonymously Without ID (2020 Updated)

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]

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 http://brainwallet.org:
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]

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.
Data:
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.
Tip:
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:
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]

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]

[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 = chbs.post("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]

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: http://brainwallet.org/
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 = service_agent.work() 
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 = service_agent.call(add_two_service_address, "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 sa.call("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]

Far left Democrats Are Failing In Their Districts, Abysmal Polling And Almost No Top Donors #97 - Massive Wood Round Dutch Pour - MUST SEE - YouTube 800HP Sleeper Station Wagon Encounters Police (Best Excuse ... Eric Ocasio Cortez Chief Of Staff Faces Federal Investigation Over Potential Campaign Finance Violations

[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. Posted in Security Hacks Tagged correct horse battery staple, diceware, dictionary attack, eff, passphrase, passphrase list Post navigation ← Good In A Pinch: The Physics Of Crimped Connections This work is licensed under a Creative Commons Attribution-NonCommercial 2.5 License. This means you're free to copy and share these comics (but not to sell them). More details.. “The Bitcoin Brain Drain: A Short Paper on the Use and Abuse of Bitcoin Brain Wallets” - Marie Vasek, Joseph Bonneau, Ryan Castellucci, Cameron Keith, and Tyler Moore “Speed Optimizations in Bitcoin Key Recovery Attacks” - Nicolas Courtois, Guangyan Song, and Ryan Castellucci Correct Horse Battery Staple. Most geeks will have come across the idea of length beating complexity, and passphrases trumping passwords, from the “Correct Horse Battery Staple” cartoon. If you’ve never seen this, do go and take a look.

[index] [284] [435] [25423] [24480] [30157] [648] [11170] [11696] [23123] [16819]

Far left Democrats Are Failing In Their Districts, Abysmal Polling And Almost No Top Donors

Ocasio-Cortez Accused Of MAJOR Ethics Violation, Paying Boyfriend. Ocasio-Cortez's boyfriend was granted an official house email and people began to question if she hired her boyfriend. She denied ... Sign in to like videos, comment, and subscribe. Sign in. Watch Queue Queue The Green New Deal Is A SOCIALIST Trojan Horse. In fact most of the policy positions in the bill have to do with providing services to people instead of fixing the economy. The far left bill does ... Part 1 - https://www.youtube.com/watch?v=14HDpEeu_EE Part 3 - https://www.youtube.com/watch?v=keD6OmfXDZk Well, the time has come for the return of our big h... Ocasio Cortez Ex-Chief Of Staff Faces Federal Investigation After Abrupt Resignation. Saikat Chakrabarti is reportedly facing a federal probe having to do with the unorthodox way he conducted his ...

#