Ah! I wasn't aware of that.  Thanks for the pointer.
It looks like with some effort, a USB 2.0 dongle could reach 0.5 TH/s (consuming 2.5 watts)
That is, 1.8 KWH / month (assuming 24h/24h operations - unrealistic!), that is roughly 4 USD energy costs per month - less than your bank fees!
If such a dongle was available, it is likely that many bitcoin (and other alts!) users would purchase and use it, as it guanrantees their own security (ie protection against 51% attacks / other forms or attacks...), this would decentralize mining effectively.
Let us suppose that such a dongle would sell for 20 USD, profit 5 USD.
When motherboard manufacturers will realize that they can get enter this market easily by providing it on board, at cost 10 USD, profit 2 USD, they will do...

So the question is: how to lower the barrier of entry to mining and make it affordable for the masses.

If the (current) bitcoin protocol has been foreseen to cope with tenths of millions of miners, that should work and is only a question of time.

I gave you an example of a good commercial existing chip to explain that there is no need for billions of users.
That chip is using 14nm technology (and is less than 20mm2 btw), so by far not the most optimized thing that could be achieved with the most recent technologies.
We are not far from the 2.5watts of USB2.0 for example, which opens the door for simple mining using USB dongles.
You can also be quite certain that big players could design faster/smaller/more efficient chips.

It looks to me like completely decentralized mining is within reach.  Laptops consuming 50 watts for example could easily accomodate 5 watts overhead.

So, the question is more about the network related issues, and the underlying bitcoin mining protocol requirements.

You can either prune the chain or use a pool.  I don't see this as a major issue.

The BM1387 ASIC chip is capable of ca 0.07 TH/s and consumes roughly 5 watts.
You would need some 70 millions of those installed to match the current total network hash rate.  No need for billions or users.

Phone and PC/laptop manufacturers could add an ASIC to their boards for example.
Or dongles could be made (possibly combining OTP generation with mining killing two birds with one stone...).
Quite honestly the "price" to pay (ie device + energy costs) is well worth it !

I believe that the major issue would be rather on the network bandwidth / latency side of things.
I do not know if bitcoin has been designed with such a heavily decentralized mining in mind.

BM1387 ASIC inside the Antminer S9: 189 pcs per unit, each unit 14 TH/s
So, each BM1387 is capable of ca 0.07 TH/s, consumption roughly 5 watts as well
To achieve the current 5.000.000 TH/s, you would need 71 millions of those.
Assume 50% mobile users with one chip, and 50% desktop users with two chips, that means a completely fully decentralized network of roughly 50 millions users.
The issues would seem to be more on the network bandwidth / latency etc side than on the ASIC side I believe.

150pcs of A3233-q48 are fitted in a 1TH/s Avalon Miner.
See https://bitcointalk.org/index.php?topic=523309.0
Cost per unit is ca 0.1 USD
Consumption is about 5 watts

So it seems that if each user/miner would be equipped with one chip, the number of users/miners necessary to achieve the same hash power as of today would be 5000000 TH/s * 150 = 750 millions.  That is much less than the number of facebook users !

Maybe the PoW function should be made as simple as possible, so that ASICs can be devised for it very easily.
The design of such ASIC could be open sourced - removing the barrier of entry, ensuring a level playing field.
Then, every device on the planet can easily be fitted with these ASICs and the overhead of doing would be negligible for HW manufacturer.
I do not think it would be necessary to reward miner in a heavily decentralized scenario (say, > 100M miners) - the fact that you would get secure transactions for the cost of the energy you spend seems to be enough of incentive.
Then, I also believe that any user node should (must) be a mining node.
That is, it should not be possible to use the system without contributing to mining.

Just installing bitcoind and running bitcoin-cli signmessagewithprivkey offline worked like a charm. 
No need to download the blockchain whatsoever so this is a very fast (2 minutes install time) and secure way to generate signed messages.

Thx to all for the explanations.

