Wednesday, January 25, 2017

Bitcoin network congestion problems & withdrawal threshold increase

Bitcoin network congestion

It is well known that due to the temporary anti-DoS limit introduced by Satoshi Nakamoto in 2010, the current Bitcoin throughput is constrained to about 3 transactions per second.

With every difficulty increase it temporarily drops and then starts growing with miners' hashing power until the next difficulty adjustment.

That is why on the 21st of January after the expected 16.64% difficulty increase many Bitcoin users faced higher bitcoin fees and longer transaction confirmation times. Dozens of thousands of unconfirmed transactions still reside in the mempool.


It will probably take a few days for most of them to get confirmed. But the situation is going to become worse with every difficulty adjustment unless Bitcoin adoption stops or its throughput is increased.

Bitcoin scalability controversy


Bitcoin community has been discussing the scalability problem for years and despite the fact that it came up with a few potential solutions, it has been failing to find the one that would satisfy everybody.

According to Nodecounter, about 17% of mining power is in favour of increasing the block size limit via a hard fork proposed by Bitcoin Unlimited team, whereas 24% support Segwit proposed by Bitcoin Core developers. For some reason the compromise that would include the benefits of both solutions has not yet been achieved.

This leaves us in the reality where a constrained Bitcoin throughput diminishes our ability to handle micro-transactions and forces us to keep users' money longer than we would prefer to.

Low value transactions

The problem with micro-transactions is that they take the same amount of block space as high value transactions, but it doesn't make economic sense to add high fees to them.

Hence they have a relatively low fee and in the current state of Bitcoin there is no guarantee that the low fee transaction will ever be confirmed.

E. g. the recommended fee currently is 120 satoshi per byte and the average transaction size is 226 bytes, thus if you want to quickly move 10000 satoshi, you have to pay a fee of 27120 satoshi.

In order to save the block space we use hourly sendmany transactions to pay our users. It allows us to send money to multiple recipients in a single transaction. E. g. if there are 64 recipients, then the transaction is only ~2309 bytes, or about 4329 satoshi per recipient (that is still prodigal for 10000 satoshi withdrawals).

That's why use use a small fee of 20 satoshi per byte (or 721 satoshi per recipient). It worked just fine until recently.

"Insufficient funds" incident

Yesterday we noticed that our bitcoin node couldn't create new transactions and returned the "Insufficient funds" errors despite the fact that the listaccounts command returned sufficient balance on our account (unlike getbalance and getinfo calls that returned a negligible balance).

We investigated the cause of this inconsistent behaviour and figured out that all of our hourly outgoing transactions got stuck after the latest difficulty increase thus forming a long chain of unconfirmed transactions. Our bitcoin node refused to continue this chain and decided to wait for confirmation of the change.

Thanks to ViaBTC pool for its transaction accelerator that enabled us to push through the stuck transactions and thus temporarily solve the problem.

Really, thank you!

Withdrawal thresholds increase

Recently we increased the default withdrawal threshold to 0.0001 btc , but many users still had lower values in their settings.

Since they might be unaware of how expensive it could be for them to spend the received micro-amounts, we decided to increase their withdrawal thresholds to 0.00100001 btc (while allowing them to set it back to 0.0001 btc if they want to).
 
We still need to develop a long-term solution and may be forced to increase the minimal withdrawal threshold, the interval between transactions, or to add a withdrawal fee in the future.

Wednesday, January 18, 2017

A 10x increase of the default withdrawal threshold

Dear A-ads users,

For security reasons we don't want to keep your money for a long time. That's why once your earnings hit the configurable withdrawal threshold, we send them to your bitcoin address automatically (on a daily basis).

The default withdrawal threshold used to be BTC 0.0001 (10 thousand satoshi) but due to increased bitcoin transaction fees caused by the limited blockchain capacity we decided to increase it to BTC 0.001 (100 thousand satoshi).

You still have the ability to set the minimum withdrawal threshold to BTC 0.0001 however you must keep in mind that if you want to receive many tiny transactions it might be very expensive for you to spend them later. E. g. if your spending transaction has hundreds of inputs, it may require a fee of about $30 worth of bitcoins.

Despite our desire to withdraw funds as soon as possible if bitcoin fees continue to rise we may be obliged to adjust our withdrawal policy.

Monday, October 10, 2016

A change in our policy: the number of ad units per page limit or how many ad units are allowed

After a careful consideration we are announcing a slight alteration of our policy which we believe will affect only a fraction of our publishers.

Starting from October 2016 we now only guarantee that only up to three ad units per page will be served to the visitors of your website and here's why.

