Topic: What does a non-mining node do for the network? (Read 743 times)

To be fair the first bitcoin ASIC wasn't as good as they are today either. For example a single ASIC unit back in 2012-2013 was only working with 0.1 to 0.3 GHS speed.

Also you have to keep issues of altcoins in mind, for example in case of Ethereum the incentive to work on an ASIC was very little and instead the manufacturers were constantly discouraged from making such an investment since this centralized altcoin has always been threatening to change PoW algorithm, they even had a difficulty bomb that ensured it.
So it is understandable that nobody wanted to dedicate valuable resources to creating Ethash ASIC for many years.

P.S. AFAIK ether miners are still computing a single round of Keccak256 (ie. SHA3-256) and this hash algorithm is designed in a way to have a computation cost that is roughly the same as SHA256. We compute a double SHA256 in bitcoin.

Right. ASIC resistant algorithms have only delayed the creation of ASICs.

I don't think having a high hashrate is necessarily something that provides security. If the hashrate is 1000 hashes per second, an attacker will need 500, or 50% of the hashrate to reliably attack the network. If the network hashrate is 100k hashes per second, an attacker would still need 50.01% of the network hashrate to attack.

What I believe provides more security is the value of the miners compared to the value of the miners if there was no bitcoin, and the R&D cost of developing the miners. If there is a high cost to develop the miners, and if the miners are valuable, the cost of attacking the network will be very high.

The argument against ASICs is that ASICs will lead to there being fewer people mining because of the high cost of ASICs. So there is the risk that a small number of miners could potentially team up to attack the network. Without ASICs, the mining process would be something closer to "one person, one vote". I think if there were no ASIC (or GPU) mining, it would still be possible for an attacker to spin up 100k VPS on GCS or AWS to attack the network.

While i agree with your statement, very few ASIC-resistant perform good enough. For example, developing Ethash ASIC took long time and it's efficiency isn't very big against GPU (if you compare efficiency between GPU and ASIC with different ASIC-resistant algorithm). RandomX also looks promising, but time will tell how well it perform.


As long as there's multiple competitor on SHA-256 ASIC, i would say no.

No, we don't need that. Pools were created to reward miners more often for a fraction of their power. Many coins were created just because mining difficulty on Bitcoin was too high and it was easier to mine some altcoin and exchange it for Bitcoin. So, there is no need to change the mining algorithm, as long as it is not broken. The only problem is getting a fraction of the block reward in decentralized way, so that running a full node and mining N times easier block would result in getting N times smaller reward. So far, people solved that problem by creating centralized pools and mining altcoins, but I believe there is a solution that could work directly on Bitcoin.

So far based on what I've seen ASIC resistant meant you can't use bitcoin SHA256d ASICs to mine that algorithm but creation of an application-specific integrated circuit (ie. ASIC) is very well possible. Even those that tried using more memory with memory expensive algorithms ended up having ASICs.
The only working solution so far seems to have been changing the algorithm every now and then!

P.S. Do we even want an ASIC resistant algorithm? After all ASICs with their huge hashrate are providing the security.

That would be similar to looking at the output address of the block reward to try to figure out how many miners are mining. It would be trivial for a miner to change the metadata for every block they find.

I don't think any "ASIC resistant" algorithm would be desirable to implement. All it would do would be to make it more difficult to develop ASICs, and there is always the risk that the person advocating for a particular algorithm has already done some research on how to create ASICs for that algorithm.

Despite this not being foolproof, it would be interesting to submit a BIP for adding metadata such as the device used within the GetBlockTemplate RPC, obviously with small size limits.

When you mine via a pool today, the pool will periodically payout your earnings. If someone was earning enough, they could receive their earnings every hour.

I also don't think it would be feasible for pools to offer LN payouts if the pool is obtaining its revenue from block rewards (as opposed to selling hashrate to a third party). The pool would need to consistently by opening new channels, and the miners would likely be consistently closing channels.

I am not sure what the payment structure is for most pools today, however there are many payment structures that depend on the pool's performance over periods longer than one hour.   

From an earnings perspective somewhat, but not from a governance perspective.

If you have a single LN channel open with a large capacity amount, you are not going to earn any revenue, because there would be no routes going through your node. Going a step further, if you have a small number of channels open with a lot of capacity, your node may not get much traffic, depending on the network topology. If you have many channels open, with a fairly small amount of capacity, you may earn more than the person with larger capacity if your open channels are well placed within the network, such that many people route payments through your node.

PoS nodes also can choose which transactions to confirm. With LN, it is not possible to choose which transactions to allow (other than by amount of the tx and the amount the participants are paying your node).

That kind of already exists, actually! NiceHash supports Lightning payments with a pretty low limit, so you could cash out daily if you have enough hashpower.

