Having been dealing with sending and receiving bitcoins on various services I have noticed a thing that always takes some extra time: checking that the address is right.
Since all transactions are irreversible and that every address looks the same, I have naturally been checking them many times before actually doing the transaction.

I have a way to simplify this: to develop a system of bitcoin-wide color coding checksums that are going to be displayed everywhere a bitcoin address can be entered (there is no way to force this of course, but if a system is good it is going to be adopted gradually).

The checksum should be color coded for fast comprehension by humans and also because it seems to be easier to remember. Making a checksum expressed as a letter, code or a similar symbol would pretty much be pointless, since it would be any easier to remember or faster to check than first/last letters of the bitcoin address itself.

I propose using 6 colors, red, green, blue, cyan, yellow, and magenta, since those are most distinguishable from each other, and involve just basic colors and mixing between them. To my understanding, people who have partial color blindness are unable to distinguish between one or several of those basic color, so using all of them increases chances that those people will still find this system usefull. They will perhaps not be able to tell difference between all 3 color bars, but perhaps the first one and last two, etc.

Keeping number of color small also makes it easier to adopt this system on many different sites with different designs. It is possible to make those colors dark, light, saturated, unsaturadet, etc, so that they will still be clearly distinguishable from each other and not stand out too much from the rest of any design.

Right now I have noticed that I have been checking the first and last letters of a bitcoin address to check that it is right (3-5 symbols). I am assuming many other people do this. To make this new system more compatible with that old behaviour, I propose that last 3 letters can be sometimes included in the color checksum, one letter per color. (Some websites right now also have this problem that the field is just too small and that you either see the beginning or the end of an address. If there was a color checksum that is always visible, I would not have to go into that field and scroll it just to check my addres, which is especially pain on mobile devices, with keyboard opening, etc...)

This way, for example if you are already instinctively checking last letters of a bitcoin address, you can still do this, but you will also notice the 3 colors on the websites that accept this. At the same time, on the website that does not support this, you are going to keep checking those last 3 letters, and won't really have to change your behavior. It's just that it will perhaps take you a little longer time to do the check, since recognizing letters takes more time than recognizing a color pattern. There can even be websites that don't want to display the least letters an extra time (they are visible in the end of the address, after all), and in that case you will still see the 3 colors after the address, so the system works without those last letters also.

How the checksum is actually calculated (how an address is "translated" into a 3-color code) should not depent just on the 3 letters, but on the whole address of course. That way there will be less collisions for the last letters+3 color code combination. (And it is that combination that the system will try to make each user to be familiar with).

So to reiterate, the point of this system is that each address is going to have it's own color combination, which is going to only depend on that address. That way, when you see your address in your wallet, you will see the 3 colors and (sometimes perhaps even unconsciously) connect those colors to that address. When you then enter your address somwhere on the internet, on a website that supports this color system, you will see the same 3 colors, and know that you have entered the right address. You won't have to check the letters like we all do right now. Even if you will still do that, you can at least very fast check if the address is indeed wrong, because it will display wrong colors and you will notice that instantly.

Another feature of this system is that we will have a standard way to display if a form field contains a valid address. Many times when I am copying an address to some field, I miss the last letter, or there can be some other mistake like a space inside an address, or some other symbol which have been copied errorneously. Right now I don't see any popular service having instant (before a form is submitted) display of whether an address is a correct bitcoin address or not. Using the color system, it will only display the colors for a valid address, and seing them will directly tell you that 1) you have copied the address correctly and 2) that this is the right one, since you recognize it's colors. (See the last example in my attached image for en example).

I am not too worried about the recent events themselves, I don't think they display any major flaw in Bitcoin.
The events happened due to a bug in another library, these things will happen eventually. Since bitcoin is software, there WILL be unforseeable bugs, if you know that Bitcoin is a piece of machine code and are using it, you basically accept it already.

But the problem is getting warned about these things as fast as possible.
It seems that a lot of bugs can cause the chain split, as well other events, for example failure to update in time, or simply not hearing some important news.
That's why it is very important that people that are left behind will always get a warning.
It seems that a lot of these problems can be indicated if the software had a warning system for when it sees two different chains available (perhaps longer than X (6? 10? 20?) blocks).

According to some topics, for example LukeJr has a system like this already in place, however it involved external checks made possible by running multiple versions of the client.

What we need is for the standard client to constantly check for this situation and warning the user if it happens. It would be very good as a (optional!) setting to also make it possible to shut down until manual inspection option, if the situation arises. Since the bitcoin client is integrated with a lot of other software, it would be good to have support for this check even in the jsonrpc-communication which the client supports.

