Why would you post this? Here is a short list of obvious problems:
1. Everything mentioned in this thread so far about DNS models, which presumably you read since you're posting here.
2. The obvious security implications of people trusting you with a giant database of email addresses, and sending these to you, without HTTPS.
3. The obvious security implications of you publishing bitcoin addresses from your database, without HTTPS.
4. Only supports one bitcoin address per transaction; every additional one "succeeds" according to site but does not show up in the lookup.
5. You do not validate checksums. I was not only able to register bad bitcoin addresses, but even "addresses" which had various special characters and looked nothing like a bitcoin address.
6. Removing addresses does not work. The link in the confirmation email 404's.

I appreciate you are just trying to accumulate email addresses for whatever nefarious purpose, but this is inexcusably sloppy.

There is no from address. It is clear what you are asking for, but not why you need it or why you believe it is the "sender's address".

You may find it worthwhile to read http://download.wpsoftware.net/bitcoin/bitcoin-faq.pdf .

No, it should be much much harder.


There you go


No, you're fine. If you had responded by insulting everyone who commented, insisted that you understand Bitcoin perfectly and everyone else doesn't, and that your idea would fix everything if only the damn developers would stop conspiring to shut you out, that would warrant an apology. (And yet, those people never offer one...)

It is definitely a problem that users are seeing and manipulating addresses. Already this leads to people using the same address for multiple transactions, people developing all sorts of weird misconceptions about what addresses actually are, and people using addresses in ways which clearly tie them to their identity.

The solution is absolutely -not- some sort of DNS. Since ideally, addresses should only be used for a single transaction, the communication effort taken to publish an address and its owner (ignoring completely the problem of how to do this securely or verifiably, how to handle name collisions, etc, etc) could just as well be spent communicating the address directly when creating the transaction. This ought to be done by some sort of payment protocol, which would not only avoid address reuse and hide addresses from users, but would also make for easier negotiation of coinjoin-style tricks, spending across multiple addresses, and other privacy-improving features.

This is maybe a longer answer that you wanted, but you're asking a pretty big question:

http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/

Let me make gmaxwell's comment a bit more concrete: suppose Bob wants to receive a payment from Alice, but Alice is conspiring with Eve to double-spend without his knowledge. Suppose there exists some spending protocol so that for any actors A and B, A can send money to B with probability p > 0 after a conversation consisting of N replies, each of which take at most t time to compute. You may suppose that all of p, N, t depend on A and B, if you like. Thus A can send money to B with probability p in time T = Nt + O(dist(A, B)), where the latter term comes from communication time.

Then Alice can send money to Bob, with probability p_B > 0 in some time T_B. (For concreteness, all times are measured in Alice's frame.) She can also send money to Eve, with probability p_E > 0, in some time T_E. As long as Eve is close (say, she and Alice are secretly the same person), T_E = Nt to a good approximation. But if Bob is far away, T_B = O(distance(Alice, Bob)), and if Bob is far enough away, Alice can spend completely to Eve before any information can be exchanged between Alice and Bob. So if Alice spends her money to Bob, but immediately after sending the last message to him, she also spends it to Eve, she has accomplished a double-spend (with probability p_Ap_B > 0), where each of Bob's and Eve's disjoint light cones see their transaction as complete but not the other. When these light cones intersect some time later there is no way to tell which of the two spends is the "real" one.

Now, this is somewhat fanciful, but if you replace the speed of light with the speed of propagation in real networks, you have a real problem. Because Alice and Eve might be on the same CPU doing this spend in L1, while Bob is on some other network, perhaps one which Alice is DOS'ing in the meantime.

(I had an even more fanciful post thought up involving Bob and Eve being in separate black holes, but it was too easy to think of simple rebuttals which missed the point :})

It's worthwhile to learn the git bisect command for finding things like this out.

If the offending commit did nothing except this, you can even commit a reversion to your local repository, by running git revert 123abc. Then you can keep track of future updates by

(You may want to replace 'master' with some other branch, if it offends you that 'master' will no longer match 'origin/master'.)

My bad. I misread that he was using blockchain.info to obtain blockchain data.

Edit: I take this back. He is using bc.i: https://github.com/coinmessage/coinmessage/blob/master/coinmessage/services.py

You should probably qualify this with "manually managing keys is an easy way to make money-losing mistakes". If you want to move money into a wallet, just send a transaction.

Even bitcoin developers have stories of fat-fingering these things. It can be much worse for people who aren't clear on how wallets handle keys. There are quite tragic stories which show up on IRC and the development list from time to time, and with bitcoin valued as highly as it is, this is not the sort of mistake you want to make.