There are probably several reasons for why this is the case:
- Me being stupid, as I mentioned above, is a primary cause of why I would think this could be the case
- Another reason could be the confusion that exists between signing a transaction and signing a message 
- And yet another one could be that the documentation is maybe lacking / unclear

I hope this helps your understanding.

Aaaah! You nailed it.  Stupid me was under the impression that signing was somehow linked to broadcasting the message/signed message.
But it is not the case, so my questions were not relevant indeed.
Thank you for making it clear.

I guess I will try this API then: https://bitcoin.org/en/developer-reference#signmessagewithprivkey

Thank you.

I understand that I can import the private key in an (offline) tool on an airgapped computer.
However, what is unclear to me is how to generate the signed message on the airgapped computer, but submit it on an online computer.
For that, I would need to be able to export the message/signed message on a USB key for example.
Is this possible using existing tools?

I have a paper wallet, and would like to sign a message (NOT a transaction!) offline, on an air-gapped computer, transfer the message and signature using a USB key to an online computer and send the message and signature online.

a) Is there a way to achieve the above?
b) Do I put my private keys in danger in any way? In particular, can I trust the digital signature algorithm to be robust? (i.e. NOT to reveal anything about the private key)
c) Do I need to pay fees to submit the message?

Hitting 3000 USD would require a daily increase of about 0.4% for the remainder of the year.  Seems very possible to me!

Update set new value=old value - difference is more efficient and locks the row with resorting to the lock you mention.  Add a check constraint on table.

Yes, we realize fully that it will take a % of future profits.  This is the price to pay for this type of things...
=> This should be made "standard" by the BCF and people should only go to exchanges that adopt this guideline.

This is a very good post ! Thanks.

That being said, I think that the mechanism for 'reparation' should be as such:

Distribute 12.5 % shares of your company to all customers, pro-rata their BTC.
Pay dividends on a frequent basis.
Offer to buy back shares if users so desire.

It would be excellent to have such mechanisms described and agreed for all exchanges...

Epic:

Gold vs bitcoin thread, extract:

...
SG: "No, gold is real."
FS: "If your gold has not received three confirmations on the blockchain it is not real."
...

Isn't lambda a solution of l*l+l=-1 mod n ?

If that's the case, there are actually two possible lambdas:

5363AD4CC05C30E0A5261C028812645A122E22EA20816678DF02967C1B23BD72
and
AC9C52B33FA3CF1F5AD9E3FD77ED9BA4A880B9FC8EC739C2E0CFC810B51283CE

What made you choose the smaller one ?

Wow! Impressive how fast you did this!

- I suppose that addition can be sped up in bounty castle because parameter 'A' is zero for the BC curve.
- This part of your code is interesting:

for (int j = 255; j >= 0; j--) {
         sum = sum.twice();
         for (int i = 0; i < len; i++) {
            if (u2.testBit(j)) {
               sum = sum.add(Q);
            }
         }
      }

I do not know how much the 'if' and the 'testbit' method cost, but theoretically they could be replaced by a symbolic expression evaluator, at the cost of traversing a tree and a few pointers.  Not sure what would be fastest.

- I am unsure whether the 'attack'  on batch verifications apply to the use of signature verifications of the blockchain in the BC context.  Presumably, one could apply batch verify until, say, the last 1000 blocks, then switch to the individual verifications.

It would be good if there was an implementation of this available somewhere to try to figure out what the actual speed up could be, as it is not possible, on modern CPU architecture to determine the speed up by counting the number of adds/muls.  Unfortunately, I have not been able to identify an implementation.


Is it so that sipa's custom code is used in the current implementation ?

Why do you say that the technique is potentially "insecure" ? This would only be used to verify signatures on the blockchain, how can this be "insecure" ?
The signature verification can be tested thoroughly against a reference implementation (OpenSSL and sipa), so the likelihood to incorrectly verify signatures (either declaring them valid, when they are not, or vice-versa) is very low.