As of 5 minutes ago, a second Electrum server runs on electrum.novit.ro port 50000.

Feel free to play with it, it should offer the same service as ThomasV's server. While I can guarantee that the server will remain online and updated, do remember that this is alpha code so please don't move all your coins to Electrum just yet.

For any issues with this server, please PM me. Slowness is expected if there will be a lot of concurrent clients, SQL is to blame. I don't think that's a problem at the moment.

If there's interest, I can write a short guide to setting up your own server (which can be public, like mine, or private).

My way of doing it is to connect to a few fallback nodes ( https://en.bitcoin.it/wiki/Fallback_Nodes#IPv4_Nodes ). For example, btcnode.novit.ro would be a good choice for people in Romania or a few hops away (Europe, Russia), it is located in Bucharest and has 100 Mbit bandwidth, soon (read: next year) to be upgraded to 1 Gbit.

It is possible, but it will be treated like a normal international wire. I don't know for sure if it will go through a US bank or not, but nothing would surprise me anymore with regards to the banking system

No, SEPA is only for Euro zone.

+1. Of course, the general aspect and usability of the web interface could be (much) improved, but the system is very good as it is.

It is already possible, you can simply create a script or an alias like:


The client would also be easy to patch to not commit the file to disk at all. You start it, it asks for the mnemonic phrase, generates the keys, and when you close the client the data is purged from memory.

Also, ThomasV suggested another (better) solution for Linuxes. You run the client with the wallet file set in /dev/shm (temporary storage in RAM):


But can you tell me what the usage scenario is? I don't think it's that useful, do you think it would be a security feature? What are you trying to prevent happening?

Of course, it's the difference between selling the coins and being an intermediary for two parties who want to exchange coins. See my post #24.

I don't know what is the procedure for VAT in Japan, but as the general case says, they should charge VAT on their exchange fees.


I believe they would have to, yes.

I think it's mrcoins.org .

Yes, that is the real problem with VAT vs bitcoins. In probably 90% of the cases, bitcoins will be purchased from people, and will not carry VAT, so there's nothing to deduct .

Well, that's not really a problem, the taxman won't care, as long as he can put a price on that. It will be like selling services, or SSL certificates, or selling the same copy of an MP3 over and over.

The sale of bitcoins for fiat is actually easier for the accounting dept., since it has an evident value attached. It's more complicated to sell products for bitcoins, as this will be a barter (which must have a fiat value attached, too). But I digress.

Much better explained than I could do: https://en.wikipedia.org/wiki/VAT


No. Currency exchange is VAT-exempt.

This will not work in countries with VAT. If you want to be legal, you'll have a huge spread between buy and sell price (your markup and the VAT). Minimum 20%, much more in some countries. In order to avoid the VAT issue, you'd have to be registered as an exchange office (but Bitcoin is not a recognized currency...), or as a money transfer/non-banking financial institution, which has its own many issues, costs and regulations.

The only way I could find that might work is as a "commercial intermediary" (sorry if I didn't translate correcly) - a company that introduces two parties who will engage in a commercial exchange. Think auction sites. User A has bitcoins, user B has USD, company C provides the way for them to engage in the exchange, for a small fee. It does have the issue that company C can't be a party of the exchange, both A and B are needed...

It's complicated

No, no and no . Running the client is easy enough. Running your own server is so-so (I'll write a post about it, if there's interest). You can play, I think you'll like it, but for the moment I wouldn't advise you to transfer large amounts, as there can be bugs that could eat your coins.

Yes, yes, I meant it like in your example. I think it would be confusing if "90% chance of being included in the next 3 blocks" will vary wildly. But it's too soon to tell. Just something to keep in mind.


Well, I guess this is a point where we will not reach a compromise. I believe there should be a guarantee, and it must be enforced by the protocol/network. On the other hand, I don't really care what the technical solution is, if it works.

This sounds to be exactly what is needed to solve my initial problem. If I could make a suggestion here: it's confusing for the user that sometimes a transaction of X BTC costs a certain fee, and sometimes a completely different fee. I understand why, but the regular user won't. I know that it will probably be impossible to keep the fee constant, but it would be nice if the algorithm to calculate it will try to avoid erratic fees.

I can only imagine what a user will think if sending 1 BTC will require 0 fee, 0.05 fee, 0.000002 fee, 0.9 fee and so on

Do you know if these features are currently being worked on? The second one is enough for the moment, I think. One can simply start with 0 or a small fee and keep increasing the fee. I'm not much of a developer, but I'll help test.

If these features would be available and work correctly, I think it will fix my problem. It won't protect against miners that simply don't want to include a specific transaction, but let's assume that won't be the case.

Maybe I didn't express myself correctly. I don't want miners to do something much different than what they do now. Obviously, I don't want a service *for me*. I just want to add a "and don't leave out tx older than x blocks" restriction - which, looking at http://bitcoinstats.org/, is not even a problem, since most transactions are confirmed much faster anyway. For the miners the effect will be minimal. For the end-user though, this restriction brings a much-needed warranty.

You might be right about the technical glitch. I supposed my tx simply tripped some checks in the miners. I assumed it was intentional, but I might be wrong.

I do believe the problem still remains, though - how can we make sure transactions are always confirmed in a predetermined time (max. number of blocks)?

The standard suggestion - "increase fee" - has the following problems:

* it's impossible for a user to determine what the fee should be. Most will use the suggested value, which might or might not be enough. And...

* ...once a transaction is out, there's nothing you can do to speed it up. I suggested that the network should guarantee that it will get into a block, what other solutions can there be?

Thank you. I almost started believing that it's not possible anymore to have a debate and disagree without everybody insulting eachother .

Thank you for helping me decide whether or not you should make it on my block list. I will also be grateful if you will ignore me too, there's no reason for us to interact anymore.