Judging by what numbers?


How did you determine that it is by far the superior? Did you make the comparison?

Thank you for your words of support. Yes, UI need to be improved, functionality enhanced, more content with information about bitcoin signatures should be placed there as well.

I announced Bitcoinocracy here and in Reddit (https://www.reddit.com/r/Bitcoin/comments/3ef380/bitcoinocracy_an_opensource_project_to_facilitate/), but I don't see much interest yet. Someone just created an argument "ok" and nobody signed any statement.

Thanks for your question. It looks like not so many people are aware of bitcoin signatures.

When I say "to sign with bitcoin address" I mean "to sign with the private key that corresponds to the bitcoin address". Each bitcoin address has a corresponding private key that can be used to create a cryptographic signature for any message. Popular bitcoin wallets (Bitcoin-QT, Electrum, Armory, Multibit, Blockchain.info) support this functionality.

When you sign a statement with your bitcoin address (and submit it), Bitcoinocracy considers that statement to be supported by all bitcoins stored at that address.

Different people can sign the same statement with their bitcoin addresses and Bitcoinocracy will sum their balances up.

If the statement is controversial then some people are likely to sign the opposite statement and Bitcoinocracy will evaluate the validity of the argument as a difference between sum of beleiver's and sum of doubters' bitcoins.

It is somewhat similar to shareholder voting in the corporate world. Your weight depends on amount of voting shares (satoshis).

This is an experimental launch of the Bitcoinocracy -- a project that aims to determine the truth backed by real monetary value and to facilitate decentralized decision making in the Bitcoin eco-system.

It is not a commercial-grade software, but it is absolutely free, transparent, open source and doesn't require user registration.

Just sign the statements with non-empty bitcoin addresses to express your opinion.

PS: I wanted to make it long ago but I didn't have time to do it and wasn't sure there would be a demand for it, so I decided to publish it and see what happens. Anybody is  welcome to participate.

Thanks for your valuable feedback.

I agree that the system is unusual and thus confusing, but it is more or less fair. If you have N banners on your page, that doesn't mean that you will attract N times more customers to your advertisers. More banners you display to a single visitor, less valuable each impression is. That sounds reasonable and that is expected to be priced in by the market.

If you want to know how many times the banner was displayed on your site - please see the charts for non-unique impressions in the "Stats" section of your ad unit page.

Advertisers are probably most interested to see the globally unique impressions, because when they target N publisher's ad units with M unique impressions each, they expect to get N*M unique impressions.

That wouldn't be the case if we had counted unique impressions the way you suggest.

PS: if your ad unit attracts customers to our advertisers, you can earn no matter how many unique clicks/impressions you have (e. g. https://a-ads.com/ad_units/74193/stats). that's why we dedicate a share of impressions from under-monetized ad units to affiliate programs (https://a-ads.com/admin/affiliate_programs), you can edit "Expected income" value to adjust this share.

yes, they are, but any of them may receive transactions in future.

Eventually I managed to send out the money from the old wallet.

I tried to partially synchronize the wallet form 0 to 10000, then from 10000 to 11000, from 11000 to 12000, etc, and noticed that somewhere between 16000 and 16500 addresses an exception happened:


(the line numbers might not match yours since I was experimenting with the sources locally)

So I added a "return" to the beginning of the remove_transaction function in wallet.py (so that this function doesn't do anything and doesn't raise an exception) and successfully synchronized the wallet and sent out funds from it. I think this problem is solved for me until I upgrade to the next version of Electrum

Despite the fact that the "hacked" version of Electrum displays the balance as if it were synchronized, unfortunately this hack didn't solve my problem.

Perhaps during synchronization phase Electrum removes unnecessary information from the wallet so that it is not possible to synchronize it partially.

When I try to spend funds, it returns error 25. When I start the wallet with "-v" option, I see a bunch of errors "'No information available about transaction', u'code': -5}" from the WalletSynchronizer and sometimes "Error: history not synchronized" or "KeyError".

So I probably need to either find some non-deterministic SPV wallet and export the keys there, or look deeper into Electrum's sources and understand how it works before making modifications. Or maybe just restore the wallet from the seed and try to synchronize from scratch? It is going to take days...

I tried to synchronize my wallet for 2 days but couldn't do it. It looked like public Electrum servers refused to serve me due to the huge amount of bitcoin addresses I have. Here is a dirty hack I came up with to overcome this issue:

In /usr/local/lib/python2.7/dist-packages/electrum/synchronizer.py

I changed  


to

What it does is it allows the wallet to synchronize partially from start_index to stop_index (excluding stop_index). If start_index is not set then it will start from 0. If stop_index is not set then it will go up to the end. That's what I thought, but when I started Electrum with start_index=0 and stop_index=100, for some reason it didn't stop at 100 and synchronized it up to the end. Perhaps some other logic comes into play there, but at least Electrum servers didn't reject me and my wallet got synchronized from the first attempt! I hope I didn't break anything.


PS: I used Electrum's console to specify start_index and stop_index parameters, e. g.: wallet.storage.put('start_index', 10000) sets start_index to 10000 and wallet.storage.put('start_index', None) resets it.

The problem with my wallet is that any of its 17K+ addresses may receive money but it is already too large to get synchronized in a timely fashion.

I wish Electrum had parameters "start key index" and "stop key index" that could be used to create multiple wallets from the same seed with different sets of the keys, e. g. wallet1.dat for keys 0..9999, wallet2.dat for keys 10000..19999, etc. Then each individual wallet wouldn't be too large and I could synchronize them time to time separately

I agree with Satoshi on this, but please keep in mind that Electrum wallet is deterministic. I don't suggest to delete the wallet, I suggest to delete (or just to ignore) the information that can be easily recovered from the seed and the blockchain if needed.

Thanks for your answers, very helpful!

Not sure what are the bottlenecks there. Do you think Electrum could support unlimited amount of bitcoin addresses without performance issues (assuming that only a few thousands of the addresses are being used at a time)?

E. g. would it be technically feasible to:
1) automatically delete information about the used addresses with 0 balance that haven't been used for a while
2) partially recover this information when those addresses receive new funds
?