Unlike other advertising networks, A-Ads doesn't pay merely for impressions or for clicks: we consider globally unique impressions within our entire network. It becomes obvious then that having more than several ad units per page doesn't make a lot of sense from the financial point of view: additional ad units might not necessarily bring your additional earnings.

Secondly, we've had a number of publishers who placed literally dozens of dozens of ad units per page in a hope that extra ad units would proportionally increase their earnings and of course that hadn't helped their cause. Consequently our servers bore a very substantial computational burden and it jeopardized our operations.

Tuesday, August 30, 2016

Downtime and compensations to the advertisers

Yesterday at 7:54 UTC during deployment of the newer version of our software we encountered an unexpected problem that made our site unavailable. It took about 3 hours to figure out the reason and resolve the issue. It didn't affect publishers' income, but unfortunately part of that time the graphic versions of ads could not be served properly.

We decided to compensate the downtime to all the advertisers. Here is the list of campaign IDs and the respective amounts (in satoshi):

[[1, 62500], [3782, 1250000], [4888, 12500], [5305, 625], [5334, 625000], [7358, 125], [9712, 12500], [9713, 3749.875], [9714, 3749.875], [9715, 3749.875], [9716, 3749.875], [9717, 3749.875], [9718, 3749.875], [9719, 3749.875], [9720, 3749.875], [9721, 3749.875], [9722, 3749.875], [9723, 3749.875], [9725, 3749.875], [9726, 3749.875], [9727, 3749.875], [11013, 125], [11736, 1250], [12323, 1250], [13145, 2125], [13159, 1250], [13161, 1250], [13164, 1250], [13324, 1250], [13355, 12500], [13547, 112499.75], [13614, 62500], [13669, 250], [13751, 1250], [13853, 375], [14929, 37500], [15092, 37500], [15128, 37500], [15236, 37500], [15397, 37500], [16095, 12500], [16214, 62500], [16307, 375], [16936, 37500], [17012, 12500], [17686, 500], [18051, 37500], [18594, 62500], [19722, 625], [19849, 37500], [20102, 0], [20207, 1937.5], [20218, 2500], [20594, 1250], [20634, 125000], [20638, 125000], [20639, 125000], [20696, 3749.875], [20715, 250000], [21095, 187500], [21105, 6250], [21282, 3749.875], [21338, 37500], [21402, 1250], [21496, 1250000], [21556, 37500], [21576, 250000], [21595, 4375], [21627, 37500], [21780, 12500], [21811, 43750], [21965, 3749.75], [21997, 1525], [22021, 37500], [22159, 37500], [22206, 7499.625], [22396, 25000], [22474, 125000], [22560, 37500], [22666, 375], [22699, 2500], [22744, 25000], [22755, 125000], [22756, 125000], [22790, 250], [22819, 125000], [22885, 12500], [22887, 12500], [22998, 43750], [22999, 125000], [23006, 125], [23036, 25000], [23116, 1250], [23117, 37500], [23129, 37500], [23136, 25000], [23201, 625], [23308, 375], [23367, 125000], [23378, 1250], [23407, 375], [23461, 12500], [23466, 25000], [23563, 25000], [23570, 62500], [23571, 37500], [23616, 5000], [23674, 100000], [23755, 12500], [23758, 12500], [23797, 12500], [23805, 1250], [23811, 12500], [23834, 37500], [23838, 8750], [23843, 5000], [23846, 5000], [23856, 37500], [23858, 1250], [23864, 12500], [23867, 12500], [23879, 62500], [23885, 62500], [23886, 62500], [23899, 6250], [23905, 125000], [23910, 125000], [23911, 12500], [23927, 187500], [23936, 0], [23947, 62500], [23949, 0], [23954, 125000], [23960, 62500], [23961, 75000], [23971, 12500], [23973, 12500], [23974, 62500], [23977, 31250], [23981, 262500], [23985, 1250], [23993, 50000], [23999, 12500], [24006, 25000], [24007, 125000], [24009, 12500], [24010, 12500], [24020, 12500], [24022, 12500], [24023, 125000], [24026, 12500], [24027, 1250], [24029, 12500], [24030, 12500], [24033, 25000], [24034, 875000], [24037, 12500]]

The funds have been returned to the campaigns' balances. 

We also returned the funds that we had promised to return in June (sorry for the delay), so some of the 0-balance campaigns with positive daily budgets were resumed.

Tuesday, June 21, 2016

We are having technical issues [RESOLVED]

Sorry, we are having a technical issue that affects the availability of our web site and of the graphic banners. We are working to resolve it.