But, contributing power to a pool doesn't pay you on-chain without trusting the pool. I haven't tried this ever, but don't you get pool shares firstly and then you give those for BTC? Wouldn't it be better if you were rewarded every hour, off-chain?

Also, let's not forget that: LN is essentially PoS! 

I don't think that is very realistic. L2 protocols are not ever going to have anything similar to PoW-type mining because they rely on the L1 layer. The closest thing to mining on LN we will ever see is someone running a LN node that generates revenue via LN-tx fees in a way that is similar to how PoS miners earn "mining" revenue.

If we want to solve the issue of mining pools having more power than they should then we should just solve that instead of changing the bitcoin protocol that has nothing to do with mining pool and their issues and add new issues on top of all that.
The solution is also not that hard, we just have to change the pool protocol and how the miner communicates with the pool so that the miner can participate in decision making such as signalling for changes. There are proposals like betterhash out there already.

Running two algorithms together is also possible. You can require SHA-256d with existing difficulty and some new algorithm with some new difficulty. First you rehash all old blocks with some new algorithm, then you include both headers: old nodes see old headers and stay in the network, new nodes see everything.

If SHA-256d will be completely broken, it is possible to force producing blocks with all (or almost all) leading zeros and store new hashes in the same place. For example: if you have 256-bit hashes and it is trivial to produce a hash with 224-bit leading zeros, then you can place the whole previous block hash of the new hashing function in the same field, then you will store both old and new block headers in a compact, 80-byte form.

I agree it's not needed to change SHA-256 and it'd be great to reduce dominance of centralized pool. However, i'm not talking about changing SHA-256, but running 2 algorithm together since i assumed that's what @itel meant.

They did even less than that: there are still commands that allow generating blocks: you have "generatetoaddress", "generatetodescriptor" and "generateblock". They can be used on all networks, including mainnet. But there is a catch: they are building on top of the block they saw when executing command, so if you run "generatexyz" command and a new block will be received during mining, you will mine a block on top of some old block. So, you can mine directly using Bitcoin Core and nothing else, but it is easier to connect external miner, even if it will be some CPU miner, because it is more convenient and you will get less stale blocks in this way, because any miner will take care of calling "getblocktemplate" and updating previous block and other block data correctly.

But they didn't remove the mining capabilities from core, they just removed the command for it. The code still exists.

You are right, they won't. We are talking about millions of hashes per second for CPUs (140 million according to wiki) compared to hundred tera hashes per second (that's 100 trillion). They can't compare and even if ASICs went down there won't be enough blocks mined to reach the difficulty adjustment.

Oh, you mean sort of decentralized home mining pool through Lightning 'contracts' in a way? Not 100% sure what you envision, but a lot will be possible through Lightning. Definitely excited for the future!

It is not a setup that exists today, it is just my explanation of what is technically possible and could be done to decentralize mining and to make CPU mining possible. For now, it is just an idea, more work on that is needed to make it real.

LN has no mining, it's not a blockchain. It's an off-chain transaction method. So you cannot mine 'in the Lightning Network'.

True, you can use a CPU miner and connect it to Core, that's possible.

Because it is more likely that you will win a millions or billions of dollars in a lottery than you solo mine a single block on your CPU. Also, this option is still available, you can call generatetoaddress and mine a block in this way. Also you can connect any CPU mining software, choose SHA-256d as an algorithm and start mining on your CPU. Technically, you can connect your CPU miner to your full node. Practically, you will get nothing, or maybe a single block in your lifetime, if you will be extremely lucky.

In practice, if you want to reintroduce CPU mining option and if you want to get any coins, you can try to do some kind of mining in the Lightning Network. Then, I can imagine that a thousands or millions of CPU miners will mine on some shared N-of-N multisig, expressed as a single taproot address, and maybe will mine some block together. But for most of the time they will get nothing and use a fraction of their computing power to replace LN fees with their blocks. So, it is technically possible to, for example mine a block way easier and instead of receiving 6.25 BTC plus fees, receive one satoshi in LN, because your block will meet around 625,000,000 easier difficulty and another party will accept shares instead of coins.

Currently, changing the mining algorithm from SHA-256d to something different is not needed. All that is needed to decentralize mining, is receiving smaller amounts of coins without having to trust any centralized mining pools. I can imagine people moving single satoshis, millisatoshis, or maybe smaller amounts in decentralized way. The algorithm can be the same, as long as it is not broken.

Nobody needs that. You can connect any miner to your full node, in this way you can replace the old miner with the new miner (and even run them on two machines in parallel to compare them) without changing Bitcoin Core. That situation is way better than rebuilding the Core client, just because you want to make faster miner.