Thanks for your answer!

Actually I do use several Electrum wallets.

A small one with 421 addresses takes less than a minute to load, connect and synchronize. When I start it with -v option (verbose) then it displays a bunch of WalletSynchronizer messages in console without any any errors.

But for the big wallet it writes "SSLError: The write operation timed out" in console all the time and I am spending half a day to get it into synchronized state (restarting it time to time if it doesn't output anything meaningful a while).

Connections settings are the same.

After I broadcast a transaction I can see that Electrum fetches the history for each of its inputs. It takes at least 5 seconds and a bunch of SSLErrors to fetch the history for 1 input. And my transactions from the big wallet often contain hundreds of inputs, so it takes a while.

I created my Electrum wallet in 2013 and I liked how it worked. But now it contains over 17000 addresses and takes a lot of time to synchronize. Even if it is synchronized, it becomes sluggish after I send a transaction.

Can it handle the ever-increasing amount of bitcoin addresses?

Public Electrum servers have limits of 10000 addresses, does it mean I should create a new wallet each time my old one approaches this limit?

Thanks!

Since almost nobody is using coingiving.com, we are closing it. The domain name coingiving.com now redirects to tip4commit.com.

Thanks to blockchain.info all the donation addresses should still work and all the donations sent to them should still be forwarded to their recipients.

The sources of coingiving are available at github (https://github.com/tip4commit/coingiving/). I saved a copy of server files and the database too just in case if anybody needs it.

Thanks to all the contributors!

I am not either. So if anybody thinks that "Desired income" is a better title for this parameter or has another word for it then please let me know.

Since "unique impressions" in terms of a-ads means something different from what our publishers and advertisers think, we are considering to introduce couple of changes:

• Display non-unique impressions by default
• Don't display unique impressions at all (since we don't have it in traditional understanding) but display a relative measure of ad unit's audience instead. It will be calculated based on your share of network-wide unique IPs/24hours. If you have several ad units on the same page, you will get more impressions but the relative measure of your audience won't change. What's a good name for this indicator?

This is a cosmetic change that won't affect money distribution algorithms. It is supposed to make our service easier to understand and probably look a little bit more attractive to the advertisers. What do you think, is it worth of doing?

Renamed "Min Daily Income" to "Expected Daily Income". Hopefully it is easier to understand the meaning of this parameter now. Or would "Desired Daily Income" be better? 

Thanks for your feedback. I think "Expected Minimum Daily Income" is too long. Do you think "Expected Daily Income" would be good enough?

Thanks for your message. Sorry for not being clear.

Minimum Daily Income (MDI) represents the minimum level of income you expect to earn from your ad unit per day.

You probably know something about the quantity and quality of your traffic and you expect that your average daily income should be in a certain range. So just set the MDI to the lower bound of that range.

If advertisers pay you less than MDI then they won't get 100% of your impressions, your unsold impressions will be used to display free affiliate programs that can potentially increase your income if your traffic converts well. That's the main idea behind this feature.

If advertisers pay you more than MDI then your traffic will be considered monetized and no impressions will be used to display affiliate ads for free.

If you set MDI too high then that might decrease your income due to advertisers' Max CPM constraints.


The default value is small enough to prevent a significant increase of traffic cost for advertisers, but at the same time it is big enough to prevent advertisers from monopolizing ad units by paying them just few satoshis a day. It gives a chance to new or severely undervalued ad units with useful but mostly non-unique traffic to earn more.

Theoretically your daily income should depend on quantity and quality (fair value) of your traffic, but we are not yet good at measuring it, so we ask our publishers to set their expectations of MDI.

Ok, now this feature is announced (Min bid renamed to Min daily income -- should be easier to understand).



Thanks for kind words! We are far from being perfect but I hope we are moving in the right direction.

If you embed your ad unit to the URL specified upon ad unit creation or to any other URL under the same domain then there is no problem. But if you embed it to sites from other domains or generate traffic directly from mobile apps, browser extensions, etc, then it won't be counted as unique because domain name won't match.


Thanks for your feedback. Yes, this sounds like a good idea.

Do you think it would be sufficient to enable our users to get registered with their public email addresses? We'd prefer not to keep others' secrets (like private email addresses).