1. I am not a sockpuppet of Luke-Jr's.
2. Accusing core developers of having sock puppets and trolling is a stupid way to get anyone to take you seriously.
3. Putting core developers on your ignore list is a stupid way to learn anything.
4. My activity on bitcointroll says absolutely nothing about my knowledge or experience with bitcoin, its community or cryptography in general.
5. I didn't call you anything. I provided a link to the "accounts are not addresses" FAQ. I'll give you the benefit of the doubt and assume you read it, since my server logs show several accesses between the time I posted the link and the time of your "sock puppet" comment.

If you want to develop usable software with bitcoin, you need to listen to the experts in the community. You need to understand how bitcoin works. You need to be aware of existing tools (especially those built into the reference client!), and follow the current development and research. You need to understand the cryptography involved and common pitfalls surrounding it.

Instead, you published cryptographic software which abuses bitcoin primitives to obtain cryptographic keys (using some random centralized service no less!), which you then use for purposes they weren't designed for, to do something which has already been done. You then admitted that you weren't familiar with ECC and didn't understand what bitcoin addresses were for, and despite this you personally attacked Luke and myself. This is not the behaviour of a responsible person, or someone who can be trusted to properly develop cryptographic software.

http://download.wpsoftware.net/bitcoin/bitcoin-faq.pdf

Also accusing Luke-Jr of trolling is quite rich..

At risk of my server being killed by the load, I'll post this here:
http://download.wpsoftware.net/bitcoin/bitcoin-faq.pdf

If anyone knows how to make JSON-RPC calls through Rust (or C), I'd be able to (a) do my own 'sendtoaddress' equivalent, and (b) check for double-spends, excessive fees, negative fees, etc, and flag these as errors.

Right now I only check things intrinsic to the transactions -- for merge-unsigned, I ensure there are no duplicate inputs; for merge-signed, I ensure that all transactions are identical modulo scriptSigs.

It's not terribly important to do lockunspent -- if somebody double-spends, the coinjoin will be invalid. Presumably they wanted to do the coinjoin, so they've just screwed themselves. So any double-spend blocking is purely a usability feature.

Hey guys,

I have written a tool in Rust to make CoinJoining easier to do -- though it still requires creating and passing raw transactions. (I apologize for the weird language choice, but Rust is awesome. The first time the code compiled it worked correctly, that's just how good the static analysis is with this language.) Having said that, I have only done so much testing, so I encourage you guys to download and play with it:

https://github.com/apoelstra/coinjoin

Be aware that testing is perfectly safe -- no matter how badly my code mangles the transaction, any changes to the outputs will invalidate the signatures, so there is no additional risk of money loss from running the program. (On the other hand, make sure you verify every transaction you sign!)

From the README, there are two steps to using the program:

1. All parties who want to coinjoin create a raw transaction using createrawtransaction. They submit these to one individual, who enters them into CoinJoiner by running

./coinjoin-merge-unsigned

Then just copy/paste the transactions in, one on each line, followed by a blank line. The output will be an unsigned merged transaction.

2. This merged transaction is distributed to the original parties, who each sign it. Then they send these back to the individual running CoinJoiner, who merges them by running

./coinjoin-merge-signed

Then just copy/paste the signed transactions in, one on each line, followed by a blank line. The output will be a merged, signed transaction that is ready to be submitted to the bitcoin network.

Well, you'd need to require a deposit well in excess of the purchased amount (say, deposit 1BTC to buy 0.5BTC), and at least initially, you would need to force the user to wait 3-6 months before they broke even.

It would then take a number of years to build enough trust to make the system usable for reasonable amounts in a reasonable time.

In that time, a person seeking to buy bitcoin could easily build up a decent reputation on #bitcoin-otc, probably find some people in real life to verify him and sign his crypto key.

Where did you hear the phrase 'scriptPubKey'? This contains the lowlevel bitcoin script used for transactions, but generally there is no need to know what exactly is in it. However, if you really want to, it's all publically available on the blockchain. (I believe blockchain.info will give you the hex values, which might be easier than poking around with bitcoind.)

You can translate the raw binary data into a human-understandable form by checking the relevant wiki page:
https://en.bitcoin.it/wiki/Script

Standard address-to-address transactions all have the same template, as given on that page:
scriptPubKey: OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
scriptSig: <sig> <pubKey>

Hope this helps.

If you order an ASIC today, it will be several months before it ships. In that time, the difficulty of the blockchain will have increased by several times (since there are ASICs shipping now and turning on now). I suspect that by the time you finally get it, you won't have much of a chance of getting your money back.

However, if you have electric heat, your ASIC will be able to take some of the load off of your heater, and therefore run for free. In that case, you only need to wait and you will eventually get your money back (maybe after several winters).

The problem here is that credit cards can be reversed up to several months after the initial charge. So your drip would need to be very slow, wouldn't be worth the wait, and ultimately could still be used for fraud. (Say, you deposit $5, buy another $5 by CC, then reverse the CC charge. The longer you wait, the more you gain, but there is never any risk to you, the scammer.)

Hey all, andytoshi from #bitcoin here. I've been around since 2011.