Thoughts?

As per my request, I wrote a patch to apply to the Bitcoin client that will drop all transactions to bitcoin users and simply not relay or verify them. It will also drop all transactions that are less than 21,000,000 bitcoins in value, so you might want to change that value to 1 or 2 satoshis, to only drop SD's losing bets tx's.

Let's show them how the free market works and that not only miners have a say on this subject!

Code:

diff --git a/src/main.cpp b/src/main.cpp
index 9a06dbf..d3fba73 100644
--- a/src/main.cpp
+++ b/src/main.cpp
@@ -384,8 +384,16 @@ bool CTransaction::IsStandard() const
     BOOST_FOREACH(const CTxOut& txout, vout) {
         if (!::IsStandard(txout.scriptPubKey))
             return false;
+        if (txout.nValue <= 2100000000000000)
+            return error("CTransaction::IsStandard : ignoring transaction with dust output");
     }
     return true;
 }

As I can see, they don't charge their users anything? And even though the fees are pretty small right now, they must have thousands of transactions which in the end must cost a "real" amount of money?

Times go by, nobody seems to want to "kill" bitcoin with legislation, so ultimately there are more and more completely legit companies dealing in bitcoins. Both taking payments and paying other parties in bitcoins. Due to the new nature of payments with bitcoin, as opposed to normal payments, many of the companies should be including special clauses into their EULAs. For example, what does it actually mean to pay someone? (i.e, confirmations, connectability to different nodes, basically how to prove that you have paid) What happens if there is a block chain split, how to prove there was a block chain split? Such legal framework would protect both the users and the owners of businesses, maybe it is time we should start writing some basic legal texts to help new companies and users alike?

These would not be any texts or licenses that the bitcoin software comes with, or requires anyone to comply with. These would be very good examples of how to form an EULA for a company that is dealing with bitcoins, to avoid future problems and make any possible future legal processes more clear and easier to settle.

Or maybe there exists something like this already?

(If this has been discussed already or similar idea is implemented, please point me there.)

The chances are very small that ECDSA will be broken suddenly (perhaps not very soon, but unexpectedly). However that is possible, we never know. There are mathematical problems that were unsolvable for decades, to be finally resolved, to everybody's surprise. As I understand, for bitcoin this would mean death: no owner of any address will be able to prove that he really was the owner of the address.

Again, this is a very hypothetical scenario, but if Bitcoin is to become really widely adopted, this probably should be addressed. No single mathematical problem should be responsible for total world chaos.

So I propose a simple solution: make a widely accepted mechanism for publishing a signature based on another algorithm in the blockchain, that would prove the ownership of a certain address. That way, in the future, if the bitcoin crypto would be broken, it will be easy to prove that somebody had the private key for a certain address before the breakage.

This could for example be done like this: A user that wishes to ensure the proof of ownership of a private key, generates a new public key pair using a different algorithm than what is used in bitcoin (RSA is the logical choice). Since ECDSA and RSA are based on different mathematical concepts, chances that they both will be broken at the same time are MUCH smaller than that any one of them will be broken at all.

