What does a non-mining node do for the network?

[n0nce]

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

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.

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!

[1714675037]

1714675037

[1714675037]

1714675037

[1714675037]

1714675037

[1714675037]

1714675037

[pooya87]

No no, I think he means simply adding back the CPU mining capability to Bitcoin Core.

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

The issue though is the scales we're talking about. ASICs are not just a bit faster than CPUs, they're orders of magnitude faster. So I'm not sure if even all Bitcoin nodes ran a CPU miner in the background, it would help in any type of attack.

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.

[garlonicon]

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

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.

[ABCbits]

First of all, how would consensus work when are 2 different PoW (SHA-256 and other algorithm for CPU) on the network?

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.

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.

[garlonicon]

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.

[pooya87]

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.

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.

[Quickseller]

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

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.

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.

[BlackHatCoiner]

L2 protocols are not ever going to have anything similar to PoW-type mining because they rely on the L1 layer.

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! 

[n0nce]

L2 protocols are not ever going to have anything similar to PoW-type mining because they rely on the L1 layer.

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?

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.

[Quickseller]

L2 protocols are not ever going to have anything similar to PoW-type mining because they rely on the L1 layer.

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?

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.   

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

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).

[NotATether]

Additionally when it comes to doing work we have no way of distinguishing what hardware was used to perform that work. In other words someone could build a new ASIC to mine the new "slow CPU mining option" and we would be right back where we started.

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.

[Quickseller]

Additionally when it comes to doing work we have no way of distinguishing what hardware was used to perform that work. In other words someone could build a new ASIC to mine the new "slow CPU mining option" and we would be right back where we started.

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.

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.

[pooya87]

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.

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.

[garlonicon]

Do we even want an ASIC resistant algorithm?

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.

[ABCbits]

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.

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.

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.

P.S. Do we even want an ASIC resistant algorithm?

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

[Quickseller]

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.

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!

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

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

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.

[pooya87]

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).

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.

Code:

Antminer E3 has 190 MHS 
Btc-Digger (ASIC) had 150 MHS (released 2013)

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.