Update 22:10 UTC: The issue probably appeared about 5 hours ago. We expect to fix it in 1-2 hours. Sorry for the inconvenience.

Despite the mentioned problems, publishers' ad units are continuing to earn and advertising campaigns are continuing to spend. Publishers' income is not affected.

Since the issue is related to the graphic banners, advertisers that have them will be compensated for the missing impressions.

Update 23:19 UTC: The issue has been resolved. The  main site should be available and the graphic ads should be served properly.

The estimated downtime was about 6 hours. Here is the preliminary list of the  advertising campaigns than were affected by the issue (in the form of the JSON array of pairs <campaign id, estimated loss in satoshis>):

[[1, 83333], [5334, 833333], [5516, 16666], [7550, 33333], [9712, 16666], [9713, 4999], [9714, 4999], [9715, 4999], [9716, 4999], [9717, 4999], [9718, 4999], [9719, 4999], [9720, 4999], [9721, 4999], [9722, 4999], [9723, 4999], [9725, 4999], [9726, 4999], [11719, 25000], [11720, 4999], [11721, 4999], [11723, 4999], [11724, 4999], [11725, 4999], [11726, 4999], [11727, 4999], [11729, 4999], [11730, 4999], [11732, 4999], [11733, 4999], [11735, 4999], [11738, 4999], [11739, 4999], [11740, 4999], [12827, 5500], [13547, 149999], [15092, 50000], [16095, 16666], [17012, 16666], [17920, 16666], [18402, 25000], [18689, 25000], [18692, 4999], [18693, 4999], [18694, 4999], [18695, 4999], [18697, 4999], [18698, 4999], [18699, 4999], [18701, 4999], [18702, 4999], [18703, 4999], [18704, 25000], [18708, 165277], [19041, 283333], [20012, 166666], [20055, 500000], [20102, 33333], [20207, 50000], [20379, 16666], [20512, 8333], [20574, 8333], [20634, 333333], [20638, 1000000], [21022, 66666], [21095, 333333], [21105, 8333], [21148, 1666666], [21186, 16666], [21221, 33333], [21249, 33333], [21250, 33333], [21256, 16666], [21338, 50000], [21373, 33333], [21374, 16666], [21375, 33333], [21377, 33333], [21379, 33333], [21419, 50000], [21424, 16666], [21496, 2500000], [21519, 83333], [21523, 20833], [21561, 166666], [21563, 16666], [21588, 166666], [21597, 50000], [21600, 16666], [21623, 16666], [21627, 66666], [21642, 16666], [21648, 3333], [21650, 3333], [21651, 3333], [21652, 3333], [21662, 16666], [21664, 4999], [21666, 16666], [21682, 16666], [21714, 3333], [21715, 116666], [21716, 16666], [21739, 33333], [21740, 66666], [21757, 3333], [21763, 50000], [21766, 116666], [21769, 2499], [21770, 2499], [21776, 16666], [21777, 16666], [21779, 16666], [21785, 50000], [21787, 33333], [21790, 33333], [21791, 333333], [21792, 8333]]

The estimated advertisers' losses will be compensated in a day or two.

Monday, June 20, 2016

Withdrawals from user's campaigns go to user's account balance

A-ads users' balances are automatically used to top up the depleting balances of their active campaigns (the ones with positive daily budget and activated ads).

In order to pause or stop the campaign, the advertiser has to set its daily budget to 0. It may leave a tiny unsused balance that is sometimes too small to get withdrawn via bitcoin transaction.

That is why we introduced a change: if advertiser requests a withdrawal from her campaign, the campaigns' balance will be returned to her user account (instead of bitcoin address). So even a single satoshi left on the campaign's balance can be withdrawn (and the campaign can be safely deleted after that).

This change doesn't affect anonymous campaigns that are not linked to any particular user.

Thursday, June 2, 2016

A-ads affiliate program: create affiliate link in less than 30 seconds


We share 50% of fees collected from advertisers with our affiliates that attracted them. We paid out over 44 btc in over 85 thousands of rewards (all are public and transparent).
 
Everybody can participate in our affiliate program, you don't even need to have a web site neither a user account to do it.

1. Click "Earn" in our top menu:

2. Select any ad unit type (if you don't plan to embed our ad unit anywhere, then select "affiliate"):


3. If you are in a hurry then just scroll down to withdraw parameters, click "Bitcoin address", paste your bitcoin address and click "Create ad unit":

That's it, notice your affiliate link!


Share your affiliate link with potential advertisers and get 50% of fees collected from ads that they create with it.

Note: for your own convenience it is recommended to sign up before creating your affiliate link (in that case on step 3 choose to withdraw to your user account).