Using this new public key, the user encrypts a strong hash of his ECDSA private key with his RSA public key, and makes the encrypted result public in the blockchain, along with the RSA public key (or it's hash perhaps).

This way, in the future, if the ECDSA will be broken, there will still be no ready mechanism for everything to just work as it did, but the users will at least have the ability to prove that they did have their ECDSA private key at the time of making this signature public in the block chain.

If the RSA will be broken first, we'll just revise this method using some other public key algo instead, republicising signatures made with it instead.


Implementing this would not require any change in the protocol, just a general consensus on the format of these signatures. They could be made public in some way in the scripts of transactions with nominal transfer amounts. At this point no other node needs to understand these transactions, they just have to be in the public block chain history for the idea to work.

In the future, if the shit would hit the fan, a new bitcoin version would be made anyway (incompatible with the old ones), and then that version could be made to understand these transactions, but that may never happen, so for now it would be enough to just make this information stick in the block chain.

Thoughts?

I am not talking about the block chain split, even though it could of course be caused by the network split.

I am talking about any substantial amount of nodes somehow get disconnected from the rest of the network and only being interconnected to themselves. Just for the sake of argument, let's talk about 20 nodes (which is still a very low number and would not cause any global problems) being disconnected for even 1 hour. And of course, I am not talking about a bug in the software which causes clients to behave differently, I am talking about the scenario where just due to the uncertainties of the internet, network hardware failures and such those 20 nodes simply are disconnected from the rest.

What is the real probability of this happening? Isn't it really low? Nodes are trying to connect to other random nodes, they don't choose only their neibours, right? So that if for example even 1 of those 20 nodes gets connected to any of the outside nodes, those 20 are not "disconnected from the world" anymore?

(previous name: Both the protocol and individual coins should have an expiration date)
Too often has the topic of "what to do with users that won't upgrade and become incompatible with the system" come up in the discussions about BIP16/17, and in many other discussions. To put an end to this, I think we should come up with an official time limit of the protocol and even individual transactions, a time limit which will guarantee their acceptance and compatibility.

I am not sayng that after a certian time a transaction automatically becomes invalid, I am just saying that the bitcoin network will only guarantee that the transaction will be kept valid for a certain time, say a year, or 6 months or something like that.

The reason is that bitcoin is a developing system. We cannot just wait for all the people to upgrade, because that just slows down the progress for everyone. If you are using bitcoin, you SHOULD already be very present in what happens to it, if there are any upgrades, due to the inheretnt instability of a such new product. The price varies, there are serious bugs found in clients, if there will ever be a successfull attack on it, that would be good to know also, etc... You should "keep an eye" on your bitcoin assets anyway. So why not make this requirement official? Not only official, but also set an actual time, so the people will know exactly, when to check on their coins and maybe transfer them to new addresses if needed.

Because this argument, which ultimately says that we shouldn't make any changes to the protocol which would be incompatible to the previous versions, only makes the change discussions harder, as if they were not already hard enough. There will always be people who won't upgrade, but if we have an official expiration date for them, then it is only their fault.

Another thing why that would be good is for example the block chain bloating. There is obviously not a defined solution for it yet, but at some point a solution will come up, and what if that solution will mean somehow forgetting parts of the old block chain? Then if we would have an expiration date, we would know exactly how much time to wait to make sure that everyone is onboard.

Let's setup an account with adwords, and try to get anyone to donate to that campaign, and basically run a pay-per-click campaign for keywords like "pay online", "anonymous payment", "liberty reserve" and such.

This would certainly promote bitcoin, and online marketing seems like the perfect way for this. We will attract target audience (ie, not offline people who never even heard of online payments) for very reasonable price.

Not only would it get more people to get interested in bitcoin, it would benefit everyone in the long run, the more people are using it, the more stable the price (and probably higher too, since the demand is increased).

We could setup a single bitcoin address, and a trusted person would transfer the money to the adwords campaign, providing us with screenshots. If I am not mistaken, there can even be public accounts of adwords which people can use to log in and check how much money was spent and on what advertisements. The actual donated amount could easily be checked from the block chain. So there are not many ways this scheme can be frauded.

If this works well, maybe even some pools could cotribute some percent from their generated amount to this address, for the sake of the community and the future.

I would do this, but it's probably better if someone with larger reputation here does it to get the trust of donators.


So basically what we need in this case:

- A trusted person that could setup this kind of thing and keep it going? If noone wants to, we can discuss some reward scheme. (Like a percent of all donations go to him, or a set amount per month)
- We must come up with advertisement texts and keywords that those text should apply to. Please put your suggestions here!

[And instead of putting our time on trying to make it something it's not]

While it is maybe "feels cool" when an offline restaurant chain, or a gas station or some other store starts accepting bitcoins, I think we should not forget that bitcoin is an *online* currency. I even think of it as "liberty reserve, but much better".

Basically, there are these reasons:
1. Bitcoin is not meant to be used offline, in stores, not even so much on mobile devices (which would work, but not as good as on PCs). It *is* however, a great and unique online currency, with some great qualities, like speed, low transaction fees, anonymity (sort of). This is what it should be used as. And instead of putting our time on trying to make it something it's not, and trying to get offline retailers to use it, we should spend more time on promoting it online, where it is at its best. Are there any stores that use Liberty Reserve offline? No, because it wasn't meant for that!

2. Using bitcoin in offline locations is very problematic technically. If you go to buy lunch, they don't want to wait for 10 minutes until your transaction confirms. They don't either want to check the market price all the time and adjust their prices, which, as opposed to online shops can be printed on papers and boards. Do you reprint them all the time then?
Most of "normal" shops don't have secure enough setups anyway, and wallet stealings and such things would be a great problem if you could pay by bitcoin in every restaurant.
The only thing we will achieve by accepting bitcoins offline is people starting to believe that bitcoin is slow, unsecure and plain pain in the ass. Which it is, when used offline!

3. There is no inherent *reason* to use bitcoin offline. Are you trying to achieve anonymity when paying for your lunch? Pay with cash, much easier. Transaction fees? Pay with cash. Or maybe are you trying to eat lunch in a restaurant that's on the other side of the globe? Well then you've got bigger problems
So while by promoting bitcoin online we are actually making the world better and simpler, by promoting it in offline stores, we are just doing so because "bitcoin is cool".

So I say, stick to online businesses, and put all the effort into promoting it there! Like discounts for bitcoin payments, bitcoins for charity, and such and such!

"A miner that can work with memory underclocked to 300MHz and scans whole 32bit nonce space."
This is a quote from the wiki page about the Phoenix miner. (https://en.bitcoin.it/wiki/Phoenix_miner)

But there is no more explanation about this, can someone elaborate? Should I underclock my memory and use some extra options with it if I underclock? How much faster will the card peform? Seems strange that underclocking anything can improve performance... Can't find any info about this.

Hello, this question was supposed to be as an entry in the https://bitcointalk.org/index.php?topic=1458.160, but I am noobie, so let's hope he will see it here instead.

Anyway, I have been trying to compile the latest source downloaded from the topic ((Updated 2010-12-24), based on SVN 205), and have been having a lot of problems. And while some of them were due to my lack of knowledge and have fixed themselves as soon as I learned the right stuff, some of the problems seem to be just things that have to be fixed in the source.

I am compiling on x64 windows with MINGW. (not x64 executables, just running on a x64 os. The executables are compiled to x86 arch.)

1. I am getting very strange compile errors in src/remote/remoteminer.cpp

Code:

bitcoin-remote-rpc-20110122-src\src\remote\remoteminer.cpp:751:27: error: no match for 'operator=' in 'i = ((BitcoinMinerRemoteServer*)this)->BitcoinMinerRemoteServer::m_receiverate.std::map<_Key, _Tp, _Compare, _Alloc>::erase [with _Key = long int, _Tp = unsigned int, _Compare = std::less<long int>, _Alloc = std::allocator<std::pair<const long int, unsigned int> >, std::map<_Key, _Tp, _Compare, _Alloc>::iterator = std::_Rb_tree_iterator<std::pair<const long int, unsigned int> >](i)'

Assuming the author has compiled this somehow and it's not just a wrong version of the file or something, it looks to me like there are different versions of stl out there, and the one I have (in mingw) does not support = operator on stl container.
This does not look too difficult to fix, just rewrite that line in a way that doesn't use the =operator.
This is like this in just 2 places, no biggie

2.
errors

Code:

C:\Users\heavydist\Downloads\jelcin\build\bitcoin-remote-rpc-20110122-src\src\remote\remoteminer.cpp:929:66: error: 'getaddrinfo' was not declared in this scope
C:\Users\heavydist\Downloads\jelcin\build\bitcoin-remote-rpc-20110122-src\src\remote\remoteminer.cpp:962:22: error: 'freeaddrinfo' was not declared in this scope

After searching "the internets" something like this http://www.developpez.net/forums/d734362/c-cpp/c/getaddrinfo-was-not-declared-in-this-scope/ comes up, and so the error is easily fixed by modifying the src/headers.h file

instead of "#define _WIN32_WINNT 0x0500" insert  "#define _WIN32_WINNT 0x0501" and these errors go away

3.
but now when the compilation errors about getaddrinfo and freeaddrinfo go away, the linker cannot find them either. By looking through CMakeFiles.txt in the project I couldn't find any library that should hold these functions, so I added it
(to files cmake-bitcoin/CMakeLists.txt, cmake-bitcoind/CMakeLitst.txt and such. NOT the root CMakeLists.txt)
change

Code:

IF(WIN32)
	TARGET_LINK_LIBRARIES(bitcoin winmm.lib shlwapi.lib)
ENDIF(WIN32)

to

Code:

IF(WIN32)
	TARGET_LINK_LIBRARIES(bitcoin winmm.lib shlwapi.lib ws2_32.lib)
ENDIF(WIN32)

After that the program links just fine.

4.
Now actually the main problem: now bitcoin.exe is produced, but cannot be run...
I get the "The application was unable to start correctly (0xc000007b)."
If that code is the standard windows error code, it's
"ERROR_INVALID_NAME 123 (0x7B) The filename, directory name, or volume label syntax is incorrect."

What could this mean? Any ideas?